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:	Wed, 9 Jan 2013 10:48:15 +0900
From:	Alexandre Courbot <acourbot@...dia.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Linus Walleij <linus.walleij@...aro.org>,
	Guenter Roeck <linux@...ck-us.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arch <linux-arch@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>
Subject: Re: [PATCH 0/4] gpio: introduce descriptor-based interface

On Tue, Jan 8, 2013 at 10:06 PM, Arnd Bergmann <arnd@...db.de> wrote:
> I like the interface, good idea!

Great! This was initially suggested by Linus W.

> A few questions:
>
> Is there a plan for migrating all the existing users of the current GPIO
> interface?

Nothing specifically planned for now, as we need to make sure the new
interface covers all needs first. There would be a lot of drivers to
change if we decide to deprecate the integer interface, but Coccinelle
could probably help here.

The question is, do we want to totally get rid of the integer
namespace? That would be the ultimate step, but would require another
way to identify GPIOs (controller_device:offset might be such a way),
and also to reorganize sysfs nodes. Wouldn't that be considered
breaking user-space? 'cause we all know what happens to those who
break user-space.

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

With the current code, a driver should depend on gpiolib being
compiled if it uses the new interface. It is not even declared if
gpiolib is not used.

Given that both interfaces are quite close, one could imagine having a
gpiod wrapper around the integer namespace (the "opaque descriptors"
would then just be casted integers). This way drivers would only need
to depend on GENERIC_GPIO. It's a little bit weird to have gpiod
wrapping around gpio in one case and the opposite in another though -
I'd rather have these platforms convert to GPIO descriptors internally
(or even better, to gpiolib), but this is probably asking too much.

I do not know all the details of gpiolib's history, but why would
anyone want to implement the generic gpio interface and not use
gpiolib anyways?

Then there are platforms who do not follow generic gpios and implement
their own sauce. I don't think we need to care here, as these are not
supposed to be used with generic drivers anyway.

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

That may be a chance to introduce deeper changes indeed - what do you
have in mind exactly?

Thanks,
Alex.
--
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/