LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: "Jon Smirl" <jonsmirl@gmail.com> To: "Jean Delvare" <khali@linux-fr.org> 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 13:01:06 -0500 [thread overview] Message-ID: <9e4733910801131001o604c1474vc2fd021d32b8c2a3@mail.gmail.com> (raw) In-Reply-To: <20080113184017.7e3b409f@hyperion.delvare> On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote: > On Sun, 13 Jan 2008 11:24:29 -0500, Jon Smirl wrote: > > On 1/13/08, Jean Delvare wrote: > > > On Sat, 12 Jan 2008 11:26:34 -0500, Jon Smirl wrote: > > > > IMHO, driver_name/type should be removed in new style drivers and > > > > replaced with aliases on all platforms since aliases are the standard > > > > kernel mechanism. > > > > > > I agree. But we can take your aliasing code now (once you have > > > addressed the issues I raised) and convert the users of driver_name > > > later; it doesn't have to be done all at once. > > > > GregKH, adding a new dynamically loadable subsystem is not something > > that happens every day, can you check to make sure all of the standard > > kernels mechanisms are being used? I'm not totally sure how the > > modalias naming code is supposed to be done. The subsystem core code > > in these patches needs review. > > > > Jean, could you take over the i2c core portion of the patch? That will > > let you decide exactly how you want the driver_name/name fields to be > > dealt with. After you get standard naming support into i2c core I'll > > rework the rest of the patch to use your new code. > > Yes, that could be done, and I agree that it will probably be faster > than iterative review/rework cycles between you and me. I'll free some > cycles next week for that. > > > I don't think driver_name/name fields should be stored in an i2c > > structure at all. They are redundant with the standard mechanism. > > > > 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. > > > 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 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? jonsmirl@terra:/sys/bus/i2c/devices/0-0052$ ls driver eeprom modalias name power subsystem uevent jonsmirl@terra:/sys/bus/i2c/devices/0-0052$ cat name eeprom jonsmirl@terra:/sys/bus/i2c/devices/0-0052$ ls driver -l lrwxrwxrwx 1 root root 0 2008-01-13 12:46 driver -> ../../../../../../bus/i2c/drivers/eeprom jonsmirl@terra:/sys/bus/i2c/devices/0-0052$ jonsmirl@terra:/sys/bus/i2c/drivers$ ls eeprom jonsmirl@terra:/sys/bus/i2c/drivers$ ls eeprom 0-0050 0-0051 0-0052 0-0053 bind module uevent unbind > > You may not like what the i2c subsystem does but you can't ignore its > history. The name attribute of i2c devices has been there pretty much > forever and user-space relies on it, thus we can't remove it. > > -- > Jean Delvare > -- Jon Smirl jonsmirl@gmail.com
next prev parent reply other threads:[~2008-01-13 18:01 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 [this message] 2008-01-13 18:45 ` Jean Delvare 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=9e4733910801131001o604c1474vc2fd021d32b8c2a3@mail.gmail.com \ --to=jonsmirl@gmail.com \ --cc=greg@kroah.com \ --cc=i2c@lm-sensors.org \ --cc=khali@linux-fr.org \ --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).