Messages in this thread |  | | Date | Sat, 22 Oct 2016 17:48:57 -0400 | From | Paul Gortmaker <> | Subject | Re: [PATCH 0/5] reset: make non-modular drivers really non modular |
| |
[[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@free-electrons.com> > Cc: Joachim Eastwood <manabian@gmail.com> > Cc: Masahiro Yamada <yamada.masahiro@socionext.com> > Cc: Maxime Ripard <maxime.ripard@free-electrons.com> > Cc: Michal Simek <michal.simek@xilinx.com> > Cc: Moritz Fischer <moritz.fischer@ettus.com> > Cc: Philipp Zabel <p.zabel@pengutronix.de> > Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> > Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com> > Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de> > > > 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 >
|  |