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 18:40:17 +0100 [thread overview] Message-ID: <20080113184017.7e3b409f@hyperion.delvare> (raw) In-Reply-To: <9e4733910801130824i547b65a9n64e415f9626d6ab5@mail.gmail.com> 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? > 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. 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
next prev parent reply other threads:[~2008-01-13 17:40 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 [this message] 2008-01-13 18:01 ` Jon Smirl 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=20080113184017.7e3b409f@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).