[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VehagLZLTb4hC5J+w8JVUu-zYBDb+npeS8ZgadfF9MheA@mail.gmail.com>
Date: Fri, 18 Aug 2023 11:59:43 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Asmaa Mnebhi <asmaa@...dia.com>
Cc: linux-gpio@...r.kernel.org, linus.walleij@...aro.org,
bgolaszewski@...libre.com, brgl@...ev.pl,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] gpio: mlxbf3: Support add_pin_ranges()
On Fri, Aug 18, 2023 at 4:21 AM Asmaa Mnebhi <asmaa@...dia.com> wrote:
>
> Support add_pin_ranges() so that pinctrl_gpio_request() can be called.
> The GPIO value is not modified when the user runs the "gpioset" tool.
> This is because when gpiochip_generic_request is invoked by the gpio-mlxbf3
> driver, "pin_ranges" is empty so it skips "pinctrl_gpio_request()".
> pinctrl_gpio_request() is essential in the code flow because it changes the
> mux value so that software has control over modifying the GPIO value.
> Adding add_pin_ranges() creates a dependency on the pinctrl-mlxbf3.c driver.
Better now,
Reviewed-by: Andy Shevchenko <andy.shevchenko@...il.com>
...
> #define MLXBF3_GPIO_MAX_PINS_PER_BLOCK 32
> +#define MLXBF3_GPIO_MAX_PINS_BLOCK0 MLXBF3_GPIO_MAX_PINS_PER_BLOCK
> +#define MLXBF3_GPIO_MAX_PINS_BLOCK1 24
Since it's a fix for backporting, I'm not insisting to amend it now,
but can we actually drop the common define and use
#define MLXBF3_GPIO_MAX_PINS_BLOCK0 32
#define MLXBF3_GPIO_MAX_PINS_BLOCK1 24
and modify code accordingly, please?
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists