Skip to contentSkip to conversation

3.4.92-stable review

PATCH In review Greg Kroah-Hartman 8 participants 230 messages Jun 5, 2014 – Jun 6, 2014 Stable branch Page 2 of 2

lore
Share & tools
lore
author maintainer
#160 lore raw

PATCH 155/214 x86/efi: Fix dummy variable buffer allocation

In reply to Greg Kroah-Hartman

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

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

From: Ben Hutchings <[email protected]>

commit b8cb62f82103083a6e8fa5470bfe634a2c06514d upstream.

1. Check for allocation failure
2. Clear the buffer contents, as they may actually be written to flash
3. Don't leak the buffer

Compile-tested only.

[ Tested successfully on my buggy ASUS machine - Matt ]

---
 arch/x86/platform/efi/efi.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
arch/x86/platform/efi/efi.c +6 -1
@@ -1020,7 +1020,10 @@ efi_status_t efi_query_variable_store(u3
 		 * that by attempting to use more space than is available.
 		 */
 		unsigned long dummy_size = remaining_size + 1024;
-		void *dummy = kmalloc(dummy_size, GFP_ATOMIC);
+		void *dummy = kzalloc(dummy_size, GFP_ATOMIC);
+
+		if (!dummy)
+			return EFI_OUT_OF_RESOURCES;
 
 		status = efi.set_variable(efi_dummy_name, &EFI_DUMMY_GUID,
 					  EFI_VARIABLE_NON_VOLATILE |
@@ -1040,6 +1043,8 @@ efi_status_t efi_query_variable_store(u3
 					 0, dummy);
 		}
 
+		kfree(dummy);
+
 		/*
 		 * The runtime code may now have triggered a garbage collection
 		 * run, so check the variable info again
author maintainer
#161 lore raw

PATCH 156/214 nbd: fsync and kill block device on shutdown

In reply to Greg Kroah-Hartman

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

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

From: Paolo Bonzini <[email protected]>

commit 3a2d63f87989e01437ba994df5f297528c353d7d upstream.

There are two problems with shutdown in the NBD driver.

1: Receiving the NBD_DISCONNECT ioctl does not sync the filesystem.

This patch adds the sync operation into __nbd_ioctl()'s NBD_DISCONNECT handler. This is useful because BLKFLSBUF is restricted to processes that have CAP_SYS_ADMIN, and the NBD client may not possess it (fsync of the block device does not sync the filesystem, either).

2: Once we clear the socket we have no guarantee that later reads will
come from the same backing storage.

The patch adds calls to kill_bdev() in __nbd_ioctl()'s socket clearing code so the page cache is cleaned, lest reads that hit on the page cache will return stale data from the previously-accessible disk.

Example:

    # qemu-nbd -r -c/dev/nbd0 /dev/sr0
    # file -s /dev/nbd0
    /dev/stdin: # UDF filesystem data (version 1.5) etc.
    # qemu-nbd -d /dev/nbd0
    # qemu-nbd -r -c/dev/nbd0 /dev/sda
    # file -s /dev/nbd0
    /dev/stdin: # UDF filesystem data (version 1.5) etc.

While /dev/sda has:

    # file -s /dev/sda
    /dev/sda: x86 boot sector; etc.

[bwh: Backported to 3.2:
- Adjusted context
- s/\bnbd\b/lo/
- Incorporate export of kill_bdev() from commit ff01bb483265 ('fs: move code out of buffer.c')]

[hq: Backported to 3.4: Adjusted context]
---
 drivers/block/nbd.c |    9 +++++++++
 1 file changed, 9 insertions(+)
drivers/block/nbd.c +9 -0
@@ -584,10 +584,17 @@ static int __nbd_ioctl(struct block_devi
 		struct request sreq;
 
 		dev_info(disk_to_dev(nbd->disk), "NBD_DISCONNECT\n");
+		if (!nbd->sock)
+			return -EINVAL;
 
+		mutex_unlock(&nbd->tx_lock);
+		fsync_bdev(bdev);
+		mutex_lock(&nbd->tx_lock);
 		blk_rq_init(NULL, &sreq);
 		sreq.cmd_type = REQ_TYPE_SPECIAL;
 		nbd_cmd(&sreq) = NBD_CMD_DISC;
+
+		/* Check again after getting mutex back.  */
 		if (!nbd->sock)
 			return -EINVAL;
 
@@ -606,6 +613,7 @@ static int __nbd_ioctl(struct block_devi
 		nbd_clear_que(nbd);
 		BUG_ON(!list_empty(&nbd->queue_head));
 		BUG_ON(!list_empty(&nbd->waiting_queue));
+		kill_bdev(bdev);
 		if (file)
 			fput(file);
 		return 0;
@@ -688,6 +696,7 @@ static int __nbd_ioctl(struct block_devi
 		nbd->file = NULL;
 		nbd_clear_que(nbd);
 		dev_warn(disk_to_dev(nbd->disk), "queue cleared\n");
+		kill_bdev(bdev);
 		if (file)
 			fput(file);
 		nbd->bytesize = 0;
author maintainer
#162 lore raw

PATCH 157/214 drivers: hv: switch to use mb() instead of smp_mb()

In reply to Greg Kroah-Hartman

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

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

From: Jason Wang <[email protected]>

commit 35848f68b07df3f917cb13fc3c134718669f569b upstream.

Even if guest were compiled without SMP support, it could not assume that host wasn't. So switch to use mb() instead of smp_mb() to force memory barriers for UP guest.

[bwh: Backported to 3.2:
- Drop changes to functions that don't exist here
- hv_ringbuffer_write() has only a write memory barrier]

[hq: Backported to 3.4:
- Add the change in hv_ringbuffer_read]

---
 drivers/hv/ring_buffer.c |    4 ++--
 drivers/hv/vmbus_drv.c   |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)
drivers/hv/ring_buffer.c +2 -2
@@ -383,7 +383,7 @@ int hv_ringbuffer_write(struct hv_ring_b
 					     sizeof(u64));
 
 	/* Make sure we flush all writes before updating the writeIndex */
-	smp_wmb();
+	wmb();
 
 	/* Now, update the write location */
 	hv_set_next_write_location(outring_info, next_write_location);
@@ -485,7 +485,7 @@ int hv_ringbuffer_read(struct hv_ring_bu
 	/* Make sure all reads are done before we update the read index since */
 	/* the writer may start writing to the read area once the read index */
 	/*is updated */
-	smp_mb();
+	mb();
 
 	/* Update the read index */
 	hv_set_next_read_location(inring_info, next_read_location);
drivers/hv/vmbus_drv.c +1 -1
@@ -466,7 +466,7 @@ static void vmbus_on_msg_dpc(unsigned lo
 		 * will not deliver any more messages since there is
 		 * no empty slot
 		 */
-		smp_mb();
+		mb();
 
 		if (msg->header.message_flags.msg_pending) {
 			/*
author maintainer
#163 lore raw

PATCH 158/214 drm/i915/sdvo: clean up connectors on intel_sdvo_init() failures

In reply to Greg Kroah-Hartman

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

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

From: Jani Nikula <[email protected]>

commit d0ddfbd3d1346c1f481ec2289eef350cdba64b42 upstream.

Any failures in intel_sdvo_init() after the intel_sdvo_setup_output() call left behind ghost connectors, attached (with a dangling pointer) to the sdvo that has been cleaned up and freed. Properly destroy any connectors attached to the encoder.

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

[danvet: added a comment to explain why we need to clean up connectors even when sdvo_output_setup fails.]

[bwh: Backported to 3.2: adjust context]
Cc Weng Meiling <[email protected]>
---
 drivers/gpu/drm/i915/intel_sdvo.c |   22 +++++++++++++++++++---
 1 file changed, 19 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/intel_sdvo.c +19 -3
@@ -2265,6 +2265,18 @@ intel_sdvo_output_setup(struct intel_sdv
 	return true;
 }
 
+static void intel_sdvo_output_cleanup(struct intel_sdvo *intel_sdvo)
+{
+	struct drm_device *dev = intel_sdvo->base.base.dev;
+	struct drm_connector *connector, *tmp;
+
+	list_for_each_entry_safe(connector, tmp,
+				 &dev->mode_config.connector_list, head) {
+		if (intel_attached_encoder(connector) == &intel_sdvo->base)
+			intel_sdvo_destroy(connector);
+	}
+}
+
 static bool intel_sdvo_tv_create_property(struct intel_sdvo *intel_sdvo,
 					  struct intel_sdvo_connector *intel_sdvo_connector,
 					  int type)
@@ -2583,7 +2595,8 @@ bool intel_sdvo_init(struct drm_device *
 				    intel_sdvo->caps.output_flags) != true) {
 		DRM_DEBUG_KMS("SDVO output failed to setup on SDVO%c\n",
 			      IS_SDVOB(sdvo_reg) ? 'B' : 'C');
-		goto err;
+		/* Output_setup can leave behind connectors! */
+		goto err_output;
 	}
 
 	/* Only enable the hotplug irq if we need it, to work around noisy
@@ -2596,12 +2609,12 @@ bool intel_sdvo_init(struct drm_device *
 
 	/* Set the input timing to the screen. Assume always input 0. */
 	if (!intel_sdvo_set_target_input(intel_sdvo))
-		goto err;
+		goto err_output;
 
 	if (!intel_sdvo_get_input_pixel_clock_range(intel_sdvo,
 						    &intel_sdvo->pixel_clock_min,
 						    &intel_sdvo->pixel_clock_max))
-		goto err;
+		goto err_output;
 
 	DRM_DEBUG_KMS("%s device VID/DID: %02X:%02X.%02X, "
 			"clock range %dMHz - %dMHz, "
@@ -2621,6 +2634,9 @@ bool intel_sdvo_init(struct drm_device *
 			(SDVO_OUTPUT_TMDS1 | SDVO_OUTPUT_RGB1) ? 'Y' : 'N');
 	return true;
 
+err_output:
+	intel_sdvo_output_cleanup(intel_sdvo);
+
 err:
 	drm_encoder_cleanup(&intel_encoder->base);
 	i2c_del_adapter(&intel_sdvo->ddc);
author maintainer
#164 lore raw

PATCH 159/214 drm: fix documentation for drm_crtc_set_mode()

In reply to Greg Kroah-Hartman

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

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

From: Alex Deucher <[email protected]>

commit 4c9287c6009b37754c42e0ba73a4cc79de92d8f8 upstream.

x and y parameters are offsets, not width/height

---
 drivers/gpu/drm/drm_crtc_helper.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/drm_crtc_helper.c +2 -2
@@ -328,8 +328,8 @@ drm_crtc_prepare_encoders(struct drm_dev
  * drm_crtc_set_mode - set a mode
  * @crtc: CRTC to program
  * @mode: mode to use
- * @x: width of mode
- * @y: height of mode
+ * @x: horizontal offset into the surface
+ * @y: vertical offset into the surface
  *
  * LOCKING:
  * Caller must hold mode config lock.
author maintainer
#165 lore raw

PATCH 160/214 drm/radeon/dce32+: use fractional fb dividers for high clocks

In reply to Greg Kroah-Hartman

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

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

From: Alex Deucher <[email protected]>

commit a02dc74b317d78298cb0587b9b1f6f741fd5c139 upstream.

Fixes flickering with some high res montiors.

[bwh: Backported to 3.2: use pll->flags instead of radeon_crtc->pll_flags]
Cc Weng Meiling <[email protected]>
---
 drivers/gpu/drm/radeon/atombios_crtc.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/gpu/drm/radeon/atombios_crtc.c +2 -0
@@ -573,6 +573,8 @@ static u32 atombios_adjust_pll(struct dr
 		/* use frac fb div on APUs */
 		if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE61(rdev))
 			pll->flags |= RADEON_PLL_USE_FRAC_FB_DIV;
+		if (ASIC_IS_DCE32(rdev) && mode->clock > 165000)
+			pll->flags |= RADEON_PLL_USE_FRAC_FB_DIV;
 	} else {
 		pll->flags |= RADEON_PLL_LEGACY;
 
author maintainer
#166 lore raw

PATCH 161/214 drm/radeon: fix amd afusion gpu setup aka sumo v2

In reply to Greg Kroah-Hartman

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

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

From: Jerome Glisse <[email protected]>

commit bd25f0783dc3fb72e1e2779c2b99b2d34b67fa8a upstream.

Set the proper number of tile pipe that should be a multiple of pipe depending on the number of se engine.

Fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56405
https://bugs.freedesktop.org/show_bug.cgi?id=56720

v2: Don't change sumo2

[bwh: Backported to 3.2: don't define/use *_GB_ADDR_CONFIG_GOLDEN]
Cc Weng Meiling <[email protected]>
---
 drivers/gpu/drm/radeon/evergreen.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/radeon/evergreen.c +2 -2
@@ -1874,7 +1874,7 @@ static void evergreen_gpu_init(struct ra
 	case CHIP_SUMO:
 		rdev->config.evergreen.num_ses = 1;
 		rdev->config.evergreen.max_pipes = 4;
-		rdev->config.evergreen.max_tile_pipes = 2;
+		rdev->config.evergreen.max_tile_pipes = 4;
 		if (rdev->pdev->device == 0x9648)
 			rdev->config.evergreen.max_simds = 3;
 		else if ((rdev->pdev->device == 0x9647) ||
@@ -1963,7 +1963,7 @@ static void evergreen_gpu_init(struct ra
 		break;
 	case CHIP_CAICOS:
 		rdev->config.evergreen.num_ses = 1;
-		rdev->config.evergreen.max_pipes = 4;
+		rdev->config.evergreen.max_pipes = 2;
 		rdev->config.evergreen.max_tile_pipes = 2;
 		rdev->config.evergreen.max_simds = 2;
 		rdev->config.evergreen.max_backends = 1 * rdev->config.evergreen.num_ses;
author maintainer
#167 lore raw

PATCH 162/214 drm/radeon: add connector table for SAM440ep embedded board

In reply to Greg Kroah-Hartman

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

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

From: Alex Deucher <[email protected]>

commit 6a556039e7823d27a0a7f7724d4d455053ea9253 upstream.

RV250 found on ppc embedded boards.

---
 drivers/gpu/drm/radeon/radeon_combios.c |   66 ++++++++++++++++++++++++++++++++
 drivers/gpu/drm/radeon/radeon_mode.h    |    1 
 2 files changed, 67 insertions(+)
drivers/gpu/drm/radeon/radeon_combios.c +66 -0
@@ -1509,6 +1509,11 @@ bool radeon_get_legacy_connector_info_fr
 			   (rdev->pdev->subsystem_device == 0x4150)) {
 			/* Mac G5 tower 9600 */
 			rdev->mode_info.connector_table = CT_MAC_G5_9600;
+		} else if ((rdev->pdev->device == 0x4c66) &&
+			   (rdev->pdev->subsystem_vendor == 0x1002) &&
+			   (rdev->pdev->subsystem_device == 0x4c66)) {
+			/* SAM440ep RV250 embedded board */
+			rdev->mode_info.connector_table = CT_SAM440EP;
 		} else
 #endif /* CONFIG_PPC_PMAC */
 #ifdef CONFIG_PPC64
@@ -2080,6 +2085,67 @@ bool radeon_get_legacy_connector_info_fr
 					    DRM_MODE_CONNECTOR_SVIDEO,
 					    &ddc_i2c,
 					    CONNECTOR_OBJECT_ID_SVIDEO,
+					    &hpd);
+		break;
+	case CT_SAM440EP:
+		DRM_INFO("Connector Table: %d (SAM440ep embedded board)\n",
+			 rdev->mode_info.connector_table);
+		/* LVDS */
+		ddc_i2c = combios_setup_i2c_bus(rdev, DDC_NONE_DETECTED, 0, 0);
+		hpd.hpd = RADEON_HPD_NONE;
+		radeon_add_legacy_encoder(dev,
+					  radeon_get_encoder_enum(dev,
+								ATOM_DEVICE_LCD1_SUPPORT,
+								0),
+					  ATOM_DEVICE_LCD1_SUPPORT);
+		radeon_add_legacy_connector(dev, 0, ATOM_DEVICE_LCD1_SUPPORT,
+					    DRM_MODE_CONNECTOR_LVDS, &ddc_i2c,
+					    CONNECTOR_OBJECT_ID_LVDS,
+					    &hpd);
+		/* DVI-I - secondary dac, int tmds */
+		ddc_i2c = combios_setup_i2c_bus(rdev, DDC_DVI, 0, 0);
+		hpd.hpd = RADEON_HPD_1; /* ??? */
+		radeon_add_legacy_encoder(dev,
+					  radeon_get_encoder_enum(dev,
+								ATOM_DEVICE_DFP1_SUPPORT,
+								0),
+					  ATOM_DEVICE_DFP1_SUPPORT);
+		radeon_add_legacy_encoder(dev,
+					  radeon_get_encoder_enum(dev,
+								ATOM_DEVICE_CRT2_SUPPORT,
+								2),
+					  ATOM_DEVICE_CRT2_SUPPORT);
+		radeon_add_legacy_connector(dev, 1,
+					    ATOM_DEVICE_DFP1_SUPPORT |
+					    ATOM_DEVICE_CRT2_SUPPORT,
+					    DRM_MODE_CONNECTOR_DVII, &ddc_i2c,
+					    CONNECTOR_OBJECT_ID_SINGLE_LINK_DVI_I,
+					    &hpd);
+		/* VGA - primary dac */
+		ddc_i2c = combios_setup_i2c_bus(rdev, DDC_VGA, 0, 0);
+		hpd.hpd = RADEON_HPD_NONE;
+		radeon_add_legacy_encoder(dev,
+					  radeon_get_encoder_enum(dev,
+								ATOM_DEVICE_CRT1_SUPPORT,
+								1),
+					  ATOM_DEVICE_CRT1_SUPPORT);
+		radeon_add_legacy_connector(dev, 2,
+					    ATOM_DEVICE_CRT1_SUPPORT,
+					    DRM_MODE_CONNECTOR_VGA, &ddc_i2c,
+					    CONNECTOR_OBJECT_ID_VGA,
+					    &hpd);
+		/* TV - TV DAC */
+		ddc_i2c.valid = false;
+		hpd.hpd = RADEON_HPD_NONE;
+		radeon_add_legacy_encoder(dev,
+					  radeon_get_encoder_enum(dev,
+								ATOM_DEVICE_TV1_SUPPORT,
+								2),
+					  ATOM_DEVICE_TV1_SUPPORT);
+		radeon_add_legacy_connector(dev, 3, ATOM_DEVICE_TV1_SUPPORT,
+					    DRM_MODE_CONNECTOR_SVIDEO,
+					    &ddc_i2c,
+					    CONNECTOR_OBJECT_ID_SVIDEO,
 					    &hpd);
 		break;
 	default:
drivers/gpu/drm/radeon/radeon_mode.h +1 -0
@@ -210,6 +210,7 @@ enum radeon_connector_table {
 	CT_RN50_POWER,
 	CT_MAC_X800,
 	CT_MAC_G5_9600,
+	CT_SAM440EP
 };
 
 enum radeon_dvo_chip {
author maintainer
#168 lore raw

PATCH 163/214 drm/radeon: add connector table for Mac G4 Silver

In reply to Greg Kroah-Hartman

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

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

From: Alex Deucher <[email protected]>

commit cafa59b9011a7790be4ddd5979419259844a165d upstream.

Apple cards do not provide data tables in the vbios so we have to hard code the connector parameters in the driver.

---
 drivers/gpu/drm/radeon/radeon_combios.c |   51 ++++++++++++++++++++++++++++++++
 drivers/gpu/drm/radeon/radeon_mode.h    |    3 +
 2 files changed, 53 insertions(+), 1 deletion(-)
drivers/gpu/drm/radeon/radeon_combios.c +51 -0
@@ -1484,6 +1484,9 @@ bool radeon_get_legacy_connector_info_fr
 			   of_machine_is_compatible("PowerBook6,7")) {
 			/* ibook */
 			rdev->mode_info.connector_table = CT_IBOOK;
+		} else if (of_machine_is_compatible("PowerMac3,5")) {
+			/* PowerMac G4 Silver radeon 7500 */
+			rdev->mode_info.connector_table = CT_MAC_G4_SILVER;
 		} else if (of_machine_is_compatible("PowerMac4,4")) {
 			/* emac */
 			rdev->mode_info.connector_table = CT_EMAC;
@@ -2146,6 +2149,54 @@ bool radeon_get_legacy_connector_info_fr
 					    DRM_MODE_CONNECTOR_SVIDEO,
 					    &ddc_i2c,
 					    CONNECTOR_OBJECT_ID_SVIDEO,
+					    &hpd);
+		break;
+	case CT_MAC_G4_SILVER:
+		DRM_INFO("Connector Table: %d (mac g4 silver)\n",
+			 rdev->mode_info.connector_table);
+		/* DVI-I - tv dac, int tmds */
+		ddc_i2c = combios_setup_i2c_bus(rdev, DDC_DVI, 0, 0);
+		hpd.hpd = RADEON_HPD_1; /* ??? */
+		radeon_add_legacy_encoder(dev,
+					  radeon_get_encoder_enum(dev,
+								ATOM_DEVICE_DFP1_SUPPORT,
+								0),
+					  ATOM_DEVICE_DFP1_SUPPORT);
+		radeon_add_legacy_encoder(dev,
+					  radeon_get_encoder_enum(dev,
+								ATOM_DEVICE_CRT2_SUPPORT,
+								2),
+					  ATOM_DEVICE_CRT2_SUPPORT);
+		radeon_add_legacy_connector(dev, 0,
+					    ATOM_DEVICE_DFP1_SUPPORT |
+					    ATOM_DEVICE_CRT2_SUPPORT,
+					    DRM_MODE_CONNECTOR_DVII, &ddc_i2c,
+					    CONNECTOR_OBJECT_ID_SINGLE_LINK_DVI_I,
+					    &hpd);
+		/* VGA - primary dac */
+		ddc_i2c = combios_setup_i2c_bus(rdev, DDC_VGA, 0, 0);
+		hpd.hpd = RADEON_HPD_NONE;
+		radeon_add_legacy_encoder(dev,
+					  radeon_get_encoder_enum(dev,
+								ATOM_DEVICE_CRT1_SUPPORT,
+								1),
+					  ATOM_DEVICE_CRT1_SUPPORT);
+		radeon_add_legacy_connector(dev, 1, ATOM_DEVICE_CRT1_SUPPORT,
+					    DRM_MODE_CONNECTOR_VGA, &ddc_i2c,
+					    CONNECTOR_OBJECT_ID_VGA,
+					    &hpd);
+		/* TV - TV DAC */
+		ddc_i2c.valid = false;
+		hpd.hpd = RADEON_HPD_NONE;
+		radeon_add_legacy_encoder(dev,
+					  radeon_get_encoder_enum(dev,
+								ATOM_DEVICE_TV1_SUPPORT,
+								2),
+					  ATOM_DEVICE_TV1_SUPPORT);
+		radeon_add_legacy_connector(dev, 2, ATOM_DEVICE_TV1_SUPPORT,
+					    DRM_MODE_CONNECTOR_SVIDEO,
+					    &ddc_i2c,
+					    CONNECTOR_OBJECT_ID_SVIDEO,
 					    &hpd);
 		break;
 	default:
drivers/gpu/drm/radeon/radeon_mode.h +2 -1
@@ -210,7 +210,8 @@ enum radeon_connector_table {
 	CT_RN50_POWER,
 	CT_MAC_X800,
 	CT_MAC_G5_9600,
-	CT_SAM440EP
+	CT_SAM440EP,
+	CT_MAC_G4_SILVER
 };
 
 enum radeon_dvo_chip {
author maintainer
#169 lore raw

PATCH 164/214 drm/nouveau: fix init with agpgart-uninorth

In reply to Greg Kroah-Hartman

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

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

From: Aaro Koskinen <[email protected]>

commit eda85d6ad490923152544fba0473798b6cc0edf6 upstream.

Check that the AGP aperture can be mapped. This follows a similar change done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if the aperture can be mapped by the CPU.).

The patch fixes the following error seen on G5 iMac:

nouveau E[ DRM] failed to create kernel channel, -12

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58806

---
 drivers/gpu/drm/nouveau/nouveau_bo.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/nouveau/nouveau_bo.c +1 -1
@@ -946,7 +946,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo
 		if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
 			mem->bus.offset = mem->start << PAGE_SHIFT;
 			mem->bus.base = dev_priv->gart_info.aper_base;
-			mem->bus.is_iomem = true;
+			mem->bus.is_iomem = !dev->agp->cant_use_aperture;
 		}
 #endif
 		break;
author maintainer
#170 lore raw

PATCH 165/214 drm/radeon: fix typo in evergreen_mc_resume()

In reply to Greg Kroah-Hartman

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

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

From: Alex Deucher <[email protected]>

commit 695ddeb457584a602f2ba117d08ce37cf6ec1589 upstream.

Add missing index that may have led us to enabling more crtcs than necessary.

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

---
 drivers/gpu/drm/radeon/evergreen.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/radeon/evergreen.c +1 -1
@@ -1292,7 +1292,7 @@ void evergreen_mc_resume(struct radeon_d
 	WREG32(BIF_FB_EN, FB_READ_EN | FB_WRITE_EN);
 
 	for (i = 0; i < rdev->num_crtc; i++) {
-		if (save->crtc_enabled) {
+		if (save->crtc_enabled[i]) {
 			if (ASIC_IS_DCE6(rdev)) {
 				tmp = RREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i]);
 				tmp |= EVERGREEN_CRTC_BLANK_DATA_EN;
author maintainer
#171 lore raw

PATCH 166/214 drm/i915: Close race between processing unpin task and queueing the flip

In reply to Greg Kroah-Hartman

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

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

From: Chris Wilson <[email protected]>

commit e7d841ca03b7ab668620045cd7b428eda9f41601 upstream.

Before queuing the flip but crucially after attaching the unpin-work to the crtc, we continue to setup the unpin-work. However, should the hardware fire early, we see the connected unpin-work and queue the task. The task then promptly runs and unpins the fb before we finish taking the required references or even pinning it... Havoc.

To close the race, we use the flip-pending atomic to indicate when the flip is finally setup and enqueued. So during the flip-done processing, we can check more accurately whether the flip was expected.

v2: Add the appropriate mb() to ensure that the writes to the page-flip worker are complete prior to marking it active and emitting the MI_FLIP. On the read side, the mb should be enforced by the spinlocks.

[danvet: Review the barriers a bit, we need a write barrier both before and after updating ->pending. Similarly we need a read barrier in the interrupt handler both before and after reading ->pending. With well-ordered irqs only one barrier in each place should be required, but since this patch explicitly sets out to combat spurious interrupts with is staged activation of the unpin work we need to go full-bore on the barriers, too. Discussed with Chris Wilson on irc and changes acked by him.]

[wml: Backported to 3.4: adjust context]
---
 drivers/gpu/drm/i915/i915_debugfs.c  |    4 +--
 drivers/gpu/drm/i915/i915_irq.c      |    4 ++-
 drivers/gpu/drm/i915/intel_display.c |   39 ++++++++++++++++++++++++++++-------
 drivers/gpu/drm/i915/intel_drv.h     |    5 +++-
 4 files changed, 41 insertions(+), 11 deletions(-)
drivers/gpu/drm/i915/i915_debugfs.c +2 -2
@@ -340,7 +340,7 @@ static int i915_gem_pageflip_info(struct
 			seq_printf(m, "No flip due on pipe %c (plane %c)\n",
 				   pipe, plane);
 		} else {
-			if (!work->pending) {
+			if (atomic_read(&work->pending) < INTEL_FLIP_COMPLETE) {
 				seq_printf(m, "Flip queued on pipe %c (plane %c)\n",
 					   pipe, plane);
 			} else {
@@ -351,7 +351,7 @@ static int i915_gem_pageflip_info(struct
 				seq_printf(m, "Stall check enabled, ");
 			else
 				seq_printf(m, "Stall check waiting for page flip ioctl, ");
-			seq_printf(m, "%d prepares\n", work->pending);
+			seq_printf(m, "%d prepares\n", atomic_read(&work->pending));
 
 			if (work->old_fb_obj) {
 				struct drm_i915_gem_object *obj = work->old_fb_obj;
drivers/gpu/drm/i915/i915_irq.c +3 -1
@@ -1251,7 +1251,9 @@ static void i915_pageflip_stall_check(st
 	spin_lock_irqsave(&dev->event_lock, flags);
 	work = intel_crtc->unpin_work;
 
-	if (work == NULL || work->pending || !work->enable_stall_check) {
+	if (work == NULL ||
+	    atomic_read(&work->pending) >= INTEL_FLIP_COMPLETE ||
+	    !work->enable_stall_check) {
 		/* Either the pending flip IRQ arrived, or we're too early. Don't check */
 		spin_unlock_irqrestore(&dev->event_lock, flags);
 		return;
drivers/gpu/drm/i915/intel_display.c +32 -7
@@ -7245,11 +7245,18 @@ static void do_intel_finish_page_flip(st
 
 	spin_lock_irqsave(&dev->event_lock, flags);
 	work = intel_crtc->unpin_work;
-	if (work == NULL || !work->pending) {
+
+	/* Ensure we don't miss a work->pending update ... */
+	smp_rmb();
+
+	if (work == NULL || atomic_read(&work->pending) < INTEL_FLIP_COMPLETE) {
 		spin_unlock_irqrestore(&dev->event_lock, flags);
 		return;
 	}
 
+	/* and that the unpin work is consistent wrt ->pending. */
+	smp_rmb();
+
 	intel_crtc->unpin_work = NULL;
 
 	if (work->event) {
@@ -7321,16 +7328,25 @@ void intel_prepare_page_flip(struct drm_
 		to_intel_crtc(dev_priv->plane_to_crtc_mapping[plane]);
 	unsigned long flags;
 
+	/* NB: An MMIO update of the plane base pointer will also
+	 * generate a page-flip completion irq, i.e. every modeset
+	 * is also accompanied by a spurious intel_prepare_page_flip().
+	 */
 	spin_lock_irqsave(&dev->event_lock, flags);
-	if (intel_crtc->unpin_work) {
-		if ((++intel_crtc->unpin_work->pending) > 1)
-			DRM_ERROR("Prepared flip multiple times\n");
-	} else {
-		DRM_DEBUG_DRIVER("preparing flip with no unpin work?\n");
-	}
+	if (intel_crtc->unpin_work)
+		atomic_inc_not_zero(&intel_crtc->unpin_work->pending);
 	spin_unlock_irqrestore(&dev->event_lock, flags);
 }
 
+inline static void intel_mark_page_flip_active(struct intel_crtc *intel_crtc)
+{
+	/* Ensure that the work item is consistent when activating it ... */
+	smp_wmb();
+	atomic_set(&intel_crtc->unpin_work->pending, INTEL_FLIP_PENDING);
+	/* and that it is marked active as soon as the irq could fire. */
+	smp_wmb();
+}
+
 static int intel_gen2_queue_flip(struct drm_device *dev,
 				 struct drm_crtc *crtc,
 				 struct drm_framebuffer *fb,
@@ -7367,6 +7383,8 @@ static int intel_gen2_queue_flip(struct
 	OUT_RING(fb->pitches[0]);
 	OUT_RING(obj->gtt_offset + offset);
 	OUT_RING(0); /* aux display base address, unused */
+
+	intel_mark_page_flip_active(intel_crtc);
 	ADVANCE_LP_RING();
 	return 0;
 
@@ -7410,6 +7428,7 @@ static int intel_gen3_queue_flip(struct
 	OUT_RING(obj->gtt_offset + offset);
 	OUT_RING(MI_NOOP);
 
+	intel_mark_page_flip_active(intel_crtc);
 	ADVANCE_LP_RING();
 	return 0;
 
@@ -7453,6 +7472,8 @@ static int intel_gen4_queue_flip(struct
 	pf = 0;
 	pipesrc = I915_READ(PIPESRC(intel_crtc->pipe)) & 0x0fff0fff;
 	OUT_RING(pf | pipesrc);
+
+	intel_mark_page_flip_active(intel_crtc);
 	ADVANCE_LP_RING();
 	return 0;
 
@@ -7494,6 +7515,8 @@ static int intel_gen6_queue_flip(struct
 	pf = 0;
 	pipesrc = I915_READ(PIPESRC(intel_crtc->pipe)) & 0x0fff0fff;
 	OUT_RING(pf | pipesrc);
+
+	intel_mark_page_flip_active(intel_crtc);
 	ADVANCE_LP_RING();
 	return 0;
 
@@ -7548,6 +7571,8 @@ static int intel_gen7_queue_flip(struct
 	intel_ring_emit(ring, (fb->pitches[0] | obj->tiling_mode));
 	intel_ring_emit(ring, (obj->gtt_offset));
 	intel_ring_emit(ring, (MI_NOOP));
+
+	intel_mark_page_flip_active(intel_crtc);
 	intel_ring_advance(ring);
 	return 0;
 
drivers/gpu/drm/i915/intel_drv.h +4 -1
@@ -277,7 +277,10 @@ struct intel_unpin_work {
 	struct drm_i915_gem_object *old_fb_obj;
 	struct drm_i915_gem_object *pending_flip_obj;
 	struct drm_pending_vblank_event *event;
-	int pending;
+	atomic_t pending;
+#define INTEL_FLIP_INACTIVE	0
+#define INTEL_FLIP_PENDING	1
+#define INTEL_FLIP_COMPLETE	2
 	bool enable_stall_check;
 };
 
author maintainer
#172 lore raw

PATCH 167/214 drm/i915; Only increment the user-pin-count after successfully pinning the bo

In reply to Greg Kroah-Hartman

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

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

From: Chris Wilson <[email protected]>

commit 93be8788e648817d62fda33e2998eb6ca6ebf3a3 upstream.

As along the error path we do not correct the user pin-count for the failure, we may end up with userspace believing that it has a pinned object at offset 0 (when interrupted by a signal for example).

[bwh: Backported to 3.2: adjust context]
Cc Weng Meiling <[email protected]>
---
 drivers/gpu/drm/i915/i915_gem.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/i915_gem.c +4 -3
@@ -3411,14 +3411,15 @@ i915_gem_pin_ioctl(struct drm_device *de
 		goto out;
 	}
 
-	obj->user_pin_count++;
-	obj->pin_filp = file;
-	if (obj->user_pin_count == 1) {
+	if (obj->user_pin_count == 0) {
 		ret = i915_gem_object_pin(obj, args->alignment, true);
 		if (ret)
 			goto out;
 	}
 
+	obj->user_pin_count++;
+	obj->pin_filp = file;
+
 	/* XXX - flush the CPU caches for pinned objects
 	 * as the X server doesn't manage domains yet
 	 */
author maintainer
#173 lore raw

PATCH 168/214 drm/i915: dump UTS_RELEASE into the error_state

In reply to Greg Kroah-Hartman

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

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

From: Daniel Vetter <[email protected]>

commit 4518f611ba21ba165ea3714055938a8984a44ff9 upstream.

Useful for statistics or on overflowing bug reports to keep things all lined up.

[bwh: Backported to 3.2: adjust context]
Cc Weng Meiling <[email protected]>
---
 drivers/gpu/drm/i915/i915_debugfs.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/gpu/drm/i915/i915_debugfs.c +2 -0
@@ -30,6 +30,7 @@
 #include <linux/debugfs.h>
 #include <linux/slab.h>
 #include <linux/export.h>
+#include <generated/utsrelease.h>
 #include "drmP.h"
 #include "drm.h"
 #include "intel_drv.h"
@@ -750,6 +751,7 @@ static int i915_error_state(struct seq_f
 
 	seq_printf(m, "Time: %ld s %ld us\n", error->time.tv_sec,
 		   error->time.tv_usec);
+	seq_printf(m, "Kernel: " UTS_RELEASE);
 	seq_printf(m, "PCI ID: 0x%04x\n", dev->pci_device);
 	seq_printf(m, "EIR: 0x%08x\n", error->eir);
 	seq_printf(m, "PGTBL_ER: 0x%08x\n", error->pgtbl_er);
author maintainer
#174 lore raw

PATCH 169/214 drm/i915: add missing \n to UTS_RELEASE in the error_state

In reply to Greg Kroah-Hartman

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

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

From: Jani Nikula <[email protected]>

commit fdfa175d0a9cfa2082ce24e67e284e5acbba452a upstream.

Amending
commit 4518f611ba21ba165ea3714055938a8984a44ff9

Author: Daniel Vetter <[email protected]>
Date:   Wed Jan 23 16:16:35 2013 +0100

drm/i915: dump UTS_RELEASE into the error_state

---
 drivers/gpu/drm/i915/i915_debugfs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/i915_debugfs.c +1 -1
@@ -751,7 +751,7 @@ static int i915_error_state(struct seq_f
 
 	seq_printf(m, "Time: %ld s %ld us\n", error->time.tv_sec,
 		   error->time.tv_usec);
-	seq_printf(m, "Kernel: " UTS_RELEASE);
+	seq_printf(m, "Kernel: " UTS_RELEASE "\n");
 	seq_printf(m, "PCI ID: 0x%04x\n", dev->pci_device);
 	seq_printf(m, "EIR: 0x%08x\n", error->eir);
 	seq_printf(m, "PGTBL_ER: 0x%08x\n", error->pgtbl_er);
author maintainer
#175 lore raw

PATCH 170/214 drm/i915: panel: invert brightness via parameter

In reply to Greg Kroah-Hartman

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

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

From: Carsten Emde <[email protected]>

commit 7bd90909bbf9ce7c40e1da3d72b97b93839c188a upstream.

Following the documentation of the Legacy Backlight Brightness (LBB) Register in the configuration space of some Intel PCI graphics adapters, setting the LBB register with the value 0x0 causes the backlight to be turned off, and 0xFF causes the backlight to be set to 100% intensity
(http://download.intel.com/embedded/processors/Whitepaper/324567.pdf).
The Acer Aspire 5734Z, however, turns the backlight off at 0xFF and sets it to maximum intensity at 0. In consequence, the screen of this systems becomes dark at an early boot stage which makes it unusable. The same inversion applies to the BLC_PWM_CTL I915 register. This problem was introduced in kernel version 2.6.38 when the PCI device of this system was first supported by the i915 KMS module.

This patch adds a parameter to the i915 module to enable inversion of the brightness variable (i915.invert_brightness).

---
 Documentation/kernel-parameters.txt |    9 +++++++++
 drivers/gpu/drm/i915/intel_panel.c  |   17 +++++++++++++++++
 2 files changed, 26 insertions(+)
Documentation/kernel-parameters.txt +9 -0
@@ -993,6 +993,15 @@ bytes respectively. Such letter suffixes
 	i8k.restricted	[HW] Allow controlling fans only if SYS_ADMIN
 			capability is set.
 
+	i915.invert_brightness
+			[DRM] Invert the sense of the variable that is used to
+			set the brightness of the panel backlight. Normally a
+			value of 0 indicates backlight switched off, and the
+			maximum value sets the backlight to maximum brightness.
+			If this parameter is specified, a value of 0 sets the
+			backlight to maximum brightness, and the maximum value
+			switches the backlight off.
+
 	icn=		[HW,ISDN]
 			Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
 
drivers/gpu/drm/i915/intel_panel.c +17 -0
@@ -28,6 +28,7 @@
  *      Chris Wilson <[email protected]>
  */
 
+#include <linux/moduleparam.h>
 #include "intel_drv.h"
 
 #define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
@@ -189,6 +190,20 @@ u32 intel_panel_get_max_backlight(struct
 	return max;
 }
 
+static bool i915_panel_invert_brightness;
+MODULE_PARM_DESC(invert_brightness, "Invert backlight brightness, please "
+	"report PCI device ID, subsystem vendor and subsystem device ID "
+	"to [email protected], if your machine needs it. "
+	"It will then be included in an upcoming module version.");
+module_param_named(invert_brightness, i915_panel_invert_brightness, bool, 0600);
+static u32 intel_panel_compute_brightness(struct drm_device *dev, u32 val)
+{
+	if (i915_panel_invert_brightness)
+		return intel_panel_get_max_backlight(dev) - val;
+
+	return val;
+}
+
 u32 intel_panel_get_backlight(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
@@ -209,6 +224,7 @@ u32 intel_panel_get_backlight(struct drm
 		}
 	}
 
+	val = intel_panel_compute_brightness(dev, val);
 	DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
 	return val;
 }
@@ -226,6 +242,7 @@ static void intel_panel_actually_set_bac
 	u32 tmp;
 
 	DRM_DEBUG_DRIVER("set backlight PWM = %d\n", level);
+	level = intel_panel_compute_brightness(dev, level);
 
 	if (HAS_PCH_SPLIT(dev))
 		return intel_pch_panel_set_backlight(dev, level);
author maintainer
#176 lore raw

PATCH 171/214 drm/i915: panel: invert brightness via quirk

In reply to Greg Kroah-Hartman

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

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

From: Carsten Emde <[email protected]>

commit 4dca20efb1a9c2efefc28ad2867e5d6c3f5e1955 upstream.

A machine may need to invert the panel backlight brightness value. This patch adds the infrastructure for a quirk to do so.

[wml: Backported to 3.4:
- Adjust context
- one more flag QUIRK_NO_PCH_PWM_ENABLE]

---
 Documentation/kernel-parameters.txt  |   17 +++++++++++------
 drivers/gpu/drm/i915/i915_drv.h      |    3 ++-
 drivers/gpu/drm/i915/intel_display.c |    9 +++++++++
 drivers/gpu/drm/i915/intel_panel.c   |   15 +++++++++++----
 4 files changed, 33 insertions(+), 11 deletions(-)
Documentation/kernel-parameters.txt +11 -6
@@ -993,14 +993,19 @@ bytes respectively. Such letter suffixes
 	i8k.restricted	[HW] Allow controlling fans only if SYS_ADMIN
 			capability is set.
 
-	i915.invert_brightness
+	i915.invert_brightness=
 			[DRM] Invert the sense of the variable that is used to
 			set the brightness of the panel backlight. Normally a
-			value of 0 indicates backlight switched off, and the
-			maximum value sets the backlight to maximum brightness.
-			If this parameter is specified, a value of 0 sets the
-			backlight to maximum brightness, and the maximum value
-			switches the backlight off.
+			brightness value of 0 indicates backlight switched off,
+			and the maximum of the brightness value sets the backlight
+			to maximum brightness. If this parameter is set to 0
+			(default) and the machine requires it, or this parameter
+			is set to 1, a brightness value of 0 sets the backlight
+			to maximum brightness, and the maximum of the brightness
+			value switches the backlight off.
+			-1 -- never invert brightness
+			 0 -- machine default
+			 1 -- force brightness inversion
 
 	icn=		[HW,ISDN]
 			Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
drivers/gpu/drm/i915/i915_drv.h +2 -1
@@ -296,7 +296,8 @@ enum intel_pch {
 
 #define QUIRK_PIPEA_FORCE (1<<0)
 #define QUIRK_LVDS_SSC_DISABLE (1<<1)
-#define QUIRK_NO_PCH_PWM_ENABLE (1<<2)
+#define QUIRK_INVERT_BRIGHTNESS (1<<2)
+#define QUIRK_NO_PCH_PWM_ENABLE (1<<3)
 
 struct intel_fbdev;
 struct intel_fbc_work;
drivers/gpu/drm/i915/intel_display.c +9 -0
@@ -9200,6 +9200,15 @@ static void quirk_no_pcm_pwm_enable(stru
 	DRM_INFO("applying no-PCH_PWM_ENABLE quirk\n");
 }
 
+/*
+ * A machine may need to invert the panel backlight brightness value
+ */
+static void quirk_invert_brightness(struct drm_device *dev)
+{
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	dev_priv->quirks |= QUIRK_INVERT_BRIGHTNESS;
+}
+
 struct intel_quirk {
 	int device;
 	int subsystem_vendor;
drivers/gpu/drm/i915/intel_panel.c +11 -4
@@ -190,15 +190,22 @@ u32 intel_panel_get_max_backlight(struct
 	return max;
 }
 
-static bool i915_panel_invert_brightness;
-MODULE_PARM_DESC(invert_brightness, "Invert backlight brightness, please "
+static int i915_panel_invert_brightness;
+MODULE_PARM_DESC(invert_brightness, "Invert backlight brightness "
+	"(-1 force normal, 0 machine defaults, 1 force inversion), please "
 	"report PCI device ID, subsystem vendor and subsystem device ID "
 	"to [email protected], if your machine needs it. "
 	"It will then be included in an upcoming module version.");
-module_param_named(invert_brightness, i915_panel_invert_brightness, bool, 0600);
+module_param_named(invert_brightness, i915_panel_invert_brightness, int, 0600);
 static u32 intel_panel_compute_brightness(struct drm_device *dev, u32 val)
 {
-	if (i915_panel_invert_brightness)
+	struct drm_i915_private *dev_priv = dev->dev_private;
+
+	if (i915_panel_invert_brightness < 0)
+		return val;
+
+	if (i915_panel_invert_brightness > 0 ||
+	    dev_priv->quirks & QUIRK_INVERT_BRIGHTNESS)
 		return intel_panel_get_max_backlight(dev) - val;
 
 	return val;
author maintainer
#177 lore raw

PATCH 172/214 drm/i915: panel: invert brightness acer aspire 5734z

In reply to Greg Kroah-Hartman

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

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

commit 5a15ab5b93e4a3ebcd4fa6c76cf646a45e9cf806 upstream.

Mark the Acer Aspire 5734Z that this machines requires the module to invert the panel backlight brightness value after reading from and prior to writing to the PCI configuration space.

---
 drivers/gpu/drm/i915/intel_display.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/gpu/drm/i915/intel_display.c +5 -1
@@ -9201,7 +9201,8 @@ static void quirk_no_pcm_pwm_enable(stru
 }
 
 /*
- * A machine may need to invert the panel backlight brightness value
+ * A machine (e.g. Acer Aspire 5734Z) may need to invert the panel backlight
+ * brightness value
  */
 static void quirk_invert_brightness(struct drm_device *dev)
 {
@@ -9242,6 +9243,9 @@ struct intel_quirk intel_quirks[] = {
 	/* Sony Vaio Y cannot use SSC on LVDS */
 	{ 0x0046, 0x104d, 0x9076, quirk_ssc_force_disable },
 
+	/* Acer Aspire 5734Z must invert backlight brightness */
+	{ 0x2a42, 0x1025, 0x0459, quirk_invert_brightness },
+
 	/* Dell XPS13 HD Sandy Bridge */
 	{ 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable },
 	/* Dell XPS13 HD and XPS13 FHD Ivy Bridge */
author maintainer
#178 lore raw

PATCH 173/214 drm/i915: add quirk to invert brightness on eMachines G725

In reply to Greg Kroah-Hartman

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

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

From: Jani Nikula <[email protected]>

commit 1ffff60320879830e469e26062c18f75236822ba upstream.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59628

---
 drivers/gpu/drm/i915/intel_display.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/gpu/drm/i915/intel_display.c +3 -0
@@ -9246,6 +9246,9 @@ struct intel_quirk intel_quirks[] = {
 	/* Acer Aspire 5734Z must invert backlight brightness */
 	{ 0x2a42, 0x1025, 0x0459, quirk_invert_brightness },
 
+	/* Acer/eMachines G725 */
+	{ 0x2a42, 0x1025, 0x0210, quirk_invert_brightness },
+
 	/* Dell XPS13 HD Sandy Bridge */
 	{ 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable },
 	/* Dell XPS13 HD and XPS13 FHD Ivy Bridge */
author maintainer
#179 lore raw

PATCH 174/214 drm/i915: add quirk to invert brightness on eMachines e725

In reply to Greg Kroah-Hartman

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

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

From: Jani Nikula <[email protected]>

commit 01e3a8feb40e54b962a20fa7eb595c5efef5e109 upstream.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=31522#c35

[Note: There are more than one broken setups in the bug. This fixes one.]
[wml: Backported to 3.4: Adjust context]
---
 drivers/gpu/drm/i915/intel_display.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/gpu/drm/i915/intel_display.c +3 -0
@@ -9249,6 +9249,9 @@ struct intel_quirk intel_quirks[] = {
 	/* Acer/eMachines G725 */
 	{ 0x2a42, 0x1025, 0x0210, quirk_invert_brightness },
 
+	/* Acer/eMachines e725 */
+	{ 0x2a42, 0x1025, 0x0212, quirk_invert_brightness },
+
 	/* Dell XPS13 HD Sandy Bridge */
 	{ 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable },
 	/* Dell XPS13 HD and XPS13 FHD Ivy Bridge */
author maintainer
#180 lore raw

PATCH 175/214 drm/i915: add quirk to invert brightness on Packard Bell NCL20

In reply to Greg Kroah-Hartman

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

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

From: Jani Nikula <[email protected]>

commit 5559ecadad5a73b27f863e92f4b4f369501dce6f upstream.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44156

---
 drivers/gpu/drm/i915/intel_display.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/gpu/drm/i915/intel_display.c +3 -0
@@ -9252,6 +9252,9 @@ struct intel_quirk intel_quirks[] = {
 	/* Acer/eMachines e725 */
 	{ 0x2a42, 0x1025, 0x0212, quirk_invert_brightness },
 
+	/* Acer/Packard Bell NCL20 */
+	{ 0x2a42, 0x1025, 0x034b, quirk_invert_brightness },
+
 	/* Dell XPS13 HD Sandy Bridge */
 	{ 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable },
 	/* Dell XPS13 HD and XPS13 FHD Ivy Bridge */
author maintainer
#181 lore raw

PATCH 176/214 DRM/i915: Add QUIRK_INVERT_BRIGHTNESS for NCR machines.

In reply to Greg Kroah-Hartman

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

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

From: Egbert Eich <[email protected]>

commit 5f85f176c2f1c9d2a23f60ca0b99e4d0aa5a26a7 upstream.

NCR machines with LVDS panels using Intel chipsets need to have the QUIRK_INVERT_BRIGHTNESS bit set.
Unfortunately NCR doesn't set a meaningful subvendor/subdevice ID, therefore we add a DMI dependent quirk list.

[danvet: fixup whitespace fail.]

[bwh: Backported to 3.2:
- Adjust context
- Add #include <linux/dmi.h>]

---
 drivers/gpu/drm/i915/intel_display.c |   33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)
drivers/gpu/drm/i915/intel_display.c +33 -0
@@ -25,6 +25,7 @@
  */
 
 #include <linux/cpufreq.h>
+#include <linux/dmi.h>
 #include <linux/module.h>
 #include <linux/input.h>
 #include <linux/i2c.h>
@@ -9217,6 +9218,34 @@ struct intel_quirk {
 	void (*hook)(struct drm_device *dev);
 };
 
+/* For systems that don't have a meaningful PCI subdevice/subvendor ID */
+struct intel_dmi_quirk {
+	void (*hook)(struct drm_device *dev);
+	const struct dmi_system_id (*dmi_id_list)[];
+};
+
+static int intel_dmi_reverse_brightness(const struct dmi_system_id *id)
+{
+	DRM_INFO("Backlight polarity reversed on %s\n", id->ident);
+	return 1;
+}
+
+static const struct intel_dmi_quirk intel_dmi_quirks[] = {
+	{
+		.dmi_id_list = &(const struct dmi_system_id[]) {
+			{
+				.callback = intel_dmi_reverse_brightness,
+				.ident = "NCR Corporation",
+				.matches = {DMI_MATCH(DMI_SYS_VENDOR, "NCR Corporation"),
+					    DMI_MATCH(DMI_PRODUCT_NAME, ""),
+				},
+			},
+			{ }  /* terminating entry */
+		},
+		.hook = quirk_invert_brightness,
+	},
+};
+
 struct intel_quirk intel_quirks[] = {
 	/* HP Mini needs pipe A force quirk (LP: #322104) */
 	{ 0x27ae, 0x103c, 0x361a, quirk_pipea_force },
@@ -9276,6 +9305,10 @@ static void intel_init_quirks(struct drm
 		     q->subsystem_device == PCI_ANY_ID))
 			q->hook(dev);
 	}
+	for (i = 0; i < ARRAY_SIZE(intel_dmi_quirks); i++) {
+		if (dmi_check_system(*intel_dmi_quirks[i].dmi_id_list) != 0)
+			intel_dmi_quirks[i].hook(dev);
+	}
 }
 
 /* Disable the VGA plane that we never use */
author maintainer
#182 lore raw

PATCH 177/214 drm/radeon: use frac fb div on RS780/RS880

In reply to Greg Kroah-Hartman

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

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

From: Alex Deucher <[email protected]>

commit 411678288d61ba17afe1f8afed92200be6bbc65d upstream.

Monitors seem to prefer it. Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=37696

[bwh: Backported to 3.2:
- Adjust context
- Add to pll->flags, not radeon_crtc->pll_flags]

---
 drivers/gpu/drm/radeon/atombios_crtc.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/gpu/drm/radeon/atombios_crtc.c +3 -0
@@ -573,6 +573,9 @@ static u32 atombios_adjust_pll(struct dr
 		/* use frac fb div on APUs */
 		if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE61(rdev))
 			pll->flags |= RADEON_PLL_USE_FRAC_FB_DIV;
+		/* use frac fb div on RS780/RS880 */
+		if ((rdev->family == CHIP_RS780) || (rdev->family == CHIP_RS880))
+			pll->flags |= RADEON_PLL_USE_FRAC_FB_DIV;
 		if (ASIC_IS_DCE32(rdev) && mode->clock > 165000)
 			pll->flags |= RADEON_PLL_USE_FRAC_FB_DIV;
 	} else {
author maintainer
#183 lore raw

PATCH 178/214 drm/radeon: cleanup properly if mmio mapping fails

In reply to Greg Kroah-Hartman

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

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

From: Alex Deucher <[email protected]>

commit 0cd9cb76ae26a19df21abc6f94f5fff141e689c7 upstream.

If we fail to map the mmio BAR, skip driver tear down that requires mmio.

Should fix:
https://bugzilla.kernel.org/show_bug.cgi?id=56541

[bwh: Backported to 3.2: adjust context]
Cc Weng Meiling <[email protected]>
---
 drivers/gpu/drm/radeon/radeon_kms.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/gpu/drm/radeon/radeon_kms.c +4 -0
@@ -39,8 +39,12 @@ int radeon_driver_unload_kms(struct drm_
 
 	if (rdev == NULL)
 		return 0;
+	if (rdev->rmmio == NULL)
+		goto done_free;
 	radeon_modeset_fini(rdev);
 	radeon_device_fini(rdev);
+
+done_free:
 	kfree(rdev);
 	dev->dev_private = NULL;
 	return 0;
author maintainer
#184 lore raw

PATCH 179/214 drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

In reply to Greg Kroah-Hartman

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

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

From: Chris Wilson <[email protected]>

commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06 upstream.

In order to fully serialize access to the fenced region and the update to the fence register we need to take extreme measures on SNB+, and manually flush writes to memory prior to writing the fence register in conjunction with the memory barriers placed around the register write.

Fixes i-g-t/gem_fence_thrash

v2: Bring a bigger gun
v3: Switch the bigger gun for heavier bullets (Arjan van de Ven)
v4: Remove changes for working generations.
v5: Reduce to a per-cpu wbinvd() call prior to updating the fences.
v6: Rewrite comments to ellide forgotten history.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62191

Cc Jon Bloomfield <[email protected]>
[bwh: Backported to 3.2: insert the cache flush in i915_gem_object_get_fence()]
Cc Weng Meiling <[email protected]>
---
 drivers/gpu/drm/i915/i915_gem.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)
drivers/gpu/drm/i915/i915_gem.c +16 -0
@@ -2468,6 +2468,11 @@ i915_find_fence_reg(struct drm_device *d
 	return avail;
 }
 
+static void i915_gem_write_fence__ipi(void *data)
+{
+	wbinvd();
+}
+
 /**
  * i915_gem_object_get_fence - set up a fence reg for an object
  * @obj: object to map through a fence reg
@@ -2589,6 +2594,17 @@ update:
 	switch (INTEL_INFO(dev)->gen) {
 	case 7:
 	case 6:
+		/* In order to fully serialize access to the fenced region and
+		 * the update to the fence register we need to take extreme
+		 * measures on SNB+. In theory, the write to the fence register
+		 * flushes all memory transactions before, and coupled with the
+		 * mb() placed around the register write we serialise all memory
+		 * operations with respect to the changes in the tiler. Yet, on
+		 * SNB+ we need to take a step further and emit an explicit wbinvd()
+		 * on each processor in order to manually flush all memory
+		 * transactions before updating the fence register.
+		 */
+		on_each_cpu(i915_gem_write_fence__ipi, NULL, 1);
 		ret = sandybridge_write_fence_reg(obj, pipelined);
 		break;
 	case 5:
author maintainer
#185 lore raw

PATCH 180/214 drm/i915: ensure single initialization and cleanup of backlight device

In reply to Greg Kroah-Hartman

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

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

From: Jani Nikula <[email protected]>

commit dc652f90e088798bfa31f496ba994ddadd5d5680 upstream.

Backlight cleanup in the eDP connector destroy callback caused the backlight device to be removed on some systems that first initialized LVDS and then attempted to initialize eDP. Prevent multiple backlight initializations, and ensure backlight cleanup is only done once by moving it to modeset cleanup.

A small wrinkle is the introduced asymmetry in backlight setup/cleanup. This could be solved by adding refcounting, but it seems overkill considering that there should only ever be one backlight device.

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

[bwh: Backported to 3.2:
- Adjust context
- s/dev_priv->backlight\.device/dev_priv->backlight/]

---
 drivers/gpu/drm/i915/intel_display.c |    3 +++
 drivers/gpu/drm/i915/intel_dp.c      |    5 -----
 drivers/gpu/drm/i915/intel_lvds.c    |    2 --
 drivers/gpu/drm/i915/intel_panel.c   |    7 ++++++-
 4 files changed, 9 insertions(+), 8 deletions(-)
drivers/gpu/drm/i915/intel_display.c +3 -0
@@ -9471,6 +9471,9 @@ void intel_modeset_cleanup(struct drm_de
 	del_timer_sync(&dev_priv->idle_timer);
 	cancel_work_sync(&dev_priv->idle_work);
 
+	/* destroy backlight, if any, before the connectors */
+	intel_panel_destroy_backlight(dev);
+
 	drm_mode_config_cleanup(dev);
 }
 
drivers/gpu/drm/i915/intel_dp.c +0 -5
@@ -2289,11 +2289,6 @@ done:
 static void
 intel_dp_destroy(struct drm_connector *connector)
 {
-	struct drm_device *dev = connector->dev;
-
-	if (intel_dpd_is_edp(dev))
-		intel_panel_destroy_backlight(dev);
-
 	drm_sysfs_connector_remove(connector);
 	drm_connector_cleanup(connector);
 	kfree(connector);
drivers/gpu/drm/i915/intel_lvds.c +0 -2
@@ -553,8 +553,6 @@ static void intel_lvds_destroy(struct dr
 	struct drm_device *dev = connector->dev;
 	struct drm_i915_private *dev_priv = dev->dev_private;
 
-	intel_panel_destroy_backlight(dev);
-
 	if (dev_priv->lid_notifier.notifier_call)
 		acpi_lid_notifier_unregister(&dev_priv->lid_notifier);
 	drm_sysfs_connector_remove(connector);
drivers/gpu/drm/i915/intel_panel.c +6 -1
@@ -359,6 +359,9 @@ int intel_panel_setup_backlight(struct d
 
 	intel_panel_init_backlight(dev);
 
+	if (WARN_ON(dev_priv->backlight))
+		return -ENODEV;
+
 	if (dev_priv->int_lvds_connector)
 		connector = dev_priv->int_lvds_connector;
 	else if (dev_priv->int_edp_connector)
@@ -386,8 +389,10 @@ int intel_panel_setup_backlight(struct d
 void intel_panel_destroy_backlight(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
-	if (dev_priv->backlight)
+	if (dev_priv->backlight) {
 		backlight_device_unregister(dev_priv->backlight);
+		dev_priv->backlight = NULL;
+	}
 }
 #else
 int intel_panel_setup_backlight(struct drm_device *dev)
author maintainer
#186 lore raw

PATCH 181/214 drm/radeon: Another card with wrong primary dac adj

In reply to Greg Kroah-Hartman

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

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

From: Ondrej Zary <[email protected]>

commit f7929f34fa0e0bb6736a2484fdc07d77a1653081 upstream.

Hello,
got another card with "too bright" problem:
Sapphire Radeon VE 7000 DDR (VGA+S-Video)

lspci -vnn:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited Sapphire Radeon VE 7000 DDR [174b:7c28]

The patch below fixes the problem for this card.
But I don't like the blacklist, couldn't some heuristic be used instead? The interesting thing is that the manufacturer is the same as the other card needing the same quirk. I wonder how many different types are broken this way.

The "wrong" ps2_pdac_adj value that comes from BIOS on this card is 0x300.

====================
drm/radeon: Add primary dac adj quirk for Sapphire Radeon VE 7000 DDR

Values from BIOS are wrong, causing too bright colors. Use default values instead.

---
 drivers/gpu/drm/radeon/radeon_combios.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/gpu/drm/radeon/radeon_combios.c +6 -2
@@ -898,10 +898,14 @@ struct radeon_encoder_primary_dac *radeo
 	}
 
 	/* quirks */
+	/* Radeon 7000 (RV100) */
+	if (((dev->pdev->device == 0x5159) &&
+	    (dev->pdev->subsystem_vendor == 0x174B) &&
+	    (dev->pdev->subsystem_device == 0x7c28)) ||
 	/* Radeon 9100 (R200) */
-	if ((dev->pdev->device == 0x514D) &&
+	   ((dev->pdev->device == 0x514D) &&
 	    (dev->pdev->subsystem_vendor == 0x174B) &&
-	    (dev->pdev->subsystem_device == 0x7149)) {
+	    (dev->pdev->subsystem_device == 0x7149))) {
 		/* vbios value is bad, use the default */
 		found = 0;
 	}
author maintainer
#187 lore raw

PATCH 182/214 drm/i915: try not to lose backlight CBLV precision

In reply to Greg Kroah-Hartman

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

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

From: Jani Nikula <[email protected]>

commit cac6a5ae0118832936eb162ec4cedb30f2422bcc upstream.

ACPI has _BCM and _BQC methods to set and query the backlight brightness, respectively. The ACPI opregion has variables BCLP and CBLV to hold the requested and current backlight brightness, respectively.

The BCLP variable has range 0..255 while the others have range 0..100. This means the _BCM method has to scale the brightness for BCLP, and the gfx driver has to scale the requested value back for CBLV. If the _BQC method uses the CBLV variable (apparently some implementations do, some don't) for current backlight level reporting, there's room for rounding errors.

Use DIV_ROUND_UP for scaling back to CBLV to get back to the same values that were passed to _BCM, presuming the _BCM simply uses bclp = (in *
255) / 100 for scaling to BCLP.

Reference: https://gist.github.com/aaronlu/6314920

[bwh: Backported to 3.2:
- Adjust context
- ASLE region is treated as normal memory rather than __iomem]

---
 drivers/gpu/drm/i915/intel_opregion.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/intel_opregion.c +1 -1
@@ -161,7 +161,7 @@ static u32 asle_set_backlight(struct drm
 
 	max = intel_panel_get_max_backlight(dev);
 	intel_panel_set_backlight(dev, bclp * max / 255);
-	asle->cblv = (bclp*0x64)/0xff | ASLE_CBLV_VALID;
+	asle->cblv = DIV_ROUND_UP(bclp * 100, 255) | ASLE_CBLV_VALID;
 
 	return 0;
 }
author maintainer
#188 lore raw

PATCH 183/214 drm/radeon: fix panel scaling with eDP and LVDS bridges

In reply to Greg Kroah-Hartman

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

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

From: Alex Deucher <[email protected]>

commit 855f5f1d882a34e4e9dd27b299737cd3508a5624 upstream.

We were using the wrong set_properly callback so we always ended up with Full scaling even if something else (Center or Full aspect) was selected.

[bwh: Backported to 3.2: adjust context]
Cc Weng Meiling <[email protected]>
---
 drivers/gpu/drm/radeon/radeon_connectors.c |   34 ++++++++++++++++++++++++++---
 1 file changed, 31 insertions(+), 3 deletions(-)
drivers/gpu/drm/radeon/radeon_connectors.c +31 -3
@@ -1423,6 +1423,24 @@ struct drm_connector_funcs radeon_dp_con
 	.force = radeon_dvi_force,
 };
 
+static const struct drm_connector_funcs radeon_edp_connector_funcs = {
+	.dpms = drm_helper_connector_dpms,
+	.detect = radeon_dp_detect,
+	.fill_modes = drm_helper_probe_single_connector_modes,
+	.set_property = radeon_lvds_set_property,
+	.destroy = radeon_dp_connector_destroy,
+	.force = radeon_dvi_force,
+};
+
+static const struct drm_connector_funcs radeon_lvds_bridge_connector_funcs = {
+	.dpms = drm_helper_connector_dpms,
+	.detect = radeon_dp_detect,
+	.fill_modes = drm_helper_probe_single_connector_modes,
+	.set_property = radeon_lvds_set_property,
+	.destroy = radeon_dp_connector_destroy,
+	.force = radeon_dvi_force,
+};
+
 void
 radeon_add_atom_connector(struct drm_device *dev,
 			  uint32_t connector_id,
@@ -1514,8 +1532,6 @@ radeon_add_atom_connector(struct drm_dev
 			goto failed;
 		radeon_dig_connector->igp_lane_info = igp_lane_info;
 		radeon_connector->con_priv = radeon_dig_connector;
-		drm_connector_init(dev, &radeon_connector->base, &radeon_dp_connector_funcs, connector_type);
-		drm_connector_helper_add(&radeon_connector->base, &radeon_dp_connector_helper_funcs);
 		if (i2c_bus->valid) {
 			/* add DP i2c bus */
 			if (connector_type == DRM_MODE_CONNECTOR_eDP)
@@ -1532,6 +1548,10 @@ radeon_add_atom_connector(struct drm_dev
 		case DRM_MODE_CONNECTOR_VGA:
 		case DRM_MODE_CONNECTOR_DVIA:
 		default:
+			drm_connector_init(dev, &radeon_connector->base,
+					   &radeon_dp_connector_funcs, connector_type);
+			drm_connector_helper_add(&radeon_connector->base,
+						 &radeon_dp_connector_helper_funcs);
 			connector->interlace_allowed = true;
 			connector->doublescan_allowed = true;
 			radeon_connector->dac_load_detect = true;
@@ -1544,6 +1564,10 @@ radeon_add_atom_connector(struct drm_dev
 		case DRM_MODE_CONNECTOR_HDMIA:
 		case DRM_MODE_CONNECTOR_HDMIB:
 		case DRM_MODE_CONNECTOR_DisplayPort:
+			drm_connector_init(dev, &radeon_connector->base,
+					   &radeon_dp_connector_funcs, connector_type);
+			drm_connector_helper_add(&radeon_connector->base,
+						 &radeon_dp_connector_helper_funcs);
 			drm_connector_attach_property(&radeon_connector->base,
 						      rdev->mode_info.underscan_property,
 						      UNDERSCAN_OFF);
@@ -1568,6 +1592,10 @@ radeon_add_atom_connector(struct drm_dev
 			break;
 		case DRM_MODE_CONNECTOR_LVDS:
 		case DRM_MODE_CONNECTOR_eDP:
+			drm_connector_init(dev, &radeon_connector->base,
+					   &radeon_lvds_bridge_connector_funcs, connector_type);
+			drm_connector_helper_add(&radeon_connector->base,
+						 &radeon_dp_connector_helper_funcs);
 			drm_connector_attach_property(&radeon_connector->base,
 						      dev->mode_config.scaling_mode_property,
 						      DRM_MODE_SCALE_FULLSCREEN);
@@ -1731,7 +1759,7 @@ radeon_add_atom_connector(struct drm_dev
 				goto failed;
 			radeon_dig_connector->igp_lane_info = igp_lane_info;
 			radeon_connector->con_priv = radeon_dig_connector;
-			drm_connector_init(dev, &radeon_connector->base, &radeon_dp_connector_funcs, connector_type);
+			drm_connector_init(dev, &radeon_connector->base, &radeon_edp_connector_funcs, connector_type);
 			drm_connector_helper_add(&radeon_connector->base, &radeon_dp_connector_helper_funcs);
 			if (i2c_bus->valid) {
 				/* add DP i2c bus */
author maintainer
#189 lore raw

PATCH 184/214 drm: Pad drm_mode_get_connector to 64-bit boundary

In reply to Greg Kroah-Hartman

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

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

From: Chris Wilson <[email protected]>

commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream.

Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting the 4 bytes beyond the end of its structure with a 32-bit userspace running on a 64-bit kernel. This is due to the padding gcc inserts as the drm_mode_get_connector struct includes a u64 and its size is not a natural multiple of u64s.

64-bit kernel:

sizeof(drm_mode_get_connector)=80, alignof=8
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=4

32-bit userspace:

sizeof(drm_mode_get_connector)=76, alignof=4
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=4

Fortuituously we can insert explicit padding to the tail of our structures without breaking ABI.

---
 include/drm/drm_mode.h |    2 ++
 1 file changed, 2 insertions(+)
include/drm/drm_mode.h +2 -0
@@ -223,6 +223,8 @@ struct drm_mode_get_connector {
 	__u32 connection;
 	__u32 mm_width, mm_height; /**< HxW in millimeters */
 	__u32 subpixel;
+
+	__u32 pad;
 };
 
 #define DRM_MODE_PROP_PENDING	(1<<0)
author maintainer
#190 lore raw

PATCH 185/214 drm/ttm: Fix memory type compatibility check

In reply to Greg Kroah-Hartman

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

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

From: Thomas Hellstrom <[email protected]>

commit 59c8e66378fb78adbcd05f0d09783dde6fef282b upstream.

Also check the busy placements before deciding to move a buffer object. Failing to do this may result in a completely unneccessary move within a single memory type.

[bwh: Backported to 3.2: adjust context]
Cc Weng Meiling <[email protected]>
---
 drivers/gpu/drm/ttm/ttm_bo.c |   32 ++++++++++++++++++++------------
 1 file changed, 20 insertions(+), 12 deletions(-)
drivers/gpu/drm/ttm/ttm_bo.c +20 -12
@@ -1091,24 +1091,32 @@ out_unlock:
 	return ret;
 }
 
-static int ttm_bo_mem_compat(struct ttm_placement *placement,
-			     struct ttm_mem_reg *mem)
+static bool ttm_bo_mem_compat(struct ttm_placement *placement,
+			      struct ttm_mem_reg *mem,
+			      uint32_t *new_flags)
 {
 	int i;
 
 	if (mem->mm_node && placement->lpfn != 0 &&
 	    (mem->start < placement->fpfn ||
 	     mem->start + mem->num_pages > placement->lpfn))
-		return -1;
+		return false;
 
 	for (i = 0; i < placement->num_placement; i++) {
-		if ((placement->placement[i] & mem->placement &
-			TTM_PL_MASK_CACHING) &&
-			(placement->placement[i] & mem->placement &
-			TTM_PL_MASK_MEM))
-			return i;
+		*new_flags = placement->placement[i];
+		if ((*new_flags & mem->placement & TTM_PL_MASK_CACHING) &&
+		    (*new_flags & mem->placement & TTM_PL_MASK_MEM))
+			return true;
 	}
-	return -1;
+
+	for (i = 0; i < placement->num_busy_placement; i++) {
+		*new_flags = placement->busy_placement[i];
+		if ((*new_flags & mem->placement & TTM_PL_MASK_CACHING) &&
+		    (*new_flags & mem->placement & TTM_PL_MASK_MEM))
+			return true;
+	}
+
+	return false;
 }
 
 int ttm_bo_validate(struct ttm_buffer_object *bo,
@@ -1117,6 +1125,7 @@ int ttm_bo_validate(struct ttm_buffer_ob
 			bool no_wait_gpu)
 {
 	int ret;
+	uint32_t new_flags;
 
 	BUG_ON(!atomic_read(&bo->reserved));
 	/* Check that range is valid */
@@ -1127,8 +1136,7 @@ int ttm_bo_validate(struct ttm_buffer_ob
 	/*
 	 * Check whether we need to move buffer.
 	 */
-	ret = ttm_bo_mem_compat(placement, &bo->mem);
-	if (ret < 0) {
+	if (!ttm_bo_mem_compat(placement, &bo->mem, &new_flags)) {
 		ret = ttm_bo_move_buffer(bo, placement, interruptible, no_wait_reserve, no_wait_gpu);
 		if (ret)
 			return ret;
@@ -1137,7 +1145,7 @@ int ttm_bo_validate(struct ttm_buffer_ob
 		 * Use the access and other non-mapping-related flag bits from
 		 * the compatible memory placement flags to the active flags
 		 */
-		ttm_flag_masked(&bo->mem.placement, placement->placement[ret],
+		ttm_flag_masked(&bo->mem.placement, new_flags,
 				~TTM_PL_MASK_MEMTYPE);
 	}
 	/*
author maintainer
#191 lore raw

PATCH 186/214 drm/radeon: fix hdmi mode enable on RS600/RS690/RS740

In reply to Greg Kroah-Hartman

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

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

From: Alex Deucher <[email protected]>

commit dcb852905772416e322536ced5cb3c796d176af5 upstream.

These chips were previously skipped since they are pre-R600.

[bwh: Backported to 3.2: adjust context]

[wml: Backported to 3.4:
- adjust context
- no !ASIC_IS_DCE3(rdev)]

---
 drivers/gpu/drm/radeon/r600_hdmi.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/radeon/r600_hdmi.c +2 -2
@@ -530,7 +530,7 @@ void r600_hdmi_enable(struct drm_encoder
 		WREG32_P(radeon_encoder->hdmi_config_offset + 0x4, 0x1, ~0x1);
 	} else if (ASIC_IS_DCE3(rdev)) {
 		/* TODO */
-	} else if (rdev->family >= CHIP_R600) {
+	} else if (ASIC_IS_DCE2(rdev)) {
 		switch (radeon_encoder->encoder_id) {
 		case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
 			WREG32_P(AVIVO_TMDSA_CNTL, AVIVO_TMDSA_CNTL_HDMI_EN,
@@ -602,7 +602,7 @@ void r600_hdmi_disable(struct drm_encode
 		WREG32_P(radeon_encoder->hdmi_config_offset + 0xc, 0, ~0x1);
 	} else if (ASIC_IS_DCE32(rdev)) {
 		WREG32_P(radeon_encoder->hdmi_config_offset + 0x4, 0, ~0x1);
-	} else if (rdev->family >= CHIP_R600 && !ASIC_IS_DCE3(rdev)) {
+	} else if (ASIC_IS_DCE2(rdev) && !ASIC_IS_DCE3(rdev)) {
 		switch (radeon_encoder->encoder_id) {
 		case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
 			WREG32_P(AVIVO_TMDSA_CNTL, 0,
author maintainer
#192 lore raw

PATCH 187/214 drm/radeon: always program the MC on startup

In reply to Greg Kroah-Hartman

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

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

From: Alex Deucher <[email protected]>

commit 6fab3febf6d949b0a12b1e4e73db38e4a177a79e upstream.

For r6xx+ asics. This mirrors the behavior of pre-r6xx asics. We need to program the MC even if something else in startup() fails. Failure to do so results in an unusable GPU.

Based on a fix from: Mark Kettenis <[email protected]>

[wml: Backported to 3.4:
- adjust context
- drop changes to cik.c]

---
 drivers/gpu/drm/radeon/evergreen.c |    3 ++-
 drivers/gpu/drm/radeon/ni.c        |    3 ++-
 drivers/gpu/drm/radeon/r600.c      |    3 ++-
 drivers/gpu/drm/radeon/rv770.c     |    3 ++-
 drivers/gpu/drm/radeon/si.c        |    3 ++-
 5 files changed, 10 insertions(+), 5 deletions(-)
drivers/gpu/drm/radeon/evergreen.c +2 -1
@@ -3219,6 +3219,8 @@ static int evergreen_startup(struct rade
 	/* enable pcie gen2 link */
 	evergreen_pcie_gen2_enable(rdev);
 
+	evergreen_mc_program(rdev);
+
 	if (ASIC_IS_DCE5(rdev)) {
 		if (!rdev->me_fw || !rdev->pfp_fw || !rdev->rlc_fw || !rdev->mc_fw) {
 			r = ni_init_microcode(rdev);
@@ -3246,7 +3248,6 @@ static int evergreen_startup(struct rade
 	if (r)
 		return r;
 
-	evergreen_mc_program(rdev);
 	if (rdev->flags & RADEON_IS_AGP) {
 		evergreen_agp_enable(rdev);
 	} else {
drivers/gpu/drm/radeon/ni.c +2 -1
@@ -1552,6 +1552,8 @@ static int cayman_startup(struct radeon_
 	/* enable pcie gen2 link */
 	evergreen_pcie_gen2_enable(rdev);
 
+	evergreen_mc_program(rdev);
+
 	if (rdev->flags & RADEON_IS_IGP) {
 		if (!rdev->me_fw || !rdev->pfp_fw || !rdev->rlc_fw) {
 			r = ni_init_microcode(rdev);
@@ -1580,7 +1582,6 @@ static int cayman_startup(struct radeon_
 	if (r)
 		return r;
 
-	evergreen_mc_program(rdev);
 	r = cayman_pcie_gart_enable(rdev);
 	if (r)
 		return r;
drivers/gpu/drm/radeon/r600.c +2 -1
@@ -2431,6 +2431,8 @@ int r600_startup(struct radeon_device *r
 	/* enable pcie gen2 link */
 	r600_pcie_gen2_enable(rdev);
 
+	r600_mc_program(rdev);
+
 	if (!rdev->me_fw || !rdev->pfp_fw || !rdev->rlc_fw) {
 		r = r600_init_microcode(rdev);
 		if (r) {
@@ -2443,7 +2445,6 @@ int r600_startup(struct radeon_device *r
 	if (r)
 		return r;
 
-	r600_mc_program(rdev);
 	if (rdev->flags & RADEON_IS_AGP) {
 		r600_agp_enable(rdev);
 	} else {
drivers/gpu/drm/radeon/rv770.c +2 -1
@@ -1058,6 +1058,8 @@ static int rv770_startup(struct radeon_d
 	/* enable pcie gen2 link */
 	rv770_pcie_gen2_enable(rdev);
 
+	rv770_mc_program(rdev);
+
 	if (!rdev->me_fw || !rdev->pfp_fw || !rdev->rlc_fw) {
 		r = r600_init_microcode(rdev);
 		if (r) {
@@ -1070,7 +1072,6 @@ static int rv770_startup(struct radeon_d
 	if (r)
 		return r;
 
-	rv770_mc_program(rdev);
 	if (rdev->flags & RADEON_IS_AGP) {
 		rv770_agp_enable(rdev);
 	} else {
drivers/gpu/drm/radeon/si.c +2 -1
@@ -3834,6 +3834,8 @@ static int si_startup(struct radeon_devi
 	struct radeon_ring *ring;
 	int r;
 
+	si_mc_program(rdev);
+
 	if (!rdev->me_fw || !rdev->pfp_fw || !rdev->ce_fw ||
 	    !rdev->rlc_fw || !rdev->mc_fw) {
 		r = si_init_microcode(rdev);
@@ -3853,7 +3855,6 @@ static int si_startup(struct radeon_devi
 	if (r)
 		return r;
 
-	si_mc_program(rdev);
 	r = si_pcie_gart_enable(rdev);
 	if (r)
 		return r;
author maintainer
#193 lore raw

PATCH 188/214 drivers/rtc/rtc-pl031.c: fix the missing operation on enable

In reply to Greg Kroah-Hartman

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

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

From: Haojian Zhuang <[email protected]>

commit e7e034e18a0ab6bafb2425c3242cac311164f4d6 upstream.

The RTC control register should be enabled in the process of initializing.

Without this patch, I failed to enable RTC in Hisilicon Hi3620 SoC. The register mapping section in RTC is always read as zero. So I doubt that ST guys may already enable this register in bootloader. So they won't meet this issue.

Cc Srinidhi Kasagar <[email protected]>
Cc Linus Walleij <[email protected]>
Cc Alessandro Zummo <[email protected]>
[bwh: Backported to 3.2: adjust context]
Cc Qiang Huang <[email protected]>
---
 drivers/rtc/rtc-pl031.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/rtc/rtc-pl031.c +5 -3
@@ -44,6 +44,7 @@
 #define RTC_YMR		0x34	/* Year match register */
 #define RTC_YLR		0x38	/* Year data load register */
 
+#define RTC_CR_EN	(1 << 0)	/* counter enable bit */
 #define RTC_CR_CWEN	(1 << 26)	/* Clockwatch enable bit */
 
 #define RTC_TCR_EN	(1 << 1) /* Periodic timer enable bit */
@@ -312,7 +313,7 @@ static int pl031_probe(struct amba_devic
 	int ret;
 	struct pl031_local *ldata;
 	struct rtc_class_ops *ops = id->data;
-	unsigned long time;
+	unsigned long time, data;
 
 	ret = amba_request_regions(adev, NULL);
 	if (ret)
@@ -339,10 +340,11 @@ static int pl031_probe(struct amba_devic
 	dev_dbg(&adev->dev, "designer ID = 0x%02x\n", ldata->hw_designer);
 	dev_dbg(&adev->dev, "revision = 0x%01x\n", ldata->hw_revision);
 
+	data = readl(ldata->base + RTC_CR);
 	/* Enable the clockwatch on ST Variants */
 	if (ldata->hw_designer == AMBA_VENDOR_ST)
-		writel(readl(ldata->base + RTC_CR) | RTC_CR_CWEN,
-		       ldata->base + RTC_CR);
+		data |= RTC_CR_CWEN;
+	writel(data | RTC_CR_EN, ldata->base + RTC_CR);
 
 	/*
 	 * On ST PL031 variants, the RTC reset value does not provide correct
author maintainer
#194 lore raw

PATCH 189/214 wireless: rt2x00: rt{2500,73}usb.c put back duplicate id

In reply to Greg Kroah-Hartman

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

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

From: Xose Vazquez Perez <[email protected]>

commit 8f35f787b75e9b6435ea37dabcae2d40dc72d31c upstream.

put back 0x050d,0x7050 to rt73usb, same usb_id for two chips:

K7SF5D7050A ver 2xxx is rt2500
K7SF5D7050B ver 3xxx is rt73

<http://en-us-support.belkin.com/app/answers/detail/a_id/297/kw/K7SF5D7050>

---
 drivers/net/wireless/rt2x00/rt2500usb.c |    2 +-
 drivers/net/wireless/rt2x00/rt73usb.c   |    1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
drivers/net/wireless/rt2x00/rt2500usb.c +1 -1
@@ -1921,7 +1921,7 @@ static struct usb_device_id rt2500usb_de
 	{ USB_DEVICE(0x0b05, 0x1706) },
 	{ USB_DEVICE(0x0b05, 0x1707) },
 	/* Belkin */
-	{ USB_DEVICE(0x050d, 0x7050) },
+	{ USB_DEVICE(0x050d, 0x7050) },	/* FCC ID: K7SF5D7050A ver. 2.x */
 	{ USB_DEVICE(0x050d, 0x7051) },
 	/* Cisco Systems */
 	{ USB_DEVICE(0x13b1, 0x000d) },
drivers/net/wireless/rt2x00/rt73usb.c +1 -0
@@ -2422,6 +2422,7 @@ static struct usb_device_id rt73usb_devi
 	{ USB_DEVICE(0x0b05, 0x1723) },
 	{ USB_DEVICE(0x0b05, 0x1724) },
 	/* Belkin */
+	{ USB_DEVICE(0x050d, 0x7050) },	/* FCC ID: K7SF5D7050B ver. 3.x */
 	{ USB_DEVICE(0x050d, 0x705a) },
 	{ USB_DEVICE(0x050d, 0x905b) },
 	{ USB_DEVICE(0x050d, 0x905c) },
author maintainer
#195 lore raw

PATCH 190/214 Wireless: rt2x00: Add device id for Sweex LW323 to rt2800usb.c

In reply to Greg Kroah-Hartman

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

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

From: =?UTF-8?q?Jaume=20Delcl=C3=B2s?= <[email protected]>

commit 36f318bb124b231c01db6965a009f46d5731f012 upstream.

This patch adds detection for the Sweex LW323 USB wireless network card in the rt2x00 driver (just one line in rt2800usb.c).
It applies to linux-3.7-rc3.

---
 drivers/net/wireless/rt2x00/rt2800usb.c |    1 +
 1 file changed, 1 insertion(+)
drivers/net/wireless/rt2x00/rt2800usb.c +1 -0
@@ -1140,6 +1140,7 @@ static struct usb_device_id rt2800usb_de
 	{ USB_DEVICE(0x177f, 0x0153) },
 	{ USB_DEVICE(0x177f, 0x0302) },
 	{ USB_DEVICE(0x177f, 0x0313) },
+	{ USB_DEVICE(0x177f, 0x0323) },
 	/* U-Media */
 	{ USB_DEVICE(0x157e, 0x300e) },
 	{ USB_DEVICE(0x157e, 0x3013) },
author maintainer
#196 lore raw

PATCH 191/214 rt2800usb: Add support for 2001:3c1e (D-Link DWA-125 rev B1) USB Wi-Fi adapter

In reply to Greg Kroah-Hartman

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

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

From: Maia Kozheva <[email protected]>

commit fd7b9270120ca7e53fbf0469febe0c68acf6a0a2 upstream.

D-Link DWA-125/B1 is a relatively new USB Wi-Fi adapter, using a Ralink chipset supported by the rt2800usb driver. Currently, to work around the problem (it's missing in all present kernel versions, up to and including 3.7.x), I had to add this to /etc/rc.local:

echo 2001 3c1e >> /sys/bus/usb/drivers/rt2800usb/new_id

After that, the device works without problems. Been using it for over a week with no bugs in sight.

The attached patch is trivial and simply adds the new USB ID to the list of devices handled by rt2800usb.

---
 drivers/net/wireless/rt2x00/rt2800usb.c |    1 +
 1 file changed, 1 insertion(+)
drivers/net/wireless/rt2x00/rt2800usb.c +1 -0
@@ -1009,6 +1009,7 @@ static struct usb_device_id rt2800usb_de
 	{ USB_DEVICE(0x07d1, 0x3c15) },
 	{ USB_DEVICE(0x07d1, 0x3c16) },
 	{ USB_DEVICE(0x2001, 0x3c1b) },
+	{ USB_DEVICE(0x2001, 0x3c1e) },
 	/* Draytek */
 	{ USB_DEVICE(0x07fa, 0x7712) },
 	/* DVICO */
author maintainer
#197 lore raw

PATCH 192/214 drivers/rtc/rtc-pl031.c: restore ST variant functionality

In reply to Greg Kroah-Hartman

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

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

From: Linus Walleij <[email protected]>

commit 3399cfb5df9594495b876d1843a7165f77366b2b upstream.

Commit e7e034e18a0a ("drivers/rtc/rtc-pl031.c: fix the missing operation on enable") accidentally broke the ST variants of PL031.

The bit that is being poked as "clockwatch" enable bit for the ST variants does the work of bit 0 on this variant. Bit 0 is used for a clock divider on the ST variants, and setting it to 1 will affect timekeeping in a very bad way.

---
 drivers/rtc/rtc-pl031.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/rtc/rtc-pl031.c +3 -1
@@ -344,7 +344,9 @@ static int pl031_probe(struct amba_devic
 	/* Enable the clockwatch on ST Variants */
 	if (ldata->hw_designer == AMBA_VENDOR_ST)
 		data |= RTC_CR_CWEN;
-	writel(data | RTC_CR_EN, ldata->base + RTC_CR);
+	else
+		data |= RTC_CR_EN;
+	writel(data, ldata->base + RTC_CR);
 
 	/*
 	 * On ST PL031 variants, the RTC reset value does not provide correct
author maintainer
#198 lore raw

PATCH 193/214 ata_piix: Add Device IDs for Intel Lynx Point-LP PCH

In reply to Greg Kroah-Hartman

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

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

From: James Ralston <[email protected]>

commit 389cd784969e9148fedcde0608f15bd74d6b769e upstream.

This patch adds the IDE-mode SATA Device IDs for the Intel Lynx Point-LP PCH

---
 drivers/ata/ata_piix.c |    8 ++++++++
 1 file changed, 8 insertions(+)
drivers/ata/ata_piix.c +8 -0
@@ -331,6 +331,14 @@ static const struct pci_device_id piix_p
 	{ 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_snb },
 	/* SATA Controller IDE (Lynx Point) */
 	{ 0x8086, 0x8c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+	/* SATA Controller IDE (Lynx Point-LP) */
+	{ 0x8086, 0x9c00, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+	/* SATA Controller IDE (Lynx Point-LP) */
+	{ 0x8086, 0x9c01, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+	/* SATA Controller IDE (Lynx Point-LP) */
+	{ 0x8086, 0x9c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+	/* SATA Controller IDE (Lynx Point-LP) */
+	{ 0x8086, 0x9c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
 	/* SATA Controller IDE (DH89xxCC) */
 	{ 0x8086, 0x2326, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
 	/* SATA Controller IDE (Avoton) */
author maintainer
#199 lore raw

PATCH 194/214 speakup: lower default software speech rate

In reply to Greg Kroah-Hartman

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

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

From: Samuel Thibault <[email protected]>

commit cfd757010691eae4e17acc246f74e7622c3a2f05 upstream.

Speech synthesis beginners need a low speech rate, and trained people want a high speech rate. A medium speech rate is thus actually not a good default for neither. Since trained people will typically know how to change the rate, better default for a low speech rate, which beginners can grasp and learn how to increase it afterwards

This was agreed with users on the speakup mailing list.

---
 drivers/staging/speakup/speakup_soft.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/speakup/speakup_soft.c +1 -1
@@ -46,7 +46,7 @@ static int misc_registered;
 static struct var_t vars[] = {
 	{ CAPS_START, .u.s = {"\x01+3p" } },
 	{ CAPS_STOP, .u.s = {"\x01-3p" } },
-	{ RATE, .u.n = {"\x01%ds", 5, 0, 9, 0, 0, NULL } },
+	{ RATE, .u.n = {"\x01%ds", 2, 0, 9, 0, 0, NULL } },
 	{ PITCH, .u.n = {"\x01%dp", 5, 0, 9, 0, 0, NULL } },
 	{ VOL, .u.n = {"\x01%dv", 5, 0, 9, 0, 0, NULL } },
 	{ TONE, .u.n = {"\x01%dx", 1, 0, 2, 0, 0, NULL } },
author maintainer
#200 lore raw

PATCH 195/214 i2c: tegra: check the clk_prepare_enable() return value

In reply to Greg Kroah-Hartman

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

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

From: Laxman Dewangan <[email protected]>

commit 132c803f7b70b17322579f6f4f3f65cf68e55135 upstream.

NVIDIA's Tegra SoC allows read/write of controller register only if controller clock is enabled. System hangs if read/write happens to registers without enabling clock.

clk_prepare_enable() can be fail due to unknown reason and hence adding check for return value of this function. If this function success then only access register otherwise return to caller with error.

[bwh: Backported to 3.2:
- Adjust context
- Keep calling clk_enable() directly]

---
 drivers/i2c/busses/i2c-tegra.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
drivers/i2c/busses/i2c-tegra.c +11 -2
@@ -341,7 +341,11 @@ static int tegra_i2c_init(struct tegra_i
 	u32 val;
 	int err = 0;
 
-	clk_enable(i2c_dev->clk);
+	err = clk_enable(i2c_dev->clk);
+	if (err < 0) {
+		dev_err(i2c_dev->dev, "Clock enable failed %d\n", err);
+		return err;
+	}
 
 	tegra_periph_reset_assert(i2c_dev->clk);
 	udelay(2);
@@ -543,7 +547,12 @@ static int tegra_i2c_xfer(struct i2c_ada
 	if (i2c_dev->is_suspended)
 		return -EBUSY;
 
-	clk_enable(i2c_dev->clk);
+	ret = clk_enable(i2c_dev->clk);
+	if (ret < 0) {
+		dev_err(i2c_dev->dev, "Clock enable failed %d\n", ret);
+		return ret;
+	}
+
 	for (i = 0; i < num; i++) {
 		int stop = (i == (num - 1)) ? 1  : 0;
 		ret = tegra_i2c_xfer_msg(i2c_dev, &msgs[i], stop);
author maintainer
#201 lore raw

PATCH 196/214 ixgbe: fix registration order of driver and DCA nofitication

In reply to Greg Kroah-Hartman

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

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

From: Jakub Kicinski <[email protected]>

commit f01fc1a82c2ee68726b400fadb156bd623b5f2f1 upstream.

ixgbe_notify_dca cannot be called before driver registration because it expects driver's klist_devices to be allocated and initialized. While on it make sure debugfs files are removed when registration fails.

---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +5 -2
@@ -7464,12 +7464,15 @@ static int __init ixgbe_init_module(void
 	pr_info("%s - version %s\n", ixgbe_driver_string, ixgbe_driver_version);
 	pr_info("%s\n", ixgbe_copyright);
 
+	ret = pci_register_driver(&ixgbe_driver);
+	if (ret)
+		return ret;
+
 #ifdef CONFIG_IXGBE_DCA
 	dca_register_notify(&dca_notifier);
 #endif
 
-	ret = pci_register_driver(&ixgbe_driver);
-	return ret;
+	return 0;
 }
 
 module_init(ixgbe_init_module);
author maintainer
#202 lore raw

PATCH 197/214 msi-wmi: Fix memory leak

In reply to Greg Kroah-Hartman

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

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

From: Maxim Mikityanskiy <[email protected]>

commit 51c94491c82c3d9029f6e87a1a153db321d88e35 upstream.

Fix memory leak - don't forget to kfree ACPI object when returning from msi_wmi_notify() after suppressing key event.

---
 drivers/platform/x86/msi-wmi.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/platform/x86/msi-wmi.c +3 -1
@@ -176,7 +176,7 @@ static void msi_wmi_notify(u32 value, vo
 				pr_debug("Suppressed key event 0x%X - "
 					 "Last press was %lld us ago\n",
 					 key->code, ktime_to_us(diff));
-				return;
+				goto msi_wmi_notify_exit;
 			}
 			last_pressed[key->code - SCANCODE_BASE] = cur;
 
@@ -195,6 +195,8 @@ static void msi_wmi_notify(u32 value, vo
 			pr_info("Unknown key pressed - %x\n", eventcode);
 	} else
 		pr_info("Unknown event received\n");
+
+msi_wmi_notify_exit:
 	kfree(response.pointer);
 }
 
author maintainer
#203 lore raw

PATCH 198/214 rapidio/tsi721: fix bug in MSI interrupt handling

In reply to Greg Kroah-Hartman

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

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

From: Alexandre Bounine <[email protected]>

commit 1ccc819da6fda9bee10ab8b72e9adbb5ad3e4959 upstream.

Fix bug in MSI interrupt handling which causes loss of event notifications.

Typical indication of lost MSI interrupts are stalled message and doorbell transfers between RapidIO endpoints. To avoid loss of MSI interrupts all interrupts from the device must be disabled on entering the interrupt handler routine and re-enabled when exiting it. Re-enabling device interrupts will trigger new MSI message(s) if Tsi721 registered new events since entering interrupt handler routine.

This patch is applicable to kernel versions starting from v3.2.

Cc Matt Porter <[email protected]>
[bwh: Backported to 3.2: adjust context]
Cc Qiang Huang <[email protected]>
---
 drivers/rapidio/devices/tsi721.c |   11 +++++++++++
 1 file changed, 11 insertions(+)
drivers/rapidio/devices/tsi721.c +11 -0
@@ -475,6 +475,10 @@ static irqreturn_t tsi721_irqhandler(int
 	u32 intval;
 	u32 ch_inte;
 
+	/* For MSI mode disable all device-level interrupts */
+	if (priv->flags & TSI721_USING_MSI)
+		iowrite32(0, priv->regs + TSI721_DEV_INTE);
+
 	dev_int = ioread32(priv->regs + TSI721_DEV_INT);
 	if (!dev_int)
 		return IRQ_NONE;
@@ -548,6 +552,13 @@ static irqreturn_t tsi721_irqhandler(int
 			tsi721_pw_handler(mport);
 	}
 
+	/* For MSI mode re-enable device-level interrupts */
+	if (priv->flags & TSI721_USING_MSI) {
+		dev_int = TSI721_DEV_INT_SR2PC_CH | TSI721_DEV_INT_SRIO |
+			TSI721_DEV_INT_SMSG_CH | TSI721_DEV_INT_BDMA_CH;
+		iowrite32(dev_int, priv->regs + TSI721_DEV_INTE);
+	}
+
 	return IRQ_HANDLED;
 }
 
author maintainer
#204 lore raw

PATCH 199/214 rapidio/tsi721: Fix interrupt mask when handling MSI

In reply to Greg Kroah-Hartman

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

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

From: Ben Hutchings <[email protected]>

commit 94e0104bca7d6927e85119030b8e6e31fde88a7a upstream.

Commit 1619f441963e 'rapidio/tsi721: fix bug in MSI interrupt handling' (commit 1ccc819da6fd upstream) makes the MSI handler disable and re-enable interrupts. When re-enabling interrupts, we should set the same flags as were originally set, but this changed in Linux 3.5 so the flags are now inconsistent in 3.2. In fact, the extra flag isn't even defined in 3.2. Remove the extra flag from the MSI handler.

---
 drivers/rapidio/devices/tsi721.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/rapidio/devices/tsi721.c +1 -1
@@ -555,7 +555,7 @@ static irqreturn_t tsi721_irqhandler(int
 	/* For MSI mode re-enable device-level interrupts */
 	if (priv->flags & TSI721_USING_MSI) {
 		dev_int = TSI721_DEV_INT_SR2PC_CH | TSI721_DEV_INT_SRIO |
-			TSI721_DEV_INT_SMSG_CH | TSI721_DEV_INT_BDMA_CH;
+			TSI721_DEV_INT_SMSG_CH;
 		iowrite32(dev_int, priv->regs + TSI721_DEV_INTE);
 	}
 
author maintainer
#205 lore raw

PATCH 200/214 random: fix accounting race condition with lockless irq entropy_count update

In reply to Greg Kroah-Hartman

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

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

From: Jiri Kosina <[email protected]>

commit 10b3a32d292c21ea5b3ad5ca5975e88bb20b8d68 upstream.

Commit 902c098a3663 ("random: use lockless techniques in the interrupt path") turned IRQ path from being spinlock protected into lockless cmpxchg-retry update.

That commit removed r->lock serialization between crediting entropy bits from IRQ context and accounting when extracting entropy on userspace read path, but didn't turn the r->entropy_count reads/updates in account() to use cmpxchg as well.

It has been observed, that under certain circumstances this leads to read() on /dev/urandom to return 0 (EOF), as r->entropy_count gets corrupted and becomes negative, which in turn results in propagating 0 all the way from account() to the actual read() call.

Convert the accounting code to be the proper lockless counterpart of what has been partially done by 902c098a3663.

Cc Theodore Ts'o <[email protected]>
Cc Greg KH <[email protected]>
[bwh: Backported to 3.2: adjust context]
Cc Qiang Huang <[email protected]>
---
 drivers/char/random.c |   22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)
drivers/char/random.c +15 -7
@@ -867,16 +867,24 @@ static size_t account(struct entropy_sto
 	if (r->entropy_count / 8 < min + reserved) {
 		nbytes = 0;
 	} else {
+		int entropy_count, orig;
+retry:
+		entropy_count = orig = ACCESS_ONCE(r->entropy_count);
 		/* If limited, never pull more than available */
-		if (r->limit && nbytes + reserved >= r->entropy_count / 8)
-			nbytes = r->entropy_count/8 - reserved;
+		if (r->limit && nbytes + reserved >= entropy_count / 8)
+			nbytes = entropy_count/8 - reserved;
 
-		if (r->entropy_count / 8 >= nbytes + reserved)
-			r->entropy_count -= nbytes*8;
-		else
-			r->entropy_count = reserved;
+		if (entropy_count / 8 >= nbytes + reserved) {
+			entropy_count -= nbytes*8;
+			if (cmpxchg(&r->entropy_count, orig, entropy_count) != orig)
+				goto retry;
+		} else {
+			entropy_count = reserved;
+			if (cmpxchg(&r->entropy_count, orig, entropy_count) != orig)
+				goto retry;
+		}
 
-		if (r->entropy_count < random_write_wakeup_thresh) {
+		if (entropy_count < random_write_wakeup_thresh) {
 			wake_up_interruptible(&random_write_wait);
 			kill_fasync(&fasync, SIGIO, POLL_OUT);
 		}
author maintainer
#206 lore raw

PATCH 201/214 cfg80211: check wdev->netdev in connection work

In reply to Greg Kroah-Hartman

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

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

From: Johannes Berg <[email protected]>

commit c815797663b72e3ac1736f1886538152bc48e4af upstream.

If a P2P-Device is present and another virtual interface triggers the connection work, the system crash because it tries to check if the P2P-Device's netdev (which doesn't exist) is up. Skip any wdevs that have no netdev to fix this.

[bwh: Backported to 3.2: adjust context]
Cc Qiang Huang <[email protected]>
---
 net/wireless/sme.c |    3 +++
 1 file changed, 3 insertions(+)
net/wireless/sme.c +3 -0
@@ -222,6 +222,9 @@ void cfg80211_conn_work(struct work_stru
 	mutex_lock(&rdev->devlist_mtx);
 
 	list_for_each_entry(wdev, &rdev->netdev_list, list) {
+		if (!wdev->netdev)
+			continue;
+
 		wdev_lock(wdev);
 		if (!netif_running(wdev->netdev)) {
 			wdev_unlock(wdev);
author maintainer
#207 lore raw

PATCH 202/214 i2c-piix4: Add AMD CZ SMBus device ID

In reply to Greg Kroah-Hartman

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

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

From: Shane Huang <[email protected]>

commit b996ac90f595dda271cbd858b136b45557fc1a57 upstream.

To add AMD CZ SMBus controller device ID.

[bhelgaas: drop pci_ids.h update]
[bwh: Backported to 3.2: adjust context]
Cc Qiang Huang <[email protected]>
---
 Documentation/i2c/busses/i2c-piix4 |    2 +-
 drivers/i2c/busses/Kconfig         |    1 +
 drivers/i2c/busses/i2c-piix4.c     |    3 ++-
 3 files changed, 4 insertions(+), 2 deletions(-)
Documentation/i2c/busses/i2c-piix4 +1 -1
@@ -8,7 +8,7 @@ Supported adapters:
     Datasheet: Only available via NDA from ServerWorks
   * ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges
     Datasheet: Not publicly available
-  * AMD Hudson-2
+  * AMD Hudson-2, CZ
     Datasheet: Not publicly available
   * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
     Datasheet: Publicly available at the SMSC website http://www.smsc.com
drivers/i2c/busses/Kconfig +1 -0
@@ -138,6 +138,7 @@ config I2C_PIIX4
 	    ATI SB700
 	    ATI SB800
 	    AMD Hudson-2
+	    AMD CZ
 	    Serverworks OSB4
 	    Serverworks CSB5
 	    Serverworks CSB6
drivers/i2c/busses/i2c-piix4.c +2 -1
@@ -22,7 +22,7 @@
 	Intel PIIX4, 440MX
 	Serverworks OSB4, CSB5, CSB6, HT-1000, HT-1100
 	ATI IXP200, IXP300, IXP400, SB600, SB700, SB800
-	AMD Hudson-2
+	AMD Hudson-2, CZ
 	SMSC Victory66
 
    Note: we assume there can only be one device, with one SMBus interface.
@@ -481,6 +481,7 @@ static DEFINE_PCI_DEVICE_TABLE(piix4_ids
 	{ PCI_DEVICE(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP400_SMBUS) },
 	{ PCI_DEVICE(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS) },
 	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_HUDSON2_SMBUS) },
+	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, 0x790b) },
 	{ PCI_DEVICE(PCI_VENDOR_ID_SERVERWORKS,
 		     PCI_DEVICE_ID_SERVERWORKS_OSB4) },
 	{ PCI_DEVICE(PCI_VENDOR_ID_SERVERWORKS,
author maintainer
#208 lore raw

PATCH 203/214 b43: ensue that BCMA is "y" when B43 is "y"

In reply to Greg Kroah-Hartman

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

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

From: Hauke Mehrtens <[email protected]>

commit 693026ef2e751fd94d2e6c71028e68343cc875d5 upstream.

When b43 gets build into the kernel and it should use bcma we have to ensure that bcma was also build into the kernel and not as a module. In this patch this is also done for SSB, although you can not build b43 without ssb support for now.

This fixes a build problem reported by Randy Dunlap in [email protected]

---
 drivers/net/wireless/b43/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/wireless/b43/Kconfig +2 -2
@@ -28,7 +28,7 @@ config B43
 
 config B43_BCMA
 	bool "Support for BCMA bus"
-	depends on B43 && BCMA
+	depends on B43 && (BCMA = y || BCMA = B43)
 	default y
 
 config B43_BCMA_EXTRA
@@ -39,7 +39,7 @@ config B43_BCMA_EXTRA
 
 config B43_SSB
 	bool
-	depends on B43 && SSB
+	depends on B43 && (SSB = y || SSB = B43)
 	default y
 
 # Auto-select SSB PCI-HOST support, if possible
author maintainer
#209 lore raw

PATCH 204/214 vgacon.c: add cond reschedule points in vgacon_do_font_op

In reply to Greg Kroah-Hartman

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

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

From: Marcelo Tosatti <[email protected]>

commit 7e6d72c15ff4cc0c27573901bb05f9eddbd71ed4 upstream.

Booting a 64-vcpu KVM guest, with CONFIG_PREEMPT_VOLUNTARY, can result in a soft lockup:

BUG: soft lockup - CPU#41 stuck for 67s! [setfont:1505]
 RIP: 0010:[<ffffffff812c48da>]
[<ffffffff812c48da>] vgacon_do_font_op.clone.0+0x1ba/0x550

This is due to the 8192 (cmapsz) IO operations taking longer than expected due to lock contention in QEMU.

Add conditional resched points in between writes allowing other tasks to execute.

[bwh: Backported to 3.2: add #include <linux/sched.h>, already present
upstream]

---
 drivers/video/console/vgacon.c |   17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)
drivers/video/console/vgacon.c +13 -4
@@ -42,6 +42,7 @@
 #include <linux/kd.h>
 #include <linux/slab.h>
 #include <linux/vt_kern.h>
+#include <linux/sched.h>
 #include <linux/selection.h>
 #include <linux/spinlock.h>
 #include <linux/ioport.h>
@@ -1124,11 +1125,15 @@ static int vgacon_do_font_op(struct vgas
 
 	if (arg) {
 		if (set)
-			for (i = 0; i < cmapsz; i++)
+			for (i = 0; i < cmapsz; i++) {
 				vga_writeb(arg[i], charmap + i);
+				cond_resched();
+			}
 		else
-			for (i = 0; i < cmapsz; i++)
+			for (i = 0; i < cmapsz; i++) {
 				arg[i] = vga_readb(charmap + i);
+				cond_resched();
+			}
 
 		/*
 		 * In 512-character mode, the character map is not contiguous if
@@ -1139,11 +1144,15 @@ static int vgacon_do_font_op(struct vgas
 			charmap += 2 * cmapsz;
 			arg += cmapsz;
 			if (set)
-				for (i = 0; i < cmapsz; i++)
+				for (i = 0; i < cmapsz; i++) {
 					vga_writeb(arg[i], charmap + i);
+					cond_resched();
+				}
 			else
-				for (i = 0; i < cmapsz; i++)
+				for (i = 0; i < cmapsz; i++) {
 					arg[i] = vga_readb(charmap + i);
+					cond_resched();
+				}
 		}
 	}
 
author maintainer
#210 lore raw

PATCH 205/214 mac80211: drop spoofed packets in ad-hoc mode

In reply to Greg Kroah-Hartman

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

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

From: Felix Fietkau <[email protected]>

commit 6329b8d917adc077caa60c2447385554130853a3 upstream.

If an Ad-Hoc node receives packets with the Cell ID or its own MAC address as source address, it hits a WARN_ON in sta_info_insert_check() With many packets, this can massively spam the logs. One way that this can easily happen is through having Cisco APs in the area with rouge AP detection and countermeasures enabled.
Such Cisco APs will regularly send fake beacons, disassoc and deauth packets that trigger these warnings.

To fix this issue, drop such spoofed packets early in the rx path.

[bwh: Backported to 3.2: use compare_ether_addr() instead of ether_addr_equal()]
Cc Qiang Huang <[email protected]>
---
 net/mac80211/rx.c |    3 +++
 1 file changed, 3 insertions(+)
net/mac80211/rx.c +3 -0
@@ -2828,6 +2828,9 @@ static int prepare_for_handlers(struct i
 	case NL80211_IFTYPE_ADHOC:
 		if (!bssid)
 			return 0;
+		if (compare_ether_addr(sdata->vif.addr, hdr->addr2) == 0 ||
+		    compare_ether_addr(sdata->u.ibss.bssid, hdr->addr2) == 0)
+			return 0;
 		if (ieee80211_is_beacon(hdr->frame_control)) {
 			return 1;
 		}
author maintainer
#211 lore raw

PATCH 206/214 crypto: s390 - Fix aes-cbc IV corruption

In reply to Greg Kroah-Hartman

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

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

From: Herbert Xu <[email protected]>

commit f262f0f5cad0c9eca61d1d383e3b67b57dcbe5ea upstream.

The cbc-aes-s390 algorithm incorrectly places the IV in the tfm data structure. As the tfm is shared between multiple threads, this introduces a possibility of data corruption.

This patch fixes this by moving the parameter block containing the IV and key onto the stack (the block is 48 bytes long).

The same bug exists elsewhere in the s390 crypto system and they will be fixed in subsequent patches.

[bwh: Backported to 3.2: adjust context]
Cc Qiang Huang <[email protected]>
---
 arch/s390/crypto/aes_s390.c |   19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)
arch/s390/crypto/aes_s390.c +12 -7
@@ -35,7 +35,6 @@ static u8 *ctrblk;
 static char keylen_flag;
 
 struct s390_aes_ctx {
-	u8 iv[AES_BLOCK_SIZE];
 	u8 key[AES_MAX_KEY_SIZE];
 	long enc;
 	long dec;
@@ -442,29 +441,35 @@ static int cbc_aes_set_key(struct crypto
 	return aes_set_key(tfm, in_key, key_len);
 }
 
-static int cbc_aes_crypt(struct blkcipher_desc *desc, long func, void *param,
+static int cbc_aes_crypt(struct blkcipher_desc *desc, long func,
 			 struct blkcipher_walk *walk)
 {
+	struct s390_aes_ctx *sctx = crypto_blkcipher_ctx(desc->tfm);
 	int ret = blkcipher_walk_virt(desc, walk);
 	unsigned int nbytes = walk->nbytes;
+	struct {
+		u8 iv[AES_BLOCK_SIZE];
+		u8 key[AES_MAX_KEY_SIZE];
+	} param;
 
 	if (!nbytes)
 		goto out;
 
-	memcpy(param, walk->iv, AES_BLOCK_SIZE);
+	memcpy(param.iv, walk->iv, AES_BLOCK_SIZE);
+	memcpy(param.key, sctx->key, sctx->key_len);
 	do {
 		/* only use complete blocks */
 		unsigned int n = nbytes & ~(AES_BLOCK_SIZE - 1);
 		u8 *out = walk->dst.virt.addr;
 		u8 *in = walk->src.virt.addr;
 
-		ret = crypt_s390_kmc(func, param, out, in, n);
+		ret = crypt_s390_kmc(func, &param, out, in, n);
 		BUG_ON((ret < 0) || (ret != n));
 
 		nbytes &= AES_BLOCK_SIZE - 1;
 		ret = blkcipher_walk_done(desc, walk, nbytes);
 	} while ((nbytes = walk->nbytes));
-	memcpy(walk->iv, param, AES_BLOCK_SIZE);
+	memcpy(walk->iv, param.iv, AES_BLOCK_SIZE);
 
 out:
 	return ret;
@@ -481,7 +486,7 @@ static int cbc_aes_encrypt(struct blkcip
 		return fallback_blk_enc(desc, dst, src, nbytes);
 
 	blkcipher_walk_init(&walk, dst, src, nbytes);
-	return cbc_aes_crypt(desc, sctx->enc, sctx->iv, &walk);
+	return cbc_aes_crypt(desc, sctx->enc, &walk);
 }
 
 static int cbc_aes_decrypt(struct blkcipher_desc *desc,
@@ -495,7 +500,7 @@ static int cbc_aes_decrypt(struct blkcip
 		return fallback_blk_dec(desc, dst, src, nbytes);
 
 	blkcipher_walk_init(&walk, dst, src, nbytes);
-	return cbc_aes_crypt(desc, sctx->dec, sctx->iv, &walk);
+	return cbc_aes_crypt(desc, sctx->dec, &walk);
 }
 
 static struct crypto_alg cbc_aes_alg = {
author maintainer
#212 lore raw

PATCH 207/214 mtd: m25p80: fix allocation size

In reply to Greg Kroah-Hartman

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

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

From: Brian Norris <[email protected]>

commit 778d226a1462572b51d6777cdb1d611543410cb4 upstream.

This patch fixes two memory errors:

1. During a probe failure (in mtd_device_parse_register?) the command buffer would not be freed.

2. The command buffer's size is determined based on the 'fast_read' boolean, but the assignment of fast_read is made after this allocation. Thus, the buffer may be allocated "too small".

To fix the first, just switch to the devres version of kzalloc.

To fix the second, increase MAX_CMD_SIZE unconditionally. It's not worth saving a byte to fiddle around with the conditions here.

This problem was reported by Yuhang Wang a while back.

---
 drivers/mtd/devices/m25p80.c |   19 +++++++------------
 1 file changed, 7 insertions(+), 12 deletions(-)
drivers/mtd/devices/m25p80.c +7 -12
@@ -71,7 +71,7 @@
 
 /* Define max times to check status register before we give up. */
 #define	MAX_READY_WAIT_JIFFIES	(40 * HZ)	/* M25P16 specs 40s max chip erase */
-#define	MAX_CMD_SIZE		5
+#define	MAX_CMD_SIZE		6
 
 #ifdef CONFIG_M25PXX_USE_FAST_READ
 #define OPCODE_READ 	OPCODE_FAST_READ
@@ -843,14 +843,13 @@ static int __devinit m25p_probe(struct s
 		}
 	}
 
-	flash = kzalloc(sizeof *flash, GFP_KERNEL);
+	flash = devm_kzalloc(&spi->dev, sizeof(*flash), GFP_KERNEL);
 	if (!flash)
 		return -ENOMEM;
-	flash->command = kmalloc(MAX_CMD_SIZE + FAST_READ_DUMMY_BYTE, GFP_KERNEL);
-	if (!flash->command) {
-		kfree(flash);
+
+	flash->command = devm_kzalloc(&spi->dev, MAX_CMD_SIZE, GFP_KERNEL);
+	if (!flash->command)
 		return -ENOMEM;
-	}
 
 	flash->spi = spi;
 	mutex_init(&flash->lock);
@@ -947,14 +946,10 @@ static int __devinit m25p_probe(struct s
 static int __devexit m25p_remove(struct spi_device *spi)
 {
 	struct m25p	*flash = dev_get_drvdata(&spi->dev);
-	int		status;
 
 	/* Clean up MTD stuff. */
-	status = mtd_device_unregister(&flash->mtd);
-	if (status == 0) {
-		kfree(flash->command);
-		kfree(flash);
-	}
+	mtd_device_unregister(&flash->mtd);
+
 	return 0;
 }
 
author maintainer
#213 lore raw

PATCH 208/214 backlight: atmel-pwm-bl: fix gpio polarity in remove

In reply to Greg Kroah-Hartman

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

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

From: Johan Hovold <[email protected]>

commit ad5066d4c2b1d696749f8d7816357c23b648c4d3 upstream.

Make sure to honour gpio polarity also at remove so that the backlight is actually disabled on boards with active-low enable pin.

---
 drivers/video/backlight/atmel-pwm-bl.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/video/backlight/atmel-pwm-bl.c +2 -1
@@ -211,7 +211,8 @@ static int __exit atmel_pwm_bl_remove(st
 	struct atmel_pwm_bl *pwmbl = platform_get_drvdata(pdev);
 
 	if (pwmbl->gpio_on != -1) {
-		gpio_set_value(pwmbl->gpio_on, 0);
+		gpio_set_value(pwmbl->gpio_on,
+					0 ^ pwmbl->pdata->on_active_low);
 		gpio_free(pwmbl->gpio_on);
 	}
 	pwm_channel_disable(&pwmbl->pwmc);
author maintainer
#214 lore raw

PATCH 209/214 can: sja1000: fix {pre,post}_irq() handling and IRQ handler return value

In reply to Greg Kroah-Hartman

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

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

From: Oliver Hartkopp <[email protected]>

commit 2fea6cd303c0d0cd9067da31d873b6a6d5bd75e7 upstream.

This patch fixes the issue that the sja1000_interrupt() function may have returned IRQ_NONE without processing the optional pre_irq() and post_irq() function before. Further the irq processing counter 'n' is moved to the end of the while statement to return correct IRQ_[NONE|HANDLED] values at error conditions.

[bwh: Backported to 3.2: s/SJA1000_IER/REG_IER/; s/SJA1000_IR/REG_IR/]
Cc Qiang Huang <[email protected]>
---
 drivers/net/can/sja1000/sja1000.c |   17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)
drivers/net/can/sja1000/sja1000.c +9 -8
@@ -487,19 +487,19 @@ irqreturn_t sja1000_interrupt(int irq, v
 	uint8_t isrc, status;
 	int n = 0;
 
-	/* Shared interrupts and IRQ off? */
-	if (priv->read_reg(priv, REG_IER) == IRQ_OFF)
-		return IRQ_NONE;
-
 	if (priv->pre_irq)
 		priv->pre_irq(priv);
 
+	/* Shared interrupts and IRQ off? */
+	if (priv->read_reg(priv, REG_IER) == IRQ_OFF)
+		goto out;
+
 	while ((isrc = priv->read_reg(priv, REG_IR)) && (n < SJA1000_MAX_IRQ)) {
-		n++;
+
 		status = priv->read_reg(priv, SJA1000_REG_SR);
 		/* check for absent controller due to hw unplug */
 		if (status == 0xFF && sja1000_is_absent(priv))
-			return IRQ_NONE;
+			goto out;
 
 		if (isrc & IRQ_WUI)
 			netdev_warn(dev, "wakeup interrupt\n");
@@ -518,7 +518,7 @@ irqreturn_t sja1000_interrupt(int irq, v
 				status = priv->read_reg(priv, SJA1000_REG_SR);
 				/* check for absent controller */
 				if (status == 0xFF && sja1000_is_absent(priv))
-					return IRQ_NONE;
+					goto out;
 			}
 		}
 		if (isrc & (IRQ_DOI | IRQ_EI | IRQ_BEI | IRQ_EPI | IRQ_ALI)) {
@@ -526,8 +526,9 @@ irqreturn_t sja1000_interrupt(int irq, v
 			if (sja1000_err(dev, isrc, status))
 				break;
 		}
+		n++;
 	}
-
+out:
 	if (priv->post_irq)
 		priv->post_irq(priv);
 
author maintainer
#215 lore raw

PATCH 210/214 crypto: s390 - Fix aes-xts parameter corruption

In reply to Greg Kroah-Hartman

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

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

From: Gerald Schaefer <[email protected]>

commit 9dda2769af4f3f3093434648c409bb351120d9e8 upstream.

Some s390 crypto algorithms incorrectly use the crypto_tfm structure to store private data. As the tfm can be shared among multiple threads, this can result in data corruption.

This patch fixes aes-xts by moving the xts and pcc parameter blocks from the tfm onto the stack (48 + 96 bytes).

[bwh: Backported to 3.2: adjust context]
Cc Qiang Huang <[email protected]>
---
 arch/s390/crypto/aes_s390.c |   31 +++++++++++++++++--------------
 1 file changed, 17 insertions(+), 14 deletions(-)
arch/s390/crypto/aes_s390.c +17 -14
@@ -55,8 +55,7 @@ struct pcc_param {
 
 struct s390_xts_ctx {
 	u8 key[32];
-	u8 xts_param[16];
-	struct pcc_param pcc;
+	u8 pcc_key[32];
 	long enc;
 	long dec;
 	int key_len;
@@ -592,7 +591,7 @@ static int xts_aes_set_key(struct crypto
 		xts_ctx->enc = KM_XTS_128_ENCRYPT;
 		xts_ctx->dec = KM_XTS_128_DECRYPT;
 		memcpy(xts_ctx->key + 16, in_key, 16);
-		memcpy(xts_ctx->pcc.key + 16, in_key + 16, 16);
+		memcpy(xts_ctx->pcc_key + 16, in_key + 16, 16);
 		break;
 	case 48:
 		xts_ctx->enc = 0;
@@ -603,7 +602,7 @@ static int xts_aes_set_key(struct crypto
 		xts_ctx->enc = KM_XTS_256_ENCRYPT;
 		xts_ctx->dec = KM_XTS_256_DECRYPT;
 		memcpy(xts_ctx->key, in_key, 32);
-		memcpy(xts_ctx->pcc.key, in_key + 32, 32);
+		memcpy(xts_ctx->pcc_key, in_key + 32, 32);
 		break;
 	default:
 		*flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
@@ -622,28 +621,32 @@ static int xts_aes_crypt(struct blkciphe
 	unsigned int nbytes = walk->nbytes;
 	unsigned int n;
 	u8 *in, *out;
-	void *param;
+	struct pcc_param pcc_param;
+	struct {
+		u8 key[32];
+		u8 init[16];
+	} xts_param;
 
 	if (!nbytes)
 		goto out;
 
-	memset(xts_ctx->pcc.block, 0, sizeof(xts_ctx->pcc.block));
-	memset(xts_ctx->pcc.bit, 0, sizeof(xts_ctx->pcc.bit));
-	memset(xts_ctx->pcc.xts, 0, sizeof(xts_ctx->pcc.xts));
-	memcpy(xts_ctx->pcc.tweak, walk->iv, sizeof(xts_ctx->pcc.tweak));
-	param = xts_ctx->pcc.key + offset;
-	ret = crypt_s390_pcc(func, param);
+	memset(pcc_param.block, 0, sizeof(pcc_param.block));
+	memset(pcc_param.bit, 0, sizeof(pcc_param.bit));
+	memset(pcc_param.xts, 0, sizeof(pcc_param.xts));
+	memcpy(pcc_param.tweak, walk->iv, sizeof(pcc_param.tweak));
+	memcpy(pcc_param.key, xts_ctx->pcc_key, 32);
+	ret = crypt_s390_pcc(func, &pcc_param.key[offset]);
 	BUG_ON(ret < 0);
 
-	memcpy(xts_ctx->xts_param, xts_ctx->pcc.xts, 16);
-	param = xts_ctx->key + offset;
+	memcpy(xts_param.key, xts_ctx->key, 32);
+	memcpy(xts_param.init, pcc_param.xts, 16);
 	do {
 		/* only use complete blocks */
 		n = nbytes & ~(AES_BLOCK_SIZE - 1);
 		out = walk->dst.virt.addr;
 		in = walk->src.virt.addr;
 
-		ret = crypt_s390_km(func, param, out, in, n);
+		ret = crypt_s390_km(func, &xts_param.key[offset], out, in, n);
 		BUG_ON(ret < 0 || ret != n);
 
 		nbytes &= AES_BLOCK_SIZE - 1;
author maintainer
#216 lore raw

PATCH 211/214 net: Add net_ratelimited_function and net_<level>_ratelimited macros

In reply to Greg Kroah-Hartman

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

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

From: Joe Perches <[email protected]>

commit 3a3bfb61e64476ff1e4ac3122cb6dec9c79b795c upstream.

__ratelimit() can be considered an inverted bool test because it returns true when not ratelimited. Several tests in the kernel tree use this __ratelimit() function incorrectly.

No net_ratelimit uses are incorrect currently though.

Most uses of net_ratelimit are to log something via printk or pr_<level>.

In order to minimize the uses of net_ratelimit, and to start standardizing the code style used for __ratelimit() and net_ratelimit(), add a net_ratelimited_function() macro and net_<level>_ratelimited() logging macros similar to pr_<level>_ratelimited that use the global net_ratelimit instead of a static per call site "struct ratelimit_state".

---
 include/linux/net.h |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
include/linux/net.h +23 -0
@@ -282,6 +282,29 @@ do {								\
 #define net_dbg_ratelimited(fmt, ...)				\
 	net_ratelimited_function(pr_debug, fmt, ##__VA_ARGS__)
 
+#define net_ratelimited_function(function, ...)			\
+do {								\
+	if (net_ratelimit())					\
+		function(__VA_ARGS__);				\
+} while (0)
+
+#define net_emerg_ratelimited(fmt, ...)				\
+	net_ratelimited_function(pr_emerg, fmt, ##__VA_ARGS__)
+#define net_alert_ratelimited(fmt, ...)				\
+	net_ratelimited_function(pr_alert, fmt, ##__VA_ARGS__)
+#define net_crit_ratelimited(fmt, ...)				\
+	net_ratelimited_function(pr_crit, fmt, ##__VA_ARGS__)
+#define net_err_ratelimited(fmt, ...)				\
+	net_ratelimited_function(pr_err, fmt, ##__VA_ARGS__)
+#define net_notice_ratelimited(fmt, ...)			\
+	net_ratelimited_function(pr_notice, fmt, ##__VA_ARGS__)
+#define net_warn_ratelimited(fmt, ...)				\
+	net_ratelimited_function(pr_warn, fmt, ##__VA_ARGS__)
+#define net_info_ratelimited(fmt, ...)				\
+	net_ratelimited_function(pr_info, fmt, ##__VA_ARGS__)
+#define net_dbg_ratelimited(fmt, ...)				\
+	net_ratelimited_function(pr_debug, fmt, ##__VA_ARGS__)
+
 #define net_random()		random32()
 #define net_srandom(seed)	srandom32((__force u32)seed)
 
author maintainer
#217 lore raw

PATCH 212/214 xen-netfront: reduce gso_max_size to account for max TCP header

In reply to Greg Kroah-Hartman

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

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

From: Wei Liu <[email protected]>

commit 9ecd1a75d977e2e8c48139c7d3efed183f898d94 upstream.

The maximum packet including header that can be handled by netfront / netback wire format is 65535. Reduce gso_max_size accordingly.

Drop skb and print warning when skb->len > 65535. This can 1) save the effort to send malformed packet to netback, 2) help spotting misconfiguration of netfront in the future.

[bwh: Backported to 3.2: adjust context]
[hq: Backported to 3.4: adjust context]
---
 drivers/net/xen-netfront.c       |   17 +++++++++++++++--
 include/xen/interface/io/netif.h |    1 +
 2 files changed, 16 insertions(+), 2 deletions(-)
drivers/net/xen-netfront.c +15 -2
@@ -36,7 +36,7 @@
 #include <linux/skbuff.h>
 #include <linux/ethtool.h>
 #include <linux/if_ether.h>
-#include <linux/tcp.h>
+#include <net/tcp.h>
 #include <linux/udp.h>
 #include <linux/moduleparam.h>
 #include <linux/mm.h>
@@ -492,6 +492,16 @@ static int xennet_start_xmit(struct sk_b
 	unsigned int len = skb_headlen(skb);
 	unsigned long flags;
 
+	/* If skb->len is too big for wire format, drop skb and alert
+	 * user about misconfiguration.
+	 */
+	if (unlikely(skb->len > XEN_NETIF_MAX_TX_SIZE)) {
+		net_alert_ratelimited(
+			"xennet: skb->len = %u, too big for wire format\n",
+			skb->len);
+		goto drop;
+	}
+
 	frags += DIV_ROUND_UP(offset + len, PAGE_SIZE);
 	if (unlikely(frags > MAX_SKB_FRAGS + 1)) {
 		printk(KERN_ALERT "xennet: skb rides the rocket: %d frags\n",
@@ -1045,7 +1055,8 @@ err:
 
 static int xennet_change_mtu(struct net_device *dev, int mtu)
 {
-	int max = xennet_can_sg(dev) ? 65535 - ETH_HLEN : ETH_DATA_LEN;
+	int max = xennet_can_sg(dev) ?
+		XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER : ETH_DATA_LEN;
 
 	if (mtu > max)
 		return -EINVAL;
@@ -1349,6 +1360,8 @@ static struct net_device * __devinit xen
 	SET_ETHTOOL_OPS(netdev, &xennet_ethtool_ops);
 	SET_NETDEV_DEV(netdev, &dev->dev);
 
+	netif_set_gso_max_size(netdev, XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER);
+
 	np->netdev = netdev;
 
 	netif_carrier_off(netdev);
include/xen/interface/io/netif.h +1 -0
@@ -65,6 +65,7 @@
 #define _XEN_NETTXF_extra_info		(3)
 #define  XEN_NETTXF_extra_info		(1U<<_XEN_NETTXF_extra_info)
 
+#define XEN_NETIF_MAX_TX_SIZE 0xFFFF
 struct xen_netif_tx_request {
     grant_ref_t gref;      /* Reference to buffer page */
     uint16_t offset;       /* Offset within buffer page */
author maintainer
#218 lore raw

PATCH 213/214 PCI/ASPM: Dont touch ASPM if forcibly disabled

In reply to Greg Kroah-Hartman

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

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

From: Joe Lawrence <[email protected]>

commit a26d5ecb3201c11e03663a8f4a7dedc0c5f85c07 upstream.

Don't allocate and track PCIe ASPM state when "pcie_aspm=off" is specified on the kernel command line.

Based-on-patch-from: Matthew Garrett <[email protected]>

---
 drivers/pci/pcie/aspm.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/pci/pcie/aspm.c +3 -0
@@ -583,6 +583,9 @@ void pcie_aspm_init_link_state(struct pc
 	struct pcie_link_state *link;
 	int blacklist = !!pcie_aspm_sanity_check(pdev);
 
+	if (!aspm_support_enabled)
+		return;
+
 	if (!pci_is_pcie(pdev) || pdev->link_state)
 		return;
 	if (pdev->pcie_type != PCI_EXP_TYPE_ROOT_PORT &&
author maintainer
#219 lore raw

PATCH 214/214 HID: logitech: dont use stack based dj_report structures

In reply to Greg Kroah-Hartman

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

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

From: Marc Dionne <[email protected]>

commit d8dc3494f77a5cc3b274bae36f7e74e85cf8a407 upstream.

On a system with a logitech wireless keyboard/mouse and DMA-API debugging enabled, this warning appears at boot:

kernel: WARNING: at lib/dma-debug.c:929 check_for_stack.part.12+0x70/0xa7()
kernel: Hardware name: MS-7593
kernel: uhci_hcd 0000:00:1d.1: DMA-API: device driver maps memory fromstack [addr=ffff8801b0079c29]

Make logi_dj_recv_query_paired_devices and logi_dj_recv_switch_to_dj_mode use a structure allocated with kzalloc rather than a stack based one.

---
 drivers/hid/hid-logitech-dj.c |   38 ++++++++++++++++++++++++--------------
 1 file changed, 24 insertions(+), 14 deletions(-)
drivers/hid/hid-logitech-dj.c +24 -14
@@ -474,28 +474,38 @@ static int logi_dj_recv_send_report(stru
 
 static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
 {
-	struct dj_report dj_report;
+	struct dj_report *dj_report;
+	int retval;
 
-	memset(&dj_report, 0, sizeof(dj_report));
-	dj_report.report_id = REPORT_ID_DJ_SHORT;
-	dj_report.device_index = 0xFF;
-	dj_report.report_type = REPORT_TYPE_CMD_GET_PAIRED_DEVICES;
-	return logi_dj_recv_send_report(djrcv_dev, &dj_report);
+	dj_report = kzalloc(sizeof(dj_report), GFP_KERNEL);
+	if (!dj_report)
+		return -ENOMEM;
+	dj_report->report_id = REPORT_ID_DJ_SHORT;
+	dj_report->device_index = 0xFF;
+	dj_report->report_type = REPORT_TYPE_CMD_GET_PAIRED_DEVICES;
+	retval = logi_dj_recv_send_report(djrcv_dev, dj_report);
+	kfree(dj_report);
+	return retval;
 }
 
 
 static int logi_dj_recv_switch_to_dj_mode(struct dj_receiver_dev *djrcv_dev,
 					  unsigned timeout)
 {
-	struct dj_report dj_report;
+	struct dj_report *dj_report;
+	int retval;
 
-	memset(&dj_report, 0, sizeof(dj_report));
-	dj_report.report_id = REPORT_ID_DJ_SHORT;
-	dj_report.device_index = 0xFF;
-	dj_report.report_type = REPORT_TYPE_CMD_SWITCH;
-	dj_report.report_params[CMD_SWITCH_PARAM_DEVBITFIELD] = 0x3F;
-	dj_report.report_params[CMD_SWITCH_PARAM_TIMEOUT_SECONDS] = (u8)timeout;
-	return logi_dj_recv_send_report(djrcv_dev, &dj_report);
+	dj_report = kzalloc(sizeof(dj_report), GFP_KERNEL);
+	if (!dj_report)
+		return -ENOMEM;
+	dj_report->report_id = REPORT_ID_DJ_SHORT;
+	dj_report->device_index = 0xFF;
+	dj_report->report_type = REPORT_TYPE_CMD_SWITCH;
+	dj_report->report_params[CMD_SWITCH_PARAM_DEVBITFIELD] = 0x3F;
+	dj_report->report_params[CMD_SWITCH_PARAM_TIMEOUT_SECONDS] = (u8)timeout;
+	retval = logi_dj_recv_send_report(djrcv_dev, dj_report);
+	kfree(dj_report);
+	return retval;
 }
 
 
#220 lore raw

Re: [PATCH 3.4 214/214] HID: logitech: dont use stack based dj_report structures

Quoted 34 lines · Greg Kroah-Hartman

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

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

From: Marc Dionne <[email protected]>

commit d8dc3494f77a5cc3b274bae36f7e74e85cf8a407 upstream.

On a system with a logitech wireless keyboard/mouse and DMA-API debugging enabled, this warning appears at boot:

kernel: WARNING: at lib/dma-debug.c:929 check_for_stack.part.12+0x70/0xa7()
kernel: Hardware name: MS-7593
kernel: uhci_hcd 0000:00:1d.1: DMA-API: device driver maps memory fromstack [addr=ffff8801b0079c29]

Make logi_dj_recv_query_paired_devices and logi_dj_recv_switch_to_dj_mode use a structure allocated with kzalloc rather than a stack based one.

---
 drivers/hid/hid-logitech-dj.c |   38 ++++++++++++++++++++++++--------------
 1 file changed, 24 insertions(+), 14 deletions(-)
drivers/hid/hid-logitech-dj.c +0 -0
@@ -474,28 +474,38 @@ static int logi_dj_recv_send_report(stru
 
 static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
 {

drivers/hid/hid-logitech-dj.c static int logi_dj_recv_send_report(stru · line 480

Quoted 10 lines
drivers/hid/hid-logitech-dj.c +3 -6
-       struct dj_report dj_report;
+       struct dj_report *dj_report;
+       int retval;
 
-       memset(&dj_report, 0, sizeof(dj_report));
-       dj_report.report_id = REPORT_ID_DJ_SHORT;
-       dj_report.device_index = 0xFF;
-       dj_report.report_type = REPORT_TYPE_CMD_GET_PAIRED_DEVICES;
-       return logi_dj_recv_send_report(djrcv_dev, &dj_report);
+       dj_report = kzalloc(sizeof(dj_report), GFP_KERNEL);

This patch was unfortunately incorrect as is - it needs to allocate sizeof(struct dj_report) here and a little further down. This was later fixed in mainline by 8a55ade7655, which should also be included if you take this - I don't see it in the current set.

Quoted 16 lines
drivers/hid/hid-logitech-dj.c +9 -1
+       if (!dj_report)
+               return -ENOMEM;
+       dj_report->report_id = REPORT_ID_DJ_SHORT;
+       dj_report->device_index = 0xFF;
+       dj_report->report_type = REPORT_TYPE_CMD_GET_PAIRED_DEVICES;
+       retval = logi_dj_recv_send_report(djrcv_dev, dj_report);
+       kfree(dj_report);
+       return retval;
 }
 
 
 static int logi_dj_recv_switch_to_dj_mode(struct dj_receiver_dev *djrcv_dev,
                                          unsigned timeout)
 {
-       struct dj_report dj_report;
+       struct dj_report *dj_report;

drivers/hid/hid-logitech-dj.c static int logi_dj_recv_send_report(stru · line 498

Quoted 10 lines
drivers/hid/hid-logitech-dj.c +2 -7
+       int retval;
 
-       memset(&dj_report, 0, sizeof(dj_report));
-       dj_report.report_id = REPORT_ID_DJ_SHORT;
-       dj_report.device_index = 0xFF;
-       dj_report.report_type = REPORT_TYPE_CMD_SWITCH;
-       dj_report.report_params[CMD_SWITCH_PARAM_DEVBITFIELD] = 0x3F;
-       dj_report.report_params[CMD_SWITCH_PARAM_TIMEOUT_SECONDS] = (u8)timeout;
-       return logi_dj_recv_send_report(djrcv_dev, &dj_report);
+       dj_report = kzalloc(sizeof(dj_report), GFP_KERNEL);

Same here.

drivers/hid/hid-logitech-dj.c static int logi_dj_recv_send_report(stru · line 509

Quoted 11 lines
drivers/hid/hid-logitech-dj.c +10 -0
+       if (!dj_report)
+               return -ENOMEM;
+       dj_report->report_id = REPORT_ID_DJ_SHORT;
+       dj_report->device_index = 0xFF;
+       dj_report->report_type = REPORT_TYPE_CMD_SWITCH;
+       dj_report->report_params[CMD_SWITCH_PARAM_DEVBITFIELD] = 0x3F;
+       dj_report->report_params[CMD_SWITCH_PARAM_TIMEOUT_SECONDS] = (u8)timeout;
+       retval = logi_dj_recv_send_report(djrcv_dev, dj_report);
+       kfree(dj_report);
+       return retval;
 }

Marc

#221 lore raw

Re: [PATCH 3.4 214/214] HID: logitech: dont use stack based dj_report structures

Quoted 8 lines

drivers/hid/hid-logitech-dj.c static int logi_dj_recv_send_report(stru · line 480

Quoted 3 lines
drivers/hid/hid-logitech-dj.c +1 -2
-       dj_report.report_type = REPORT_TYPE_CMD_GET_PAIRED_DEVICES;
-       return logi_dj_recv_send_report(djrcv_dev, &dj_report);
+       dj_report = kzalloc(sizeof(dj_report), GFP_KERNEL);

This patch was unfortunately incorrect as is - it needs to allocate sizeof(struct dj_report) here and a little further down. This was later fixed in mainline by 8a55ade7655, which should also be included if you take this - I don't see it in the current set.

Good catch, I'm so sorry, I missed this fix patch. Marc, thanks for your review.

Hi Greg, Can you cherry pick this fix patch? upstream commit id: 8a55ade7655(dj: memory scribble in logi_dj).

Thanks!
Yijing.

Quoted 46 lines
Quoted 17 lines
drivers/hid/hid-logitech-dj.c +9 -1
+       if (!dj_report)
+               return -ENOMEM;
+       dj_report->report_id = REPORT_ID_DJ_SHORT;
+       dj_report->device_index = 0xFF;
+       dj_report->report_type = REPORT_TYPE_CMD_GET_PAIRED_DEVICES;
+       retval = logi_dj_recv_send_report(djrcv_dev, dj_report);
+       kfree(dj_report);
+       return retval;
 }
 
 
 static int logi_dj_recv_switch_to_dj_mode(struct dj_receiver_dev *djrcv_dev,
                                          unsigned timeout)
 {
-       struct dj_report dj_report;
+       struct dj_report *dj_report;

drivers/hid/hid-logitech-dj.c static int logi_dj_recv_send_report(stru · line 498

Quoted 10 lines
drivers/hid/hid-logitech-dj.c +2 -7
+       int retval;
 
-       memset(&dj_report, 0, sizeof(dj_report));
-       dj_report.report_id = REPORT_ID_DJ_SHORT;
-       dj_report.device_index = 0xFF;
-       dj_report.report_type = REPORT_TYPE_CMD_SWITCH;
-       dj_report.report_params[CMD_SWITCH_PARAM_DEVBITFIELD] = 0x3F;
-       dj_report.report_params[CMD_SWITCH_PARAM_TIMEOUT_SECONDS] = (u8)timeout;
-       return logi_dj_recv_send_report(djrcv_dev, &dj_report);
+       dj_report = kzalloc(sizeof(dj_report), GFP_KERNEL);

Same here.

drivers/hid/hid-logitech-dj.c static int logi_dj_recv_send_report(stru · line 509

Quoted 11 lines
drivers/hid/hid-logitech-dj.c +10 -0
+       if (!dj_report)
+               return -ENOMEM;
+       dj_report->report_id = REPORT_ID_DJ_SHORT;
+       dj_report->device_index = 0xFF;
+       dj_report->report_type = REPORT_TYPE_CMD_SWITCH;
+       dj_report->report_params[CMD_SWITCH_PARAM_DEVBITFIELD] = 0x3F;
+       dj_report->report_params[CMD_SWITCH_PARAM_TIMEOUT_SECONDS] = (u8)timeout;
+       retval = logi_dj_recv_send_report(djrcv_dev, dj_report);
+       kfree(dj_report);
+       return retval;
 }

Marc

.

Signature · 2 lines
Thanks!
Yijing
author maintainer
#222 lore raw

Re: [PATCH 3.4 214/214] HID: logitech: dont use stack based dj_report structures

Quoted 4 lines · Yijing Wang
Quoted 4 lines
Quoted 3 lines
drivers/hid/hid-logitech-dj.c +1 -2
-       dj_report.report_type = REPORT_TYPE_CMD_GET_PAIRED_DEVICES;
-       return logi_dj_recv_send_report(djrcv_dev, &dj_report);
+       dj_report = kzalloc(sizeof(dj_report), GFP_KERNEL);
Quoted 8 lines
Quoted 4 lines

This patch was unfortunately incorrect as is - it needs to allocate sizeof(struct dj_report) here and a little further down. This was later fixed in mainline by 8a55ade7655, which should also be included if you take this - I don't see it in the current set.

Good catch, I'm so sorry, I missed this fix patch. Marc, thanks for your review.

Hi Greg, Can you cherry pick this fix patch? upstream commit id: 8a55ade7655(dj: memory scribble in logi_dj).

Now applied, thanks.

greg k-h

#223 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.4.92 release. There are 214 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 Jun 7 04:15:47 UTC 2014. Anything received after that time might be too late.

Build results:

	total: 136 pass: 109 skipped: 20 fail: 7

Qemu tests all passed.

Results are as expected.
Details are available at server.roeck-us.net:8010/builders.

I see there is an update coming to fix one of the patches; I also see that there is a second patch with potential problems, so maybe there will be another update. I'll monitor and report if there are differences in test results.

I also noticed that patch 7998eb3d (powerpc: Fix 64 bit builds with binutils 2.24) does not apply cleanly to 3.4; I'll send a backport of it to the -stable mailing list after testing it.

Guenter

author maintainer
#224 lore raw
Quoted 14 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.4.92 release. There are 214 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 Jun 7 04:15:47 UTC 2014. Anything received after that time might be too late.

Build results:

	total: 136 pass: 109 skipped: 20 fail: 7

Qemu tests all passed.

Quoted 7 lines

Results are as expected.
Details are available at server.roeck-us.net:8010/builders.

I see there is an update coming to fix one of the patches; I also see that there is a second patch with potential problems, so maybe there will be another update. I'll monitor and report if there are differences in test results.

Thanks, that would be appreciated.

greg k-h

#225 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.4.92 release. There are 214 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 Jun 7 04:15:47 UTC 2014. Anything received after that time might be too late.

Quoted 8 lines

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

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

and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted on my test system with no dmesg regressions.

-- Shuah

Signature · 4 lines
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
[email protected] | (970) 672-0658
author maintainer
#226 lore raw
Quoted 13 lines · Shuah Khan
Quoted 12 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.4.92 release. There are 214 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 Jun 7 04:15:47 UTC 2014. Anything received after that time might be too late.

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

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

and the diffstat can be found below.

Quoted 6 lines
Quoted 4 lines

thanks,

greg k-h

Compiled and booted on my test system with no dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

author maintainer
#227 lore raw
In reply to Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.4.92 release. There are 214 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 Jun 7 04:15:47 UTC 2014. Anything received after that time might be too late.

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

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

and the diffstat can be found below.

Given the recent changes in this tree, I've released a -rc2 to handle all of the updates.:

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

thanks,

greg k-h

#228 lore raw
Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.4.92 release. There are 214 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 Jun 7 04:15:47 UTC 2014. Anything received after that time might be too late.

Quoted 8 lines
Quoted 3 lines

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

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

and the diffstat can be found below.

Given the recent changes in this tree, I've released a -rc2 to handle all of the updates.:

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

Presumably you mean

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.92-rc2.gz

Same for 3.10 and 3.14.

Guenter

author maintainer
#229 lore raw
Quoted 14 lines · Guenter Roeck
Quoted 13 lines · Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.4.92 release. There are 214 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 Jun 7 04:15:47 UTC 2014. Anything received after that time might be too late.

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

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

and the diffstat can be found below.

Quoted 6 lines
Quoted 4 lines

Given the recent changes in this tree, I've released a -rc2 to handle all of the updates.:

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

Presumably you mean

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.92-rc2.gz

Doh, yes, cutting and pasting and not changing the number was dumb...

Quoted 1 line

Same for 3.10 and 3.14.

Yes.

Thanks for testing and verifying it's all good.

greg k-h