linux-kernel - [PATCH] powerpc/fsl_lbc: Explicitly populate bus

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>] [day] [month] [year] [list]

Message-Id: <20250209-localbus-v1-1-efcd780153a0@posteo.net>
Date: Sun, 09 Feb 2025 22:58:50 +0100
From: J. Neuschäfer via B4 Relay <devnull+j.ne.posteo.net@...nel.org>
To: Madhavan Srinivasan <maddy@...ux.ibm.com>, 
 Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>, 
 Christophe Leroy <christophe.leroy@...roup.eu>, 
 Naveen N Rao <naveen@...nel.org>
Cc: linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org, 
 J. Neuschäfer <j.ne@...teo.net>
Subject: [PATCH] powerpc/fsl_lbc: Explicitly populate bus

From: "J. Neuschäfer" <j.ne@...teo.net>

Historically, devicetree nodes representing the Freescale Enhanced
Local Bus Controller (eLBC) have compatible strings such as:

    compatible = "fsl,mpc8313-elbc", "fsl,elbc", "simple-bus";

The "simple-bus" string causes the bus to be populated, and the memory
devices contained within it to be discovered. The eLBC bus (as
represented in device trees) differs from a simple-bus in a few ways,
though:

 - Addresses are not simple/linear: The first cell of an address is a
   chip select, the second is an linear address within the space thus
   selected. Representing 1,0 as 100000000, for example, would decrease
   readability[1].
 - It is expected that the devices on a simple-bus "can be accessed
   directly without additional configuration required"[2], but the eLBC
   needs some configuration.

To accommodate devicetrees that declare an eLBC without "simple-bus",
explicitly populate the bus in the eLBC driver.

[1]: dtc makes such a suggestion opon encountering an eLBC
[2]: Quoting the Devicetree Specification Release v0.3

Signed-off-by: J. Neuschäfer <j.ne@...teo.net>
---
 arch/powerpc/sysdev/fsl_lbc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index 217cea150987df1e1b5c6dbf9e9a1607dd5ce49b..2007ced997fcf0c7059e5b780893b530764dc8b2 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -20,6 +20,7 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/of_platform.h>
 #include <linux/slab.h>
 #include <linux/sched.h>
 #include <linux/platform_device.h>
@@ -336,7 +337,7 @@ static int fsl_lbc_ctrl_probe(struct platform_device *dev)
 	/* Enable interrupts for any detected events */
 	out_be32(&fsl_lbc_ctrl_dev->regs->lteir, LTEIR_ENABLE);

-	return 0;
+	return devm_of_platform_populate(&dev->dev);

 err1:
 	free_irq(fsl_lbc_ctrl_dev->irq[0], fsl_lbc_ctrl_dev);

---
base-commit: 7ccde445dddcca030cd6ed66974bb80915ad9dd5
change-id: 20250209-localbus-94a6ebb04c12

Best regards,
-- 
J. Neuschäfer <j.ne@...teo.net>