Re: [PATCH v1 1/1] Add driver for Mellanox BlueField-3 GPIO controller

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Mon, May 16, 2022 at 3:00 PM Asmaa Mnebhi <asmaa@xxxxxxxxxx> wrote:

> So these GPIO pins are assigned one specific HW functionality on the boards
>  and software should never change them.
>
> By default, for security purposes, I think we shouldn't let the user have the option
> to control the GPIO pins since they have a specific HW functionality.
>
> But for bringup/debug purposes, we would like to support the option of software
> being able to change these pin values. We also might have customers that choose
> to change the default HW connection of a certain GPIO pin and connect it to
> control their LEDs for instance.

The fact that the usecase is bringup/debug does not mean we cut
corners and do "quick fixes". The proper APIs have to be implemented,
the alternative is to not submit the driver at all.

What I hear is that these pins have two modes:

1. Used for a device (I2C etc)
2. Used as GPIO by setting a bit in YU_GPIO_FW_CONTROL_SET

This is two pin control multiplexing states already.

So this should have a simple pin control driver as back-end with
the GPIO as front end. A shortcut to enabling pins into GPIO
mode can be provided using .gpio_request_enable() from
struct pinmux_ops.

Please refer to
https://docs.kernel.org/driver-api/pin-control.html

I know this means more work and is kind of complex. But drivers/pinctrl
has a lot of examples you can follow, for example
drivers/pinctrl/pinctrl-sx150x.c and other simple multipurpose
chips.

Yours,
Linus Walleij