linux-kernel - Re: [PATCH v2 0/6] dt-bindings: Convert mux bindings to schema

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: <1cc2b5e5-0901-f615-0484-f56427ccb9db@axentia.se>
Date:   Fri, 28 May 2021 23:20:23 +0200
From:   Peter Rosin <peda@...ntia.se>
To:     Wolfram Sang <wsa@...nel.org>, Rob Herring <robh@...nel.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Jacopo Mondi <jacopo+renesas@...ndi.org>,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        Kishon Vijay Abraham I <kishon@...com>,
        Lee Jones <lee.jones@...aro.org>,
        Niklas Söderlund 
        <niklas.soderlund+renesas@...natech.se>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        linux-i2c@...r.kernel.org
Subject: Re: [PATCH v2 0/6] dt-bindings: Convert mux bindings to schema

On 2021-05-28 10:45, Wolfram Sang wrote:
> On Wed, May 26, 2021 at 01:48:33PM -0500, Rob Herring wrote:
>> This series converts the mux-controller and some i2c mux bindings to DT
>> schema. This was a rabbit hole of trying to fix undocumented (by schema)
>> compatibles (enabled by setting DT_CHECKER_FLAGS=-m). So this is mux
>> bindings, and then a few others that are used in the mux binding
>> examples.
> 
> So, I assume this should all go via your tree? That would be fine with
> me. Maybe Peter has some more comments, but for the procedure, here is
> my ack for the I2C parts of this series:

Hi Rob,

Thanks for converting these!

I can't call what I have done a review, because the details escape me, and
I don't have time to spend at the moment. However, from where I'm looking,
it all looks splendid. Ignorance is bliss! So, for patches 3-5 (where I'm
the maintainer) you have my

Acked-by: Peter Rosin <peda@...ntia.se>

Interesting times, being a maintainer of things I don't understand. I need
to fix that...

The main worry I have is the comment from Laurent about the intermediate
"i2c-mux" node, which also applies to i2c-gate which has been converted
to yaml before and to i2c-arb which is still in .txt format. I don't
remember exactly what the issue was that made me add the optional level,
but hopefully it is as you say, and that it is only MFD-type devices
that need them and that those can specify the intermediate level
themselves. My vision was to always have the intermediate level, since
I thought the bindings looked clearer that way. But that's just a personal
opinion, and it doesn't really matter...

However, I also worry that the information needed by future authors of
MFD bindings is lost and that they will have no readily available source
of the information that the intermediate nodes should be called i2c-mux,
i2c-arb or i2c-gate. The info was removed in the i2c-gate.txt -> .yaml
conversion. But that problem is not present in this series, since the
info is preserved in i2c-mux.txt -> .yaml conversion.

So, please go ahead with this series. Thanks again!

Cheers,
Peter