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!
