[PATCH v24 04/12] mfd: psci-mfd: Add PSCI MFD driver for cpuidle-psci-domain cell

[Lee Jones]

On Wed, 26 Aug 2026, Bartosz Golaszewski wrote:

> On Fri, 21 Aug 2026 14:59:49 +0200, Ulf Hansson
> <ulf.hansson at oss.qualcomm.com> said:
> > On Mon, Aug 3, 2026 at 11:45 AM Shivendra Pratap
> > <shivendra.pratap at oss.qualcomm.com> wrote:
> >>
> >> PSCI has multiple kernel consumers, such as cpuidle-psci-domain.
> >> Currently, both the PSCI core driver and cpuidle-psci-domain bind
> >> directly to the same PSCI node "arm,psci-1.0". Additional consumers, if
> >> introduced, would also need to bind in the same way, leading to several
> >> drivers attached to a single device node.
> >>
> >> Introduce a PSCI MFD driver that binds to "arm,psci-1.0" and registers
> >> PSCI child cells. As the first user, register cpuidle-psci-domain as a
> >> child cell.
> >
> > I don't think PSCI should be modeled as an MFD device with childrens.
> >
> > Instead, this looks rather like a better fit for the auxiliary
> > bus/driver. Please consider using that instead.
> >
> 
> Hi Uffe!
> 
> Since I was the one to suggest MFD - would you mind providing more arguments
> in favor of your preferred option?
> 
> My reasoning for MFD was that it is indeed a device that provides multiple
> functionalities, of which cpuidle is not really he main one even though it's
> currently the only driver binding to this node.
> 
> In any case, we'd need a "core" driver binding to the psci node and with
> multiple auxiliary devices with their own drivers, we'd end up reimplementing
> MFD.

Ulf could be correct.

MFD is usually reserved for real devices, whereas the aux is a little
more loose.  Please consider it as an option.

-- 
Lee Jones