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]

Date:	Tue, 13 Oct 2009 19:31:09 +1100
From:	Ben Nizette <bn@...sdigital.com>
To:	Jonathan Corbet <corbet@....net>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	dsilvers@...tec.co.uk
Subject: Re: [PATCH v2] GPIO: Add gpio_lookup

On Mon, 2009-10-12 at 09:23 -0600, Jonathan Corbet wrote:
> On Mon, 12 Oct 2009 17:11:44 +1100
> Ben Nizette <bn@...sdigital.com> wrote:
> 
> > Back to this patch though, the gpio names have to come from the platform
> > code via some platform_data for the gpio chip [1], the driver then looks
> > up that pre-defined name to find the gpio number.  Why not just pass the
> > gpio number straight to the end device driver through platform_data and
> > bypass the middle-man?
> 
> That's true in a situation where you've one One Platform to Bind Them
> All, yes.  But if you have (say) GPIOs provided by a PCI-connected
> peripheral which are needed in (say) a camera driver, there is no one
> platform which can manage all those GPIO numbers.  In particular, I've
> done a driver for viafb-based GPIOs; these devices can show up in any
> of a number of x86-based systems.  I honestly don't know why it would
> make sense to try to hardware numbers to these GPIOs when using names
> and dynamic numbering is so much more flexible - and we are already
> tracking the names.
> 
> Perhaps it would make sense to implement a proper namespace layer for
> GPIOs rather than continuing to grow something which evidently sneaked
> in through the back door.  Until that's done, though, I think this
> patch is useful.  But it it's really unwanted I'll find some other way.
> 

Fair enough; I hadn't seen gpio controllers on such buses before but
that makes sense.  If the naming information isn't coming from platform
code but from some driver itself this seems fairly sane.

If gpios are going to be named, and it seems they are, then personally
I'd like to see the names field of struct gpio_chip go and a proper
namespace layer inserted.  Something which allows gpio_name() and
gpio_lookup() and decentralises that responsibility would be nice (the
chip could call gpio_name itself if it has reason).  That code could be
common to all gpio framework implementations.

But a) I don't have the hours to do this myself and b) it's really
David's call, I'm just an interested bystander :-)

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