Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp1993899imw; Tue, 5 Jul 2022 20:34:22 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vGnzgNJ7uIJRYDC3ges2yt+zzEM/0kv0vm5NDgz/QzW/nNVl9EW9hbnM7tTqgr5D0XypPq X-Received: by 2002:a05:6402:2b93:b0:43a:5aad:73c2 with SMTP id fj19-20020a0564022b9300b0043a5aad73c2mr18622552edb.300.1657078462738; Tue, 05 Jul 2022 20:34:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657078462; cv=none; d=google.com; s=arc-20160816; b=fB8fipS6JSjplqFVzz7kg9prgGUBiFzl5aZx1rCRtVgKufYPA3vGMXC3oMOUnJvCVr ucdhZZMkSDJkr19RbA6wF7DAZEFP+2/jBA99EVUkOm0J0bFkmJkS+2ahPOwyFPzPU6me 62NNb5idxdXW/b4vCNdvmW6ezitOKOfN0zmMlSvkuvN7QYSf88AdmL6tzcVag55B9RLB tJGfzckVp5ufak2O0n4lLsdVoH1ByKef5zkdW7IHy9QGfDSpmnkNlNOG23tJxH6gxyGT nyAHt5RvUrBkW4Mbh09JruhOdfx3r79+Dx/E10s37icz0cGoG4rW7f0/ZONpRtKFOX+J w/MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=3G8AJUPNdeXHxdK11v2ens9rp8pWF9KEJuCg9Xy8WOI=; b=JTgHokXPmbID5swq/bDhvIJZZ2cvu/4ZUFu3+1+4ZQWpLdvQNBk0fZFv4GUS3Xgh0s 0jRiahdkGgzMMyIzSQzDJCuYbDMvo20xXhgFLfZQFtsrgomonPzksULJrkoZXbwKKqsD 7CZF/gtlOdb/l7r8DRqL4R+MCb8Onze4p3x5LATqBsEV1uVRS9qVwyKHSClanp8m/Dv1 7Sn1PBFknWUAmeQo5DorVWcGvpt6NiOSD6RX/Dg9cgQWRiaJWOB8i5lhqwSmfk45AZtf sNu2Cy7UOBp5lrKVx2NFIXThb6YuAqc7d0YRWm+qMkW8a07Gg6tfwqPHQ25qgom8DXMz b2bw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@igel-co-jp.20210112.gappssmtp.com header.s=20210112 header.b=UQXvkK3e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d38-20020a056402402600b0043a79986c17si1889031eda.487.2022.07.05.20.33.58; Tue, 05 Jul 2022 20:34:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@igel-co-jp.20210112.gappssmtp.com header.s=20210112 header.b=UQXvkK3e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229973AbiGFDPy (ORCPT + 99 others); Tue, 5 Jul 2022 23:15:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34962 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229535AbiGFDPx (ORCPT ); Tue, 5 Jul 2022 23:15:53 -0400 Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7916B1CB04 for ; Tue, 5 Jul 2022 20:15:52 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id r9so16807245ljp.9 for ; Tue, 05 Jul 2022 20:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=igel-co-jp.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3G8AJUPNdeXHxdK11v2ens9rp8pWF9KEJuCg9Xy8WOI=; b=UQXvkK3e0+BUuLrhVL9zEaoMNJgJ/1uW7iD9TZYFbvle2tITMyV1culntFFAk7Hmkj cVGlCapiIK2i8juSYgtsF6Y0zITaiL8K7z5Wx+vcJrHM1CKwkJEykqkLKYf73Zgrz76H /BIVVNK2V8zb5vw3K/fXUwYgahiowXZh0b1V6xLPStvKZJkYmsz6rk75F3PrY8eO8vyo G1cambYG1XfxOtZAvPQzRrJ9Tv3HyI1YZtjXDZG8kbyd95XI4/fIUDZ564ffjD5Xy/sX uwCg33tg7iSNl+BX1u6Zv+pJ2P+/FVk+tPJE4xmJlJ8KNeSH35syZHhFXGTHhwjoOfBU ZBjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3G8AJUPNdeXHxdK11v2ens9rp8pWF9KEJuCg9Xy8WOI=; b=EC9fE6PUyhk0RH0+4nE425NY0PEgNCNsoSRyp+C/ElpHzRgxarm/A6TWamknJYrU49 ES8sHqQt6BUaX7UTHRWknbPEnEKj6wpmS+2oJXhatMrWzJk5+SJEh0Ox77QMVzL8uyYC 4bYx8+VrKEAbbZVjqgjHcyf6A6zkUEmSH/2jNxE2ACORMfh0krvOdHaMf7iVPlYZghBX GNkyKGDW3rsHUFtJbmpWjmVn6mGd7ex62ezZQrqccUeNjvA+v3eNYIkTmUkIokfF0Bfr 3r5dk+S/lmggXiJKukGnDJXQvU76UA8Fqgqmsxrr+lQ+LunQa2UqRhZMZ7ZrpEcAl4d1 kp2g== X-Gm-Message-State: AJIora+PkWh28tH+IaZBy0YOnLM53VoiH3+sN8ViTaaHGvElnJZ2mMaa ywTQu5xz0fZCFyqyUYcZc3nb9p2uMd589kMEMBTe4Lrl6jI= X-Received: by 2002:a2e:bb88:0:b0:25a:6ec7:a1a0 with SMTP id y8-20020a2ebb88000000b0025a6ec7a1a0mr22324641lje.360.1657077350779; Tue, 05 Jul 2022 20:15:50 -0700 (PDT) MIME-Version: 1.0 References: <20220706030812.GA109866@bhelgaas> In-Reply-To: <20220706030812.GA109866@bhelgaas> From: Shunsuke Mie Date: Wed, 6 Jul 2022 12:15:38 +0900 Message-ID: Subject: Re: [PATCH] PCI: endpoint: Don't stop EP controller by EP function To: Bjorn Helgaas Cc: Kishon Vijay Abraham I , Lorenzo Pieralisi , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Bjorn Helgaas , Hou Zhiqiang , Li Chen , linux-pci@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2022=E5=B9=B47=E6=9C=886=E6=97=A5(=E6=B0=B4) 12:08 Bjorn Helgaas : > > On Wed, Jul 06, 2022 at 11:37:29AM +0900, Shunsuke Mie wrote: > > 2022=E5=B9=B47=E6=9C=886=E6=97=A5(=E6=B0=B4) 7:40 Bjorn Helgaas : > > > On Wed, Jun 22, 2022 at 01:09:24PM +0900, Shunsuke Mie wrote: > > > > For multi-function endpoint device, an ep function shouldn't stop E= P > > > > controller. Nomally the controller is stopped via configfs. > > > > > > Can you please clarify this for me? > > > > > > An endpoint function by itself wouldn't stop an endpoint controller. > > > I assume that some *operation* on an endpoint function currently stop= s > > > the endpoint controller, but that operation should not stop the > > > controller? > > > > > > I guess the operation is an "unbind" that detaches an EPF device from > > > an EPC device? > > > > It is likely that after all of the endpoint functions are unbound, the > > controller can be stopped safely, but I'm not sure if it is desired beh= avior > > for endpoint framework. > > I'm not asking about the patch itself. I'm asking about the commit > log because "an EP function shouldn't stop EP controller" doesn't > quite make sense in English. I'm sorry. > I suspect it should say something like "unbinding one endpoint > function of a multi-function device from the endpoint controller > should not stop the controller." Yes, it is correct and represents the commit clearly. > But I don't know enough about EPF/EPC binding to know whether that > makes sense either. > > > Kishon, could you please comment? > > > > > > Fixes: 349e7a85b25f ("PCI: endpoint: functions: Add an EP function = to test PCI") > > > > Signed-off-by: Shunsuke Mie > > > > --- > > > > drivers/pci/endpoint/functions/pci-epf-test.c | 1 - > > > > 1 file changed, 1 deletion(-) > > > > > > > > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/driver= s/pci/endpoint/functions/pci-epf-test.c > > > > index 5b833f00e980..a5ed779b0a51 100644 > > > > --- a/drivers/pci/endpoint/functions/pci-epf-test.c > > > > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c > > > > @@ -627,7 +627,6 @@ static void pci_epf_test_unbind(struct pci_epf = *epf) > > > > > > > > cancel_delayed_work(&epf_test->cmd_handler); > > > > pci_epf_test_clean_dma_chan(epf_test); > > > > - pci_epc_stop(epc); > > > > for (bar =3D 0; bar < PCI_STD_NUM_BARS; bar++) { > > > > epf_bar =3D &epf->bar[bar]; > > > > > > > > -- > > > > 2.17.1 > > > > > > > > Thanks, > > Shunsuke