Clarification of overcurrent config via device tree ("atmel,oc-gpio)

[havasi]

Hi there,

I am debugging an USB device disconnect issue, where our current "top candidate" for the root cause is an over-current on the USB.

I have seen in `Documentation/devicetree/bindings/usb/atmel-usb.txt`:

Code: Select all

 - atmel,vbus-gpio: If present, specifies a gpio that needs to be
   activated for the bus to be powered.
 - atmel,oc-gpio: If present, specifies a gpio that needs to be
   activated for the overcurrent detection.

These descriptions were not clear for me, so in the code I could find "atmel,vbus-gpio" from `drivers/usb/gadget/udc/at91_udc.c`

Code: Select all

board->vbus_pin = of_get_named_gpio_flags(np, "atmel,vbus-gpio", 0,  &flags);
if (gpio_is_valid(udc->board.vbus_pin)) {
		retval = devm_gpio_request(dev, udc->board.vbus_pin,
					   "udc_vbus");
		if (retval) {
			DBG("request vbus pin failed\n");
			goto err_unprepare_iclk;
		}

		gpio_direction_input(udc->board.vbus_pin);

So I understood it that the specified vbus-gpio is a kind of input to enable/disable the USB bus.

But if I grep for the "atmel,oc-gpio" string in the kernel (5.4) tree, it is only present in DTS and Documentation.

So do I need to defined a gpio via "atmel,oc-gpio" and assert it so that the kernel driver detects over-current? Or is this for some totally different reasons?

Many thanks for any pointers!

P.S. I have seen in the code also that the undocumented "atmel,vbus-polled" and "atmel,pullup-gpio" Any info on those

[blue_z]

I am debugging an USB device disconnect issue ...

To be clear, do you mean a USB gadget that is/was connected to the USB host port of the target board (that uses a MIcrochip SoC)?
Or is the target board (that uses a MIcrochip SoC) connected as a USB gadget?

I have seen in `Documentation/devicetree/bindings/usb/atmel-usb.txt`:
...
These descriptions were not clear for me ...

Probably because you seem to ignore the context of what you quoted.
You seem to overlook the salient fact that bindings for four (4) different modes or drivers are documented in that file, and what you quoted applies to only one of those four modes.

So do I need to defined a gpio via "atmel,oc-gpio" and assert it so that the kernel driver detects over-current? Or is this for some totally different reasons?

You neglect to provide salient details such as which SoC and kernel version you are using (as well as which end of the USB).

As stated in the bindings document, the property you mention is required (only) by the OHCI host peripheral.
Older Atmel SoCs such as AT91SAM926x have only host & gadget OHCI controllers (and no high-speed capability).
More recent Atmel/Microchip SoCs have the OHCI functionality integrated into the EHCI peripherals.

The EHCI host peripheral (of most recent Atmel/Microchip SoCs) may have built-in overcurrent detection on the USB power supply.
The OHCI host peripheral (of older Atmel SoCs) requires external overcurrent-detection circuitry on the USB power supply, and its driver can utilize a GPIO input to receive that status for each port.

I have seen in the code also that the undocumented "atmel,vbus-polled" and "atmel,pullup-gpio"

You seem to conflate host mode and gadget mode and the respective controllers/drivers.
Instead you need to distinguish between the two modes, and reference the appropriate driver of the controller.


Regards