Re: [PATCH v3 3/6] dt-bindings: PCI: qcom: Add IPQ5018 SoC
From: Krzysztof Kozlowski
Date: Wed Mar 05 2025 - 11:47:08 EST
On 05/03/2025 17:41, George Moussalem wrote:
>
>
> On 3/5/25 19:51, Krzysztof Kozlowski wrote:
>> On 05/03/2025 14:41, George Moussalem wrote:
>>> From: Sricharan Ramabadhran <quic_srichara@xxxxxxxxxxx>
>>>
>>> From: Nitheesh Sekar <quic_nsekar@xxxxxxxxxxx>
>> Nope, that's not a correct chain. Apply it yourself and check results.
> this series is dependent on the series to add support for IPQ5332:
> https://lore.kernel.org/all/20250220094251.230936-1-quic_varada@xxxxxxxxxxx/
> which was applied to dt-bindings
>>
>>> Add support for the PCIe controller on the Qualcomm
>>> IPQ5108 SoC to the bindings.
>>>
>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
>> Also not really correct. I did not provide tag to Nitheesh patch. How
>> the tag was added there? b4?
> the RB tag was passed on from here:
> https://lore.kernel.org/all/20240830081132.4016860-3-quic_srichara@xxxxxxxxxxx/
> but I'll drop it as it changed quite a bit since.
You linked v3, but this is v3!
I think I was stating it, but just to recap: please keep versioning the
patchsets, so if you ever do any change, it is next version. If you do
not make changes and keep the version but send again something, then
this should be RESEND PATCH.
>>
>>> Signed-off-by: Nitheesh Sekar <quic_nsekar@xxxxxxxxxxx>
>>> Signed-off-by: Sricharan Ramabadhran <quic_srichara@xxxxxxxxxxx>
>>> Signed-off-by: George Moussalem <george.moussalem@xxxxxxxxxxx>
>>> ---
>>> .../devicetree/bindings/pci/qcom,pcie.yaml | 49 +++++++++++++++++++
>>> 1 file changed, 49 insertions(+)
>>>
>> ...
>>
>>> + reset-names:
>>> + items:
>>> + - const: pipe # PIPE reset
>>> + - const: sleep # Sleep reset
>>> + - const: sticky # Core sticky reset
>>> + - const: axi_m # AXI master reset
>>> + - const: axi_s # AXI slave reset
>>> + - const: ahb # AHB reset
>>> + - const: axi_m_sticky # AXI master sticky reset
>>> + - const: axi_s_sticky # AXI slave sticky reset
>>> + interrupts:
>>> + minItems: 8
>>> + interrupt-names:
>>> + minItems: 8
>> Why is this flexible?
> I'll restrict it with maxItems in next version, thanks
This was not in v3, so is this resend of v3 or v4?
You are making this process unnecessary difficult and confusing.
Best regards,
Krzysztof