LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org> To: "Jon Smirl" <jonsmirl@gmail.com> Cc: "Greg KH" <greg@kroah.com>, linuxppc-dev@ozlabs.org, i2c@lm-sensors.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names Date: Sun, 13 Jan 2008 19:45:23 +0100 [thread overview] Message-ID: <20080113194523.51683e97@hyperion.delvare> (raw) In-Reply-To: <9e4733910801131001o604c1474vc2fd021d32b8c2a3@mail.gmail.com> 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
next prev parent reply other threads:[~2008-01-13 18:45 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-12-20 4:41 [PATCH 0/5] Version 17, series to add device tree naming to i2c Jon Smirl 2007-12-20 4:41 ` [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names Jon Smirl 2008-01-11 19:20 ` [i2c] " Jean Delvare 2008-01-12 8:46 ` Jean Delvare 2008-01-12 16:26 ` Jon Smirl 2008-01-13 14:41 ` Jean Delvare 2008-01-13 16:24 ` Jon Smirl 2008-01-13 17:40 ` Jean Delvare 2008-01-13 18:01 ` Jon Smirl 2008-01-13 18:45 ` Jean Delvare [this message] 2008-01-13 18:50 ` Jon Smirl 2008-01-13 19:05 ` Jean Delvare 2007-12-20 4:41 ` [PATCH 2/5] Modify several rtc drivers to use the alias names list property of i2c Jon Smirl 2007-12-20 4:41 ` [PATCH 3/5] Clean up error returns Jon Smirl 2007-12-20 4:41 ` [PATCH 4/5] Convert PowerPC MPC i2c to of_platform_driver from platform_driver Jon Smirl 2007-12-20 5:16 ` David Gibson 2007-12-20 6:01 ` Olof Johansson 2007-12-20 6:04 ` Stefan Roese 2007-12-20 15:56 ` Jon Smirl 2007-12-20 4:41 ` [PATCH 5/5] Convert pfc8563 i2c driver from old style to new style Jon Smirl 2007-12-20 23:59 ` [PATCH 0/5] Version 17, series to add device tree naming to i2c Jon Smirl 2007-12-27 16:47 ` Jon Smirl 2007-12-28 12:14 ` Jean Delvare 2008-01-11 8:56 ` [i2c] " Jean Delvare 2008-01-11 15:52 ` Jon Smirl 2008-01-11 16:05 ` Jochen Friedrich 2008-01-11 19:15 ` Jean Delvare 2008-01-11 20:16 ` Jon Smirl 2008-01-12 9:08 ` Jean Delvare 2008-01-12 16:00 ` Jon Smirl 2008-01-13 15:09 ` Jean Delvare
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20080113194523.51683e97@hyperion.delvare \ --to=khali@linux-fr.org \ --cc=greg@kroah.com \ --cc=i2c@lm-sensors.org \ --cc=jonsmirl@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@ozlabs.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).