linux-kernel - Re: dma_mask limited to 32-bits with OF platform device

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: <827fa19d-1990-16bc-33f5-fc82ac0d4a8a@arm.com>
Date:   Wed, 19 Feb 2020 15:25:29 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Roger Quadros <rogerq@...com>, Rob Herring <robh+dt@...nel.org>
Cc:     Christoph Hellwig <hch@....de>,
        Péter Ujfalusi <peter.ujfalusi@...com>,
        Murali Karicheri <m-karicheri2@...com>,
        "Nori, Sekhar" <nsekhar@...com>, "Anna, Suman" <s-anna@...com>,
        Stefan Wahren <stefan.wahren@...e.com>,
        Andreas Färber <afaerber@...e.de>,
        Hans Verkuil <hverkuil@...all.nl>, devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Nishanth Menon <nm@...com>,
        "hdegoede@...hat.com" <hdegoede@...hat.com>,
        Vignesh Raghavendra <vigneshr@...com>
Subject: Re: dma_mask limited to 32-bits with OF platform device

On 19/02/2020 2:29 pm, Roger Quadros wrote:
> Rob,
> 
> On 18/02/2020 19:22, Rob Herring wrote:
>> On Tue, Feb 18, 2020 at 2:28 AM Roger Quadros <rogerq@...com> wrote:
>>>
>>> Chrishtoph,
>>>
>>> The branch works fine for SATA on DRA7 with CONFIG_LPAE once I
>>> have the below DT fix.
>>>
>>> Do you intend to send these fixes to -stable?
>>>
>>> ------------------------- arch/arm/boot/dts/dra7.dtsi 
>>> -------------------------
>>> index d78b684e7fca..853ecf3cfb37 100644
>>> @@ -645,6 +645,8 @@
>>>                  sata: sata@...41100 {
>>>                          compatible = "snps,dwc-ahci";
>>>                          reg = <0x4a140000 0x1100>, <0x4a141100 0x7>;
>>> +                       #size-cells = <2>;
>>> +                       dma-ranges = <0x00000000 0x00000000 0x1 
>>> 0x00000000>;
>>
>> dma-ranges should be in the parent (bus) node, not the device node.
> 
> I didn't understand why.
> 
> There are many devices on the parent bus node and all devices might not 
> have the 32-bit DMA limit
> the SATA controller has.
> 
> SATA controller is the bus master and the ATA devices are children of 
> the SATA controller.

But SATA is not a memory-mapped bus - in the context of MMIO, the AHCI 
is the bus-master device, not a bridge or level of interconnect. The 
DeviceTree spec[1] clearly defines dma-ranges as an address translation 
between a "parent bus" and a "child bus".

If in the worst case this address-limited interconnect really only 
exists between the AHCI's master interface and everything else in the 
system, then you'll have to describe it explicitly to meet DT's 
expectation of a "bus" (e.g. [2]). Yes, it's a bit clunky, but any 
scheme has its edge cases.

>  From Documentation/devicetree/booting-without-of.txt
> 
> * DMA Bus master
> Optional property:
> - dma-ranges: <prop-encoded-array> encoded as arbitrary number of 
> triplets of
>          (child-bus-address, parent-bus-address, length). Each triplet 
> specified
>          describes a contiguous DMA address range.
>          The dma-ranges property is used to describe the direct memory 
> access (DMA)
>          structure of a memory-mapped bus whose device tree parent can 
> be accessed
>          from DMA operations originating from the bus. It provides a 
> means of
>          defining a mapping or translation between the physical address 
> space of
>          the bus and the physical address space of the parent of the bus.
>          (for more information see the Devicetree Specification)
> 
> * DMA Bus child
> Optional property:
> - dma-ranges: <empty> value. if present - It means that DMA addresses
>          translation has to be enabled for this device.

Disregarding that this was apparently never in ePAPR, so not 
grandfathered in to DTSpec, and effectively nobody ever has actually 
followed it (oh, if only...), note "<empty>" - that still doesn't imply 
that a *non-empty* dma-ranges would be valid on device nodes.

Robin.

[1] https://www.devicetree.org/specifications/
[2] 
https://lore.kernel.org/lkml/20181010120737.30300-20-laurentiu.tudor@nxp.com/