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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 31 Mar 2011 07:43:12 -0700
From:	Kevin Hilman <khilman@...com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	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>,
	Arnd Bergmann <arnd@...db.de>,
	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

Thomas Gleixner <tglx@...utronix.de> writes:

> But the current SoC maintainer model does not work either. The SoC
> maintainers care about their sandbox and have exactly zero incentive
> to look at the overall picture, e.g reuse of code for the same IP
> blocks, better abstraction mechanisms etc. 

zero incentive?  that's a bit strong, IMO.

That may be true for some SoCs, it's not really fair as a sweeping
statement.

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.

There are several examples of SoC maintainers looking at the overall
picture and contributing to better abstractions and common
infrastructure code.

One is USB as Felipe already pointed out where the same USB OTG IP block
(with vendor tweaks of course) is used across several completely
different SoCs with common infrastructure code.

Another example that I'm more familiar with is power management.  In
OMAP land, we have been been very supportive and active in generic
infrastructure improvements (like runtime PM.)  In fact runtime PM was
born partially because one of the other ARM SoC maintainers (Magnus
Damm, SH-mobile) proposed the idea as he was implementing PM for that
SoC family.  We have been actively contributing to the runtime PM
infrastructure with both code, testing, converting our drivers over to
using runtime PM. and contributing back fixes and enhancements as we
find problems or limitations.  In addition, personally, I have spent the
last year evangelizing the importance of using common frameworks like
runtime PM to the embedded community via talks at the Embedded Linux
Conference (ELC, US and Europe.)  Especially as IP blocks are reused
across SoC families, abstractions like runtime PM are the only way to
keep the SoC specifics of PM out of the common driver.

Yes, ARM SoC maintainers have to make up some ground.  But compare this
to just a couple years ago where the common complaint was "why aren't
embedded SoC people contributing code to mainline", and you'll see we
have come a long way.

Kevin

Maintainer of parts of the ARM kernel:
- TI Davinci SoC family
- TI OMAP Power Management infrastructure
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ