[PATCH] driver core: Early dev_name() support.
Paul Mundt
use dev_xxx() calls early on due to dev_name() and others being
unavailable at the time ->probe() is called.
This implements early init_name construction from the matched name/id
pair following the semantics of the late device/driver match. As a
result, matched IDs (inclusive of requested ones) are preserved when the
handoff from the early platform code happens at kobject initialization
time.
Since we still require kmalloc slabs to be available at this point, using
kstrdup() for establishing the init_name works fine. This subsequently
needs to be tested from dev_name() prior to the init_name being cleared
by the driver core. We don't kfree() since others will already have a
handle on the string long before the kobject initialization takes place.
This is also needed to permit drivers to use the clock framework early,
without having to manually construct their own device IDs from the match
id/name pair locally (needed by the early console and timer code on sh
and arm).
Signed-off-by: Paul Mundt <let...@linux-sh.org>
---
drivers/base/platform.c | 19 +++++++++++++++++++
include/linux/device.h | 4 ++++
2 files changed, 23 insertions(+)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 58efaf2..bc38f63 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1181,6 +1181,25 @@ static int __init early_platform_driver_probe_id(char *class_str,
}
if (match) {
+ /*
+ * Set up a sensible init_name to enable
+ * dev_name() and others to be used before the
+ * rest of the driver core is initialized.
+ */
+ if (!match->dev.init_name) {
+ char buf[32];
+
+ if (match->id != -1)
+ snprintf(buf, sizeof(buf), "%s.%d",
+ match->name, match->id);
+ else
+ snprintf(buf, sizeof(buf), "%s",
+ match->name);
+
+ match->dev.init_name = kstrdup(buf, GFP_KERNEL);
+ if (!match->dev.init_name)
+ return -ENOMEM;
+ }
if (epdrv->pdrv->probe(match))
pr_warning("%s: unable to probe %s early.\n",
class_str, match->name);
diff --git a/include/linux/device.h b/include/linux/device.h
index b30527d..3af5bce 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -432,6 +432,10 @@ struct device {
static inline const char *dev_name(const struct device *dev)
{
+ /* Use the init name until the kobject becomes available */
+ if (dev->init_name)
+ return dev->init_name;
+
return kobject_name(&dev->kobj);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
> Presently early platform devices suffer from the fact they are unable to
> use dev_xxx() calls early on due to dev_name() and others being
> unavailable at the time ->probe() is called.
>
> This implements early init_name construction from the matched name/id
> pair following the semantics of the late device/driver match. As a
> result, matched IDs (inclusive of requested ones) are preserved when the
> handoff from the early platform code happens at kobject initialization
> time.
>
> Since we still require kmalloc slabs to be available at this point, using
> kstrdup() for establishing the init_name works fine. This subsequently
> needs to be tested from dev_name() prior to the init_name being cleared
> by the driver core. We don't kfree() since others will already have a
> handle on the string long before the kobject initialization takes place.
>
> This is also needed to permit drivers to use the clock framework early,
> without having to manually construct their own device IDs from the match
> id/name pair locally (needed by the early console and timer code on sh
> and arm).
Is this change something that we need for .34? Or can it wait for .35?
thanks,
greg k-h
Paul Mundt
> On Tue, Mar 09, 2010 at 03:57:53PM +0900, Paul Mundt wrote:
> > Presently early platform devices suffer from the fact they are unable to
> > use dev_xxx() calls early on due to dev_name() and others being
> > unavailable at the time ->probe() is called.
> >
> > This implements early init_name construction from the matched name/id
> > pair following the semantics of the late device/driver match. As a
> > result, matched IDs (inclusive of requested ones) are preserved when the
> > handoff from the early platform code happens at kobject initialization
> > time.
> >
> > Since we still require kmalloc slabs to be available at this point, using
> > kstrdup() for establishing the init_name works fine. This subsequently
> > needs to be tested from dev_name() prior to the init_name being cleared
> > by the driver core. We don't kfree() since others will already have a
> > handle on the string long before the kobject initialization takes place.
> >
> > This is also needed to permit drivers to use the clock framework early,
> > without having to manually construct their own device IDs from the match
> > id/name pair locally (needed by the early console and timer code on sh
> > and arm).
>
> Is this change something that we need for .34? Or can it wait for .35?
>
error paths for the existing early platform drivers, but that's obviously
not critical.
I have a bunch of work I plan to do on top of it for 2.6.35, so I was
planning on carrying it in a topic branch once I got your Acked-by.
Greg KH
Sure, that's fine with me. Feel free to add a:
Acked-by: Greg Kroah-Hartman <gre...@suse.de>
to the patch.
thanks,
greg k-h
Paul Mundt
Kay Sievers
> This implements early init_name construction from the matched name/id
> pair following the semantics of the late device/driver match. As a
> result, matched IDs (inclusive of requested ones) are preserved when the
> handoff from the early platform code happens at kobject initialization
> time.
> + if (!match->dev.init_name) {
> + char buf[32];
> +
> + if (match->id != -1)
> + snprintf(buf, sizeof(buf), "%s.%d",
> + match->name, match->id);
> + else
> + snprintf(buf, sizeof(buf), "%s",
> + match->name);
> +
> + match->dev.init_name = kstrdup(buf, GFP_KERNEL);
> + if (!match->dev.init_name)
> + return -ENOMEM;
> + }
This can be kasprintf() I guess.
> static inline const char *dev_name(const struct device *dev)
> {
> + /* Use the init name until the kobject becomes available */
This should probably state that it's used for getting names out of
unregistered devices. Otherwise it sounds confusing.
> + if (dev->init_name)
> + return dev->init_name;
> +
> return kobject_name(&dev->kobj);
> }
Thanks,
Kay
Paul Mundt
> On Tue, Mar 9, 2010 at 07:57, Paul Mundt <let...@linux-sh.org> wrote:
> > This implements early init_name construction from the matched name/id
> > pair following the semantics of the late device/driver match. As a
> > result, matched IDs (inclusive of requested ones) are preserved when the
> > handoff from the early platform code happens at kobject initialization
> > time.
>
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? char buf[32];
> > +
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? if (match->id != -1)
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? snprintf(buf, sizeof(buf), "%s.%d",
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??match->name, match->id);
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? else
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? snprintf(buf, sizeof(buf), "%s",
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??match->name);
> > +
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? match->dev.init_name = kstrdup(buf, GFP_KERNEL);
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? if (!match->dev.init_name)
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? return -ENOMEM;
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? }
>
> This can be kasprintf() I guess.
>
> > ??static inline const char *dev_name(const struct device *dev)
> > ??{
> > + ?? ?? ?? /* Use the init name until the kobject becomes available */
>
> This should probably state that it's used for getting names out of
> unregistered devices. Otherwise it sounds confusing.
>
It's not clear that that distinction makes things any less confusing.
Early devices are registered, they just haven't been fully initialized
yet.
Kay Sievers
> On Thu, Mar 11, 2010 at 08:59:18PM +0100, Kay Sievers wrote:
>> > ??static inline const char *dev_name(const struct device *dev)
>> > ??{
>> > + ?? ?? ?? /* Use the init name until the kobject becomes available */
>>
>> This should probably state that it's used for getting names out of
>> unregistered devices. Otherwise it sounds confusing.
>>
> It's not clear that that distinction makes things any less confusing.
> Early devices are registered, they just haven't been fully initialized
> yet.
For the driver core, "registered" devices are devices where
device_add() or device_register() has been called. Initialized devices
are devices which device_initialize() was called for. The devices you
mean are not "registered" in that sense, right?
Thanks,
Kay
Paul Mundt
> On Mon, Mar 15, 2010 at 09:03, Paul Mundt <let...@linux-sh.org> wrote:
> > On Thu, Mar 11, 2010 at 08:59:18PM +0100, Kay Sievers wrote:
>
> >> > ??static inline const char *dev_name(const struct device *dev)
> >> > ??{
> >> > + ?? ?? ?? /* Use the init name until the kobject becomes available */
> >>
> >> This should probably state that it's used for getting names out of
> >> unregistered devices. Otherwise it sounds confusing.
> >>
> > It's not clear that that distinction makes things any less confusing.
> > Early devices are registered, they just haven't been fully initialized
> > yet.
>
> For the driver core, "registered" devices are devices where
> device_add() or device_register() has been called. Initialized devices
> are devices which device_initialize() was called for. The devices you
> mean are not "registered" in that sense, right?
>
here is the kobject initialization, where we wait on device_add() to
clear the init name before switching over to the kobject name. However
the kobject initialization happens is ultimately immaterial.
All early devices have been added with early_platform_add_devices(), that
to me signifies an added and available device, regardless of whether it's
waiting around for the driver core to complete part of its initialization
at a later stage or not.
I have a hard time believing that the comment that we're waiting on the
kobject is in any way less confusing than some arbitrary redefinition of
"registered" vs "added" etc. that the driver core chooses to engage in
for arbitrary parts of the boot process.