All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: "Moffett, Kyle D" <Kyle.D.Moffett@boeing.com>,
	Magnus Damm <damm@opensource.se>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <rob.herring@calxeda.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: Driver core support for early platform devices
Date: Thu, 22 Dec 2011 10:10:52 -0800	[thread overview]
Message-ID: <20111222181052.GA30259@suse.de> (raw)
In-Reply-To: <99F3E881-FB9E-4D49-9A91-793FDD04795D@boeing.com>

On Thu, Dec 22, 2011 at 11:55:56AM -0600, Moffett, Kyle D wrote:
> On Dec 22, 2011, at 12:45, Greg KH wrote:
> > On Thu, Dec 22, 2011 at 11:15:06AM -0600, Moffett, Kyle D wrote:
> >> Hi,
> >> 
> >> I'm tinkering with some improvements to the way that OpenPIC/MPIC are
> >> detected and loaded on PowerPC platforms, and it seems like I am trying
> >> to use the driver model before it is fully initialized.
> >> 
> >> In particular, it seems like it should be possible to simply declare an
> >> OpenPIC in the device-tree and have it automatically bound to a platform
> >> driver declaring the right OpenFirmware match strings.
> >> 
> >> Unfortunately, it needs to be bound by init_IRQ() time, while the driver
> >> model does not get initialized until much later (after the scheduler is
> >> up and running).
> >> 
> >> As far as I can tell, there seem to be 2 possible approaches to making
> >> that possible:
> >> 
> >> (1) Split the driver-model initialization into "early" and "late" phases
> >>    so that drivers can be registered and devices probed very early on
> >>    and then replay the necessary scheduler-dependent things after the
> >>    system is mostly started up (IE: devtmpfs, etc).
> > 
> > We already have that today with the "early_platform*" functions, right?
> > Will those work for you, or do you need this for a bus you are creating
> > and not using the platform bus?
> 
> Well, I can't figure out how "early_platform" is actually supposed to
> integrate with the platform bus itself.  It seems designed mostly for
> drivers like "earlyprintk" et. al. for which loading is controlled by
> a kernel parameter.
> 
> Specifically, I don't see any "early_platform" logic to match devices in
> the OF device-tree based on the driver "of_match" parameters, just based
> on text strings in early_param().
> 
> Furthermore, if I register an "early_platform" device, it seems to get
> unregistered when the normal driver model is brought up, instead of
> being sucked in and promoted to a normal platform_device.  That code is
> pretty poorly documented and only used in a couple places right now,
> though, so it's possible I am misreading it.

I think Magnus wrote this code, as he was having the same issues you
were, so he should be able to answer these questions better than I, as I
do not know this code at all, sorry.

greg k-h

  reply	other threads:[~2011-12-22 18:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-22 17:15 Driver core support for early platform devices Moffett, Kyle D
2011-12-22 17:45 ` Greg KH
2011-12-22 17:55   ` Moffett, Kyle D
2011-12-22 18:10     ` Greg KH [this message]
2011-12-22 20:45     ` Rob Herring
2012-01-05 18:41       ` Grant Likely

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=20111222181052.GA30259@suse.de \
    --to=gregkh@suse.de \
    --cc=Kyle.D.Moffett@boeing.com \
    --cc=benh@kernel.crashing.org \
    --cc=damm@opensource.se \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob.herring@calxeda.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.