linux-kernel - [PATCH v1 1/4] driver core: fw_devlink: Use driver to determine probe ability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240123014517.5787-2-mcpratt@pm.me>
Date: Tue, 23 Jan 2024 01:46:18 +0000
From: Michael Pratt <mcpratt@...me>
To: devicetree@...r.kernel.org, gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org
Cc: Michael Pratt <mcpratt@...me>, saravanak@...gle.com, abel.vesa@...aro.org, alexander.stein@...tq-group.com, andriy.shevchenko@...ux.intel.com, bigunclemax@...il.com, brgl@...ev.pl, colin.foster@...advantage.com, djrscally@...il.com, dmitry.baryshkov@...aro.org, festevam@...il.com, fido_max@...ox.ru, frowand.list@...il.com, geert@...ux-m68k.org, heikki.krogerus@...ux.intel.com, kernel@...gutronix.de, linus.walleij@...aro.org, linux@...ck-us.net, luca.weiss@...rphone.com, magnus.damm@...il.com, martin.kepplinger@...i.sm, miquel.raynal@...tlin.com, rafal@...ecki.pl, ansuelsmth@...il.com, richard@....at, sakari.ailus@...ux.intel.com, sudeep.holla@....com, tglx@...utronix.de, tony@...mide.com, vigneshr@...com, dianders@...omium.org, jpb@...nel.org, rafael@...nel.org
Subject: [PATCH v1 1/4] driver core: fw_devlink: Use driver to determine probe ability

The function __fw_devlink_pickup_dangling_consumers()
intends to ignore suppliers that are already capable of probing,
but uses whether or not a bus struct is defined in the device struct.

There are some cases where a firmware child node
can be address translatable but not able to probe
(e.g. the use of of_platform_populate() for MTD partitions),
so whether or not a driver is present is a more accurate way
to guess whether a fwnode represents a real probing device here.

This also serves as a preparation step for further changes
to fw_devlink including making the contents of this function
less strict in order to compensate for more cases being passed into
the rest of the function because the return case is now more strict.

"Hey! Who's driving the bus?"

Signed-off-by: Michael Pratt <mcpratt@...me>
---
 drivers/base/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 14d46af40f9a..c05a5f6b0641 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -214,7 +214,7 @@ static void __fwnode_links_move_consumers(struct fwnode_handle *from,
  * @new_sup: fwnode of new supplier
  *
  * If the @fwnode has a corresponding struct device and the device supports
- * probing (that is, added to a bus), then we want to let fw_devlink create
+ * probing (that is, bound to a driver), then we want to let fw_devlink create
  * MANAGED device links to this device, so leave @fwnode and its descendant's
  * fwnode links alone.
  *
@@ -225,7 +225,7 @@ static void __fw_devlink_pickup_dangling_consumers(struct fwnode_handle *fwnode,
 {
 	struct fwnode_handle *child;
 
-	if (fwnode->dev && fwnode->dev->bus)
+	if (fwnode->dev && fwnode->dev->driver)
 		return;
 
 	fwnode->flags |= FWNODE_FLAG_NOT_DEVICE;
-- 
2.30.2