From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: How about a gpio_get(device *, char *) function? Date: Mon, 26 Nov 2012 11:14:31 +0000 Message-ID: <20121126111431.AE4C23E09C2@localhost> References: <38620644.IyR5R8rjKP@percival> <5097F8CF.5090100@wwwdotorg.org> Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Linus Walleij , Stephen Warren Cc: Alex Courbot , devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org List-Id: devicetree@vger.kernel.org On Wed, 7 Nov 2012 22:28:01 +0100, Linus Walleij wrote: > On Mon, Nov 5, 2012 at 6:35 PM, Stephen Warren wrote: > > [Me] > >> gpio_get() should get an abstract handle just like clk_get() or > >> regulator_get(), not a fixed numeral. > > > > I don't really see why the return type of gpio_get() influences whether > > it can be implemented or not. > > It doesn't influence that, but I want to follow the opaqueness design > pattern from irq descriptors and struct clk. Right. I like the pattern too. Unforutunately that means dealing with somewhere on the order of 2500 callers of the old API. :-( However, I don't think that the GPIO numberspace issue is completely intertwined with opaqifying the gpio handles. The numberspace can be fixed with the current API if someone creates a sparse gpio registrations. I don't have any problem with a gpio_get function, but I do agree that making it return an opaque handle is how it should be written with a new set of accessors. The handle should probably be simply the pointer to the &gpio_desc[number] which is a private table in gpiolib.c. The definition of it isn't available outside of gpiolib.c In fact, the old functions should be redefined in terms of getting the gpio_desc from the irq number and calling the new functions. > > > With board files, some "gpio map" table would simply contain the same > > int GPIO ID value the table as is used anywhere else already. With DT, > > the same xlate function would translate from DT GPIO-chip-relative > > IDs/specifiers into the global number space in the same way that we do > > today via other APIs. > > Yes, this part I buy into, just want to see how we can move forward > from there. The coplete nightmare is to introduce something into DT > that nails down a global GPIO numberspace... but I think that is not > the case atleast. > > > If the GPIO subsystem were reworked as you propose, this API could be > > reworked in exactly the same way, or if implemented after the rework, it > > would return whatever handle type was in use at the time. > > Yes, I just think we should return an opaque struct from day 1, so > just a little, little bit more to shield us. > > Yours, > Linus Walleij -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd.