On Fri, Aug 14, 2015 at 12:37:13PM -0700, Dustin Byford wrote:
> 70762ab from 11/2014 (i2c: Use stable dev_name for ACPI enumerated I2C
> slaves) modified the sysfs-visible dev_name() for ACPI enumerated I2C
> devices. With that change, /sys/bus/i2c/devices/i2c-0-004a, for
> example, became /sys/bus/i2c/devices/i2c-PNPXXXX:xx
>
> That causes problems for userspace code such as 'sensors' which does
> this:
>
> lib/sysfs.c:665:
> if ((!subsys || !strcmp(subsys, "i2c")) &&
> sscanf(dev_name, "%hd-%x", &entry.chip.bus.nr,
> &entry.chip.addr) == 2) {
> ...
>
> Therefore, in theory, sensors that were previously visible by running
> 'sensors' no longer show up. On the other hand, there are probably few,
> if any, cases of this because ACPI enumerated I2C hwmon devices are not
> common.
>
> I'm not defending the 'sensors' code, I'm sure there are better ways to
> discover a hwmon I2C device from userspace. But, I'm also not sure
Is it necessary to defend user space applications nowadays if a kernel change
breaks a well established ABI ? WHat happened to "Thou Shalt Not Break
Userspace" ?
I absolutely agree that i2c bus renumbering across reboots is a problem.
However, it seems to me that 70762ab doesn't solve that problem, it just
paints it over. And, as you have noticed, it introduces new problems along
the way.
Guenter
> 70762ab achieved its stated goal in a meaningful way. Won't
> "i2c-<acpi_dev_name>" also vary with ACPI scan order, BIOS settings,
> firmware upgrades, etc...?
>
> Hence the RFC patch. To submit a change like this I would need to
> consider the fallout for ALSA SoC. The other option is to see what can
> be done in 'sensors' to include the ACPI enumerated hwmon devices.
>
> Any opinions on which way to go?
>
> --Dustin
>
> Dustin Byford (1):
> i2c: acpi: revert setting a "stable" device name
>
> drivers/i2c/i2c-core.c | 7 -------
> 1 file changed, 7 deletions(-)
>
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
