lkml.org 
[lkml]   [2015]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2015-07-23 14:41    [W:0.069 / U:2.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site