linux-kernel - Active-low behavior in gpiolib

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: <CAAVeFu+hQHScYYkvO1KOrUPLLaC0ju_O4SDZWyJE8KhLn_hibQ@mail.gmail.com>
Date:	Wed, 5 Jun 2013 14:22:26 +0900
From:	Alexandre Courbot <gnurou@...il.com>
To:	Grant Likely <grant.likely@...retlab.ca>,
	Linus Walleij <linus.walleij@...aro.org>,
	Arnd Bergmann <arnd@...db.de>
Cc:	linux-gpio@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Active-low behavior in gpiolib

Hi everyone,

While preparing the v2 of the descriptor-based GPIO interface (gpiod),
I stumbled upon this point that looks like some inconsistency in the
current interface.

gpiolib.c defines the following flags that can influence the gpio
output: FLAG_ACTIVE_LOW, FLAG_OPEN_DRAIN, and FLAG_OPEN_SOURCE.
FLAG_OPEN_DRAIN and FLAG_OPEN_SOURCE, when set, take effet on all set
operations no matter where they come from.

FLAG_ACTIVE_LOW, on the other hand, is *only* set and used through
sysfs operations. Independently, the active low property can be
specified in gpio phandles and retrieved by
of_get_(named_)gpio_flags() - only it has to be kept in a separate
variable which must then be checked everytime one wants to change the
GPIO value to set the correct level.

I find it rather confusing and wonder if we could not come with a more
consistent behavior for the gpiod interface. In particular:
- the active low property could be specified when declaring GPIO
mappings (either through DT or platform data)
- gpiod_get() would retrieve it transparently and set it as a
permanent property of the GPIO
- gpiod_set/get_value() would take the active low property into
account when setting the value - making these functions work with the
actual *value* (as their name states) instead of the physical line
level.

The old gpio_* interface would still behave as usual, of course.

This would make gpiolib behavior more consistent IMHO, at the price of
a semantic difference between the otherwise very similar gpio and
gpiod interfaces. Any thought for or against this? If we go this way
and decide to allow gpiod to diverge, are there other things we are
not satisfied with about the current gpio interface and that we want
to improve?

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/