linux-kernel - Re: OF: Can't handle multiple dma-ranges with different offsets

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] [day] [month] [year] [list]

Message-ID: <0fc927d8-2610-3948-fe15-7a7a38be2ccf@alliedtelesis.co.nz>
Date:   Fri, 31 Jul 2020 00:10:47 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "frowand.list@...il.com" <frowand.list@...il.com>,
        "mpe@...erman.id.au" <mpe@...erman.id.au>,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>,
        "paulus@...ba.org" <paulus@...ba.org>,
        "christophe.leroy@....fr" <christophe.leroy@....fr>
CC:     "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: OF: Can't handle multiple dma-ranges with different offsets


On 23/07/20 10:11 am, Chris Packham wrote:
>
> On 22/07/20 4:19 pm, Chris Packham wrote:
>> Hi,
>>
>> I've just fired up linux kernel v5.7 on a p2040 based system and I'm 
>> getting the following new warning
>>
>> OF: Can't handle multiple dma-ranges with different offsets on 
>> node(/pcie@...202000)
>> OF: Can't handle multiple dma-ranges with different offsets on 
>> node(/pcie@...202000)
>>
>> The warning itself was added in commit 9d55bebd9816 ("of/address: 
>> Support multiple 'dma-ranges' entries") but I gather it's pointing 
>> out something about the dts. My boards dts is based heavily on 
>> p2041rdb.dts and the relevant pci2 section is identical (reproduced 
>> below for reference).
>>
>>     pci2: pcie@...202000 {
>>         reg = <0xf 0xfe202000 0 0x1000>;
>>         ranges = <0x02000000 0 0xe0000000 0xc 0x40000000 0 0x20000000
>>               0x01000000 0 0x00000000 0xf 0xf8020000 0 0x00010000>;
>>         pcie@0 {
>>             ranges = <0x02000000 0 0xe0000000
>>                   0x02000000 0 0xe0000000
>>                   0 0x20000000
>>
>>                   0x01000000 0 0x00000000
>>                   0x01000000 0 0x00000000
>>                   0 0x00010000>;
>>         };
>>     };
>>
>> I haven't noticed any ill effect (aside from the scary message). I'm 
>> not sure if there's something missing in the dts or in the code that 
>> checks the ranges. Any guidance would be appreciated.
>
> I've also just checked the T2080RDB on v5.7.9 which shows a similar issue
>
> OF: Can't handle multiple dma-ranges with different offsets on 
> node(/pcie@...250000)
> OF: Can't handle multiple dma-ranges with different offsets on 
> node(/pcie@...250000)
> pcieport 0000:00:00.0: Invalid size 0xfffff9 for dma-range
> pcieport 0000:00:00.0: AER: enabled with IRQ 21
> OF: Can't handle multiple dma-ranges with different offsets on 
> node(/pcie@...270000)
> OF: Can't handle multiple dma-ranges with different offsets on 
> node(/pcie@...270000)
> pcieport 0001:00:00.0: Invalid size 0xfffff9 for dma-range
> pcieport 0001:00:00.0: AER: enabled with IRQ 23

I've been doing a bit more digging. The dma-ranges property is not in 
the dts/dtb. It's actually inserted by u-boot via ft_fsl_pci_setup().

Here's some output from my T2080RDB

root@...uxbox ~]# xxd -g4 
/sys/firmware/devicetree/base/pcie@...240000/dma-ranges
0000000: 02000000 00000000 df000007 0000000f  ................
0000010: fe000000 00000000 00fffff9 42000000  ............B...
0000020: 00000000 00000000 00000000 00000000  ................
0000030: 00000000 df000007 43000000 00000010  ........C.......
0000040: 00000000 00000000 00000000 00000001  ................
0000050: 00000000                             ....

I'm still wondering how best to deal with this. Hopefully without 
needing to deploy a u-boot update.