Re: [PATCH v15 2/6] platform: misc: add NXP MC33978/MC34978 core driver

[Oleksij Rempel]

On Thu, Jul 23, 2026 at 03:53:00PM +0100, Lee Jones wrote:
> On Fri, 10 Jul 2026, Oleksij Rempel wrote:
> 
> > Add the core support module for the NXP MC33978 and MC34978 Multiple
> > Switch Detection Interfaces (MSDI).
> > 
> > The MC33978/MC34978 devices provide 22 switch detection inputs, analog
> > multiplexing (AMUX), and comprehensive hardware fault detection.
> > 
> > This core module handles:
> > - SPI communications via a custom regmap bus to support the device's
> >   pipelined two-frame MISO response requirement.
> > - Interrupt demultiplexing, utilizing an irq_domain to provide 22 virtual
> >   IRQs for switch state changes and 1 virtual IRQ for hardware faults.
> > - Inline status harvesting from the SPI MSB to detect and trigger events
> >   without requiring dedicated status register polling.
> > 
> > It exports mc33978_core_init(), called by the MFD driver added in the
> > following patch. CONFIG_MC33978_CORE carries no prompt and is selected
> > by CONFIG_MFD_MC33978, so this patch alone builds nothing new.
> > 
> > Note: The device currently lacks suspend/resume power management
> > callbacks. If the system enters a sleep state cutting power to
> > VDDQ/VBATP, the device will wake up in POR state with hardware interrupt
> > masks reset. Power management support is intentionally deferred for now.
> > 
> > Signed-off-by: Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx>
> > ---
> > changes v15:
> > - Split out of the MFD patch, as requested by Lee Jones. The register
> >   definitions in include/linux/mfd/mc33978.h are carried here rather than
> >   with the MFD driver because this module includes them, keeping every
> >   commit individually buildable.
> 
> I can't help feeling that this is a hack.
> 
> When I suggested moving the functional parts out, I meant properly
> separating off and compartmentalising.  Instead, a huge slice has been
> taken out of the initial submission's MFD driver and dumped into the
> wild west that is drivers/platform.  Worse still; we're masquerading as
> the MFD since the MFD's 'dev' pointer is being passed through so
> everything here is operating as though it's the parent device.  You've
> created half library / half MFD.
> 
> I get that we're on v15 and there's still a lot to do, but I guess
> that's what happens when 3500 lines of code is submitted at the same
> time.
> 
> My suggestion is to return to first principles; what lives where?
> 
> Allocating of shared resources, including the various regmaps, IRQs and
> domains should live in the MFD subsystem - that's literally what it's
> for. 

This is exactly, what you suggest do move to the separate location.

> Anything that does-a-thing, should be allocated a proper subsystem
> and platform drivers should be created.

Every thing you suggest to move is making regmap and irq work in
the first place.

-- 
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 |