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

[Alvin Šipraga]

On Sat, Jul 11, 2026 at 07:21:14AM +0200, Oleksij Rempel wrote:
> 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.

Yeah, that sounds perfectly reasonable. Thank you for
clarifying. Interesting also to hear your (perhaps frustrating)
experience sending a bigger series. I hope the situation will improve.

Kind regards,
Alvin