Re: commit 3497b9a5 (usb: dwc3: add power down scale setting) breaks imx8mp

[Linux kernel regression tracking (#adding)]

[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]

[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; all text you find below is based on a few templates
paragraphs you might have encountered already already in similar form.
See link in footer if these mails annoy you.]

On 06.01.23 12:54, Rasmus Villemoes wrote:
> 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.

Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:

#regzbot ^introduced 3497b9a5c8c
#regzbot title usb: dwc3: imx8mp broken
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.

Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (see page linked in footer for details).

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.