Re: [PATCH v15 4/6] pinctrl: add NXP MC33978/MC34978 pinctrl driver

[Alvin Šipraga]

Hi Oleksij,

On Fri, Jul 10, 2026 at 12:13:53PM +0200, Oleksij Rempel wrote:
> +/*
> + * Defensive wrappers for hierarchical IRQ proxying.
> + *
> + * gpiolib's hierarchical allocation exposes a lifecycle gap: the child
> + * descriptor is registered before irq_domain_alloc_irqs_parent() fully
> + * instantiates the parent chip.
> + *
> + * During consumer probe (e.g., gpiod_to_irq()), irq_create_fwspec_mapping()
> + * allocates the hierarchy. As part of this, irq_domain_set_info() initializes
> + * the top-level irq_desc and calls __irq_set_handler(). If the irq_desc
> + * requires locking, __irq_get_desc_lock() will invoke the child's
> + * .irq_bus_lock before the parent allocation is complete.
> + *
> + * Upstream generic helpers (e.g., irq_chip_mask_parent) blindly dereference
> + * data->parent_data->chip, causing an immediate NULL pointer panic during
> + * this gap. These wrappers check for a valid parent chip to safely drop
> + * premature locking or masking events while the legacy subsystem hierarchy
> + * is still assembling itself.
> + */

I encountered the same problem while working on a pinctrl/GPIO driver
this week. While searching lore to see if I'm doing it wrong, I found
this series. Such wrappers fix the problem for me too (although in my
case, it's not a slow bus, so it crashes in .irq_mask instead of
.irq_bus_lock).

But I see that in a previous version, you were reordering things in
gpiochip_hierarchy_irq_domain_alloc(). Why did you abandon this
approach?

Just wondering if we can find a more generic solution which doesn't
require such drivers to add this defensive boilerplate. Another option
might be to move such checks into the generic helpers.


> +static void mc33978_gpio_irq_mask(struct irq_data *data)
> +{
> +	struct irq_data *parent = data->parent_data;
> +
> +	if (parent && parent->chip && parent->chip->irq_mask)
> +		parent->chip->irq_mask(parent);
> +}

Kind regards,
Alvin