[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <91e03d54-5de2-4f41-90df-3d46225edf64@oss.qualcomm.com>
Date: Mon, 13 Oct 2025 20:10:35 +0530
From: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>
To: Manivannan Sadhasivam <mani@...nel.org>,
Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
linus.walleij@...aro.org, brgl@...ev.pl
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof WilczyĆski <kwilczynski@...nel.org>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Abraham I <kishon@...nel.org>,
Bjorn Andersson <andersson@...nel.org>, linux-pci@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org,
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Subject: Re: [PATCH 3/3] PCI: qcom: Treat PHY and PERST# as optional for the
new binding
On 10/11/2025 9:39 AM, Manivannan Sadhasivam wrote:
> + GPIO folks for the below API query
>
> On Fri, Oct 10, 2025 at 08:32:51PM +0200, Konrad Dybcio wrote:
>> On 10/10/25 8:25 PM, Manivannan Sadhasivam wrote:
>>> Even for the new DT binding where the PHY and PERST# properties are
>>> specified in the Root Port, both are optional. Hence, treat them as
>>> optional in the driver too.
>>
>> I suppose this makes sense if the PHY is transparent to the OS
>> or otherwise pre-programmed and PERST# is hardwired or otherwise
>> unnecessary.. both of which I suppose aren't totally impossible..
>>
>
> PERST# is by definition an optional signal, but I'm not sure about why PHY is
> not used by the controller driver.
>
one case where phy is optional is in pcie tunneling through usb4, there
we don't require any phy.
- Krishna Chaitanya.
>>>
>>> If both properties are not specified, then fall back to parsing the legacy
>>> binding for backwards compatibility.
>>>
>>> Fixes: a2fbecdbbb9d ("PCI: qcom: Add support for parsing the new Root Port binding")
>>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>
>>> ---
>>> drivers/pci/controller/dwc/pcie-qcom.c | 11 +++++++++--
>>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>>> index 805edbbfe7eba496bc99ca82051dee43d240f359..d380981cf3ad78f549de3dc06bd2f626f8f53920 100644
>>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>>> @@ -1720,13 +1720,20 @@ static int qcom_pcie_parse_port(struct qcom_pcie *pcie, struct device_node *node
>>>
>>> reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
>>> "reset", GPIOD_OUT_HIGH, "PERST#");
>>> - if (IS_ERR(reset))
>>> + if (IS_ERR(reset) && PTR_ERR(reset) != -ENOENT)
>>> return PTR_ERR(reset);
>>
>> Please introduce an _optional variant instead
>>
>
> Linus, Bartosz, are you OK with devm_fwnode_gpiod_get_optional() API? Just
> wanted to confirm before I go ahead as there are existing users checking for
> -ENOENT explicitly. Not sure if they are doing it for a reason other than the
> absence of the _optional variant or not.
>
> - Mani
>
Powered by blists - more mailing lists