Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp43159iob; Tue, 17 May 2022 18:09:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxd985hSb7JYR1ZEySK3iqKGpDBeuiCBc25RuFPlLWZcxziD7jTo33AV1cEDhqgVXfIMNm0 X-Received: by 2002:a05:6402:4256:b0:428:39:c6c7 with SMTP id g22-20020a056402425600b004280039c6c7mr21987047edb.374.1652836148780; Tue, 17 May 2022 18:09:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652836148; cv=none; d=google.com; s=arc-20160816; b=lgaVvOObckL2s+LlBC/L/hq0SJlATY22whG7K8ptsqt9uo+BHWIxDthLzDCTbmCJ14 4iqo5ae2vQdokWFiJoDWNz+DUtPJvA6YD12ZIsbgma69oQFCn1/98ImjGphj75S/NWrE LAFFRi/W+yFypP0bdN1Ynk95axGtOfeIeqUVRUuX/DevvVU1p4pbgilpNkBesXchbsqw k+3ztuEoApxzsg9pyTGIq/mMC89X0iQqptyq/eew/JszZ9G01E0P4xJHhTDCMLFjdW8I 7NVwH35pDskG2pqUFyoOb6b3Z7NuUDpIyBPF4KqAxFmA6drHpb0NupP0WR0SNvkwnm+/ p14g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=8Pxt3UlA5ORUqwbrRQ6VvUIBqTvuwePuHgUl7TQL8J0=; b=a8wIk84Z5fFGsdvTpWs463qGijlpt3KDiZFAHMdv7f/uU1t4vcP0TAGTzDkY51BaFV cjUtIQaMAf+eSvI5viG+eUYD8pQR44brRyNgj5JSmD+MnOKOl54ThdVkzyVNQ0zzO50X t63pHu25bzpD9Heqdf4ESOH9dvRtQatl7Fs7Shs5CWLM9ssJbTmTYLwN5pE/hbfyYcOr ogqZKehs9zUAqQDy1jploiGuZ4LAPkLKPHGm2bYAM6GP4qrOVSIiv3tMwuYyfOhnrWKy RoVDOSNT4Dbgsi5/A+DxlQJDyYGu4OryPTQZHxzBl6ehhYIcASvf2HZGE4XcfI6/dS20 mykg== ARC-Authentication-Results: i=1; mx.google.com; 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 24-20020a170906311800b006ec0aaff9cfsi678399ejx.932.2022.05.17.18.08.18; Tue, 17 May 2022 18:09:08 -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; 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 S241427AbiEQHdP (ORCPT + 99 others); Tue, 17 May 2022 03:33:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34690 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241223AbiEQHdA (ORCPT ); Tue, 17 May 2022 03:33:00 -0400 Received: from hostingweb31-40.netsons.net (hostingweb31-40.netsons.net [89.40.174.40]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F10EC48386; Tue, 17 May 2022 00:32:58 -0700 (PDT) Received: from [77.244.183.192] (port=64646 helo=[192.168.178.75]) by hostingweb31.netsons.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nqrhP-000129-WE; Tue, 17 May 2022 09:32:56 +0200 Message-ID: Date: Tue, 17 May 2022 09:32:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH 1/2] PCI: dra7xx: Fix link removal on probe error Content-Language: it-IT To: Saravana Kannan Cc: Lorenzo Pieralisi , Rob Herring , PCI , Dan Carpenter , linux-omap , linux-arm-kernel , "linux-kernel@vger.kernel.org" , Kishon Vijay Abraham I , =?UTF-8?Q?Krzysztof_Wilczy=c5=84ski?= , Bjorn Helgaas , Sekhar Nori References: <20211214221450.589884-1-luca@lucaceresoli.net> <59a23c89-0810-eb28-acd9-7051ac34d438@lucaceresoli.net> <4579940c-27dc-733e-4022-ebea4671c839@lucaceresoli.net> <615718f9-151e-20fb-fcb0-56063ae61ca6@lucaceresoli.net> From: Luca Ceresoli In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hostingweb31.netsons.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lucaceresoli.net X-Get-Message-Sender-Via: hostingweb31.netsons.net: authenticated_id: luca@lucaceresoli.net X-Authenticated-Sender: hostingweb31.netsons.net: luca@lucaceresoli.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,NICE_REPLY_A, 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 Hi Saravana, On 14/05/22 05:46, Saravana Kannan wrote: > On Thu, May 12, 2022 at 7:07 AM Luca Ceresoli wrote: >> >> Hi Lorenzo, >> >> On 11/05/22 18:41, Lorenzo Pieralisi wrote: >>> On Sat, Jan 15, 2022 at 10:02:00AM -0600, Rob Herring wrote: >>>> +Saravana >>>> >>>> On Tue, Jan 11, 2022 at 4:35 AM Luca Ceresoli wrote: >>>>> >>>>> Hi Rob, >>>>> >>>>> On 16/12/21 10:08, Luca Ceresoli wrote: >>>>>> Hi Rob, >>>>>> >>>>>> thanks for the quick feedback! >>>>>> >>>>>> On 14/12/21 23:42, Rob Herring wrote: >>>>>>> On Tue, Dec 14, 2021 at 4:15 PM Luca Ceresoli wrote: >>>>>>>> >>>>>>>> If a devm_phy_get() calls fails with phy_count==N (N > 0), then N links >>>>>>>> have already been added by device_link_add() and won't be deleted by >>>>>>>> device_link_del() because the code calls 'return' and not 'goto err_link'. >>>>>>>> >>>>>>>> Fix in a very simple way by doing all the devm_phy_get() calls before all >>>>>>>> the device_link_add() calls. >>>>>>>> >>>>>>>> Fixes: 7a4db656a635 ("PCI: dra7xx: Create functional dependency between PCIe and PHY") >>>>>>>> Signed-off-by: Luca Ceresoli >>>>>>>> --- >>>>>>>> drivers/pci/controller/dwc/pci-dra7xx.c | 2 ++ >>>>>>>> 1 file changed, 2 insertions(+) >>>>>>>> >>>>>>>> diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c b/drivers/pci/controller/dwc/pci-dra7xx.c >>>>>>>> index f7f1490e7beb..2ccc53869e13 100644 >>>>>>>> --- a/drivers/pci/controller/dwc/pci-dra7xx.c >>>>>>>> +++ b/drivers/pci/controller/dwc/pci-dra7xx.c >>>>>>>> @@ -757,7 +757,9 @@ static int dra7xx_pcie_probe(struct platform_device *pdev) >>>>>>>> phy[i] = devm_phy_get(dev, name); >>>>>>>> if (IS_ERR(phy[i])) >>>>>>>> return PTR_ERR(phy[i]); >>>>>>>> + } >>>>>>>> >>>>>>>> + for (i = 0; i < phy_count; i++) { >>>>>>>> link[i] = device_link_add(dev, &phy[i]->dev, DL_FLAG_STATELESS); >>>>>>> >>>>>>> I think this should happen automatically now with fw_devlink being >>>>>>> enabled by default. Can you try? >>>>>> >>>>>> Do you mean removal should be done automatically? I think they are not >>>>>> due to the DL_FLAG_STATELESS flag. >>>>> >>>>> I would love to have feedback because, as said, I think my patch is >>>>> correct, but if I'm wrong (which might well be) I have to drop patch 1 >>>>> and rewrite patch 2 in a slightly more complex form. >>>> >>>> I mean that why do you need explicit dependency tracking here when >>>> dependencies on a PHY should happen automatically now. IOW, what is >>>> special about this driver and dependency? >>> >>> Any update on this patch ? I think patch 2 can be merged, please >>> let me know if this one can be dropped. >> >> Thanks for the feedback! You would say yes, you can merge patch 2, >> except it probably does not even apply as it is written in a way that is >> based on the changes in patch 1. >> >> I could rewrite patch 2 to not depend on patch 1 of course, but it >> wouldn't make code simpler, perhaps more complex. And moreover the >> hardware that I used to have access to has phy_count==1 so I could never >> test the failing case, and sadly now I have no access to that hardware. > > Hi Luca, > > The fw_devlink code to create device links from consumers to "phys" > suppliers is pretty well exercised. Most/all Android devices running > 5.10+ kernels (including Pixel 6) use fw_devlink=on to be able to boot > properly. > > So I'd be pretty confident in deleting the device_link_add/del() code > in drivers/pci/controller/dwc/pci-dra7xx.c. The device links should > already be there before the probe is even called. > > Also, if you want to check if the device links (even the 1 phy one you > have) are being created, you can look at /sys/class/devlink to see the > list of all device links that are currently present. You can delete > the code and then use this to check too. Thank you for your feedback. Unfortunately as I said I have no access to the hardware, and won't have anymore. I don't think it is a good idea to send a patch that I cannot test on real hardware, especially since it is for a generic hardware that thus might affect others. But I would be glad to review any such patch that might be sent, FWIW. -- Luca