[PATCH 01/20] drivers_base: platform: use always ->name for uevent

[PATCH 01/20] drivers_base: platform: use always ->name for uevent

[Sebastian Andrzej Siewior]

If id_entry is available then it is used. However if we remove first the
driver followed by the device, then the id_entry is pointing to driver's
memory which is long gone.
Since id->name and plat->name are equal there is no point in
distinguishing them.

Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 drivers/base/platform.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 0cad9c7..cd71575 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -614,7 +614,7 @@ static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
 		return rc;
 
 	add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX,
-		(pdev->id_entry) ? pdev->id_entry->name : pdev->name);
+			pdev->name);
 	return 0;
 }
 
-- 
1.7.4.4

Re: [PATCH 01/20] drivers_base: platform: use always ->name for uevent

[Grant Likely]

On Mon, Aug 15, 2011 at 8:51 AM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> If id_entry is available then it is used. However if we remove first the
> driver followed by the device, then the id_entry is pointing to driver's
> memory which is long gone.
> Since id->name and plat->name are equal there is no point in
> distinguishing them.
>
> Cc: Greg Kroah-Hartman <gregkh@suse.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  drivers/base/platform.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 0cad9c7..cd71575 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -614,7 +614,7 @@ static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
>                return rc;
>
>        add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX,
> -               (pdev->id_entry) ? pdev->id_entry->name : pdev->name);
> +                       pdev->name);

Yes, this looks like the right thing to do to me.  Also, I think the
original code is suspect because it causes the uevent data to be
different after binding a driver to a device.

g.

Re: [PATCH 01/20] drivers_base: platform: use always ->name for uevent

[Sebastian Andrzej Siewior]

Grant Likely wrote:
>> --- a/drivers/base/platform.c
>> +++ b/drivers/base/platform.c
>> @@ -614,7 +614,7 @@ static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
>>                return rc;
>>
>>        add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX,
>> -               (pdev->id_entry) ? pdev->id_entry->name : pdev->name);
>> +                       pdev->name);
> 
> Yes, this looks like the right thing to do to me.  Also, I think the
> original code is suspect because it causes the uevent data to be
> different after binding a driver to a device.

Why different? The code matches (pdev->name == id->name) or
(pdev->name ==  driver->name) so in both cases it should be equal to
pdev->name.

Are you or Greg taking this?

> g.

Sebastian

Re: [PATCH 01/20] drivers_base: platform: use always ->name for uevent

[Grant Likely]

On Mon, Aug 15, 2011 at 9:13 AM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> Grant Likely wrote:
>>>
>>> --- a/drivers/base/platform.c
>>> +++ b/drivers/base/platform.c
>>> @@ -614,7 +614,7 @@ static int platform_uevent(struct device *dev, struct
>>> kobj_uevent_env *env)
>>>               return rc;
>>>
>>>       add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX,
>>> -               (pdev->id_entry) ? pdev->id_entry->name : pdev->name);
>>> +                       pdev->name);
>>
>> Yes, this looks like the right thing to do to me.  Also, I think the
>> original code is suspect because it causes the uevent data to be
>> different after binding a driver to a device.
>
> Why different? The code matches (pdev->name == id->name) or
> (pdev->name ==  driver->name) so in both cases it should be equal to
> pdev->name.

Ah, true.  So not only was the code wrong, it was completely redundant.  :-)

g.

Re: [PATCH 01/20] drivers_base: platform: use always ->name for uevent

[Grant Likely]

On Mon, Aug 15, 2011 at 9:13 AM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> Grant Likely wrote:
>>>
>>> --- a/drivers/base/platform.c
>>> +++ b/drivers/base/platform.c
>>> @@ -614,7 +614,7 @@ static int platform_uevent(struct device *dev, struct
>>> kobj_uevent_env *env)
>>>               return rc;
>>>
>>>       add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX,
>>> -               (pdev->id_entry) ? pdev->id_entry->name : pdev->name);
>>> +                       pdev->name);
>>
>> Yes, this looks like the right thing to do to me.  Also, I think the
>> original code is suspect because it causes the uevent data to be
>> different after binding a driver to a device.
>
> Why different? The code matches (pdev->name == id->name) or
> (pdev->name ==  driver->name) so in both cases it should be equal to
> pdev->name.
>
> Are you or Greg taking this?

This one is all Greg.

g.

Re: [PATCH 01/20] drivers_base: platform: use always ->name for uevent

[Sarah Sharp]

On Mon, Aug 15, 2011 at 09:17:41AM -0600, Grant Likely wrote:
> On Mon, Aug 15, 2011 at 9:13 AM, Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
> > Grant Likely wrote:
> >>>
> >>> --- a/drivers/base/platform.c
> >>> +++ b/drivers/base/platform.c
> >>> @@ -614,7 +614,7 @@ static int platform_uevent(struct device *dev, struct
> >>> kobj_uevent_env *env)
> >>>               return rc;
> >>>
> >>>       add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX,
> >>> -               (pdev->id_entry) ? pdev->id_entry->name : pdev->name);
> >>> +                       pdev->name);
> >>
> >> Yes, this looks like the right thing to do to me.  Also, I think the
> >> original code is suspect because it causes the uevent data to be
> >> different after binding a driver to a device.
> >
> > Why different? The code matches (pdev->name == id->name) or
> > (pdev->name ==  driver->name) so in both cases it should be equal to
> > pdev->name.
> >
> > Are you or Greg taking this?
> 
> This one is all Greg.

Greg, do you want to take this patch through your driver core tree, or
would you prefer to have it come through the xHCI tree?

Sarah Sharp

Re: [PATCH 01/20] drivers_base: platform: use always ->name for uevent

[Greg KH]

On Mon, Aug 22, 2011 at 02:41:54PM -0700, Sarah Sharp wrote:
> On Mon, Aug 15, 2011 at 09:17:41AM -0600, Grant Likely wrote:
> > On Mon, Aug 15, 2011 at 9:13 AM, Sebastian Andrzej Siewior
> > <bigeasy@linutronix.de> wrote:
> > > Grant Likely wrote:
> > >>>
> > >>> --- a/drivers/base/platform.c
> > >>> +++ b/drivers/base/platform.c
> > >>> @@ -614,7 +614,7 @@ static int platform_uevent(struct device *dev, struct
> > >>> kobj_uevent_env *env)
> > >>>               return rc;
> > >>>
> > >>>       add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX,
> > >>> -               (pdev->id_entry) ? pdev->id_entry->name : pdev->name);
> > >>> +                       pdev->name);
> > >>
> > >> Yes, this looks like the right thing to do to me.  Also, I think the
> > >> original code is suspect because it causes the uevent data to be
> > >> different after binding a driver to a device.
> > >
> > > Why different? The code matches (pdev->name == id->name) or
> > > (pdev->name ==  driver->name) so in both cases it should be equal to
> > > pdev->name.
> > >
> > > Are you or Greg taking this?
> > 
> > This one is all Greg.
> 
> Greg, do you want to take this patch through your driver core tree, or
> would you prefer to have it come through the xHCI tree?

I'll take it in my driver-core tree separate, as the others don't depend
on this one, right?

greg k-h

Re: [PATCH 01/20] drivers_base: platform: use always ->name for uevent

[Sebastian Andrzej Siewior]

* Greg KH | 2011-08-22 14:51:51 [-0700]:

>> Greg, do you want to take this patch through your driver core tree, or
>> would you prefer to have it come through the xHCI tree?
>
>I'll take it in my driver-core tree separate, as the others don't depend
>on this one, right?

Should the xhci series hit Linus' tree before your driver-core than
rmmod of the xhci-pci driver will lead to a crash.

>greg k-h

Sebastian

Re: [PATCH 01/20] drivers_base: platform: use always ->name for uevent

[Greg KH]

On Tue, Aug 23, 2011 at 11:50:36AM +0200, Sebastian Andrzej Siewior wrote:
> * Greg KH | 2011-08-22 14:51:51 [-0700]:
> 
> >> Greg, do you want to take this patch through your driver core tree, or
> >> would you prefer to have it come through the xHCI tree?
> >
> >I'll take it in my driver-core tree separate, as the others don't depend
> >on this one, right?
> 
> Should the xhci series hit Linus' tree before your driver-core than
> rmmod of the xhci-pci driver will lead to a crash.

That's ok, just don't do that :)

And you can tell me to merge stuff with Linus after one of my other
trees is applied, I can do that as well.

greg k-h

Re: [PATCH 01/20] drivers_base: platform: use always ->name for uevent

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

Hi,

On Mon, Aug 15, 2011 at 04:51:22PM +0200, Sebastian Andrzej Siewior wrote:
> If id_entry is available then it is used. However if we remove first the
> driver followed by the device, then the id_entry is pointing to driver's
> memory which is long gone.
> Since id->name and plat->name are equal there is no point in
> distinguishing them.
> 
> Cc: Greg Kroah-Hartman <gregkh@suse.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  drivers/base/platform.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 0cad9c7..cd71575 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -614,7 +614,7 @@ static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
>  		return rc;
>  
>  	add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX,
> -		(pdev->id_entry) ? pdev->id_entry->name : pdev->name);
> +			pdev->name);
>  	return 0;
>  }
>  

Just a gentle reminder on this patch. Greg, has this one been queued to
your drivers-core tree ? Should it go on -rc or now it's already too
late and going on merge window ?

thanks

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [PATCH 01/20] drivers_base: platform: use always ->name for uevent

[Greg KH]

On Fri, Sep 30, 2011 at 04:29:16PM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Aug 15, 2011 at 04:51:22PM +0200, Sebastian Andrzej Siewior wrote:
> > If id_entry is available then it is used. However if we remove first the
> > driver followed by the device, then the id_entry is pointing to driver's
> > memory which is long gone.
> > Since id->name and plat->name are equal there is no point in
> > distinguishing them.
> > 
> > Cc: Greg Kroah-Hartman <gregkh@suse.de>
> > Cc: Grant Likely <grant.likely@secretlab.ca>
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > ---
> >  drivers/base/platform.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index 0cad9c7..cd71575 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -614,7 +614,7 @@ static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
> >  		return rc;
> >  
> >  	add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX,
> > -		(pdev->id_entry) ? pdev->id_entry->name : pdev->name);
> > +			pdev->name);
> >  	return 0;
> >  }
> >  
> 
> Just a gentle reminder on this patch. Greg, has this one been queued to
> your drivers-core tree ? Should it go on -rc or now it's already too
> late and going on merge window ?

It's been in my drivers-core tree for a while, and I didn't think it was
needed for 3.1, as it didn't solve an existing bug, did it?

It's queued for 3.2, does it need to get into 3.1-stable?  If so, I can
do that.

thanks,

greg k-h

Re: [PATCH 01/20] drivers_base: platform: use always ->name for uevent

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

Hi,

On Fri, Sep 30, 2011 at 10:09:14AM -0700, Greg KH wrote:
> On Fri, Sep 30, 2011 at 04:29:16PM +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Aug 15, 2011 at 04:51:22PM +0200, Sebastian Andrzej Siewior wrote:
> > > If id_entry is available then it is used. However if we remove first the
> > > driver followed by the device, then the id_entry is pointing to driver's
> > > memory which is long gone.
> > > Since id->name and plat->name are equal there is no point in
> > > distinguishing them.
> > > 
> > > Cc: Greg Kroah-Hartman <gregkh@suse.de>
> > > Cc: Grant Likely <grant.likely@secretlab.ca>
> > > Cc: linux-kernel@vger.kernel.org
> > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > > ---
> > >  drivers/base/platform.c |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > > index 0cad9c7..cd71575 100644
> > > --- a/drivers/base/platform.c
> > > +++ b/drivers/base/platform.c
> > > @@ -614,7 +614,7 @@ static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
> > >  		return rc;
> > >  
> > >  	add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX,
> > > -		(pdev->id_entry) ? pdev->id_entry->name : pdev->name);
> > > +			pdev->name);
> > >  	return 0;
> > >  }
> > >  
> > 
> > Just a gentle reminder on this patch. Greg, has this one been queued to
> > your drivers-core tree ? Should it go on -rc or now it's already too
> > late and going on merge window ?
> 
> It's been in my drivers-core tree for a while, and I didn't think it was
> needed for 3.1, as it didn't solve an existing bug, did it?
> 
> It's queued for 3.2, does it need to get into 3.1-stable?  If so, I can
> do that.

I don't think it's needed. Just make sure drivers-core is merged before
your USB tree :-)

thanks

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [PATCH 01/20] drivers_base: platform: use always ->name for uevent

[Greg KH]

On Fri, Sep 30, 2011 at 08:40:02PM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Sep 30, 2011 at 10:09:14AM -0700, Greg KH wrote:
> > On Fri, Sep 30, 2011 at 04:29:16PM +0300, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Mon, Aug 15, 2011 at 04:51:22PM +0200, Sebastian Andrzej Siewior wrote:
> > > > If id_entry is available then it is used. However if we remove first the
> > > > driver followed by the device, then the id_entry is pointing to driver's
> > > > memory which is long gone.
> > > > Since id->name and plat->name are equal there is no point in
> > > > distinguishing them.
> > > > 
> > > > Cc: Greg Kroah-Hartman <gregkh@suse.de>
> > > > Cc: Grant Likely <grant.likely@secretlab.ca>
> > > > Cc: linux-kernel@vger.kernel.org
> > > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > > > ---
> > > >  drivers/base/platform.c |    2 +-
> > > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > > > index 0cad9c7..cd71575 100644
> > > > --- a/drivers/base/platform.c
> > > > +++ b/drivers/base/platform.c
> > > > @@ -614,7 +614,7 @@ static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
> > > >  		return rc;
> > > >  
> > > >  	add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX,
> > > > -		(pdev->id_entry) ? pdev->id_entry->name : pdev->name);
> > > > +			pdev->name);
> > > >  	return 0;
> > > >  }
> > > >  
> > > 
> > > Just a gentle reminder on this patch. Greg, has this one been queued to
> > > your drivers-core tree ? Should it go on -rc or now it's already too
> > > late and going on merge window ?
> > 
> > It's been in my drivers-core tree for a while, and I didn't think it was
> > needed for 3.1, as it didn't solve an existing bug, did it?
> > 
> > It's queued for 3.2, does it need to get into 3.1-stable?  If so, I can
> > do that.
> 
> I don't think it's needed. Just make sure drivers-core is merged before
> your USB tree :-)

Ok, will do, I forgot about that restriction, thanks for reminding me.

greg k-h