linux-kernel - Re: [PATCH] USB: otg: twl4030: fix phy initialization

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:	Sat, 04 Sep 2010 16:24:39 -0500
From:	Felipe Balbi <me@...ipebalbi.com>
To:	Ming Lei <tom.leiming@...il.com>
Cc:	<greg@...ah.com>, <linux-usb@...r.kernel.org>,
	<linux-omap@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	Anand Gadiyar <gadiyar@...com>,
	Mike Frysinger <vapier@...too.org>,
	Sergei Shtylyov <sshtylyov@...mvista.com>
Subject: Re: [PATCH] USB: otg: twl4030: fix phy initialization

Hi,

On Sat, 4 Sep 2010 23:36:39 +0800, Ming Lei <tom.leiming@...il.com> wrote:
> Considered bit PHYPWD of PHY_PWR_CTRL is zero at default,
> say, OTG phy is not put into power down after system poweron,
> so 2.6.36-rc3 will make musb device mode broken if bootloader
> doesn't touch  PHYPWD of PHY_PWR_CTRL.
> 
> Could you ack the patch if no further objections or give other
> suggestions?

I don't see why that patch should cause problems with device
mode. Fact is that transceiver is only "asleep" when PHYPWD
bit is true and without setting that flag correctly we were
leaving phy's LDOs powered on for nothing when we were
booting without a USB cable connected.

If you don't explain exactly what is the problem you see
(besides the WARN) it's to help any further, specially now
that I'm 100% without HW to test against. I'm also in a
big hurry packing a buch of stuff for moving to another
appartment, so if there isn't enough information, I can't
be of any help.

Still, I would NACK you patch because I don't think it's
approaching the correct problem. If you only see that WARN,
you could start by chaging the code so that:

if (!regulator_is_enabled(twl->usb3v1)
    regulator_enable(twl->usb3v1);

and similarly for the regulator_disable() call, then check
whether there are any other problems. If there are, we will
take it from there.

All in all, I doubt that patch would cause break anything
since it's just checking the initial state from the
transceiver itself to set a flag in the driver structure,
that's all.

-- 
balbi
--
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/