From: Hans de Goede <hansg@kernel.org>
To: Maurizio Casciano <mauriziocasciano7@gmail.com>,
Sebastian Reichel <sre@kernel.org>
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
Maurizio Casciano <maurizio.casciano@eng.it>,
stable@vger.kernel.org
Subject: Re: [PATCH] power: supply: core: Honor supplied-from with CONFIG_OF=y
Date: Tue, 1 Sep 2026 18:07:42 +0200 [thread overview]
Message-ID: <c9cf1a69-9136-4f64-b223-aa038520a0a9@kernel.org> (raw)
In-Reply-To: <20260901145156.3177187-1-mauriziocasciano7@gmail.com>
Hi,
Thank you for your patch.
On 1-Sep-26 16:51, Maurizio Casciano wrote:
> From: Maurizio Casciano <maurizio.casciano@eng.it>
>
> The supplied-from device property is the name-based counterpart to
> firmware-node power-supplies references. It was added for non-DT platforms,
> but its parser is compiled only when CONFIG_OF is disabled. CONFIG_OF is a
> global kernel option, so x86 systems commonly enable it even when
> individual power supplies are described by software nodes.
>
> Consequently, these consumers never populate supplied_from and supplier
> notifications do not reach their external_power_changed() callbacks. On a
> Lenovo Yoga Book YB1-X91L, ftrace showed the Whiskey Cove supplier
> notification running without invoking the BQ25892 callback, leaving the
> input current limit at its boot-time value.
>
> Move the generic supplied-from parser into an unconditional helper and try
> it before firmware-reference power-supplies lookup. Keep an explicitly
> supplied list at the highest priority and retain power-supplies as the
> fallback. With the fix, ftrace shows the BQ25892 callback on hotplug and a
> boot-offline test changes its input current limit from 500 mA to 2 A.
>
> Fixes: 58a36bb06891 ("power: supply: core: Add support for supplied-from device-property")
> Cc: stable@vger.kernel.org
> Signed-off-by: Maurizio Casciano <maurizio.casciano@eng.it>
Interesting. This seems to be a new problem / development in 7.3-rc1
where it seems CONFIG_OF now seems to get enabled on x86 configs.
This change has also lead to other problems, e.g. :
https://bugzilla.redhat.com/show_bug.cgi?id=2523734#c7
Still I agree that this code should do the right thing when CONFIG_OF
is enabled on x86 which it currently clearly is not doing.
But I don't taking that making the new power_supply_check_supplies_by_name()
function higher priority then proper OF/devicetree node links is a good
idea.
IMHO this should be the fallback (in the CONFIG_OF enabled case)
when no suppliers are found through looking at DT node links first.
Sebastian, what do you think ?
Regards,
Hans
> ---
> drivers/power/supply/power_supply_core.c | 61 ++++++++++++++----------
> 1 file changed, 36 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/power/supply/power_supply_core.c b/drivers/power/supply/power_supply_core.c
> index 00d8bc98d588..5101decebb7a 100644
> --- a/drivers/power/supply/power_supply_core.c
> +++ b/drivers/power/supply/power_supply_core.c
> @@ -190,6 +190,35 @@ static void power_supply_deferred_register_work(struct work_struct *work)
> device_unlock(psy->dev.parent);
> }
>
> +static int power_supply_check_supplies_by_name(struct power_supply *psy)
> +{
> + struct device *parent = psy->dev.parent;
> + int nval, ret;
> +
> + if (!parent)
> + return 0;
> +
> + nval = device_property_string_array_count(parent, "supplied-from");
> + if (nval <= 0)
> + return 0;
> +
> + psy->supplied_from = devm_kmalloc_array(&psy->dev, nval,
> + sizeof(*psy->supplied_from),
> + GFP_KERNEL);
> + if (!psy->supplied_from)
> + return -ENOMEM;
> +
> + ret = device_property_read_string_array(parent, "supplied-from",
> + (const char **)psy->supplied_from,
> + nval);
> + if (ret < 0)
> + return ret;
> +
> + psy->num_supplies = nval;
> +
> + return 0;
> +}
> +
> #ifdef CONFIG_OF
> static int __power_supply_populate_supplied_from(struct power_supply *epsy,
> void *data)
> @@ -262,19 +291,22 @@ static int power_supply_find_supply_from_fwnode(struct fwnode_handle *supply_nod
> static int power_supply_check_supplies(struct power_supply *psy)
> {
> struct fwnode_handle *np;
> - int cnt = 0;
> + int cnt = 0, ret;
>
> /* If there is already a list honor it */
> if (psy->supplied_from && psy->num_supplies > 0)
> return 0;
>
> + /* Check for the name-based "supplied-from" device property first. */
> + ret = power_supply_check_supplies_by_name(psy);
> + if (ret || psy->num_supplies)
> + return ret;
> +
> /* No device node found, nothing to do */
> if (!psy->dev.fwnode)
> return 0;
>
> do {
> - int ret;
> -
> np = fwnode_find_reference(psy->dev.fwnode, "power-supplies", cnt++);
> if (IS_ERR(np))
> break;
> @@ -304,28 +336,7 @@ static int power_supply_check_supplies(struct power_supply *psy)
> #else
> static int power_supply_check_supplies(struct power_supply *psy)
> {
> - int nval, ret;
> -
> - if (!psy->dev.parent)
> - return 0;
> -
> - nval = device_property_string_array_count(psy->dev.parent, "supplied-from");
> - if (nval <= 0)
> - return 0;
> -
> - psy->supplied_from = devm_kmalloc_array(&psy->dev, nval,
> - sizeof(char *), GFP_KERNEL);
> - if (!psy->supplied_from)
> - return -ENOMEM;
> -
> - ret = device_property_read_string_array(psy->dev.parent,
> - "supplied-from", (const char **)psy->supplied_from, nval);
> - if (ret < 0)
> - return ret;
> -
> - psy->num_supplies = nval;
> -
> - return 0;
> + return power_supply_check_supplies_by_name(psy);
> }
> #endif
>
next parent reply other threads:[~2026-09-01 16:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260901145156.3177187-1-mauriziocasciano7@gmail.com>
2026-09-01 16:07 ` Hans de Goede [this message]
2026-09-01 17:04 ` [PATCH] power: supply: core: Honor supplied-from with CONFIG_OF=y Maurizio Casciano
2026-09-09 20:47 ` Sebastian Reichel
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=c9cf1a69-9136-4f64-b223-aa038520a0a9@kernel.org \
--to=hansg@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=maurizio.casciano@eng.it \
--cc=mauriziocasciano7@gmail.com \
--cc=sre@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.