[PATCH 2/3] dt-bindings: PCI: ti,j721e-pci-*: Add checks for max-link-speed

Siddharth Vadapalli s-vadapalli at ti.com
Wed Jan 17 03:22:32 PST 2024



On 17/01/24 16:49, Krzysztof Kozlowski wrote:
> On 17/01/2024 12:15, Siddharth Vadapalli wrote:
>>
>>
>> On 17/01/24 16:30, Krzysztof Kozlowski wrote:
>>> On 17/01/2024 11:58, Siddharth Vadapalli wrote:
>>>> On 17/01/24 16:05, Krzysztof Kozlowski wrote:
>>>>> On 17/01/2024 11:25, Siddharth Vadapalli wrote:
>>>>>> Extend the existing compatible based checks for validating and enforcing
>>>>>> the "max-link-speed" property.
>>>>>
>>>>> Based on what? Driver or hardware? Your entire change suggests you
>>>>
>>>> Hardware. The PCIe controller on AM64 SoC supports up to Gen2 link speed while
>>>> the PCIe controllers on other SoCs support Gen3 link speed.
>>>>
>>>>> should just drop it from the binding, because this can be deduced from
>>>>> compatible.
>>>>
>>>> Could you please clarify? Isn't the addition of the checks for "max-link-speed"
>>>> identical to the checks which were added for "num-lanes", both of which are
>>>> Hardware specific?
>>>
>>> Compatible defines these values, at least what it looks like from the patch.
>>
>> In this patch, I have added checks for the "max-link-speed" property in the same
>> section that "num-lanes" is being evaluated. 
> 
> I know what you did in patch. I read it.
> 
>> The values for "max-link-speed" are
>> based on the Hardware support and this patch is validating the "max-link-speed"
>> property in the device-tree nodes for the devices against the Hardware supported
>> values which this patch is adding in the corresponding section. Kindly let me
>> know if I misunderstood what you meant to convey.
> 
> Nothing of this is relevant.
> 
> I used two entirely different wordings for this and you still don't get
> it, so I don't know if I have third one.
> 
> Maybe this:
> Move it to driver match data.

Ok. I will drop the checks for "max-link-speed" and move them to the driver. But
I wonder why the checks for "num-lanes" are needed in the first place when they
could be in the driver as well.

> 
> So three entirely different wordings for the same. I don't have fourth...
> 
> Best regards,
> Krzysztof
> 

-- 
Regards,
Siddharth.



More information about the linux-arm-kernel mailing list