Re: [PATCH 1/5] dt-bindings: can: tcan4x5x: Add tcan4552 and tcan4553 variants
From: Krzysztof Kozlowski
Date: Wed Mar 15 2023 - 12:08:40 EST
On 15/03/2023 16:58, Markus Schneider-Pargmann wrote:
> On Wed, Mar 15, 2023 at 02:14:27PM +0100, Krzysztof Kozlowski wrote:
>> On 15/03/2023 12:25, Marc Kleine-Budde wrote:
>>> On 14.03.2023 21:01:10, Krzysztof Kozlowski wrote:
>>>> On 14/03/2023 16:11, Markus Schneider-Pargmann wrote:
>>>>> These two new chips do not have state or wake pins.
>>>>>
>>>>> Signed-off-by: Markus Schneider-Pargmann <msp@xxxxxxxxxxxx>
>>>>> ---
>>>>> .../devicetree/bindings/net/can/tcan4x5x.txt | 11 ++++++++---
>>>>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt
>>>>> index e3501bfa22e9..38a2b5369b44 100644
>>>>> --- a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt
>>>>> +++ b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt
>>>>> @@ -4,7 +4,10 @@ Texas Instruments TCAN4x5x CAN Controller
>>>>> This file provides device node information for the TCAN4x5x interface contains.
>>>>>
>>>>> Required properties:
>>>>> - - compatible: "ti,tcan4x5x"
>>>>> + - compatible:
>>>>> + "ti,tcan4x5x" or
>>>>> + "ti,tcan4552" or
>>>>> + "ti,tcan4553"
>>>>
>>>> Awesome, they nicely fit into wildcard... Would be useful to deprecate
>>>> the wildcard at some point and switch to proper compatibles in such
>>>> case, because now they became confusing.
>>>
>>> I plead for DT stability!
>>>
>>> As I understand correctly, the exact version of the chip (4550, 4552, or
>>> 4553) can be detected via the ID2 register.
>>
>> So maybe there is no need for this patch at all? Or the new compatibles
>> should be made compatible with generic fallback?
>
> I can use the value being read from the ID2 register to get the version.
> This at least holds the correct value for tcan4550, 4552 and 4553. But
> the state and wake gpios can't be used in case of a 4552 or 4553.
>
> So yes, it is possible to do it without the new compatibles but the
> changes for state and wake gpios need to stay.
>
> What do you two prefer?
Then specific with generic fallback compatibles, although for driver it
still won't matter as you need to customize driver_data anyway.
Best regards,
Krzysztof