Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1506606 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/5] reset: make non-modular drivers really non modular Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-10-22 23:50 +0200
    Re: [PATCH 0/5] reset: make non-modular drivers really non modular Philipp Zabel <p.zabel@pengutronix.de> - 2016-10-24 11:00 +0200

#1506606 — 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
> 

[toc] | [next] | [standalone]

#1507002

Hi Paul,

Am Samstag, den 22.10.2016, 17:48 -0400 schrieb 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?

thanks for the reminder. I had them stashed away because I wanted to see
whether the introduction of per-driver Kconfig options would change some
of them to become modular. That wasn't the case, so I have pushed your
patches to the reset/next branch now, with fixed up commit messages.

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

regards
Philipp

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web