Skip to contentSkip to conversation

3.4.30-stable review

PATCH In review Greg Kroah-Hartman 3 participants 29 messages Feb 8, 2013 – Feb 9, 2013

Subsystems (13)
Stable branch DRM drivers x86 USB +9 more subsystems
lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 3.4.30-stable review

This is the start of the stable review cycle for the 3.4.30 release. There are 26 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Feb 10 00:43:18 UTC 2013. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.30-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 3.4.30-rc1

David Moore <[email protected]>
usb: Prevent dead ports when xhci is not enabled

Alan Stern <[email protected]>
USB: XHCI: fix memory leak of URB-private data

Sarah Sharp <[email protected]>
xhci: Fix TD size for isochronous URBs.

Sarah Sharp <[email protected]>
xhci: Fix isoc TD encoding.

Nickolai Zeldovich <[email protected]>
drivers: xhci: fix incorrect bit test

fangxiaozhi <[email protected]>
USB: storage: optimize to match the Huawei USB storage devices and support new switch command

fangxiaozhi <[email protected]>
USB: storage: Define a new macro for USB storage match rules

Lan Tianyu <[email protected]>
usb: Using correct way to clear usb3.0 device's remote wakeup feature.

Alan Stern <[email protected]>
USB: EHCI: fix bug in scheduling periodic split transfers

Alan Stern <[email protected]>
USB: EHCI: fix timer bug affecting port resume

Daniele Palmas <[email protected]>
USB: qcserial: add Telit Gobi QDL device

Bjørn Mork <[email protected]>
USB: option: add Changhong CH690

Daniele Palmas <[email protected]>
USB: option: add support for Telit LE920

Sven Killig <[email protected]>
USB: ftdi_sio: add PID/VID entries for ELV WS 300 PC II

Petr Kubánek <[email protected]>
USB: ftdi_sio: add Zolix FTDI PID

Jan Luebbe <[email protected]>
drivers/rtc/rtc-isl1208.c: call rtc_update_irq() from the alarm irq handler

Vyacheslav Dubeyko <[email protected]>
nilfs2: fix fix very long mount time issue

Shawn Bohrer <[email protected]>
sched/rt: Use root_domain of rt_rq not current processor

Jan Beulich <[email protected]>
x86-64: Replace left over sti/cli in ia32 audit exit code

liu chuansheng <[email protected]>
drm/radeon: Calling object_unrefer() when creating fb failure

Alex Deucher <[email protected]>
drm/radeon: prevent crash in the ring space allocation

Christopher Staite <[email protected]>
drm/radeon: fix MC blackout on evergreen+

Alex Deucher <[email protected]>
drm/radeon: add quirk for RV100 board

Alex Deucher <[email protected]>
drm/radeon: add WAIT_UNTIL to the non-VM safe regs list for cayman/TN

Alex Deucher <[email protected]>
drm/radeon/evergreen+: wait for the MC to settle after MC blackout

YOSHIFUJI Hideaki <[email protected]>
digsig: Fix memory leakage in digsig_verify_rsa()

-------------

Diffstat:

 Makefile                                |   4 +-
 arch/x86/ia32/ia32entry.S               |   4 +-
 drivers/gpu/drm/radeon/evergreen.c      |  10 +
 drivers/gpu/drm/radeon/radeon_combios.c |   8 +
 drivers/gpu/drm/radeon/radeon_display.c |   4 +-
 drivers/gpu/drm/radeon/radeon_ring.c    |   3 +
 drivers/gpu/drm/radeon/reg_srcs/cayman  |   1 +
 drivers/rtc/rtc-isl1208.c               |   3 +
 drivers/usb/core/hub.c                  |  70 +++++--
 drivers/usb/host/ehci-hub.c             |   6 +-
 drivers/usb/host/ehci-sched.c           |   2 +-
 drivers/usb/host/pci-quirks.c           |   1 +
 drivers/usb/host/xhci-ring.c            |  13 +-
 drivers/usb/serial/ftdi_sio.c           |   2 +
 drivers/usb/serial/ftdi_sio_ids.h       |   9 +-
 drivers/usb/serial/option.c             |  13 ++
 drivers/usb/serial/qcserial.c           |   1 +
 drivers/usb/storage/initializers.c      |  76 +++++++-
 drivers/usb/storage/initializers.h      |   4 +-
 drivers/usb/storage/unusual_devs.h      | 329 +-------------------------------
 drivers/usb/storage/usb.c               |  12 ++
 drivers/usb/storage/usual-tables.c      |  15 ++
 fs/nilfs2/ioctl.c                       |   5 +-
 include/linux/usb/ch9.h                 |   6 +
 kernel/sched/rt.c                       |   2 +-
 lib/digsig.c                            |   2 +
 26 files changed, 242 insertions(+), 363 deletions(-)
author maintainer
#1 lore raw

PATCH 1/26 digsig: Fix memory leakage in digsig_verify_rsa()

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: YOSHIFUJI Hideaki <[email protected]>

commit 7810cc1e7721220f1ed2a23ca95113d6434f6dcd upstream.

digsig_verify_rsa() does not free kmalloc'ed buffer returned by mpi_get_buffer().

---
 lib/digsig.c |    2 ++
 1 file changed, 2 insertions(+)
lib/digsig.c +2 -0
@@ -162,6 +162,8 @@ static int digsig_verify_rsa(struct key
 	memset(out1, 0, head);
 	memcpy(out1 + head, p, l);
 
+	kfree(p);
+
 	err = pkcs_1_v1_5_decode_emsa(out1, len, mblen, out2, &len);
 	if (err)
 		goto err;
author maintainer
#2 lore raw

PATCH 2/26 drm/radeon/evergreen+: wait for the MC to settle after MC blackout

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alex Deucher <[email protected]>

commit ed39fadd6df01095378e499fac3674883f16b853 upstream.

Some chips seem to need a little delay after blacking out the MC before the requests actually stop.

May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139
https://bugs.freedesktop.org/show_bug.cgi?id=57567

---
 drivers/gpu/drm/radeon/evergreen.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/gpu/drm/radeon/evergreen.c +2 -0
@@ -1179,6 +1179,8 @@ void evergreen_mc_stop(struct radeon_dev
 		blackout &= ~BLACKOUT_MODE_MASK;
 		WREG32(MC_SHARED_BLACKOUT_CNTL, blackout | 1);
 	}
+	/* wait for the MC to settle */
+	udelay(100);
 }
 
 void evergreen_mc_resume(struct radeon_device *rdev, struct evergreen_mc_save *save)
author maintainer
#3 lore raw

PATCH 3/26 drm/radeon: add WAIT_UNTIL to the non-VM safe regs list for cayman/TN

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alex Deucher <[email protected]>

commit 674a16f2b4724880d07389abbb95abf320b924aa upstream.

Newer versions of mesa emit this.

---
 drivers/gpu/drm/radeon/reg_srcs/cayman |    1 +
 1 file changed, 1 insertion(+)
drivers/gpu/drm/radeon/reg_srcs/cayman +1 -0
@@ -1,5 +1,6 @@
 cayman 0x9400
 0x0000802C GRBM_GFX_INDEX
+0x00008040 WAIT_UNTIL
 0x000084FC CP_STRMOUT_CNTL
 0x000085F0 CP_COHER_CNTL
 0x000085F4 CP_COHER_SIZE
author maintainer
#4 lore raw

PATCH 4/26 drm/radeon: add quirk for RV100 board

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alex Deucher <[email protected]>

commit 9200ee4941a6e5d1ec5df88982243686882dff3f upstream.

vbios says external TMDS while the board is actually internal TMDS.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=60037

---
 drivers/gpu/drm/radeon/radeon_combios.c |    8 ++++++++
 1 file changed, 8 insertions(+)
drivers/gpu/drm/radeon/radeon_combios.c +8 -0
@@ -2338,6 +2338,14 @@ bool radeon_get_legacy_connector_info_fr
 								   1),
 								  ATOM_DEVICE_CRT1_SUPPORT);
 				}
+				/* RV100 board with external TDMS bit mis-set.
+				 * Actually uses internal TMDS, clear the bit.
+				 */
+				if (dev->pdev->device == 0x5159 &&
+				    dev->pdev->subsystem_vendor == 0x1014 &&
+				    dev->pdev->subsystem_device == 0x029A) {
+					tmp &= ~(1 << 4);
+				}
 				if ((tmp >> 4) & 0x1) {
 					devices |= ATOM_DEVICE_DFP2_SUPPORT;
 					radeon_add_legacy_encoder(dev,
author maintainer
#5 lore raw

PATCH 5/26 drm/radeon: fix MC blackout on evergreen+

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christopher Staite <[email protected]>

commit bb588820ef421c6098dca1fec29c3b347f1c8c19 upstream.

Force the crtc mem requests on/off immediately rather than waiting for the double buffered updates to kick in. Seems we miss the update in certain conditions. Also handle the DCE6 case.

---
 drivers/gpu/drm/radeon/evergreen.c |    8 ++++++++
 1 file changed, 8 insertions(+)
drivers/gpu/drm/radeon/evergreen.c +8 -0
@@ -1147,14 +1147,18 @@ void evergreen_mc_stop(struct radeon_dev
 				if (!(tmp & EVERGREEN_CRTC_BLANK_DATA_EN)) {
 					radeon_wait_for_vblank(rdev, i);
 					tmp |= EVERGREEN_CRTC_BLANK_DATA_EN;
+					WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 1);
 					WREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i], tmp);
+					WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 0);
 				}
 			} else {
 				tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]);
 				if (!(tmp & EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE)) {
 					radeon_wait_for_vblank(rdev, i);
 					tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;
+					WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 1);
 					WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
+					WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 0);
 				}
 			}
 			/* wait for the next frame */
@@ -1214,11 +1218,15 @@ void evergreen_mc_resume(struct radeon_d
 			if (ASIC_IS_DCE6(rdev)) {
 				tmp = RREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i]);
 				tmp |= EVERGREEN_CRTC_BLANK_DATA_EN;
+				WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 1);
 				WREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i], tmp);
+				WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 0);
 			} else {
 				tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]);
 				tmp &= ~EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;
+				WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 1);
 				WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
+				WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 0);
 			}
 			/* wait for the next frame */
 			frame_count = radeon_get_vblank_counter(rdev, i);
author maintainer
#6 lore raw

PATCH 6/26 drm/radeon: prevent crash in the ring space allocation

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alex Deucher <[email protected]>

commit fd5d93a0015ce1a7db881382022b2fcdfdc61760 upstream.

If the requested number of DWs on the ring is larger than the size of the ring itself, return an error.

In testing with large VM updates, we've seen crashes when we try and allocate more space on the ring than the total size of the ring without checking.

This prevents the crash but for large VM updates or bo moves of very large buffers, we will need to break the transaction down into multiple batches. I have patches to use IBs for the next kernel.

---
 drivers/gpu/drm/radeon/radeon_ring.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/gpu/drm/radeon/radeon_ring.c +3 -0
@@ -311,6 +311,9 @@ int radeon_ring_alloc(struct radeon_devi
 {
 	int r;
 
+	/* make sure we aren't trying to allocate more space than there is on the ring */
+	if (ndw > (ring->ring_size / 4))
+		return -ENOMEM;
 	/* Align requested size with padding so unlock_commit can
 	 * pad safely */
 	ndw = (ndw + ring->align_mask) & ~ring->align_mask;
author maintainer
#7 lore raw

PATCH 7/26 drm/radeon: Calling object_unrefer() when creating fb failure

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: liu chuansheng <[email protected]>

commit f2d68cf4daa4de97d400d94836b907e35228e54f upstream.

When kzalloc() failed in radeon_user_framebuffer_create(), need to call object_unreference() to match the object_reference().

---
 drivers/gpu/drm/radeon/radeon_display.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/gpu/drm/radeon/radeon_display.c +3 -1
@@ -1129,8 +1129,10 @@ radeon_user_framebuffer_create(struct dr
 	}
 
 	radeon_fb = kzalloc(sizeof(*radeon_fb), GFP_KERNEL);
-	if (radeon_fb == NULL)
+	if (radeon_fb == NULL) {
+		drm_gem_object_unreference_unlocked(obj);
 		return ERR_PTR(-ENOMEM);
+	}
 
 	ret = radeon_framebuffer_init(dev, radeon_fb, mode_cmd, obj);
 	if (ret) {
author maintainer
#8 lore raw

PATCH 8/26 x86-64: Replace left over sti/cli in ia32 audit exit code

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jan Beulich <[email protected]>

commit 40a1ef95da85843696fc3ebe5fce39b0db32669f upstream.

For some reason they didn't get replaced so far by their paravirt equivalents, resulting in code to be run with interrupts disabled that doesn't expect so (causing, in the observed case, a BUG_ON() to trigger) when syscall auditing is enabled.

David (Cc-ed) came up with an identical fix, so likely this can be taken to count as an ack from him.

---
 arch/x86/ia32/ia32entry.S |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/ia32/ia32entry.S +2 -2
@@ -205,7 +205,7 @@ sysexit_from_sys_call:
 	testl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
 	jnz ia32_ret_from_sys_call
 	TRACE_IRQS_ON
-	sti
+	ENABLE_INTERRUPTS(CLBR_NONE)
 	movl %eax,%esi		/* second arg, syscall return value */
 	cmpl $-MAX_ERRNO,%eax	/* is it an error ? */
 	jbe 1f
@@ -215,7 +215,7 @@ sysexit_from_sys_call:
 	call __audit_syscall_exit
 	movq RAX-ARGOFFSET(%rsp),%rax	/* reload syscall return value */
 	movl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT),%edi
-	cli
+	DISABLE_INTERRUPTS(CLBR_NONE)
 	TRACE_IRQS_OFF
 	testl %edi,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
 	jz \exit
author maintainer
#9 lore raw

PATCH 9/26 sched/rt: Use root_domain of rt_rq not current processor

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Shawn Bohrer <[email protected]>

commit aa7f67304d1a03180f463258aa6f15a8b434e77d upstream.

When the system has multiple domains do_sched_rt_period_timer() can run on any CPU and may iterate over all rt_rq in cpu_online_mask. This means when balance_runtime() is run for a given rt_rq that rt_rq may be in a different rd than the current processor. Thus if we use smp_processor_id() to get rd in do_balance_runtime() we may borrow runtime from a rt_rq that is not part of our rd.

This changes do_balance_runtime to get the rd from the passed in rt_rq ensuring that we borrow runtime only from the correct rd for the given rt_rq.

This fixes a BUG at kernel/sched/rt.c:687! in __disable_runtime when we try reclaim runtime lent to other rt_rq but runtime has been lent to a rt_rq in another rd.

---
 kernel/sched/rt.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/sched/rt.c +1 -1
@@ -560,7 +560,7 @@ static inline struct rt_bandwidth *sched
 static int do_balance_runtime(struct rt_rq *rt_rq)
 {
 	struct rt_bandwidth *rt_b = sched_rt_bandwidth(rt_rq);
-	struct root_domain *rd = cpu_rq(smp_processor_id())->rd;
+	struct root_domain *rd = rq_of_rt_rq(rt_rq)->rd;
 	int i, weight, more = 0;
 	u64 rt_period;
 
author maintainer
#10 lore raw

PATCH 10/26 nilfs2: fix fix very long mount time issue

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vyacheslav Dubeyko <[email protected]>

commit a9bae189542e71f91e61a4428adf6e5a7dfe8063 upstream.

There exists a situation when GC can work in background alone without any other filesystem activity during significant time.

The nilfs_clean_segments() method calls nilfs_segctor_construct() that updates superblocks in the case of NILFS_SC_SUPER_ROOT and THE_NILFS_DISCONTINUED flags are set. But when GC is working alone the nilfs_clean_segments() is called with unset THE_NILFS_DISCONTINUED flag. As a result, the update of superblocks doesn't occurred all this time and in the case of SPOR superblocks keep very old values of last super root placement.

SYMPTOMS:

Trying to mount a NILFS2 volume after SPOR in such environment ends with very long mounting time (it can achieve about several hours in some cases).

REPRODUCING PATH:

1. It needs to use external USB HDD, disable automount and doesn't make any additional filesystem activity on the NILFS2 volume.

2. Generate temporary file with size about 100 - 500 GB (for example, dd if=/dev/zero of=<file_name> bs=1073741824 count=200). The size of file defines duration of GC working.

3. Then it needs to delete file.

4. Start GC manually by means of command "nilfs-clean -p 0". When you start GC by means of such way then, at the end, superblocks is updated by once. So, for simulation of SPOR, it needs to wait sometime (15 - 40 minutes) and simply switch off USB HDD manually.

5. Switch on USB HDD again and try to mount NILFS2 volume. As a result, NILFS2 volume will mount during very long time.

REPRODUCIBILITY: 100%

FIX:

This patch adds checking that superblocks need to update and set THE_NILFS_DISCONTINUED flag before nilfs_clean_segments() call.

---
 fs/nilfs2/ioctl.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
fs/nilfs2/ioctl.c +4 -1
@@ -666,8 +666,11 @@ static int nilfs_ioctl_clean_segments(st
 	if (ret < 0)
 		printk(KERN_ERR "NILFS: GC failed during preparation: "
 			"cannot read source blocks: err=%d\n", ret);
-	else
+	else {
+		if (nilfs_sb_need_update(nilfs))
+			set_nilfs_discontinued(nilfs);
 		ret = nilfs_clean_segments(inode->i_sb, argv, kbufs);
+	}
 
 	nilfs_remove_all_gcinodes(nilfs);
 	clear_nilfs_gc_running(nilfs);
author maintainer
#11 lore raw

PATCH 11/26 drivers/rtc/rtc-isl1208.c: call rtc_update_irq() from the alarm irq handler

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jan Luebbe <[email protected]>

commit 72fca4a4b32dc778b5b885c3498700e42b610d49 upstream.

Previously the alarm event was not propagated into the RTC subsystem. By adding a call to rtc_update_irq, this fixes a timeout problem with the hwclock utility.

---
 drivers/rtc/rtc-isl1208.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/rtc/rtc-isl1208.c +3 -0
@@ -494,6 +494,7 @@ isl1208_rtc_interrupt(int irq, void *dat
 {
 	unsigned long timeout = jiffies + msecs_to_jiffies(1000);
 	struct i2c_client *client = data;
+	struct rtc_device *rtc = i2c_get_clientdata(client);
 	int handled = 0, sr, err;
 
 	/*
@@ -516,6 +517,8 @@ isl1208_rtc_interrupt(int irq, void *dat
 	if (sr & ISL1208_REG_SR_ALM) {
 		dev_dbg(&client->dev, "alarm!\n");
 
+		rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF);
+
 		/* Clear the alarm */
 		sr &= ~ISL1208_REG_SR_ALM;
 		sr = i2c_smbus_write_byte_data(client, ISL1208_REG_SR, sr);
author maintainer
#12 lore raw

PATCH 12/26 USB: ftdi_sio: add Zolix FTDI PID

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Petr Kubánek <[email protected]>

commit 0ba3b2ccc72b3df5c305d61f59d93ab0f0e87991 upstream.

Add support for Zolix Omni 1509 monochromator custom USB-RS232 converter.

---
 drivers/usb/serial/ftdi_sio.c     |    1 +
 drivers/usb/serial/ftdi_sio_ids.h |    5 +++++
 2 files changed, 6 insertions(+)
drivers/usb/serial/ftdi_sio.c +1 -0
@@ -676,6 +676,7 @@ static struct usb_device_id id_table_com
 	{ USB_DEVICE(FTDI_VID, XSENS_CONVERTER_5_PID) },
 	{ USB_DEVICE(FTDI_VID, XSENS_CONVERTER_6_PID) },
 	{ USB_DEVICE(FTDI_VID, XSENS_CONVERTER_7_PID) },
+	{ USB_DEVICE(FTDI_VID, FTDI_OMNI1509) },
 	{ USB_DEVICE(MOBILITY_VID, MOBILITY_USB_SERIAL_PID) },
 	{ USB_DEVICE(FTDI_VID, FTDI_ACTIVE_ROBOTS_PID) },
 	{ USB_DEVICE(FTDI_VID, FTDI_MHAM_KW_PID) },
drivers/usb/serial/ftdi_sio_ids.h +5 -0
@@ -147,6 +147,11 @@
 #define XSENS_CONVERTER_6_PID	0xD38E
 #define XSENS_CONVERTER_7_PID	0xD38F
 
+/**
+ * Zolix (www.zolix.com.cb) product ids
+ */
+#define FTDI_OMNI1509			0xD491	/* Omni1509 embedded USB-serial */
+
 /*
  * NDI (www.ndigital.com) product ids
  */
author maintainer
#13 lore raw

PATCH 13/26 USB: ftdi_sio: add PID/VID entries for ELV WS 300 PC II

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sven Killig <[email protected]>

commit c249f911406efcc7456cb4af79396726bf7b8c57 upstream.

Add PID/VID entries for ELV WS 300 PC II weather station

---
 drivers/usb/serial/ftdi_sio.c     |    1 +
 drivers/usb/serial/ftdi_sio_ids.h |    4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)
drivers/usb/serial/ftdi_sio.c +1 -0
@@ -590,6 +590,7 @@ static struct usb_device_id id_table_com
 	/*
 	 * ELV devices:
 	 */
+	{ USB_DEVICE(FTDI_ELV_VID, FTDI_ELV_WS300_PID) },
 	{ USB_DEVICE(FTDI_VID, FTDI_ELV_USR_PID) },
 	{ USB_DEVICE(FTDI_VID, FTDI_ELV_MSM1_PID) },
 	{ USB_DEVICE(FTDI_VID, FTDI_ELV_KL100_PID) },
drivers/usb/serial/ftdi_sio_ids.h +3 -1
@@ -209,7 +209,7 @@
 
 /*
  * ELV USB devices submitted by Christian Abt of ELV (www.elv.de).
- * All of these devices use FTDI's vendor ID (0x0403).
+ * Almost all of these devices use FTDI's vendor ID (0x0403).
  * Further IDs taken from ELV Windows .inf file.
  *
  * The previously included PID for the UO 100 module was incorrect.
@@ -217,6 +217,8 @@
  *
  * Armin Laeuger originally sent the PID for the UM 100 module.
  */
+#define FTDI_ELV_VID	0x1B1F	/* ELV AG */
+#define FTDI_ELV_WS300_PID	0xC006	/* eQ3 WS 300 PC II */
 #define FTDI_ELV_USR_PID	0xE000	/* ELV Universal-Sound-Recorder */
 #define FTDI_ELV_MSM1_PID	0xE001	/* ELV Mini-Sound-Modul */
 #define FTDI_ELV_KL100_PID	0xE002	/* ELV Kfz-Leistungsmesser KL 100 */
author maintainer
#14 lore raw

PATCH 14/26 USB: option: add support for Telit LE920

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniele Palmas <[email protected]>

commit 03eb466f276ceef9dcf023dc5474db02af68aad9 upstream.

Add PID and special handling for Telit LE920

---
 drivers/usb/serial/option.c |    8 ++++++++
 1 file changed, 8 insertions(+)
drivers/usb/serial/option.c +8 -0
@@ -242,6 +242,7 @@ static void option_instat_callback(struc
 #define TELIT_PRODUCT_CC864_DUAL		0x1005
 #define TELIT_PRODUCT_CC864_SINGLE		0x1006
 #define TELIT_PRODUCT_DE910_DUAL		0x1010
+#define TELIT_PRODUCT_LE920			0x1200
 
 /* ZTE PRODUCTS */
 #define ZTE_VENDOR_ID				0x19d2
@@ -534,6 +535,11 @@ static const struct option_blacklist_inf
 	.reserved = BIT(3) | BIT(4),
 };
 
+static const struct option_blacklist_info telit_le920_blacklist = {
+	.sendsetup = BIT(0),
+	.reserved = BIT(1) | BIT(5),
+};
+
 static const struct usb_device_id option_ids[] = {
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -784,6 +790,8 @@ static const struct usb_device_id option
 	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_CC864_DUAL) },
 	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_CC864_SINGLE) },
 	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_DE910_DUAL) },
+	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
+		.driver_info = (kernel_ulong_t)&telit_le920_blacklist },
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF622, 0xff, 0xff, 0xff) }, /* ZTE WCDMA products */
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0002, 0xff, 0xff, 0xff),
 		.driver_info = (kernel_ulong_t)&net_intf1_blacklist },
author maintainer
#15 lore raw

PATCH 15/26 USB: option: add Changhong CH690

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bjørn Mork <[email protected]>

commit d4fa681541aa7bf8570d03426dd7ba663a71c467 upstream.

New device with 3 serial interfaces:

If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend) Sub=ff Prot=ff If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend) Sub=ff Prot=ff If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend) Sub=ff Prot=ff If#= 3 Alt= 0 #EPs= 2 Cls=08(stor) Sub=06 Prot=50

---
 drivers/usb/serial/option.c |    5 +++++
 1 file changed, 5 insertions(+)
drivers/usb/serial/option.c +5 -0
@@ -454,6 +454,10 @@ static void option_instat_callback(struc
 #define TPLINK_VENDOR_ID			0x2357
 #define TPLINK_PRODUCT_MA180			0x0201
 
+/* Changhong products */
+#define CHANGHONG_VENDOR_ID			0x2077
+#define CHANGHONG_PRODUCT_CH690			0x7001
+
 /* some devices interfaces need special handling due to a number of reasons */
 enum option_blacklist_reason {
 		OPTION_BLACKLIST_NONE = 0,
@@ -1326,6 +1330,7 @@ static const struct usb_device_id option
 	{ USB_DEVICE(PETATEL_VENDOR_ID, PETATEL_PRODUCT_NP10T) },
 	{ USB_DEVICE(TPLINK_VENDOR_ID, TPLINK_PRODUCT_MA180),
 	  .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
+	{ USB_DEVICE(CHANGHONG_VENDOR_ID, CHANGHONG_PRODUCT_CH690) },
 	{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);
author maintainer
#16 lore raw

PATCH 16/26 USB: qcserial: add Telit Gobi QDL device

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniele Palmas <[email protected]>

commit 78796ae17eacedcdcaaeb03ba73d2e532a4c8f83 upstream.

Add VID and PID for Telit Gobi QDL device

---
 drivers/usb/serial/qcserial.c |    1 +
 1 file changed, 1 insertion(+)
drivers/usb/serial/qcserial.c +1 -0
@@ -55,6 +55,7 @@ static const struct usb_device_id id_tab
 	{DEVICE_G1K(0x05c6, 0x9221)},	/* Generic Gobi QDL device */
 	{DEVICE_G1K(0x05c6, 0x9231)},	/* Generic Gobi QDL device */
 	{DEVICE_G1K(0x1f45, 0x0001)},	/* Unknown Gobi QDL device */
+	{DEVICE_G1K(0x1bc7, 0x900e)},	/* Telit Gobi QDL device */
 
 	/* Gobi 2000 devices */
 	{USB_DEVICE(0x1410, 0xa010)},	/* Novatel Gobi 2000 QDL device */
author maintainer
#17 lore raw

PATCH 17/26 USB: EHCI: fix timer bug affecting port resume

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alan Stern <[email protected]>

commit ee74290b7853db9d5fd64db70e5c175241c59fba upstream.

This patch (as1652) fixes a long-standing bug in ehci-hcd. The driver relies on status polls to know when to stop port-resume signalling. It uses the root-hub status timer to schedule these status polls. But when the driver for the root hub is resumed, the timer is rescheduled to go off immediately -- before the port is ready. When this happens the timer does not get re-enabled, which prevents the port resume from finishing until some other event occurs.

The symptom is that when a new device is plugged in, it doesn't get recognized or enumerated until lsusb is run or something else happens.

The solution is to re-enable the root-hub status timer after every status poll while a port resume is in progress.

This bug hasn't surfaced before now because we never used to try to suspend the root hub in the middle of a port resume (except by coincidence).

---
 drivers/usb/host/ehci-hub.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/usb/host/ehci-hub.c +5 -1
@@ -612,7 +612,11 @@ ehci_hub_status_data (struct usb_hcd *hc
 			status = STS_PCD;
 		}
 	}
-	/* FIXME autosuspend idle root hubs */
+
+	/* If a resume is in progress, make sure it can finish */
+	if (ehci->resuming_ports)
+		mod_timer(&hcd->rh_timer, jiffies + msecs_to_jiffies(25));
+
 	spin_unlock_irqrestore (&ehci->lock, flags);
 	return status ? retval : 0;
 }
author maintainer
#18 lore raw

PATCH 18/26 USB: EHCI: fix bug in scheduling periodic split transfers

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alan Stern <[email protected]>

commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d upstream.

This patch (as1654) fixes a very old bug in ehci-hcd, connected with scheduling of periodic split transfers. The calculations for full/low-speed bus usage are all carried out after the correction for bit-stuffing has been applied, but the values in the max_tt_usecs array assume it hasn't been. The array should allow for allocation of up to 90% of the bus capacity, which is 900 us, not 780 us.

The symptom caused by this bug is that any isochronous transfer to a full-speed device with a maxpacket size larger than about 980 bytes is always rejected with a -ENOSPC error.

---
 drivers/usb/host/ehci-sched.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/ehci-sched.c +1 -1
@@ -236,7 +236,7 @@ static inline unsigned char tt_start_ufr
 }
 
 static const unsigned char
-max_tt_usecs[] = { 125, 125, 125, 125, 125, 125, 30, 0 };
+max_tt_usecs[] = { 125, 125, 125, 125, 125, 125, 125, 25 };
 
 /* carryover low/fullspeed bandwidth that crosses uframe boundries */
 static inline void carryover_tt_bandwidth(unsigned short tt_usecs[8])
author maintainer
#19 lore raw

PATCH 19/26 usb: Using correct way to clear usb3.0 devices remote wakeup feature.

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lan Tianyu <[email protected]>

commit 54a3ac0c9e5b7213daa358ce74d154352657353a upstream.

Usb3.0 device defines function remote wakeup which is only for interface recipient rather than device recipient. This is different with usb2.0 device's remote wakeup feature which is defined for device recipient. According usb3.0 spec 9.4.5, the function remote wakeup can be modified by the SetFeature() requests using the FUNCTION_SUSPEND feature selector. This patch is to use correct way to disable usb3.0 device's function remote wakeup after suspend error and resuming.

This should be backported to kernels as old as 3.4, that contain the commit 623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote wakeup for USB3 devices."

---
 drivers/usb/core/hub.c  |   70 +++++++++++++++++++++++++++++++++++-------------
 include/linux/usb/ch9.h |    6 ++++
 2 files changed, 58 insertions(+), 18 deletions(-)
drivers/usb/core/hub.c +52 -18
@@ -2463,6 +2463,23 @@ static int check_port_resume_type(struct
 }
 
 #ifdef	CONFIG_USB_SUSPEND
+/*
+ * usb_disable_function_remotewakeup - disable usb3.0
+ * device's function remote wakeup
+ * @udev: target device
+ *
+ * Assume there's only one function on the USB 3.0
+ * device and disable remote wake for the first
+ * interface. FIXME if the interface association
+ * descriptor shows there's more than one function.
+ */
+static int usb_disable_function_remotewakeup(struct usb_device *udev)
+{
+	return usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+				USB_REQ_CLEAR_FEATURE, USB_RECIP_INTERFACE,
+				USB_INTRF_FUNC_SUSPEND,	0, NULL, 0,
+				USB_CTRL_SET_TIMEOUT);
+}
 
 /*
  * usb_port_suspend - suspend a usb device's upstream port
@@ -2569,12 +2586,19 @@ int usb_port_suspend(struct usb_device *
 		dev_dbg(hub->intfdev, "can't suspend port %d, status %d\n",
 				port1, status);
 		/* paranoia:  "should not happen" */
-		if (udev->do_remote_wakeup)
-			(void) usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
-				USB_REQ_CLEAR_FEATURE, USB_RECIP_DEVICE,
-				USB_DEVICE_REMOTE_WAKEUP, 0,
-				NULL, 0,
-				USB_CTRL_SET_TIMEOUT);
+		if (udev->do_remote_wakeup) {
+			if (!hub_is_superspeed(hub->hdev)) {
+				(void) usb_control_msg(udev,
+						usb_sndctrlpipe(udev, 0),
+						USB_REQ_CLEAR_FEATURE,
+						USB_RECIP_DEVICE,
+						USB_DEVICE_REMOTE_WAKEUP, 0,
+						NULL, 0,
+						USB_CTRL_SET_TIMEOUT);
+			} else
+				(void) usb_disable_function_remotewakeup(udev);
+
+		}
 
 		/* Try to enable USB2 hardware LPM again */
 		if (udev->usb2_hw_lpm_capable == 1)
@@ -2661,20 +2685,30 @@ static int finish_port_resume(struct usb
 	 * udev->reset_resume
 	 */
 	} else if (udev->actconfig && !udev->reset_resume) {
-		le16_to_cpus(&devstatus);
-		if (devstatus & (1 << USB_DEVICE_REMOTE_WAKEUP)) {
-			status = usb_control_msg(udev,
-					usb_sndctrlpipe(udev, 0),
-					USB_REQ_CLEAR_FEATURE,
+		if (!hub_is_superspeed(udev->parent)) {
+			le16_to_cpus(&devstatus);
+			if (devstatus & (1 << USB_DEVICE_REMOTE_WAKEUP))
+				status = usb_control_msg(udev,
+						usb_sndctrlpipe(udev, 0),
+						USB_REQ_CLEAR_FEATURE,
 						USB_RECIP_DEVICE,
-					USB_DEVICE_REMOTE_WAKEUP, 0,
-					NULL, 0,
-					USB_CTRL_SET_TIMEOUT);
-			if (status)
-				dev_dbg(&udev->dev,
-					"disable remote wakeup, status %d\n",
-					status);
+						USB_DEVICE_REMOTE_WAKEUP, 0,
+						NULL, 0,
+						USB_CTRL_SET_TIMEOUT);
+		} else {
+			status = usb_get_status(udev, USB_RECIP_INTERFACE, 0,
+					&devstatus);
+			le16_to_cpus(&devstatus);
+			if (!status && devstatus & (USB_INTRF_STAT_FUNC_RW_CAP
+					| USB_INTRF_STAT_FUNC_RW))
+				status =
+					usb_disable_function_remotewakeup(udev);
 		}
+
+		if (status)
+			dev_dbg(&udev->dev,
+				"disable remote wakeup, status %d\n",
+				status);
 		status = 0;
 	}
 	return status;
include/linux/usb/ch9.h +6 -0
@@ -150,6 +150,12 @@
 #define USB_INTRF_FUNC_SUSPEND_LP	(1 << (8 + 0))
 #define USB_INTRF_FUNC_SUSPEND_RW	(1 << (8 + 1))
 
+/*
+ * Interface status, Figure 9-5 USB 3.0 spec
+ */
+#define USB_INTRF_STAT_FUNC_RW_CAP     1
+#define USB_INTRF_STAT_FUNC_RW         2
+
 #define USB_ENDPOINT_HALT		0	/* IN/OUT will STALL */
 
 /* Bit array elements as returned by the USB_REQ_GET_STATUS request. */
author maintainer
#20 lore raw

PATCH 20/26 USB: storage: Define a new macro for USB storage match rules

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: fangxiaozhi <[email protected]>

commit 07c7be3d87e5cdaf5f94c271c516456364ef286c upstream.

1. Define a new macro for USB storage match rules:
matching with Vendor ID and interface descriptors.

---
 drivers/usb/storage/usb.c          |   12 ++++++++++++
 drivers/usb/storage/usual-tables.c |   15 +++++++++++++++
 2 files changed, 27 insertions(+)
drivers/usb/storage/usb.c +12 -0
@@ -120,6 +120,17 @@ MODULE_PARM_DESC(quirks, "supplemental l
 	.useTransport = use_transport,	\
 }
 
+#define UNUSUAL_VENDOR_INTF(idVendor, cl, sc, pr, \
+		vendor_name, product_name, use_protocol, use_transport, \
+		init_function, Flags) \
+{ \
+	.vendorName = vendor_name,	\
+	.productName = product_name,	\
+	.useProtocol = use_protocol,	\
+	.useTransport = use_transport,	\
+	.initFunction = init_function,	\
+}
+
 static struct us_unusual_dev us_unusual_dev_list[] = {
 #	include "unusual_devs.h" 
 	{ }		/* Terminating entry */
@@ -131,6 +142,7 @@ static struct us_unusual_dev for_dynamic
 #undef UNUSUAL_DEV
 #undef COMPLIANT_DEV
 #undef USUAL_DEV
+#undef UNUSUAL_VENDOR_INTF
 
 #ifdef CONFIG_LOCKDEP
 
drivers/usb/storage/usual-tables.c +15 -0
@@ -46,6 +46,20 @@
 { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, useProto, useTrans), \
   .driver_info = ((useType)<<24) }
 
+/* Define the device is matched with Vendor ID and interface descriptors */
+#define UNUSUAL_VENDOR_INTF(id_vendor, cl, sc, pr, \
+			vendorName, productName, useProtocol, useTransport, \
+			initFunction, flags) \
+{ \
+	.match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
+				| USB_DEVICE_ID_MATCH_VENDOR, \
+	.idVendor    = (id_vendor), \
+	.bInterfaceClass = (cl), \
+	.bInterfaceSubClass = (sc), \
+	.bInterfaceProtocol = (pr), \
+	.driver_info = (flags) \
+}
+
 struct usb_device_id usb_storage_usb_ids[] = {
 #	include "unusual_devs.h"
 	{ }		/* Terminating entry */
@@ -57,6 +71,7 @@ MODULE_DEVICE_TABLE(usb, usb_storage_usb
 #undef UNUSUAL_DEV
 #undef COMPLIANT_DEV
 #undef USUAL_DEV
+#undef UNUSUAL_VENDOR_INTF
 
 
 /*
author maintainer
#21 lore raw

PATCH 21/26 USB: storage: optimize to match the Huawei USB storage devices and support new switch command

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: fangxiaozhi <[email protected]>

commit 200e0d994d9d1919b28c87f1a5fb99a8e13b8a0f upstream.

1. Optimize the match rules with new macro for Huawei USB storage devices, to avoid to load USB storage driver for the modem interface with Huawei devices.
2. Add to support new switch command for new Huawei USB dongles.

---
 drivers/usb/storage/initializers.c |   76 ++++++++
 drivers/usb/storage/initializers.h |    4 
 drivers/usb/storage/unusual_devs.h |  329 -------------------------------------
 3 files changed, 78 insertions(+), 331 deletions(-)
drivers/usb/storage/initializers.c +74 -2
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
 	return 0;
 }
 
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us)
+/* This places the HUAWEI usb dongles in multi-port mode */
+static int usb_stor_huawei_feature_init(struct us_data *us)
 {
 	int result;
 
@@ -104,3 +104,75 @@ int usb_stor_huawei_e220_init(struct us_
 	US_DEBUGP("Huawei mode set result is %d\n", result);
 	return 0;
 }
+
+/*
+ * It will send a scsi switch command called rewind' to huawei dongle.
+ * When the dongle receives this command at the first time,
+ * it will reboot immediately. After rebooted, it will ignore this command.
+ * So it is  unnecessary to read its response.
+ */
+static int usb_stor_huawei_scsi_init(struct us_data *us)
+{
+	int result = 0;
+	int act_len = 0;
+	struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us->iobuf;
+	char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
+			0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+
+	bcbw->Signature = cpu_to_le32(US_BULK_CB_SIGN);
+	bcbw->Tag = 0;
+	bcbw->DataTransferLength = 0;
+	bcbw->Flags = bcbw->Lun = 0;
+	bcbw->Length = sizeof(rewind_cmd);
+	memset(bcbw->CDB, 0, sizeof(bcbw->CDB));
+	memcpy(bcbw->CDB, rewind_cmd, sizeof(rewind_cmd));
+
+	result = usb_stor_bulk_transfer_buf(us, us->send_bulk_pipe, bcbw,
+					US_BULK_CB_WRAP_LEN, &act_len);
+	US_DEBUGP("transfer actual length=%d, result=%d\n", act_len, result);
+	return result;
+}
+
+/*
+ * It tries to find the supported Huawei USB dongles.
+ * In Huawei, they assign the following product IDs
+ * for all of their mobile broadband dongles,
+ * including the new dongles in the future.
+ * So if the product ID is not included in this list,
+ * it means it is not Huawei's mobile broadband dongles.
+ */
+static int usb_stor_huawei_dongles_pid(struct us_data *us)
+{
+	struct usb_interface_descriptor *idesc;
+	int idProduct;
+
+	idesc = &us->pusb_intf->cur_altsetting->desc;
+	idProduct = us->pusb_dev->descriptor.idProduct;
+	/* The first port is CDROM,
+	 * means the dongle in the single port mode,
+	 * and a switch command is required to be sent. */
+	if (idesc && idesc->bInterfaceNumber == 0) {
+		if ((idProduct == 0x1001)
+			|| (idProduct == 0x1003)
+			|| (idProduct == 0x1004)
+			|| (idProduct >= 0x1401 && idProduct <= 0x1500)
+			|| (idProduct >= 0x1505 && idProduct <= 0x1600)
+			|| (idProduct >= 0x1c02 && idProduct <= 0x2202)) {
+			return 1;
+		}
+	}
+	return 0;
+}
+
+int usb_stor_huawei_init(struct us_data *us)
+{
+	int result = 0;
+
+	if (usb_stor_huawei_dongles_pid(us)) {
+		if (us->pusb_dev->descriptor.idProduct >= 0x1446)
+			result = usb_stor_huawei_scsi_init(us);
+		else
+			result = usb_stor_huawei_feature_init(us);
+	}
+	return result;
+}
drivers/usb/storage/initializers.h +2 -2
@@ -46,5 +46,5 @@ int usb_stor_euscsi_init(struct us_data
  * flash reader */
 int usb_stor_ucr61s2b_init(struct us_data *us);
 
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us);
+/* This places the HUAWEI usb dongles in multi-port mode */
+int usb_stor_huawei_init(struct us_data *us);
drivers/usb/storage/unusual_devs.h +2 -327

337 lines not on this page · raw message

author maintainer
#22 lore raw

PATCH 22/26 drivers: xhci: fix incorrect bit test

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nickolai Zeldovich <[email protected]>

commit ba7b5c22d33136a5612ca5ef8d31564dcc501126 upstream.

Fix incorrect bit test that originally showed up in 4ee823b83bc9851743fab756c76b27d6a1e2472b "USB/xHCI: Support device-initiated USB 3.0 resume."

Use '&' instead of '&&'.

This should be backported to kernels as old as 3.4.

---
 drivers/usb/host/xhci-ring.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/xhci-ring.c +1 -1
@@ -1698,7 +1698,7 @@ static void handle_port_status(struct xh
 				faked_port_index + 1);
 		if (slot_id && xhci->devs[slot_id])
 			xhci_ring_device(xhci, slot_id);
-		if (bus_state->port_remote_wakeup && (1 << faked_port_index)) {
+		if (bus_state->port_remote_wakeup & (1 << faked_port_index)) {
 			bus_state->port_remote_wakeup &=
 				~(1 << faked_port_index);
 			xhci_test_and_clear_bit(xhci, port_array,
author maintainer
#23 lore raw

PATCH 23/26 xhci: Fix isoc TD encoding.

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sarah Sharp <[email protected]>

commit 760973d2a74b93eb1697981f7448f0e62767cfc4 upstream.

An isochronous TD is comprised of one isochronous TRB chained to zero or more normal TRBs. Only the isoc TRB has the TBC and TLBPC fields. The normal TRBs must set those fields to zeroes. The code was setting the TBC and TLBPC fields for both isoc and normal TRBs. Fix this.

This should be backported to stable kernels as old as 3.0, that contain the commit b61d378f2da41c748aba6ca19d77e1e1c02bcea5 " xhci 1.0: Set transfer burst last packet count field."

---
 drivers/usb/host/xhci-ring.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/usb/host/xhci-ring.c +3 -1
@@ -3662,9 +3662,11 @@ static int xhci_queue_isoc_tx(struct xhc
 		td = urb_priv->td[i];
 		for (j = 0; j < trbs_per_td; j++) {
 			u32 remainder = 0;
-			field = TRB_TBC(burst_count) | TRB_TLBPC(residue);
+			field = 0;
 
 			if (first_trb) {
+				field = TRB_TBC(burst_count) |
+					TRB_TLBPC(residue);
 				/* Queue the isoc TRB */
 				field |= TRB_TYPE(TRB_ISOC);
 				/* Assume URB_ISO_ASAP is set */
author maintainer
#24 lore raw

PATCH 24/26 xhci: Fix TD size for isochronous URBs.

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sarah Sharp <[email protected]>

commit f18f8ed2a9adc41c2d9294b85b6af115829d2af1 upstream.

To calculate the TD size for a particular TRB in an isoc TD, we need know the endpoint's max packet size. Isochronous endpoints also encode the number of additional service opportunities in their wMaxPacketSize field. The TD size calculation did not mask off those bits before using the field. This resulted in incorrect TD size information for isochronous TRBs when an URB frame buffer crossed a 64KB boundary.

For example:
- an isoc endpoint has 2 additional service opportunites and a max packet size of 1020 bytes
- a frame transfer buffer contains 3060 bytes
- one frame buffer crosses a 64KB boundary, and must be split into one 1276 byte TRB, and one 1784 byte TRB.

The TD size is is the number of packets that remain to be transferred for a TD after processing all the max packet sized packets in the current TRB and all previous TRBs.

For this TD, the number of packets to be transferred is (3060 / 1020), or 3. The first TRB contains 1276 bytes, which means it contains one full packet, and a 256 byte remainder. After processing all the max packet-sized packets in the first TRB, the host will have 2 packets left to transfer.

The old code would calculate the TD size for the first TRB as:

total packet count = DIV_ROUND_UP (TD length / endpoint wMaxPacketSize) total packet count - (first TRB length / endpoint wMaxPacketSize)

The math should have been:

total packet count = DIV_ROUND_UP (3060 / 1020) = 3 3 - (1276 / 1020) = 2

Since the old code didn't mask off the additional service interval bits from the wMaxPacketSize field, the math ended up as

total packet count = DIV_ROUND_UP (3060 / 5116) = 1 1 - (1276 / 5116) = 1

Fix this by masking off the number of additional service opportunities in the wMaxPacketSize field.

This patch should be backported to stable kernels as old as 3.0, that contain the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0:
Update TD size field format." It may not apply well to kernels older than 3.2 because of commit 29cc88979a8818cd8c5019426e945aed118b400e "USB: use usb_endpoint_maxp() instead of le16_to_cpu()".

---
 drivers/usb/host/xhci-ring.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/usb/host/xhci-ring.c +3 -2
@@ -3106,7 +3106,7 @@ static u32 xhci_v1_0_td_remainder(int ru
 	 * running_total.
 	 */
 	packets_transferred = (running_total + trb_buff_len) /
-		usb_endpoint_maxp(&urb->ep->desc);
+		GET_MAX_PACKET(usb_endpoint_maxp(&urb->ep->desc));
 
 	if ((total_packet_count - packets_transferred) > 31)
 		return 31 << 17;
@@ -3640,7 +3640,8 @@ static int xhci_queue_isoc_tx(struct xhc
 		td_len = urb->iso_frame_desc[i].length;
 		td_remain_len = td_len;
 		total_packet_count = DIV_ROUND_UP(td_len,
-				usb_endpoint_maxp(&urb->ep->desc));
+				GET_MAX_PACKET(
+					usb_endpoint_maxp(&urb->ep->desc)));
 		/* A zero-length transfer still involves at least one packet. */
 		if (total_packet_count == 0)
 			total_packet_count++;
author maintainer
#25 lore raw

PATCH 25/26 USB: XHCI: fix memory leak of URB-private data

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alan Stern <[email protected]>

commit 48c3375c5f69b1c2ef3d1051a0009cb9bce0ce24 upstream.

This patch (as1640) fixes a memory leak in xhci-hcd. The urb_priv data structure isn't always deallocated in the handle_tx_event() routine for non-control transfers. The patch adds a kfree() call so that all paths end up freeing the memory properly.

This patch should be backported to kernels as old as 2.6.36, that contain the commit 8e51adccd4c4b9ffcd509d7f2afce0a906139f75 "USB: xHCI:
Introduce urb_priv structure"

---
 drivers/usb/host/xhci-ring.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/usb/host/xhci-ring.c +2 -0
@@ -2587,6 +2587,8 @@ cleanup:
 				(trb_comp_code != COMP_STALL &&
 					trb_comp_code != COMP_BABBLE))
 				xhci_urb_free_priv(xhci, urb_priv);
+			else
+				kfree(urb_priv);
 
 			usb_hcd_unlink_urb_from_ep(bus_to_hcd(urb->dev->bus), urb);
 			if ((urb->actual_length != urb->transfer_buffer_length &&
author maintainer
#26 lore raw

PATCH 26/26 usb: Prevent dead ports when xhci is not enabled

In reply to Greg Kroah-Hartman

3.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: David Moore <[email protected]>

commit 58b2939b4d5a030eaec469d29812ab8477ee7e76 upstream.

When the xHCI driver is not available, actively switch the ports to EHCI mode since some BIOSes leave them in xHCI mode where they would otherwise appear dead. This was discovered on a Dell Optiplex 7010, but it's possible other systems could be affected.

This should be backported to kernels as old as 3.0, that contain the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching."

---
 drivers/usb/host/pci-quirks.c |    1 +
 1 file changed, 1 insertion(+)
drivers/usb/host/pci-quirks.c +1 -0
@@ -780,6 +780,7 @@ void usb_enable_xhci_ports(struct pci_de
 				"defaulting to EHCI.\n");
 		dev_warn(&xhci_pdev->dev,
 				"USB 3.0 devices will work at USB 2.0 speeds.\n");
+		usb_disable_xhci_ports(xhci_pdev);
 		return;
 	}
 
#27 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.4.30 release. There are 26 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Feb 10 00:43:18 UTC 2013. Anything received after that time might be too late.

Quoted 7 lines

The whole patch series can be found in one patch at:

        kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.30-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

Patches applied cleanly to 3.0.62, 3.4.29, and 3.7.6. Compiled and booted on the following systems:
HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics

Cross-compile tests:
alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.7.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.7.y.
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

-- Shuah

#28 lore raw
In reply to Greg Kroah-Hartman

At Thu, 7 Feb 2013 16:57:28 -0800,

Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.4.30 release. There are 26 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Feb 10 00:43:18 UTC 2013. Anything received after that time might be too late.

This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine.

- Build Machine: debian wheezy x86_64
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
memory: 8GB

- Test machine: debian wheezy x86_64(KVM guest on the Build Machine)
vCPU: x2
memory: 2GB

I reviewed the following patch and it looks good to me.

Quoted 2 lines

Shawn Bohrer <[email protected]>
sched/rt: Use root_domain of rt_rq not current processor

Thanks,
Satoru