linux-kernel - Re: [PATCH -next 0/9] drivers: fix some module autoloading

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: <c1bc5137-9654-4434-a329-9381e14dffaf@huawei.com>
Date: Mon, 19 Aug 2024 20:23:01 +0800
From: "liuyuntao (F)" <liuyuntao12@...wei.com>
To: Arnd Bergmann <arnd@...db.de>, <openipmi-developer@...ts.sourceforge.net>,
	<linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<dmaengine@...r.kernel.org>, "linux-edac@...r.kernel.org"
	<linux-edac@...r.kernel.org>, <linux-i2c@...r.kernel.org>,
	<linux-usb@...r.kernel.org>
CC: Alexandre Belloni <alexandre.belloni@...tlin.com>, Claudiu Beznea
	<claudiu.beznea@...on.dev>, Robert Jarzmik <robert.jarzmik@...e.fr>, Andy
 Shevchenko <andriy.shevchenko@...ux.intel.com>, Corey Minyard
	<minyard@....org>, Ludovic.Desroches <ludovic.desroches@...rochip.com>, Alan
 Stern <stern@...land.harvard.edu>, Uwe Kleine-König
	<u.kleine-koenig@...gutronix.de>, <codrin.ciubotariu@...rochip.com>,
	Duje Mihanović <duje.mihanovic@...le.hr>, Robert Richter
	<rric@...nel.org>, Andi Shyti <andi.shyti@...nel.org>, Haojian Zhuang
	<haojian.zhuang@...il.com>, Tony Luck <tony.luck@...el.com>, Borislav Petkov
	<bp@...en8.de>, Mauro Carvalho Chehab <mchehab@...nel.org>,
	<morbidrsa@...il.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Vinod
 Koul <vkoul@...nel.org>, Mark Brown <broonie@...nel.org>, James Morse
	<james.morse@....com>, Daniel Mack <daniel@...que.org>
Subject: Re: [PATCH -next 0/9] drivers: fix some module autoloading

yes sir^^.

Regards!
Yuntao

On 2024/8/19 20:09, Arnd Bergmann wrote:
> On Mon, Aug 19, 2024, at 13:38, Yuntao Liu wrote:
>> Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
>> based on the alias from platform_device_id table.
>>
>> Yuntao Liu (9):
>>    usb: ehci-mv: fix module autoloading
>>    soc: pxa: ssp: fix module autoloading
>>    misc: atmel-ssc: fix module autoloading
>>    i2c: at91: fix module autoloading
>>    mpc85xx_edac: fix module autoloading
>>    dmaengine: pxa: fix module autoloading
>>    dmaengine: mmp_pdma: fix module autoloading
>>    dmaengine: at_hdmac: fix module autoloading
>>    ipmi: ipmi_ssif: fix module autoloading
> 
> I looked at all the patches and found that most of them do not
> use the table any more, or will stop using it in the near future.
> 
> I think your work to validate the correctness of the entries
> is useful, but it may be more helpful to focus on removing
> all the unused tables, including those that have a
> MODULE_DEVICE_TABLE() tag.
> 
> If you are planning to do more such cleanups, maybe you can
> go through them one subsystem at a time and look for drivers
> that have both of_device_id and i2c_device_id/platform_device_id/
> spi_device_id tables. If nothing in the kernel creates a device
> with the legacy string, you can then send a patch that removes
> the old device ID list and at the same time makes the DT support
> unconditional in case there is an #ifdef CONFIG_OF check.
> 
> If the probe() function accesses platform_data, this would also
> be unused, allowing an even nicer cleanup of removing the
> platofrm_data path in favor of OF properties.
> 
>        Arnd