From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05F3BC43334 for ; Wed, 6 Jul 2022 03:15:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229884AbiGFDPy (ORCPT ); Tue, 5 Jul 2022 23:15:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229606AbiGFDPx (ORCPT ); Tue, 5 Jul 2022 23:15:53 -0400 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 772811BE8E for ; Tue, 5 Jul 2022 20:15:52 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id w2so478136ljj.7 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=U+HXHZ3rVNJxsJGsIp07ig8t6hF08E1G0uBdnXvJoOP+oDOvKmrHPUp3xXPUTqJZdU +bSIqwK4KcUGaA0KaJJEpWiFkowKEkBxtivY2Xe2IKtnNq1BADlx3bCdXsfdF0rL7oYo AAb5dU9vC8SPcETun2LhWDUgUxnVnPzB4iZisZUfXaWijeymIhaNIO9u+ovYd4EkjjuX qG+RCl3+Efj4h5pbocx5+vPdHqQybLJVid/SS2CprcD3kw/zdlg+mvVMgDb3/1Lg8hpz R+0ms/oqHqqUy7nFcv0aQoUvPuQcBQhTbVbR08Ffr+SrNs1OpRYSq8LDgPrgg6M0Cps1 vxMg== X-Gm-Message-State: AJIora80LnmPBq3u5ZwEL44D+99PQEx2zdRkDjjQJuMtAdVMi3mteKXP IlX+zXMR8+7lOTOs8chcj7Ry4TSLhtFQDxicrhRM4w== X-Google-Smtp-Source: AGRyM1vAX5WpM+PWUidEjVteiohH2A9OnZY9W6tH18+Y6jl+xCfnaMAWQ+tE55YbvX2n4CNqwjWtuxBWykJfU5KsFtM= 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 Precedence: bulk List-ID: X-Mailing-List: linux-pci@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