linux-kernel - Re: [PATCH 0/4] gpio: introduce descriptor-based interface

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Jan 2013 13:06:02 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Alexandre Courbot <acourbot@...dia.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Linus Walleij <linus.walleij@...aro.org>,
	Guenter Roeck <linux@...ck-us.net>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	devicetree-discuss@...ts.ozlabs.org,
	Alexandre Courbot <gnurou@...il.com>
Subject: Re: [PATCH 0/4] gpio: introduce descriptor-based interface

On Tuesday 08 January 2013, Alexandre Courbot wrote:
> This series introduce a first take at implementing the RFC for the new GPIO API
> that I submitted last month. It proposes a new, opaque descriptor-based GPIO API
> that becomes available when GPIOlib is compiled, and provides a safer, more
> abstract alternative to the current integer-based interface. GPIOlib internals
> are also switched to use the descriptor logic, and the former integer API
> becomes a lightweight wrapper around the new descriptor-based API.
> 
> Functionally speaking the new API is identical to the integer-based API, with
> only the prefix changing from gpio_ to gpiod_. However, the second patch
> introduces new functions for obtaining GPIOs from a device and a consumer name,
> in a fashion similar to what is done with e.g. regulators and PWMs.

I like the interface, good idea!

A few questions:

Is there a plan for migrating all the existing users of the current GPIO
interface?

How do you want to deal with drivers that work on platforms that currently
don't use gpiolib but have their own implementation of asm/gpio.h? Are
we going to phase them out?

If we are adding a new way to deal with GPIOs, would it make sense to
have that more closely integrated into pinctrl in one form or another?
My feeling is that there is already a significant overlap between the
two, and while the addition of the gpiod_* functions doesn't necessarily
make this worse, it could be a chance to improve the current situation
to make the interface more consistent with pinctrl.

	Arnd
--
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/