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

["Russell King (Oracle)" <linux@armlinux.org.uk>]

Usefully, Krzysztof Kozlowski's email bounces for me.

On Wed, Mar 30, 2022 at 04:54:28PM +0100, Russell King (Oracle) wrote:
> On Wed, Mar 16, 2022 at 01:04:21PM +0100, Krzysztof Kozlowski wrote:
> > On 16/03/2022 11:18, Ioana Ciornei wrote:
> > >>>
> > >>> It's related since it shows a generic usage pattern of the sfp node.
> > >>> I wouldn't just remove it since it's just adds context to the example
> > >>> not doing any harm.
> > >>
> > >> Usage (consumer) is not related to these bindings. The bindings for this
> > >> phy/mac should show the usage of sfp, but not the provider bindings.
> > >>
> > >> The bindings of each clock provider do not contain examples for clock
> > >> consumer. Same for regulator, pinctrl, power domains, interconnect and
> > >> every other component. It would be a lot of code duplication to include
> > >> consumers in each provider. Instead, we out the example of consumer in
> > >> the consumer bindings.
> > >>
> > >> The harm is - duplicated code and one more example which can be done
> > >> wrong (like here node name not conforming to DT spec).
> > > 
> > > I suppose you refer to "sfp-eth3" which you suggested here to be just
> > > "sfp". 
> > 
> > I refer now to "cps_emac3" which uses specific name instead of generic
> > and underscore instead of hyphen (although underscore is actually listed
> > as allowed in DT spec, dtc will complain about it).
> > 
> > >In an example, that's totally acceptable but on boards there can
> > > be multiple SFPs which would mean that there would be multiple sfp
> > > nodes. We have to discern somehow between them. Adding a unit name would
> > > not be optimal since there is no "reg" property to go with it.
> > 
> > The common practice is adding a numbering suffix.
> > 
> > > 
> > > So "sfp-eth3" or variants I think are necessary even though not
> > > conforming to the DT spec.
> > > 
> > >>
> > >> If you insist to keep it, please share why these bindings are special,
> > >> different than all other bindings I mentioned above.
> > > 
> > > 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?
> > 
> > I am also learning and I wished many of my mistakes of early DT bindings
> > conversion were spotted. Especially my early bindings... but even now I
> > keep making mistakes. Human thing. :)
> > 
> > I converted quite a lot of bindings, so can you point to such examples
> > of my schema which includes consumer example in a provider bindings? If
> > you find such, please send a patch removing trivial code.
> > 
> > 
> > > As an example for a consumer device being listed in the provider yaml
> > > file is 'gpio-pca95xx.yaml'
> > 
> > Indeed, this is trivial and useless code which I kept from conversion,
> > should be removed.
> > 
> > >
> >  and for the reverse (provider described in
> > > the consumer) I can list 'samsung,s5pv210-clock.yaml',
> > > 'samsung,exynos5260-clock.yaml' etc.
> > 
> > These are different. This is an example how to model the input clock to
> > the device being described in the bindings. This is not an example how
> > to use the clock provider, like you created here. The input clock
> > sometimes is defined in Exynos clock controller, sometimes outside. The
> > example there shows the second case - when it has to come outside. It's
> > not showing the usage of clocks provided by this device, but I agree
> > that it also might be trivial and obvious. If you think it is obvious,
> > feel free to comment/send a patch.
> 
> Why is whether something is an input or output relevant? One can quite
> rightly argue that SFPs are both input and output. :)
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

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