Re: gpio_request() vs __gpio_get()

[Lucas De Marchi <lucas.de.marchi@xxxxxxxxx>]

On Mon, Mar 9, 2015 at 6:21 AM, Alexandre Courbot <gnurou@xxxxxxxxx> wrote:
> Hi,
>
> On Mon, Mar 9, 2015 at 5:14 AM, Lucas De Marchi
> <lucas.de.marchi@xxxxxxxxx> wrote:
>> I was looking at drivers/leds/ in how it interacts with gpiolib. I see
>> that there's a new gpiod_* API.
>> "git grep gpio_request -- drivers/leds/" reveals quite a number of
>> users of gpio_request() and gpio_request_one().
>>
>> Am I right that these are going to be ported to the new gpiod_* API?
>> If yes, what would be the equivalent calls?  I thought it would be one
>> of the __gpiod_get() functions, but these would invariably fail if I
>> passed dev == NULL which is my case.
>
> Any new code should use the gpiod API. gpio_* are considered
> deprecated and unsafe, and users are encouraged to switch to gpiod
> (which is not always easy if they use GPIOs in unconventional ways).
>
> With gpiod, GPIO descriptors are obtained using one of the
> gpiod_get*() functions (do not call __gpiod_get directly) and must be
> assigned to the device and function using either Device Tree, ACPI, or
> platform tables. See Documentation/gpio/board.txt for how GPIOs are
> assigned, and Documentation/gpio/consumer.txt for how to use the gpiod
> API.

Ahhn. Ok. I'm converting a "userspace driver" that used to use the
sysfs interface to be a proper driver in kernel. The use case is for
boards with expansion headers like minnow, beaglebone etc.  In
userspace it would refer to a certain gpio index without any
"function" from DT/ACPI.

My doubt is how to map from this number to gpio_desc. I see there's
gpio_to_desc(), but then I'd need to use gpiod_request() (like
gpiolib-sysfs.c does) which is not exported for users outside of gpio
subsystem.

thanks

-- 
Lucas De Marchi
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html