diff mbox

[v4,1/1] extcon: usb-gpio: Introduce gpio usb extcon driver

Message ID 54CF4FC7.2050309@ti.com
State Accepted, archived
Headers show

Commit Message

Roger Quadros Feb. 2, 2015, 10:21 a.m. UTC
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 <rogerq@ti.com>
---
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

Comments

Chanwoo Choi Feb. 3, 2015, 1:13 a.m. UTC | #1
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 <rogerq@ti.com>
> ---
> 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 0000000..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 devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ivan T. Ivanov March 16, 2015, 12:32 p.m. UTC | #2
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 <rogerq@ti.com>
> ---
> 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,
> +};
> 

<snip>

> +
> +static int usb_extcon_probe(struct platform_device *pdev)
> +{
> 

<snip>

> +
> +       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 devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Roger Quadros March 16, 2015, 1:11 p.m. UTC | #3
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 <rogerq@ti.com>
>> ---
>> 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[][].

>>
> 
> <snip>
> 
>> +
>> +static int usb_extcon_probe(struct platform_device *pdev)
>> +{
>>
> 
> <snip>
> 
>> +
>> +       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 devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ivan T. Ivanov March 16, 2015, 2:23 p.m. UTC | #4
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 <rogerq@ti.com>
> > > ---
> > > 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?

> 
> > 
> > <snip>
> > 
> > > +
> > > +static int usb_extcon_probe(struct platform_device *pdev)
> > > +{
> > > 
> > 
> > <snip>
> > 
> > > +
> > > +       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 devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chanwoo Choi March 17, 2015, 2:01 a.m. UTC | #5
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 <rogerq@ti.com>
>>>> ---
>>>> 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 devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ivan T. Ivanov March 17, 2015, 7:52 a.m. UTC | #6
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 <rogerq@ti.com>
> > > > > ---
> > > > > 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 devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ivan T. Ivanov March 17, 2015, 8 a.m. UTC | #7
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 <rogerq@ti.com>
> > > > > > ---
> > > > > > 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 devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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 0000000..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 0000000..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 <rogerq@ti.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/extcon.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/workqueue.h>
+
+#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,
+		 * we simulate USB peripheral attach here.
+		 */
+		extcon_set_cable_state(info->edev,
+				       usb_extcon_cable[EXTCON_CABLE_USB_HOST],
+				       false);
+		extcon_set_cable_state(info->edev,
+				       usb_extcon_cable[EXTCON_CABLE_USB],
+				       true);
+	} else {
+		/*
+		 * ID = 0 means USB HOST cable attached.
+		 * As we don't have event for USB peripheral cable detached,
+		 * we simulate USB peripheral detach here.
+		 */
+		extcon_set_cable_state(info->edev,
+				       usb_extcon_cable[EXTCON_CABLE_USB],
+				       false);
+		extcon_set_cable_state(info->edev,
+				       usb_extcon_cable[EXTCON_CABLE_USB_HOST],
+				       true);
+	}
+}
+
+static irqreturn_t usb_irq_handler(int irq, void *dev_id)
+{
+	struct usb_extcon_info *info = dev_id;
+
+	queue_delayed_work(system_power_efficient_wq, &info->wq_detcable,
+			   info->debounce_jiffies);
+
+	return IRQ_HANDLED;
+}
+
+static int usb_extcon_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct usb_extcon_info *info;
+	int ret;
+
+	if (!np)
+		return -EINVAL;
+
+	info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
+	if (!info)
+		return -ENOMEM;
+
+	info->dev = dev;
+	info->id_gpiod = devm_gpiod_get(&pdev->dev, "id");
+	if (IS_ERR(info->id_gpiod)) {
+		dev_err(dev, "failed to get ID GPIO\n");
+		return PTR_ERR(info->id_gpiod);
+	}
+
+	ret = gpiod_set_debounce(info->id_gpiod,
+				 USB_GPIO_DEBOUNCE_MS * 1000);
+	if (ret < 0)
+		info->debounce_jiffies = msecs_to_jiffies(USB_GPIO_DEBOUNCE_MS);
+
+	INIT_DELAYED_WORK(&info->wq_detcable, usb_extcon_detect_cable);
+
+	info->id_irq = gpiod_to_irq(info->id_gpiod);
+	if (info->id_irq < 0) {
+		dev_err(dev, "failed to get ID IRQ\n");
+		return info->id_irq;
+	}
+
+	ret = devm_request_threaded_irq(dev, info->id_irq, NULL,
+					usb_irq_handler,
+					IRQF_TRIGGER_RISING |
+					IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+					pdev->name, info);
+	if (ret < 0) {
+		dev_err(dev, "failed to request handler for ID IRQ\n");
+		return ret;
+	}
+
+	info->edev = devm_extcon_dev_allocate(dev, usb_extcon_cable);
+	if (IS_ERR(info->edev)) {
+		dev_err(dev, "failed to allocate extcon device\n");
+		return -ENOMEM;
+	}
+
+	ret = devm_extcon_dev_register(dev, info->edev);
+	if (ret < 0) {
+		dev_err(dev, "failed to register extcon device\n");
+		return ret;
+	}
+
+	platform_set_drvdata(pdev, info);
+	device_init_wakeup(dev, 1);
+
+	/* Perform initial detection */
+	usb_extcon_detect_cable(&info->wq_detcable.work);
+
+	return 0;
+}
+
+static int usb_extcon_remove(struct platform_device *pdev)
+{
+	struct usb_extcon_info *info = platform_get_drvdata(pdev);
+
+	cancel_delayed_work_sync(&info->wq_detcable);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int usb_extcon_suspend(struct device *dev)
+{
+	struct usb_extcon_info *info = dev_get_drvdata(dev);
+	int ret = 0;
+
+	if (device_may_wakeup(dev)) {
+		ret = enable_irq_wake(info->id_irq);
+		if (ret)
+			return ret;
+	}
+
+	/*
+	 * We don't want to process any IRQs after this point
+	 * as GPIOs used behind I2C subsystem might not be
+	 * accessible until resume completes. So disable IRQ.
+	 */
+	disable_irq(info->id_irq);
+
+	return ret;
+}
+
+static int usb_extcon_resume(struct device *dev)
+{
+	struct usb_extcon_info *info = dev_get_drvdata(dev);
+	int ret = 0;
+
+	if (device_may_wakeup(dev)) {
+		ret = disable_irq_wake(info->id_irq);
+		if (ret)
+			return ret;
+	}
+
+	enable_irq(info->id_irq);
+
+	return ret;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(usb_extcon_pm_ops,
+			 usb_extcon_suspend, usb_extcon_resume);
+
+static struct of_device_id usb_extcon_dt_match[] = {
+	{ .compatible = "linux,extcon-usb-gpio", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, usb_extcon_dt_match);
+
+static struct platform_driver usb_extcon_driver = {
+	.probe		= usb_extcon_probe,
+	.remove		= usb_extcon_remove,
+	.driver		= {
+		.name	= "extcon-usb-gpio",
+		.pm	= &usb_extcon_pm_ops,
+		.of_match_table = usb_extcon_dt_match,
+	},
+};
+
+module_platform_driver(usb_extcon_driver);
+
+MODULE_AUTHOR("Roger Quadros <rogerq@ti.com>");
+MODULE_DESCRIPTION("USB GPIO extcon driver");
+MODULE_LICENSE("GPL v2");