Skip to contentSkip to conversation

3.1.3-stable review

PATCH New Greg KH 1 participant 54 messages Nov 23, 2011

Subsystems (31)
lore
Share & tools
lore

Greg KH

author
#0 lore raw

cover 3.1.3-stable review

This is the start of the stable review cycle for the 3.1.3 release. There are 53 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 us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.

Responses should be made by Friday, November 25, 2011, 20:00:00 UTC. 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.1.3-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

 Makefile                                    |    4 +-
 arch/arm/kernel/head.S                      |    2 +-
 arch/s390/include/asm/kvm_host.h            |    2 +-
 arch/s390/kvm/diag.c                        |    2 +-
 arch/s390/kvm/intercept.c                   |    3 +-
 arch/s390/kvm/interrupt.c                   |    1 +
 arch/s390/kvm/kvm-s390.c                    |   10 +++-
 arch/s390/kvm/sigp.c                        |    6 +-
 drivers/base/core.c                         |    3 +
 drivers/base/node.c                         |   14 +++---
 drivers/gpu/drm/i915/i915_reg.h             |    9 ++++
 drivers/gpu/drm/i915/intel_display.c        |   42 +++++++++++++++--
 drivers/media/video/saa7164/saa7164-cards.c |   66 +++++++++++++++++++++++++++
 drivers/media/video/saa7164/saa7164-dvb.c   |    1 +
 drivers/media/video/saa7164/saa7164.h       |    1 +
 drivers/misc/Kconfig                        |   15 +++---
 drivers/misc/pch_phub.c                     |   22 +++++++++-
 drivers/misc/spear13xx_pcie_gadget.c        |    2 +-
 drivers/net/wireless/libertas/if_spi.c      |    1 +
 drivers/net/wireless/rt2x00/rt2x00.h        |    1 +
 drivers/net/wireless/rt2x00/rt2x00dev.c     |   22 ++++++++-
 drivers/scsi/aacraid/linit.c                |    4 ++
 drivers/scsi/hpsa.c                         |    5 ++
 drivers/scsi/scsi_scan.c                    |    6 +--
 drivers/tty/hvc/hvc_dcc.c                   |    2 +
 drivers/tty/serial/Kconfig                  |   14 +++---
 drivers/tty/serial/pch_uart.c               |   13 +++++-
 drivers/tty/tty_ldisc.c                     |   30 +++++++++---
 drivers/usb/class/cdc-acm.c                 |    8 ++-
 drivers/usb/core/hub.c                      |    6 +++
 drivers/usb/core/quirks.c                   |   27 +++++++++++
 drivers/usb/gadget/Kconfig                  |    9 ++--
 drivers/usb/gadget/pch_udc.c                |    6 +++
 drivers/usb/host/ehci-sched.c               |   15 ++++--
 drivers/usb/host/pci-quirks.c               |    7 +--
 drivers/usb/host/xhci-mem.c                 |    5 --
 drivers/usb/host/xhci-ring.c                |   13 +++---
 drivers/usb/host/xhci.c                     |   34 +++++++-------
 drivers/usb/serial/ark3116.c                |   10 ++--
 drivers/usb/serial/ftdi_sio.c               |   14 +++++-
 drivers/usb/serial/option.c                 |   23 +++++++++
 drivers/usb/serial/pl2303.c                 |    1 -
 drivers/usb/serial/pl2303.h                 |    4 --
 drivers/usb/storage/protocol.c              |    7 +--
 fs/nfs/dir.c                                |    2 +-
 fs/nfs/file.c                               |   32 +++++++++++++
 fs/nfs/inode.c                              |    2 +-
 fs/nfs/nfs3proc.c                           |    1 +
 fs/nfs/nfs4proc.c                           |    1 +
 fs/nfs/proc.c                               |    1 +
 fs/super.c                                  |    2 +-
 include/linux/nfs_fs.h                      |    3 +
 include/linux/nfs_xdr.h                     |    1 +
 include/linux/shrinker.h                    |    1 +
 kernel/irq/spurious.c                       |    2 +-
 net/batman-adv/translation-table.c          |   24 +++++++++-
 net/batman-adv/types.h                      |    4 +-
 net/ipv6/ip6_tunnel.c                       |    8 +++-
 net/mac80211/rx.c                           |    9 +++-
 net/mac80211/util.c                         |    4 ++
 net/wireless/nl80211.c                      |    3 +-
 net/wireless/reg.c                          |    3 +
 sound/pci/hda/hda_eld.c                     |    5 +--
 sound/pci/hda/patch_cirrus.c                |   23 +++++----
 sound/pci/hda/patch_hdmi.c                  |   15 ++++---
 65 files changed, 489 insertions(+), 149 deletions(-)
author
#1 lore raw

PATCH 1/53 genirq: Fix irqfixup, irqpoll regression

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

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

From: Edward Donovan <[email protected]>

commit c75d720fca8a91ce99196d33adea383621027bf2 upstream.

commit d05c65fff0 ("genirq: spurious: Run only one poller at a time") introduced a regression, leaving the boot options 'irqfixup' and 'irqpoll' non-functional. The patch placed tests in each function, to exit if the function is already running. The test in 'misrouted_irq' exited when it should have proceeded, effectively disabling 'misrouted_irq' and 'poll_spurious_irqs'.

The check for an already running poller needs to be "!= 1" not "== 1" as "1" is the value when the first poller starts running.

---
 kernel/irq/spurious.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/irq/spurious.c +1 -1
@@ -115,7 +115,7 @@ static int misrouted_irq(int irq)
 	struct irq_desc *desc;
 	int i, ok = 0;
 
-	if (atomic_inc_return(&irq_poll_active) == 1)
+	if (atomic_inc_return(&irq_poll_active) != 1)
 		goto out;
 
 	irq_poll_cpu = smp_processor_id();
author
#2 lore raw

PATCH 2/53 ALSA: hda - Fix the connection selection of ADCs on Cirrus codecs

In reply to Greg KH

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

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

From: Takashi Iwai <[email protected]>

commit 05ee7964a470d29889ac48cc8274c1b5a1904a11 upstream.

spec->cur_adc isn't set until cs_capture_pcm_prepare() is called although the driver tries to select the connection at init time and at auto-mic switch. This results in the access to the widget NID 0, which is obviously invalid, also a wrong capture source.

This patch fixes the issue by issuing the connect-select verb conditionally at appropriate places.

---
 sound/pci/hda/patch_cirrus.c |   23 +++++++++++++----------
 1 file changed, 13 insertions(+), 10 deletions(-)
sound/pci/hda/patch_cirrus.c +13 -10
@@ -236,6 +236,15 @@ static int cs_dig_playback_pcm_cleanup(s
 	return snd_hda_multi_out_dig_cleanup(codec, &spec->multiout);
 }
 
+static void cs_update_input_select(struct hda_codec *codec)
+{
+	struct cs_spec *spec = codec->spec;
+	if (spec->cur_adc)
+		snd_hda_codec_write(codec, spec->cur_adc, 0,
+				    AC_VERB_SET_CONNECT_SEL,
+				    spec->adc_idx[spec->cur_input]);
+}
+
 /*
  * Analog capture
  */
@@ -249,6 +258,7 @@ static int cs_capture_pcm_prepare(struct
 	spec->cur_adc = spec->adc_nid[spec->cur_input];
 	spec->cur_adc_stream_tag = stream_tag;
 	spec->cur_adc_format = format;
+	cs_update_input_select(codec);
 	snd_hda_codec_setup_stream(codec, spec->cur_adc, stream_tag, 0, format);
 	return 0;
 }
@@ -688,10 +698,8 @@ static int change_cur_input(struct hda_c
 					   spec->cur_adc_stream_tag, 0,
 					   spec->cur_adc_format);
 	}
-	snd_hda_codec_write(codec, spec->cur_adc, 0,
-			    AC_VERB_SET_CONNECT_SEL,
-			    spec->adc_idx[idx]);
 	spec->cur_input = idx;
+	cs_update_input_select(codec);
 	return 1;
 }
 
@@ -972,10 +980,7 @@ static void cs_automic(struct hda_codec
 		} else  {
 			spec->cur_input = spec->last_input;
 		}
-
-		snd_hda_codec_write_cache(codec, spec->cur_adc, 0,
-					AC_VERB_SET_CONNECT_SEL,
-					spec->adc_idx[spec->cur_input]);
+		cs_update_input_select(codec);
 	} else {
 		if (present)
 			change_cur_input(codec, spec->automic_idx, 0);
@@ -1072,9 +1077,7 @@ static void init_input(struct hda_codec
 			cs_automic(codec);
 		else  {
 			spec->cur_adc = spec->adc_nid[spec->cur_input];
-			snd_hda_codec_write(codec, spec->cur_adc, 0,
-					AC_VERB_SET_CONNECT_SEL,
-					spec->adc_idx[spec->cur_input]);
+			cs_update_input_select(codec);
 		}
 	} else {
 		change_cur_input(codec, spec->cur_input, 1);
author
#3 lore raw

PATCH 3/53 fix WARNING: at drivers/scsi/scsi_lib.c:1704

In reply to Greg KH

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

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

From: James Bottomley <[email protected]>

commit 4e6c82b3614a18740ef63109d58743a359266daf upstream.

Quoted 57 lines · Stephen Rothwell

Hi all,

Starting some time last week I am getting the following during boot on our PPC970 blade:

calling .ipr_init+0x0/0x68 @ 1
ipr: IBM Power RAID SCSI Device Driver version: 2.5.2 (April 27, 2011) ipr 0000:01:01.0: Found IOA with IRQ: 26
ipr 0000:01:01.0: Starting IOA initialization sequence.
ipr 0000:01:01.0: Adapter firmware version: 06160039
ipr 0000:01:01.0: IOA initialized.
scsi0 : IBM 572E Storage Adapter

------------[ cut here ]------------
WARNING: at drivers/scsi/scsi_lib.c:1704
Modules linked in:
NIP: c00000000053b3d4 LR: c00000000053e5b0 CTR: c000000000541d70
REGS: c0000000783c2f60 TRAP: 0700   Not tainted  (3.1.0-autokern1)
MSR: 8000000000029032 <EE,ME,CE,IR,DR>  CR: 24002024  XER: 20000002

TASK = c0000000783b8000[1] 'swapper' THREAD: c0000000783c0000 CPU: 0
GPR00: 0000000000000001 c0000000783c31e0 c000000000cf38b0 c00000000239a9d0
GPR04: c000000000cbe8f8 0000000000000000 c0000000783c3040 0000000000000000
GPR08: c000000075daf488 c000000078a3b7ff c000000000bcacc8 0000000000000000
GPR12: 0000000044002028 c000000007ffb000 0000000002e40000 000000000099b800
GPR16: 0000000000000000 c000000000bba5fc c000000000a61db8 0000000000000000
GPR20: 0000000001b77200 0000000000000000 c000000078990000 0000000000000001
GPR24: c000000002396828 0000000000000000 0000000000000000 c000000078a3b938
GPR28: fffffffffffffffa c0000000008ad2c0 c000000000c7faa8 c00000000239a9d0 NIP [c00000000053b3d4] .scsi_free_queue+0x24/0x90
LR [c00000000053e5b0] .scsi_alloc_sdev+0x280/0x2e0

Call Trace:
[c0000000783c31e0] [c000000000c7faa8] wireless_seq_fops+0x278d0/0x2eb88 (unreliable)
[c0000000783c3270] [c00000000053e5b0] .scsi_alloc_sdev+0x280/0x2e0
[c0000000783c3330] [c00000000053eba0] .scsi_probe_and_add_lun+0x390/0xb40
[c0000000783c34a0] [c00000000053f7ec] .__scsi_scan_target+0x16c/0x650
[c0000000783c35f0] [c00000000053fd90] .scsi_scan_channel+0xc0/0x100
[c0000000783c36a0] [c00000000053fefc] .scsi_scan_host_selected+0x12c/0x1c0
[c0000000783c3750] [c00000000083dcb4] .ipr_probe+0x2c0/0x390
[c0000000783c3830] [c0000000003f50b4] .local_pci_probe+0x34/0x50
[c0000000783c38a0] [c0000000003f5f78] .pci_device_probe+0x148/0x150
[c0000000783c3950] [c0000000004e1e8c] .driver_probe_device+0xdc/0x210
[c0000000783c39f0] [c0000000004e20cc] .__driver_attach+0x10c/0x110
[c0000000783c3a80] [c0000000004e1228] .bus_for_each_dev+0x98/0xf0
[c0000000783c3b30] [c0000000004e1bf8] .driver_attach+0x28/0x40
[c0000000783c3bb0] [c0000000004e07d8] .bus_add_driver+0x218/0x340
[c0000000783c3c60] [c0000000004e2a2c] .driver_register+0x9c/0x1b0
[c0000000783c3d00] [c0000000003f62d4] .__pci_register_driver+0x64/0x140
[c0000000783c3da0] [c000000000b99f88] .ipr_init+0x4c/0x68
[c0000000783c3e20] [c00000000000ad24] .do_one_initcall+0x1a4/0x1e0
[c0000000783c3ee0] [c000000000b512d0] .kernel_init+0x14c/0x1fc
[c0000000783c3f90] [c000000000022468] .kernel_thread+0x54/0x70
Instruction dump:
ebe1fff8 7c0803a6 4e800020 7c0802a6 fba1ffe8 fbe1fff8 7c7f1b78 f8010010
f821ff71 e8030398 3120ffff 7c090110 <0b000000> e86303b0 482de065 60000000
---[ end trace 759bed76a85e8dec ]---
scsi 0:0:1:0: Direct-Access     IBM-ESXS MAY2036RC        T106 PQ: 0 ANSI: 5
------------[ cut here ]------------
Quoted 3 lines

I get lots more of these. The obvious commit to point the finger at is 3308511c93e6 ("[SCSI] Make scsi_free_queue() kill pending SCSI commands") but the root cause may be something different.

Caused by

commit f7c9c6bb14f3104608a3a83cadea10a6943d2804

Author: Anton Blanchard <[email protected]>
Date:   Thu Nov 3 08:56:22 2011 +1100

[SCSI] Fix block queue and elevator memory leak in scsi_alloc_sdev

Doesn't completely do the teardown. The true fix is to do a proper teardown instead of hand rolling it

---
 drivers/scsi/scsi_scan.c |    6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)
drivers/scsi/scsi_scan.c +1 -5
@@ -319,11 +319,7 @@ static struct scsi_device *scsi_alloc_sd
 	return sdev;
 
 out_device_destroy:
-	scsi_device_set_state(sdev, SDEV_DEL);
-	transport_destroy_device(&sdev->sdev_gendev);
-	put_device(&sdev->sdev_dev);
-	scsi_free_queue(sdev->request_queue);
-	put_device(&sdev->sdev_gendev);
+	__scsi_remove_device(sdev);
 out:
 	if (display_failure_msg)
 		printk(ALLOC_FAILURE_MSG, __func__);
author
#4 lore raw

PATCH 4/53 hpsa: Disable ASPM

In reply to Greg KH

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

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

From: Matthew Garrett <[email protected]>

commit e5a44df85e8d78e5c2d3d2e4f59b460905691e2f upstream.

The Windows driver .inf disables ASPM on hpsa devices. Do the same because the selection of a non default ASPM policy can cause the device to hang.

---
 drivers/scsi/hpsa.c |    5 +++++
 1 file changed, 5 insertions(+)
drivers/scsi/hpsa.c +5 -0
@@ -23,6 +23,7 @@
 #include <linux/interrupt.h>
 #include <linux/types.h>
 #include <linux/pci.h>
+#include <linux/pci-aspm.h>
 #include <linux/kernel.h>
 #include <linux/slab.h>
 #include <linux/delay.h>
@@ -3887,6 +3888,10 @@ static int __devinit hpsa_pci_init(struc
 		dev_warn(&h->pdev->dev, "controller appears to be disabled\n");
 		return -ENODEV;
 	}
+
+	pci_disable_link_state(h->pdev, PCIE_LINK_STATE_L0S |
+			       PCIE_LINK_STATE_L1 | PCIE_LINK_STATE_CLKPM);
+
 	err = pci_enable_device(h->pdev);
 	if (err) {
 		dev_warn(&h->pdev->dev, "unable to enable PCI device\n");
author
#5 lore raw

PATCH 5/53 aacraid: controller hangs if kernel uses non-default ASPM policy

In reply to Greg KH

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

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

From: Vasily Averin <[email protected]>

commit cf16123c9c8e346ed1dd171295a678d77648d7f8 upstream.

Aacraid controller can hang on some nodes if kernel uses non-default (powersave) ASPM policy. Controller hangs shortly after successful load and hardware detection. Scsi error handler detects this hang and tries to restart hardware but it does not help.

Initially it was noticed on RHEL6-based openVZ kernel after backporting aacraid driver from mainline (RHEL6 kernel with original driver works well)
http://bugzilla.openvz.org/show_bug.cgi?id=2043

This issue happens because default ASPM policy was changed in Red Hat kernels. Therefore guys from Red Hat have noticed this problem long time ago:
on Fedora 12
https://bugzilla.redhat.com/show_bug.cgi?id=540478
on Fedora 14
https://bugzilla.redhat.com/show_bug.cgi?id=679385

In RHEL6 kernel this issue was fixed, ASPM was disabled in aacraid driver. In kernel changelog I've found that seems it was done by Matthew Garrett: - [scsi] aacraid: Disable ASPM by default (Matthew Garrett) [599735]

However seems this patch was not submitted to mainline. I've reproduced this issue on vanilla 3.1.0 kernel booted with "pcie_aspm.policy=powersave" option, So I believe it makes sense to do it now.

[mjg: Checking the Windows drivers indicates that they disable ASPM under all circumstances, so:]

---
 drivers/scsi/aacraid/linit.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/scsi/aacraid/linit.c +4 -0
@@ -38,6 +38,7 @@
 #include <linux/module.h>
 #include <linux/moduleparam.h>
 #include <linux/pci.h>
+#include <linux/pci-aspm.h>
 #include <linux/slab.h>
 #include <linux/mutex.h>
 #include <linux/spinlock.h>
@@ -1108,6 +1109,9 @@ static int __devinit aac_probe_one(struc
 		unique_id++;
 	}
 
+	pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
+			       PCIE_LINK_STATE_CLKPM);
+
 	error = pci_enable_device(pdev);
 	if (error)
 		goto out;
author
#6 lore raw

PATCH 6/53 saa7164: Add support for another HVR2200 hardware revision

In reply to Greg KH

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

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

From: Tony Jago <[email protected]>

commit 62dd28d0c659db29bdb89cfe9f0aefe42f0adfe9 upstream.

Hauppauge have released a new model rev, sub id 8940, this adds support.

[[email protected]: I modified Tony's patch slightly in relation to the
card numbering in saa7164.h, appending rather than inserting the new card
- normal practise]

---
 drivers/media/video/saa7164/saa7164-cards.c |   66 ++++++++++++++++++++++++++++
 drivers/media/video/saa7164/saa7164-dvb.c   |    1 
 drivers/media/video/saa7164/saa7164.h       |    1 
 3 files changed, 68 insertions(+)
drivers/media/video/saa7164/saa7164-cards.c +66 -0
@@ -203,6 +203,66 @@ struct saa7164_board saa7164_boards[] =
 			.i2c_reg_len	= REGLEN_8bit,
 		} },
 	},
+	[SAA7164_BOARD_HAUPPAUGE_HVR2200_4] = {
+		.name		= "Hauppauge WinTV-HVR2200",
+		.porta		= SAA7164_MPEG_DVB,
+		.portb		= SAA7164_MPEG_DVB,
+		.portc		= SAA7164_MPEG_ENCODER,
+		.portd		= SAA7164_MPEG_ENCODER,
+		.porte		= SAA7164_MPEG_VBI,
+		.portf		= SAA7164_MPEG_VBI,
+		.chiprev	= SAA7164_CHIP_REV3,
+		.unit		= {{
+			.id		= 0x1d,
+			.type		= SAA7164_UNIT_EEPROM,
+			.name		= "4K EEPROM",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_0,
+			.i2c_bus_addr	= 0xa0 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x04,
+			.type		= SAA7164_UNIT_TUNER,
+			.name		= "TDA18271-1",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_1,
+			.i2c_bus_addr	= 0xc0 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x05,
+			.type		= SAA7164_UNIT_ANALOG_DEMODULATOR,
+			.name		= "TDA8290-1",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_1,
+			.i2c_bus_addr	= 0x84 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1b,
+			.type		= SAA7164_UNIT_TUNER,
+			.name		= "TDA18271-2",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_2,
+			.i2c_bus_addr	= 0xc0 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1c,
+			.type		= SAA7164_UNIT_ANALOG_DEMODULATOR,
+			.name		= "TDA8290-2",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_2,
+			.i2c_bus_addr	= 0x84 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1e,
+			.type		= SAA7164_UNIT_DIGITAL_DEMODULATOR,
+			.name		= "TDA10048-1",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_1,
+			.i2c_bus_addr	= 0x10 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1f,
+			.type		= SAA7164_UNIT_DIGITAL_DEMODULATOR,
+			.name		= "TDA10048-2",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_2,
+			.i2c_bus_addr	= 0x12 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		} },
+	},
 	[SAA7164_BOARD_HAUPPAUGE_HVR2250] = {
 		.name		= "Hauppauge WinTV-HVR2250",
 		.porta		= SAA7164_MPEG_DVB,
@@ -426,6 +486,10 @@ struct saa7164_subid saa7164_subids[] =
 		.subvendor = 0x0070,
 		.subdevice = 0x8851,
 		.card      = SAA7164_BOARD_HAUPPAUGE_HVR2250_2,
+	}, {
+		.subvendor = 0x0070,
+		.subdevice = 0x8940,
+		.card      = SAA7164_BOARD_HAUPPAUGE_HVR2200_4,
 	},
 };
 const unsigned int saa7164_idcount = ARRAY_SIZE(saa7164_subids);
@@ -469,6 +533,7 @@ void saa7164_gpio_setup(struct saa7164_d
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_3:
+	case SAA7164_BOARD_HAUPPAUGE_HVR2200_4:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_3:
@@ -549,6 +614,7 @@ void saa7164_card_setup(struct saa7164_d
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_3:
+	case SAA7164_BOARD_HAUPPAUGE_HVR2200_4:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_3:
drivers/media/video/saa7164/saa7164-dvb.c +1 -0
@@ -475,6 +475,7 @@ int saa7164_dvb_register(struct saa7164_
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_3:
+	case SAA7164_BOARD_HAUPPAUGE_HVR2200_4:
 		i2c_bus = &dev->i2c_bus[port->nr + 1];
 		switch (port->nr) {
 		case 0:
drivers/media/video/saa7164/saa7164.h +1 -0
@@ -82,6 +82,7 @@
 #define SAA7164_BOARD_HAUPPAUGE_HVR2200_3	6
 #define SAA7164_BOARD_HAUPPAUGE_HVR2250_2	7
 #define SAA7164_BOARD_HAUPPAUGE_HVR2250_3	8
+#define SAA7164_BOARD_HAUPPAUGE_HVR2200_4	9
 
 #define SAA7164_MAX_UNITS		8
 #define SAA7164_TS_NUMBER_OF_LINES	312
author
#7 lore raw

PATCH 7/53 KVM: s390: Fix RUNNING flag misinterpretation

In reply to Greg KH

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

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

From: Cornelia Huck <[email protected]>

commit 9e6dabeffd1d0ec2aa19aa076c4886067238d442 upstream.

CPUSTAT_RUNNING was implemented signifying that a vcpu is not stopped. This is not, however, what the architecture says: RUNNING should be set when the host is acting on the behalf of the guest operating system.

CPUSTAT_RUNNING has been changed to be set in kvm_arch_vcpu_load() and to be unset in kvm_arch_vcpu_put().

For signifying stopped state of a vcpu, a host-controlled bit has been used and is set/unset basically on the reverse as the old CPUSTAT_RUNNING bit (including pushing it down into stop handling proper in handle_stop()).

---
 arch/s390/include/asm/kvm_host.h |    2 +-
 arch/s390/kvm/diag.c             |    2 +-
 arch/s390/kvm/intercept.c        |    3 ++-
 arch/s390/kvm/interrupt.c        |    1 +
 arch/s390/kvm/kvm-s390.c         |   10 +++++++---
 arch/s390/kvm/sigp.c             |    6 +++---
 6 files changed, 15 insertions(+), 9 deletions(-)
arch/s390/include/asm/kvm_host.h +1 -1
@@ -47,7 +47,7 @@ struct sca_block {
 #define KVM_HPAGE_MASK(x)	(~(KVM_HPAGE_SIZE(x) - 1))
 #define KVM_PAGES_PER_HPAGE(x)	(KVM_HPAGE_SIZE(x) / PAGE_SIZE)
 
-#define CPUSTAT_HOST       0x80000000
+#define CPUSTAT_STOPPED    0x80000000
 #define CPUSTAT_WAIT       0x10000000
 #define CPUSTAT_ECALL_PEND 0x08000000
 #define CPUSTAT_STOP_INT   0x04000000
arch/s390/kvm/diag.c +1 -1
@@ -42,7 +42,7 @@ static int __diag_ipl_functions(struct k
 		return -EOPNOTSUPP;
 	}
 
-	atomic_clear_mask(CPUSTAT_RUNNING, &vcpu->arch.sie_block->cpuflags);
+	atomic_set_mask(CPUSTAT_STOPPED, &vcpu->arch.sie_block->cpuflags);
 	vcpu->run->s390_reset_flags |= KVM_S390_RESET_SUBSYSTEM;
 	vcpu->run->s390_reset_flags |= KVM_S390_RESET_IPL;
 	vcpu->run->s390_reset_flags |= KVM_S390_RESET_CPU_INIT;
arch/s390/kvm/intercept.c +2 -1
@@ -132,7 +132,6 @@ static int handle_stop(struct kvm_vcpu *
 	int rc = 0;
 
 	vcpu->stat.exit_stop_request++;
-	atomic_clear_mask(CPUSTAT_RUNNING, &vcpu->arch.sie_block->cpuflags);
 	spin_lock_bh(&vcpu->arch.local_int.lock);
 	if (vcpu->arch.local_int.action_bits & ACTION_STORE_ON_STOP) {
 		vcpu->arch.local_int.action_bits &= ~ACTION_STORE_ON_STOP;
@@ -149,6 +148,8 @@ static int handle_stop(struct kvm_vcpu *
 	}
 
 	if (vcpu->arch.local_int.action_bits & ACTION_STOP_ON_STOP) {
+		atomic_set_mask(CPUSTAT_STOPPED,
+				&vcpu->arch.sie_block->cpuflags);
 		vcpu->arch.local_int.action_bits &= ~ACTION_STOP_ON_STOP;
 		VCPU_EVENT(vcpu, 3, "%s", "cpu stopped");
 		rc = -EOPNOTSUPP;
arch/s390/kvm/interrupt.c +1 -0
@@ -224,6 +224,7 @@ static void __do_deliver_interrupt(struc
 			offsetof(struct _lowcore, restart_psw), sizeof(psw_t));
 		if (rc == -EFAULT)
 			exception = 1;
+		atomic_clear_mask(CPUSTAT_STOPPED, &vcpu->arch.sie_block->cpuflags);
 		break;
 
 	case KVM_S390_PROGRAM_INT:
arch/s390/kvm/kvm-s390.c +7 -3
@@ -265,10 +265,12 @@ void kvm_arch_vcpu_load(struct kvm_vcpu
 	restore_fp_regs(&vcpu->arch.guest_fpregs);
 	restore_access_regs(vcpu->arch.guest_acrs);
 	gmap_enable(vcpu->arch.gmap);
+	atomic_set_mask(CPUSTAT_RUNNING, &vcpu->arch.sie_block->cpuflags);
 }
 
 void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
 {
+	atomic_clear_mask(CPUSTAT_RUNNING, &vcpu->arch.sie_block->cpuflags);
 	gmap_disable(vcpu->arch.gmap);
 	save_fp_regs(&vcpu->arch.guest_fpregs);
 	save_access_regs(vcpu->arch.guest_acrs);
@@ -296,7 +298,9 @@ static void kvm_s390_vcpu_initial_reset(
 
 int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
 {
-	atomic_set(&vcpu->arch.sie_block->cpuflags, CPUSTAT_ZARCH | CPUSTAT_SM);
+	atomic_set(&vcpu->arch.sie_block->cpuflags, CPUSTAT_ZARCH |
+						    CPUSTAT_SM |
+						    CPUSTAT_STOPPED);
 	vcpu->arch.sie_block->ecb   = 6;
 	vcpu->arch.sie_block->eca   = 0xC1002001U;
 	vcpu->arch.sie_block->fac   = (int) (long) facilities;
@@ -421,7 +425,7 @@ static int kvm_arch_vcpu_ioctl_set_initi
 {
 	int rc = 0;
 
-	if (atomic_read(&vcpu->arch.sie_block->cpuflags) & CPUSTAT_RUNNING)
+	if (!(atomic_read(&vcpu->arch.sie_block->cpuflags) & CPUSTAT_STOPPED))
 		rc = -EBUSY;
 	else {
 		vcpu->run->psw_mask = psw.mask;
@@ -494,7 +498,7 @@ rerun_vcpu:
 	if (vcpu->sigset_active)
 		sigprocmask(SIG_SETMASK, &vcpu->sigset, &sigsaved);
 
-	atomic_set_mask(CPUSTAT_RUNNING, &vcpu->arch.sie_block->cpuflags);
+	atomic_clear_mask(CPUSTAT_STOPPED, &vcpu->arch.sie_block->cpuflags);
 
 	BUG_ON(vcpu->kvm->arch.float_int.local_int[vcpu->vcpu_id] == NULL);
 
arch/s390/kvm/sigp.c +3 -3
@@ -57,8 +57,8 @@ static int __sigp_sense(struct kvm_vcpu
 	spin_lock(&fi->lock);
 	if (fi->local_int[cpu_addr] == NULL)
 		rc = 3; /* not operational */
-	else if (atomic_read(fi->local_int[cpu_addr]->cpuflags)
-		 & CPUSTAT_RUNNING) {
+	else if (!(atomic_read(fi->local_int[cpu_addr]->cpuflags)
+		  & CPUSTAT_STOPPED)) {
 		*reg &= 0xffffffff00000000UL;
 		rc = 1; /* status stored */
 	} else {
@@ -212,7 +212,7 @@ static int __sigp_set_prefix(struct kvm_
 
 	spin_lock_bh(&li->lock);
 	/* cpu must be in stopped state */
-	if (atomic_read(li->cpuflags) & CPUSTAT_RUNNING) {
+	if (!(atomic_read(li->cpuflags) & CPUSTAT_STOPPED)) {
 		rc = 1; /* incorrect state */
 		*reg &= SIGP_STAT_INCORRECT_STATE;
 		kfree(inti);
author
#8 lore raw

PATCH 8/53 ARM: 7150/1: Allow kernel unaligned accesses on ARMv6+

In reply to Greg KH

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

------------------
processors

From: Catalin Marinas <[email protected]>

commit 8428e84d42179c2a00f5f6450866e70d802d1d05 upstream.

Recent gcc versions generate unaligned accesses by default on ARMv6 and later processors. This patch ensures that the SCTLR.A bit is always cleared on such processors to avoid kernel traping before alignment_init() is called.

---
 arch/arm/kernel/head.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/kernel/head.S +1 -1
@@ -356,7 +356,7 @@ __secondary_data:
  *  r13 = *virtual* address to jump to upon completion
  */
 __enable_mmu:
-#ifdef CONFIG_ALIGNMENT_TRAP
+#if defined(CONFIG_ALIGNMENT_TRAP) && __LINUX_ARM_ARCH__ < 6
 	orr	r0, r0, #CR_A
 #else
 	bic	r0, r0, #CR_A
author
#9 lore raw

PATCH 9/53 Net, libertas: Resolve memory leak in if_spi_host_to_card()

In reply to Greg KH

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

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

From: Jesper Juhl <[email protected]>

commit fe09b32a4361bea44169b2063e8c867cabb6a8ba upstream.

If we hit the default case in the switch in if_spi_host_to_card() we'll leak the memory we allocated for 'packet'. This patch resolves the leak by freeing the allocated memory in that case.

---
 drivers/net/wireless/libertas/if_spi.c |    1 +
 1 file changed, 1 insertion(+)
drivers/net/wireless/libertas/if_spi.c +1 -0
@@ -999,6 +999,7 @@ static int if_spi_host_to_card(struct lb
 		spin_unlock_irqrestore(&card->buffer_lock, flags);
 		break;
 	default:
+		kfree(packet);
 		netdev_err(priv->dev, "can't transfer buffer of type %d\n",
 			   type);
 		err = -EINVAL;
author
#10 lore raw

PATCH 10/53 rt2x00: Fix sleep-while-atomic bug in powersaving code.

In reply to Greg KH

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

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

From: Gertjan van Wingerde <[email protected]>

commit ed66ba472a742cd8df37d7072804b2111cdb1014 upstream.

The generic powersaving code that determines after reception of a frame whether the device should go back to sleep or whether is could stay awake was calling rt2x00lib_config directly from RX tasklet context. On a number of the devices this call can actually sleep, due to having to confirm that the sleeping commands have been executed successfully.

Fix this by moving the call to rt2x00lib_config to a workqueue call.

This fixes bug https://bugzilla.redhat.com/show_bug.cgi?id=731672

---
 drivers/net/wireless/rt2x00/rt2x00.h    |    1 +
 drivers/net/wireless/rt2x00/rt2x00dev.c |   22 ++++++++++++++++++++--
 2 files changed, 21 insertions(+), 2 deletions(-)
drivers/net/wireless/rt2x00/rt2x00.h +1 -0
@@ -923,6 +923,7 @@ struct rt2x00_dev {
 	 * Powersaving work
 	 */
 	struct delayed_work autowakeup_work;
+	struct work_struct sleep_work;
 
 	/*
 	 * Data queue arrays for RX, TX, Beacon and ATIM.
drivers/net/wireless/rt2x00/rt2x00dev.c +20 -2
@@ -449,6 +449,23 @@ static u8 *rt2x00lib_find_ie(u8 *data, u
 	return NULL;
 }
 
+static void rt2x00lib_sleep(struct work_struct *work)
+{
+	struct rt2x00_dev *rt2x00dev =
+	    container_of(work, struct rt2x00_dev, sleep_work);
+
+	if (!test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+		return;
+
+	/*
+	 * Check again is powersaving is enabled, to prevent races from delayed
+	 * work execution.
+	 */
+	if (!test_bit(CONFIG_POWERSAVING, &rt2x00dev->flags))
+		rt2x00lib_config(rt2x00dev, &rt2x00dev->hw->conf,
+				 IEEE80211_CONF_CHANGE_PS);
+}
+
 static void rt2x00lib_rxdone_check_ps(struct rt2x00_dev *rt2x00dev,
 				      struct sk_buff *skb,
 				      struct rxdone_entry_desc *rxdesc)
@@ -496,8 +513,7 @@ static void rt2x00lib_rxdone_check_ps(st
 	cam |= (tim_ie->bitmap_ctrl & 0x01);
 
 	if (!cam && !test_bit(CONFIG_POWERSAVING, &rt2x00dev->flags))
-		rt2x00lib_config(rt2x00dev, &rt2x00dev->hw->conf,
-				 IEEE80211_CONF_CHANGE_PS);
+		queue_work(rt2x00dev->workqueue, &rt2x00dev->sleep_work);
 }
 
 static int rt2x00lib_rxdone_read_signal(struct rt2x00_dev *rt2x00dev,
@@ -1121,6 +1137,7 @@ int rt2x00lib_probe_dev(struct rt2x00_de
 
 	INIT_WORK(&rt2x00dev->intf_work, rt2x00lib_intf_scheduled);
 	INIT_DELAYED_WORK(&rt2x00dev->autowakeup_work, rt2x00lib_autowakeup);
+	INIT_WORK(&rt2x00dev->sleep_work, rt2x00lib_sleep);
 
 	/*
 	 * Let the driver probe the device to detect the capabilities.
@@ -1177,6 +1194,7 @@ void rt2x00lib_remove_dev(struct rt2x00_
 	 */
 	cancel_work_sync(&rt2x00dev->intf_work);
 	cancel_delayed_work_sync(&rt2x00dev->autowakeup_work);
+	cancel_work_sync(&rt2x00dev->sleep_work);
 	if (rt2x00_is_usb(rt2x00dev)) {
 		del_timer_sync(&rt2x00dev->txstatus_timer);
 		cancel_work_sync(&rt2x00dev->rxdone_work);
author
#11 lore raw

PATCH 11/53 mac80211: fix NULL dereference in radiotap code

In reply to Greg KH

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

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

From: Johannes Berg <[email protected]>

commit f8d1ccf15568268c76f913b45ecdd33134387f1a upstream.

When receiving failed PLCP frames is enabled, there won't be a rate pointer when we add the radiotap header and thus the kernel will crash. Fix this by not assuming the rate pointer is always valid. It's still always valid for frames that have good PLCP though, and that is checked & enforced.

This was broken by my
commit fc88518916793af8ad6a02e05ff254d95c36d875

Author: Johannes Berg <[email protected]>
Date:   Fri Jul 30 13:23:12 2010 +0200

mac80211: don't check rates on PLCP error frames

where I removed the check in this case but didn't take into account that the rate info would be used.

---
 net/mac80211/rx.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
net/mac80211/rx.c +6 -3
@@ -140,8 +140,9 @@ ieee80211_add_rx_radiotap_header(struct
 	pos++;
 
 	/* IEEE80211_RADIOTAP_RATE */
-	if (status->flag & RX_FLAG_HT) {
+	if (!rate || status->flag & RX_FLAG_HT) {
 		/*
+		 * Without rate information don't add it. If we have,
 		 * MCS information is a separate field in radiotap,
 		 * added below. The byte here is needed as padding
 		 * for the channel though, so initialise it to 0.
@@ -162,12 +163,14 @@ ieee80211_add_rx_radiotap_header(struct
 	else if (status->flag & RX_FLAG_HT)
 		put_unaligned_le16(IEEE80211_CHAN_DYN | IEEE80211_CHAN_2GHZ,
 				   pos);
-	else if (rate->flags & IEEE80211_RATE_ERP_G)
+	else if (rate && rate->flags & IEEE80211_RATE_ERP_G)
 		put_unaligned_le16(IEEE80211_CHAN_OFDM | IEEE80211_CHAN_2GHZ,
 				   pos);
-	else
+	else if (rate)
 		put_unaligned_le16(IEEE80211_CHAN_CCK | IEEE80211_CHAN_2GHZ,
 				   pos);
+	else
+		put_unaligned_le16(IEEE80211_CHAN_2GHZ, pos);
 	pos += 2;
 
 	/* IEEE80211_RADIOTAP_DBM_ANTSIGNAL */
author
#12 lore raw

PATCH 12/53 mac80211: fix bug in ieee80211_build_probe_req

In reply to Greg KH

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

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

From: Johannes Berg <[email protected]>

commit 5b2bbf75a24d6b06afff6de0eb4819413fd81971 upstream.

ieee80211_probereq_get() can return NULL in
which case we should clean up & return NULL
in ieee80211_build_probe_req() as well.

---
 net/mac80211/util.c |    4 ++++
 1 file changed, 4 insertions(+)
net/mac80211/util.c +4 -0
@@ -1055,6 +1055,8 @@ struct sk_buff *ieee80211_build_probe_re
 	skb = ieee80211_probereq_get(&local->hw, &sdata->vif,
 				     ssid, ssid_len,
 				     buf, buf_len);
+	if (!skb)
+		goto out;
 
 	if (dst) {
 		mgmt = (struct ieee80211_mgmt *) skb->data;
@@ -1063,6 +1065,8 @@ struct sk_buff *ieee80211_build_probe_re
 	}
 
 	IEEE80211_SKB_CB(skb)->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT;
+
+ out:
 	kfree(buf);
 
 	return skb;
author
#13 lore raw

PATCH 13/53 nl80211: fix HT capability attribute validation

In reply to Greg KH

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

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

From: Johannes Berg <[email protected]>

commit 6c7394197af90f6a332180e33f5d025d3037d883 upstream.

Since the NL80211_ATTR_HT_CAPABILITY attribute is used as a struct, it needs a minimum, not maximum length. Enforce that properly. Not doing so could potentially lead to reading after the buffer.

---
 net/wireless/nl80211.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
net/wireless/nl80211.c +1 -2
@@ -126,8 +126,7 @@ static const struct nla_policy nl80211_p
 	[NL80211_ATTR_MESH_CONFIG] = { .type = NLA_NESTED },
 	[NL80211_ATTR_SUPPORT_MESH_AUTH] = { .type = NLA_FLAG },
 
-	[NL80211_ATTR_HT_CAPABILITY] = { .type = NLA_BINARY,
-					 .len = NL80211_HT_CAPABILITY_LEN },
+	[NL80211_ATTR_HT_CAPABILITY] = { .len = NL80211_HT_CAPABILITY_LEN },
 
 	[NL80211_ATTR_MGMT_SUBTYPE] = { .type = NLA_U8 },
 	[NL80211_ATTR_IE] = { .type = NLA_BINARY,
author
#14 lore raw

PATCH 14/53 cfg80211: fix bug on regulatory core exit on access to last_request

In reply to Greg KH

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

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

From: "Luis R. Rodriguez" <[email protected]>

commit 58ebacc66bd11be2327edcefc79de94bd6f5bb4a upstream.

Commit 4d9d88d1 by Scott James Remnant <[email protected]> added the .uevent() callback for the regulatory device used during the platform device registration. The change was done to account for queuing up udev change requests through udevadm triggers. The change also meant that upon regulatory core exit we will now send a uevent() but the uevent() callback, reg_device_uevent(), also accessed last_request. Right before commiting device suicide we free'd last_request but never set it to NULL so platform_device_unregister() would lead to bogus kernel paging request. Fix this and also simply supress uevents right before we commit suicide as they are pointless.

This fix is required for kernels >= v2.6.39

$ git describe --contains 4d9d88d1
v2.6.39-rc1~468^2~25^2^2~21

The impact of not having this present is that a bogus paging access may occur (only read) upon cfg80211 unload time. You may also get this BUG complaint below. Although Johannes could not reproduce the issue this fix is theoretically correct.

mac80211_hwsim: unregister radios
mac80211_hwsim: closing netlink

BUG: unable to handle kernel paging request at ffff88001a06b5ab
IP: [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211]
PGD 1836063 PUD 183a063 PMD 1ffcb067 PTE 1a06b160
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU 0
Modules linked in: cfg80211(-) [last unloaded: mac80211]

Pid: 2279, comm: rmmod Tainted: G W 3.1.0-wl+ #663 Bochs Bochs

RIP: 0010:[<ffffffffa030df9a>]  [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211]
RSP: 0000:ffff88001c5f9d58  EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88001d2eda88 RCX: ffff88001c7468fc
RDX: ffff88001a06b5a0 RSI: ffff88001c7467b0 RDI: ffff88001c7467b0
RBP: ffff88001c5f9d58 R08: 000000000000ffff R09: 000000000000ffff
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001c7467b0
R13: ffff88001d2eda78 R14: ffffffff8164a840 R15: 0000000000000001
FS:  00007f8a91d8a6e0(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff88001a06b5ab CR3: 000000001c62e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process rmmod (pid: 2279, threadinfo ffff88001c5f8000, task ffff88000023c780)
Stack:
 ffff88001c5f9d98 ffffffff812ff7e5 ffffffff8176ab3d ffff88001c7468c2
 000000000000ffff ffff88001d2eda88 ffff88001c7467b0 ffff880000114820
 ffff88001c5f9e38 ffffffff81241dc7 ffff88001c5f9db8 ffffffff81040189
Call Trace:
 [<ffffffff812ff7e5>] dev_uevent+0xc5/0x170
 [<ffffffff81241dc7>] kobject_uevent_env+0x1f7/0x490
 [<ffffffff81040189>] ? sub_preempt_count+0x29/0x60
 [<ffffffff814cab1a>] ? _raw_spin_unlock_irqrestore+0x4a/0x90
 [<ffffffff81305307>] ? devres_release_all+0x27/0x60
 [<ffffffff8124206b>] kobject_uevent+0xb/0x10
 [<ffffffff812fee27>] device_del+0x157/0x1b0
 [<ffffffff8130377d>] platform_device_del+0x1d/0x90
 [<ffffffff81303b76>] platform_device_unregister+0x16/0x30
 [<ffffffffa030fffd>] regulatory_exit+0x5d/0x180 [cfg80211]
 [<ffffffffa032bec3>] cfg80211_exit+0x2b/0x45 [cfg80211]
 [<ffffffff8109a84c>] sys_delete_module+0x16c/0x220
 [<ffffffff8108a23e>] ? trace_hardirqs_on_caller+0x7e/0x120
 [<ffffffff814cba02>] system_call_fastpath+0x16/0x1b
Code: <all your base are belong to me>
RIP  [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211]
 RSP <ffff88001c5f9d58>
CR2: ffff88001a06b5ab
---[ end trace 147c5099a411e8c0 ]---
---
 net/wireless/reg.c |    3 +++
 1 file changed, 3 insertions(+)
net/wireless/reg.c +3 -0
@@ -2254,6 +2254,9 @@ void /* __init_or_exit */ regulatory_exi
 
 	kfree(last_request);
 
+	last_request = NULL;
+	dev_set_uevent_suppress(&reg_pdev->dev, true);
+
 	platform_device_unregister(reg_pdev);
 
 	spin_lock_bh(&reg_pending_beacons_lock);
author
#15 lore raw

PATCH 15/53 ip6_tunnel: copy parms.name after register_netdevice

In reply to Greg KH

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

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

From: Josh Boyer <[email protected]>

commit 731abb9cb27aef6013ce60808a04e04a545f3f4e upstream.

Commit 1c5cae815d removed an explicit call to dev_alloc_name in ip6_tnl_create because register_netdevice will now create a valid name. This works for the net_device itself.

However the tunnel keeps a copy of the name in the parms structure for the ip6_tnl associated with the tunnel. parms.name is set by copying the net_device name in ip6_tnl_dev_init_gen. That function is called from ip6_tnl_dev_init in ip6_tnl_create, but it is done before register_netdevice is called so the name is set to a bogus value in the parms.name structure.

This shows up if you do a simple tunnel add, followed by a tunnel show:

[root@localhost ~]# ip -6 tunnel add remote fec0::100 local fec0::200
[root@localhost ~]# ip -6 tunnel show
ip6tnl0: ipv6/ipv6 remote :: local :: encaplimit 0 hoplimit 0 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000) ip6tnl%d: ipv6/ipv6 remote fec0::100 local fec0::200 encaplimit 4 hoplimit 64 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000) [root@localhost ~]#

Fix this by moving the strcpy out of ip6_tnl_dev_init_gen, and calling it after register_netdevice has successfully returned.

---
 net/ipv6/ip6_tunnel.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
net/ipv6/ip6_tunnel.c +7 -1
@@ -289,6 +289,8 @@ static struct ip6_tnl *ip6_tnl_create(st
 	if ((err = register_netdevice(dev)) < 0)
 		goto failed_free;
 
+	strcpy(t->parms.name, dev->name);
+
 	dev_hold(dev);
 	ip6_tnl_link(ip6n, t);
 	return t;
@@ -1397,7 +1399,6 @@ ip6_tnl_dev_init_gen(struct net_device *
 	struct ip6_tnl *t = netdev_priv(dev);
 
 	t->dev = dev;
-	strcpy(t->parms.name, dev->name);
 	dev->tstats = alloc_percpu(struct pcpu_tstats);
 	if (!dev->tstats)
 		return -ENOMEM;
@@ -1477,6 +1478,7 @@ static void __net_exit ip6_tnl_destroy_t
 static int __net_init ip6_tnl_init_net(struct net *net)
 {
 	struct ip6_tnl_net *ip6n = net_generic(net, ip6_tnl_net_id);
+	struct ip6_tnl *t = NULL;
 	int err;
 
 	ip6n->tnls[0] = ip6n->tnls_wc;
@@ -1497,6 +1499,10 @@ static int __net_init ip6_tnl_init_net(s
 	err = register_netdev(ip6n->fb_tnl_dev);
 	if (err < 0)
 		goto err_register;
+
+	t = netdev_priv(ip6n->fb_tnl_dev);
+
+	strcpy(t->parms.name, ip6n->fb_tnl_dev->name);
 	return 0;
 
 err_register:
author
#16 lore raw

PATCH 16/53 PM / driver core: disable devices runtime PM during shutdown

In reply to Greg KH

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

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

From: Peter Chen <[email protected]>

commit af8db1508f2c9f3b6e633e2d2d906c6557c617f9 upstream.

There may be an issue when the user issue "reboot/shutdown" command, then the device has shut down its hardware, after that, this runtime-pm featured device's driver will probably be scheduled to do its suspend routine, and at its suspend routine, it may access hardware, but the device has already shutdown physically, then the system hang may be occurred.

I ran out this issue using an auto-suspend supported USB devices, like 3G modem, keyboard. The usb runtime suspend routine may be scheduled after the usb controller has been shut down, and the usb runtime suspend routine will try to suspend its roothub(controller), it will access register, then the system hang occurs as the controller is shutdown.

---
 drivers/base/core.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/base/core.c +3 -0
@@ -22,6 +22,7 @@
 #include <linux/kallsyms.h>
 #include <linux/mutex.h>
 #include <linux/async.h>
+#include <linux/pm_runtime.h>
 
 #include "base.h"
 #include "power/power.h"
@@ -1742,6 +1743,8 @@ void device_shutdown(void)
 		 */
 		list_del_init(&dev->kobj.entry);
 		spin_unlock(&devices_kset->list_lock);
+		/* Disable all device's runtime power management */
+		pm_runtime_disable(dev);
 
 		if (dev->bus && dev->bus->shutdown) {
 			dev_dbg(dev, "shutdown\n");
author
#17 lore raw

PATCH 17/53 pch_phub: Support new device LAPIS Semiconductor ML7831 IOH

In reply to Greg KH

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

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

From: Tomoya MORINAGA <[email protected]>

commit 584ad00ce4bfe594e4c4a89944b3c635187a1ca1 upstream.

ML7831 is companion chip for Intel Atom E6xx series.

---
 drivers/misc/Kconfig    |   15 ++++++++-------
 drivers/misc/pch_phub.c |   20 ++++++++++++++++++++
 2 files changed, 28 insertions(+), 7 deletions(-)
drivers/misc/Kconfig +8 -7
@@ -472,7 +472,7 @@ config BMP085
 	  module will be called bmp085.
 
 config PCH_PHUB
-	tristate "Intel EG20T PCH / OKI SEMICONDUCTOR IOH(ML7213/ML7223) PHUB"
+	tristate "Intel EG20T PCH/LAPIS Semicon IOH(ML7213/ML7223/ML7831) PHUB"
 	depends on PCI
 	help
 	  This driver is for PCH(Platform controller Hub) PHUB(Packet Hub) of
@@ -480,12 +480,13 @@ config PCH_PHUB
 	  processor. The Topcliff has MAC address and Option ROM data in SROM.
 	  This driver can access MAC address and Option ROM data in SROM.
 
-	  This driver also can be used for OKI SEMICONDUCTOR IOH(Input/
-	  Output Hub), ML7213 and ML7223.
-	  ML7213 IOH is for IVI(In-Vehicle Infotainment) use and ML7223 IOH is
-	  for MP(Media Phone) use.
-	  ML7213/ML7223 is companion chip for Intel Atom E6xx series.
-	  ML7213/ML7223 is completely compatible for Intel EG20T PCH.
+	  This driver also can be used for LAPIS Semiconductor's IOH,
+	  ML7213/ML7223/ML7831.
+	  ML7213 which is for IVI(In-Vehicle Infotainment) use.
+	  ML7223 IOH is for MP(Media Phone) use.
+	  ML7831 IOH is for general purpose use.
+	  ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
+	  ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
 
 	  To compile this driver as a module, choose M here: the module will
 	  be called pch_phub.
drivers/misc/pch_phub.c +20 -0
@@ -73,6 +73,9 @@
 #define PCI_DEVICE_ID_ROHM_ML7223_mPHUB	0x8012 /* for Bus-m */
 #define PCI_DEVICE_ID_ROHM_ML7223_nPHUB	0x8002 /* for Bus-n */
 
+/* Macros for ML7831 */
+#define PCI_DEVICE_ID_ROHM_ML7831_PHUB 0x8801
+
 /* SROM ACCESS Macro */
 #define PCH_WORD_ADDR_MASK (~((1 << 2) - 1))
 
@@ -757,6 +760,22 @@ static int __devinit pch_phub_probe(stru
 		chip->pch_opt_rom_start_address =\
 						 PCH_PHUB_ROM_START_ADDR_ML7223;
 		chip->pch_mac_start_address = PCH_PHUB_MAC_START_ADDR_ML7223;
+	} else if (id->driver_data == 5) { /* ML7831 */
+		retval = sysfs_create_file(&pdev->dev.kobj,
+					   &dev_attr_pch_mac.attr);
+		if (retval)
+			goto err_sysfs_create;
+
+		retval = sysfs_create_bin_file(&pdev->dev.kobj, &pch_bin_attr);
+		if (retval)
+			goto exit_bin_attr;
+
+		/* set the prefech value */
+		iowrite32(0x000affaa, chip->pch_phub_base_address + 0x14);
+		/* set the interrupt delay value */
+		iowrite32(0x25, chip->pch_phub_base_address + 0x44);
+		chip->pch_opt_rom_start_address = PCH_PHUB_ROM_START_ADDR_EG20T;
+		chip->pch_mac_start_address = PCH_PHUB_MAC_START_ADDR_EG20T;
 	}
 
 	chip->ioh_type = id->driver_data;
@@ -841,6 +860,7 @@ static struct pci_device_id pch_phub_pci
 	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ROHM_ML7213_PHUB), 2,  },
 	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ROHM_ML7223_mPHUB), 3,  },
 	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ROHM_ML7223_nPHUB), 4,  },
+	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ROHM_ML7831_PHUB), 5,  },
 	{ }
 };
 MODULE_DEVICE_TABLE(pci, pch_phub_pcidev_id);
author
#18 lore raw

PATCH 18/53 pch_phub: Fix MAC address writing issue for LAPIS ML7831

In reply to Greg KH

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

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

From: Tomoya MORINAGA <[email protected]>

commit 2a9887919457c6e1bd482e8448223be59d19010a upstream.

ISSUE:
Using ML7831, MAC address writing doesn't work well.

CAUSE:
ML7831 and EG20T have the same register map for MAC address access. However, this driver processes the writing the same as ML7223. This is not true.
This driver must process the writing the same as EG20T. This patch fixes the issue.

---
 drivers/misc/pch_phub.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/misc/pch_phub.c +1 -1
@@ -467,7 +467,7 @@ static int pch_phub_write_gbe_mac_addr(s
 	int retval;
 	int i;
 
-	if (chip->ioh_type == 1) /* EG20T */
+	if ((chip->ioh_type == 1) || (chip->ioh_type == 5)) /* EG20T or ML7831*/
 		retval = pch_phub_gbe_serial_rom_conf(chip);
 	else	/* ML7223 */
 		retval = pch_phub_gbe_serial_rom_conf_mp(chip);
author
#19 lore raw

PATCH 19/53 pch_uart: Fix hw-flow control issue

In reply to Greg KH

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

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

From: Tomoya MORINAGA <[email protected]>

commit a1d7cfe29f13cf45f8094929864b9c66bf0cd91b upstream.

Using hardware flow control,
currently, register of the control-bit(AFE) is not set. This patch fixes the issue.

---
 drivers/tty/serial/pch_uart.c |    1 +
 1 file changed, 1 insertion(+)
drivers/tty/serial/pch_uart.c +1 -0
@@ -1278,6 +1278,7 @@ static void pch_uart_set_termios(struct
 	if (rtn)
 		goto out;
 
+	pch_uart_set_mctrl(&priv->port, priv->port.mctrl);
 	/* Don't rewrite B0 */
 	if (tty_termios_baud_rate(termios))
 		tty_termios_encode_baud_rate(termios, baud, baud);
author
#20 lore raw

PATCH 20/53 pch_uart: Fix DMA resource leak issue

In reply to Greg KH

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

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

From: Tomoya MORINAGA <[email protected]>

commit 90f04c2926cfb5bf74533b0a7766bc896f6a0c0e upstream.

Changing UART mode PIO->DMA->PIO->DMA like below, pch_uart driver can't get DMA channel resource.

setserial /dev/ttyPCH0 ^low_latency
setserial /dev/ttyPCH0 low_latency

CAUSE:
Changing mode using setserial command, ".startup" function which gets DMA channel is called before ".verify_port" function which sets dma-flag(use_dma/use_dma_flag) as 1.

PIO->DMA
.startup: Since dma-flag is 0, DMA channel is not requested. .verify_port: dma-flag is set as 1.
.shutdown: N/A

DMA->PIO
.startup: Since dma-flag is 1, DMA channel is requested. .verify_port: dma-flag is set as 0.
.shutdown: Since dma-flag is 0, DMA channel is not released.

This means DMA channel resource leak occurs.
Next time, this driver can't get DMA channel resource forever.

MODIFICATION:
Currently, when release DMA channel resource, this driver checks dma-flag. However, this specification occurs the above issue.
This driver must check whether dma_request_channel is executed or not. The values are saved in private data variable "chan_tx/chan_tx". These variables mean if the value is NULL, DMA channel is not requested, if not NULL, DMA channel is requested.

This patch fixes the issue.

---
 drivers/tty/serial/pch_uart.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/tty/serial/pch_uart.c +2 -2
@@ -626,6 +626,7 @@ static void pch_request_dma(struct uart_
 		dev_err(priv->port.dev, "%s:dma_request_channel FAILS(Rx)\n",
 			__func__);
 		dma_release_channel(priv->chan_tx);
+		priv->chan_tx = NULL;
 		return;
 	}
 
@@ -1213,8 +1214,7 @@ static void pch_uart_shutdown(struct uar
 		dev_err(priv->port.dev,
 			"pch_uart_hal_set_fifo Failed(ret=%d)\n", ret);
 
-	if (priv->use_dma_flag)
-		pch_free_dma(port);
+	pch_free_dma(port);
 
 	free_irq(priv->port.irq, priv);
 }
author
#21 lore raw

PATCH 21/53 pch_uart: Support new device LAPIS Semiconductor ML7831 IOH

In reply to Greg KH

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

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

From: Tomoya MORINAGA <[email protected]>

commit 8249f743f732ccbc3056428945ab1d9bd36d46bf upstream.

ML7831 is companion chip for Intel Atom E6xx series.

---
 drivers/tty/serial/Kconfig    |   14 +++++++-------
 drivers/tty/serial/pch_uart.c |    8 ++++++++
 2 files changed, 15 insertions(+), 7 deletions(-)
drivers/tty/serial/Kconfig +7 -7
@@ -1570,7 +1570,7 @@ config SERIAL_IFX6X60
 	  Support for the IFX6x60 modem devices on Intel MID platforms.
 
 config SERIAL_PCH_UART
-	tristate "Intel EG20T PCH / OKI SEMICONDUCTOR IOH(ML7213/ML7223) UART"
+	tristate "Intel EG20T PCH/LAPIS Semicon IOH(ML7213/ML7223/ML7831) UART"
 	depends on PCI
 	select SERIAL_CORE
 	help
@@ -1578,12 +1578,12 @@ config SERIAL_PCH_UART
 	  which is an IOH(Input/Output Hub) for x86 embedded processor.
 	  Enabling PCH_DMA, this PCH UART works as DMA mode.
 
-	  This driver also can be used for OKI SEMICONDUCTOR IOH(Input/
-	  Output Hub), ML7213 and ML7223.
-	  ML7213 IOH is for IVI(In-Vehicle Infotainment) use and ML7223 IOH is
-	  for MP(Media Phone) use.
-	  ML7213/ML7223 is companion chip for Intel Atom E6xx series.
-	  ML7213/ML7223 is completely compatible for Intel EG20T PCH.
+	  This driver also can be used for LAPIS Semiconductor IOH(Input/
+	  Output Hub), ML7213, ML7223 and ML7831.
+	  ML7213 IOH is for IVI(In-Vehicle Infotainment) use, ML7223 IOH is
+	  for MP(Media Phone) use and ML7831 IOH is for general purpose use.
+	  ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
+	  ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
 
 config SERIAL_MSM_SMD
 	bool "Enable tty device interface for some SMD ports"
drivers/tty/serial/pch_uart.c +8 -0
@@ -256,6 +256,8 @@ enum pch_uart_num_t {
 	pch_ml7213_uart2,
 	pch_ml7223_uart0,
 	pch_ml7223_uart1,
+	pch_ml7831_uart0,
+	pch_ml7831_uart1,
 };
 
 static struct pch_uart_driver_data drv_dat[] = {
@@ -268,6 +270,8 @@ static struct pch_uart_driver_data drv_d
 	[pch_ml7213_uart2] = {PCH_UART_2LINE, 2},
 	[pch_ml7223_uart0] = {PCH_UART_8LINE, 0},
 	[pch_ml7223_uart1] = {PCH_UART_2LINE, 1},
+	[pch_ml7831_uart0] = {PCH_UART_8LINE, 0},
+	[pch_ml7831_uart1] = {PCH_UART_2LINE, 1},
 };
 
 static unsigned int default_baud = 9600;
@@ -1551,6 +1555,10 @@ static DEFINE_PCI_DEVICE_TABLE(pch_uart_
 	 .driver_data = pch_ml7223_uart0},
 	{PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x800D),
 	 .driver_data = pch_ml7223_uart1},
+	{PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8811),
+	 .driver_data = pch_ml7831_uart0},
+	{PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8812),
+	 .driver_data = pch_ml7831_uart1},
 	{0,},
 };
 
author
#22 lore raw

PATCH 22/53 tty: hvc_dcc: Fix duplicate character inputs

In reply to Greg KH

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

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

From: Stephen Boyd <[email protected]>

commit c2a3e84f950e7ddba1f3914b005861d46ae60359 upstream.

Reading from the DCC grabs a character from the buffer and clears the status bit. Since this is a context-changing operation, instructions following the character read that rely on the status bit being accurate need to be synchronized with an ISB.

In this case, the status bit check needs to execute after the character read otherwise we run the risk of reading the character and checking the status bit before the read can clear the status bit in the first place. When this happens, the user will see the same character they typed twice, instead of once.

Add an ISB after the read and the write, so that the status check is synchronized with the read/write operations.

---
 drivers/tty/hvc/hvc_dcc.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/tty/hvc/hvc_dcc.c +2 -0
@@ -46,6 +46,7 @@ static inline char __dcc_getchar(void)
 
 	asm volatile("mrc p14, 0, %0, c0, c5, 0	@ read comms data reg"
 		: "=r" (__c));
+	isb();
 
 	return __c;
 }
@@ -55,6 +56,7 @@ static inline void __dcc_putchar(char c)
 	asm volatile("mcr p14, 0, %0, c0, c5, 0	@ write a char"
 		: /* no output register */
 		: "r" (c));
+	isb();
 }
 
 static int hvc_dcc_put_chars(uint32_t vt, const char *buf, int count)
author
#23 lore raw

PATCH 23/53 TTY: ldisc, allow waiting for ldisc arbitrarily long

In reply to Greg KH

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

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

From: Jiri Slaby <[email protected]>

commit df92d0561de364de53c42abc5d43e04ab6f326a5 upstream.

To fix a nasty bug in ldisc hup vs. reinit we need to wait infinitely long for ldisc to be gone. So here we add a parameter to tty_ldisc_wait_idle to allow that.

This is only a preparation for the real fix which is done in the following patches.

Cc Dave Young <[email protected]>
Cc Dave Jones <[email protected]>
Cc Ben Hutchings <[email protected]>
Cc Dmitriy Matrosov <[email protected]>
Cc Alan Cox <[email protected]>
---
 drivers/tty/tty_ldisc.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/tty/tty_ldisc.c +6 -5
@@ -548,15 +548,16 @@ static void tty_ldisc_flush_works(struct
 /**
  *	tty_ldisc_wait_idle	-	wait for the ldisc to become idle
  *	@tty: tty to wait for
+ *	@timeout: for how long to wait at most
  *
  *	Wait for the line discipline to become idle. The discipline must
  *	have been halted for this to guarantee it remains idle.
  */
-static int tty_ldisc_wait_idle(struct tty_struct *tty)
+static int tty_ldisc_wait_idle(struct tty_struct *tty, long timeout)
 {
-	int ret;
+	long ret;
 	ret = wait_event_timeout(tty_ldisc_idle,
-			atomic_read(&tty->ldisc->users) == 1, 5 * HZ);
+			atomic_read(&tty->ldisc->users) == 1, timeout);
 	if (ret < 0)
 		return ret;
 	return ret > 0 ? 0 : -EBUSY;
@@ -666,7 +667,7 @@ int tty_set_ldisc(struct tty_struct *tty
 
 	tty_ldisc_flush_works(tty);
 
-	retval = tty_ldisc_wait_idle(tty);
+	retval = tty_ldisc_wait_idle(tty, 5 * HZ);
 
 	tty_lock();
 	mutex_lock(&tty->ldisc_mutex);
@@ -763,7 +764,7 @@ static int tty_ldisc_reinit(struct tty_s
 	if (IS_ERR(ld))
 		return -1;
 
-	WARN_ON_ONCE(tty_ldisc_wait_idle(tty));
+	WARN_ON_ONCE(tty_ldisc_wait_idle(tty, 5 * HZ));
 
 	tty_ldisc_close(tty, tty->ldisc);
 	tty_ldisc_put(tty->ldisc);
author
#24 lore raw

PATCH 24/53 TTY: ldisc, move wait idle to caller

In reply to Greg KH

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

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

From: Jiri Slaby <[email protected]>

commit 300420722e0734a4254f3b634e0f82664495d210 upstream.

It is the only place where reinit is called from. And we really need to wait for the old ldisc to go once. Actually this is the place where the waiting originally was (before removed and re-added later).

This will make the fix in the following patch easier to implement.

Cc Dave Young <[email protected]>
Cc Dave Jones <[email protected]>
Cc Ben Hutchings <[email protected]>
Cc Dmitriy Matrosov <[email protected]>
Cc Alan Cox <[email protected]>
---
 drivers/tty/tty_ldisc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/tty/tty_ldisc.c +2 -2
@@ -764,8 +764,6 @@ static int tty_ldisc_reinit(struct tty_s
 	if (IS_ERR(ld))
 		return -1;
 
-	WARN_ON_ONCE(tty_ldisc_wait_idle(tty, 5 * HZ));
-
 	tty_ldisc_close(tty, tty->ldisc);
 	tty_ldisc_put(tty->ldisc);
 	tty->ldisc = NULL;
@@ -849,6 +847,8 @@ void tty_ldisc_hangup(struct tty_struct
 	   it means auditing a lot of other paths so this is
 	   a FIXME */
 	if (tty->ldisc) {	/* Not yet closed */
+		WARN_ON_ONCE(tty_ldisc_wait_idle(tty, 5 * HZ));
+
 		if (reset == 0) {
 
 			if (!tty_ldisc_reinit(tty, tty->termios->c_line))
author
#25 lore raw

PATCH 25/53 TTY: ldisc, wait for ldisc infinitely in hangup

In reply to Greg KH

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

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

From: Jiri Slaby <[email protected]>

commit 0c73c08ec73dbe080b9ec56696ee21d32754d918 upstream.

For /dev/console case, we do not kill all ldisc users. It's due to redirected_tty_write test in __tty_hangup. In that case there still might be a process waiting e.g. in n_tty_read for input.

We wait for such processes to disappear. The problem is that we use a timeout. After this timeout, we continue closing the ldisc and start freeing tty resources. It obviously leads to crashes when the other process is woken.

So to fix this, we wait infinitely before reiniting the ldisc. (The tiocsetd remains untouched -- times out after 5s.)

This is nicely reproducible with this run from shell:
exec 0<>/dev/console 1<>/dev/console 2<>/dev/console
and stopping a getty like:
systemctl stop [email protected]

The crash proper may be produced only under load or with constified timing the same as for 92f6fa09b.

Cc Dave Young <[email protected]>
Cc Dave Jones <[email protected]>
Cc Ben Hutchings <[email protected]>
Cc Dmitriy Matrosov <[email protected]>
Cc Alan Cox <[email protected]>
---
 drivers/tty/tty_ldisc.c |   19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)
drivers/tty/tty_ldisc.c +17 -2
@@ -36,6 +36,7 @@
 
 #include <linux/kmod.h>
 #include <linux/nsproxy.h>
+#include <linux/ratelimit.h>
 
 /*
  *	This guards the refcounted line discipline lists. The lock
@@ -838,7 +839,7 @@ void tty_ldisc_hangup(struct tty_struct
 	tty_unlock();
 	cancel_work_sync(&tty->buf.work);
 	mutex_unlock(&tty->ldisc_mutex);
-
+retry:
 	tty_lock();
 	mutex_lock(&tty->ldisc_mutex);
 
@@ -847,7 +848,21 @@ void tty_ldisc_hangup(struct tty_struct
 	   it means auditing a lot of other paths so this is
 	   a FIXME */
 	if (tty->ldisc) {	/* Not yet closed */
-		WARN_ON_ONCE(tty_ldisc_wait_idle(tty, 5 * HZ));
+		if (atomic_read(&tty->ldisc->users) != 1) {
+			char cur_n[TASK_COMM_LEN], tty_n[64];
+			long timeout = 3 * HZ;
+			tty_unlock();
+
+			while (tty_ldisc_wait_idle(tty, timeout) == -EBUSY) {
+				timeout = MAX_SCHEDULE_TIMEOUT;
+				printk_ratelimited(KERN_WARNING
+					"%s: waiting (%s) for %s took too long, but we keep waiting...\n",
+					__func__, get_task_comm(cur_n, current),
+					tty_name(tty, tty_n));
+			}
+			mutex_unlock(&tty->ldisc_mutex);
+			goto retry;
+		}
 
 		if (reset == 0) {
 
author
#26 lore raw

PATCH 26/53 nfs: when attempting to open a directory, fall back on normal lookup (try #5)

In reply to Greg KH

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

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

From: Jeff Layton <[email protected]>

commit 1788ea6e3b2a58cf4fb00206e362d9caff8d86a7 upstream.

commit d953126 changed how nfs_atomic_lookup handles an -EISDIR return from an OPEN call. Prior to that patch, that caused the client to fall back to doing a normal lookup. When that patch went in, the code began returning that error to userspace. The d_revalidate codepath however never had the corresponding change, so it was still possible to end up with a NULL ctx->state pointer after that.

That patch caused a regression. When we attempt to open a directory that does not have a cached dentry, that open now errors out with EISDIR. If you attempt the same open with a cached dentry, it will succeed.

Fix this by reverting the change in nfs_atomic_lookup and allowing attempts to open directories to fall back to a normal lookup

Also, add a NFSv4-specific f_ops->open routine that just returns -ENOTDIR. This should never be called if things are working properly, but if it ever is, then the dprintk may help in debugging.

To facilitate this, a new file_operations field is also added to the nfs_rpc_ops struct.

---
 fs/nfs/dir.c            |    2 +-
 fs/nfs/file.c           |   32 ++++++++++++++++++++++++++++++++
 fs/nfs/inode.c          |    2 +-
 fs/nfs/nfs3proc.c       |    1 +
 fs/nfs/nfs4proc.c       |    1 +
 fs/nfs/proc.c           |    1 +
 include/linux/nfs_fs.h  |    3 +++
 include/linux/nfs_xdr.h |    1 +
 8 files changed, 41 insertions(+), 2 deletions(-)
fs/nfs/dir.c +1 -1
@@ -1468,12 +1468,12 @@ static struct dentry *nfs_atomic_lookup(
 				res = NULL;
 				goto out;
 			/* This turned out not to be a regular file */
+			case -EISDIR:
 			case -ENOTDIR:
 				goto no_open;
 			case -ELOOP:
 				if (!(nd->intent.open.flags & O_NOFOLLOW))
 					goto no_open;
-			/* case -EISDIR: */
 			/* case -EINVAL: */
 			default:
 				res = ERR_CAST(inode);
fs/nfs/file.c +32 -0
@@ -895,3 +895,35 @@ static int nfs_setlease(struct file *fil
 			file->f_path.dentry->d_name.name, arg);
 	return -EINVAL;
 }
+
+#ifdef CONFIG_NFS_V4
+static int
+nfs4_file_open(struct inode *inode, struct file *filp)
+{
+	/*
+	 * NFSv4 opens are handled in d_lookup and d_revalidate. If we get to
+	 * this point, then something is very wrong
+	 */
+	dprintk("NFS: %s called! inode=%p filp=%p\n", __func__, inode, filp);
+	return -ENOTDIR;
+}
+
+const struct file_operations nfs4_file_operations = {
+	.llseek		= nfs_file_llseek,
+	.read		= do_sync_read,
+	.write		= do_sync_write,
+	.aio_read	= nfs_file_read,
+	.aio_write	= nfs_file_write,
+	.mmap		= nfs_file_mmap,
+	.open		= nfs4_file_open,
+	.flush		= nfs_file_flush,
+	.release	= nfs_file_release,
+	.fsync		= nfs_file_fsync,
+	.lock		= nfs_lock,
+	.flock		= nfs_flock,
+	.splice_read	= nfs_file_splice_read,
+	.splice_write	= nfs_file_splice_write,
+	.check_flags	= nfs_check_flags,
+	.setlease	= nfs_setlease,
+};
+#endif /* CONFIG_NFS_V4 */
fs/nfs/inode.c +1 -1
@@ -291,7 +291,7 @@ nfs_fhget(struct super_block *sb, struct
 		 */
 		inode->i_op = NFS_SB(sb)->nfs_client->rpc_ops->file_inode_ops;
 		if (S_ISREG(inode->i_mode)) {
-			inode->i_fop = &nfs_file_operations;
+			inode->i_fop = NFS_SB(sb)->nfs_client->rpc_ops->file_ops;
 			inode->i_data.a_ops = &nfs_file_aops;
 			inode->i_data.backing_dev_info = &NFS_SB(sb)->backing_dev_info;
 		} else if (S_ISDIR(inode->i_mode)) {
fs/nfs/nfs3proc.c +1 -0
@@ -853,6 +853,7 @@ const struct nfs_rpc_ops nfs_v3_clientop
 	.dentry_ops	= &nfs_dentry_operations,
 	.dir_inode_ops	= &nfs3_dir_inode_operations,
 	.file_inode_ops	= &nfs3_file_inode_operations,
+	.file_ops	= &nfs_file_operations,
 	.getroot	= nfs3_proc_get_root,
 	.getattr	= nfs3_proc_getattr,
 	.setattr	= nfs3_proc_setattr,
fs/nfs/nfs4proc.c +1 -0
@@ -6267,6 +6267,7 @@ const struct nfs_rpc_ops nfs_v4_clientop
 	.dentry_ops	= &nfs4_dentry_operations,
 	.dir_inode_ops	= &nfs4_dir_inode_operations,
 	.file_inode_ops	= &nfs4_file_inode_operations,
+	.file_ops	= &nfs4_file_operations,
 	.getroot	= nfs4_proc_get_root,
 	.getattr	= nfs4_proc_getattr,
 	.setattr	= nfs4_proc_setattr,
fs/nfs/proc.c +1 -0
@@ -710,6 +710,7 @@ const struct nfs_rpc_ops nfs_v2_clientop
 	.dentry_ops	= &nfs_dentry_operations,
 	.dir_inode_ops	= &nfs_dir_inode_operations,
 	.file_inode_ops	= &nfs_file_inode_operations,
+	.file_ops	= &nfs_file_operations,
 	.getroot	= nfs_proc_get_root,
 	.getattr	= nfs_proc_getattr,
 	.setattr	= nfs_proc_setattr,
include/linux/nfs_fs.h +3 -0
@@ -410,6 +410,9 @@ extern const struct inode_operations nfs
 extern const struct inode_operations nfs3_file_inode_operations;
 #endif /* CONFIG_NFS_V3 */
 extern const struct file_operations nfs_file_operations;
+#ifdef CONFIG_NFS_V4
+extern const struct file_operations nfs4_file_operations;
+#endif /* CONFIG_NFS_V4 */
 extern const struct address_space_operations nfs_file_aops;
 extern const struct address_space_operations nfs_dir_aops;
 
include/linux/nfs_xdr.h +1 -0
@@ -1194,6 +1194,7 @@ struct nfs_rpc_ops {
 	const struct dentry_operations *dentry_ops;
 	const struct inode_operations *dir_inode_ops;
 	const struct inode_operations *file_inode_ops;
+	const struct file_operations *file_ops;
 
 	int	(*getroot) (struct nfs_server *, struct nfs_fh *,
 			    struct nfs_fsinfo *);
author
#27 lore raw

PATCH 27/53 ALSA: hda - fix ELD memory leak

In reply to Greg KH

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

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

Backported from commit b95d68b8179764e29558b75cec35ef4a6a98925b.

memset(eld) clears eld->proc_entry which will leak the struct snd_info_entry when unloading module.

Fix it by
- memset only the fields before eld->eld_buffer
- set eld->eld_valid to true _after_ all eld fields have been filled

---
 sound/pci/hda/hda_eld.c    |    5 +----
 sound/pci/hda/patch_hdmi.c |   15 +++++++++------
 2 files changed, 10 insertions(+), 10 deletions(-)
sound/pci/hda/hda_eld.c +1 -4
@@ -297,10 +297,10 @@ static int hdmi_update_eld(struct hdmi_e
 					buf + ELD_FIXED_BYTES + mnl + 3 * i);
 	}
 
+	e->eld_valid = true;
 	return 0;
 
 out_fail:
-	e->eld_ver = 0;
 	return -EINVAL;
 }
 
@@ -318,9 +318,6 @@ int snd_hdmi_get_eld(struct hdmi_eld *el
 	int size;
 	unsigned char *buf;
 
-	if (!eld->eld_valid)
-		return -ENOENT;
-
 	size = snd_hdmi_get_eld_size(codec, nid);
 	if (size == 0) {
 		/* wfg: workaround for ASUS P5E-VM HDMI board */
sound/pci/hda/patch_hdmi.c +9 -6
@@ -920,20 +920,23 @@ static void hdmi_present_sense(struct hd
 	 * the unsolicited response to avoid custom WARs.
 	 */
 	int present = snd_hda_pin_sense(codec, pin_nid);
+	bool eld_valid = false;
 
-	memset(eld, 0, sizeof(*eld));
+#ifdef CONFIG_PROC_FS
+	memset(eld, 0, offsetof(struct hdmi_eld, proc_entry));
+#else
+	memset(eld, 0, sizeof(struct hdmi_eld));
+#endif
 
 	eld->monitor_present	= !!(present & AC_PINSENSE_PRESENCE);
 	if (eld->monitor_present)
-		eld->eld_valid	= !!(present & AC_PINSENSE_ELDV);
-	else
-		eld->eld_valid	= 0;
+		eld_valid	= !!(present & AC_PINSENSE_ELDV);
 
 	printk(KERN_INFO
 		"HDMI status: Codec=%d Pin=%d Presence_Detect=%d ELD_Valid=%d\n",
-		codec->addr, pin_nid, eld->monitor_present, eld->eld_valid);
+		codec->addr, pin_nid, eld->monitor_present, eld_valid);
 
-	if (eld->eld_valid)
+	if (eld_valid)
 		if (!snd_hdmi_get_eld(eld, codec, pin_nid))
 			snd_hdmi_show_eld(eld);
 
author
#28 lore raw

PATCH 28/53 pcie-gadget-spear: Add "platform:" prefix for platform modalias

In reply to Greg KH

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

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

From: Axel Lin <[email protected]>

commit 161f14191dc166c4e3f37f68af1bc199c6868b7d upstream.

Since 43cc71eed1250755986da4c0f9898f9a635cb3bf (platform: prefix MODALIAS with "platform:"), the platform modalias is prefixed with "platform:".

---
 drivers/misc/spear13xx_pcie_gadget.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/misc/spear13xx_pcie_gadget.c +1 -1
@@ -903,6 +903,6 @@ static void __exit spear_pcie_gadget_exi
 }
 module_exit(spear_pcie_gadget_exit);
 
-MODULE_ALIAS("pcie-gadget-spear");
+MODULE_ALIAS("platform:pcie-gadget-spear");
 MODULE_AUTHOR("Pratyush Anand");
 MODULE_LICENSE("GPL");
author
#29 lore raw

PATCH 29/53 drivers/base/node.c: fix compilation error with older versions of gcc

In reply to Greg KH

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

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

From: Claudio Scordino <[email protected]>

commit 91a13c281d7d4648c0b32dede11a0144c4e7984c upstream.

Patch to fix the error message "directives may not be used inside a macro argument" which appears when the kernel is compiled for the cris architecture.

---
 drivers/base/node.c |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/base/node.c +8 -6
@@ -127,12 +127,13 @@ static ssize_t node_read_meminfo(struct
 		       nid, K(node_page_state(nid, NR_WRITEBACK)),
 		       nid, K(node_page_state(nid, NR_FILE_PAGES)),
 		       nid, K(node_page_state(nid, NR_FILE_MAPPED)),
-		       nid, K(node_page_state(nid, NR_ANON_PAGES)
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
+		       nid, K(node_page_state(nid, NR_ANON_PAGES)
 			+ node_page_state(nid, NR_ANON_TRANSPARENT_HUGEPAGES) *
-			HPAGE_PMD_NR
+			HPAGE_PMD_NR),
+#else
+		       nid, K(node_page_state(nid, NR_ANON_PAGES)),
 #endif
-		       ),
 		       nid, K(node_page_state(nid, NR_SHMEM)),
 		       nid, node_page_state(nid, NR_KERNEL_STACK) *
 				THREAD_SIZE / 1024,
@@ -143,13 +144,14 @@ static ssize_t node_read_meminfo(struct
 		       nid, K(node_page_state(nid, NR_SLAB_RECLAIMABLE) +
 				node_page_state(nid, NR_SLAB_UNRECLAIMABLE)),
 		       nid, K(node_page_state(nid, NR_SLAB_RECLAIMABLE)),
-		       nid, K(node_page_state(nid, NR_SLAB_UNRECLAIMABLE))
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
+		       nid, K(node_page_state(nid, NR_SLAB_UNRECLAIMABLE))
 			, nid,
 			K(node_page_state(nid, NR_ANON_TRANSPARENT_HUGEPAGES) *
-			HPAGE_PMD_NR)
+			HPAGE_PMD_NR));
+#else
+		       nid, K(node_page_state(nid, NR_SLAB_UNRECLAIMABLE)));
 #endif
-		       );
 	n += hugetlb_report_node_meminfo(nid, buf + n);
 	return n;
 }
author
#30 lore raw

PATCH 30/53 xhci: Set slot and ep0 flags for address command.

In reply to Greg KH

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

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

From: Sarah Sharp <[email protected]>

commit d31c285b3a71cf9056e6a060de41f37780b0af86 upstream.

Matt's AsMedia xHCI host controller was responding with a Context Error to an address device command after a configured device reset. Some sequence of events leads both the slot and endpoint zero add flags cleared to zero, which the AsMedia host doesn't like:

[  223.701839] xhci_hcd 0000:03:00.0: Slot ID 1 Input Context:
[  223.701841] xhci_hcd 0000:03:00.0: @ffff880137b25000 (virt) @ffffc000 (dma) 0x000000 - drop flags
[  223.701843] xhci_hcd 0000:03:00.0: @ffff880137b25004 (virt) @ffffc004 (dma) 0x000000 - add flags
[  223.701846] xhci_hcd 0000:03:00.0: @ffff880137b25008 (virt) @ffffc008 (dma) 0x000000 - rsvd2[0]
[  223.701848] xhci_hcd 0000:03:00.0: @ffff880137b2500c (virt) @ffffc00c (dma) 0x000000 - rsvd2[1]
[  223.701850] xhci_hcd 0000:03:00.0: @ffff880137b25010 (virt) @ffffc010 (dma) 0x000000 - rsvd2[2]
[  223.701852] xhci_hcd 0000:03:00.0: @ffff880137b25014 (virt) @ffffc014 (dma) 0x000000 - rsvd2[3]
[  223.701854] xhci_hcd 0000:03:00.0: @ffff880137b25018 (virt) @ffffc018 (dma) 0x000000 - rsvd2[4]
[  223.701857] xhci_hcd 0000:03:00.0: @ffff880137b2501c (virt) @ffffc01c (dma) 0x000000 - rsvd2[5]
[  223.701858] xhci_hcd 0000:03:00.0: Slot Context:
[  223.701860] xhci_hcd 0000:03:00.0: @ffff880137b25020 (virt) @ffffc020 (dma) 0x8400000 - dev_info
[  223.701862] xhci_hcd 0000:03:00.0: @ffff880137b25024 (virt) @ffffc024 (dma) 0x010000 - dev_info2
[  223.701864] xhci_hcd 0000:03:00.0: @ffff880137b25028 (virt) @ffffc028 (dma) 0x000000 - tt_info
[  223.701866] xhci_hcd 0000:03:00.0: @ffff880137b2502c (virt) @ffffc02c (dma) 0x000000 - dev_state
[  223.701869] xhci_hcd 0000:03:00.0: @ffff880137b25030 (virt) @ffffc030 (dma) 0x000000 - rsvd[0]
[  223.701871] xhci_hcd 0000:03:00.0: @ffff880137b25034 (virt) @ffffc034 (dma) 0x000000 - rsvd[1]
[  223.701873] xhci_hcd 0000:03:00.0: @ffff880137b25038 (virt) @ffffc038 (dma) 0x000000 - rsvd[2]
[  223.701875] xhci_hcd 0000:03:00.0: @ffff880137b2503c (virt) @ffffc03c (dma) 0x000000 - rsvd[3]
[  223.701877] xhci_hcd 0000:03:00.0: Endpoint 00 Context:
[  223.701879] xhci_hcd 0000:03:00.0: @ffff880137b25040 (virt) @ffffc040 (dma) 0x000000 - ep_info
[  223.701881] xhci_hcd 0000:03:00.0: @ffff880137b25044 (virt) @ffffc044 (dma) 0x2000026 - ep_info2
[  223.701883] xhci_hcd 0000:03:00.0: @ffff880137b25048 (virt) @ffffc048 (dma) 0xffffe8e0 - deq
[  223.701885] xhci_hcd 0000:03:00.0: @ffff880137b25050 (virt) @ffffc050 (dma) 0x000000 - tx_info
[  223.701887] xhci_hcd 0000:03:00.0: @ffff880137b25054 (virt) @ffffc054 (dma) 0x000000 - rsvd[0]
[  223.701889] xhci_hcd 0000:03:00.0: @ffff880137b25058 (virt) @ffffc058 (dma) 0x000000 - rsvd[1]
[  223.701892] xhci_hcd 0000:03:00.0: @ffff880137b2505c (virt) @ffffc05c (dma) 0x000000 - rsvd[2]
...
[  223.701927] xhci_hcd 0000:03:00.0: // Ding dong!
[  223.701992] xhci_hcd 0000:03:00.0: Setup ERROR: address device command for slot 1.

The xHCI spec says that both flags must be set to one for the Address Device command. When the device is first enumerated, xhci_setup_addressable_virt_dev() does set those flags. However, when the device is addressed after it has been reset in the configured state, xhci_setup_addressable_virt_dev() is not called, and xhci_copy_ep0_dequeue_into_input_ctx() is called instead. That function relies on the flags being set up by previous commands, which apparently isn't a good assumption.

Move the setting of the flags into the common parent function.

This should be queued for stable kernels as old as 2.6.35, since that was the first introduction of xhci_copy_ep0_dequeue_into_input_ctx.

---
 drivers/usb/host/xhci-mem.c |    5 -----
 drivers/usb/host/xhci.c     |    5 ++++-
 2 files changed, 4 insertions(+), 6 deletions(-)
drivers/usb/host/xhci-mem.c +0 -5
@@ -875,7 +875,6 @@ int xhci_setup_addressable_virt_dev(stru
 	struct xhci_virt_device *dev;
 	struct xhci_ep_ctx	*ep0_ctx;
 	struct xhci_slot_ctx    *slot_ctx;
-	struct xhci_input_control_ctx *ctrl_ctx;
 	u32			port_num;
 	struct usb_device *top_dev;
 
@@ -887,12 +886,8 @@ int xhci_setup_addressable_virt_dev(stru
 		return -EINVAL;
 	}
 	ep0_ctx = xhci_get_ep_ctx(xhci, dev->in_ctx, 0);
-	ctrl_ctx = xhci_get_input_control_ctx(xhci, dev->in_ctx);
 	slot_ctx = xhci_get_slot_ctx(xhci, dev->in_ctx);
 
-	/* 2) New slot context and endpoint 0 context are valid*/
-	ctrl_ctx->add_flags = cpu_to_le32(SLOT_FLAG | EP0_FLAG);
-
 	/* 3) Only the control endpoint is valid - one endpoint context */
 	slot_ctx->dev_info |= cpu_to_le32(LAST_CTX(1) | udev->route);
 	switch (udev->speed) {
drivers/usb/host/xhci.c +4 -1
@@ -2873,6 +2873,10 @@ int xhci_address_device(struct usb_hcd *
 	/* Otherwise, update the control endpoint ring enqueue pointer. */
 	else
 		xhci_copy_ep0_dequeue_into_input_ctx(xhci, udev);
+	ctrl_ctx = xhci_get_input_control_ctx(xhci, virt_dev->in_ctx);
+	ctrl_ctx->add_flags = cpu_to_le32(SLOT_FLAG | EP0_FLAG);
+	ctrl_ctx->drop_flags = 0;
+
 	xhci_dbg(xhci, "Slot ID %d Input Context:\n", udev->slot_id);
 	xhci_dbg_ctx(xhci, virt_dev->in_ctx, 2);
 
@@ -2954,7 +2958,6 @@ int xhci_address_device(struct usb_hcd *
 	virt_dev->address = (le32_to_cpu(slot_ctx->dev_state) & DEV_ADDR_MASK)
 		+ 1;
 	/* Zero the input context control for later use */
-	ctrl_ctx = xhci_get_input_control_ctx(xhci, virt_dev->in_ctx);
 	ctrl_ctx->add_flags = 0;
 	ctrl_ctx->drop_flags = 0;
 
author
#31 lore raw

PATCH 31/53 usb, xhci: Clear warm reset change event during init

In reply to Greg KH

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

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

From: Don Zickus <[email protected]>

commit 79c3dd8150fd5236d95766a9e662e3e932b462c9 upstream.

I noticed on my Panther Point system that I wasn't getting hotplug events for my usb3.0 disk on a usb3 port. I tracked it down to the fact that the system had the warm reset change bit still set. This seemed to block future events from being received, including a hotplug event.

Clearing this bit during initialization allowed the hotplug event to be received and the disk to be recognized correctly.

This patch should be backported to kernels as old as 2.6.39.

---
 drivers/usb/core/hub.c |    6 ++++++
 1 file changed, 6 insertions(+)
drivers/usb/core/hub.c +6 -0
@@ -813,6 +813,12 @@ static void hub_activate(struct usb_hub
 					USB_PORT_FEAT_C_PORT_LINK_STATE);
 		}
 
+		if ((portchange & USB_PORT_STAT_C_BH_RESET) &&
+				hub_is_superspeed(hub->hdev)) {
+			need_debounce_delay = true;
+			clear_port_feature(hub->hdev, port1,
+					USB_PORT_FEAT_C_BH_PORT_RESET);
+		}
 		/* We can forget about a "removed" device when there's a
 		 * physical disconnect or the connect status changes.
 		 */
author
#32 lore raw

PATCH 32/53 usb, xhci: fix lockdep warning on endpoint timeout

In reply to Greg KH

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

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

From: Don Zickus <[email protected]>

commit f43d623164022dcbf6750ef220b7a1133a1183eb upstream.

While debugging a usb3 problem, I stumbled upon this lockdep warning.

Oct 18 21:41:17 dhcp47-74 kernel: =================================
Oct 18 21:41:17 dhcp47-74 kernel: [ INFO: inconsistent lock state ]
Oct 18 21:41:17 dhcp47-74 kernel: 3.1.0-rc4nmi+ #456
Oct 18 21:41:17 dhcp47-74 kernel: ---------------------------------
Oct 18 21:41:17 dhcp47-74 kernel: inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
Oct 18 21:41:17 dhcp47-74 kernel: swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
Oct 18 21:41:17 dhcp47-74 kernel: (&(&xhci->lock)->rlock){?.-...}, at: [<ffffffffa0228990>] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: {IN-HARDIRQ-W} state was registered at:
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8109a941>] __lock_acquire+0x781/0x1660
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8109bed7>] lock_acquire+0x97/0x170
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81501b46>] _raw_spin_lock+0x46/0x80
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa02299fa>] xhci_irq+0x3a/0x1960 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa022b351>] xhci_msi_irq+0x31/0x40 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d2305>] handle_irq_event_percpu+0x85/0x320
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d25e8>] handle_irq_event+0x48/0x70
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d537d>] handle_edge_irq+0x6d/0x130
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810048c9>] handle_irq+0x49/0xa0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8150d56d>] do_IRQ+0x5d/0xe0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff815029b0>] ret_from_intr+0x0/0x13
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81388aca>] usb_set_device_state+0x8a/0x180
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8138f038>] usb_add_hcd+0x2b8/0x730
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa022ed7e>] xhci_pci_probe+0x9e/0xd4 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127915f>] local_pci_probe+0x5f/0xd0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127a569>] pci_device_probe+0x119/0x120
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81334473>] driver_probe_device+0xa3/0x2c0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8133473b>] __driver_attach+0xab/0xb0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8133373c>] bus_for_each_dev+0x6c/0xa0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff813341fe>] driver_attach+0x1e/0x20
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81333b88>] bus_add_driver+0x1f8/0x2b0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81334df6>] driver_register+0x76/0x140
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127a7c6>] __pci_register_driver+0x66/0xe0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa013c04a>] snd_timer_find+0x4a/0x70 [snd_timer]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa013c00e>] snd_timer_find+0xe/0x70 [snd_timer]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810001d3>] do_one_initcall+0x43/0x180
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810a9ed2>] sys_init_module+0x92/0x1f0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8150ab6b>] system_call_fastpath+0x16/0x1b
Oct 18 21:41:17 dhcp47-74 kernel: irq event stamp: 631984
Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last  enabled at (631984): [<ffffffff81502720>] _raw_spin_unlock_irq+0x30/0x50
Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last disabled at (631983): [<ffffffff81501c49>] _raw_spin_lock_irq+0x19/0x90
Oct 18 21:41:17 dhcp47-74 kernel: softirqs last  enabled at (631980): [<ffffffff8105ff63>] _local_bh_enable+0x13/0x20
Oct 18 21:41:17 dhcp47-74 kernel: softirqs last disabled at (631981): [<ffffffff8150ce6c>] call_softirq+0x1c/0x30
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: other info that might help us debug this:
Oct 18 21:41:17 dhcp47-74 kernel: Possible unsafe locking scenario:
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel:       CPU0
Oct 18 21:41:17 dhcp47-74 kernel:       ----
Oct 18 21:41:17 dhcp47-74 kernel:  lock(&(&xhci->lock)->rlock);
Oct 18 21:41:17 dhcp47-74 kernel:  <Interrupt>
Oct 18 21:41:17 dhcp47-74 kernel:    lock(&(&xhci->lock)->rlock);
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: *** DEADLOCK ***
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: 1 lock held by swapper/0:
Oct 18 21:41:17 dhcp47-74 kernel: #0:  (&ep->stop_cmd_timer){+.-...}, at: [<ffffffff8106abf2>] run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: stack backtrace:
Oct 18 21:41:17 dhcp47-74 kernel: Pid: 0, comm: swapper Tainted: G        W   3.1.0-rc4nmi+ #456
Oct 18 21:41:17 dhcp47-74 kernel: Call Trace:
Oct 18 21:41:17 dhcp47-74 kernel: <IRQ>  [<ffffffff81098ed7>] print_usage_bug+0x227/0x270
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810999c6>] mark_lock+0x346/0x410
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109a7de>] __lock_acquire+0x61e/0x1660
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81099893>] ? mark_lock+0x213/0x410
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109bed7>] lock_acquire+0x97/0x170
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81501b46>] _raw_spin_lock+0x46/0x80
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106abf2>] ? run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106ac9d>] run_timer_softirq+0x20d/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106abf2>] ? run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228960>] ? xhci_queue_isoc_tx_prepare+0x8e0/0x8e0 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810604d2>] __do_softirq+0xf2/0x3f0
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81020edd>] ? lapic_next_event+0x1d/0x30
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81090d4e>] ? clockevents_program_event+0x5e/0x90
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150ce6c>] call_softirq+0x1c/0x30
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8100484d>] do_softirq+0x8d/0xc0
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8105ff35>] irq_exit+0xe5/0x100
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150d65e>] smp_apic_timer_interrupt+0x6e/0x99
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150b6f0>] apic_timer_interrupt+0x70/0x80
Oct 18 21:41:17 dhcp47-74 kernel: <EOI>  [<ffffffff81095d8d>] ? trace_hardirqs_off+0xd/0x10
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff812ddb76>] ? acpi_idle_enter_bm+0x227/0x25b
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff812ddb71>] ? acpi_idle_enter_bm+0x222/0x25b
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff813eda63>] cpuidle_idle_call+0x103/0x290
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81002155>] cpu_idle+0xe5/0x160
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff814e7f50>] rest_init+0xe0/0xf0
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff814e7e70>] ? csum_partial_copy_generic+0x170/0x170
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8e23>] start_kernel+0x3fc/0x407
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8321>] x86_64_start_reservations+0x131/0x135
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8412>] x86_64_start_kernel+0xed/0xf4
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: Assuming host is dying, halting host.
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -110
Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -22
Oct 18 21:41:17 dhcp47-74 kernel: hub 3-0:1.0: cannot disable port 4 (err = -19)

Basically what is happening is in xhci_stop_endpoint_command_watchdog() the xhci->lock is grabbed with just spin_lock. What lockdep deduces is that if an interrupt occurred while in this function it would deadlock with xhci_irq because that function also grabs the xhci->lock.

Fixing it is trivial by using spin_lock_irqsave instead.

This should be queued to stable kernels as far back as 2.6.33.

---
 drivers/usb/host/xhci-ring.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)
drivers/usb/host/xhci-ring.c +7 -6
@@ -816,23 +816,24 @@ void xhci_stop_endpoint_command_watchdog
 	struct xhci_ring *ring;
 	struct xhci_td *cur_td;
 	int ret, i, j;
+	unsigned long flags;
 
 	ep = (struct xhci_virt_ep *) arg;
 	xhci = ep->xhci;
 
-	spin_lock(&xhci->lock);
+	spin_lock_irqsave(&xhci->lock, flags);
 
 	ep->stop_cmds_pending--;
 	if (xhci->xhc_state & XHCI_STATE_DYING) {
 		xhci_dbg(xhci, "Stop EP timer ran, but another timer marked "
 				"xHCI as DYING, exiting.\n");
-		spin_unlock(&xhci->lock);
+		spin_unlock_irqrestore(&xhci->lock, flags);
 		return;
 	}
 	if (!(ep->stop_cmds_pending == 0 && (ep->ep_state & EP_HALT_PENDING))) {
 		xhci_dbg(xhci, "Stop EP timer ran, but no command pending, "
 				"exiting.\n");
-		spin_unlock(&xhci->lock);
+		spin_unlock_irqrestore(&xhci->lock, flags);
 		return;
 	}
 
@@ -844,11 +845,11 @@ void xhci_stop_endpoint_command_watchdog
 	xhci->xhc_state |= XHCI_STATE_DYING;
 	/* Disable interrupts from the host controller and start halting it */
 	xhci_quiesce(xhci);
-	spin_unlock(&xhci->lock);
+	spin_unlock_irqrestore(&xhci->lock, flags);
 
 	ret = xhci_halt(xhci);
 
-	spin_lock(&xhci->lock);
+	spin_lock_irqsave(&xhci->lock, flags);
 	if (ret < 0) {
 		/* This is bad; the host is not responding to commands and it's
 		 * not allowing itself to be halted.  At least interrupts are
@@ -896,7 +897,7 @@ void xhci_stop_endpoint_command_watchdog
 			}
 		}
 	}
-	spin_unlock(&xhci->lock);
+	spin_unlock_irqrestore(&xhci->lock, flags);
 	xhci_dbg(xhci, "Calling usb_hc_died()\n");
 	usb_hc_died(xhci_to_hcd(xhci)->primary_hcd);
 	xhci_dbg(xhci, "xHCI host controller is dead.\n");
author
#33 lore raw

PATCH 33/53 USB: XHCI: resume root hubs when the controller resumes

In reply to Greg KH

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

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

From: Alan Stern <[email protected]>

commit f69e3120df82391a0ee8118e0a156239a06b2afb upstream.

This patch (as1494) fixes a problem in xhci-hcd's resume routine. When the controller is runtime-resumed, this can only mean that one of the two root hubs has made a wakeup request and therefore needs to be resumed as well. Rather than try to determine which root hub requires attention (which might be difficult in the case where a new non-SuperSpeed device has been plugged in), the patch simply resumes both root hubs.

Without this change, there is a race: The controller might be put back to sleep before it can activate its IRQ line, and the wakeup condition might never get handled.

The patch also simplifies the logic in xhci_resume a little, combining some repeated flag settings into a single pair of statements.

---
 drivers/usb/host/xhci.c |   29 ++++++++++++++---------------
 1 file changed, 14 insertions(+), 15 deletions(-)
drivers/usb/host/xhci.c +14 -15
@@ -749,7 +749,7 @@ int xhci_resume(struct xhci_hcd *xhci, b
 	u32			command, temp = 0;
 	struct usb_hcd		*hcd = xhci_to_hcd(xhci);
 	struct usb_hcd		*secondary_hcd;
-	int			retval;
+	int			retval = 0;
 
 	/* Wait a bit if either of the roothubs need to settle from the
 	 * transition into bus suspend.
@@ -759,6 +759,9 @@ int xhci_resume(struct xhci_hcd *xhci, b
 				xhci->bus_state[1].next_statechange))
 		msleep(100);
 
+	set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
+	set_bit(HCD_FLAG_HW_ACCESSIBLE, &xhci->shared_hcd->flags);
+
 	spin_lock_irq(&xhci->lock);
 	if (xhci->quirks & XHCI_RESET_ON_RESUME)
 		hibernated = true;
@@ -828,20 +831,13 @@ int xhci_resume(struct xhci_hcd *xhci, b
 			return retval;
 		xhci_dbg(xhci, "Start the primary HCD\n");
 		retval = xhci_run(hcd->primary_hcd);
-		if (retval)
-			goto failed_restart;
-
-		xhci_dbg(xhci, "Start the secondary HCD\n");
-		retval = xhci_run(secondary_hcd);
 		if (!retval) {
-			set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
-			set_bit(HCD_FLAG_HW_ACCESSIBLE,
-					&xhci->shared_hcd->flags);
+			xhci_dbg(xhci, "Start the secondary HCD\n");
+			retval = xhci_run(secondary_hcd);
 		}
-failed_restart:
 		hcd->state = HC_STATE_SUSPENDED;
 		xhci->shared_hcd->state = HC_STATE_SUSPENDED;
-		return retval;
+		goto done;
 	}
 
 	/* step 4: set Run/Stop bit */
@@ -860,11 +856,14 @@ failed_restart:
 	 * Running endpoints by ringing their doorbells
 	 */
 
-	set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
-	set_bit(HCD_FLAG_HW_ACCESSIBLE, &xhci->shared_hcd->flags);
-
 	spin_unlock_irq(&xhci->lock);
-	return 0;
+
+ done:
+	if (retval == 0) {
+		usb_hcd_resume_root_hub(hcd);
+		usb_hcd_resume_root_hub(xhci->shared_hcd);
+	}
+	return retval;
 }
 #endif	/* CONFIG_PM */
 
author
#34 lore raw

PATCH 34/53 USB: option: release new PID for ZTE 3G modem

In reply to Greg KH

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

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

From: "[email protected]" <[email protected]>

commit 46b5a277ed90317a4d17e936c16037e76011b219 upstream.

This patch adds new PIDs for ZTE 3G modem, after we confirm it and tested. Thanks for Dan's work at kernel option devier.

---
 drivers/usb/serial/option.c |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)
drivers/usb/serial/option.c +21 -0
@@ -316,6 +316,9 @@ static void option_instat_callback(struc
 #define ZTE_PRODUCT_AC8710			0xfff1
 #define ZTE_PRODUCT_AC2726			0xfff5
 #define ZTE_PRODUCT_AC8710T			0xffff
+#define ZTE_PRODUCT_MC2718			0xffe8
+#define ZTE_PRODUCT_AD3812			0xffeb
+#define ZTE_PRODUCT_MC2716			0xffed
 
 #define BENQ_VENDOR_ID				0x04a5
 #define BENQ_PRODUCT_H10			0x4068
@@ -500,6 +503,18 @@ static const struct option_blacklist_inf
 	.reserved = BIT(4),
 };
 
+static const struct option_blacklist_info zte_ad3812_z_blacklist = {
+	.sendsetup = BIT(0) | BIT(1) | BIT(2),
+};
+
+static const struct option_blacklist_info zte_mc2718_z_blacklist = {
+	.sendsetup = BIT(1) | BIT(2) | BIT(3) | BIT(4),
+};
+
+static const struct option_blacklist_info zte_mc2716_z_blacklist = {
+	.sendsetup = BIT(1) | BIT(2) | BIT(3),
+};
+
 static const struct option_blacklist_info huawei_cdc12_blacklist = {
 	.reserved = BIT(1) | BIT(2),
 };
@@ -1043,6 +1058,12 @@ static const struct usb_device_id option
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC8710, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC2726, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC8710T, 0xff, 0xff, 0xff) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2718, 0xff, 0xff, 0xff),
+	 .driver_info = (kernel_ulong_t)&zte_mc2718_z_blacklist },
+	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AD3812, 0xff, 0xff, 0xff),
+	 .driver_info = (kernel_ulong_t)&zte_ad3812_z_blacklist },
+	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2716, 0xff, 0xff, 0xff),
+	 .driver_info = (kernel_ulong_t)&zte_mc2716_z_blacklist },
 	{ USB_DEVICE(BENQ_VENDOR_ID, BENQ_PRODUCT_H10) },
 	{ USB_DEVICE(DLINK_VENDOR_ID, DLINK_PRODUCT_DWM_652) },
 	{ USB_DEVICE(ALINK_VENDOR_ID, DLINK_PRODUCT_DWM_652_U5) }, /* Yes, ALINK_VENDOR_ID */
author
#35 lore raw

PATCH 35/53 USB: option: add PID of Huawei E173s 3G modem

In reply to Greg KH

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

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

From: Ferenc Wagner <[email protected]>

commit 4aa3648c719265bac9c2742c9ebb043e6dbdd790 upstream.

---
 drivers/usb/serial/option.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/usb/serial/option.c +2 -0
@@ -156,6 +156,7 @@ static void option_instat_callback(struc
 #define HUAWEI_PRODUCT_K4511			0x14CC
 #define HUAWEI_PRODUCT_ETS1220			0x1803
 #define HUAWEI_PRODUCT_E353			0x1506
+#define HUAWEI_PRODUCT_E173S			0x1C05
 
 #define QUANTA_VENDOR_ID			0x0408
 #define QUANTA_PRODUCT_Q101			0xEA02
@@ -637,6 +638,7 @@ static const struct usb_device_id option
 	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E143D, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E143E, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E143F, 0xff, 0xff, 0xff) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173S, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4505, 0xff, 0xff, 0xff),
 		.driver_info = (kernel_ulong_t) &huawei_cdc12_blacklist },
 	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3765, 0xff, 0xff, 0xff),
author
#36 lore raw

PATCH 36/53 USB: serial: pl2303: rm duplicate id

In reply to Greg KH

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

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

From: wangyanqing <[email protected]>

commit 0c16595539b612fe948559433dda08ff96a8bdc7 upstream.

I get report from customer that his usb-serial converter doesn't work well,it sometimes work, but sometimes it doesn't.

The usb-serial converter's id:
vendor_id product_id
0x4348 0x5523

Then I search the usb-serial codes, and there are
two drivers announce support this device, pl2303
and ch341, commit 026dfaf1 cause it. Through many times to test, ch341 works well with this device,
and pl2303 doesn't work quite often(it just work quite little).

ch341 works well with this device, so we doesn't need pl2303 to support.I try to revert 026dfaf1 first, but it failed. So I prepare this patch by hand to revert it.

---
 drivers/usb/serial/pl2303.c |    1 -
 drivers/usb/serial/pl2303.h |    4 ----
 2 files changed, 5 deletions(-)
drivers/usb/serial/pl2303.c +0 -1
@@ -91,7 +91,6 @@ static const struct usb_device_id id_tab
 	{ USB_DEVICE(SONY_VENDOR_ID, SONY_QN3USB_PRODUCT_ID) },
 	{ USB_DEVICE(SANWA_VENDOR_ID, SANWA_PRODUCT_ID) },
 	{ USB_DEVICE(ADLINK_VENDOR_ID, ADLINK_ND6530_PRODUCT_ID) },
-	{ USB_DEVICE(WINCHIPHEAD_VENDOR_ID, WINCHIPHEAD_USBSER_PRODUCT_ID) },
 	{ USB_DEVICE(SMART_VENDOR_ID, SMART_PRODUCT_ID) },
 	{ }					/* Terminating entry */
 };
drivers/usb/serial/pl2303.h +0 -4
@@ -145,10 +145,6 @@
 #define ADLINK_VENDOR_ID		0x0b63
 #define ADLINK_ND6530_PRODUCT_ID	0x6530
 
-/* WinChipHead USB->RS 232 adapter */
-#define WINCHIPHEAD_VENDOR_ID		0x4348
-#define WINCHIPHEAD_USBSER_PRODUCT_ID	0x5523
-
 /* SMART USB Serial Adapter */
 #define SMART_VENDOR_ID	0x0b8c
 #define SMART_PRODUCT_ID	0x2303
author
#37 lore raw

PATCH 37/53 USB: pch_udc: Support new device LAPIS Semiconductor ML7831 IOH

In reply to Greg KH

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

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

From: Tomoya MORINAGA <[email protected]>

commit 731ad81e2dd97e3f222361f7b3ff4b35639e46af upstream.

ML7831 is companion chip for Intel Atom E6xx series.

---
 drivers/usb/gadget/Kconfig   |    9 +++++----
 drivers/usb/gadget/pch_udc.c |    6 ++++++
 2 files changed, 11 insertions(+), 4 deletions(-)
drivers/usb/gadget/Kconfig +5 -4
@@ -442,7 +442,7 @@ config USB_LANGWELL
 	   gadget drivers to also be dynamically linked.
 
 config USB_EG20T
-	tristate "Intel EG20T PCH/OKI SEMICONDUCTOR ML7213 IOH UDC"
+	tristate "Intel EG20T PCH/LAPIS Semiconductor IOH(ML7213/ML7831) UDC"
 	depends on PCI
 	select USB_GADGET_DUALSPEED
 	help
@@ -458,10 +458,11 @@ config USB_EG20T
 	  This driver dose not support interrupt transfer or isochronous
 	  transfer modes.
 
-	  This driver also can be used for OKI SEMICONDUCTOR's ML7213 which is
+	  This driver also can be used for LAPIS Semiconductor's ML7213 which is
 	  for IVI(In-Vehicle Infotainment) use.
-	  ML7213 is companion chip for Intel Atom E6xx series.
-	  ML7213 is completely compatible for Intel EG20T PCH.
+	  ML7831 is for general purpose use.
+	  ML7213/ML7831 is companion chip for Intel Atom E6xx series.
+	  ML7213/ML7831 is completely compatible for Intel EG20T PCH.
 
 config USB_CI13XXX_MSM
 	tristate "MIPS USB CI13xxx for MSM"
drivers/usb/gadget/pch_udc.c +6 -0
@@ -363,6 +363,7 @@ struct pch_udc_dev {
 #define PCI_DEVICE_ID_INTEL_EG20T_UDC	0x8808
 #define PCI_VENDOR_ID_ROHM		0x10DB
 #define PCI_DEVICE_ID_ML7213_IOH_UDC	0x801D
+#define PCI_DEVICE_ID_ML7831_IOH_UDC	0x8808
 
 static const char	ep0_string[] = "ep0in";
 static DEFINE_SPINLOCK(udc_stall_spinlock);	/* stall spin lock */
@@ -2979,6 +2980,11 @@ static DEFINE_PCI_DEVICE_TABLE(pch_udc_p
 		.class = (PCI_CLASS_SERIAL_USB << 8) | 0xfe,
 		.class_mask = 0xffffffff,
 	},
+	{
+		PCI_DEVICE(PCI_VENDOR_ID_ROHM, PCI_DEVICE_ID_ML7831_IOH_UDC),
+		.class = (PCI_CLASS_SERIAL_USB << 8) | 0xfe,
+		.class_mask = 0xffffffff,
+	},
 	{ 0 },
 };
 
author
#38 lore raw

PATCH 38/53 USB: cdc-acm: Fix disconnect() vs close() race

In reply to Greg KH

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

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

From: Havard Skinnemoen <[email protected]>

commit 5dc2470c602da8851907ec18942cd876c3b4ecc1 upstream.

There's a race between the USB disconnect handler and the TTY close handler which may cause the acm object to be freed while it's still being used. This may lead to things like

http://article.gmane.org/gmane.linux.usb.general/54250

and

https://lkml.org/lkml/2011/5/29/64

This is the simplest fix I could come up with. Holding on to open_mutex while closing the TTY device prevents acm_disconnect() from freeing the acm object between acm->port.count drops to 0 and the TTY side of the cleanups are finalized.

---
 drivers/usb/class/cdc-acm.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/usb/class/cdc-acm.c +5 -3
@@ -539,7 +539,6 @@ static void acm_port_down(struct acm *ac
 {
 	int i;
 
-	mutex_lock(&open_mutex);
 	if (acm->dev) {
 		usb_autopm_get_interface(acm->control);
 		acm_set_control(acm, acm->ctrlout = 0);
@@ -551,14 +550,15 @@ static void acm_port_down(struct acm *ac
 		acm->control->needs_remote_wakeup = 0;
 		usb_autopm_put_interface(acm->control);
 	}
-	mutex_unlock(&open_mutex);
 }
 
 static void acm_tty_hangup(struct tty_struct *tty)
 {
 	struct acm *acm = tty->driver_data;
 	tty_port_hangup(&acm->port);
+	mutex_lock(&open_mutex);
 	acm_port_down(acm);
+	mutex_unlock(&open_mutex);
 }
 
 static void acm_tty_close(struct tty_struct *tty, struct file *filp)
@@ -569,8 +569,9 @@ static void acm_tty_close(struct tty_str
 	   shutdown */
 	if (!acm)
 		return;
+
+	mutex_lock(&open_mutex);
 	if (tty_port_close_start(&acm->port, tty, filp) == 0) {
-		mutex_lock(&open_mutex);
 		if (!acm->dev) {
 			tty_port_tty_set(&acm->port, NULL);
 			acm_tty_unregister(acm);
@@ -582,6 +583,7 @@ static void acm_tty_close(struct tty_str
 	acm_port_down(acm);
 	tty_port_close_end(&acm->port, tty);
 	tty_port_tty_set(&acm->port, NULL);
+	mutex_unlock(&open_mutex);
 }
 
 static int acm_tty_write(struct tty_struct *tty,
author
#39 lore raw

PATCH 39/53 USB: workaround for bug in old version of GCC

In reply to Greg KH

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

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

From: Alan Stern <[email protected]>

commit 97ff22ee3b4cb3a334f7385e269773141aed702f upstream.

This patch (as1491) works around a bug in GCC-3.4.6, which is still supposed to be supported. The number of microseconds in the udelay() call in quirk_usb_disable_ehci() is fixed at 100, but the compiler doesn't understand this and generates a link-time error. So we replace the otherwise unused variable "delta" with a simple constant
100. This same pattern is already used in other delay loops in that source file.

---
 drivers/usb/host/pci-quirks.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
drivers/usb/host/pci-quirks.c +3 -4
@@ -626,7 +626,7 @@ static void __devinit quirk_usb_disable_
 	void __iomem *base, *op_reg_base;
 	u32	hcc_params, cap, val;
 	u8	offset, cap_length;
-	int	wait_time, delta, count = 256/4;
+	int	wait_time, count = 256/4;
 
 	if (!mmio_resource_enabled(pdev, 0))
 		return;
@@ -672,11 +672,10 @@ static void __devinit quirk_usb_disable_
 		writel(val, op_reg_base + EHCI_USBCMD);
 
 		wait_time = 2000;
-		delta = 100;
 		do {
 			writel(0x3f, op_reg_base + EHCI_USBSTS);
-			udelay(delta);
-			wait_time -= delta;
+			udelay(100);
+			wait_time -= 100;
 			val = readl(op_reg_base + EHCI_USBSTS);
 			if ((val == ~(u32)0) || (val & EHCI_USBSTS_HALTED)) {
 				break;
author
#40 lore raw

PATCH 40/53 USB: ark3116 initialisation fix

In reply to Greg KH

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

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

From: Bart Hartgers <[email protected]>

commit 583182ba5f02c8c9be82ea550f2051eaec15b975 upstream.

This patch for the usb serial ark3116 driver fixes an initialisation ordering bug that gets triggered on hotplug when using at least recent debian/ubuntu userspace. Without it, ark3116 serial cables don't work.

---
 drivers/usb/serial/ark3116.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/usb/serial/ark3116.c +5 -5
@@ -42,7 +42,7 @@ static int debug;
  * Version information
  */
 
-#define DRIVER_VERSION "v0.6"
+#define DRIVER_VERSION "v0.7"
 #define DRIVER_AUTHOR "Bart Hartgers <[email protected]>"
 #define DRIVER_DESC "USB ARK3116 serial/IrDA driver"
 #define DRIVER_DEV_DESC "ARK3116 RS232/IrDA"
@@ -380,10 +380,6 @@ static int ark3116_open(struct tty_struc
 		goto err_out;
 	}
 
-	/* setup termios */
-	if (tty)
-		ark3116_set_termios(tty, port, NULL);
-
 	/* remove any data still left: also clears error state */
 	ark3116_read_reg(serial, UART_RX, buf);
 
@@ -406,6 +402,10 @@ static int ark3116_open(struct tty_struc
 	/* enable DMA */
 	ark3116_write_reg(port->serial, UART_FCR, UART_FCR_DMA_SELECT);
 
+	/* setup termios */
+	if (tty)
+		ark3116_set_termios(tty, port, NULL);
+
 err_out:
 	kfree(buf);
 	return result;
author
#41 lore raw

PATCH 41/53 USB: Fix Corruption issue in USB ftdi driver ftdi_sio.c

In reply to Greg KH

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

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

From: Andrew Worsley <[email protected]>

commit b1ffb4c851f185e9051ba837c16d9b84ef688d26 upstream.

Fix for ftdi_set_termios() glitching output

ftdi_set_termios() is constantly setting the baud rate, data bits and parity unnecessarily on every call, . When called while characters are being transmitted can cause the FTDI chip to corrupt the serial port bit stream output by stalling the output half a bit during the output of a character. Simple fix by skipping this setting if the baud rate/data bits/parity are unchanged.

---
 drivers/usb/serial/ftdi_sio.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)
drivers/usb/serial/ftdi_sio.c +11 -3
@@ -2083,13 +2083,19 @@ static void ftdi_set_termios(struct tty_
 
 	cflag = termios->c_cflag;
 
-	/* FIXME -For this cut I don't care if the line is really changing or
-	   not  - so just do the change regardless  - should be able to
-	   compare old_termios and tty->termios */
+	if (old_termios->c_cflag == termios->c_cflag
+	    && old_termios->c_ispeed == termios->c_ispeed
+	    && old_termios->c_ospeed == termios->c_ospeed)
+		goto no_c_cflag_changes;
+
 	/* NOTE These routines can get interrupted by
 	   ftdi_sio_read_bulk_callback  - need to examine what this means -
 	   don't see any problems yet */
 
+	if ((old_termios->c_cflag & (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB)) ==
+	    (termios->c_cflag & (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB)))
+		goto no_data_parity_stop_changes;
+
 	/* Set number of data bits, parity, stop bits */
 
 	urb_value = 0;
@@ -2130,6 +2136,7 @@ static void ftdi_set_termios(struct tty_
 	}
 
 	/* Now do the baudrate */
+no_data_parity_stop_changes:
 	if ((cflag & CBAUD) == B0) {
 		/* Disable flow control */
 		if (usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
@@ -2157,6 +2164,7 @@ static void ftdi_set_termios(struct tty_
 
 	/* Set flow control */
 	/* Note device also supports DTR/CD (ugh) and Xon/Xoff in hardware */
+no_c_cflag_changes:
 	if (cflag & CRTSCTS) {
 		dbg("%s Setting to CRTSCTS flow control", __func__);
 		if (usb_control_msg(dev,
author
#42 lore raw

PATCH 42/53 usb-storage: Accept 8020i-protocol commands longer than 12 bytes

In reply to Greg KH

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

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

From: Alan Stern <[email protected]>

commit 2f640bf4c94324aeaa1b6385c10aab8c5ad1e1cf upstream.

The 8020i protocol (also 8070i and QIC-157) uses 12-byte commands; shorter commands must be padded. Simon Detheridge reports that his 3-TB USB disk drive claims to use the 8020i protocol (which is normally meant for ATAPI devices like CD drives), and because of its large size, the disk drive requires the use of 16-byte commands. However the usb_stor_pad12_command() routine in usb-storage always sets the command length to 12, making the drive impossible to use.

Since the SFF-8020i specification allows for 16-byte commands in future extensions, we may as well accept them. This patch (as1490) changes usb_stor_pad12_command() to leave commands larger than 12 bytes alone rather than truncating them.

---
 drivers/usb/storage/protocol.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
drivers/usb/storage/protocol.c +3 -4
@@ -58,7 +58,9 @@
 
 void usb_stor_pad12_command(struct scsi_cmnd *srb, struct us_data *us)
 {
-	/* Pad the SCSI command with zeros out to 12 bytes
+	/*
+	 * Pad the SCSI command with zeros out to 12 bytes.  If the
+	 * command already is 12 bytes or longer, leave it alone.
 	 *
 	 * NOTE: This only works because a scsi_cmnd struct field contains
 	 * a unsigned char cmnd[16], so we know we have storage available
@@ -66,9 +68,6 @@ void usb_stor_pad12_command(struct scsi_
 	for (; srb->cmd_len<12; srb->cmd_len++)
 		srb->cmnd[srb->cmd_len] = 0;
 
-	/* set command length to 12 bytes */
-	srb->cmd_len = 12;
-
 	/* send the command to the transport layer */
 	usb_stor_invoke_transport(srb, us);
 }
author
#43 lore raw

PATCH 43/53 USB: EHCI: fix HUB TT scheduling issue with iso transfer

In reply to Greg KH

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

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

From: Thomas Poussevin <[email protected]>

commit 811c926c538f7e8d3c08b630dd5844efd7e000f6 upstream.

The current TT scheduling doesn't allow to play and then record on a full-speed device connected to a high speed hub.

The IN iso stream can only start on the first uframe (0-2 for a 165 us) because of CSPLIT transactions.
For the OUT iso stream there no such restriction. uframe 0-5 are possible.

The idea of this patch is that the first uframe are precious (for IN TT iso stream) and we should allocate the last uframes first if possible.

For that we reverse the order of uframe allocation (last uframe first).

Here an example :

hid interrupt stream
----------------------------------------------------------------------
uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
----------------------------------------------------------------------
max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 |
----------------------------------------------------------------------
used usecs on a frame | 13 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
----------------------------------------------------------------------

iso OUT stream
----------------------------------------------------------------------
uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
----------------------------------------------------------------------
max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 |
----------------------------------------------------------------------
used usecs on a frame | 13 | 125 | 39 | 0 | 0 | 0 | 0 | 0 |
----------------------------------------------------------------------

There no place for iso IN stream (uframe 0-2 are used) and we got "cannot submit datapipe for urb 0, error -28: not enough bandwidth" error.

With the patch this become.

iso OUT stream
----------------------------------------------------------------------
uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
----------------------------------------------------------------------
max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 |
----------------------------------------------------------------------
used usecs on a frame | 13 | 0 | 0 | 0 | 125 | 39 | 0 | 0 |
----------------------------------------------------------------------

iso IN stream
----------------------------------------------------------------------
uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
----------------------------------------------------------------------
max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 |
----------------------------------------------------------------------
used usecs on a frame | 13 | 0 | 125 | 40 | 125 | 39 | 0 | 0 |
----------------------------------------------------------------------

---
 drivers/usb/host/ehci-sched.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)
drivers/usb/host/ehci-sched.c +10 -5
@@ -1480,10 +1480,15 @@ iso_stream_schedule (
 
 		/* NOTE:  assumes URB_ISO_ASAP, to limit complexity/bugs */
 
-		/* find a uframe slot with enough bandwidth */
-		next = start + period;
-		for (; start < next; start++) {
-
+		/* find a uframe slot with enough bandwidth.
+		 * Early uframes are more precious because full-speed
+		 * iso IN transfers can't use late uframes,
+		 * and therefore they should be allocated last.
+		 */
+		next = start;
+		start += period;
+		do {
+			start--;
 			/* check schedule: enough space? */
 			if (stream->highspeed) {
 				if (itd_slot_ok(ehci, mod, start,
@@ -1496,7 +1501,7 @@ iso_stream_schedule (
 						start, sched, period))
 					break;
 			}
-		}
+		} while (start > next);
 
 		/* no room in the schedule */
 		if (start == next) {
author
#44 lore raw

PATCH 44/53 USB: add quirk for Logitech C600 web cam

In reply to Greg KH

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

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

From: Josh Boyer <[email protected]>

commit 60c71ca972a2dd3fd9d0165b405361c8ad48349b upstream.

We've had another report of the "chipmunk" sound on a Logitech C600 webcam. This patch resolves the issue.

---
 drivers/usb/core/quirks.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/usb/core/quirks.c +3 -0
@@ -50,6 +50,9 @@ static const struct usb_device_id usb_qu
 	/* Logitech Webcam B/C500 */
 	{ USB_DEVICE(0x046d, 0x0807), .driver_info = USB_QUIRK_RESET_RESUME },
 
+	/* Logitech Webcam C600 */
+	{ USB_DEVICE(0x046d, 0x0808), .driver_info = USB_QUIRK_RESET_RESUME },
+
 	/* Logitech Webcam Pro 9000 */
 	{ USB_DEVICE(0x046d, 0x0809), .driver_info = USB_QUIRK_RESET_RESUME },
 
author
#45 lore raw

PATCH 45/53 USB: quirks: adding more quirky webcams to avoid squeaky audio

In reply to Greg KH

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

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

From: sordna <[email protected]>

commit 0d145d7d4a241c321c832a810bb6edad18e2217b upstream.

The following patch contains additional affected webcam models, on top of the patches commited to linux-next 2394d67e446bf616a0885167d5f0d397bdacfdfc and 5b253d88cc6c65a23cefc457a5a4ef139913c5fc

---
 drivers/usb/core/quirks.c |   24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
drivers/usb/core/quirks.c +24 -0
@@ -56,12 +56,36 @@ static const struct usb_device_id usb_qu
 	/* Logitech Webcam Pro 9000 */
 	{ USB_DEVICE(0x046d, 0x0809), .driver_info = USB_QUIRK_RESET_RESUME },
 
+	/* Logitech Webcam C905 */
+	{ USB_DEVICE(0x046d, 0x080a), .driver_info = USB_QUIRK_RESET_RESUME },
+
+	/* Logitech Webcam C210 */
+	{ USB_DEVICE(0x046d, 0x0819), .driver_info = USB_QUIRK_RESET_RESUME },
+
+	/* Logitech Webcam C260 */
+	{ USB_DEVICE(0x046d, 0x081a), .driver_info = USB_QUIRK_RESET_RESUME },
+
 	/* Logitech Webcam C310 */
 	{ USB_DEVICE(0x046d, 0x081b), .driver_info = USB_QUIRK_RESET_RESUME },
 
+	/* Logitech Webcam C910 */
+	{ USB_DEVICE(0x046d, 0x0821), .driver_info = USB_QUIRK_RESET_RESUME },
+
+	/* Logitech Webcam C160 */
+	{ USB_DEVICE(0x046d, 0x0824), .driver_info = USB_QUIRK_RESET_RESUME },
+
 	/* Logitech Webcam C270 */
 	{ USB_DEVICE(0x046d, 0x0825), .driver_info = USB_QUIRK_RESET_RESUME },
 
+	/* Logitech Quickcam Pro 9000 */
+	{ USB_DEVICE(0x046d, 0x0990), .driver_info = USB_QUIRK_RESET_RESUME },
+
+	/* Logitech Quickcam E3500 */
+	{ USB_DEVICE(0x046d, 0x09a4), .driver_info = USB_QUIRK_RESET_RESUME },
+
+	/* Logitech Quickcam Vision Pro */
+	{ USB_DEVICE(0x046d, 0x09a6), .driver_info = USB_QUIRK_RESET_RESUME },
+
 	/* Logitech Harmony 700-series */
 	{ USB_DEVICE(0x046d, 0xc122), .driver_info = USB_QUIRK_DELAY_INIT },
 
author
#46 lore raw

PATCH 46/53 drm/i915: fix IVB cursor support

In reply to Greg KH

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

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

From: Jesse Barnes <[email protected]>

commit 65a21cd65316145f9302594be8e69074369e1050 upstream.

The cursor regs have moved around, add the offsets and new macros for getting at them.

---
 drivers/gpu/drm/i915/i915_reg.h      |    8 +++++++
 drivers/gpu/drm/i915/intel_display.c |   40 ++++++++++++++++++++++++++++++-----
 2 files changed, 43 insertions(+), 5 deletions(-)
drivers/gpu/drm/i915/i915_reg.h +8 -0
@@ -2554,10 +2554,18 @@
 #define _CURBBASE		0x700c4
 #define _CURBPOS			0x700c8
 
+#define _CURBCNTR_IVB		0x71080
+#define _CURBBASE_IVB		0x71084
+#define _CURBPOS_IVB		0x71088
+
 #define CURCNTR(pipe) _PIPE(pipe, _CURACNTR, _CURBCNTR)
 #define CURBASE(pipe) _PIPE(pipe, _CURABASE, _CURBBASE)
 #define CURPOS(pipe) _PIPE(pipe, _CURAPOS, _CURBPOS)
 
+#define CURCNTR_IVB(pipe) _PIPE(pipe, _CURACNTR, _CURBCNTR_IVB)
+#define CURBASE_IVB(pipe) _PIPE(pipe, _CURABASE, _CURBBASE_IVB)
+#define CURPOS_IVB(pipe) _PIPE(pipe, _CURAPOS, _CURBPOS_IVB)
+
 /* Display A control */
 #define _DSPACNTR                0x70180
 #define   DISPLAY_PLANE_ENABLE			(1<<31)
drivers/gpu/drm/i915/intel_display.c +35 -5
@@ -5758,6 +5758,31 @@ static void i9xx_update_cursor(struct dr
 	I915_WRITE(CURBASE(pipe), base);
 }
 
+static void ivb_update_cursor(struct drm_crtc *crtc, u32 base)
+{
+	struct drm_device *dev = crtc->dev;
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+	int pipe = intel_crtc->pipe;
+	bool visible = base != 0;
+
+	if (intel_crtc->cursor_visible != visible) {
+		uint32_t cntl = I915_READ(CURCNTR_IVB(pipe));
+		if (base) {
+			cntl &= ~CURSOR_MODE;
+			cntl |= CURSOR_MODE_64_ARGB_AX | MCURSOR_GAMMA_ENABLE;
+		} else {
+			cntl &= ~(CURSOR_MODE | MCURSOR_GAMMA_ENABLE);
+			cntl |= CURSOR_MODE_DISABLE;
+		}
+		I915_WRITE(CURCNTR_IVB(pipe), cntl);
+
+		intel_crtc->cursor_visible = visible;
+	}
+	/* and commit changes on next vblank */
+	I915_WRITE(CURBASE_IVB(pipe), base);
+}
+
 /* If no-part of the cursor is visible on the framebuffer, then the GPU may hang... */
 static void intel_crtc_update_cursor(struct drm_crtc *crtc,
 				     bool on)
@@ -5805,11 +5830,16 @@ static void intel_crtc_update_cursor(str
 	if (!visible && !intel_crtc->cursor_visible)
 		return;
 
-	I915_WRITE(CURPOS(pipe), pos);
-	if (IS_845G(dev) || IS_I865G(dev))
-		i845_update_cursor(crtc, base);
-	else
-		i9xx_update_cursor(crtc, base);
+	if (IS_IVYBRIDGE(dev)) {
+		I915_WRITE(CURPOS_IVB(pipe), pos);
+		ivb_update_cursor(crtc, base);
+	} else {
+		I915_WRITE(CURPOS(pipe), pos);
+		if (IS_845G(dev) || IS_I865G(dev))
+			i845_update_cursor(crtc, base);
+		else
+			i9xx_update_cursor(crtc, base);
+	}
 
 	if (visible)
 		intel_mark_busy(dev, to_intel_framebuffer(crtc->fb)->obj);
author
#47 lore raw

PATCH 47/53 drm/i915: always set FDI composite sync bit

In reply to Greg KH

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

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

From: Jesse Barnes <[email protected]>

commit c4f9c4c2b3f1831e932e04db992cf6fe92c2a95a upstream.

It's needed for 3 pipe support as well as just regular functionality (e.g. DisplayPort).

---
 drivers/gpu/drm/i915/i915_reg.h      |    1 +
 drivers/gpu/drm/i915/intel_display.c |    2 ++
 2 files changed, 3 insertions(+)
drivers/gpu/drm/i915/i915_reg.h +1 -0
@@ -3175,6 +3175,7 @@
 #define  FDI_LINK_TRAIN_NONE_IVB            (3<<8)
 
 /* both Tx and Rx */
+#define  FDI_COMPOSITE_SYNC		(1<<11)
 #define  FDI_LINK_TRAIN_AUTO		(1<<10)
 #define  FDI_SCRAMBLING_ENABLE          (0<<7)
 #define  FDI_SCRAMBLING_DISABLE         (1<<7)
drivers/gpu/drm/i915/intel_display.c +2 -0
@@ -2600,6 +2600,7 @@ static void ivb_manual_fdi_link_train(st
 	temp |= FDI_LINK_TRAIN_PATTERN_1_IVB;
 	temp &= ~FDI_LINK_TRAIN_VOL_EMP_MASK;
 	temp |= FDI_LINK_TRAIN_400MV_0DB_SNB_B;
+	temp |= FDI_COMPOSITE_SYNC;
 	I915_WRITE(reg, temp | FDI_TX_ENABLE);
 
 	reg = FDI_RX_CTL(pipe);
@@ -2607,6 +2608,7 @@ static void ivb_manual_fdi_link_train(st
 	temp &= ~FDI_LINK_TRAIN_AUTO;
 	temp &= ~FDI_LINK_TRAIN_PATTERN_MASK_CPT;
 	temp |= FDI_LINK_TRAIN_PATTERN_1_CPT;
+	temp |= FDI_COMPOSITE_SYNC;
 	I915_WRITE(reg, temp | FDI_RX_ENABLE);
 
 	POSTING_READ(reg);
author
#48 lore raw

PATCH 48/53 batman-adv: fix tt_local_reset_flags() function

In reply to Greg KH

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

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

From: Antonio Quartulli <[email protected]>

commit 31901264511cf20c5ed33b8649a3ca9ce28df60b upstream.

Currently the counter of tt_local_entry structures (tt_local_num) is incremented each time the tt_local_reset_flags() is invoked causing the node to send wrong TT_REPONSE packets containing a copy of non-initialised memory thus corrupting other nodes global translation table and making higher level communication impossible.

---
 net/batman-adv/translation-table.c |    2 ++
 1 file changed, 2 insertions(+)
net/batman-adv/translation-table.c +2 -0
@@ -1668,6 +1668,8 @@ static void tt_local_reset_flags(struct
 		rcu_read_lock();
 		hlist_for_each_entry_rcu(tt_local_entry, node,
 					 head, hash_entry) {
+			if (!(tt_local_entry->flags & flags))
+				continue;
 			tt_local_entry->flags &= ~flags;
 			atomic_inc(&bat_priv->num_local_tt);
 		}
author
#49 lore raw

PATCH 49/53 batman-adv: correctly set the data field in the TT_REPONSE packet

In reply to Greg KH

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

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

From: Antonio Quartulli <[email protected]>

commit 9d8523931f7f5eb8900077f0da0fbe6b8ad0010b upstream.

In the TT_RESPONSE packet, the number of carried entries is not correctly set. This leads to a wrong interpretation of the packet payload on the receiver side causing random entries to be added to the global translation table. Therefore the latter gets always corrupted, triggering a table recovery all the time.

---
 net/batman-adv/translation-table.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
net/batman-adv/translation-table.c +4 -1
@@ -999,7 +999,6 @@ static struct sk_buff *tt_response_fill_
 	tt_response = (struct tt_query_packet *)skb_put(skb,
 						     tt_query_size + tt_len);
 	tt_response->ttvn = ttvn;
-	tt_response->tt_data = htons(tt_tot);
 
 	tt_change = (struct tt_change *)(skb->data + tt_query_size);
 	tt_count = 0;
@@ -1025,6 +1024,10 @@ static struct sk_buff *tt_response_fill_
 	}
 	rcu_read_unlock();
 
+	/* store in the message the number of entries we have successfully
+	 * copied */
+	tt_response->tt_data = htons(tt_count);
+
 out:
 	return skb;
 }
author
#50 lore raw

PATCH 50/53 batman-adv: remove references for global tt entries

In reply to Greg KH

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

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

From: Simon Wunderlich <[email protected]>

commit 531027fcddbcf81c9937dd04f08a7e8f11fd47d2 upstream.

struct tt_global_entry holds a reference to an orig_node which must be decremented before deallocating the structure.

---
 net/batman-adv/translation-table.c |   14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)
net/batman-adv/translation-table.c +13 -1
@@ -137,10 +137,22 @@ static void tt_local_entry_free_ref(stru
 		kfree_rcu(tt_local_entry, rcu);
 }
 
+static void tt_global_entry_free_rcu(struct rcu_head *rcu)
+{
+	struct tt_global_entry *tt_global_entry;
+
+	tt_global_entry = container_of(rcu, struct tt_global_entry, rcu);
+
+	if (tt_global_entry->orig_node)
+		orig_node_free_ref(tt_global_entry->orig_node);
+
+	kfree(tt_global_entry);
+}
+
 static void tt_global_entry_free_ref(struct tt_global_entry *tt_global_entry)
 {
 	if (atomic_dec_and_test(&tt_global_entry->refcount))
-		kfree_rcu(tt_global_entry, rcu);
+		call_rcu(&tt_global_entry->rcu, tt_global_entry_free_rcu);
 }
 
 static void tt_local_event(struct bat_priv *bat_priv, const uint8_t *addr,
author
#51 lore raw

PATCH 51/53 batman-adv: add sanity check when removing global tts

In reply to Greg KH

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

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

From: Simon Wunderlich <[email protected]>

commit 6e8014947d6469df1566e9e253805557c5c0e4e0 upstream.

After removing the batman-adv module, the hash may be already gone when tt_global_del_orig() tries to clean the hash. This patch adds a sanity check to avoid this.

---
 net/batman-adv/translation-table.c |    3 +++
 1 file changed, 3 insertions(+)
net/batman-adv/translation-table.c +3 -0
@@ -698,6 +698,9 @@ void tt_global_del_orig(struct bat_priv
 	struct hlist_head *head;
 	spinlock_t *list_lock; /* protects write access to the hash lists */
 
+	if (!hash)
+		return;
+
 	for (i = 0; i < hash->size; i++) {
 		head = &hash->table[i];
 		list_lock = &hash->list_locks[i];
author
#52 lore raw

PATCH 52/53 batman-adv: unify hash_entry field position in tt_local/global_entry

In reply to Greg KH

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

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

From: Antonio Quartulli <[email protected]>

commit 93840ac40bb0d0f177ef8af74e64671be67e8c37 upstream.

Function tt_response_fill_table() actually uses a tt_local_entry pointer to iterate either over the local or the global table entries (it depends on the what hash table is passed as argument). To iterate over such entries the hlist_for_each_entry_rcu() macro has to access their "hash_entry" field which MUST be at the same position in both the tt_global/local_entry structures.

---
 net/batman-adv/types.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
net/batman-adv/types.h +2 -2
@@ -223,22 +223,22 @@ struct socket_packet {
 
 struct tt_local_entry {
 	uint8_t addr[ETH_ALEN];
+	struct hlist_node hash_entry;
 	unsigned long last_seen;
 	uint16_t flags;
 	atomic_t refcount;
 	struct rcu_head rcu;
-	struct hlist_node hash_entry;
 };
 
 struct tt_global_entry {
 	uint8_t addr[ETH_ALEN];
+	struct hlist_node hash_entry; /* entry in the global table */
 	struct orig_node *orig_node;
 	uint8_t ttvn;
 	uint16_t flags; /* only TT_GLOBAL_ROAM is used */
 	unsigned long roam_at; /* time at which TT_GLOBAL_ROAM was set */
 	atomic_t refcount;
 	struct rcu_head rcu;
-	struct hlist_node hash_entry; /* entry in the global table */
 };
 
 struct tt_change_node {
author
#53 lore raw

PATCH 53/53 vmscan: fix shrinker callback bug in fs/super.c

In reply to Greg KH

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

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

From: Mikulas Patocka <[email protected]>

commit 09f363c7363eb10cfb4b82094bd7064e5608258b upstream.

The callback must not return -1 when nr_to_scan is zero. Fix the bug in fs/super.c and add this requirement to the callback specification.

---
 fs/super.c               |    2 +-
 include/linux/shrinker.h |    1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
fs/super.c +1 -1
@@ -61,7 +61,7 @@ static int prune_super(struct shrinker *
 		return -1;
 
 	if (!grab_super_passive(sb))
-		return -1;
+		return !sc->nr_to_scan ? 0 : -1;
 
 	if (sb->s_op && sb->s_op->nr_cached_objects)
 		fs_objects = sb->s_op->nr_cached_objects(sb);
include/linux/shrinker.h +1 -0
@@ -20,6 +20,7 @@ struct shrink_control {
  * 'nr_to_scan' entries and attempt to free them up.  It should return
  * the number of objects which remain in the cache.  If it returns -1, it means
  * it cannot do any scanning at this time (eg. there is a risk of deadlock).
+ * The callback must not return -1 if nr_to_scan is zero.
  *
  * The 'gfpmask' refers to the allocation we are currently trying to
  * fulfil.