linux-kernel - Re: Handling of modular boards

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]

Date:	Sat, 5 May 2012 01:03:09 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Samuel Ortiz <sameo@...ux.intel.com>, Arnd Bergmann <arnd@...b.de>,
	Olof Johansson <olof@...om.net>,
	Stephen Warren <swarren@...dotorg.org>,
	Igor Grinberg <grinberg@...pulab.co.il>,
	linux-embedded@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: Handling of modular boards

On Sat, May 05, 2012 at 12:52:25AM +0100, Russell King - ARM Linux wrote:

> How about this - we have struct platform_device_info, which is used to
> create platform devices.  We can use this as an array to describe what
> platform devices to create in the sub-driver, including what the resources
> should be etc.

We (well, I at least) need to handle devices on other buses like I2C and
SPI too but yes, that's the sort of thing I was looking for.

> However, there's a problem with this - what if you need to do some board
> level init before hand?  That needs to be handled somehow before these
> devices are instantiated.  That could be done via a callback through
> platform data.

> But... this all seems wrong, because rather than having a driver which
> knows about the details of the board, we now have all the details of the
> board in question back in platform code which originally declared the
> board device.  That's wrong, because a daughter board may be shared
> between different platforms, and we don't want multiple copies of that
> data all around the place.

> I don't think there's an easy or generic solution to this.

I think that's OK - if there's any init stuff that needs to be done on a
prior to identification of the board then presumably it's a generic
thing for the motherboard which will apply to any plugin module on that
board and can be done as part of the normal board init.  If the init
needs to be done after identification of the board then probably it
applies to any motherboard the board might be plugged in to so we can
just define callbacks for the plugin module that can be part of the
plugin module description.

Cases that depend on a specific combination will doubtless exist and do
have the problems you describe but are probably less frequent but I
think we can go a long way on the first two.

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