Messages in this thread |  | | Date | Thu, 8 Jan 2015 20:23:03 +0100 | Subject | Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s) | From | Linus Walleij <> |
| |
On Mon, Dec 22, 2014 at 11:43 PM, David Cohen <david.a.cohen@linux.intel.com> wrote:
> Some platforms have an USB OTG port fully (or partially) controlled by > GPIOs: > > (1) USB ID is connected directly to GPIO > > Optionally: > (2) VBUS is enabled by a GPIO (when ID is grounded) > (3) Platform has 2 USB controllers connected to same port: one for > device and one for host role. D+/- are switched between phys > by GPIO. > > As per initial version, this driver has the duty to control whether > USB-Host cable is plugged in or not: > - If yes, OTG port is configured for host role > - If no, by standard, the OTG port is configured for device role > > Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Pretty interesting! I don't understand the USB stuff so commenting from a GPIO side of things only.
> +config EXTCON_OTG_GPIO > + tristate "VIRTUAL USB OTG PORT support" > + depends on GPIOLIB
Isn't it dependent on ACPI? This was mentioned in the commit message.
> +/* > + * Virtual USB OTG Port driver controlled by gpios > + * > + * Copyright (c) 2014, Intel Corporation. > + * Author: David Cohen <david.a.cohen@linux.intel.com> > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include <linux/acpi.h> > +#include <linux/extcon.h> > +#include <linux/gpio.h>
You should include <linux/gpio/consumer.h>
And nothing else. (I think it'll just work.)
> +static int __init vuport_init(void) > +{ > + return platform_driver_register(&vuport_driver); > +} > +subsys_initcall(vuport_init);
Usually we try to avoid this kind of early initcalls. Doesn't deferred probe work as intended?
Yours, Linus Walleij
|  |