Hi Stefan, On 25/07/17 06:19, Stefan Wahren wrote: >>> With arm64 4.13-rc1 I get no eth0 device on Pi3 (openSUSE Tumbleweed). >>> The v4.13-rc1 DT works okay with a 4.12 kernel. >>> >>> Possibly related: >>> >>> [ 15.916350] OF: /soc/usb@7e980000: could not get #phy-cells for /phy >>> >>> [ 16.496662] usb 1-1: new high-speed USB device number 2 using dwc2 >>> [ 16.502988] dwc2 3f980000.usb: Cannot do DMA to address >>> 0x00000000335da400 >> >> This is from SWIOTLB's map_single(), which means whatever device was >> passed into dma_map_single() when mapping the URB had a DMA mask smaller >> than 30 bits (or none at all), which sounds wrong and is almost >> certainly the root of the problem (i.e. it probably wasn't the actual >> HCD device described in DT and set up by of_dma_configure()). > > how can i figure out what's cause this issue (bcm283x or dwc2 specific)? > > The dwc2 hcd already check the DMA mask on probe [1] and i never saw a warning in error case. I'll admit I'm a little stumped, since the two commits to dwc2 since 4.12 seem entirely inconsequential. The only way I can see this happening is if the first dma_capable() check in swiotlb_map_page() fails, and since swiotlb_force must be set to SWIOTLB_NOFORCE in order to print the error later, and the address and size look reasonable, that only leaves dev->dma_mask as the culprit. >From the subsequent fallout (which on closer inspection looks more to do with calling into uninitialised SWIOTLB state than the arm64 DMA code actually doing anything wrong), I'd guess dev->dma_pfn_offset is probably 0 as well, which further points to the wrong device. Maybe something's changed lower down in the USB core? Turning on tracing and booting with "tp_printk trace_event=swiotlb_bounced" on the command line should shed a bit more light on what's going on. Robin. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
