linux-kernel - commit 3497b9a5 (usb: dwc3: add power down scale setting) breaks imx8mp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <5ae757aa-5b0e-be81-e87c-134e2ba5205d@prevas.dk>
Date:   Fri, 6 Jan 2023 12:54:43 +0100
From:   Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Li Jun <jun.li@....com>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: commit 3497b9a5 (usb: dwc3: add power down scale setting) breaks
 imx8mp

We have an imx8mp board with a lan7801 usb ethernet chip hardwired on
the PCB, which is used as the host port for a Microchip KSZ9567 switch.

While trying to update the kernel to 6.1.y, I found something quite
weird: When the switch was being probed for the second time (the first
ends with a standard -EPROBE_DEFER), the board would spontaneously reset.

Now when I disable the switch driver in .config just to see how far I
could otherwise get, the lan7801 device didn't appear until about 47
seconds after boot. Bisecting unambiguously points at 3497b9a5, and
digging in, it's pretty obvious why that is bogus at least for imx8mp.

The .dtsi file lists IMX8MP_CLK_USB_ROOT as the "suspend" clk, and
clk_get_rate() of that returns 500000000 ; divided by 16000 that's
31250, which certainly doesn't fit in the 13-bit field GCTL_PWRDNSCALE.
But I assume the .dtsi file is wrong, because imx8mq.dtsi has
74bd5951dd3 (arm64: dts: imx8mq: correct usb controller clocks), and it
seems likely from the commit log of 3497b9a5 that it was at least tested
on imx8mq.

Now I have no idea if the right clock for imx8mp is also some 32kHz clk,
but it would certainly make sense; unlike what the reference manual
claims, it seems that the reset value of the GCTL register is
0x00112004, amounting to a pwrdwnscale value of 0x00100000>>19 == 2 ==
32kHz/16kHz, and that could explain why things worked just fine without
3497b9a5.

Li Jun, please either revert 3497b9a5 or figure out if imx8mp.dtsi is
broken and needs a fix similar to 74bd5951dd3.

Rasmus