linux-kernel - Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

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:	Mon, 20 Nov 2006 13:49:28 -0800
From:	David Brownell <david-b@...bell.net>
To:	Paul Mundt <lethal@...ux-sh.org>
Cc:	Bill Gatliff <bgat@...lgatliff.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	Andrew Victor <andrew@...people.com>,
	Haavard Skinnemoen <hskinnemoen@...el.com>, jamey.hicks@...com,
	Kevin Hilman <khilman@...sta.com>,
	Nicolas Pitre <nico@....org>,
	Russell King <rmk@....linux.org.uk>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

On Monday 13 November 2006 12:15 pm, Paul Mundt wrote:
> On Mon, Nov 13, 2006 at 01:29:24PM -0600, Bill Gatliff wrote:
> 
> Pin muxing is somewhat of a decoupled issue,

I'll continue to read that as "100% orthogonal to any GPIO API since it's
so thoroughly platform-specific".  :)

>	 but it's quite related when 
> "GPIO" is just another pin state depending on the mux. The primary
> concern here is where we end up doing the refcounting for the pins, so we
> don't run in to a situation where a pin is toggled out from an existing
> user with regards to drivers contending for pin functions. 

A fine example of two platform-specific notions.  First, that GPIO signals
are muxed in that way ... they could easily have dedicated pins!!  Second,
that there's even a one-to-one association between pins and GPIOs ... I'll
repeat the previous example of OMAP1, where certain GPIOs could come out on
any of several pins.  And where some pins can be muxed to work with more
than one GPIO (but only one at a time, of course).  Clearly, neither pin
refcounting nor GPIO claiming can be sufficient to prevent such problems ...

Another issue that's orthogonal to a GPIO API is IRQ trigger modes:

> > Think: today, most drivers don't know or care if an IRQ line is
> > edge-triggered or level-triggered.  That code is in the domain of the
> > IRQ subsystem.  What David is proposing is the same sort of thing for
> > GPIO.
> > 
> I would suggest that it's exactly the opposite, other than the blatantly
> obvious cases (edge-triggered NMI, controllers with fixed detection
> logic, etc.) it's _specifically_ up to the drivers to indicate where to
> do the detection, as to allow the IRQ controller to adjust the sense
> selection for that particular IRQ. Grepping drivers/ for IRQF_TRIGGER is
> a pretty good indicator of this.

It's easy to think that way, but then it's just as easy to assemble boards
that happen to route IRQs through an inverting buffer because of signal
level or strength issues.  And with discrete controllers, I've certainly
had to cope with drivers running on systems that don't support the ideal
triggering mode ... typically there'd be an edge trigger mode (e.g. only
"both edges" supported) for a chip whose IRQ is active low.

It's better to make the board setup include the right IRQ triggering mode
for each IRQ, so that drivers don't have to embed board-specific knowledge
like that.  It's bad enough to have to write the driver to cope with some
unnatural trigger mode ... but it's really rude to make them have to try
guess several times before they can find which one works!!

Boards can pass the IORESOURCE_IRQ_* flags in irq resources, though it
seems not many do.

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