On Thu, Jul 31, 2008 at 01:13:10PM -0500, Timur Tabi wrote: > Grant Likely wrote: > > > This is a solved problem. The device tree simple claims compatibility > > with an older part that has the identical register-level interface. > > That would assume that the clock frequency is the only thing that decides > compatibility, which may technically be true now, but I don't think it's a > good > idea.
No it doesn't, it depends on the register interface to decide compatibility. Clock interface is part of that. I suggested encoding the clock divider directly in compatible (implicit in the SoC version), but it doesn't have to be that way. If clock freq is obtained from another property or some other method then that is okay too. What is important is that if compatibility is claimed, then it must really be compatible! If some new part appears in the future that breaks our assumptions, then we'll need to rework the driver anyway and the new part will *not* claim compatibility with the old. > I don't understand what's wrong with simply specifying the actual clock > frequency that the device uses? It varies from SOC to SOC, but U-Boot > calculates today already: There is nothing wrong with it (as long as we agree and it gets documented). I certainly don't have a problem with doing it this way. g. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
