devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Ioana Ciornei <ioana.ciornei@nxp.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH net-next] dt-bindings: net: convert sff,sfp to dtschema
Date: Wed, 30 Mar 2022 16:52:21 +0100	[thread overview]
Message-ID: <YkR8tTWabfTRLarB@shell.armlinux.org.uk> (raw)
In-Reply-To: <20220316101854.imevzoqk6oashrgg@skbuf>

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@nxp.com>
> > >>> ---
> > > 
> > > (..)
> > > 
> > >>> +maintainers:
> > >>> +  - Russell King <linux@armlinux.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!

  parent reply	other threads:[~2022-03-30 15:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15 12:33 [PATCH net-next] dt-bindings: net: convert sff,sfp to dtschema Ioana Ciornei
2022-03-15 18:21 ` Krzysztof Kozlowski
2022-03-15 19:07   ` Ioana Ciornei
2022-03-16  8:23     ` Krzysztof Kozlowski
2022-03-16 10:18       ` Ioana Ciornei
2022-03-16 12:04         ` Krzysztof Kozlowski
2022-03-30 15:54           ` Russell King (Oracle)
2022-03-30 15:56             ` Russell King (Oracle)
2022-03-30 16:44             ` Krzysztof Kozlowski
2022-03-30 15:52         ` Russell King (Oracle) [this message]
2022-03-30 16:09           ` Rob Herring
2022-03-30 16:35             ` Russell King (Oracle)
2022-03-30 15:40   ` Russell King (Oracle)
2022-03-30 16:51     ` Krzysztof Kozlowski
2022-03-30 16:59       ` Krzysztof Kozlowski
2022-03-31 20:45       ` Krzysztof Kozlowski
2022-06-10 22:31 ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YkR8tTWabfTRLarB@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=ioana.ciornei@nxp.com \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).