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

[Ulf Hansson]

On Tue, Sep 1, 2026 at 10:12 AM Bartosz Golaszewski <brgl at kernel.org> wrote:
>
> On Thu, 27 Aug 2026 14:59:06 +0200, Lee Jones <lee at kernel.org> said:
> > 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.
> >
>
> My point is: if you start registering auxiliary devices from a "core" platform
> driver based on real child OF nodes then you're basically re-implementing MFD.
>
> At that point you're better off just using the existing MFD infrastructure.

I think it's as Lee said. MFD is for real devices, while auxiliary is
more suited to split up functionality using multiple drivers.

Kind regards
Uffe