Skip to contentSkip to conversation

driver core: Early dev_name() support.

PATCH In review Paul Mundt 3 participants 9 messages Mar 9, 2010 – Mar 15, 2010

Subsystems (2)
SuperH Driver core
lore
Share & tools
lore

Paul Mundt

author
#0 lore raw

PATCH 1/1 driver core: Early dev_name() support.

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).

Signed-off-by Paul Mundt <[email protected]>

---

 drivers/base/platform.c |   19 +++++++++++++++++++
 include/linux/device.h  |    4 ++++
 2 files changed, 23 insertions(+)
drivers/base/platform.c +19 -0
index 58efaf2..bc38f63 100644
@@ -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);
include/linux/device.h +4 -0
index b30527d..3af5bce 100644
@@ -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);
 }
#1 lore raw
Quoted 16 lines · Paul Mundt

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.

Quoted 4 lines

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

author
#2 lore raw
Quoted 17 lines · Greg KH
Quoted 16 lines · Paul Mundt

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.

Quoted 7 lines
Quoted 4 lines

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?

If it went in for .34 we would get properly dev_name() resolution in the 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.

Acked-by Greg Kroah-Hartman
#3 lore raw
Quoted 23 lines · Paul Mundt
Quoted 22 lines · Greg KH
Quoted 20 lines · Paul Mundt

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).

Quoted 8 lines
Quoted 2 lines

Is this change something that we need for .34? Or can it wait for .35?

If it went in for .34 we would get properly dev_name() resolution in the 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.

Sure, that's fine with me. Feel free to add a:

Acked-by Greg Kroah-Hartman <[email protected]>

to the patch.

thanks,

greg k-h

author
#4 lore raw
Quoted 30 lines · Greg KH
Quoted 29 lines · Paul Mundt
Quoted 17 lines · Greg KH
Quoted 16 lines · Paul Mundt

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.

Quoted 7 lines
Quoted 4 lines

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?

If it went in for .34 we would get properly dev_name() resolution in the error paths for the existing early platform drivers, but that's obviously not critical.

Quoted 8 lines
Quoted 2 lines

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.

Sure, that's fine with me. Feel free to add a:

Acked-by Greg Kroah-Hartman <[email protected]>

to the patch.

Done, thanks Greg.

#5 lore raw
In reply to Paul Mundt
Quoted 10 lines · Paul Mundt

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];

(quoted diff) +2 -0
+
+                               if (match->id != -1)

Review

Quoted 10 lines
(quoted diff) +10 -0
+                                       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.

Quoted 3 lines

 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.

Quoted 5 lines

+       if (dev->init_name)
+               return dev->init_name;
+
       return kobject_name(&dev->kobj);
 }

Thanks,
Kay ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ¥Šwÿº{.nÇ+‰·¥Š{±şÈÿŠ{ayºʇڙë,j­¢f£¢·hš�ï�êÿ‘êçz_è®(­éš�Šİ¢j"�ú¶m§ÿÿ¾«şG«�éÿ¢¸?™¨è­Ú&£ø§~�á

author
#6 lore raw
Quoted 7 lines · Kay Sievers
Quoted 5 lines · Paul Mundt

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.

Quoted 17 lines
Quoted 4 lines

+ ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? if (!match->dev.init_name) {
+ ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? char buf[32];

(quoted diff) +2 -0
+
+ ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? if (match->id != -1)

Review

Quoted 10 lines
(quoted diff) +10 -0
+ ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 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.

Yeah, that looks fine. I'll update it.

Quoted 7 lines
Quoted 3 lines

??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.

#7 lore raw
Quoted 6 lines · Paul Mundt
Quoted 4 lines · Kay Sievers
Quoted 3 lines

??static inline const char *dev_name(const struct device *dev) ??{
+ ?? ?? ?? /* Use the init name until the kobject becomes available */

Quoted 6 lines
Quoted 3 lines

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

author
#8 lore raw
Quoted 10 lines · Kay Sievers
Quoted 9 lines · Paul Mundt
Quoted 7 lines · Kay Sievers
Quoted 3 lines

??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.

Quoted 9 lines
Quoted 3 lines

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?

And you call that less confusing? The only dependency that dev_name() has 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.