linux-kernel - Re: [-mm patch 1/4] GPIO framework for AVR32

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: <1defaf580611081447t4f443657xc4058626ce0f0907@mail.gmail.com>
Date:	Wed, 8 Nov 2006 23:47:36 +0100
From:	"Haavard Skinnemoen" <hskinnemoen@...il.com>
To:	"David Brownell" <david-b@...bell.net>
Cc:	hskinnemoen@...el.com, linux-kernel@...r.kernel.org,
	andrew@...people.com, akpm@...l.org
Subject: Re: [-mm patch 1/4] GPIO framework for AVR32

On 11/8/06, David Brownell <david-b@...bell.net> wrote:
> > The request/free calls aren't really arch-specific, are they?
>
> Remember that where one platform may use numbers 32-159 for GPIOs, another
> might use 0-71 ... GPIO numbering has an arch-specific core, but whether
> a given board adds more GPIOs from an FPGA or other non-SOC chip is even
> more variable than "arch-specific".

Sorry, I'm having trouble expressing myself clearly today ;-)

I didn't mean to suggest that the interpretation of the numbers or the
gpio_request() implementation should be arch-independent. I was merely
suggesting that the _concept_ of requesting GPIO pins before using
them, keeping track of which pins have been allocated before, isn't
something inherently arch-specific.

I'm all for leaving it up to each arch or possibly each sub-arch how
to implement the request/free functions. They can even be implemented
as no-op stubs that always succeed for all I care. But I don't think
any arch or platform will really have much trouble with implementing
some kind of "please reserve this gpio pin represented as an unsigned
int for me" call.

> > I implement the actual allocation mechanism using atomic bitops.
>
> That's a fair way to implement it, sure; but if you look at e.g. how
> OMAP does it, the bitmap is inside a per-controller structure.  When
> one chip has two different _types_ of GPIO controller, and multiple
> instances of one (plus restrictions applying to specific instances),
> the notion of an arch-neutral implementation there seems unworkable.

Agreed. The avr32 implementation also uses a per-controller bitmap and
supports any number of instances (up to a compile-time limit since it
is initialized too early to be able to allocate any memory.) It
doesn't support different type of controllers though; that would
require some kind of demuxing and should probably be avoided on
platforms that don't need it.

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