pinctrl: sunxi: a733: irq_banks too small for port K

pinctrl: sunxi: a733: irq_banks too small for port K

[Norman Herms]

Andre, Linus,

Observation on "pinctrl: sunxi: add support for the Allwinner A733"
(Andre's series [2], now in linusw/devel for 7.4):
the A733 pinctrl description sets .irq_banks = 10, but PA does not
exist there, and prepare_function_table() in pinctrl-sunxi-dt.c counts
IRQ banks from PA, so PB is 1 and PK is 10. This is the same
numbering problem as in Pablo's thread [1].

With irq_banks = 10, PK (26 pins, bank 10):
 - sunxi_pinctrl_init_with_flags() allocates irq_array for 320
   entries but sunxi_pinctrl_build_state() writes PK to 320..345
   (104 bytes past the end) at every probe;
 - PK gets no parent interrupt and its hwirqs are outside the IRQ
   domain, so there are no GPIO interrupts on port K.

Measured on two Radxa Cubie A7S boards, same kernel (v7.3-rc5 plus
this series), once as is and once with irq_banks = 11. Requesting
edge detection on PK0 through the GPIO v2 character device fails
with ENXIO as is and works with irq_banks = 11. PB0 as a control
works in both cases.

KASAN (generic) does not report the overflow on either board. devres
rounds the allocation up to the whole kmalloc bucket, so the 104
bytes still lie inside the object. The out-of-bounds write is
therefore invisible to KASAN here.

Regarding Pablo's thread: with the convention Andre preferred there
(count from PA, placeholder interrupt in the DT), the A733 needs
irq_banks = 11, which also matches the binding (exactly 11
interrupts). 10 would only be right with the renumbering from
Pablo's patch, which is not applied.

I am not a kernel developer. The measurements were run on my boards
by AI agents, and the analysis was done with the help of an AI
assistant (Claude). This is a report, not a Tested-by.

[1] https://lore.kernel.org/linux-sunxi/20260929203634.32998-1-pmazzini@gmail.com/
[2] https://lore.kernel.org/linux-sunxi/20260910133519.459011-1-andre.przywara@arm.com/

Thanks,
Norman

Re: pinctrl: sunxi: a733: irq_banks too small for port K

[Andre Przywara]

On Sun, 04 Oct 2026 06:38:56 +0000
Norman Herms <dockseed@proton.me> wrote:

Hi Norman,

> Andre, Linus,
> 
> Observation on "pinctrl: sunxi: add support for the Allwinner A733"
> (Andre's series [2], now in linusw/devel for 7.4):
> the A733 pinctrl description sets .irq_banks = 10, but PA does not
> exist there, and prepare_function_table() in pinctrl-sunxi-dt.c counts
> IRQ banks from PA, so PB is 1 and PK is 10. This is the same
> numbering problem as in Pablo's thread [1].
> 

So I blame AI, but that below is a lot of words for a simple problem:
the number of IRQ banks should be 11, not 10. If we go with the dummy
IRQ. There are no official DTs for the A733 yet, so we need to decide
there, and I guess that depends on the outcome of the A523 problem.
I will send a fix after -rc1, with one of the solutions - unless you
beat me to it.

Thanks,
Andre

> With irq_banks = 10, PK (26 pins, bank 10):
>  - sunxi_pinctrl_init_with_flags() allocates irq_array for 320
>    entries but sunxi_pinctrl_build_state() writes PK to 320..345
>    (104 bytes past the end) at every probe;
>  - PK gets no parent interrupt and its hwirqs are outside the IRQ
>    domain, so there are no GPIO interrupts on port K.
> 
> Measured on two Radxa Cubie A7S boards, same kernel (v7.3-rc5 plus
> this series), once as is and once with irq_banks = 11. Requesting
> edge detection on PK0 through the GPIO v2 character device fails
> with ENXIO as is and works with irq_banks = 11. PB0 as a control
> works in both cases.
> 
> KASAN (generic) does not report the overflow on either board. devres
> rounds the allocation up to the whole kmalloc bucket, so the 104
> bytes still lie inside the object. The out-of-bounds write is
> therefore invisible to KASAN here.
> 
> Regarding Pablo's thread: with the convention Andre preferred there
> (count from PA, placeholder interrupt in the DT), the A733 needs
> irq_banks = 11, which also matches the binding (exactly 11
> interrupts). 10 would only be right with the renumbering from
> Pablo's patch, which is not applied.
> 
> I am not a kernel developer. The measurements were run on my boards
> by AI agents, and the analysis was done with the help of an AI
> assistant (Claude). This is a report, not a Tested-by.
> 
> [1] https://lore.kernel.org/linux-sunxi/20260929203634.32998-1-pmazzini@gmail.com/
> [2] https://lore.kernel.org/linux-sunxi/20260910133519.459011-1-andre.przywara@arm.com/
> 
> Thanks,
> Norman
>