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: <20220302211100.65264-2-paul.kocialkowski@bootlin.com>
Date:   Wed,  2 Mar 2022 22:10:53 +0100
From:   Paul Kocialkowski <paul.kocialkowski@...tlin.com>
To:     devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org
Cc:     Rob Herring <robh+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Samuel Holland <samuel@...lland.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Maxime Ripard <mripard@...nel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>
Subject: [PATCH RFC v3 1/8] of: Mark interconnects property supplier as optional

In order to set their correct DMA address offset, some devices rely on
the device-tree interconnects property which identifies an
interconnect node that provides a dma-ranges property that can be used
to set said offset.

Since that logic is all handled by the generic openfirmware and driver
code, the device-tree description could be enough to properly set
the offset.

However the interconnects property is currently not marked as
optional, which implies that a driver for the corresponding node
must be loaded as a requirement. When no such driver exists, this
results in an endless EPROBE_DEFER which gets propagated to the
calling driver. This ends up in the driver never loading.

Marking the interconnects property as optional makes it possible
to load the driver in that situation, since the EPROBE_DEFER return
code will no longer be propagated to the driver.

There might however be undesirable consequences with this change,
which I do not fully grasp at this point.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@...tlin.com>
---
 drivers/of/property.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index 8e90071de6ed..ef7c56b510e8 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1365,7 +1365,7 @@ static struct device_node *parse_interrupts(struct device_node *np,
 
 static const struct supplier_bindings of_supplier_bindings[] = {
 	{ .parse_prop = parse_clocks, },
-	{ .parse_prop = parse_interconnects, },
+	{ .parse_prop = parse_interconnects, .optional = true,},
 	{ .parse_prop = parse_iommus, .optional = true, },
 	{ .parse_prop = parse_iommu_maps, .optional = true, },
 	{ .parse_prop = parse_mboxes, },
-- 
2.35.1

Powered by blists - more mailing lists