Contrary to the datasheet, setting both DETACH and PULLD_DIS bits to 1
does not always drive the DP and DM lines to high-impedance. This
prevents the host from reliably detecting a USB disconnect and subsequent
reconnect.
The symptom is that the first gadget command (e.g., dhcp) succeeds, while
subsequent commands (e.g., nfs) fail.
Disabling and re-enabling the controller entirely, instead of toggling the
PULLD_DIS bit, reliably generates a disconnect event.
The Linux driver works correctly because gadget_disconnect/gadget_connect
are always followed by gadget_udc_start/gadget_udc_stop. In U-Boot
pullup() is used solely.
This behavior has been observed on the SAM9X60-Curiosity and
AT91SAM9G25-EK boards and has been reported to Microchip.
Signed-off-by: Zixun LI <admin@hifiphile.com>
Link: https://lore.kernel.org/r/20250602-pullup-v1-1-edcde5a050dd@hifiphile.com
[mkorpershoek: reworded commit title + comment to usba_udc_pullup()]
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
static int usba_udc_pullup(struct usb_gadget *gadget, int is_on)
{
struct usba_udc *udc = to_usba_udc(gadget);
- u32 ctrl;
-
- ctrl = usba_readl(udc, CTRL);
+ /*
+ * Some chips don't reliably drive DP/DM lines to high impedance when
+ * using the DETACH/PULLD_DIS bits.
+ * To ensure a reliable disconnect, power cycle the controller instead
+ */
if (is_on)
- ctrl &= ~USBA_DETACH;
+ usba_writel(udc, CTRL, USBA_ENABLE_MASK);
else
- ctrl |= USBA_DETACH;
-
- usba_writel(udc, CTRL, ctrl);
+ usba_writel(udc, CTRL, USBA_DISABLE_MASK);
return 0;
}