Skip to contentSkip to conversation

3.3.4-stable review

PATCH In review Greg KH 9 participants 89 messages Apr 24, 2012 – Apr 30, 2012

Subsystems (46)
lore
Share & tools
lore

Greg KH

author maintainer
#0 lore raw

cover 3.3.4-stable review

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

Responses should be made by Thu Apr 26 22:32:39 UTC 2012. 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.3.4-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

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

 Makefile                                       |    4 +-
 arch/arm/mach-at91/board-sam9261ek.c           |    5 +-
 arch/arm/mach-omap1/timer.c                    |    4 +-
 arch/arm/mach-omap2/serial.c                   |    8 ++-
 crypto/sha512_generic.c                        |    2 +-
 drivers/bluetooth/ath3k.c                      |    2 +
 drivers/bluetooth/btusb.c                      |    1 +
 drivers/hwmon/fam15h_power.c                   |   39 ++++++++++++++
 drivers/md/md.c                                |    7 +--
 drivers/media/dvb/dvb-core/dvb_frontend.c      |   25 ++++++++-
 drivers/media/dvb/frontends/drxk_hard.c        |    6 ++-
 drivers/media/rc/winbond-cir.c                 |    1 +
 drivers/mmc/card/block.c                       |   54 +++++++++++++------
 drivers/mmc/card/queue.c                       |    2 +-
 drivers/mmc/core/core.c                        |    9 ++--
 drivers/mmc/host/sdhci-esdhc-imx.c             |    3 +-
 drivers/mmc/host/sdhci.c                       |    2 +-
 drivers/net/ethernet/ti/davinci_mdio.c         |    5 ++
 drivers/net/wireless/brcm80211/brcmsmac/main.c |    8 +++
 drivers/net/wireless/mwifiex/pcie.h            |   18 +++----
 drivers/pci/quirks.c                           |   34 ++++++++++++
 drivers/platform/x86/dell-laptop.c             |   28 ++++++++++
 drivers/staging/rtl8712/os_intfs.c             |    3 --
 drivers/staging/rtl8712/usb_intf.c             |    5 ++
 drivers/tty/amiserial.c                        |    4 +-
 drivers/tty/serial/clps711x.c                  |   14 ++---
 drivers/tty/serial/pch_uart.c                  |    4 +-
 drivers/usb/core/hub.c                         |    3 --
 drivers/usb/core/message.c                     |    6 +--
 drivers/usb/gadget/f_fs.c                      |    2 +-
 drivers/usb/gadget/udc-core.c                  |    6 ++-
 drivers/usb/host/ehci-hcd.c                    |    9 +++-
 drivers/usb/misc/yurex.c                       |   10 ++--
 drivers/usb/musb/omap2430.c                    |    9 ++--
 drivers/usb/serial/cp210x.c                    |    9 ++--
 drivers/usb/serial/sierra.c                    |    6 ++-
 drivers/uwb/hwa-rc.c                           |    3 +-
 drivers/uwb/neh.c                              |   12 ++++-
 drivers/xen/gntdev.c                           |    2 +-
 drivers/xen/xenbus/xenbus_probe_frontend.c     |   69 ++++++++++++++++++------
 fs/btrfs/ctree.h                               |    2 +-
 fs/ext4/extents.c                              |    2 +-
 fs/jbd2/commit.c                               |    4 +-
 fs/lockd/clnt4xdr.c                            |    2 +-
 fs/lockd/clntxdr.c                             |    2 +-
 fs/nfsd/nfs3xdr.c                              |   22 +++-----
 fs/nfsd/nfs4proc.c                             |    7 +--
 fs/nfsd/nfs4state.c                            |   23 ++++----
 fs/nfsd/nfs4xdr.c                              |    2 +-
 fs/ocfs2/alloc.c                               |    2 +-
 fs/ocfs2/refcounttree.c                        |   12 ++---
 fs/ocfs2/suballoc.c                            |    4 +-
 include/linux/kvm_host.h                       |    6 +++
 mm/memblock.c                                  |    7 ++-
 mm/swap_state.c                                |    2 +-
 net/mac80211/ibss.c                            |    4 +-
 net/wireless/util.c                            |    2 +-
 scripts/mod/file2alias.c                       |    4 ++
 sound/pci/hda/patch_conexant.c                 |   37 +++++++++++--
 tools/perf/util/hist.c                         |    4 +-
 virt/kvm/iommu.c                               |    7 ++-
 virt/kvm/kvm_main.c                            |    5 +-
 62 files changed, 441 insertions(+), 164 deletions(-)
author maintainer
#1 lore raw

PATCH 1/62 Perf: fix build breakage

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

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

From: Zeev Tarantov <[email protected]>

[Patch not needed upstream as this is a backport build bugfix - gregkh

gcc correctly complains:

util/hist.c: In function ‘__hists__add_entry’:
util/hist.c:240:27: error: invalid type argument of ‘->’ (have ‘struct hist_entry’) util/hist.c:241:23: error: invalid type argument of ‘->’ (have ‘struct hist_entry’)

for this new code:

+ if (he->ms.map != entry->ms.map) {
+ he->ms.map = entry->ms.map;
+ if (he->ms.map)
+ he->ms.map->referenced = true;
+ }

because "entry" is a "struct hist_entry", not a pointer to a struct.

In mainline, "entry" is a pointer to struct passed as argument to the function. So this is broken during backporting. But obviously not compile tested.

Cc Signed-off-by: David S. Miller <[email protected]>
Cc Arnaldo Carvalho de Melo <[email protected]>
---
 tools/perf/util/hist.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
tools/perf/util/hist.c +2 -2
@@ -237,8 +237,8 @@ struct hist_entry *__hists__add_entry(st
 			 * mis-adjust symbol addresses when computing
 			 * the history counter to increment.
 			 */
-			if (he->ms.map != entry->ms.map) {
-				he->ms.map = entry->ms.map;
+			if (he->ms.map != entry.ms.map) {
+				he->ms.map = entry.ms.map;
 				if (he->ms.map)
 					he->ms.map->referenced = true;
 			}
author maintainer
#2 lore raw

PATCH 2/62 crypto: sha512 - Fix byte counter overflow in SHA-512

In reply to Greg KH

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

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

From: Kent Yoder <[email protected]>

commit 25c3d30c918207556ae1d6e663150ebdf902186b upstream.

The current code only increments the upper 64 bits of the SHA-512 byte counter when the number of bytes hashed happens to hit 2^64 exactly.

This patch increments the upper 64 bits whenever the lower 64 bits overflows.

---
 crypto/sha512_generic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
crypto/sha512_generic.c +1 -1
@@ -174,7 +174,7 @@ sha512_update(struct shash_desc *desc, c
 	index = sctx->count[0] & 0x7f;
 
 	/* Update number of bytes */
-	if (!(sctx->count[0] += len))
+	if ((sctx->count[0] += len) < len)
 		sctx->count[1]++;
 
         part_len = 128 - index;
author maintainer
#3 lore raw

PATCH 3/62 hwmon: fam15h_power: fix bogus values with current BIOSes

In reply to Greg KH

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

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

From: Andre Przywara <[email protected]>

commit 00250ec90963b7ef6678438888f3244985ecde14 upstream.

Newer BKDG[1] versions recommend a different initialization value for the running average range register in the northbridge. This improves the power reading by avoiding counter saturations resulting in bogus values for anything below about 80% of TDP power consumption. Updated BIOSes will have this new value set up from the beginning, but meanwhile we correct this value ourselves.
This needs to be done on all northbridges, even on those where the driver itself does not register at.

This fixes the driver on all current machines to provide proper values for idle load.

[1]
http://support.amd.com/us/Processor_TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf
Chapter 3.8: D18F5xE0 Processor TDP Running Average (p. 452)

---
 drivers/hwmon/fam15h_power.c |   39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
drivers/hwmon/fam15h_power.c +39 -0
@@ -122,6 +122,38 @@ static bool __devinit fam15h_power_is_in
 	return true;
 }
 
+/*
+ * Newer BKDG versions have an updated recommendation on how to properly
+ * initialize the running average range (was: 0xE, now: 0x9). This avoids
+ * counter saturations resulting in bogus power readings.
+ * We correct this value ourselves to cope with older BIOSes.
+ */
+static void __devinit tweak_runavg_range(struct pci_dev *pdev)
+{
+	u32 val;
+	const struct pci_device_id affected_device = {
+		PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) };
+
+	/*
+	 * let this quirk apply only to the current version of the
+	 * northbridge, since future versions may change the behavior
+	 */
+	if (!pci_match_id(&affected_device, pdev))
+		return;
+
+	pci_bus_read_config_dword(pdev->bus,
+		PCI_DEVFN(PCI_SLOT(pdev->devfn), 5),
+		REG_TDP_RUNNING_AVERAGE, &val);
+	if ((val & 0xf) != 0xe)
+		return;
+
+	val &= ~0xf;
+	val |=  0x9;
+	pci_bus_write_config_dword(pdev->bus,
+		PCI_DEVFN(PCI_SLOT(pdev->devfn), 5),
+		REG_TDP_RUNNING_AVERAGE, val);
+}
+
 static void __devinit fam15h_power_init_data(struct pci_dev *f4,
 					     struct fam15h_power_data *data)
 {
@@ -155,6 +187,13 @@ static int __devinit fam15h_power_probe(
 	struct device *dev;
 	int err;
 
+	/*
+	 * though we ignore every other northbridge, we still have to
+	 * do the tweaking on _each_ node in MCM processors as the counters
+	 * are working hand-in-hand
+	 */
+	tweak_runavg_range(pdev);
+
 	if (!fam15h_power_is_internal_node0(pdev)) {
 		err = -ENODEV;
 		goto exit;
#4 lore raw

Re: [ 03/62] hwmon: fam15h_power: fix bogus values with current BIOSes

Quoted 1 line · Greg KH

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

[...]

drivers/hwmon/fam15h_power.c static bool __devinit fam15h_power_is_in · line 142

Quoted 12 lines
drivers/hwmon/fam15h_power.c +12 -0
+static void __devinit tweak_runavg_range(struct pci_dev *pdev)
+{
+	u32 val;
+	const struct pci_device_id affected_device = {
+		PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) };
+
+	/*
+	 * let this quirk apply only to the current version of the
+	 * northbridge, since future versions may change the behavior
+	 */
+	if (!pci_match_id(&affected_device, pdev))
+		return;

[...]

pci_match_id() takes an *array* of IDs which must be properly zero- terminated. This change is bogus and should be fixed up before it goes into a stable update.

Ben.

Signature · 3 lines
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus
#5 lore raw

Re: [ 03/62] hwmon: fam15h_power: fix bogus values with current BIOSes

Quoted 17 lines · Ben Hutchings
Quoted 1 line · Greg KH

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

[...]

Quoted 12 lines
drivers/hwmon/fam15h_power.c +12 -0
+static void __devinit tweak_runavg_range(struct pci_dev *pdev)
+{
+	u32 val;
+	const struct pci_device_id affected_device = {
+		PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) };
+
+	/*
+	 * let this quirk apply only to the current version of the
+	 * northbridge, since future versions may change the behavior
+	 */
+	if (!pci_match_id(&affected_device, pdev))
+		return;

[...]

Quoted 3 lines

pci_match_id() takes an *array* of IDs which must be properly zero- terminated. This change is bogus and should be fixed up before it goes into a stable update.

Good catch. I sent a patch to fix this in mainline a minute ago.

Guenter

author maintainer
#6 lore raw

Re: [ 03/62] hwmon: fam15h_power: fix bogus values with current BIOSes

Quoted 18 lines · Guenter Roeck
Quoted 17 lines · Ben Hutchings
Quoted 1 line · Greg KH

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

[...]

Quoted 12 lines
drivers/hwmon/fam15h_power.c +12 -0
+static void __devinit tweak_runavg_range(struct pci_dev *pdev)
+{
+	u32 val;
+	const struct pci_device_id affected_device = {
+		PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) };
+
+	/*
+	 * let this quirk apply only to the current version of the
+	 * northbridge, since future versions may change the behavior
+	 */
+	if (!pci_match_id(&affected_device, pdev))
+		return;

[...]

Quoted 5 lines
Quoted 3 lines

pci_match_id() takes an *array* of IDs which must be properly zero- terminated. This change is bogus and should be fixed up before it goes into a stable update.

Good catch. I sent a patch to fix this in mainline a minute ago.

Is it in Linus's tree yet? If so, what's the git commit id? If not, I'll have to drop it from this release.

thanks,

greg k-h

#7 lore raw

Re: [ 03/62] hwmon: fam15h_power: fix bogus values with current BIOSes

Quoted 19 lines · Greg KH
Quoted 18 lines · Guenter Roeck
Quoted 17 lines · Ben Hutchings
Quoted 1 line · Greg KH

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

[...]

Quoted 12 lines
drivers/hwmon/fam15h_power.c +12 -0
+static void __devinit tweak_runavg_range(struct pci_dev *pdev)
+{
+	u32 val;
+	const struct pci_device_id affected_device = {
+		PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) };
+
+	/*
+	 * let this quirk apply only to the current version of the
+	 * northbridge, since future versions may change the behavior
+	 */
+	if (!pci_match_id(&affected_device, pdev))
+		return;

[...]

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

pci_match_id() takes an *array* of IDs which must be properly zero- terminated. This change is bogus and should be fixed up before it goes into a stable update.

Good catch. I sent a patch to fix this in mainline a minute ago.

Is it in Linus's tree yet? If so, what's the git commit id? If not, I'll have to drop it from this release.

It is not in Linus' tree yet. I plan to send the pull request tomorrow, after having it rest for another night in my tree (with nightly builds) and in linux-next.

Please drop the patch for now. The fix will include a reference to it, so you can pull both patches once the fix shows up in Linus' tree.

Sorry for the trouble.

Thanks,
Guenter

author maintainer
#8 lore raw

Re: [ 03/62] hwmon: fam15h_power: fix bogus values with current BIOSes

Quoted 29 lines · Guenter Roeck
Quoted 19 lines · Greg KH
Quoted 18 lines · Guenter Roeck
Quoted 17 lines · Ben Hutchings
Quoted 1 line · Greg KH

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

[...]

Quoted 12 lines
drivers/hwmon/fam15h_power.c +12 -0
+static void __devinit tweak_runavg_range(struct pci_dev *pdev)
+{
+	u32 val;
+	const struct pci_device_id affected_device = {
+		PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) };
+
+	/*
+	 * let this quirk apply only to the current version of the
+	 * northbridge, since future versions may change the behavior
+	 */
+	if (!pci_match_id(&affected_device, pdev))
+		return;

[...]

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

pci_match_id() takes an *array* of IDs which must be properly zero- terminated. This change is bogus and should be fixed up before it goes into a stable update.

Good catch. I sent a patch to fix this in mainline a minute ago.

Is it in Linus's tree yet? If so, what's the git commit id? If not, I'll have to drop it from this release.

Quoted 6 lines

It is not in Linus' tree yet. I plan to send the pull request tomorrow, after having it rest for another night in my tree (with nightly builds) and in linux-next.

Please drop the patch for now. The fix will include a reference to it, so you can pull both patches once the fix shows up in Linus' tree.

Now dropped.

author maintainer
#9 lore raw

PATCH 4/62 ALSA: hda/conexant - Dont set HP pin-control bit unconditionally

In reply to Greg KH

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

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

From: Takashi Iwai <[email protected]>

commit ca3649de026ff95c6f2847e8d096cf2f411c02b3 upstream.

Some output pins on Conexant chips have no HP control bit, but the auto-parser initializes these pins unconditionally with PIN_HP.

Check the pin-capability and avoid the HP bit if not supported.

---
 sound/pci/hda/patch_conexant.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)
sound/pci/hda/patch_conexant.c +7 -2
@@ -3951,9 +3951,14 @@ static void cx_auto_init_output(struct h
 	int i;
 
 	mute_outputs(codec, spec->multiout.num_dacs, spec->multiout.dac_nids);
-	for (i = 0; i < cfg->hp_outs; i++)
+	for (i = 0; i < cfg->hp_outs; i++) {
+		unsigned int val = PIN_OUT;
+		if (snd_hda_query_pin_caps(codec, cfg->hp_pins[i]) &
+		    AC_PINCAP_HP_DRV)
+			val |= AC_PINCTL_HP_EN;
 		snd_hda_codec_write(codec, cfg->hp_pins[i], 0,
-				    AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP);
+				    AC_VERB_SET_PIN_WIDGET_CONTROL, val);
+	}
 	mute_outputs(codec, cfg->hp_outs, cfg->hp_pins);
 	mute_outputs(codec, cfg->line_outs, cfg->line_out_pins);
 	mute_outputs(codec, cfg->speaker_outs, cfg->speaker_pins);
author maintainer
#10 lore raw

PATCH 5/62 ALSA: hda/conexant - Set up the missing docking-station pins

In reply to Greg KH

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

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

From: Takashi Iwai <[email protected]>

commit d70f363222ef373c2037412f09a600357cfa1c7a upstream.

ThinkPad 410,420,510,520 and X201 with cx50585 & co chips have the docking-station ports, but BIOS doesn't initialize for these pins. Thus, like the former X200, we need to set up the pins manually in the driver.

The odd part is that the same PCI SSID is used for X200 and T400, thus we need to prepare individual fixup tables for cx5051 and others.

Bugzilla entries:

	https://bugzilla.redhat.com/show_bug.cgi?id=808559
	https://bugzilla.redhat.com/show_bug.cgi?id=806217
	https://bugzilla.redhat.com/show_bug.cgi?id=810697
---
 sound/pci/hda/patch_conexant.c |   28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)
sound/pci/hda/patch_conexant.c +25 -3
@@ -4367,8 +4367,10 @@ static void apply_pin_fixup(struct hda_c
 
 enum {
 	CXT_PINCFG_LENOVO_X200,
+	CXT_PINCFG_LENOVO_TP410,
 };
 
+/* ThinkPad X200 & co with cxt5051 */
 static const struct cxt_pincfg cxt_pincfg_lenovo_x200[] = {
 	{ 0x16, 0x042140ff }, /* HP (seq# overridden) */
 	{ 0x17, 0x21a11000 }, /* dock-mic */
@@ -4376,15 +4378,33 @@ static const struct cxt_pincfg cxt_pincf
 	{}
 };
 
+/* ThinkPad 410/420/510/520, X201 & co with cxt5066 */
+static const struct cxt_pincfg cxt_pincfg_lenovo_tp410[] = {
+	{ 0x19, 0x042110ff }, /* HP (seq# overridden) */
+	{ 0x1a, 0x21a190f0 }, /* dock-mic */
+	{ 0x1c, 0x212140ff }, /* dock-HP */
+	{}
+};
+
 static const struct cxt_pincfg *cxt_pincfg_tbl[] = {
 	[CXT_PINCFG_LENOVO_X200] = cxt_pincfg_lenovo_x200,
+	[CXT_PINCFG_LENOVO_TP410] = cxt_pincfg_lenovo_tp410,
 };
 
-static const struct snd_pci_quirk cxt_fixups[] = {
+static const struct snd_pci_quirk cxt5051_fixups[] = {
 	SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo X200", CXT_PINCFG_LENOVO_X200),
 	{}
 };
 
+static const struct snd_pci_quirk cxt5066_fixups[] = {
+	SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400", CXT_PINCFG_LENOVO_TP410),
+	SND_PCI_QUIRK(0x17aa, 0x215e, "Lenovo T410", CXT_PINCFG_LENOVO_TP410),
+	SND_PCI_QUIRK(0x17aa, 0x215f, "Lenovo T510", CXT_PINCFG_LENOVO_TP410),
+	SND_PCI_QUIRK(0x17aa, 0x21ce, "Lenovo T420", CXT_PINCFG_LENOVO_TP410),
+	SND_PCI_QUIRK(0x17aa, 0x21cf, "Lenovo T520", CXT_PINCFG_LENOVO_TP410),
+	{}
+};
+
 /* add "fake" mute amp-caps to DACs on cx5051 so that mixer mute switches
  * can be created (bko#42825)
  */
@@ -4421,11 +4441,13 @@ static int patch_conexant_auto(struct hd
 		break;
 	case 0x14f15051:
 		add_cx5051_fake_mutes(codec);
+		apply_pin_fixup(codec, cxt5051_fixups, cxt_pincfg_tbl);
+		break;
+	default:
+		apply_pin_fixup(codec, cxt5066_fixups, cxt_pincfg_tbl);
 		break;
 	}
 
-	apply_pin_fixup(codec, cxt_fixups, cxt_pincfg_tbl);
-
 	err = cx_auto_search_adcs(codec);
 	if (err < 0)
 		return err;
author maintainer
#11 lore raw

PATCH 6/62 memblock: memblock should be able to handle zero length operations

In reply to Greg KH

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

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

From: Tejun Heo <[email protected]>

commit b3dc627cabb33fc95f93da78457770c1b2a364d2 upstream.

Commit 24aa07882b ("memblock, x86: Replace memblock_x86_reserve/ free_range() with generic ones") replaced x86 specific memblock operations with the generic ones; unfortunately, it lost zero length operation handling in the process making the kernel panic if somebody tries to reserve zero length area.

There isn't much to be gained by being cranky to zero length operations and panicking is almost the worst response. Drop the BUG_ON() in memblock_reserve() and update memblock_add_region/isolate_range() so that all zero length operations are handled as noops.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43098

---
 mm/memblock.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
mm/memblock.c +6 -1
@@ -330,6 +330,9 @@ static int __init_memblock memblock_add_
 	phys_addr_t end = base + memblock_cap_size(base, &size);
 	int i, nr_new;
 
+	if (!size)
+		return 0;
+
 	/* special case for empty array */
 	if (type->regions[0].size == 0) {
 		WARN_ON(type->cnt != 1 || type->total_size);
@@ -430,6 +433,9 @@ static int __init_memblock memblock_isol
 
 	*start_rgn = *end_rgn = 0;
 
+	if (!size)
+		return 0;
+
 	/* we'll create at most two more regions */
 	while (type->cnt + 2 > type->max)
 		if (memblock_double_array(type) < 0)
@@ -514,7 +520,6 @@ int __init_memblock memblock_reserve(phy
 		     (unsigned long long)base,
 		     (unsigned long long)base + size,
 		     (void *)_RET_IP_);
-	BUG_ON(0 == size);
 
 	return memblock_add_region(_rgn, base, size, MAX_NUMNODES);
 }
author maintainer
#12 lore raw

PATCH 7/62 ARM: clps711x: serial driver hungs are a result of call disable_irq within ISR

In reply to Greg KH

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

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

From: Alexander Shiyan <[email protected]>

commit 7a6fbc9a887193a1e9f8658703881c528040afbc upstream.

Since 2.6.30-rc1 clps711x serial driver hungs system. This is a result of call disable_irq from ISR. synchronize_irq waits for end of interrupt and goes to infinite loop. This patch fix this problem.

---
 drivers/tty/serial/clps711x.c |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/tty/serial/clps711x.c +8 -6
@@ -154,10 +154,9 @@ static irqreturn_t clps711xuart_int_tx(i
 		port->x_char = 0;
 		return IRQ_HANDLED;
 	}
-	if (uart_circ_empty(xmit) || uart_tx_stopped(port)) {
-		clps711xuart_stop_tx(port);
-		return IRQ_HANDLED;
-	}
+
+	if (uart_circ_empty(xmit) || uart_tx_stopped(port))
+		goto disable_tx_irq;
 
 	count = port->fifosize >> 1;
 	do {
@@ -171,8 +170,11 @@ static irqreturn_t clps711xuart_int_tx(i
 	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
 		uart_write_wakeup(port);
 
-	if (uart_circ_empty(xmit))
-		clps711xuart_stop_tx(port);
+	if (uart_circ_empty(xmit)) {
+	disable_tx_irq:
+		disable_irq_nosync(TX_IRQ(port));
+		tx_enabled(port) = 0;
+	}
 
 	return IRQ_HANDLED;
 }
author maintainer
#13 lore raw

PATCH 8/62 ARM: at91: fix at91sam9261ek Ethernet dm9000 irq

In reply to Greg KH

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

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

From: Jean-Christophe PLAGNIOL-VILLARD <[email protected]>

commit ee9dd7631af6fb5c02964ed5b496217cd4ced059 upstream.

You need to setup the dm9000 irq via gpio_to_irq() since d0fbda9add (ARM: at91/gpio: drop PIN_BASE).

---
 arch/arm/mach-at91/board-sam9261ek.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
arch/arm/mach-at91/board-sam9261ek.c +3 -2
@@ -85,8 +85,6 @@ static struct resource dm9000_resource[]
 		.flags	= IORESOURCE_MEM
 	},
 	[2] = {
-		.start	= AT91_PIN_PC11,
-		.end	= AT91_PIN_PC11,
 		.flags	= IORESOURCE_IRQ
 			| IORESOURCE_IRQ_LOWEDGE | IORESOURCE_IRQ_HIGHEDGE,
 	}
@@ -130,6 +128,8 @@ static struct sam9_smc_config __initdata
 
 static void __init ek_add_device_dm9000(void)
 {
+	struct resource *r = &dm9000_resource[2];
+
 	/* Configure chip-select 2 (DM9000) */
 	sam9_smc_configure(0, 2, &dm9000_smc_config);
 
@@ -139,6 +139,7 @@ static void __init ek_add_device_dm9000(
 	/* Configure Interrupt pin as input, no pull-up */
 	at91_set_gpio_input(AT91_PIN_PC11, 0);
 
+	r->start = r->end = gpio_to_irq(AT91_PIN_PC11);
 	platform_device_register(&dm9000_device);
 }
 #else
author maintainer
#14 lore raw

PATCH 9/62 ARM: OMAP1: DMTIMER: fix broken timer clock source selection

In reply to Greg KH

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

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

From: Paul Walmsley <[email protected]>

commit 6aaec67da1e41a0752a2b903b989e73b9f02e182 upstream.

DMTIMER source selection on OMAP1 is broken. omap1_dm_timer_set_src() tries to use __raw_{read,write}l() to read from and write to physical addresses, but those functions take virtual addresses.

sparse caught this:

arch/arm/mach-omap1/timer.c:50:13: warning: incorrect type in argument 1 (different base types)
arch/arm/mach-omap1/timer.c:50:13: expected void const volatile [noderef] <asn:2>*<noident>
arch/arm/mach-omap1/timer.c:50:13: got unsigned int
arch/arm/mach-omap1/timer.c:52:9: warning: incorrect type in argument 1 (different base types)
arch/arm/mach-omap1/timer.c:52:9: expected void const volatile [noderef] <asn:2>*<noident>
arch/arm/mach-omap1/timer.c:52:9: got unsigned int

Fix by using omap_{read,writel}(), just like the other users of the MOD_CONF_CTRL_1 register in the OMAP1 codebase. Of course, in the long term, removing omap_{read,write}l() is the appropriate thing to do; but this will take some work to do this cleanly.

Looks like this was caused by 97933d6 (ARM: OMAP1: dmtimer: conversion to platform devices) that dangerously moved code and changed it in the same patch.

Cc Tarun Kanti DebBarma <[email protected]>
[[email protected]: updated comments to include the breaking commit]
---
 arch/arm/mach-omap1/timer.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/mach-omap1/timer.c +2 -2
@@ -47,9 +47,9 @@ static int omap1_dm_timer_set_src(struct
 	int n = (pdev->id - 1) << 1;
 	u32 l;
 
-	l = __raw_readl(MOD_CONF_CTRL_1) & ~(0x03 << n);
+	l = omap_readl(MOD_CONF_CTRL_1) & ~(0x03 << n);
 	l |= source << n;
-	__raw_writel(l, MOD_CONF_CTRL_1);
+	omap_writel(l, MOD_CONF_CTRL_1);
 
 	return 0;
 }
author maintainer
#15 lore raw

PATCH 10/62 ARM: OMAP: serial: Fix the ocp smart idlemode handling bug

In reply to Greg KH

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

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

From: Santosh Shilimkar <[email protected]>

commit 5ae256dcd91bf308826a4ac19598b27ebb86a536 upstream.

The current serial UART code, while fidling with ocp idlemode bits, forget about the smart idle wakeup bit even if it is supported by UART IP block. This will lead to missing the module wakeup on OMAP's where the smart idle wakeup is supported.

This was the root cause of the console sluggishness issue, I have been observing on OMAP4 devices and also can be potential reason for some other UART wakeup issues.

---
 arch/arm/mach-omap2/serial.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
arch/arm/mach-omap2/serial.c +7 -1
@@ -110,8 +110,14 @@ static void omap_uart_set_noidle(struct
 static void omap_uart_set_smartidle(struct platform_device *pdev)
 {
 	struct omap_device *od = to_omap_device(pdev);
+	u8 idlemode;
 
-	omap_hwmod_set_slave_idlemode(od->hwmods[0], HWMOD_IDLEMODE_SMART);
+	if (od->hwmods[0]->class->sysc->idlemodes & SIDLE_SMART_WKUP)
+		idlemode = HWMOD_IDLEMODE_SMART_WKUP;
+	else
+		idlemode = HWMOD_IDLEMODE_SMART;
+
+	omap_hwmod_set_slave_idlemode(od->hwmods[0], idlemode);
 }
 
 #else
author maintainer
#16 lore raw

PATCH 11/62 mmc: fixes for eMMC v4.5 discard operation

In reply to Greg KH

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

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

From: Adrian Hunter <[email protected]>

commit 7194efb8f063ee3aa0cb50d9002348887e68ec10 upstream.

eMMC v4.5 discard operation is significantly different from the existing trim operation because it is not guaranteed to work with the new sanitize operation. Consequently mmc_can_trim() is separated from mmc_can_discard().

Also the new discard operation does not result in the sectors being set to all-zeros, so discard_zeroes_data must not be set.

In addition, the new discard has the same timeout as trim, but from v4.5 trim is defined to use the hc timeout. The timeout calculation is adjusted accordingly.

Fixes apply to linux 3.2 on.

---
 drivers/mmc/card/queue.c |    2 +-
 drivers/mmc/core/core.c  |    7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)
drivers/mmc/card/queue.c +1 -1
@@ -139,7 +139,7 @@ static void mmc_queue_setup_discard(stru
 
 	queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, q);
 	q->limits.max_discard_sectors = max_discard;
-	if (card->erased_byte == 0)
+	if (card->erased_byte == 0 && !mmc_can_discard(card))
 		q->limits.discard_zeroes_data = 1;
 	q->limits.discard_granularity = card->pref_erase << 9;
 	/* granularity must not be greater than max. discard */
drivers/mmc/core/core.c +4 -3
@@ -1557,7 +1557,10 @@ static unsigned int mmc_mmc_erase_timeou
 {
 	unsigned int erase_timeout;
 
-	if (card->ext_csd.erase_group_def & 1) {
+	if (arg == MMC_DISCARD_ARG ||
+	    (arg == MMC_TRIM_ARG && card->ext_csd.rev >= 6)) {
+		erase_timeout = card->ext_csd.trim_timeout;
+	} else if (card->ext_csd.erase_group_def & 1) {
 		/* High Capacity Erase Group Size uses HC timeouts */
 		if (arg == MMC_TRIM_ARG)
 			erase_timeout = card->ext_csd.trim_timeout;
@@ -1829,8 +1832,6 @@ int mmc_can_trim(struct mmc_card *card)
 {
 	if (card->ext_csd.sec_feature_support & EXT_CSD_SEC_GB_CL_EN)
 		return 1;
-	if (mmc_can_discard(card))
-		return 1;
 	return 0;
 }
 EXPORT_SYMBOL(mmc_can_trim);
author maintainer
#17 lore raw

PATCH 12/62 mmc: fixes for eMMC v4.5 sanitize operation

In reply to Greg KH

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

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

From: Adrian Hunter <[email protected]>

commit 283028122db37621b124f079ca8eae5b64807ad4 upstream.

eMMC v4.5 sanitize operation erases all copies of unmapped data. However trim or erase operations must be used first to unmap the required sectors. That was not being done.

Fixes apply to linux 3.2 on.

---
 drivers/mmc/card/block.c |   54 +++++++++++++++++++++++++++++++++--------------
 drivers/mmc/core/core.c  |    2 +
 2 files changed, 40 insertions(+), 16 deletions(-)
drivers/mmc/card/block.c +38 -16
@@ -874,7 +874,7 @@ static int mmc_blk_issue_secdiscard_rq(s
 {
 	struct mmc_blk_data *md = mq->data;
 	struct mmc_card *card = md->queue.card;
-	unsigned int from, nr, arg;
+	unsigned int from, nr, arg, trim_arg, erase_arg;
 	int err = 0, type = MMC_BLK_SECDISCARD;
 
 	if (!(mmc_can_secure_erase_trim(card) || mmc_can_sanitize(card))) {
@@ -882,20 +882,26 @@ static int mmc_blk_issue_secdiscard_rq(s
 		goto out;
 	}
 
+	from = blk_rq_pos(req);
+	nr = blk_rq_sectors(req);
+
 	/* The sanitize operation is supported at v4.5 only */
 	if (mmc_can_sanitize(card)) {
-		err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
-				EXT_CSD_SANITIZE_START, 1, 0);
-		goto out;
+		erase_arg = MMC_ERASE_ARG;
+		trim_arg = MMC_TRIM_ARG;
+	} else {
+		erase_arg = MMC_SECURE_ERASE_ARG;
+		trim_arg = MMC_SECURE_TRIM1_ARG;
 	}
 
-	from = blk_rq_pos(req);
-	nr = blk_rq_sectors(req);
-
-	if (mmc_can_trim(card) && !mmc_erase_group_aligned(card, from, nr))
-		arg = MMC_SECURE_TRIM1_ARG;
-	else
-		arg = MMC_SECURE_ERASE_ARG;
+	if (mmc_erase_group_aligned(card, from, nr))
+		arg = erase_arg;
+	else if (mmc_can_trim(card))
+		arg = trim_arg;
+	else {
+		err = -EINVAL;
+		goto out;
+	}
 retry:
 	if (card->quirks & MMC_QUIRK_INAND_CMD38) {
 		err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
@@ -905,25 +911,41 @@ retry:
 				 INAND_CMD38_ARG_SECERASE,
 				 0);
 		if (err)
-			goto out;
+			goto out_retry;
 	}
+
 	err = mmc_erase(card, from, nr, arg);
-	if (!err && arg == MMC_SECURE_TRIM1_ARG) {
+	if (err == -EIO)
+		goto out_retry;
+	if (err)
+		goto out;
+
+	if (arg == MMC_SECURE_TRIM1_ARG) {
 		if (card->quirks & MMC_QUIRK_INAND_CMD38) {
 			err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
 					 INAND_CMD38_ARG_EXT_CSD,
 					 INAND_CMD38_ARG_SECTRIM2,
 					 0);
 			if (err)
-				goto out;
+				goto out_retry;
 		}
+
 		err = mmc_erase(card, from, nr, MMC_SECURE_TRIM2_ARG);
+		if (err == -EIO)
+			goto out_retry;
+		if (err)
+			goto out;
 	}
-out:
-	if (err == -EIO && !mmc_blk_reset(md, card->host, type))
+
+	if (mmc_can_sanitize(card))
+		err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+				 EXT_CSD_SANITIZE_START, 1, 0);
+out_retry:
+	if (err && !mmc_blk_reset(md, card->host, type))
 		goto retry;
 	if (!err)
 		mmc_blk_reset_success(md, type);
+out:
 	spin_lock_irq(&md->lock);
 	__blk_end_request(req, err, blk_rq_bytes(req));
 	spin_unlock_irq(&md->lock);
drivers/mmc/core/core.c +2 -0
@@ -1850,6 +1850,8 @@ EXPORT_SYMBOL(mmc_can_discard);
 
 int mmc_can_sanitize(struct mmc_card *card)
 {
+	if (!mmc_can_trim(card) && !mmc_can_erase(card))
+		return 0;
 	if (card->ext_csd.sec_feature_support & EXT_CSD_SEC_SANITIZE)
 		return 1;
 	return 0;
author maintainer
#18 lore raw

PATCH 13/62 mmc: sdhci: refine non-removable card checking for card detection

In reply to Greg KH

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

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

From: Daniel Drake <[email protected]>

commit 87b87a3fc0eec58d95e4216392f889a26439ad22 upstream.

Commit c79396c191bc19 ("mmc: sdhci: prevent card detection activity for non-removable cards") disables card detection where the cards are marked as non-removable.

This makes sense, but the implementation detail of calling mmc_card_is_removable() causes some problems, because mmc_card_is_removable() is overloaded with CONFIG_MMC_UNSAFE_RESUME semantics.

In the OLPC XO case, we need CONFIG_MMC_UNSAFE_RESUME because our root filesystem is stored on SD, but we also have external SD card slots where we want automatic card detection.

Refine the check to only apply to hosts marked as MMC_CAP_NONREMOVABLE, which is defined to mean that the card is *really* nonremovable. This could be revisited in future if we find a way to improve CONFIG_MMC_UNSAFE_RESUME semantics.

---
 drivers/mmc/host/sdhci.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mmc/host/sdhci.c +1 -1
@@ -147,7 +147,7 @@ static void sdhci_set_card_detection(str
 	u32 present, irqs;
 
 	if ((host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION) ||
-	    !mmc_card_is_removable(host->mmc))
+	    (host->mmc->caps & MMC_CAP_NONREMOVABLE))
 		return;
 
 	present = sdhci_readl(host, SDHCI_PRESENT_STATE) &
author maintainer
#19 lore raw

PATCH 14/62 mmc: unbreak sdhci-esdhc-imx on i.MX25

In reply to Greg KH

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

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

From: Eric Bénard <[email protected]>

commit b89152824f993a9572b47eb31f4579feadeac34c upstream.

This was broken by me in 37865fe91582582a6f6c00652f6a2b1ff71f8a78 ("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read).

---
 drivers/mmc/host/sdhci-esdhc-imx.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/mmc/host/sdhci-esdhc-imx.c +1 -2
@@ -467,8 +467,7 @@ static int __devinit sdhci_esdhc_imx_pro
 	clk_enable(clk);
 	pltfm_host->clk = clk;
 
-	if (!is_imx25_esdhc(imx_data))
-		host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
+	host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
 
 	if (is_imx25_esdhc(imx_data) || is_imx35_esdhc(imx_data))
 		/* Fix errata ENGcm07207 present on i.MX25 and i.MX35 */
Acked-by Wolfram Sang on v1 14/62
#20 lore raw

Re: [ 14/62] mmc: unbreak sdhci-esdhc-imx on i.MX25

Hi,

Quoted 1 line · Greg KH

3.3-stable review patch.

[...]

Quoted 6 lines

commit b89152824f993a9572b47eb31f4579feadeac34c upstream.

This was broken by me in 37865fe91582582a6f6c00652f6a2b1ff71f8a78 ("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read).

37865fe91582 is v2.6.37-rc4~24^2~7 so it sounds like this patch should also be applied to 3.0.y.

Here's a straightforward backport to account for the lack of v3.1-rc1~321^2~77 ("mmc: sdhci: make sdhci-pltfm device drivers self registered") and v3.1-rc1~125^2^2~5 ("mmc: sdhci-esdhc-imx: get rid of the uses of cpu_is_mx"). Sensible?

-- >8 --
From: Eric Bénard <[email protected]>
Date: Wed, 18 Apr 2012 02:30:20 +0200

commit b89152824f993a9572b47eb31f4579feadeac34c upstream.

This was broken by me in 37865fe91582582a6f6c00652f6a2b1ff71f8a78 ("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read).

---
Thanks,
Jonathan

 drivers/mmc/host/sdhci-esdhc-imx.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/mmc/host/sdhci-esdhc-imx.c +1 -2
index 92e543701836..6fe8cede4179 100644
@@ -245,8 +245,7 @@ static int esdhc_pltfm_init(struct sdhci_host *host, struct sdhci_pltfm_data *pd
 	}
 	pltfm_host->priv = imx_data;
 
-	if (!cpu_is_mx25())
-		host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
+	host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
 
 	if (cpu_is_mx25() || cpu_is_mx35()) {
 		/* Fix errata ENGcm07207 present on i.MX25 and i.MX35 */
Signature · 1 line
1.7.10
#21 lore raw

Re: [ 14/62] mmc: unbreak sdhci-esdhc-imx on i.MX25

Quoted 13 lines · Jonathan Nieder

Hi,

Quoted 1 line · Greg KH

3.3-stable review patch.

[...]

Quoted 6 lines

commit b89152824f993a9572b47eb31f4579feadeac34c upstream.

This was broken by me in 37865fe91582582a6f6c00652f6a2b1ff71f8a78 ("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read).

Quoted 7 lines

37865fe91582 is v2.6.37-rc4~24^2~7 so it sounds like this patch should also be applied to 3.0.y.

Here's a straightforward backport to account for the lack of v3.1-rc1~321^2~77 ("mmc: sdhci: make sdhci-pltfm device drivers self registered") and v3.1-rc1~125^2^2~5 ("mmc: sdhci-esdhc-imx: get rid of the uses of cpu_is_mx"). Sensible?

Yes, thanks.

Signature · 2 lines
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
author maintainer
#22 lore raw

Re: [ 14/62] mmc: unbreak sdhci-esdhc-imx on i.MX25

In reply to Jonathan Nieder
Quoted 13 lines · Jonathan Nieder

Hi,

Quoted 1 line · Greg KH

3.3-stable review patch.

[...]

Quoted 6 lines

commit b89152824f993a9572b47eb31f4579feadeac34c upstream.

This was broken by me in 37865fe91582582a6f6c00652f6a2b1ff71f8a78 ("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read).

Quoted 7 lines

37865fe91582 is v2.6.37-rc4~24^2~7 so it sounds like this patch should also be applied to 3.0.y.

Here's a straightforward backport to account for the lack of v3.1-rc1~321^2~77 ("mmc: sdhci: make sdhci-pltfm device drivers self registered") and v3.1-rc1~125^2^2~5 ("mmc: sdhci-esdhc-imx: get rid of the uses of cpu_is_mx"). Sensible?

Looks good to me, thanks for doing this.

author maintainer
#23 lore raw

PATCH 15/62 xen/gntdev: do not set VM_PFNMAP

In reply to Greg KH

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

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

From: Stefano Stabellini <[email protected]>

commit e8e937be971d706061dc56220ff3605ab77622a7 upstream.

Since we are using the m2p_override we do have struct pages corresponding to the user vma mmap'ed by gntdev.

Removing the VM_PFNMAP flag makes get_user_pages work on that vma. An example test case would be using a Xen userspace block backend (QDISK) on a file on NFS using O_DIRECT.

---
 drivers/xen/gntdev.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/xen/gntdev.c +1 -1
@@ -722,7 +722,7 @@ static int gntdev_mmap(struct file *flip
 	vma->vm_flags |= VM_RESERVED|VM_DONTEXPAND;
 
 	if (use_ptemod)
-		vma->vm_flags |= VM_DONTCOPY|VM_PFNMAP;
+		vma->vm_flags |= VM_DONTCOPY;
 
 	vma->vm_private_data = map;
 
author maintainer
#24 lore raw

PATCH 16/62 xen/xenbus: Add quirk to deal with misconfigured backends.

In reply to Greg KH

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

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

From: Konrad Rzeszutek Wilk <[email protected]>

commit 3066616ce23aad5719c23a0f21f32676402cb44b upstream.

A rather annoying and common case is when booting a PVonHVM guest and exposing the PV KBD and PV VFB - as broken toolstacks don't always initialize the backends correctly.

Normally The HVM guest is using the VGA driver and the emulated keyboard for this (though upstream version of QEMU implements PV KBD, but still uses a VGA driver). We provide a very basic two-stage wait mechanism - where we wait for 30 seconds for all devices, and then for 270 for all them except the two mentioned.

That allows us to wait for the essential devices, like network or disk for the full 6 minutes.

To trigger this, put this in your guest config:

vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1']

instead of this:
vnc=1
vnclisten="0.0.0.0"

[v3: Split delay in non-essential (30 seconds) and essential
devices per Ian and Stefano suggestion]

[v4: Added comments per Stefano suggestion]
---
 drivers/xen/xenbus/xenbus_probe_frontend.c |   69 ++++++++++++++++++++++-------
 1 file changed, 53 insertions(+), 16 deletions(-)
drivers/xen/xenbus/xenbus_probe_frontend.c +53 -16
@@ -129,7 +129,7 @@ static int read_backend_details(struct x
 	return xenbus_read_otherend_details(xendev, "backend-id", "backend");
 }
 
-static int is_device_connecting(struct device *dev, void *data)
+static int is_device_connecting(struct device *dev, void *data, bool ignore_nonessential)
 {
 	struct xenbus_device *xendev = to_xenbus_device(dev);
 	struct device_driver *drv = data;
@@ -146,16 +146,41 @@ static int is_device_connecting(struct d
 	if (drv && (dev->driver != drv))
 		return 0;
 
+	if (ignore_nonessential) {
+		/* With older QEMU, for PVonHVM guests the guest config files
+		 * could contain: vfb = [ 'vnc=1, vnclisten=0.0.0.0']
+		 * which is nonsensical as there is no PV FB (there can be
+		 * a PVKB) running as HVM guest. */
+
+		if ((strncmp(xendev->nodename, "device/vkbd", 11) == 0))
+			return 0;
+
+		if ((strncmp(xendev->nodename, "device/vfb", 10) == 0))
+			return 0;
+	}
 	xendrv = to_xenbus_driver(dev->driver);
 	return (xendev->state < XenbusStateConnected ||
 		(xendev->state == XenbusStateConnected &&
 		 xendrv->is_ready && !xendrv->is_ready(xendev)));
 }
+static int essential_device_connecting(struct device *dev, void *data)
+{
+	return is_device_connecting(dev, data, true /* ignore PV[KBB+FB] */);
+}
+static int non_essential_device_connecting(struct device *dev, void *data)
+{
+	return is_device_connecting(dev, data, false);
+}
 
-static int exists_connecting_device(struct device_driver *drv)
+static int exists_essential_connecting_device(struct device_driver *drv)
 {
 	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
-				is_device_connecting);
+				essential_device_connecting);
+}
+static int exists_non_essential_connecting_device(struct device_driver *drv)
+{
+	return bus_for_each_dev(&xenbus_frontend.bus, NULL, drv,
+				non_essential_device_connecting);
 }
 
 static int print_device_status(struct device *dev, void *data)
@@ -186,6 +211,23 @@ static int print_device_status(struct de
 /* We only wait for device setup after most initcalls have run. */
 static int ready_to_wait_for_devices;
 
+static bool wait_loop(unsigned long start, unsigned int max_delay,
+		     unsigned int *seconds_waited)
+{
+	if (time_after(jiffies, start + (*seconds_waited+5)*HZ)) {
+		if (!*seconds_waited)
+			printk(KERN_WARNING "XENBUS: Waiting for "
+			       "devices to initialise: ");
+		*seconds_waited += 5;
+		printk("%us...", max_delay - *seconds_waited);
+		if (*seconds_waited == max_delay)
+			return true;
+	}
+
+	schedule_timeout_interruptible(HZ/10);
+
+	return false;
+}
 /*
  * On a 5-minute timeout, wait for all devices currently configured.  We need
  * to do this to guarantee that the filesystems and / or network devices
@@ -209,19 +251,14 @@ static void wait_for_devices(struct xenb
 	if (!ready_to_wait_for_devices || !xen_domain())
 		return;
 
-	while (exists_connecting_device(drv)) {
-		if (time_after(jiffies, start + (seconds_waited+5)*HZ)) {
-			if (!seconds_waited)
-				printk(KERN_WARNING "XENBUS: Waiting for "
-				       "devices to initialise: ");
-			seconds_waited += 5;
-			printk("%us...", 300 - seconds_waited);
-			if (seconds_waited == 300)
-				break;
-		}
-
-		schedule_timeout_interruptible(HZ/10);
-	}
+	while (exists_non_essential_connecting_device(drv))
+		if (wait_loop(start, 30, &seconds_waited))
+			break;
+
+	/* Skips PVKB and PVFB check.*/
+	while (exists_essential_connecting_device(drv))
+		if (wait_loop(start, 270, &seconds_waited))
+			break;
 
 	if (seconds_waited)
 		printk("\n");
author maintainer
#25 lore raw

PATCH 17/62 USB: yurex: Remove allocation of coherent buffer for setup-packet buffer

In reply to Greg KH

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

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

From: Tomoki Sekiyama <[email protected]>

commit 523fc5c14f6cad283e5a266eba0e343aed6e73d5 upstream.

Removes allocation of coherent buffer for the control-request setup-packet buffer from the yurex driver. Using coherent buffers for setup-packet is obsolete and does not work with some USB host implementations.

---
 drivers/usb/misc/yurex.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)
drivers/usb/misc/yurex.c +2 -6
@@ -99,9 +99,7 @@ static void yurex_delete(struct kref *kr
 	usb_put_dev(dev->udev);
 	if (dev->cntl_urb) {
 		usb_kill_urb(dev->cntl_urb);
-		if (dev->cntl_req)
-			usb_free_coherent(dev->udev, YUREX_BUF_SIZE,
-				dev->cntl_req, dev->cntl_urb->setup_dma);
+		kfree(dev->cntl_req);
 		if (dev->cntl_buffer)
 			usb_free_coherent(dev->udev, YUREX_BUF_SIZE,
 				dev->cntl_buffer, dev->cntl_urb->transfer_dma);
@@ -234,9 +232,7 @@ static int yurex_probe(struct usb_interf
 	}
 
 	/* allocate buffer for control req */
-	dev->cntl_req = usb_alloc_coherent(dev->udev, YUREX_BUF_SIZE,
-					   GFP_KERNEL,
-					   &dev->cntl_urb->setup_dma);
+	dev->cntl_req = kmalloc(YUREX_BUF_SIZE, GFP_KERNEL);
 	if (!dev->cntl_req) {
 		err("Could not allocate cntl_req");
 		goto error;
author maintainer
#26 lore raw

PATCH 18/62 USB: yurex: Fix missing URB_NO_TRANSFER_DMA_MAP flag in urb

In reply to Greg KH

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

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

From: Tomoki Sekiyama <[email protected]>

commit 532f17b5d59bf0deb6f1ff9bc1fb27d5b5011c09 upstream.

Current probing code is setting URB_NO_TRANSFER_DMA_MAP flag into a wrong urb structure, and this causes BUG_ON with some USB host implementations. This patch fixes the issue.

---
 drivers/usb/misc/yurex.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/misc/yurex.c +1 -1
@@ -282,7 +282,7 @@ static int yurex_probe(struct usb_interf
 			 usb_rcvintpipe(dev->udev, dev->int_in_endpointAddr),
 			 dev->int_buffer, YUREX_BUF_SIZE, yurex_interrupt,
 			 dev, 1);
-	dev->cntl_urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
+	dev->urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
 	if (usb_submit_urb(dev->urb, GFP_KERNEL)) {
 		retval = -EIO;
 		err("Could not submitting URB");
author maintainer
#27 lore raw

PATCH 19/62 uwb: fix use of del_timer_sync() in interrupt

In reply to Greg KH

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

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

From: Oliver Neukum <[email protected]>

commit 9426cd05682745d1024dbabdec5631309bd2f480 upstream.

del_timer_sync() cannot be used in interrupt.
Replace it with del_timer() and a flag

---
 drivers/uwb/neh.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)
drivers/uwb/neh.c +11 -1
@@ -107,6 +107,7 @@ struct uwb_rc_neh {
 	u8 evt_type;
 	__le16 evt;
 	u8 context;
+	u8 completed;
 	uwb_rc_cmd_cb_f cb;
 	void *arg;
 
@@ -409,6 +410,7 @@ static void uwb_rc_neh_grok_event(struct
 	struct device *dev = &rc->uwb_dev.dev;
 	struct uwb_rc_neh *neh;
 	struct uwb_rceb *notif;
+	unsigned long flags;
 
 	if (rceb->bEventContext == 0) {
 		notif = kmalloc(size, GFP_ATOMIC);
@@ -422,7 +424,11 @@ static void uwb_rc_neh_grok_event(struct
 	} else {
 		neh = uwb_rc_neh_lookup(rc, rceb);
 		if (neh) {
-			del_timer_sync(&neh->timer);
+			spin_lock_irqsave(&rc->neh_lock, flags);
+			/* to guard against a timeout */
+			neh->completed = 1;
+			del_timer(&neh->timer);
+			spin_unlock_irqrestore(&rc->neh_lock, flags);
 			uwb_rc_neh_cb(neh, rceb, size);
 		} else
 			dev_warn(dev, "event 0x%02x/%04x/%02x (%zu bytes): nobody cared\n",
@@ -568,6 +574,10 @@ static void uwb_rc_neh_timer(unsigned lo
 	unsigned long flags;
 
 	spin_lock_irqsave(&rc->neh_lock, flags);
+	if (neh->completed) {
+		spin_unlock_irqrestore(&rc->neh_lock, flags);
+		return;
+	}
 	if (neh->context)
 		__uwb_rc_neh_rm(rc, neh);
 	else
author maintainer
#28 lore raw

PATCH 20/62 uwb: fix error handling

In reply to Greg KH

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

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

From: Oliver Neukum <[email protected]>

commit 5bd7b419ef2eb4989b207753e088c3437159618a upstream.

Fatal errors such as a device disconnect must not trigger error handling. The error returns must be checked.

---
 drivers/uwb/hwa-rc.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/uwb/hwa-rc.c +2 -1
@@ -645,7 +645,8 @@ void hwarc_neep_cb(struct urb *urb)
 		dev_err(dev, "NEEP: URB error %d\n", urb->status);
 	}
 	result = usb_submit_urb(urb, GFP_ATOMIC);
-	if (result < 0) {
+	if (result < 0 && result != -ENODEV && result != -EPERM) {
+		/* ignoring unrecoverable errors */
 		dev_err(dev, "NEEP: Can't resubmit URB (%d) resetting device\n",
 			result);
 		goto error;
author maintainer
#29 lore raw

PATCH 21/62 davinci_mdio: Fix MDIO timeout check

In reply to Greg KH

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

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

From: Christian Riesch <[email protected]>

commit 5b76d0600b2b08eef77f8e9226938b7b6bde3099 upstream.

Under heavy load (flood ping) it is possible for the MDIO timeout to expire before the loop checks the GO bit again. This patch adds an additional check whether the operation was done before actually returning -ETIMEDOUT.

To reproduce this bug, flood ping the device, e.g., ping -f -l 1000 After some time, a "timed out waiting for user access" warning may appear. And even worse, link may go down since the PHY reported a timeout.

---
 drivers/net/ethernet/ti/davinci_mdio.c |    5 +++++
 1 file changed, 5 insertions(+)
drivers/net/ethernet/ti/davinci_mdio.c +5 -0
@@ -181,6 +181,11 @@ static inline int wait_for_user_access(s
 		__davinci_mdio_reset(data);
 		return -EAGAIN;
 	}
+
+	reg = __raw_readl(&regs->user[0].access);
+	if ((reg & USERACCESS_GO) == 0)
+		return 0;
+
 	dev_err(data->dev, "timed out waiting for user access\n");
 	return -ETIMEDOUT;
 }
author maintainer
#30 lore raw

PATCH 22/62 mwifiex: update pcie8766 scratch register addresses

In reply to Greg KH

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

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

From: Bing Zhao <[email protected]>

commit 428ca8a7065354877db63ceabfc493107686eebe upstream.

The scratch register addresses have been changed for newer chips. Since the old chip was never shipped and it will not be supported any more, just update register addresses to support the new chips.

---
 drivers/net/wireless/mwifiex/pcie.h |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/net/wireless/mwifiex/pcie.h +9 -9
@@ -48,15 +48,15 @@
 #define PCIE_HOST_INT_STATUS_MASK			0xC3C
 #define PCIE_SCRATCH_2_REG				0xC40
 #define PCIE_SCRATCH_3_REG				0xC44
-#define PCIE_SCRATCH_4_REG				0xCC0
-#define PCIE_SCRATCH_5_REG				0xCC4
-#define PCIE_SCRATCH_6_REG				0xCC8
-#define PCIE_SCRATCH_7_REG				0xCCC
-#define PCIE_SCRATCH_8_REG				0xCD0
-#define PCIE_SCRATCH_9_REG				0xCD4
-#define PCIE_SCRATCH_10_REG				0xCD8
-#define PCIE_SCRATCH_11_REG				0xCDC
-#define PCIE_SCRATCH_12_REG				0xCE0
+#define PCIE_SCRATCH_4_REG				0xCD0
+#define PCIE_SCRATCH_5_REG				0xCD4
+#define PCIE_SCRATCH_6_REG				0xCD8
+#define PCIE_SCRATCH_7_REG				0xCDC
+#define PCIE_SCRATCH_8_REG				0xCE0
+#define PCIE_SCRATCH_9_REG				0xCE4
+#define PCIE_SCRATCH_10_REG				0xCE8
+#define PCIE_SCRATCH_11_REG				0xCEC
+#define PCIE_SCRATCH_12_REG				0xCF0
 
 #define CPU_INTR_DNLD_RDY				BIT(0)
 #define CPU_INTR_DOOR_BELL				BIT(1)
author maintainer
#31 lore raw

PATCH 23/62 brcm80211: smac: resume transmit fifo upon receiving frames

In reply to Greg KH

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

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

From: Arend van Spriel <[email protected]>

commit badc4f07622f0f7093a201638f45e85765f1b5e4 upstream.

There have been reports about not being able to use access-points on channel 12 and 13 or having connectivity issues when these channels were part of the selected regulatory domain. Upon switching to these channels the brcmsmac driver suspends the transmit dma fifos. This patch resumes them upon handing over the first received beacon to mac80211.

This patch is to be applied to the stable tree for kernel versions 3.2 and 3.3.

---
 drivers/net/wireless/brcm80211/brcmsmac/main.c |    8 ++++++++
 1 file changed, 8 insertions(+)
drivers/net/wireless/brcm80211/brcmsmac/main.c +8 -0
@@ -7629,6 +7629,7 @@ brcms_c_recvctl(struct brcms_c_info *wlc
 {
 	int len_mpdu;
 	struct ieee80211_rx_status rx_status;
+	struct ieee80211_hdr *hdr;
 
 	memset(&rx_status, 0, sizeof(rx_status));
 	prep_mac80211_status(wlc, rxh, p, &rx_status);
@@ -7638,6 +7639,13 @@ brcms_c_recvctl(struct brcms_c_info *wlc
 	skb_pull(p, D11_PHY_HDR_LEN);
 	__skb_trim(p, len_mpdu);
 
+	/* unmute transmit */
+	if (wlc->hw->suspended_fifos) {
+		hdr = (struct ieee80211_hdr *)p->data;
+		if (ieee80211_is_beacon(hdr->frame_control))
+			brcms_b_mute(wlc->hw, false);
+	}
+
 	memcpy(IEEE80211_SKB_RXCB(p), &rx_status, sizeof(rx_status));
 	ieee80211_rx_irqsafe(wlc->pub->ieee_hw, p);
 }
Tested-by Francesco Saverio Schiavarelli Reviewed-by Pieter-Paul Giesberts Reviewed-by Brett Rudley on v1 23/62
#32 lore raw

Re: [ 23/62] brcm80211: smac: resume transmit fifo upon receiving frames

Quoted 1 line · Greg KH

3.3-stable review patch.

[...]

Quoted 11 lines

commit badc4f07622f0f7093a201638f45e85765f1b5e4 upstream.

There have been reports about not being able to use access-points on channel 12 and 13 or having connectivity issues when these channels were part of the selected regulatory domain. Upon switching to these channels the brcmsmac driver suspends the transmit dma fifos. This patch resumes them upon handing over the first received beacon to mac80211.

This patch is to be applied to the stable tree for kernel versions 3.2 and 3.3.

Here's a blind backport to 3.0.y for the next cycle. Nothing scary involved, though of course it's completely untested. Sensible?

Thanks,
Jonathan

-- >8 --
From: Arend van Spriel <[email protected]>
Date: Wed, 11 Apr 2012 11:52:51 +0200

commit badc4f07622f0f7093a201638f45e85765f1b5e4 upstream.

There have been reports about not being able to use access-points on channel 12 and 13 or having connectivity issues when these channels were part of the selected regulatory domain. Upon switching to these channels the brcmsmac driver suspends the transmit dma fifos. This patch resumes them upon handing over the first received beacon to mac80211.

This patch is to be applied to the stable tree for kernel versions 3.2 and 3.3.

---
 drivers/staging/brcm80211/brcmsmac/wlc_bmac.c |    3 +--
 drivers/staging/brcm80211/brcmsmac/wlc_bmac.h |    1 +
 drivers/staging/brcm80211/brcmsmac/wlc_main.c |    8 ++++++++
 3 files changed, 10 insertions(+), 2 deletions(-)
drivers/staging/brcm80211/brcmsmac/wlc_bmac.c +1 -2
index 453492610613..934e7f9a8673 100644
@@ -143,7 +143,6 @@ static bool wlc_bmac_validate_chip_access(struct wlc_hw_info *wlc_hw);
 static char *wlc_get_macaddr(struct wlc_hw_info *wlc_hw);
 static void wlc_mhfdef(struct wlc_info *wlc, u16 *mhfs, u16 mhf2_init);
 static void wlc_mctrl_write(struct wlc_hw_info *wlc_hw);
-static void wlc_bmac_mute(struct wlc_hw_info *wlc_hw, bool want, mbool flags);
 static void wlc_ucode_mute_override_set(struct wlc_hw_info *wlc_hw);
 static void wlc_ucode_mute_override_clear(struct wlc_hw_info *wlc_hw);
 static u32 wlc_wlintrsoff(struct wlc_info *wlc);
@@ -2725,7 +2724,7 @@ void wlc_intrsrestore(struct wlc_info *wlc, u32 macintmask)
 	W_REG(&wlc_hw->regs->macintmask, wlc->macintmask);
 }
 
-static void wlc_bmac_mute(struct wlc_hw_info *wlc_hw, bool on, mbool flags)
+void wlc_bmac_mute(struct wlc_hw_info *wlc_hw, bool on, mbool flags)
 {
 	u8 null_ether_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
 
drivers/staging/brcm80211/brcmsmac/wlc_bmac.h +1 -0
index a5dccc273ac5..a2a4e7328ee4 100644
@@ -103,6 +103,7 @@ extern void wlc_bmac_macphyclk_set(struct wlc_hw_info *wlc_hw, bool clk);
 extern void wlc_bmac_phy_reset(struct wlc_hw_info *wlc_hw);
 extern void wlc_bmac_corereset(struct wlc_hw_info *wlc_hw, u32 flags);
 extern void wlc_bmac_reset(struct wlc_hw_info *wlc_hw);
+extern void wlc_bmac_mute(struct wlc_hw_info *wlc_hw, bool want, mbool flags);
 extern void wlc_bmac_init(struct wlc_hw_info *wlc_hw, chanspec_t chanspec,
 			  bool mute);
 extern int wlc_bmac_up_prep(struct wlc_hw_info *wlc_hw);
drivers/staging/brcm80211/brcmsmac/wlc_main.c +8 -0
index 4b4a31eff90c..99250e29461f 100644
@@ -6145,6 +6145,7 @@ wlc_recvctl(struct wlc_info *wlc, d11rxhdr_t *rxh, struct sk_buff *p)
 {
 	int len_mpdu;
 	struct ieee80211_rx_status rx_status;
+	struct ieee80211_hdr *hdr;
 
 	memset(&rx_status, 0, sizeof(rx_status));
 	prep_mac80211_status(wlc, rxh, p, &rx_status);
@@ -6154,6 +6155,13 @@ wlc_recvctl(struct wlc_info *wlc, d11rxhdr_t *rxh, struct sk_buff *p)
 	skb_pull(p, D11_PHY_HDR_LEN);
 	__skb_trim(p, len_mpdu);
 
+	/* unmute transmit */
+	if (wlc->hw->suspended_fifos) {
+		hdr = (struct ieee80211_hdr *)p->data;
+		if (ieee80211_is_beacon(hdr->frame_control))
+			wlc_bmac_mute(wlc->hw, false, 0);
+	}
+
 	memcpy(IEEE80211_SKB_RXCB(p), &rx_status, sizeof(rx_status));
 	ieee80211_rx_irqsafe(wlc->pub->ieee_hw, p);
 	return;
Signature · 1 line
1.7.10
#33 lore raw

Re: [ 23/62] brcm80211: smac: resume transmit fifo upon receiving frames

Quoted 13 lines · Jonathan Nieder
Quoted 1 line · Greg KH

3.3-stable review patch.

[...]

Quoted 9 lines

commit badc4f07622f0f7093a201638f45e85765f1b5e4 upstream.

There have been reports about not being able to use access-points on channel 12 and 13 or having connectivity issues when these channels were part of the selected regulatory domain. Upon switching to these channels the brcmsmac driver suspends the transmit dma fifos. This patch resumes them upon handing over the first received beacon to mac80211.

Quoted 8 lines
Quoted 2 lines

This patch is to be applied to the stable tree for kernel versions 3.2 and 3.3.

Here's a blind backport to 3.0.y for the next cycle. Nothing scary involved, though of course it's completely untested. Sensible?

Thanks,
Jonathan

We decided to only submit the patch for the mainline version of the driver, but your changes on the staging driver look fine. So if this patch is accepted in stable it is

Gr. AvS

#34 lore raw

Re: [ 23/62] brcm80211: smac: resume transmit fifo upon receiving frames

Quoted 5 lines · Arend van Spriel

We decided to only submit the patch for the mainline version of the driver, but your changes on the staging driver look fine. So if this patch is accepted in stable it is

Thanks for looking it over.

author maintainer
#35 lore raw

Re: [ 23/62] brcm80211: smac: resume transmit fifo upon receiving frames

Quoted 9 lines · Jonathan Nieder
Quoted 5 lines · Arend van Spriel

We decided to only submit the patch for the mainline version of the driver, but your changes on the staging driver look fine. So if this patch is accepted in stable it is

Thanks for looking it over.

Thanks for doing the work, now applied.

greg k-h

author maintainer
#36 lore raw

PATCH 24/62 mac80211: fix logic error in ibss channel type check

In reply to Greg KH

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

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

From: Felix Fietkau <[email protected]>

commit 6741e7f048dacc92e37c5d724ff5c64e45f6c2c9 upstream.

The broken check leads to rate control attempting to use HT40 while the driver is configured for HT20. This leads to interesting hardware issues.

HT40 can only be used if the channel type is either HT40- or HT40+ and if the channel type of the cell matches the local type.

---
 net/mac80211/ibss.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
net/mac80211/ibss.c +2 -2
@@ -435,8 +435,8 @@ static void ieee80211_rx_bss_info(struct
 			 * fall back to HT20 if we don't use or use
 			 * the other extension channel
 			 */
-			if ((channel_type == NL80211_CHAN_HT40MINUS ||
-			     channel_type == NL80211_CHAN_HT40PLUS) &&
+			if (!(channel_type == NL80211_CHAN_HT40MINUS ||
+			      channel_type == NL80211_CHAN_HT40PLUS) ||
 			    channel_type != sdata->u.ibss.channel_type)
 				sta_ht_cap_new.cap &=
 					~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
author maintainer
#37 lore raw

PATCH 25/62 media: rc-core: set mode for winbond-cir

In reply to Greg KH

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

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

From: David Härdeman <[email protected]>

commit d9b786955f80fb306471fdb9ea24c6d03af6ca36 upstream.

Setting the correct mode is required by rc-core or scancodes won't be generated (which isn't very user-friendly).

This one-line fix should be suitable for 3.4-rc2.

---
 drivers/media/rc/winbond-cir.c |    1 +
 1 file changed, 1 insertion(+)
drivers/media/rc/winbond-cir.c +1 -0
@@ -1046,6 +1046,7 @@ wbcir_probe(struct pnp_dev *device, cons
 		goto exit_unregister_led;
 	}
 
+	data->dev->driver_type = RC_DRIVER_IR_RAW;
 	data->dev->driver_name = WBCIR_NAME;
 	data->dev->input_name = WBCIR_NAME;
 	data->dev->input_phys = "wbcir/cir0";
author maintainer
#38 lore raw

PATCH 26/62 media: drxk: Does not unlock mutex if sanity check failed in scu_command()

In reply to Greg KH

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

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

From: Alexey Khoroshilov <[email protected]>

commit e4459e1682c107d7ee1bf102c1ba534230e9b50b upstream.

If sanity check fails in scu_command(), goto error leads to unlock of an unheld mutex. The check should not fail in reality, but it nevertheless worth fixing.

Found by Linux Driver Verification project (linuxtesting.org).

---
 drivers/media/dvb/frontends/drxk_hard.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/media/dvb/frontends/drxk_hard.c +4 -2
@@ -1525,8 +1525,10 @@ static int scu_command(struct drxk_state
 	dprintk(1, "\n");
 
 	if ((cmd == 0) || ((parameterLen > 0) && (parameter == NULL)) ||
-	    ((resultLen > 0) && (result == NULL)))
-		goto error;
+	    ((resultLen > 0) && (result == NULL))) {
+		printk(KERN_ERR "drxk: Error %d on %s\n", status, __func__);
+		return status;
+	}
 
 	mutex_lock(&state->mutex);
 
author maintainer
#39 lore raw

PATCH 27/62 media: dvb_frontend: Fix a regression when switching back to DVB-S

In reply to Greg KH

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

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

From: Mauro Carvalho Chehab <[email protected]>

commit 3626479e482aa3247aac03724094ba6c13ea1e46 upstream.

There are some softwares (Kaffeine and likely xine) that uses a DVBv5 call to switch to DVB-S2, but expects that a DVBv3 call to switch back to DVB-S. Well, this is not right, as a DVBv3 call doesn't know anything about delivery systems.

However, as, by accident, this used to work, we need to restore its behavior, in order to avoid regressions with those softwares.

Reported on this Fedora 16 bugzilla:

	https://bugzilla.redhat.com/show_bug.cgi?id=812895
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |   25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)
drivers/media/dvb/dvb-core/dvb_frontend.c +24 -1
@@ -1446,6 +1446,28 @@ static int set_delivery_system(struct dv
 				__func__);
 			return -EINVAL;
 		}
+		/*
+		 * Get a delivery system that is compatible with DVBv3
+		 * NOTE: in order for this to work with softwares like Kaffeine that
+		 *	uses a DVBv5 call for DVB-S2 and a DVBv3 call to go back to
+		 *	DVB-S, drivers that support both should put the SYS_DVBS entry
+		 *	before the SYS_DVBS2, otherwise it won't switch back to DVB-S.
+		 *	The real fix is that userspace applications should not use DVBv3
+		 *	and not trust on calling FE_SET_FRONTEND to switch the delivery
+		 *	system.
+		 */
+		ncaps = 0;
+		while (fe->ops.delsys[ncaps] && ncaps < MAX_DELSYS) {
+			if (fe->ops.delsys[ncaps] == desired_system) {
+				delsys = desired_system;
+				break;
+			}
+			ncaps++;
+		}
+		if (delsys == SYS_UNDEFINED) {
+			dprintk("%s() Couldn't find a delivery system that matches %d\n",
+				__func__, desired_system);
+		}
 	} else {
 		/*
 		 * This is a DVBv5 call. So, it likely knows the supported
@@ -1494,9 +1516,10 @@ static int set_delivery_system(struct dv
 				__func__);
 			return -EINVAL;
 		}
-		c->delivery_system = delsys;
 	}
 
+	c->delivery_system = delsys;
+
 	/*
 	 * The DVBv3 or DVBv5 call is requesting a different system. So,
 	 * emulation is needed.
author maintainer
#40 lore raw

PATCH 28/62 cfg80211: fix interface combinations check.

In reply to Greg KH

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

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

From: Lukasz Kucharczyk <[email protected]>

commit e55a4046dab28c440c96890bdddcf02dc8981f2d upstream.

---
 net/wireless/util.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/wireless/util.c +1 -1
@@ -988,7 +988,7 @@ int cfg80211_can_change_interface(struct
 			if (rdev->wiphy.software_iftypes & BIT(iftype))
 				continue;
 			for (j = 0; j < c->n_limits; j++) {
-				if (!(limits[j].types & iftype))
+				if (!(limits[j].types & BIT(iftype)))
 					continue;
 				if (limits[j].max < num[iftype])
 					goto cont;
author maintainer
#41 lore raw

PATCH 29/62 staging: r8712u: Fix regression caused by commit 8c213fa

In reply to Greg KH

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

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

From: Larry Finger <[email protected]>

commit 2080913e017ab9f88379d93fd09546ad95faf87b upstream.

In commit 8c213fa "staging: r8712u: Use asynchronous firmware loading", the command to release the firmware was placed in the wrong routine.

In combination with the bug introduced in commit a5ee652 "staging: r8712u:
Interface-state not fully tracked", the driver attempts to upload firmware that had already been released. This bug is the source of one of the problems in https://bugs.archlinux.org/task/27996#comment89833.

---
 drivers/staging/rtl8712/os_intfs.c |    3 ---
 drivers/staging/rtl8712/usb_intf.c |    5 +++++
 2 files changed, 5 insertions(+), 3 deletions(-)
drivers/staging/rtl8712/os_intfs.c +0 -3
@@ -476,9 +476,6 @@ static int netdev_close(struct net_devic
 	r8712_free_assoc_resources(padapter);
 	/*s2-4.*/
 	r8712_free_network_queue(padapter);
-	release_firmware(padapter->fw);
-	/* never exit with a firmware callback pending */
-	wait_for_completion(&padapter->rtl8712_fw_ready);
 	return 0;
 }
 
drivers/staging/rtl8712/usb_intf.c +5 -0
@@ -30,6 +30,7 @@
 
 #include <linux/usb.h>
 #include <linux/module.h>
+#include <linux/firmware.h>
 
 #include "osdep_service.h"
 #include "drv_types.h"
@@ -621,6 +622,10 @@ static void r871xu_dev_remove(struct usb
 	struct _adapter *padapter = netdev_priv(pnetdev);
 	struct usb_device *udev = interface_to_usbdev(pusb_intf);
 
+	if (padapter->fw_found)
+		release_firmware(padapter->fw);
+	/* never exit with a firmware callback pending */
+	wait_for_completion(&padapter->rtl8712_fw_ready);
 	usb_set_intfdata(pusb_intf, NULL);
 	if (padapter) {
 		if (drvpriv.drv_registered == true)
author maintainer
#42 lore raw

PATCH 30/62 Fix modpost failures in fedora 17

In reply to Greg KH

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

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

From: David Miller <[email protected]>

commit e88aa7bbbe3046a125ea1936b16bb921cc9c6349 upstream.

The symbol table on x86-64 starts to have entries that have names like:

_GLOBAL__sub_I_65535_0___mod_x86cpu_device_table

They are of type STT_FUNCTION and this one had a length of 18. This matched the device ID validation logic and it barfed because the length did not meet the device type's criteria.

--------------------
FATAL: arch/x86/crypto/aesni-intel: sizeof(struct x86cpu_device_id)=16 is not a modulo of the size of section __mod_x86cpu_device_table=18. Fix definition of struct x86cpu_device_id in mod_devicetable.h
--------------------

These are some kind of compiler tool internal stuff being emitted and not something we want to inspect in modpost's device ID table validation code.

So skip the symbol if it is not of type STT_OBJECT.

---
 scripts/mod/file2alias.c |    4 ++++
 1 file changed, 4 insertions(+)
scripts/mod/file2alias.c +4 -0
@@ -1075,6 +1075,10 @@ void handle_moddevtable(struct module *m
 	if (!sym->st_shndx || get_secindex(info, sym) >= info->num_sections)
 		return;
 
+	/* We're looking for an object */
+	if (ELF_ST_TYPE(sym->st_info) != STT_OBJECT)
+		return;
+
 	/* All our symbols are of form <prefix>__mod_XXX_device_table. */
 	name = strstr(symname, "__mod_");
 	if (!name)
Acked-by Sam Ravnborg on v1 30/62
#43 lore raw

Re: [ 30/62] Fix modpost failures in fedora 17

Quoted 1 line · Greg KH

3.3-stable review patch.

[...]

Quoted 6 lines

commit e88aa7bbbe3046a125ea1936b16bb921cc9c6349 upstream.

The symbol table on x86-64 starts to have entries that have names like:

_GLOBAL__sub_I_65535_0___mod_x86cpu_device_table

[...]

Quoted 1 line

FATAL: arch/x86/crypto/aesni-intel: sizeof(struct x86cpu_device_id)=16 is not a modulo of the size of section __mod_x86cpu_device_table=18.

I haven't tested this, but I suspect 3.0.y has the same problem --- v3.3-rc1~66^2~12 ("modpost: use a table rather than a giant if/else statement") just clarified the code a little and does not seem to have gone wrong.

In other words, the conflict encountered when applying this to 3.0.y looks like a textual and not a meaningful one. Backport follows.

-- >8 --
From: David Miller <[email protected]>
Date: Thu, 12 Apr 2012 14:37:30 -0400

commit e88aa7bbbe3046a125ea1936b16bb921cc9c6349 upstream.

The symbol table on x86-64 starts to have entries that have names like:

_GLOBAL__sub_I_65535_0___mod_x86cpu_device_table

They are of type STT_FUNCTION and this one had a length of 18. This matched the device ID validation logic and it barfed because the length did not meet the device type's criteria.

--------------------
FATAL: arch/x86/crypto/aesni-intel: sizeof(struct x86cpu_device_id)=16 is not a modulo of the size of section __mod_x86cpu_device_table=18. Fix definition of struct x86cpu_device_id in mod_devicetable.h
--------------------

These are some kind of compiler tool internal stuff being emitted and not something we want to inspect in modpost's device ID table validation code.

So skip the symbol if it is not of type STT_OBJECT.

---
Thanks,
Jonathan

 scripts/mod/file2alias.c |    4 ++++
 1 file changed, 4 insertions(+)
scripts/mod/file2alias.c +4 -0
index e26e2fb462d4..f210eae9bd7e 100644
@@ -905,6 +905,10 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
 	if (!sym->st_shndx || get_secindex(info, sym) >= info->num_sections)
 		return;
 
+	/* We're looking for an object */
+	if (ELF_ST_TYPE(sym->st_info) != STT_OBJECT)
+		return;
+
 	/* Handle all-NULL symbols allocated into .bss */
 	if (info->sechdrs[get_secindex(info, sym)].sh_type & SHT_NOBITS) {
 		zeros = calloc(1, sym->st_size);
Signature · 1 line
1.7.10
maintainer
#44 lore raw

Re: [ 30/62] Fix modpost failures in fedora 17

From: Jonathan Nieder <[email protected]>
Date: Wed, 25 Apr 2012 19:41:32 -0500

Quoted 7 lines

I haven't tested this, but I suspect 3.0.y has the same problem --- v3.3-rc1~66^2~12 ("modpost: use a table rather than a giant if/else statement") just clarified the code a little and does not seem to have gone wrong.

In other words, the conflict encountered when applying this to 3.0.y looks like a textual and not a meaningful one. Backport follows.

This is %100 correct.

author maintainer
#45 lore raw

Re: [ 30/62] Fix modpost failures in fedora 17

Quoted 8 lines · David Miller

From: Jonathan Nieder <[email protected]>
Date: Wed, 25 Apr 2012 19:41:32 -0500

Quoted 5 lines

I haven't tested this, but I suspect 3.0.y has the same problem --- v3.3-rc1~66^2~12 ("modpost: use a table rather than a giant if/else statement") just clarified the code a little and does not seem to have gone wrong.

Quoted 4 lines
Quoted 2 lines

In other words, the conflict encountered when applying this to 3.0.y looks like a textual and not a meaningful one. Backport follows.

This is %100 correct.

Great, now applied.

author maintainer
#46 lore raw

PATCH 31/62 mm: fix s390 BUG by __set_page_dirty_no_writeback on swap

In reply to Greg KH

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

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

From: Hugh Dickins <[email protected]>

commit aca50bd3b4c4bb5528a1878158ba7abce41de534 upstream.

Mel reports a BUG_ON(slot == NULL) in radix_tree_tag_set() on s390 3.0.13: called from __set_page_dirty_nobuffers() when page_remove_rmap() tries to transfer dirty flag from s390 storage key to struct page and radix_tree.

That would be because of reclaim's shrink_page_list() calling add_to_swap() on this page at the same time: first PageSwapCache is set (causing page_mapping(page) to appear as &swapper_space), then page->private set, then tree_lock taken, then page inserted into radix_tree - so there's an interval before taking the lock when the radix_tree slot is empty.

We could fix this by moving __add_to_swap_cache()'s spin_lock_irq up before the SetPageSwapCache. But a better fix is simply to do what's five years overdue: Ken Chen introduced __set_page_dirty_no_writeback() (if !PageDirty TestSetPageDirty) for tmpfs to skip all the radix_tree overhead, and swap is just the same - it ignores the radix_tree tag, and does not participate in dirty page accounting, so should be using __set_page_dirty_no_writeback() too.

s390 testing now confirms that this does indeed fix the problem.

---
 mm/swap_state.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
mm/swap_state.c +1 -1
@@ -26,7 +26,7 @@
  */
 static const struct address_space_operations swap_aops = {
 	.writepage	= swap_writepage,
-	.set_page_dirty	= __set_page_dirty_nobuffers,
+	.set_page_dirty	= __set_page_dirty_no_writeback,
 	.migratepage	= migrate_page,
 };
 
author maintainer
#47 lore raw

PATCH 32/62 md: dont call ->add_disk unless there is good reason.

In reply to Greg KH

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

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

From: NeilBrown <[email protected]>

commit ed209584c38fb74b7eecc03e5b1bfe674e591bd8 upstream.

Commit 7bfec5f35c68121e7b18

md/raid5: If there is a spare and a want_replacement device, start replacement.

cause md_check_recovery to call ->add_disk much more often. Instead of only when the array is degraded, it is now called whenever md_check_recovery finds anything useful to do, which includes updating the metadata for clean<->dirty transition.
This causes unnecessary work, and causes info messages from ->add_disk to be reported much too often.

So refine md_check_recovery to only do any actual recovery checking (including ->add_disk) if MD_RECOVERY_NEEDED is set.

This fix is suitable for 3.3.y:

---
 drivers/md/md.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/md/md.c +2 -2
@@ -7580,14 +7580,14 @@ void md_check_recovery(struct mddev *mdd
 		 * any transients in the value of "sync_action".
 		 */
 		set_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
-		clear_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
 		/* Clear some bits that don't mean anything, but
 		 * might be left set
 		 */
 		clear_bit(MD_RECOVERY_INTR, &mddev->recovery);
 		clear_bit(MD_RECOVERY_DONE, &mddev->recovery);
 
-		if (test_bit(MD_RECOVERY_FROZEN, &mddev->recovery))
+		if (!test_and_clear_bit(MD_RECOVERY_NEEDED, &mddev->recovery) ||
+		    test_bit(MD_RECOVERY_FROZEN, &mddev->recovery))
 			goto unlock;
 		/* no recovery is running.
 		 * remove any failed drives, then
author maintainer
#48 lore raw

PATCH 33/62 md: fix possible corruption of array metadata on shutdown.

In reply to Greg KH

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

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

From: NeilBrown <[email protected]>

commit 30b8aa9172dfeaac6d77897c67ee9f9fc574cdbb upstream.

commit c744a65c1e2d59acc54333ce8
md: don't set md arrays to readonly on shutdown.

removed the possibility of a 'BUG' when data is written to an array that has just been switched to read-only, but also introduced the possibility that the array metadata could be corrupted.

If, when md_notify_reboot gets the mddev lock, the array is in a state where it is assembled but hasn't been started (as can happen if the personality module is not available, or in other unusual situations), then incorrect metadata will be written out making it impossible to re-assemble the array.

So only call __md_stop_writes() if the array has actually been activated.

This patch is needed for any stable kernel which has had the above commit applied.

---
 drivers/md/md.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/md/md.c +2 -1
@@ -8160,7 +8160,8 @@ static int md_notify_reboot(struct notif
 
 	for_each_mddev(mddev, tmp) {
 		if (mddev_trylock(mddev)) {
-			__md_stop_writes(mddev);
+			if (mddev->pers)
+				__md_stop_writes(mddev);
 			mddev->safemode = 2;
 			mddev_unlock(mddev);
 		}
author maintainer
#49 lore raw

PATCH 34/62 jbd2: use GFP_NOFS for blkdev_issue_flush

In reply to Greg KH

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

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

From: Shaohua Li <[email protected]>

commit 99aa78466777083255b876293e9e83dec7cd809a upstream.

flush request is issued in transaction commit code path, so looks using GFP_KERNEL to allocate memory for flush request bio falls into the classic deadlock issue. I saw btrfs and dm get it right, but ext4, xfs and md are using GFP.

---
 fs/jbd2/commit.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
fs/jbd2/commit.c +2 -2
@@ -689,7 +689,7 @@ start_journal_io:
 	if (commit_transaction->t_need_data_flush &&
 	    (journal->j_fs_dev != journal->j_dev) &&
 	    (journal->j_flags & JBD2_BARRIER))
-		blkdev_issue_flush(journal->j_fs_dev, GFP_KERNEL, NULL);
+		blkdev_issue_flush(journal->j_fs_dev, GFP_NOFS, NULL);
 
 	/* Done it all: now write the commit record asynchronously. */
 	if (JBD2_HAS_INCOMPAT_FEATURE(journal,
@@ -825,7 +825,7 @@ wait_for_iobuf:
 	if (JBD2_HAS_INCOMPAT_FEATURE(journal,
 				      JBD2_FEATURE_INCOMPAT_ASYNC_COMMIT) &&
 	    journal->j_flags & JBD2_BARRIER) {
-		blkdev_issue_flush(journal->j_dev, GFP_KERNEL, NULL);
+		blkdev_issue_flush(journal->j_dev, GFP_NOFS, NULL);
 	}
 
 	if (err)
author maintainer
#50 lore raw

PATCH 35/62 USB: serial: cp210x: Fixed usb_control_msg timeout values

In reply to Greg KH

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

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

From: Yuri Matylitski <[email protected]>

commit 2d5733fcd33dd451022d197cb6b476e970519ca7 upstream.

Fixed too small hardcoded timeout values for usb_control_msg in driver for SiliconLabs cp210x-based usb-to-serial adapters. Replaced with USB_CTRL_GET_TIMEOUT/USB_CTRL_SET_TIMEOUT.

---
 drivers/usb/serial/cp210x.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/usb/serial/cp210x.c +6 -3
@@ -285,7 +285,8 @@ static int cp210x_get_config(struct usb_
 	/* Issue the request, attempting to read 'size' bytes */
 	result = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
 				request, REQTYPE_DEVICE_TO_HOST, 0x0000,
-				port_priv->bInterfaceNumber, buf, size, 300);
+				port_priv->bInterfaceNumber, buf, size,
+				USB_CTRL_GET_TIMEOUT);
 
 	/* Convert data into an array of integers */
 	for (i = 0; i < length; i++)
@@ -338,12 +339,14 @@ static int cp210x_set_config(struct usb_
 		result = usb_control_msg(serial->dev,
 				usb_sndctrlpipe(serial->dev, 0),
 				request, REQTYPE_HOST_TO_DEVICE, 0x0000,
-				port_priv->bInterfaceNumber, buf, size, 300);
+				port_priv->bInterfaceNumber, buf, size,
+				USB_CTRL_SET_TIMEOUT);
 	} else {
 		result = usb_control_msg(serial->dev,
 				usb_sndctrlpipe(serial->dev, 0),
 				request, REQTYPE_HOST_TO_DEVICE, data[0],
-				port_priv->bInterfaceNumber, NULL, 0, 300);
+				port_priv->bInterfaceNumber, NULL, 0,
+				USB_CTRL_SET_TIMEOUT);
 	}
 
 	kfree(buf);
author maintainer
#51 lore raw

PATCH 36/62 pch_uart: Fix dma channel unallocated issue

In reply to Greg KH

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

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

From: Tomoya MORINAGA <[email protected]>

commit af6d17cdc8c89aeb3101f0d27cd32fc0592b40b2 upstream.

This driver anticipates pch_uart_verify_port() is not called during installation.
However, actually pch_uart_verify_port() is called during installation.
As a result, memory access violation occurs like below.

0. initial value: use_dma=0
1. starup()
- dma channel is not allocated because use_dma=0
2. pch_uart_verify_port()
- Set use_dma=1
3. UART processing acts DMA mode because use_dma=1
- memory access violation occurs!

This patch fixes the issue.

Solution:
Whenever pch_uart_verify_port() is called and then dma channel is not allocated, the channel should be allocated.

---
 drivers/tty/serial/pch_uart.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/tty/serial/pch_uart.c +3 -1
@@ -1366,9 +1366,11 @@ static int pch_uart_verify_port(struct u
 			__func__);
 		return -EOPNOTSUPP;
 #endif
-		priv->use_dma = 1;
 		priv->use_dma_flag = 1;
 		dev_info(priv->port.dev, "PCH UART : Use DMA Mode\n");
+		if (!priv->use_dma)
+			pch_request_dma(port);
+		priv->use_dma = 1;
 	}
 
 	return 0;
author maintainer
#52 lore raw

PATCH 37/62 drivers/tty/amiserial.c: add missing tty_unlock

In reply to Greg KH

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

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

From: Julia Lawall <[email protected]>

commit d3a7b83f865b46bb7b5e1ed18a129ce1af349db4 upstream.

tty_unlock is used on all other exits from the function.

---
 drivers/tty/amiserial.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/tty/amiserial.c +3 -1
@@ -1113,8 +1113,10 @@ static int set_serial_info(struct async_
 		    (new_serial.close_delay != state->close_delay) ||
 		    (new_serial.xmit_fifo_size != state->xmit_fifo_size) ||
 		    ((new_serial.flags & ~ASYNC_USR_MASK) !=
-		     (state->flags & ~ASYNC_USR_MASK)))
+		     (state->flags & ~ASYNC_USR_MASK))) {
+			tty_unlock();
 			return -EPERM;
+		}
 		state->flags = ((state->flags & ~ASYNC_USR_MASK) |
 			       (new_serial.flags & ASYNC_USR_MASK));
 		info->flags = ((info->flags & ~ASYNC_USR_MASK) |
author maintainer
#53 lore raw

PATCH 38/62 USB: sierra: avoid QMI/wwan interface on MC77xx

In reply to Greg KH

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

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

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

commit 749541d19e70905e3971f2a08335a206a98e4d0c upstream.

These devices have a number of non serial interfaces as well. Use the existing "Direct IP" blacklist to prevent binding to interfaces which are handled by other drivers.

We also extend the "Direct IP" blacklist with with interfaces only seen in "QMI" mode, assuming that these devices use the same interface numbers for serial interfaces both in "Direct IP" and in "QMI" mode.

---
 drivers/usb/serial/sierra.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/usb/serial/sierra.c +4 -2
@@ -221,7 +221,7 @@ static const struct sierra_iface_info ty
 };
 
 /* 'blacklist' of interfaces not served by this driver */
-static const u8 direct_ip_non_serial_ifaces[] = { 7, 8, 9, 10, 11 };
+static const u8 direct_ip_non_serial_ifaces[] = { 7, 8, 9, 10, 11, 19, 20 };
 static const struct sierra_iface_info direct_ip_interface_blacklist = {
 	.infolen = ARRAY_SIZE(direct_ip_non_serial_ifaces),
 	.ifaceinfo = direct_ip_non_serial_ifaces,
@@ -289,7 +289,6 @@ static const struct usb_device_id id_tab
 	{ USB_DEVICE(0x1199, 0x6856) },	/* Sierra Wireless AirCard 881 U */
 	{ USB_DEVICE(0x1199, 0x6859) },	/* Sierra Wireless AirCard 885 E */
 	{ USB_DEVICE(0x1199, 0x685A) },	/* Sierra Wireless AirCard 885 E */
-	{ USB_DEVICE(0x1199, 0x68A2) }, /* Sierra Wireless MC7710 */
 	/* Sierra Wireless C885 */
 	{ USB_DEVICE_AND_INTERFACE_INFO(0x1199, 0x6880, 0xFF, 0xFF, 0xFF)},
 	/* Sierra Wireless C888, Air Card 501, USB 303, USB 304 */
@@ -299,6 +298,9 @@ static const struct usb_device_id id_tab
 	/* Sierra Wireless HSPA Non-Composite Device */
 	{ USB_DEVICE_AND_INTERFACE_INFO(0x1199, 0x6892, 0xFF, 0xFF, 0xFF)},
 	{ USB_DEVICE(0x1199, 0x6893) },	/* Sierra Wireless Device */
+	{ USB_DEVICE(0x1199, 0x68A2),   /* Sierra Wireless MC77xx in QMI mode */
+	  .driver_info = (kernel_ulong_t)&direct_ip_interface_blacklist
+	},
 	{ USB_DEVICE(0x1199, 0x68A3), 	/* Sierra Wireless Direct IP modems */
 	  .driver_info = (kernel_ulong_t)&direct_ip_interface_blacklist
 	},
author maintainer
#54 lore raw

PATCH 39/62 EHCI: fix criterion for resuming the root hub

In reply to Greg KH

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

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

From: Alan Stern <[email protected]>

commit dc75ce9d929aabeb0843a6b1a4ab320e58ba1597 upstream.

This patch (as1542) changes the criterion ehci-hcd uses to tell when it needs to resume the controller's root hub. A resume is needed when a port status change is detected, obviously, but only if the root hub is currently suspended.

Right now the driver tests whether the root hub is running, and that is not the correct test. In particular, if the controller has died then the root hub should not be restarted. In addition, some buggy hardware occasionally requires the root hub to be running and sending out SOF packets even while it is nominally supposed to be suspended.

In the end, the test needs to be changed. Rather than checking whether the root hub is currently running, the driver will now check whether the root hub is currently suspended. This will yield the correct behavior in all cases.

---
 drivers/usb/host/ehci-hcd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/ehci-hcd.c +1 -1
@@ -909,7 +909,7 @@ static irqreturn_t ehci_irq (struct usb_
 		pcd_status = status;
 
 		/* resume root hub? */
-		if (!(cmd & CMD_RUN))
+		if (ehci->rh_state == EHCI_RH_SUSPENDED)
 			usb_hcd_resume_root_hub(hcd);
 
 		/* get per-port change detect bits */
#55 lore raw

Re: [ 39/62] EHCI: fix criterion for resuming the root hub

Hi Greg,

Quoted 1 line · Greg KH

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

[...]

Quoted 6 lines

commit dc75ce9d929aabeb0843a6b1a4ab320e58ba1597 upstream.

This patch (as1542) changes the criterion ehci-hcd uses to tell when it needs to resume the controller's root hub. A resume is needed when a port status change is detected, obviously, but only if the root hub is currently suspended.

Here's a blind backport to 3.0-stable (for next week, perhaps) that accounts for the lack of v3.2-rc1~183^2~179^2~19 ("USB: EHCI: remove usages of hcd->state", 2011-08-18).

Thanks,
Jonathan

-- >8 --
From: Alan Stern <[email protected]>
Date: Tue, 17 Apr 2012 15:24:15 -0400

commit dc75ce9d929aabeb0843a6b1a4ab320e58ba1597 upstream.

This patch (as1542) changes the criterion ehci-hcd uses to tell when it needs to resume the controller's root hub. A resume is needed when a port status change is detected, obviously, but only if the root hub is currently suspended.

Right now the driver tests whether the root hub is running, and that is not the correct test. In particular, if the controller has died then the root hub should not be restarted. In addition, some buggy hardware occasionally requires the root hub to be running and sending out SOF packets even while it is nominally supposed to be suspended.

In the end, the test needs to be changed. Rather than checking whether the root hub is currently running, the driver will now check whether the root hub is currently suspended. This will yield the correct behavior in all cases.

---
 drivers/usb/host/ehci-hcd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/ehci-hcd.c +1 -1
index b27ceab17743..6144c804cf10 100644
@@ -860,7 +860,7 @@ static irqreturn_t ehci_irq (struct usb_hcd *hcd)
 		pcd_status = status;
 
 		/* resume root hub? */
-		if (!(cmd & CMD_RUN))
+		if (hcd->state == HC_STATE_SUSPENDED)
 			usb_hcd_resume_root_hub(hcd);
 
 		/* get per-port change detect bits */
Signature · 1 line
1.7.10
author maintainer Applied
#56 lore raw

Re: [ 39/62] EHCI: fix criterion for resuming the root hub

Quoted 8 lines · Jonathan Nieder

Hi Greg,

Quoted 1 line · Greg KH

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

[...]

Quoted 2 lines

commit dc75ce9d929aabeb0843a6b1a4ab320e58ba1597 upstream.

Quoted 8 lines
Quoted 4 lines

This patch (as1542) changes the criterion ehci-hcd uses to tell when it needs to resume the controller's root hub. A resume is needed when a port status change is detected, obviously, but only if the root hub is currently suspended.

Here's a blind backport to 3.0-stable (for next week, perhaps) that accounts for the lack of v3.2-rc1~183^2~179^2~19 ("USB: EHCI: remove usages of hcd->state", 2011-08-18).

Applied, thanks.

author maintainer
#57 lore raw

PATCH 40/62 EHCI: always clear the STS_FLR status bit

In reply to Greg KH

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

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

From: Alan Stern <[email protected]>

commit 2fbe2bf1fd37f9d99950bd8d8093623cf22cf08b upstream.

This patch (as1544) fixes a problem affecting some EHCI controllers. They can generate interrupts whenever the STS_FLR status bit is turned on, even though that bit is masked out in the Interrupt Enable register.

Since the driver doesn't use STS_FLR anyway, the patch changes the interrupt routine to clear that bit whenever it is set, rather than leaving it alone.

---
 drivers/usb/host/ehci-hcd.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/usb/host/ehci-hcd.c +6 -1
@@ -857,8 +857,13 @@ static irqreturn_t ehci_irq (struct usb_
 		goto dead;
 	}
 
+	/*
+	 * We don't use STS_FLR, but some controllers don't like it to
+	 * remain on, so mask it out along with the other status bits.
+	 */
+	masked_status = status & (INTR_MASK | STS_FLR);
+
 	/* Shared IRQ? */
-	masked_status = status & INTR_MASK;
 	if (!masked_status || unlikely(ehci->rh_state == EHCI_RH_HALTED)) {
 		spin_unlock(&ehci->lock);
 		return IRQ_NONE;
author maintainer
#58 lore raw

PATCH 41/62 USB: fix deadlock in bConfigurationValue attribute method

In reply to Greg KH

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

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

From: Alan Stern <[email protected]>

commit 8963c487a80b4688c9e68dcc504a90074aacc145 upstream.

This patch (as154) fixes a self-deadlock that occurs when userspace writes to the bConfigurationValue sysfs attribute for a hub with children. The task tries to lock the bandwidth_mutex at a time when it already owns the lock:

The attribute's method calls usb_set_configuration(), which calls usb_disable_device() with the bandwidth_mutex held.

usb_disable_device() unregisters the existing interfaces, which causes the hub driver to be unbound.

The hub_disconnect() routine calls hub_quiesce(), which calls usb_disconnect() for each of the hub's children.

usb_disconnect() attempts to acquire the bandwidth_mutex around a call to usb_disable_device().

The solution is to make usb_disable_device() acquire the mutex for itself instead of requiring the caller to hold it. Then the mutex can cover only the bandwidth deallocation operation and not the region where the interfaces are unregistered.

This has the potential to change system behavior slightly when a config change races with another config or altsetting change. Some of the bandwidth released from the old config might get claimed by the other config or altsetting, make it impossible to restore the old config in case of a failure. But since we don't try to recover from config-change failures anyway, this doesn't matter.

[This should be marked for stable kernels that contain the commit fccf4e86200b8f5edd9a65da26f150e32ba79808 "USB: Free bandwidth when usb_disable_device is called."
That commit was marked for stable kernels as old as 2.6.32.]

---
 drivers/usb/core/hub.c     |    3 ---
 drivers/usb/core/message.c |    6 +++---
 2 files changed, 3 insertions(+), 6 deletions(-)
drivers/usb/core/hub.c +0 -3
@@ -1643,7 +1643,6 @@ void usb_disconnect(struct usb_device **
 {
 	struct usb_device	*udev = *pdev;
 	int			i;
-	struct usb_hcd		*hcd = bus_to_hcd(udev->bus);
 
 	/* mark the device as inactive, so any further urb submissions for
 	 * this device (and any of its children) will fail immediately.
@@ -1666,9 +1665,7 @@ void usb_disconnect(struct usb_device **
 	 * so that the hardware is now fully quiesced.
 	 */
 	dev_dbg (&udev->dev, "unregistering device\n");
-	mutex_lock(hcd->bandwidth_mutex);
 	usb_disable_device(udev, 0);
-	mutex_unlock(hcd->bandwidth_mutex);
 	usb_hcd_synchronize_unlinks(udev);
 
 	usb_remove_ep_devs(&udev->ep0);
drivers/usb/core/message.c +3 -3
@@ -1136,8 +1136,6 @@ void usb_disable_interface(struct usb_de
  * Deallocates hcd/hardware state for the endpoints (nuking all or most
  * pending urbs) and usbcore state for the interfaces, so that usbcore
  * must usb_set_configuration() before any interfaces could be used.
- *
- * Must be called with hcd->bandwidth_mutex held.
  */
 void usb_disable_device(struct usb_device *dev, int skip_ep0)
 {
@@ -1190,7 +1188,9 @@ void usb_disable_device(struct usb_devic
 			usb_disable_endpoint(dev, i + USB_DIR_IN, false);
 		}
 		/* Remove endpoints from the host controller internal state */
+		mutex_lock(hcd->bandwidth_mutex);
 		usb_hcd_alloc_bandwidth(dev, NULL, NULL, NULL);
+		mutex_unlock(hcd->bandwidth_mutex);
 		/* Second pass: remove endpoint pointers */
 	}
 	for (i = skip_ep0; i < 16; ++i) {
@@ -1750,7 +1750,6 @@ free_interfaces:
 	/* if it's already configured, clear out old state first.
 	 * getting rid of old interfaces means unbinding their drivers.
 	 */
-	mutex_lock(hcd->bandwidth_mutex);
 	if (dev->state != USB_STATE_ADDRESS)
 		usb_disable_device(dev, 1);	/* Skip ep0 */
 
@@ -1763,6 +1762,7 @@ free_interfaces:
 	 * host controller will not allow submissions to dropped endpoints.  If
 	 * this call fails, the device state is unchanged.
 	 */
+	mutex_lock(hcd->bandwidth_mutex);
 	ret = usb_hcd_alloc_bandwidth(dev, cp, NULL, NULL);
 	if (ret < 0) {
 		mutex_unlock(hcd->bandwidth_mutex);
author maintainer
#59 lore raw

PATCH 42/62 usb: gadget: udc-core: stop UDC on device-initiated disconnect

In reply to Greg KH

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

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

From: Felipe Balbi <[email protected]>

commit 6d258a4c42089229b855fd706622029decf316d6 upstream.

When we want to do device-initiated disconnect, let's make sure we stop the UDC in order to e.g. allow lower power states to be achieved by turning off unnecessary clocks and/or stoping PHYs.

When reconnecting, call ->udc_start() again to make sure UDC is reinitialized.

---
 drivers/usb/gadget/udc-core.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/usb/gadget/udc-core.c +4 -0
@@ -359,8 +359,12 @@ static ssize_t usb_udc_softconn_store(st
 	struct usb_udc		*udc = container_of(dev, struct usb_udc, dev);
 
 	if (sysfs_streq(buf, "connect")) {
+		if (udc_is_newstyle(udc))
+			usb_gadget_udc_start(udc->gadget, udc->driver);
 		usb_gadget_connect(udc->gadget);
 	} else if (sysfs_streq(buf, "disconnect")) {
+		if (udc_is_newstyle(udc))
+			usb_gadget_udc_stop(udc->gadget, udc->driver);
 		usb_gadget_disconnect(udc->gadget);
 	} else {
 		dev_err(dev, "unsupported command '%s'\n", buf);
author maintainer
#60 lore raw

PATCH 43/62 usb: gadget: udc-core: fix asymmetric calls in remove_driver

In reply to Greg KH

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

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

From: Kishon Vijay Abraham I <[email protected]>

commit 8ae8090c82eb407267001f75b3d256b3bd4ae691 upstream.

During modprobe of gadget driver, pullup is called after udc_start. In order to make the exit path symmetric when removing a gadget driver, call pullup before ->udc_stop.

This is needed to avoid issues with PM where udc_stop disables the module completely (put IP in reset state, cut functional and interface clocks, and so on), which prevents us from accessing the IP's address space, thus creating the possibility of an abort exception when we try to access IP's address space after clocks are off.

---
 drivers/usb/gadget/udc-core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/udc-core.c +1 -1
@@ -212,8 +212,8 @@ static void usb_gadget_remove_driver(str
 	if (udc_is_newstyle(udc)) {
 		udc->driver->disconnect(udc->gadget);
 		udc->driver->unbind(udc->gadget);
-		usb_gadget_udc_stop(udc->gadget, udc->driver);
 		usb_gadget_disconnect(udc->gadget);
+		usb_gadget_udc_stop(udc->gadget, udc->driver);
 	} else {
 		usb_gadget_stop(udc->gadget, udc->driver);
 	}
#61 lore raw

Re: [ 43/62] usb: gadget: udc-core: fix asymmetric calls in remove_driver

Quoted 11 lines · Greg KH

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

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

From: Kishon Vijay Abraham I <[email protected]>

commit 8ae8090c82eb407267001f75b3d256b3bd4ae691 upstream.

During modprobe of gadget driver, pullup is called after udc_start. In order to make the exit path symmetric when removing a gadget driver, call pullup before ->udc_stop.

[...]

It looks like commit 6d258a4c42089229b855fd706622029decf316d6 (previous patch in this series!) added another case where the cleanup functions are called in the wrong order.

Ben.

Signature · 3 lines
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus
author maintainer
#62 lore raw

Re: [ 43/62] usb: gadget: udc-core: fix asymmetric calls in remove_driver

Quoted 9 lines · Ben Hutchings
Quoted 8 lines · Greg KH

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

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

From: Kishon Vijay Abraham I <[email protected]>

commit 8ae8090c82eb407267001f75b3d256b3bd4ae691 upstream.

Quoted 8 lines
Quoted 3 lines

During modprobe of gadget driver, pullup is called after udc_start. In order to make the exit path symmetric when removing a gadget driver, call pullup before ->udc_stop.

[...]

It looks like commit 6d258a4c42089229b855fd706622029decf316d6 (previous patch in this series!) added another case where the cleanup functions are called in the wrong order.

Felipe? Any thoughts?

#63 lore raw

Re: [ 43/62] usb: gadget: udc-core: fix asymmetric calls in remove_driver

Quoted 13 lines · Greg KH
Quoted 12 lines · Ben Hutchings
Quoted 11 lines · Greg KH

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

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

From: Kishon Vijay Abraham I <[email protected]>

commit 8ae8090c82eb407267001f75b3d256b3bd4ae691 upstream.

During modprobe of gadget driver, pullup is called after udc_start. In order to make the exit path symmetric when removing a gadget driver, call pullup before ->udc_stop.

Quoted 7 lines
Quoted 5 lines

[...]

It looks like commit 6d258a4c42089229b855fd706622029decf316d6 (previous patch in this series!) added another case where the cleanup functions are called in the wrong order.

Felipe? Any thoughts?

oops, indeed. Will send a fix ASAP. Thanks for spotting that one.

Signature · 1 line
balbi
author maintainer
#64 lore raw

PATCH 44/62 usb: gadget: eliminate NULL pointer dereference (bugfix)

In reply to Greg KH

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

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

From: Andrzej Pietrasiewicz <[email protected]>

commit 92b0abf80c5c5f0e0d71d1309688a330fd74731b upstream.

usb: gadget: eliminate NULL pointer dereference (bugfix)

This patch fixes a bug which causes NULL pointer dereference in ffs_ep0_ioctl. The bug happens when the FunctionFS is not bound (either has not been bound yet or has been bound and then unbound) and can be reproduced with running the following commands:

$ insmod g_ffs.ko
$ mount -t functionfs func /dev/usbgadget
$ ./null

where null.c is:

#include <fcntl.h>
#include <linux/usb/functionfs.h>

int main(void)

{
	int fd = open("/dev/usbgadget/ep0", O_RDWR);
	ioctl(fd, FUNCTIONFS_CLEAR_HALT);

	return 0;
}
---
 drivers/usb/gadget/f_fs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/f_fs.c +1 -1
@@ -712,7 +712,7 @@ static long ffs_ep0_ioctl(struct file *f
 	if (code == FUNCTIONFS_INTERFACE_REVMAP) {
 		struct ffs_function *func = ffs->func;
 		ret = func ? ffs_func_revmap_intf(func, value) : -ENODEV;
-	} else if (gadget->ops->ioctl) {
+	} else if (gadget && gadget->ops->ioctl) {
 		ret = gadget->ops->ioctl(gadget, code, value);
 	} else {
 		ret = -ENOTTY;
author maintainer
#65 lore raw

PATCH 45/62 usb: musb: omap: fix crash when musb glue (omap) gets initialized

In reply to Greg KH

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

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

From: Kishon Vijay Abraham I <[email protected]>

commit 3006dc8c627d738693e910c159630e4368c9e86c upstream.

pm_runtime_enable is being called after omap2430_musb_init. Hence pm_runtime_get_sync in omap2430_musb_init does not have any effect (does not enable clocks) resulting in a crash during register access. It is fixed here.

---
 drivers/usb/musb/omap2430.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/musb/omap2430.c +2 -2
@@ -451,14 +451,14 @@ static int __init omap2430_probe(struct
 		goto err2;
 	}
 
+	pm_runtime_enable(&pdev->dev);
+
 	ret = platform_device_add(musb);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to register musb device\n");
 		goto err2;
 	}
 
-	pm_runtime_enable(&pdev->dev);
-
 	return 0;
 
 err2:
#66 lore raw

Re: [ 45/62] usb: musb: omap: fix crash when musb glue (omap) gets initialized

Quoted 24 lines · Greg KH

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

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

From: Kishon Vijay Abraham I <[email protected]>

commit 3006dc8c627d738693e910c159630e4368c9e86c upstream.

pm_runtime_enable is being called after omap2430_musb_init. Hence pm_runtime_get_sync in omap2430_musb_init does not have any effect (does not enable clocks) resulting in a crash during register access. It is fixed here.

---
 drivers/usb/musb/omap2430.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/usb/musb/omap2430.c static int __init omap2430_probe(struct · line 458

Quoted 8 lines
drivers/usb/musb/omap2430.c +2 -0
@@ -451,14 +451,14 @@ static int __init omap2430_probe(struct
 		goto err2;
 	}
 
+	pm_runtime_enable(&pdev->dev);
+
 	ret = platform_device_add(musb);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to register musb device\n");

This failure path now needs a call to pm_runtime_disable().

Ben.

Quoted 8 lines
drivers/usb/musb/omap2430.c +0 -2
 		goto err2;
 	}
 
-	pm_runtime_enable(&pdev->dev);
-
 	return 0;
 
 err2:
Signature · 3 lines
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus
author maintainer
#67 lore raw

PATCH 46/62 usb: musb: omap: fix the error check for pm_runtime_get_sync

In reply to Greg KH

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

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

From: Shubhrajyoti D <[email protected]>

commit ad579699c4f0274bf522a9252ff9b20c72197e48 upstream.

pm_runtime_get_sync returns a signed integer. In case of errors it returns a negative value. This patch fixes the error check by making it signed instead of unsigned thus preventing register access if get_sync_fails. Also passes the error cause to the debug message.

---
 drivers/usb/musb/omap2430.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/usb/musb/omap2430.c +3 -2
@@ -281,7 +281,8 @@ static void musb_otg_notifier_work(struc
 
 static int omap2430_musb_init(struct musb *musb)
 {
-	u32 l, status = 0;
+	u32 l;
+	int status = 0;
 	struct device *dev = musb->controller;
 	struct musb_hdrc_platform_data *plat = dev->platform_data;
 	struct omap_musb_board_data *data = plat->board_data;
@@ -300,7 +301,7 @@ static int omap2430_musb_init(struct mus
 
 	status = pm_runtime_get_sync(dev);
 	if (status < 0) {
-		dev_err(dev, "pm_runtime_get_sync FAILED");
+		dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
 		goto err1;
 	}
 
author maintainer
#68 lore raw

PATCH 47/62 PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUs

In reply to Greg KH

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

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

From: Thomas Jarosch <[email protected]>

commit f67fd55fa96f7d7295b43ffbc4a97d8f55e473aa upstream.

Some BIOS implementations leave the Intel GPU interrupts enabled, even though no one is handling them (f.e. i915 driver is never loaded). Additionally the interrupt destination is not set up properly and the interrupt ends up -somewhere-.

These spurious interrupts are "sticky" and the kernel disables the (shared) interrupt line after 100.000+ generated interrupts.

Fix it by disabling the still enabled interrupts. This resolves crashes often seen on monitor unplug.

Tested on the following boards:
- Intel DH61CR: Affected
- Intel DH67BL: Affected
- Intel S1200KP server board: Affected
- Asus P8H61-M LE: Affected, but system does not crash. Probably the IRQ ends up somewhere unnoticed.

According to reports on the net, the Intel DH61WW board is also affected.

Many thanks to Jesse Barnes from Intel for helping with the register configuration and to Intel in general for providing public hardware documentation.

---
 drivers/pci/quirks.c |   34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)
drivers/pci/quirks.c +34 -0
@@ -2906,6 +2906,40 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_I
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x65f9, quirk_intel_mc_errata);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x65fa, quirk_intel_mc_errata);
 
+/*
+ * Some BIOS implementations leave the Intel GPU interrupts enabled,
+ * even though no one is handling them (f.e. i915 driver is never loaded).
+ * Additionally the interrupt destination is not set up properly
+ * and the interrupt ends up -somewhere-.
+ *
+ * These spurious interrupts are "sticky" and the kernel disables
+ * the (shared) interrupt line after 100.000+ generated interrupts.
+ *
+ * Fix it by disabling the still enabled interrupts.
+ * This resolves crashes often seen on monitor unplug.
+ */
+#define I915_DEIER_REG 0x4400c
+static void __devinit disable_igfx_irq(struct pci_dev *dev)
+{
+	void __iomem *regs = pci_iomap(dev, 0, 0);
+	if (regs == NULL) {
+		dev_warn(&dev->dev, "igfx quirk: Can't iomap PCI device\n");
+		return;
+	}
+
+	/* Check if any interrupt line is still enabled */
+	if (readl(regs + I915_DEIER_REG) != 0) {
+		dev_warn(&dev->dev, "BIOS left Intel GPU interrupts enabled; "
+			"disabling\n");
+
+		writel(0, regs + I915_DEIER_REG);
+	}
+
+	pci_iounmap(dev, regs);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
+
 static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
 			  struct pci_fixup *end)
 {
author maintainer
#69 lore raw

PATCH 48/62 ext4: fix endianness breakage in ext4_split_extent_at()

In reply to Greg KH

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

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

From: Al Viro <[email protected]>

commit af1584f570b19b0285e4402a0b54731495d31784 upstream.

->ee_len is __le16, so assigning cpu_to_le32() to it is going to do Bad Things(tm) on big-endian hosts...

---
 fs/ext4/extents.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ext4/extents.c +1 -1
@@ -2811,7 +2811,7 @@ static int ext4_split_extent_at(handle_t
 		if (err)
 			goto fix_extent_len;
 		/* update the extent length and mark as initialized */
-		ex->ee_len = cpu_to_le32(ee_len);
+		ex->ee_len = cpu_to_le16(ee_len);
 		ext4_ext_try_to_merge(inode, path, ex);
 		err = ext4_ext_dirty(handle, inode, path + depth);
 		goto out;
author maintainer
#70 lore raw

PATCH 49/62 KVM: unmap pages from the iommu when slots are removed

In reply to Greg KH

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

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

From: Alex Williamson <[email protected]>

commit 32f6daad4651a748a58a3ab6da0611862175722f upstream.

We've been adding new mappings, but not destroying old mappings. This can lead to a page leak as pages are pinned using get_user_pages, but only unpinned with put_page if they still exist in the memslots list on vm shutdown. A memslot that is destroyed while an iommu domain is enabled for the guest will therefore result in an elevated page reference count that is never cleared.

Additionally, without this fix, the iommu is only programmed with the first translation for a gpa. This can result in peer-to-peer errors if a mapping is destroyed and replaced by a new mapping at the same gpa as the iommu will still be pointing to the original, pinned memory address.

---
 include/linux/kvm_host.h |    6 ++++++
 virt/kvm/iommu.c         |    7 ++++++-
 virt/kvm/kvm_main.c      |    5 +++--
 3 files changed, 15 insertions(+), 3 deletions(-)
include/linux/kvm_host.h +6 -0
@@ -593,6 +593,7 @@ void kvm_free_irq_source_id(struct kvm *
 
 #ifdef CONFIG_IOMMU_API
 int kvm_iommu_map_pages(struct kvm *kvm, struct kvm_memory_slot *slot);
+void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot);
 int kvm_iommu_map_guest(struct kvm *kvm);
 int kvm_iommu_unmap_guest(struct kvm *kvm);
 int kvm_assign_device(struct kvm *kvm,
@@ -606,6 +607,11 @@ static inline int kvm_iommu_map_pages(st
 	return 0;
 }
 
+static inline void kvm_iommu_unmap_pages(struct kvm *kvm,
+					 struct kvm_memory_slot *slot)
+{
+}
+
 static inline int kvm_iommu_map_guest(struct kvm *kvm)
 {
 	return -ENODEV;
virt/kvm/iommu.c +6 -1
@@ -310,6 +310,11 @@ static void kvm_iommu_put_pages(struct k
 	}
 }
 
+void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot)
+{
+	kvm_iommu_put_pages(kvm, slot->base_gfn, slot->npages);
+}
+
 static int kvm_iommu_unmap_memslots(struct kvm *kvm)
 {
 	int idx;
@@ -320,7 +325,7 @@ static int kvm_iommu_unmap_memslots(stru
 	slots = kvm_memslots(kvm);
 
 	kvm_for_each_memslot(memslot, slots)
-		kvm_iommu_put_pages(kvm, memslot->base_gfn, memslot->npages);
+		kvm_iommu_unmap_pages(kvm, memslot);
 
 	srcu_read_unlock(&kvm->srcu, idx);
 
virt/kvm/kvm_main.c +3 -2
@@ -873,12 +873,13 @@ skip_lpage:
 	if (r)
 		goto out_free;
 
-	/* map the pages in iommu page table */
+	/* map/unmap the pages in iommu page table */
 	if (npages) {
 		r = kvm_iommu_map_pages(kvm, &new);
 		if (r)
 			goto out_free;
-	}
+	} else
+		kvm_iommu_unmap_pages(kvm, &old);
 
 	r = -ENOMEM;
 	slots = kmemdup(kvm->memslots, sizeof(struct kvm_memslots),
#71 lore raw

Re: [ 49/62] KVM: unmap pages from the iommu when slots are removed

Hi,

Quoted 1 line · Greg KH

3.3-stable review patch.

[...]

Quoted 4 lines

commit 32f6daad4651a748a58a3ab6da0611862175722f upstream.

We've been adding new mappings, but not destroying old mappings. This can lead to a page leak

Does 3.0.y need this? The patch does not apply as is to 3.0.y because the latter lacks v3.3-rc1~131^2~41 ("KVM: introduce kvm_for_each_memslot macro"), but a backport is straightforward.

Completely untested. Test results and other comments welcome.

-- >8 --
From: Alex Williamson <[email protected]>
Date: Wed, 11 Apr 2012 09:51:49 -0600

commit 32f6daad4651a748a58a3ab6da0611862175722f upstream.

We've been adding new mappings, but not destroying old mappings. This can lead to a page leak as pages are pinned using get_user_pages, but only unpinned with put_page if they still exist in the memslots list on vm shutdown. A memslot that is destroyed while an iommu domain is enabled for the guest will therefore result in an elevated page reference count that is never cleared.

Additionally, without this fix, the iommu is only programmed with the first translation for a gpa. This can result in peer-to-peer errors if a mapping is destroyed and replaced by a new mapping at the same gpa as the iommu will still be pointing to the original, pinned memory address.

---
 include/linux/kvm_host.h |    6 ++++++
 virt/kvm/iommu.c         |   12 ++++++++----
 virt/kvm/kvm_main.c      |    5 +++--
 3 files changed, 17 insertions(+), 6 deletions(-)
include/linux/kvm_host.h +6 -0
index 31ebb59cbd2f..82d5476e69cc 100644
@@ -554,6 +554,7 @@ void kvm_free_irq_source_id(struct kvm *kvm, int irq_source_id);
 
 #ifdef CONFIG_IOMMU_API
 int kvm_iommu_map_pages(struct kvm *kvm, struct kvm_memory_slot *slot);
+void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot);
 int kvm_iommu_map_guest(struct kvm *kvm);
 int kvm_iommu_unmap_guest(struct kvm *kvm);
 int kvm_assign_device(struct kvm *kvm,
@@ -567,6 +568,11 @@ static inline int kvm_iommu_map_pages(struct kvm *kvm,
 	return 0;
 }
 
+static inline void kvm_iommu_unmap_pages(struct kvm *kvm,
+					 struct kvm_memory_slot *slot)
+{
+}
+
 static inline int kvm_iommu_map_guest(struct kvm *kvm)
 {
 	return -ENODEV;
virt/kvm/iommu.c +8 -4
index 62a9caf0563c..fb0f6e469bb4 100644
@@ -285,6 +285,11 @@ static void kvm_iommu_put_pages(struct kvm *kvm,
 	}
 }
 
+void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot)
+{
+	kvm_iommu_put_pages(kvm, slot->base_gfn, slot->npages);
+}
+
 static int kvm_iommu_unmap_memslots(struct kvm *kvm)
 {
 	int i, idx;
@@ -293,10 +298,9 @@ static int kvm_iommu_unmap_memslots(struct kvm *kvm)
 	idx = srcu_read_lock(&kvm->srcu);
 	slots = kvm_memslots(kvm);
 
-	for (i = 0; i < slots->nmemslots; i++) {
-		kvm_iommu_put_pages(kvm, slots->memslots[i].base_gfn,
-				    slots->memslots[i].npages);
-	}
+	for (i = 0; i < slots->nmemslots; i++)
+		kvm_iommu_unmap_pages(kvm, &slots->memslots[i]);
+
 	srcu_read_unlock(&kvm->srcu, idx);
 
 	return 0;
virt/kvm/kvm_main.c +3 -2
index 96ebc0679415..6b39ba9540e8 100644
@@ -796,12 +796,13 @@ skip_lpage:
 	if (r)
 		goto out_free;
 
-	/* map the pages in iommu page table */
+	/* map/unmap the pages in iommu page table */
 	if (npages) {
 		r = kvm_iommu_map_pages(kvm, &new);
 		if (r)
 			goto out_free;
-	}
+	} else
+		kvm_iommu_unmap_pages(kvm, &old);
 
 	r = -ENOMEM;
 	slots = kzalloc(sizeof(struct kvm_memslots), GFP_KERNEL);
Signature · 1 line
1.7.10
#72 lore raw

Re: [ 49/62] KVM: unmap pages from the iommu when slots are removed

Quoted 4 lines · Jonathan Nieder

Hi,

Greg KH wrote:

Quoted 8 lines
Quoted 1 line

3.3-stable review patch.

[...]

Quoted 4 lines

commit 32f6daad4651a748a58a3ab6da0611862175722f upstream.

We've been adding new mappings, but not destroying old mappings. This can lead to a page leak

Does 3.0.y need this?

Yep, same issues exists there.

Quoted 5 lines

The patch does not apply as is to 3.0.y because
the latter lacks v3.3-rc1~131^2~41 ("KVM: introduce kvm_for_each_memslot macro"), but a backport is straightforward.

Completely untested. Test results and other comments welcome.

Looks correct to me.

Thanks,
Alex

Quoted 103 lines

-- >8 --
From: Alex Williamson <[email protected]>
Date: Wed, 11 Apr 2012 09:51:49 -0600

commit 32f6daad4651a748a58a3ab6da0611862175722f upstream.

We've been adding new mappings, but not destroying old mappings. This can lead to a page leak as pages are pinned using get_user_pages, but only unpinned with put_page if they still exist in the memslots list on vm shutdown. A memslot that is destroyed while an iommu domain is enabled for the guest will therefore result in an elevated page reference count that is never cleared.

Additionally, without this fix, the iommu is only programmed with the first translation for a gpa. This can result in peer-to-peer errors if a mapping is destroyed and replaced by a new mapping at the same gpa as the iommu will still be pointing to the original, pinned memory address.

---
 include/linux/kvm_host.h |    6 ++++++
 virt/kvm/iommu.c         |   12 ++++++++----
 virt/kvm/kvm_main.c      |    5 +++--
 3 files changed, 17 insertions(+), 6 deletions(-)
include/linux/kvm_host.h +6 -0
index 31ebb59cbd2f..82d5476e69cc 100644
@@ -554,6 +554,7 @@ void kvm_free_irq_source_id(struct kvm *kvm, int irq_source_id);
 
 #ifdef CONFIG_IOMMU_API
 int kvm_iommu_map_pages(struct kvm *kvm, struct kvm_memory_slot *slot);
+void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot);
 int kvm_iommu_map_guest(struct kvm *kvm);
 int kvm_iommu_unmap_guest(struct kvm *kvm);
 int kvm_assign_device(struct kvm *kvm,
@@ -567,6 +568,11 @@ static inline int kvm_iommu_map_pages(struct kvm *kvm,
 	return 0;
 }
 
+static inline void kvm_iommu_unmap_pages(struct kvm *kvm,
+					 struct kvm_memory_slot *slot)
+{
+}
+
 static inline int kvm_iommu_map_guest(struct kvm *kvm)
 {
 	return -ENODEV;
virt/kvm/iommu.c +8 -4
index 62a9caf0563c..fb0f6e469bb4 100644
@@ -285,6 +285,11 @@ static void kvm_iommu_put_pages(struct kvm *kvm,
 	}
 }
 
+void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot)
+{
+	kvm_iommu_put_pages(kvm, slot->base_gfn, slot->npages);
+}
+
 static int kvm_iommu_unmap_memslots(struct kvm *kvm)
 {
 	int i, idx;
@@ -293,10 +298,9 @@ static int kvm_iommu_unmap_memslots(struct kvm *kvm)
 	idx = srcu_read_lock(&kvm->srcu);
 	slots = kvm_memslots(kvm);
 
-	for (i = 0; i < slots->nmemslots; i++) {
-		kvm_iommu_put_pages(kvm, slots->memslots[i].base_gfn,
-				    slots->memslots[i].npages);
-	}
+	for (i = 0; i < slots->nmemslots; i++)
+		kvm_iommu_unmap_pages(kvm, &slots->memslots[i]);
+
 	srcu_read_unlock(&kvm->srcu, idx);
 
 	return 0;
virt/kvm/kvm_main.c +3 -2
index 96ebc0679415..6b39ba9540e8 100644
@@ -796,12 +796,13 @@ skip_lpage:
 	if (r)
 		goto out_free;
 
-	/* map the pages in iommu page table */
+	/* map/unmap the pages in iommu page table */
 	if (npages) {
 		r = kvm_iommu_map_pages(kvm, &new);
 		if (r)
 			goto out_free;
-	}
+	} else
+		kvm_iommu_unmap_pages(kvm, &old);
 
 	r = -ENOMEM;
 	slots = kzalloc(sizeof(struct kvm_memslots), GFP_KERNEL);
author maintainer
#73 lore raw

Re: [ 49/62] KVM: unmap pages from the iommu when slots are removed

Quoted 20 lines · Alex Williamson
Quoted 4 lines · Jonathan Nieder

Hi,

Greg KH wrote:

Quoted 8 lines
Quoted 1 line

3.3-stable review patch.

[...]

Quoted 4 lines

commit 32f6daad4651a748a58a3ab6da0611862175722f upstream.

We've been adding new mappings, but not destroying old mappings. This can lead to a page leak

Does 3.0.y need this?

Yep, same issues exists there.

Quoted 4 lines

The patch does not apply as is to 3.0.y because
the latter lacks v3.3-rc1~131^2~41 ("KVM: introduce kvm_for_each_memslot macro"), but a backport is straightforward.

Quoted 5 lines
Quoted 1 line

Completely untested. Test results and other comments welcome.

Looks correct to me.

Wonderful, now applied.

author maintainer
#74 lore raw

PATCH 50/62 dell-laptop: add 3 machines that has touchpad LED

In reply to Greg KH

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

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

From: AceLan Kao <[email protected]>

commit 2a748853ca395c48ea75baa250f7cea6f0f23dbf upstream.

Add "Vostro 3555", "Inspiron N311z", and "Inspiron M5110" into quirks, so that they could have touchpad LED function work.

---
 drivers/platform/x86/dell-laptop.c |   27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)
drivers/platform/x86/dell-laptop.c +27 -0
@@ -184,6 +184,33 @@ static struct dmi_system_id __devinitdat
 		},
 		.driver_data = &quirk_dell_vostro_v130,
 	},
+	{
+		.callback = dmi_matched,
+		.ident = "Dell Vostro 3555",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 3555"),
+		},
+		.driver_data = &quirk_dell_vostro_v130,
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Dell Inspiron N311z",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron N311z"),
+		},
+		.driver_data = &quirk_dell_vostro_v130,
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Dell Inspiron M5110",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron M5110"),
+		},
+		.driver_data = &quirk_dell_vostro_v130,
+	},
 };
 
 static struct calling_interface_buffer *buffer;
author maintainer
#75 lore raw

PATCH 51/62 dell-laptop: touchpad LED should persist its status after S3

In reply to Greg KH

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

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

From: AceLan Kao <[email protected]>

commit 2d5de9e84928e35b4d9b46b4d8d5dcaac1cff1fa upstream.

Touchpad LED will not turn on after S3, it will make the touchpad status doesn't consist with the LED.
By adding one flag to let the LED device restore it's status.

---
 drivers/platform/x86/dell-laptop.c |    1 +
 1 file changed, 1 insertion(+)
drivers/platform/x86/dell-laptop.c +1 -0
@@ -642,6 +642,7 @@ static void touchpad_led_set(struct led_
 static struct led_classdev touchpad_led = {
 	.name = "dell-laptop::touchpad",
 	.brightness_set = touchpad_led_set,
+	.flags = LED_CORE_SUSPENDRESUME,
 };
 
 static int __devinit touchpad_led_init(struct device *dev)
author maintainer
#76 lore raw

PATCH 52/62 Bluetooth: Add support for Atheros [04ca:3005]

In reply to Greg KH

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

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

From: AceLan Kao <[email protected]>

commit 55ed7d4d1469eafbe3ad7e8fcd44f5af27845a81 upstream.

Add another vendor specific ID for Atheros AR3012 device. This chip is wrapped by Lite-On Technology Corp.

output of usb-devices:

T:  Bus=04 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=04ca ProdID=3005 Rev=00.02
S:  Manufacturer=Atheros Communications
S:  Product=Bluetooth USB Host Controller
S:  SerialNumber=Alaska Day 2006
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
---
 drivers/bluetooth/ath3k.c |    2 ++
 drivers/bluetooth/btusb.c |    1 +
 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -74,6 +74,7 @@ static struct usb_device_id ath3k_table[
 	{ USB_DEVICE(0x0CF3, 0x3004) },
 	{ USB_DEVICE(0x0CF3, 0x311D) },
 	{ USB_DEVICE(0x13d3, 0x3375) },
+	{ USB_DEVICE(0x04CA, 0x3005) },
 
 	/* Atheros AR5BBU12 with sflash firmware */
 	{ USB_DEVICE(0x0489, 0xE02C) },
@@ -92,6 +93,7 @@ static struct usb_device_id ath3k_blist_
 	{ USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x0cf3, 0x311D), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
+	{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
 
 	{ }	/* Terminating entry */
 };
drivers/bluetooth/btusb.c +1 -0
@@ -130,6 +130,7 @@ static struct usb_device_id blacklist_ta
 	{ USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
+	{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
 
 	/* Atheros AR5BBU12 with sflash firmware */
 	{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
author maintainer
#77 lore raw

PATCH 53/62 nfsd: fix b0rken error value for setattr on read-only mount

In reply to Greg KH

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

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

From: Al Viro <[email protected]>

commit 96f6f98501196d46ce52c2697dd758d9300c63f5 upstream.

..._want_write() returns -EROFS on failure, _not_ an NFS error value.

---
 fs/nfsd/nfs4proc.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
fs/nfsd/nfs4proc.c +4 -3
@@ -826,6 +826,7 @@ nfsd4_setattr(struct svc_rqst *rqstp, st
 	      struct nfsd4_setattr *setattr)
 {
 	__be32 status = nfs_ok;
+	int err;
 
 	if (setattr->sa_iattr.ia_valid & ATTR_SIZE) {
 		nfs4_lock_state();
@@ -837,9 +838,9 @@ nfsd4_setattr(struct svc_rqst *rqstp, st
 			return status;
 		}
 	}
-	status = fh_want_write(&cstate->current_fh);
-	if (status)
-		return status;
+	err = fh_want_write(&cstate->current_fh);
+	if (err)
+		return nfserrno(err);
 	status = nfs_ok;
 
 	status = check_attr_support(rqstp, cstate, setattr->sa_bmval,
#78 lore raw

Re: [ 53/62] nfsd: fix b0rken error value for setattr on read-only mount

Quoted 1 line · Greg KH

3.3-stable review patch.

[...]

Quoted 3 lines

commit 96f6f98501196d46ce52c2697dd758d9300c63f5 upstream.

..._want_write() returns -EROFS on failure, _not_ an NFS error value.

Here's the corresponding change for kernels without

	static inline int fh_want_write(struct svc_fh *fh)
	{
		return mnt_want_write(fh->fh_export->ex_path.mnt);
	}

from v3.3-rc1~170^2~81 ("new helpers: fh_{want,drop}_write()"), such as the 3.0.y kernel. Thoughts and testing welcome as usual.

-- >8 --
From: Al Viro <[email protected]>
Date: Thu, 12 Apr 2012 23:47:00 -0400

commit 96f6f98501196d46ce52c2697dd758d9300c63f5 upstream.

..._want_write() returns -EROFS on failure, _not_ an NFS error value.

---
Thanks,
Jonathan

 fs/nfsd/nfs4proc.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
fs/nfsd/nfs4proc.c +4 -3
index 0b8830c9de73..d06a02c1b1a3 100644
@@ -812,6 +812,7 @@ nfsd4_setattr(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
 	      struct nfsd4_setattr *setattr)
 {
 	__be32 status = nfs_ok;
+	int err;
 
 	if (setattr->sa_iattr.ia_valid & ATTR_SIZE) {
 		nfs4_lock_state();
@@ -823,9 +824,9 @@ nfsd4_setattr(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
 			return status;
 		}
 	}
-	status = mnt_want_write(cstate->current_fh.fh_export->ex_path.mnt);
-	if (status)
-		return status;
+	err = mnt_want_write(cstate->current_fh.fh_export->ex_path.mnt);
+	if (err)
+		return nfserrno(err);
 	status = nfs_ok;
 
 	status = check_attr_support(rqstp, cstate, setattr->sa_bmval,
Signature · 1 line
1.7.10
author maintainer
#79 lore raw

PATCH 54/62 nfsd: fix error values returned by nfsd4_lockt() when nfsd_open() fails

In reply to Greg KH

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

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

From: Al Viro <[email protected]>

commit 04da6e9d63427b2d0fd04766712200c250b3278f upstream.

nfsd_open() already returns an NFS error value; only vfs_test_lock() result needs to be fed through nfserrno(). Broken by commit 55ef12 (nfsd: Ensure nfsv4 calls the underlying filesystem on LOCKT) three years ago...

---
 fs/nfsd/nfs4state.c |   23 +++++++++--------------
 1 file changed, 9 insertions(+), 14 deletions(-)
fs/nfsd/nfs4state.c +9 -14
@@ -4109,16 +4109,14 @@ out:
  * vfs_test_lock.  (Arguably perhaps test_lock should be done with an
  * inode operation.)
  */
-static int nfsd_test_lock(struct svc_rqst *rqstp, struct svc_fh *fhp, struct file_lock *lock)
+static __be32 nfsd_test_lock(struct svc_rqst *rqstp, struct svc_fh *fhp, struct file_lock *lock)
 {
 	struct file *file;
-	int err;
-
-	err = nfsd_open(rqstp, fhp, S_IFREG, NFSD_MAY_READ, &file);
-	if (err)
-		return err;
-	err = vfs_test_lock(file, lock);
-	nfsd_close(file);
+	__be32 err = nfsd_open(rqstp, fhp, S_IFREG, NFSD_MAY_READ, &file);
+	if (!err) {
+		err = nfserrno(vfs_test_lock(file, lock));
+		nfsd_close(file);
+	}
 	return err;
 }
 
@@ -4132,7 +4130,6 @@ nfsd4_lockt(struct svc_rqst *rqstp, stru
 	struct inode *inode;
 	struct file_lock file_lock;
 	struct nfs4_lockowner *lo;
-	int error;
 	__be32 status;
 
 	if (locks_in_grace())
@@ -4178,12 +4175,10 @@ nfsd4_lockt(struct svc_rqst *rqstp, stru
 
 	nfs4_transform_lock_offset(&file_lock);
 
-	status = nfs_ok;
-	error = nfsd_test_lock(rqstp, &cstate->current_fh, &file_lock);
-	if (error) {
-		status = nfserrno(error);
+	status = nfsd_test_lock(rqstp, &cstate->current_fh, &file_lock);
+	if (status)
 		goto out;
-	}
+
 	if (file_lock.fl_type != F_UNLCK) {
 		status = nfserr_denied;
 		nfs4_set_lock_denied(&file_lock, &lockt->lt_denied);
#80 lore raw

Re: [ 54/62] nfsd: fix error values returned by nfsd4_lockt() when nfsd_open() fails

Quoted 1 line · Greg KH

3.3-stable review patch.

[...]

Quoted 6 lines

commit 04da6e9d63427b2d0fd04766712200c250b3278f upstream.

nfsd_open() already returns an NFS error value; only vfs_test_lock() result needs to be fed through nfserrno(). Broken by commit 55ef12 (nfsd: Ensure nfsv4 calls the underlying filesystem on LOCKT) three years ago...

The regression was introduced in v2.6.29-rc1~177^2~14, so presumably 2.6.32.y and 3.0.y need this. Here's a blind backport to 3.0.y --- the only conflict encountered is of the unrelated-changes-on-adjacent- lines kind, against

v3.2-rc1~80^2~63 nfsd4: eliminate unused lt_stateowner v3.2-rc1~80^2~58 nfsd4: split stateowners into open and lockowners

Untested, so thoughts and testing would be welcome as usual.

-- >8 --
From: Al Viro <[email protected]>
Date: Fri, 13 Apr 2012 00:00:04 -0400

commit 04da6e9d63427b2d0fd04766712200c250b3278f upstream.

nfsd_open() already returns an NFS error value; only vfs_test_lock() result needs to be fed through nfserrno(). Broken by commit 55ef12 (nfsd: Ensure nfsv4 calls the underlying filesystem on LOCKT) three years ago...

---
Thanks,
Jonathan

 fs/nfsd/nfs4state.c |   23 +++++++++--------------
 1 file changed, 9 insertions(+), 14 deletions(-)
fs/nfsd/nfs4state.c +9 -14
index ecd8152965ee..92f7eb7c5863 100644
@@ -3956,16 +3956,14 @@ out:
  * vfs_test_lock.  (Arguably perhaps test_lock should be done with an
  * inode operation.)
  */
-static int nfsd_test_lock(struct svc_rqst *rqstp, struct svc_fh *fhp, struct file_lock *lock)
+static __be32 nfsd_test_lock(struct svc_rqst *rqstp, struct svc_fh *fhp, struct file_lock *lock)
 {
 	struct file *file;
-	int err;
-
-	err = nfsd_open(rqstp, fhp, S_IFREG, NFSD_MAY_READ, &file);
-	if (err)
-		return err;
-	err = vfs_test_lock(file, lock);
-	nfsd_close(file);
+	__be32 err = nfsd_open(rqstp, fhp, S_IFREG, NFSD_MAY_READ, &file);
+	if (!err) {
+		err = nfserrno(vfs_test_lock(file, lock));
+		nfsd_close(file);
+	}
 	return err;
 }
 
@@ -3978,7 +3976,6 @@ nfsd4_lockt(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
 {
 	struct inode *inode;
 	struct file_lock file_lock;
-	int error;
 	__be32 status;
 
 	if (locks_in_grace())
@@ -4030,12 +4027,10 @@ nfsd4_lockt(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
 
 	nfs4_transform_lock_offset(&file_lock);
 
-	status = nfs_ok;
-	error = nfsd_test_lock(rqstp, &cstate->current_fh, &file_lock);
-	if (error) {
-		status = nfserrno(error);
+	status = nfsd_test_lock(rqstp, &cstate->current_fh, &file_lock);
+	if (status)
 		goto out;
-	}
+
 	if (file_lock.fl_type != F_UNLCK) {
 		status = nfserr_denied;
 		nfs4_set_lock_denied(&file_lock, &lockt->lt_denied);
Signature · 1 line
1.7.10
author maintainer
#81 lore raw

PATCH 55/62 nfsd: fix endianness breakage in TEST_STATEID handling

In reply to Greg KH

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

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

From: Al Viro <[email protected]>

commit 02f5fde5df0ea930e70f93763dd48beff182b208 upstream.

->ts_id_status gets nfs errno, i.e. it's already big-endian; no need to apply htonl() to it. Broken by commit 174568 (NFSD: Added TEST_STATEID operation) last year...

---
 fs/nfsd/nfs4xdr.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfsd/nfs4xdr.c +1 -1
@@ -3410,7 +3410,7 @@ nfsd4_encode_test_stateid(struct nfsd4_c
 		nfsd4_decode_stateid(argp, &si);
 		valid = nfs4_validate_stateid(cl, &si);
 		RESERVE_SPACE(4);
-		*p++ = htonl(valid);
+		*p++ = valid;
 		resp->p = p;
 	}
 	nfs4_unlock_state();
author maintainer
#82 lore raw

PATCH 56/62 nfsd: fix compose_entry_fh() failure exits

In reply to Greg KH

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

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

From: Al Viro <[email protected]>

commit efe39651f08813180f37dc508d950fc7d92b29a8 upstream.

Restore the original logics ("fail on mountpoints, negatives and in case of fh_compose() failures"). Since commit 8177e (nfsd: clean up readdirplus encoding) that got broken -

	rv = fh_compose(fhp, exp, dchild, &cd->fh);
	if (rv)
	       goto out;
	if (!dchild->d_inode)
		goto out;
	rv = 0;
out:
is equivalent to
	rv = fh_compose(fhp, exp, dchild, &cd->fh);

out:
and the second check has no effect whatsoever...

---
 fs/nfsd/nfs3xdr.c |   22 ++++++++--------------
 1 file changed, 8 insertions(+), 14 deletions(-)
fs/nfsd/nfs3xdr.c +8 -14
@@ -803,13 +803,13 @@ encode_entry_baggage(struct nfsd3_readdi
 	return p;
 }
 
-static int
+static __be32
 compose_entry_fh(struct nfsd3_readdirres *cd, struct svc_fh *fhp,
 		const char *name, int namlen)
 {
 	struct svc_export	*exp;
 	struct dentry		*dparent, *dchild;
-	int rv = 0;
+	__be32 rv = nfserr_noent;
 
 	dparent = cd->fh.fh_dentry;
 	exp  = cd->fh.fh_export;
@@ -817,26 +817,20 @@ compose_entry_fh(struct nfsd3_readdirres
 	if (isdotent(name, namlen)) {
 		if (namlen == 2) {
 			dchild = dget_parent(dparent);
-			if (dchild == dparent) {
-				/* filesystem root - cannot return filehandle for ".." */
-				dput(dchild);
-				return -ENOENT;
-			}
+			/* filesystem root - cannot return filehandle for ".." */
+			if (dchild == dparent)
+				goto out;
 		} else
 			dchild = dget(dparent);
 	} else
 		dchild = lookup_one_len(name, dparent, namlen);
 	if (IS_ERR(dchild))
-		return -ENOENT;
-	rv = -ENOENT;
+		return rv;
 	if (d_mountpoint(dchild))
 		goto out;
-	rv = fh_compose(fhp, exp, dchild, &cd->fh);
-	if (rv)
-		goto out;
 	if (!dchild->d_inode)
 		goto out;
-	rv = 0;
+	rv = fh_compose(fhp, exp, dchild, &cd->fh);
 out:
 	dput(dchild);
 	return rv;
@@ -845,7 +839,7 @@ out:
 static __be32 *encode_entryplus_baggage(struct nfsd3_readdirres *cd, __be32 *p, const char *name, int namlen)
 {
 	struct svc_fh	fh;
-	int err;
+	__be32 err;
 
 	fh_init(&fh, NFS3_FHSIZE);
 	err = compose_entry_fh(cd, &fh, name, namlen);
author maintainer
#83 lore raw

PATCH 57/62 btrfs: btrfs_root_readonly() broken on big-endian

In reply to Greg KH

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

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

From: Al Viro <[email protected]>

commit 6ed3cf2cdfce4c9f1d73171bd3f27d9cb77b734e upstream.

->root_flags is __le64 and all accesses to it go through the helpers that do proper conversions. Except for btrfs_root_readonly(), which checks bit 0 as in host-endian...

---
 fs/btrfs/ctree.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/ctree.h +1 -1
@@ -2115,7 +2115,7 @@ BTRFS_SETGET_STACK_FUNCS(root_last_snaps
 
 static inline bool btrfs_root_readonly(struct btrfs_root *root)
 {
-	return root->root_item.flags & BTRFS_ROOT_SUBVOL_RDONLY;
+	return (root->root_item.flags & cpu_to_le64(BTRFS_ROOT_SUBVOL_RDONLY)) != 0;
 }
 
 /* struct btrfs_root_backup */
author maintainer
#84 lore raw

PATCH 58/62 ocfs2: ->l_next_free_req breakage on big-endian

In reply to Greg KH

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

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

From: Al Viro <[email protected]>

commit 3a251f04fe97c3d335b745c98e4b377e3c3899f2 upstream.

It's le16, not le32...

---
 fs/ocfs2/alloc.c        |    2 +-
 fs/ocfs2/refcounttree.c |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
fs/ocfs2/alloc.c +1 -1
@@ -1134,7 +1134,7 @@ static int ocfs2_adjust_rightmost_branch
 	}
 
 	el = path_leaf_el(path);
-	rec = &el->l_recs[le32_to_cpu(el->l_next_free_rec) - 1];
+	rec = &el->l_recs[le16_to_cpu(el->l_next_free_rec) - 1];
 
 	ocfs2_adjust_rightmost_records(handle, et, path, rec);
 
fs/ocfs2/refcounttree.c +2 -2
@@ -1036,14 +1036,14 @@ static int ocfs2_get_refcount_cpos_end(s
 
 	tmp_el = left_path->p_node[subtree_root].el;
 	blkno = left_path->p_node[subtree_root+1].bh->b_blocknr;
-	for (i = 0; i < le32_to_cpu(tmp_el->l_next_free_rec); i++) {
+	for (i = 0; i < le16_to_cpu(tmp_el->l_next_free_rec); i++) {
 		if (le64_to_cpu(tmp_el->l_recs[i].e_blkno) == blkno) {
 			*cpos_end = le32_to_cpu(tmp_el->l_recs[i+1].e_cpos);
 			break;
 		}
 	}
 
-	BUG_ON(i == le32_to_cpu(tmp_el->l_next_free_rec));
+	BUG_ON(i == le16_to_cpu(tmp_el->l_next_free_rec));
 
 out:
 	ocfs2_free_path(left_path);
author maintainer
#85 lore raw

PATCH 59/62 ocfs: ->rl_used breakage on big-endian

In reply to Greg KH

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

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

From: Al Viro <[email protected]>

commit e1bf4cc620fd143766ddfcee3b004a1d1bb34fd0 upstream.

it's le16, not le32 or le64...

---
 fs/ocfs2/refcounttree.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
fs/ocfs2/refcounttree.c +4 -4
@@ -1468,7 +1468,7 @@ static int ocfs2_divide_leaf_refcount_bl
 
 	trace_ocfs2_divide_leaf_refcount_block(
 		(unsigned long long)ref_leaf_bh->b_blocknr,
-		le32_to_cpu(rl->rl_count), le32_to_cpu(rl->rl_used));
+		le32_to_cpu(rl->rl_count), le16_to_cpu(rl->rl_used));
 
 	/*
 	 * XXX: Improvement later.
@@ -2411,7 +2411,7 @@ static int ocfs2_calc_refcount_meta_cred
 				rb = (struct ocfs2_refcount_block *)
 							prev_bh->b_data;
 
-				if (le64_to_cpu(rb->rf_records.rl_used) +
+				if (le16_to_cpu(rb->rf_records.rl_used) +
 				    recs_add >
 				    le16_to_cpu(rb->rf_records.rl_count))
 					ref_blocks++;
@@ -2476,7 +2476,7 @@ static int ocfs2_calc_refcount_meta_cred
 	if (prev_bh) {
 		rb = (struct ocfs2_refcount_block *)prev_bh->b_data;
 
-		if (le64_to_cpu(rb->rf_records.rl_used) + recs_add >
+		if (le16_to_cpu(rb->rf_records.rl_used) + recs_add >
 		    le16_to_cpu(rb->rf_records.rl_count))
 			ref_blocks++;
 
@@ -3629,7 +3629,7 @@ int ocfs2_refcounted_xattr_delete_need(s
 			 * one will split a refcount rec, so totally we need
 			 * clusters * 2 new refcount rec.
 			 */
-			if (le64_to_cpu(rb->rf_records.rl_used) + clusters * 2 >
+			if (le16_to_cpu(rb->rf_records.rl_used) + clusters * 2 >
 			    le16_to_cpu(rb->rf_records.rl_count))
 				ref_blocks++;
 
author maintainer
#86 lore raw

PATCH 60/62 ocfs2: ->rl_count endianness breakage

In reply to Greg KH

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

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

From: Al Viro <[email protected]>

commit 28748b325dc2d730ccc312830a91c4ae0c0d9379 upstream.

le16, not le32...

---
 fs/ocfs2/refcounttree.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ocfs2/refcounttree.c +1 -1
@@ -1468,7 +1468,7 @@ static int ocfs2_divide_leaf_refcount_bl
 
 	trace_ocfs2_divide_leaf_refcount_block(
 		(unsigned long long)ref_leaf_bh->b_blocknr,
-		le32_to_cpu(rl->rl_count), le16_to_cpu(rl->rl_used));
+		le16_to_cpu(rl->rl_count), le16_to_cpu(rl->rl_used));
 
 	/*
 	 * XXX: Improvement later.
author maintainer
#87 lore raw

PATCH 61/62 ocfs2: ->e_leaf_clusters endianness breakage

In reply to Greg KH

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

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

From: Al Viro <[email protected]>

commit 72094e43e3af5020510f920321d71f1798fa896d upstream.

le16, not le32...

---
 fs/ocfs2/suballoc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
fs/ocfs2/suballoc.c +2 -2
@@ -600,7 +600,7 @@ static void ocfs2_bg_alloc_cleanup(handl
 		ret = ocfs2_free_clusters(handle, cluster_ac->ac_inode,
 					  cluster_ac->ac_bh,
 					  le64_to_cpu(rec->e_blkno),
-					  le32_to_cpu(rec->e_leaf_clusters));
+					  le16_to_cpu(rec->e_leaf_clusters));
 		if (ret)
 			mlog_errno(ret);
 		/* Try all the clusters to free */
@@ -1628,7 +1628,7 @@ static int ocfs2_bg_discontig_fix_by_rec
 {
 	unsigned int bpc = le16_to_cpu(cl->cl_bpc);
 	unsigned int bitoff = le32_to_cpu(rec->e_cpos) * bpc;
-	unsigned int bitcount = le32_to_cpu(rec->e_leaf_clusters) * bpc;
+	unsigned int bitcount = le16_to_cpu(rec->e_leaf_clusters) * bpc;
 
 	if (res->sr_bit_offset < bitoff)
 		return 0;
author maintainer
#88 lore raw

PATCH 62/62 lockd: fix the endianness bug

In reply to Greg KH

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

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

From: Al Viro <[email protected]>

commit e847469bf77a1d339274074ed068d461f0c872bc upstream.

comparing be32 values for < is not doing the right thing...

Cc "J. Bruce Fields" <[email protected]>
Cc Trond Myklebust <[email protected]>
---
 fs/lockd/clnt4xdr.c |    2 +-
 fs/lockd/clntxdr.c  |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
fs/lockd/clnt4xdr.c +1 -1
@@ -241,7 +241,7 @@ static int decode_nlm4_stat(struct xdr_s
 	p = xdr_inline_decode(xdr, 4);
 	if (unlikely(p == NULL))
 		goto out_overflow;
-	if (unlikely(*p > nlm4_failed))
+	if (unlikely(ntohl(*p) > ntohl(nlm4_failed)))
 		goto out_bad_xdr;
 	*stat = *p;
 	return 0;
fs/lockd/clntxdr.c +1 -1
@@ -236,7 +236,7 @@ static int decode_nlm_stat(struct xdr_st
 	p = xdr_inline_decode(xdr, 4);
 	if (unlikely(p == NULL))
 		goto out_overflow;
-	if (unlikely(*p > nlm_lck_denied_grace_period))
+	if (unlikely(ntohl(*p) > ntohl(nlm_lck_denied_grace_period)))
 		goto out_enum;
 	*stat = *p;
 	return 0;