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: <20200122092815.449037179@linuxfoundation.org>
Date:   Wed, 22 Jan 2020 10:29:43 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        Liviu Dudau <liviu.dudau@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Robin Murphy <robin.murphy@....com>,
        Sudeep Holla <sudeep.holla@....com>
Subject: [PATCH 4.19 087/103] Revert "arm64: dts: juno: add dma-ranges property"

From: Sudeep Holla <sudeep.holla@....com>

commit 54fb3fe0f211d4729a2551cf9497bd612189af9d upstream.

This reverts commit 193d00a2b35ee3353813b4006a18131122087205.

Commit 951d48855d86 ("of: Make of_dma_get_range() work on bus nodes")
reworked the logic such that of_dma_get_range() works correctly
starting from a bus node containing "dma-ranges".

Since on Juno we don't have a SoC level bus node and "dma-ranges" is
present only in the root node, we get the following error:

OF: translation of DMA address(0) to CPU address failed node(/sram@...00000)
OF: translation of DMA address(0) to CPU address failed node(/uart@...80000)
...
OF: translation of DMA address(0) to CPU address failed node(/mhu@...f0000)
OF: translation of DMA address(0) to CPU address failed node(/iommu@...00000)
OF: translation of DMA address(0) to CPU address failed node(/iommu@...00000)
OF: translation of DMA address(0) to CPU address failed node(/iommu@...00000)

So let's fix it by dropping the "dma-ranges" property for now. This
should be fine since it doesn't represent any kind of device-visible
restriction; it was only there for completeness, and we've since given
in to the assumption that missing "dma-ranges" implies a 1:1 mapping
anyway.

We can add it later with a proper SoC bus node and moving all the
devices that belong there along with the "dma-ranges" if required.

Fixes: 193d00a2b35e ("arm64: dts: juno: add dma-ranges property")
Cc: Rob Herring <robh+dt@...nel.org>
Cc: Liviu Dudau <liviu.dudau@....com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Acked-by: Robin Murphy <robin.murphy@....com>
Signed-off-by: Sudeep Holla <sudeep.holla@....com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

---
 arch/arm64/boot/dts/arm/juno-base.dtsi |    1 -
 1 file changed, 1 deletion(-)

--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -6,7 +6,6 @@
 	/*
 	 *  Devices shared by all Juno boards
 	 */
-	dma-ranges = <0 0 0 0 0x100 0>;
 
 	memtimer: timer@...10000 {
 		compatible = "arm,armv7-timer-mem";


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ