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
