Rpi3: no ethernet in 4.13: bisected to patch 'USB: of: fix root-hub device-tree node handling'

[Johan Hovold]

On Wed, Aug 02, 2017 at 12:43:01PM +0100, Robin Murphy wrote:
> On 02/08/17 12:10, Stefan Wahren wrote:
> > Am 02.08.2017 um 09:03 schrieb Hans Verkuil:
> >> When testing with my Raspberry Pi 3 and the 4.13-rcX mainline kernel
> >> I discovered that there was no ethernet. After bisecting I got to commit
> >> 2bf69867 ('USB: of: fix root-hub device-tree node handling').
> >>
> >> With that commit lsusb outputs:
> >>
> >> rpi3: ~ # lsusb
> >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> >>
> >> After reverting just that commit (I'm on 4.13-rc3 now) ethernet is
> >> restored and lsusb gives me:
> >>
> >> rpi3: ~ $ lsusb
> >> Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
> >> Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
> >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> >>
> >> I don't speak USB, so I have no idea why this patch causes these issues,
> >> but I am happy to test patches.
> > 
> > Thanks for finding.
> > 
> > Just a note, Andreas Färber also found a regression in 4.13-rc1, which
> > is related to USB & DMA [1].
> > Unfortunately i wasn't able to bisect this issue. I think it's related
> > to the configuration.
> 
> OK, so from the look of 2bf69867, whatever struct device dwc2 is calling
> dma_set_mask() on is not the same one as ends up getting used for DMA
> API calls. That in itself is a bug, but whether it's dwc2's or the USB
> core's fault I don't know enough to say.

It's the same struct device, but USB devices are special and literally
share the mask of the controller. Hence, when of_dma_configure() later
sets a 30-bit DMA mask for the root hub, the controller's mask is also
corrupted.

> I'd guess that previously, either the DMA device was the correct one, or
> was happening to work due to not having an associated of_node for
> of_dma_configure() to pick up on and reduce the default 32-bit DMA mask
> to the smaller once generated from the "dma-ranges" property.

So it happened to work as dwc2 would overwrite the mask generated by
of_dma_configure() in dwc2_driver_probe().

[    1.030528] dwc2 3f980000.usb: dwc2_driver_probe - dma_mask = 000000007fffffff
[    1.037859] dwc2 3f980000.usb: dwc2_driver_probe - dma_mask = 00000000ffffffff

But since 2bf698671205 ("USB: of: fix root-hub device-tree node
handling") it would be corrupted again when the root hub was later
probed.

Note that of_dma_configure() would be called for non-root-hub devices
(e.g. the RPI3 hub and ethernet controller) also before that commit, but
for some reason that does not corrupt the mask.

> The fact that of_dma_configure() incorrectly generates a 30-bit DMA mask
> from the Rpi3 "dma-ranges" in the first place is an unrelated problem
> (which I'm working on) but has at least helped reveal this bug ;)

Indeed. I just submitted patch which would skip DMA configuration for
USB devices during probe and thereby prevent this and similar future
problems.

Thanks,
Johan