From: sashiko-bot@kernel.org
To: "Herve Codina" <herve.codina@bootlin.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v9 4/4] bus: simple-pm-bus: Populate child nodes at probe
Date: Mon, 09 Nov 2026 14:50:21 +0000 [thread overview]
Message-ID: <sashiko-outbox-205130@kernel.org> (raw)
In-Reply-To: <20261109140916.90625-5-herve.codina@bootlin.com>
Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [High] bus: simple-pm-bus: unpopulated grandchildren in
simple_pm_bus_populate()
- [Medium] bus: simple-pm-bus: auxdata lookup table dropped in
simple_pm_bus_probe()
- [Low] bus: simple-pm-bus: missing Fixes trailer for commit
98e96cf80045
--
commit 7ba99d9ea04b1e1a29eebc1e1525489b300fe107
Author: Herve Codina <herve.codina@bootlin.com>
bus: simple-pm-bus: Populate child nodes at probe
This commit updates simple_pm_bus_probe() to populate child devices for
transparent bus matches (such as simple-bus, simple-mfd, isa, and
arm,amba-bus) during probe, and skips runtime PM calls in
simple_pm_bus_depopulate() when runtime PM is not enabled.
[Severity: Low]
In the commit message, this patch fixes the probe behavior for bus-only
devices where returning 0 without populating children caused
device_links_driver_bound() to create wrong fw_devlinks. Should the commit
message include a Fixes tag for 98e96cf80045 ("drivers: bus: simple-pm-bus:
Add support for probing simple bus only devices")?
[Severity: High]
In drivers/bus/simple-pm-bus.c, simple_pm_bus_probe() at line 104 now calls
simple_pm_bus_populate(), which at line 64 calls of_platform_populate() with
NULL for the matches table instead of calling of_platform_default_populate().
Does this leave grandchild devices unpopulated when a child node has a
device-specific compatible string followed by a fallback bus or MFD
compatible string (such as compatible = "vendor,syscon", "syscon",
"simple-mfd")?
When an outer of_platform_default_populate() creates an ONLY_BUS device
after simple_pm_bus_driver is registered, of_platform_device_create_pdata()
synchronously runs simple_pm_bus_probe() before the outer
of_platform_bus_create() reaches its child loop. Inside
simple_pm_bus_populate(), of_platform_populate(np, NULL, lookup, dev)
creates the child platform_device and sets OF_POPULATED on the child node.
During device_add(), simple_pm_bus_probe() rejects that child with -ENODEV
at line 100 because the generic bus compatible is not first, and
of_platform_bus_create() returns 0 at drivers/of/platform.c line 371 without
recursing into the child's subnodes because matches is NULL. When control
returns to the outer of_platform_default_populate() loop,
of_platform_device_create_pdata() sees OF_POPULATED already set on the child
and returns NULL, so the outer loop also returns 0 without populating the
grandchildren. Calling of_platform_default_populate(np, lookup, dev) in
simple_pm_bus_populate() would pass the default match table and avoid
skipping those grandchildren.
[Severity: Medium]
In drivers/bus/simple-pm-bus.c, simple_pm_bus_probe() reads lookup from
dev_get_platdata(dev) at line 74 and passes it to simple_pm_bus_populate()
at line 104. Can this drop the caller's of_dev_auxdata lookup table for
devices beneath a simple-bus node?
When a caller such as sysc_probe() in drivers/bus/ti-sysc.c (line 3243)
calls of_platform_populate() with a match table that includes simple-bus and
a non-NULL auxdata lookup table, of_platform_bus_create() only attaches
platform_data to the simple-bus device itself if the auxdata table has an
explicit entry matching the simple-bus node. Otherwise dev_get_platdata(dev)
on the simple-bus device is NULL, and simple_pm_bus_probe() synchronously
populates all child devices of the simple-bus with lookup = NULL (setting
OF_POPULATED on each child) before the caller's of_platform_bus_create()
loop can recurse with the caller's auxdata table. As a result, child devices
under that simple-bus lose their auxdata bus_id and platform_data overrides.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261109140916.90625-1-herve.codina@bootlin.com?part=4
prev parent reply other threads:[~2026-11-09 14:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 14:08 [PATCH v9 0/4] lan966x pci device: Add support for SFPs, simple-bus part Herve Codina
2026-11-09 14:08 ` [PATCH v9 1/4] bus: simple-pm-bus: Avoid inconsistencies between probe() and remove() Herve Codina
2026-11-09 14:08 ` [PATCH v9 2/4] bus: simple-pm-bus: Remove the remove() function Herve Codina
2026-11-09 14:08 ` [PATCH v9 3/4] bus: simple-pm-bus: Remove child devices when the bus is unbound Herve Codina
2026-11-09 14:08 ` [PATCH v9 4/4] bus: simple-pm-bus: Populate child nodes at probe Herve Codina
2026-11-09 14:50 ` sashiko-bot [this message]
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=sashiko-outbox-205130@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=herve.codina@bootlin.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox