Messages in this thread | | | Date | Fri, 3 Nov 2023 15:14:49 +0000 | Subject | Re: [RFC 2/8] usb: dwc3: core: Register vendor hooks for dwc3-qcom | From | Bryan O'Donoghue <> |
| |
On 17/10/2023 14:18, Krishna Kurapati wrote: > Currently on QC targets, the conndone/disconnect events in device mode are > generated by controller when software writes to QSCRATCH registers in qcom > glue layer rather than the vbus line being routed to dwc3 core IP for it > to recognize and generate these events. > > We need to write '1' to UTMI_OTG_VBUS_VALID bit of QSCRATCH_HS_PHY_CTRL > register to generate a connection done event and "0" if we need to > generate a disconnect event during cable removal or mode switch. Exactly > what is done by "dwc3_qcom_vbus_override_enable" call in dwc3-qcom. > > When the disconnect is not generated upon cable removal, the connected > flag of dwc3 is left marked as "true" and it blocks runtime suspend. > > The goal of these vendor hooks is to let the mode change and cable removal > notifications from core reach the glue layers so that glue can take > necessary action. > > Before flattening the device tree, glue driver is not sure when the core > probe was completed as core probe can be deferred. In this case, glue is > not sure when to register vendor hooks. So mandate enabling runtime only > for flattened device node platforms so that glue can know when to register > vendor hooks. > > 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@quicinc.com>
What happens to this code if you
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 ?
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.
--- bod
| |