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: <063D6719AE5E284EB5DD2968C1650D6D1CB5B140@AcuExch.aculab.com>
Date:	Thu, 2 Jul 2015 09:39:28 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Peter Chen' <peter.chen@...escale.com>,
	Mike Looijmans <mike.looijmans@...ic.nl>
CC:	"lars@...afoo.de" <lars@...afoo.de>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/2] usb: chipidea: Reduce ULPI PHY reset pulse to
 datasheet spec of 1us

From: Peter Chen
> Sent: 30 June 2015 03:06
> On Fri, Jun 26, 2015 at 03:47:03PM +0200, Mike Looijmans wrote:
> > The datasheet for the 334x PHY mentions that a reset can be performed:
> > "... by bringing the pin low for a minimum of 1 microsecond and
> > then high."
> > A delay of 5ms to implement that seems overly long, so reduce it to
> > just 1us.
> > As for the delay after reset, the datasheet only mentioned that the
> > chip will assert the DIR output. 1ms seems like a safe time to wait
> > for that to happen, so no change there.
> >
> > Signed-off-by: Mike Looijmans <mike.looijmans@...ic.nl>
> > ---
> >  drivers/usb/chipidea/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index e970863..c865abe 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -664,7 +664,7 @@ static int ci_hdrc_create_ulpi_phy(struct device *dev, struct ci_hdrc *ci)
> >  			dev_err(dev, "Failed to request ULPI reset gpio: %d\n", ret);
> >  			return ret;
> >  		}
> > -		msleep(5);
> > +		udelay(1);

If the spec says 1us I'd delay for longer just to make sure.
And add a comment saying that the reset needs to be 1us long.

	David

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ