Re: [PATCH] MAINTAINERS: drop two usb-serial subdriver entries
On Sun, Jun 01, 2014 at 10:45:59AM -0700, Greg Kroah-Hartman wrote: On Sun, Jun 01, 2014 at 11:32:17AM +0200, Johan Hovold wrote: Remove the remaining two obsolete usb-serial subdriver entries from MAINTAINERS, which were missed in the recent purge by commit f896b7968b62 (USB: Maintainers change for usb serial drivers). Signed-off-by: Johan Hovold jhov...@gmail.com --- MAINTAINERS | 12 1 file changed, 12 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 51ebb779c5f3..68599b26f514 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9298,12 +9298,6 @@ S: Maintained F: drivers/usb/host/isp116x* F: include/linux/usb/isp116x.h -USB KAWASAKI LSI DRIVER -M: Oliver Neukum oli...@neukum.org -L: linux-usb@vger.kernel.org -S: Maintained -F: drivers/usb/serial/kl5kusb105.* - USB MASS STORAGE DRIVER M: Matthew Dharm mdharm-...@one-eyed-alien.net L: linux-usb@vger.kernel.org @@ -9331,12 +9325,6 @@ S: Maintained F: Documentation/usb/ohci.txt F: drivers/usb/host/ohci* -USB OPTION-CARD DRIVER -M: Matthias Urlichs sm...@smurf.noris.de -L: linux-usb@vger.kernel.org -S: Maintained -F: drivers/usb/serial/option.c Why are we taking away the maintainership of these individual drivers from these developers? I had no problem giving you the drivers I was supposed to be in charge of, but I need a signed-off-by from Matthias and Oliver for these if they want to do the same. I honestly thought you had just missed these entries when you removed individual maintainership for the other usb-serial drivers with the motivation that the developers were not around and that maintainership for individual drivers did not make much sense anymore (as consolidation proceeds, I read). (These two entries were also not grouped with the others.) Oliver and perhaps also Mathias are still around, but the option driver is now down to about 200 LOC (including boilerplate) when not counting the id table, while the kl5kusb105 is currently at about 400 LOC (including boilerplate) since I converted it to use the generic implementation a few years ago. Oliver and Mathias, what do you think of this? Would you be willing to sign off on this patch? 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] MAINTAINERS: drop two usb-serial subdriver entries
Hi, Johan Hovold: -USB OPTION-CARD DRIVER -M: Matthias Urlichs sm...@smurf.noris.de -L: linux-usb@vger.kernel.org -S: Maintained -F: drivers/usb/serial/option.c Why are we taking away the maintainership of these individual drivers from these developers? I had no problem giving you the drivers I was supposed to be in charge of, but I need a signed-off-by from Matthias and Oliver for these if they want to do the same. I honestly thought you had just missed these entries when you removed individual maintainership for the other usb-serial drivers with the motivation that the developers were not around and that maintainership for individual drivers did not make much sense anymore (as consolidation proceeds, I read). (These two entries were also not grouped with the others.) Oliver and perhaps also Mathias are still around, but the option driver is now down to about 200 LOC (including boilerplate) when not counting the id table, while the kl5kusb105 is currently at about 400 LOC (including boilerplate) since I converted it to use the generic implementation a few years ago. Oliver and Mathias, what do you think of this? Would you be willing to sign off on this patch? Fine by me. While I am indeed still around, Option doesn't need a maintainer any more -- the thing just works, and I do not see any need for driver-specific changes other than additions to the ID table. You hardly need a maintainer for that. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: [PATCH] usb: dwc3: add support for USB 2.0-only core configuration
On 5/31/2014 5:35 AM, Paul Zimmerman wrote: From: Felipe Balbi [mailto:ba...@ti.com] Sent: Friday, May 30, 2014 4:42 PM On Fri, May 23, 2014 at 11:39:24AM -0700, Paul Zimmerman wrote: Newer DWC3 controllers can be built for USB 2.0-only mode, where most of the USB 3.0 circuitry is left out. To support this mode, the driver must limit the speed programmed into the DCFG register to Hi-Speed or lower. Reads and writes to the PIPECTL register are left as-is, since they should be no-ops in USB 2.0-only mode. Calls to phy_init() etc. for the USB3 phy are also left as-is, since the no-op USB3 phy should be used for USB 2.0-only mode controllers. Signed-off-by: Paul Zimmerman pa...@synopsys.com --- Hi Felipe, Does this look OK to you? I think it is fine to leave the PIPECTL accesses and the phy_init() calls as-is, but if you would prefer that I also conditionalize those I can do that. We have at least one customer who will need this feature fairly soon, so we would like to get this in without too much delay, although I guess we missed the 3.16 merge window. I like this a lot :-) Very nice of Synopsys to support this configuration. Could you just let me know which versions of the core support this configuration ? We have AM437x which has this sort of quirk although, I think it's done using a TI-specific modification, perhaps ? AM437x is version 2.40a It has been officially supported since 2.60a. But it's possible that customers have hacked up something like this on their own with previous versions, so the exact version number might not mean much. The patch should work for all versions of the core, because the DWC_USB3_SSPHY_INTERFACE bits have always been there, going back to preproduction versions of the core. It has been pointed out to me that DT can already be used to limit the max speed, using the 'maximum-speed' property (duh). But I think we still want the patch for non-DT platforms like dwc3-pci. In TI implementation (AM437x) DWC3_GHWPARAMS3_SSPHY_IFC(dwc-hwparams.hwparams3) is read as 1. -- -George -- 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] usbhid : enable NO_INIT_REPORTS quirk for Semico USB Keykoard
On Sun, 1 Jun 2014, Daniel Kamil Kozar wrote:
The device which identifies itself as a USB Keykoard (no typo) with
VID:PID 1a2c:0023 does not seem to be handling the reports initialization
very well. This results in a usb_submit_urb(ctrl) failed: -1 message
from the kernel when connected, and a delay before its initialization.
This patch adds the quirk for this device, which causes the delay to
disappear.
Signed-off-by: Daniel Kamil Kozar dkk...@gmail.com
Please always add an empty line between the changelog and a signoff.
---
diff -uprN -X linux-3.15-rc7/Documentation/dontdiff
linux-3.15-rc7/drivers/hid/hid-ids.h linux-3.15-rc7-mine/drivers/hid/hid-ids.h
--- linux-3.15-rc7/drivers/hid/hid-ids.h 2014-05-26 01:06:00.0
+0200
+++ linux-3.15-rc7-mine/drivers/hid/hid-ids.h 2014-06-01 12:30:45.910903449
+0200
@@ -769,6 +769,10 @@
#define USB_DEVICE_ID_SAMSUNG_IR_REMOTE 0x0001
#define USB_DEVICE_ID_SAMSUNG_WIRELESS_KBD_MOUSE 0x0600
+/* China Resource Semico Co., Ltd */
We're not putting such comments there.
+#define USB_VENDOR_ID_SEMICO 0x1a2c
+#define USB_DEVICE_ID_SEMICO_USB_KEYKOARD0x0023
+
#define USB_VENDOR_ID_SENNHEISER 0x1395
#define USB_DEVICE_ID_SENNHEISER_BTD500USB 0x002c
diff -uprN -X linux-3.15-rc7/Documentation/dontdiff
linux-3.15-rc7/drivers/hid/usbhid/hid-quirks.c
linux-3.15-rc7-mine/drivers/hid/usbhid/hid-quirks.c
--- linux-3.15-rc7/drivers/hid/usbhid/hid-quirks.c2014-05-26
01:06:00.0 +0200
+++ linux-3.15-rc7-mine/drivers/hid/usbhid/hid-quirks.c 2014-06-01
12:32:01.161744987 +0200
@@ -120,6 +120,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_HD,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_QUAD_HD,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_TP_V103,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_SEMICO, USB_DEVICE_ID_SEMICO_USB_KEYKOARD,
HID_QUIRK_NO_INIT_REPORTS },
The list ought to be kept sorted.
These were trivial to fix, so I have fixed it and applied, but please keep
that in mind for your future patch submissions.
Thanks,
--
Jiri Kosina
SUSE Labs
--
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: renesas: gadget: fixup: complete STATUS stage after receiving
Hello.
On 02-06-2014 7:31, Kuninori Morimoto wrote:
From: Kuninori Morimoto kuninori.morimoto...@renesas.com
Current usbhs gadget driver didn't complete STATUS stage after receiving.
It wasn't problem for us before, because some USB class doesn't use
DATA OUT stage in control transfer.
But, it is required on some device.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
drivers/usb/renesas_usbhs/fifo.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c
index d49f9c3..4fd3653 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -681,6 +681,14 @@ usbhs_fifo_read_end:
usbhs_pipe_number(pipe),
pkt-length, pkt-actual, *is_done, pkt-zero);
+ /*
+* Transmission end
+*/
+ if (*is_done) {
+ if (usbhs_pipe_is_dcp(pipe))
Why not collapse these into single *if*? That would decrease the
indentation level...
+ usbhs_dcp_control_transfer_done(pipe);
+ }
+
usbhs_fifo_read_busy:
usbhsf_fifo_unselect(pipe, fifo);
WBR, Sergei
--
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: xhci usb 3.0 logitech c920 not working
On Mon, 2014-05-26 at 13:17 +0200, Martin Rudhart wrote: Thank your for your reply, A summary of my Bugreport at Launchpad: My usb-Webcam Logitech c920 doesn't work when connected to my usb 3.0 Host Controller (Etron EJ168a). When connected to a usb 2.0 Host Controller it works perfectly. When I connect my usb 3.0 stick to the same port, it's recognized and also works - just not the Webcam. Disabling usb 3.0 Legacy Mode (xhci) in my Bios doesn't change anything, It's still used instead of ehci. Ubuntu 14.04 x64 3.13.0-24-generic Mainboard: Asrock Z68 Pro3 Gen3 Bios: P2.30 (latest) Here's what dmesg shows if I un/replug the webcam with the mainline/upstream kernel (3.15.0-031500rc6-generic amd64): dmesg | grep xhci [ 165.165101] usb 3-1: new high-speed USB device number 3 using xhci_hcd [ 166.411905] xhci_hcd :06:00.0: ERROR: unexpected command completion code 0x11. (multiple instances) Parameter error. Please switch on xhci dynamic debugging. But whatever you do, never ever mutilate a bug report like this. Never ever grep around and drop parts of the report. And don't put things on an external server one cannot access with all tools. Regards Oliver -- 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] ARM: dts: Enable USB 3503 hub on exynos5250-snow
Hi Julius, On Thu, May 29, 2014 at 4:07 AM, Julius Werner jwer...@chromium.org wrote: We originally tried using this driver on ChromiumOS and never got it to work reliably. IIRC the issue was that if the hub had already been initialized by firmware, the USB stack might enumerate it before the usb3503 driver is probed and then the later reset will silently disrupt that connection. (I think I tried to force the 3503 to probe earlier as well, and there was some other issue with that although I don't recall the details.) Ok, there was already a patch posted by you for this[1], which had quite a much discussion on it. Would you like to give some pointers based on that ? One that Olof had suggested was to use gpio-reset driver which is yet to make to mainline. But i think with that too we need to take care of the timing for resetting the hub before PHY gets reset. This will not be an issue for the Snow and Peach_Pi(t) boards (since neither of them shipped with firmware that supports this hub), but it will be an issue for Spring and Skate. On ChromiumOS we decided to carry a local (and admittedly ugly) patch to pull that reset line from the USB PHY driver instead, since that's the only way I could get it to work in all cases (see http://crosreview.com/58963). This doesn't mean I'm against this patch per se, just wanted to point out the trade-offs. Thanks for raising the concern, this needs to be addressed. [1] https://lkml.org/lkml/2013/7/9/486 -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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] xhci: make error messages grepable
From: Oliver Neukum oneu...@suse.de
grep must work, not matter the line length.
Signed-off-by: Oliver Neukum oneu...@suse.de
---
drivers/usb/host/xhci.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 3008369..c15d665 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1805,15 +1805,15 @@ static int xhci_configure_endpoint_result(struct
xhci_hcd *xhci,
switch (*cmd_status) {
case COMP_ENOMEM:
- dev_warn(udev-dev, Not enough host controller resources
- for new device state.\n);
+ dev_warn(udev-dev,
+Not enough host controller resources for new device
state.\n);
ret = -ENOMEM;
/* FIXME: can we allocate more resources for the HC? */
break;
case COMP_BW_ERR:
case COMP_2ND_BW_ERR:
- dev_warn(udev-dev, Not enough bandwidth
- for new device state.\n);
+ dev_warn(udev-dev,
+Not enough bandwidth for new device state.\n);
ret = -ENOSPC;
/* FIXME: can we go back to the old state? */
break;
@@ -1825,8 +1825,8 @@ static int xhci_configure_endpoint_result(struct xhci_hcd
*xhci,
ret = -EINVAL;
break;
case COMP_DEV_ERR:
- dev_warn(udev-dev, ERROR: Incompatible device for endpoint
- configure command.\n);
+ dev_warn(udev-dev,
+ERROR: Incompatible device for endpoint configure
command.\n);
ret = -ENODEV;
break;
case COMP_SUCCESS:
@@ -1835,8 +1835,8 @@ static int xhci_configure_endpoint_result(struct xhci_hcd
*xhci,
ret = 0;
break;
default:
- xhci_err(xhci, ERROR: unexpected command completion
- code 0x%x.\n, *cmd_status);
+ xhci_err(xhci, ERROR: unexpected command completion code
0x%x.\n,
+ *cmd_status);
ret = -EINVAL;
break;
}
@@ -1851,24 +1851,24 @@ static int xhci_evaluate_context_result(struct xhci_hcd
*xhci,
switch (*cmd_status) {
case COMP_EINVAL:
- dev_warn(udev-dev, WARN: xHCI driver setup invalid evaluate
- context command.\n);
+ dev_warn(udev-dev,
+WARN: xHCI driver setup invalid evaluate context
command.\n);
ret = -EINVAL;
break;
case COMP_EBADSLT:
- dev_warn(udev-dev, WARN: slot not enabled for
- evaluate context command.\n);
+ 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);
+ dev_warn(udev-dev,
+ WARN: invalid context state for evaluate context
command.\n);
xhci_dbg_ctx(xhci, virt_dev-out_ctx, 1);
ret = -EINVAL;
break;
case COMP_DEV_ERR:
- dev_warn(udev-dev, ERROR: Incompatible device for evaluate
- context command.\n);
+ dev_warn(udev-dev,
+ ERROR: Incompatible device for evaluate context
command.\n);
ret = -ENODEV;
break;
case COMP_MEL_ERR:
@@ -1882,8 +1882,8 @@ static int xhci_evaluate_context_result(struct xhci_hcd
*xhci,
ret = 0;
break;
default:
- xhci_err(xhci, ERROR: unexpected command completion
- code 0x%x.\n, *cmd_status);
+ xhci_err(xhci, ERROR: unexpected command completion code
0x%x.\n,
+ *cmd_status);
ret = -EINVAL;
break;
}
--
1.8.4.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 1/1] usb: add xhci warm reset if get device descripor return error
hi Greg:
2014-05-31 0:02 GMT+08:00 Greg KH gre...@linuxfoundation.org:
On Fri, May 30, 2014 at 11:28:36PM +0800, che-chun Kuo wrote:
We found when we plug in/out usb3.0 device for stress testing, once
usb_get_device_descriptor fail in hub_port_init, we will call
hub_port_disable.
Then usb3.0 device may not recover successfully with only hot reset like
below function
retval = hub_port_reset(hub, port1, udev, delay, false);
For covering this error handling, we add warm reset if getting device
descriptor fail on usb3.0 devices.
Odd linewrapping :(
since I try to make the explanation more readable, I purposely add
more blank like.
sorry for making you confused. ^^
Anyway, what makes USB 3 devices so special here that they need a
reset vs. all other devices?
in the beginning, I try to add quirk determination in usb driver.
But get descriptor is the 1st command we get.
if getting descriptor fail, I have no idea how to add quirk
determination in usb driver.
Are you sure your device isn't just broken somehow?
Yes, your concern is reasonable.
for accelerating the issue happen, I purposely create diff at the end of mail.
And I try 5 devices on my hand, 2 of them will not successfully return
back with only hot reset.
In usb3.0 spec, warm reset will force usb3.0 jump to Rx.detect.
But hot reset will direct down stream port from to ss.Disabled only
only if time out happen.
That is why I add warm reset when get device descriptor fail.
appreciate your help,
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
old mode 100644
new mode 100755
index f829a1a..ffc5241
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -18,6 +18,9 @@
#include usb.h
+static int try_flag = 0;
+module_param(try_flag, int, S_IRUGO|S_IWUSR);
+
static void cancel_async_set_config(struct usb_device *udev);
struct api_context {
@@ -912,6 +915,12 @@ int usb_get_device_descriptor(struct usb_device
*dev, unsigned int size)
if (!desc)
return -ENOMEM;
+
+ if ((try_flag = 3) (dev-speed == USB_SPEED_SUPER)
(dev-state == USB_STATE_ADDRESS) (dev-devpath[0] != '0')){
+ printk(KERN_ERRpurposely let get device descriptor fail\n);
+ try_flag ++;
+ return -2;
+ }
ret = usb_get_descriptor(dev, USB_DT_DEVICE, 0, desc, size);
if (ret = 0)
memcpy(dev-descriptor, desc, size);
--
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: xHCI regression for VIA USB 3.0 controller in handle_cmd_completion
The SLOT ID for reset device command completion TRB's isn't very well documented. If VIA chose to set it to zero we should use what works best, e.g. dig out the SLOT ID from the queued command TRB. This has been working previously. For Reset Device in Section 4.6.1, it says: Insert a Command Completion Event on the Event Ring of Interrupter 0 and initialize the following fields: ... Clear all other fields of the event TRB to ‘0’. Can all other fields be interpreted to include Slot ID? Thats right, so it does. The VIA controller behaving like it should. I'd like to use Saran's patch partly, I'd like to keep Xenia's WARN and compare SLOT ID's in the cases specs clearly specify event SLOT ID. In the Reset Device case use the command TRB SLOT ID. I can do this myself, but if you, Saran, feel you want to send a patch for it please let me know Thanks for asking, but since the patch is trivial, it'll be easier/faster if you write/backport it. Sure, will do it. Thanks -Mathias -- 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/1] usb: add xhci warm reset if get device descripor return error
On Mon, 2 Jun 2014, vichy wrote: hi Greg: 2014-05-31 0:02 GMT+08:00 Greg KH gre...@linuxfoundation.org: On Fri, May 30, 2014 at 11:28:36PM +0800, che-chun Kuo wrote: We found when we plug in/out usb3.0 device for stress testing, once usb_get_device_descriptor fail in hub_port_init, we will call hub_port_disable. Then usb3.0 device may not recover successfully with only hot reset like below function retval = hub_port_reset(hub, port1, udev, delay, false); For covering this error handling, we add warm reset if getting device descriptor fail on usb3.0 devices. Odd linewrapping :( since I try to make the explanation more readable, I purposely add more blank like. sorry for making you confused. ^^ Anyway, what makes USB 3 devices so special here that they need a reset vs. all other devices? in the beginning, I try to add quirk determination in usb driver. But get descriptor is the 1st command we get. if getting descriptor fail, I have no idea how to add quirk determination in usb driver. Are you sure your device isn't just broken somehow? Yes, your concern is reasonable. for accelerating the issue happen, I purposely create diff at the end of mail. And I try 5 devices on my hand, 2 of them will not successfully return back with only hot reset. In usb3.0 spec, warm reset will force usb3.0 jump to Rx.detect. But hot reset will direct down stream port from to ss.Disabled only only if time out happen. That is why I add warm reset when get device descriptor fail. Dan Williams should take a look at this patch. He has been doing lots of similar stuff lately involving warm resets. 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: ftdi_sio BUG: NULL pointer dereference
On Mon, Jun 02, 2014 at 10:25:39AM -0400, Mike Remski wrote: Please CC me as not subscribed to list. Third party device, with FTDI chip on it. Get this when plugging device in. Discovered in kernel 2.6.32 Wow, that kernel is ancient. Please upgrade to a more recent kernel such as v3.14.5, or you need to get support from whatever vendor is forcing you to use such an old kernel. Good luck, 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: BUG: EHCI Bios handoff fails and system gets stuck
On Fri, 30 May 2014, Leandro Liptak wrote:
Adjunct is the output of dmidecode (:
I didn't try setting try_handoff to 0, but I think behavior is
predictable since in that case the kernel will never reach the
pci_write in question. I found a kernel compiling option named Enable
PCI quirk workarounds. It seems what i've been looking for (i mean,
disabling of it), at least while i have this buggy bios...
See if the patch below fixes your problem.
Alan Stern
Index: usb-3.15/drivers/usb/host/pci-quirks.c
===
--- usb-3.15.orig/drivers/usb/host/pci-quirks.c
+++ usb-3.15/drivers/usb/host/pci-quirks.c
@@ -656,6 +656,14 @@ static const struct dmi_system_id ehci_d
DMI_MATCH(DMI_BIOS_VERSION, Lucid-),
},
},
+ {
+ /* HASEE E200 */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, HASEE),
+ DMI_MATCH(DMI_BOARD_NAME, E210),
+ DMI_MATCH(DMI_BIOS_VERSION, 6.00),
+ },
+ },
{ }
};
@@ -665,9 +673,14 @@ static void ehci_bios_handoff(struct pci
{
int try_handoff = 1, tried_handoff = 0;
- /* The Pegatron Lucid tablet sporadically waits for 98 seconds trying
-* the handoff on its unused controller. Skip it. */
- if (pdev-vendor == 0x8086 pdev-device == 0x283a) {
+ /*
+* The Pegatron Lucid tablet sporadically waits for 98 seconds trying
+* the handoff on its unused controller. Skip it.
+*
+* The HASEE E200 hangs when the semaphore is set (bugzilla #77021).
+*/
+ if (pdev-vendor == 0x8086 (pdev-device == 0x283a ||
+ pdev-device == 0x27cc)) {
if (dmi_check_system(ehci_dmi_nohandoff_table))
try_handoff = 0;
}
--
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/3] usb: gadget: dummy_hcd: refactor dummy_start to be DRY
On Sat, 31 May 2014, Pantelis Koukousoulas wrote:
When dummy_hcd is created as a SuperSpeed controller (configurable via
a module parameter) dummy_start() is called twice, once to make the
Not to make the hcds, but to start them running. The hcd structures
are created in dummy_hcd_probe().
SuperSpeed HCD and once to make the Highspeed HCD. When it is created
as a HighSpeed controller, then dummy_start() is only called once.
The way dummy_start() was written, the URB list and the timer are
initialized twice (in the superspeed case). Besides looking weird
it is also possible that this can be buggy, because the way it works
is that we initialize the timer and the list when starting the
SuperSpeed HCD, we return all the way back to the USB core (so
possibly the timer and list start to get used due to requests
by the hub) and then we initialize them again while starting
the HighSpeed HCD. It is not impossible for this to result at
least in lost/leaked URBs.
No, this is completely wrong. When the driver uses SuperSpeed support,
there are two hcds: the high speed one and the SuperSpeed one. They
are different structures and they both need to be initialized.
It sounds like you have confused struct dummy (there's only one of
these) with struct dummy_hcd (there are two of these).
So, rework dummy_start() to only initialize dummy_hcd struct
fields once and delete dummy_start_ss() helper function
as it is no longer useful.
Signed-off-by: Pantelis Koukousoulas pkt...@gmail.com
---
drivers/usb/gadget/dummy_hcd.c | 50
++
1 file changed, 17 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index 8c06430..dbbee3e 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -2314,45 +2314,23 @@ static ssize_t urbs_show(struct device *dev, struct
device_attribute *attr,
}
static DEVICE_ATTR_RO(urbs);
-static int dummy_start_ss(struct dummy_hcd *dum_hcd)
-{
- init_timer(dum_hcd-timer);
- dum_hcd-timer.function = dummy_timer;
- dum_hcd-timer.data = (unsigned long)dum_hcd;
- dum_hcd-rh_state = DUMMY_RH_RUNNING;
- dum_hcd-stream_en_ep = 0;
- INIT_LIST_HEAD(dum_hcd-urbp_list);
- dummy_hcd_to_hcd(dum_hcd)-power_budget = POWER_BUDGET;
- dummy_hcd_to_hcd(dum_hcd)-state = HC_STATE_RUNNING;
- dummy_hcd_to_hcd(dum_hcd)-uses_new_polling = 1;
-#ifdef CONFIG_USB_OTG
- dummy_hcd_to_hcd(dum_hcd)-self.otg_port = 1;
-#endif
- return 0;
-
- /* FIXME 'urbs' should be a per-device thing, maybe in usbcore */
- return device_create_file(dummy_dev(dum_hcd), dev_attr_urbs);
-}
-
static int dummy_start(struct usb_hcd *hcd)
{
struct dummy_hcd*dum_hcd = hcd_to_dummy_hcd(hcd);
/*
- * MASTER side init ... we emulate a root hub that'll only ever
- * talk to one device (the slave side). Also appears in sysfs,
- * just like more familiar pci-based HCDs.
Don't remove this comment. It's still correct.
+ * These are per-device, not per HCD, so they should only be
I don't know what These refers to, but the data structures used in
this subroutine _are_ per-hcd.
+ * initialized once although in the superspeed case this
+ * function will be called twice. Thus we use a conditional.
*/
- if (!usb_hcd_is_primary_hcd(hcd))
- return dummy_start_ss(dum_hcd);
-
- spin_lock_init(dum_hcd-dum-lock);
- init_timer(dum_hcd-timer);
- dum_hcd-timer.function = dummy_timer;
- dum_hcd-timer.data = (unsigned long)dum_hcd;
- dum_hcd-rh_state = DUMMY_RH_RUNNING;
-
- INIT_LIST_HEAD(dum_hcd-urbp_list);
+ if (dum_hcd-rh_state != DUMMY_RH_RUNNING) {
+ spin_lock_init(dum_hcd-dum-lock);
+ init_timer(dum_hcd-timer);
+ dum_hcd-timer.function = dummy_timer;
+ dum_hcd-timer.data = (unsigned long)dum_hcd;
+ INIT_LIST_HEAD(dum_hcd-urbp_list);
+ dum_hcd-rh_state = DUMMY_RH_RUNNING;
+ }
This stuff needs to be executed unconditionally.
hcd-power_budget = POWER_BUDGET;
hcd-state = HC_STATE_RUNNING;
@@ -2362,6 +2340,12 @@ static int dummy_start(struct usb_hcd *hcd)
hcd-self.otg_port = 1;
#endif
+ /* In dummy_hcd the SuperSpeed HCD is the secondary one */
This is true for all HCDs that have SuperSpeed support, not just
dummy_hcd.
+ if (!usb_hcd_is_primary_hcd(hcd)) {
+ dum_hcd-stream_en_ep = 0;
+ return 0;
+ }
+
/* FIXME 'urbs' should be a per-device thing, maybe in usbcore */
return device_create_file(dummy_dev(dum_hcd), dev_attr_urbs);
}
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 3/3] usb: gadget: Port dummy_hcd to hrtimers
On Sat, 31 May 2014, Pantelis Koukousoulas wrote: dummy_hcd uses jiffies and seems to assume that HZ=1000 and no tickless behavior. This makes its emulation not very faithful, especially for typical distro desktop kernels (HZ=250, tickless which means that e.g., when dummy_hcd asks for a delay of 1ms in reality it can get 4ms or more). For some devices, this might manifest as unexpectedly low performance (e.g., 2-4MB/s for a tcm_gadget_usb backed by a ramdisk) compared to real hardware, others might even break if they are more sensitive to timing. This patch ports dummy_hcd to use hrtimers instead, which fixes these problems and hopefully allows both for more gadgets to work with dummy_hcd and for a better emulation user experience overall, especially in typical kernel configurations. For storage this brings performance to acceptable levels (around 25MB/s for BOT, 100MB/s for UAS) improving the user experience when testing, for other devices it might mean that now they will work properly with dummy_hcd when before they didn't. Implementation uses the tasklet_hrtimer framework. This means dummy_timer callback is executed in softirq context (as it was with wheel timers) which keeps required changes to a minimum. Acked-by: Alan Stern st...@rowland.harvard.edu -- 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: ftdi_sio BUG: NULL pointer dereference
Thanks Johan, that's why I looked at the cross references for ftdi_sio.c over on http://lxr.free-electrons.com/source/drivers/usb/serial/ftdi_sio.c, latest version it's showing is 3.14. It appears that the ftdi_sio code is largely the same as in 2.6.32, particularly in the ftdi_set_max_packet_size() function. I'm trying to verify if the number of endpoints is 0 is a valid situation. Just a typical day of fun with kernels and devices. On 06/02/2014 10:33 AM, Johan Hovold wrote: On Mon, Jun 02, 2014 at 10:25:39AM -0400, Mike Remski wrote: Please CC me as not subscribed to list. Third party device, with FTDI chip on it. Get this when plugging device in. Discovered in kernel 2.6.32 Wow, that kernel is ancient. Please upgrade to a more recent kernel such as v3.14.5, or you need to get support from whatever vendor is forcing you to use such an old kernel. Good luck, Johan -- Office: (978)401-4032 (x123 internally) Cell: (603) 759-6953 -- 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: ftdi_sio BUG: NULL pointer dereference
[ Please avoid top-posting. ] On Mon, Jun 02, 2014 at 11:16:11AM -0400, Mike Remski wrote: Thanks Johan, that's why I looked at the cross references for ftdi_sio.c over on http://lxr.free-electrons.com/source/drivers/usb/serial/ftdi_sio.c, latest version it's showing is 3.14. It appears that the ftdi_sio code is largely the same as in 2.6.32, particularly in the ftdi_set_max_packet_size() function. Lots of things have changed since v2.6.32 and not just in the driver itself but in all the infrastructure it relies on. I'm trying to verify if the number of endpoints is 0 is a valid situation. No, that is not normal, but it should not crash the driver if it's a hardware issue. What is the lsusb -v output of your device (make sure the ftdi_sio driver isn't loaded when connecting the device). And what happens if you plug it into a machine running a recent kernel? 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
[PATCH] usb: musb: tusb6010: Introduce the use of the managed version of kzalloc
This patch moves data allocated using kzalloc to managed data allocated
using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
functions. Also, the unnecesary labels are removed and linux/device.h is
added to make sure the devm_*() routine declarations are unambiguously
available.
The following Coccinelle semantic patch was used for making the change:
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
.probe = probefn,
.remove = removefn,
};
@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(pdev-dev, e1, e2)
...
?-kfree(e);
...+
}
@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
...
- kfree(e);
...
}
Signed-off-by: Himangi Saraogi himangi...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
---
drivers/usb/musb/tusb6010.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 159ef4b..7dfc6cb 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -22,6 +22,7 @@
#include linux/usb.h
#include linux/irq.h
#include linux/io.h
+#include linux/device.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/usb/usb_phy_generic.h
@@ -1160,12 +1161,12 @@ static int tusb_probe(struct platform_device *pdev)
struct platform_device *musb;
struct tusb6010_glue*glue;
struct platform_device_info pinfo;
- int ret = -ENOMEM;
+ int ret;
- glue = kzalloc(sizeof(*glue), GFP_KERNEL);
+ glue = devm_kzalloc(pdev-dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
dev_err(pdev-dev, failed to allocate glue context\n);
- goto err0;
+ return -ENOMEM;
}
glue-dev = pdev-dev;
@@ -1204,16 +1205,10 @@ static int tusb_probe(struct platform_device *pdev)
if (IS_ERR(musb)) {
ret = PTR_ERR(musb);
dev_err(pdev-dev, failed to register musb device: %d\n,
ret);
- goto err3;
+ return ret;
}
return 0;
-
-err3:
- kfree(glue);
-
-err0:
- return ret;
}
static int tusb_remove(struct platform_device *pdev)
@@ -1222,7 +1217,6 @@ static int tusb_remove(struct platform_device *pdev)
platform_device_unregister(glue-musb);
usb_phy_generic_unregister(glue-phy);
- kfree(glue);
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ftdi_sio BUG: NULL pointer dereference
On 06/02/2014 11:40 AM, Johan Hovold wrote: [ Please avoid top-posting. ] On Mon, Jun 02, 2014 at 11:16:11AM -0400, Mike Remski wrote: Thanks Johan, that's why I looked at the cross references for ftdi_sio.c over on http://lxr.free-electrons.com/source/drivers/usb/serial/ftdi_sio.c, latest version it's showing is 3.14. It appears that the ftdi_sio code is largely the same as in 2.6.32, particularly in the ftdi_set_max_packet_size() function. Lots of things have changed since v2.6.32 and not just in the driver itself but in all the infrastructure it relies on. I'm trying to verify if the number of endpoints is 0 is a valid situation. No, that is not normal, but it should not crash the driver if it's a hardware issue. What is the lsusb -v output of your device (make sure the ftdi_sio driver isn't loaded when connecting the device). And what happens if you plug it into a machine running a recent kernel? Thanks, Johan Thanks Johan; sorry for top posting. An even more ancient kernel (2.6.18) has v1.4.3 of the ftdi_sio.c and I do not see this problem. In v1.4.3, ftdi_sio_attach() is doing the work that is now in ftdi_sio_port_probe(), but 1.4.3 does not have the ftdi_set_max_packet_size() code. The device works fine under 2.6.18. I have to see if I can scrounge up a machine running a later kernel (other than my desktop). Should have included this earlier but its unmodified CentOs 6.0 and 6.4, kernel is: Linux nicA91A84 2.6.32-71.29.1.el6.i686 #1 SMP Tue May 10 17:35:05 CDT 2011 i686 i686 i386 GNU/Linux lsusb -v cut for the device in question. Bus 005 Device 003: ID 1fdf:1001 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x1fdf idProduct 0x1001 bcdDevice0.03 iManufacturer 1 Sepura iProduct2 Colour Console iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 134 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 0 None iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 0 None iInterface 0 CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x01 call management bDataInterface 1 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface0 bSlaveInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType11 bFirstInterface 2
Re: ftdi_sio BUG: NULL pointer dereference
On 06/02/2014 11:40 AM, Johan Hovold wrote: [ Please avoid top-posting. ] On Mon, Jun 02, 2014 at 11:16:11AM -0400, Mike Remski wrote: Thanks Johan, that's why I looked at the cross references for ftdi_sio.c over on http://lxr.free-electrons.com/source/drivers/usb/serial/ftdi_sio.c, latest version it's showing is 3.14. It appears that the ftdi_sio code is largely the same as in 2.6.32, particularly in the ftdi_set_max_packet_size() function. Lots of things have changed since v2.6.32 and not just in the driver itself but in all the infrastructure it relies on. I'm trying to verify if the number of endpoints is 0 is a valid situation. No, that is not normal, but it should not crash the driver if it's a hardware issue. What is the lsusb -v output of your device (make sure the ftdi_sio driver isn't loaded when connecting the device). And what happens if you plug it into a machine running a recent kernel? Thanks, Johan Plugging device into a system running Redhat, kernel 3.3.4 crashes the system. -- Office: (978)401-4032 (x123 internally) Cell: (603) 759-6953 -- 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: ftdi_sio BUG: NULL pointer dereference
On Mon, Jun 02, 2014 at 12:09:36PM -0400, Mike Remski wrote: On 06/02/2014 11:40 AM, Johan Hovold wrote: [ Please avoid top-posting. ] On Mon, Jun 02, 2014 at 11:16:11AM -0400, Mike Remski wrote: Thanks Johan, that's why I looked at the cross references for ftdi_sio.c over on http://lxr.free-electrons.com/source/drivers/usb/serial/ftdi_sio.c, latest version it's showing is 3.14. It appears that the ftdi_sio code is largely the same as in 2.6.32, particularly in the ftdi_set_max_packet_size() function. Lots of things have changed since v2.6.32 and not just in the driver itself but in all the infrastructure it relies on. I'm trying to verify if the number of endpoints is 0 is a valid situation. No, that is not normal, but it should not crash the driver if it's a hardware issue. What is the lsusb -v output of your device (make sure the ftdi_sio driver isn't loaded when connecting the device). And what happens if you plug it into a machine running a recent kernel? Thanks, Johan Plugging device into a system running Redhat, kernel 3.3.4 crashes the system. 3.3.4 is still _many_ years old. Please try something from 2014 at the latest... -- 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: ftdi_sio BUG: NULL pointer dereference
On Mon, Jun 02, 2014 at 12:02:40PM -0400, Mike Remski wrote: On 06/02/2014 11:40 AM, Johan Hovold wrote: [ Please avoid top-posting. ] On Mon, Jun 02, 2014 at 11:16:11AM -0400, Mike Remski wrote: Thanks Johan, that's why I looked at the cross references for ftdi_sio.c over on http://lxr.free-electrons.com/source/drivers/usb/serial/ftdi_sio.c, latest version it's showing is 3.14. It appears that the ftdi_sio code is largely the same as in 2.6.32, particularly in the ftdi_set_max_packet_size() function. Lots of things have changed since v2.6.32 and not just in the driver itself but in all the infrastructure it relies on. I'm trying to verify if the number of endpoints is 0 is a valid situation. No, that is not normal, but it should not crash the driver if it's a hardware issue. What is the lsusb -v output of your device (make sure the ftdi_sio driver isn't loaded when connecting the device). And what happens if you plug it into a machine running a recent kernel? Thanks, Johan Thanks Johan; sorry for top posting. An even more ancient kernel (2.6.18) has v1.4.3 of the ftdi_sio.c and I do not see this problem. In v1.4.3, ftdi_sio_attach() is doing the work that is now in ftdi_sio_port_probe(), but 1.4.3 does not have the ftdi_set_max_packet_size() code. The device works fine under 2.6.18. I have to see if I can scrounge up a machine running a later kernel (other than my desktop). Your desktop should be just fine for testing. Should have included this earlier but its unmodified CentOs 6.0 and 6.4, kernel is: Linux nicA91A84 2.6.32-71.29.1.el6.i686 #1 SMP Tue May 10 17:35:05 CDT 2011 i686 i686 i386 GNU/Linux lsusb -v cut for the device in question. Bus 005 Device 003: ID 1fdf:1001 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x1fdf idProduct 0x1001 bcdDevice0.03 iManufacturer 1 Sepura iProduct2 Colour Console iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 134 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) Is this indeed the right device? Then you seem to be using the wrong driver as this is no FTDI device, but a CDC-ACM modem-class device which should be driven by the cdc-acm driver. bFunctionProtocol 0 None iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 0 None iInterface 0 CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x01 call management bDataInterface 1 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface0 bSlaveInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval
Re: ftdi_sio BUG: NULL pointer dereference
On 06/02/2014 12:20 PM, Johan Hovold wrote: On Mon, Jun 02, 2014 at 12:02:40PM -0400, Mike Remski wrote: On 06/02/2014 11:40 AM, Johan Hovold wrote: [ Please avoid top-posting. ] On Mon, Jun 02, 2014 at 11:16:11AM -0400, Mike Remski wrote: Thanks Johan, that's why I looked at the cross references for ftdi_sio.c over on http://lxr.free-electrons.com/source/drivers/usb/serial/ftdi_sio.c, latest version it's showing is 3.14. It appears that the ftdi_sio code is largely the same as in 2.6.32, particularly in the ftdi_set_max_packet_size() function. Lots of things have changed since v2.6.32 and not just in the driver itself but in all the infrastructure it relies on. I'm trying to verify if the number of endpoints is 0 is a valid situation. No, that is not normal, but it should not crash the driver if it's a hardware issue. What is the lsusb -v output of your device (make sure the ftdi_sio driver isn't loaded when connecting the device). And what happens if you plug it into a machine running a recent kernel? Thanks, Johan Thanks Johan; sorry for top posting. An even more ancient kernel (2.6.18) has v1.4.3 of the ftdi_sio.c and I do not see this problem. In v1.4.3, ftdi_sio_attach() is doing the work that is now in ftdi_sio_port_probe(), but 1.4.3 does not have the ftdi_set_max_packet_size() code. The device works fine under 2.6.18. I have to see if I can scrounge up a machine running a later kernel (other than my desktop). Your desktop should be just fine for testing. Should have included this earlier but its unmodified CentOs 6.0 and 6.4, kernel is: Linux nicA91A84 2.6.32-71.29.1.el6.i686 #1 SMP Tue May 10 17:35:05 CDT 2011 i686 i686 i386 GNU/Linux lsusb -v cut for the device in question. Bus 005 Device 003: ID 1fdf:1001 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x1fdf idProduct 0x1001 bcdDevice0.03 iManufacturer 1 Sepura iProduct2 Colour Console iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 134 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) Is this indeed the right device? Then you seem to be using the wrong driver as this is no FTDI device, but a CDC-ACM modem-class device which should be driven by the cdc-acm driver. bFunctionProtocol 0 None iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 0 None iInterface 0 CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x01 call management bDataInterface 1 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface0 bSlaveInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0
Re: ftdi_sio BUG: NULL pointer dereference
On 06/02/2014 12:23 PM, Greg KH wrote: On Mon, Jun 02, 2014 at 12:09:36PM -0400, Mike Remski wrote: On 06/02/2014 11:40 AM, Johan Hovold wrote: [ Please avoid top-posting. ] On Mon, Jun 02, 2014 at 11:16:11AM -0400, Mike Remski wrote: Thanks Johan, that's why I looked at the cross references for ftdi_sio.c over on http://lxr.free-electrons.com/source/drivers/usb/serial/ftdi_sio.c, latest version it's showing is 3.14. It appears that the ftdi_sio code is largely the same as in 2.6.32, particularly in the ftdi_set_max_packet_size() function. Lots of things have changed since v2.6.32 and not just in the driver itself but in all the infrastructure it relies on. I'm trying to verify if the number of endpoints is 0 is a valid situation. No, that is not normal, but it should not crash the driver if it's a hardware issue. What is the lsusb -v output of your device (make sure the ftdi_sio driver isn't loaded when connecting the device). And what happens if you plug it into a machine running a recent kernel? Thanks, Johan Plugging device into a system running Redhat, kernel 3.3.4 crashes the system. 3.3.4 is still _many_ years old. Please try something from 2014 at the latest... Understood Greg; it was the best I had immediately available. I am working on setting up/finding a later kernel at the moment. thanks -- Office: (978)401-4032 (x123 internally) Cell: (603) 759-6953 -- 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] iusb: musb: davinci: use devm_ functions.
This patch moves data allocated using kzalloc to managed data allocated
using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
functions. Also, a label is done away with and clk_get is replaced by it
corresponding devm version and the clk_puts are done away with. The
labels are renamed to make them ordered.
The following Coccinelle semantic patch was used for making the change:
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
.probe = probefn,
.remove = removefn,
};
@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(pdev-dev, e1, e2)
...
?-kfree(e);
...+
}
@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
...
- kfree(e);
...
}
Signed-off-by: Himangi Saraogi himangi...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
---
Not compile tested due to incompatible architechture.
drivers/usb/musb/davinci.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index de8492b..110b784 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -519,23 +519,23 @@ static int davinci_probe(struct platform_device *pdev)
int ret = -ENOMEM;
- glue = kzalloc(sizeof(*glue), GFP_KERNEL);
+ glue = devm_kzalloc(pdev-dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
dev_err(pdev-dev, failed to allocate glue context\n);
goto err0;
}
- clk = clk_get(pdev-dev, usb);
+ clk = devm_clk_get(pdev-dev, usb);
if (IS_ERR(clk)) {
dev_err(pdev-dev, failed to get clock\n);
ret = PTR_ERR(clk);
- goto err3;
+ goto err0;
}
ret = clk_enable(clk);
if (ret) {
dev_err(pdev-dev, failed to enable clock\n);
- goto err4;
+ goto err0;
}
glue-dev = pdev-dev;
@@ -579,20 +579,14 @@ static int davinci_probe(struct platform_device *pdev)
if (IS_ERR(musb)) {
ret = PTR_ERR(musb);
dev_err(pdev-dev, failed to register musb device: %d\n,
ret);
- goto err5;
+ goto err1;
}
return 0;
-err5:
+err1:
clk_disable(clk);
-err4:
- clk_put(clk);
-
-err3:
- kfree(glue);
-
err0:
return ret;
}
@@ -604,8 +598,6 @@ static int davinci_remove(struct platform_device *pdev)
platform_device_unregister(glue-musb);
usb_phy_generic_unregister();
clk_disable(glue-clk);
- clk_put(glue-clk);
- kfree(glue);
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ftdi_sio BUG: NULL pointer dereference
On Mon, Jun 02, 2014 at 12:24:44PM -0400, Mike Remski wrote: On 06/02/2014 12:20 PM, Johan Hovold wrote: On Mon, Jun 02, 2014 at 12:02:40PM -0400, Mike Remski wrote: On 06/02/2014 11:40 AM, Johan Hovold wrote: [ Please avoid top-posting. ] On Mon, Jun 02, 2014 at 11:16:11AM -0400, Mike Remski wrote: lsusb -v cut for the device in question. Bus 005 Device 003: ID 1fdf:1001 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x1fdf idProduct 0x1001 bcdDevice0.03 iManufacturer 1 Sepura iProduct2 Colour Console iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 134 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) Is this indeed the right device? Then you seem to be using the wrong driver as this is no FTDI device, but a CDC-ACM modem-class device which should be driven by the cdc-acm driver. bFunctionProtocol 0 None iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 0 None iInterface 0 CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x01 call management bDataInterface 1 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface0 bSlaveInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType11 bFirstInterface 2 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 0 None iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 0 The third interface lacks endpoints and crashes the ftdi_sio driver. This shouldn't happen (even if you're forcing the wrong driver to bind), so I'll fix it up if still broken in v3.15-rc. Thanks, Johan Johan,
Re: ftdi_sio BUG: NULL pointer dereference
On 06/02/2014 12:49 PM, Johan Hovold wrote: On Mon, Jun 02, 2014 at 12:24:44PM -0400, Mike Remski wrote: On 06/02/2014 12:20 PM, Johan Hovold wrote: On Mon, Jun 02, 2014 at 12:02:40PM -0400, Mike Remski wrote: On 06/02/2014 11:40 AM, Johan Hovold wrote: [ Please avoid top-posting. ] On Mon, Jun 02, 2014 at 11:16:11AM -0400, Mike Remski wrote: lsusb -v cut for the device in question. Bus 005 Device 003: ID 1fdf:1001 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x1fdf idProduct 0x1001 bcdDevice0.03 iManufacturer 1 Sepura iProduct2 Colour Console iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 134 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) Is this indeed the right device? Then you seem to be using the wrong driver as this is no FTDI device, but a CDC-ACM modem-class device which should be driven by the cdc-acm driver. bFunctionProtocol 0 None iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 0 None iInterface 0 CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x01 call management bDataInterface 1 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface0 bSlaveInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType11 bFirstInterface 2 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 0 None iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 0 The third interface lacks endpoints and crashes the ftdi_sio driver. This shouldn't happen (even if you're forcing the wrong driver to bind), so I'll fix it up if still broken in v3.15-rc. Thanks, Johan Johan, Thanks again. Yes, the device does indeed have an FTDI embedded in it; they've programmed in
Re: [PATCH 1/2] ARM: dts: Enable USB 3503 hub on exynos5250-snow
Ok, there was already a patch posted by you for this[1], which had quite a much discussion on it. Would you like to give some pointers based on that ? One that Olof had suggested was to use gpio-reset driver which is yet to make to mainline. But i think with that too we need to take care of the timing for resetting the hub before PHY gets reset. Oh, right, I remember now. Seems like there wasn't much consensus on how to solve the problem there, and I think I didn't really have time to work on it any more either. I think coupling in another driver to reset the device isn't a bad idea... this could even be usb3503 if you modified it a little, and it could also address Tomasz' concerns from that thread that the solution should be extensible to other HSIC devices that need a different reset sequence. But you need some mechanism to hook the two drivers together and make sure phy-samsung-usb2 synchronously calls the reset function at exactly the right point to ensure the timing works right. -- 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: usb5303: make use of uninitialized err variable
The variable err is not initialized here, this patch uses it
to store an eventual error value from devm_clk_get().
Signed-off-by: Emil Goode emilgo...@gmail.com
---
drivers/usb/misc/usb3503.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index f43c619..c86c3fa 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -191,9 +191,13 @@ static int usb3503_probe(struct usb3503 *hub)
hub-port_off_mask = 0;
clk = devm_clk_get(dev, refclk);
- if (IS_ERR(clk) PTR_ERR(clk) != -ENOENT) {
- dev_err(dev, unable to request refclk (%d)\n, err);
- return PTR_ERR(clk);
+ if (IS_ERR(clk)) {
+ err = PTR_ERR(clk);
+ if (err != -ENOENT) {
+ dev_err(dev, unable to request refclk (%d)\n,
+ err);
+ return err;
+ }
}
if (!IS_ERR(clk)) {
--
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: ftdi_sio BUG: NULL pointer dereference
On Mon, Jun 02, 2014 at 01:11:37PM -0400, Mike Remski wrote: On 06/02/2014 12:49 PM, Johan Hovold wrote: On Mon, Jun 02, 2014 at 12:24:44PM -0400, Mike Remski wrote: On 06/02/2014 12:20 PM, Johan Hovold wrote: On Mon, Jun 02, 2014 at 12:02:40PM -0400, Mike Remski wrote: On 06/02/2014 11:40 AM, Johan Hovold wrote: [ Please avoid top-posting. ] On Mon, Jun 02, 2014 at 11:16:11AM -0400, Mike Remski wrote: The third interface lacks endpoints and crashes the ftdi_sio driver. This shouldn't happen (even if you're forcing the wrong driver to bind), so I'll fix it up if still broken in v3.15-rc. Johan, Thanks again. Yes, the device does indeed have an FTDI embedded in it; they've programmed in their own ids. They supply a Windows driver for it, but that doesn't do me any good. :) Not just their own ID's it seems. Have you tried just using the cdc-acm driver? The ports should up as /dev/ttyACMx instead of ttyUSBx. Not yet, next on the list. You really should try this before anything else. :) I'm suspecting that bNumEndpoints == 0 is causing endpoint[1].desc to stay at NULL (line 1567 in 3.1.4.5 source), so by the time it gets used later on, I'm hitting the NULL dereference. Yeah, the code is obviously broken (also in v3.15-rc). It should probably work to just return from ftdi_set_max_packet_size if num_endpoints is 0 if you want to try that (or you can use your ?: construct), but I should be able to fix this up properly on Wednesday. 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: ftdi_sio BUG: NULL pointer dereference
On 06/02/2014 01:46 PM, Johan Hovold wrote: On Mon, Jun 02, 2014 at 01:11:37PM -0400, Mike Remski wrote: On 06/02/2014 12:49 PM, Johan Hovold wrote: On Mon, Jun 02, 2014 at 12:24:44PM -0400, Mike Remski wrote: On 06/02/2014 12:20 PM, Johan Hovold wrote: On Mon, Jun 02, 2014 at 12:02:40PM -0400, Mike Remski wrote: On 06/02/2014 11:40 AM, Johan Hovold wrote: [ Please avoid top-posting. ] On Mon, Jun 02, 2014 at 11:16:11AM -0400, Mike Remski wrote: The third interface lacks endpoints and crashes the ftdi_sio driver. This shouldn't happen (even if you're forcing the wrong driver to bind), so I'll fix it up if still broken in v3.15-rc. Johan, Thanks again. Yes, the device does indeed have an FTDI embedded in it; they've programmed in their own ids. They supply a Windows driver for it, but that doesn't do me any good. :) Not just their own ID's it seems. Have you tried just using the cdc-acm driver? The ports should up as /dev/ttyACMx instead of ttyUSBx. Not yet, next on the list. You really should try this before anything else. :) I'm suspecting that bNumEndpoints == 0 is causing endpoint[1].desc to stay at NULL (line 1567 in 3.1.4.5 source), so by the time it gets used later on, I'm hitting the NULL dereference. Yeah, the code is obviously broken (also in v3.15-rc). It should probably work to just return from ftdi_set_max_packet_size if num_endpoints is 0 if you want to try that (or you can use your ?: construct), but I should be able to fix this up properly on Wednesday. Thanks, Johan Yep, trying to get the modalias correct so the cdc_acm driver recognizes and loads for the device in question. Appreciate your help. m -- Office: (978)401-4032 (x123 internally) Cell: (603) 759-6953 -- 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: xhci usb 3.0 logitech c920 not working
On Mon, 2014-06-02 at 13:47, Oliver Neukum wrote: Parameter error. Please switch on xhci dynamic debugging. But whatever you do, never ever mutilate a bug report like this. Never ever grep around and drop parts of the report. And don't put things on an external server one cannot access with all tools. I think I reconfigured thunderbird correctly now - so the format/quotes should be right from now on. Sorry about the mutilation and the badly formatted answer. I'm used to bulletin boards with codeboxes. Should I really have posted 1835 lines of lsusb -v in my email response? I thought that would be to too long. (1000 lines--1835 lines; 100.000 Char-Limit--88.098) That's why I posted it on pastebin/an external server ... should I have used something else? Switching on xhci dynamic debugging would mean compiling a new kernel, right? It can't somehow be switched on afterwards with a ubuntu upstream/mainline kernel? Regards Martin -- 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] net: qmi_wwan: interface #11 in Sierra Wireless MC73xx is not QMI
From: Aleksander Morgado aleksan...@aleksander.es Date: Thu, 29 May 2014 13:51:36 +0200 This interface is unusable, as the cdc-wdm character device doesn't reply to any QMI command. Also, the out-of-tree Sierra Wireless GobiNet driver fully skips it. Signed-off-by: Aleksander Morgado aleksan...@aleksander.es Applied. -- 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] net: qmi_wwan: add additional Sierra Wireless QMI devices
From: Aleksander Morgado aleksan...@aleksander.es Date: Thu, 29 May 2014 13:44:45 +0200 A set of new VID/PIDs retrieved from the out-of-tree GobiNet/GobiSerial Sierra Wireless drivers. Signed-off-by: Aleksander Morgado aleksan...@aleksander.es Applied. -- 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 0/4] port power control rework stragglers
Changes since v1 [1]: 1/ Deleted usb: fix hub_handle_remote_wakeup() only exists for CONFIG_PM=y in favor of the full refactoring of hub.c into hub.c/hub_pm.c 2/ Added usb: introduce usb_set_reset_resume as its own patch as suggested by Alan. [2] 3/ Added usb: move hub power management routines to hub_pm.c with fixups suggested by Alan. 4/ Added Alan's acked-by to usb: force warm reset to break link re-connect livelock and usb: documentation for usb port power off mechanisms which were patch 18 and 19 from the v10 posting [3]. [1]: http://marc.info/?l=linux-usbm=140139351920273w=2 [2]: http://marc.info/?l=linux-usbm=140146126207527w=2 [3]: http://marc.info/?l=linux-usbm=140063512208229w=2 --- Dan Williams (3): usb: force warm reset to break link re-connect livelock usb: introduce usb_set_reset_resume usb: move hub power management routines to hub_pm.c Lan Tianyu (1): usb: documentation for usb port power off mechanisms Documentation/usb/power-management.txt | 245 ++ drivers/usb/core/Makefile |1 drivers/usb/core/hub.c | 1303 ++-- drivers/usb/core/hub.h | 50 + drivers/usb/core/hub_pm.c | 1130 drivers/usb/core/port.c| 21 - drivers/usb/core/usb.h | 41 + include/linux/usb.h| 20 8 files changed, 1557 insertions(+), 1254 deletions(-) create mode 100644 drivers/usb/core/hub_pm.c -- 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 1/4] usb: force warm reset to break link re-connect livelock
Resuming a powered down port sometimes results in the port state being
stuck in the training sequence.
hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
port1: can't get reconnection after setting port power on, status -110
hub 3-0:1.0: port 1 status .02e0 after resume, -19
usb 3-1: can't resume, status -19
hub 3-0:1.0: logical disconnect on port 1
In the case above we wait for the port re-connect timeout of 2 seconds
and observe that the port status is USB_SS_PORT_LS_POLLING (although it
is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT).
This is indicative of a case where the device is failing to progress the
link training state machine.
It is resolved by issuing a warm reset to get the hub and device link
state machines back in sync.
hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
usb usb3: port1 usb_port_runtime_resume requires warm reset
hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms
usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd
After a reconnect timeout when we expect the device to be present, force
a warm reset of the device. Note that we can not simply look at the
link status to determine if a warm reset is required as any of the
training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or
USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need
for warm reset by themselves.
Cc: Kukjin Kim kgene@samsung.com
Cc: Vincent Palatin vpala...@chromium.org
Cc: Lan Tianyu tianyu@intel.com
Cc: Ksenia Ragiadakou burzalod...@gmail.com
Cc: Vivek Gautam gautam.vi...@samsung.com
Cc: Douglas Anderson diand...@chromium.org
Cc: Felipe Balbi ba...@ti.com
Cc: Sunil Joshi jo...@samsung.com
Cc: Hans de Goede hdego...@redhat.com
Acked-by: Julius Werner jwer...@chromium.org
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
drivers/usb/core/hub.c | 36 +---
drivers/usb/core/hub.h |2 ++
drivers/usb/core/port.c | 21 -
3 files changed, 39 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 6346fb2acbd7..c8916969d76c 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2570,13 +2570,20 @@ static int hub_port_reset(struct usb_hub *hub, int
port1,
/* Is a USB 3.0 port in the Inactive or Compliance Mode state?
* Port worm reset is required to recover
*/
-static bool hub_port_warm_reset_required(struct usb_hub *hub, u16 portstatus)
+static bool hub_port_warm_reset_required(struct usb_hub *hub, int port1,
+ u16 portstatus)
{
- return hub_is_superspeed(hub-hdev)
- (((portstatus USB_PORT_STAT_LINK_STATE) ==
- USB_SS_PORT_LS_SS_INACTIVE) ||
-((portstatus USB_PORT_STAT_LINK_STATE) ==
- USB_SS_PORT_LS_COMP_MOD)) ;
+ u16 link_state;
+
+ if (!hub_is_superspeed(hub-hdev))
+ return false;
+
+ if (test_bit(port1, hub-warm_reset_bits))
+ return true;
+
+ link_state = portstatus USB_PORT_STAT_LINK_STATE;
+ return link_state == USB_SS_PORT_LS_SS_INACTIVE
+ || link_state == USB_SS_PORT_LS_COMP_MOD;
}
static int hub_port_wait_reset(struct usb_hub *hub, int port1,
@@ -2613,7 +2620,7 @@ static int hub_port_wait_reset(struct usb_hub *hub, int
port1,
if ((portstatus USB_PORT_STAT_RESET))
return -EBUSY;
- if (hub_port_warm_reset_required(hub, portstatus))
+ if (hub_port_warm_reset_required(hub, port1, portstatus))
return -ENOTCONN;
/* Device went away? */
@@ -2713,9 +2720,10 @@ static int hub_port_reset(struct usb_hub *hub, int port1,
if (status 0)
goto done;
- if (hub_port_warm_reset_required(hub, portstatus))
+ if (hub_port_warm_reset_required(hub, port1, portstatus))
warm = true;
}
+ clear_bit(port1, hub-warm_reset_bits);
/* Reset the port */
for (i = 0; i PORT_RESET_TRIES; i++) {
@@ -2752,7 +2760,8 @@ static int hub_port_reset(struct usb_hub *hub, int port1,
portstatus, portchange) 0)
goto done;
- if (!hub_port_warm_reset_required(hub, portstatus))
+ if (!hub_port_warm_reset_required(hub, port1,
+ portstatus))
goto done;
/*
@@ -2839,8 +2848,13 @@ static int check_port_resume_type(struct usb_device
*udev,
{
struct usb_port *port_dev = hub-ports[port1 - 1];
+ /* Is a warm reset needed to recover the connection? */
+ if (status == 0 udev-reset_resume
+hub_port_warm_reset_required(hub, port1, portstatus)) {
+ /* pass */;
+
[PATCH v2 3/4] usb: introduce usb_set_reset_resume
In preparation for moving hub power management logic to its own file and
removing instances of #ifdef CONFIG_PM in hub.c, introduce a
usb_set_reset_resume() helper.
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
drivers/usb/core/hub.c |5 ++---
include/linux/usb.h| 11 +++
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index c8916969d76c..63b1963620a3 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1172,9 +1172,8 @@ static void hub_activate(struct usb_hub *hub, enum
hub_activation_type type)
set_bit(port1, hub-change_bits);
} else if (udev-persist_enabled) {
-#ifdef CONFIG_PM
- udev-reset_resume = 1;
-#endif
+ usb_set_reset_resume(udev);
+
/* Don't set the change_bits when the device
* was powered off.
*/
diff --git a/include/linux/usb.h b/include/linux/usb.h
index d2465bc0e73c..909b56380c2f 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -592,6 +592,17 @@ struct usb_device {
};
#defineto_usb_device(d) container_of(d, struct usb_device, dev)
+#ifdef CONFIG_PM
+static inline void usb_set_reset_resume(struct usb_device *udev)
+{
+ udev-reset_resume = 1;
+}
+#else
+static inline void usb_set_reset_resume(struct usb_device *udev)
+{
+}
+#endif
+
static inline struct usb_device *interface_to_usbdev(struct usb_interface
*intf)
{
return to_usb_device(intf-dev.parent);
--
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 2/4] usb: documentation for usb port power off mechanisms
From: Lan Tianyu tianyu@intel.com describe the mechanisms for controlling port power policy and discovering the port power state. [oliver]: fixes, clarification of wakeup vs port-power-control [sarah]: wordsmithing [djbw]: updates for peer port changes [alan]: review and fixes Cc: Oliver Neukum oneu...@suse.de Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Lan Tianyu tianyu@intel.com Signed-off-by: Dan Williams dan.j.willi...@intel.com --- Documentation/usb/power-management.txt | 245 1 files changed, 243 insertions(+), 2 deletions(-) diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt index 1392b61d6ebe..7b90fe034c4b 100644 --- a/Documentation/usb/power-management.txt +++ b/Documentation/usb/power-management.txt @@ -2,8 +2,27 @@ Alan Stern st...@rowland.harvard.edu - October 28, 2010 - + Last-updated: February 2014 + + + Contents: + - + * What is Power Management? + * What is Remote Wakeup? + * When is a USB device idle? + * Forms of dynamic PM + * The user interface for dynamic PM + * Changing the default idle-delay time + * Warnings + * The driver interface for Power Management + * The driver interface for autosuspend and autoresume + * Other parts of the driver interface + * Mutual exclusion + * Interaction between dynamic PM and system PM + * xHCI hardware link PM + * USB Port Power Control + * User Interface for Port Power Control + * Suggested Userspace Port Power Policy What is Power Management? @@ -516,3 +535,225 @@ relevant attribute files is usb2_hardware_lpm. driver will enable hardware LPM for the device. You can write y/Y/1 or n/N/0 to the file to enable/disable USB2 hardware LPM manually. This is for test purpose mainly. + + + USB Port Power Control + -- + +In addition to suspending endpoint devices and enabling hardware +controlled link power management, the USB subsystem also has the +capability to disable power to ports under some conditions. Power is +controlled through Set/ClearPortFeature(PORT_POWER) requests to a hub. +In the case of a root or platform-internal hub the host controller +driver translates PORT_POWER requests into platform firmware (ACPI) +method calls to set the port power state. For more background see the +Linux Plumbers Conference 2012 slides [1] and video [2]: + +Upon receiving a ClearPortFeature(PORT_POWER) request a USB port is +logically off, and may trigger the actual loss of VBUS to the port [3]. +VBUS may be maintained in the case where a hub gangs multiple ports into +a shared power well causing power to remain until all ports in the gang +are turned off. VBUS may also be maintained by hub ports configured for +a charging application. In any event a logically off port will lose +connection with its device, not respond to hotplug events, and not +respond to remote wakeup events*. + +WARNING: turning off a port may result in the inability to hot add a device. +Please see User Interface for Port Power Control for details. + +As far as the effect on the device itself it is similar to what a device +goes through during system suspend, i.e. the power session is lost. Any +USB device or driver that misbehaves with system suspend will be +similarly affected by a port power cycle event. For this reason the +implementation shares the same device recovery path (and honors the same +quirks) as the system resume path for the hub. + +[1]: http://dl.dropbox.com/u/96820575/sarah-sharp-lpt-port-power-off2-mini.pdf +[2]: http://linuxplumbers.ubicast.tv/videos/usb-port-power-off-kerneluserspace-api/ +[3]: USB 3.1 Section 10.12 +* wakeup note: if a device is configured to send wakeup events the port + power control implementation will block poweroff attempts on that + port. + + + User Interface for Port Power Control + - + +The port power control mechanism uses the PM runtime system. Poweroff is +requested by clearing the power/pm_qos_no_power_off flag of the port device +(defaults to 1). If the port is disconnected it will immediately receive a +ClearPortFeature(PORT_POWER) request. Otherwise, it will honor the pm runtime +rules and require the attached child device and all descendants to be suspended. +This mechanism is dependent on the hub advertising port power switching in its +hub descriptor (wHubCharacteristics logical power switching mode field). + +Note, some interface devices/drivers do not support autosuspend. Userspace may +need to unbind the interface drivers before the usb_device will suspend. An +unbound interface device is suspended by default. When unbinding, be careful +to unbind interface drivers, not the driver of the parent
Re: [PATCH v2 0/4] port power control rework stragglers
On Mon, Jun 02, 2014 at 02:49:57PM -0700, Dan Williams wrote: Changes since v1 [1]: 1/ Deleted usb: fix hub_handle_remote_wakeup() only exists for CONFIG_PM=y in favor of the full refactoring of hub.c into hub.c/hub_pm.c Now that the merge window is open, I'd really not like to take anything so big as these patches for the 3.16-rc1 tree. So, how about I just take Stephen's original patch for now, and then you rebase these on 3.16-rc1 when it comes out for 3.17-rc1? 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: [PATCH v2 0/4] port power control rework stragglers
On Mon, Jun 2, 2014 at 3:02 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Jun 02, 2014 at 02:49:57PM -0700, Dan Williams wrote: Changes since v1 [1]: 1/ Deleted usb: fix hub_handle_remote_wakeup() only exists for CONFIG_PM=y in favor of the full refactoring of hub.c into hub.c/hub_pm.c Now that the merge window is open, I'd really not like to take anything so big as these patches for the 3.16-rc1 tree. So, how about I just take Stephen's original patch for now, and then you rebase these on 3.16-rc1 when it comes out for 3.17-rc1? That's reasonable. -- 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 3.15-rc8
The following changes since commit d6d211db37e75de2ddc3a4f979038c40df7cc79c: Linux 3.15-rc5 (2014-05-09 13:10:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.15-rc8 for you to fetch changes up to 5dc2808c4729bf080487e61b80ee04e0fdb12a37: xhci: delete endpoints from bandwidth list before freeing whole device (2014-05-28 14:53:53 -0700) USB fixes for 3.15-rc8 Here are some fixes for 3.15-rc8 that resolve a number of tiny USB issues that have been reported, and there are some new device ids as well. All have been tested in linux-next. Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Alan Stern (1): USB: Avoid runtime suspend loops for HCDs that can't handle suspend/resume Alexej Starschenko (1): USB: serial: option: add support for Novatel E371 PCIe card Bjørn Mork (1): usb: cdc-wdm: export cdc-wdm uapi header George McCollister (1): USB: ftdi_sio: add NovaTech OrionLXm product ID Greg Kroah-Hartman (1): USB: cdc-wdm: properly include types.h Johan Hovold (1): USB: io_ti: fix firmware download on big-endian machines (part 2) Mathias Nyman (2): usb: pci-quirks: Prevent Sony VAIO t-series from switching usb ports xhci: delete endpoints from bandwidth list before freeing whole device drivers/usb/core/driver.c | 9 ++--- drivers/usb/core/hub.c| 15 +-- drivers/usb/host/pci-quirks.c | 7 +++ drivers/usb/host/xhci-mem.c | 20 ++-- drivers/usb/serial/ftdi_sio.c | 2 ++ drivers/usb/serial/ftdi_sio_ids.h | 5 + drivers/usb/serial/io_ti.c| 2 +- drivers/usb/serial/io_usbvend.h | 2 +- drivers/usb/serial/option.c | 2 ++ include/uapi/linux/usb/Kbuild | 1 + include/uapi/linux/usb/cdc-wdm.h | 2 ++ 11 files changed, 50 insertions(+), 17 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
Re: [PATCH v2 net-next 0/8] cdc_ncm: fixes and conversion to sysfs API
From: Bjørn Mork bj...@mork.no Date: Fri, 30 May 2014 09:31:02 +0200 After considering the comments received after the ethtool coalesce support was commited, I have ended up concluding that we should remove it again, while we can, before it hits a release. The idea was not well enough thought through, and all comments received pointed to advantages of using a sysfs based API instead. This series removes the ethtool coalesce support and replaces it with sysfs attributes in a driver specific group under the netdev. The first 3 patches are unrelated fixes: patch 1: reducing truesize as discussed patch 2: fixing a potentional buffer overrun when changing tx_max patch 3: prevent framing errors when changing rx_max Changes v2: - minor editorial changes to patch 8, as suggested by Peter Stuge Generally speaking I wouldn't be OK with using sysfs for this stuff, but you make a very convincing argument for doing so in this specific case. Series applied, 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] usb: renesas: gadget: fixup: complete STATUS stage after receiving
Hi Sergei
+ /*
+* Transmission end
+*/
+ if (*is_done) {
+ if (usbhs_pipe_is_dcp(pipe))
Why not collapse these into single *if*? That would decrease the
indentation level...
This is same style with TX case
--
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 driver patches for 3.16-rc1
The following changes since commit d6d211db37e75de2ddc3a4f979038c40df7cc79c: Linux 3.15-rc5 (2014-05-09 13:10:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.16-rc1 for you to fetch changes up to 4a95b1fce97756d0333f8232eb7ed6974e93b054: usb: hub_handle_remote_wakeup() only exists for CONFIG_PM=y (2014-06-02 15:16:33 -0700) USB driver patches for 3.16-rc1 Here is the big USB driver pull request for 3.16-rc1. Nothing huge here, but lots of little things in the USB core, and in lots of drivers. Hopefully the USB power management will be work better now that it has been reworked to do per-port power control dynamically. There's also a raft of gadget driver updates and fixes, CONFIG_USB_DEBUG is finally gone now that everything has been converted over to the dynamic debug inteface, the last hold-out drivers were cleaned up and the config option removed. There were also other minor things all through the drivers/usb/ tree, the shortlog shows this pretty well. All have been in linux-next, including the very last patch, which came from linux-next to fix a build issue on some platforms. Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Alan Stern (1): USB: mutual exclusion for resetting a hub and power-managing a port Aleksander Morgado (2): usb: qcserial: add Netgear AirCard 341U usb: qcserial: add additional Sierra Wireless QMI devices Alexander Gordeev (1): xhci: Use pci_enable_msix_exact() instead of pci_enable_msix() Alexander Shiyan (1): usb: chipidea: core: Add missing module owner field Alexandre Belloni (1): usb: gadget: atmel_usba: always test udc-driver Alexey Khoroshilov (1): usb: gadget: gr_udc: unconditionally use GFP_ATOMIC in gr_queue_ext() Andreas Larsson (7): usb: gadget: gr_udc: improve platform_device variable name usb: gadget: gr_udc: Expand devicetree documentation usb: gadget: gr_udc: Use platform_get_irq instead of irq_of_parse_and_map usb: gadget: gr_udc: Use of_property_read_u32_index to access arrays usb: gadget: gr_udc: Add ep.maxpacket_limit to debugfs information usb: gadget: gr_udc: Return error code when trying to set ep.maxpacket ep.maxpacket_limit usb: gadget: gr_udc: Use GFP_ATOMIC when allocating under held spinlock Andrzej Pietrasiewicz (9): usb: gadget: FunctionFS: share VLA macros with all usb gadget files usb: gadget: OS String support usb: gadget: OS Feature Descriptors support usb: gadget: f_rndis: OS descriptors support usb: gadget: configfs: OS String support usb: gadget: configfs: OS Extended Compatibility descriptors support usb: gadget: f_rndis: OS Descriptors configfs support usb: gadget: configfs: OS Extended Properties descriptors support usb: gadget: f_uac2: don't queue new requests when shutting down Andy Shevchenko (2): usb: dwc3: no need to initialize ret variable usb: dwc3: convert to pcim_enable_device() Antoine Ténart (1): phy: exynos-mipi-video: fix check on array index Apelete Seketeli (1): documentation: docbook: document process of writing an musb glue layer Arnd Bergmann (9): PHY: Exynos: fix SATA phy license typo phy: kona2: use 'select GENERIC_PHY' in Kconfig usb: gadget: s3c2410_udc: don't use pr_debug return value usb: musb: tusb-dma can't be built-in if tusb is not usb: musb: omap2plus bus glue needs USB host support usb: phy: msm: reset controller is mandatory now usb: xhci: avoid warning for !PM_SLEEP usb: ohci-da8xx can only be built-in usb: ohci: sort out dependencies for lpc32xx and omap Benoit Taine (1): USB: storage: ene_ub6250: Use kmemdup instead of kmalloc + memcpy Bjørn Mork (4): usb: qcserial: fix multiline comment coding style usb: qcserial: refactor device layout selection usb: qcserial: define and use Sierra Wireless layout usb: qcserial: remove interface number matching Boris BREZILLON (1): usb: ehci-platform: add optional reset controller retrieval Dan Carpenter (2): usb: phy: msm: change devm_ioremap() to devm_ioremap_resource() usb: phy: msm: fix bug in probe() Dan Williams (17): usb: catch attempts to submit urbs with a vmalloc'd transfer buffer usb: disable port power control if not supported in wHubCharacteristics usb: rename usb_port device objects usb: cleanup setting udev-removable from port_dev-connect_type usb: assign default peer ports for root hubs usb: assign usb3 external hub port peers usb: find internal hub tier mismatch via acpi usb: sysfs link peer ports usb: make usb_port flags atomic, rename did_runtime_put to child_usage usb: block suspension
