The EcoNet EN7528 is a MIPS SoC that uses the same pin controller and GPIO
IP as the Airoha SoCs, so it reuses the shared driver code introduced by
the split into per-SoC drivers. Its register layout differs from every
existing variant though: all IOMUX mode bits live in a single CHIP SCU
register plus a few spill-over bits in IOMUX Control 3, EJTAG has its own
enable register, and every pin configuration register is at a different
offset than on EN7523.

It also differs in a way the shared code did not model: only GPIO0-GPIO15
are wired to the interrupt controller, while the driver assumed all
AIROHA_NUM_PINS GPIOs could raise an interrupt. Patch 1 adds a
num_irq_pins field to the per-SoC match data to describe that, bounds the
interrupt callbacks and handler with it, and feeds it to gpiolib through
gpio_irq_chip::init_valid_mask so gpiod_to_irq() fails up front for a pin
that can never be an interrupt source. All existing SoCs pass
AIROHA_NUM_PINS and are unaffected.

Patch 2 documents the binding, patch 3 adds the driver.

The series is based on linux-pinctrl/for-next, as it depends on the
per-SoC driver split and on the CHIP SCU lookup by "airoha,chip-scu"
phandle that landed there.

Tested on a DASAN H660GM-A (EN7528, Airtel), booting OpenWrt.

Ahmed Naseef (2):
  pinctrl: airoha: limit GPIO interrupts to interrupt-capable pins
  dt-bindings: pinctrl: Add EcoNet EN7528 pin controller

Benjamin Larsson (1):
  pinctrl: airoha: add support of en7528 SoC

 .../pinctrl/econet,en7528-pinctrl.yaml        |  190 +++
 drivers/pinctrl/airoha/Kconfig                |   15 +-
 drivers/pinctrl/airoha/Makefile               |    1 +
 drivers/pinctrl/airoha/airoha-common.h        |    3 +
 drivers/pinctrl/airoha/pinctrl-airoha.c       |   33 +-
 drivers/pinctrl/airoha/pinctrl-an7563.c       |    1 +
 drivers/pinctrl/airoha/pinctrl-an7581.c       |    1 +
 drivers/pinctrl/airoha/pinctrl-an7583.c       |    1 +
 drivers/pinctrl/airoha/pinctrl-en7523.c       |    1 +
 drivers/pinctrl/airoha/pinctrl-en7528.c       | 1204 +++++++++++++++++
 10 files changed, 1443 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/econet,en7528-pinctrl.yaml
 create mode 100644 drivers/pinctrl/airoha/pinctrl-en7528.c


base-commit: 87e787e591a82b9b324aa0968795b256f789d287
-- 
2.34.1

Hi Ahmed,

thanks for your patches!

On Sun, Aug 9, 2026 at 10:05 AM Ahmed Naseef <naseefkm@gmail.com> wrote:

> The series is based on linux-pinctrl/for-next, as it depends on the
> per-SoC driver split and on the CHIP SCU lookup by "airoha,chip-scu"
> phandle that landed there.

If we can get a speedy review on these patches I don't mind merging
them for v7.3 already, it's nice to get some movement on all the
nice Airoha silicon.

Yours,
Linus Walleij

Il giorno lun 10 ago 2026 alle ore 09:23 Linus Walleij
<linusw@kernel.org> ha scritto:
>
> Hi Ahmed,
>
> thanks for your patches!
>
> On Sun, Aug 9, 2026 at 10:05 AM Ahmed Naseef <naseefkm@gmail.com> wrote:
>
> > The series is based on linux-pinctrl/for-next, as it depends on the
> > per-SoC driver split and on the CHIP SCU lookup by "airoha,chip-scu"
> > phandle that landed there.
>
> If we can get a speedy review on these patches I don't mind merging
> them for v7.3 already, it's nice to get some movement on all the
> nice Airoha silicon.
>

Hi Linus,

I wonder if the same speed treatment can be done also for the clock driver and
also dts?
There are a few patch there that are currently blocking usb phy and pcie...

On Mon, Aug 10, 2026 at 9:27 AM Christian Marangi (Ansuel)
<ansuelsmth@gmail.com> wrote:
> Il giorno lun 10 ago 2026 alle ore 09:23 Linus Walleij
> <linusw@kernel.org> ha scritto:

> > If we can get a speedy review on these patches I don't mind merging
> > them for v7.3 already, it's nice to get some movement on all the
> > nice Airoha silicon.
>
> I wonder if the same speed treatment can be done also for the clock driver and
> also dts?
> There are a few patch there that are currently blocking usb phy and pcie...

Heh not my department. I think the SoC maintainers can merge some
late DTS patches, the clock driver is up to the clock maintainers.

Yours,
Linus Walleij