Quoting Rob Herring (2016-02-22 11:42:49) > 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. I like the "err on the side of caution" part. I'll add that to clock-bindings.txt. Regards, Mike > > 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
