On 17/10/2023 14:18, Krishna Kurapati wrote:
The following are the requirements aimed in this implementation:
1. When enum in device mode, Glue/core must stay active.
2. When cable is connected but UDC is not written yet, then glue/core
must be suspended.
3. Upon removing cable in device mode, the disconnect event must be
generated and unblock runtime suspend for dwc3 core.
Signed-off-by: Krishna Kurapati <quic_kriskura@xxxxxxxxxxx>
What happens to this code if youThe vendor hooks are used in __dwc3_set_mode and role_switch_set calls in core and drd files respectively. These are invoked only if we are OTG capable. The drd_work is initialized in core_init_mode which is called at the end of dwc3_probe. If dwc3_probe fails and gets deferred before that, none of the vendor hooks will be fired and dwc3_qcom_probe is also deferred.
static int count;
1. sleep in dwc3_probe for 10 milliseconds
2. return -EPROBE_DEFER
3. if count++ < 5 goto 1
i.e. if we simulate say waiting on a PHY driver to probe in dwc3_probe()
and what happens if we introduce a 100 millsecond sleep into dwc3_qcom_probe() - and run a fake disconnect event from dwc3_qcom_probe_core() directly ?Just wanted to understand the situation clearly. Is this the sequence you are referring to ?
In other words if make it that dwc3_probe() completes and struct dwc3_glue_ops->notify_cable_disconnect() fires prior to dwc3_qcom_probe_core() completing ?
i.e. I don't immediately see how you've solved the probe() completion race condition here.