On Mon, Feb 22, 2016 at 12:32 PM, Michael Turquette <mturquette@xxxxxxxxxxxx> wrote: > Quoting Andrew Lunn (2016-02-22 06:16:17) >> > Such information will come later, and we can rework the drivers and DT >> > bindings accordingly. Those DT bindings cannot be stable, as the >> > platform is under heavy development and we'll probably discover some >> > issues down the road. >> >> Hi Thomas >> >> Maybe add a big fat warning that the bindings are unstable, and the DT >> blob must be kept in sync with the kernel? > > +1 and feel free to blame the lack of documentation. No one can expect > bindings to be finalized when the chip topology is not fully understood. I can understand not understanding the full clock tree. I have "full" documentation of a Marvell chip and don't understand the clock tree fully. But I can't believe you don't have some sense of how many clocks you have to deal with. 10? 100? 1000? What I see is 2 nodes of a single register each for clocks at roughly the same address. That tells me your binding is too fine grained. If you really don't know what is right, then err on the side of a single clock provider node and don't put the clock details in DT. Rob -- 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
