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

[Lee Jones <lee@kernel.org>]

On Thu, 23 Jul 2026, Oleksij Rempel wrote:

> 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@pengutronix.de>
> > > ---
> > > 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.

Let me know if the above doesn't make sense and I'll try to find another
way to put it.  Essentially slicing the code out and simply relocating
it, but still operating as the same (MFD) platform device, is not an
acceptable strategy.  When I suggested that it should be moved, I meant
properly separated, not just sliced and shifted.

-- 
Lee Jones