[PATCH v2 0/2] gpio: Add a managed API

[Simon Glass <sjg@chromium.org>]

Hi Pratyush,

On Fri, 29 May 2020 at 15:39, Pratyush Yadav <p.yadav@ti.com> wrote:
>
> Hi,
>
> This is a re-submission of Jean-Jacques' earlier work in October last
> year. It can be found at [0]. The goal is to facilitate porting drivers
> from the linux kernel. Most of the series will be about adding managed
> API to existing infrastructure (GPIO, reset, regmap (already
> submitted)).
>
> This particular series is about GPIOs. It adds a managed API using the
> API as Linux. To make it 100% compatible with linux, there is a small
> deviation from u-boot's way of naming the gpio lists: the managed
> equivalent of gpio_request_by_name(..,"blabla-gpios", ...) is
> devm_gpiod_get_index(..., "blabla", ...)
>
> Changes in v2:
> - The original series had a patch that checked for NULL pointers in the
>   core GPIO functions. The checks were needed because of the addition of
>   devm_gpiod_get_index_optional() which would return NULL when when no
>   GPIO was assigned to the requested function. This is convenient for
>   drivers that need to handle optional GPIOs.
>
>   Simon argued that those should be behind a Kconfig option because of
>   code size concerns. He also argued against implicit return in the
>   macro that checked for the optional GPIOs.
>
>   This submission removes the controversial patch so that base
>   functionality can get unblocked.
>
>   We still need to take a stance on who is responsible for the NULL
>   check: the driver or the GPIO core? Do we want to trust drivers to
>   take care of the NULL checks, or do we want to distrust them and make
>   sure they don't send us anything bogus in the GPIO core. For now the
>   responsibility lies on the drivers by default. I will send a separate
>   RFC of the NULL check patch and we can probably discuss the issue
>   there.
>
> [0] https://patchwork.ozlabs.org/project/uboot/cover/20191001115130.18886-1-jjhiblot at ti.com/
>
> Jean-Jacques Hiblot (2):
>   drivers: gpio: Add a managed API to get a GPIO from the device-tree
>   test: gpio: Add tests for the managed API
>
>  arch/sandbox/dts/test.dts  |  10 ++++
>  drivers/gpio/gpio-uclass.c |  70 +++++++++++++++++++++++++
>  include/asm-generic/gpio.h |  47 +++++++++++++++++
>  test/dm/gpio.c             | 102 +++++++++++++++++++++++++++++++++++++
>  4 files changed, 229 insertions(+)
>
> --
> 2.26.2
>

The first question I have is why do you want to allocate the gpio_desc
and return it? Doesn't the caller have a place for that in its private
struct?

Regards,
Simon