Thread (6 messages) 6 messages, 4 authors, 2015-07-27

Re: [PATCH] MIPS: Remove most of the custom gpio.h

From: Alban <albeu@free.fr>
Date: 2015-07-23 08:41:41
Also in: linux-gpio, linux-ide, linux-input, linux-mips, lkml

On Wed, 22 Jul 2015 19:47:18 +0200
Manuel Lauss [off-list ref] wrote:
On Wed, Jul 22, 2015 at 7:33 PM, Alban Bedel [off-list ref] wrote:
quoted
Currently CONFIG_ARCH_HAVE_CUSTOM_GPIO_H is defined for all MIPS
machines, and each machine type provides its own gpio.h. However
only the Alchemy machine really use the feature, all other machines
only use the default wrappers.

For most machine types we can just remove the custom gpio.h, as well
as the custom wrappers if some exists. A few more fixes are need in
a few drivers as they rely on linux/gpio.h to provides some machine
specific definitions, or used asm/gpio.h instead of linux/gpio.h for
the gpio API.

Signed-off-by: Alban Bedel <albeu@free.fr>
---

This patch is based on my previous serie:
"MIPS: ath79: Move the GPIO driver to drivers/gpio".

For testing I tried to build all mips defconfig, however my
toolchain couldn't handle a few configs: ip28 malta_qemu_32r6
maltasmvp_eva sead3micro. If somebody can test these that would be
more than welcome.

It might well be that some more drivers for MIPS devices that are
not enabled in the defconfig will break because of this change, so
more testing would be nice :)

Regarding Alchemy I'm not sure what to do. It use a little more
complex setup, quoting arch/mips/include/asm/mach-au1x00/gpio.h:

/* Linux gpio framework integration.
*
* 4 use cases of Alchemy GPIOS:
*(1) GPIOLIB=y, ALCHEMY_GPIO_INDIRECT=y:
*       Board must register gpiochips.
*(2) GPIOLIB=y, ALCHEMY_GPIO_INDIRECT=n:
*       A gpiochip for the 75 GPIOs is registered.
*
*(3) GPIOLIB=n, ALCHEMY_GPIO_INDIRECT=y:
*       the boards' gpio.h must provide the linux gpio wrapper
functions,
*
*(4) GPIOLIB=n, ALCHEMY_GPIO_INDIRECT=n:
*       inlinable gpio functions are provided which enable access
to the
*       Au1300 gpios only by using the numbers straight out of the
data-
*       sheets.

* Cases 1 and 3 are intended for boards which want to provide their
own
* GPIO namespace and -operations (i.e. for example you have 8 GPIOs
* which are in part provided by spare Au1300 GPIO pins and in part
by
* an external FPGA but you still want them to be accssible in linux
* as gpio0-7. The board can of course use the alchemy_gpioX_*
functions
* as required).
*/

This sound to me like this is really not needed anymore. Is there
any users of this left, or can it just go?
There are no in-tree users of this, but a few out-of-tree ones (all
made by me) Does it have to be removed?  Is it blocking anything?
It is not blocking anything, but I see little gain in it. Cases 1 and 3
should nowadays be handled using normal GPIO drivers, and not with such
platform specific constructs.

Alban
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help