linux-kernel - Re: Nokia N900: musb is in wrong state after boot

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]

Message-ID: <20160121174146.GK19432@atomide.com>
Date:	Thu, 21 Jan 2016 09:41:46 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	joerg Reisenweber <joerg@...nmoko.org>
Cc:	Pali Rohár <pali.rohar@...il.com>,
	Felipe Balbi <balbi@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-omap@...r.kernel.org,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	Sebastian Reichel <sre@...nel.org>,
	Aaro Koskinen <aaro.koskinen@....fi>,
	Pavel Machek <pavel@....cz>, Nishanth Menon <nm@...com>
Subject: Re: Nokia N900: musb is in wrong state after boot

* joerg Reisenweber <joerg@...nmoko.org> [160121 02:30]:
> On Thu 21 January 2016 09:40:07 Pali Rohár wrote:
> > On Tuesday 19 January 2016 12:33:15 Tony Lindgren wrote:
> > > Hi,
> > > 
> > > * Pali Rohár <pali.rohar@...il.com> [160109 07:16]:
> > > > Hello,
> > > > 
> > > > when I boot 4.4.0-rc7+ kernel compiled with g_nokia into zImage on Nokia
> > > > N900 into userspace then usb gadget (g_nokia) does not work. Notebook,
> > > > connected on other side does not see any usb device... Connecting and
> > > > disconnecting cable does not change anything, still not work.
> > > > 
> > > > But if I run this command
> > > > $ echo peripheral > /sys/bus/platform/devices/musb-hdrc.0.auto/mode
> > > > 
> > > > 
> > > > then gadget starts working. Other side see usb device and can use it.
> > > > Also connecting and disconnecting usb cable working fine. After
> > > > connecting it again, usb device OK.
> > > 
> > > N900 had the PHY interrupt wired to the bq chip instead of twl4030, right?
> 
> which interrupt? I'll try to answer based on assumptions: 1707 PHY connects to 
> bq24150 charger via CHRG_DET signal.
> I guess you're talking about the VBUS detection which is done in twl4030 VBUS-
> pin R8.

Right, I'm confusing things a bit here. If the VBUS detection is done in
twl4030, then it should notify the USB subsystem. But on n900 the USB
phy is not ti,twl4030-usb, it's the 1707 instead.

So my guess is that in drivers/phy/phy-twl4030-usb.c the interrupt never
gets enabled as the PHY driver never gets probed?

Then for supporting the USB host mode.. We should add regulator support
to the USB PHY driver so if the ID pin is grounded, the PHY driver enables
the VBUS regulator. That too seems to need some coordination between the
drivers/phy/phy-twl4030-usb.c and 1707 driver if the ID pin interrupt is
only detected in drivers/phy/phy-twl4030-usb.c.

> N900 PHY (1707) is connected to musb core via ULPI 
> (https://www.mentor.com/products/ip/usb/usb20otg/phy_interfaces), it has no 
> I2C interface and no other IRQ than what's implemented in (normally powered-
> down?) ULPI already.
> I guess the problem in this case is along the USB VBUS and ID pin A/B OTG 
> detection: the USB jack's ID pin is _not_ connected to the PHY in N900 but 
> rather is connected to TWL4030 aka GAIA ID pin R11 which afaik is part of the 
> otherwise unused (except VBUS detection?) PHY in TWL4030. 
> It seems to me the actually used PHY 1707 does not support ID, neither does it 
> support a dedicated IRQ line for VBUS.

Yes so it seems.

> Generally musb-core and buses should be suspended/off by default, for energy 
> conservation reasons (seemingly ~40mA on Vbatt!), and only get enabled when 
> twl4030 detects +5V on VBUS (also before my hostmode botch tries to talk to 
> the musb core debug registers which needs to happen before VBUS gets applied)

I also think there's also some related twl4030 errata where it's
recommended the USB PHY is in suspend mode instead of disabled.

Regards,

Tony