From: Paul Fertser Subject: Re: rkclock(4), rkusbphy(4): fix USB-related bitmasks for RK3399 To: Mark Kettenis Cc: David Gwynne , tech@openbsd.org, kettenis@openbsd.org Date: Mon, 25 Nov 2024 01:59:45 +0300 On Sun, Nov 24, 2024 at 11:48:45PM +0100, Mark Kettenis wrote: > > From: David Gwynne > > Date: Thu, 21 Nov 2024 21:19:09 +1000 > > > > > On 19 Nov 2024, at 08:45, Paul Fertser wrote: > > > > > > On Mon, Nov 18, 2024 at 02:56:42AM +0300, Paul Fertser wrote: > > >> However with changes to rkusbphy(4) added back it manages to attach > > >> and continues to boot so they must be doing something important but > > >> not quite right, full speed device attached to xHCI hubs > > >> (TYPEC{0,1}_D* signals) works, for EHCI and OHCI (HOST{0,1}_D*) > > >> there's zero reaction. This can be fixed later. > > > > > > Later happened to be today, and with the attached diff I confirm all > > > ports work in all modes both after booting from a modern U-Boot with > > > "usb start" and after booting from the stock OpenBSD U-Boot which > > > doesn't touch USB at all. > > > > this looks right to me. > > I dropped the comment about OpenBSD only supporting host mode. That > is true, but the sentence seemed garbled and we are (mostly) using the > same values as the Linux driver I'm looking at. Although there is a > funny difference between the two PHYs for the RK3568 that I need to > look into... For the reference, the values I observed booting with U-boot that doesn't touch USB matched exactly what the SoC datasheet specified as reset values, and if "usb start" was performed the lowest two bits were changed from 2 to 1. I didn't really dig the ULPI + controller docs to fully understand what the datasheet was trying to tell me but the testing results were pretty convincing in that 1 there disables the USB2.0 functionality on the corresponding port while 2 enables. Comment I didn't really fully understood so just copied from your earlier patch :) Thank you for merging!