Hello, On Tue, Oct 17, 2023 at 07:20:19PM +0900, Masahiro Yamada wrote: > On Mon, Oct 16, 2023 at 7:21 PM Uwe Kleine-König > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > On Mon, Oct 16, 2023 at 11:25:44AM +0200, Arnd Bergmann wrote: > > > Based on a few days of randconfig build testing, the patch > > > below addresses the remaining warnings I get for arm, arm64 and > > > x86 on linux-next. This is a shorter list than the ones that > > > I found in theory, possibly because some of the other ones > > > are only used in built-in code, or because they are never used > > > on these three architectures. > > > > > > Have you already sent patches for (some of) these? > > > > > > Arnd > > > > > > drivers/char/hw_random/mxc-rnga.c | 2 +- > > > drivers/gpu/drm/bridge/ti-tpd12s015.c | 4 ++-- > > > drivers/hwmon/smsc47m1.c | 2 +- > > > drivers/hwtracing/coresight/coresight-etm4x-core.c | 8 ++++---- > > > drivers/media/i2c/et8ek8/et8ek8_driver.c | 4 ++-- > > > drivers/memory/emif.c | 2 +- > > > drivers/mmc/host/davinci_mmc.c | 2 +- > > > drivers/mtd/nand/raw/txx9ndfmc.c | 2 +- > > > > The txx9ndfmc driver was fixed as part of this series, but Miquèl didn't > > take the patch, I guess because he wants it to be converted to > > module_platform_driver(). > > > So, there are two ways for fixing, and it is > up to subsystem maintainers? Yes, either you use module_platform_driver_probe() and benefit from .probe in __init and .remove in __exit. Or you use module_platform_driver() and benefit from more flexible bind/unbind support (probing devices that appear only after boot, hotplugging, binding/unbinding via sysfs) > A question is, is module_platform_driver_probe() > still worth supporting? If you ask me, module_platform_driver_probe is a thing from the past and hardly relevant any more. The effect of converting drivers/mtd/nand/raw/txx9ndfmc.c (on ARCH=arm allmodconfig) is: add/remove: 0/0 grow/shrink: 1/2 up/down: 12/-16 (-4) Function old new delta txx9ndfmc_remove 228 240 +12 txx9ndfmc_driver_init 48 40 -8 init_module 48 40 -8 Total: Before=5496, After=5492, chg -0.07% I didn't try to understand why the remove callback got bigger. The section sizes were changed as follows: .text: 0xe94 -> 0xf84 ( +0xf0) .ARM.exidx: 0x58 -> 0x60 ( +0x8) .init.text: 0x444 -> 0x43c ( -0x8) .exit.text 0xfc -> 0x18 ( -0xe4) .ARM.exidx.exit.text: 0x10 -> 0x8 ( -0x8) So we're talking about less than 250 bytes that cannot be discarded any more with a builtin-driver after boot. Still I'd expect some resistance if we deprecate it and work on removing it. OTOH: $ git grep -l module_platform_driver_probe next/master | wc -l 74 with 19 in drivers/rtc (I added Alexandre to Cc:), 4 in drivers/mtd, 6 in drivers/usb and otherwise here and there a driver. That doesn't look insurmountable. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
