laptop-kernel/drivers/pinctrl/sunxi, 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

pinctrl: sunxi: A523: fix voltage withstand encoding

2026-09-16T17:07:42Z

The Allwinner A523 uses the same GPIO voltage "withstand" programming (setting the input level voltage thresholds) as the previous SoCs, but for some odd reason inverts the encoding of 1.8V vs. 3.3V. Add a new bias voltage type to note this difference, and select it for the A523. At the same time also use the newer "CTL" version, which in addition allows to turn off the withstand programming for I/O voltages other than exact 1.8V or 3.3V (for instance for 2.5V sometimes used for Ethernet PHYs). The A523 has that enable register, but didn't use it so far. This fixes eMMC and reportedly Ethernet operation on some A523 boards. Fixes: 648be4cd9517 ("pinctrl: sunxi: Add support for the Allwinner A523") Signed-off-by: Andre Przywara Tested-by: Per Larsson Tested-by: Juan Manuel Lopez Carrillo Reviewed-by: Chen-Yu Tsai Tested-by: Chen-Yu Tsai # Fixes eMMC on Orange Pi 4A Signed-off-by: Linus Walleij

pinctrl: sunxi: keep a shadow copy of the data register output latches

2026-09-16T13:03:50Z

On Allwinner SoCs, reading a bank's data register returns the pin level, not the output latch, for pins that are muxed as inputs. Writing a GPIO therefore corrupts the output latches of all input-muxed pins in the same bank: the read-modify-write in sunxi_pinctrl_gpio_set() reads back their pin levels and writes those into their latches. This breaks emulated open-drain lines (e.g. a bit-banged I2C bus from i2c-gpio). Such a line is released high by muxing it as input and letting the pull-up raise it, so any concurrent GPIO write in the same bank stores 1 into its latch. Driving the line low afterwards is a non-atomic data-then-mux sequence in sunxi_pinctrl_gpio_direction_output(); if the poisoning write lands between the two steps, the pin actively drives high (push-pull) instead of low. Observed in practice as sporadic glitches on a T507 board bit-banging I2C on port E while other PE GPIOs are toggled. On a scope the failure is unmistakable: on a clock pulse where SCL should fall to GND, the line instead steps *above* its idle high level for the whole low phase — the pad drives a strong push-pull 3.3 V high, higher than the level the pull-up sustains on the loaded bus — before the next transition recovers it. The same can hit SDA, corrupting data instead of clocks. Steps to reproduce on any sunxi board with a bit-banged (i2c-gpio) bus: # background: toggle any other GPIO of the same bank, e.g. line 21 gpioset -c --toggle 100us 21=0 & # foreground: keep the bit-banged bus busy while :; do i2cdetect -y 0x50 0x57; done # watch SCL/SDA with a scope or logic analyzer: sporadic clock-low # phases driven high (above the pull-up level) instead of low The bank spinlock cannot help: the racing write is a perfectly valid whole-register RMW that faithfully writes back what the hardware returned. There are no set/clear registers on this IP to write a single bit atomically. Fix it the same way gpio-mmio handles hardware whose data register read does not return the output latch: keep a shadow copy of each bank's latches, base the read-modify-write on the shadow, and only write the register. The shadow is seeded from the hardware at probe time so pins left in output mode by the bootloader keep their state. Pins that reach output mode through the gpiolib paths write their value (and thereby their shadow bit) before the mux switch in sunxi_pinctrl_gpio_direction_output(); pins muxed to gpio_out directly through a pinmux node bypass that path, so sunxi_pmx_set() refreshes their shadow bit from the latch (readable once the pin is in output mode) to keep them driving their pre-existing level. Seeding the shadow reads the PIO registers at probe time, which requires the bus clock to be enabled. The clock was only requested at the very end of probe, after devm_pinctrl_register() had already claimed the pin hogs described in the device tree - which mux pins, and thus access registers, with the clock still gated. Move the request ahead of both. Boards whose bootloader leaves the PIO clock running are unaffected, which is why the pre-existing hog problem has gone unnoticed since commit 950707c0eb5c ("pinctrl: sunxi: add clock support"). Fixes: df7b34f4c3d2 ("pinctrl: sunxi: Fix gpio_set behaviour") Cc: stable@vger.kernel.org Signed-off-by: Ilya Titov Signed-off-by: Linus Walleij

pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag

2026-06-11T11:47:52Z

The Allwinner A10 and H3 SoCs cannot read the state of a GPIO line when that line is muxed for IRQ triggering (muxval 6), but only if it's explicitly muxed for GPIO input (muxval 0). Other SoCs do not show this behaviour, so we added a optional workaround, triggered by a quirk bit, which triggers remuxing the pin when it's configured for IRQ, while we need to read its value. For some reasons this quirk flag was copied over to newer SoCs, even though they don't show this behaviour, and the GPIO data register reflects the true GPIO state even with a pin muxed to IRQ trigger. Remove the unneeded quirk from the A523 family, where it's definitely not needed (confirmed by experiments), and where it actually breaks, because the workaround is not compatible with the newer generation pinctrl IP used in that chip. Together with a DT change this fixes GPIO IRQ operation on the A523 family of SoCs, as for instance used for the SD card detection. Signed-off-by: Andre Przywara Fixes: b8a51e95b376 ("pinctrl: sunxi: Add support for the secondary A523 GPIO ports") Reviewed-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Signed-off-by: Linus Walleij

pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path

2026-05-05T09:25:46Z

In the error path of sunxi_pmx_request(), the code calls regulator_put(s_reg->regulator) to release the regulator. However, s_reg->regulator is only assigned after a successful regulator_enable(). This causes a memory leak: the regulator obtained via regulator_get() is never properly released when regulator_enable() fails. Fixes: dc1445584177 ("pinctrl: sunxi: Fix and simplify pin bank regulator handling") Signed-off-by: Felix Gu Reviewed-by: Andre Przywara Signed-off-by: Linus Walleij

pinctrl: sunxi: fix gpiochip_lock_as_irq() failure when pinmux is unknown

2026-03-23T13:23:09Z

Fixes kernel hang during boot due to inability to set up IRQ on AXP313a. The issue is caused by gpiochip_lock_as_irq() which is failing when gpio is in uninitialized state. Solution is to set pinmux to GPIO INPUT in sunxi_pinctrl_irq_request_resources() if it wasn't initialized earlier. Tested on Orange Pi Zero 3. Fixes: 01e10d0272b9 ("pinctrl: sunxi: Implement gpiochip::get_direction()") Reviewed-by: Andre Przywara Reviewed-by: Chen-Yu Tsai Signed-off-by: Michal Piekos Signed-off-by: Linus Walleij

pinctrl: sunxi: pass down flags to pinctrl routines

2026-03-23T13:23:08Z

Recent changes in the Allwinner pinctrl/GPIO IP made us add some quirks, which the new SoCs (A523 family) need to use. We now have a comfortable "flags" field on the per-SoC setup side, to tag those quirks we need, but were translating those flag bits into specific fields for runtime use, in the init routine. Now the newest Allwinner GPIO IP adds even more quirks and exceptions, some of a boolean nature. To avoid inventing various new boolean flags for the runtime struct sunxi_pinctrl, let's just directly pass on the flags variable used by the setup code, so runtime can check for those various quirk bits directly. Rename the "variant" member to "flags", and directly copy the value from the setup code into there. Move the variant masking from the init routine to the functions which actually use the "variant" value. This mostly paves the way for the new A733 IP generation, which needs more quirks to be checked at runtime. Reviewed-by: Chen-Yu Tsai Signed-off-by: Andre Przywara Signed-off-by: Michal Piekos Signed-off-by: Linus Walleij

pinctrl: sunxi: Implement gpiochip::get_direction()

2026-02-24T09:51:53Z

After commit 471e998c0e31 ("gpiolib: remove redundant callback check"), a warning will be printed if the gpio driver does not implement this callback. The warning was added in commit e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()"), but was masked by the "redundant" check. The warning can be triggered by any action that calls the callback, such as dumping the GPIO state from /sys/kernel/debug/gpio. Implement it for the sunxi driver. This is simply a matter of reading out the mux value from the registers, then checking if it is one of the GPIO functions and which direction it is. Signed-off-by: Chen-Yu Tsai Reviewed-by: Jernej Skrabec Reviewed-by: Bartosz Golaszewski Reviewed-by: Andre Przywara Signed-off-by: Linus Walleij

Convert more 'alloc_obj' cases to default GFP_KERNEL arguments

2026-02-22T04:03:00Z

This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51Z

This was done entirely with mindless brute force, using git grep -l '\