[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1438682920.8734.61.camel@tiscali.nl>
Date: Tue, 04 Aug 2015 12:08:40 +0200
From: Paul Bolle <pebolle@...cali.nl>
To: Javier Martinez Canillas <javier@....samsung.com>
Cc: Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 15/27] regulator: fan53555: Export I2C module alias
information
Hi Javier,
On ma, 2015-08-03 at 16:29 +0200, Javier Martinez Canillas wrote:
> On 08/03/2015 01:43 PM, Paul Bolle wrote:
> > On do, 2015-07-30 at 18:18 +0200, Javier Martinez Canillas wrote:
> I2C is a little special in that it uses the id_table again to match
> in i2c_device_probe() and pass a i2c_device_id to the I2C driver's probe
> function. That is what I meant by matching but maybe I could had been more
> precise.
(So is what I2C currently does comparable to what, say, USB does (ie,
using usb_device_id for the match and also passing it to the driver's
probe function) or is it more complicated?)
> > But I'm guessing that parsing a device tree blob that contains
> > strings like
> > compatible = "silergy,syr828"
> >
> > would add strings like
> > MODALIAS=of:N[...]T[...]Csilergy,syr828
>
> That would be the correct behavior and is what the RFC patch #27 does.
>
> > to the related uevents. (Likewise for the two other aliases.) Doesn't
> > that happen here?
>
> No, that is exactly the problem.
Which also explains how these
MODULE_DEVICE_TABLE(of, ...);
lines, which have no effect for the drivers at hand, added to my confusion.
> Take a look to i2c_device_uevent() [0],
> it just does:
>
> add_uevent_var(env, "MODALIAS=%s%s", I2C_MODULE_PREFIX, client->name))
>
> So if you have a i2c_device_id table but no
> MODULE_DEVICE_TABLE(i2c,...),
> then module autoload won't work.
Thanks for taking the time to explain all this to me.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists