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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
