linux-kernel - Re: [PATCH] ARM: EXYNOS: Update defconfig for Arndale and Origen board

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] [day] [month] [year] [list]

Date:	Tue, 4 Jun 2013 13:13:17 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Olof Johansson <olof@...om.net>
Cc:	Tushar Behera <tushar.behera@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Kukjin Kim <kgene.kim@...sung.com>, grant.likely@...aro.org,
	Kevin Hilman <khilman@...aro.org>,
	Patch Tracking <patches@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Doug Anderson <dianders@...omium.org>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: EXYNOS: Update defconfig for Arndale and Origen
 board

On Tue, May 28, 2013 at 10:31:41PM -0700, Olof Johansson wrote:
> On Tue, May 28, 2013 at 8:59 PM, Tushar Behera <tushar.behera@...aro.org> wrote:

> > e. usb: ehci-s5p: add the HSIC port initialization
> > f. ARM: dts: Add USB gpio entries for Arndale board

> > I am not sure whether such kind of board-specific patches (e, f) are
> > appreciated in the drivers. But that is all we need to get USB and
> > Ethernet to work on v3.10-rc3 kernel.

> I've come across a similar situation with wifi reset sequence on the
> chromebook. On the product kernel we added some code to the board file
> to deal with it, but if we keep doing that things will grow out of
> hand.

> I don't know if it'll be unpopular, but I think it's time to start a
> drivers/platform/arm for these kind of things, and have those drivers
> probe on the system compatible value, similar to how x86 does it (with
> DMI tables). At least that's my plan for approaching the wifi
> reset/power-on sequence on the Chromebook. I hope to have patches in
> not all that long...

This does seem to be a fairly general problem for embedded systems with
devices on enumerable buses - it's even worse for things like Slimbus
where the expectation is that many devices will spend almost all of
their time powered down.  We probably need to come up with
infrastructure to enable the drivers for the individual devices to
handle this, or at least roll out such infrastructure more widely, IIRC
there's some DT stuff for PCI.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)