From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753473AbcEBJtZ (ORCPT ); Mon, 2 May 2016 05:49:25 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:15490 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752940AbcEBJtS (ORCPT ); Mon, 2 May 2016 05:49:18 -0400 X-AuditID: cbfec7f4-f796c6d000001486-49-5727229a616d Subject: Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization To: Mark Brown References: <1461927591-7864-1-git-send-email-k.kozlowski@samsung.com> <1461927591-7864-2-git-send-email-k.kozlowski@samsung.com> <20160429113059.GX3217@sirena.org.uk> <57234BA2.6020304@samsung.com> <20160429164448.GY3217@sirena.org.uk> Cc: Kukjin Kim , Chanwoo Choi , Liam Girdwood , Greg Kroah-Hartman , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-usb@vger.kernel.org, linux.amoon@gmail.com, tjakobi@math.uni-bielefeld.de, m.szyprowski@samsung.com, hverkuil@xs4all.nl, Bartlomiej Zolnierkiewicz From: Krzysztof Kozlowski X-Enigmail-Draft-Status: N1110 Message-id: <57272298.50701@samsung.com> Date: Mon, 02 May 2016 11:49:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-version: 1.0 In-reply-to: <20160429164448.GY3217@sirena.org.uk> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsVy+t/xq7qzlNTDDbq3SVtsnLGe1WLqwyds Fte/PGe1mH/kHKtF8+L1bBanJj9jsnj9wtCi//FrZotvVzqYLDY9vsZqcXnXHDaLGef3MVks WtbKbLFu4y12i7VH7rJbtK3+wOog4LFz1l12j02rOtk89s9dw+6xeUm9x79j7B59W1Yxenze JOdx6utn9gCOKC6blNSczLLUIn27BK6Mhz8jCrYKVpxbVdnA+Ia3i5GTQ0LAROJI8wc2CFtM 4sK99UA2F4eQwFJGib3TP7GAJIQEnjFK/Gn2AbGFBeIlZnQuZwSxRQSUJa5+38sC0fCJUeL/ q19g3cwCj5kljs2fzwRSxSZgLLF5+RKoFXISvd2TwKbyCmhI7Dt8CCzOIqAq8eRLIzuILSoQ IbF63TVmiBpBiR+T74HVcwoYScxvnAcU5wBaoCdx/6IWSJhZQF5i85q3zBMYBWch6ZiFUDUL SdUCRuZVjKKppckFxUnpuYZ6xYm5xaV56XrJ+bmbGCGx9mUH4+JjVocYBTgYlXh4PdLVwoVY E8uKK3MPMUpwMCuJ8G6TUw8X4k1JrKxKLcqPLyrNSS0+xCjNwaIkzjt31/sQIYH0xJLU7NTU gtQimCwTB6dUA2Ov3FnmfTcjZ9+QCc9yOHRkD9cnjduHdDbe+zzZLnPzjSUPnKZ/aZ9y4OOm HIV3KeEyjF4vJXenbq3Y+kKJdc1fGba4/r7PAXMuzPumVvEpwELg+oHVTfeKljK6NLHc5tBY mGJzJdpBovPOTN1/NzhiuyZ6sadfD9AQ3brp6rVbHJoTP2ik71NQYinOSDTUYi4qTgQABy7p ubECAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/29/2016 06:44 PM, Mark Brown wrote: > On Fri, Apr 29, 2016 at 01:55:14PM +0200, Krzysztof Kozlowski wrote: >> On 04/29/2016 01:30 PM, Mark Brown wrote: > >>> Supplies are only optional if they may be physically absent. In this >>> case it's possible that on device regulators may be used instead, a >>> pattern more like that used for arizona-ldo1 where we represent those >>> regulators might be better as it's more clearly describing the >>> situation. I'm just wondering if the supply lookup stuff there should >>> be factored out as this is not an uncommon pattern.. > >>> It should at least be clearly stated what's going on, ignoring failure >>> to get supplies is generally a bug and people will tend to blindly cut >>> and paste things (witness all the breakage in graphics drivers with >>> this). > >> The VDD33 is really optional. The device can work in different >> configuration, e.g. only on VBAT. How the reset logic would work then? I >> don't know... I would suspect that it could be exactly the same (just >> replace VDD33 with VBAT) but I am not sure. > > What the Arizona example I mentioned does is look for the property > specifying an external supply in DT and if there isn't one assumes that > it must be using the internal regulator. That's a bit icky but it does > the right thing and is much simpler from a user point of view. Okay, that indeed looks similar... in case of lack of external supplies the usb3503 pins should be tied to the internal regulators. However it seems I was wrong at the beginning. We've been looking here at the schematics and the datasheet. The design is unfortunately a little bit confusing but finally I think we got the impression how does it work. 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. Best regards, Krzysztof