LKML Archive on
help / color / mirror / Atom feed
From: "Jon Smirl" <>
To: "Jean Delvare" <>, "Greg KH" <>
Subject: Re: [i2c] [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
Date: Sun, 13 Jan 2008 11:24:29 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20080113154114.4a1c5166@hyperion.delvare>

On 1/13/08, Jean Delvare <> wrote:
> Hi Jon,
> On Sat, 12 Jan 2008 11:26:34 -0500, Jon Smirl wrote:
> > The common scheme used elsewhere in the kernel for handling more than
> > one device in a single driver is aliases. The i2c code's existing
> > driver_name/type combination is a different way of implementing the
> > same feature. But there is no real need for driver_name/type on any
> > platform if aliases are used. Back in version 10 or 11 I had code in
> > there which replaced the two fields with aliases on all platforms but
> > too many people objected so I removed it..
> While I agree that aliases make i2c_client.driver_name obsolete,
> i2c_client.type is still needed. Not for device/driver matching in the
> kernel, granted, but for device identification from userspace. This is
> a first problem your patch has: when using your aliasing mechanism, the
> type string is left empty. i2c-core exports this value to user-space
> via the "name" sysfs attribute, and some libraries and applications
> make use of it. I know of libsensors at least, but I guess there are
> more. I can't apply your patch until this problem is solved, otherwise
> we would break some user-space applications.
> > 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.

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.

Standard devices don't export a 'name' attribute. To see the driver
name for a device in sysfs look at the 'driver' link.

> The second problem I have with your patch is that you make use of the
> driver_name field, while I ultimately want to get rid of it. I'd rather
> see you use a different field for aliases, so that the later removal of
> the driver_name field and the associated mechanism is easier.
> A third, related problem, is the contents of the modalias file when
> using your patch. When I tested on my ADM1032 evaluation board, the
> modalias contained "adm1032". This isn't a valid module alias string:
> "modprobe adm1032" doesn't work. What works is "modprobe i2c:Nadm1032"
> so the modalias file should contain "i2c:Nadm1032". Just take a look at
> all modalias files in /sys, they all include the subsystem prefix and a
> simple modprobe `cat modalias` loads the required driver. I fail to see
> why the i2c subsystem would be different.
> I said this is related to the second problem because right now,
> i2c-core can't easily differentiate between driver names and aliases,
> as both are stored in i2c_client.driver_name. Having separate fields
> would make it possible (and relatively easy) to add the required prefix
> before aliases but not before driver names. The only drawback is that
> it will increase the size of the i2c_client structure, but I do not
> care that much given that it is only temporary.
> --
> Jean Delvare

Jon Smirl

  reply	other threads:[~2008-01-13 16:24 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 [this message]
2008-01-13 17:40             ` Jean Delvare
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be 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).