Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp1963537imw; Tue, 5 Jul 2022 19:48:55 -0700 (PDT) X-Google-Smtp-Source: AGRyM1ukLHUamD/cn6hZ7uLj1/TUVjLeyYVoLJySl22j6rbksk7QBQ32pNmIxsL1/+cjblsVsmk0 X-Received: by 2002:a17:90a:4294:b0:1ee:f3f2:9cd0 with SMTP id p20-20020a17090a429400b001eef3f29cd0mr45516046pjg.79.1657075735469; Tue, 05 Jul 2022 19:48:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657075735; cv=none; d=google.com; s=arc-20160816; b=osibOesLcQRAh//rZkDNt075MHJSn2YQ0eqZNfLHrOOnvVeeHl0OJubKldcXmqpiMu w73Am2xs1IxbTrn2T5RVtYpSaC0nR8FtZ+7+ipsrh+N+EfJQxwgZRf4AU+7V7oAj752T pyh6xX4oHnxWVP1znyYy1bsskorSHmWFG8EVpav/ggg9TVkaiAklBwgh2p5yURZDZFad zOHv9wrZc+rXURya7Ez4s+BIrEepvtB8IYIQfcgMwPORzXqeY2mpe6sWLkx38hndydiz dYJ3zcP2fW9uYe7jPAPbtPaWHY49KCJKW12++Pr0P9UvA8P+qVVhWQxQLEauRVbI/r74 XtpQ== 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=emiR8o/UQR5w8WuS4yBByTW8/kBqRL/MkaDBR+7tZUM=; b=mlLnhwm6+NFhhcU7LGSGFUbXx6HSEp5GIJ14+CNt7W9Wh30WyDb3hBscd5fJbrymst 8JUnB0aJRuC5hs3yXoXFTeiBuWcp9Z4eXQIk3YjKLJIqarDAfkq62oDeDAndlVZ8iXdK GHyC2Y4jIJojuv1SgFrLODGOJXMRgpX1vd9dS7mhrZF+PH6M0wdDmKuU9HqmWJ24GL+3 RZCYV3Q30NG4AAZd8tSNMI9y9r0q9mnpC/GEnIyBi7O7BbdKIg2KePT7WpExq3M5uqJp Lb1ed6DLzMP2YGGl5c85h1TP/yymSEGZQNYxg4sGapfWJvNhUw4uy1aSHz/ZbGMnDuCo pFOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@igel-co-jp.20210112.gappssmtp.com header.s=20210112 header.b=ZDAbVaBd; 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 k71-20020a63844a000000b0041294aa04a7si1090144pgd.857.2022.07.05.19.48.44; Tue, 05 Jul 2022 19:48:55 -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=ZDAbVaBd; 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 S230453AbiGFChp (ORCPT + 99 others); Tue, 5 Jul 2022 22:37:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229592AbiGFChn (ORCPT ); Tue, 5 Jul 2022 22:37:43 -0400 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74F0019036 for ; Tue, 5 Jul 2022 19:37:42 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id t19so22976980lfl.5 for ; Tue, 05 Jul 2022 19:37:42 -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=emiR8o/UQR5w8WuS4yBByTW8/kBqRL/MkaDBR+7tZUM=; b=ZDAbVaBdb6JWaypB6MUdJBd3icqZkN9Syz5Eg8Y9Z7SDjm0dzENMBXJVnnE+p5l7/g dtx//SKvB5Vu+bKnB8TdkcpAHjcyq/xx0KoDyHMcIMB0us20Ws36vkvIWes8KwRfUq+A BiEKRFu3Cuu5hAALcJ3VZmDivAolfkmsBcmwe8ReK3KQXcZZZYQfE+n1G7uzm/zVY1f9 qoQgusprL1m3w+acx2rYh/X3bLAjJFGjhti7FRmMYjraIiR1VSIrx744jfslCz6+KZxM 8OebKQK7b1WI+1F/wceBWUoXB7INbLOHA/rLBUvxE8bU/m2X6FeIMlFKzeJkGXDfU3ON b0RA== 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=emiR8o/UQR5w8WuS4yBByTW8/kBqRL/MkaDBR+7tZUM=; b=sgdQTINWNr6vnwrYutwCZkP/Yct6lzscDDaympX19fbQXVAkOC2eAyz/olc5t9NFPr M4+QwjRDTK/thymxka1mlWOa/H8tHbr2Jk+1HFWdJgc1tXluviKNKJNTdcTU4YogxuoW 6Ny8zL0nXvVyR4EgzkeW+K/fE0KqurktxZn5MEI2eqllSLV8RZEFTLAw2klO3f6C5wve h1XW3XKQWKtZGg/aLFR/IPiZEFYlCIEjj3QoNY12jO4hjZ0IlU8gbQHrckv/xcQY6gFJ Yw/hRv6p2d/vAlsmKlXphOBzuJNQdy2UaNT22FrHcpqGAKjHWXyD+63qne/76GHoN5Km EDbQ== X-Gm-Message-State: AJIora8JZaLfl3F3FGtX54+5IKLuhrFgmwaQKB2Myeux+pZBPE+j01sF FP7jVENR8M8FulaLqm9gOJ/EeZAwjgfr8lsJM3vDmw== X-Received: by 2002:a05:6512:22cd:b0:47f:6e84:f51c with SMTP id g13-20020a05651222cd00b0047f6e84f51cmr23532318lfu.175.1657075060834; Tue, 05 Jul 2022 19:37:40 -0700 (PDT) MIME-Version: 1.0 References: <20220622040924.113279-1-mie@igel.co.jp> <20220705224028.GA90560@bhelgaas> In-Reply-To: <20220705224028.GA90560@bhelgaas> From: Shunsuke Mie Date: Wed, 6 Jul 2022 11:37:29 +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) 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 EP > > 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 stops > 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 behavio= r for endpoint framework. Kishon, could you please comment? > > Fixes: 349e7a85b25f ("PCI: endpoint: functions: Add an EP function to t= est 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/drivers/pc= i/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