drivers/pinctrl/bcm/pinctrl-bcm63268.c | 71 +++++++++++++++++++++++++- 1 file changed, 70 insertions(+), 1 deletion(-)
From: Kyle Hendry <kylehendrydev@gmail.com>
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@gmail.com>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
---
drivers/pinctrl/bcm/pinctrl-bcm63268.c | 71 +++++++++++++++++++++++++-
1 file changed, 70 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm63268.c b/drivers/pinctrl/bcm/pinctrl-bcm63268.c
index 80c2fc55ffa2..a98f57e64d1e 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm63268.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm63268.c
@@ -34,6 +34,7 @@
#define BCM63268_BASEMODE_VDSL_PHY_3 BIT(9) /* GPIOs 26/27 */
enum bcm63268_pinctrl_reg {
+ BCM63268_NONE,
BCM63268_LEDCTRL,
BCM63268_MODE,
BCM63268_CTRL,
@@ -242,6 +243,61 @@ static struct pingroup bcm63268_groups[] = {
BCM_PIN_GROUP(vdsl_phy3_grp),
};
+static const char * const gpio_groups[] = {
+ "gpio0",
+ "gpio1",
+ "gpio2",
+ "gpio3",
+ "gpio4",
+ "gpio5",
+ "gpio6",
+ "gpio7",
+ "gpio8",
+ "gpio9",
+ "gpio10",
+ "gpio11",
+ "gpio12",
+ "gpio13",
+ "gpio14",
+ "gpio15",
+ "gpio16",
+ "gpio17",
+ "gpio18",
+ "gpio19",
+ "gpio20",
+ "gpio21",
+ "gpio22",
+ "gpio23",
+ "gpio24",
+ "gpio25",
+ "gpio26",
+ "gpio27",
+ "gpio28",
+ "gpio29",
+ "gpio30",
+ "gpio31",
+ "gpio32",
+ "gpio33",
+ "gpio34",
+ "gpio35",
+ "gpio36",
+ "gpio37",
+ "gpio38",
+ "gpio39",
+ "gpio40",
+ "gpio41",
+ "gpio42",
+ "gpio43",
+ "gpio44",
+ "gpio45",
+ "gpio46",
+ "gpio47",
+ "gpio48",
+ "gpio49",
+ "gpio50",
+ "gpio51",
+};
+
static const char * const led_groups[] = {
"gpio0",
"gpio1",
@@ -394,6 +450,14 @@ static const char * const vdsl_phy_override_3_groups[] = {
"vdsl_phy_override_3_grp",
};
+#define BCM63268_GPIO_FUN(n) \
+ { \
+ .name = #n, \
+ .groups = n##_groups, \
+ .num_groups = ARRAY_SIZE(n##_groups), \
+ .reg = BCM63268_NONE, \
+ }
+
#define BCM63268_LED_FUN(n) \
{ \
.name = #n, \
@@ -428,6 +492,7 @@ static const char * const vdsl_phy_override_3_groups[] = {
}
static const struct bcm63268_function bcm63268_funcs[] = {
+ BCM63268_GPIO_FUN(gpio),
BCM63268_LED_FUN(led),
BCM63268_MODE_FUN(serial_led_clk),
BCM63268_MODE_FUN(serial_led_data),
@@ -542,6 +607,9 @@ static int bcm63268_pinctrl_set_mux(struct pinctrl_dev *pctldev,
bcm63268_set_gpio(pc, pg->pins[i]);
switch (f->reg) {
+ case BCM63268_NONE:
+ reg = 0;
+ break;
case BCM63268_LEDCTRL:
reg = BCM63268_LED_REG;
mask = BIT(pg->pins[0]);
@@ -567,7 +635,8 @@ static int bcm63268_pinctrl_set_mux(struct pinctrl_dev *pctldev,
return -EINVAL;
}
- regmap_update_bits(pc->regs, reg, mask, val);
+ if (reg)
+ regmap_update_bits(pc->regs, reg, mask, val);
return 0;
}
--
2.39.5
Hi, On Tue, Dec 24, 2024 at 11:41 AM Álvaro Fernández Rojas <noltari@gmail.com> wrote: > > From: Kyle Hendry <kylehendrydev@gmail.com> > > 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@gmail.com> > Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> 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
On 2024-12-30 08:42, Jonas Gorski wrote: > Hi, > > On Tue, Dec 24, 2024 at 11:41 AM Álvaro Fernández Rojas > <noltari@gmail.com> wrote: >> From: Kyle Hendry <kylehendrydev@gmail.com> >> >> 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@gmail.com> >> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> > > 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
El vie, 3 ene 2025 a las 4:04, Kyle Hendry (<kylehendrydev@gmail.com>) 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@gmail.com> wrote: > >> From: Kyle Hendry <kylehendrydev@gmail.com> > >> > >> 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@gmail.com> > >> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> > > > > 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.
El sáb, 4 ene 2025 a las 16:44, Álvaro Fernández Rojas (<noltari@gmail.com>) escribió: > > El vie, 3 ene 2025 a las 4:04, Kyle Hendry (<kylehendrydev@gmail.com>) 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@gmail.com> wrote: > > >> From: Kyle Hendry <kylehendrydev@gmail.com> > > >> > > >> 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@gmail.com> > > >> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> > > > > > > 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... Best regards, Álvaro.
On Sat, Jan 4, 2025 at 6:02 PM Álvaro Fernández Rojas <noltari@gmail.com> wrote: > > El sáb, 4 ene 2025 a las 16:44, Álvaro Fernández Rojas > (<noltari@gmail.com>) escribió: > > > > El vie, 3 ene 2025 a las 4:04, Kyle Hendry (<kylehendrydev@gmail.com>) 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@gmail.com> wrote: > > > >> From: Kyle Hendry <kylehendrydev@gmail.com> > > > >> > > > >> 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@gmail.com> > > > >> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> > > > > > > > > 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
El sáb, 4 ene 2025 a las 20:32, Jonas Gorski (<jonas.gorski@gmail.com>) escribió: > > On Sat, Jan 4, 2025 at 6:02 PM Álvaro Fernández Rojas <noltari@gmail.com> wrote: > > > > El sáb, 4 ene 2025 a las 16:44, Álvaro Fernández Rojas > > (<noltari@gmail.com>) escribió: > > > > > > El vie, 3 ene 2025 a las 4:04, Kyle Hendry (<kylehendrydev@gmail.com>) 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@gmail.com> wrote: > > > > >> From: Kyle Hendry <kylehendrydev@gmail.com> > > > > >> > > > > >> 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@gmail.com> > > > > >> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> > > > > > > > > > > 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 You're totally right, after adding request() and free() functions to gpio-regmap it's now working without this patch because bcm63268_gpio_request_enable() is now properly called: 1. gpio-keys-polled [ 4.052132] gpio_button_hotplug: loading out-of-tree module taints kernel. [ 4.060657] bcm63268-pinctrl 100000d0.pinctrl: request pin 34 (gpio34) for 100000d0.pinctrl:546 [ 4.069704] bcm63268_gpio_request_enable: range=99a2e0ae offset=34 [ 4.076158] bcm63268-pinctrl 100000d0.pinctrl: request pin 35 (gpio35) for 100000d0.pinctrl:547 [ 4.085135] bcm63268_gpio_request_enable: range=99a2e0ae offset=35 2. gpio-leds [ 4.480190] bcm63268-pinctrl 100000d0.pinctrl: request pin 0 (gpio0) for 100000d0.pinctrl:512 [ 4.489078] bcm63268_gpio_request_enable: range=99a2e0ae offset=0 [ 4.495747] bcm63268-pinctrl 100000d0.pinctrl: request pin 1 (gpio1) for 100000d0.pinctrl:513 [ 4.504600] bcm63268_gpio_request_enable: range=99a2e0ae offset=1 3. userspace gpio export root@OpenWrt:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 512-563, parent: platform/100000d0.pinctrl, 100000d0.pinctrl: gpio-512 ( |red:mobile ) out lo gpio-513 ( |green:mobile ) out lo gpio-546 ( |wps ) in hi ACTIVE LOW gpio-547 ( |reset ) in hi ACTIVE LOW root@OpenWrt:~# echo 545 > /sys/class/gpio/export [ 33.437477] bcm63268-pinctrl 100000d0.pinctrl: request pin 33 (gpio33) for 100000d0.pinctrl:545 [ 33.446503] bcm63268_gpio_request_enable: range=99a2e0ae offset=33 root@OpenWrt:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 512-563, parent: platform/100000d0.pinctrl, 100000d0.pinctrl: gpio-512 ( |red:mobile ) out lo gpio-513 ( |green:mobile ) out lo gpio-545 ( |sysfs ) in hi gpio-546 ( |wps ) in hi ACTIVE LOW gpio-547 ( |reset ) in hi ACTIVE LOW OpenWrt test source code: https://github.com/Noltari/openwrt/commits/bmips-gpio-tests https://github.com/Noltari/openwrt/commit/d3bc7610c8fe8f713a3e47ed8368b6aa220ae763 Linux test source code: https://github.com/Noltari/linux/commits/gpio-regmap-pinctrl-request-free https://github.com/Noltari/linux/commit/2d0ebb8cad8084e932f40f3f69d4e931b2316aa4 @Linus I assume that adding those functions may cause issues to other drivers and maybe we need to add some logic to add them dynamically based on a new gpio_regmap_config parameter? Best regards, Álvaro.
On Tue, Dec 24, 2024 at 11:36 AM Álvaro Fernández Rojas <noltari@gmail.com> wrote: > From: Kyle Hendry <kylehendrydev@gmail.com> > > 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@gmail.com> > Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> This looks right to me, but can we get some review from some of the Broadcom people? (Hm it's MIPS so I guess that means Florian.) Yours, Linus Walleij
El vie, 27 dic 2024 a las 17:17, Linus Walleij (<linus.walleij@linaro.org>) escribió: > > On Tue, Dec 24, 2024 at 11:36 AM Álvaro Fernández Rojas > <noltari@gmail.com> wrote: > > > From: Kyle Hendry <kylehendrydev@gmail.com> > > > > 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@gmail.com> > > Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> > > This looks right to me, but can we get some review from some > of the Broadcom people? (Hm it's MIPS so I guess that means > Florian.) > > Yours, > Linus Walleij Thanks Linus :) BTW, I think that other bcm63xx pinctrl drivers need that fix too (or at least bcm6362). Can anyone confirm it? Best regards, Álvaro.
© 2016 - 2026 Red Hat, Inc.