Re: [PATCH] xhci: Add BayTrail to list of Intel switchable hosts
On Sat, May 25, 2013 at 03:00:28AM +0400, Sergei Shtylyov wrote: Hello. On 05/25/2013 01:54 AM, Sarah Sharp wrote: From: Chew, Chiau Ee chiau.ee.c...@intel.com Like the xHCI controller on Intel Panther Point and Lynx Point chipsets, the xHCI controller on Intel BayTrail has also ports that can be switched between the EHCI host controller. s/between/to/ Sergei, DO NOT REVIEW PATCHES TO THE XHCI DRIVER. OK, I'll try to follow another rule from you, though I'm getting tired of you telling me what not to do. I've told you not to review patches to the xHCI driver three times now. This is not another rule, this is something I've asked you to avoid already. Strange, I would have remembered if you told me *thrice*, yet what I clearly remember you told me is not to comment on your own patches. Our recollections differ. Fine. I am telling you now, do not provide reviews for ANY xHCI driver patches where the number of noise comments (grammar, spelling fixes, extra parens, etc) outnumber the signal comments (bugs in the patch, missing some idea, etc). Sarah Sharp -- 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
[RFC] xhci: fix dma mask setup in xhci.c
This patch adds a check on whether the host machine
supports the xHC DMA address mask and sets the DMA
mask for coherent DMA address allocation via an
explicit call to dma_set_coherent_mask().
According to DMA-API-HOWTO, if coherent DMA address
mask has not been set explicitly via dma_set_coherent_mask(),
and the driver calls dma_alloc_coherent() or
dma_pool_create() to allocate consistent DMA memory
blocks, the consistent DMA mapping interface will
return by default DMA addresses which are 32-bit
addressable.
Hence, if 64-bit DMA mapping is supported, it
is appropriate to call dma_set_coherent_mask()
with DMA_BIT_MASK(64) to take advantage of it.
Also, according to DMA-API-HOWTO, dma_set_coherent_mask()
is guaranteed to set successfully the same or a smaller
mask as dma_set_mask().
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
---
After this change, (i have a 64-bit machine) the
consistent_dma_mask_bits entry for xhci controller
that appears under:
/sys/devices/pci:00/:00:device.function/
changed from 32 to 64.
I did not find another way to test this change.
drivers/usb/host/xhci.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b4aa79d..887db65 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4662,11 +4662,21 @@ int xhci_gen_setup(struct usb_hcd *hcd,
xhci_get_quirks_t get_quirks)
*/
xhci = hcd_to_xhci(hcd);
temp = xhci_readl(xhci, xhci-cap_regs-hcc_params);
- if (HCC_64BIT_ADDR(temp)) {
+ /*
+* Check if host machine supports 64 bit DMA address mask
+* and enable it for both streaming and coherent DMA transfers.
+* Otherwise, use 32bit DMA mask, if it is supported.
+*/
+ if (HCC_64BIT_ADDR(temp)
+ !dma_set_mask(hcd-self.controller, DMA_BIT_MASK(64))) {
xhci_dbg(xhci, Enabling 64-bit DMA addresses.\n);
- dma_set_mask(hcd-self.controller, DMA_BIT_MASK(64));
+ dma_set_coherent_mask(hcd-self.controller,
+ DMA_BIT_MASK(64));
} else {
- dma_set_mask(hcd-self.controller, DMA_BIT_MASK(32));
+ if (dma_set_mask(hcd-self.controller,
DMA_BIT_MASK(32)))
+ goto error;
+ dma_set_coherent_mask(hcd-self.controller,
+ DMA_BIT_MASK(32));
}
return 0;
}
@@ -4700,11 +4710,21 @@ int xhci_gen_setup(struct usb_hcd *hcd,
xhci_get_quirks_t get_quirks)
xhci_dbg(xhci, Reset complete\n);
temp = xhci_readl(xhci, xhci-cap_regs-hcc_params);
- if (HCC_64BIT_ADDR(temp)) {
+ /*
+* Check if host machine supports 64 bit DMA address mask
+* and enable it for both streaming and coherent DMA transfers.
+* Otherwise, use 32bit DMA mask, if it is supported.
+*/
+ if (HCC_64BIT_ADDR(temp)
+ !dma_set_mask(hcd-self.controller, DMA_BIT_MASK(64))) {
xhci_dbg(xhci, Enabling 64-bit DMA addresses.\n);
- dma_set_mask(hcd-self.controller, DMA_BIT_MASK(64));
+ dma_set_coherent_mask(hcd-self.controller,
+ DMA_BIT_MASK(64));
} else {
- dma_set_mask(hcd-self.controller, DMA_BIT_MASK(32));
+ if (dma_set_mask(hcd-self.controller, DMA_BIT_MASK(32)))
+ goto error;
+ dma_set_coherent_mask(hcd-self.controller,
+ DMA_BIT_MASK(32));
}
xhci_dbg(xhci, Calling HCD init\n);
--
1.7.10.4
--
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
[PATCH 0/2] MOXA UPORT Serial USB driver
These two patches add support for MOXA 12XX/14XX/16XX USB serial devices. The first patch exports a function from the generic usb serial driver, which the driver in the second patch would like to use. Andrew Lunn (2): USB: Serial: export usb_serial_generic_submit_read_urb() usb-serial: Moxa UPORT 12XX/14XX/16XX driver drivers/usb/serial/Kconfig | 30 + drivers/usb/serial/Makefile |1 + drivers/usb/serial/generic.c |5 +- drivers/usb/serial/mxuport.c | 2005 ++ drivers/usb/serial/mxuport.h | 184 include/linux/usb/serial.h |2 + 6 files changed, 2225 insertions(+), 2 deletions(-) create mode 100644 drivers/usb/serial/mxuport.c create mode 100644 drivers/usb/serial/mxuport.h -- 1.7.10.4 -- 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
[PATCH 1/2] USB: Serial: export usb_serial_generic_submit_read_urb()
USB Serial drivers can currently use the generic function
usb_serial_generic_submit_read_urbs() to submit a group of urbs when
starting up the device. The read bulk callback needs to be able to
submit a single urb. usb_serial_generic_submit_read_urb() does this,
but it is not exported and so only usable within generic functions,
in particular usb_serial_generic_read_bulk_callback().
Export this function so drivers can use it in there own read bulk
callback routine.
Signed-off-by: Andrew Lunn and...@lunn.ch
---
drivers/usb/serial/generic.c |5 +++--
include/linux/usb/serial.h |2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 297665f..13e9b3b 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -253,8 +253,8 @@ int usb_serial_generic_chars_in_buffer(struct tty_struct
*tty)
}
EXPORT_SYMBOL_GPL(usb_serial_generic_chars_in_buffer);
-static int usb_serial_generic_submit_read_urb(struct usb_serial_port *port,
- int index, gfp_t mem_flags)
+int usb_serial_generic_submit_read_urb(struct usb_serial_port *port,
+ int index, gfp_t mem_flags)
{
int res;
@@ -276,6 +276,7 @@ static int usb_serial_generic_submit_read_urb(struct
usb_serial_port *port,
return 0;
}
+EXPORT_SYMBOL_GPL(usb_serial_generic_submit_read_urb);
int usb_serial_generic_submit_read_urbs(struct usb_serial_port *port,
gfp_t mem_flags)
diff --git a/include/linux/usb/serial.h b/include/linux/usb/serial.h
index b9b0f7b4..a85e35b 100644
--- a/include/linux/usb/serial.h
+++ b/include/linux/usb/serial.h
@@ -337,6 +337,8 @@ extern int usb_serial_generic_get_icount(struct tty_struct
*tty,
struct serial_icounter_struct *icount);
extern int usb_serial_generic_register(void);
extern void usb_serial_generic_deregister(void);
+extern int usb_serial_generic_submit_read_urb(struct usb_serial_port *port,
+ int index, gfp_t mem_flags);
extern int usb_serial_generic_submit_read_urbs(struct usb_serial_port *port,
gfp_t mem_flags);
extern void usb_serial_generic_process_read_urb(struct urb *urb);
--
1.7.10.4
--
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: [RFC 6/6] usb: check usb_hub_to_struct_hub() return value
On Fri, 24 May 2013, Sarah Sharp wrote:
From: Mathias Nyman mathias.ny...@linux.intel.com
usb_hub_to_struct_hub() can return NULL in the unlikely cases a hub
without active configuration, or a hub without ports is found.
I think the proper way to fix the last part is to prevent the hub
driver from binding to a hub with no ports. Then it will be guaranteed
that usb_hub_to_struct_hub() will never return NULL whenever the hub
driver is bound to the device in question.
Even now, we are guaranteed that the return value will not be NULL if
the device has any child USB devices or any ports (i.e., if its
maxchild value is larger than 0). Therefore almost all of the checks
added in this patch are not necessary.
Even if unlikely we need to handle those cases properly.
However, we don't have to if they are not just unlikely but impossible.
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -730,7 +730,12 @@ int usb_hub_set_port_power(struct usb_device *hdev, int
port1,
{
int ret;
struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
- struct usb_port *port_dev = hub-ports[port1 - 1];
+ struct usb_port *port_dev;
+
+ if (!hub)
+ return -EINVAL;
This routine is called from only two places, and in both places it is
known that the return value isn't NULL. On the other hand, it might
make more sense to pass the hub pointer as an additional argument to
usb_hub_set_port_power(), so the issue doesn't arise at all.
@@ -964,6 +969,10 @@ int usb_remove_device(struct usb_device *udev)
if (!udev-parent) /* Can't remove a root hub */
return -EINVAL;
hub = usb_hub_to_struct_hub(udev-parent);
+
+ if (!hub)
+ return -EINVAL;
Not needed since we know there is a child device.
@@ -1733,6 +1742,9 @@ hub_ioctl(struct usb_interface *intf, unsigned int
code, void *user_data)
struct usb_device *hdev = interface_to_usbdev (intf);
struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
+ if (!hub)
+ return -EINVAL;
This should be fixed by not binding to hubs with no ports.
@@ -1769,15 +1781,17 @@ hub_ioctl(struct usb_interface *intf, unsigned int
code, void *user_data)
static int find_port_owner(struct usb_device *hdev, unsigned port1,
struct dev_state ***ppowner)
{
+ struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
+
if (hdev-state == USB_STATE_NOTATTACHED)
return -ENODEV;
- if (port1 == 0 || port1 hdev-maxchild)
+ if (port1 == 0 || port1 hdev-maxchild || !hub)
return -EINVAL;
The test is not needed since the hdev-maxchild cannot be larger than 0
if the hub driver isn't bound.
/* This assumes that devices not managed by the hub driver
* will always have maxchild equal to 0.
*/
- *ppowner = (usb_hub_to_struct_hub(hdev)-ports[port1 - 1]-port_owner);
+ *ppowner = (hub-ports[port1 - 1]-port_owner);
This change is okay. The comment should be updated as well, since the
fact it refers to is not an assumption but is guaranteed.
Most of the remaining changes in this patch aren't needed, for reasons
already mentioned.
@@ -5323,7 +5367,8 @@ void usb_set_hub_port_connect_type(struct usb_device
*hdev, int port1,
{
struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
- hub-ports[port1 - 1]-connect_type = type;
+ if (hub)
+ hub-ports[port1 - 1]-connect_type = type;
}
/**
@@ -5339,6 +5384,9 @@ usb_get_hub_port_connect_type(struct usb_device *hdev,
int port1)
{
struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
+ if (!hub)
+ return USB_PORT_CONNECT_TYPE_UNKNOWN;
+
return hub-ports[port1 - 1]-connect_type;
}
@@ -5397,6 +5445,9 @@ acpi_handle usb_get_hub_port_acpi_handle(struct
usb_device *hdev,
{
struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
+ if (!hub)
+ return NULL;
+
return DEVICE_ACPI_HANDLE(hub-ports[port1 - 1]-dev);
}
These three changes probably aren't needed either, but verifying it is
a little more complicated since the callers are in a different source
file. I guess it won't hurt to keep them.
Alan Stern
--
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 2/2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver
On Sun, May 26, 2013 at 06:04:24PM +0200, Johan Hovold wrote:
On Sun, May 26, 2013 at 01:00:51PM +0200, Andrew Lunn wrote:
Add a driver which supports the following Moxa USB to serial converters:
* 2 ports : UPort 1250, UPort 1250I
* 4 ports : UPort 1410, UPort 1450, UPort 1450I
* 8 ports : UPort 1610-8, UPort 1650-8
* 16 ports : UPort 1610-16, UPort 1650-16
The UPORT devices don't directy fit the USB serial model. USB serial
assumes a bulk in/out endpoint pair per serial port. Thus a dual port
USB serial device is expected to have two bulk in/out pairs. The Moxa
UPORT only has one pair for data transfer and places a header on each
transfer over the endpoint indicating for which port the transfer
relates to. There is a second endpoint pair for events, just as modem
control lines changing state, setting baud rates etc. Again, a
multiplexing header is used on these endpoints.
This difference to the model results in some additional code which
other drivers don't have:
Some ports need to have a kfifo explicitily allocated since the
framework does not allocate one if there is no associated endpoints.
The framework will however free it on unload of the module.
All data transfers are made on port0, yet the locks are taken on PortN.
urb-context points to PortN, even though the URL is for port0.
First, thanks for submitting the driver.
And thanks for the quick review.
As you mention, it does not fit
the usb-serial model directly, but it seems that there's still quite a
bit more of generic code that could be reused rather than copied or
reimplemented.
I will take another look. I was not happy with cut/pasting code from
the generic driver, so tried to minimize it. I will take a deeper look
at your suggestions with the endpoints.
Consider my comments as a first round of review, there's probably some
things I've missed and more minor things I'll get back to later.
Sure, no problem.
The driver will attempt to load firmware from userspace and compare
the available version and the running version. If the available
version is newer, it will be download into RAM of the device and
started. This is optional and currently the firmware blobs are not yet
in linux-firmware. However MOXA have agreed that the blobs can be
distributed.
This driver is based on the MOXA driver and retains MOXAs copyright.
The driver is also quite heavily based on the generic driver and much
code is copied more or less verbatim. Please make sure to mention in
this in the header as well.
O.K.
Also, most of the paranoid checks for NULL pointers and closed ports
is from the original MOXA driver. Maybe in the past they have had
problems. I've already take out a lot of dead code, and converted to
generic where i could. I'm happy to continue this.
+/* Global variables */
+static bool debug;
Please drop the debug module parameter. usb_serial_debug_data is
supposed to be controlled using dynamic debugging.
O.K.
+
+/* Table of devices that work with this driver */
+static struct usb_device_id mxuport_idtable[] = {
+ {USB_DEVICE(MX_USBSERIAL_VID, MX_UPORT1250_PID)},
+ {USB_DEVICE(MX_USBSERIAL_VID, MX_UPORT1251_PID)},
+ {USB_DEVICE(MX_USBSERIAL_VID, MX_UPORT1410_PID)},
+ {USB_DEVICE(MX_USBSERIAL_VID, MX_UPORT1450_PID)},
+ {USB_DEVICE(MX_USBSERIAL_VID, MX_UPORT1451_PID)},
+ {USB_DEVICE(MX_USBSERIAL_VID, MX_UPORT1618_PID)},
+ {USB_DEVICE(MX_USBSERIAL_VID, MX_UPORT1658_PID)},
+ {USB_DEVICE(MX_USBSERIAL_VID, MX_UPORT1613_PID)},
+ {USB_DEVICE(MX_USBSERIAL_VID, MX_UPORT1653_PID)},
+ {} /* Terminating entry */
+};
+
+MODULE_DEVICE_TABLE(usb, mxuport_idtable);
+
+/*
+ * mxuport_prepare_write_buffer - fill in the buffer, ready for
+ * sending
+ *
+ * Add a four byte header containing the port number and the number of
+ * bytes of data in the message. Return the number of bytes in the
+ * buffer.
+ */
+static int mxuport_prepare_write_buffer(struct usb_serial_port *port,
+ void *dest, size_t size)
+{
+ struct mxuport_port *mx_port = usb_get_serial_port_data(port);
+ unsigned char *buf = dest;
+ int count;
+
+ count = kfifo_out_locked(port-write_fifo, buf + 4, size - 4,
+port-lock);
+
+ put_unaligned_be16(mx_port-portno, buf);
+ put_unaligned_be16(count, buf + 2);
+
+ dev_dbg(port-dev, %s - port %d, size %d count %d, __func__,
+ mx_port-portno, size, count);
+
+ return count + 4;
+}
+
+/*
+ * mxuport_write_start - kick off an URB write
+ * @port: Pointer to the struct usb_serial_port data
+ *
+ * Returns zero on success, or a negative errno value
+ */
+static int mxuport_write_start(struct usb_serial_port *port)
+{
+ struct usb_serial *serial = port-serial;
+ struct urb *urb;
+ int count, result;
+
[PATCH 13/24] drivers/uwb/whci: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen libo.c...@huawei.com
---
drivers/uwb/whci.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/uwb/whci.c b/drivers/uwb/whci.c
index f48093e..deeeba4 100644
--- a/drivers/uwb/whci.c
+++ b/drivers/uwb/whci.c
@@ -253,18 +253,7 @@ static struct pci_driver whci_driver = {
.remove = whci_remove,
};
-static int __init whci_init(void)
-{
- return pci_register_driver(whci_driver);
-}
-
-static void __exit whci_exit(void)
-{
- pci_unregister_driver(whci_driver);
-}
-
-module_init(whci_init);
-module_exit(whci_exit);
+module_pci_driver(whci_driver);
MODULE_DESCRIPTION(WHCI UWB Multi-interface Controller enumerator);
MODULE_AUTHOR(Cambridge Silicon Radio Ltd.);
--
1.7.1
--
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 v5 2/3] extcon: Palmas Extcon Driver
Hi Kishon,
I have some comment about this patch
and upload modified patch to following repository (extcon-for-palmas).
-
http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-for-palmasid=f2b7cb80699cbe1a5fd6c97ef2c600915f8d7f2c
This patchset include patch related to other module
,so I need your opinion to apply this patchset to git repository.
On 05/24/2013 11:31 PM, Kishon Vijay Abraham I wrote:
From: Graeme Gregory g...@slimlogic.co.uk
This is the driver for the USB comparator built into the palmas chip. It
handles the various USB OTG events that can be generated by cable
insertion/removal.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Ruchika Kharwar ruch...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
[kis...@ti.com: adapted palmas usb driver to use the extcon framework]
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
Changes from v4:
* removed no_control_vbus property (to be used if the platform wants to use
its own vbus control.
* removed unnecessary headers
* moved the palmas_usb_state to palmas.h
* misc cleanups
*A checkpatch warning WARNING: static const char * array should
probably be static const char * constis ignored since it introduces a
compilation warning.
Changes from v3:
* adapted the driver to extcon framework (so moved to drivers/extcon)
* removed palmas_usb_(write/read) and replaced all calls with
palmas_(read/write).
* ignored a checkpatch warning in the line
static const char *palmas_extcon_cable[] = {
as it seemed to be incorrect?
* removed all references to OMAP in this driver.
* couldn't test this driver with mainline as omap5 panda is not booting
with mainline.
* A comment to change to platform_get_irq from regmap is not done as I felt
the data should come from regmap in this case. Graeme?
Changes from v2:
* Moved the driver to drivers/usb/phy/
* Added a bit more explanation in Kconfig
.../devicetree/bindings/extcon/extcon-twl.txt | 16 +
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-palmas.c | 341
+
include/linux/mfd/palmas.h | 25 +-
5 files changed, 380 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-twl.txt
create mode 100644 drivers/extcon/extcon-palmas.c
diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt
b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
new file mode 100644
index 000..8ffdeed
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
@@ -0,0 +1,15 @@
+EXTCON FOR TWL CHIPS
+
+PALMAS USB COMPARATOR
+Required Properties:
+ - compatible : Should be ti,palmas-usb or ti,twl6035-usb
+ - vbus-supply : phandle to the regulator device tree node.
+
+Optional Properties:
+ - ti,wakeup : To enable the wakeup comparator in probe
+
+palmas-usb {
+ compatible = ti,twl6035-usb, ti,palmas-usb;
+ vbus-supply = smps10_reg;
+ ti,wakeup;
+};
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 3297301..63f454e 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -53,4 +53,11 @@ config EXTCON_ARIZONA
with Wolfson Arizona devices. These are audio CODECs with
advanced audio accessory detection support.
+config EXTCON_PALMAS
+ tristate Palmas USB EXTCON support
+ depends on MFD_PALMAS
You should add REGULATOR_PALMAS dependency because
palmas_set_switch_smps10() is defined in palmas regulator driver.
+depends on MFD_PALMAS REGULATOR_PALMAS
+ help
+ Say Y here to enable support for USB peripheral and USB host
+ detection by palmas usb.
+
endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index f98a3c4..540e2c3 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
obj-$(CONFIG_EXTCON_MAX77693)+= extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
+obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
new file mode 100644
index 000..9e613e9
--- /dev/null
+++ b/drivers/extcon/extcon-palmas.c
@@ -0,0 +1,341 @@
+/*
+ * Palmas USB transceiver driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
Re: [PATCH 3/3] usb: dwc3: use extcon fwrk to receive connect/disconnect notification
On 05/24/2013 11:31 PM, Kishon Vijay Abraham I wrote: Modified dwc3-omap to receive connect and disconnect notification using extcon framework. Also did the necessary cleanups required after adapting to extcon framework. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- drivers/usb/dwc3/dwc3-omap.c | 80 +-- include/linux/usb/dwc3-omap.h | 30 2 files changed, 62 insertions(+), 48 deletions(-) delete mode 100644 include/linux/usb/dwc3-omap.h I check the code about extcon framework. Acked-by: Chanwoo Choi cw00.c...@samsung.com 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 v5 2/3] extcon: Palmas Extcon Driver
Hi, On Monday 27 May 2013 11:04 AM, Chanwoo Choi wrote: Hi Kishon, I have some comment about this patch and upload modified patch to following repository (extcon-for-palmas). - http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-for-palmasid=f2b7cb80699cbe1a5fd6c97ef2c600915f8d7f2c This patchset include patch related to other module ,so I need your opinion to apply this patchset to git repository. yeah.. Still there is some confusion with palmas_set_switch_smps10(). I think we can remove it for now and add it separately later. By this at least we can have device mode fully functional in OMAP5. What do you think? Thanks Kishon -- 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
