On 3/1/26 6:25 AM, Siddharth Vadapalli wrote:
There are two users of cdns3_bind() which have registered their
own .bind() callback as cdns3_bind():
1. cdns3-starfive.c driver
2. cdns3-ti.c driver
Since .bind() is called before .probe()
.bind callback is meant to BIND the driver instance (to a DT node), it
is not meant to initialize the hardware. .probe callback is meant to
I agree. But that's exactly where the issue lies. When 'dr_mode' is set
to OTG, cdns3_bind() is unable to determine if the driver to bind to the
DT node is "cdns-usb3-host" or "cdns-usb3-peripheral".
Since [0], we attempt to identify if OTG should imply 'peripheral' or
'host'. But to do that, [0] needs to read the VBUS Valid field of the
OTG Status register. And register access requires the USB Controller to
be powered ON.
Correct, so bind is the wrong place to do any HW access .
[0]: bfb530e06ca6 ("usb: cdns3: use VBUS Valid to determine role for
dr_mode OTG")
initialize the hardware. This is fundamental part of the U-Boot DM
lazy initialization scheme. If something does initialize hardware
in .bind, then it is very likely wrong.
, and, since cdns3_bind() is also the .bind() callback of the above
drivers, device_probe() has to be added here itself. Moreover, it is
only due to the register accesses being performed by the recently
introduced cdns3_get_otg_mode() function that we need the USB
Controller to be powered ON at this stage.
So, can we fix this so the HW initialization won't be happening in
bind, but instead in .probe ?
That isn't possible
Can you investigate how to make that possible ? Maybe by having some
common .probe implementation that would determine the OTG state, or by
having some stub driver which handles the OTG selection ?
