linux-kernel - [RFC 00/17] Remove GENERIC_GPIO from architecture code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1363083150-30964-1-git-send-email-acourbot@nvidia.com>
Date:	Tue, 12 Mar 2013 19:12:13 +0900
From:	Alexandre Courbot <acourbot@...dia.com>
To:	Grant Likely <grant.likely@...retlab.ca>,
	Linus Walleij <linus.walleij@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Russell King <linux@....linux.org.uk>,
	Haavard Skinnemoen <hskinnemoen@...il.com>,
	Hans-Christian Egtvedt <egtvedt@...fundet.no>,
	Mike Frysinger <vapier@...too.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Jonas Bonn <jonas@...thpole.se>,
	Josh Boyer <jwboyer@...il.com>,
	Matt Porter <mporter@...nel.crashing.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>,
	Kumar Gala <galak@...nel.crashing.org>,
	Vitaly Bordug <vitb@...nel.crashing.org>,
	Marcelo Tosatti <marcelo@...ck.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Guan Xuetao <gxt@...c.pku.edu.cn>,
	Chris Zankel <chris@...kel.net>,
	Max Filippov <jcmvbkbc@...il.com>
CC:	Alexandre Courbot <gnurou@...il.com>,
	<linux-kernel@...r.kernel.org>,
	Alexandre Courbot <acourbot@...dia.com>
Subject: [RFC 00/17] Remove GENERIC_GPIO from architecture code

This series makes sure the GENERIC_GPIO option can only be set through GPIOLIB 
(and not by individual architectures), as a first step towards its removal.

It is targeted at getting feedback from architecture maintainers (and complains
if this is deemed too bold a move - however, I hope the rationale  behind this
will be convincing).

AFAICT every GPIO driver that implement the generic GPIO API support gpiolib at 
least optionally, and the overwhelming majority actually requires it. Using the 
generic GPIO API alone has become a marginal practice, and the benefit of 
retaining this option is rather uncertain when compared to the confusion and 
complexity it induces:
* More and more GPIO features are built around gpiolib. The sysfs interface is 
one of them ; the future gpiod API is another one. Platforms that only implement 
the generic GPIO API cannot benefit from these and the split between those who 
only implement the generic GPIO API and full-fledge users of gpiolib is becoming 
wider and wider.
* Having two layers of GPIO support is confusing to both GPIO users and 
providers, and it is easy to e.g. only depend on GENERIC_GPIO when one actually 
needs gpiolib. This series actually fixes a few of these cases.
* Simplicity and consistency is always a good thing - features in the kernel are 
typically implemented through well-defined frameworks, and similarly GPIO 
support could be consolidated around gpiolib.

Arguments against using gpiolib:
* Memory footprint of gpiolib. According to my tests a gpiolib with 256 GPIOs 
induces an overhead of ~15KB, which sounds rather reasonable.
* Performance. gpiolib introduces another layer of indirection compared to 
drivers that only implement the generic GPIO API. However, a fast path is 
available to platforms for which GPIO performance matters through the 
implementation of custom gpio_set_value() and gpio_get_value() functions which 
test for a given GPIO range and shortcut gpiolib.

For most platforms, this change should be a no-op. However I would like to make 
sure that everyone is ok with it and that nothing gets broken, as the effect of 
changing configuration options are sometimes difficult to predict.

Alexandre Courbot (17):
  arm: remove unneeded select GENERIC_GPIO
  arm: remove redundant GENERIC_GPIO selection
  arm: plat-orion: use GPIO driver on CONFIG_GPIOLIB
  mips: remove redundant GENERIC_GPIO select
  mips: loongson: use GPIO driver on CONFIG_GPIOLIB
  mips: txx9: change GENERIC_GPIO to GPIOLIB
  unicore32: remove unneeded select GENERIC_GPIO
  powerpc: remove redundant GENERIC_GPIO selection
  sh: replace CONFIG_GENERIC_GPIO by CONFIG_GPIOLIB
  xtensa: remove explicit selection of GENERIC_GPIO
  mips: alchemy: require gpiolib
  mips: pnx833x: remove requirement for GENERIC_GPIO
  avr32: default GENERIC_GPIO to false
  m68k: coldfire: use gpiolib
  avr32: default GENERIC_GPIO to false
  openrisc: default GENERIC_GPIO to false
  unicore32: default GENERIC_GPIO to false

 arch/arm/Kconfig                     | 2 --
 arch/arm/plat-orion/Makefile         | 2 +-
 arch/avr32/Kconfig                   | 2 +-
 arch/blackfin/Kconfig                | 2 +-
 arch/m68k/Kconfig.cpu                | 3 +--
 arch/mips/Kconfig                    | 7 +------
 arch/mips/loongson/common/Makefile   | 2 +-
 arch/mips/txx9/generic/setup.c       | 2 +-
 arch/openrisc/Kconfig                | 2 +-
 arch/powerpc/platforms/40x/Kconfig   | 1 -
 arch/powerpc/platforms/44x/Kconfig   | 1 -
 arch/powerpc/platforms/85xx/Kconfig  | 1 -
 arch/powerpc/platforms/86xx/Kconfig  | 3 ---
 arch/powerpc/platforms/8xx/Kconfig   | 1 -
 arch/powerpc/platforms/Kconfig       | 4 ----
 arch/sh/boards/mach-sdk7786/Makefile | 2 +-
 arch/sh/boards/mach-x3proto/Makefile | 2 +-
 arch/sh/kernel/cpu/sh2a/Makefile     | 2 +-
 arch/sh/kernel/cpu/sh3/Makefile      | 2 +-
 arch/sh/kernel/cpu/sh4a/Makefile     | 2 +-
 arch/unicore32/Kconfig               | 3 +--
 arch/xtensa/configs/iss_defconfig    | 1 -
 arch/xtensa/configs/s6105_defconfig  | 1 -
 23 files changed, 14 insertions(+), 36 deletions(-)

-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/