[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<CH2PPF4D26F8E1C29A09F1B6C6608DA3145A243A@CH2PPF4D26F8E1C.namprd07.prod.outlook.com>
Date: Thu, 3 Jul 2025 01:35:05 +0000
From: Manikandan Karunakaran Pillai <mpillai@...ence.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, Hans Zhang <hans.zhang@...tech.com>
CC: "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"lpieralisi@...nel.org"
<lpieralisi@...nel.org>,
"kw@...ux.com" <kw@...ux.com>, "mani@...nel.org"
<mani@...nel.org>,
"robh@...nel.org" <robh@...nel.org>,
"kwilczynski@...nel.org" <kwilczynski@...nel.org>,
"krzk+dt@...nel.org"
<krzk+dt@...nel.org>,
"conor+dt@...nel.org" <conor+dt@...nel.org>,
"fugang.duan@...tech.com" <fugang.duan@...tech.com>,
"guoyin.chen@...tech.com" <guoyin.chen@...tech.com>,
"peter.chen@...tech.com"
<peter.chen@...tech.com>,
"cix-kernel-upstream@...tech.com"
<cix-kernel-upstream@...tech.com>,
"linux-pci@...r.kernel.org"
<linux-pci@...r.kernel.org>,
"devicetree@...r.kernel.org"
<devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v5 01/14] dt-bindings: pci: cadence: Extend compatible for
new RP configuration
:
>>>>>>
>>>>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-
>>>>> devicetree/20250424-elm-magma-
>>>>> b791798477ab@...d/__;!!EHscmS1ygiU1lA!Bo-
>>>>>
>>>
>ayMVqCWXSbSgFpsBZzgk1ADft8pqRQbuOeAhIuAjz0zI015s4dmzxgaWKycqKMn
>>>>> 1cejS8kKZvjF5xDAse$
>>>>>>
>>>>>> You cannot just send someone's work and bypassing the review
>feedback.
>>>>
>>>> I thought the comment was implicitly addressed when the device drivers
>>> were separated out based on other review comments in this patch.
>>>> To make it more clear, in the next patch I will add the following description
>>> for the dt-binding patch
>>>>
>>>> "The High performance architecture is different from legacy architecture
>>> controller in design of register banks,
>>>> register definitions, hardware sequences of initialization and is considered
>as
>>> a different device due to the
>>>> large number of changes required in the device driver and hence adding a
>>> new compatible."
>>> That's still vague. Anyway this does not address other concern that the
>>> generic compatible is discouraged and we expect specific compatibles. We
>>> already said that and what? You send the same patch.
>>>
>>> So no, don't send the same patch.
>>
>>
>> Hi Kryzsztof,
>>
>> Are you suggesting to create new file for both RC and EP for HPA host like:
>> cdns,cdns-pcie-hpa-host.yaml
>> cdns,cdns-pcie-hpa-ep.yaml
>> And during the commit log, explain why you need to create a new file for
>HPA, and not use the legacy one.
>
>No, there was no such suggestions in any previous or current
>discussions. IIRC, this was simply rejected previously. I consider this
>rejected still, with the same arguments: you should use specific SoC
>compatibles. The generic compatible alone is rather legacy approach and
>we have been commenting on this sooooo many times.
>
Hi Kryzsztof,
Thanks for your response.
The SoC specific dts patches are already being submitted by CIX team for their SoC based on the same PCIe controller IP.
Since there is no SoC for this platform(it only an FPGA based board),
are you suggesting to drop the dt-bindings patch altogether as the SoC specific dts bindings are already being in the same patch set.
There will be a compatible in the platform code that would not have a binding.
Pls let me know if this is the approach
>Best regards,
>Krzysztof
Powered by blists - more mailing lists