Re: [PATCH v2 1/7] ARM: tegra: finalize USB EHCI and PHY bindings

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

On 04/03/2013 02:41 AM, Venu Byravarasu wrote:
> The existing Tegra USB bindings have a few issues:
...
> This patch fixes the binding definition to resolve these issues.

> diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt

>  Required properties :
...
> +  - vbus-supply: regulator for VBUS

Doesn't the driver only need to control VBUS if the port is in OTG mode?

If there is no VBUS control, and the HW provides VBUS, I think that the
port can only operate in host mode.

If there is no VBUS control, and the HW does not provide VBUS, I think
that the port can only operate in peripheral mode.

If there is VBUS control, then shouldn't the port always operate in OTG
mode, or are there other reasons to control VBUS even in host-only mode?

If VBUS control is only useful for OTG mode, then I think the
vbus-supply property should be documented in a "Required properties for
dr_mode == otg" section.

I assume that VBUS control makes no sense for a peripheral-mode-only
port, so if VBUS control is useful for host-only mode as well as OTG
mode, then I think the vbus-supply property should be documented in a
"Required properties for dr_mode != peripheral" section.

Is the following table correct?

Port operating mode:	host	peripheral	otg
--------------------	----	----------	---
VBUS control required:	no	no		yes
VBUS control useful:	yes[1]?	no		yes

[1] perhaps for power-saving/suspend???