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

Arnd Bergmann arnd at kernel.org
Fri Oct 23 03:17:37 EDT 2020


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.

      Arnd



More information about the linux-arm-kernel mailing list