2013-05-22 22:18:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 0/5] 3.4.47-stable review

This is the start of the stable review cycle for the 3.4.47 release.
There are 5 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 Fri May 24 22:10:47 UTC 2013.
Anything received after that time might be too late.

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

thanks,

greg k-h

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

Greg Kroah-Hartman <[email protected]>
Linux 3.4.47-rc1

Alan Cox <[email protected]>
media: mantis: fix silly crash case

Niels Ole Salscheider <[email protected]>
drm/radeon: Fix VRAM size calculation for VRAM >= 4GB

Mika Westerberg <[email protected]>
i2c: designware: always clear interrupts before enabling them

Wei Yongjun <[email protected]>
hwmon: fix error return code in abituguru_probe()

Gabriel de Perthuis <[email protected]>
btrfs: don't stop searching after encountering the wrong item


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

Diffstat:

Makefile | 4 ++--
drivers/gpu/drm/radeon/evergreen.c | 4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/radeon/si.c | 4 ++--
drivers/hwmon/abituguru.c | 16 ++++++++++------
drivers/i2c/busses/i2c-designware-core.c | 3 ++-
drivers/media/dvb/mantis/mantis_dvb.c | 6 ++++--
fs/btrfs/ioctl.c | 10 +++++-----
8 files changed, 28 insertions(+), 21 deletions(-)


2013-05-22 22:18:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 2/5] hwmon: fix error return code in abituguru_probe()

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

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

From: Wei Yongjun <[email protected]>

commit ecacb0b17c08fae89f65468727f0e4b8e91da4e1 upstream.

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/hwmon/abituguru.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)

--- a/drivers/hwmon/abituguru.c
+++ b/drivers/hwmon/abituguru.c
@@ -1410,14 +1410,18 @@ static int __devinit abituguru_probe(str
pr_info("found Abit uGuru\n");

/* Register sysfs hooks */
- for (i = 0; i < sysfs_attr_i; i++)
- if (device_create_file(&pdev->dev,
- &data->sysfs_attr[i].dev_attr))
+ for (i = 0; i < sysfs_attr_i; i++) {
+ res = device_create_file(&pdev->dev,
+ &data->sysfs_attr[i].dev_attr);
+ if (res)
goto abituguru_probe_error;
- for (i = 0; i < ARRAY_SIZE(abituguru_sysfs_attr); i++)
- if (device_create_file(&pdev->dev,
- &abituguru_sysfs_attr[i].dev_attr))
+ }
+ for (i = 0; i < ARRAY_SIZE(abituguru_sysfs_attr); i++) {
+ res = device_create_file(&pdev->dev,
+ &abituguru_sysfs_attr[i].dev_attr);
+ if (res)
goto abituguru_probe_error;
+ }

data->hwmon_dev = hwmon_device_register(&pdev->dev);
if (!IS_ERR(data->hwmon_dev))

2013-05-22 22:18:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 4/5] drm/radeon: Fix VRAM size calculation for VRAM >= 4GB

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

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

From: Niels Ole Salscheider <[email protected]>

commit fc986034540102cd090237bf3f70262e1ae80d9c upstream.

Add ULL prefix to avoid overflow.

Signed-off-by: Niels Ole Salscheider <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/radeon/evergreen.c | 4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/radeon/si.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)

--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2443,8 +2443,8 @@ int evergreen_mc_init(struct radeon_devi
rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE);
} else {
/* size in MB on evergreen/cayman/tn */
- rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
- rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
+ rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
}
rdev->mc.visible_vram_size = rdev->mc.aper_size;
r700_vram_gtt_location(rdev, &rdev->mc);
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -744,7 +744,7 @@ int radeon_ttm_init(struct radeon_device
return r;
}
DRM_INFO("radeon: %uM of VRAM memory ready\n",
- (unsigned)rdev->mc.real_vram_size / (1024 * 1024));
+ (unsigned) (rdev->mc.real_vram_size / (1024 * 1024)));
r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
rdev->mc.gtt_size >> PAGE_SHIFT);
if (r) {
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2464,8 +2464,8 @@ static int si_mc_init(struct radeon_devi
rdev->mc.aper_base = pci_resource_start(rdev->pdev, 0);
rdev->mc.aper_size = pci_resource_len(rdev->pdev, 0);
/* size in MB on si */
- rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
- rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
+ rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
rdev->mc.visible_vram_size = rdev->mc.aper_size;
si_vram_gtt_location(rdev, &rdev->mc);
radeon_update_bandwidth_info(rdev);

2013-05-22 22:18:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 5/5] media: mantis: fix silly crash case

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

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

From: Alan Cox <[email protected]>

commit e1d45ae10aea8e8a403e5d96bf5902ee670007ff upstream.

If we set mantis->fe to NULL on an error its not a good idea to then try
passing NULL to the unregister paths and oopsing really.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=16473

Signed-off-by: Alan Cox <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Cc: Bjørn Mork <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/dvb/mantis/mantis_dvb.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/media/dvb/mantis/mantis_dvb.c
+++ b/drivers/media/dvb/mantis/mantis_dvb.c
@@ -248,8 +248,10 @@ int __devinit mantis_dvb_init(struct man
err5:
tasklet_kill(&mantis->tasklet);
dvb_net_release(&mantis->dvbnet);
- dvb_unregister_frontend(mantis->fe);
- dvb_frontend_detach(mantis->fe);
+ if (mantis->fe) {
+ dvb_unregister_frontend(mantis->fe);
+ dvb_frontend_detach(mantis->fe);
+ }
err4:
mantis->demux.dmx.remove_frontend(&mantis->demux.dmx, &mantis->fe_mem);


2013-05-22 22:18:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 1/5] btrfs: dont stop searching after encountering the wrong item

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

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

From: Gabriel de Perthuis <[email protected]>

commit 03b71c6ca6286625d8f1ed44aabab9b5bf5dac10 upstream.

The search ioctl skips items that are too large for a result buffer, but
inline items of a certain size occuring before any search result is
found would trigger an overflow and stop the search entirely.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=57641

Signed-off-by: Gabriel de Perthuis <[email protected]>
Signed-off-by: Josef Bacik <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/ioctl.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1653,7 +1653,11 @@ static noinline int copy_to_sk(struct bt
item_off = btrfs_item_ptr_offset(leaf, i);
item_len = btrfs_item_size_nr(leaf, i);

- if (item_len > BTRFS_SEARCH_ARGS_BUFSIZE)
+ btrfs_item_key_to_cpu(leaf, key, i);
+ if (!key_in_sk(key, sk))
+ continue;
+
+ if (sizeof(sh) + item_len > BTRFS_SEARCH_ARGS_BUFSIZE)
item_len = 0;

if (sizeof(sh) + item_len + *sk_offset >
@@ -1662,10 +1666,6 @@ static noinline int copy_to_sk(struct bt
goto overflow;
}

- btrfs_item_key_to_cpu(leaf, key, i);
- if (!key_in_sk(key, sk))
- continue;
-
sh.objectid = key->objectid;
sh.offset = key->offset;
sh.type = key->type;

2013-05-22 22:19:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 3/5] i2c: designware: always clear interrupts before enabling them

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

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

From: Mika Westerberg <[email protected]>

commit 2a2d95e9d6d29e726cc294b65391917ed2e32bf4 upstream.

If the I2C bus is put to a low power state by an ACPI method it might pull
the SDA line low (as its power is removed). Once the bus is put to full
power state again, the SDA line is pulled back to high. This transition
looks like a STOP condition from the controller point-of-view which sets
STOP detected bit in its status register causing the driver to fail
subsequent transfers.

Fix this by always clearing all interrupts before we start a transfer.

Signed-off-by: Mika Westerberg <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/i2c/busses/i2c-designware-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -349,7 +349,8 @@ static void i2c_dw_xfer_init(struct dw_i
/* Enable the adapter */
dw_writel(dev, 1, DW_IC_ENABLE);

- /* Enable interrupts */
+ /* Clear and enable interrupts */
+ i2c_dw_clear_int(dev);
dw_writel(dev, DW_IC_INTR_DEFAULT_MASK, DW_IC_INTR_MASK);
}


2013-05-23 16:53:54

by Shuah Khan

[permalink] [raw]
Subject: Re: [ 0/5] 3.4.47-stable review

On Wed, 2013-05-22 at 15:18 -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.4.47 release.
> There are 5 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 Fri May 24 22:10:47 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.47-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Patches applied cleanly to 3.0.79, 3.4.46, and 3.9.3

Compiled and booted on the following systems:

Samsung Series 9 900X4C Intel Corei5:
(3.4.47-rc1, and 3.9.4-rc1)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics:
(3.0.80-rc1, 3.4.47-rc1, and 3.9.4-rc1)

dmesgs for all releases look good. No regressions compared to the previous
dmesgs for each of these releases.

Reviewed patches.

Cross-compile testing:
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:
(3.0.80-rc1, 3.4.47-rc1, and 3.9.4-rc1)

Cross-compile tests results:

alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.9.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y and 3.9.y
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 672-0658

????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?

2013-05-24 12:44:00

by Satoru Takeuchi

[permalink] [raw]
Subject: Re: [ 0/5] 3.4.47-stable review

At Wed, 22 May 2013 15:18:06 -0700,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.4.47 release.
> There are 5 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 Fri May 24 22:10:47 UTC 2013.
> Anything received after that time might be too late.

This kernel can be built and boot without any problem.
Building a kernel with this kernel also works fine.

- Build Machine: debian wheezy x86_64
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
memory: 8GB

- Test machine: debian wheezy x86_64(KVM guest on the Build Machine)
vCPU: x2
memory: 2GB

Thanks,
Satoru