laptop-kernel/drivers/pinctrl, branch master

pinctrl: sunxi: dt: do not accumulate npins across probe attempts

2026-10-12T09:30:12Z

init_pins_table() adds to npins in the driver's static descriptor, so after a probe deferral the count doubles and the next probe fails with "pin 0 already registered". Reset it first. Signed-off-by: Pablo Mazzini Fixes: f5e2cd34b12f ("pinctrl: sunxi: allow reading mux values from DT") Reviewed-by: Andre Przywara Signed-off-by: Linus Walleij

Merge tag 'pinctrl-qcom-fixes-for-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into fixes

2026-10-08T11:38:23Z

Qualcomm pin control fixes for v7.3-rc7 - fix intr_target_width in several qualcomm pinctrl drivers - make direction changes exclusive in pinctrl-spmi-gpio - fix function issues in pinctrl-ipq5018 - add missing OF module alias to pinctrl-ipq5210 - split QUP1 SE2/SE3 into lane-pair functions Signed-off-by: Linus Walleij

pinctrl: amd: Clear S4 wake bits when firmware has _AEI

2026-10-07T11:26:54Z

Commit ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe") preserves firmware-programmed S4 wake sources because some PCIe devices rely on them for Wake-on-LAN. The system that motivated that change does not expose ACPI GPIO events through _AEI. On a Chuwi CoreBook Plus, firmware exposes _AEI but also leaves the S4/S5 wake bit set for GPIO 24. This causes the machine to power back on immediately after shutdown even though Wake-on-LAN is not enabled. GPIO register dumps show that the only relevant difference is bit 15 on GPIO 24. Clearing that bit makes the machine remain off. GPIO 24 is not itself listed in _AEI, so _AEI is not a per-pin indication of which pins the OS manages; it is a platform level signal of which wake model the firmware follows. Use that signal to decide what to clear. Continue clearing S0i3/S3 bits on every system. Clear S4 bits when firmware exposes _AEI, indicating that the platform hands GPIO events to the OS, but preserve S4 bits when _AEI is absent so that firmware-programmed sources such as PCIe PME that bypass the GPIO IRQ wake API keep working. A platform that exposes _AEI for some pins while routing a wake capable device through a raw GPIO not listed in _AEI would lose that wake source unless firmware re-arms it during the sleep transition. No such system has been reported. Fixes: ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe") Reported-by: Olzhas Marat Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222041 Cc: stable@vger.kernel.org Tested-by: Olzhas Marat Reviewed-by: Shyam Sundar S K Signed-off-by: Mario Limonciello Signed-off-by: Linus Walleij

pinctrl: qcom: ipq5018: replace gcc_plltest with pwm2 on gpio12

2026-10-06T08:05:09Z

The pingroup table has gcc_plltest at function 5 of gpio12 and does not offer pwm2 on that pin, so the pinmux core rejects a request for pwm2 on gpio12 as an invalid group. On the hardware, function 5 of gpio12 carries the PWM2 output: the Xiaomi AX3000T v2 drives its blue status LED from PWM2 on gpio12. The vendor kernel shipped on that router (Linux 4.4, stock firmware 2.0.28) has pwm2 in this slot. Its pingroup table, as read from the firmware image, lists these functions for gpio12: gpio, blsp0_spi, blsp0_i2c, blsp1_uart0, _, pwm2, qdss_tracedata_a, _, _, _ and has pwm3 at function 4 of gpio13, matching commit c6c159fcdb4e ("pinctrl: qcom: ipq5018: add missing pwm3 function on gpio13"). Measured on the board: with gpio12 set to each of the 16 function values in turn, and PWM2 held at 0% and then at 100% duty, the pad level read back from GPIO_IN follows PWM2 only at function 5. There it does not follow PWM channels 0, 1 or 3, and the LED switches with PWM2. Functions 4 and 7, which the table leaves empty, do not carry PWM2. Put pwm2 in function 5 of gpio12 and list gpio12 in pwm2_groups. Drop gpio12 from gcc_plltest_groups: none of its functions is gcc_plltest any more, and selecting it would trigger the WARN_ON() in msm_pinmux_set_mux(). Fixes: 725d1c891658 ("pinctrl: qcom: Add IPQ5018 pinctrl driver") Assisted-by: LLM Signed-off-by: Adriel Santos Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20261002160958.908424-1-adriel@adriel.eu Signed-off-by: Bartosz Golaszewski

pinctrl: qcom: ipq5018: update PWM groups and corresponding pin functions

2026-10-01T12:32:42Z

On multiple Linksys routers, GPIOs 1, 30, and 46 drive the PWM LED on the PWM1, PWM3, and PWM0 channels, respectively. Update the corresponding PWM groups to include these GPIOs and allocate the PWM functions to empty slots in the relevant pin groups. Signed-off-by: George Moussalem Link: https://patch.msgid.link/20260928-ipq5018-pwm-functions-v2-1-87bbcd706bc6@outlook.com Signed-off-by: Bartosz Golaszewski

pinctrl: qcom: spmi-gpio: make direction changes exclusive

2026-09-28T17:15:24Z

Neither direction callback clears the opposite buffer: .direction_output() only packs PIN_CONFIG_LEVEL and .direction_input() only packs PIN_CONFIG_INPUT_ENABLE. As pmic_gpio_populate() seeds input_enabled and output_enabled from MODE_CTL, a pad left in DIGITAL_INPUT[_OUTPUT] by the bootloader ends up in DIGITAL_INPUT_OUTPUT whichever direction is requested. That leaves an input still driving the line, and makes pmic_gpio_get_direction() report an output as an input, which breaks consumers that read the direction back: reg-fixed-voltage regulator-wcn-core-vm-1p35: setup of GPIO (default) failed: -1 reg-fixed-voltage regulator-wcn-core-vm-1p35: error -EPERM: can't get GPIO Pack the opposite buffer's PIN_CONFIG_*_ENABLE along with the requested direction, so MODE_CTL becomes DIGITAL_INPUT or DIGITAL_OUTPUT, never both. pmic_gpio_config_set() writes the registers once after walking all configs, so this stays a single write. An open-drain or open-source output is the exception: it only drives one rail, so pmic_gpio_get() needs the input buffer to sample the line rather than return the value last written. Program the input buffer from pad->buffer_type, which gpiolib has already updated via PIN_CONFIG_DRIVE_OPEN_DRAIN, and key pmic_gpio_get_direction() off output_enabled so such pads still read back as outputs. Genuinely bidirectional pads can still be described that way through pinconf; the gpiolib callbacks now mean what gpiolib says they mean. Fixes: 263447532463 ("pinctrl: qcom: spmi-gpio: implement .get_direction()") Assisted-by: LLM Reviewed-by: Linus Walleij Signed-off-by: Shawn Guo Link: https://patch.msgid.link/20260927010913.1212600-1-shengchao.guo@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski

Merge tag 'v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into pinctrl-qcom/for-current

2026-09-28T17:15:10Z

Linux 7.3-rc5

pinctrl: qcom: ipq5018: add missing pwm3 function on gpio13

2026-09-22T08:13:19Z

GPIO13 supports the PWM3 function at mux select value 4, but the pingroup table leaves that slot empty and gpio13 is not listed in pwm3_groups. Selecting pwm3 on gpio13 is therefore rejected by the pinmux core: ipq5018-tlmm: invalid group "gpio13" for function "pwm3" The GL.iNet GL-X2000 drives its fan from PWM3 on this pin, and the vendor firmware muxes it with select value 4: gpio13 : out low func4 8mA no pull Add pwm3 to the fourth function slot of gpio13 and list gpio13 in pwm3_groups. With this the pin muxes as expected: pin 13 (GPIO_13): device 1941010.pwm function pwm3 group gpio13 Fixes: 725d1c891658 ("pinctrl: qcom: Add IPQ5018 pinctrl driver") Signed-off-by: Gilberto Conde Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260921093419.2870168-1-gilbertorconde@gmail.com Signed-off-by: Bartosz Golaszewski

pinctrl: tegra238: Fix register bank for AON pin groups

2026-09-20T22:06:32Z

The AON pin controller has a single register region and therefore, the bank defined in the tegra238_functions[] and tegra238_aon_groups[] for the AON pin groups must be 0. However, commit 25cac7292d49 ("pinctrl: tegra: Add Tegra238 pinmux driver") incorrectly specified the bank for these pins as 1 and not 0. This means that in the tegra_pinctrl_probe() function we use an invalid index when accessing the pmx->regs[] array which causes an incorrect address to be used for accessing the pinmux registers. Fix this by correcting the bank for the AON pin groups. Fixes: 25cac7292d49 ("pinctrl: tegra: Add Tegra238 pinmux driver") Signed-off-by: Prathamesh Shete Signed-off-by: Linus Walleij

pinctrl: qcom: ipq5210: Publish the OF module alias

2026-09-18T17:00:35Z

The IPQ5210 TLMM platform driver can be a module and matches through ipq5210_tlmm_of_match. This table is not published for OF modalias matching. Publish the existing table, preserving arch_initcall ordering and the shared MSM pinctrl probe. Fixes: a549fe22376f ("pinctrl: qcom: Introduce IPQ5210 TLMM driver") Signed-off-by: hpp.iscas Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260905134340.67477-1-hppiscas@163.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Linus Walleij