Thank you for the feedback Linus! I will address your comments in my next patch. Best, Asmaa -----Original Message----- From: Linus Walleij <linus.walleij@xxxxxxxxxx> Sent: Wednesday, May 18, 2022 9:51 AM To: Asmaa Mnebhi <asmaa@xxxxxxxxxx> Cc: andy.shevchenko@xxxxxxxxx; bgolaszewski@xxxxxxxxxxxx; linux-gpio@xxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx Subject: Re: [PATCH v1 1/1] Add driver for Mellanox BlueField-3 GPIO controller Importance: High 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
