linux-kernel - Re: [PATCH v2] GPIO: Add gpio

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]

Message-Id: <200910131505.44739.david-b@pacbell.net>
Date:	Tue, 13 Oct 2009 15:05:44 -0700
From:	David Brownell <david-b@...bell.net>
To:	Ben Nizette <bn@...sdigital.com>
Cc:	Jonathan Corbet <corbet@....net>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	dsilvers@...tec.co.uk
Subject: Re: [PATCH v2] GPIO: Add gpio_lookup

On Sunday 11 October 2009, Ben Nizette wrote:
> OK for something supposedly basic, all this gpio stuff is getting messy.

Sigh.  :(

One can only _expect_ that as infrastructure gets more widely
used, it (unfortunately) starts expanding.  And one _hopes_ the
growth does not turn into bloat.  This is a constant battle with
all tools and infrastructure.  

> The gpio framework was written to use gpio numbers as they were
> recognised as being common to all possible implementations of the
> framework.  

I'm not sure I'd put it that way.  Most SoC-integrated GPIOs
had vendor docs using names like "GPIO-n"; a few combined them
with bank IDs, like "Port C-19".  In all cases, the IDs could
be mapped to numbers ... ('C' - 'A') * 32 + 19, etc.  And mostly
they *needed* to have such a mapping, since GPIOs are often the
main flavor of external IRQ signal, and IRQs are numbered.

Embedded boards also use pcf8574 I2C GPIO expanders and such,
which can be modeled as just fancier banks where IO the calls
require sleeping access.  Enter gpiolib to pull such devices
into the API.

Plus of course, numbers are easily used as a global ID space,
on any platform.  Trivially, if one had a per-GPIO structure
(a thing to avoid, in general, for a single hardware bit!!),
the pointer to that structure is a number.  QED.

Originally, the only name-ish thing was labels for diagnostics,
to help associate for example GPIO-78 with nCS2 or SDA in the
/sys/kernel/debug/gpio listing or in diagnostics.

> I didn't notice Daniel's original patch fly by otherwise I would have
> said something at the time, but storing the names at the chip level
> seems an odd idea.  Given that at that stage they were only for sysfs
> id, why not just give them as an argument to gpio_export()?

Yeah, I wasn't wholly keen on that either.  Notice that we now
have gpio_export_link()... and that the names given in gpio bank
registration can conflict with the *existing* ones registered by
the gpio_request() primitives.

There's also some role conflict here ... the entity registering
the GPIO bank may not always know the purpose to which the GPIO
will be put, while the entity calling gpio_request() *does*.  And
what good is a name which presents the wrong purpose?

Plus, GPIOs may need to be registered very early -- preceding
core_initcall() in some cases -- which can be a long time before
the board-specific labels are available, e.g. in arch_initcall().

But the biggest issue is name uniqueness ...

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