Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp97374pxb; Tue, 15 Feb 2022 06:19:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJywH3nOmluWyNPzOHK8I9XHUPsLS58dHMv1rSfSXnMFWKiOwzs8pnWCG4xwyarIkL34Kzp8 X-Received: by 2002:a05:6402:7ce:: with SMTP id u14mr4225056edy.176.1644934763072; Tue, 15 Feb 2022 06:19:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644934763; cv=none; d=google.com; s=arc-20160816; b=oZQkcre1RYjDj705d9pLW3aeRtCeJJui26Xo2/sqmSboof7i25btWh0UdxOT/os+f7 vVgdIbyhFQX+T8ht9OqYmPAqzKzgM7jRav632P+ylY8BcuiVdgfH2WqvEx1KY1B2iBaA 3+4Me0tUVLR+9PJAfpNU/77Q6OSYkOdTc232UYCo70a3OngHTrb0lhDeKGoNfstjPrgm oK573xXVp/tXLBOeR9e6guDl63HpA7PoEDkAXkTK4InMGoOHyjzvvEZvadhAyIsmcLem bS58ik2kpijGBS4jDt9d/MJB70aArmjuTOf+weQ9HGUL+510taGBm84y5ucbEZa5c9J5 11Aw== 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 :organization:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id; bh=u3kOKaf9x5aBx0ZHSt5piw+VDsO8F2kMGmHDptGgAs8=; b=eT27zWbSHjYgbKPFS4t4tjLiZ6uNhz3MqKUbqBTVwhHvDkjqbWlAWTmJz9NRZyjWjH r5QIICDGgndAw4w61PyAeRkZurq9EO/KhbBgnurZ0bpaoZOzDDHjZf9V4UDiYp9/G/5i zxcxqFEenLOitSH0nskatwCZf9tMr1gov35RhmgNuqPeCWT/5ljobopQIXXbuy+W+kdQ idOWDUeAwvJHga95nrrAIxFeBk32V8PbhOPv2jig/NCBl3etwhmyk8Kpden+pRyr0TRE 5c4oLwc/nFeZAKKUNQm/CP1g4NbsJEUMaEcuf7ZnKeXog7oQoGKKPpubhGXQQFTFWCmA H3gA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id nc34si658033ejc.4.2022.02.15.06.18.58; Tue, 15 Feb 2022 06:19:23 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237323AbiBOLpJ (ORCPT + 99 others); Tue, 15 Feb 2022 06:45:09 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:40446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237225AbiBOLpI (ORCPT ); Tue, 15 Feb 2022 06:45:08 -0500 X-Greylist: delayed 1431 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Tue, 15 Feb 2022 03:44:57 PST Received: from imap3.hz.codethink.co.uk (imap3.hz.codethink.co.uk [176.9.8.87]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A2FCC60044; Tue, 15 Feb 2022 03:44:57 -0800 (PST) Received: from cpc152649-stkp13-2-0-cust121.10-2.cable.virginm.net ([86.15.83.122] helo=[192.168.0.21]) by imap3.hz.codethink.co.uk with esmtpsa (Exim 4.92 #3 (Debian)) id 1nJvtI-0005EU-8w; Tue, 15 Feb 2022 11:21:04 +0000 Message-ID: Date: Tue, 15 Feb 2022 11:21:03 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH 1/2] PCI: fu740: fix finding GPIOs Content-Language: en-GB To: Bjorn Helgaas Cc: linux-kernel@vger.kernel.org, bhelgaas@google.comv, linux-pci@vger.kernel.org, paul.walmsley@sifive.com, greentime.hu@sifive.com, david.abdurachmanov@gmail.com, Rob Herring , Lorenzo Pieralisi References: <20220214160556.GA9253@bhelgaas> From: Ben Dooks Organization: Codethink Limited. In-Reply-To: <20220214160556.GA9253@bhelgaas> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_PASS,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 On 14/02/2022 16:05, Bjorn Helgaas wrote: > [+cc Rob for possible DT/kernel match issue, > Lorenzo (native host bridge driver maintainer)] > > s/fix finding/Fix finding/ (in subject) > Or even better, say something specific about the DT properties in > question, e.g., look for "reset" instead of "reset-gpios". > > On Mon, Feb 14, 2022 at 08:21:43AM +0000, Ben Dooks wrote: >> The calls to devm_gpiod_get_optional() have the -gpios at the end of >> the name. This means the pcie driver is not finding the necessary >> reset or power GPOOs to allow the PCIe devices on the SiFive Unmatched >> boards. > > s/pcie/PCIe/ > s/GPOOs/GPIOs/ Will fix > "to allow the PCIe devices ...?" Something is missing from this > sentence. "To allow the devices "? Or maybe the driver > needs these GPIOs to power up the PCIe devices? > > I guess the implication is that the code looks for "reset-gpios" and > "pwren-gpios", but the DT contains "reset" and "pwren"? > > But both Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml > and arch/riscv/boot/dts/sifive/fu740-c000.dtsi actually do contain > "reset-gpios" and "pwren-gpios". Yes, the issue is the gpio core code adds either "-gpio" or "-gpios" itself, thus the find code does not need this. The error messages and DT are correct. I'll reword the initial paragraph to note that which should also deal with the other comments: The calls to devm_gpiod_get_optional() have the -gpios at the end of the name but the GPIO core code is already adding the suffix during the lookup. This means the PCIe driver is not finding the necessary reset or power lines to allow initialisation of the PCIe. > If we *do* want to change the code, please change the error messages > to match. See above, it is just devm_gpiod_get_optional() parameters at fault. >> This has not been a noted bug as the PCIe probe from u-boot has been >> required to get the PCIe working due to other issues with the system >> setup. It could have been broken since the driver inclusion, and not >> been noticed as it is not necessary for the driver to funciton. > > s/u-boot/U-Boot/ > s/funciton/function/ > > Please add a line about what the connection between U-Boot and this > issue is, e.g., maybe U-Boot powers up the devices, so we wouldn't > notice the kernel's inability to do so? Does a reword to the following make better sense: This bug has not been noticed as if U-Boot has setup the GPIO lines for the hardware when it does the PCIe initialisation (either by booting from PCIe or user command to access PCIe) then the PCIe will work in Linux. The U-Boot as supplied by SiFive does not by default initialise any PCIe component. >> Signed-off-by: Ben Dooks >> --- >> drivers/pci/controller/dwc/pcie-fu740.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/pci/controller/dwc/pcie-fu740.c b/drivers/pci/controller/dwc/pcie-fu740.c >> index 00cde9a248b5..842b7202b96e 100644 >> --- a/drivers/pci/controller/dwc/pcie-fu740.c >> +++ b/drivers/pci/controller/dwc/pcie-fu740.c >> @@ -259,11 +259,11 @@ static int fu740_pcie_probe(struct platform_device *pdev) >> return PTR_ERR(afp->mgmt_base); >> >> /* Fetch GPIOs */ >> - afp->reset = devm_gpiod_get_optional(dev, "reset-gpios", GPIOD_OUT_LOW); >> + afp->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW); >> if (IS_ERR(afp->reset)) >> return dev_err_probe(dev, PTR_ERR(afp->reset), "unable to get reset-gpios\n"); >> >> - afp->pwren = devm_gpiod_get_optional(dev, "pwren-gpios", GPIOD_OUT_LOW); >> + afp->pwren = devm_gpiod_get_optional(dev, "pwren", GPIOD_OUT_LOW); >> if (IS_ERR(afp->pwren)) >> return dev_err_probe(dev, PTR_ERR(afp->pwren), "unable to get pwren-gpios\n"); >> >> -- >> 2.34.1 >> > -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html