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

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 <[email protected]>
> ---
> 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.  Anything that does-a-thing, should be allocated a proper subsystem
and platform drivers should be created.

Complicated platform / embedded-controller type work (events,
conditions, bespoke messaging, etc) that truly cannot live anywhere else
can live in drivers/platform, but perhaps don't invent a new
sub-sub-system here or create an extended MFD device here - it should be
a separate entity.

Take a look to see how the other drivers/platform dumpers work.

-- 
Lee Jones