sc16is75x-spi overlay: GPIO24 (int_pin) left as output on Pi 5/RP1, causing a permanent ~16-17k interrupts/sec CPU-eating storm — same root cause as #6106, but the fix from #6111/#6114 doesn't apply/work here

[GregerA]

Summary

arch/arm/boot/dts/overlays/sc16is75x-spi-overlay.dts — the generic
SC16IS750/752 SPI overlay (as opposed to the now-removed
sc16is752-spi0-overlay.dts this appears to have superseded) — leaves
its int_pin GPIO configured as an actively-driven output, not an
input, on a Raspberry Pi 5. This causes a continuous, ~16,600-16,900
interrupts/sec storm on the SPI IRQ line, pegging one CPU core at
~30-33% permanently, from boot.

This looks like the same underlying issue as #6106 ("high cpu with
2-CH RS485 HAT Interface-Card and pi5"), which @pelwell correctly
diagnosed and fixed via #6111 (further corrected by #6114) — but that
fix touched sc16is752-spi0-overlay.dts, sc16is752-spi1-overlay.dts,
sc16is750-i2c-overlay.dts, and sc16is752-i2c-overlay.dts, not
sc16is75x-spi-overlay.dts. And critically, sc16is75x-spi-overlay.dts
already contains the equivalent of that fix (see below) — yet the
bug still reproduces on current kernel/firmware. So either this specific
overlay file was never covered by the original fix and needs the same
change applied, or (more concerning) the fix pattern that verifiably
worked in April 2024 no longer works on current RP1 firmware/kernel —
i.e. a possible regression in RP1's handling of the legacy
brcm,pins/brcm,function/brcm,pull pinctrl properties.

Environment

• Raspberry Pi 5 Model B Rev 1.1 (reproduced on two separate physical
  units)
• Kernel: 6.18.34+rpt-rpi-2712 (fully up to date via apt-get upgrade
  as of 2026-07-25)
• RP1 bootloader/EEPROM: updated via rpi-eeprom-update -a from the
  2026-05-11 build to the 2026-05-26 build — no change in behaviour
• Overlay in use: dtoverlay=sc16is75x-spi,sc16is752,spi0-0,int_pin=24,xtal=14745600
  (also reproduces identically with a hand-patched IRQ_TYPE_LEVEL_LOW
  variant of the same overlay instead of the stock EDGE_FALLING)
• Chip: NXP SC16IS752 (dual UART + GPIO expander over SPI)

What we already have on the pin (this is the part that should fix it, per #6111)

Decompiling our installed sc16is75x-spi.dtbo:

sc16is750@0 {
    ...
    interrupt-parent = <gpio>;
    interrupts = <24 IRQ_TYPE_EDGE_FALLING>;
    pinctrl-0 = <&sc16is75x_pins>;
    pinctrl-names = "default";
    ...
};

fragment@3 {
    target = <&gpio>;
    __overlay__ {
        sc16is75x_pins: sc16is75x_pins@18 {
            brcm,pins = <24>;
            brcm,function = <BCM2835_FSEL_GPIO_IN>;  /* = 0, input */
            brcm,pull = <BCM2835_PUD_OFF>;
        };
    };
};

This is functionally identical to what #6111 added to
sc16is752-spi0-overlay.dts (pinctrl-0 = <&int_pins>; +
brcm,function = <0>; /* in */). Despite that, on Pi 5 the pin is
observed to be actively driven low as an output at all times, not
configured as input.

Reproduction / evidence

pinctrl get 22,23,24,25,26 while the SC16IS752 driver is loaded and
actively servicing (/dev/ttySC0/ttySC1 present):

22: no    pd | -- // GPIO22 = none
23: op dl pd | lo // GPIO23 = output   (claimed by our own unrelated code)
24: op dl pn | lo // GPIO24 = output   <-- should be an input
25: no    pd | -- // GPIO25 = none
26: no    pd | -- // GPIO26 = none

/sys/kernel/debug/gpio shows no consumer/requester holding GPIO24 at
all — its state isn't coming from a Linux gpiolib request, just from
whatever RP1's pinctrl driver leaves it at once the overlay's pinctrl-0
group is (ineffectively) applied.

Live scope trace on GPIO24 during the storm: constant low, no
toggling — not electrical noise, a genuine persistent driven level.
Physical confirmation: the Codec Zero HAT's own status LED wired to
this pin (lit when high) is permanently off on Pi 5, but was correctly
lit (idling high under the external 1kΩ pull-up, as designed) on the
Pi 4 this SD card was previously running on — same physical board,
same wiring, only the host Pi changed.

/proc/interrupts:

186:    XXXXXXXX          0          0          0 pinctrl-rp1  24 Level     spi0.0

incrementing at ~16,600-16,900/sec continuously, ~30-33% of one CPU
core spent in irq/186-spi0.0, from boot, indefinitely.

Kprobe tracing the live kernel driver (sc16is7xx.ko) confirms:

• sc16is7xx_irq (the real threaded IRQ handler) fires at this same
  rate — genuinely interrupt-driven, not a polling fallback
  (sc16is7xx_poll_proc never fires).
• It returns IRQ_HANDLED every single call (not IRQ_NONE/spurious).
• It never reaches sc16is7xx_handle_tx, sc16is7xx_ms_proc, or
  sc16is7xx_reg_proc — it just reads IIR (register 2) and returns,
  every ~35-40µs (matches raw SPI transaction round-trip time).

Ruled out as causes (three independent single-variable hardware
tests, all negative — no change in storm rate):

• Jumpering RTS↔CTS (floating modem-control pin theory)
• Overlay trigger type: IRQ_TYPE_LEVEL_LOW vs. stock EDGE_FALLING
  — identical rate either way. /proc/interrupts's own type column
  reports Level under both configurations, on two separate Pi 5
  units, one of which has never had the level-low variant applied at
  all — suggesting genuine edge-triggered behaviour for this pin may
  not be achievable at all on RP1 for this binding, independent of
  what the overlay requests.
• Removing a TXD→RXD loopback jumper

Also ruled out: a suspected Codec-Zero rotary-encoder pin conflict on
GPIO23/24/25 — no encoder/rotary/gpio-hog node exists anywhere
in the live decompiled device tree (dtc -I fs -O dts /proc/device-tree)
that references these pins.

What we tried that didn't help

• Full apt-get upgrade (all packages, including raspi-firmware,
  libgpiolib0, libdtovl0) — no change.
• rpi-eeprom-update -a (RP1 bootloader firmware, May 11 → May 26 2026
  build) — no change.
• gpio=24=ip in config.txt (forcing genuine input at RP1
  boot-firmware level, before the kernel/overlay/driver stack loads)
  — no change; the SC16IS7xx driver's own pin-claiming at probe time
  appears to override whatever firmware set beforehand.

Question

Is sc16is75x-spi-overlay.dts simply missing the fix that
sc16is752-spi0-overlay.dts received in #6111 (seems unlikely, given
it already has the equivalent pinctrl-0/brcm,function=<in>
content) — or has something changed in RP1's pinctrl driver since
April 2024 that broke the brcm,pins/brcm,function/brcm,pull
compatibility path that #6111 relied on? Happy to test a patch/build
on real hardware (two separate Pi 5 units currently reproducing this).

[nbuchwitz]

Looks like the rp1 legacy mapping for brcm,* semantics is missing the brcm,function part, which sets the direction. See #7521 for a potential fix.

With the patch:

nbw@rpicm5-build ~ $ pinctrl get 24                                              
24: no    pd | -- // GPIO24 = none
nbw@rpicm5-build ~ $ sudo pinctrl set 24 op dl                                             

nbw@rpicm5-build ~ $ pinctrl get 24           
24: op dl pd | lo // GPIO24 = output
nbw@rpicm5-build ~ $ sudo dtoverlay sc16is75x-spi sc16is752 spi0-0 int_pin=24 xtal=14745600

nbw@rpicm5-build ~ $ pinctrl get 24                                                        
24: ip    pn | lo // GPIO24 = input