Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753844AbbBXTQ2 (ORCPT ); Tue, 24 Feb 2015 14:16:28 -0500 Received: from mga01.intel.com ([192.55.52.88]:60865 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753803AbbBXTQ0 (ORCPT ); Tue, 24 Feb 2015 14:16:26 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,640,1418112000"; d="scan'208";a="670978118" Date: Tue, 24 Feb 2015 11:18:06 -0800 From: David Cohen To: Linus Walleij , Robert Baldyga , heikki.krogerus@linux.intel.com Cc: MyungJoo Ham , Chanwoo Choi , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" , baolu.lu@linux.intel.com, balbi@ti.com Subject: Re: [PATCH v2] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s) Message-ID: <20150224191806.GB13094@psi-dev26.jf.intel.com> References: <1419288217-19262-1-git-send-email-david.a.cohen@linux.intel.com> <1424375984-26241-1-git-send-email-david.a.cohen@linux.intel.com> <54E6D721.9070107@samsung.com> <20150220191700.GB15303@psi-dev26.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150220191700.GB15303@psi-dev26.jf.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1268 Lines: 36 Hi, [snip] > Felipe suggested to "divide to conquer" instead of having a single > extcon driver to handle all these functions: > > - The mux functions would be controlled by a possible new pinctrl-gpio > driver (Linus, your input here would be nice :) > - The VBUS would be a fixed regulator > - The USB ID would make usage of existent extcon-gpio > > But the on fw side, this is a single ACPI device representing a virtual > device for USB OTG port, which is nothing but a bunch of independent > GPIOs. > > I could make a mfd driver to register devices for those simpler and more > generic drivers, but according to [1] community recognized it as a hack > with ACPI since I'd need to give them the GPIO without requesting on > mfd. I believe this case could be resumed in: Would be [1] acceptable for mfd drivers? - If yes, I can split this driver into more generic ones - If no, I see no other option but having this driver fully controlling the USB OTG port. BR, David [1] https://lkml.org/lkml/2014/12/18/82 -- 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/