[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75Vdp9TYTod6UBLxG_YrT_vD4azfyrM9dTrau8CPJuH_vrQ@mail.gmail.com>
Date: Wed, 16 Aug 2023 18:49:27 +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 v2 2/2] gpio: mlxbf3: Support add_pin_ranges()
On Wed, Aug 16, 2023 at 6:45 PM 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.
...
> v1->v2:
> - No changes.
Is this correct?
...
> +static int mlxbf3_gpio_add_pin_ranges(struct gpio_chip *chip)
> +{
> + unsigned int id = 0;
> + int ret;
> +
> + if (chip->ngpio % MLXBF3_GPIO_MAX_PINS_PER_BLOCK)
> + id = 1;
This id calculation seems wrong to me as I said in v1 review.
Why do you think the above is what you want and not just working by luck?
> + return gpiochip_add_pin_range(chip, "MLNXBF34:00",
> + chip->base, id * MLXBF3_GPIO_MAX_PINS_PER_BLOCK,
> + chip->ngpio);
> +}
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists