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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <alpine.LFD.2.00.1103311400190.28032@xanadu.home>
Date:	Thu, 31 Mar 2011 14:23:13 -0400 (EDT)
From:	Nicolas Pitre <nico@...xnic.net>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Arnd Bergmann <arnd@...db.de>, Kevin Hilman <khilman@...com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Ingo Molnar <mingo@...e.hu>, david@...g.hm,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Tony Lindgren <tony@...mide.com>,
	David Brown <davidb@...eaurora.org>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org, linux-omap@...r.kernel.org,
	Catalin Marinas <catalin.marinas@....com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window

On Thu, 31 Mar 2011, Thomas Gleixner wrote:

> Start off with such a trivial, but immense effective cleanup and see
> what it helps to share code even accross SoC vendors. They all glue
> together random IP blocks from the market and there are not soo many
> sources which are relevant. This makes sense in all aspects:
> 
>       1) less and better code
>       2) faster setup for new SoCs
>       3) shared benefit for all vendors

If this was always true.  Someone commented on the fact that the IP 
block providing USB on OMAP is shared with a couple other platforms.  
But about 2600 lines of pure glue is still necessary around the common 
driver to make it work for everyone.  I'm not saying that separate 
drivers are called for here, simply that hardware people _will_ screw it 
up, especially when they are hooking it up to a non-standard 
SOC-specific bus.

Another example: there used to be many different IP blocks providing 
MMC/SD/SDIO support that people were adding to their SOCs.  Each SOC 
would have its own reinvention of the wheel but they were all different 
but simple wheels, and drivers for them were obvious and straight 
forward.  Then came the SDHCI "standard".  At first few implementation 
existed so the sdhci driver was, too, rather straight forward.  But 
hardware manufacturers thought (rightfully) that this would be a good 
idea to use that standard instead of using their custom simple wheel.  
And so they did, releasing new SOC revision with the old wheel replaced 
by a square implementation of the sdhci one.  Today the sdhci driver is 
literally bastardized by all the quirks needed to work around all the 
different and creative bugs or even standard misinterpretation of the 
standard out there in the field.  And in many cases the sdhci version is 
even _less_ functional than the custom and already supported 
implementation it replaced.

And what would the hardware guys tell you?  That software is cheap.

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