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