linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: 2.6.24 breaks BIOS updates on all Dell machines
       [not found] <20080129063244.GA19076@humbolt.us.dell.com>
@ 2008-01-29  6:44 ` Greg KH
  0 siblings, 0 replies; 11+ messages in thread
From: Greg KH @ 2008-01-29  6:44 UTC (permalink / raw)
  To: Michael E Brown
  Cc: Jos?? Luis Tall??n, Douglas_Warzecha, Abhay_Salunke,
	linux-kernel, matt_domsch, marcel

On Tue, Jan 29, 2008 at 12:32:44AM -0600, Michael E Brown wrote:
> BIOS updates are broken on all Dell systems due to Commit
> 109f0e93b6b728f03c1eb4af02bc25d71b646c59, which is now in 2.6.24.
> 
>   static inline void fw_setup_device_id(struct device *f_dev, struct
> device *dev)
>   {
> -       /* XXX warning we should watch out for name collisions */
> -       strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
> +       snprintf(f_dev->bus_id, BUS_ID_SIZE, "firmware-%s",
> dev->bus_id);
>  }
> 
> Two programs are broken by this change: 
>     1) dellBiosUpdate, which is part of libsmbios
>     2) All of the Dell Update Packages (DUPs) that are part of Dell
> OpenManage: each BIOS release for each of 3-4 dozen platforms.
> 
> These programs are broken due to the pathname change from
> /sys/class/firmware/dell_rbu/   to
> /sys/class/firmware/firmware-dell_rbu/loading. 
> 
> Realistically, I can fix libsmbios in a couple of weeks, but there is no
> way that we can go back and fix a couple hundred DUP packages for this
> change. If this stays, we are looking at over 6 months before we have an
> officially-available Dell OpenManage that can deal with it, and that
> would be for new BIOS releases only, I suspect.
> 
> Some of the relevant threads from when this was submitted and accepted:
> http://lkml.org/lkml/2005/5/23/73
> http://lkml.org/lkml/2005/5/23/62
> 
> Due to the extremely large and disruptive nature of this bug, it would
> be nice to get a 2.6.24.1 with this patch reverted.
> 
> I have copied the relevant developers at Dell who maintain this driver.
> Please preserve the cc: list when replying.

Fair enough, I have no problem reverting this.

Anyone want to keep it in?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
       [not found] <E9909A75A543064DB66E55B8E3BE41EC5FD218@ausx3mps307.aus.amer.dell.com>
@ 2008-01-29 14:59 ` Markus Rechberger
  2008-01-29 18:41   ` Greg KH
  2008-01-29 19:04   ` FW: " Sytse Wielinga
  0 siblings, 2 replies; 11+ messages in thread
From: Markus Rechberger @ 2008-01-29 14:59 UTC (permalink / raw)
  To: Matt_Domsch, Jos?? Luis Tall??n, Douglas_Warzecha, Abhay_Salunke,
	linux-kernel, matt_domsch, Michael E Brown, Greg KH,
	Jean Delvare

Matt_Domsch@Dell.com wrote:
> Markus, I see you were accidentally left off the cc: list on this bug.
> The change was yours, so I suspect you'll have an opinion to share with
> LKML.
>
> Thanks,
> Matt
>
> --
> Matt Domsch
> Linux Technology Strategist, Dell Office of the CTO
> linux.dell.com & www.dell.com/linux
>
> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de] 
> Sent: Tuesday, January 29, 2008 12:44 AM
> To: Brown, Michael E
> Cc: Jos?? Luis Tall??n; Warzecha, Douglas; Salunke, Abhay;
> linux-kernel@vger.kernel.org; Domsch, Matt; marcel@holtmann.org
> Subject: Re: 2.6.24 breaks BIOS updates on all Dell machines
>
> On Tue, Jan 29, 2008 at 12:32:44AM -0600, Michael E Brown wrote:
>   
>> BIOS updates are broken on all Dell systems due to Commit
>> 109f0e93b6b728f03c1eb4af02bc25d71b646c59, which is now in 2.6.24.
>>
>>   static inline void fw_setup_device_id(struct device *f_dev, struct
>> device *dev)
>>   {
>> -       /* XXX warning we should watch out for name collisions */
>> -       strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
>> +       snprintf(f_dev->bus_id, BUS_ID_SIZE, "firmware-%s",
>> dev->bus_id);
>>  }
>>
>> Two programs are broken by this change: 
>>     1) dellBiosUpdate, which is part of libsmbios
>>     2) All of the Dell Update Packages (DUPs) that are part of Dell
>> OpenManage: each BIOS release for each of 3-4 dozen platforms.
>>
>> These programs are broken due to the pathname change from
>> /sys/class/firmware/dell_rbu/   to
>> /sys/class/firmware/firmware-dell_rbu/loading. 
>>
>> Realistically, I can fix libsmbios in a couple of weeks, but there is
>>     
> no
>   
>> way that we can go back and fix a couple hundred DUP packages for this
>> change. If this stays, we are looking at over 6 months before we have
>>     
> an
>   
>> officially-available Dell OpenManage that can deal with it, and that
>> would be for new BIOS releases only, I suspect.
>>
>> Some of the relevant threads from when this was submitted and
>>     
> accepted:
>   
>> http://lkml.org/lkml/2005/5/23/73
>> http://lkml.org/lkml/2005/5/23/62
>>
>> Due to the extremely large and disruptive nature of this bug, it would
>> be nice to get a 2.6.24.1 with this patch reverted.
>>
>> I have copied the relevant developers at Dell who maintain this
>>     
> driver.
>   
>> Please preserve the cc: list when replying.
>>     
>
> Fair enough, I have no problem reverting this.
>
> Anyone want to keep it in?
>
>   
Hi Greg,

reverting this breaks support for several media (DVB/V4L) devices. I 
would have to look up some bugreports the same name collision happened 
with several different drivers.
There was a comment in the fw code to watch out for name collisions 
earlier already, so it needs a fix somewhere.

Here's some history:
http://mcentral.de/wiki/index.php5/Bugtracker#i2c_dev_problem

Markus



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
  2008-01-29 14:59 ` FW: 2.6.24 breaks BIOS updates on all Dell machines Markus Rechberger
@ 2008-01-29 18:41   ` Greg KH
  2008-01-29 22:15     ` Jean Delvare
  2008-01-29 19:04   ` FW: " Sytse Wielinga
  1 sibling, 1 reply; 11+ messages in thread
From: Greg KH @ 2008-01-29 18:41 UTC (permalink / raw)
  To: Markus Rechberger
  Cc: Matt_Domsch, Jos?? Luis Tall??n, Douglas_Warzecha, Abhay_Salunke,
	linux-kernel, Michael E Brown, Greg KH, Jean Delvare

On Tue, Jan 29, 2008 at 03:59:44PM +0100, Markus Rechberger wrote:
>> -----Original Message-----
>> From: Greg KH [mailto:gregkh@suse.de] Sent: Tuesday, January 29, 2008 
>> 12:44 AM
>> To: Brown, Michael E
>> Cc: Jos?? Luis Tall??n; Warzecha, Douglas; Salunke, Abhay;
>> linux-kernel@vger.kernel.org; Domsch, Matt; marcel@holtmann.org
>> Subject: Re: 2.6.24 breaks BIOS updates on all Dell machines
>>
>> On Tue, Jan 29, 2008 at 12:32:44AM -0600, Michael E Brown wrote:
>>   
>>> BIOS updates are broken on all Dell systems due to Commit
>>> 109f0e93b6b728f03c1eb4af02bc25d71b646c59, which is now in 2.6.24.
>>>
>>>   static inline void fw_setup_device_id(struct device *f_dev, struct
>>> device *dev)
>>>   {
>>> -       /* XXX warning we should watch out for name collisions */
>>> -       strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
>>> +       snprintf(f_dev->bus_id, BUS_ID_SIZE, "firmware-%s",
>>> dev->bus_id);
>>>  }
>>>
>>> Two programs are broken by this change:     1) dellBiosUpdate, which is 
>>> part of libsmbios
>>>     2) All of the Dell Update Packages (DUPs) that are part of Dell
>>> OpenManage: each BIOS release for each of 3-4 dozen platforms.
>>>
>>> These programs are broken due to the pathname change from
>>> /sys/class/firmware/dell_rbu/   to
>>> /sys/class/firmware/firmware-dell_rbu/loading. 
>>> Realistically, I can fix libsmbios in a couple of weeks, but there is
>>>     
>> no
>>   
>>> way that we can go back and fix a couple hundred DUP packages for this
>>> change. If this stays, we are looking at over 6 months before we have
>>>     
>> an
>>   
>>> officially-available Dell OpenManage that can deal with it, and that
>>> would be for new BIOS releases only, I suspect.
>>>
>>> Some of the relevant threads from when this was submitted and
>>>     
>> accepted:
>>   
>>> http://lkml.org/lkml/2005/5/23/73
>>> http://lkml.org/lkml/2005/5/23/62
>>>
>>> Due to the extremely large and disruptive nature of this bug, it would
>>> be nice to get a 2.6.24.1 with this patch reverted.
>>>
>>> I have copied the relevant developers at Dell who maintain this
>>>     
>> driver.
>>   
>>> Please preserve the cc: list when replying.
>>>     
>>
>> Fair enough, I have no problem reverting this.
>>
>> Anyone want to keep it in?
>>
>>   
> Hi Greg,
>
> reverting this breaks support for several media (DVB/V4L) devices. I would 
> have to look up some bugreports the same name collision happened with 
> several different drivers.
> There was a comment in the fw code to watch out for name collisions earlier 
> already, so it needs a fix somewhere.
>
> Here's some history:
> http://mcentral.de/wiki/index.php5/Bugtracker#i2c_dev_problem

Yes, but we can't break existing code that has been working for quite
some time.  That's just unacceptable.  The i2c devices can fix things by
changing their module names so this collision doesn't happen :)

So, I'm all for reverting this patch.

And then, feel free to revisit the problem by proposing something that
doesn't break existing users of the interface.

Michael, can you please send me a patch, and CC: stable@kernel.org so we
make sure to get this into 2.6.24.1?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
  2008-01-29 14:59 ` FW: 2.6.24 breaks BIOS updates on all Dell machines Markus Rechberger
  2008-01-29 18:41   ` Greg KH
@ 2008-01-29 19:04   ` Sytse Wielinga
       [not found]     ` <20080129190924.GB8786@humbolt.us.dell.com>
  1 sibling, 1 reply; 11+ messages in thread
From: Sytse Wielinga @ 2008-01-29 19:04 UTC (permalink / raw)
  To: Markus Rechberger
  Cc: Matt_Domsch, Jos?? Luis Tall??n, Douglas_Warzecha, Abhay_Salunke,
	linux-kernel, Michael E Brown, Greg KH, Jean Delvare

On Tue, Jan 29, 2008 at 03:59:44PM +0100, Markus Rechberger wrote:
(quote reformatted)
> On Mon, Jan 28, 2008 at 10:44:15PM -0800, Greg KH wrote:
> > On Tue, Jan 29, 2008 at 12:32:44AM -0600, Michael E Brown wrote:
> > > BIOS updates are broken on all Dell systems due to Commit
> > > 109f0e93b6b728f03c1eb4af02bc25d71b646c59, which is now in 2.6.24.
> > > 
> > >   static inline void fw_setup_device_id(struct device *f_dev, struct
> > > device *dev)
> > >   {
> > > -       /* XXX warning we should watch out for name collisions */
> > > -       strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
> > > +       snprintf(f_dev->bus_id, BUS_ID_SIZE, "firmware-%s",
> > > dev->bus_id);
> > >  }
> > > 
> > > Two programs are broken by this change: 
> > >     1) dellBiosUpdate, which is part of libsmbios
> > >     2) All of the Dell Update Packages (DUPs) that are part of Dell
> > > OpenManage: each BIOS release for each of 3-4 dozen platforms.
> > > 
> > > These programs are broken due to the pathname change from
> > > /sys/class/firmware/dell_rbu/   to
> > > /sys/class/firmware/firmware-dell_rbu/loading. 
> > > 
> > > Realistically, I can fix libsmbios in a couple of weeks, but there is no
> > > way that we can go back and fix a couple hundred DUP packages for this
> > > change. If this stays, we are looking at over 6 months before we have an
> > > officially-available Dell OpenManage that can deal with it, and that
> > > would be for new BIOS releases only, I suspect.
> > > 
> > > Some of the relevant threads from when this was submitted and accepted:
> > > http://lkml.org/lkml/2005/5/23/73
> > > http://lkml.org/lkml/2005/5/23/62
> > > 
> > > Due to the extremely large and disruptive nature of this bug, it would
> > > be nice to get a 2.6.24.1 with this patch reverted.
> > > 
> > > I have copied the relevant developers at Dell who maintain this driver.
> > > Please preserve the cc: list when replying.
> > 
> > Fair enough, I have no problem reverting this.
> > 
> > Anyone want to keep it in?
>
> Hi Greg,
> 
> reverting this breaks support for several media (DVB/V4L) devices. I 
> would have to look up some bugreports the same name collision happened 
> with several different drivers.
> There was a comment in the fw code to watch out for name collisions 
> earlier already, so it needs a fix somewhere.
> 
> Here's some history:
> http://mcentral.de/wiki/index.php5/Bugtracker#i2c_dev_problem

What about creating symlinks with the old device names? That shouldn't give
rise to any collisions, as it only works in the /sys/class/firmware/ namespace
(correct me if I'm wrong, I haven't actually taken the time to investigate the
problem properly and have no experience with the firmware driver).

I've created the simple patch below. I have no idea if it actually works,
though, as I don't appear to have any hardware for which a linux driver
supports firmware loading. Please comment.

Oh, and I almost forgot to ask about __FUNCTION__, which is gcc-specific;
wouldn't it be a good idea to simply replace all occurrences in the kernel
source with __func__?

Sytse

---
 drivers/base/Kconfig          |   11 +++++++++++
 drivers/base/firmware_class.c |    7 +++++++
 2 files changed, 18 insertions(+)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index d7da109..d0a9cf6 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -34,6 +34,17 @@ config FW_LOADER
 	  require userspace firmware loading support, but a module built outside
 	  the kernel tree does.
 
+config FW_LOADER_SYSFS_COMPAT
+	bool "Deprecated /sys/class/firmware/ folders"
+	depends on FW_LOADER
+	default y
+	help
+	  Folders in /sys/class/firmware/ have been prefixed with 'firmware-'
+	  to prevent name collisions. Enable this option to create symlinks
+	  for backward compatibility.
+
+	  If unsure, say Y.
+
 config DEBUG_DRIVER
 	bool "Driver Core verbose debug messages"
 	depends on DEBUG_KERNEL
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 0295855..f8aba6c 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -330,6 +330,13 @@ static int fw_register_device(struct device **dev_p, const char *fw_name,
 		       __FUNCTION__);
 		goto error_kfree;
 	}
+
+#ifdef CONFIG_FW_LOADER_SYSFS_COMPAT
+	if (sysfs_create_link(&firmware_class.subsys.kobj, &f_dev->kobj, device->bus_id))
+		printk(KERN_WARNING "%s: sysfs_create_link failed for %s\n",
+			   __FUNCTION__, device->bus_id);
+#endif
+
 	*dev_p = f_dev;
 	return 0;
 

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
  2008-01-29 18:41   ` Greg KH
@ 2008-01-29 22:15     ` Jean Delvare
  2008-02-05  6:45       ` Greg KH
  0 siblings, 1 reply; 11+ messages in thread
From: Jean Delvare @ 2008-01-29 22:15 UTC (permalink / raw)
  To: greg, markus.rechberger
  Cc: Matt_Domsch, Jos?? Luis Tall??n, Douglas_Warzecha, Abhay_Salunke,
	linux-kernel, Michael E Brown, Greg KH


Hi Greg,

Le 29/1/2008, "Greg KH" <greg@kroah.com> a écrit:

>On Tue, Jan 29, 2008 at 03:59:44PM +0100, Markus Rechberger wrote:
>>> -----Original Message-----
>>> (...)
>>> On Tue, Jan 29, 2008 at 12:32:44AM -0600, Michael E Brown wrote:
>>>
>>>> BIOS updates are broken on all Dell systems due to Commit
>>>> 109f0e93b6b728f03c1eb4af02bc25d71b646c59, which is now in 2.6.24.
>>>>
>>>>   static inline void fw_setup_device_id(struct device *f_dev, struct
>>>> device *dev)
>>>>   {
>>>> -       /* XXX warning we should watch out for name collisions */
>>>> -       strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
>>>> +       snprintf(f_dev->bus_id, BUS_ID_SIZE, "firmware-%s",
>>>> dev->bus_id);
>>>>  }
>>>>
>> reverting this breaks support for several media (DVB/V4L) devices. I would
>> have to look up some bugreports the same name collision happened with
>> several different drivers.
>> There was a comment in the fw code to watch out for name collisions earlier
>> already, so it needs a fix somewhere.
>>
>> Here's some history:
>> http://mcentral.de/wiki/index.php5/Bugtracker#i2c_dev_problem
>
>Yes, but we can't break existing code that has been working for quite
>some time.  That's just unacceptable.  The i2c devices can fix things by
>changing their module names so this collision doesn't happen :)

Actually, the i2c-dev driver was there before the firmware class, so if
anything, the firmware class broke something that was working before. It
just happens that nobody really needs to poke at the i2c-dev sysfs
directories, while user-space tools need to access firmware sysfs
directories. And most people do not need i2c-dev at all.

Also note that the way firmware directories were originally named (by the
name of the device itself!) wasn't exactly smart and was calling for
confusion if not trouble IMHO.

>So, I'm all for reverting this patch.
>
>And then, feel free to revisit the problem by proposing something that
>doesn't break existing users of the interface.

I'm a bit confused. It seems to me that the "class devices" are named
differently in recent kernels. The i2c-dev class devices were originally
showing as i2c-%d in their parent device directories (causing the
collision), and now show as i2c-dev:i2c-%d. This suggests that the
collision the patch above was trying to solve is in fact already fixed
(by prefixing the device name with the class name). The good news is
that it would mean that we can just revert the patch in question...

But quite frankly I'm not really sure, the class devices look different
on every kernel I looked at, depending on the version and whether
CONFIG_SYSFS_DEPRECATED is set or not.

--
Jean Delvare

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.6.24 breaks BIOS updates on all Dell machines
       [not found]     ` <20080129190924.GB8786@humbolt.us.dell.com>
@ 2008-02-03 14:02       ` Jean Delvare
       [not found]         ` <20080204155834.GA32437@humbolt.us.dell.com>
  0 siblings, 1 reply; 11+ messages in thread
From: Jean Delvare @ 2008-02-03 14:02 UTC (permalink / raw)
  To: Michael E Brown
  Cc: Markus Rechberger, Matt_Domsch, Jos?? Luis Tall??n,
	Douglas_Warzecha, Abhay_Salunke, linux-kernel, Greg KH

Hi Michael,

On Tue, 29 Jan 2008 13:09:25 -0600, Michael E Brown wrote:
> On Tue, Jan 29, 2008 at 08:04:17PM +0100, Sytse Wielinga wrote:
> > I've created the simple patch below. I have no idea if it actually works,
> > though, as I don't appear to have any hardware for which a linux driver
> > supports firmware loading. Please comment.
> 
> You can test this rather easily. Simply modprobe the "dell_rbu" driver.
> You dont need any special hardware, it should load on any machine. After
> you have loaded it, check the sysfs path to see if it has the correct
> path (or some symlink thereof):
> 
> GOOD: /sys/class/firmware/dell_rbu/   
> BAD : /sys/class/firmware/firmware-dell_rbu/loading

This doesn't actually work for me. Loading the dell_rbu driver on a
non-Dell system doesn't create anything under /sys/class/firmware.

-- 
Jean Delvare

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
  2008-01-29 22:15     ` Jean Delvare
@ 2008-02-05  6:45       ` Greg KH
  2008-02-05 20:16         ` Jean Delvare
  0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2008-02-05  6:45 UTC (permalink / raw)
  To: Jean Delvare
  Cc: greg, markus.rechberger, Matt_Domsch, Jos?? Luis Tall??n,
	Douglas_Warzecha, Abhay_Salunke, linux-kernel, Michael E Brown

On Tue, Jan 29, 2008 at 11:15:22PM +0100, Jean Delvare wrote:
> >So, I'm all for reverting this patch.
> >
> >And then, feel free to revisit the problem by proposing something that
> >doesn't break existing users of the interface.
> 
> I'm a bit confused. It seems to me that the "class devices" are named
> differently in recent kernels. The i2c-dev class devices were originally
> showing as i2c-%d in their parent device directories (causing the
> collision), and now show as i2c-dev:i2c-%d. This suggests that the
> collision the patch above was trying to solve is in fact already fixed
> (by prefixing the device name with the class name). The good news is
> that it would mean that we can just revert the patch in question...
> 
> But quite frankly I'm not really sure, the class devices look different
> on every kernel I looked at, depending on the version and whether
> CONFIG_SYSFS_DEPRECATED is set or not.

THe naming is different depending on that sysfs variable, yes.  But it
should be consistant other than that.  If not, please let me know.

And yes, we did have to add the ":" a while ago to handle the namespace
collisions we were having.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.6.24 breaks BIOS updates on all Dell machines
       [not found]         ` <20080204155834.GA32437@humbolt.us.dell.com>
@ 2008-02-05 16:25           ` Jean Delvare
  0 siblings, 0 replies; 11+ messages in thread
From: Jean Delvare @ 2008-02-05 16:25 UTC (permalink / raw)
  To: Michael E Brown
  Cc: Markus Rechberger, Matt_Domsch, Jos?? Luis Tall??n,
	Douglas_Warzecha, Abhay_Salunke, linux-kernel, Greg KH

On Mon, 4 Feb 2008 09:58:35 -0600, Michael E Brown wrote:
> On Sun, Feb 03, 2008 at 03:02:38PM +0100, Jean Delvare wrote:
> > Hi Michael,
> > 
> > On Tue, 29 Jan 2008 13:09:25 -0600, Michael E Brown wrote:
> > > On Tue, Jan 29, 2008 at 08:04:17PM +0100, Sytse Wielinga wrote:
> > > > I've created the simple patch below. I have no idea if it actually works,
> > > > though, as I don't appear to have any hardware for which a linux driver
> > > > supports firmware loading. Please comment.
> > > 
> > > You can test this rather easily. Simply modprobe the "dell_rbu" driver.
> > > You dont need any special hardware, it should load on any machine. After
> > > you have loaded it, check the sysfs path to see if it has the correct
> > > path (or some symlink thereof):
> > > 
> > > GOOD: /sys/class/firmware/dell_rbu/   
> > > BAD : /sys/class/firmware/firmware-dell_rbu/loading
> > 
> > This doesn't actually work for me. Loading the dell_rbu driver on a
> > non-Dell system doesn't create anything under /sys/class/firmware.
> 
> You have to initialize the driver first before that file appears.
> 
> [root@localhost ~]# modprobe dell_rbu
> [root@localhost ~]# cd /sys/devices/platform/dell_rbu/
> [root@localhost dell_rbu]# ll /sys/class/firmware/dell_rbu/loading 
> ls: cannot access /sys/class/firmware/dell_rbu/loading: No such file or
> directory
> [root@localhost dell_rbu]# echo -n -e 'init\0' > image_type 
> [root@localhost dell_rbu]# ll /sys/class/firmware/dell_rbu/loading 
> -rw-r--r-- 1 root root 4096 2008-02-04 09:57
> /sys/class/firmware/dell_rbu/loading

Ah, OK, thanks for the hint, it works now.

-- 
Jean Delvare

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.6.24 breaks BIOS updates on all Dell machines
  2008-02-05  6:45       ` Greg KH
@ 2008-02-05 20:16         ` Jean Delvare
  2008-02-05 23:44           ` Greg KH
  0 siblings, 1 reply; 11+ messages in thread
From: Jean Delvare @ 2008-02-05 20:16 UTC (permalink / raw)
  To: Greg KH
  Cc: markus.rechberger, Matt_Domsch, Jos?? Luis Tall??n,
	Douglas_Warzecha, Abhay_Salunke, linux-kernel, Michael E Brown,
	Kay Sievers

On Mon, 4 Feb 2008 22:45:47 -0800, Greg KH wrote:
> On Tue, Jan 29, 2008 at 11:15:22PM +0100, Jean Delvare wrote:
> > I'm a bit confused. It seems to me that the "class devices" are named
> > differently in recent kernels. The i2c-dev class devices were originally
> > showing as i2c-%d in their parent device directories (causing the
> > collision), and now show as i2c-dev:i2c-%d. This suggests that the
> > collision the patch above was trying to solve is in fact already fixed
> > (by prefixing the device name with the class name). The good news is
> > that it would mean that we can just revert the patch in question...
> > 
> > But quite frankly I'm not really sure, the class devices look different
> > on every kernel I looked at, depending on the version and whether
> > CONFIG_SYSFS_DEPRECATED is set or not.
> 
> THe naming is different depending on that sysfs variable, yes.  But it
> should be consistant other than that.  If not, please let me know.
> 
> And yes, we did have to add the ":" a while ago to handle the namespace
> collisions we were having.

OK, I am officially confused now.

This is 2.6.24, CONFIG_SYSFS_DEPRECATED=y:

# ls -l /sys/class/i2c-adapter/i2c-0
total 0
lrwxrwxrwx 1 root root    0 fév  5 18:07 device -> ../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
lrwxrwxrwx 1 root root    0 fév  5 18:17 i2c-dev:i2c-0 -> ../../../class/i2c-dev/i2c-0
-r--r--r-- 1 root root 4096 fév  5 18:07 name
drwxr-xr-x 2 root root    0 fév  5 18:17 power
lrwxrwxrwx 1 root root    0 fév  5 18:07 subsystem -> ../../../class/i2c-adapter
-rw-r--r-- 1 root root 4096 fév  5  2008 uevent

2.6.24 rebuilt without CONFIG_SYSFS_DEPRECATED:

# ls -l /sys/class/i2c-adapter/i2c-0/
total 0
lrwxrwxrwx 1 root root    0 fév  5 18:42 device -> ../../../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
drwxr-xr-x 3 root root    0 fév  5 18:42 i2c-0
-r--r--r-- 1 root root 4096 fév  5 18:31 name
drwxr-xr-x 2 root root    0 fév  5 18:42 power
lrwxrwxrwx 1 root root    0 fév  5 18:31 subsystem -> ../../../../../../class/i2c-adapter
-rw-r--r-- 1 root root 4096 fév  5  2008 uevent

The latter corresponds to what older kernels had ("i2c-0"). This means
that enabling CONFIG_SYSFS_DEPRECATED causes the i2c-dev class device
names to change. Isn't it supposed to be exactly the other way around,
i.e. enabling CONFIG_SYSFS_DEPRECATED should preserve the names as they
were in older kernels?

If the "$class:" prefix was added to prevent collisions (and this
sounds like a good idea), then why wasn't it added in the regular case
(CONFIG_SYSFS_DEPRECATED=n) as well?

Someone please clarify the situation.

Thanks,
-- 
Jean Delvare

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.6.24 breaks BIOS updates on all Dell machines
  2008-02-05 20:16         ` Jean Delvare
@ 2008-02-05 23:44           ` Greg KH
  2008-02-06 13:20             ` Jean Delvare
  0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2008-02-05 23:44 UTC (permalink / raw)
  To: Jean Delvare
  Cc: markus.rechberger, Matt_Domsch, Jos?? Luis Tall??n,
	Douglas_Warzecha, Abhay_Salunke, linux-kernel, Michael E Brown,
	Kay Sievers

On Tue, Feb 05, 2008 at 09:16:42PM +0100, Jean Delvare wrote:
> On Mon, 4 Feb 2008 22:45:47 -0800, Greg KH wrote:
> > On Tue, Jan 29, 2008 at 11:15:22PM +0100, Jean Delvare wrote:
> > > I'm a bit confused. It seems to me that the "class devices" are named
> > > differently in recent kernels. The i2c-dev class devices were originally
> > > showing as i2c-%d in their parent device directories (causing the
> > > collision), and now show as i2c-dev:i2c-%d. This suggests that the
> > > collision the patch above was trying to solve is in fact already fixed
> > > (by prefixing the device name with the class name). The good news is
> > > that it would mean that we can just revert the patch in question...
> > > 
> > > But quite frankly I'm not really sure, the class devices look different
> > > on every kernel I looked at, depending on the version and whether
> > > CONFIG_SYSFS_DEPRECATED is set or not.
> > 
> > THe naming is different depending on that sysfs variable, yes.  But it
> > should be consistant other than that.  If not, please let me know.
> > 
> > And yes, we did have to add the ":" a while ago to handle the namespace
> > collisions we were having.
> 
> OK, I am officially confused now.

Heh, it is a mess :)

> This is 2.6.24, CONFIG_SYSFS_DEPRECATED=y:
> 
> # ls -l /sys/class/i2c-adapter/i2c-0
> total 0
> lrwxrwxrwx 1 root root    0 f?v  5 18:07 device -> ../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
> lrwxrwxrwx 1 root root    0 f?v  5 18:17 i2c-dev:i2c-0 -> ../../../class/i2c-dev/i2c-0
> -r--r--r-- 1 root root 4096 f?v  5 18:07 name
> drwxr-xr-x 2 root root    0 f?v  5 18:17 power
> lrwxrwxrwx 1 root root    0 f?v  5 18:07 subsystem -> ../../../class/i2c-adapter
> -rw-r--r-- 1 root root 4096 f?v  5  2008 uevent
> 
> 2.6.24 rebuilt without CONFIG_SYSFS_DEPRECATED:
> 
> # ls -l /sys/class/i2c-adapter/i2c-0/
> total 0
> lrwxrwxrwx 1 root root    0 f?v  5 18:42 device -> ../../../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
> drwxr-xr-x 3 root root    0 f?v  5 18:42 i2c-0
> -r--r--r-- 1 root root 4096 f?v  5 18:31 name
> drwxr-xr-x 2 root root    0 f?v  5 18:42 power
> lrwxrwxrwx 1 root root    0 f?v  5 18:31 subsystem -> ../../../../../../class/i2c-adapter
> -rw-r--r-- 1 root root 4096 f?v  5  2008 uevent
> 
> The latter corresponds to what older kernels had ("i2c-0"). This means
> that enabling CONFIG_SYSFS_DEPRECATED causes the i2c-dev class device
> names to change.

Yes.  Well, no, not really.  The class device names are the same, it's
just that it is a symlink in the DEPRECATED=Y name and a real directory
in the =N case.

> Isn't it supposed to be exactly the other way around, i.e. enabling
> CONFIG_SYSFS_DEPRECATED should preserve the names as they were in
> older kernels?

The real name is the same (look above, it's really called "i2c-0" in
both cases, just that the symlink in the =Y case has to have a different
name to handle the fact that there could be duplicate names in this
format.

Does that help?

It's really to keep older programs still work properly.  The =N case is
what you should pay attention to for all modern distros.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.6.24 breaks BIOS updates on all Dell machines
  2008-02-05 23:44           ` Greg KH
@ 2008-02-06 13:20             ` Jean Delvare
  0 siblings, 0 replies; 11+ messages in thread
From: Jean Delvare @ 2008-02-06 13:20 UTC (permalink / raw)
  To: Greg KH
  Cc: markus.rechberger, Matt_Domsch, Jos?? Luis Tall??n,
	Douglas_Warzecha, Abhay_Salunke, linux-kernel, Michael E Brown,
	Kay Sievers

On Tue, 5 Feb 2008 15:44:13 -0800, Greg KH wrote:
> On Tue, Feb 05, 2008 at 09:16:42PM +0100, Jean Delvare wrote:
> > This is 2.6.24, CONFIG_SYSFS_DEPRECATED=y:
> > 
> > # ls -l /sys/class/i2c-adapter/i2c-0
> > total 0
> > lrwxrwxrwx 1 root root    0 f?v  5 18:07 device -> ../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
> > lrwxrwxrwx 1 root root    0 f?v  5 18:17 i2c-dev:i2c-0 -> ../../../class/i2c-dev/i2c-0
> > -r--r--r-- 1 root root 4096 f?v  5 18:07 name
> > drwxr-xr-x 2 root root    0 f?v  5 18:17 power
> > lrwxrwxrwx 1 root root    0 f?v  5 18:07 subsystem -> ../../../class/i2c-adapter
> > -rw-r--r-- 1 root root 4096 f?v  5  2008 uevent
> > 
> > 2.6.24 rebuilt without CONFIG_SYSFS_DEPRECATED:
> > 
> > # ls -l /sys/class/i2c-adapter/i2c-0/
> > total 0
> > lrwxrwxrwx 1 root root    0 f?v  5 18:42 device -> ../../../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
> > drwxr-xr-x 3 root root    0 f?v  5 18:42 i2c-0
> > -r--r--r-- 1 root root 4096 f?v  5 18:31 name
> > drwxr-xr-x 2 root root    0 f?v  5 18:42 power
> > lrwxrwxrwx 1 root root    0 f?v  5 18:31 subsystem -> ../../../../../../class/i2c-adapter
> > -rw-r--r-- 1 root root 4096 f?v  5  2008 uevent
> > 
> > The latter corresponds to what older kernels had ("i2c-0"). This means
> > that enabling CONFIG_SYSFS_DEPRECATED causes the i2c-dev class device
> > names to change.
> 
> Yes.  Well, no, not really.  The class device names are the same, it's
> just that it is a symlink in the DEPRECATED=Y name and a real directory
> in the =N case.
>
> > Isn't it supposed to be exactly the other way around, i.e. enabling
> > CONFIG_SYSFS_DEPRECATED should preserve the names as they were in
> > older kernels?
> 
> The real name is the same (look above, it's really called "i2c-0" in
> both cases, just that the symlink in the =Y case has to have a different
> name to handle the fact that there could be duplicate names in this
> format.
> 
> Does that help?

Not really. Why is =Y supposed to be a factor for duplicate names? The
exact same collision can happen in the =N case. This is exactly the
problem Markus and myself tried to address with
109f0e93b6b728f03c1eb4af02bc25d71b646c59. The i2c-dev class names its
class devices i2c-%d, and the firmware class as well (for i2c devices).
If 109f0e93b6b728f03c1eb4af02bc25d71b646c59 is going to be reverted,
then we will see the same collision again, but only for DEPRECATED=N.
That's rather confusing.

To add to the confusion, it seems that, in some cases, the potential
name collision is addressed by inserting a directory (named after the
class name) between the parent device and the class device. For example:

/sys/bus/pci/devices/0000:00:11.0/i2c-adapter/i2c-0

0000:00:11.0 is the PCI device, i2c-0 is the class device and
i2c-adapter is the class name.

So why isn't it done in all cases? This would solve the problem, as the
colliding class devices would finally get their own namespace:

/sys/bus/pci/devices/0000:00:11.0/i2c-adapter/i2c-0/i2c-dev/i2c-0
/sys/bus/pci/devices/0000:00:11.0/i2c-adapter/i2c-0/firmware/i2c-0

> It's really to keep older programs still work properly.  The =N case is
> what you should pay attention to for all modern distros.

Unfortunately the =N case is the one that will break when you revert
109f0e93b6b728f03c1eb4af02bc25d71b646c59.

-- 
Jean Delvare

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2008-02-06 13:20 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <E9909A75A543064DB66E55B8E3BE41EC5FD218@ausx3mps307.aus.amer.dell.com>
2008-01-29 14:59 ` FW: 2.6.24 breaks BIOS updates on all Dell machines Markus Rechberger
2008-01-29 18:41   ` Greg KH
2008-01-29 22:15     ` Jean Delvare
2008-02-05  6:45       ` Greg KH
2008-02-05 20:16         ` Jean Delvare
2008-02-05 23:44           ` Greg KH
2008-02-06 13:20             ` Jean Delvare
2008-01-29 19:04   ` FW: " Sytse Wielinga
     [not found]     ` <20080129190924.GB8786@humbolt.us.dell.com>
2008-02-03 14:02       ` Jean Delvare
     [not found]         ` <20080204155834.GA32437@humbolt.us.dell.com>
2008-02-05 16:25           ` Jean Delvare
     [not found] <20080129063244.GA19076@humbolt.us.dell.com>
2008-01-29  6:44 ` Greg KH

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