On Fri, May 24, 2013 at 01:03:25PM +0200, Linus Walleij wrote: > On Fri, May 24, 2013 at 12:40 AM, Sebastian Hesselbarth > <sebastian.hesselba...@gmail.com> wrote: > > On 05/23/2013 08:40 PM, Jason Cooper wrote: > > >> I think marvell,psc1_reset =<>; gives us the most flexibility in > >> accurately describing the hardware. > > > > > > IMHO using that is just another workaround for a broken driver. We > > could hack the whole register setup in DT as it would still accurately > > describe HW. Don't get me wrong, but I don't like it. > > > > Haven't checked how happy Linus Walleij is about pinctrl drivers with > > reg values hacked in lately. > > One of the things I've been ranting about lately is that Linux > subsystem maintainers have become de-facto device tree > standard commite chairs. :-(
This is the first I've heard this rant. :( To that end, I agree with you. My frustration boiled down to trying to predict the future, which is futile. :-P For our scenario, once we can confirm our least popular kirkwood variant, the 6282, behaves the same as we've seen so far, then "marvell,kirkwood-eth" is fine by me. > So to the actual question: > > In general I think we need to draw a line and define what we > mean with "describing the hardware" in a device tree. > > We have some consensus: > - <reg> properties to describe regsiter BASE offset in physical > memory and size. > - Resources like IRQ, DMA channel, regulator, GPIO pin control > handles, are passed using <&ersand> notation. > > And so it goes on. > > When it comes to defining different registers and their individual > bits and the meaning of these and/or default values, I personally > think that is making things harder for developers rather than > simplifying things. I know that pinctrl-single is anyway doing this > and I was talked into accepting it under circumstances where > developers are being passed opaque machine-generated > data that would otherwise be translated into unreadable header > files littering the kernel. > > For a coder it is definately better if the *driver* know these > details, but whether that is possible seems to depend on things > like hardware development process. Agree. > IMO: if you want to go down that road, what you really want is not > ever more expressible device trees, but real open firmware, > or ACPI or UEFI that can interpret and run bytecode as some > "bios" for you. With DT coming from OF maybe this is a natural > progression of things, but one has to realize when we reach the > point where what we really want is a bios. Then your time is > likely better spent with Tianocore or something than with the > kernel. shudder. I like embedded systems because the *don't* have a bios. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
