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
