linux/drivers, branch v2.6.29.3

ath9k: Fix FIF_BCN_PRBRESP_PROMISC handling

2009-05-08T22:45:12Z

This is a port of commit 91ed19f5f66a7fe544f0ec385e981f43491d1d5a for 2.6.29. Without this after scanning your device will set the association ID to something bogus and what is being reported is multicast/broadcast frame are not being received. For details see this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=498502 >From the original commit: So that a new created IBSS network doesn't break on the first scan. It seems to Sujith and me that this stupid code unnecessary, too. So remove it... Reported-by: David Woodhouse Tested-by: David Woodhouse Signed-off-by: Alina Friedrichsen Signed-off-by: John W. Linville Signed-off-by: Jouni Malinen Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman

rndis_wlan: fix initialization order for workqueue&workers

2009-05-08T22:45:11Z

commit e805e4d0b53506dff4255a2792483f094e7fcd2c upstream. rndis_wext_link_change() might be called from rndis_command() at initialization stage and priv->workqueue/priv->work have not been initialized yet. This causes invalid opcode at rndis_wext_bind on some brands of bcm4320. Fix by initializing workqueue/workers in rndis_wext_bind() before rndis_command is used. This bug has existed since 2.6.25, reported at: http://bugzilla.kernel.org/show_bug.cgi?id=12794 Signed-off-by: Jussi Kivilinna Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

intel-iommu: Avoid panic() for DRHD at address zero.

2009-05-08T22:45:10Z

(cherry picked from commit e523b38e2f568af58baa13120a994cbf24e6dee0) If the BIOS does something obviously stupid, like claiming that the registers for the IOMMU are at physical address zero, then print a nasty message and abort, rather than trying to set up the IOMMU and then later panicking. It's becoming more and more obvious that trusting this stuff to the BIOS was a mistake. Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman

intel-iommu: Fix oops in device_to_iommu() when devices not found.

2009-05-08T22:45:10Z

(cherry picked from commit 4958c5dc7bcb2e42d985cd26aeafd8a7eca9ab1e) It's possible for a device in the drhd->devices[] array to be NULL if it wasn't found at boot time, which means we have to check for that case. Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman

intel-iommu: Fix device-to-iommu mapping for PCI-PCI bridges.

2009-05-08T22:45:10Z

(cherry picked from commit 924b6231edfaf1e764ffb4f97ea382bf4facff58) When the DMAR table identifies that a PCI-PCI bridge belongs to a given IOMMU, that means that the bridge and all devices behind it should be associated with the IOMMU. Not just the bridge itself. This fixes the device_to_iommu() function accordingly. (It's broken if you have the same PCI bus numbers in multiple domains, but this function was always broken in that way; I'll be dealing with that later). Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman

cs5536: define dma_sff_read_status() method

2009-05-08T22:45:10Z

commit 15da90b516e9da92cc1d90001e640fd6707d0e27 upstream. The driver somehow got merged with the initializer for the dma_sff_read_status() method missing which caused kernel panic on bootup. This should fix the kernel.org bug #13026... Signed-off-by: Sergei Shtylyov Reported-by: Arnd Hannemann Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman

ath5k: fix buffer overrun in rate debug code

2009-05-08T22:45:09Z

commit b7fcb5c4a4c27da2f6d86cb03d18687e537442cf upstream. char bname[5] is too small for the string "X GHz" when the null terminator is taken into account. Thus, turning on rate debugging can crash unless we have lucky stack alignment. Cc: stable@kernel.org Reported-by: Paride Legovini Signed-off-by: Bob Copeland Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

mv643xx_eth: OOM handling fixes

2009-05-08T22:45:09Z

commit 1319ebadf185933e6b7ff95211d3cef9004e9754 upstream. Currently, when OOM occurs during rx ring refill, mv643xx_eth will get into an infinite loop, due to the refill function setting the OOM bit but not clearing the 'rx refill needed' bit for this queue, while the calling function (the NAPI poll handler) will call the refill function in a loop until the 'rx refill needed' bit goes off, without checking the OOM bit. This patch fixes this by checking the OOM bit in the NAPI poll handler before attempting to do rx refill. This means that once OOM occurs, we won't try to do any memory allocations again until the next invocation of the poll handler. While we're at it, change the OOM flag to be a single bit instead of one bit per receive queue since OOM is a system state rather than a per-queue state, and cancel the OOM timer on entry to the NAPI poll handler if it's running to prevent it from firing when we've already come out of OOM. Signed-off-by: Lennert Buytenhek Cc: stable@kernel.org Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

mv643xx_eth: 64bit mib counter read fix

2009-05-08T22:45:09Z

commit 93af7aca44f0e82e67bda10a0fb73d383edcc8bd upstream. On several mv643xx_eth hardware versions, the two 64bit mib counters for 'good octets received' and 'good octets sent' are actually 32bit counters, and reading from the upper half of the register has the same effect as reading from the lower half of the register: an atomic read-and-clear of the entire 32bit counter value. This can under heavy traffic occasionally lead to small numbers being added to the upper half of the 64bit mib counter even though no 32bit wrap has occured. Since we poll the mib counters at least every 30 seconds anyway, we might as well just skip the reads of the upper halves of the hardware counters without breaking the stats, which this patch does. Signed-off-by: Lennert Buytenhek Cc: stable@kernel.org Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ACPI: Revert conflicting workaround for BIOS w/ mangled PRT entries

2009-05-08T22:45:05Z

upstream 82babbb3887e234c995626e4121d411ea9070ca5 backported to 2.6.29.2 2f894ef9c8b36a35d80709bedca276d2fc691941 in Linux-2.6.21 worked around BIOS with mangled _PRT entries: http://bugzilla.kernel.org/show_bug.cgi?id=6859 d0e184abc5983281ef189db2c759d65d56eb1b80 worked around the same issue via ACPICA, and shipped in 2.6.27. Unfortunately the two workarounds conflict: http://bugzilla.kernel.org/show_bug.cgi?id=12270 So revert the Linux specific one. Signed-off-by: Zhang Rui Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman