[PATCH] driver core: Early dev_name() support.

[PATCH] driver core: Early dev_name() support.

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

Signed-off-by: Paul Mundt <lethal@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);
 }
 

[PATCH] driver core: Early dev_name() support.

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

Signed-off-by: Paul Mundt <lethal@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);
 }
 

Re: [PATCH] driver core: Early dev_name() support.

[Greg KH]

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?

thanks,

greg k-h

Re: [PATCH] driver core: Early dev_name() support.

[Greg KH]

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?

thanks,

greg k-h

Re: [PATCH] driver core: Early dev_name() support.

[Paul Mundt]

On Tue, Mar 09, 2010 at 06:37:27PM -0800, Greg KH wrote:
> 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?
> 
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.

Re: [PATCH] driver core: Early dev_name() support.

[Paul Mundt]

On Tue, Mar 09, 2010 at 06:37:27PM -0800, Greg KH wrote:
> 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?
> 
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.

Re: [PATCH] driver core: Early dev_name() support.

[Greg KH]

On Wed, Mar 10, 2010 at 12:21:58PM +0900, Paul Mundt wrote:
> On Tue, Mar 09, 2010 at 06:37:27PM -0800, Greg KH wrote:
> > 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?
> > 
> 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 <gregkh@suse.de>

to the patch.

thanks,

greg k-h

Re: [PATCH] driver core: Early dev_name() support.

[Greg KH]

On Wed, Mar 10, 2010 at 12:21:58PM +0900, Paul Mundt wrote:
> On Tue, Mar 09, 2010 at 06:37:27PM -0800, Greg KH wrote:
> > 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?
> > 
> 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 <gregkh@suse.de>

to the patch.

thanks,

greg k-h

Re: [PATCH] driver core: Early dev_name() support.

[Paul Mundt]

On Tue, Mar 09, 2010 at 07:28:46PM -0800, Greg KH wrote:
> On Wed, Mar 10, 2010 at 12:21:58PM +0900, Paul Mundt wrote:
> > On Tue, Mar 09, 2010 at 06:37:27PM -0800, Greg KH wrote:
> > > 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?
> > > 
> > 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 <gregkh@suse.de>
> 
> to the patch.
> 
Done, thanks Greg.

Re: [PATCH] driver core: Early dev_name() support.

[Paul Mundt]

On Tue, Mar 09, 2010 at 07:28:46PM -0800, Greg KH wrote:
> On Wed, Mar 10, 2010 at 12:21:58PM +0900, Paul Mundt wrote:
> > On Tue, Mar 09, 2010 at 06:37:27PM -0800, Greg KH wrote:
> > > 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?
> > > 
> > 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 <gregkh@suse.de>
> 
> to the patch.
> 
Done, thanks Greg.

Re: [PATCH] driver core: Early dev_name() support.

[Kay Sievers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1874 bytes --]

On Tue, Mar 9, 2010 at 07:57, Paul Mundt <lethal@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.

> +                       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
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þÈÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á

Re: [PATCH] driver core: Early dev_name() support.

[Kay Sievers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 1877 bytes --]

On Tue, Mar 9, 2010 at 07:57, Paul Mundt <lethal@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.
> +                       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 ofunregistered devices. Otherwise it sounds confusing.
> +       if (dev->init_name)> +               return dev->init_name;> +>        return kobject_name(&dev->kobj);>  }
Thanks,Kayÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH] driver core: Early dev_name() support.

[Paul Mundt]

On Thu, Mar 11, 2010 at 08:59:18PM +0100, Kay Sievers wrote:
> On Tue, Mar 9, 2010 at 07:57, Paul Mundt <lethal@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.
> 
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 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.
> 
Yeah, that looks fine. I'll update it.

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

Re: [PATCH] driver core: Early dev_name() support.

[Paul Mundt]

On Thu, Mar 11, 2010 at 08:59:18PM +0100, Kay Sievers wrote:
> On Tue, Mar 9, 2010 at 07:57, Paul Mundt <lethal@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.
> 
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 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.
> 
Yeah, that looks fine. I'll update it.

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

Re: [PATCH] driver core: Early dev_name() support.

[Kay Sievers]

On Mon, Mar 15, 2010 at 09:03, Paul Mundt <lethal@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?

Thanks,
Kay

Re: [PATCH] driver core: Early dev_name() support.

[Kay Sievers]

On Mon, Mar 15, 2010 at 09:03, Paul Mundt <lethal@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?

Thanks,
Kay

Re: [PATCH] driver core: Early dev_name() support.

[Paul Mundt]

On Mon, Mar 15, 2010 at 12:29:23PM +0100, Kay Sievers wrote:
> On Mon, Mar 15, 2010 at 09:03, Paul Mundt <lethal@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?
> 
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.

Re: [PATCH] driver core: Early dev_name() support.

[Paul Mundt]

On Mon, Mar 15, 2010 at 12:29:23PM +0100, Kay Sievers wrote:
> On Mon, Mar 15, 2010 at 09:03, Paul Mundt <lethal@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?
> 
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.