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

[Leizhen (ThunderTown)]

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
> 
> .
>