Stephen, Thanks for your feedback! On Thu, 25 Feb 2016 15:37:10 -0800, Stephen Boyd wrote: > I would think the binding would be done in a way that we don't > have to describe every little register in this misc register > block. Instead, dfx server has a compatible: > > node@f00 { > reg = <0xf00 0x100>; > compatible = "marvell,dfx-ap806"; > #clock-cells = <1>; > }; > > And then a driver that probes this compatible string and > registers a handful of clks. If we ever get into a situation > where we want to expose non-clk functionality from this device > node, we would make some sort of mfd driver that probes based on > the same compatible string and creates platform devices in > software to register the clk device component and whatever other > device type is used. In that situation, we could assign a regmap > to the mfd device and the clk device would be a child of the mfd > and get a regmap through the dev->parent pointer. > > TL;DR I'm still lost why we have to describe each clk in DT. I would entirely agree with you if this DFX Server was some sort of "system control" IP block that provided clocks, resets, and all sort of other features. But this DFX server thing is just a bunch of registers with absolutely no relation to clocks. Due to this, it would be completely awkward to have clock references like: serial { clocks = <&dfxserver 42>; }; One will wonder "why the heck this UART controller is using a clock from this really odd dfxserver thing" ? Currently we have: serial { clocks = <&coreclk 4>; }; which makes a *lot* more sense. Also, your idea of just hiding everything behind a MFD bothers me quite a bit. If I push this idea further, then why shouldn't I replace my entire DT with a single node, that covers the entire register space of my SoC, and then handle *everything* as a huge MFD. In a way, it would be quite useful for me, as it would resolve the on-going dispute over DT binding stability with Rob and Mark. For sure, I wouldn't have any DT backward compatibility issue, because everything is hidden in my big MFD. But in terms of the DT as a representation of the different HW blocks and the relations between then, such a choice would be quite a failure. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html