3.4.92-stable review
Greg Kroah-Hartman
maintainerPATCH 155/214 x86/efi: Fix dummy variable buffer allocation
In reply to Greg Kroah-Hartman3.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
Greg Kroah-Hartman
maintainerPATCH 156/214 nbd: fsync and kill block device on shutdown
In reply to Greg Kroah-Hartman3.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')]
--- 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_devistruct 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_devinbd_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 ;
Greg Kroah-Hartman
maintainerPATCH 157/214 drivers: hv: switch to use mb() instead of smp_mb()
In reply to Greg Kroah-Hartman3.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) {/*
Greg Kroah-Hartman
maintainerPATCH 158/214 drm/i915/sdvo: clean up connectors on intel_sdvo_init() failures
In reply to Greg Kroah-Hartman3.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.]
--- 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_sdvreturn 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);
Greg Kroah-Hartman
maintainerPATCH 159/214 drm: fix documentation for drm_crtc_set_mode()
In reply to Greg Kroah-Hartman3.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.
Greg Kroah-Hartman
maintainerPATCH 160/214 drm/radeon/dce32+: use fractional fb dividers for high clocks
In reply to Greg Kroah-Hartman3.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.
--- 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 ;
Greg Kroah-Hartman
maintainerPATCH 161/214 drm/radeon: fix amd afusion gpu setup aka sumo v2
In reply to Greg Kroah-Hartman3.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
--- 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 racase 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 rabreak ;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;
Greg Kroah-Hartman
maintainerPATCH 162/214 drm/radeon: add connector table for SAM440ep embedded board
In reply to Greg Kroah-Hartman3.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_frDRM_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 {
Greg Kroah-Hartman
maintainerPATCH 163/214 drm/radeon: add connector table for Mac G4 Silver
In reply to Greg Kroah-Hartman3.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_frDRM_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 {
Greg Kroah-Hartman
maintainerPATCH 164/214 drm/nouveau: fix init with agpgart-uninorth
In reply to Greg Kroah-Hartman3.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_boif (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 ;
Greg Kroah-Hartman
maintainerPATCH 165/214 drm/radeon: fix typo in evergreen_mc_resume()
In reply to Greg Kroah-Hartman3.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_dWREG32 (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 ;
Greg Kroah-Hartman
maintainerPATCH 166/214 drm/i915: Close race between processing unpin task and queueing the flip
In reply to Greg Kroah-Hartman3.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.]
--- 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(structseq_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(structseq_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(stspin_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(stspin_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(structOUT_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(structOUT_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(structintel_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 2bool enable_stall_check; };
Greg Kroah-Hartman
maintainerPATCH 167/214 drm/i915; Only increment the user-pin-count after successfully pinning the bo
In reply to Greg Kroah-Hartman3.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).
--- 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 */
Greg Kroah-Hartman
maintainerPATCH 168/214 drm/i915: dump UTS_RELEASE into the error_state
In reply to Greg Kroah-Hartman3.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.
--- 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_fseq_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);
Greg Kroah-Hartman
maintainerPATCH 169/214 drm/i915: add missing \n to UTS_RELEASE in the error_state
In reply to Greg Kroah-Hartman3.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_fseq_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);
Greg Kroah-Hartman
maintainerPATCH 170/214 drm/i915: panel: invert brightness via parameter
In reply to Greg Kroah-Hartman3.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(structreturn 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_bacu32 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);
Greg Kroah-Hartman
maintainerPATCH 171/214 drm/i915: panel: invert brightness via quirk
In reply to Greg Kroah-Hartman3.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(struDRM_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(structreturn 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;
Greg Kroah-Hartman
maintainerPATCH 172/214 drm/i915: panel: invert brightness acer aspire 5734z
In reply to Greg Kroah-Hartman3.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 */
Greg Kroah-Hartman
maintainerPATCH 173/214 drm/i915: add quirk to invert brightness on eMachines G725
In reply to Greg Kroah-Hartman3.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 */
Greg Kroah-Hartman
maintainerPATCH 174/214 drm/i915: add quirk to invert brightness on eMachines e725
In reply to Greg Kroah-Hartman3.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
--- 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 */
Greg Kroah-Hartman
maintainerPATCH 175/214 drm/i915: add quirk to invert brightness on Packard Bell NCL20
In reply to Greg Kroah-Hartman3.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 */
Greg Kroah-Hartman
maintainerPATCH 176/214 DRM/i915: Add QUIRK_INVERT_BRIGHTNESS for NCR machines.
In reply to Greg Kroah-Hartman3.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.
[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 */
Greg Kroah-Hartman
maintainerPATCH 177/214 drm/radeon: use frac fb div on RS780/RS880
In reply to Greg Kroah-Hartman3.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 {
Greg Kroah-Hartman
maintainerPATCH 178/214 drm/radeon: cleanup properly if mmio mapping fails
In reply to Greg Kroah-Hartman3.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
--- 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 ;
Greg Kroah-Hartman
maintainerPATCH 179/214 drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
In reply to Greg Kroah-Hartman3.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
--- 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 *dreturn 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 :
Greg Kroah-Hartman
maintainerPATCH 180/214 drm/i915: ensure single initialization and cleanup of backlight device
In reply to Greg Kroah-Hartman3.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_dedel_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 drstruct 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 dintel_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 dvoid 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)
Greg Kroah-Hartman
maintainerPATCH 181/214 drm/radeon: Another card with wrong primary dac adj
In reply to Greg Kroah-Hartman3.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 ; }
Greg Kroah-Hartman
maintainerPATCH 182/214 drm/i915: try not to lose backlight CBLV precision
In reply to Greg Kroah-Hartman3.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 ; }
Greg Kroah-Hartman
maintainerPATCH 183/214 drm/radeon: fix panel scaling with eDP and LVDS bridges
In reply to Greg Kroah-Hartman3.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.
--- 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_devcase 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_devcase 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_devbreak ;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 */
Greg Kroah-Hartman
maintainerPATCH 184/214 drm: Pad drm_mode_get_connector to 64-bit boundary
In reply to Greg Kroah-Hartman3.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)
Greg Kroah-Hartman
maintainerPATCH 185/214 drm/ttm: Fix memory type compatibility check
In reply to Greg Kroah-Hartman3.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.
--- 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 ); }/*
Greg Kroah-Hartman
maintainerPATCH 186/214 drm/radeon: fix hdmi mode enable on RS600/RS690/RS740
In reply to Greg Kroah-Hartman3.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.
[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_encoderWREG32_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_encodeWREG32_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,
Greg Kroah-Hartman
maintainerPATCH 187/214 drm/radeon: always program the MC on startup
In reply to Greg Kroah-Hartman3.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 radeif (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 *rif (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_dif (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_devistruct 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_deviif (r)return r; -si_mc_program (rdev); r =si_pcie_gart_enable (rdev);if (r)return r;
Greg Kroah-Hartman
maintainerPATCH 188/214 drivers/rtc/rtc-pl031.c: fix the missing operation on enable
In reply to Greg Kroah-Hartman3.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.
--- 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_devicint 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_devicdev_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
Greg Kroah-Hartman
maintainerPATCH 189/214 wireless: rt2x00: rt{2500,73}usb.c put back duplicate id
In reply to Greg Kroah-Hartman3.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) },
Greg Kroah-Hartman
maintainerPATCH 190/214 Wireless: rt2x00: Add device id for Sweex LW323 to rt2800usb.c
In reply to Greg Kroah-Hartman3.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) },
Greg Kroah-Hartman
maintainerPATCH 191/214 rt2800usb: Add support for 2001:3c1e (D-Link DWA-125 rev B1) USB Wi-Fi adapter
In reply to Greg Kroah-Hartman3.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 */
Greg Kroah-Hartman
maintainerPATCH 192/214 drivers/rtc/rtc-pl031.c: restore ST variant functionality
In reply to Greg Kroah-Hartman3.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
Greg Kroah-Hartman
maintainerPATCH 193/214 ata_piix: Add Device IDs for Intel Lynx Point-LP PCH
In reply to Greg Kroah-Hartman3.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) */
Greg Kroah-Hartman
maintainerPATCH 194/214 speakup: lower default software speech rate
In reply to Greg Kroah-Hartman3.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 } },
Greg Kroah-Hartman
maintainerPATCH 195/214 i2c: tegra: check the clk_prepare_enable() return value
In reply to Greg Kroah-Hartman3.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_iu32 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_adaif (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);
Greg Kroah-Hartman
maintainerPATCH 196/214 ixgbe: fix registration order of driver and DCA nofitication
In reply to Greg Kroah-Hartman3.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(voidpr_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);
Greg Kroah-Hartman
maintainerPATCH 197/214 msi-wmi: Fix memory leak
In reply to Greg Kroah-Hartman3.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, vopr_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, vopr_info ("Unknown key pressed - %x\n" , eventcode); }else pr_info ("Unknown event received\n" ); + +msi_wmi_notify_exit:kfree (response.pointer); }
Greg Kroah-Hartman
maintainerPATCH 198/214 rapidio/tsi721: fix bug in MSI interrupt handling
In reply to Greg Kroah-Hartman3.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.
--- 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(intu32 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(inttsi721_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 ; }
Greg Kroah-Hartman
maintainerPATCH 199/214 rapidio/tsi721: Fix interrupt mask when handling MSI
In reply to Greg Kroah-Hartman3.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 ); }
Greg Kroah-Hartman
maintainerPATCH 200/214 random: fix accounting race condition with lockless irq entropy_count update
In reply to Greg Kroah-Hartman3.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.
--- 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_stoif (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 ); }
Greg Kroah-Hartman
maintainerPATCH 201/214 cfg80211: check wdev->netdev in connection work
In reply to Greg Kroah-Hartman3.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.
--- 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_strumutex_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);
Greg Kroah-Hartman
maintainerPATCH 202/214 i2c-piix4: Add AMD CZ SMBus device ID
In reply to Greg Kroah-Hartman3.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.
--- 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,
Greg Kroah-Hartman
maintainerPATCH 203/214 b43: ensue that BCMA is "y" when B43 is "y"
In reply to Greg Kroah-Hartman3.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
Greg Kroah-Hartman
maintainerPATCH 204/214 vgacon.c: add cond reschedule points in vgacon_do_font_op
In reply to Greg Kroah-Hartman3.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 vgasif (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 (); + } } }
Greg Kroah-Hartman
maintainerPATCH 205/214 mac80211: drop spoofed packets in ad-hoc mode
In reply to Greg Kroah-Hartman3.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.
--- 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 icase 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 ; }
Greg Kroah-Hartman
maintainerPATCH 206/214 crypto: s390 - Fix aes-cbc IV corruption
In reply to Greg Kroah-Hartman3.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.
--- 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 cryptoreturn 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, ¶m, 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 blkcipreturn 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 blkcipreturn 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 = {
Greg Kroah-Hartman
maintainerPATCH 207/214 mtd: m25p80: fix allocation size
In reply to Greg Kroah-Hartman3.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 ; }
Greg Kroah-Hartman
maintainerPATCH 208/214 backlight: atmel-pwm-bl: fix gpio polarity in remove
In reply to Greg Kroah-Hartman3.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(ststruct 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);
Greg Kroah-Hartman
maintainerPATCH 209/214 can: sja1000: fix {pre,post}_irq() handling and IRQ handler return value
In reply to Greg Kroah-Hartman3.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.
--- 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, vuint8_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, vif (sja1000_err (dev, isrc, status))break ; } + n++; } - +out:if (priv->post_irq) priv->post_irq (priv);
Greg Kroah-Hartman
maintainerPATCH 210/214 crypto: s390 - Fix aes-xts parameter corruption
In reply to Greg Kroah-Hartman3.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).
--- 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 blkcipheunsigned 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;
Greg Kroah-Hartman
maintainerPATCH 211/214 net: Add net_ratelimited_function and net_<level>_ratelimited macros
In reply to Greg Kroah-Hartman3.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)
Greg Kroah-Hartman
maintainerPATCH 212/214 xen-netfront: reduce gso_max_size to account for max TCP header
In reply to Greg Kroah-Hartman3.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.
--- 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_bunsigned 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 xenSET_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 0xFFFFstruct xen_netif_tx_request {grant_ref_t gref;/* Reference to buffer page */ uint16_t offset;/* Offset within buffer page */
Greg Kroah-Hartman
maintainerPATCH 213/214 PCI/ASPM: Dont touch ASPM if forcibly disabled
In reply to Greg Kroah-Hartman3.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 pcstruct 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 &&
Greg Kroah-Hartman
maintainerPATCH 214/214 HID: logitech: dont use stack based dj_report structures
In reply to Greg Kroah-Hartman3.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(strustatic 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; }
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
d8dc3494f77a5cc3b274bae36f7e74e85cf8a407upstream.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:929check_for_stack.part.12+0x70/0xa7()
kernel: Hardware name: MS-7593
kernel:uhci_hcd0000:00:1d.1: DMA-API: device driver maps memory fromstack [addr=ffff8801b0079c29]Make
logi_dj_recv_query_paired_devicesandlogi_dj_recv_switch_to_dj_modeuse a structure allocated with kzalloc rather than a stack based one.Signed-off-by Marc Dionne <[email protected]>Signed-off-by Jiri Kosina <[email protected]>Signed-off-by Ben Hutchings <[email protected]>Cc Yijing Wang <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- 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(strustatic 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
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 by8a55ade7655, 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
Greg Kroah-Hartman
maintainerRe: [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 by8a55ade7655, 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
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
Greg Kroah-Hartman
maintainerQuoted 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: 7Qemu 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
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.gzand 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
Greg Kroah-Hartman
maintainerQuoted 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.gzand 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
Greg Kroah-Hartman
maintainerQuoted 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.gzand 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
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.gzand 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
Greg Kroah-Hartman
maintainerQuoted 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.gzand 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.gzPresumably 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