linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Samuel Ortiz <sameo@linux.intel.com>,
	Arnd Bergmann <arnd@ardb.de>, Olof Johansson <olof@lixom.net>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Igor Grinberg <grinberg@compulab.co.il>,
	linux-embedded@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: Handling of modular boards
Date: Sat, 5 May 2012 01:03:09 +0100	[thread overview]
Message-ID: <20120505000308.GX14230@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20120504235225.GN897@n2100.arm.linux.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

      reply	other threads:[~2012-05-05  0:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04 18:58 Handling of modular boards Mark Brown
2012-05-04 19:34 ` Arnd Bergmann
2012-05-04 20:07   ` Mark Brown
2012-05-04 20:33   ` Wolfgang Denk
2012-05-04 20:39     ` Arnd Bergmann
2012-05-04 20:54       ` Wolfgang Denk
2012-05-04 21:03         ` Arnd Bergmann
2012-05-04 21:09           ` Stephen Warren
2012-05-04 21:52             ` Mark Brown
2012-05-04 22:09     ` Mark Brown
2012-05-10 10:41       ` Ben Dooks
2012-05-10 12:40       ` Igor Grinberg
2012-05-10 16:15         ` Stephen Warren
2012-05-11  6:15           ` Igor Grinberg
2012-05-08 12:26   ` Linus Walleij
2012-05-09 17:12     ` Mark Brown
2012-05-04 19:50 ` Stephen Warren
2012-05-04 20:38   ` Wolfgang Denk
2012-05-04 20:59     ` Stephen Warren
2012-05-04 20:44   ` Mark Brown
2012-05-08 12:33     ` Linus Walleij
2012-05-09  8:41     ` Alessandro Rubini
2012-05-10 10:43   ` Ben Dooks
2012-05-10 16:11     ` Stephen Warren
2012-05-04 22:55 ` Russell King - ARM Linux
2012-05-04 23:40   ` Mark Brown
2012-05-04 23:52     ` Russell King - ARM Linux
2012-05-05  0:03       ` Mark Brown [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120505000308.GX14230@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=arnd@ardb.de \
    --cc=grinberg@compulab.co.il \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=olof@lixom.net \
    --cc=sameo@linux.intel.com \
    --cc=swarren@wwwdotorg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).