[PATCH 01/20] mtd: rawnand: txx9ndfmc: Mark driver struct with __refdata to prevent section mismatch warning

[Uwe Kleine-König]

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 at pengutronix.de> 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/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20231017/125aa07f/attachment-0001.sig>