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]
Message-ID: <20111109063638.GF23337@legolas.emea.dhcp.ti.com>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ