From: Shivendra Pratap <shivendra.pratap@oss•qualcomm.com>
To: Bartosz Golaszewski <brgl@kernel•org>, Lee Jones <lee@kernel•org>
Cc: linux-pm@vger•kernel.org, linux-kernel@vger•kernel.org,
linux-arm-msm@vger•kernel.org,
linux-arm-kernel@lists•infradead.org, devicetree@vger•kernel.org,
Florian Fainelli <florian.fainelli@broadcom•com>,
Krzysztof Kozlowski <krzk@kernel•org>,
Dmitry Baryshkov <dmitry.baryshkov@oss•qualcomm.com>,
Mukesh Ojha <mukesh.ojha@oss•qualcomm.com>,
Andre Draszik <andre.draszik@linaro•org>,
Greg Kroah-Hartman <gregkh@linuxfoundation•org>,
Kathiravan Thirumoorthy
<kathiravan.thirumoorthy@oss•qualcomm.com>,
Srinivas Kandagatla <srini@kernel•org>,
Bartosz Golaszewski <bartosz.golaszewski@oss•qualcomm.com>,
Sebastian Reichel <sre@kernel•org>,
Mark Rutland <mark.rutland@arm•com>,
Lorenzo Pieralisi <lpieralisi@kernel•org>,
"Rafael J. Wysocki" <rafael@kernel•org>,
Daniel Lezcano <daniel.lezcano@kernel•org>,
Christian Loehle <christian.loehle@arm•com>,
Ulf Hansson <ulfh@kernel•org>, Rob Herring <robh@kernel•org>,
Krzysztof Kozlowski <krzk+dt@kernel•org>,
Conor Dooley <conor+dt@kernel•org>,
Bjorn Andersson <andersson@kernel•org>,
Konrad Dybcio <konradybcio@kernel•org>,
Arnd Bergmann <arnd@arndb•de>,
Souvik Chakravarty <Souvik.Chakravarty@arm•com>,
Andy Yan <andy.yan@rock-chips•com>,
Matthias Brugger <matthias.bgg@gmail•com>,
John Stultz <john.stultz@linaro•org>,
Moritz Fischer <moritz.fischer@ettus•com>,
Sudeep Holla <sudeep.holla@kernel•org>
Subject: Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
Date: Wed, 20 May 2026 23:21:02 +0530 [thread overview]
Message-ID: <b16ab4d5-40d0-4438-8fab-6cff3fa6845c@oss.qualcomm.com> (raw)
In-Reply-To: <f604833d-b333-4514-91fa-3cf95f99f9e7@oss.qualcomm.com>
On 18-05-2026 22:11, Shivendra Pratap wrote:
>
>
> On 18-05-2026 14:27, Bartosz Golaszewski wrote:
>> On Thu, 14 May 2026 16:25:49 +0200, Shivendra Pratap
>> <shivendra.pratap@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 a callback that allows drivers to provide an
>>> explicit firmware node. The node is added to the MFD child device during
>>> registration when none is assigned by device tree, ACPI, or software
>>> matching.
>>>
>>> Suggested-by: Bartosz Golaszewski <bartosz.golaszewski@oss•qualcomm.com>
>>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss•qualcomm.com>
>>> ---
>>> drivers/mfd/mfd-core.c | 30 ++++++++++++++++++++++++++++++
>>> include/linux/mfd/core.h | 14 ++++++++++++++
>>> 2 files changed, 44 insertions(+)
>>>
>>> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
>>> index
>>> 7aa32b90cf1eb7fa0a05bf3dc506e60a262c9850..cc2a2a924d6d3044e29a9f864b536ee325ed797b 100644
>>> --- a/drivers/mfd/mfd-core.c
>>> +++ b/drivers/mfd/mfd-core.c
>>> @@ -10,6 +10,7 @@
>>> #include <linux/kernel.h>
>>> #include <linux/platform_device.h>
>>> #include <linux/acpi.h>
>>> +#include <linux/fwnode.h>
>>> #include <linux/list.h>
>>> #include <linux/property.h>
>>> #include <linux/mfd/core.h>
>>> @@ -148,6 +149,11 @@ static int mfd_match_of_node_to_dev(struct
>>> platform_device *pdev,
>>> return 0;
>>> }
>>>
>>> +static void mfd_child_fwnode_put(void *data)
>>> +{
>>> + fwnode_handle_put(data);
>>> +}
>>
>> Ah, this seems to answer my previous question, but...
>>
>>> +
>>> static int mfd_add_device(struct device *parent, int id,
>>> const struct mfd_cell *cell,
>>> struct resource *mem_base,
>>> @@ -156,6 +162,7 @@ static int mfd_add_device(struct device *parent,
>>> int id,
>>> struct resource *res;
>>> struct platform_device *pdev;
>>> struct mfd_of_node_entry *of_entry, *tmp;
>>> + struct fwnode_handle *fwnode;
>>> bool disabled = false;
>>> int ret = -ENOMEM;
>>> int platform_id;
>>> @@ -224,6 +231,29 @@ static int mfd_add_device(struct device *parent,
>>> int id,
>>>
>>> mfd_acpi_add_device(cell, pdev);
>>>
>>> + if (!pdev->dev.fwnode && cell->get_child_fwnode) {
>>> + fwnode = cell->get_child_fwnode(parent);
>>> + if (fwnode) {
>>> + device_set_node(&pdev->dev, fwnode);
>>> +
>>> + /*
>>> + * platform_device_release() drops only of_node refs.
>>
>> Which is a separate problem we're discussing elsewhere. It should
>> probably drop
>> the fwnode reference it holds, not the one of of_node.
>>
>>> + * Track non-OF fwnodes explicitly so they are put on
>>> + * all teardown paths.
>>> + */
>>> + if (!to_of_node(fwnode)) {
>>> + ret = devm_add_action(&pdev->dev,
>>> + mfd_child_fwnode_put,
>>> + fwnode);
>>
>> What if the device never gets bound to the driver? The release will
>> never be
>> called, this is why it's wrong to schedule devres actions for unbound
>> devices
>> and one of the reasons for patch 1 in this series.
>>
>> What I suggest for now is: in tear-down path: see if the cell has the
>> get_child_fwnode() callback and - if so - drop the reference. Add a
>> big, fat
>> comment saying that this must be removed if we decide to switch to
>> dropping the
>> device's fwnode reference in platform driver core which may happen soon.
>
> Ack. sure. lets me work it out.
Hi Lee,
While planning to address this for the next spin, it would be helpful if
you could review and share any additional comments that should be taken
care in next spin.
thanks,
Shivendra
next prev parent reply other threads:[~2026-05-20 17:51 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 14:25 [PATCH v22 00/13] Implement PSCI reboot mode driver for PSCI resets Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 01/13] power: reset: reboot-mode: Remove devres based allocations Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 02/13] power: reset: reboot-mode: Add support for 64 bit magic Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 03/13] power: reset: reboot-mode: Add support for predefined reboot modes Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 04/13] firmware: psci: Introduce command-based resets Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 05/13] mfd: psci-mfd: Add PSCI MFD driver for cpuidle-psci-domain cell Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 06/13] dt-bindings: arm: Document reboot mode magic Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 07/13] power: reset: Add psci-reboot-mode driver Shivendra Pratap
2026-05-18 8:58 ` Bartosz Golaszewski
2026-05-18 16:45 ` Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells Shivendra Pratap
2026-05-18 8:57 ` Bartosz Golaszewski
2026-05-18 16:41 ` Shivendra Pratap
2026-05-20 17:51 ` Shivendra Pratap [this message]
2026-05-21 11:26 ` Lee Jones
2026-05-21 12:29 ` Bartosz Golaszewski
2026-05-21 13:24 ` Lee Jones
2026-05-21 13:36 ` Bartosz Golaszewski
2026-05-21 16:27 ` Lee Jones
2026-05-22 9:08 ` Bartosz Golaszewski
2026-05-25 9:34 ` Shivendra Pratap
2026-06-03 18:51 ` Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 09/13] mfd: psci-mfd: Add psci-reboot-mode child cell Shivendra Pratap
2026-05-18 8:53 ` Bartosz Golaszewski
2026-05-14 14:25 ` [PATCH v22 10/13] arm64: dts: qcom: Add psci reboot-modes for kodiak boards Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 11/13] arm64: dts: qcom: Add psci reboot-modes for lemans boards Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 12/13] arm64: dts: qcom: Add psci reboot-modes for monaco boards Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 13/13] arm64: dts: qcom: Add psci reboot-modes for talos boards Shivendra Pratap
2026-05-29 13:30 ` [PATCH v22 00/13] Implement PSCI reboot mode driver for PSCI resets Shivendra Pratap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b16ab4d5-40d0-4438-8fab-6cff3fa6845c@oss.qualcomm.com \
--to=shivendra.pratap@oss$(echo .)qualcomm.com \
--cc=Souvik.Chakravarty@arm$(echo .)com \
--cc=andersson@kernel$(echo .)org \
--cc=andre.draszik@linaro$(echo .)org \
--cc=andy.yan@rock-chips$(echo .)com \
--cc=arnd@arndb$(echo .)de \
--cc=bartosz.golaszewski@oss$(echo .)qualcomm.com \
--cc=brgl@kernel$(echo .)org \
--cc=christian.loehle@arm$(echo .)com \
--cc=conor+dt@kernel$(echo .)org \
--cc=daniel.lezcano@kernel$(echo .)org \
--cc=devicetree@vger$(echo .)kernel.org \
--cc=dmitry.baryshkov@oss$(echo .)qualcomm.com \
--cc=florian.fainelli@broadcom$(echo .)com \
--cc=gregkh@linuxfoundation$(echo .)org \
--cc=john.stultz@linaro$(echo .)org \
--cc=kathiravan.thirumoorthy@oss$(echo .)qualcomm.com \
--cc=konradybcio@kernel$(echo .)org \
--cc=krzk+dt@kernel$(echo .)org \
--cc=krzk@kernel$(echo .)org \
--cc=lee@kernel$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-arm-msm@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-pm@vger$(echo .)kernel.org \
--cc=lpieralisi@kernel$(echo .)org \
--cc=mark.rutland@arm$(echo .)com \
--cc=matthias.bgg@gmail$(echo .)com \
--cc=moritz.fischer@ettus$(echo .)com \
--cc=mukesh.ojha@oss$(echo .)qualcomm.com \
--cc=rafael@kernel$(echo .)org \
--cc=robh@kernel$(echo .)org \
--cc=sre@kernel$(echo .)org \
--cc=srini@kernel$(echo .)org \
--cc=sudeep.holla@kernel$(echo .)org \
--cc=ulfh@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox