Re: [GIT PULL] omap changes for v2.6.39 merge window

[Linus Torvalds]

On Wed, Mar 30, 2011 at 7:20 PM, Bill Gatliff <bgat@xxxxxxxxxxxxxxx> wrote:
>
> If it isn't opportunity, then you must be arguing that we shouldn't
> add any new ARM SoC support to the kernel.  Is that what you are
> saying?

What I'm saying is that we should not be adding ANY MINDLESS BOARD
DRIVERS for ARM.

Because they don't work. Most of them are totally unmaintainable CRAP
in the long run. They are extra code that actually have negative
worth. It shouldn't be in the kernel at all.

So let's take a really simple example of this kind of crap.

Do this:

    git ls-files arch/arm/ | grep gpio

and cry. That's 145 files in the arm directory that are some kind of
crazy gpio support.

Now, we have gpio drivers in other parts of the kernel too, but ARM is
at the point where it's just crazy.

And most GPIO drivers I've ever seen are actually basically "turn this
bit on or off in this register to turn it into an Input or Output"
along with "read/write this other bit to actually see/set the value".
Repeat that for 'nr' bits, where 'nr' is just some small value,
usually in single digits.

Now, not all of them are that, by all means, and the details are often
slightly different. Sometimes the read register is the same as the
write register, sometimes it isn't. Sometimes you have a "clear
register" and a "set register" instead of a register you write the
value to. And I haven't checked what those 145 files do, but I bet a
_lot_ of them could be described by having a single generic gpio
driver, and then just using devicetree to give that common driver a
few values to describe where the IO ports are, which bits they are,
and which type of gpio it is.

And then when you have another ARM SoC, instead of writing yet another
mindless board driver for the gpio's on it, just add the <nr> entries
for the GPIO's to the device tree. NOT A SINGLE LINE OF CODE.

Yes, yes, there are always exceptions. Many GPIO's are actually behind
some i2c bus or something. Others can do pulsing or are just generally
more complex than an array of single bits. So I'm sure we couldn't
replace all those 145 gpio files under arch/arm with a single driver
and some devicetree entries, but maybe half of them match the simple
pattern. I bet the SoC case it's more than half, it would be silly to
do i2c on an SoC. But I dunno. I really didn't look.

PowerPC does exactly the above, btw. So I'm not just talking about
some magical theoretical thing. I seriously think every ARM person who
has ever written any of those "gpio" files should look at powerpc.
Now, I suspect that most powerpc SoC's tend to share more IP blocks
than the crazy ARM situation, but even so, please just check it out.
Check out the device tree files (*.dts) and do that same

   git ls-files arch/arm/ | grep gpio

except do it on powerpc.

See the difference?

The powerpc people even wrote documentation about the thing, which is
just above and beyond reasonable.

                             Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/