linux-toradex.git/drivers/net, branch v2.6.29.3

ath9k: Fix FIF_BCN_PRBRESP_PROMISC handling

2009-05-08T22:45:12+00:00

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:11+00:00

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

ath5k: fix buffer overrun in rate debug code

2009-05-08T22:45:09+00:00

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:09+00:00

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:09+00:00

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

b44: Use kernel DMA addresses for the kernel DMA API

2009-05-08T22:45:00+00:00

commit 37efa239901493694a48f1d6f59f8de17c2c4509 upstream.

We must not use the device DMA addresses for the kernel DMA API, because
device DMA addresses have an additional offset added for the SSB translation.

Use the original dma_addr_t for the sync operation.

Cc: stable@kernel.org
Signed-off-by: Michael Buesch 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

b43: Refresh RX poison on buffer recycling

2009-05-08T22:44:58+00:00

upstream commit: cf68636a9773aa97915497fe54fa4a51e3f08f3a

The RX buffer poison needs to be refreshed, if we recycle an RX buffer,
because it might be (partially) overwritten by some DMA operations.

Cc: stable@kernel.org
Cc: Francesco Gringoli 
Signed-off-by: Michael Buesch 
Signed-off-by: John W. Linville 
Signed-off-by: Chris Wright

b43: Poison RX buffers

2009-05-08T22:44:58+00:00

upstream commit: ec9a1d8c13e36440eda0f3c79b8149080e3ab5ba

This patch adds poisoning and sanity checking to the RX DMA buffers.
This is used for protection against buggy hardware/firmware that raises
RX interrupts without doing an actual DMA transfer.

This mechanism protects against rare "bad packets" (due to uninitialized skb data)
and rare kernel crashes due to uninitialized RX headers.

The poison is selected to not match on valid frames and to be cheap for checking.

The poison check mechanism _might_ trigger incorrectly, if we are voluntarily
receiving frames with bad PLCP headers. However, this is nonfatal, because the
chance of such a match is basically zero and in case it happens it just results
in dropping the packet.
Bad-PLCP RX defaults to off, and you should leave it off unless you want to listen
to the latest news broadcasted by your microwave oven.

This patch also moves the initialization of the RX-header "length" field in front of
the mapping of the DMA buffer. The CPU should not touch the buffer after we mapped it.

Cc: stable@kernel.org
Reported-by: Francesco Gringoli 
Signed-off-by: Michael Buesch 
Signed-off-by: John W. Linville 
Signed-off-by: Chris Wright

forcedeth: Fix resume from hibernation regression.

2009-05-08T22:44:57+00:00

upstream commit: 35a7433c789ba6df6d96b70fa745ae9e6cac0038

Reset phy state on resume, fixing a regression caused by powering down
the phy on hibernate.

Signed-off-by: Ed Swierk 
Signed-off-by: David S. Miller 
Cc: Tvrtko Ursulin 
Signed-off-by: Chris Wright

Bonding: fix zero address hole bug in arp_ip_target list

2009-04-27T17:37:05+00:00

upstream commit: 5a31bec014449dc9ca994e4c1dbf2802b7ca458a

Fix a zero address hole bug in the bonding arp_ip_target list
that was causing the bond to ignore ARP replies (bugz 13006).
Instead of just setting the array entry to zero, we now
copy any additional entries down one slot, putting the
zero entry at the end.  With this change we can now have
all the loops that walk the array stop when they hit a zero
since there will be no addresses after it.

Changes are based in part on code fragment provided in kernel:
bugzilla 13006:

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

by Steve Howard 

Signed-off-by: Brian Haley 
Signed-off-by: Jay Vosburgh 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright