[PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.
The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.
For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-HOST (attach/detach)
This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.
Signed-off-by: Roger Quadros
---
v4:
- got rid of id_irqwake flag. Fail if enable/disable_irq_wake() fails
- changed host cable name to "USB-HOST"
- use 'depends on' instead of 'select' GPIOLIB
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 18 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 237 +
4 files changed, 263 insertions(+)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
create mode 100644 drivers/extcon/extcon-usb-gpio.c
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
new file mode 100644
index 000..85fe6b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -0,0 +1,18 @@
+USB GPIO Extcon device
+
+This is a virtual device used to generate USB cable states from the USB ID pin
+connected to a GPIO pin.
+
+Required properties:
+- compatible: Should be "linux,extcon-usb-gpio"
+- id-gpio: gpio for USB ID pin. See gpio binding.
+
+Example:
+ extcon_usb1 {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
+ }
+
+ &omap_dwc3_1 {
+ extcon = <&extcon_usb1>;
+ };
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..e4c01ab 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,11 @@ config EXTCON_SM5502
Silicon Mitus SM5502. The SM5502 is a USB port accessory
detector and switch.
+config EXTCON_USB_GPIO
+ tristate "USB GPIO extcon support"
+ depends on GPIOLIB
+ help
+ Say Y here to enable GPIO based USB cable detection extcon support.
+ Used typically if GPIO is used for USB ID pin detection.
+
endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..6a08a98 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
+obj-$(CONFIG_EXTCON_USB_GPIO) += extcon-usb-gpio.o
diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
new file mode 100644
index 000..3f0bad3
--- /dev/null
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -0,0 +1,237 @@
+/**
+ * drivers/extcon/extcon-usb-gpio.c - USB GPIO extcon driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define USB_GPIO_DEBOUNCE_MS 20 /* ms */
+
+struct usb_extcon_info {
+ struct device *dev;
+ struct extcon_dev *edev;
+
+ struct gpio_desc *id_gpiod;
+ int id_irq;
+
+ unsigned long debounce_jiffies;
+ struct delayed_work wq_detcable;
+};
+
+/* List of detectable cables */
+enum {
+ EXTCON_CABLE_USB = 0,
+ EXTCON_CABLE_USB_HOST,
+
+ EXTCON_CABLE_END,
+};
+
+static const char *usb_extcon_cable[] = {
+ [EXTCON_CABLE_USB] = "USB",
+ [EXTCON_CABLE_USB_HOST] = "USB-HOST",
+ NULL,
+};
+
+static void usb_extcon_detect_cable(struct work_struct *work)
+{
+ int id;
+ struct usb_extcon_info *info = container_of(to_delayed_work(work),
+ struct usb_extcon_info,
+ wq_detcable);
+
+ /* check ID and update cable state */
+ id = gpiod_get_value_cansleep(info->id_gpiod);
+ if (id) {
+ /*
+* ID = 1 means USB HOST cable detached.
+* As we don't have event for USB peripheral cable attached,
+
Re: [PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi,
On Mon, 2015-02-02 at 12:21 +0200, Roger Quadros wrote:
> This driver observes the USB ID pin connected over a GPIO and
> updates the USB cable extcon states accordingly.
>
> The existing GPIO extcon driver is not suitable for this purpose
> as it needs to be taught to understand USB cable states and it
> can't handle more than one cable per instance.
>
> For the USB case we need to handle 2 cable states.
> 1) USB (attach/detach)
> 2) USB-HOST (attach/detach)
>
> This driver can be easily updated in the future to handle VBUS
> events in case it happens to be available on GPIO for any platform.
>
> Signed-off-by: Roger Quadros
> ---
> v4:
> - got rid of id_irqwake flag. Fail if enable/disable_irq_wake() fails
> - changed host cable name to "USB-HOST"
I am sorry that I am getting a bit little late into this.
Isn't supposed that we have to use strings defined in
const char extcon_cable_name[][]?
> +
> +/* List of detectable cables */
> +enum {
> + EXTCON_CABLE_USB = 0,
> + EXTCON_CABLE_USB_HOST,
> +
Same here: duplicated with enum extcon_cable_name
> + EXTCON_CABLE_END,
> +};
> +
> +static const char *usb_extcon_cable[] = {
> + [EXTCON_CABLE_USB] = "USB",
> + [EXTCON_CABLE_USB_HOST] = "USB-HOST",
> + NULL,
> +};
>
> +
> +static int usb_extcon_probe(struct platform_device *pdev)
> +{
>
> +
> + ret = devm_request_threaded_irq(dev, info->id_irq, NULL,
> + usb_irq_handler,
> + IRQF_TRIGGER_RISING |
> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
Shouldn't triggers be defined in DTS files?
Regards,
Ivan
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi Ivan,
On 16/03/15 14:32, Ivan T. Ivanov wrote:
> Hi,
>
> On Mon, 2015-02-02 at 12:21 +0200, Roger Quadros wrote:
>> This driver observes the USB ID pin connected over a GPIO and
>> updates the USB cable extcon states accordingly.
>>
>> The existing GPIO extcon driver is not suitable for this purpose
>> as it needs to be taught to understand USB cable states and it
>> can't handle more than one cable per instance.
>>
>> For the USB case we need to handle 2 cable states.
>> 1) USB (attach/detach)
>> 2) USB-HOST (attach/detach)
>>
>> This driver can be easily updated in the future to handle VBUS
>> events in case it happens to be available on GPIO for any platform.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> v4:
>> - got rid of id_irqwake flag. Fail if enable/disable_irq_wake() fails
>> - changed host cable name to "USB-HOST"
>
> I am sorry that I am getting a bit little late into this.
>
> Isn't supposed that we have to use strings defined in
> const char extcon_cable_name[][]?
>
>
>> +
>> +/* List of detectable cables */
>> +enum {
>> + EXTCON_CABLE_USB = 0,
>> + EXTCON_CABLE_USB_HOST,
>> +
>
> Same here: duplicated with enum extcon_cable_name
>
>> + EXTCON_CABLE_END,
>> +};
>> +
>> +static const char *usb_extcon_cable[] = {
>> + [EXTCON_CABLE_USB] = "USB",
>> + [EXTCON_CABLE_USB_HOST] = "USB-HOST",
>> + NULL,
>> +};
I'm not exactly sure how else it is supposed to work if we
support only a subset of cables from the global extcon_cable_name[][].
>>
>
>
>
>> +
>> +static int usb_extcon_probe(struct platform_device *pdev)
>> +{
>>
>
>
>
>> +
>> + ret = devm_request_threaded_irq(dev, info->id_irq, NULL,
>> + usb_irq_handler,
>> + IRQF_TRIGGER_RISING |
>> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>
> Shouldn't triggers be defined in DTS files?
Could be but we're sure that we always need the trigger for both rising/falling
edges
in this case. So the usage is more appropriately decided from application point
of view
rather than h/w point of view. h/w is generic GPIO.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi Roger,
On Mon, 2015-03-16 at 15:11 +0200, Roger Quadros wrote:
> Hi Ivan,
>
> On 16/03/15 14:32, Ivan T. Ivanov wrote:
> > Hi,
> >
> > On Mon, 2015-02-02 at 12:21 +0200, Roger Quadros wrote:
> > > This driver observes the USB ID pin connected over a GPIO and
> > > updates the USB cable extcon states accordingly.
> > >
> > > The existing GPIO extcon driver is not suitable for this purpose
> > > as it needs to be taught to understand USB cable states and it
> > > can't handle more than one cable per instance.
> > >
> > > For the USB case we need to handle 2 cable states.
> > > 1) USB (attach/detach)
> > > 2) USB-HOST (attach/detach)
> > >
> > > This driver can be easily updated in the future to handle VBUS
> > > events in case it happens to be available on GPIO for any platform.
> > >
> > > Signed-off-by: Roger Quadros
> > > ---
> > > v4:
> > > - got rid of id_irqwake flag. Fail if enable/disable_irq_wake() fails
> > > - changed host cable name to "USB-HOST"
> >
> > I am sorry that I am getting a bit little late into this.
> >
> > Isn't supposed that we have to use strings defined in
> > const char extcon_cable_name[][]?
> >
> >
> > > +
> > > +/* List of detectable cables */
> > > +enum {
> > > + EXTCON_CABLE_USB = 0,
> > > + EXTCON_CABLE_USB_HOST,
> > > +
> >
> > Same here: duplicated with enum extcon_cable_name
> >
> > > + EXTCON_CABLE_END,
> > > +};
> > > +
> > > +static const char *usb_extcon_cable[] = {
> > > + [EXTCON_CABLE_USB] = "USB",
> > > + [EXTCON_CABLE_USB_HOST] = "USB-HOST",
> > > + NULL,
> > > +};
>
> I'm not exactly sure how else it is supposed to work if we
> support only a subset of cables from the global extcon_cable_name[][].
I don't see issue that we use just 2 events. I think that we can
reuse enum extcon_cable_name and strings already defined in
extcon_cable_name[][] global variable. It is defined extern in
extcon.h file exactly for this purpose, no?
>
> >
> >
> >
> > > +
> > > +static int usb_extcon_probe(struct platform_device *pdev)
> > > +{
> > >
> >
> >
> >
> > > +
> > > + ret = devm_request_threaded_irq(dev, info->id_irq, NULL,
> > > + usb_irq_handler,
> > > + IRQF_TRIGGER_RISING |
> > > + IRQF_TRIGGER_FALLING |
> > > IRQF_ONESHOT,
> >
> > Shouldn't triggers be defined in DTS files?
>
> Could be but we're sure that we always need the trigger for both
> rising/falling edges
> in this case. So the usage is more appropriately decided from application
> point of view
> rather than h/w point of view. h/w is generic GPIO.
No strong opinion on this. Could it be that GPIO did't support edge
triggered interrupt, but just level triggered?
Regards,
Ivan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi Ivan,
On 03/16/2015 11:23 PM, Ivan T. Ivanov wrote:
>
> Hi Roger,
>
> On Mon, 2015-03-16 at 15:11 +0200, Roger Quadros wrote:
>> Hi Ivan,
>>
>> On 16/03/15 14:32, Ivan T. Ivanov wrote:
>>> Hi,
>>>
>>> On Mon, 2015-02-02 at 12:21 +0200, Roger Quadros wrote:
This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.
The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.
For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-HOST (attach/detach)
This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.
Signed-off-by: Roger Quadros
---
v4:
- got rid of id_irqwake flag. Fail if enable/disable_irq_wake() fails
- changed host cable name to "USB-HOST"
>>>
>>> I am sorry that I am getting a bit little late into this.
>>>
>>> Isn't supposed that we have to use strings defined in
>>> const char extcon_cable_name[][]?
>>>
>>>
+
+/* List of detectable cables */
+enum {
+ EXTCON_CABLE_USB = 0,
+ EXTCON_CABLE_USB_HOST,
+
>>>
>>> Same here: duplicated with enum extcon_cable_name
>>>
+ EXTCON_CABLE_END,
+};
+
+static const char *usb_extcon_cable[] = {
+ [EXTCON_CABLE_USB] = "USB",
+ [EXTCON_CABLE_USB_HOST] = "USB-HOST",
+ NULL,
+};
>>
>> I'm not exactly sure how else it is supposed to work if we
>> support only a subset of cables from the global extcon_cable_name[][].
>
> I don't see issue that we use just 2 events. I think that we can
> reuse enum extcon_cable_name and strings already defined in
> extcon_cable_name[][] global variable. It is defined extern in
> extcon.h file exactly for this purpose, no?
'extcon_cable_name' global variable is not used on extcon driver directly.
It is just recommended cable name.
I have plan to use standard cable name for extcon driver instead of that
each extcon driver define the cable name.
[snip]
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi,
On Tue, 2015-03-17 at 11:01 +0900, Chanwoo Choi wrote:
> Hi Ivan,
>
> On 03/16/2015 11:23 PM, Ivan T. Ivanov wrote:
> > Hi Roger,
> >
> > On Mon, 2015-03-16 at 15:11 +0200, Roger Quadros wrote:
> > > Hi Ivan,
> > >
> > > On 16/03/15 14:32, Ivan T. Ivanov wrote:
> > > > Hi,
> > > >
> > > > On Mon, 2015-02-02 at 12:21 +0200, Roger Quadros wrote:
> > > > > This driver observes the USB ID pin connected over a GPIO and
> > > > > updates the USB cable extcon states accordingly.
> > > > >
> > > > > The existing GPIO extcon driver is not suitable for this purpose
> > > > > as it needs to be taught to understand USB cable states and it
> > > > > can't handle more than one cable per instance.
> > > > >
> > > > > For the USB case we need to handle 2 cable states.
> > > > > 1) USB (attach/detach)
> > > > > 2) USB-HOST (attach/detach)
> > > > >
> > > > > This driver can be easily updated in the future to handle VBUS
> > > > > events in case it happens to be available on GPIO for any platform.
> > > > >
> > > > > Signed-off-by: Roger Quadros
> > > > > ---
> > > > > v4:
> > > > > - got rid of id_irqwake flag. Fail if enable/disable_irq_wake() fails
> > > > > - changed host cable name to "USB-HOST"
> > > >
> > > > I am sorry that I am getting a bit little late into this.
> > > >
> > > > Isn't supposed that we have to use strings defined in
> > > > const char extcon_cable_name[][]?
> > > >
> > > >
> > > > > +
> > > > > +/* List of detectable cables */
> > > > > +enum {
> > > > > + EXTCON_CABLE_USB = 0,
> > > > > + EXTCON_CABLE_USB_HOST,
> > > > > +
> > > >
> > > > Same here: duplicated with enum extcon_cable_name
> > > >
> > > > > + EXTCON_CABLE_END,
> > > > > +};
> > > > > +
> > > > > +static const char *usb_extcon_cable[] = {
> > > > > + [EXTCON_CABLE_USB] = "USB",
> > > > > + [EXTCON_CABLE_USB_HOST] = "USB-HOST",
> > > > > + NULL,
> > > > > +};
> > >
> > > I'm not exactly sure how else it is supposed to work if we
> > > support only a subset of cables from the global extcon_cable_name[][].
> >
> > I don't see issue that we use just 2 events. I think that we can
> > reuse enum extcon_cable_name
Now I see that extcon_dev_register() expect NULL terminated array of
pointers, so it will not be possible to use enum extcon_cable_name
as index in the above array, sorry.
> > and strings already defined in
> > extcon_cable_name[][] global variable. It is defined extern in
> > extcon.h file exactly for this purpose, no?
>
> 'extcon_cable_name' global variable is not used on extcon driver directly.
> It is just recommended cable name.
Hm, this is what bothers me. How client drivers will know cable name if
every provider start using its own naming scheme?
If I write client driver I will use:
extcon_register_interest(obj, name, extcon_cable_name[EXTCON_USB_HOST], nb);
and this will now work with this driver because it define string differently.
... Well, I see that string is changed because your recommendation :-),
then lets fix extcon_cable_name strings and not let drivers define its own
names.
> I have plan to use standard cable name for extcon driver instead of that
> each extcon driver define the cable name.
>
Sound like a good plan :-)
Regards,
Ivan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
Fixed spelling error.
On Tue, 2015-03-17 at 09:52 +0200, Ivan T. Ivanov wrote:
> Hi,
>
> On Tue, 2015-03-17 at 11:01 +0900, Chanwoo Choi wrote:
> > Hi Ivan,
> >
> > On 03/16/2015 11:23 PM, Ivan T. Ivanov wrote:
> > > Hi Roger,
> > >
> > > On Mon, 2015-03-16 at 15:11 +0200, Roger Quadros wrote:
> > > > Hi Ivan,
> > > >
> > > > On 16/03/15 14:32, Ivan T. Ivanov wrote:
> > > > > Hi,
> > > > >
> > > > > On Mon, 2015-02-02 at 12:21 +0200, Roger Quadros wrote:
> > > > > > This driver observes the USB ID pin connected over a GPIO and
> > > > > > updates the USB cable extcon states accordingly.
> > > > > >
> > > > > > The existing GPIO extcon driver is not suitable for this purpose
> > > > > > as it needs to be taught to understand USB cable states and it
> > > > > > can't handle more than one cable per instance.
> > > > > >
> > > > > > For the USB case we need to handle 2 cable states.
> > > > > > 1) USB (attach/detach)
> > > > > > 2) USB-HOST (attach/detach)
> > > > > >
> > > > > > This driver can be easily updated in the future to handle VBUS
> > > > > > events in case it happens to be available on GPIO for any platform.
> > > > > >
> > > > > > Signed-off-by: Roger Quadros
> > > > > > ---
> > > > > > v4:
> > > > > > - got rid of id_irqwake flag. Fail if enable/disable_irq_wake()
> > > > > > fails
> > > > > > - changed host cable name to "USB-HOST"
> > > > >
> > > > > I am sorry that I am getting a bit little late into this.
> > > > >
> > > > > Isn't supposed that we have to use strings defined in
> > > > > const char extcon_cable_name[][]?
> > > > >
> > > > >
> > > > > > +
> > > > > > +/* List of detectable cables */
> > > > > > +enum {
> > > > > > + EXTCON_CABLE_USB = 0,
> > > > > > + EXTCON_CABLE_USB_HOST,
> > > > > > +
> > > > >
> > > > > Same here: duplicated with enum extcon_cable_name
> > > > >
> > > > > > + EXTCON_CABLE_END,
> > > > > > +};
> > > > > > +
> > > > > > +static const char *usb_extcon_cable[] = {
> > > > > > + [EXTCON_CABLE_USB] = "USB",
> > > > > > + [EXTCON_CABLE_USB_HOST] = "USB-HOST",
> > > > > > + NULL,
> > > > > > +};
> > > >
> > > > I'm not exactly sure how else it is supposed to work if we
> > > > support only a subset of cables from the global extcon_cable_name[][].
> > >
> > > I don't see issue that we use just 2 events. I think that we can
> > > reuse enum extcon_cable_name
>
> Now I see that extcon_dev_register() expect NULL terminated array of
> pointers, so it will not be possible to use enum extcon_cable_name
> as index in the above array, sorry.
>
> > > and strings already defined in
> > > extcon_cable_name[][] global variable. It is defined extern in
> > > extcon.h file exactly for this purpose, no?
> >
> > 'extcon_cable_name' global variable is not used on extcon driver directly.
> > It is just recommended cable name.
>
> Hm, this is what bothers me. How client drivers will know cable name if
> every provider start using its own naming scheme?
>
> If I write client driver I will use:
>
> extcon_register_interest(obj, name, extcon_cable_name[EXTCON_USB_HOST], nb);
>
> and this will now work with this driver because it define string differently.
^^^
s/now/not/
>
> ... Well, I see that string is changed because your recommendation :-),
> then lets fix extcon_cable_name strings and not let drivers define its own
> names.
>
>
> > I have plan to use standard cable name for extcon driver instead of that
> > each extcon driver define the cable name.
> >
>
> Sound like a good plan :-)
>
> Regards,
> Ivan
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi Roger,
Looks good to me. Applied it on v3.21 queue.
Thanks,
Chanwoo Choi
On 02/02/2015 07:21 PM, Roger Quadros wrote:
> This driver observes the USB ID pin connected over a GPIO and
> updates the USB cable extcon states accordingly.
>
> The existing GPIO extcon driver is not suitable for this purpose
> as it needs to be taught to understand USB cable states and it
> can't handle more than one cable per instance.
>
> For the USB case we need to handle 2 cable states.
> 1) USB (attach/detach)
> 2) USB-HOST (attach/detach)
>
> This driver can be easily updated in the future to handle VBUS
> events in case it happens to be available on GPIO for any platform.
>
> Signed-off-by: Roger Quadros
> ---
> v4:
> - got rid of id_irqwake flag. Fail if enable/disable_irq_wake() fails
> - changed host cable name to "USB-HOST"
> - use 'depends on' instead of 'select' GPIOLIB
>
> .../devicetree/bindings/extcon/extcon-usb-gpio.txt | 18 ++
> drivers/extcon/Kconfig | 7 +
> drivers/extcon/Makefile| 1 +
> drivers/extcon/extcon-usb-gpio.c | 237
> +
> 4 files changed, 263 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> create mode 100644 drivers/extcon/extcon-usb-gpio.c
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> new file mode 100644
> index 000..85fe6b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> @@ -0,0 +1,18 @@
> +USB GPIO Extcon device
> +
> +This is a virtual device used to generate USB cable states from the USB ID
> pin
> +connected to a GPIO pin.
> +
> +Required properties:
> +- compatible: Should be "linux,extcon-usb-gpio"
> +- id-gpio: gpio for USB ID pin. See gpio binding.
> +
> +Example:
I add some description for example as following:
+Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
> + extcon_usb1 {
> + compatible = "linux,extcon-usb-gpio";
> + id-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
> + }
> +
> + &omap_dwc3_1 {
> + extcon = <&extcon_usb1>;
> + };
[snip]
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
