On Sat, Jan 4, 2025 at 6:02 PM Álvaro Fernández Rojas <noltari@xxxxxxxxx> wrote: > > El sáb, 4 ene 2025 a las 16:44, Álvaro Fernández Rojas > (<noltari@xxxxxxxxx>) escribió: > > > > El vie, 3 ene 2025 a las 4:04, Kyle Hendry (<kylehendrydev@xxxxxxxxx>) escribió: > > > > > > On 2024-12-30 08:42, Jonas Gorski wrote: > > > > Hi, > > > > > > > > On Tue, Dec 24, 2024 at 11:41 AM Álvaro Fernández Rojas > > > > <noltari@xxxxxxxxx> wrote: > > > >> From: Kyle Hendry <kylehendrydev@xxxxxxxxx> > > > >> > > > >> There is no guarantee that the bootloader will leave the pin configuration > > > >> in a known default state, so pinctrl needs to be explicitly set in some > > > >> cases. This patch adds a gpio function for drivers that need it, i.e. > > > >> gpio-leds. > > > >> > > > >> Signed-off-by: Kyle Hendry <kylehendrydev@xxxxxxxxx> > > > >> Signed-off-by: Álvaro Fernández Rojas <noltari@xxxxxxxxx> > > > > > > > > bcm63268-pinctrl implements pinmux_ops::gpio_request_enable(), which > > > > should automatically set any requested GPIO pin to the GPIO function, > > > > so explicitly requesting the gpio function for a pin should not be > > > > needed. Is this not enough? > > > > > > > > Best Regards, > > > > Jonas > > > > > > > > > > > I assumed that as well, but nothing I tried worked with gpio-leds. > > > gpiochip_generic_request() does call gpio_request_enable(), but gpio-leds > > > uses devm_fwnode_gpiod_get() which looks like a different code path. The > > > only place it seems to be configuring the gpio is in create_gpio_led() > > > where it needs a pinctl node in the device tree. That's just my reading > > > of the code, though. I haven't set up a ftrace to verify it. > > > > > > Best Regards, > > > Kyle > > > > As Kyle pointed out it's not enough and gpio_request_enable() doesn't > > get called from gpio-leds. > > I will try to investigate this and report back. > > > > Best regards, > > Álvaro. > > I've performed some tests and so far I haven't been able to get > bcm63268_gpio_request_enable() called. > > Even exporting a gpio from userspace doesn't trigger that function, > which seems strange because in that case we won't have a "gpio" > function on the pinctrl for that gpio, even with this patch... On a first glance it looks like that regmap-gpio does not populate gpio_chip::request and gpio_chip:free, so the gpio subsystem is not aware that it needs to request anything. Not sure if just using gpiolib_generic_request() / gpiolib_generic_free() is fine. Currently on vacation, so no hardware to test anything at hand ;-) Best Regards, Jonas