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: <201103311723.02301.arnd@arndb.de>
Date:	Thu, 31 Mar 2011 17:23:01 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Kevin Hilman <khilman@...com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"Russell King - ARM Linux" <linux@....linux.org.uk>,
	Ingo Molnar <mingo@...e.hu>, Nicolas Pitre <nico@...xnic.net>,
	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 Thursday 31 March 2011, Kevin Hilman wrote:
> Some SoCs families (like OMAP) have huge amount of diversity even within
> the SoC family, so better abstractions and generic infrastrucure
> improvements are an obvious win, even staying within the SoC.

But that's the point. The incentive is there for managing the infrastructure
within the SoC, but not across SoCs. Allow me to use OMAP as a bad example
while pointing out that it's really one of the best supported platforms
we currently have, while the others are usually much worse in terms of
working with the community (or at least they are behind on the learning
curve but getting there):

* OMAP2 introduced the hwmod concept as an attempt to reduce duplication
  between board code, but the code was done on the mach-omap2 level
  instead of finding a way to make it work across SOC vendors, or using
  an existing solution.

* The IOMMU code in omap2 duplicates the API we have in the common kernel,
  with slight differences, instead of using the existing code, making it
  impossible to share a driver between SOC families.

* The ti-st code duplicates parts of the bluetooth layer (apparently
  that is getting fixed soon).

* The DSS display drivers introduce new infrastructure include new bus
  types that have the complexity to make them completely generic, but
  in practice can only work on OMAP, and are clearly not written with
  cross-vendor abstractions in mind.

	Arnd
--
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/