netdev - Re: [PATCH net-next] dt-bindings: net: convert sff,sfp to dtschema

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: <CAL_JsqKFbU6VyLu+as_bZxWsfHRf5mJGeExjZ2ZJQqOcJchC+g@mail.gmail.com>
Date:   Wed, 30 Mar 2022 11:09:42 -0500
From:   Rob Herring <robh+dt@...nel.org>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Ioana Ciornei <ioana.ciornei@....com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>
Subject: Re: [PATCH net-next] dt-bindings: net: convert sff,sfp to dtschema

On Wed, Mar 30, 2022 at 10:52 AM Russell King (Oracle)
<linux@...linux.org.uk> wrote:
>
> On Wed, Mar 16, 2022 at 10:18:55AM +0000, Ioana Ciornei wrote:
> > On Wed, Mar 16, 2022 at 09:23:45AM +0100, Krzysztof Kozlowski wrote:
> > > On 15/03/2022 20:07, Ioana Ciornei wrote:
> > > > On Tue, Mar 15, 2022 at 07:21:59PM +0100, Krzysztof Kozlowski wrote:
> > > >> On 15/03/2022 13:33, Ioana Ciornei wrote:
> > > >>> Convert the sff,sfp.txt bindings to the DT schema format.
> > > >>>
> > > >>> Signed-off-by: Ioana Ciornei <ioana.ciornei@....com>
> > > >>> ---
> > > >
> > > > (..)
> > > >
> > > >>> +maintainers:
> > > >>> +  - Russell King <linux@...linux.org.uk>
> > > >>> +
> > > >>> +properties:
> > > >>> +  compatible:
> > > >>> +    enum:
> > > >>> +      - sff,sfp  # for SFP modules
> > > >>> +      - sff,sff  # for soldered down SFF modules
> > > >>> +
> > > >>> +  i2c-bus:
> > > >>
> > > >> Thanks for the conversion.
> > > >>
> > > >> You need here a type because this does not look like standard property.
> > > >
> > > > Ok.
> > > >
> > > >>
> > > >>> +    description:
> > > >>> +      phandle of an I2C bus controller for the SFP two wire serial
> > > >>> +
> > > >>> +  maximum-power-milliwatt:
> > > >>> +    maxItems: 1
> > > >>> +    description:
> > > >>> +      Maximum module power consumption Specifies the maximum power consumption
> > > >>> +      allowable by a module in the slot, in milli-Watts. Presently, modules can
> > > >>> +      be up to 1W, 1.5W or 2W.
> > > >>> +
> > > >>> +patternProperties:
> > > >>> +  "mod-def0-gpio(s)?":
> > > >>
> > > >> This should be just "mod-def0-gpios", no need for pattern. The same in
> > > >> all other places.
> > > >>
> > > >
> > > > The GPIO subsystem accepts both suffixes: "gpio" and "gpios", see
> > > > gpio_suffixes[]. If I just use "mod-def0-gpios" multiple DT files will
> > > > fail the check because they are using the "gpio" suffix.
> > > >
> > > > Why isn't this pattern acceptable?
> > >
> > > Because original bindings required gpios, so DTS are wrong, and the
> > > pattern makes it difficult to grep and read such simple property.
> > >
> > > The DTSes which do not follow bindings should be corrected.
> > >
> >
> > Russell, do you have any thoughts on this?
> > I am asking this because you were the one that added the "-gpios" suffix
> > in the dtbinding and the "-gpio" usage in the DT files so I wouldn't
> > want this to diverge from your thinking.
> >
> > Do you have a preference?
>
> SFP support predated (in my tree) the deprecation of the -gpio suffix,
> and despite the SFP binding doc being sent for review, it didn't get
> reviewed so the issue was never picked up.

Really?

https://lore.kernel.org/all/CAL_JsqL_7gG8FSEJDXu=37DFpHjfLhQuUhPFRKcScYTzM4cNyg@mail.gmail.com/


> My understanding is that GPIO will continue to accept either -gpio or
> -gpios for ever, so there shouldn't be any issue here - so converting
> all instances of -gpio to -gpios should be doable without issue.
>
> > If it's that unheard of to have a somewhat complete example why are
> > there multiple dtschema files submitted even by yourself with this same
> > setup?
> > As an example for a consumer device being listed in the provider yaml
> > file is 'gpio-pca95xx.yaml' and for the reverse (provider described in
> > the consumer) I can list 'samsung,s5pv210-clock.yaml',
> > 'samsung,exynos5260-clock.yaml' etc.
>
> My feels are it _is_ useful to show the consumer side in examples.

I think having it is fine here as long as the consumer has a schema.
This case is a bit different as there's really only 1 provider
instance and this is it.

It's the 100s of clock, gpio, interrupt, etc. schemas that we don't
need showing the consumer side over and over.

Rob