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

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

Hi Pratyush,

On Fri, 29 May 2020 at 15:39, Pratyush Yadav <p.yadav at 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