Re: [PATCH v2] Staging: fbtft: Add support for the Ultrachip UC1611 LCD controller

["Noralf Trønnes" <noralf@tronnes.org>]

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.