On Mon, Dec 14, 2020 at 8:09 PM Ray Jui <ray.jui@xxxxxxxxxxxx> wrote:
> On 11/28/2020 1:58 AM, Arnd Bergmann wrote:
> > On Sat, Nov 28, 2020 at 5:53 AM Florian Fainelli <f.fainelli@xxxxxxxxx> wrote:
> >>
> >> On Fri, 16 Oct 2020 17:08:32 +0800, Zhen Lei <thunder.leizhen@xxxxxxxxxx> wrote:
> >>> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
> >>> property must have the same "#address-cells" and "#size-cells" values as
> >>> the parent node. Otherwise, the following warnings is reported:
> >>>
> >>> 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)
> >>>
> >>> Arnd Bergmann figured out why it's necessary:
> >>> Also note that the #address-cells=<1> means that any device under
> >>> this bus is assumed to only support 32-bit addressing, and DMA will
> >>> have to go through a slow swiotlb in the absence of an IOMMU.
> >>>
> >>> Suggested-by: Arnd Bergmann <arnd@xxxxxxxx>
> >>> Signed-off-by: Zhen Lei <thunder.leizhen@xxxxxxxxxx>
> >>> ---
> >>
> >> Applied to devicetree-arm64/next, thanks!
> >
> > The notification may have gone missing, but I had merged it into v5.10-fixes
> > already, and as of today, it's in mainline, so you can drop it from your
> > next branch, or just leave it in if you want to avoid taking things out of
> > your tree.
>
> It looks like this patch might have caused a regression on Stingray USB.
> Bharat, could you please confirm?
Well, this is what I had asked about originally, I assumed that
Florian had asked someone with access to the datasheet.
> The fix would be to properly define the dma-ranges to be 32-bit (0x0 ~
> 0xffffffff) since IOMMU is disabled on this device and the device's DMA
> engine is on a 32-bit bus.
That's not how dma-ranges work, they tell you what the capabilities
of the bus are, while the capabilities of the device are identified by
the properties of that device.
The device claims to be compatible with "generic-xhci", so the
driver asks for a 64-bit mask to be set according to the xhci
specification. If this device is not xhci compliant, then it should
not ask for a 64-bit mask.
However, if this is a 64-bit capable bus master on a 32-bit bus,
then the dma-ranges property should list the capabilities of the
bus, so the kernel can force the driver to fall back to 32-bit addressing.
Arnd
