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

[Oleksij Rempel]

Hi Alvin,

On Fri, Jul 10, 2026 at 05:22:30PM +0200, Alvin Šipraga wrote:
> 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.

My previous attempts to address it in the core were simply too fragile
and caused other regressions.

To be honest, I have already run out of budget for this task. A lot of
that time was spent just learning how to deal with the new upstreaming
reality. With sashiko.dev, it is much harder to upstream any moderate to
large amount of code now. You either have to use public sashiko and spam
everyone until all issues are addressed, or learn to set up and use your
own sashiko instance.

Because of that, these driver-level wrappers are the most practical way
forward for me right now.

Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |