[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 & http://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;
> [email protected]; 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
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;
>> [email protected]; 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
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;
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
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
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
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
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