- 13 Jan, 2014 10 commits
-
-
Peter Chen authored
We have met a bug that the high bandwidth ISO-TX transfer has failed at the last packet if it is less than 1024, the TD status shows it is "Transaction Error". The root cause of this problem is: the mult value at qh is not correct for current TD's transfer length. We use TD list to queue un-transfer TDs, and change mult for new adding TDs. If new adding TDs transfer length less than 1024, but the queued un-transfer TDs transfer length is larger than 1024, the transfer error will occur, and vice versa. Usually, this problem occurs at the last packet, and the first packet for new frame. We fixed this problem by setting Mult at QH as the largest value (3), and set MultO (Multiplier Override) at TD according to every transfer length. It can cover both hardware version less than 2.3 (the real mult is MultO if it is not 0) and 2.3+ (the real mult is min(qh.mult, td.multo)). Since the MultO bits are only existed at TX TD, we keep the ISO-RX behavior unchanged. For stable tree: 3.11+. Cc: stable <stable@vger.kernel.org> Cc: Michael Grzeschik <m.grzeschik@pengutronix.de> Reported-by:
Matthieu Vanin <b47495@freescale.com> Tested-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Chen authored
For otgsc, both enable bits and status bits are in it. So we need to make sure the status bits are not be cleared when write enable bits. It can fix one bug that we plug in/out Micro AB cable fast, and sometimes, the IDIS will be cleared wrongly when handle last ID interrupt (ID 0->1), so the current interrupt will not occur. For stable tree: 3.12+ Cc: stable@vger.kernel.org Signed-off-by:
-
Chris Ruehl authored
hw_phymode_configure configures the PORTSC registers and allow the following phy_inits to operate on the right parameters. This fix a problem where the UPLI (ISP1504) could not be detected, because the Viewport was not available and read the viewport return 0's only. Signed-off-by:
Chris Ruehl <chris.ruehl@gtsys.com.hk> Signed-off-by:
-
Chris Ruehl authored
* init the sts flag to 0 (missed) * fix write the real bit not sts value * Set PORTCS_STS and DEVLC_STS only if sts = 1 [Peter Chen: This one and the next patch fix the problem occurred imx27 and imx31, and imx27 and imx31 usb support are enabled until 3.14, so these two patches isn't needed for -stable] Signed-off-by:
-
Peter Chen authored
Due to imx28 needs ARM swp instruction for writing, we set CI_HDRC_IMX28_WRITE_FIX for imx28. This patch is needed for stable tree 3.11+ Cc: stable@vger.kernel.org Cc: robert.hodaszi@digi.com Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Tested-by:
-
Peter Chen authored
According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB register error issue", All USB register write operations must use the ARM SWP instruction. So, we implement special hw_write and hw_test_and_clear for imx28. Discussion for it at below: http://marc.info/?l=linux-usb&m=137996395529294&w=2 This patch is needed for stable tree 3.11+. Cc: stable@vger.kernel.org Cc: robert.hodaszi@digi.com Signed-off-by:
-
Peter Chen authored
According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB register error issue", All USB register write operations must use the ARM SWP instruction. So, we implement a special ehci_write for imx28. Discussion for it at below: http://marc.info/?l=linux-usb&m=137996395529294&w=2 Without this patcheset, imx28 works unstable at high AHB bus loading. If the bus loading is not high, the imx28 usb can work well at the most of time. There is a IC errata for this problem, usually, we consider IC errata is a problem not a new feature, and this workaround is needed for that, so we need to add them to stable tree 3.11+. Cc: stable@vger.kernel.org Cc: robert.hodaszi@digi.com Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Wolfram Sang authored
When implementing the RefId feature, it was missed that id_tables can be NULL under special circumstances. Bail out in that case. Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Bjørn Mork authored
Do not decrement resp_count if it's already 0. We set resp_count to 0 when the device is closed. The next open and read will try to clear the WDM_READ flag if there was leftover data in the read buffer. This fix is necessary to prevent resubmitting the read URB in a tight loop because resp_count becomes negative. The bug can easily be triggered from userspace by not reading all data in the read buffer, and then closing and reopening the chardev. Fixes: 8dd5cd53 ("usb: cdc-wdm: avoid hanging on zero length reads") Cc: <stable@vger.kernel.org> # 3.13 Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Wolfram Sang authored
If users use the new RefId feature of new_id, give them an error message if they provided an unknown reference. That helps detecting typos. Signed-off-by:
-
- 11 Jan, 2014 2 commits
-
-
Wolfram Sang authored
Often, usb drivers need some driver_info to get a device to work. To have access to driver_info when using new_id, allow to pass a reference vendor:product tuple from which new_id will inherit driver_info. Signed-off-by:
-
Wolfram Sang authored
Check if that field is actually used and if so, bail out if it exeeds a u8. Make it also future-proof by not requiring "exactly three" parameters in new_id, but simply "more than two". Signed-off-by:
-
- 08 Jan, 2014 27 commits
-
-
Rahul Bedarkar authored
Signed-off-by:
Rahul Bedarkar <rahulbedarkar89@gmail.com> Signed-off-by:
-
Rahul Bedarkar authored
Signed-off-by:
-
Paul Gortmaker authored
None of these files are actually using any __init type directives and hence don't need to include <linux/init.h>. Most are just a left over from __devinit and __cpuinit removal, or simply due to code getting copied from one driver to the next. Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Shen Guang authored
When we are doing compliance test with xHCI, we found that if we enable CONFIG_USB_SUSPEND and plug in a bad device which causes over-current condition to the root port, software will not be noticed. The reason is that current code don't set hub->change_bits in hub_activate() when over-current happens, and then hub_events() will not check the port status because it thinks nothing changed. If CONFIG_USB_SUSPEND is disabled, the interrupt pipe of the hub will report the change and set hub->event_bits, and then hub_events() will check what events happened.In this case over-current can be detected. Signed-off-by:
Shen Guang <shenguang10@gmail.com> Acked-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 30666249, as it depended on a previous patch that I rejected, causing a build error here. Sorry about that. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Peter Chen <peter.chen@freescale.com> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Greg Kroah-Hartman authored
Merge tag 'for-usb-next-2014-01-08' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next Sarah writes: xhci: Urgent bug fixes for usb-next and 3.14. Hi Greg, Please queue these two patches to usb-next for 3.14. An xHCI driver fix for USB ethernet devices that went into 3.13 and 3.12 stable is causing usb-storage to go into an infinite loop, and these two patches fix the issue. I would like these to get into 3.14-rc1 so we can avoid any potential data corruption for users. Sarah Sharp
-
Sarah Sharp authored
Commit 35773dac "usb: xhci: Link TRB must not occur within a USB payload burst" attempted to fix an issue found with USB ethernet adapters, and inadvertently broke USB storage devices. The patch attempts to ensure that transfers never span a segment, and rejects transfers that have more than 63 entries (or possibly less, if some entries cross 64KB boundaries). usb-storage limits the maximum transfer size to 120K, and we had assumed the block layer would pass a scatter-gather list of 4K entries, resulting in no more than 31 sglist entries: http://marc.info/?l=linux-usb&m=138498190419312&w=2 That assumption was wrong, since we've seen the driver reject a write that was 218 sectors long (of probably 512 bytes each): Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd 0000:00:14.0: Too many fragments 79, max 63 ... Jan 1 07:04:58 jidanni5 kernel: [ 568.622583] Write(10): 2a 00 00 06 85 0e 00 00 da 00 Limit the number of scatter-gather entries to half a ring segment. That should be margin enough in case some entries cross 64KB boundaries. Increase the number of TRBs per segment from 64 to 256, which should result in ring segments fitting on a 4K page. Signed-off-by:
-
Ben Hutchings authored
Currently prepare_ring() returns -ENOMEM if the urb won't fit into a single ring segment. usb_sg_wait() treats this error as a temporary condition and will keep retrying until something else goes wrong. The number of retries should be limited in usb_sg_wait(), but also prepare_ring() should not return an error code that suggests it might be worth retrying. Change it to -EINVAL. Reported-by: jidanni@jidanni.org References: http://bugs.debian.org/733907 Fixes: 35773dac ('usb: xhci: Link TRB must not occur within a USB payload burst') Cc: stable <stable@vger.kernel.org> # 3.12 Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Wei Yongjun authored
The variable 'dev' is initialized but never used otherwise, so remove the unused variable. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
Wei Yongjun authored
Remove duplicated include. Signed-off-by:
-
Colin Leitner authored
Genuine FTDI chips support only CS7/8. A previous fix in commit 8704211f ("USB: ftdi_sio: fixed handling of unsupported CSIZE setting") enforced this limitation and reported it back to userspace. However, certain types of smartcard readers depend on specific driver behaviour that requests 0 data bits (not 5) to change into a different operating mode if CS5 has been set. This patch reenables this behaviour for all FTDI devices. Tagged to be added to stable, because it affects a lot of users of embedded systems which rely on these readers to work properly. Cc: stable <stable@vger.kernel.org> Reported-by:
Heinrich Siebmanns <H.Siebmanns@t-online.de> Tested-by:
Colin Leitner <colin.leitner@gmail.com> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Peter Chen authored
Due to imx28 needs ARM swp instruction for writing, we set CI_HDRC_IMX28_WRITE_FIX for imx28. Signed-off-by:
-
Peter Chen authored
We have already renamed the file name, change doc name at this patch. Cc: devicetree@vger.kernel.org Cc: linux-doc@vger.kernel.org Signed-off-by:
-
Marc Kleine-Budde authored
This patch makes the controller register map ci_regs_nolpm and ci_regs_lpm as "const". Further, as all offset fit into a single byte, the type is changed from uintptr_t to u8. Signed-off-by:
-
Marc Kleine-Budde authored
Without this patch a seperate chunk of memory is allocated for the regmap array. As the regmap is always used it makes no sense to allocate a seperate memory block for it, this patch moves the regmap array directly into the struct hw_bank. Signed-off-by:
-
Rahul Bedarkar authored
Signed-off-by:
-
Rahul Bedarkar authored
Signed-off-by:
-
Rahul Bedarkar authored
Signed-off-by:
-
Rahul Bedarkar authored
Signed-off-by:
-
Rahul Bedarkar authored
Signed-off-by:
-
Rahul Bedarkar authored
Signed-off-by:
-
Rahul Bedarkar authored
Signed-off-by:
-
Rahul Bedarkar authored
Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Rahul Bedarkar authored
Signed-off-by:
-
Greg Kroah-Hartman authored
CONFIG_USB_DEBUG is going away, and all of the other USB drivers no longer rely on "debug" module parameters for debugging lines, so move the pcwd_usb driver to use the dynamic debug infrastructure to be more in line with the rest of the kernel. Signed-off-by:
Guenter Roeck <linux@roeck-us.net>
-
Max Filippov authored
This fixes the following warning: BUG: sleeping function called from invalid context at mm/slub.c:940 in_atomic(): 1, irqs_disabled(): 1, pid: 17, name: khubd CPU: 0 PID: 17 Comm: khubd Not tainted 3.12.0-00004-g938dd60-dirty #1 __might_sleep+0xbe/0xc0 kmem_cache_alloc_trace+0x36/0x170 c67x00_urb_enqueue+0x5c/0x254 usb_hcd_submit_urb+0x66e/0x724 usb_submit_urb+0x2ac/0x308 usb_start_wait_urb+0x2c/0xb8 usb_control_msg+0x8c/0xa8 hub_port_init+0x191/0x718 hub_thread+0x804/0xe14 kthread+0x72/0x78 ret_from_kernel_thread+0x8/0xc Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Acked-by:
Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
-
Max Filippov authored
According to CY7C67300 specification HPI read and write cycle duration Tcyc must be at least 6T long, where T is 1/48MHz, which is 125ns. Without this delay fast host processor cannot write to chip registers. Add proper ndelay to hpi_{read,write}_reg. Signed-off-by:
-
- 07 Jan, 2014 1 commit
-
-
Alan Stern authored
There is a race in the hub driver between hub_disconnect() and recursively_mark_NOTATTACHED(). This race can be triggered if the driver is unbound from a device at the same time as the bus's root hub is removed. When the race occurs, it can cause an oops: BUG: unable to handle kernel NULL pointer dereference at 0000015c IP: [<c16d5fb0>] recursively_mark_NOTATTACHED+0x20/0x60 Call Trace: [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d6082>] usb_set_device_state+0x92/0x120 [<c16d862b>] usb_disconnect+0x2b/0x1a0 [<c16dd4c0>] usb_remove_hcd+0xb0/0x160 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50 [<c1704efc>] ehci_mid_remove+0x1c/0x30 [<c1704f26>] ehci_mid_stop_host+0x16/0x30 [<c16f7698>] penwell_otg_work+0xd28/0x3520 [<c19c945b>] ? __schedule+0x39b/0x7f0 [<c19cdb9d>] ? sub_preempt_count+0x3d/0x50 [<c125e97d>] process_one_work+0x11d/0x3d0 [<c19c7f4d>] ? mutex_unlock+0xd/0x10 [<c125e0e5>] ? manage_workers.isra.24+0x1b5/0x270 [<c125f009>] worker_thread+0xf9/0x320 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50 [<c125ef10>] ? rescuer_thread+0x2b0/0x2b0 [<c1264ac4>] kthread+0x94/0xa0 [<c19d0f77>] ret_from_kernel_thread+0x1b/0x28 [<c1264a30>] ? kthread_create_on_node+0xc0/0xc0 One problem is that recursively_mark_NOTATTACHED() uses the intfdata value and hub->hdev->maxchild while hub_disconnect() is clearing them. Another problem is that it uses hub->ports[i] while the port device is being released. To fix this race, we need to hold the device_state_lock while hub_disconnect() changes the values. (Note that usb_disconnect() and hub_port_connect_change() already acquire this lock at similar critical times during a USB device's life cycle.) We also need to remove the port devices after maxchild has been set to 0, instead of before. Signed-off-by:
"Du, Changbin" <changbinx.du@intel.com> Tested-by:
-
