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!
