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: <YkR8tTWabfTRLarB@shell.armlinux.org.uk>
Date:   Wed, 30 Mar 2022 16:52:21 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Ioana Ciornei <ioana.ciornei@....com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH net-next] dt-bindings: net: convert sff,sfp to dtschema

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.

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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!