Add NVIDIA BlueField-3 GPIO driver and pin controller

This patch adds support for the BlueField-3 SoC GPIO driver

which allows:
- setting certain GPIOs as interrupts from other dependent drivers
- ability to manipulate certain GPIO pins via libgpiod tools

BlueField-3 has 56 GPIOs but the user is only allowed to change some of them into GPIO mode. Use valid_mask to make it impossible to alter the rest of the GPIOs.

+/*
+ * Copyright (C) 2022 NVIDIA CORPORATION & AFFILIATES
+ */

+#include <linux/acpi.h>

drivers/gpio/gpio-mlxbf3.c new file +9 -0

+	/* YU GPIO block address */
+	void __iomem *gpio_io;
+
+	/* YU GPIO cause block address */
+	void __iomem *gpio_cause_io;
+
+	/* Mask of valid gpios that can be accessed by software */
+	unsigned int valid_mask;
+};

drivers/gpio/gpio-mlxbf3.c new file +14 -0

+	switch (type & IRQ_TYPE_SENSE_MASK) {
+	case IRQ_TYPE_EDGE_BOTH:
+		fall = true;
+		rise = true;
+		break;
+	case IRQ_TYPE_EDGE_RISING:
+		rise = true;
+		break;
+	case IRQ_TYPE_EDGE_FALLING:
+		fall = true;
+		break;
+	default:
+		return -EINVAL;
+	}

+}

drivers/gpio/gpio-mlxbf3.c new file +1 -0

+	gs->valid_mask = valid_mask;

(quoted diff) +2 -0

+		}
+	}

(quoted diff) +1 -0

+	}

+};

+module_platform_driver(mlxbf3_gpio_driver);

Thanks Andy for the feedback! Will address your comment in v4.

drivers/gpio/gpio-mlxbf3.c line 90

Quoted 1 line

drivers/gpio/gpio-mlxbf3.c new file +1 -0

+		generic_handle_irq(irq_find_mapping(gc->irq.domain, level));

There is a helper that unites these two calls together.

I didn't find any helper in v6.2. Could you please point me to it?

drivers/gpio/gpio-mlxbf3.c line 147

Quoted 10 lines

drivers/gpio/gpio-mlxbf3.c new file +10 -0

+static int mlxbf3_gpio_init_valid_mask(struct gpio_chip *gc,
+				       unsigned long *valid_mask,
+				       unsigned int ngpios)
+{
+	struct mlxbf3_gpio_context *gs = gpiochip_get_data(gc);
+
+	*valid_mask = gs->valid_mask;
+
+	return 0;
+}

Why do you need this?

Since we only use ACPI tables and we want user space (libgpiod tool) or possibly (in the future) other kernel drivers to have access to certain GPIO pins, we use this valid_mask to do so. Linus previously explained that if we ask for a GPIO then it will be muxed in using .gpio_request_enable(). And so we would use .valid_mask to restrict the use of certain gpios.

This patch adds support to the BlueField-3 SoC pin controller.

It allows muxing individual GPIOs to switch from the default hardware mode to software controlled mode.

drivers/pinctrl/Kconfig config PINCTRL_ZYNQMP · line 528

Quoted 3 lines

drivers/pinctrl/Kconfig +3 -0

+config PINCTRL_MLXBF
+	tristate "NVIDIA BlueField-3 SoC Pinctrl driver"
+	depends on (MELLANOX_PLATFORM && ARM64 && ACPI)

This is wrong.
Please make sure you cover more testing.
Also, do you really need an ACPI dependency?

Could you please provide more details on why this is wrong? All our upstreamed drivers use the same "depends on" Our pinctrl driver only applies to Mellanox platforms, ARM64 and use ACPI tables.

drivers/pinctrl/Kconfig config PINCTRL_ZYNQMP · line 528

Quoted 3 lines

drivers/pinctrl/Kconfig +3 -0

+config PINCTRL_MLXBF
+	tristate "NVIDIA BlueField-3 SoC Pinctrl driver"
+	depends on (MELLANOX_PLATFORM && ARM64 && ACPI)

This is wrong.
Please make sure you cover more testing.
Also, do you really need an ACPI dependency?

Could you please provide more details on why this is wrong? All our upstreamed drivers use the same "depends on" Our pinctrl driver only applies to Mellanox platforms, ARM64 and use ACPI tables.

Quoted 11 lines

drivers/pinctrl/Kconfig config PINCTRL_ZYNQMP · line 528

Quoted 3 lines

drivers/pinctrl/Kconfig +3 -0

+config PINCTRL_MLXBF
+	tristate "NVIDIA BlueField-3 SoC Pinctrl driver"
+	depends on (MELLANOX_PLATFORM && ARM64 && ACPI)

This is wrong.
Please make sure you cover more testing.
Also, do you really need an ACPI dependency?

Could you please provide more details on why this is wrong? All our upstreamed drivers use the same "depends on" Our pinctrl driver only applies to Mellanox platforms, ARM64 and use ACPI tables.

This is wrong because it narrows down testing coverage.

Besides that you need to define functional and build dependencies separately.

ACPI probably is not what you are using in the driver. I do not believe you have at all dependency on it.

Noted, I will define function and build dependencies separately. We have our own custom UEFI for BlueField SoCs so ACPI tables are our only options (for users/customer etc... as well)

Quoted 11 lines

drivers/pinctrl/Kconfig config PINCTRL_ZYNQMP · line 528

Quoted 3 lines

drivers/pinctrl/Kconfig +3 -0

+config PINCTRL_MLXBF
+	tristate "NVIDIA BlueField-3 SoC Pinctrl driver"
+	depends on (MELLANOX_PLATFORM && ARM64 && ACPI)

This is wrong.
Please make sure you cover more testing.
Also, do you really need an ACPI dependency?

Could you please provide more details on why this is wrong? All our upstreamed drivers use the same "depends on" Our pinctrl driver only applies to Mellanox platforms, ARM64 and use ACPI tables.

This is wrong because it narrows down testing coverage.

Besides that you need to define functional and build dependencies separately.

ACPI probably is not what you are using in the driver. I do not believe you have at all dependency on it.

Noted, I will define function and build dependencies separately. We have our own custom UEFI for BlueField SoCs so ACPI tables are our only options (for users/customer etc... as well)

This series of patches creates a pin controller driver and GPIO driver for NVIDIA BlueField-3 SoC.
The first patch creates a GPIO driver for handling interrupts and allowing the change of direction and value of a GPIO if needed. The second patch creates a pin controller driver for allowing a select number of GPIO pins to be manipulated from userspace or the kernel.

The BlueField-3 SoC gpio-mlxbf3.c driver handles different hardware registers and logic that from gpio-mlxbf.c and gpio-mlxbf2.c.
For that reason, we have separate drivers for each generation.

Add support for the BlueField-3 SoC GPIO driver.
This driver configures and handles GPIO interrupts. It also enables a user to manipulate certain GPIO pins via libgpiod tools or other kernel drivers. The usables pins are defined via the gpio-reserved-ranges property.

+ depends on (MELLANOX_PLATFORM && ARM64 && ACPI) || (64BIT && COMPILE_TEST)

+#include <linux/version.h>

drivers/gpio/gpio-mlxbf3.c new file +9 -0

+struct mlxbf3_gpio_context {
+       struct gpio_chip gc;
+
+       /* YU GPIO block address */
+       void __iomem *gpio_io;
+
+       /* YU GPIO cause block address */
+       void __iomem *gpio_cause_io;
+};

+ int offset = irqd_to_hwirq(irqd);

+ int offset = irqd_to_hwirq(irqd);

drivers/gpio/gpio-mlxbf3.c new file +12 -0

+       raw_spin_lock_irqsave(&gs->gc.bgpio_lock, flags);
+
+       switch (type & IRQ_TYPE_SENSE_MASK) {
+       case IRQ_TYPE_EDGE_BOTH:
+               val = readl(gs->gpio_io + MLXBF_GPIO_CAUSE_FALL_EN);
+               val |= BIT(offset);
+               writel(val, gs->gpio_io + MLXBF_GPIO_CAUSE_FALL_EN);
+               val = readl(gs->gpio_io + MLXBF_GPIO_CAUSE_RISE_EN);
+               val |= BIT(offset);
+               writel(val, gs->gpio_io + MLXBF_GPIO_CAUSE_RISE_EN);
+               break;
+       case IRQ_TYPE_EDGE_RISING:

drivers/gpio/gpio-mlxbf3.c new file +4 -0

+               return -EINVAL;
+       }
+
+       raw_spin_unlock_irqrestore(&gs->gc.bgpio_lock, flags);

+ irq_set_handler_locked(irqd, handle_simple_irq);

+ girq->default_type = IRQ_TYPE_NONE;

drivers/gpio/gpio-mlxbf3.c

Quoted 5 lines

drivers/gpio/gpio-mlxbf3.c new file +5 -0

+static const struct irq_chip gpio_mlxbf3_irqchip = {
+       .name = "MLNXBF33",
+       .irq_set_type = mlxbf3_gpio_irq_set_type,
+       .irq_enable = mlxbf3_gpio_irq_enable,
+       .irq_disable = mlxbf3_gpio_irq_disable, };

Seems missing two things (dunno if bgpio_init() helps with that):
- IMMUTABLE flag
- actual calls to enable and disable IRQs for internal GPIO library usage
See other drivers how it's done. There are even plenty of patches to enable this thing separately.

I saw that in other drivers only irq_enable and irq_disable are defined. Example in gpio-davinci.c:
static struct irq_chip gpio_irqchip = {

.name           = "GPIO",
.irq_enable     = gpio_irq_enable,
.irq_disable    = gpio_irq_disable,
.irq_set_type   = gpio_irq_type,
.flags          = IRQCHIP_SET_TYPE_MASKED,

};

Which I think is ok due to the following logic:

gpiochip_add_irqchip calls
gpiochip_set_irq_hooks which contains the following logic:

if (irqchip->irq_disable) {
                 gc->irq.irq_disable = irqchip->irq_disable;
                 irqchip->irq_disable = gpiochip_irq_disable;
} else {
                 gc->irq.irq_mask = irqchip->irq_mask;
                 irqchip->irq_mask = gpiochip_irq_mask;
}
if (irqchip->irq_enable) {
                 gc->irq.irq_enable = irqchip->irq_enable;
                 irqchip->irq_enable = gpiochip_irq_enable;
} else {
                 gc->irq.irq_unmask = irqchip->irq_unmask;
                 irqchip->irq_unmask = gpiochip_irq_unmask;
}

So it doesn’t seem like we need to define irq_mask/unmask if we have irq_enable/disable?

drivers/gpio/gpio-mlxbf3.c line 167

Quoted 2 lines

drivers/gpio/gpio-mlxbf3.c new file +2 -0

+       npins = MLXBF3_GPIO_MAX_PINS_PER_BLOCK;
+       device_property_read_u32(dev, "npins", &npins);

I don't see DT bindings for this property (being added in this series). Is it already established one?

Ah that’s my bad. The property should be called "ngpios" like in the DT documentation. Will fix.

Quoted 4 lines

drivers/gpio/gpio-mlxbf3.c line 167

Quoted 2 lines

drivers/gpio/gpio-mlxbf3.c new file +2 -0

+       npins = MLXBF3_GPIO_MAX_PINS_PER_BLOCK;
+       device_property_read_u32(dev, "npins", &npins);

I don't see DT bindings for this property (being added in this series). Is it

already established one?

Quoted 2 lines

Ah that’s my bad. The property should be called "ngpios" like in the DT

documentation. Will fix.

And why do you need it? What's a corner case that the GPIO library doesn't handle yet?

Quoted 7 lines

Quoted 5 lines

drivers/gpio/gpio-mlxbf3.c line 167

Quoted 3 lines

drivers/gpio/gpio-mlxbf3.c new file +2 -0

+       npins = MLXBF3_GPIO_MAX_PINS_PER_BLOCK;
+       device_property_read_u32(dev, "npins", &npins);

I don't see DT bindings for this property (being added in this series). Is it

already established one?

Quoted 1 line

Quoted 5 lines

Quoted 1 line

Ah that’s my bad. The property should be called "ngpios" like in the DT

documentation. Will fix.

And why do you need it? What's a corner case that the GPIO library doesn't handle yet?

We have 2 gpiochips, gpiochip 0 supports 32 gpio pins and gpiochip 1 supports only 24 pins.
If I remove the logic from gpio-mlxbf3.c, the gpiolib.c logic will correctly set the ngpios = 32 for gpiochip 0 but will wrongly set ngpios=32 for gpiogchip 1:

Quoted 16 lines

Quoted 15 lines

Quoted 7 lines

drivers/gpio/gpio-mlxbf3.c line 167

Quoted 4 lines

drivers/gpio/gpio-mlxbf3.c new file +2 -0

+       npins = MLXBF3_GPIO_MAX_PINS_PER_BLOCK;
+       device_property_read_u32(dev, "npins", &npins);

I don't see DT bindings for this property (being added in this series). Is it

already established one?

Quoted 3 lines

Ah that’s my bad. The property should be called "ngpios" like in the DT

documentation. Will fix.

And why do you need it? What's a corner case that the GPIO library doesn't handle yet?

Quoted 1 line

We have 2 gpiochips, gpiochip 0 supports 32 gpio pins and gpiochip 1

supports only 24 pins.

Quoted 1 line

If I remove the logic from gpio-mlxbf3.c, the gpiolib.c logic will correctly set

the ngpios = 32 for gpiochip 0 but will wrongly set ngpios=32 for gpiogchip 1:

So, either you need to have two entries in DT per chip or ngpios should be 56.

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

Quoted 2 lines

Ah that’s my bad. The property should be called "ngpios" like in the DT

documentation. Will fix.

And why do you need it? What's a corner case that the GPIO library doesn't handle yet?

Quoted 7 lines

Quoted 1 line

We have 2 gpiochips, gpiochip 0 supports 32 gpio pins and gpiochip 1

supports only 24 pins.

Quoted 1 line

If I remove the logic from gpio-mlxbf3.c, the gpiolib.c logic will correctly set

the ngpios = 32 for gpiochip 0 but will wrongly set ngpios=32 for gpiogchip 1:

So, either you need to have two entries in DT per chip or ngpios should be 56.

I already have 2 entries in my ACPI table, in the first entry, ngpios = 32 and in the second entry ngpios = 24.

Gpiochip_add_data_with_keys only reads the ngpios property if (ngpios == 0) which is not the case when bgpio_init is called. bgpio_init uses "sz" argument to populate the ngpio in bgpio_init, which is not what we want.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

Quoted 2 lines

Ah that’s my bad. The property should be called "ngpios" like in the DT

documentation. Will fix.

And why do you need it? What's a corner case that the GPIO library doesn't handle yet?

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

We have 2 gpiochips, gpiochip 0 supports 32 gpio pins and gpiochip 1

supports only 24 pins.

Quoted 2 lines

If I remove the logic from gpio-mlxbf3.c, the gpiolib.c logic will correctly set

the ngpios = 32 for gpiochip 0 but will wrongly set ngpios=32 for gpiogchip

1:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

So, either you need to have two entries in DT per chip or ngpios should be

56.

Quoted 2 lines

Quoted 1 line

I already have 2 entries in my ACPI table, in the first entry, ngpios = 32 and

in the second entry ngpios = 24.

Can you show the DSDT excerpt of this device? (Also including the pieces for pin control)

Quoted 3 lines

Gpiochip_add_data_with_keys only reads the ngpios property if (ngpios == 0) which is not the case when bgpio_init is called. bgpio_init uses "sz"

argument to populate the ngpio in bgpio_init, which is not what we want.

Maybe bgpio_init() is not a good API for your case?

Quoted 16 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

Ah that’s my bad. The property should be called "ngpios" like in the DT

documentation. Will fix.

And why do you need it? What's a corner case that the GPIO library doesn't handle yet?

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

We have 2 gpiochips, gpiochip 0 supports 32 gpio pins and gpiochip 1

supports only 24 pins.

Quoted 2 lines

If I remove the logic from gpio-mlxbf3.c, the gpiolib.c logic will correctly set

the ngpios = 32 for gpiochip 0 but will wrongly set ngpios=32 for gpiogchip

1:

Quoted 1 line

Quoted 1 line

Quoted 8 lines

Quoted 1 line

Quoted 1 line

So, either you need to have two entries in DT per chip or ngpios should be

56.

Quoted 2 lines

Quoted 1 line

I already have 2 entries in my ACPI table, in the first entry, ngpios = 32 and

in the second entry ngpios = 24.

Can you show the DSDT excerpt of this device? (Also including the pieces for pin control)

Our ACPI tables are internal:

Device(GPI0) {
        Name(_HID, "MLNXBF33")
        Name(_UID, Zero)
        Name(_CCA, 1)
        Name(_CRS, ResourceTemplate() {
          // for fw_gpio[0] yu block
         Memory32Fixed(ReadWrite, 0x13401100, 0x00000080)
         // for yu_gpio_causereg0 block
         Memory32Fixed(ReadWrite, 0x13401c00, 0x00000020)
         Interrupt(ResourceConsumer, Edge, ActiveHigh, Shared)
           { BF_RSH0_YU }
       })
       Name(_DSD, Package() {
         ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
         Package() {
           Package () { "ngpios", 32 }, // Number of GPIO pins on gpio block 0
           Package () { "gpio-reserved-ranges", Package () {5, 1, 7, 3, 11, 31}},
         }
       })
     }
 Device(GPI1) {
       Name(_HID, "MLNXBF33")
       Name(_UID, 1)
       Name(_CCA, 1)
       Name(_CRS, ResourceTemplate() {
         // for fw_gpio[1] yu block
         Memory32Fixed(ReadWrite, 0x13401180, 0x00000080)
         // for yu_gpio_causereg1 block
         Memory32Fixed(ReadWrite, 0x13401c20, 0x00000020)
       })
       Name(_DSD, Package() {
         ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
         Package() {
           Package () { "ngpios", 24 }, // Number of GPIO pins on gpio block 1
           Package () { "gpio-reserved-ranges", Package () {0, 21}},
         }
       })

}

    Device(PIN0) {
      Name(_HID, "MLNXBF34")
      Name(_UID, Zero)
      Name(_CCA, 1)
      Name(_CRS, ResourceTemplate() {
        // for fw_gpio[0] and fw_gpio[1] yu blocks
        Memory32Fixed(ReadWrite, 0x13401100, 0x00000100)
      })
     }

Quoted 5 lines

Quoted 2 lines

Gpiochip_add_data_with_keys only reads the ngpios property if (ngpios == 0) which is not the case when bgpio_init is called. bgpio_init uses "sz"

argument to populate the ngpio in bgpio_init, which is not what we want.

Maybe bgpio_init() is not a good API for your case?

At the moment, bgpio_init handles all the direction in/out get/set gpio value for us.
So I can either remove bgpio_init so that we get the correct ngpios property, but will have to define get_gpio, set_gpio, dir in and dir out. Or I can keep bgpio_init and device_property_read_u32 in the gpio-mlxbf3.c driver.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Gpiochip_add_data_with_keys only reads the ngpios property if (ngpios == 0) which is not the case when bgpio_init is called. bgpio_init

uses "sz"

Quoted 5 lines

Quoted 3 lines

argument to populate the ngpio in bgpio_init, which is not what we want.

Maybe bgpio_init() is not a good API for your case?

At the moment, bgpio_init handles all the direction in/out get/set gpio value

for us.

Quoted 1 line

So I can either remove bgpio_init so that we get the correct ngpios

property, but will have to define get_gpio, set_gpio, dir in and dir out.

Quoted 1 line

Or I can keep bgpio_init and device_property_read_u32 in the gpio-

mlxbf3.c driver.

So far it seems the issue is in bgpio_init() that doesn't handle ngpios properly. Maybe we need to fix this first?

Btw, have you considered using the gpio-regmap approach?

           Package () { "gpio-reserved-ranges", Package () {5, 1, 7, 3, 11, 31}},

Quoted 1 line · Asmaa Mnebhi

           Package () { "gpio-reserved-ranges", Package () {5, 1, 7, 3, 11, 31}},

Side note, doesn't it the same to

           Package () { "gpio-reserved-ranges", Package () {5, 1, 7, 34}},

?

Add support for the BlueField-3 SoC GPIO driver.
This driver configures and handles GPIO interrupts. It also enables a user to manipulate certain GPIO pins via libgpiod tools or other kernel drivers. The usables pins are defined via the gpio-reserved-ranges property.

Signed-off-by Asmaa Mnebhi <[email protected]>

drivers/gpio/gpio-mlxbf3.c new file +5 -0

+static void mlxbf3_gpio_irq_enable(struct irq_data *irqd)
+{
+       struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
+       struct mlxbf3_gpio_context *gs = gpiochip_get_data(gc);
+       int offset = irqd_to_hwirq(irqd);

drivers/gpio/gpio-mlxbf3.c new file +6 -0

+       raw_spin_lock_irqsave(&gs->gc.bgpio_lock, flags);
+       val = readl(gs->gpio_cause_io + MLXBF_GPIO_CAUSE_OR_EVTEN0);
+       val &= ~BIT(offset);
+       writel(val, gs->gpio_cause_io + MLXBF_GPIO_CAUSE_OR_EVTEN0);
+       raw_spin_unlock_irqrestore(&gs->gc.bgpio_lock, flags);
+}

NVIDIA BlueField-3 SoC has a few pins that can be used as GPIOs or take the default hardware functionality. Add a driver for the pinmuxing.

+++ b/drivers/pinctrl/pinctrl-mlxbf.c

+};

+};

drivers/pinctrl/pinctrl-mlxbf.c new file +2 -0

+} mlxbf_pmx_funcs[] = {
 
+};

+}

+ struct resource *res;

+ /* This resource is shared so use devm_ioremap */

drivers/pinctrl/pinctrl-mlxbf.c new file +3 -0

+       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+       if (!res)
+               return -ENODEV;

+ ret = devm_pinctrl_register_and_init(priv->dev,

drivers/pinctrl/pinctrl-mlxbf.c new file +5 -0

+                                            &mlxbf_pin_desc,
+                                            priv,
+                                            &priv->pctl);
+       if (ret)
+               return dev_err_probe(dev, ret, "Failed to register pinctrl\n");

drivers/pinctrl/pinctrl-mlxbf.c line 176

Quoted 3 lines

drivers/pinctrl/pinctrl-mlxbf.c new file +3 -0

+static const struct {
+       const char *name;
+       const char * const *group_names;

Use this instead
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-
pinctrl.git/tree/include/linux/pinctrl/pinctrl.h?h=devel#n215 and this
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-
pinctrl.git/tree/include/linux/pinctrl/pinctrl.h?h=devel#n222

Quoted 3 lines

drivers/pinctrl/pinctrl-mlxbf.c new file +2 -0

+} mlxbf_pmx_funcs[] = {
 
+};

Quoted 2 lines

+ /* This resource is shared so use devm_ioremap */

Can you elaborate on who actually requests the region? And why is it not _this_ driver?

Quoted 12 lines

drivers/pinctrl/pinctrl-mlxbf.c line 176

Quoted 4 lines

drivers/pinctrl/pinctrl-mlxbf.c new file +3 -0

+static const struct {
+       const char *name;
+       const char * const *group_names;

Use this instead
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-
pinctrl.git/tree/include/linux/pinctrl/pinctrl.h?h=devel#n215 and this
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-
pinctrl.git/tree/include/linux/pinctrl/pinctrl.h?h=devel#n222

Quoted 3 lines

drivers/pinctrl/pinctrl-mlxbf.c line 186

Quoted 3 lines

drivers/pinctrl/pinctrl-mlxbf.c new file +2 -0

+} mlxbf_pmx_funcs[] = {
 
+};

so copy that struct definition and macro to my driver? (I don’t see these code changes in master)

Quoted 4 lines

Quoted 1 line

+ /* This resource is shared so use devm_ioremap */

Can you elaborate on who actually requests the region? And why is it not _this_ driver?

This resource is shared with the gpio-mlxbf3.c driver. The gpio-mlxbf3.c driver does not access the same offsets as the pinctrl-mlxbf3.c driver, but it accesses several other registers offsets in between.

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

+ /* This resource is shared so use devm_ioremap */

Can you elaborate on who actually requests the region? And why is it not _this_ driver?

Quoted 1 line

This resource is shared with the gpio-mlxbf3.c driver. The gpio-mlxbf3.c

driver does not access the same offsets as the pinctrl-mlxbf3.c driver, but it accesses several other registers offsets in between.

Okay, so in such a case you need a common denominator that actually does this all for you via, for example, regmap. If the region is not requested, bad things may happen.