Messages in this thread | | | Date | Thu, 23 Jul 2015 14:14:42 +0200 | From | Noralf Trønnes <> | Subject | Re: [PATCH v2] Staging: fbtft: Add support for the Ultrachip UC1611 LCD controller |
| |
Den 15.07.2015 11:36, skrev Paul Bolle: > On di, 2015-07-14 at 14:59 +0200, Henri Chain wrote: >> --- /dev/null >> +++ b/drivers/staging/fbtft/fb_uc1611.c >> +#define DRVNAME "fb_uc1611" >> +MODULE_ALIAS("spi:" DRVNAME); >> +MODULE_ALIAS("platform:" DRVNAME); >> +MODULE_ALIAS("spi:uc1611"); >> +MODULE_ALIAS("platform:uc1611"); > Many of the drivers under drivers/staging/fbtft use a comparable set of > aliases. But I wonder if they are all needed (here, and in the other > drivers). > > In this case I think I understand how the "fb_uc1611" .modalias (see > below) will eventually trigger a "MODALIAS=spi:fb_uc1611" uevent. And > that uevent will make userspace load the fb_uc1611.ko module, right? > > But is there a similar way that "spi:uc1611" fits into the system? > Because I couldn't spot anything similar for "uc1611".
If I remember correctly, this is used for autoloading the module when using Device Tree.
> Likewise, "platform:fb_uc1611" and "platform:uc1611" require struct > platform_device's with "fb_uc1611" and "uc1611" .name's. But I couldn't > spot where platform_device's with those .name's are created. How do > these two aliases fit into the system?
Most of these display controllers support both SPI and 8080 parallel interface. So the FBTFT_REGISTER_DRIVER macro sets up both a SPI and a platform driver. I can't remember the reason why I couldn't put the MODULE_ALIAS'es inside FBTFT_REGISTER_DRIVER. If the chip only has a SPI interface, then the platform aliases are not needed.
Noralf.
| |