From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758200AbcEEWmv (ORCPT ); Thu, 5 May 2016 18:42:51 -0400 Received: from mail.kernel.org ([198.145.29.136]:37393 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755589AbcEEWmr (ORCPT ); Thu, 5 May 2016 18:42:47 -0400 Date: Thu, 5 May 2016 17:42:40 -0500 From: Rob Herring To: Krzysztof Kozlowski Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-mmc@vger.kernel.org, linux-pm@vger.kernel.org, linux-usb@vger.kernel.org, Ulf Hansson , Sebastian Reichel , Dmitry Eremin-Solenikov , David Woodhouse , Greg Kroah-Hartman , Mark Brown , hverkuil@xs4all.nl, tjakobi@math.uni-bielefeld.de, Bartlomiej Zolnierkiewicz , m.szyprowski@samsung.com Subject: Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting Message-ID: <20160505224240.GA31429@rob-hp-laptop> References: <1462451666-17945-1-git-send-email-k.kozlowski@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1462451666-17945-1-git-send-email-k.kozlowski@samsung.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: > Hi, > > This is a different, second try to fix usb3503+lan on Odroid U3 board > if it was initialized by bootloader (e.g. for TFTP boot). > > First version: > http://www.spinics.net/lists/linux-usb/msg140042.html > > > Problem > ======= > When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP), > the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset > is required, e.g. by suspend to RAM. The actual TFTP boot does > not have to happen. Just "usb start" from U-Boot is sufficient. > > From the schematics, the regulator is a supply only to LAN, however > without toggling it off/on, the usb3503 hub won appear neither. > > > Solution > ======== > This is very similar to the MMC pwrseq behavior so the idea is to: > 1. Move MMC pwrseq drivers to generic place, You can do that, but I'm going to NAK any use of pwrseq bindings outside of MMC. I think it is the wrong way to do things. The DT should describe the devices. If they happen to be "simple" then the core can walk the tree and do any setup. For example, look for "reset-gpios" and toggle that GPIO. There is no need for a special node. > 2. Extend the pwrseq-simple with regulator toggling, > 3. Add support to USB hub and port core for pwrseq, We discussed this for USB already[1] and is why we defined how to add USB child devices. The idea is not to add pwrseq to that. Rob [1] http://www.spinics.net/lists/linux-usb/msg134082.html