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: <dabde7bf-dcff-47c6-a68d-f5018ab00282@app.fastmail.com>
Date: Mon, 19 Aug 2024 14:09:49 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Yuntao Liu" <liuyuntao12@...wei.com>,
 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

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