Funny timing. I am just reviewing the series from Lee and also stumbled
over modaliases, too...
On Thu, Sep 11, 2014 at 10:19:54AM +0100, Nick Dyer wrote:
> On 11/09/14 09:38, Javier Martinez Canillas wrote:
> > To expand on what Sjoerd already said and just to be sure everyone is on the
> > same page.
> >
> > The problem is that right now the driver reports the following modalias:
> >
> > # cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
> > i2c:maxtouch
> >
> > but if you look at the module information, that is not a valid alias:
> >
> > # modinfo atmel_mxt_ts | grep alias
> > alias: i2c:mXT224
> > alias: i2c:atmel_mxt_tp
> > alias: i2c:atmel_mxt_ts
> > alias: i2c:qt602240_ts
> > alias: of:N*T*Catmel,maxtouch*
> >
> > which means that udev/kmod can't load the module automatically based on the
> > alias information.
> >
> > The aliases are filled by both MODULE_DEVICE_TABLE(i2c, mxt_id) and
> > MODULE_DEVICE_TABLE(of, mxt_of_match) so after Sjoerd's patch:
> >
> > # cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
> > i2c:maxtouch
> >
> > # modinfo atmel_mxt_ts | grep alias
> > alias: i2c:mXT224
> > alias: i2c:maxtouch
> > alias: i2c:atmel_mxt_tp
> > alias: i2c:atmel_mxt_ts
> > alias: i2c:qt602240_ts
> >
> > which matches the reported uevent so the module will be auto-loaded.
> >
> > This is because the I2C subsystem hardcodes i2c:<client->name>, if you look at
> > drivers/i2c/i2c-core.c:
> >
> > /* uevent helps with hotplug: modprobe -q $(MODALIAS) */
> > static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> > {
> > ...
> > if (add_uevent_var(env, "MODALIAS=%s%s",
> > I2C_MODULE_PREFIX, client->name))
> > ...
> > }
> >
> > I've looked at Lee's series and AFAICT that remains the same so I second
> > Sjoerd that module auto-loading will continue to be broken.
I think the above code in the i2c core needs a fix. Will have a closer
look after lunch.
> The i2c aliases are a bit confusing. The original device the driver was
> written for was called qt602240, which was renamed by Atmel to mXT224 when
> the chip series was called "maXTouch". The driver now actually supports
> many other chips which aren't listed (more than 20 devices that I've
> personally tested). I could add them all, but it would be an extremely long
> list. It may be preferable to use the generic name maXTouch.
This is probably true for some more I2C devices. Like RTCs being
compatible or, most prominent, EEPROMS. I don't want to have a list of
all vendors producing 24c02s if they are all compatible. If generic
entries are frowned upon, I'd agree on a "first come, first served" policy:
Somebody provides one compatible-property with the vendor which happens
to be on that board, and the others have to reuse that
compatible-property since they are, well, compatible.
> So I think the sensible thing to do here would be to add "maxtouch" to the
> i2c list to fix the module autoload issue.
This is a workaround. It would make sense, however, to add it because we
want to support i2c_board_info structures.
Regards,
Wolfram
Attachment:
signature.asc
Description: Digital signature
