Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752300AbbGMPCn (ORCPT ); Mon, 13 Jul 2015 11:02:43 -0400 Received: from relmlor2.renesas.com ([210.160.252.172]:31053 "EHLO relmlie1.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750856AbbGMPCi convert rfc822-to-8bit (ORCPT ); Mon, 13 Jul 2015 11:02:38 -0400 X-IronPort-AV: E=Sophos;i="5.15,462,1432566000"; d="scan'208";a="190236895" From: Phil Edworthy To: Sergei Shtylyov , "Kishon Vijay Abraham I" CC: Rob Herring , Pawel Moll , "Mark Rutland" , Ian Campbell , Kumar Gala , Yoshihiro Shimoda , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" , "linux-sh@vger.kernel.org" Subject: RE: [PATCH v3] phy: rcar-gen2 usb: Add Host/Function switching for USB0 Thread-Topic: [PATCH v3] phy: rcar-gen2 usb: Add Host/Function switching for USB0 Thread-Index: AQHQuKwjcYvjF2RvDkeFG+0NoRt2Cp3U67UAgAQ2M3CAABbzAIAASK4A Date: Mon, 13 Jul 2015 15:02:26 +0000 Message-ID: References: <1436270121-25924-1-git-send-email-phil.edworthy@renesas.com> <559FF47A.5000001@cogentembedded.com> <55A39030.1030601@cogentembedded.com> In-Reply-To: <55A39030.1030601@cogentembedded.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cogentembedded.com; dkim=none (message not signed) header.d=none; x-originating-ip: [193.141.220.21] x-microsoft-exchange-diagnostics: 1;SIXPR06MB0923;5:25NfHPQ83YgAEsU9VuZrBPjkeeEoeq7U8htV3hEULGnde+uKA+9vS4WOP5Mfil8/Y7smS8qdw+6+J3cEoynH9MvzeYzdTwlcQsNsnf3Bl/Mjl3SEa6OjRLV0sDSsMjLIvvXELcg35+VVM9mCq49z7A==;24:IWUGBEL0OXawy1Z1sV1Z8deuTELGby1NJFXh9GcfcXMn+8mkjPT6q1m42cpvpLKQC2Rww3VjXNNRSb4hXMliZKM0N5d8nCx+V5K1E2jbt6s=;20:IPYqqH8zYJYCa4C3wcJNSNcncz19FgMIE9blIZ/XZnvGIcU+2RprZhk7e3I9in9By8NPT3NVPZI8bDQWdHwbjYsUr39PbC+kS8Y/l5lpF8cHukyX7ajcYJ7yvqDEzqlQaMzaZoEAkKWDfLL6ES+1AUzHoVCYuCdrkAafi1FJU08= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SIXPR06MB0923; sixpr06mb0923: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:SIXPR06MB0923;BCL:0;PCL:0;RULEID:;SRVR:SIXPR06MB0923; x-forefront-prvs: 0636271852 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(51704005)(479174004)(24454002)(377454003)(54356999)(76176999)(50986999)(33656002)(5003600100002)(92566002)(86362001)(76576001)(62966003)(77156002)(2900100001)(77096005)(40100003)(122556002)(2950100001)(46102003)(87936001)(2656002)(5002640100001)(102836002)(106116001)(93886004)(74316001)(66066001)(5001960100002)(189998001);DIR:OUT;SFP:1102;SCL:1;SRVR:SIXPR06MB0923;H:SIXPR06MB0639.apcprd06.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: renesas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2015 15:02:26.1126 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SIXPR06MB0923 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2085 Lines: 54 Hi Sergei, On 13 July 2015 11:17, Sergei wrote: > Hello. > > On 7/13/2015 12:04 PM, Phil Edworthy wrote: > > >>> Instead of statically selecting the PHY connection to either the > >>> USBHS (Function) or PCI0 (Host) IP blocks, this change allows the > >>> dts to specifiy gpio pins for the vbus and id signals. Additional > > >> These GPIOs don't have anything to do with the PHY, they're interfacing > > Perhaps that was too strong statement but nevertheless... Looking at your MAX3355 extcon driver, I can't see how it would work on it's own. The system needs to sense vbus in order to determine that the board has been plugged into a USB Host. Since the MAX3355 device doesn't directly provide any vbus signals, this shouldn't be part of the extcon driver, so where should it be? On the other hand, the MAX3355 has a pair of status pins that can be used to get vbus instead. If these pins aren't used for other functions, maybe it's better to use these in the extcon driver. My intention is to make the USB PHY driver listen for extcon events instead of directly accessing the ID and VBUS signals, but otherwise behave in the same way it currently does. After reading some other threads, I also intend to set up a fixed regulator for the MAX3355 device to setup the shutdown and vbus enable pins. I know that the vbus enable should really be controlled some other way depending on the role, but for the moment I think it's ok just to enable it always. Do you think that is the correct way to progress this? > >> Maxim MAX3355 OTG chip for which I have submitted the extcon driver. > > > Hmm, I see what you mean... could you post your latest version of that > > driver as it seems to have stalled 6 months ago? > > I haven't worked on that driver since then. > > > Thanks > > Phil > > WBR, Sergei Thanks Phil -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/