linux-kernel - Re: [PATCH] usb: phy: samsung-usb2: Toggle HSIC GPIO from device tree

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: <CAODwPW-=bo2BqcHopY32N76p6DDGNDmCrKFo1R4gEEZhsG-DYg@mail.gmail.com>
Date:	Thu, 11 Jul 2013 14:46:14 -0700
From:	Julius Werner <jwerner@...omium.org>
To:	Jingoo Han <jg1.han@...sung.com>
Cc:	Julius Werner <jwerner@...omium.org>,
	LKML <linux-kernel@...r.kernel.org>, Felipe Balbi <balbi@...com>,
	linux-usb@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org,
	linux-samsung-soc@...r.kernel.org,
	Vivek Gautam <gautam.vivek@...sung.com>,
	Praveen Paneri <p.paneri@...sung.com>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Tushar Behera <tushar.behera@...aro.org>,
	Doug Anderson <dianders@...omium.org>,
	Olof Johansson <olofj@...omium.org>,
	Vincent Palatin <vpalatin@...omium.org>,
	Thomas Abraham <thomas.abraham@...aro.org>
Subject: Re: [PATCH] usb: phy: samsung-usb2: Toggle HSIC GPIO from device tree

Hi Jingoo,

Yeah, I followed that discussion back then, but it seems to have
stalled a little (at least the HSIC patches haven't been picked up in
any kernel.org repo yet to my knowledge).

The problem is that I think these approaches cannot work reliably. I
agree that it would be nice to control the HSIC device from its own
driver, and have spent quite some time playing around with the
usb/misc/usb3503.c driver to try to make this work... but there's a
timing dependency here that you just can't model correctly with
independent drivers.

If the HSIC device is already active during boot (e.g. because it was
used by firmware), there's always a chance that the USB stack will
come up before the driver that resets it does. The device will be
enumerated as normal, and when the other driver later pulls the reset
signal the USB stack will not notice because there is no real
disconnect detection on HSIC. Only when you eventually try to send
another transfer to the device will you start to get timeouts, and the
newly reset device will not be able to reenumerate because the host
never asks it to.

I really don't see how you could solve this without putting some kind
of synchronization mechanism in the USB drivers. So this leaves
ehci-s5p and phy-samsung-usb2 as the only possible places, and I chose
the latter since all the host-side HSIC initialization is also there
already. I think if you think of it as "reset whatever is on the other
side of this PHY", it's okay to put it as an optional feature into the
PHY driver.
--
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/