linux-kernel - Re: [PATCH 2/5] dt-bindings: i2c: renesas,riic: Document R9A09G057 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b04f9c39-9797-40b8-a25b-8154ad559cd5@linaro.org>
Date: Tue, 12 Mar 2024 12:04:13 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: "Lad, Prabhakar" <prabhakar.csengg@...il.com>,
 Chris Brandt <chris.brandt@...esas.com>, Andi Shyti <andi.shyti@...nel.org>,
 Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Magnus Damm <magnus.damm@...il.com>,
 Wolfram Sang <wsa+renesas@...g-engineering.com>,
 linux-renesas-soc@...r.kernel.org, linux-i2c@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
 Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH 2/5] dt-bindings: i2c: renesas,riic: Document R9A09G057
 support

On 11/03/2024 10:00, Geert Uytterhoeven wrote:
>>>>> -          - renesas,riic-r9a07g054  # RZ/V2L
>>>>> -      - const: renesas,riic-rz      # generic RIIC compatible
>>>>> +    oneOf:
>>>>> +      - items:
>>>>> +          - enum:
>>>>> +              - renesas,riic-r7s72100   # RZ/A1H
>>>>> +              - renesas,riic-r7s9210    # RZ/A2M
>>>>> +              - renesas,riic-r9a07g043  # RZ/G2UL and RZ/Five
>>>>> +              - renesas,riic-r9a07g044  # RZ/G2{L,LC}
>>>>> +              - renesas,riic-r9a07g054  # RZ/V2L
>>>>> +          - const: renesas,riic-rz      # generic RIIC compatible
>>>>> +
>>>>> +      - items:
>>>>> +          - enum:
>>>>> +              - renesas,riic-r9a09g057  # RZ/V2H(P)
>>>>
>>>> No, that does not look right. If you added generic compatible for all
>>>> RIIC then how can you add a new RIIC compatible which does not follow
>>>> generic one?
>>>>
>>> The generic compatible above which was added previously was for the
>>> RZ/(A) SoCs and not for all the RIICs. The RZ/G2L family was also
>>
>> No, it said: "generic RIIC compatible". It did not say "RIIC RZ/A". It
>> said RIIC RZ
> 
> At the time the original bindings were written, only RZ/A1, RZ/T1,
> and RZ/N1 existed, and all RIIC modules present in these SoCs were
> identical.  Later, we got RZ/A2, which also included a compatible
> RIIC block.
> 
> Somewhere along the timeline, the marketing department became creative,
> and we got RZ/G1 (RZ/G1[HMNEC]) and RZ/G2 (RZ/G2[HMNE]), which were
> unrelated to earlier RZ series :-(  When marketing started smoking
> something different, we got RZ/G2L, which is unrelated to RZ/G2,
> but reuses some parts from RZ/A.  Recently, we got RZ/G3S, which is
> similar to RZ/G2L...

That's fine, but then the comment "generic RIIC compatible" is confusing
for anyone not knowing this. Commit msg could also mention why the
generic compatible covers actually entirely different hardware. The
commit msg so far focused on the differences between these hardwares,
thus my questions - why do you create generic compatibles which are not
generic?

> 
>>> compatible hence they fallback to the generic RZ one.
>>
>> riic-r9a09g057 is also RIIC RZ, isn't it?
> 
> Yes, as in "it comes from the division that calls its products
> RZ/something". But...
> 
>>>> This shows the ridiculousness of these generic compatibles. They are
>>>> generic till you figure out the truth: oh crap, it's not generic.
>>>>
>>> Sorry I lack skills to predict the future of upcoming IP blocks which
>>> fit in the SoC.
>>
>> So don't use generic compatibles as fallbacks. That's the point.
> 
> It's indeed difficult to predict the future. So SoC-specific compatible
> values are safer.
> At the same time, we want to avoid having to add compatible values for
> each and every SoC to each driver, so we try to group SoCs per family.
> For R-Car that worked out reasonably well, however, for RZ...

I did not propose that. Nothing changes in your driver with my proposal.
Use SoC-compatibles only: for fallbacks and for specific(frontbacks?) parts.

To give you some sort of guidance for any future submission:
1. Use SoC-like fallback compatible, prepended with SoC-specific compatible.
2. If you insist on generic fallback compatible, its usage should be
limited to the cases where you can guarantee for 99.9% that future
devices will be compatible with this. I doubt anyone can guarantee that,
thus we keep repeating on mailing lists the same: go to point (1).

Best regards,
Krzysztof