public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: linuxppc-dev list
	<linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
	Paul Mundt <lethal-M7jkjyW5wf5g9hUCZPvPmw@public.gmane.org>,
	Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	Linux I2C <i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org>
Subject: Re: [PATCH 1/2] i2c: Add support for device alias names
Date: Thu, 01 May 2008 17:51:29 +0200	[thread overview]
Message-ID: <1209657089.20889.46.camel@linux.site> (raw)
In-Reply-To: <20080501100409.1b04fdb7-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>

On Thu, 2008-05-01 at 10:04 +0200, Jean Delvare wrote:
> On Mon, 28 Apr 2008 18:16:17 +0200, Kay Sievers wrote:
> > On Mon, 2008-04-28 at 17:40 +0200, Jean Delvare wrote:
> > > Why would i2c device modaliases ever contain multiple strings? A device
> > > can't have multiple names, can it?
> > 
> > Like ACPI/PNP devices, which can have several compat id's, which means
> > that a single device can have "multiple names":
> >   $ cat /sys/bus/pnp/devices/00:09/id
> >   IBM0057
> >   PNP0f13
> 
> Ah, I didn't know about this. Now I'm curious how it can work. Does it
> mean that several drivers attempt to bind to this device? 

They are usually all id's for the same type of device, and don't describe
multiple functions at the same time. In most cases the vendor id's, like
"IBM0057" here, do not match anything.

> > > Can't we just stop handle_moddevtable() from adding a tailing "*"
> > > automatically, and just let the device types which need it, add it on
> > > their own?
> > 
> > For a lot subsystems it's fine to have it appended, as there is a
> > defined list of identifiers, which must appear in the same order, and
> > new identifiers are appended to the end. So the "*" still matches
> > modules with possibly extended modalias strings.
> 
> I understand the logic, however I am skeptical how useful it is in
> practice. If we add an identifier to the device aliases, then we also
> update the corresponding modalias, so no in-tree driver can break. The
> only case where it makes a difference, as far as I can see, is for
> out-of-tree drivers. Am I correct?

That sounds correct, yes.

> On top of that, I doubt that we
> actually add new identifiers that frequently, do we?

Not that I know.

> > We would also need to review all buses which export modalias, if they
> > need the "*" or not, and add them by hand, if needed.
> > 
> > I guess, it's easier to introduce an additional parameter to
> > file2alias::do_table() and suppress the trailing "*" for i2c?
> 
> That's one possibility, but I had a slightly different approach, which
> is to just let the type-specific handlers add the trailing "*" by
> themselves if they need it. This allows for optimization in a few
> cases.
> 
> Subject: modpost: i2c aliases need no trailing wildcard
> 
> Not all device type aliases need a trailing wildcard, in particular
> the i2c aliases don't. Don't add a wildcard by default in do_table(),
> instead let each device type handler add it if needed.

...

> The patch only changes the i2c aliases, all the rest is the same as
> before (unless I messed up somewhere, that is.) Do you think this would
> be acceptable for upstream? If you think it's better to add a parameter
> to do_table() and let it add the "*" as it did so far, that's also fine
> with me, I can update the patch to do that.

Looks fine to me.

If the content of:
  /lib/modules/$(uname -r)/modules.alias
looks correct after the patch, this should go in, I think.

Thanks,
Kay


_______________________________________________
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

  parent reply	other threads:[~2008-05-01 15:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-28  9:30 [PATCH 0/2] i2c: Add support for device alias names Jean Delvare
2008-04-28  9:39 ` [PATCH 1/2] " Jean Delvare
2008-04-28 14:43   ` Jon Smirl
     [not found]     ` <9e4733910804280743q2de1da62m120c607b200cafa0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-04-28 15:42       ` Jean Delvare
2008-04-28 15:07   ` Kay Sievers
     [not found]     ` <1209395245.3666.9.camel-YbU/o29LwNHN0uC3ymp8PA@public.gmane.org>
2008-04-28 15:40       ` Jean Delvare
2008-04-28 16:16         ` Kay Sievers
2008-05-01  8:04           ` Jean Delvare
     [not found]             ` <20080501100409.1b04fdb7-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-05-01 15:51               ` Kay Sievers [this message]
2008-04-28  9:53 ` [PATCH 2/2] i2c: Convert most new-style drivers to use module aliasing Jean Delvare
     [not found] ` <20080428113052.6d024bda-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-04-28 15:35   ` [PATCH 0/2] i2c: Add support for device alias names Wolfram Sang
     [not found]     ` <20080428153543.GB4353-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2008-04-28 20:24       ` Jochen Friedrich

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=1209657089.20889.46.camel@linux.site \
    --to=kay.sievers-td+1ro4qerm@public.gmane.org \
    --cc=i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
    --cc=lethal-M7jkjyW5wf5g9hUCZPvPmw@public.gmane.org \
    --cc=linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org \
    --cc=scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.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: 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