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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 5 May 2012 00:40:57 +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 Fri, May 04, 2012 at 11:55:14PM +0100, Russell King - ARM Linux wrote:
> On Fri, May 04, 2012 at 07:58:51PM +0100, Mark Brown wrote:

> > I'm just starting to put some stuff together for this so I was wondering
> > if anyone had been thinking about this and had any bright ideas for how
> > to handle it, and also if people think that MFD is a good fit for this
> > or if we should split the silicon MFDs from these PCBs.

> I don't think its true to say that there's no support for this kind of
> thing.

> If you're thinking about a motherboard with separate add-on cards, then
> you can view the cards as their own separate platform device.  Your
> platform device driver would be a "whole board driver" responsible
> for creating and registering the specific devices found on the board
> in its probe function, and unregistering them in the remove function.

Oh, absolutely - there's support there at that level and several boards
doing some or all of this in mainline already.  It's not that you can't
do it, it's that there's a bunch of generic stuff to do with how you map
the resources through to the devices on the modules and describe the
chips that are on the modules for which there's no infrastructure so
everything needs to be hand coded on a per board basis.  The board
identification bits are board specific but the remapping and subdevice
instantiation bits seem like they shouldn't be.

> It also helps to give the right model to the power management support,
> because you're automatically arranging the child devices below the
> board-level device, which means all the child devices should be
> suspended before the board level device, and the board level device
> should be resumed before the child devices.

Yes, I'd anticipate that we'd have a device for the board which should
help with this sort of stuff.

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