[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160502105501.GE6292@sirena.org.uk>
Date: Mon, 2 May 2016 11:55:01 +0100
From: Mark Brown <broonie@...nel.org>
To: Krzysztof Kozlowski <k.kozlowski@...sung.com>
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>
Subject: Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after
bootloader initialization
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.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists