linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: linux-kernel@vger.kernel.org
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>,
	Alexandre Courbot <gnurou@gmail.com>,
	Fabian Vogt <fabian@ritter-vogt.de>,
	"Hans J . Koch" <hjk@linutronix.de>,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-gpio@vger.kernel.org,
	Rabin Vincent <rabin.vincent@stericsson.com>
Subject: [PATCH 0/4] gpio: batch #3: remove modular code from non-modular drivers
Date: Mon, 9 May 2016 19:59:54 -0400	[thread overview]
Message-ID: <1462838398-10725-1-git-send-email-paul.gortmaker@windriver.com> (raw)

For GPIO, I'd divided up the the audit of modular usage in non-modular
drivers into three categories to ease review and limit the batch size.
Group #1 & #2 have been submitted and merged ; this here is group #3.

The breakdown of the three groups was as follows:

1) just replacement of modular macros with their non-modular equivalents
   that CPP would have inserted anyway ; this means runtime equivalence
   and actually also binary equivalence.

2) as per #1 but also with the removal of unused/orphaned __exit functions
   that could never be called/exercised.  This also maintains runtime
   equivalence, but since the unused __exit function is gone, there is a
   reduction in the object file size and hence not binary equivalence, eg:
       before: -rw-rw-r-- 1 8828 drivers/gpio/gpio-rc5t583.o
       after:  -rw-rw-r-- 1 7396 drivers/gpio/gpio-rc5t583.o

3) as per #2 but also with the removal of a ".remove" function that is
   hooked into the driver struct.   This ".remove" function would of
   course not be called from the __exit function since that is 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 these drivers.

Since this is the #3 of 3, an additional bind comment is warranted.
One could argue that the suppress bind is overkill, since it isn't used
by all non-modular drivers everywhere, but it does ensure that anyone
who was manually trying to (ab)use it with _these_ drivers gets a clear
signal that it was never meant to be used like that.

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:

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

There are no initcall level changes here; everything was at the level
of device_initcall and remains so, by using the builtin equivalents.

I fixed up the shortlogs in this lot to match the existing gpio shortlog
format (no "device/" in the prefix, etc.) -- apologies for not catching
that for the earlier lot of commits in #1 and #2.

Build tested for 5-6 different key arch on today's linux-next to ensure
no silly typos crept in.

There is one remaining trivial bool ---> tristate gpio conversion I have to
send that didn't fit #1/#2/#3, but getting these groups done is 99% of it,
so thanks in advance for handling these and getting them off of my queue.

Paul.
---

Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Fabian Vogt <fabian@ritter-vogt.de>
Cc: Hans J. Koch <hjk@linutronix.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Cc: Rabin Vincent <rabin.vincent@stericsson.com>

Paul Gortmaker (4):
  gpio: sodaville: make it explicitly non-modular
  gpio: stmpe: make it explicitly non-modular
  gpio: timberdale: make it explicitly non-modular
  gpio: zevio: make it explicitly non-modular

 drivers/gpio/gpio-sodaville.c  | 28 ++++++----------------------
 drivers/gpio/gpio-stmpe.c      | 31 +++++--------------------------
 drivers/gpio/gpio-timberdale.c | 35 +++++------------------------------
 drivers/gpio/gpio-zevio.c      | 21 +++------------------
 4 files changed, 19 insertions(+), 96 deletions(-)

-- 
2.8.0


             reply	other threads:[~2016-05-10  0:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09 23:59 Paul Gortmaker [this message]
2016-05-09 23:59 ` [PATCH 1/4] gpio: sodaville: make it explicitly non-modular Paul Gortmaker
2016-05-11 11:47   ` Linus Walleij
2016-05-09 23:59 ` [PATCH 2/4] gpio: stmpe: " Paul Gortmaker
2016-05-11 11:48   ` Linus Walleij
2016-05-09 23:59 ` [PATCH 3/4] gpio: timberdale: " Paul Gortmaker
2016-05-11 11:49   ` Linus Walleij
2016-05-09 23:59 ` [PATCH 4/4] gpio: zevio: " Paul Gortmaker
2016-05-11 11:50   ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1462838398-10725-1-git-send-email-paul.gortmaker@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=fabian@ritter-vogt.de \
    --cc=gnurou@gmail.com \
    --cc=hjk@linutronix.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rabin.vincent@stericsson.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).