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: <53698380.1060006@gmail.com>
Date:	Tue, 06 May 2014 17:51:12 -0700
From:	Frank Rowand <frowand.list@...il.com>
To:	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Josh Cartwright <joshc@...eaurora.org>,
	Courtney Cavin <courtney.cavin@...ymobile.com>
CC:	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: [RFC PATCH 1/3] devicetree: set bus type same as parent

From: Frank Rowand <frank.rowand@...ymobile.com>

This is a somewhat scary patch since it touches a path that is central to
device creation based on the device tree.  It should not be applied without
careful consideration.

I am not sure if this patch is a good idea, even if it does not break
anything.

An issue with the path of SPMI nodes under /sys/bus/... was reported in
https://lkml.org/lkml/2014/4/23/312.  The symptom is that two different
grandchild nodes of the spmi with the same node-name@...t-address will
result in attempting to create duplicate links at
/sys/bus/platform/devices/unit-address.node-name.  It turns out that the
specific example provided might not be an expected configuration for
current hardware, but the reported trap remains an issue.

The common pattern exposed is a driver probe function calling
of_platform_populate() to create child devices.  As the reporting
email noted, the devices are created with dev.bus set to
platform_bus_type.  Thus all devices created via this pattern will
result in a link in /sys/bus/platform/devices/, with the risk that
a name collision will occur.

This patch reduces the scope of possible name collisions to devices
on the same bus type.  This is still not ideal, because a legal
device tree source file can result in run time errors.  In the case
of SPMI nodes, the collisions will occur in /bus/spmi/devices/.

I have not investigated whether other drivers would be negatively impacted
by this change - there are 26 drivers in tree that call of_platform_populate().

Signed-off-by: Frank Rowand <frank.rowand@...ymobile.com>
---
 drivers/of/platform.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: b/drivers/of/platform.c
===================================================================
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -217,7 +217,10 @@ static struct platform_device *of_platfo
 	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
 	if (!dev->dev.dma_mask)
 		dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
-	dev->dev.bus = &platform_bus_type;
+	if (parent && parent->bus)
+		dev->dev.bus = parent->bus;
+	else
+		dev->dev.bus = &platform_bus_type;
 	dev->dev.platform_data = platform_data;
 
 	/* We do not fill the DMA ops for platform devices by default.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ