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: <CA+V-a8tM29h10DULurMJtBZBnLK_ZF7pH_Y0bhZTvWO0O7-G-Q@mail.gmail.com>
Date: Sat, 9 Mar 2024 23:28:50 +0000
From: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Geert Uytterhoeven <geert+renesas@...der.be>, 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

Hi Krzysztof,

Thank you for the review.

On Sat, Mar 9, 2024 at 12:00 PM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> On 08/03/2024 18:27, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> >
> > Document support for the I2C Bus Interface (RIIC) available in the
> > Renesas RZ/V2H (R9A09G057) SoC.
> >
> > The RIIC interface in the Renesas RZ/V2H differs from RZ/A in a
> > couple of ways:
> > - Register offsets for the RZ/V2H SoC differ from those of the RZ/A SoC.
> > - RZ/V2H register access is 8-bit, whereas RZ/A supports 8/16/32-bit.
> > - RZ/V2H has some bit differences in the slave address register.
> >
> > To accommodate these differences in the existing driver, a new compatible
> > string "renesas,riic-r9a09g057" is added.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > Reviewed-by: Fabrizio Castro <fabrizio.castro.jz@...esas.com>
>
> I have doubts this are true reviews. What did it even show? Why this
> review did not point problem with generic compatible?
>
As mentioned in path#1 these are "real"!

> > ---
> >  .../devicetree/bindings/i2c/renesas,riic.yaml | 21 ++++++++++++-------
> >  1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml
> > index 63ac5fe3208d..2a7125688647 100644
> > --- a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml
> > +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml
> > @@ -15,14 +15,19 @@ allOf:
> >
> >  properties:
> >    compatible:
> > -    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
> > +    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
compatible hence they fallback to the generic RZ one.

> 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.

> Stop adding generic compatibles when they are not generic.
>
BTW I am not adding a generic compatible string here and instead
adding a SoC specific string. Anyway DT maintainers "should not" have
been accepting the generic compatibles from day 1 for any binding at
all.

Is there a guideline where you can point me to please for when to add
generic and when not to.

Cheers,
Prabhakar

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ