linux-kernel - RE: [PATCH v2 1/7] ARM: tegra: finalize USB EHCI and PHY bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 4 Apr 2013 17:51:09 +0530
From:	Venu Byravarasu <vbyravarasu@...dia.com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"balbi@...com" <balbi@...com>,
	"stern@...land.harvard.edu" <stern@...land.harvard.edu>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 1/7] ARM: tegra: finalize USB EHCI and PHY bindings

> -----Original Message-----
> From: linux-tegra-owner@...r.kernel.org [mailto:linux-tegra-
> owner@...r.kernel.org] On Behalf Of Stephen Warren
> Sent: Thursday, April 04, 2013 12:38 AM
> To: Venu Byravarasu
> Cc: gregkh@...uxfoundation.org; balbi@...com;
> stern@...land.harvard.edu; linux-tegra@...r.kernel.org; linux-
> usb@...r.kernel.org; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v2 1/7] ARM: tegra: finalize USB EHCI and PHY bindings
> 
> 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.

Agree, will do it in next patch update.

> 
> 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???
 
For waking system up from sleep via devices connected to USB, I think Vbus is always
kept ON in host mode. 

> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/