From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751395AbdFBWAO (ORCPT ); Fri, 2 Jun 2017 18:00:14 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:46440 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751176AbdFBWAM (ORCPT ); Fri, 2 Jun 2017 18:00:12 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 1F4EA60764 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=sboyd@codeaurora.org Date: Fri, 2 Jun 2017 15:00:10 -0700 From: Stephen Boyd To: Fabien Lahoudere Cc: Peter Chen , Peter Senna Tschudin , Felipe Balbi , Greg Kroah-Hartman , "open list:USB PHY LAYER" , open list Subject: Re: [RFC] usb-phy-generic: Add support to SMSC USB3315 Message-ID: <20170602220010.GQ20170@codeaurora.org> References: <20170419061413.20961-1-peter.senna@collabora.com> <20170420085046.GA11378@b29397-desktop> <1495563396.12055.93.camel@collabora.co.uk> <20170523210022.GN20170@codeaurora.org> <1495708587.12055.97.camel@collabora.co.uk> <1495789230.12055.104.camel@collabora.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1495789230.12055.104.camel@collabora.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/26, Fabien Lahoudere wrote: > Hello > > I modify ci_hrdc_imx_probe to bypass "data->phy = devm_usb_get_phy_by_phandle(&pdev->dev, > "fsl,usbphy", 0);". Everything works as expected and call ci_ulpi_init. > > The problem is that in ci_ulpi_init, before calling "ci->ulpi = ulpi_register_interface(ci->dev, > &ci->ulpi_ops);" (to initialize our phy), "hw_phymode_configure(ci);" is called which is the > original function that make our system to hang. > > Our phy is not initialised before calling ulpi_register_interface so I don't understand how the phy > can reply if it is not out of reset state. I haven't see any problem in hw_phymode_configure(). What's the value of ci->platdata->phy_mode? USBPHY_INTERFACE_MODE_ULPI? If you phy needs to be taken out of reset to reply to the ulpi reads of the vendor/product ids, then it sounds like you have a similar situation to what I had. I needed to turn on some regulators to get those reads to work, otherwise they would fail, but knowing what needed to be turned on basically meant I needed to probe the ulpi driver so probing the ids wasn't going to be useful. So on my device the reads for the ids go through, but they get all zeroes back, which is actually ok because there aren't any bits set on my devices anyway. After the reads see 0, we fallback to DT matching, which avoids the "bring it out of reset/power it on" sorts of problems entirely. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project