[RFC v11 3/4] soc: microchip: add mpfs gpio interrupt mux driver

Herve Codina herve.codina at bootlin.com
Mon Mar 2 01:58:24 PST 2026


Hi Conor,

On Fri, 27 Feb 2026 14:52:29 +0000
Conor Dooley <conor at kernel.org> wrote:

> From: Conor Dooley <conor.dooley at microchip.com>
> 
> On PolarFire SoC there are more GPIO interrupts than there are interrupt
> lines available on the PLIC, and a runtime configurable mux is used to
> decide which interrupts are assigned direct connections to the PLIC &
> which are relegated to sharing a line.
> 
> Add a driver so that Linux can set the mux based on the interrupt
> mapping in the devicetree.
> 
> Signed-off-by: Conor Dooley <conor.dooley at microchip.com>
> ---
...

> --- a/drivers/soc/microchip/Kconfig
> +++ b/drivers/soc/microchip/Kconfig
> @@ -1,3 +1,14 @@
> +config POLARFIRE_SOC_IRQ_MUX
> +	bool "Microchip PolarFire SoC's GPIO IRQ Mux"
> +	depends on ARCH_MICROCHIP
> +	select REGMAP
> +	select REGMAP_MMIO
> +	default y
> +	help
> +	  Support for the interrupt mux on Polarfire SoC. It sits between
> +	  the GPIO controllers and the PLIC, as only 35 interrupts are shared
> +	  between 3 GPIO controllers with 32 interrupts each.

35 interrupts ?

Previously (other patches) you mentionned 41 (38 + 3).

Also 32 interrutps on each (3 * 32 = 96) but you talked about 70 on previous
patches.

Can you double check or clarify those numbers ?

...
> +++ b/drivers/soc/microchip/mpfs-irqmux.c
> @@ -0,0 +1,167 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Largely copied from rzn1_irqmux.c
> + */
> +
> +#include <linux/bitmap.h>
> +#include <linux/bitops.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +
> +#define MPFS_IRQMUX_CR		0x54
> +#define MPFS_IRQMUX_NUM_OUTPUTS	70

Is 70 really the outputs ?

According to previous patches, I would say 41 (38+3).

...
> +static int mpfs_irqmux_probe(struct platform_device *pdev)
> +{
> +	DECLARE_BITMAP(line_done, MPFS_IRQMUX_NUM_OUTPUTS) = {};
> +	struct device *dev = &pdev->dev;
> +	struct device_node *np = dev->of_node;
> +	struct of_imap_parser imap_parser;
> +	struct of_imap_item imap_item;
> +	struct regmap *regmap;
> +	int ret, direct_mode, line, controller, gpio;

Reverse Xmas tree.

> +	u32 tmp, val = 0, old;

...
> +	for_each_of_imap_item(&imap_parser, &imap_item) {
> +
> +		direct_mode = mpfs_irqmux_is_direct_mode(dev, &imap_item.parent_args);
> +		if (direct_mode < 0) {
> +			of_node_put(imap_item.parent_args.np);
> +			return direct_mode;
> +		}
> +
> +		line = imap_item.child_imap[0];
> +		gpio = line % 32;
> +		controller = line / 32;
> +
> +		if (controller > 2) {
> +			of_node_put(imap_item.parent_args.np);
> +			dev_err(dev, "child interrupt number too large: %d\n", line);
> +			return -EINVAL;
> +		}
> +
> +		if (test_and_set_bit(line, line_done)) {

Your bitmap size is MPFS_IRQMUX_NUM_OUTPUTS but you your line variable can
have values from 0 to 95.

Maybe some checks on imap_item.child_imap[0] or line could be added in
order to be be sure that line value will fit in the bitmap.


> +			of_node_put(imap_item.parent_args.np);
> +			dev_err(dev, "Mux output line %d already defined in interrupt-map\n",
> +				line);

line is computed from imap_item.child_imap[0]. It is the input and not the
output.

In rzn1-irqmux.c, the bitmap is used to avoid multiple input lines using the same
output line. Bitmap bits represent outputs.

> +			return -EINVAL;
> +		}
> +
> +		/*
> +		 * There are 41 interrupts assigned to GPIOs, of which 38 are "direct". Since the
> +		 * mux has 32 bits only, 6 of these exclusive/"direct" interrupts remain. These
> +		 * are used by GPIO controller 1's lines 18 to 23. Nothing needs to be done
> +		 * for these interrupts.
> +		 */
> +		if (controller == 1 && gpio >= 18)
> +			continue;
> +
> +		/*
> +		 * The mux has a single register, where bits 0 to 13 mux between GPIO controller
> +		 * 1's 14 GPIOs and GPIO controller 2's first 14 GPIOs. The remaining bits mux
> +		 * between the first 18 GPIOs of controller 1 and the last 18 GPIOS of
> +		 * controller 2. If a bit in the mux's control register is set, the
> +		 * corresponding interrupt line for GPIO controller 0 or 1 will be put in
> +		 * "non-direct" mode. If cleared, the "fabric" controller's will.
> +		 *
> +		 * Register layout:
> +		 *    GPIO 1 interrupt line 17 | mux bit 31 | GPIO 2 interrupt line 31
> +		 *    ...                      | ...        | ...
> +		 *    ...                      | ...        | ...
> +		 *    GPIO 1 interrupt line  0 | mux bit 14 | GPIO 2 interrupt line 14
> +		 *    GPIO 0 interrupt line 13 | mux bit 13 | GPIO 2 interrupt line 13
> +		 *    ...                      | ...        | ...
> +		 *    ...                      | ...        | ...
> +		 *    GPIO 0 interrupt line  0 | mux bit  0 | GPIO 2 interrupt line  0
> +		 *
> +		 * As the binding mandates 70 items, one for each GPIO line, there's no need to
> +		 * handle anything for GPIO controller 2, since the bit will be set for the
> +		 * corresponding line in GPIO controller 0 or 1.

Hum, what happen if the interrupts property is set in the GPIO controller 2 and not
GPIO controllers 0 or 1.

Is it legit ?

If so, should lines coming from GPIO controller 2 be took into account ?

Maybe my comment is not relevant due to some misunderstanding in the not
so obvious mapping.

> +		 */
> +		if (controller == 2)
> +			continue;
> +
> +		/*
> +		 * If in direct mode, the bit is cleared, nothing needs to be done as val is zero
> +		 * initialised and that's the direct mode setting for GPIO controller 0 and 1.
> +		 */
> +		if (direct_mode)
> +			continue;
> +
> +		if (controller == 0)
> +			val |= 1U << gpio;
> +		else
> +			val |= 1U << (gpio + 14);
> +	}
> +
> +	regmap_read(regmap, MPFS_IRQMUX_CR, &old);
> +	regmap_write(regmap, MPFS_IRQMUX_CR, val);
> +
> +	if (val != old)
> +		dev_info(dev, "firmware mux setting of 0x%x overwritten to 0x%x\n", old, val);
> +
> +	return 0;
> +}
> +

Best regards,
Hervé



More information about the linux-riscv mailing list