linux-kernel - Re: [PATCHv6 01/19] usb: otg: Rename otg_transceiver to usb

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 9 Nov 2011 08:36:39 +0200
From:	Felipe Balbi <balbi@...com>
To:	Peter Chen <hzpeterchen@...il.com>
Cc:	balbi@...com, Peter Chen <peter.chen@...escale.com>,
	"ABRAHAM, KISHON VIJAY" <kishon@...com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Greg KH <gregkh@...e.de>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, Sascha Hauer <s.hauer@...gutronix.de>
Subject: Re: [PATCHv6 01/19] usb: otg: Rename otg_transceiver to usb_phy

On Wed, Nov 09, 2011 at 02:15:43PM +0800, Peter Chen wrote:
> > > > > Includes fixes to IMX code from Sascha Hauer.
> > > >
> > > > I tend to defer with your opinion of renaming otg_transceiver to
> > > > usb_phy. According to me otg_transceiver should program hardware
> > > > mechanisms associated to VBUS, ID lines, etc.. and phy is responsible
> > > > for transmitting data over differential data lines (with its own
> > > > programming of phy_init, phy_shutdown, setting phy clocks etc..). So
> > > > in my opinion otg_transceiver and usb_phy should be two different and
> > > > separate entities.
> > > >
> > > I am a little puzzled, are there two separate analog usb parts at OMap
> > > 's usb part? What the transceiver do? And what the phy do?
> >
> > Kinda... there's one which is mostly digital inside the SoC handling
> > data lines and also comunicating VBUS/ID levels to the link but the
> > actual VBUS/ID comparators are outside of the SoC, inside the PMIC.
> >
> > It's a bit of a pain, but I understand why they did it that way. It's
> > mostly for power management, although the same is likely to be
> > achievable by keeping everything in the PMIC.
> >
> So, in that way, the users must choose specific PMICs which have USB
> interface if
> they want to use OMAP

OMAP only works with its own matching PMIC. It's not like you can go to
a shelf an buy a PMIC for OMAP. OMAP's too complex for that. That's why
TI also provides the PMIC for every OMAP Silicon.

What can be done, though, and has happened before, is that some
companies will completely ditch the internal transceiver and the pieces
inside the PMIC and use another ULPI-based transceiver.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)