linux-kernel - Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader 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]

Message-id: <5729E4B5.2090702@samsung.com>
Date:	Wed, 04 May 2016 14:01:57 +0200
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	Rob Herring <robh@...nel.org>, Mark Brown <broonie@...nel.org>
Cc:	Kukjin Kim <kgene@...nel.org>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org, linux-usb@...r.kernel.org,
	linux.amoon@...il.com, tjakobi@...h.uni-bielefeld.de,
	m.szyprowski@...sung.com, hverkuil@...all.nl,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	ulf.hansson@...aro.org
Subject: Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader
 initialization

On 05/03/2016 08:00 PM, Rob Herring wrote:
> On Mon, May 02, 2016 at 11:55:01AM +0100, Mark Brown wrote:
>> On Mon, May 02, 2016 at 11:49:12AM +0200, Krzysztof Kozlowski wrote:
>>
>>> This VDD regulator supply actually is not a usb3503 USB HUB regulator
>>> supply... but a supply to the LAN attached to this HUB. Regulator off/on
>>> is needed for LAN to show up. The hub will show up with typical reset
>>> (which is also missing before my patchset btw).
>>
>>> The LAN, as a USB device, is auto-probed so it cannot take the regulator
>>> and play with it. The simplest idea I have is to add it as "external
>>> supply"  to the parent: usb3503.
>>
>> This is common enough that that just isn't going to scale well I fear
>> without some generic handling, either walking child devices at the bus
>> level or at the device level with a pre-probe() callback to get the
>> device to power on.  The latter is more appropriate to things like
>> Slimbus where the device is more likely to do active management at
>> runtime, it's not clear people are building USB devices like that.
> 
> There's a new binding and support in -next (.../usb/usb-device.txt) for 
> USB devices that should help here. Though, how to handle a hub on USB 
> and I2C buses would need to be worked out.

This binding might help, especially with other idea we have - usage of
pwrseq for the USB hub.

The USB hub, without toggling the regulator off/on, appears as USB
device only sometimes. Apparently there is some timing or other
behavior. not yet known to me.

When playing with regulator, the USB hub and child USB device (LAN) will
appear correctly.

This looks like pwrseq for MMC devices so the idea is to:
1. Move drivers/mmc/core/pwrseq* to separate directory
(drivers/power/pwrseq ?)
2. Add support for pwrseq to USB core,
3. Add new pwrseq driver (or extend existing one): toggling the regulator.
4. Add pwrseq phandle to the DT node of USB hub (to the binding
mentioned by Rob?).


Does it look sensible?

Best regards,
Krzysztof