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

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

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!