Hi Linus, On Mon, Mar 09, 2015 at 11:16:08AM -0500, Felipe Balbi wrote: > On Sat, Mar 07, 2015 at 09:06:22PM +0100, Linus Walleij wrote: > > On Fri, Feb 20, 2015 at 8:17 PM, David Cohen > > <david.a.cohen@xxxxxxxxxxxxxxx> wrote: > > > On Fri, Feb 20, 2015 at 10:53:44AM +0100, Linus Walleij wrote: > > > > >> I would put this adjacent to the phy driver somewhere in drivers/usb/* > > >> and make the actual USB-driver thing handle its GPIOs directly. > > >> But I guess David and Felipe have already discussed that as we're > > >> seeing this patch? > > > > > > - The mux functions would be controlled by a possible new pinctrl-gpio > > > driver (Linus, your input here would be nice :) > > > > I don't understand what this means, does it mean a pin control function > > somewhere else controlled by a GPIO pin? > > > > Or do you mean a new combined pin control and GPIO driver (we have > > plenty of these). > > > > If you elaborate on what you need to do in that driver I might > > understand it better. This is a "virtual" ACPI device. Long story short we've 3 GPIOs controlling the state of an USB OTG port. Neither of the hw components controlled by these GPIOs are connected to a bus. The ACPI table was implemented in such way that it considers this USB port as a single "device" giving all 3 GPIOs to it. When upstreaming this driver, the feedback I got is to split this driver into simpler and more generic ones. FWIW ACPI tables are constructed considering a valid Linux API during its implementation and are quite difficult to change after product is released. The solution would be to use MFD subsystem: this driver would create simpler children platform devices. But at least on ACPI case, GPIO API blocks the ability to create children platform devices that require GPIO as platform data, despite we've many drivers on upstream that expect this behavior: e.g. extcon-gpio.c Are we considering those driver deprecated from the GPIO point of view? If yes, we need to provide an update for them (we can't let upstreamed drivers broken). If no, we need to provide a way to move forward the GPIO to children devices. BR, David > > there's a discrete mux (not something integrated in the SoC) whose > select signal is tied to a GPIO (in some cases, more than one, but > usually people use 2-state muxes). > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
