From: sashiko-bot@kernel.org
To: "Herve Codina" <herve.codina@bootlin.com>
Cc: krzk+dt@kernel.org, devicetree@vger.kernel.org,
conor+dt@kernel.org, robh@kernel.org
Subject: Re: [PATCH v7 2/2] bus: simple-pm-bus: Populate child nodes at probe
Date: Tue, 12 May 2026 22:12:30 +0000 [thread overview]
Message-ID: <20260512221231.2876FC2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260511155902.34534-3-herve.codina@bootlin.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch resolves fw_devlink corruption for transparent buses matched via `of_match_table`, but fails to apply this fix to transparent buses bound via `driver_override`, leaving devlinks broken in that path.
--
commit 428668c33cfe17b55dfc398a9e43567a082e1c3e
Author: Herve Codina <herve.codina@bootlin.com>
bus: simple-pm-bus: Populate child nodes at probe
This commit modifies the simple-pm-bus driver to populate child nodes
during probe for transparent buses matched via of_match_table. This prevents
wrong or missing devlinks when fw_devlink assumes a bound driver will
populate its child firmware nodes.
> diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
> index 4b2a793dfbd90..d969bf19a4e95 100644
> --- a/drivers/bus/simple-pm-bus.c
> +++ b/drivers/bus/simple-pm-bus.c
> @@ -42,14 +42,15 @@ static int simple_pm_bus_probe(struct platform_device *pdev)
> match = of_match_device(dev->driver->of_match_table, dev);
> /*
> * These are transparent bus devices (not simple-pm-bus matches) that
[ ... ]
> if (match && match->data) {
> if (of_property_match_string(np, "compatible", match->compatible) == 0)
> - return 0;
> + goto populate;
> else
> return -ENODEV;
> }
Does this leave fw_devlink corrupted when the driver is bound using
driver_override?
Looking at simple_pm_bus_probe(), there is an early exit for driver_override
just before this block:
if (device_has_driver_override(&pdev->dev))
return 0;
Since it still returns directly instead of jumping to the populate label,
transparent buses bound via the driver_override sysfs attribute will skip
populating their child nodes. This seems to trigger the same wrong
supplier assignments from fw_devlink that this patch intended to fix.
> @@ -78,7 +80,7 @@ static void simple_pm_bus_remove(struct platform_device *pdev)
> {
> const void *data = of_device_get_match_data(&pdev->dev);
>
> - if (device_has_driver_override(&pdev->dev) || data)
> + if (device_has_driver_override(&pdev->dev))
> return;
>
> dev_dbg(&pdev->dev, "%s\n", __func__);
> @@ -86,7 +88,8 @@ static void simple_pm_bus_remove(struct platform_device *pdev)
> if (pdev->dev.of_node)
> of_platform_depopulate(&pdev->dev);
If the driver_override path in probe() is updated to populate children,
should this remove() function also be updated to depopulate them?
Additionally, does checking device_has_driver_override() here risk unbalanced
cleanup? If userspace modifies the driver_override sysfs attribute after
probe() but before remove(), this check could evaluate differently during
removal. Since of_platform_depopulate() safely ignores unpopulated buses,
would it be better to call it unconditionally?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260511155902.34534-1-herve.codina@bootlin.com?part=2
next prev parent reply other threads:[~2026-05-12 22:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 15:58 [PATCH v7 0/2] lan966x pci device: Add support for SFPs, simple-bus part Herve Codina
2026-05-11 15:58 ` [PATCH v7 1/2] bus: simple-pm-bus: Remove child devices when the bus is unbound Herve Codina
2026-05-11 15:59 ` [PATCH v7 2/2] bus: simple-pm-bus: Populate child nodes at probe Herve Codina
2026-05-12 22:12 ` sashiko-bot [this message]
2026-05-13 14:32 ` Herve Codina
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=20260512221231.2876FC2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=herve.codina@bootlin.com \
--cc=krzk+dt@kernel.org \
--cc=robh@kernel.org \
--cc=sashiko@lists.linux.dev \
/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.