All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: "Krishna Chaitanya Chundru" <krishna.chundru@oss.qualcomm.com>,
	"Vinod Koul" <vkoul@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Bjorn Andersson" <andersson@kernel.org>,
	"Konrad Dybcio" <konradybcio@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, quic_vbadigan@quicinc.com,
	quic_mrana@quicinc.com
Subject: Re: [PATCH v2 3/3] PCI: qcom: Restrict port parsing only to pci child nodes
Date: Tue, 26 Aug 2025 11:29:37 +0200	[thread overview]
Message-ID: <dfd9cc8b-8103-4fa9-8b3b-c31ae7c4970a@kernel.org> (raw)
In-Reply-To: <p6yacm6hkhp4rgtl2xn677kek24ksczvtuersxnou4kmxmp7go@tmoy7gn4hrhx>

On 26/08/2025 11:26, Manivannan Sadhasivam wrote:
> On Tue, Aug 26, 2025 at 10:28:51AM GMT, Krzysztof Kozlowski wrote:
>> On 26/08/2025 08:17, Manivannan Sadhasivam wrote:
>>> On Tue, Aug 26, 2025 at 10:48:19AM GMT, Krishna Chaitanya Chundru wrote:
>>>> The qcom_pcie_parse_ports() function currently iterates over all available
>>>> child nodes of the PCIe controller's device tree node. This can lead to
>>>> attempts to parse unrelated nodes like OPP nodes, resulting in unnecessary
>>>> errors or misconfiguration.
>>>>
>>>
>>> What errors? Errors you are seeing on your setup or you envision?
>>>
>>>> Restrict the parsing logic to only consider child nodes named "pcie" or
>>>> "pci", which are the expected node names for PCIe ports.
>>>>
>>>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>>>
>>> Since this is a fix, 'Fixes' tag is needed.
>>>
>>>> ---
>>>>  drivers/pci/controller/dwc/pcie-qcom.c | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>>>> index 294babe1816e4d0c2b2343fe22d89af72afcd6cd..5dbdb69fbdd1b9b78a3ebba3cd50d78168f2d595 100644
>>>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>>>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>>>> @@ -1740,6 +1740,8 @@ static int qcom_pcie_parse_ports(struct qcom_pcie *pcie)
>>>>  	int ret = -ENOENT;
>>>>  
>>>>  	for_each_available_child_of_node_scoped(dev->of_node, of_port) {
>>>> +		if (!(of_node_name_eq(of_port, "pcie") || of_node_name_eq(of_port, "pci")))
>>>
>>> May I know which platform has 'pci' as the node name for the bridge node? AFAIK,
>>> all platforms defining bridge nodes have 'pcie' as the node name.
>>
>> It does not matter. If I name my node name as "pc" it stops working?
>>
>> No, Qualcomm cannot introduce such hidden ABI.
> 
> There is no hidden ABI that Qcom is introducing. We are just trying to reuse the
> standard node names documented in the devicetree spec. So you are saying that
> we should not rely on it even though it is documented? Maybe because, the dt
> tooling is not yet screaming if people put non-standard names in DT?
> 

If it is documented, you can use it, but I doubted first the author even
checked that. Otherwise commit message would say that.

As I mentioned in other response, I still find it discouraged pattern if
you have (and you do have!) compatibles.


Best regards,
Krzysztof

WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: "Krishna Chaitanya Chundru" <krishna.chundru@oss.qualcomm.com>,
	"Vinod Koul" <vkoul@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Bjorn Andersson" <andersson@kernel.org>,
	"Konrad Dybcio" <konradybcio@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, quic_vbadigan@quicinc.com,
	quic_mrana@quicinc.com
Subject: Re: [PATCH v2 3/3] PCI: qcom: Restrict port parsing only to pci child nodes
Date: Tue, 26 Aug 2025 11:29:37 +0200	[thread overview]
Message-ID: <dfd9cc8b-8103-4fa9-8b3b-c31ae7c4970a@kernel.org> (raw)
In-Reply-To: <p6yacm6hkhp4rgtl2xn677kek24ksczvtuersxnou4kmxmp7go@tmoy7gn4hrhx>

On 26/08/2025 11:26, Manivannan Sadhasivam wrote:
> On Tue, Aug 26, 2025 at 10:28:51AM GMT, Krzysztof Kozlowski wrote:
>> On 26/08/2025 08:17, Manivannan Sadhasivam wrote:
>>> On Tue, Aug 26, 2025 at 10:48:19AM GMT, Krishna Chaitanya Chundru wrote:
>>>> The qcom_pcie_parse_ports() function currently iterates over all available
>>>> child nodes of the PCIe controller's device tree node. This can lead to
>>>> attempts to parse unrelated nodes like OPP nodes, resulting in unnecessary
>>>> errors or misconfiguration.
>>>>
>>>
>>> What errors? Errors you are seeing on your setup or you envision?
>>>
>>>> Restrict the parsing logic to only consider child nodes named "pcie" or
>>>> "pci", which are the expected node names for PCIe ports.
>>>>
>>>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>>>
>>> Since this is a fix, 'Fixes' tag is needed.
>>>
>>>> ---
>>>>  drivers/pci/controller/dwc/pcie-qcom.c | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>>>> index 294babe1816e4d0c2b2343fe22d89af72afcd6cd..5dbdb69fbdd1b9b78a3ebba3cd50d78168f2d595 100644
>>>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>>>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>>>> @@ -1740,6 +1740,8 @@ static int qcom_pcie_parse_ports(struct qcom_pcie *pcie)
>>>>  	int ret = -ENOENT;
>>>>  
>>>>  	for_each_available_child_of_node_scoped(dev->of_node, of_port) {
>>>> +		if (!(of_node_name_eq(of_port, "pcie") || of_node_name_eq(of_port, "pci")))
>>>
>>> May I know which platform has 'pci' as the node name for the bridge node? AFAIK,
>>> all platforms defining bridge nodes have 'pcie' as the node name.
>>
>> It does not matter. If I name my node name as "pc" it stops working?
>>
>> No, Qualcomm cannot introduce such hidden ABI.
> 
> There is no hidden ABI that Qcom is introducing. We are just trying to reuse the
> standard node names documented in the devicetree spec. So you are saying that
> we should not rely on it even though it is documented? Maybe because, the dt
> tooling is not yet screaming if people put non-standard names in DT?
> 

If it is documented, you can use it, but I doubted first the author even
checked that. Otherwise commit message would say that.

As I mentioned in other response, I still find it discouraged pattern if
you have (and you do have!) compatibles.


Best regards,
Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2025-08-26  9:29 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-26  5:18 [PATCH v2 0/3] arm64: dts: qcom: Add PCIe Support for sm8750 Krishna Chaitanya Chundru
2025-08-26  5:18 ` Krishna Chaitanya Chundru
2025-08-26  5:18 ` [PATCH v2 1/3] dt-bindings: PCI: qcom,pcie-sm8550: Add SM8750 compatible Krishna Chaitanya Chundru
2025-08-26  5:18   ` Krishna Chaitanya Chundru
2025-08-26  5:18 ` [PATCH v2 2/3] arm64: dts: qcom: sm8750: Add PCIe PHY and controller node Krishna Chaitanya Chundru
2025-08-26  5:18   ` Krishna Chaitanya Chundru
2025-08-26  5:18 ` [PATCH v2 3/3] PCI: qcom: Restrict port parsing only to pci child nodes Krishna Chaitanya Chundru
2025-08-26  5:18   ` Krishna Chaitanya Chundru
2025-08-26  6:17   ` Manivannan Sadhasivam
2025-08-26  6:17     ` Manivannan Sadhasivam
2025-08-26  6:24     ` Krishna Chaitanya Chundru
2025-08-26  6:24       ` Krishna Chaitanya Chundru
2025-08-26  8:28     ` Krzysztof Kozlowski
2025-08-26  8:28       ` Krzysztof Kozlowski
2025-08-26  9:26       ` Manivannan Sadhasivam
2025-08-26  9:26         ` Manivannan Sadhasivam
2025-08-26  9:29         ` Krzysztof Kozlowski [this message]
2025-08-26  9:29           ` Krzysztof Kozlowski
2025-08-26 10:20           ` Manivannan Sadhasivam
2025-08-26 10:20             ` Manivannan Sadhasivam
2025-08-26  8:27   ` Krzysztof Kozlowski
2025-08-26  8:27     ` Krzysztof Kozlowski
2025-08-26  8:32     ` Krzysztof Kozlowski
2025-08-26  8:32       ` Krzysztof Kozlowski
2025-08-26  9:03       ` Krishna Chaitanya Chundru
2025-08-26  9:03         ` Krishna Chaitanya Chundru
2025-08-26  9:28         ` Manivannan Sadhasivam
2025-08-26  9:28           ` Manivannan Sadhasivam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dfd9cc8b-8103-4fa9-8b3b-c31ae7c4970a@kernel.org \
    --to=krzk@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kishon@kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krishna.chundru@oss.qualcomm.com \
    --cc=krzk+dt@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=quic_mrana@quicinc.com \
    --cc=quic_vbadigan@quicinc.com \
    --cc=robh@kernel.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.