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

Bartosz Golaszewski <[email protected]>
Newsgroups org.kernel.vger.linux-pm,dev.linux.lists.mfd,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <CAMRc=Mezpj4A7o00C9hhs97kdA5Q+FZKTLRbDM+fR8qr0xCCqw@mail.gmail.com>
On Fri, 21 Aug 2026 14:59:49 +0200, Ulf Hansson
<[email protected]> said:
> On Mon, Aug 3, 2026 at 11:45 AM Shivendra Pratap
> <[email protected]> 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.

Thanks,
Bartosz
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.