2010-08-06 18:33:26

by Greg KH

[permalink] [raw]
Subject: [00/38] 2.6.35.1-stable review

This is the start of the stable review cycle for the 2.6.35.1 release.
There are 38 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
us know. If anyone is a maintainer of the proper subsystem, and wants
to add a Signed-off-by: line to the patch, please respond with it.

Responses should be made by August 8, 2010, 18:00:00 UTC.
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/v2.6/stable-review/patch-2.6.35.1-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

Makefile | 2 +-
arch/arm/plat-mxc/gpio.c | 8 ++
arch/arm/plat-mxc/include/mach/gpio.h | 1 +
arch/parisc/kernel/firmware.c | 12 +--
arch/x86/xen/enlighten.c | 2 +-
arch/x86/xen/time.c | 39 -------
drivers/edac/amd64_edac.c | 6 +-
drivers/gpu/drm/i915/intel_display.c | 144 +++++++++++++++---------
drivers/gpu/drm/i915/intel_drv.h | 8 +-
drivers/gpu/drm/i915/intel_overlay.c | 7 +-
drivers/gpu/drm/radeon/r600.c | 24 ++++-
drivers/gpu/drm/radeon/r600d.h | 1 +
drivers/gpu/drm/radeon/radeon_object.c | 27 +++--
drivers/gpu/drm/radeon/rs690.c | 27 ++---
drivers/gpu/drm/radeon/rv515.c | 23 ++---
drivers/gpu/drm/radeon/rv770.c | 5 +-
drivers/gpu/drm/radeon/rv770d.h | 1 +
drivers/misc/enclosure.c | 7 +-
drivers/net/e1000e/hw.h | 2 +-
drivers/net/e1000e/netdev.c | 13 ++-
drivers/net/igb/igb_main.c | 8 +-
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom.h | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 4 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 4 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 6 +-
drivers/net/wireless/ath/ath9k/hw.c | 23 +++-
drivers/net/wireless/ath/ath9k/xmit.c | 95 ++++++++++------
drivers/net/wireless/iwlwifi/iwl-scan.c | 18 ++--
drivers/net/xen-netfront.c | 1 +
drivers/parisc/led.c | 6 +-
drivers/ssb/driver_chipcommon.c | 1 +
drivers/ssb/pci.c | 15 ++-
fs/block_dev.c | 4 +-
include/drm/drm_pciids.h | 7 +
include/linux/netdevice.h | 2 +
include/linux/notifier.h | 1 +
kernel/signal.c | 9 +-
net/9p/trans_fd.c | 2 +-
net/ipv4/devinet.c | 1 +
net/mac80211/mesh_plink.c | 42 +++++--
net/sched/sch_generic.c | 18 +++
net/wireless/mlme.c | 8 +-
net/wireless/scan.c | 5 +
45 files changed, 395 insertions(+), 250 deletions(-)


2010-08-06 18:35:34

by Greg KH

[permalink] [raw]
Subject: [07/38] amd64_edac: Fix operator precendence error

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Borislav Petkov <[email protected]>

commit 962b70a1eb22c467b95756a290c694e73da17f41 upstream.

The bitwise AND is of higher precedence, make that explicit.

Signed-off-by: Borislav Petkov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/edac/amd64_edac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -1679,7 +1679,7 @@ static void f10_map_sysaddr_to_csrow(str
* ganged. Otherwise @chan should already contain the channel at
* this point.
*/
- if (dct_ganging_enabled(pvt) && pvt->nbcfg & K8_NBCFG_CHIPKILL)
+ if (dct_ganging_enabled(pvt) && (pvt->nbcfg & K8_NBCFG_CHIPKILL))
chan = get_channel_from_ecc_syndrome(mci, syndrome);

if (chan >= 0)

2010-08-06 18:35:45

by Greg KH

[permalink] [raw]
Subject: [12/38] 9p: strlen() doesnt count the terminator

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Dan Carpenter <[email protected]>

commit 5c4bfa17f3ec46becec4b23d12323f7605ebd696 upstream.

This is an off by one bug because strlen() doesn't count the NULL
terminator. We strcpy() addr into a fixed length array of size
UNIX_PATH_MAX later on.

The addr variable is the name of the device being mounted.

Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/9p/trans_fd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -948,7 +948,7 @@ p9_fd_create_unix(struct p9_client *clie

csocket = NULL;

- if (strlen(addr) > UNIX_PATH_MAX) {
+ if (strlen(addr) >= UNIX_PATH_MAX) {
P9_EPRINTK(KERN_ERR, "p9_trans_unix: address too long: %s\n",
addr);
return -ENAMETOOLONG;

2010-08-06 18:35:53

by Greg KH

[permalink] [raw]
Subject: [16/38] ath9k_hw: prevent a fast channel change after a rx DMA stuck issue

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Felix Fietkau <[email protected]>

commit 9cc2f3e881dcda5466c55ffe8dd0a9d1433469cb upstream.

If the receive path gets stuck, a full hardware reset is necessary to
recover from it. If this happens during a scan, the whole scan might fail,
as each channel change bypasses the full reset sequence.
Fix this by resetting the fast channel change flag if stopping the
receive path fails.

This will reduce the number of error messages that look like this:
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x40000020

Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/hw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1233,9 +1233,11 @@ int ath9k_hw_reset(struct ath_hw *ah, st

if (!ah->chip_fullsleep) {
ath9k_hw_abortpcurecv(ah);
- if (!ath9k_hw_stopdmarecv(ah))
+ if (!ath9k_hw_stopdmarecv(ah)) {
ath_print(common, ATH_DBG_XMIT,
"Failed to stop receive dma\n");
+ bChannelChange = false;
+ }
}

if (!ath9k_hw_setpower(ah, ATH9K_PM_AWAKE))

2010-08-06 18:35:57

by Greg KH

[permalink] [raw]
Subject: [18/38] ath9k_hw: fix an off-by-one error in the PDADC boundaries calculation

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Felix Fietkau <[email protected]>

commit 03b4776c408d2f4bf3a5d204e223724d154716d1 upstream.

PDADC values were only generated for values surrounding the target
index, however not for the target index itself, leading to a minor
error in the generated curve.

Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/eeprom_def.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
@@ -729,7 +729,7 @@ static void ath9k_hw_get_def_gain_bounda
vpdTableI[i][sizeCurrVpdTable - 2]);
vpdStep = (int16_t)((vpdStep < 1) ? 1 : vpdStep);

- if (tgtIndex > maxIndex) {
+ if (tgtIndex >= maxIndex) {
while ((ss <= tgtIndex) &&
(k < (AR5416_NUM_PDADC_VALUES - 1))) {
tmpVal = (int16_t)((vpdTableI[i][sizeCurrVpdTable - 1] +

2010-08-06 18:36:21

by Greg KH

[permalink] [raw]
Subject: [31/38] SCSI: enclosure: fix error path - actually return ERR_PTR() on error

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: James Bottomley <[email protected]>

commit a91c1be21704113b023919826c6d531da46656ef upstream.

we also need to clean up and free the cdev.

Reported-by: Jani Nikula <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/misc/enclosure.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/misc/enclosure.c
+++ b/drivers/misc/enclosure.c
@@ -285,8 +285,11 @@ enclosure_component_register(struct encl
cdev->groups = enclosure_groups;

err = device_register(cdev);
- if (err)
- ERR_PTR(err);
+ if (err) {
+ ecomp->number = -1;
+ put_device(cdev);
+ return ERR_PTR(err);
+ }

return ecomp;
}

2010-08-06 18:36:30

by Greg KH

[permalink] [raw]
Subject: [32/38] xen: drop xen_sched_clock in favour of using plain wallclock time

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Jeremy Fitzhardinge <[email protected]>

commit 8a22b9996b001c88f2bfb54c6de6a05fc39e177a upstream.

xen_sched_clock only counts unstolen time. In principle this should
be useful to the Linux scheduler so that it knows how much time a process
actually consumed. But in practice this doesn't work very well as the
scheduler expects the sched_clock time to be synchronized between
cpus. It also uses sched_clock to measure the time a task spends
sleeping, in which case "unstolen time" isn't meaningful.

So just use plain xen_clocksource_read to return wallclock nanoseconds
for sched_clock.

Signed-off-by: Jeremy Fitzhardinge <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/xen/enlighten.c | 2 +-
arch/x86/xen/time.c | 39 ---------------------------------------
2 files changed, 1 insertion(+), 40 deletions(-)

--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -927,7 +927,7 @@ static const struct pv_init_ops xen_init
};

static const struct pv_time_ops xen_time_ops __initdata = {
- .sched_clock = xen_sched_clock,
+ .sched_clock = xen_clocksource_read,
};

static const struct pv_cpu_ops xen_cpu_ops __initdata = {
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -155,45 +155,6 @@ static void do_stolen_accounting(void)
account_idle_ticks(ticks);
}

-/*
- * Xen sched_clock implementation. Returns the number of unstolen
- * nanoseconds, which is nanoseconds the VCPU spent in RUNNING+BLOCKED
- * states.
- */
-unsigned long long xen_sched_clock(void)
-{
- struct vcpu_runstate_info state;
- cycle_t now;
- u64 ret;
- s64 offset;
-
- /*
- * Ideally sched_clock should be called on a per-cpu basis
- * anyway, so preempt should already be disabled, but that's
- * not current practice at the moment.
- */
- preempt_disable();
-
- now = xen_clocksource_read();
-
- get_runstate_snapshot(&state);
-
- WARN_ON(state.state != RUNSTATE_running);
-
- offset = now - state.state_entry_time;
- if (offset < 0)
- offset = 0;
-
- ret = state.time[RUNSTATE_blocked] +
- state.time[RUNSTATE_running] +
- offset;
-
- preempt_enable();
-
- return ret;
-}
-
-
/* Get the TSC speed from Xen */
unsigned long xen_tsc_khz(void)
{

2010-08-06 18:36:47

by Greg KH

[permalink] [raw]
Subject: [38/38] drm/i915: Check overlay stride errata for i830 and i845

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Chris Wilson <[email protected]>

commit a1efd14a99483a4fb9308902397ed86b69454c99 upstream.

Apparently i830 and i845 cannot handle any stride that is not a multiple
of 256, unlike their brethren which do support 64 byte aligned strides.

Signed-off-by: Chris Wilson <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/i915/intel_overlay.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -958,7 +958,7 @@ static int check_overlay_src(struct drm_
|| rec->src_width < N_HORIZ_Y_TAPS*4)
return -EINVAL;

- /* check alingment constrains */
+ /* check alignment constraints */
switch (rec->flags & I915_OVERLAY_TYPE_MASK) {
case I915_OVERLAY_RGB:
/* not implemented */
@@ -990,7 +990,10 @@ static int check_overlay_src(struct drm_
return -EINVAL;

/* stride checking */
- stride_mask = 63;
+ if (IS_I830(dev) || IS_845G(dev))
+ stride_mask = 255;
+ else
+ stride_mask = 63;

if (rec->stride_Y & stride_mask || rec->stride_UV & stride_mask)
return -EINVAL;

2010-08-06 18:36:35

by Greg KH

[permalink] [raw]
Subject: [30/38] CRED: Fix RCU warning due to previous patch fixing __task_cred()s checks

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: David Howells <[email protected]>

commit 694f690d27dadccc8cb9d90532e76593b61fe098 upstream.

Commit 8f92054e7ca1 ("CRED: Fix __task_cred()'s lockdep check and banner
comment") fixed the lockdep checks on __task_cred(). This has shown up
a place in the signalling code where a lock should be held - namely that
check_kill_permission() requires its callers to hold the RCU lock.

Fix group_send_sig_info() to get the RCU read lock around its call to
check_kill_permission().

Without this patch, the following warning can occur:

===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
kernel/signal.c:660 invoked rcu_dereference_check() without protection!
...

Reported-by: Tetsuo Handa <[email protected]>
Signed-off-by: David Howells <[email protected]>
Acked-by: Oleg Nesterov <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/signal.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -637,7 +637,7 @@ static inline bool si_fromuser(const str

/*
* Bad permissions for sending the signal
- * - the caller must hold at least the RCU read lock
+ * - the caller must hold the RCU read lock
*/
static int check_kill_permission(int sig, struct siginfo *info,
struct task_struct *t)
@@ -1127,11 +1127,14 @@ struct sighand_struct *lock_task_sighand

/*
* send signal info to all the members of a group
- * - the caller must hold the RCU read lock at least
*/
int group_send_sig_info(int sig, struct siginfo *info, struct task_struct *p)
{
- int ret = check_kill_permission(sig, info, p);
+ int ret;
+
+ rcu_read_lock();
+ ret = check_kill_permission(sig, info, p);
+ rcu_read_unlock();

if (!ret && sig)
ret = do_send_sig_info(sig, info, p, true);

2010-08-06 18:36:41

by Greg KH

[permalink] [raw]
Subject: [36/38] drm/radeon/kms: handle the case of no active displays properly in the bandwidth code

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Alex Deucher <[email protected]>

commit e06b14ee91a2ddefc9a67443a6cd8ee0fa800115 upstream.

Logic was:
if (mode0 && mode1)
else if (mode0)
else

Should be:
if (mode0 && mode1)
else if (mode0)
else if (mode1)

Otherwise we may end up calculating the priority regs with
unitialized values.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=16492

Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/radeon/rs690.c | 27 +++++++++------------------
drivers/gpu/drm/radeon/rv515.c | 23 +++++++++--------------
2 files changed, 18 insertions(+), 32 deletions(-)

--- a/drivers/gpu/drm/radeon/rs690.c
+++ b/drivers/gpu/drm/radeon/rs690.c
@@ -398,7 +398,9 @@ void rs690_bandwidth_update(struct radeo
struct drm_display_mode *mode1 = NULL;
struct rs690_watermark wm0;
struct rs690_watermark wm1;
- u32 tmp, d1mode_priority_a_cnt, d2mode_priority_a_cnt;
+ u32 tmp;
+ u32 d1mode_priority_a_cnt = S_006548_D1MODE_PRIORITY_A_OFF(1);
+ u32 d2mode_priority_a_cnt = S_006548_D1MODE_PRIORITY_A_OFF(1);
fixed20_12 priority_mark02, priority_mark12, fill_rate;
fixed20_12 a, b;

@@ -495,10 +497,6 @@ void rs690_bandwidth_update(struct radeo
d1mode_priority_a_cnt |= S_006548_D1MODE_PRIORITY_A_ALWAYS_ON(1);
d2mode_priority_a_cnt |= S_006D48_D2MODE_PRIORITY_A_ALWAYS_ON(1);
}
- WREG32(R_006548_D1MODE_PRIORITY_A_CNT, d1mode_priority_a_cnt);
- WREG32(R_00654C_D1MODE_PRIORITY_B_CNT, d1mode_priority_a_cnt);
- WREG32(R_006D48_D2MODE_PRIORITY_A_CNT, d2mode_priority_a_cnt);
- WREG32(R_006D4C_D2MODE_PRIORITY_B_CNT, d2mode_priority_a_cnt);
} else if (mode0) {
if (dfixed_trunc(wm0.dbpp) > 64)
a.full = dfixed_mul(wm0.dbpp, wm0.num_line_pair);
@@ -528,13 +526,7 @@ void rs690_bandwidth_update(struct radeo
d1mode_priority_a_cnt = dfixed_trunc(priority_mark02);
if (rdev->disp_priority == 2)
d1mode_priority_a_cnt |= S_006548_D1MODE_PRIORITY_A_ALWAYS_ON(1);
- WREG32(R_006548_D1MODE_PRIORITY_A_CNT, d1mode_priority_a_cnt);
- WREG32(R_00654C_D1MODE_PRIORITY_B_CNT, d1mode_priority_a_cnt);
- WREG32(R_006D48_D2MODE_PRIORITY_A_CNT,
- S_006D48_D2MODE_PRIORITY_A_OFF(1));
- WREG32(R_006D4C_D2MODE_PRIORITY_B_CNT,
- S_006D4C_D2MODE_PRIORITY_B_OFF(1));
- } else {
+ } else if (mode1) {
if (dfixed_trunc(wm1.dbpp) > 64)
a.full = dfixed_mul(wm1.dbpp, wm1.num_line_pair);
else
@@ -563,13 +555,12 @@ void rs690_bandwidth_update(struct radeo
d2mode_priority_a_cnt = dfixed_trunc(priority_mark12);
if (rdev->disp_priority == 2)
d2mode_priority_a_cnt |= S_006D48_D2MODE_PRIORITY_A_ALWAYS_ON(1);
- WREG32(R_006548_D1MODE_PRIORITY_A_CNT,
- S_006548_D1MODE_PRIORITY_A_OFF(1));
- WREG32(R_00654C_D1MODE_PRIORITY_B_CNT,
- S_00654C_D1MODE_PRIORITY_B_OFF(1));
- WREG32(R_006D48_D2MODE_PRIORITY_A_CNT, d2mode_priority_a_cnt);
- WREG32(R_006D4C_D2MODE_PRIORITY_B_CNT, d2mode_priority_a_cnt);
}
+
+ WREG32(R_006548_D1MODE_PRIORITY_A_CNT, d1mode_priority_a_cnt);
+ WREG32(R_00654C_D1MODE_PRIORITY_B_CNT, d1mode_priority_a_cnt);
+ WREG32(R_006D48_D2MODE_PRIORITY_A_CNT, d2mode_priority_a_cnt);
+ WREG32(R_006D4C_D2MODE_PRIORITY_B_CNT, d2mode_priority_a_cnt);
}

uint32_t rs690_mc_rreg(struct radeon_device *rdev, uint32_t reg)
--- a/drivers/gpu/drm/radeon/rv515.c
+++ b/drivers/gpu/drm/radeon/rv515.c
@@ -925,7 +925,9 @@ void rv515_bandwidth_avivo_update(struct
struct drm_display_mode *mode1 = NULL;
struct rv515_watermark wm0;
struct rv515_watermark wm1;
- u32 tmp, d1mode_priority_a_cnt, d2mode_priority_a_cnt;
+ u32 tmp;
+ u32 d1mode_priority_a_cnt = MODE_PRIORITY_OFF;
+ u32 d2mode_priority_a_cnt = MODE_PRIORITY_OFF;
fixed20_12 priority_mark02, priority_mark12, fill_rate;
fixed20_12 a, b;

@@ -999,10 +1001,6 @@ void rv515_bandwidth_avivo_update(struct
d1mode_priority_a_cnt |= MODE_PRIORITY_ALWAYS_ON;
d2mode_priority_a_cnt |= MODE_PRIORITY_ALWAYS_ON;
}
- WREG32(D1MODE_PRIORITY_A_CNT, d1mode_priority_a_cnt);
- WREG32(D1MODE_PRIORITY_B_CNT, d1mode_priority_a_cnt);
- WREG32(D2MODE_PRIORITY_A_CNT, d2mode_priority_a_cnt);
- WREG32(D2MODE_PRIORITY_B_CNT, d2mode_priority_a_cnt);
} else if (mode0) {
if (dfixed_trunc(wm0.dbpp) > 64)
a.full = dfixed_div(wm0.dbpp, wm0.num_line_pair);
@@ -1032,11 +1030,7 @@ void rv515_bandwidth_avivo_update(struct
d1mode_priority_a_cnt = dfixed_trunc(priority_mark02);
if (rdev->disp_priority == 2)
d1mode_priority_a_cnt |= MODE_PRIORITY_ALWAYS_ON;
- WREG32(D1MODE_PRIORITY_A_CNT, d1mode_priority_a_cnt);
- WREG32(D1MODE_PRIORITY_B_CNT, d1mode_priority_a_cnt);
- WREG32(D2MODE_PRIORITY_A_CNT, MODE_PRIORITY_OFF);
- WREG32(D2MODE_PRIORITY_B_CNT, MODE_PRIORITY_OFF);
- } else {
+ } else if (mode1) {
if (dfixed_trunc(wm1.dbpp) > 64)
a.full = dfixed_div(wm1.dbpp, wm1.num_line_pair);
else
@@ -1065,11 +1059,12 @@ void rv515_bandwidth_avivo_update(struct
d2mode_priority_a_cnt = dfixed_trunc(priority_mark12);
if (rdev->disp_priority == 2)
d2mode_priority_a_cnt |= MODE_PRIORITY_ALWAYS_ON;
- WREG32(D1MODE_PRIORITY_A_CNT, MODE_PRIORITY_OFF);
- WREG32(D1MODE_PRIORITY_B_CNT, MODE_PRIORITY_OFF);
- WREG32(D2MODE_PRIORITY_A_CNT, d2mode_priority_a_cnt);
- WREG32(D2MODE_PRIORITY_B_CNT, d2mode_priority_a_cnt);
}
+
+ WREG32(D1MODE_PRIORITY_A_CNT, d1mode_priority_a_cnt);
+ WREG32(D1MODE_PRIORITY_B_CNT, d1mode_priority_a_cnt);
+ WREG32(D2MODE_PRIORITY_A_CNT, d2mode_priority_a_cnt);
+ WREG32(D2MODE_PRIORITY_B_CNT, d2mode_priority_a_cnt);
}

void rv515_bandwidth_update(struct radeon_device *rdev)

2010-08-06 18:36:14

by Greg KH

[permalink] [raw]
Subject: [22/38] ath9k: fix TSF after reset on AR913x

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Felix Fietkau <[email protected]>

commit f860d526eb2939a1c37128900b5af2b6f3ff7f20 upstream.

When issuing a reset, the TSF value is lost in the hardware because of
the 913x specific cold reset. As with some AR9280 cards, the TSF needs
to be preserved in software here.

Additionally, there's an issue that frequently prevents a successful
TSF write directly after the chip reset. In this case, repeating the
TSF write after the initval-writes usually works.

This patch detects failed TSF writes and recovers from them, taking
into account the delay caused by the initval writes.

Signed-off-by: Felix Fietkau <[email protected]>
Reported-by: Björn Smedman <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/hw.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1268,7 +1268,8 @@ int ath9k_hw_reset(struct ath_hw *ah, st
macStaId1 = REG_READ(ah, AR_STA_ID1) & AR_STA_ID1_BASE_RATE_11B;

/* For chips on which RTC reset is done, save TSF before it gets cleared */
- if (AR_SREV_9280(ah) && ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL))
+ if (AR_SREV_9100(ah) ||
+ (AR_SREV_9280(ah) && ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL)))
tsf = ath9k_hw_gettsf64(ah);

saveLedState = REG_READ(ah, AR_CFG_LED) &
@@ -1300,7 +1301,7 @@ int ath9k_hw_reset(struct ath_hw *ah, st
}

/* Restore TSF */
- if (tsf && AR_SREV_9280(ah) && ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL))
+ if (tsf)
ath9k_hw_settsf64(ah, tsf);

if (AR_SREV_9280_10_OR_LATER(ah))
@@ -1310,6 +1311,17 @@ int ath9k_hw_reset(struct ath_hw *ah, st
if (r)
return r;

+ /*
+ * Some AR91xx SoC devices frequently fail to accept TSF writes
+ * right after the chip reset. When that happens, write a new
+ * value after the initvals have been applied, with an offset
+ * based on measured time difference
+ */
+ if (AR_SREV_9100(ah) && (ath9k_hw_gettsf64(ah) < tsf)) {
+ tsf += 1500;
+ ath9k_hw_settsf64(ah, tsf);
+ }
+
/* Setup MFP options for CCMP */
if (AR_SREV_9280_20_OR_LATER(ah)) {
/* Mask Retry(b11), PwrMgt(b12), MoreData(b13) to 0 in mgmt

2010-08-06 18:37:32

by Greg KH

[permalink] [raw]
Subject: [37/38] drm/i915: Unset cursor if out-of-bounds upon mode change (v4)

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Chris Wilson <[email protected]>

commit cda4b7d3a5b1dcbc0d8e7bad52134347798e9047 upstream.

The docs warn that to position the cursor such that no part of it is
visible on the pipe is an undefined operation. Avoid such circumstances
upon changing the mode, or at any other time, by unsetting the cursor if
it moves out of bounds.

"For normal high resolution display modes, the cursor must have at least a
single pixel positioned over the active screen.” (p143, p148 of the hardware
registers docs).

Fixes:

Bug 24748 - [965G] Graphics crashes when resolution is changed with KMS
enabled
https://bugs.freedesktop.org/show_bug.cgi?id=24748

v2: Only update the cursor registers if they change.
v3: Fix the unsigned comparision of x,y against width,height.
v4: Always set CUR.BASE or else the cursor may become corrupt.

Signed-off-by: Chris Wilson <[email protected]>
Reported-by: Christian Eggers <[email protected]>
Cc: Christopher James Halse Rogers <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/i915/intel_display.c | 144 ++++++++++++++++++++++-------------
drivers/gpu/drm/i915/intel_drv.h | 8 +
2 files changed, 99 insertions(+), 53 deletions(-)

--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -42,6 +42,7 @@
bool intel_pipe_has_type (struct drm_crtc *crtc, int type);
static void intel_update_watermarks(struct drm_device *dev);
static void intel_increase_pllclock(struct drm_crtc *crtc, bool schedule);
+static void intel_crtc_update_cursor(struct drm_crtc *crtc);

typedef struct {
/* given values */
@@ -3403,6 +3404,9 @@ static int intel_crtc_mode_set(struct dr
return -EINVAL;
}

+ /* Ensure that the cursor is valid for the new mode before changing... */
+ intel_crtc_update_cursor(crtc);
+
if (is_lvds && dev_priv->lvds_downclock_avail) {
has_reduced_clock = limit->find_pll(limit, crtc,
dev_priv->lvds_downclock,
@@ -3939,6 +3943,85 @@ void intel_crtc_load_lut(struct drm_crtc
}
}

+/* If no-part of the cursor is visible on the framebuffer, then the GPU may hang... */
+static void intel_crtc_update_cursor(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc->pipe;
+ int x = intel_crtc->cursor_x;
+ int y = intel_crtc->cursor_y;
+ uint32_t base, pos;
+ bool visible;
+
+ pos = 0;
+
+ if (crtc->fb) {
+ base = intel_crtc->cursor_addr;
+ if (x > (int) crtc->fb->width)
+ base = 0;
+
+ if (y > (int) crtc->fb->height)
+ base = 0;
+ } else
+ base = 0;
+
+ if (x < 0) {
+ if (x + intel_crtc->cursor_width < 0)
+ base = 0;
+
+ pos |= CURSOR_POS_SIGN << CURSOR_X_SHIFT;
+ x = -x;
+ }
+ pos |= x << CURSOR_X_SHIFT;
+
+ if (y < 0) {
+ if (y + intel_crtc->cursor_height < 0)
+ base = 0;
+
+ pos |= CURSOR_POS_SIGN << CURSOR_Y_SHIFT;
+ y = -y;
+ }
+ pos |= y << CURSOR_Y_SHIFT;
+
+ visible = base != 0;
+ if (!visible && !intel_crtc->cursor_visble)
+ return;
+
+ I915_WRITE(pipe == 0 ? CURAPOS : CURBPOS, pos);
+ if (intel_crtc->cursor_visble != visible) {
+ uint32_t cntl = I915_READ(pipe == 0 ? CURACNTR : CURBCNTR);
+ if (base) {
+ /* Hooray for CUR*CNTR differences */
+ if (IS_MOBILE(dev) || IS_I9XX(dev)) {
+ cntl &= ~(CURSOR_MODE | MCURSOR_PIPE_SELECT);
+ cntl |= CURSOR_MODE_64_ARGB_AX | MCURSOR_GAMMA_ENABLE;
+ cntl |= pipe << 28; /* Connect to correct pipe */
+ } else {
+ cntl &= ~(CURSOR_FORMAT_MASK);
+ cntl |= CURSOR_ENABLE;
+ cntl |= CURSOR_FORMAT_ARGB | CURSOR_GAMMA_ENABLE;
+ }
+ } else {
+ if (IS_MOBILE(dev) || IS_I9XX(dev)) {
+ cntl &= ~(CURSOR_MODE | MCURSOR_GAMMA_ENABLE);
+ cntl |= CURSOR_MODE_DISABLE;
+ } else {
+ cntl &= ~(CURSOR_ENABLE | CURSOR_GAMMA_ENABLE);
+ }
+ }
+ I915_WRITE(pipe == 0 ? CURACNTR : CURBCNTR, cntl);
+
+ intel_crtc->cursor_visble = visible;
+ }
+ /* and commit changes on next vblank */
+ I915_WRITE(pipe == 0 ? CURABASE : CURBBASE, base);
+
+ if (visible)
+ intel_mark_busy(dev, to_intel_framebuffer(crtc->fb)->obj);
+}
+
static int intel_crtc_cursor_set(struct drm_crtc *crtc,
struct drm_file *file_priv,
uint32_t handle,
@@ -3949,11 +4032,7 @@ static int intel_crtc_cursor_set(struct
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_gem_object *bo;
struct drm_i915_gem_object *obj_priv;
- int pipe = intel_crtc->pipe;
- uint32_t control = (pipe == 0) ? CURACNTR : CURBCNTR;
- uint32_t base = (pipe == 0) ? CURABASE : CURBBASE;
- uint32_t temp = I915_READ(control);
- size_t addr;
+ uint32_t addr;
int ret;

DRM_DEBUG_KMS("\n");
@@ -3961,12 +4040,6 @@ static int intel_crtc_cursor_set(struct
/* if we want to turn off the cursor ignore width and height */
if (!handle) {
DRM_DEBUG_KMS("cursor off\n");
- if (IS_MOBILE(dev) || IS_I9XX(dev)) {
- temp &= ~(CURSOR_MODE | MCURSOR_GAMMA_ENABLE);
- temp |= CURSOR_MODE_DISABLE;
- } else {
- temp &= ~(CURSOR_ENABLE | CURSOR_GAMMA_ENABLE);
- }
addr = 0;
bo = NULL;
mutex_lock(&dev->struct_mutex);
@@ -4008,7 +4081,8 @@ static int intel_crtc_cursor_set(struct

addr = obj_priv->gtt_offset;
} else {
- ret = i915_gem_attach_phys_object(dev, bo, (pipe == 0) ? I915_GEM_PHYS_CURSOR_0 : I915_GEM_PHYS_CURSOR_1);
+ ret = i915_gem_attach_phys_object(dev, bo,
+ (intel_crtc->pipe == 0) ? I915_GEM_PHYS_CURSOR_0 : I915_GEM_PHYS_CURSOR_1);
if (ret) {
DRM_ERROR("failed to attach phys object\n");
goto fail_locked;
@@ -4019,21 +4093,7 @@ static int intel_crtc_cursor_set(struct
if (!IS_I9XX(dev))
I915_WRITE(CURSIZE, (height << 12) | width);

- /* Hooray for CUR*CNTR differences */
- if (IS_MOBILE(dev) || IS_I9XX(dev)) {
- temp &= ~(CURSOR_MODE | MCURSOR_PIPE_SELECT);
- temp |= CURSOR_MODE_64_ARGB_AX | MCURSOR_GAMMA_ENABLE;
- temp |= (pipe << 28); /* Connect to correct pipe */
- } else {
- temp &= ~(CURSOR_FORMAT_MASK);
- temp |= CURSOR_ENABLE;
- temp |= CURSOR_FORMAT_ARGB | CURSOR_GAMMA_ENABLE;
- }
-
finish:
- I915_WRITE(control, temp);
- I915_WRITE(base, addr);
-
if (intel_crtc->cursor_bo) {
if (dev_priv->info->cursor_needs_physical) {
if (intel_crtc->cursor_bo != bo)
@@ -4047,6 +4107,10 @@ static int intel_crtc_cursor_set(struct

intel_crtc->cursor_addr = addr;
intel_crtc->cursor_bo = bo;
+ intel_crtc->cursor_width = width;
+ intel_crtc->cursor_height = height;
+
+ intel_crtc_update_cursor(crtc);

return 0;
fail_unpin:
@@ -4060,34 +4124,12 @@ fail:

static int intel_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
{
- struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_framebuffer *intel_fb;
- int pipe = intel_crtc->pipe;
- uint32_t temp = 0;
- uint32_t adder;
-
- if (crtc->fb) {
- intel_fb = to_intel_framebuffer(crtc->fb);
- intel_mark_busy(dev, intel_fb->obj);
- }
-
- if (x < 0) {
- temp |= CURSOR_POS_SIGN << CURSOR_X_SHIFT;
- x = -x;
- }
- if (y < 0) {
- temp |= CURSOR_POS_SIGN << CURSOR_Y_SHIFT;
- y = -y;
- }

- temp |= x << CURSOR_X_SHIFT;
- temp |= y << CURSOR_Y_SHIFT;
+ intel_crtc->cursor_x = x;
+ intel_crtc->cursor_y = y;

- adder = intel_crtc->cursor_addr;
- I915_WRITE((pipe == 0) ? CURAPOS : CURBPOS, temp);
- I915_WRITE((pipe == 0) ? CURABASE : CURBBASE, adder);
+ intel_crtc_update_cursor(crtc);

return 0;
}
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -143,8 +143,6 @@ struct intel_crtc {
struct drm_crtc base;
enum pipe pipe;
enum plane plane;
- struct drm_gem_object *cursor_bo;
- uint32_t cursor_addr;
u8 lut_r[256], lut_g[256], lut_b[256];
int dpms_mode;
bool busy; /* is scanout buffer being updated frequently? */
@@ -153,6 +151,12 @@ struct intel_crtc {
struct intel_overlay *overlay;
struct intel_unpin_work *unpin_work;
int fdi_lanes;
+
+ struct drm_gem_object *cursor_bo;
+ uint32_t cursor_addr;
+ int16_t cursor_x, cursor_y;
+ int16_t cursor_width, cursor_height;
+ bool cursor_visble;
};

#define to_intel_crtc(x) container_of(x, struct intel_crtc, base)

2010-08-06 18:37:49

by Greg KH

[permalink] [raw]
Subject: [34/38] drm/radeon: fall back to GTT if bo creation/validation in VRAM fails.

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Michel Dänzer <[email protected]>

commit e376573f7267390f4e1bdc552564b6fb913bce76 upstream.

This fixes a problem where on low VRAM cards we'd run out of space for validation.

[airlied: Tested on my M7, Thinkpad T42, compiz works with no problems.]

Signed-off-by: Michel Dänzer <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/radeon/radeon_object.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)

--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -110,6 +110,7 @@ int radeon_bo_create(struct radeon_devic
bo->surface_reg = -1;
INIT_LIST_HEAD(&bo->list);

+retry:
radeon_ttm_placement_from_domain(bo, domain);
/* Kernel allocation are uninterruptible */
mutex_lock(&rdev->vram_mutex);
@@ -118,10 +119,15 @@ int radeon_bo_create(struct radeon_devic
&radeon_ttm_bo_destroy);
mutex_unlock(&rdev->vram_mutex);
if (unlikely(r != 0)) {
- if (r != -ERESTARTSYS)
+ if (r != -ERESTARTSYS) {
+ if (domain == RADEON_GEM_DOMAIN_VRAM) {
+ domain |= RADEON_GEM_DOMAIN_GTT;
+ goto retry;
+ }
dev_err(rdev->dev,
"object_init failed for (%lu, 0x%08X)\n",
size, domain);
+ }
return r;
}
*bo_ptr = bo;
@@ -321,6 +327,7 @@ int radeon_bo_list_validate(struct list_
{
struct radeon_bo_list *lobj;
struct radeon_bo *bo;
+ u32 domain;
int r;

list_for_each_entry(lobj, head, list) {
@@ -333,17 +340,19 @@ int radeon_bo_list_validate(struct list_
list_for_each_entry(lobj, head, list) {
bo = lobj->bo;
if (!bo->pin_count) {
- if (lobj->wdomain) {
- radeon_ttm_placement_from_domain(bo,
- lobj->wdomain);
- } else {
- radeon_ttm_placement_from_domain(bo,
- lobj->rdomain);
- }
+ domain = lobj->wdomain ? lobj->wdomain : lobj->rdomain;
+
+ retry:
+ radeon_ttm_placement_from_domain(bo, domain);
r = ttm_bo_validate(&bo->tbo, &bo->placement,
true, false, false);
- if (unlikely(r))
+ if (unlikely(r)) {
+ if (r != -ERESTARTSYS && domain == RADEON_GEM_DOMAIN_VRAM) {
+ domain |= RADEON_GEM_DOMAIN_GTT;
+ goto retry;
+ }
return r;
+ }
}
lobj->gpu_offset = radeon_bo_gpu_offset(bo);
lobj->tiling_flags = bo->tiling_flags;

2010-08-06 18:36:06

by Greg KH

[permalink] [raw]
Subject: [19/38] ath9k: fix retry count for A-MPDU rate control status reports

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Felix Fietkau <[email protected]>

commit 78c4653a2274479547e259e1f416d2b3d04c42a8 upstream.

The 'bf_retries' field of the ath_buf structure was used for both
software retries (AMPDU subframes) and hardware retries (legacy
frames). This led to a wrong retry count being reported for the A-MPDU
rate control stats.
This patch changes the code to no longer use bf_retries for reporting
retry counts, but instead always using the real on-chip retry count
from the ath_tx_status.
Additionally, if the first subframe of an A-MPDU was not acked, the tx
status report is submitted along with the first acked subframe, which
may not contain the correct rates in the tx info.
This is easily corrected by saving the tx rate info before looping over
subframes, and then copying it back once the A-MPDU status report is
submitted.
In my tests this change improves throughput visibly.

Signed-off-by: Felix Fietkau <[email protected]>
Reported-by: Björn Smedman <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/xmit.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -328,6 +328,7 @@ static void ath_tx_complete_aggr(struct
u32 ba[WME_BA_BMP_SIZE >> 5];
int isaggr, txfail, txpending, sendbar = 0, needreset = 0, nbad = 0;
bool rc_update = true;
+ struct ieee80211_tx_rate rates[4];

skb = bf->bf_mpdu;
hdr = (struct ieee80211_hdr *)skb->data;
@@ -335,6 +336,8 @@ static void ath_tx_complete_aggr(struct
tx_info = IEEE80211_SKB_CB(skb);
hw = bf->aphy->hw;

+ memcpy(rates, tx_info->control.rates, sizeof(rates));
+
rcu_read_lock();

/* XXX: use ieee80211_find_sta! */
@@ -375,6 +378,9 @@ static void ath_tx_complete_aggr(struct
txfail = txpending = 0;
bf_next = bf->bf_next;

+ skb = bf->bf_mpdu;
+ tx_info = IEEE80211_SKB_CB(skb);
+
if (ATH_BA_ISSET(ba, ATH_BA_INDEX(seq_st, bf->bf_seqno))) {
/* transmit completion, subframe is
* acked by block ack */
@@ -428,6 +434,7 @@ static void ath_tx_complete_aggr(struct
spin_unlock_bh(&txq->axq_lock);

if (rc_update && (acked_cnt == 1 || txfail_cnt == 1)) {
+ memcpy(tx_info->control.rates, rates, sizeof(rates));
ath_tx_rc_status(bf, ts, nbad, txok, true);
rc_update = false;
} else {
@@ -2050,7 +2057,7 @@ static void ath_tx_rc_status(struct ath_
tx_info->status.rates[i].idx = -1;
}

- tx_info->status.rates[tx_rateindex].count = bf->bf_retries + 1;
+ tx_info->status.rates[tx_rateindex].count = ts->ts_longretry + 1;
}

static void ath_wake_mac80211_queue(struct ath_softc *sc, struct ath_txq *txq)
@@ -2161,7 +2168,6 @@ static void ath_tx_processq(struct ath_s
* This frame is sent out as a single frame.
* Use hardware retry status for this frame.
*/
- bf->bf_retries = ts.ts_longretry;
if (ts.ts_status & ATH9K_TXERR_XRETRY)
bf->bf_state.bf_type |= BUF_XRETRY;
ath_tx_rc_status(bf, &ts, 0, txok, true);
@@ -2280,7 +2286,6 @@ void ath_tx_edma_tasklet(struct ath_soft
txok = !(txs.ts_status & ATH9K_TXERR_MASK);

if (!bf_isampdu(bf)) {
- bf->bf_retries = txs.ts_longretry;
if (txs.ts_status & ATH9K_TXERR_XRETRY)
bf->bf_state.bf_type |= BUF_XRETRY;
ath_tx_rc_status(bf, &txs, 0, txok, true);

2010-08-06 18:37:55

by Greg KH

[permalink] [raw]
Subject: [35/38] drm/radeon/kms/r7xx: add workaround for hw issue with HDP flush

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Alex Deucher <[email protected]>

commit 812d046915f48236657f02c06d7dc47140e9ceda upstream.

Use of HDP_*_COHERENCY_FLUSH_CNTL can cause a hang in certain
situations. Add workaround.

Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/radeon/r600.c | 24 ++++++++++++++++++++++--
drivers/gpu/drm/radeon/r600d.h | 1 +
drivers/gpu/drm/radeon/rv770.c | 5 ++++-
drivers/gpu/drm/radeon/rv770d.h | 1 +
4 files changed, 28 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -869,7 +869,17 @@ void r600_pcie_gart_tlb_flush(struct rad
u32 tmp;

/* flush hdp cache so updates hit vram */
- WREG32(R_005480_HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
+ if ((rdev->family >= CHIP_RV770) && (rdev->family <= CHIP_RV740)) {
+ void __iomem *ptr = (void *)rdev->gart.table.vram.ptr;
+ u32 tmp;
+
+ /* r7xx hw bug. write to HDP_DEBUG1 followed by fb read
+ * rather than write to HDP_REG_COHERENCY_FLUSH_CNTL
+ */
+ WREG32(HDP_DEBUG1, 0);
+ tmp = readl((void __iomem *)ptr);
+ } else
+ WREG32(R_005480_HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);

WREG32(VM_CONTEXT0_INVALIDATION_LOW_ADDR, rdev->mc.gtt_start >> 12);
WREG32(VM_CONTEXT0_INVALIDATION_HIGH_ADDR, (rdev->mc.gtt_end - 1) >> 12);
@@ -3512,5 +3522,15 @@ int r600_debugfs_mc_info_init(struct rad
*/
void r600_ioctl_wait_idle(struct radeon_device *rdev, struct radeon_bo *bo)
{
- WREG32(R_005480_HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
+ /* r7xx hw bug. write to HDP_DEBUG1 followed by fb read
+ * rather than write to HDP_REG_COHERENCY_FLUSH_CNTL
+ */
+ if ((rdev->family >= CHIP_RV770) && (rdev->family <= CHIP_RV740)) {
+ void __iomem *ptr = (void *)rdev->gart.table.vram.ptr;
+ u32 tmp;
+
+ WREG32(HDP_DEBUG1, 0);
+ tmp = readl((void __iomem *)ptr);
+ } else
+ WREG32(R_005480_HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
}
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -245,6 +245,7 @@
#define HDP_NONSURFACE_SIZE 0x2C0C
#define HDP_REG_COHERENCY_FLUSH_CNTL 0x54A0
#define HDP_TILING_CONFIG 0x2F3C
+#define HDP_DEBUG1 0x2F34

#define MC_VM_AGP_TOP 0x2184
#define MC_VM_AGP_BOT 0x2188
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -189,7 +189,10 @@ static void rv770_mc_program(struct rade
WREG32((0x2c20 + j), 0x00000000);
WREG32((0x2c24 + j), 0x00000000);
}
- WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
+ /* r7xx hw bug. Read from HDP_DEBUG1 rather
+ * than writing to HDP_REG_COHERENCY_FLUSH_CNTL
+ */
+ tmp = RREG32(HDP_DEBUG1);

rv515_mc_stop(rdev, &save);
if (r600_mc_wait_for_idle(rdev)) {
--- a/drivers/gpu/drm/radeon/rv770d.h
+++ b/drivers/gpu/drm/radeon/rv770d.h
@@ -128,6 +128,7 @@
#define HDP_NONSURFACE_SIZE 0x2C0C
#define HDP_REG_COHERENCY_FLUSH_CNTL 0x54A0
#define HDP_TILING_CONFIG 0x2F3C
+#define HDP_DEBUG1 0x2F34

#define MC_SHARED_CHMAP 0x2004
#define NOOFCHAN_SHIFT 12

2010-08-06 18:38:07

by Greg KH

[permalink] [raw]
Subject: [33/38] drm/radeon: add new pci ids

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Alex Deucher <[email protected]>

commit 1297c05a8dfb568c689f057d51a65eebe5ddc86f upstream.

New evergreen and r7xx ids.

Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/drm/drm_pciids.h | 7 +++++++
1 file changed, 7 insertions(+)

--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -146,6 +146,8 @@
{0x1002, 0x6888, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CYPRESS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6889, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CYPRESS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x688A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CYPRESS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x688C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CYPRESS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x688D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CYPRESS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6898, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CYPRESS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6899, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CYPRESS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x689c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_HEMLOCK|RADEON_NEW_MEMMAP}, \
@@ -161,6 +163,7 @@
{0x1002, 0x68be, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_JUNIPER|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68c0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_REDWOOD|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68c1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_REDWOOD|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x68c7, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_REDWOOD|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68c8, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_REDWOOD|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68c9, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_REDWOOD|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68d8, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_REDWOOD|RADEON_NEW_MEMMAP}, \
@@ -174,6 +177,7 @@
{0x1002, 0x68e8, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68e9, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68f1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x68f2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68f8, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68f9, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68fe, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
@@ -314,6 +318,7 @@
{0x1002, 0x9456, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x945A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x945B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x945E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9460, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9462, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x946A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
@@ -324,6 +329,7 @@
{0x1002, 0x9487, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9488, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9489, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x948A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x948F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9490, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9491, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
@@ -366,6 +372,7 @@
{0x1002, 0x9553, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9555, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9557, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x955f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9580, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV630|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9581, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV630|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9583, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV630|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \

2010-08-06 18:38:42

by Greg KH

[permalink] [raw]
Subject: [29/38] mac80211: avoid scheduling while atomic in mesh_rx_plink_frame

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: John W. Linville <[email protected]>

commit c937019761a758f2749b1f3a032b7a91fb044753 upstream.

While mesh_rx_plink_frame holds sta->lock...

mesh_rx_plink_frame ->
mesh_plink_inc_estab_count ->
ieee80211_bss_info_change_notify

...but ieee80211_bss_info_change_notify is allowed to sleep. A driver
taking advantage of that allowance can cause a scheduling while
atomic bug. Similar paths exist for mesh_plink_dec_estab_count,
so work around those as well.

http://bugzilla.kernel.org/show_bug.cgi?id=16099

Also, correct a minor kerneldoc comment error (mismatched function names).

Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/mac80211/mesh_plink.c | 42 +++++++++++++++++++++++++++++++-----------
1 file changed, 31 insertions(+), 11 deletions(-)

--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -65,7 +65,6 @@ void mesh_plink_inc_estab_count(struct i
{
atomic_inc(&sdata->u.mesh.mshstats.estab_plinks);
mesh_accept_plinks_update(sdata);
- ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
}

static inline
@@ -73,7 +72,6 @@ void mesh_plink_dec_estab_count(struct i
{
atomic_dec(&sdata->u.mesh.mshstats.estab_plinks);
mesh_accept_plinks_update(sdata);
- ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
}

/**
@@ -115,7 +113,7 @@ static struct sta_info *mesh_plink_alloc
}

/**
- * mesh_plink_deactivate - deactivate mesh peer link
+ * __mesh_plink_deactivate - deactivate mesh peer link
*
* @sta: mesh peer link to deactivate
*
@@ -123,18 +121,23 @@ static struct sta_info *mesh_plink_alloc
*
* Locking: the caller must hold sta->lock
*/
-static void __mesh_plink_deactivate(struct sta_info *sta)
+static bool __mesh_plink_deactivate(struct sta_info *sta)
{
struct ieee80211_sub_if_data *sdata = sta->sdata;
+ bool deactivated = false;

- if (sta->plink_state == PLINK_ESTAB)
+ if (sta->plink_state == PLINK_ESTAB) {
mesh_plink_dec_estab_count(sdata);
+ deactivated = true;
+ }
sta->plink_state = PLINK_BLOCKED;
mesh_path_flush_by_nexthop(sta);
+
+ return deactivated;
}

/**
- * __mesh_plink_deactivate - deactivate mesh peer link
+ * mesh_plink_deactivate - deactivate mesh peer link
*
* @sta: mesh peer link to deactivate
*
@@ -142,9 +145,15 @@ static void __mesh_plink_deactivate(stru
*/
void mesh_plink_deactivate(struct sta_info *sta)
{
+ struct ieee80211_sub_if_data *sdata = sta->sdata;
+ bool deactivated;
+
spin_lock_bh(&sta->lock);
- __mesh_plink_deactivate(sta);
+ deactivated = __mesh_plink_deactivate(sta);
spin_unlock_bh(&sta->lock);
+
+ if (deactivated)
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
}

static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
@@ -381,10 +390,16 @@ int mesh_plink_open(struct sta_info *sta

void mesh_plink_block(struct sta_info *sta)
{
+ struct ieee80211_sub_if_data *sdata = sta->sdata;
+ bool deactivated;
+
spin_lock_bh(&sta->lock);
- __mesh_plink_deactivate(sta);
+ deactivated = __mesh_plink_deactivate(sta);
sta->plink_state = PLINK_BLOCKED;
spin_unlock_bh(&sta->lock);
+
+ if (deactivated)
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
}


@@ -397,6 +412,7 @@ void mesh_rx_plink_frame(struct ieee8021
enum plink_event event;
enum plink_frame_type ftype;
size_t baselen;
+ bool deactivated;
u8 ie_len;
u8 *baseaddr;
__le16 plid, llid, reason;
@@ -651,8 +667,9 @@ void mesh_rx_plink_frame(struct ieee8021
case CNF_ACPT:
del_timer(&sta->plink_timer);
sta->plink_state = PLINK_ESTAB;
- mesh_plink_inc_estab_count(sdata);
spin_unlock_bh(&sta->lock);
+ mesh_plink_inc_estab_count(sdata);
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
mpl_dbg("Mesh plink with %pM ESTABLISHED\n",
sta->sta.addr);
break;
@@ -684,8 +701,9 @@ void mesh_rx_plink_frame(struct ieee8021
case OPN_ACPT:
del_timer(&sta->plink_timer);
sta->plink_state = PLINK_ESTAB;
- mesh_plink_inc_estab_count(sdata);
spin_unlock_bh(&sta->lock);
+ mesh_plink_inc_estab_count(sdata);
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
mpl_dbg("Mesh plink with %pM ESTABLISHED\n",
sta->sta.addr);
mesh_plink_frame_tx(sdata, PLINK_CONFIRM, sta->sta.addr, llid,
@@ -702,11 +720,13 @@ void mesh_rx_plink_frame(struct ieee8021
case CLS_ACPT:
reason = cpu_to_le16(MESH_CLOSE_RCVD);
sta->reason = reason;
- __mesh_plink_deactivate(sta);
+ deactivated = __mesh_plink_deactivate(sta);
sta->plink_state = PLINK_HOLDING;
llid = sta->llid;
mod_plink_timer(sta, dot11MeshHoldingTimeout(sdata));
spin_unlock_bh(&sta->lock);
+ if (deactivated)
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
mesh_plink_frame_tx(sdata, PLINK_CLOSE, sta->sta.addr, llid,
plid, reason);
break;

2010-08-06 18:38:49

by Greg KH

[permalink] [raw]
Subject: [28/38] cfg80211: dont get expired BSSes

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Johannes Berg <[email protected]>

commit ccb6c1360f8dd43303c659db718e7e0b24175db5 upstream.

When kernel-internal users use cfg80211_get_bss()
to get a reference to a BSS struct, they may end
up getting one that would have been removed from
the list if there had been any userspace access
to the list. This leads to inconsistencies and
problems.

Fix it by making cfg80211_get_bss() ignore BSSes
that cfg80211_bss_expire() would remove.

Fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2180

Reported-by: Jiajia Zheng <[email protected]>
Tested-by: Jiajia Zheng <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/wireless/scan.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -275,6 +275,7 @@ struct cfg80211_bss *cfg80211_get_bss(st
{
struct cfg80211_registered_device *dev = wiphy_to_dev(wiphy);
struct cfg80211_internal_bss *bss, *res = NULL;
+ unsigned long now = jiffies;

spin_lock_bh(&dev->bss_lock);

@@ -283,6 +284,10 @@ struct cfg80211_bss *cfg80211_get_bss(st
continue;
if (channel && bss->pub.channel != channel)
continue;
+ /* Don't get expired BSS structs */
+ if (time_after(now, bss->ts + IEEE80211_SCAN_RESULT_EXPIRE) &&
+ !atomic_read(&bss->hold))
+ continue;
if (is_bss(&bss->pub, bssid, ssid, ssid_len)) {
res = bss;
kref_get(&res->ref);

2010-08-06 18:39:25

by Greg KH

[permalink] [raw]
Subject: [27/38] cfg80211: ignore spurious deauth

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Johannes Berg <[email protected]>

commit 643f82e32f14faf0d0944c804203a6681b6b0a1e upstream.

Ever since mac80211/drivers are no longer
fully in charge of keeping track of the
auth status, trying to make them do so will
fail. Instead of warning and reporting the
deauthentication to userspace, cfg80211 must
simply ignore it so that spurious
deauthentications, e.g. before starting
authentication, aren't seen by userspace as
actual deauthentications.

Reported-by: Paul Stewart <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/wireless/mlme.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -44,10 +44,10 @@ void cfg80211_send_rx_auth(struct net_de
}
}

- WARN_ON(!done);
-
- nl80211_send_rx_auth(rdev, dev, buf, len, GFP_KERNEL);
- cfg80211_sme_rx_auth(dev, buf, len);
+ if (done) {
+ nl80211_send_rx_auth(rdev, dev, buf, len, GFP_KERNEL);
+ cfg80211_sme_rx_auth(dev, buf, len);
+ }

wdev_unlock(wdev);
}

2010-08-06 18:39:32

by Greg KH

[permalink] [raw]
Subject: [26/38] ssb: Handle alternate SSPROM location

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Larry Finger <[email protected]>

commit 9d1ac34ec3a67713308ae0883c3359c557f14d17 upstream.

In kernel Bugzilla #15825 (2 users), in a wireless mailing list thread
(http://lists.infradead.org/pipermail/b43-dev/2010-May/000124.html), and on a
netbook owned by John Linville
(http://marc.info/?l=linux-wireless&m=127230751408818&w=4), there are reports
of ssb failing to detect an SPROM at the normal location. After studying the
MMIO trace dump for the Broadcom wl driver, it was determined that the affected
boxes had a relocated SPROM.

This patch fixes all systems that have reported this problem.

Signed-off-by: Larry Finger <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/ssb/driver_chipcommon.c | 1 +
drivers/ssb/pci.c | 15 +++++++++++++--
2 files changed, 14 insertions(+), 2 deletions(-)

--- a/drivers/ssb/driver_chipcommon.c
+++ b/drivers/ssb/driver_chipcommon.c
@@ -235,6 +235,7 @@ void ssb_chipcommon_init(struct ssb_chip
return; /* We don't have a ChipCommon */
if (cc->dev->id.revision >= 11)
cc->status = chipco_read32(cc, SSB_CHIPCO_CHIPSTAT);
+ ssb_dprintk(KERN_INFO PFX "chipcommon status is 0x%x\n", cc->status);
ssb_pmu_init(cc);
chipco_powercontrol_init(cc);
ssb_chipco_set_clockmode(cc, SSB_CLKMODE_FAST);
--- a/drivers/ssb/pci.c
+++ b/drivers/ssb/pci.c
@@ -626,11 +626,22 @@ static int ssb_pci_sprom_get(struct ssb_
return -ENODEV;
}
if (bus->chipco.dev) { /* can be unavailible! */
- bus->sprom_offset = (bus->chipco.dev->id.revision < 31) ?
- SSB_SPROM_BASE1 : SSB_SPROM_BASE31;
+ /*
+ * get SPROM offset: SSB_SPROM_BASE1 except for
+ * chipcommon rev >= 31 or chip ID is 0x4312 and
+ * chipcommon status & 3 == 2
+ */
+ if (bus->chipco.dev->id.revision >= 31)
+ bus->sprom_offset = SSB_SPROM_BASE31;
+ else if (bus->chip_id == 0x4312 &&
+ (bus->chipco.status & 0x03) == 2)
+ bus->sprom_offset = SSB_SPROM_BASE31;
+ else
+ bus->sprom_offset = SSB_SPROM_BASE1;
} else {
bus->sprom_offset = SSB_SPROM_BASE1;
}
+ ssb_dprintk(KERN_INFO PFX "SPROM offset is 0x%x\n", bus->sprom_offset);

buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
if (!buf)

2010-08-06 18:39:35

by Greg KH

[permalink] [raw]
Subject: [25/38] iwlwifi: fix scan abort

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Stanislaw Gruszka <[email protected]>

commit d28232b461b8d54b09e59325dbac8b0913ce2049 upstream.

Fix possible double priv->mutex lock introduced by commit
a69b03e941abae00380fc6bc1877fb797a1b31e6
"iwlwifi: cancel scan watchdog in iwl_bg_abort_scan" .
We can not call cancel_delayed_work_sync(&priv->scan_check) with
priv->mutex locked because workqueue function iwl_bg_scan_check()
take that lock internally.

We do not need to synchronize when canceling priv->scan_check work.
We can avoid races (sending double abort command or send no
command at all) using STATUS_SCAN_ABORT bit. Moreover
current iwl_bg_scan_check() code seems to be broken, as
we should not send abort commands when currently aborting.

Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/iwlwifi/iwl-scan.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)

--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@ -420,11 +420,10 @@ void iwl_bg_scan_check(struct work_struc
return;

mutex_lock(&priv->mutex);
- if (test_bit(STATUS_SCANNING, &priv->status) ||
- test_bit(STATUS_SCAN_ABORTING, &priv->status)) {
- IWL_DEBUG_SCAN(priv, "Scan completion watchdog resetting "
- "adapter (%dms)\n",
- jiffies_to_msecs(IWL_SCAN_CHECK_WATCHDOG));
+ if (test_bit(STATUS_SCANNING, &priv->status) &&
+ !test_bit(STATUS_SCAN_ABORTING, &priv->status)) {
+ IWL_DEBUG_SCAN(priv, "Scan completion watchdog (%dms)\n",
+ jiffies_to_msecs(IWL_SCAN_CHECK_WATCHDOG));

if (!test_bit(STATUS_EXIT_PENDING, &priv->status))
iwl_send_scan_abort(priv);
@@ -489,12 +488,11 @@ void iwl_bg_abort_scan(struct work_struc
!test_bit(STATUS_GEO_CONFIGURED, &priv->status))
return;

- mutex_lock(&priv->mutex);
-
- cancel_delayed_work_sync(&priv->scan_check);
- set_bit(STATUS_SCAN_ABORTING, &priv->status);
- iwl_send_scan_abort(priv);
+ cancel_delayed_work(&priv->scan_check);

+ mutex_lock(&priv->mutex);
+ if (test_bit(STATUS_SCAN_ABORTING, &priv->status))
+ iwl_send_scan_abort(priv);
mutex_unlock(&priv->mutex);
}
EXPORT_SYMBOL(iwl_bg_abort_scan);

2010-08-06 18:39:57

by Greg KH

[permalink] [raw]
Subject: [24/38] ath9k_hw: fix antenna diversity on AR9285

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Felix Fietkau <[email protected]>

commit 601e0cb165e65dc185b31fe7ebd2c0169ea47306 upstream.

On AR9285, the antenna switch configuration register uses more than just
16 bits. Because of an arbitrary mask applied to the EEPROM value that
stores this configuration, diversity was broken in some cases, leading
to a significant degradation in signal strength.
Fix this by changing the callback to return a 32 bit value and remove
the arbitrary mask.

Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom.h | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 4 ++--
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 4 ++--
drivers/net/wireless/ath/ath9k/eeprom_def.c | 4 ++--
5 files changed, 8 insertions(+), 8 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -944,7 +944,7 @@ static u8 ath9k_hw_ar9300_get_num_ant_co
return 1;
}

-static u16 ath9k_hw_ar9300_get_eeprom_antenna_cfg(struct ath_hw *ah,
+static u32 ath9k_hw_ar9300_get_eeprom_antenna_cfg(struct ath_hw *ah,
struct ath9k_channel *chan)
{
return -EINVAL;
--- a/drivers/net/wireless/ath/ath9k/eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/eeprom.h
@@ -669,7 +669,7 @@ struct eeprom_ops {
int (*get_eeprom_ver)(struct ath_hw *hw);
int (*get_eeprom_rev)(struct ath_hw *hw);
u8 (*get_num_ant_config)(struct ath_hw *hw, enum ieee80211_band band);
- u16 (*get_eeprom_antenna_cfg)(struct ath_hw *hw,
+ u32 (*get_eeprom_antenna_cfg)(struct ath_hw *hw,
struct ath9k_channel *chan);
void (*set_board_values)(struct ath_hw *hw, struct ath9k_channel *chan);
void (*set_addac)(struct ath_hw *hw, struct ath9k_channel *chan);
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -1149,13 +1149,13 @@ static void ath9k_hw_4k_set_board_values
}
}

-static u16 ath9k_hw_4k_get_eeprom_antenna_cfg(struct ath_hw *ah,
+static u32 ath9k_hw_4k_get_eeprom_antenna_cfg(struct ath_hw *ah,
struct ath9k_channel *chan)
{
struct ar5416_eeprom_4k *eep = &ah->eeprom.map4k;
struct modal_eep_4k_header *pModal = &eep->modalHeader;

- return pModal->antCtrlCommon & 0xFFFF;
+ return pModal->antCtrlCommon;
}

static u8 ath9k_hw_4k_get_num_ant_config(struct ath_hw *ah,
--- a/drivers/net/wireless/ath/ath9k/eeprom_9287.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
@@ -1131,13 +1131,13 @@ static u8 ath9k_hw_AR9287_get_num_ant_co
return 1;
}

-static u16 ath9k_hw_AR9287_get_eeprom_antenna_cfg(struct ath_hw *ah,
+static u32 ath9k_hw_AR9287_get_eeprom_antenna_cfg(struct ath_hw *ah,
struct ath9k_channel *chan)
{
struct ar9287_eeprom *eep = &ah->eeprom.map9287;
struct modal_eep_ar9287_header *pModal = &eep->modalHeader;

- return pModal->antCtrlCommon & 0xFFFF;
+ return pModal->antCtrlCommon;
}

static u16 ath9k_hw_AR9287_get_spur_channel(struct ath_hw *ah,
--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
@@ -1437,14 +1437,14 @@ static u8 ath9k_hw_def_get_num_ant_confi
return num_ant_config;
}

-static u16 ath9k_hw_def_get_eeprom_antenna_cfg(struct ath_hw *ah,
+static u32 ath9k_hw_def_get_eeprom_antenna_cfg(struct ath_hw *ah,
struct ath9k_channel *chan)
{
struct ar5416_eeprom_def *eep = &ah->eeprom.def;
struct modal_eep_header *pModal =
&(eep->modalHeader[IS_CHAN_2GHZ(chan)]);

- return pModal->antCtrlCommon & 0xFFFF;
+ return pModal->antCtrlCommon;
}

static u16 ath9k_hw_def_get_spur_channel(struct ath_hw *ah, u16 i, bool is2GHz)

2010-08-06 18:40:07

by Greg KH

[permalink] [raw]
Subject: [23/38] ath9k: fix yet another buffer leak in the tx aggregation code

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Felix Fietkau <[email protected]>

commit 4cee78614cfa046a26c4fbf313d5bbacb3ad8efc upstream.

When an aggregation session is being cleaned up, while the tx status
for some frames is being processed, the TID is flushed and its buffers
are sent out.

Unfortunately that left the pending un-acked frames unprocessed, thus
leaking buffers. Fix this by reordering the code so that those frames
are processed first, before the TID is flushed.

Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/xmit.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -510,6 +510,14 @@ static void ath_tx_complete_aggr(struct
bf = bf_next;
}

+ /* prepend un-acked frames to the beginning of the pending frame queue */
+ if (!list_empty(&bf_pending)) {
+ spin_lock_bh(&txq->axq_lock);
+ list_splice(&bf_pending, &tid->buf_q);
+ ath_tx_queue_tid(txq, tid);
+ spin_unlock_bh(&txq->axq_lock);
+ }
+
if (tid->state & AGGR_CLEANUP) {
if (tid->baw_head == tid->baw_tail) {
tid->state &= ~AGGR_ADDBA_COMPLETE;
@@ -522,14 +530,6 @@ static void ath_tx_complete_aggr(struct
return;
}

- /* prepend un-acked frames to the beginning of the pending frame queue */
- if (!list_empty(&bf_pending)) {
- spin_lock_bh(&txq->axq_lock);
- list_splice(&bf_pending, &tid->buf_q);
- ath_tx_queue_tid(txq, tid);
- spin_unlock_bh(&txq->axq_lock);
- }
-
rcu_read_unlock();

if (needreset)

2010-08-06 18:40:35

by Greg KH

[permalink] [raw]
Subject: [21/38] ath9k: another fix for the A-MPDU buffer leak

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Felix Fietkau <[email protected]>

commit 31e79a5954b78fbed15de2c8974d5a2b6019199a upstream.

The patch 'ath9k: fix a buffer leak in A-MPDU completion' addressed the
issue of running out of buffers/descriptors in the tx path if a STA is
deleted while tx status feedback is still pending.
The remaining issue is that the skbs of the buffers are not reclaimed,
leaving a memory leak.
This patch fixes this issue by running the buffers through
ath_tx_complete_buf(), ensuring that the pending frames counter is also
updated.

Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/xmit.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -329,7 +329,6 @@ static void ath_tx_complete_aggr(struct
int isaggr, txfail, txpending, sendbar = 0, needreset = 0, nbad = 0;
bool rc_update = true;
struct ieee80211_tx_rate rates[4];
- unsigned long flags;

skb = bf->bf_mpdu;
hdr = (struct ieee80211_hdr *)skb->data;
@@ -346,9 +345,21 @@ static void ath_tx_complete_aggr(struct
if (!sta) {
rcu_read_unlock();

- spin_lock_irqsave(&sc->tx.txbuflock, flags);
- list_splice_tail_init(bf_q, &sc->tx.txbuf);
- spin_unlock_irqrestore(&sc->tx.txbuflock, flags);
+ INIT_LIST_HEAD(&bf_head);
+ while (bf) {
+ bf_next = bf->bf_next;
+
+ bf->bf_state.bf_type |= BUF_XRETRY;
+ if ((sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_EDMA) ||
+ !bf->bf_stale || bf_next != NULL)
+ list_move_tail(&bf->list, &bf_head);
+
+ ath_tx_rc_status(bf, ts, 0, 0, false);
+ ath_tx_complete_buf(sc, bf, txq, &bf_head, ts,
+ 0, 0);
+
+ bf = bf_next;
+ }
return;
}


2010-08-06 18:40:40

by Greg KH

[permalink] [raw]
Subject: [20/38] ath9k: fix a buffer leak in A-MPDU completion

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Felix Fietkau <[email protected]>

commit 73e194639d90594d06d0c10019c0ab4638869135 upstream.

When ath_tx_complete_aggr() is called, it's responsible for returning
all buffers in the linked list. This was not done when the STA lookup
failed, leading to a race condition that could leak a few buffers when
a STA just disconnected.
Fix this by immediately returning all buffers to the free list in this case.

Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/xmit.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -329,6 +329,7 @@ static void ath_tx_complete_aggr(struct
int isaggr, txfail, txpending, sendbar = 0, needreset = 0, nbad = 0;
bool rc_update = true;
struct ieee80211_tx_rate rates[4];
+ unsigned long flags;

skb = bf->bf_mpdu;
hdr = (struct ieee80211_hdr *)skb->data;
@@ -344,6 +345,10 @@ static void ath_tx_complete_aggr(struct
sta = ieee80211_find_sta_by_hw(hw, hdr->addr1);
if (!sta) {
rcu_read_unlock();
+
+ spin_lock_irqsave(&sc->tx.txbuflock, flags);
+ list_splice_tail_init(bf_q, &sc->tx.txbuf);
+ spin_unlock_irqrestore(&sc->tx.txbuflock, flags);
return;
}


2010-08-06 18:41:08

by Greg KH

[permalink] [raw]
Subject: [14/38] ath9k: enable serialize_regmode for non-PCIE AR9160

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: John W. Linville <[email protected]>

commit 4c85ab11ca56da1aa59b58c80cc6a356515cc645 upstream.

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

Signed-off-by: John W. Linville <[email protected]>
Acked-by: Luis R. Rodriguez <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/hw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -537,7 +537,8 @@ static int __ath9k_hw_init(struct ath_hw

if (ah->config.serialize_regmode == SER_REG_MODE_AUTO) {
if (ah->hw_version.macVersion == AR_SREV_VERSION_5416_PCI ||
- (AR_SREV_9280(ah) && !ah->is_pciexpress)) {
+ ((AR_SREV_9160(ah) || AR_SREV_9280(ah)) &&
+ !ah->is_pciexpress)) {
ah->config.serialize_regmode =
SER_REG_MODE_ON;
} else {

2010-08-06 18:41:14

by Greg KH

[permalink] [raw]
Subject: [17/38] ath9k_hw: fix a sign error in the IQ calibration code

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Felix Fietkau <[email protected]>

commit 23399016d9583d799ca98ce443a1410b13c3e96e upstream.

Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -239,7 +239,7 @@ static void ar9002_hw_iqcalibrate(struct
if (qCoff > 15)
qCoff = 15;
else if (qCoff <= -16)
- qCoff = 16;
+ qCoff = -16;

ath_print(common, ATH_DBG_CALIBRATE,
"Chn %d : iCoff = 0x%x qCoff = 0x%x\n",

2010-08-06 18:35:39

by Greg KH

[permalink] [raw]
Subject: [09/38] xen: netfront: explicitly generate arp_notify event after migration.

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Ian Campbell <[email protected]>

commit 592970675c9522bde588b945388c7995c8b51328 upstream.

Use newly introduced netif_notify_peers() method to ensure a gratuitous ARP is
generated after a migration.

Signed-off-by: Ian Campbell <[email protected]>
Cc: Stephen Hemminger <[email protected]>
Cc: Jeremy Fitzhardinge <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/xen-netfront.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1621,6 +1621,7 @@ static void backend_changed(struct xenbu
if (xennet_connect(netdev) != 0)
break;
xenbus_switch_state(dev, XenbusStateConnected);
+ netif_notify_peers(netdev);
break;

case XenbusStateClosing:

2010-08-06 18:41:38

by Greg KH

[permalink] [raw]
Subject: [15/38] ath9k: fix a potential buffer leak in the STA teardown path

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Felix Fietkau <[email protected]>

commit 2b40994cabd2f545d5c11d3a65dcee6f6f9155f8 upstream.

It looks like it might be possible for a TID to be paused, while still
holding some queued buffers, however ath_tx_node_cleanup currently only
iterates over active TIDs.
Fix this by always checking every allocated TID for the STA that is being
cleaned up.

Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/xmit.c | 56 +++++++++++++++++-----------------
1 file changed, 28 insertions(+), 28 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2449,37 +2449,37 @@ void ath_tx_node_init(struct ath_softc *

void ath_tx_node_cleanup(struct ath_softc *sc, struct ath_node *an)
{
- int i;
- struct ath_atx_ac *ac, *ac_tmp;
- struct ath_atx_tid *tid, *tid_tmp;
+ struct ath_atx_ac *ac;
+ struct ath_atx_tid *tid;
struct ath_txq *txq;
+ int i, tidno;

- for (i = 0; i < ATH9K_NUM_TX_QUEUES; i++) {
- if (ATH_TXQ_SETUP(sc, i)) {
- txq = &sc->tx.txq[i];
-
- spin_lock_bh(&txq->axq_lock);
-
- list_for_each_entry_safe(ac,
- ac_tmp, &txq->axq_acq, list) {
- tid = list_first_entry(&ac->tid_q,
- struct ath_atx_tid, list);
- if (tid && tid->an != an)
- continue;
- list_del(&ac->list);
- ac->sched = false;
-
- list_for_each_entry_safe(tid,
- tid_tmp, &ac->tid_q, list) {
- list_del(&tid->list);
- tid->sched = false;
- ath_tid_drain(sc, txq, tid);
- tid->state &= ~AGGR_ADDBA_COMPLETE;
- tid->state &= ~AGGR_CLEANUP;
- }
- }
+ for (tidno = 0, tid = &an->tid[tidno];
+ tidno < WME_NUM_TID; tidno++, tid++) {
+ i = tid->ac->qnum;

- spin_unlock_bh(&txq->axq_lock);
+ if (!ATH_TXQ_SETUP(sc, i))
+ continue;
+
+ txq = &sc->tx.txq[i];
+ ac = tid->ac;
+
+ spin_lock_bh(&txq->axq_lock);
+
+ if (tid->sched) {
+ list_del(&tid->list);
+ tid->sched = false;
}
+
+ if (ac->sched) {
+ list_del(&ac->list);
+ tid->ac->sched = false;
+ }
+
+ ath_tid_drain(sc, txq, tid);
+ tid->state &= ~AGGR_ADDBA_COMPLETE;
+ tid->state &= ~AGGR_CLEANUP;
+
+ spin_unlock_bh(&txq->axq_lock);
}
}

2010-08-06 18:35:37

by Greg KH

[permalink] [raw]
Subject: [08/38] arp_notify: allow drivers to explicitly request a notification event.

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Ian Campbell <[email protected]>

commit 06c4648d46d1b757d6b9591a86810be79818b60c upstream.

Currently such notifications are only generated when the device comes up or the
address changes. However one use case for these notifications is to enable
faster network recovery after a virtual machine migration (by causing switches
to relearn their MAC tables). A migration appears to the network stack as a
temporary loss of carrier and therefore does not trigger either of the current
conditions. Rather than adding carrier up as a trigger (which can cause issues
when interfaces a flapping) simply add an interface which the driver can use
to explicitly trigger the notification.

Signed-off-by: Ian Campbell <[email protected]>
Cc: Stephen Hemminger <[email protected]>
Cc: Jeremy Fitzhardinge <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: [email protected]
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/linux/netdevice.h | 2 ++
include/linux/notifier.h | 1 +
net/ipv4/devinet.c | 1 +
net/sched/sch_generic.c | 18 ++++++++++++++++++
4 files changed, 22 insertions(+)

--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1775,6 +1775,8 @@ extern void netif_carrier_on(struct net_

extern void netif_carrier_off(struct net_device *dev);

+extern void netif_notify_peers(struct net_device *dev);
+
/**
* netif_dormant_on - mark device as dormant.
* @dev: network device
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -210,6 +210,7 @@ static inline int notifier_to_errno(int
#define NETDEV_POST_INIT 0x0010
#define NETDEV_UNREGISTER_BATCH 0x0011
#define NETDEV_BONDING_DESLAVE 0x0012
+#define NETDEV_NOTIFY_PEERS 0x0012

#define SYS_DOWN 0x0001 /* Notify of system down */
#define SYS_RESTART SYS_DOWN
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1081,6 +1081,7 @@ static int inetdev_event(struct notifier
}
ip_mc_up(in_dev);
/* fall through */
+ case NETDEV_NOTIFY_PEERS:
case NETDEV_CHANGEADDR:
/* Send gratuitous ARP to notify of link change */
if (IN_DEV_ARP_NOTIFY(in_dev)) {
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -327,6 +327,24 @@ void netif_carrier_off(struct net_device
}
EXPORT_SYMBOL(netif_carrier_off);

+/**
+ * netif_notify_peers - notify network peers about existence of @dev
+ * @dev: network device
+ *
+ * Generate traffic such that interested network peers are aware of
+ * @dev, such as by generating a gratuitous ARP. This may be used when
+ * a device wants to inform the rest of the network about some sort of
+ * reconfiguration such as a failover event or virtual machine
+ * migration.
+ */
+void netif_notify_peers(struct net_device *dev)
+{
+ rtnl_lock();
+ call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, dev);
+ rtnl_unlock();
+}
+EXPORT_SYMBOL(netif_notify_peers);
+
/* "NOOP" scheduler: the best scheduler, recommended for all interfaces
under all circumstances. It is difficult to invent anything faster or
cheaper.

2010-08-06 18:42:16

by Greg KH

[permalink] [raw]
Subject: [13/38] igb: Use only a single Tx queue in SR-IOV mode

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Greg Rose <[email protected]>

commit 5fa8517f038d51d571981fb495206cc30ed91b06 upstream.

The 82576 expects the second rx queue in any pool to receive L2 switch
loop back packets sent from the second tx queue in another pool. The
82576 VF driver does not enable the second rx queue so if the PF driver
sends packets destined to a VF from its second tx queue then the VF
driver will never see them. In SR-IOV mode limit the number of tx queues
used by the PF driver to one. This patch fixes a bug reported in which
the PF cannot communciate with the VF and should be considered for 2.6.34
stable.

Signed-off-by: Greg Rose <[email protected]>
Tested-by: Jeff Pieper <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/igb/igb_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -630,9 +630,6 @@ static void igb_cache_ring_register(stru
for (; i < adapter->rss_queues; i++)
adapter->rx_ring[i]->reg_idx = rbase_offset +
Q_IDX_82576(i);
- for (; j < adapter->rss_queues; j++)
- adapter->tx_ring[j]->reg_idx = rbase_offset +
- Q_IDX_82576(j);
}
case e1000_82575:
case e1000_82580:
@@ -996,7 +993,10 @@ static void igb_set_interrupt_capability

/* Number of supported queues. */
adapter->num_rx_queues = adapter->rss_queues;
- adapter->num_tx_queues = adapter->rss_queues;
+ if (adapter->vfs_allocated_count)
+ adapter->num_tx_queues = 1;
+ else
+ adapter->num_tx_queues = adapter->rss_queues;

/* start with one vector for every rx queue */
numvecs = adapter->num_rx_queues;

2010-08-06 18:35:31

by Greg KH

[permalink] [raw]
Subject: [06/38] amd64_edac: Correct scrub rate setting

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Borislav Petkov <[email protected]>

commit bc57117856cf1e581135810b37d3b75f9d1749f5 upstream.

Exit early when setting scrub rate on unknown/unsupported families.

Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: Doug Thompson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/edac/amd64_edac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -178,7 +178,7 @@ static int amd64_set_scrub_rate(struct m

default:
amd64_printk(KERN_ERR, "Unsupported family!\n");
- break;
+ return -EINVAL;
}
return amd64_search_set_scrub_rate(pvt->misc_f3_ctl, *bandwidth,
min_scrubrate);

2010-08-06 18:42:48

by Greg KH

[permalink] [raw]
Subject: [11/38] e1000e: 82577/82578 PHY register access issues

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Bruce Allan <[email protected]>

commit ff847ac2d3e90edd94674c28bade25ae1e6a2e49 upstream.

The MAC-PHY interconnect on 82577/82578 uses a power management feature
(called K1) which must be disabled when in 1Gbps due to a hardware issue on
these parts. The #define bit setting used to enable/disable K1 is
incorrect and can cause PHY register accesses to stop working altogether
until the next device reset. This patch sets the register correctly.

This issue is present in kernels since 2.6.32.

Signed-off-by: Bruce Allan <[email protected]>
Tested-by: Jeff Pieper <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/e1000e/hw.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/e1000e/hw.h
+++ b/drivers/net/e1000e/hw.h
@@ -308,7 +308,7 @@ enum e1e_registers {
#define E1000_KMRNCTRLSTA_INBAND_PARAM 0x9 /* Kumeran InBand Parameters */
#define E1000_KMRNCTRLSTA_DIAG_NELPBK 0x1000 /* Nearend Loopback mode */
#define E1000_KMRNCTRLSTA_K1_CONFIG 0x7
-#define E1000_KMRNCTRLSTA_K1_ENABLE 0x140E
+#define E1000_KMRNCTRLSTA_K1_ENABLE 0x0002
#define E1000_KMRNCTRLSTA_K1_DISABLE 0x1400

#define IFE_PHY_EXTENDED_STATUS_CONTROL 0x10

2010-08-06 18:35:20

by Greg KH

[permalink] [raw]
Subject: [01/38] PARISC: led.c - fix potential stack overflow in led_proc_write()

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Helge Deller <[email protected]>

commit 4b4fd27c0b5ec638a1f06ced9226fd95229dbbf0 upstream.

avoid potential stack overflow by correctly checking count parameter

Reported-by: Ilja <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
Acked-by: Kyle McMartin <[email protected]>
Cc: James E.J. Bottomley <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/parisc/led.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/parisc/led.c
+++ b/drivers/parisc/led.c
@@ -176,16 +176,18 @@ static ssize_t led_proc_write(struct fil
size_t count, loff_t *pos)
{
void *data = PDE(file->f_path.dentry->d_inode)->data;
- char *cur, lbuf[count + 1];
+ char *cur, lbuf[32];
int d;

if (!capable(CAP_SYS_ADMIN))
return -EACCES;

- memset(lbuf, 0, count + 1);
+ if (count >= sizeof(lbuf))
+ count = sizeof(lbuf)-1;

if (copy_from_user(lbuf, buf, count))
return -EFAULT;
+ lbuf[count] = 0;

cur = lbuf;


2010-08-06 18:35:24

by Greg KH

[permalink] [raw]
Subject: [04/38] parisc: pass through \t to early (iodc) console

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Kyle McMartin <[email protected]>

commit d9b68e5e88248bb24fd4e455588bea1d56108fd6 upstream.

The firmware handles '\t' internally, so stop trying to emulate it
(which, incidentally, had a bug in it.)

Fixes a really weird hang at bootup in rcu_bootup_announce, which,
as far as I can tell, is the first printk in the core kernel to use
a tab as the first character.

Signed-off-by: Kyle McMartin <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/parisc/kernel/firmware.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)

--- a/arch/parisc/kernel/firmware.c
+++ b/arch/parisc/kernel/firmware.c
@@ -1123,7 +1123,6 @@ static char __attribute__((aligned(64)))
*/
int pdc_iodc_print(const unsigned char *str, unsigned count)
{
- static int posx; /* for simple TAB-Simulation... */
unsigned int i;
unsigned long flags;

@@ -1133,19 +1132,12 @@ int pdc_iodc_print(const unsigned char *
iodc_dbuf[i+0] = '\r';
iodc_dbuf[i+1] = '\n';
i += 2;
- posx = 0;
goto print;
- case '\t':
- while (posx & 7) {
- iodc_dbuf[i] = ' ';
- i++, posx++;
- }
- break;
case '\b': /* BS */
- posx -= 2;
+ i--; /* overwrite last */
default:
iodc_dbuf[i] = str[i];
- i++, posx++;
+ i++;
break;
}
}

2010-08-06 18:35:28

by Greg KH

[permalink] [raw]
Subject: [05/38] amd64_edac: Fix DCT base address selector

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Borislav Petkov <[email protected]>

commit 9975a5f22a4fcc8d08035c65439900a983f891ad upstream.

The correct check is to verify whether in high range we're below 4GB
and not to extract the DctSelBaseAddr again. See "2.8.5 Routing DRAM
Requests" in the F10h BKDG.

Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: Doug Thompson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/edac/amd64_edac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -1430,7 +1430,7 @@ static inline u64 f10_get_base_addr_offs
u64 chan_off;

if (hi_range_sel) {
- if (!(dct_sel_base_addr & 0xFFFFF800) &&
+ if (!(dct_sel_base_addr & 0xFFFF0000) &&
hole_valid && (sys_addr >= 0x100000000ULL))
chan_off = hole_off << 16;
else

2010-08-06 18:43:18

by Greg KH

[permalink] [raw]
Subject: [10/38] e1000e: dont inadvertently re-set INTX_DISABLE

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Dean Nelson <[email protected]>

commit 36f2407fe52c55566221f8c68c8fb808abffd2f5 upstream.

Should e1000_test_msi() fail to see an msi interrupt, it attempts to
fallback to legacy INTx interrupts. But an error in the code may prevent
this from happening correctly.

Before calling e1000_test_msi_interrupt(), e1000_test_msi() disables SERR
by clearing the SERR bit from the just read PCI_COMMAND bits as it writes
them back out.

Upon return from calling e1000_test_msi_interrupt(), it re-enables SERR
by writing out the version of PCI_COMMAND it had previously read.

The problem with this is that e1000_test_msi_interrupt() calls
pci_disable_msi(), which eventually ends up in pci_intx(). And because
pci_intx() was called with enable set to 1, the INTX_DISABLE bit gets
cleared from PCI_COMMAND, which is what we want. But when we get back to
e1000_test_msi(), the INTX_DISABLE bit gets inadvertently re-set because
of the attempt by e1000_test_msi() to re-enable SERR.

The solution is to have e1000_test_msi() re-read the PCI_COMMAND bits as
part of its attempt to re-enable SERR.

During debugging/testing of this issue I found that not all the systems
I ran on had the SERR bit set to begin with. And on some of the systems
the same could be said for the INTX_DISABLE bit. Needless to say these
latter systems didn't have a problem falling back to legacy INTx
interrupts with the code as is.

Signed-off-by: Dean Nelson <[email protected]>
Tested-by: Emil Tantilov <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/e1000e/netdev.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)

--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -3419,13 +3419,18 @@ static int e1000_test_msi(struct e1000_a

/* disable SERR in case the MSI write causes a master abort */
pci_read_config_word(adapter->pdev, PCI_COMMAND, &pci_cmd);
- pci_write_config_word(adapter->pdev, PCI_COMMAND,
- pci_cmd & ~PCI_COMMAND_SERR);
+ if (pci_cmd & PCI_COMMAND_SERR)
+ pci_write_config_word(adapter->pdev, PCI_COMMAND,
+ pci_cmd & ~PCI_COMMAND_SERR);

err = e1000_test_msi_interrupt(adapter);

- /* restore previous setting of command word */
- pci_write_config_word(adapter->pdev, PCI_COMMAND, pci_cmd);
+ /* re-enable SERR */
+ if (pci_cmd & PCI_COMMAND_SERR) {
+ pci_read_config_word(adapter->pdev, PCI_COMMAND, &pci_cmd);
+ pci_cmd |= PCI_COMMAND_SERR;
+ pci_write_config_word(adapter->pdev, PCI_COMMAND, pci_cmd);
+ }

/* success ! */
if (!err)

2010-08-06 18:43:52

by Greg KH

[permalink] [raw]
Subject: [03/38] block_dev: always serialize exclusive open attempts

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Tejun Heo <[email protected]>

commit e75aa85892b2ee78c79edac720868cbef16e62eb upstream.

bd_prepare_to_claim() incorrectly allowed multiple attempts for
exclusive open to progress in parallel if the attempting holders are
identical. This triggered BUG_ON() as reported in the following bug.

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

__bd_abort_claiming() is used to finish claiming blocks and doesn't
work if multiple openers are inside a claiming block. Allowing
multiple parallel open attempts to continue doesn't gain anything as
those are serialized down in the call chain anyway. Fix it by always
allowing only single open attempt in a claiming block.

This problem can easily be reproduced by adding a delay after
bd_prepare_to_claim() and attempting to mount two partitions of a
disk.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Markus Trippelsdorf <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/block_dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -681,8 +681,8 @@ retry:
if (!bd_may_claim(bdev, whole, holder))
return -EBUSY;

- /* if someone else is claiming, wait for it to finish */
- if (whole->bd_claiming && whole->bd_claiming != holder) {
+ /* if claiming is already in progress, wait for it to finish */
+ if (whole->bd_claiming) {
wait_queue_head_t *wq = bit_waitqueue(&whole->bd_claiming, 0);
DEFINE_WAIT(wait);


2010-08-06 18:44:07

by Greg KH

[permalink] [raw]
Subject: [02/38] arm/imx/gpio: add spinlock protection

2.6.35-stable review patch. If anyone has any objections, please let us know.

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

From: Baruch Siach <[email protected]>

commit 14cb0deb66fcfca8fdbef75da8c84b5405a8c767 upstream.

The GPIO registers need protection from concurrent access for operations that
are not atomic.

Cc: Juergen Beisert <[email protected]>
Cc: Daniel Mack <[email protected]>
Reported-by: [email protected]
Signed-off-by: Baruch Siach <[email protected]>
Signed-off-by: Sascha Hauer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/plat-mxc/gpio.c | 8 ++++++++
arch/arm/plat-mxc/include/mach/gpio.h | 1 +
2 files changed, 9 insertions(+)

--- a/arch/arm/plat-mxc/gpio.c
+++ b/arch/arm/plat-mxc/gpio.c
@@ -214,13 +214,16 @@ static void _set_gpio_direction(struct g
struct mxc_gpio_port *port =
container_of(chip, struct mxc_gpio_port, chip);
u32 l;
+ unsigned long flags;

+ spin_lock_irqsave(&port->lock, flags);
l = __raw_readl(port->base + GPIO_GDIR);
if (dir)
l |= 1 << offset;
else
l &= ~(1 << offset);
__raw_writel(l, port->base + GPIO_GDIR);
+ spin_unlock_irqrestore(&port->lock, flags);
}

static void mxc_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
@@ -229,9 +232,12 @@ static void mxc_gpio_set(struct gpio_chi
container_of(chip, struct mxc_gpio_port, chip);
void __iomem *reg = port->base + GPIO_DR;
u32 l;
+ unsigned long flags;

+ spin_lock_irqsave(&port->lock, flags);
l = (__raw_readl(reg) & (~(1 << offset))) | (value << offset);
__raw_writel(l, reg);
+ spin_unlock_irqrestore(&port->lock, flags);
}

static int mxc_gpio_get(struct gpio_chip *chip, unsigned offset)
@@ -285,6 +291,8 @@ int __init mxc_gpio_init(struct mxc_gpio
port[i].chip.base = i * 32;
port[i].chip.ngpio = 32;

+ spin_lock_init(&port[i].lock);
+
/* its a serious configuration bug when it fails */
BUG_ON( gpiochip_add(&port[i].chip) < 0 );

--- a/arch/arm/plat-mxc/include/mach/gpio.h
+++ b/arch/arm/plat-mxc/include/mach/gpio.h
@@ -36,6 +36,7 @@ struct mxc_gpio_port {
int virtual_irq_start;
struct gpio_chip chip;
u32 both_edges;
+ spinlock_t lock;
};

int mxc_gpio_init(struct mxc_gpio_port*, int);

2010-08-06 19:15:00

by Thomas Backlund

[permalink] [raw]
Subject: Re: [00/38] 2.6.35.1-stable review

06.08.2010 21:32, Greg KH skrev:
> This is the start of the stable review cycle for the 2.6.35.1 release.
> There are 38 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
> us know. If anyone is a maintainer of the proper subsystem, and wants
> to add a Signed-off-by: line to the patch, please respond with it.
>
> Responses should be made by August 8, 2010, 18:00:00 UTC.
> 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/v2.6/stable-review/patch-2.6.35.1-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


I think this one should be added as soon as possible too:


> Gitweb: http://git.kernel.org/linus/396e894d289d69bacf5acd983c97cd6e21a14c08
> Commit: 396e894d289d69bacf5acd983c97cd6e21a14c08
> Parent: f469461df6ff822f71b8737bda86eea20f16ff93
> Author: Peter Zijlstra <[email protected]>
> AuthorDate: Fri Jul 9 15:12:27 2010 +0200
> Committer: Ingo Molnar <[email protected]>
> CommitDate: Sat Jul 17 12:05:44 2010 +0200
>
> sched: Revert nohz_ratelimit() for now
>
> Norbert reported that nohz_ratelimit() causes his laptop to burn about
> 4W (40%) extra. For now back out the change and see if we can adjust
> the power management code to make better decisions.
>
> Reported-by: Norbert Preining <[email protected]>
> Signed-off-by: Peter Zijlstra <[email protected]>
> Acked-by: Mike Galbraith <[email protected]>
> Cc: Arjan van de Ven <[email protected]>
> LKML-Reference: <new-submission>
> Signed-off-by: Ingo Molnar <[email protected]>

--
Thomas

2010-08-06 19:36:02

by Greg KH

[permalink] [raw]
Subject: Re: [00/38] 2.6.35.1-stable review

On Fri, Aug 06, 2010 at 10:14:46PM +0300, Thomas Backlund wrote:
> 06.08.2010 21:32, Greg KH skrev:
> >This is the start of the stable review cycle for the 2.6.35.1 release.
> >There are 38 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
> >us know. If anyone is a maintainer of the proper subsystem, and wants
> >to add a Signed-off-by: line to the patch, please respond with it.
> >
> >Responses should be made by August 8, 2010, 18:00:00 UTC.
> >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/v2.6/stable-review/patch-2.6.35.1-rc1.gz
> >and the diffstat can be found below.
> >
> >thanks,
> >
> >greg k-h
>
>
> I think this one should be added as soon as possible too:
>
>
> >Gitweb: http://git.kernel.org/linus/396e894d289d69bacf5acd983c97cd6e21a14c08
> >Commit: 396e894d289d69bacf5acd983c97cd6e21a14c08

As it just landed in Linus's tree about an hour ago, it was a bit late
for this release.

I'll queue it up for the next .35 release after this one.

thanks,

greg k-h

2010-08-06 20:35:16

by Greg KH

[permalink] [raw]
Subject: Re: [00/38] 2.6.35.1-stable review

On Fri, Aug 06, 2010 at 01:22:10PM -0700, - wrote:
> Does not include the fix to this bug (introduced in 2.6.35.0):
>
> ???https://bugzilla.kernel.org/show_bug.cgi?id=16506
>
> Affected file:? arch/x86/lib/atomic64_386_32.S
>
> This issue causes a compile-time blocking failure.? The patch fixes the problem for older versions of BINUTILS equal to or more recent than the minimum required version currently listed in file Documentation/Changes.
>
> Patch:? https://bugzilla.kernel.org/attachment.cgi?id=27360
>
>
> Please include this in 2.6.35.1 and any other affected kernels.
>
> The problem was introduced on February 24 through March 1, 2010 by multiple commits, starting with commit a7e926abc3adfbd2e5e20d2b46177adb4e313915.
>

Which exact patch that is in Linus's tree fixes the problem? Do you
have the git commit id of it? That's what I need here.

thanks,

greg k-h

2010-08-06 21:12:49

by H. Peter Anvin

[permalink] [raw]
Subject: Re: [00/38] 2.6.35.1-stable review

On 08/06/2010 01:34 PM, Greg KH wrote:
> On Fri, Aug 06, 2010 at 01:22:10PM -0700, - wrote:
>> Does not include the fix to this bug (introduced in 2.6.35.0):
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=16506
>>
>> Affected file: arch/x86/lib/atomic64_386_32.S
>>
>> This issue causes a compile-time blocking failure. The patch fixes the problem for older versions of BINUTILS equal to or more recent than the minimum required version currently listed in file Documentation/Changes.
>>
>> Patch: https://bugzilla.kernel.org/attachment.cgi?id=27360
>>
>> Please include this in 2.6.35.1 and any other affected kernels.
>>
>> The problem was introduced on February 24 through March 1, 2010 by multiple commits, starting with commit a7e926abc3adfbd2e5e20d2b46177adb4e313915.
>>
>
> Which exact patch that is in Linus's tree fixes the problem? Do you
> have the git commit id of it? That's what I need here.
>

Not upstream just yet.

-hpa

2010-08-06 23:50:09

by Greg KH

[permalink] [raw]
Subject: Re: [00/38] 2.6.35.1-stable review

On Fri, Aug 06, 2010 at 02:12:40PM -0700, H. Peter Anvin wrote:
> On 08/06/2010 01:34 PM, Greg KH wrote:
> >On Fri, Aug 06, 2010 at 01:22:10PM -0700, - wrote:
> >>Does not include the fix to this bug (introduced in 2.6.35.0):
> >>
> >> https://bugzilla.kernel.org/show_bug.cgi?id=16506
> >>
> >>Affected file: arch/x86/lib/atomic64_386_32.S
> >>
> >>This issue causes a compile-time blocking failure. The patch fixes the problem for older versions of BINUTILS equal to or more recent than the minimum required version currently listed in file Documentation/Changes.
> >>
> >>Patch: https://bugzilla.kernel.org/attachment.cgi?id=27360
> >>
> >>Please include this in 2.6.35.1 and any other affected kernels.
> >>
> >>The problem was introduced on February 24 through March 1, 2010 by multiple commits, starting with commit a7e926abc3adfbd2e5e20d2b46177adb4e313915.
> >>
> >
> >Which exact patch that is in Linus's tree fixes the problem? Do you
> >have the git commit id of it? That's what I need here.
> >
>
> Not upstream just yet.

Ok, care to let [email protected] know when it goes into Linus's tree?

thanks,

greg k-h

2010-08-07 00:32:16

by H. Peter Anvin

[permalink] [raw]
Subject: Re: [00/38] 2.6.35.1-stable review

On 08/06/2010 04:39 PM, Greg KH wrote:
>>
>> Not upstream just yet.
>
> Ok, care to let [email protected] know when it goes into Linus's tree?
>

I'll make sure it gets tagged.

-hpa


--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

2010-08-10 13:07:36

by Ian Campbell

[permalink] [raw]
Subject: Re: [09/38] xen: netfront: explicitly generate arp_notify event after migration.

Hi Greg,

Looks like I forgot to request this for 2.6.32 too, could you queue it
up there as well?

It depends on the previous patch in this series (arp_notify: allow
drivers to explicitly request a notification event.).

Thanks,
Ian.

On Fri, 2010-08-06 at 19:30 +0100, Greg KH wrote:
> 2.6.35-stable review patch. If anyone has any objections, please let us know.
>
> ------------------
>
> From: Ian Campbell <[email protected]>
>
> commit 592970675c9522bde588b945388c7995c8b51328 upstream.
>
> Use newly introduced netif_notify_peers() method to ensure a gratuitous ARP is
> generated after a migration.
>
> Signed-off-by: Ian Campbell <[email protected]>
> Cc: Stephen Hemminger <[email protected]>
> Cc: Jeremy Fitzhardinge <[email protected]>
> Cc: David S. Miller <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Signed-off-by: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> drivers/net/xen-netfront.c | 1 +
> 1 file changed, 1 insertion(+)
>
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1621,6 +1621,7 @@ static void backend_changed(struct xenbu
> if (xennet_connect(netdev) != 0)
> break;
> xenbus_switch_state(dev, XenbusStateConnected);
> + netif_notify_peers(netdev);
> break;
>
> case XenbusStateClosing:
>
>

2010-08-11 19:59:37

by Greg KH

[permalink] [raw]
Subject: Re: [09/38] xen: netfront: explicitly generate arp_notify event after migration.

On Tue, Aug 10, 2010 at 02:07:27PM +0100, Ian Campbell wrote:
> Hi Greg,
>
> Looks like I forgot to request this for 2.6.32 too, could you queue it
> up there as well?
>
> It depends on the previous patch in this series (arp_notify: allow
> drivers to explicitly request a notification event.).

Now queued up for .32 and .34-stable kernels.

thanks,

greg k-h

2010-08-11 19:59:41

by Greg KH

[permalink] [raw]
Subject: Re: [stable] [00/38] 2.6.35.1-stable review

On Fri, Aug 06, 2010 at 12:16:54PM -0700, Greg KH wrote:
> On Fri, Aug 06, 2010 at 10:14:46PM +0300, Thomas Backlund wrote:
> > 06.08.2010 21:32, Greg KH skrev:
> > >This is the start of the stable review cycle for the 2.6.35.1 release.
> > >There are 38 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
> > >us know. If anyone is a maintainer of the proper subsystem, and wants
> > >to add a Signed-off-by: line to the patch, please respond with it.
> > >
> > >Responses should be made by August 8, 2010, 18:00:00 UTC.
> > >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/v2.6/stable-review/patch-2.6.35.1-rc1.gz
> > >and the diffstat can be found below.
> > >
> > >thanks,
> > >
> > >greg k-h
> >
> >
> > I think this one should be added as soon as possible too:
> >
> >
> > >Gitweb: http://git.kernel.org/linus/396e894d289d69bacf5acd983c97cd6e21a14c08
> > >Commit: 396e894d289d69bacf5acd983c97cd6e21a14c08
>
> As it just landed in Linus's tree about an hour ago, it was a bit late
> for this release.
>
> I'll queue it up for the next .35 release after this one.

Now queued up.

thanks,

greg k-h