Re: 2.6.24 breaks BIOS updates on all Dell machines
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 root0 f?v 5 18:07 device ->
> > ../../../devices/pci:00/:00:01.0/:01:00.0
> > lrwxrwxrwx 1 root root0 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 root0 f?v 5 18:17 power
> > lrwxrwxrwx 1 root root0 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 root0 f?v 5 18:42 device ->
> > ../../../../../../devices/pci:00/:00:01.0/:01:00.0
> > drwxr-xr-x 3 root root0 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 root0 f?v 5 18:42 power
> > lrwxrwxrwx 1 root root0 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/:00:11.0/i2c-adapter/i2c-0
: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/:00:11.0/i2c-adapter/i2c-0/i2c-dev/i2c-0
/sys/bus/pci/devices/: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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 breaks BIOS updates on all Dell machines
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 root0 f?v 5 18:07 device - ../../../devices/pci:00/:00:01.0/:01:00.0 lrwxrwxrwx 1 root root0 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 root0 f?v 5 18:17 power lrwxrwxrwx 1 root root0 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 root0 f?v 5 18:42 device - ../../../../../../devices/pci:00/:00:01.0/:01:00.0 drwxr-xr-x 3 root root0 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 root0 f?v 5 18:42 power lrwxrwxrwx 1 root root0 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/:00:11.0/i2c-adapter/i2c-0 :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/:00:11.0/i2c-adapter/i2c-0/i2c-dev/i2c-0 /sys/bus/pci/devices/: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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 breaks BIOS updates on all Dell machines
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 root0 f?v 5 18:07 device ->
> ../../../devices/pci:00/:00:01.0/:01:00.0
> lrwxrwxrwx 1 root root0 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 root0 f?v 5 18:17 power
> lrwxrwxrwx 1 root root0 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 root0 f?v 5 18:42 device ->
> ../../../../../../devices/pci:00/:00:01.0/:01:00.0
> drwxr-xr-x 3 root root0 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 root0 f?v 5 18:42 power
> lrwxrwxrwx 1 root root0 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 breaks BIOS updates on all Dell machines
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 root0 fév 5 18:07 device ->
../../../devices/pci:00/:00:01.0/:01:00.0
lrwxrwxrwx 1 root root0 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 root0 fév 5 18:17 power
lrwxrwxrwx 1 root root0 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 root0 fév 5 18:42 device ->
../../../../../../devices/pci:00/:00:01.0/:01:00.0
drwxr-xr-x 3 root root0 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 root0 fév 5 18:42 power
lrwxrwxrwx 1 root root0 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 breaks BIOS updates on all Dell machines
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. > > [EMAIL PROTECTED] ~]# modprobe dell_rbu > [EMAIL PROTECTED] ~]# cd /sys/devices/platform/dell_rbu/ > [EMAIL PROTECTED] dell_rbu]# ll /sys/class/firmware/dell_rbu/loading > ls: cannot access /sys/class/firmware/dell_rbu/loading: No such file or > directory > [EMAIL PROTECTED] dell_rbu]# echo -n -e 'init\0' > image_type > [EMAIL PROTECTED] 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 breaks BIOS updates on all Dell machines
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. [EMAIL PROTECTED] ~]# modprobe dell_rbu [EMAIL PROTECTED] ~]# cd /sys/devices/platform/dell_rbu/ [EMAIL PROTECTED] dell_rbu]# ll /sys/class/firmware/dell_rbu/loading ls: cannot access /sys/class/firmware/dell_rbu/loading: No such file or directory [EMAIL PROTECTED] dell_rbu]# echo -n -e 'init\0' image_type [EMAIL PROTECTED] 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 breaks BIOS updates on all Dell machines
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 root0 fév 5 18:07 device - ../../../devices/pci:00/:00:01.0/:01:00.0 lrwxrwxrwx 1 root root0 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 root0 fév 5 18:17 power lrwxrwxrwx 1 root root0 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 root0 fév 5 18:42 device - ../../../../../../devices/pci:00/:00:01.0/:01:00.0 drwxr-xr-x 3 root root0 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 root0 fév 5 18:42 power lrwxrwxrwx 1 root root0 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 breaks BIOS updates on all Dell machines
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 root0 f?v 5 18:07 device - ../../../devices/pci:00/:00:01.0/:01:00.0 lrwxrwxrwx 1 root root0 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 root0 f?v 5 18:17 power lrwxrwxrwx 1 root root0 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 root0 f?v 5 18:42 device - ../../../../../../devices/pci:00/:00:01.0/:01:00.0 drwxr-xr-x 3 root root0 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 root0 f?v 5 18:42 power lrwxrwxrwx 1 root root0 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 breaks BIOS updates on all Dell machines
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 breaks BIOS updates on all Dell machines
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
Hi Greg,
Le 29/1/2008, "Greg KH" <[EMAIL PROTECTED]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
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(_class.subsys.kobj, _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;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
On Tue, Jan 29, 2008 at 03:59:44PM +0100, Markus Rechberger wrote:
>> -Original Message-
>> From: Greg KH [mailto:[EMAIL PROTECTED] 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; [EMAIL PROTECTED]
>> 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: [EMAIL PROTECTED] so we
make sure to get this into 2.6.24.1?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
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; [EMAIL PROTECTED]
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
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; [EMAIL PROTECTED]
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
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;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
On Tue, Jan 29, 2008 at 03:59:44PM +0100, Markus Rechberger wrote:
-Original Message-
From: Greg KH [mailto:[EMAIL PROTECTED] 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; [EMAIL PROTECTED]
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: [EMAIL PROTECTED] so we
make sure to get this into 2.6.24.1?
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
Hi Greg,
Le 29/1/2008, Greg KH [EMAIL PROTECTED] 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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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?
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
