linux-kernel - async userspace gpio api [WAS: Re: PXA board chips control]

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

Message-Id: <1212051734.4780.26.camel@moss.renham>
Date:	Thu, 29 May 2008 19:02:14 +1000
From:	Ben Nizette <squidgit@...et.net.au>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: async userspace gpio api [WAS: Re: PXA board chips control]

[bringing lkml in on this]

On Wed, 2008-05-28 at 00:37 -0700, David Brownell wrote:
> No, very different.  Those are more like device nodes, which
> get added and removed as part of routine operations (like
> physical connect/disconnect).
> 
> 
> > I would have thought -EINVAL was sufficient, no?
> 
> Surprising to see a read return a value at one moment, then
> fail with EINVAL the next, then return a value later ...
> no, there should be some distinguished value for "that mode
> would be meaningless right now".

Actually my thought (though I didn't come close to expressing it just
now) was to have an async behaviour control file (taking irq/poll/none
options) which wouldn't be writable while the gpio was an output.

The more I think about it though, the more I'm inclined to just allow
the user to select any of those options on any gpio regardless of
direction and trust them to know whether that makes sense for the
underlying hardware (sanity checking as needed).

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