[PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges

[Leizhen (ThunderTown)]

Hi, everybody:
  How do we deal with this problem? I updated the kernel to the latest and the problem still persists.

  make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24 dtbs 2>err.txt
  vim err.txt

arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)




On 2020/10/26 10:21, Leizhen (ThunderTown) wrote:
> 
> 
> On 2020/10/23 15:17, Arnd Bergmann wrote:
>> On Sun, Oct 18, 2020 at 4:10 AM Leizhen (ThunderTown)
>> <thunder.leizhen at huawei.com> wrote:
>>> On 2020/10/17 3:27, Florian Fainelli wrote:
>>>> On 10/16/20 11:23 AM, Arnd Bergmann wrote:
>>>>> On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli <f.fainelli at gmail.com> wrote:
>>>>>> On 10/16/20 4:01 AM, Arnd Bergmann wrote:
>>>>>>> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen at huawei.com> wrote:
>>>>>>>>
>>>>>>>> Suggested-by: Arnd Bergmann <arnd at arndb.de>
>>>>>>>> Signed-off-by: Zhen Lei <thunder.leizhen at huawei.com>
>>>>>>>
>>>>>>> Acked-by: Arnd Bergmann <arnd at arndb.de>
>>>>>>>
>>>>>>> I see that at least the 'bcd' and 'xhci' devices in fact try to
>>>>>>> use 64-bit DMA. It would be good to test this on actual
>>>>>>> hardware to ensure that it works correctly when this is enabled.
>>>>>>>
>>>>>>> Ideally avoiding the swiotlb bounce buffering should only
>>>>>>> make it faster here, but there are many chips on which
>>>>>>> 64-bit DMA is broken in some form.
>>>>>>
>>>>>> Is this change really an improvement though? This 'usb' pseudo bus node
>>>>>> could just keep being defined with #address-cells = <1> and #size-cells
>>>>>> = <1> so as to satisfy the 'reg' definition however we could just adjust
>>>>>> dma-ranges to indicate full 64-bit addressing capability. Would not that
>>>>>> work?
>>>>>
>>>>> When #address-cells is '1', you cannot specify dma-ranges that
>>>>> go beyond a 32-bit address range.
>>>>
>>>> Would not it be enough to remove the 'dma-ranges' property though? Sorry
>>>> for being slow here.
>>>
>>> Remove the 'dma-ranges' property should also work. After all, it is equivalent
>>> to the original empty dma-ranges scheme. In addition, since the IOMMU nodes are
>>> defined, it should be enabled.
>>
>> Are you sure? I was expecting the IOMMU not to get used here since
>> the devices do contain list an 'iommus' property.
> 
> OK，If the SMMU maybe disabled, then your proposal is necessary.
> 
>>
>>       Arnd
>>
>> .
>>