[PATCH v21 08/13] mfd: core: Add firmware-node support to MFD cells

Bartosz Golaszewski brgl at kernel.org
Tue Apr 28 05:51:21 PDT 2026


On Tue, Apr 28, 2026 at 2:18 PM Shivendra Pratap
<shivendra.pratap at oss.qualcomm.com> wrote:
>
>
>
> On 28-04-2026 13:33, Bartosz Golaszewski wrote:
> > On Mon, 27 Apr 2026 19:34:48 +0200, Shivendra Pratap
> > <shivendra.pratap at oss.qualcomm.com> said:
> >> MFD core has no way to register a child device using an explicit firmware
> >> node. This prevents drivers from registering child nodes when those nodes
> >> do not define a compatible string. One such example is the PSCI
> >> "reboot-mode" node, which omits a compatible string as it describes
> >> boot-states provided by the underlying firmware.
> >>
> >> Extend struct mfd_cell with an optional fwnode pointer and attach it to the
> >> child device during registration when no firmware node is already assigned.
> >>
> >> Signed-off-by: Shivendra Pratap <shivendra.pratap at oss.qualcomm.com>
> >> ---
> >
> > In the following patch you use this and violate the supposed constness of
> > MFD cells. This also mean you need to modify the mfd_cell at run-time. I would
> > prefer introducing a field in mfd_cell: bool use_parent_fwnode which would
> > indicate to MFD core that - in case no fwnode was assigned from other sources:
> > DT or software node - it should reuse the parent MFD device's node.
>
> Have one doubt on this, When we fallback to use_parent_fwnode for cell:
> psci-reboot-mode, at psci_reboot_mode_probe(), pDev->dev->of_node point
> to psci node.
>
> But we want dev->of_node to point to "reboot-mode" node. This may need
> an explicit assignment again of of_node?
>

Ah, sorry you're right. I'd like to avoid having to modify the
mfd_cell entry at run-time if possible.

How about a callback in mfd_cell like:

struct fwnode_handle *(*get_fwnode)(struct device *parent);

If set, it would be called from MFD core and would do the name lookup
and return the fwnode which would then be assigned to the cell device?

Bart



More information about the linux-arm-kernel mailing list