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.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
