lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55B0DAB2.6060203@tronnes.org>
Date:	Thu, 23 Jul 2015 14:14:42 +0200
From:	Noralf Trønnes <noralf@...nnes.org>
To:	Paul Bolle <pebolle@...cali.nl>,
	Henri Chain <henri.chain@...ves.ec-nantes.fr>
CC:	thomas.petazzoni@...e-electrons.com, gregkh@...uxfoundation.org,
	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
	sudipm.mukherjee@...il.com
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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ