linux-kernel - Re: [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080113194523.51683e97@hyperion.delvare>
Date:	Sun, 13 Jan 2008 19:45:23 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	"Jon Smirl" <jonsmirl@...il.com>
Cc:	"Greg KH" <greg@...ah.com>, linuxppc-dev@...abs.org,
	i2c@...sensors.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] Implement module aliasing for i2c to translate from
 device tree names

Hi Jon,

On Sun, 13 Jan 2008 13:01:06 -0500, Jon Smirl wrote:
> On 1/13/08, Jean Delvare wrote:
> > On Sun, 13 Jan 2008 11:24:29 -0500, Jon Smirl wrote:
> > > The kernel automatically exposes modalias as a sysfs attribute so the
> > > string must be recorded further down in the driver support layers. No
> > > need to keep a copy in the i2c structure.
> >
> > Really? I didn't know that. So that's another thing that the i2c
> > subsystem is not doing like the rest of the kernel? Can you please
> > point me to the code that does this?
> 
> I never noticed it before either. Just do find | grep modalias in /sys
> and see that every driver has a modalias attribute. It is probably
> implement in drivers/base.

This doesn't mean that the kernel does this automatically! It could
also be that each subsystem does it on its own. Given that the format of
the modalias depends on the bus type, it wouldn't be all that
surprising. Anyway, I'll go look at how the other subsystems handle it
before going on.

> > > Standard devices don't export a 'name' attribute. To see the driver
> > > name for a device in sysfs look at the 'driver' link.
> >
> > The driver name and the device name are different things! The "name"
> > attribute that i2c devices have tells user-space the device name, not
> > the driver name.
> 
> For this system my i2c device names are:
> 0-0050  0-0051  0-0052  0-0053

These are not device names, these are device bus IDs. They tell you how
to access the devices, but they do not tell you what these devices are.

> How does the name=eeprom attribute interact with this? All four of my
> devices have name=eeprom. What is the name field used for in user
> space?

The eeprom case might be a bit confusing because that i2c driver
supports a single device type, so the driver name is the same as the
device name. Take a look at the hwmon/lm90 driver for a better example:
this device supports 7 different devices. The devices are mostly
compatible so it made sense to have a single driver for them, but they
all differ in some way. For example, the LM90 doesn't support PEC,
while the ADM1032 does. User-space needs to be able to distinguish
between the various types. That's the reason why we export the device
name through sysfs.

Most i2c sensor drivers support several chip types, and libsensors has
been relying heavily on the name attribute. Less so with the lm-sensors
3.0.0 rewrite, where most things are automatically detected, but if
nothing else, giving humans a way to distinguish between the different
sensor chip types is very useful. Also, not everyone will upgrade to
lm-sensors 3.0.0 so we need to keep supporting the previous versions.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/