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

[Paul Gortmaker]

[[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
>