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]

Date:   Tue, 3 Mar 2020 14:06:12 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Roger Quadros <rogerq@...com>, Rob Herring <robh+dt@...nel.org>,
        Christoph Hellwig <hch@....de>
Cc:     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 03/03/2020 8:27 am, Roger Quadros wrote:
[...]
>> With the patch (in the end). dev->bus_dma_limit is still set to 0 and 
>> so is not being used.
>>
>> from of_dma_configure()
>>          ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>> ...
>>          /* ...but only set bus limit if we found valid dma-ranges 
>> earlier */
>>          if (!ret)
>>                  dev->bus_dma_limit = end;
>>
>> There is no other place bus_dma_limit is set. Looks like every device 
>> should inherit that
>> from it's parent right?
> 
> Any ideas how to expect this to work?

Is of_dma_get_range() actually succeeding, or is it tripping up on some 
aspect of the DT (in which case there should be errors in the log)?

Looking again at the fragment below, are you sure it's correct? It 
appears to me like it might actually be defining a 1-byte-long DMA 
range, which indeed I wouldn't really expect to work.

Robin.

>>
>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> index 64a0f90f5b52..5418c31d4da7 100644
>> --- a/arch/arm/boot/dts/dra7.dtsi
>> +++ b/arch/arm/boot/dts/dra7.dtsi
>> @@ -680,15 +680,22 @@
>>           };
>>
>>           /* OCP2SCP3 */
>> -        sata: sata@...41100 {
>> -            compatible = "snps,dwc-ahci";
>> -            reg = <0x4a140000 0x1100>, <0x4a141100 0x7>;
>> -            interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
>> -            phys = <&sata_phy>;
>> -            phy-names = "sata-phy";
>> -            clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>;
>> -            ti,hwmods = "sata";
>> -            ports-implemented = <0x1>;
>> +        sata_aux_bus {
>> +            #address-cells = <2>;
>> +            #size-cells = <2>;
>> +            compatible = "simple-bus";
>> +            ranges = <0x0 0x0 0x4a140000 0x0 0x1200>;
>> +            dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x00000000>;
>> +            sata: sata@...41100 {
>> +                compatible = "snps,dwc-ahci";
>> +                reg = <0x0 0x0 0x0 0x1100>, <0x0 0x1100 0x0 0x7>;
>> +                interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
>> +                phys = <&sata_phy>;
>> +                phy-names = "sata-phy";
>> +                clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>;
>> +                ti,hwmods = "sata";
>> +                ports-implemented = <0x1>;
>> +            };
>>           };
>>
>>           /* OCP2SCP1 */
>>
>