Re: [PATCH 0/5] reset: make non-modular drivers really non modular

From: Paul Gortmaker
Date: Sat Oct 22 2016 - 17:49:57 EST


[[PATCH 0/5] reset: make non-modular drivers really non modular] On 13/06/2016 (Mon 14:03) Paul Gortmaker wrote:

> For anyone new to the underlying goal of this cleanup, we are trying to
> not use module support for code that can never be built as a module since:

Hi Philipp,

I sent this several months ago, and aside from a couple Ack'd by, there
was no negative feedback or similar.

Since then there have been two more drivers added with the same issue.

reset-make-ath79-explicitly-non-modular.patch
reset-pistachio-make-it-explicitly-non-modular.patch

Should I assume that the original send has fallen through the cracks and
resend with the two new patches, or do you still have the original five
in a queue somewhere?

I'd like to merge as many of these as I can via their respective
maintainers vs. trying to send them to Linus directly.

Thanks,
Paul.
--

>
> (1) it is easy to accidentally write unused module_exit and remove code
> (2) it can be misleading when reading the source, thinking it can be
> modular when the Makefile and/or Kconfig prohibit it
> (3) it requires the include of the module.h header file which in turn
> includes nearly everything else, thus adding to CPP overhead.
> (4) it gets copied/replicated into other code and spreads like weeds.
>
> Fortunately the reset dir is in pretty good shape, and there are only
> five instances of non-modular code using modular funcionality/macros.
>
> Changes seen here cover the following categories:
>
> -just replacement of modular macros with their non-modular
> equivalents that CPP would have inserted anyway
>
> -the removal of including module.h ; replaced with init.h
> as required based on whether the file already had it.
>
> -the removal of any ".remove" functions that were hooked into
> the driver struct. This ".remove" function would of
> course not be called from the __exit function since that was
> never run. However in theory, someone could have triggered it
> via sysfs unbind, even though there isn't a sensible use case
> for doing so. So to cover that possibility, we've also disabled
> sysfs unbind in the driver.
>
> Recently several of these drivers got removal of the ".remove" fcns
> via other changes, so only one remains for which that happens here.
>
> There are no initcall level changes here; everything was at the level
> of device_initcall and remains so, by using the builtin equivalents.
>
> Build tested for several different key arch on a recent linux-next
> tree to ensure no silly typos crept in.
>
> If there is a desire for any of these to be modular, we can definitely
> consider that, but by default the changes here keep the code consistent
> with existing behaviour and do not expand functionality into the modular
> realm that I can't run time test.
>
> Paul.
>
> ---
>
> Cc: Antoine Tenart <antoine.tenart@xxxxxxxxxxxxxxxxxx>
> Cc: Joachim Eastwood <manabian@xxxxxxxxx>
> Cc: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
> Cc: Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>
> Cc: Michal Simek <michal.simek@xxxxxxxxxx>
> Cc: Moritz Fischer <moritz.fischer@xxxxxxxxx>
> Cc: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@xxxxxxxxx>
> Cc: "Sören Brinkmann" <soren.brinkmann@xxxxxxxxxx>
> Cc: Steffen Trumtrar <s.trumtrar@xxxxxxxxxxxxxx>
>
>
> Paul Gortmaker (5):
> reset: berlin: make it explicitly non-modular
> reset: socfpga: make it explicitly non-modular
> reset: sunxi: make it explicitly non-modular
> reset: zynq: make it explicitly non-modular
> reset: lpc18xx: make it explicitly non-modular
>
> drivers/reset/reset-berlin.c | 12 ++++--------
> drivers/reset/reset-lpc18xx.c | 32 +++++---------------------------
> drivers/reset/reset-socfpga.c | 10 ++++------
> drivers/reset/reset-sunxi.c | 9 ++-------
> drivers/reset/reset-zynq.c | 10 ++++------
> 5 files changed, 19 insertions(+), 54 deletions(-)
>
> --
> 2.8.4
>