From: Thierry Reding <thierry.reding@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Grant Likely <grant.likely@linaro.org>,
Rob Herring <rob.herring@calxeda.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Hiroshi Doyu <hdoyu@nvidia.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 2/4] driver core: Allow early registration of devices
Date: Fri, 16 Aug 2013 23:55:31 +0200 [thread overview]
Message-ID: <20130816215530.GA14464@mithrandir> (raw)
In-Reply-To: <20130816210637.GC2198@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 3272 bytes --]
On Fri, Aug 16, 2013 at 02:06:37PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Aug 16, 2013 at 10:39:21PM +0200, Thierry Reding wrote:
> > +static DEFINE_MUTEX(device_early_mutex);
> > +static LIST_HEAD(device_early_list);
> > +static bool device_is_early = true;
> > +
> > +/*
> > + * Keep a list of early registered devices so that they can be fully
> > + * registered at a later point in time.
> > + */
> > +static void device_early_add(struct device *dev)
>
> __init?
Yes.
> > +{
> > + mutex_lock(&device_early_mutex);
> > + list_add_tail(&dev->p->early, &device_early_list);
> > + mutex_unlock(&device_early_mutex);
> > +}
> > +
> > +/*
> > + * Mark the early device registration phase as completed.
> > + */
> > +int __init device_early_init(void)
> > +{
> > + device_is_early = false;
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * Fixup platform devices instantiated from device tree. The problem is
> > + * that since early registration happens before interrupt controllers
> > + * have been setup, the OF core code won't know how to map interrupts.
> > + */
> > +int __init platform_device_early_fixup(struct platform_device *pdev)
>
> This shouldn't be in this file, because:
>
> > +/*
> > + * Fully register early devices.
> > + */
> > +int __init device_early_done(void)
> > +{
> > + struct device_private *private;
> > +
> > + list_for_each_entry(private, &device_early_list, early) {
> > + struct device *dev = private->device;
> > + int err;
> > +
> > + if (dev->bus == &platform_bus_type) {
>
> Why special case the platform bus? We are trying to move things off of
> the platform bus, don't make it harder to do that :)
I heard about that, but I must have missed the thread where this was
discussed. Can you point me to it?
> > + struct platform_device *pdev = to_platform_device(dev);
> > +
> > + err = platform_device_early_fixup(pdev);
> > + if (err < 0)
> > + dev_err(&pdev->dev,
> > + "failed to fixup device %s: %d\n",
> > + dev_name(&pdev->dev), err);
> > + }
>
> You should just have a bus callback that can be made here that, if
> present, can be called. That way any bus can handle this type of thing,
> not just the platform one.
You mean something like an .early_fixup() in struct bus_type? That would
indeed be much cleaner. As I mentioned this is a very early prototype
and this particular hunk exists specifically to fixup the platform
devices created by the device tree helpers so that the kernel actually
boots to the login prompt.
> Not that I really like the whole idea anyway, but I doubt there's much I
> can do about it...
Well, getting feedback from you and others is precisely the reason why I
wanted to post this early. There must be a reason why you don't like it,
so perhaps you can share your thoughts and we can mould this into
something that you'd be more comfortable with.
To be honest I don't particularly like it either. It's very hackish for
core code. But on the other hand there are a few device/driver ordering
problems that this (or something similar) would help solve. I'm
certainly open to discuss alternatives and perhaps there's a much
cleaner way to solve the problem.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-08-16 22:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-16 20:39 [RFC 0/4] Early device registration Thierry Reding
2013-08-16 20:39 ` [RFC 1/4] driver core: Register SoC bus after platform bus Thierry Reding
2013-08-16 20:39 ` [RFC 2/4] driver core: Allow early registration of devices Thierry Reding
2013-08-16 21:06 ` Greg Kroah-Hartman
2013-08-16 21:55 ` Thierry Reding [this message]
2013-08-16 22:08 ` Greg Kroah-Hartman
2013-08-17 11:17 ` Thierry Reding
2013-08-19 19:43 ` Stephen Warren
2013-08-19 20:10 ` Thierry Reding
2013-08-19 20:53 ` Stephen Warren
2013-08-19 21:41 ` Thierry Reding
2013-08-16 22:20 ` Grant Likely
2013-08-16 22:35 ` Greg Kroah-Hartman
2013-08-17 10:26 ` Tomasz Figa
2013-08-19 19:49 ` Stephen Warren
2013-08-19 20:04 ` Thierry Reding
2013-08-17 11:07 ` Thierry Reding
2013-08-16 20:39 ` [RFC 3/4] ARM: tegra: Call of_platform_populate() early Thierry Reding
2013-08-16 20:39 ` [RFC 4/4] OF: Add device pointer to struct device_node Thierry Reding
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=20130816215530.GA14464@mithrandir \
--to=thierry.reding@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=hdoyu@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=rob.herring@calxeda.com \
--cc=sebastian.hesselbarth@gmail.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).