[PATCH] usb: musb: ux500: fix 'musbid' undeclared error in ux500_remove()
commit 65b3d52d02a558fbfe08e43688e15390c5ab3067 (usb: musb: add musb_ida for multi instance support) used musbid in ux500_remove() but nerver declared it. I found this in x86_64 platform, but not sure whether this is a error on the correct ARCH. $ make drivers/usb/musb/ux500.o make[1]: Nothing to be done for `all'. make[1]: Nothing to be done for `relocs'. CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h CALLscripts/checksyscalls.sh CC drivers/usb/musb/ux500.o drivers/usb/musb/ux500.c: In function 'ux500_probe': drivers/usb/musb/ux500.c:78:2: error: 'musbid' undeclared (first use in this function) drivers/usb/musb/ux500.c:78:2: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [drivers/usb/musb/ux500.o] Error 1 make: *** [drivers/usb/musb/ux500.o] Error 2 Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn --- drivers/usb/musb/ux500.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c index d62a91f..0e62f50 100644 --- a/drivers/usb/musb/ux500.c +++ b/drivers/usb/musb/ux500.c @@ -65,7 +65,7 @@ static int __devinit ux500_probe(struct platform_device *pdev) struct platform_device *musb; struct ux500_glue *glue; struct clk *clk; - + int musbid; int ret = -ENOMEM; glue = kzalloc(sizeof(*glue), GFP_KERNEL); -- 1.7.11.7 -- 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]staging: ehci-w90x900 Fix typos.
From: Justin P. Mattock justinmatt...@gmail.com Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- The below patch fixes a typo in staging: ehci-w90x900 drivers/usb/host/ehci-w90x900.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/ehci-w90x900.c b/drivers/usb/host/ehci-w90x900.c index ec59808..a9c28a0 100644 --- a/drivers/usb/host/ehci-w90x900.c +++ b/drivers/usb/host/ehci-w90x900.c @@ -13,7 +13,7 @@ #include linux/platform_device.h -/*ebable phy0 and phy1 for w90p910*/ +/*enable phy0 and phy1 for w90p910*/ #defineENPHY (0x018) #define PHY0_CTR (0xA4) #define PHY1_CTR (0xA8) -- 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 2/2]staging: winbond Fix typos.
From: Justin P. Mattock justinmatt...@gmail.com
Signed-off-by: Justin P. Mattock justinmatt...@gmail.com
---
The below patch fixes a typo in staging: winbond
drivers/staging/winbond/mds.c |2 +-
drivers/staging/winbond/wbhal.h |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/winbond/mds.c b/drivers/staging/winbond/mds.c
index 1b8b8ac..43990e8 100644
--- a/drivers/staging/winbond/mds.c
+++ b/drivers/staging/winbond/mds.c
@@ -315,7 +315,7 @@ static void Mds_HeaderCopy(struct wbsoft_priv *adapter,
struct wb35_descriptor *
pT00-T00_tx_packet_id = pDes-Descriptor_ID; /* Set packet ID */
pT00-T00_header_length = 24; /* Set header length */
- pT01-T01_retry_abort_ebable = 1; /* 921013 931130.5.h */
+ pT01-T01_retry_abort_enable = 1; /* 921013 931130.5.h */
/* Key ID setup */
pT01-T01_wep_id = 0;
diff --git a/drivers/staging/winbond/wbhal.h b/drivers/staging/winbond/wbhal.h
index 39e84a0..289ee54 100644
--- a/drivers/staging/winbond/wbhal.h
+++ b/drivers/staging/winbond/wbhal.h
@@ -226,11 +226,11 @@ struct T01_descriptor {
u32 T01_add_challenge_text:1;
u32 T01_inhibit_crc:1;
u32 T01_loop_back_wep_mode:1;
- u32 T01_retry_abort_ebable:1;
+ u32 T01_retry_abort_enable:1;
};
#else
struct {
- u32 T01_retry_abort_ebable:1;
+ u32 T01_retry_abort_enable:1;
u32 T01_loop_back_wep_mode:1;
u32 T01_inhibit_crc:1;
u32 T01_add_challenge_text:1;
--
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: [PATCH v2 net-next 00/13] Adding a USB CDC MBIM driver
From: Bjørn Mork bj...@mork.no Date: Mon, 22 Oct 2012 22:56:27 +0200 The USB Communications Device Class Mobile Broadband Interface Model (MBIM) is the USB-IFs alternative to the current chipset/vendor specific solutions to Mobile Broadband device management. The specification, including the management protocol description, can be downloaded from http://www.usb.org/developers/devclass_docs#approved This driver implementing most MBIM features with the exception of 32bit NTB and NDP headers. All applied to net-next, thanks. -- 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] usb: phy: change phy notify functions
On Mon, Oct 22, 2012 at 11:18:58AM +0800, Peter Chen wrote: On Fri, Oct 19, 2012 at 07:20:01PM +0300, Felipe Balbi wrote: Hi, On Tue, Oct 16, 2012 at 09:36:46AM +0800, Peter Chen wrote: The patch includes both API change and caller change. The main changes like below: - add notify_suspend/notify_resume callback This let usb phy driver has the chance to change hw settings during the controller suspend/resume procedure. Besides, old parameter port is useless for phy notify, as one usb phy is only for one usb port. New parameter speed stands for the device's speed which is on the port. - implement notify_suspend/notify_resume callback for mxs phy driver These notify will be called during the bus suspend/resume procedure. - Add phy notify at suspend/resume procedure for chipidea host driver - refine phy notify operation during connection and disconnection The history of this problem like below: At some i.mx SoCs, when controller works at host mode, the PHY register needs to be changed at device connect, disconnect, bus suspend and resume due to the SoC limitations. The phy notification should be added according to below rules: 1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during high speed host mode. 2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during the reset and speed negotiation period. 3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during host suspend/resume sequence. Please refer: i.mx23RM(page 413) for detail. http://www.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf Freescale i.MX SoC, i.mx23, i.mx28 and i.mx6(i.mx6SL does not need to follow the 3rd rule) need to follow above rules. The correct notification setting method should be: 1. Set connect notify after the second bus reset. 2. Set disconnect notify after disconnection. 3. Set suspend nofity after bus goes to suspend (portsc.suspendM=1). 4. Set resume notify after resume (portsc.fpr=0). Signed-off-by: Peter Chen peter.c...@freescale.com Tested-by: Mike Thompson mpthomp...@gmail.com sorry but you're doing too much in a single patch. Please split the patch before I review it any further. Ok, I will. But I will put *.h and *.c at one patch to avoid git bitsec error. that's fine, it doesn't matter how many files you touch as long as the patch is a single, logical, self-contained change. Look at how many things you're doing in a single patch: you add new function pointers to a structure, you implement those for mxs phy driver, you make changes to connect/disconnect sequence of the phy and so on... all those should be split to their own patch. -- balbi signature.asc Description: Digital signature
[PATCH 1/4] USB: Set usb port's DeviceRemovable according acpi information in EHCI
ACPI provide _PLD and _UPC aml methods to describe usb port
visibility and connectability. This patch is to use those information
to set usb port's DeviceRemovable.
Signed-off-by: Lan Tianyu tianyu@intel.com
---
drivers/usb/core/hub.c | 23 +++
drivers/usb/core/usb.h |4
drivers/usb/host/ehci-hub.c |9 +
include/linux/usb.h |4
4 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 64854d7..4d0eebc 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1542,6 +1542,25 @@ static int hub_configure(struct usb_hub *hub,
dev_err(hub-intfdev,
couldn't create port%d device.\n, i + 1);
+ if (hub_is_superspeed(hdev)) {
+ for (i = 1; i = hdev-maxchild; i++)
+ if (hub-ports[i - 1]-connect_type
+ == USB_PORT_CONNECT_TYPE_HARD_WIRED)
+ hub-descriptor-u.hs.DeviceRemovable[i/8]
+ |= 1 (i%8);
+ } else {
+ u16 port_removable =
+ le16_to_cpu(hub-descriptor-u.ss.DeviceRemovable);
+
+ for (i = 1; i = hdev-maxchild; i++)
+ if (hub-ports[i - 1]-connect_type
+ == USB_PORT_CONNECT_TYPE_HARD_WIRED)
+ port_removable |= 1 i;
+
+ hub-descriptor-u.ss.DeviceRemovable =
+ cpu_to_le16(port_removable);
+ }
+
hub_activate(hub, HUB_INIT);
return 0;
@@ -5117,8 +5136,12 @@ usb_get_hub_port_connect_type(struct usb_device *hdev,
int port1)
{
struct usb_hub *hub = hdev_to_hub(hdev);
+ if (!hub)
+ return USB_PORT_CONNECT_TYPE_UNKNOWN;
+
return hub-ports[port1 - 1]-connect_type;
}
+EXPORT_SYMBOL_GPL(usb_get_hub_port_connect_type);
#ifdef CONFIG_ACPI
/**
diff --git a/drivers/usb/core/usb.h b/drivers/usb/core/usb.h
index 1c528c1..1633f6e 100644
--- a/drivers/usb/core/usb.h
+++ b/drivers/usb/core/usb.h
@@ -169,10 +169,6 @@ extern void usb_notify_add_device(struct usb_device *udev);
extern void usb_notify_remove_device(struct usb_device *udev);
extern void usb_notify_add_bus(struct usb_bus *ubus);
extern void usb_notify_remove_bus(struct usb_bus *ubus);
-extern enum usb_port_connect_type
- usb_get_hub_port_connect_type(struct usb_device *hdev, int port1);
-extern void usb_set_hub_port_connect_type(struct usb_device *hdev, int port1,
- enum usb_port_connect_type type);
#ifdef CONFIG_ACPI
extern int usb_acpi_register(void);
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 914ce93..8312516 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -636,6 +636,7 @@ ehci_hub_descriptor (
struct usb_hub_descriptor *desc
) {
int ports = HCS_N_PORTS (ehci-hcs_params);
+ int i;
u16 temp;
desc-bDescriptorType = 0x29;
@@ -650,6 +651,14 @@ ehci_hub_descriptor (
memset(desc-u.hs.DeviceRemovable[0], 0, temp);
memset(desc-u.hs.DeviceRemovable[temp], 0xff, temp);
+ for (i = 1; i = ports; i++) {
+ if (usb_get_hub_port_connect_type(
+ ehci_to_hcd(ehci)-self.root_hub, i)
+ == USB_PORT_CONNECT_TYPE_HARD_WIRED)
+ desc-u.hs.DeviceRemovable[i/8] |= 1 (i%8);
+ }
+
+
temp = 0x0008; /* per-port overcurrent reporting */
if (HCS_PPC (ehci-hcs_params))
temp |= 0x0001; /* per-port power control */
diff --git a/include/linux/usb.h b/include/linux/usb.h
index f92cdf0..e3c4fbb 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -575,6 +575,10 @@ static inline struct usb_device
*interface_to_usbdev(struct usb_interface *intf)
return to_usb_device(intf-dev.parent);
}
+extern enum usb_port_connect_type
+ usb_get_hub_port_connect_type(struct usb_device *hdev, int port1);
+extern void usb_set_hub_port_connect_type(struct usb_device *hdev, int port1,
+ enum usb_port_connect_type type);
extern struct usb_device *usb_get_dev(struct usb_device *dev);
extern void usb_put_dev(struct usb_device *dev);
extern struct usb_device *usb_hub_find_child(struct usb_device *hdev,
--
1.7.9.5
--
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 3/4] usb: Create link files between child device and usb port device.
To show the relationship between usb port and child device,
add link file port under usb device's sysfs directoy and
child under usb port device's sysfs directory. They are linked
to each other.
Signed-off-by: Lan Tianyu tianyu@intel.com
---
drivers/usb/core/hub.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 4d0eebc..0981aea 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1973,6 +1973,8 @@ void usb_disconnect(struct usb_device **pdev)
{
struct usb_device *udev = *pdev;
struct usb_hub *hub = hdev_to_hub(udev);
+ struct usb_port *port_dev =
+ hdev_to_hub(udev-parent)-ports[udev-portnum - 1];
int i;
/* mark the device as inactive, so any further urb submissions for
@@ -1999,6 +2001,9 @@ void usb_disconnect(struct usb_device **pdev)
usb_disable_device(udev, 0);
usb_hcd_synchronize_unlinks(udev);
+ sysfs_remove_link(udev-dev.kobj, port);
+ sysfs_remove_link(port_dev-dev.kobj,
+ child);
usb_remove_ep_devs(udev-ep0);
usb_unlock_device(udev);
@@ -2291,6 +2296,18 @@ int usb_new_device(struct usb_device *udev)
goto fail;
}
+ /* Create link files between child device and usb port device. */
+ if (udev-parent) {
+ int no_warn;
+ struct usb_port *port_dev =
+ hdev_to_hub(udev-parent)-ports[udev-portnum - 1];
+
+ no_warn = sysfs_create_link(udev-dev.kobj,
+ port_dev-dev.kobj, port);
+ no_warn = sysfs_create_link(port_dev-dev.kobj,
+ udev-dev.kobj, child);
+ }
+
(void) usb_create_ep_devs(udev-dev, udev-ep0, udev);
usb_mark_last_busy(udev);
pm_runtime_put_sync_autosuspend(udev-dev);
--
1.7.9.5
--
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] usb: phy: change phy notify functions
On Tue, Oct 23, 2012 at 09:56:45AM +0300, Felipe Balbi wrote: that's fine, it doesn't matter how many files you touch as long as the patch is a single, logical, self-contained change. Look at how many things you're doing in a single patch: you add new function pointers to a structure, you implement those for mxs phy driver, you make changes to connect/disconnect sequence of the phy and so on... all those should be split to their own patch. Thanks, I have posted the v5 patch at: http://www.spinics.net/lists/linux-usb/msg72865.html -- Best Regards, Peter Chen -- 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
[GIT PULL] USB fixes for v3.7-rc3
Hi Greg, here's my second set of fixes for v3.7-rc cycle. Let me know if you want any changes. cheers The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.7-rc3 for you to fetch changes up to 1cb60156defa4f23d5318ea1ddd400f25b2d0ce5: usb: renesas_usbhs: fixup dma transfer stall (2012-10-23 09:44:37 +0300) (from the branch description for fixes local branch) usb: fixes for v3.7-rc3 Here's a new set of fixes for v3.7-rc3. It's quite small, only four patches. There's one bug fix for the newly added musb-dsps glue layer where we could be overflowing a buffer when creating the instance name. NET2272 got a fix for a case where the lock would be left held when exiting the IRQ handler with error in case of Spurious IRQs. Renensas USBHS got a DMA stall fix which would cause transfers to stall forever and a NULL pointer deref fix in case of pipe detach. Daniel Mack (1): usb: musb: dsps: fix res_name length Kuninori Morimoto (2): usb: renesas_usbhs: fixup: avoid NULL access on error case pipe detach usb: renesas_usbhs: fixup dma transfer stall Wei Yongjun (1): usb: gadget: net2272: fix missing unlock on error in net2272_irq() drivers/usb/gadget/net2272.c | 4 +++- drivers/usb/musb/musb_dsps.c | 8 drivers/usb/renesas_usbhs/fifo.c | 1 + drivers/usb/renesas_usbhs/mod_host.c | 5 + 4 files changed, 13 insertions(+), 5 deletions(-) -- 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] usb hub: use flush_work instead of flush_work_sync
flush_work_sync and flush_work are now the same and flush_work_sync has been deprecated. This fixes the following warning: drivers/usb/core/hub.c: In function hub_quiesce: drivers/usb/core/hub.c:1216:3: warning: flush_work_sync is deprecated (declared at include/linux/workqueue.h:448) [-Wdeprecated-declarations] Reported-by: Fengguang Wu fengguang...@intel.com Signed-off-by: Octavian Purdila octavian.purd...@intel.com --- drivers/usb/core/hub.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 1181e91..1af04bd 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1213,7 +1213,7 @@ static void hub_quiesce(struct usb_hub *hub, enum hub_quiescing_type type) if (hub-has_indicators) cancel_delayed_work_sync(hub-leds); if (hub-tt.hub) - flush_work_sync(hub-tt.clear_work); + flush_work(hub-tt.clear_work); } /* caller has locked the hub device */ -- 1.7.5.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: chipidea: udc: improper use of
This if is a no-op, as OTG_ are defined as: #define OTGSC_AVVIS BIT(17) #define OTGSC_AVVIE BIT(25) Resulting in queue_work() never called from here. + spin_unlock(ci-lock); I'm not that deep into the OTG stuff to fix it properly. Yes, we have many problems at our OTG switch at chipidea driver. Alex, we have talked about it several weeks ago, do you have any thoughts about it? I will post some for your suggestion. Peter regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | -- 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 PATCH v2 6/6] USB: forbid memory allocation with I/O during bus reset
On Mon, Oct 22, 2012 at 10:37 PM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 22 Oct 2012, Ming Lei wrote: + /* + * Don't allocate memory with GFP_KERNEL in current + * context to avoid possible deadlock if usb mass + * storage interface or usbnet interface(iSCSI case) + * is included in current configuration. The easiest + * approach is to do it for all devices. + */ + memalloc_noio_save(noio_flag); Why not check dev-power.memalloc_noio_resume here too? Yes, we can use the flag here too even though it is introduced for rutime_resume case. Thanks, -- Ming Lei -- 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 03/32 v4] MIPS: Loongson 1B: use ehci-platform instead of ehci-ls1x.
Hi Kelvin,
On Tuesday 23 October 2012 16:13:01 Kelvin Cheung wrote:
Thank Florian.
It looks great.
However, you forget to remove corresponding section in
drivers/usb/host/ehci-hcd.c
...
#ifdef CONFIG_MACH_LOONGSON1
#include ehci-ls1x.c
#define PLATFORM_DRIVER ehci_ls1x_driver
#endif
Indeed, my bad I will follow up with some fixes for this patchset anyway.
Thank you!
...
2012/10/8 Florian Fainelli flor...@openwrt.org
The Loongson 1B EHCI driver does nothing more than what the EHCI platform
driver already does, so use the generic implementation.
Signed-off-by: Florian Fainelli flor...@openwrt.org
---
Changes in v4:
- rebased against greg's latest usb-next
No changes since v1
arch/mips/configs/ls1b_defconfig |1 +
arch/mips/loongson1/common/platform.c |8 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/mips/configs/ls1b_defconfig
b/arch/mips/configs/ls1b_defconfig
index 80cff8b..7eb7554 100644
--- a/arch/mips/configs/ls1b_defconfig
+++ b/arch/mips/configs/ls1b_defconfig
@@ -76,6 +76,7 @@ CONFIG_HID_GENERIC=m
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_HCD_PLATFORM=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
CONFIG_USB_STORAGE=m
CONFIG_USB_SERIAL=m
diff --git a/arch/mips/loongson1/common/platform.c
b/arch/mips/loongson1/common/platform.c
index e92d59c..2874bf2 100644
--- a/arch/mips/loongson1/common/platform.c
+++ b/arch/mips/loongson1/common/platform.c
@@ -13,6 +13,7 @@
#include linux/phy.h
#include linux/serial_8250.h
#include linux/stmmac.h
+#include linux/usb/ehci_pdriver.h
#include asm-generic/sizes.h
#include loongson1.h
@@ -107,13 +108,18 @@ static struct resource ls1x_ehci_resources[] = {
},
};
+static struct usb_ehci_pdata ls1x_ehci_pdata = {
+ .port_power_off = 1,
+};
+
struct platform_device ls1x_ehci_device = {
- .name = ls1x-ehci,
+ .name = ehci-platform,
.id = -1,
.num_resources = ARRAY_SIZE(ls1x_ehci_resources),
.resource = ls1x_ehci_resources,
.dev= {
.dma_mask = ls1x_ehci_dmamask,
+ .platform_data = ls1x_ehci_pdata,
},
};
--
1.7.9.5
--
Best Regards!
Kelvin Cheung
--
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 v3][PATCH 1/2] usb: gadget: Add USB Functions Gadget
On 10/23/2012 08:54 AM, Felipe Balbi wrote: Hi, Hi, On Mon, Oct 22, 2012 at 04:26:35PM +0200, Sebastian Andrzej Siewior wrote: after a mkdir config0 you should allocate a struct usb_configuration for this. |+-function0 |+ name (= ether) Here I am not sure if we should name it function0 and have name property or just put the name of the the directory into usb_get_function() and request that functions. I am also not sure if the order of the functions is important. *I* think that it does not matter if we first expose the serial function and then the mass storage and next time the other way around. Other opinions? I don't it should matter, what matters though is which configuration we expose first. good. What I had in mind was: - create a copy of each descriptor. Each descriptor should have a name or something different that can be used as an unique identifier. - after the copy has been done, the function can request the copy by the name and update some fields like the endpoint number in case of an endpoint descriptor. - configfs could also allow to edit some fields here like the string. note that the string is a separate descriptor :-) configfs should allow for a string descriptor to be linked to e.g. the iManufacturer field of a device descriptor. Maybe a symlink is enough ? Yes we have two pieces: the id entry in the config/device descriptor like iSerial or iFunction and the matching entry in struct usb_string. The id doesn't matter at all so this can be hidden from the user. What remains is the string entry. Now that I read symlink, this sounds great. We could have several languages however, we use only one right now. That means, having something like /cfg/FancyGadget/Strings + + funcname (identifier) + 0x409 + val (mass storage) + 0x40B + val (massamuisti) + 0x416 + val (armazenamento de massa) So now we could symlink iInterface to funcname. So if we do have two configs, we would end up with one string and so if we want to change the string we don't have to do it for each config but only once. I'm not sure if it is clever to have a folder for language id with only one property val which contains the string. So we could have /cfg/FancyGadget/Strings/funcname which is a file and lang_idblankvalue so we would have: 0x409 mass storage 0x40B massamuisti 0x416 armazenamento de massa and echo 0x409 funcname would remove the entry for langid x0409. So I like the symlink idea, just not sure about the interface here :) - each gadget provides now two sometimes three copies of those descriptors. To make things simpler the gadget could provide only set of descriptors (for instance only SS) and composite would create HS and FS from it if desired. I don't think that will work. Think about isochronous and interrupt endpoints where wMaxPacketSize can be whatever we want. I'd rather allocate 3 sets of descriptors :-s I've been looking at those. 99% of them are the same. Look at SS descriptors of mass storage for instance. Now remove the companion descriptors make wMaxPaketSize max value for the speed and you have HS. Make the wMaxPacketSize smaller (or wait this is done by the core during allocation) and you have FS. Interrupt endpoints have an interval for instance. This is always the same value in seconds but the value is different between FS and HS. This is true for all gadgets except for WebCam (the interval here is larger on HS than on FS not sure if this is by accident). wMaxPacketSize is always the same on SS/FS/HS. Isochronos is a little different they probably remain as-it. Here you could have descriptors which describe the Video resolution which is available on HS but on FS. However we could remove some descriptors and this should make it simpler. Look at the IAD descriptor which was missing at SS speed in ECM. I know we can't do it for each gadget but if you could make it simpler for most gadgets why not? Sebastian -- 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 v3][PATCH 1/2] usb: gadget: Add USB Functions Gadget
Hello Felipe, Hello Sebastian, On Tuesday, October 23, 2012 8:55 AM Felipe Balbi wrote: snip Hi, On Mon, Oct 22, 2012 at 04:26:35PM +0200, Sebastian Andrzej Siewior wrote: after a mkdir config0 you should allocate a struct usb_configuration for this. |+-function0 |+ name (= ether) Here I am not sure if we should name it function0 and have name property or just put the name of the the directory into usb_get_function() and request that functions. I am also not sure if the order of the functions is important. *I* think that it does not matter if we first expose the serial function and then the mass storage and next time the other way around. Other opinions? I don't it should matter, what matters though is which configuration we expose first. 1) What kind of ground work/housekeeping are required before configfs works can be considered? on top of my head: - the serial gadget family that is acm, obex and the simple serial require to know in advance the number of available ports. This limit is shared among all users of u_serial. One should look and see if this limitation could be hidden somewhere in u_serial or removed completely. - if the function API is consider okay convert the remaining functions to it. - descriptor allocation / creation rework. Each functions brings a few of their own descriptors. The user might want to change them. Besides the obvious VID/PID thingy there are the string descriptors. Currently a bunch of functions allocate the descriptors once and check if the of the first id is 0 and if not, they skip the allocation. This is done in order to share the string (and descriptor which contains iSerial for instance) across multiple configurations. This sharing does not work if we plan to use the same function twice on two UDCs where we could have diffent IDs. correct What I had in mind was: - create a copy of each descriptor. Each descriptor should have a name or something different that can be used as an unique identifier. - after the copy has been done, the function can request the copy by the name and update some fields like the endpoint number in case of an endpoint descriptor. - configfs could also allow to edit some fields here like the string. note that the string is a separate descriptor :-) configfs should allow for a string descriptor to be linked to e.g. the iManufacturer field of a device descriptor. Maybe a symlink is enough ? - each gadget provides now two sometimes three copies of those descriptors. To make things simpler the gadget could provide only set of descriptors (for instance only SS) and composite would create HS and FS from it if desired. I don't think that will work. Think about isochronous and interrupt endpoints where wMaxPacketSize can be whatever we want. I'd rather allocate 3 sets of descriptors :-s - after attaching all functions within a config, the code resets the allocated endpoints. This is done because only one config can be active at a time and therefore the endpoints are shared. Not only the endpoints can be shared among configs but also among alternate interfaces. If you look at the tcm gadget I share the same endpoints between UAS and BOT. Maybe this could be done in a better way. Also I hate that we allocate HS descriptors and fill the blanks in FS descriptors. Each point here is just one of my thought. I currently try hard not to mix everything in one series and get everything NAKed due to one bad thought :) Right now it works. I am not sure how well they are. Can configfs works be done in parallel? You can take what you have and rebase on top of recent code. The problem is that we can't merge incomplete code and stuff that is missing something because we can't change an interface. The rulles are for now that we want a generic interface and it should be possible to attach it to more than just one UDC at a time and we don't want break anything. 2) If only f_* files remain, where will they be used? Now they are used by their gadget counterparts, e.g. f_sourcesink and f_loopback are used by zero.c. In other words, if f_* files deal with the usb functions level and only they remain, then what takes care of usb configurations and usb devices? The configfs interface. Let me tell you more what I dreaming about while I fall asleep: Now I try to ease the entry pain for configfs. The new code should be used by configfs and by the g_* code and the g_* code shouldn't notice a thing while using it. Once the configfs is stable and working well and people don't complain that it is hard to handle, we can ask all users to switch to it instead of using modprobe g_*. Any why should they use it? Because it is so much more flexible. Then we could provide a
Re: [PATCH v1 00/11] usbnet: usb_control_msg cleanup
On Mon, Oct 15, 2012 at 2:30 PM, Oliver Neukum oneu...@suse.de wrote: v1: - drop previous patch 12, and let net/core handle runtime PM in ioctl path Acked-by: Oliver Neukum oneu...@suse.de David, could you queue the patchset on net-next since my some usbnet runtime PM patches depend on it? Thanks, -- Ming Lei -- 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 1/2] usb: musb: use DMA mode 1 whenever possible
Hi, On Wed, Aug 8, 2012 at 11:28 AM, Rajaram R rajaram.officem...@gmail.com wrote: On Tue, Aug 7, 2012 at 6:39 PM, Roger Quadros rog...@ti.com wrote: Do not rely on any hints from gadget drivers and use DMA mode 1 whenever we expect data of at least the endpoint's packet size and have not yet received a short packet. Could you please let us know what all combination this was tested ? What will happen if the request length is 513 ? The last packet if short is always transferred using DMA mode 0. This patch fixes USB throughput issues in mass storage mode for host to device transfers. Signed-off-by: Roger Quadros rog...@ti.com This commit is causing regression while using the test gadget. output of ./test.sh in usb host machine ./test.sh ./test.sh: 31: ./test.sh: declare: not found TESTING: control out in Tue Oct 23 15:25:29 IST 2012 ** Control test cases: test 9: ch9 postconfig /dev/bus/usb/001/020 test 9, 63.749319 secs test 10: control queueing /dev/bus/usb/001/020 test 10, 10.417282 secs test 14: control writes /dev/bus/usb/001/020 test 14,4.579272 secs assuming sink-src configuration ** Host Write (OUT) test cases: test 1: 5000 transfers, same size stays here infinitely 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
[PATCH] USB: OHCI: sm501: fix build failure after ohci_finish_controller_resume removal
Commit cfa49b4b (USB: ohci: merge ohci_finish_controller_resume with ohci_resume) merged ohci_finish_controller_resume with ohci_resume but forgot to update the ohci-sm501 driver accordingly, thus causing the folllowing build failure: drivers/usb/host/ohci-sm501.c: In function 'ohci_sm501_resume': drivers/usb/host/ohci-sm501.c:241:2: error: implicit declaration of function 'ohci_finish_controller_resume' [-Werror=implicit-function-declaration] Reported-by: Fengguang Wu fengguang...@intel.com Signed-off-by: Florian Fainelli flor...@openwrt.org --- drivers/usb/host/ohci-sm501.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c index 5596ac2..3b5b908 100644 --- a/drivers/usb/host/ohci-sm501.c +++ b/drivers/usb/host/ohci-sm501.c @@ -238,7 +238,7 @@ static int ohci_sm501_resume(struct platform_device *pdev) ohci-next_statechange = jiffies; sm501_unit_power(dev-parent, SM501_GATE_USB_HOST, 1); - ohci_finish_controller_resume(hcd); + ohci_resume(hcd, false); return 0; } #else -- 1.7.9.5 -- 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 v3 resend] USB: PHY: Re-organize Tegra USB PHY driver
-Original Message- From: Venu Byravarasu Sent: Monday, October 22, 2012 4:04 PM To: 'ba...@ti.com' Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux- u...@vger.kernel.org; linux-ker...@vger.kernel.org Subject: RE: [PATCH v3 resend] USB: PHY: Re-organize Tegra USB PHY driver what is this SOC dependent PHY driver ? SOC dependent PHY driver actually deals with the PHY interface programming. e.g. please see code present in tegra2_usb_driver.c. What sort of dependencies are there ? Those differences should be handled with runtime checks. As PHY related bugs got fixed across different set of SOCs apart from adding few features, wanted to separate this out from common PHY functionality. This will help us in adding support for different SOCs with minimum set of changes. Felipe, Please let me know if you have any more questions on this patch. If not, can you please merge this? Thanks, Venu -- balbi * Unknown Key * 0x35CAA444 -- 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 v3 resend] USB: PHY: Re-organize Tegra USB PHY driver
Hi, On Tue, Oct 23, 2012 at 04:23:19PM +0530, Venu Byravarasu wrote: -Original Message- From: Venu Byravarasu Sent: Monday, October 22, 2012 4:04 PM To: 'ba...@ti.com' Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux- u...@vger.kernel.org; linux-ker...@vger.kernel.org Subject: RE: [PATCH v3 resend] USB: PHY: Re-organize Tegra USB PHY driver what is this SOC dependent PHY driver ? SOC dependent PHY driver actually deals with the PHY interface programming. e.g. please see code present in tegra2_usb_driver.c. What sort of dependencies are there ? Those differences should be handled with runtime checks. As PHY related bugs got fixed across different set of SOCs apart from adding few features, wanted to separate this out from common PHY functionality. This will help us in adding support for different SOCs with minimum set of changes. Felipe, Please let me know if you have any more questions on this patch. If not, can you please merge this? Like I said before, those differences should be handled by runtime checks, you shouldn't need separate files for that. What you need to do is implement a single PHY driver which can handle all tegras known to date, later you can add support for new tegras by patching a few things here and there. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/2] USB: digi_acceleport: fix port-data memory leak
On Fri, Oct 19, 2012 at 04:53:18PM +0200, Johan Hovold wrote: Fix port-data memory leak by moving port data deallocation to port_remove for regular ports. Greg, please ignore this one for now. Only moving deallocation to port probe, fixes the memory leak at release, but port data must also be allocated in port_probe in order to avoid potential leaks in the usb-serial probe error path. I was trying to keep this patch minimal and clean up allocation in a follow-up patch, but these two really should be merged. I have fixes for the remaining leaks in the usb-serial drivers and will submit them shortly. Thanks, Johan -- 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] usb: remove CONFIG_USB_MUSB_HOST etc
On 10/8/2012 6:47 PM, Constantine Shulyupin wrote:
From: Constantine Shulyupin co...@makelinux.com
Remove USB configuration in arch/arm/mach-davinci/usb.c accordingly
CONFIG_USB_MUSB_OTG CONFIG_USB_MUSB_PERIPHERAL CONFIG_USB_MUSB_HOST
and set MUSB_OTG configuration by default
because this configuration options are removed from Kconfig.
Signed-off-by: Constantine Shulyupin co...@makelinux.com
Queuing this patch for v3.8. Since the config options are removed there
is no use having code which refers to them. The patch has been tested on
DM644x and DM365 in both host and gadget mode (I will add this
information to commit text while committing). Without this patch .mode
seems to be defaulting to MUSB_UNDEFINED which I think is definitely wrong.
Thanks,
Sekhar
---
arch/arm/mach-davinci/usb.c |6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c
index f77b953..34509ff 100644
--- a/arch/arm/mach-davinci/usb.c
+++ b/arch/arm/mach-davinci/usb.c
@@ -42,14 +42,8 @@ static struct musb_hdrc_config musb_config = {
};
static struct musb_hdrc_platform_data usb_data = {
-#if defined(CONFIG_USB_MUSB_OTG)
/* OTG requires a Mini-AB connector */
.mode = MUSB_OTG,
-#elif defined(CONFIG_USB_MUSB_PERIPHERAL)
- .mode = MUSB_PERIPHERAL,
-#elif defined(CONFIG_USB_MUSB_HOST)
- .mode = MUSB_HOST,
-#endif
.clock = usb,
.config = musb_config,
};
--
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] usb: remove CONFIG_USB_MUSB_HOST etc
Hi,
On Tue, Oct 23, 2012 at 06:04:53PM +0530, Sekhar Nori wrote:
On 10/8/2012 6:47 PM, Constantine Shulyupin wrote:
From: Constantine Shulyupin co...@makelinux.com
Remove USB configuration in arch/arm/mach-davinci/usb.c accordingly
CONFIG_USB_MUSB_OTG CONFIG_USB_MUSB_PERIPHERAL CONFIG_USB_MUSB_HOST
and set MUSB_OTG configuration by default
because this configuration options are removed from Kconfig.
Signed-off-by: Constantine Shulyupin co...@makelinux.com
Queuing this patch for v3.8. Since the config options are removed there
is no use having code which refers to them. The patch has been tested on
DM644x and DM365 in both host and gadget mode (I will add this
information to commit text while committing). Without this patch .mode
seems to be defaulting to MUSB_UNDEFINED which I think is definitely wrong.
sorry for the delay, this looks ok:
Acked-by: Felipe Balbi ba...@ti.com
Thanks,
Sekhar
---
arch/arm/mach-davinci/usb.c |6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c
index f77b953..34509ff 100644
--- a/arch/arm/mach-davinci/usb.c
+++ b/arch/arm/mach-davinci/usb.c
@@ -42,14 +42,8 @@ static struct musb_hdrc_config musb_config = {
};
static struct musb_hdrc_platform_data usb_data = {
-#if defined(CONFIG_USB_MUSB_OTG)
/* OTG requires a Mini-AB connector */
.mode = MUSB_OTG,
-#elif defined(CONFIG_USB_MUSB_PERIPHERAL)
- .mode = MUSB_PERIPHERAL,
-#elif defined(CONFIG_USB_MUSB_HOST)
- .mode = MUSB_HOST,
-#endif
.clock = usb,
.config = musb_config,
};
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/6] UVC gadget cleanup
Hi Bhupesh, On Wednesday 01 August 2012 14:57:09 Laurent Pinchart wrote: Hi, These 6 patches clean up the UVC gadget driver after Bhupesh Sharma's UVC webcam gadget related changes patch series. They're what I would have asked during patch review if the original patches hadn't been merged before I got a change to review them. Bhupesh, would you mind testing the patches, especially the ones that touch super speed support ? I have no SS hardware I can test them on. Ping ? Could you please test this patch set ? I've rebased it on top of the latest master branch in Linus' tree, the result is available in the uvcvideo- gadget branch of git://linuxtv.org/pinchartl/uvcvideo.git, including two of your fixes. I'll then work on your videobuf2 patch. Laurent Pinchart (6): usb: gadget/uvc: Clarify comment about string descriptors usb: gadget/uvc: Rename STATUS_BYTECOUNT to UVC_STATUS_MAX_PACKET_SIZE usb: gadget/uvc: Fix coding style issues introduced by SS support usb: gadget/uvc: Merge the SS/HS/FS status endpoint descriptors usb: gadget/uvc: Merge the streaming maxpacket and mult parameters usb: gadget/uvc: Configure the streaming endpoint based on the speed drivers/usb/gadget/f_uvc.c | 220 - drivers/usb/gadget/f_uvc.h | 12 +- 2 files changed, 110 insertions(+), 122 deletions(-) -- Regards, Laurent Pinchart -- 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 0/6] UVC gadget cleanup
Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Tuesday, October 23, 2012 6:31 PM To: linux-usb@vger.kernel.org Cc: Bhupesh SHARMA Subject: Re: [PATCH 0/6] UVC gadget cleanup Hi Bhupesh, On Wednesday 01 August 2012 14:57:09 Laurent Pinchart wrote: Hi, These 6 patches clean up the UVC gadget driver after Bhupesh Sharma's UVC webcam gadget related changes patch series. They're what I would have asked during patch review if the original patches hadn't been merged before I got a change to review them. Bhupesh, would you mind testing the patches, especially the ones that touch super speed support ? I have no SS hardware I can test them on. Ping ? Could you please test this patch set ? I've rebased it on top of the latest master branch in Linus' tree, the result is available in the uvcvideo- gadget branch of git://linuxtv.org/pinchartl/uvcvideo.git, including two of your fixes. I'll then work on your videobuf2 patch. Sorry for the delay. I had tested the patch-set and completely forgot about updating you with the results (I could not get the UVC gadget to enumerate properly with your patches). I was completely busy with making the UVC working on a NOMMU architecture for a customer and hence the delay. I will start sending you the test results and new patches I have generated locally for the NOMMU architecture from the next week. Sorry again for the delay and thanks for your patience :) Regards, Bhupesh Laurent Pinchart (6): usb: gadget/uvc: Clarify comment about string descriptors usb: gadget/uvc: Rename STATUS_BYTECOUNT to UVC_STATUS_MAX_PACKET_SIZE usb: gadget/uvc: Fix coding style issues introduced by SS support usb: gadget/uvc: Merge the SS/HS/FS status endpoint descriptors usb: gadget/uvc: Merge the streaming maxpacket and mult parameters usb: gadget/uvc: Configure the streaming endpoint based on the speed drivers/usb/gadget/f_uvc.c | 220 - drivers/usb/gadget/f_uvc.h | 12 +- 2 files changed, 110 insertions(+), 122 deletions(-) -- Regards, Laurent Pinchart -- 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: Unreliable USB3 with NEC uPD720200 and Delock Cardreader
On Mon, Oct 22, 2012 at 5:40 PM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Sun, Oct 21, 2012 at 06:03:24PM +0200, Ulrich Eckhardt wrote: Hello, I have problems to get my USB3 cardreader to work reliably when connected to the USB3 port. Due to lack of other USB3 devices I don't know if it is the cardreader or the USB3 host (NEC uPD720200) but the cardreader always works reliable when connected to USB2. Sometimes it is not possible to use the cardreader directly after power up and I have to restart the computer. Very often the cardreader stops working after removing a SD-card and insert another SD-card or during copying data. I have tested it with Kernel 3.6.2. The USB3 port is the one built in the Mainboard M4A87DT EVO. Did a previous kernel version work? I saw, that the outputs of lspci are different, if there is a problem directly after startup. Bjorn, can you take a look at this PCI output, and tell me if it matters that the host has bus master and latency 0 when it works and is missing those properties when it doesn't? Yes, I would think that would matter. If the Bus Master bit in the command register isn't set, the device won't be able to DMA. Also, it looks like the memory BAR is disabled (probably the Memory Space bit in the command register is also cleared). My guess is that these are just a consequence of the driver being detached from the device for some reason. It'd be nice to have a complete dmesg log for a case where the device worked, then stopped working. Also lspci -vv for both cases. Bjorn -- 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 0/6] UVC gadget cleanup
Hi, On Tue, Oct 23, 2012 at 09:50:10PM +0800, Bhupesh SHARMA wrote: Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Tuesday, October 23, 2012 6:31 PM To: linux-usb@vger.kernel.org Cc: Bhupesh SHARMA Subject: Re: [PATCH 0/6] UVC gadget cleanup Hi Bhupesh, On Wednesday 01 August 2012 14:57:09 Laurent Pinchart wrote: Hi, These 6 patches clean up the UVC gadget driver after Bhupesh Sharma's UVC webcam gadget related changes patch series. They're what I would have asked during patch review if the original patches hadn't been merged before I got a change to review them. Bhupesh, would you mind testing the patches, especially the ones that touch super speed support ? I have no SS hardware I can test them on. Ping ? Could you please test this patch set ? I've rebased it on top of the latest master branch in Linus' tree, the result is available in the uvcvideo- gadget branch of git://linuxtv.org/pinchartl/uvcvideo.git, including two of your fixes. I'll then work on your videobuf2 patch. Sorry for the delay. I had tested the patch-set and completely forgot about updating you with the results (I could not get the UVC gadget to enumerate properly with your patches). I was completely busy with making the UVC working on a NOMMU architecture for a customer and hence the delay. I will start sending you the test results and new patches I have generated locally for the NOMMU architecture from the next week. Sorry again for the delay and thanks for your patience :) Regards, Bhupesh Laurent Pinchart (6): usb: gadget/uvc: Clarify comment about string descriptors usb: gadget/uvc: Rename STATUS_BYTECOUNT to UVC_STATUS_MAX_PACKET_SIZE usb: gadget/uvc: Fix coding style issues introduced by SS support usb: gadget/uvc: Merge the SS/HS/FS status endpoint descriptors usb: gadget/uvc: Merge the streaming maxpacket and mult parameters usb: gadget/uvc: Configure the streaming endpoint based on the speed drivers/usb/gadget/f_uvc.c | 220 - drivers/usb/gadget/f_uvc.h | 12 +- 2 files changed, 110 insertions(+), 122 deletions(-) I don't seem to have the patches in my inbox. I'd like to have the patches with proper Tested-by tags so I can queue them for v3.8 merge window. -- balbi signature.asc Description: Digital signature
Re: [PATCH] USB: OHCI: sm501: fix build failure after ohci_finish_controller_resume removal
On Tue, 23 Oct 2012, Florian Fainelli wrote: Commit cfa49b4b (USB: ohci: merge ohci_finish_controller_resume with ohci_resume) merged ohci_finish_controller_resume with ohci_resume but forgot to update the ohci-sm501 driver accordingly, thus causing the folllowing build failure: drivers/usb/host/ohci-sm501.c: In function 'ohci_sm501_resume': drivers/usb/host/ohci-sm501.c:241:2: error: implicit declaration of function 'ohci_finish_controller_resume' [-Werror=implicit-function-declaration] Reported-by: Fengguang Wu fengguang...@intel.com Signed-off-by: Florian Fainelli flor...@openwrt.org Acked-by: Alan Stern st...@rowland.harvard.edu I didn't check for this sort of thing while reviewing the patches originally... 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
During xHC Initialization (device is not connected), when HC-RESET is asserted, software is not expecting WRC or PRC bit set
Hi, Whenever, software asserts, HC resets during xHCI initialization, host controller is setting PRC and CSC (one of the version of host controller sets WRC bit also). However, there is no handling of these bits in xHCI software. 1. At Initialization - device is NOT connected and due to HC RESET, is there any following bits should be SET HIGH or not? - PRC / WRC / CSC bit 2. At Initialization - device is CONNECTED and due to HC RESET, is there any following bits should be SET HIGH or not? - PRC / WRC / CSC bit I appreciate your valuable inputs. Thanks Regards, Ankit A. Patel -- 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: During xHC Initialization (device is not connected), when HC-RESET is asserted, software is not expecting WRC or PRC bit set
On Tue, 23 Oct 2012, Ankit Patel wrote: Hi, Whenever, software asserts, HC resets during xHCI initialization, host controller is setting PRC and CSC (one of the version of host controller sets WRC bit also). However, there is no handling of these bits in xHCI software. What do you mean there's no handling of these bits in the driver? Take a look at xhci-hub.c:xhci_clear_port_change_bit(). 1. At Initialization - device is NOT connected and due to HC RESET, is there any following bits should be SET HIGH or not? - PRC / WRC / CSC bit 2. At Initialization - device is CONNECTED and due to HC RESET, is there any following bits should be SET HIGH or not? - PRC / WRC / CSC bit It shouldn't matter. Linux should be able to use the controller either way. 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
[PATCH RESEND 03/17] USB: whiteheat: fix memory leak in error path
Make sure command buffer is deallocated in case of errors during attach. Cc: supp...@connecttech.com Cc: sta...@vger.kernel.org Signed-off-by: Johan Hovold jhov...@gmail.com --- drivers/usb/serial/whiteheat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/serial/whiteheat.c b/drivers/usb/serial/whiteheat.c index 346c7ef..cfd155e 100644 --- a/drivers/usb/serial/whiteheat.c +++ b/drivers/usb/serial/whiteheat.c @@ -333,6 +333,7 @@ no_firmware: %s: please contact supp...@connecttech.com\n, serial-type-description); kfree(result); + kfree(command); return -ENODEV; no_command_private: -- 1.7.12.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 00/17] USB: serial: fixes for v3.7
Here are some more fixes against v3.7-rc2. The first five USB: metro-usb: fix port-data memory leak USB: metro-usb: fix io after disconnect USB: whiteheat: fix memory leak in error path USB: whiteheat: fix port-data memory leak USB: ch341: fix port-data memory leak are simply resends to have all fixes in one thread. The digi_acceleport patch has been updated and should be used instead of the one submitted earlier (as was reported to that thread). The final eleven patches fix port-data memory leaks as well as other memory leaks and bugs I ran into while fixing the port-data issue. This leaves two more confirmed leaks in keyspan and mos7840. Patches are on the way... Please help out with testing these patches on actual hardware if you have it. Thanks, Johan Johan Hovold (17): USB: metro-usb: fix port-data memory leak USB: metro-usb: fix io after disconnect USB: whiteheat: fix memory leak in error path USB: whiteheat: fix port-data memory leak USB: ch341: fix port-data memory leak USB: digi_acceleport: fix port-data memory leak USB: mos7720: fix port-data memory leak USB: omninet: fix port-data memory leak USB: quatech2: fix memory leak in error path USB: quatech2: fix port-data memory leaks USB: opticon: fix DMA from stack USB: opticon: fix memory leak in error path USB: sierra: fix port-data memory leaks USB: mct_u232: fix port-data memory leak USB: mct_u232: fix broken close USB: quatech2: fix close and disconnect urb handling USB: quatech2: fix io after disconnect drivers/usb/serial/ch341.c | 23 -- drivers/usb/serial/digi_acceleport.c | 117 +- drivers/usb/serial/mct_u232.c| 59 --- drivers/usb/serial/metro-usb.c | 65 + drivers/usb/serial/mos7720.c | 62 drivers/usb/serial/omninet.c | 36 +- drivers/usb/serial/opticon.c | 11 ++- drivers/usb/serial/quatech2.c| 135 --- drivers/usb/serial/sierra.c | 112 + drivers/usb/serial/whiteheat.c | 60 +++- 10 files changed, 333 insertions(+), 347 deletions(-) -- 1.7.12.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 RESEND 02/17] USB: metro-usb: fix io after disconnect
Make sure no control urb is submitted during close after a disconnect by
checking the disconnected flag.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/metro-usb.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/serial/metro-usb.c b/drivers/usb/serial/metro-usb.c
index 25cb97c..6f29c74 100644
--- a/drivers/usb/serial/metro-usb.c
+++ b/drivers/usb/serial/metro-usb.c
@@ -179,16 +179,13 @@ static void metrousb_cleanup(struct usb_serial_port *port)
{
dev_dbg(port-dev, %s\n, __func__);
- if (port-serial-dev) {
- /* Shutdown any interrupt in urbs. */
- if (port-interrupt_in_urb) {
- usb_unlink_urb(port-interrupt_in_urb);
- usb_kill_urb(port-interrupt_in_urb);
- }
-
- /* Send deactivate cmd to device */
+ usb_unlink_urb(port-interrupt_in_urb);
+ usb_kill_urb(port-interrupt_in_urb);
+
+ mutex_lock(port-serial-disc_mutex);
+ if (!port-serial-disconnected)
metrousb_send_unidirectional_cmd(UNI_CMD_CLOSE, port);
- }
+ mutex_unlock(port-serial-disc_mutex);
}
static int metrousb_open(struct tty_struct *tty, struct usb_serial_port *port)
--
1.7.12.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 08/17] USB: omninet: fix port-data memory leak
Fix port-data memory leak by replacing attach and release with
port_probe and port_remove.
Since commit 0998d0631001288 (device-core: Ensure drvdata = NULL when no
driver is bound) the port private data is no longer freed at release as
it is no longer accessible.
Compile-only tested.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/omninet.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/serial/omninet.c b/drivers/usb/serial/omninet.c
index 6def58b..9ab73d2 100644
--- a/drivers/usb/serial/omninet.c
+++ b/drivers/usb/serial/omninet.c
@@ -44,8 +44,8 @@ static int omninet_write(struct tty_struct *tty, struct
usb_serial_port *port,
const unsigned char *buf, int count);
static int omninet_write_room(struct tty_struct *tty);
static void omninet_disconnect(struct usb_serial *serial);
-static void omninet_release(struct usb_serial *serial);
-static int omninet_attach(struct usb_serial *serial);
+static int omninet_port_probe(struct usb_serial_port *port);
+static int omninet_port_remove(struct usb_serial_port *port);
static const struct usb_device_id id_table[] = {
{ USB_DEVICE(ZYXEL_VENDOR_ID, ZYXEL_OMNINET_ID) },
@@ -62,7 +62,8 @@ static struct usb_serial_driver zyxel_omninet_device = {
.description = ZyXEL - omni.net lcd plus usb,
.id_table = id_table,
.num_ports =1,
- .attach = omninet_attach,
+ .port_probe = omninet_port_probe,
+ .port_remove = omninet_port_remove,
.open = omninet_open,
.close =omninet_close,
.write =omninet_write,
@@ -70,7 +71,6 @@ static struct usb_serial_driver zyxel_omninet_device = {
.read_bulk_callback = omninet_read_bulk_callback,
.write_bulk_callback = omninet_write_bulk_callback,
.disconnect = omninet_disconnect,
- .release = omninet_release,
};
static struct usb_serial_driver * const serial_drivers[] = {
@@ -112,18 +112,26 @@ struct omninet_data {
__u8od_outseq; /* Sequence number for bulk_out URBs */
};
-static int omninet_attach(struct usb_serial *serial)
+static int omninet_port_probe(struct usb_serial_port *port)
{
struct omninet_data *od;
- struct usb_serial_port *port = serial-port[0];
od = kmalloc(sizeof(struct omninet_data), GFP_KERNEL);
- if (!od) {
- dev_err(port-dev, %s- kmalloc(%Zd) failed.\n,
- __func__, sizeof(struct omninet_data));
+ if (!od)
return -ENOMEM;
- }
+
usb_set_serial_port_data(port, od);
+
+ return 0;
+}
+
+static int omninet_port_remove(struct usb_serial_port *port)
+{
+ struct omninet_data *od;
+
+ od = usb_get_serial_port_data(port);
+ kfree(od);
+
return 0;
}
@@ -279,14 +287,6 @@ static void omninet_disconnect(struct usb_serial *serial)
usb_kill_urb(wport-write_urb);
}
-
-static void omninet_release(struct usb_serial *serial)
-{
- struct usb_serial_port *port = serial-port[0];
-
- kfree(usb_get_serial_port_data(port));
-}
-
module_usb_serial_driver(serial_drivers, id_table);
MODULE_AUTHOR(DRIVER_AUTHOR);
--
1.7.12.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 11/17] USB: opticon: fix DMA from stack
Make sure to allocate the control-message buffer dynamically as some
platforms cannot do DMA from stack.
Note that only the first byte of the old buffer was used.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/opticon.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/opticon.c b/drivers/usb/serial/opticon.c
index 41b1647..459c288 100644
--- a/drivers/usb/serial/opticon.c
+++ b/drivers/usb/serial/opticon.c
@@ -155,7 +155,11 @@ static int send_control_msg(struct usb_serial_port *port,
u8 requesttype,
{
struct usb_serial *serial = port-serial;
int retval;
- u8 buffer[2];
+ u8 *buffer;
+
+ buffer = kzalloc(1, GFP_KERNEL);
+ if (!buffer)
+ return -ENOMEM;
buffer[0] = val;
/* Send the message to the vendor control endpoint
@@ -164,6 +168,7 @@ static int send_control_msg(struct usb_serial_port *port,
u8 requesttype,
requesttype,
USB_DIR_OUT|USB_TYPE_VENDOR|USB_RECIP_INTERFACE,
0, 0, buffer, 1, 0);
+ kfree(buffer);
return retval;
}
--
1.7.12.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 13/17] USB: sierra: fix port-data memory leaks
Fix port-data memory leak by moving port data allocation and
deallocation to port_probe and port_remove.
Since commit 0998d0631001288 (device-core: Ensure drvdata = NULL when no
driver is bound) the port private data is no longer freed at release as
it is no longer accessible.
Note that this patch also fixes a second port-data memory leak in the
error path of attach should port data allocation fail for any port but
the first.
Note also that urb-count for multi-port interfaces has not been changed
even though the usb-serial port number is now determined from the port
and interface minor numbers.
Compile-only tested.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/sierra.c | 112
1 file changed, 51 insertions(+), 61 deletions(-)
diff --git a/drivers/usb/serial/sierra.c b/drivers/usb/serial/sierra.c
index 01d882c..598e996 100644
--- a/drivers/usb/serial/sierra.c
+++ b/drivers/usb/serial/sierra.c
@@ -884,12 +884,6 @@ static void sierra_dtr_rts(struct usb_serial_port *port,
int on)
static int sierra_startup(struct usb_serial *serial)
{
- struct usb_serial_port *port;
- struct sierra_port_private *portdata;
- struct sierra_iface_info *himemoryp = NULL;
- int i;
- u8 ifnum;
-
/* Set Device mode to D0 */
sierra_set_power_state(serial-dev, 0x);
@@ -897,68 +891,63 @@ static int sierra_startup(struct usb_serial *serial)
if (nmea)
sierra_vsc_set_nmea(serial-dev, 1);
- /* Now setup per port private data */
- for (i = 0; i serial-num_ports; i++) {
- port = serial-port[i];
- portdata = kzalloc(sizeof(*portdata), GFP_KERNEL);
- if (!portdata) {
- dev_dbg(port-dev, %s: kmalloc for
- sierra_port_private (%d) failed!\n,
- __func__, i);
- return -ENOMEM;
- }
- spin_lock_init(portdata-lock);
- init_usb_anchor(portdata-active);
- init_usb_anchor(portdata-delayed);
- ifnum = i;
- /* Assume low memory requirements */
- portdata-num_out_urbs = N_OUT_URB;
- portdata-num_in_urbs = N_IN_URB;
-
- /* Determine actual memory requirements */
- if (serial-num_ports == 1) {
- /* Get interface number for composite device */
- ifnum = sierra_calc_interface(serial);
- himemoryp =
- (struct sierra_iface_info *)typeB_interface_list;
- if (is_himemory(ifnum, himemoryp)) {
- portdata-num_out_urbs = N_OUT_URB_HM;
- portdata-num_in_urbs = N_IN_URB_HM;
- }
- }
- else {
- himemoryp =
- (struct sierra_iface_info *)typeA_interface_list;
- if (is_himemory(i, himemoryp)) {
- portdata-num_out_urbs = N_OUT_URB_HM;
- portdata-num_in_urbs = N_IN_URB_HM;
- }
- }
- dev_dbg(serial-dev-dev,
- Memory usage (urbs) interface #%d, in=%d, out=%d\n,
- ifnum,portdata-num_in_urbs, portdata-num_out_urbs );
- /* Set the port private data pointer */
- usb_set_serial_port_data(port, portdata);
+ return 0;
+}
+
+static int sierra_port_probe(struct usb_serial_port *port)
+{
+ struct usb_serial *serial = port-serial;
+ struct sierra_port_private *portdata;
+ const struct sierra_iface_info *himemoryp;
+ u8 ifnum;
+
+ portdata = kzalloc(sizeof(*portdata), GFP_KERNEL);
+ if (!portdata)
+ return -ENOMEM;
+
+ spin_lock_init(portdata-lock);
+ init_usb_anchor(portdata-active);
+ init_usb_anchor(portdata-delayed);
+
+ /* Assume low memory requirements */
+ portdata-num_out_urbs = N_OUT_URB;
+ portdata-num_in_urbs = N_IN_URB;
+
+ /* Determine actual memory requirements */
+ if (serial-num_ports == 1) {
+ /* Get interface number for composite device */
+ ifnum = sierra_calc_interface(serial);
+ himemoryp = typeB_interface_list;
+ } else {
+ /* This is really the usb-serial port number of the interface
+* rather than the interface number.
+*/
+ ifnum = port-number - serial-minor;
+ himemoryp = typeA_interface_list;
}
+ if (is_himemory(ifnum, himemoryp)) {
+ portdata-num_out_urbs = N_OUT_URB_HM;
+ portdata-num_in_urbs = N_IN_URB_HM;
+ }
+
+ dev_dbg(port-dev,
+
[PATCH 12/17] USB: opticon: fix memory leak in error path
Fix memory leak in write error path.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/opticon.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/opticon.c b/drivers/usb/serial/opticon.c
index 459c288..6aba731 100644
--- a/drivers/usb/serial/opticon.c
+++ b/drivers/usb/serial/opticon.c
@@ -286,7 +286,7 @@ static int opticon_write(struct tty_struct *tty, struct
usb_serial_port *port,
if (!dr) {
dev_err(port-dev, out of memory\n);
count = -ENOMEM;
- goto error;
+ goto error_no_dr;
}
dr-bRequestType = USB_TYPE_VENDOR | USB_RECIP_INTERFACE | USB_DIR_OUT;
@@ -316,6 +316,8 @@ static int opticon_write(struct tty_struct *tty, struct
usb_serial_port *port,
return count;
error:
+ kfree(dr);
+error_no_dr:
usb_free_urb(urb);
error_no_urb:
kfree(buffer);
--
1.7.12.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 RESEND 04/17] USB: whiteheat: fix port-data memory leak
Fix port-data memory leak by moving port data allocation and
deallocation to port_probe and port_remove.
Since commit 0998d0631001288 (device-core: Ensure drvdata = NULL when no
driver is bound) the port private data is no longer freed at release as
it is no longer accessible.
Note that the fifth port (command port) is never registered as a
port device and thus should be handled in attach and release.
Compile-only tested.
Cc: supp...@connecttech.com
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/whiteheat.c | 59 +++---
1 file changed, 26 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/serial/whiteheat.c b/drivers/usb/serial/whiteheat.c
index cfd155e..b9fca35 100644
--- a/drivers/usb/serial/whiteheat.c
+++ b/drivers/usb/serial/whiteheat.c
@@ -83,6 +83,8 @@ static int whiteheat_firmware_attach(struct usb_serial
*serial);
/* function prototypes for the Connect Tech WhiteHEAT serial converter */
static int whiteheat_attach(struct usb_serial *serial);
static void whiteheat_release(struct usb_serial *serial);
+static int whiteheat_port_probe(struct usb_serial_port *port);
+static int whiteheat_port_remove(struct usb_serial_port *port);
static int whiteheat_open(struct tty_struct *tty,
struct usb_serial_port *port);
static void whiteheat_close(struct usb_serial_port *port);
@@ -117,6 +119,8 @@ static struct usb_serial_driver whiteheat_device = {
.num_ports =4,
.attach = whiteheat_attach,
.release = whiteheat_release,
+ .port_probe = whiteheat_port_probe,
+ .port_remove = whiteheat_port_remove,
.open = whiteheat_open,
.close =whiteheat_close,
.ioctl =whiteheat_ioctl,
@@ -218,15 +222,12 @@ static int whiteheat_attach(struct usb_serial *serial)
{
struct usb_serial_port *command_port;
struct whiteheat_command_private *command_info;
- struct usb_serial_port *port;
- struct whiteheat_private *info;
struct whiteheat_hw_info *hw_info;
int pipe;
int ret;
int alen;
__u8 *command;
__u8 *result;
- int i;
command_port = serial-port[COMMAND_PORT];
@@ -285,22 +286,6 @@ static int whiteheat_attach(struct usb_serial *serial)
serial-type-description,
hw_info-sw_major_rev, hw_info-sw_minor_rev);
- for (i = 0; i serial-num_ports; i++) {
- port = serial-port[i];
-
- info = kmalloc(sizeof(struct whiteheat_private), GFP_KERNEL);
- if (info == NULL) {
- dev_err(port-dev,
- %s: Out of memory for port structures\n,
- serial-type-description);
- goto no_private;
- }
-
- info-mcr = 0;
-
- usb_set_serial_port_data(port, info);
- }
-
command_info = kmalloc(sizeof(struct whiteheat_command_private),
GFP_KERNEL);
if (command_info == NULL) {
@@ -337,13 +322,6 @@ no_firmware:
return -ENODEV;
no_command_private:
- for (i = serial-num_ports - 1; i = 0; i--) {
- port = serial-port[i];
- info = usb_get_serial_port_data(port);
- kfree(info);
-no_private:
- ;
- }
kfree(result);
no_result_buffer:
kfree(command);
@@ -351,21 +329,36 @@ no_command_buffer:
return -ENOMEM;
}
-
static void whiteheat_release(struct usb_serial *serial)
{
struct usb_serial_port *command_port;
- struct whiteheat_private *info;
- int i;
/* free up our private data for our command port */
command_port = serial-port[COMMAND_PORT];
kfree(usb_get_serial_port_data(command_port));
+}
- for (i = 0; i serial-num_ports; i++) {
- info = usb_get_serial_port_data(serial-port[i]);
- kfree(info);
- }
+static int whiteheat_port_probe(struct usb_serial_port *port)
+{
+ struct whiteheat_private *info;
+
+ info = kzalloc(sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ usb_set_serial_port_data(port, info);
+
+ return 0;
+}
+
+static int whiteheat_port_remove(struct usb_serial_port *port)
+{
+ struct whiteheat_private *info;
+
+ info = usb_get_serial_port_data(port);
+ kfree(info);
+
+ return 0;
}
static int whiteheat_open(struct tty_struct *tty, struct usb_serial_port *port)
--
1.7.12.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 09/17] USB: quatech2: fix memory leak in error path
Fix memory leak in attach error path where the read urb was never freed.
Cc: Bill Pemberton wf...@virginia.edu
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/quatech2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/quatech2.c b/drivers/usb/serial/quatech2.c
index 2cdfdcc..5adb742 100644
--- a/drivers/usb/serial/quatech2.c
+++ b/drivers/usb/serial/quatech2.c
@@ -823,6 +823,7 @@ static int qt2_setup_urbs(struct usb_serial *serial)
if (status != 0) {
dev_err(serial-dev-dev,
%s - submit read urb failed %i\n, __func__, status);
+ usb_free_urb(serial_priv-read_urb);
return status;
}
--
1.7.12.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 17/17] USB: quatech2: fix io after disconnect
Make sure no control urb is submitted during close after a disconnect by
checking the disconnected flag.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/quatech2.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/serial/quatech2.c b/drivers/usb/serial/quatech2.c
index 7e8d8f3..ffcfc96 100644
--- a/drivers/usb/serial/quatech2.c
+++ b/drivers/usb/serial/quatech2.c
@@ -427,6 +427,12 @@ static void qt2_close(struct usb_serial_port *port)
port_priv-urb_in_use = false;
spin_unlock_irqrestore(port_priv-urb_lock, flags);
+ mutex_lock(port-serial-disc_mutex);
+ if (port-serial-disconnected) {
+ mutex_unlock(port-serial-disc_mutex);
+ return;
+ }
+
/* flush the port transmit buffer */
i = usb_control_msg(serial-dev,
usb_rcvctrlpipe(serial-dev, 0),
@@ -458,6 +464,7 @@ static void qt2_close(struct usb_serial_port *port)
dev_err(port-dev, %s - close port failed %i\n,
__func__, i);
+ mutex_unlock(port-serial-disc_mutex);
}
static void qt2_disconnect(struct usb_serial *serial)
--
1.7.12.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 v2 06/17] USB: digi_acceleport: fix port-data memory leak
Fix port-data memory leak by moving port data allocation and
deallocation to port_probe and port_remove.
Since commit 0998d0631001288 (device-core: Ensure drvdata = NULL when no
driver is bound) the port private data is no longer freed at release as
it is no longer accessible.
Note that the oob port is never registered as a port device and should
thus be handled in attach and release.
Compile-only tested.
Cc: Peter Berger pber...@brimson.com
Cc: Al Borchers alborch...@steinerpoint.com
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/digi_acceleport.c | 117 ---
1 file changed, 67 insertions(+), 50 deletions(-)
diff --git a/drivers/usb/serial/digi_acceleport.c
b/drivers/usb/serial/digi_acceleport.c
index c86f68c..b50fa1c 100644
--- a/drivers/usb/serial/digi_acceleport.c
+++ b/drivers/usb/serial/digi_acceleport.c
@@ -244,6 +244,8 @@ static int digi_startup_device(struct usb_serial *serial);
static int digi_startup(struct usb_serial *serial);
static void digi_disconnect(struct usb_serial *serial);
static void digi_release(struct usb_serial *serial);
+static int digi_port_probe(struct usb_serial_port *port);
+static int digi_port_remove(struct usb_serial_port *port);
static void digi_read_bulk_callback(struct urb *urb);
static int digi_read_inb_callback(struct urb *urb);
static int digi_read_oob_callback(struct urb *urb);
@@ -294,6 +296,8 @@ static struct usb_serial_driver digi_acceleport_2_device = {
.attach = digi_startup,
.disconnect = digi_disconnect,
.release = digi_release,
+ .port_probe = digi_port_probe,
+ .port_remove = digi_port_remove,
};
static struct usb_serial_driver digi_acceleport_4_device = {
@@ -320,6 +324,8 @@ static struct usb_serial_driver digi_acceleport_4_device = {
.attach = digi_startup,
.disconnect = digi_disconnect,
.release = digi_release,
+ .port_probe = digi_port_probe,
+ .port_remove = digi_port_remove,
};
static struct usb_serial_driver * const serial_drivers[] = {
@@ -1240,59 +1246,50 @@ static int digi_startup_device(struct usb_serial
*serial)
return ret;
}
-
-static int digi_startup(struct usb_serial *serial)
+static int digi_port_init(struct usb_serial_port *port, unsigned port_num)
{
-
- int i;
struct digi_port *priv;
- struct digi_serial *serial_priv;
- /* allocate the private data structures for all ports */
- /* number of regular ports + 1 for the out-of-band port */
- for (i = 0; i serial-type-num_ports + 1; i++) {
- /* allocate port private structure */
- priv = kmalloc(sizeof(struct digi_port), GFP_KERNEL);
- if (priv == NULL) {
- while (--i = 0)
-
kfree(usb_get_serial_port_data(serial-port[i]));
- return 1; /* error */
- }
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
- /* initialize port private structure */
- spin_lock_init(priv-dp_port_lock);
- priv-dp_port_num = i;
- priv-dp_out_buf_len = 0;
- priv-dp_write_urb_in_use = 0;
- priv-dp_modem_signals = 0;
- init_waitqueue_head(priv-dp_modem_change_wait);
- priv-dp_transmit_idle = 0;
- init_waitqueue_head(priv-dp_transmit_idle_wait);
- priv-dp_throttled = 0;
- priv-dp_throttle_restart = 0;
- init_waitqueue_head(priv-dp_flush_wait);
- init_waitqueue_head(priv-dp_close_wait);
- INIT_WORK(priv-dp_wakeup_work, digi_wakeup_write_lock);
- priv-dp_port = serial-port[i];
- /* initialize write wait queue for this port */
- init_waitqueue_head(serial-port[i]-write_wait);
-
- usb_set_serial_port_data(serial-port[i], priv);
- }
+ spin_lock_init(priv-dp_port_lock);
+ priv-dp_port_num = port_num;
+ init_waitqueue_head(priv-dp_modem_change_wait);
+ init_waitqueue_head(priv-dp_transmit_idle_wait);
+ init_waitqueue_head(priv-dp_flush_wait);
+ init_waitqueue_head(priv-dp_close_wait);
+ INIT_WORK(priv-dp_wakeup_work, digi_wakeup_write_lock);
+ priv-dp_port = port;
- /* allocate serial private structure */
- serial_priv = kmalloc(sizeof(struct digi_serial), GFP_KERNEL);
- if (serial_priv == NULL) {
- for (i = 0; i serial-type-num_ports + 1; i++)
- kfree(usb_get_serial_port_data(serial-port[i]));
- return 1; /* error */
- }
[PATCH 14/17] USB: mct_u232: fix port-data memory leak
Fix port-data memory leak by moving port data allocation and
deallocation to port_probe and port_remove.
Since commit 0998d0631001288 (device-core: Ensure drvdata = NULL when no
driver is bound) the port private data is no longer freed at release as
it is no longer accessible.
Note that the write waitqueue was initialised but never used.
Compile-only tested.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/mct_u232.c | 45 ---
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/serial/mct_u232.c b/drivers/usb/serial/mct_u232.c
index f394771..a8bce13 100644
--- a/drivers/usb/serial/mct_u232.c
+++ b/drivers/usb/serial/mct_u232.c
@@ -49,7 +49,8 @@
* Function prototypes
*/
static int mct_u232_startup(struct usb_serial *serial);
-static void mct_u232_release(struct usb_serial *serial);
+static int mct_u232_port_probe(struct usb_serial_port *port);
+static int mct_u232_port_remove(struct usb_serial_port *remove);
static int mct_u232_open(struct tty_struct *tty, struct usb_serial_port
*port);
static void mct_u232_close(struct usb_serial_port *port);
static void mct_u232_dtr_rts(struct usb_serial_port *port, int on);
@@ -99,7 +100,8 @@ static struct usb_serial_driver mct_u232_device = {
.tiocmget = mct_u232_tiocmget,
.tiocmset = mct_u232_tiocmset,
.attach =mct_u232_startup,
- .release = mct_u232_release,
+ .port_probe =mct_u232_port_probe,
+ .port_remove = mct_u232_port_remove,
.ioctl = mct_u232_ioctl,
.get_icount =mct_u232_get_icount,
};
@@ -388,18 +390,8 @@ static void mct_u232_msr_to_state(struct usb_serial_port
*port,
static int mct_u232_startup(struct usb_serial *serial)
{
- struct mct_u232_private *priv;
struct usb_serial_port *port, *rport;
- priv = kzalloc(sizeof(struct mct_u232_private), GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
- spin_lock_init(priv-lock);
- init_waitqueue_head(priv-msr_wait);
- usb_set_serial_port_data(serial-port[0], priv);
-
- init_waitqueue_head(serial-port[0]-write_wait);
-
/* Puh, that's dirty */
port = serial-port[0];
rport = serial-port[1];
@@ -412,18 +404,31 @@ static int mct_u232_startup(struct usb_serial *serial)
return 0;
} /* mct_u232_startup */
+static int mct_u232_port_probe(struct usb_serial_port *port)
+{
+ struct mct_u232_private *priv;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
-static void mct_u232_release(struct usb_serial *serial)
+ spin_lock_init(priv-lock);
+ init_waitqueue_head(priv-msr_wait);
+
+ usb_set_serial_port_data(port, priv);
+
+ return 0;
+}
+
+static int mct_u232_port_remove(struct usb_serial_port *port)
{
struct mct_u232_private *priv;
- int i;
- for (i = 0; i serial-num_ports; ++i) {
- /* My special items, the standard routines free my urbs */
- priv = usb_get_serial_port_data(serial-port[i]);
- kfree(priv);
- }
-} /* mct_u232_release */
+ priv = usb_get_serial_port_data(port);
+ kfree(priv);
+
+ return 0;
+}
static int mct_u232_open(struct tty_struct *tty, struct usb_serial_port *port)
{
--
1.7.12.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: [PATCH v4 1/2] USB: check port changes before hub runtime suspend for some bug device
On Tue, Oct 23, 2012 at 10:15 PM, Alan Stern st...@rowland.harvard.edu wrote: + .idVendor = 0x05e3, Can you make this a symbolic constant (USB_VENDOR_GENESYS_LOGIC)? Or at least put a comment there? OK, will do it in v5. Thanks, -- Ming Lei -- 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 03/32 v4] MIPS: Loongson 1B: use ehci-platform instead of ehci-ls1x.
On Tuesday 23 October 2012 10:20:15 Alan Stern wrote: On Tue, 23 Oct 2012, Florian Fainelli wrote: Hi Kelvin, On Tuesday 23 October 2012 16:13:01 Kelvin Cheung wrote: Thank Florian. It looks great. However, you forget to remove corresponding section in drivers/usb/host/ehci-hcd.c ... #ifdef CONFIG_MACH_LOONGSON1 #include ehci-ls1x.c #define PLATFORM_DRIVER ehci_ls1x_driver #endif Indeed, my bad I will follow up with some fixes for this patchset anyway. Thank you! Speaking of followups... Have you checked to see whether any of these changes should affect the definitions of CONFIG_USB_EHCI_BIG_ENDIAN_MMIO and CONFIG_USB_EHCI_BIG_ENDIAN_DESC (and likewise for OHCI)? Are they still getting set whenever they are needed? Yes I checked the defconfigs to see whether they selected these options, and also I kept, when existing the original CONFIG symbol, so that one would also select these two options if needed. We should be ok from what I checked. -- Florian -- 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 v2 2/2] USB: doc: Binding document for ehci-platform driver
On 10/23/2012 08:10 AM, Alan Stern wrote: On Mon, 22 Oct 2012, Stephen Warren wrote: I see. But why would it be done this way instead having a separate property? Well, I did say normally:-) I can certainly see an argument for representing these differences using custom properties, rather than deriving the information from the compatible value. It's probably be OK to do so for something generic like this; it's just perhaps not always the default choice. Do note that even though this binding document dictates a particular value for the compatible property, every device tree should additionally add a separate value alongside it to indicate the specific HW model that's actually present, so that if some device-specific bug-fix or workaround needs to be applied, the model can be identified anyway. So, rather than: compatible = usb-ehci; You should always have e.g.: compatible = nvidia,tegra20-ehci, usb-ehci; Given that, there is then always enough information in the device tree for the driver to be able to derive the other values from the compatible value. Yes, I get it. Whether you want to derive the information, or whether you want to explicitly represent it via properties, is a decision to make based on the trade-offs. Oh, and I note that quite a few device trees already use compatible value usb-ehci in their device-trees. Care needs to be taken not to usurp that value from any existing device drivers if that was to be picked as the compatible value required by this binding. Right. I think Tony's new binding should use compatible value usb-ehci-platform. It will essentially be a superset of usb-ehci. I know this is bike-shedding a little bit, but... The word platform isn't really about describing the HW, but rather is derived from the Linux SW used to program that HW. DT should be purely about describing the HW. Perhaps usb-ehci-generic or usb-ehci-simple would be better? -- 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 v1 00/11] usbnet: usb_control_msg cleanup
From: Ming Lei ming@canonical.com Date: Tue, 23 Oct 2012 17:19:29 +0800 On Mon, Oct 15, 2012 at 2:30 PM, Oliver Neukum oneu...@suse.de wrote: v1: - drop previous patch 12, and let net/core handle runtime PM in ioctl path Acked-by: Oliver Neukum oneu...@suse.de David, could you queue the patchset on net-next since my some usbnet runtime PM patches depend on it? Please repost it to netdev. -- 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] keyspan: fix NULL-pointer dereferences and memory leaks
Fix NULL-pointer dereference at release by moving port data allocation
and deallocation to port_probe and port_remove.
Fix NULL-pointer dereference at disconnect by stopping port urbs at
port_remove.
Since commit 0998d0631001288 (device-core: Ensure drvdata = NULL when no
driver is bound) the port private data is no longer accessible at
disconnect or release.
Note that this patch also fixes port and interface-data memory leaks in
the error path of attach should port initialisation fail for any port.
Compile-only tested.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
As the patch description says, this fixes a few hairy bugs in keyspan. Since
the patch is so intrusive, it really should get some testing by someone with
actual hardware.
But then again, in it's current state, the driver will oops at disconnect or
module reload.
Johan
drivers/usb/serial/keyspan.c | 181 +--
drivers/usb/serial/keyspan.h | 8 ++
2 files changed, 96 insertions(+), 93 deletions(-)
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index 29c943d..7179b0c 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -1374,13 +1374,9 @@ static struct callbacks {
data in device_details */
static void keyspan_setup_urbs(struct usb_serial *serial)
{
- int i, j;
struct keyspan_serial_private *s_priv;
const struct keyspan_device_details *d_details;
- struct usb_serial_port *port;
- struct keyspan_port_private *p_priv;
struct callbacks*cback;
- int endp;
s_priv = usb_get_serial_data(serial);
d_details = s_priv-device_details;
@@ -1404,45 +1400,6 @@ static void keyspan_setup_urbs(struct usb_serial *serial)
(serial, d_details-glocont_endpoint, USB_DIR_OUT,
serial, s_priv-glocont_buf, GLOCONT_BUFLEN,
cback-glocont_callback);
-
- /* Setup endpoints for each port specific thing */
- for (i = 0; i d_details-num_ports; i++) {
- port = serial-port[i];
- p_priv = usb_get_serial_port_data(port);
-
- /* Do indat endpoints first, once for each flip */
- endp = d_details-indat_endpoints[i];
- for (j = 0; j = d_details-indat_endp_flip; ++j, ++endp) {
- p_priv-in_urbs[j] = keyspan_setup_urb
- (serial, endp, USB_DIR_IN, port,
-p_priv-in_buffer[j], 64,
-cback-indat_callback);
- }
- for (; j 2; ++j)
- p_priv-in_urbs[j] = NULL;
-
- /* outdat endpoints also have flip */
- endp = d_details-outdat_endpoints[i];
- for (j = 0; j = d_details-outdat_endp_flip; ++j, ++endp) {
- p_priv-out_urbs[j] = keyspan_setup_urb
- (serial, endp, USB_DIR_OUT, port,
-p_priv-out_buffer[j], 64,
-cback-outdat_callback);
- }
- for (; j 2; ++j)
- p_priv-out_urbs[j] = NULL;
-
- /* inack endpoint */
- p_priv-inack_urb = keyspan_setup_urb
- (serial, d_details-inack_endpoints[i], USB_DIR_IN,
-port, p_priv-inack_buffer, 1, cback-inack_callback);
-
- /* outcont endpoint */
- p_priv-outcont_urb = keyspan_setup_urb
- (serial, d_details-outcont_endpoints[i], USB_DIR_OUT,
-port, p_priv-outcont_buffer, 64,
-cback-outcont_callback);
- }
}
/* usa19 function doesn't require prescaler */
@@ -2407,9 +2364,7 @@ static void keyspan_send_setup(struct usb_serial_port
*port, int reset_port)
static int keyspan_startup(struct usb_serial *serial)
{
int i, err;
- struct usb_serial_port *port;
struct keyspan_serial_private *s_priv;
- struct keyspan_port_private *p_priv;
const struct keyspan_device_details *d_details;
for (i = 0; (d_details = keyspan_devices[i]) != NULL; ++i)
@@ -2432,19 +2387,6 @@ static int keyspan_startup(struct usb_serial *serial)
s_priv-device_details = d_details;
usb_set_serial_data(serial, s_priv);
- /* Now setup per port private data */
- for (i = 0; i serial-num_ports; i++) {
- port = serial-port[i];
- p_priv = kzalloc(sizeof(struct keyspan_port_private),
- GFP_KERNEL);
- if (!p_priv) {
- dev_dbg(port-dev, %s - kmalloc for
keyspan_port_private (%d) failed!.\n, __func__,
Re: [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
On Tue, 23 Oct 2012, Stephen Warren wrote: So, rather than: compatible = usb-ehci; You should always have e.g.: compatible = nvidia,tegra20-ehci, usb-ehci; Given that, there is then always enough information in the device tree for the driver to be able to derive the other values from the compatible value. Yes, I get it. Whether you want to derive the information, or whether you want to explicitly represent it via properties, is a decision to make based on the trade-offs. Oh, and I note that quite a few device trees already use compatible value usb-ehci in their device-trees. Care needs to be taken not to usurp that value from any existing device drivers if that was to be picked as the compatible value required by this binding. Right. I think Tony's new binding should use compatible value usb-ehci-platform. It will essentially be a superset of usb-ehci. I know this is bike-shedding a little bit, but... The word platform isn't really about describing the HW, but rather is derived from the Linux SW used to program that HW. DT should be purely about describing the HW. Perhaps usb-ehci-generic or usb-ehci-simple would be better? Neither of those really describes the hardware either. Which name gets used seems pretty arbitrary. Nothing intrinsically distinguishes this class of hardware. The only thing these devices have in common is that they can be managed by Linux's ehci-platform driver. For that purpose, usb-ehci-platform makes more sense than usb-ehci-generic or usb-ehci-simple. (It also allows the class to enlarge over time as the driver becomes more capable -- is that a bad thing? Are DT board descriptions written for a later kernel supposed to be unusable with an earlier kernel that doesn't support the same features?) In essense, we're trying to say that the HW is compatible with a particular driver rather than with some other type of HW. Maybe DT wasn't intended to provide this kind of information, but it seems like a logical thing to do. Unless DT already offers some other way to accomplish the same thing? 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: [RFC PATCH v2 2/6] PM / Runtime: introduce pm_runtime_set_memalloc_noio()
On Tue, 23 Oct 2012, Ming Lei wrote: With the problem of non-SMP-safe bitfields access, the power.lock should be held, but that is not enough to prevent children from being probed or disconnected. Looks another lock is still needed. I think a global lock is OK in the infrequent path. Agreed. Got it, thanks for your detailed explanation. Looks the problem is worse than above, not only bitfields are affected, the adjacent fields might be involved too, see: http://lwn.net/Articles/478657/ Linus made it clear (in various emails at the time) that the kernel requires the compiler not to do the sort of things discussed in that article. But even the restrictions he wanted would not prevent adjacent bitfields from interfering with each other. 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 v2 2/2] USB: doc: Binding document for ehci-platform driver
On Tue, 23 Oct 2012, Stephen Warren wrote: Nothing intrinsically distinguishes this class of hardware. The only thing these devices have in common is that they can be managed by Linux's ehci-platform driver. I don't agree. They're all EHCI USB controllers (or all EHCI USB controllers that don't require custom drivers due to quirks), which is a much more general statement than anything related to which driver Linux uses for them. That's true, but it doesn't distinguish these devices. There are other EHCI controllers with no quirks that nevertheless can't be handled by ehci-platform because they have requirements (_not_ quirks) that ehci-platform is unable to deal with currently -- clocks or power supplies or special register settings or PHYs or etc. In essense, we're trying to say that the HW is compatible with a particular driver rather than with some other type of HW. Using a compatible value in order to pick a specific driver in Linux is explicitly against the device tree design principles; DT is supposed to represent just the hardware. Maybe DT wasn't intended to provide this kind of information, but it seems like a logical thing to do. Unless DT already offers some other way to accomplish the same thing? The typical way is for the Linux driver to declare that is supports a variety of different HW models. Admittedly this is annoying when there are many HW models that otherwise wouldn't need any driver changes, hence the desire to (additionally) include some generic value in the compatible field, but again, what that generic value is should be driven by the HW itself, not the SW that's using it. Okay, fine. But then what should the binding documentation specify for the compatible value? A list of all the HW models that the driver currently supports? 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 v2 2/2] USB: doc: Binding document for ehci-platform driver
On 10/23/2012 02:33 PM, Alan Stern wrote: On Tue, 23 Oct 2012, Stephen Warren wrote: Nothing intrinsically distinguishes this class of hardware. The only thing these devices have in common is that they can be managed by Linux's ehci-platform driver. I don't agree. They're all EHCI USB controllers (or all EHCI USB controllers that don't require custom drivers due to quirks), which is a much more general statement than anything related to which driver Linux uses for them. That's true, but it doesn't distinguish these devices. There are other EHCI controllers with no quirks that nevertheless can't be handled by ehci-platform because they have requirements (_not_ quirks) that ehci-platform is unable to deal with currently -- clocks or power supplies or special register settings or PHYs or etc. But what if the h/w has quirks you haven't yet discovered? You need the compatible property to be specific now, so if there are any future driver changes needed the DT does not have to change (as it may be in firmware which you can't change). In essense, we're trying to say that the HW is compatible with a particular driver rather than with some other type of HW. Using a compatible value in order to pick a specific driver in Linux is explicitly against the device tree design principles; DT is supposed to represent just the hardware. Maybe DT wasn't intended to provide this kind of information, but it seems like a logical thing to do. Unless DT already offers some other way to accomplish the same thing? The typical way is for the Linux driver to declare that is supports a variety of different HW models. Admittedly this is annoying when there are many HW models that otherwise wouldn't need any driver changes, hence the desire to (additionally) include some generic value in the compatible field, but again, what that generic value is should be driven by the HW itself, not the SW that's using it. Okay, fine. But then what should the binding documentation specify for the compatible value? A list of all the HW models that the driver currently supports? The binding docs should be independent of the driver. There may be fields the driver ignores. So you need to document all defined compatible strings. It is fine if the driver only has usb-ehci, but it is not fine for the DT to only have that. Rob -- 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
[Pull Request] xHCI bug fixes for 3.7-rc3
The following changes since commit 3b6054da68f9b0d5ed6a7ed0f42a79e61904352c: usb hub: send clear_tt_buffer_complete events when canceling TT clear work (2012-10-22 11:34:41 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-linus-2012-10-23 for you to fetch changes up to 16b45fdf9c4e82f5d3bc53aa70737650e7c8d5ed: xhci: fix integer overflow (2012-10-23 15:43:38 -0700) xHCI fixes for 3.7-rc3 Hi Greg, Here's four bug fixes for 3.7. The first patch fixes a potential deadlock in the USB port power off code, and the last two patches fix bugs in the USB 3.0 Link PM patchset. The second one is trivial and removes an unnecessary cast. Sarah Sharp Lan Tianyu (2): usb/xhci: release xhci-lock during turning on/off usb port's acpi power resource and checking the existence of port's power resource usb/xhci: Remove (__force__ __u16) before assigning DeviceRemovable and assign directly. Oliver Neukum (2): xhci: endianness xhci_calculate_intel_u2_timeout xhci: fix integer overflow drivers/usb/host/xhci-hub.c |9 ++--- drivers/usb/host/xhci.c |4 ++-- 2 files changed, 8 insertions(+), 5 deletions(-) -- 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 3/4] xhci: endianness xhci_calculate_intel_u2_timeout
From: Oliver Neukum oli...@neukum.org An le16 is accessed without conversion. This patch should be backported to kernels as old as 3.5, that contain the commit e3567d2c15a7a8e2f992a5f7c7683453ca406d82 xhci: Add Intel U1/U2 timeout policy. Signed-off-by: Oliver Neukum oneu...@suse.de Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com CC: sta...@vger.kernel.org --- drivers/usb/host/xhci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 7d462bf..8d3c454 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4142,7 +4142,7 @@ static u16 xhci_calculate_intel_u2_timeout(struct usb_device *udev, (xhci_service_interval_to_ns(desc) timeout_ns)) timeout_ns = xhci_service_interval_to_ns(desc); - u2_del_ns = udev-bos-ss_cap-bU2DevExitLat * 1000; + u2_del_ns = le16_to_cpu(udev-bos-ss_cap-bU2DevExitLat) * 1000ULL; if (u2_del_ns timeout_ns) timeout_ns = u2_del_ns; -- 1.7.9 -- 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 2/4] usb/xhci: Remove (__force__ __u16) before assigning DeviceRemovable and assign directly.
From: Lan Tianyu tianyu@intel.com Struct usb_hub_descriptor.ss.DeviceRemovable has been defined as __le16 and (__force__ __u16) doesn't need. Signed-off-by: Lan Tianyu tianyu@intel.com Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com --- drivers/usb/host/xhci-hub.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index 65d416c..a686cf4 100644 --- a/drivers/usb/host/xhci-hub.c +++ b/drivers/usb/host/xhci-hub.c @@ -151,9 +151,8 @@ static void xhci_usb3_hub_descriptor(struct usb_hcd *hcd, struct xhci_hcd *xhci, if (portsc PORT_DEV_REMOVE) port_removable |= 1 (i + 1); } - memset(desc-u.ss.DeviceRemovable, - (__force __u16) cpu_to_le16(port_removable), - sizeof(__u16)); + + desc-u.ss.DeviceRemovable = cpu_to_le16(port_removable); } static void xhci_hub_descriptor(struct usb_hcd *hcd, struct xhci_hcd *xhci, -- 1.7.9 -- 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 2/4] xhci: Fix missing break in xhci_evaluate_context_result.
Coverity complains that xhci_evaluate_context_result() is missing a break statement after the COMP_EBADSLT switch case. It's not a big deal, since we wanted to return the same error code as the case statement below it does. The end result would be one that a Slot Disabled error completion code would also print the warning message associated with a Context State error code. No other bad behavior would result. It's not worth backporting to stable kernels, since it only fixes an issue with too much debugging. Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com --- drivers/usb/host/xhci.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 9ec9396..ffe2e2e 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -1817,6 +1817,8 @@ static int xhci_evaluate_context_result(struct xhci_hcd *xhci, case COMP_EBADSLT: dev_warn(udev-dev, WARN: slot not enabled for evaluate context command.\n); + ret = -EINVAL; + break; case COMP_CTX_STATE: dev_warn(udev-dev, WARN: invalid context state for evaluate context command.\n); -- 1.7.9 -- 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 3/4] xhci: trivial: Remove assigned but unused slot_ctx.
Remove the variable slot_ctx from xhci_dbg_ctx(), since it is assigned but unused. Caught by Coverity. Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com --- drivers/usb/host/xhci-dbg.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c index 4b436f5..5f3a7c7 100644 --- a/drivers/usb/host/xhci-dbg.c +++ b/drivers/usb/host/xhci-dbg.c @@ -544,7 +544,6 @@ void xhci_dbg_ctx(struct xhci_hcd *xhci, int i; /* Fields are 32 bits wide, DMA addresses are in bytes */ int field_size = 32 / 8; - struct xhci_slot_ctx *slot_ctx; dma_addr_t dma = ctx-dma; int csz = HCC_64BYTE_CONTEXT(xhci-hcc_params); @@ -570,7 +569,6 @@ void xhci_dbg_ctx(struct xhci_hcd *xhci, dbg_rsvd64(xhci, (u64 *)ctrl_ctx, dma); } - slot_ctx = xhci_get_slot_ctx(xhci, ctx); xhci_dbg_slot_ctx(xhci, ctx); xhci_dbg_ep_ctx(xhci, ctx, last_ep); } -- 1.7.9 -- 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: [GIT PULL] USB fixes for v3.7-rc3
On Tue, Oct 23, 2012 at 10:35:54AM +0300, Felipe Balbi wrote: Hi Greg, here's my second set of fixes for v3.7-rc cycle. Let me know if you want any changes. cheers The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.7-rc3 Pulled and pushed out. thanks, greg k-h -- 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: [Pull Request] xHCI bug fixes for 3.7-rc3
On Tue, Oct 23, 2012 at 03:53:26PM -0700, Sarah Sharp wrote: The following changes since commit 3b6054da68f9b0d5ed6a7ed0f42a79e61904352c: usb hub: send clear_tt_buffer_complete events when canceling TT clear work (2012-10-22 11:34:41 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-linus-2012-10-23 Pulled and pushed out. thanks, greg k-h -- 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 v5 0/2] USB: USB: two changes on hub autosuspend
There are two patches on usb hub autosuspend. Change log: V5: - convert a symbolic constant into macro as suggested by Alan V4: - rebase on 3.7-rc2-next-20121022 V3: - don't stop suspend for !PMSG_IS_AUTO() case(1/2) - remove one unnecessary check on device_may_wakeup()(1/2) V2: - check on udev-do_remote_wakeup(1/2) - handle wakeup source for system sleep(1/2) - remove unnecessary comments(2/2) - fix comments(2/2) V1: - only check ports change on bug devices(1/2) - add comments on waking up hub by usb space context(2/2) drivers/usb/core/hub.c | 73 1 file changed, 73 insertions(+) Thanks, -- Ming Lei -- 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
