[ 00/16] 3.11.1-stable review

[ 00/16] 3.11.1-stable review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 3.11.1 release.
There are 16 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 Sat Sep 14 18:10:15 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

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


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

Diffstat:

[ 01/16] target: Fix trailing ASCII space usage in INQUIRY vendor+model

[Greg Kroah-Hartman]

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

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

From: Nicholas Bellinger <nab@linux-iscsi.org>

commit ee60bddba5a5f23e39598195d944aa0eb2d455e5 upstream.

This patch fixes spc_emulate_inquiry_std() to add trailing ASCII
spaces for INQUIRY vendor + model fields following SPC-4 text:

  "ASCII data fields described as being left-aligned shall have any
   unused bytes at the end of the field (i.e., highest offset) and
   the unused bytes shall be filled with ASCII space characters (20h)."

This addresses a problem with Falconstor NSS multipathing.

Reported-by: Tomas Molota <tomas.molota@lightstorm.sk>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/target/target_core_spc.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

--- a/drivers/target/target_core_spc.c
+++ b/drivers/target/target_core_spc.c
@@ -97,9 +97,12 @@ spc_emulate_inquiry_std(struct se_cmd *c
 
 	buf[7] = 0x2; /* CmdQue=1 */
 
-	snprintf(&buf[8], 8, "LIO-ORG");
-	snprintf(&buf[16], 16, "%s", dev->t10_wwn.model);
-	snprintf(&buf[32], 4, "%s", dev->t10_wwn.revision);
+	memcpy(&buf[8], "LIO-ORG ", 8);
+	memset(&buf[16], 0x20, 16);
+	memcpy(&buf[16], dev->t10_wwn.model,
+	       min_t(size_t, strlen(dev->t10_wwn.model), 16));
+	memcpy(&buf[32], dev->t10_wwn.revision,
+	       min_t(size_t, strlen(dev->t10_wwn.revision), 4));
 	buf[4] = 31; /* Set additional length to 31 */
 
 	return 0;

[ 02/16] iscsi-target: Fix ImmediateData=Yes failure regression in >= v3.10

[Greg Kroah-Hartman]

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

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

From: Nicholas Bellinger <nab@linux-iscsi.org>

commit 9d86a2befceb06ee83c1a588915e6d6e0abef797 upstream.

This patch addresses a regression bug within ImmediateData=Yes failure
handling that ends up triggering an OOPs within >= v3.10 iscsi-target
code.

The problem occurs when iscsit_process_scsi_cmd() does the call to
target_put_sess_cmd(), and once again in iscsit_get_immediate_data()
that is triggered during two different cases:

 - When iscsit_sequence_cmd() returns CMDSN_LOWER_THAN_EXP, for which
   the descriptor state will already have been set to ISTATE_REMOVE
   by iscsit_sequence_cmd(), and
 - When iscsi_cmd->sense_reason is set, for which iscsit_execute_cmd()
   will have already called transport_send_check_condition_and_sense()
   to queue the exception response.

It changes iscsit_process_scsi_cmd() to drop the early call, and makes
iscsit_get_immediate_data() call target_put_sess_cmd() from a single
location after dumping the immediate data for the failed command.

The regression was initially introduced in commit:

commit 561bf15892375597ee59d473a704a3e634c4f311
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Jul 3 03:58:58 2013 -0700

    iscsi-target: Fix iscsit_sequence_cmd reject handling for iser

Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/target/iscsi/iscsi_target.c |    9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -1086,7 +1086,6 @@ int iscsit_process_scsi_cmd(struct iscsi
 		if (cmd->reject_reason)
 			return 0;
 
-		target_put_sess_cmd(conn->sess->se_sess, &cmd->se_cmd);
 		return 1;
 	}
 	/*
@@ -1124,14 +1123,10 @@ after_immediate_data:
 		 */
 		cmdsn_ret = iscsit_sequence_cmd(cmd->conn, cmd,
 					(unsigned char *)hdr, hdr->cmdsn);
-		if (cmdsn_ret == CMDSN_ERROR_CANNOT_RECOVER) {
+		if (cmdsn_ret == CMDSN_ERROR_CANNOT_RECOVER)
 			return -1;
-		} else if (cmdsn_ret == CMDSN_LOWER_THAN_EXP) {
-			target_put_sess_cmd(conn->sess->se_sess, &cmd->se_cmd);
-			return 0;
-		}
 
-		if (cmd->sense_reason) {
+		if (cmd->sense_reason || cmdsn_ret == CMDSN_LOWER_THAN_EXP) {
 			int rc;
 
 			rc = iscsit_dump_data_payload(cmd->conn,

[ 03/16] iscsi-target: Fix iscsit_transport reference leak during NP thread reset

[Greg Kroah-Hartman]

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

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

From: Nicholas Bellinger <nab@linux-iscsi.org>

commit c9a03c12464c851e691e8d5b6c9deba779c512e0 upstream.

This patch fixes a bug in __iscsi_target_login_thread() where an explicit
network portal thread reset ends up leaking the iscsit_transport module
reference, along with the associated iscsi_conn allocation.

This manifests itself with iser-target where a NP reset causes the extra
iscsit_transport reference to be taken in iscsit_conn_set_transport()
during the reset, which prevents the ib_isert module from being unloaded
after the NP thread shutdown has finished.

Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/target/iscsi/iscsi_target_login.c |    9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

--- a/drivers/target/iscsi/iscsi_target_login.c
+++ b/drivers/target/iscsi/iscsi_target_login.c
@@ -1163,12 +1163,11 @@ static int __iscsi_target_login_thread(s
 		if (np->np_thread_state == ISCSI_NP_THREAD_RESET) {
 			spin_unlock_bh(&np->np_thread_lock);
 			complete(&np->np_restart_comp);
-			if (ret == -ENODEV) {
-				iscsit_put_transport(conn->conn_transport);
-				kfree(conn);
-				conn = NULL;
+			iscsit_put_transport(conn->conn_transport);
+			kfree(conn);
+			conn = NULL;
+			if (ret == -ENODEV)
 				goto out;
-			}
 			/* Get another socket */
 			return 1;
 		}

[ 04/16] iscsi-target: Fix potential NULL pointer in solicited NOPOUT reject

[Greg Kroah-Hartman]

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

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

From: Nicholas Bellinger <nab@linux-iscsi.org>

commit 28aaa950320fc7b8df3f6d2d34fa7833391a9b72 upstream.

This patch addresses a potential NULL pointer dereference regression in
iscsit_setup_nop_out() code, specifically for two cases when a solicited
NOPOUT triggers a ISCSI_REASON_PROTOCOL_ERROR reject to be generated.

This is because iscsi_cmd is expected to be NULL for solicited NOPOUT
case before iscsit_process_nop_out() locates the descriptor via TTT
using iscsit_find_cmd_from_ttt().

This regression was originally introduced in:

commit ba159914086f06532079fc15141f46ffe7e04a41
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Jul 3 03:48:24 2013 -0700

    iscsi-target: Fix iscsit_add_reject* usage for iser

Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/target/iscsi/iscsi_target.c |    8 ++++++++
 1 file changed, 8 insertions(+)

--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -1522,6 +1522,10 @@ int iscsit_setup_nop_out(struct iscsi_co
 	if (hdr->itt == RESERVED_ITT && !(hdr->opcode & ISCSI_OP_IMMEDIATE)) {
 		pr_err("NOPOUT ITT is reserved, but Immediate Bit is"
 			" not set, protocol error.\n");
+		if (!cmd)
+			return iscsit_add_reject(conn, ISCSI_REASON_PROTOCOL_ERROR,
+						 (unsigned char *)hdr);
+
 		return iscsit_reject_cmd(cmd, ISCSI_REASON_PROTOCOL_ERROR,
 					 (unsigned char *)hdr);
 	}
@@ -1531,6 +1535,10 @@ int iscsit_setup_nop_out(struct iscsi_co
 			" greater than MaxXmitDataSegmentLength: %u, protocol"
 			" error.\n", payload_length,
 			conn->conn_ops->MaxXmitDataSegmentLength);
+		if (!cmd)
+			return iscsit_add_reject(conn, ISCSI_REASON_PROTOCOL_ERROR,
+						 (unsigned char *)hdr);
+
 		return iscsit_reject_cmd(cmd, ISCSI_REASON_PROTOCOL_ERROR,
 					 (unsigned char *)hdr);
 	}

[ 05/16] target: Fix se_cmd->state_list leak regression during WRITE failure

[Greg Kroah-Hartman]

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

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

From: Nicholas Bellinger <nab@linux-iscsi.org>

commit c130480b129fbfd7932ad7af3f4ffcea630b027f upstream.

This patch addresses a v3.11 specific regression where se_cmd->state_list
was being leaked during a fabric WRITE failure, when the fabric releases
an associated se_cmd descriptor before I/O submission occurs, and normal
fast path callbacks have a chance to call target_remove_from_state_list().

It was manifesting with Poison overwritten messages with iscsi-target
once an ImmediateData payload CRC32C failure occured.

This bug was originally introduced during v3.11-rc1 with the following
commit:

commit 0b66818ac6de67a6125ae203272fb76e79b3a20f
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Jun 6 01:36:41 2013 -0700

    target: Drop unnecessary CMD_T_DEV_ACTIVE check from transport_lun_remove_cmd

Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/target/target_core_transport.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -2134,6 +2134,7 @@ static void transport_write_pending_qf(s
 
 int transport_generic_free_cmd(struct se_cmd *cmd, int wait_for_tasks)
 {
+	unsigned long flags;
 	int ret = 0;
 
 	if (!(cmd->se_cmd_flags & SCF_SE_LUN_CMD)) {
@@ -2144,6 +2145,16 @@ int transport_generic_free_cmd(struct se
 	} else {
 		if (wait_for_tasks)
 			transport_wait_for_tasks(cmd);
+		/*
+		 * Handle WRITE failure case where transport_generic_new_cmd()
+		 * has already added se_cmd to state_list, but fabric has
+		 * failed command before I/O submission.
+		 */
+		if (cmd->state_active) {
+			spin_lock_irqsave(&cmd->t_state_lock, flags);
+			target_remove_from_state_list(cmd);
+			spin_unlock_irqrestore(&cmd->t_state_lock, flags);
+		}
 
 		if (cmd->se_lun)
 			transport_lun_remove_cmd(cmd);

[ 06/16] mei: me: fix hardware reset flow

[Greg Kroah-Hartman]

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

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

From: Tomas Winkler <tomas.winkler@intel.com>

commit ff96066e3171acdea356b331163495957cb833d0 upstream.

Both H_IS and H_IE needs to be set to receive H_RDY
interrupt

1. Assert H_IS to clear the interrupts during hw reset
and use mei_me_reg_write instead of mei_hcsr_set as the later
strips down the H_IS

2. fix interrupt disablement embarrassing typo
  hcsr |= ~H_IE -> hcsr &= ~H_IE;
this will remove the unwanted interrupt on power down

3. remove useless debug print outs

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Cc: Shuah Khan <shuah.kh@samsung.com>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/misc/mei/hw-me.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -176,21 +176,18 @@ static int mei_me_hw_reset(struct mei_de
 	struct mei_me_hw *hw = to_me_hw(dev);
 	u32 hcsr = mei_hcsr_read(hw);
 
-	dev_dbg(&dev->pdev->dev, "before reset HCSR = 0x%08x.\n", hcsr);
-
-	hcsr |= (H_RST | H_IG);
+	hcsr |= H_RST | H_IG | H_IS;
 
 	if (intr_enable)
 		hcsr |= H_IE;
 	else
-		hcsr |= ~H_IE;
+		hcsr &= ~H_IE;
 
-	mei_hcsr_set(hw, hcsr);
+	mei_me_reg_write(hw, H_CSR, hcsr);
 
 	if (dev->dev_state == MEI_DEV_POWER_DOWN)
 		mei_me_hw_reset_release(dev);
 
-	dev_dbg(&dev->pdev->dev, "current HCSR = 0x%08x.\n", mei_hcsr_read(hw));
 	return 0;
 }
 

[ 07/16] usb: acm gadget: Null termintate strings table

[Greg Kroah-Hartman]

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

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

From: Graham Williams <gwilli@broadcom.com>

commit d257221854f0b34cca3247e6c45344d0470f7398 upstream.

The gadget strings table should be null terminated.
usb_gadget_get_string() loops through the table
expecting a null at the end of the list.

Signed-off-by: Graham Williams <gwilli@broadcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/gadget/f_acm.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/usb/gadget/f_acm.c
+++ b/drivers/usb/gadget/f_acm.c
@@ -285,6 +285,7 @@ static struct usb_string acm_string_defs
 	[ACM_CTRL_IDX].s = "CDC Abstract Control Model (ACM)",
 	[ACM_DATA_IDX].s = "CDC ACM Data",
 	[ACM_IAD_IDX ].s = "CDC Serial",
+	{  } /* end of list */
 };
 
 static struct usb_gadget_strings acm_string_table = {

[ 08/16] hwmon: (k10temp) Add support for Fam16h (Kabini)

[Greg Kroah-Hartman]

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

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

From: Wei Hu <wei@aristanetworks.com>

commit 30b146d1cb5e7560192057098eb705118bd5511f upstream.

The temperature reporting interface stays the same, so we just
add the PCI-ID to the list.

Verified on AMD Olive Hill.

Signed-off-by: Wei Hu <wei@aristanetworks.com>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 Documentation/hwmon/k10temp |    1 +
 drivers/hwmon/Kconfig       |    4 ++--
 drivers/hwmon/k10temp.c     |    3 ++-
 3 files changed, 5 insertions(+), 3 deletions(-)

--- a/Documentation/hwmon/k10temp
+++ b/Documentation/hwmon/k10temp
@@ -12,6 +12,7 @@ Supported chips:
 * AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series)
 * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series)
 * AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity"
+* AMD Family 16h processors: "Kabini"
 
   Prefix: 'k10temp'
   Addresses scanned: PCI space
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -296,8 +296,8 @@ config SENSORS_K10TEMP
 	  If you say yes here you get support for the temperature
 	  sensor(s) inside your CPU. Supported are later revisions of
 	  the AMD Family 10h and all revisions of the AMD Family 11h,
-	  12h (Llano), 14h (Brazos) and 15h (Bulldozer/Trinity)
-	  microarchitectures.
+	  12h (Llano), 14h (Brazos), 15h (Bulldozer/Trinity) and
+	  16h (Kabini) microarchitectures.
 
 	  This driver can also be built as a module.  If so, the module
 	  will be called k10temp.
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -1,5 +1,5 @@
 /*
- * k10temp.c - AMD Family 10h/11h/12h/14h/15h processor hardware monitoring
+ * k10temp.c - AMD Family 10h/11h/12h/14h/15h/16h processor hardware monitoring
  *
  * Copyright (c) 2009 Clemens Ladisch <clemens@ladisch.de>
  *
@@ -211,6 +211,7 @@ static DEFINE_PCI_DEVICE_TABLE(k10temp_i
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_CNB17H_F3) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M10H_F3) },
+	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
 	{}
 };
 MODULE_DEVICE_TABLE(pci, k10temp_id_table);

[ 09/16] Drivers: hv: vmbus: Fix a bug in the handling of channel offers

[Greg Kroah-Hartman]

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

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

From: "K. Y. Srinivasan" <kys@microsoft.com>

commit 42dceebe34600b2d02a38baa3e869009ba3d14c7 upstream.

The channel state should be correctly set before registering the device. In the current
code the driver probe would fail for channels that have been rescinded and subsequently
re-offered. Fix the bug.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/hv/channel_mgmt.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -262,6 +262,13 @@ static void vmbus_process_offer(struct w
 	}
 
 	/*
+	 * This state is used to indicate a successful open
+	 * so that when we do close the channel normally, we
+	 * can cleanup properly
+	 */
+	newchannel->state = CHANNEL_OPEN_STATE;
+
+	/*
 	 * Start the process of binding this offer to the driver
 	 * We need to set the DeviceObject field before calling
 	 * vmbus_child_dev_add()
@@ -287,13 +294,6 @@ static void vmbus_process_offer(struct w
 		kfree(newchannel->device_obj);
 
 		free_channel(newchannel);
-	} else {
-		/*
-		 * This state is used to indicate a successful open
-		 * so that when we do close the channel normally, we
-		 * can cleanup properly
-		 */
-		newchannel->state = CHANNEL_OPEN_STATE;
 	}
 }
 

[ 10/16] ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT

[Greg Kroah-Hartman]

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

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

From: Lan Tianyu <tianyu.lan@intel.com>

commit 524f42fab787a9510be826ce3d736b56d454ac6d upstream.

The ECDT of ASUSTEK L4R doesn't provide correct command and data
I/O ports.  The DSDT provides the correct information instead.

For this reason, add this machine to quirk list for ECDT validation
and use the EC information from the DSDT.

[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=60765
Reported-and-tested-by: Daniele Esposti <expo@expobrain.net>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/acpi/ec.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -987,6 +987,10 @@ static struct dmi_system_id __initdata e
 	ec_skip_dsdt_scan, "HP Folio 13", {
 	DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
 	DMI_MATCH(DMI_PRODUCT_NAME, "HP Folio 13"),}, NULL},
+	{
+	ec_validate_ecdt, "ASUS hardware", {
+	DMI_MATCH(DMI_SYS_VENDOR, "ASUSTek Computer Inc."),
+	DMI_MATCH(DMI_PRODUCT_NAME, "L4R"),}, NULL},
 	{},
 };
 

[ 11/16] drivers/misc/hpilo: Correct panic when an AUX iLO is detected

[Greg Kroah-Hartman]

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

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

From: Mark Rusk <Mark.Rusk@hp.com>

commit eefbc594abbb1b7e6e7eeadb65ae7c7538474210 upstream.

 Using an uninitialized variable 'devnum' after 'goto out;' was causing
 panic.  Just go ahead and return, we need to ignore AUX iLO devs.

 Oops: 0002 [#1] SMP
   .
   .
   .
 RIP  [<ffffffffa033e270>] ilo_probe+0xec/0xe7c [hpilo]

Signed-off-by: Mark Rusk <mark.rusk@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/misc/hpilo.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/misc/hpilo.c
+++ b/drivers/misc/hpilo.c
@@ -759,7 +759,7 @@ static int ilo_probe(struct pci_dev *pde
 
 	/* Ignore subsystem_device = 0x1979 (set by BIOS)  */
 	if (pdev->subsystem_device == 0x1979)
-		goto out;
+		return 0;
 
 	if (max_ccb > MAX_CCB)
 		max_ccb = MAX_CCB;
@@ -899,7 +899,7 @@ static void __exit ilo_exit(void)
 	class_destroy(ilo_class);
 }
 
-MODULE_VERSION("1.4");
+MODULE_VERSION("1.4.1");
 MODULE_ALIAS(ILO_NAME);
 MODULE_DESCRIPTION(ILO_NAME);
 MODULE_AUTHOR("David Altobelli <david.altobelli@hp.com>");

[ 12/16] ASoC: fsl: Fix module build

[Greg Kroah-Hartman]

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

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

From: Fabio Estevam <fabio.estevam@freescale.com>

commit 3f1a91aa25579ba5e7268a47a73d2a83e4802c62 upstream.

Building imx_v6_v7_defconfig with all audio drivers as modules results in
the folowing build error:

ERROR: "imx_pcm_fiq_init" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_dma_init" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_fiq_exit" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_dma_exit" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_dma_init" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!
ERROR: "imx_pcm_dma_exit" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!

Fix this by allowing SND_SOC_IMX_PCM_FIQ and SND_SOC_IMX_PCM_DMA to be also
built as modules and by using 'IS_ENABLED' to cover the module case.

Reported-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
[Guenter Roeck: back-ported to 3.11]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/soc/fsl/Kconfig   |    4 ++--
 sound/soc/fsl/imx-pcm.h |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -109,11 +109,11 @@ config SND_SOC_IMX_SSI
 	tristate
 
 config SND_SOC_IMX_PCM_FIQ
-	bool
+	tristate
 	select FIQ
 
 config SND_SOC_IMX_PCM_DMA
-	bool
+	tristate
 	select SND_SOC_GENERIC_DMAENGINE_PCM
 
 config SND_SOC_IMX_AUDMUX
--- a/sound/soc/fsl/imx-pcm.h
+++ b/sound/soc/fsl/imx-pcm.h
@@ -32,7 +32,7 @@ imx_pcm_dma_params_init_data(struct imx_
 		dma_data->peripheral_type = IMX_DMATYPE_SSI;
 }
 
-#ifdef CONFIG_SND_SOC_IMX_PCM_DMA
+#if IS_ENABLED(CONFIG_SND_SOC_IMX_PCM_DMA)
 int imx_pcm_dma_init(struct platform_device *pdev);
 void imx_pcm_dma_exit(struct platform_device *pdev);
 #else
@@ -46,7 +46,7 @@ static inline void imx_pcm_dma_exit(stru
 }
 #endif
 
-#ifdef CONFIG_SND_SOC_IMX_PCM_FIQ
+#if IS_ENABLED(CONFIG_SND_SOC_IMX_PCM_FIQ)
 int imx_pcm_fiq_init(struct platform_device *pdev);
 void imx_pcm_fiq_exit(struct platform_device *pdev);
 #else

[ 13/16] imx-drm: imx-drm-core: Export imx_drm_encoder_get_mux_id

[Greg Kroah-Hartman]

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

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

From: Fabio Estevam <fabio.estevam@freescale.com>

commit ea8d15832016b0d07a8121159904e6b1d21b5b8b upstream.

When building imx_v6_v7_defconfig with imx-drm drivers selected as modules, we
get the following build error:

ERROR: "imx_drm_encoder_get_mux_id" [drivers/staging/imx-drm/imx-ldb.ko] undefined!

Export the required function to avoid this problem.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/staging/imx-drm/imx-drm-core.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -678,6 +678,7 @@ found:
 
 	return i;
 }
+EXPORT_SYMBOL_GPL(imx_drm_encoder_get_mux_id);
 
 /*
  * imx_drm_remove_encoder - remove an encoder

[ 14/16] crypto: xor - Check for osxsave as well as avx in crypto/xor

[Greg Kroah-Hartman]

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

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

From: John Haxby <john.haxby@oracle.com>

commit edb6f29464afc65fc73767540b854abf63ae7144 upstream.

This affects xen pv guests with sufficiently old versions of xen and
sufficiently new hardware.  On such a system, a guest with a btrfs
root won't even boot.

Signed-off-by: John Haxby <john.haxby@oracle.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Reported-by: Michael Marineau <michael.marineau@coreos.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/include/asm/xor_avx.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/include/asm/xor_avx.h
+++ b/arch/x86/include/asm/xor_avx.h
@@ -167,12 +167,12 @@ static struct xor_block_template xor_blo
 
 #define AVX_XOR_SPEED \
 do { \
-	if (cpu_has_avx) \
+	if (cpu_has_avx && cpu_has_osxsave) \
 		xor_speed(&xor_block_avx); \
 } while (0)
 
 #define AVX_SELECT(FASTEST) \
-	(cpu_has_avx ? &xor_block_avx : FASTEST)
+	(cpu_has_avx && cpu_has_osxsave ? &xor_block_avx : FASTEST)
 
 #else
 

[ 15/16] drivers/rtc/rtc-max77686.c: Fix wrong register

[Greg Kroah-Hartman]

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

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

From: Sangjung Woo <sangjung.woo@samsung.com>

commit 1748cbf7f7c464593232cde914f5a103181a83b5 upstream.

Fix a read of the wrong register when checking whether the RTC timer has
reached the alarm time.

Signed-off-by: Sangjung Woo <sangjung.woo@samsung.com>
Signed-off-by: Myugnjoo Ham <myungjoo.ham@samsung.com>
Reviewed-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/rtc/rtc-max77686.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -240,9 +240,9 @@ static int max77686_rtc_read_alarm(struc
 	}
 
 	alrm->pending = 0;
-	ret = regmap_read(info->max77686->regmap, MAX77686_REG_STATUS1, &val);
+	ret = regmap_read(info->max77686->regmap, MAX77686_REG_STATUS2, &val);
 	if (ret < 0) {
-		dev_err(info->dev, "%s:%d fail to read status1 reg(%d)\n",
+		dev_err(info->dev, "%s:%d fail to read status2 reg(%d)\n",
 				__func__, __LINE__, ret);
 		goto out;
 	}

[ 16/16] mwifiex: do not create AP and P2P interfaces upon driver loading

[Greg Kroah-Hartman]

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

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

From: Bing Zhao <bzhao@marvell.com>

commit 1211c961170cedb21c30d5bb7e2033c8720b38db upstream.

Bug 60747 - 1286:2044 [Microsoft Surface Pro]
    Marvell 88W8797 wifi show 3 interface under network
https://bugzilla.kernel.org/show_bug.cgi?id=60747

This issue was also reported previously by OLPC and some folks from
the community.

There are 3 network interfaces with different types being created
when mwifiex driver is loaded:

1. mlan0 (infra. STA)
2. uap0 (AP)
3. p2p0 (P2P_CLIENT)

The Network Manager attempts to use all 3 interfaces above without
filtering the managed interface type. As the result, 3 identical
interfaces are displayed under network manager. If user happens to
click on an entry under which its interface is uap0 or p2p0, the
association will fail.

Work around it by removing the creation of AP and P2P interfaces
at driver loading time. These interfaces can be added with 'iw' or
other applications manually when they are needed.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/mwifiex/main.c |   14 --------------
 1 file changed, 14 deletions(-)

--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -458,20 +458,6 @@ static void mwifiex_fw_dpc(const struct
 		dev_err(adapter->dev, "cannot create default STA interface\n");
 		goto err_add_intf;
 	}
-
-	/* Create AP interface by default */
-	if (!mwifiex_add_virtual_intf(adapter->wiphy, "uap%d",
-				      NL80211_IFTYPE_AP, NULL, NULL)) {
-		dev_err(adapter->dev, "cannot create default AP interface\n");
-		goto err_add_intf;
-	}
-
-	/* Create P2P interface by default */
-	if (!mwifiex_add_virtual_intf(adapter->wiphy, "p2p%d",
-				      NL80211_IFTYPE_P2P_CLIENT, NULL, NULL)) {
-		dev_err(adapter->dev, "cannot create default P2P interface\n");
-		goto err_add_intf;
-	}
 	rtnl_unlock();
 
 	mwifiex_drv_get_driver_version(adapter, fmt, sizeof(fmt) - 1);

Re: [ 00/16] 3.11.1-stable review

[Linus Torvalds]

Your script may be a bit buggered...

          Linus

On Thu, Sep 12, 2013 at 11:14 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> -------------
> Pseudo-Shortlog of commits:
>
>
> -------------
>
> Diffstat:
>
>

Re: [ 00/16] 3.11.1-stable review

[Linus Torvalds]

On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> Your script may be a bit buggered...

Or maybe I should take that as a sign that 3.11 is doing really well?

I'll be optimistic.

               Linus

Re: [ 00/16] 3.11.1-stable review

[Greg Kroah-Hartman]

On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote:
> On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > Your script may be a bit buggered...
> 
> Or maybe I should take that as a sign that 3.11 is doing really well?
> 
> I'll be optimistic.

Hm, something went wrong here, let me track it down...

greg k-h

Re: [ 00/16] 3.11.1-stable review

[Greg Kroah-Hartman]

On Thu, Sep 12, 2013 at 11:22:40AM -0700, Greg Kroah-Hartman wrote:
> On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote:
> > On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > > Your script may be a bit buggered...
> > 
> > Or maybe I should take that as a sign that 3.11 is doing really well?
> > 
> > I'll be optimistic.
> 
> Hm, something went wrong here, let me track it down...

Ok, that was my fault, was working off of a 'master' branch in a repo
that expected it to be on the linux-3.11.y branch.  Here's the real
pseudo-shortlog below.

And it is short for now, as I've been holding off on applying patches
that are in your tree until 3.12-rc1 comes out.  The patches here are
ones that people have pointed out to me that should go in specifically
for various reasons.  So yes, I do think 3.11 is doing really well, I
have not heard of anything "major" being wrong with it yet.

thanks,

greg k-h


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

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 3.11.1-rc1

Bing Zhao <bzhao@marvell.com>
    mwifiex: do not create AP and P2P interfaces upon driver loading

Sangjung Woo <sangjung.woo@samsung.com>
    drivers/rtc/rtc-max77686.c: Fix wrong register

John Haxby <john.haxby@oracle.com>
    crypto: xor - Check for osxsave as well as avx in crypto/xor

Fabio Estevam <fabio.estevam@freescale.com>
    imx-drm: imx-drm-core: Export imx_drm_encoder_get_mux_id

Fabio Estevam <fabio.estevam@freescale.com>
    ASoC: fsl: Fix module build

Mark Rusk <Mark.Rusk@hp.com>
    drivers/misc/hpilo: Correct panic when an AUX iLO is detected

Lan Tianyu <tianyu.lan@intel.com>
    ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT

K. Y. Srinivasan <kys@microsoft.com>
    Drivers: hv: vmbus: Fix a bug in the handling of channel offers

Wei Hu <wei@aristanetworks.com>
    hwmon: (k10temp) Add support for Fam16h (Kabini)

Graham Williams <gwilli@broadcom.com>
    usb: acm gadget: Null termintate strings table

Tomas Winkler <tomas.winkler@intel.com>
    mei: me: fix hardware reset flow

Nicholas Bellinger <nab@linux-iscsi.org>
    target: Fix se_cmd->state_list leak regression during WRITE failure

Nicholas Bellinger <nab@linux-iscsi.org>
    iscsi-target: Fix potential NULL pointer in solicited NOPOUT reject

Nicholas Bellinger <nab@linux-iscsi.org>
    iscsi-target: Fix iscsit_transport reference leak during NP thread reset

Nicholas Bellinger <nab@linux-iscsi.org>
    iscsi-target: Fix ImmediateData=Yes failure regression in >= v3.10

Nicholas Bellinger <nab@linux-iscsi.org>
    target: Fix trailing ASCII space usage in INQUIRY vendor+model


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

Diffstat:

 Documentation/hwmon/k10temp               |  1 +
 Makefile                                  |  4 ++--
 arch/x86/include/asm/xor_avx.h            |  4 ++--
 drivers/acpi/ec.c                         |  4 ++++
 drivers/hv/channel_mgmt.c                 | 14 +++++++-------
 drivers/hwmon/Kconfig                     |  4 ++--
 drivers/hwmon/k10temp.c                   |  3 ++-
 drivers/misc/hpilo.c                      |  4 ++--
 drivers/misc/mei/hw-me.c                  |  9 +++------
 drivers/net/wireless/mwifiex/main.c       | 14 --------------
 drivers/rtc/rtc-max77686.c                |  4 ++--
 drivers/staging/imx-drm/imx-drm-core.c    |  1 +
 drivers/target/iscsi/iscsi_target.c       | 17 ++++++++++-------
 drivers/target/iscsi/iscsi_target_login.c |  9 ++++-----
 drivers/target/target_core_spc.c          |  9 ++++++---
 drivers/target/target_core_transport.c    | 11 +++++++++++
 drivers/usb/gadget/f_acm.c                |  1 +
 sound/soc/fsl/Kconfig                     |  4 ++--
 sound/soc/fsl/imx-pcm.h                   |  4 ++--
 19 files changed, 64 insertions(+), 57 deletions(-)

Re: [ 00/16] 3.11.1-stable review

[Stefan Lippers-Hollmann]

Hi

On Thursday 12 September 2013, Greg Kroah-Hartman wrote:
> On Thu, Sep 12, 2013 at 11:22:40AM -0700, Greg Kroah-Hartman wrote:
> > On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote:
> > > On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > > Your script may be a bit buggered...
> > > 
> > > Or maybe I should take that as a sign that 3.11 is doing really well?
> > > 
> > > I'll be optimistic.
> > 
> > Hm, something went wrong here, let me track it down...
> 
> Ok, that was my fault, was working off of a 'master' branch in a repo
> that expected it to be on the linux-3.11.y branch.  Here's the real
> pseudo-shortlog below.
[…]

This unfortunately affects the linked patch files as well, which are as
empty as the shortlog (compressed zero byte files); the sha256sum are 
correct:

$ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz | gzip -d
$

$ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.bz2 | bzip2 -d
$

$ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.xz | xz -d
xz: (stdin): File format not recognized
$

Regards
	Stefan Lippers-Hollmann

Re: [ 00/16] 3.11.1-stable review

[Greg Kroah-Hartman]

On Thu, Sep 12, 2013 at 09:41:59PM +0000, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On Thursday 12 September 2013, Greg Kroah-Hartman wrote:
> > On Thu, Sep 12, 2013 at 11:22:40AM -0700, Greg Kroah-Hartman wrote:
> > > On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote:
> > > > On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
> > > > <torvalds@linux-foundation.org> wrote:
> > > > > Your script may be a bit buggered...
> > > > 
> > > > Or maybe I should take that as a sign that 3.11 is doing really well?
> > > > 
> > > > I'll be optimistic.
> > > 
> > > Hm, something went wrong here, let me track it down...
> > 
> > Ok, that was my fault, was working off of a 'master' branch in a repo
> > that expected it to be on the linux-3.11.y branch.  Here's the real
> > pseudo-shortlog below.
> […]
> 
> This unfortunately affects the linked patch files as well, which are as
> empty as the shortlog (compressed zero byte files); the sha256sum are 
> correct:
> 
> $ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz | gzip -d
> $
> 
> $ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.bz2 | bzip2 -d
> $
> 
> $ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.xz | xz -d
> xz: (stdin): File format not recognized

Ah, good catch, I've copied up the patch properly and it should mirror
out soon.

thanks,

greg k-h

Re: [ 00/16] 3.11.1-stable review

[Shuah Khan]

On 09/12/2013 12:27 PM, Greg Kroah-Hartman wrote:
> On Thu, Sep 12, 2013 at 11:22:40AM -0700, Greg Kroah-Hartman wrote:
>> On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote:
>>> On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
>>> <torvalds@linux-foundation.org> wrote:
>>>> Your script may be a bit buggered...
>>>
>>> Or maybe I should take that as a sign that 3.11 is doing really well?
>>>
>>> I'll be optimistic.
>>
>> Hm, something went wrong here, let me track it down...
>
> Ok, that was my fault, was working off of a 'master' branch in a repo
> that expected it to be on the linux-3.11.y branch.  Here's the real
> pseudo-shortlog below.
>
> And it is short for now, as I've been holding off on applying patches
> that are in your tree until 3.12-rc1 comes out.  The patches here are
> ones that people have pointed out to me that should go in specifically
> for various reasons.  So yes, I do think 3.11 is doing really well, I
> have not heard of anything "major" being wrong with it yet.
>
> thanks,
>
> greg k-h
>
>

3.11.1-rc1 applied cleanly to 3.11

Compiled and booted on the following systems:

Samsung Series 9 900X4C Intel Corei5
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics

dmesgs look good. No regressions compared to the previous dmesgs for 
this release. dmesg emerg, crit, alert, err are clean. No regressions in 
warn.

Cross-compile testing: HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:

Cross-compile tests results:

alpha: defconfig passed
arm: defconfig passed
arm64: defconfig passed
blackfin: defconfig passed
c6x: defconfig passed
mips: defconfig passed
mipsel: defconfig passed
powerpc: wii_defconfig passed
sh: defconfig passed
sparc: defconfig passed
tile: tilegx_defconfig passed

-- Shuah
-- 
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658

Re: [ 00/16] 3.11.1-stable review

[Greg Kroah-Hartman]

On Fri, Sep 13, 2013 at 04:59:29PM -0600, Shuah Khan wrote:
> On 09/12/2013 12:27 PM, Greg Kroah-Hartman wrote:
> >On Thu, Sep 12, 2013 at 11:22:40AM -0700, Greg Kroah-Hartman wrote:
> >>On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote:
> >>>On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
> >>><torvalds@linux-foundation.org> wrote:
> >>>>Your script may be a bit buggered...
> >>>
> >>>Or maybe I should take that as a sign that 3.11 is doing really well?
> >>>
> >>>I'll be optimistic.
> >>
> >>Hm, something went wrong here, let me track it down...
> >
> >Ok, that was my fault, was working off of a 'master' branch in a repo
> >that expected it to be on the linux-3.11.y branch.  Here's the real
> >pseudo-shortlog below.
> >
> >And it is short for now, as I've been holding off on applying patches
> >that are in your tree until 3.12-rc1 comes out.  The patches here are
> >ones that people have pointed out to me that should go in specifically
> >for various reasons.  So yes, I do think 3.11 is doing really well, I
> >have not heard of anything "major" being wrong with it yet.
> >
> >thanks,
> >
> >greg k-h
> >
> >
> 
> 3.11.1-rc1 applied cleanly to 3.11
> 
> Compiled and booted on the following systems:
> 
> Samsung Series 9 900X4C Intel Corei5
> HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
> 
> dmesgs look good. No regressions compared to the previous dmesgs for
> this release. dmesg emerg, crit, alert, err are clean. No
> regressions in warn.

Great, thanks for testing and letting me know.

greg k-h

Re: [ 00/16] 3.11.1-stable review

[Guenter Roeck]

On 09/12/2013 11:14 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.11.1 release.
> There are 16 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 Sat Sep 14 18:10:15 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz
> and the diffstat can be found below.
>

Test results:
	total: 110 pass: 107 skipped: 2 fail: 1

The failure is xtensa:allmodconfig. A patch fixing the problem has been submitted,
but is not yet available upstream.

qemu:
	arm, microblaze, mips, mips64, ppc, x86, x86_64 all pass.
	sh passed with warning.

qemu:sh is new and only passes because of a patch I had to add to fix qemu,
so don't try it yourself. It also does create a backtrace due to a known
problem for which a patch has been submitted but is not yet available
upstream.

Details are at http://server.roeck-us.net:8010/builders.

Guenter

Re: [ 00/16] 3.11.1-stable review

[Greg Kroah-Hartman]

On Thu, Sep 12, 2013 at 03:37:10PM -0700, Guenter Roeck wrote:
> On 09/12/2013 11:14 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.11.1 release.
> >There are 16 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 Sat Sep 14 18:10:15 UTC 2013.
> >Anything received after that time might be too late.
> >
> >The whole patch series can be found in one patch at:
> >	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz
> >and the diffstat can be found below.
> >
> 
> Test results:
> 	total: 110 pass: 107 skipped: 2 fail: 1
> 
> The failure is xtensa:allmodconfig. A patch fixing the problem has been submitted,
> but is not yet available upstream.

What was skipped?

Anyway, thanks for testing and letting me know.

greg k-h

Re: [ 00/16] 3.11.1-stable review

[Guenter Roeck]

On 09/12/2013 04:07 PM, Greg Kroah-Hartman wrote:
> On Thu, Sep 12, 2013 at 03:37:10PM -0700, Guenter Roeck wrote:
>> On 09/12/2013 11:14 AM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 3.11.1 release.
>>> There are 16 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 Sat Sep 14 18:10:15 UTC 2013.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> 	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz
>>> and the diffstat can be found below.
>>>
>>
>> Test results:
>> 	total: 110 pass: 107 skipped: 2 fail: 1
>>
>> The failure is xtensa:allmodconfig. A patch fixing the problem has been submitted,
>> but is not yet available upstream.
>
> What was skipped?
>

Ah, someone noticed :).

Builds are listed as "skipped" if the configuration step fails. Usually
that means that the configuration does not exist, though in rare cases
it may fail for other reasons, which is why I still list it. For 3.11,
skipped builds are arm:ap4evb_defconfig and arm:bonito_defconfig,
both of which have been removed from 3.11.

For qemu tests, skipped means that the test is known to fail with
the affected kernel version, typically because qemu and that kernel
version don't like each other, so I don't bother trying.

Guenter