linux-toradex.git/drivers/net, branch v2.6.37.2 Linux kernel for Apalis and Colibri modules net: can: janz-ican3: world-writable sysfs termination file 2011-02-24T22:54:41+00:00 Vasiliy Kulikov segoon@openwall.com 2011-02-04T02:23:53+00:00 bd518567d945f7964742bf128def2dd01d89c303 commit 1e6d93e45b231b3ae87c01902ede2315aacfe976 upstream. Don't allow everybody to set terminator via sysfs. Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 1e6d93e45b231b3ae87c01902ede2315aacfe976 upstream.

Don't allow everybody to set terminator via sysfs.

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
iwl3945: remove plcp check 2011-02-24T22:54:32+00:00 Stanislaw Gruszka sgruszka@redhat.com 2011-02-09T07:46:06+00:00 436559bead38897e5d9e50f4a4708728de4c38f6 commit c91d01556f52255a31575be0cb1981c92a2a5028 upstream. Patch fixes: https://bugzilla.redhat.com/show_bug.cgi?id=654599 Many users report very low speed problem on 3945 devices, this patch fixes problem, but only for some of them. For unknown reason, sometimes after hw scanning, device is not able to receive frames at high rate. Since plcp health check may request hw scan to "reset radio", performance problem start to be observable after update kernel to .35, where plcp check was introduced. Bug reporter confirmed that removing plcp check fixed problem for him. Reported-and-tested-by: SilvioTO <silviotoya@yahoo.it> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit c91d01556f52255a31575be0cb1981c92a2a5028 upstream.

Patch fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=654599

Many users report very low speed problem on 3945 devices,
this patch fixes problem, but only for some of them.

For unknown reason, sometimes after hw scanning, device is not able
to receive frames at high rate. Since plcp health check may request
hw scan to "reset radio", performance problem start to be observable
after update kernel to .35, where plcp check was introduced.

Bug reporter confirmed that removing plcp check fixed problem for him.

Reported-and-tested-by: SilvioTO <silviotoya@yahoo.it>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
net/fec: fix MMFR_OP type in fec_enet_mdio_write 2011-02-17T23:15:10+00:00 Shawn Guo shawn.guo@freescale.com 2011-01-05T21:13:09+00:00 ff3aa02aba272558c0abaadc6f6641dadbc7ae95 commit 862f0982eadcea0e114576c57ea426d3d51a69a6 upstream. FEC_MMFR_OP_WRITE should be used than FEC_MMFR_OP_READ in a mdio write operation. It's probably a typo introduced by commit: e6b043d512fa8d9a3801bf5d72bfa3b8fc3b3cc8 netdev/fec.c: add phylib supporting to enable carrier detection (v2) Signed-off-by: Shawn Guo <shawn.guo@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 862f0982eadcea0e114576c57ea426d3d51a69a6 upstream.

FEC_MMFR_OP_WRITE should be used than FEC_MMFR_OP_READ in
a mdio write operation.

It's probably a typo introduced by commit:

e6b043d512fa8d9a3801bf5d72bfa3b8fc3b3cc8
netdev/fec.c: add phylib supporting to enable carrier detection (v2)

Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
hostap_cs: fix sleeping function called from invalid context 2011-02-17T23:14:52+00:00 Stanislaw Gruszka sgruszka@redhat.com 2011-01-10T11:56:05+00:00 2636e659162bef783dc21d5cec6f7e06475a08e6 commit 4e5518ca53be29c1ec3c00089c97bef36bfed515 upstream. pcmcia_request_irq() and pcmcia_enable_device() are intended to be called from process context (first function allocate memory with GFP_KERNEL, second take a mutex). We can not take spin lock and call them. It's safe to move spin lock after pcmcia_enable_device() as we still hold off IRQ until dev->base_addr is 0 and driver will not proceed with interrupts when is not ready. Patch resolves: https://bugzilla.redhat.com/show_bug.cgi?id=643758 Reported-and-tested-by: rbugz@biobind.com Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 4e5518ca53be29c1ec3c00089c97bef36bfed515 upstream.

pcmcia_request_irq() and pcmcia_enable_device() are intended
to be called from process context (first function allocate memory
with GFP_KERNEL, second take a mutex). We can not take spin lock
and call them.

It's safe to move spin lock after pcmcia_enable_device() as we
still hold off IRQ until dev->base_addr is 0 and driver will
not proceed with interrupts when is not ready.

Patch resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=643758

Reported-and-tested-by: rbugz@biobind.com
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ixgbe: fix for 82599 erratum on Header Splitting 2011-02-17T23:14:34+00:00 Don Skidmore donald.c.skidmore@intel.com 2011-01-18T22:53:47+00:00 42633db90993f3fa0401e8a2af67fd2b41db48e7 commit a124339ad28389093ed15eca990d39c51c5736cc upstream. We have found a hardware erratum on 82599 hardware that can lead to unpredictable behavior when Header Splitting mode is enabled. So we are no longer enabling this feature on affected hardware. Please see the 82599 Specification Update for more information. Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit a124339ad28389093ed15eca990d39c51c5736cc upstream.

We have found a hardware erratum on 82599 hardware that can lead to
unpredictable behavior when Header Splitting mode is enabled.  So
we are no longer enabling this feature on affected hardware.

Please see the 82599 Specification Update for more information.

Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
carl9170: fix typo in PS code 2011-02-17T23:14:31+00:00 Christian Lamparter chunkeey@googlemail.com 2011-02-03T21:22:55+00:00 653779ea4311a543968c3f042139c2cac3903310 commit 5820de5303f73d48dcc3a053c875d1f0da7eef67 upstream. This patch fixes a off-by-one bug which bugged the driver's PS-POLL capability. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 5820de5303f73d48dcc3a053c875d1f0da7eef67 upstream.

This patch fixes a off-by-one bug which bugged
the driver's PS-POLL capability.

Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
virtio_net: Add schedule check to napi_enable call 2011-02-17T23:14:31+00:00 Bruce Rogers brogers@novell.com 2011-02-10T19:03:31+00:00 815df7acb446cd2989d7c8addcf6b23716fc1e08 commit 3e9d08ec0a68f6faf718d5a7e050fe5ca0ba004f upstream. Under harsh testing conditions, including low memory, the guest would stop receiving packets. With this patch applied we no longer see any problems in the driver while performing these tests for extended periods of time. Make sure napi is scheduled subsequent to each napi_enable. Signed-off-by: Bruce Rogers <brogers@novell.com> Signed-off-by: Olaf Kirch <okir@suse.de> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 3e9d08ec0a68f6faf718d5a7e050fe5ca0ba004f upstream.

Under harsh testing conditions, including low memory, the guest would
stop receiving packets. With this patch applied we no longer see any
problems in the driver while performing these tests for extended periods
of time.

Make sure napi is scheduled subsequent to each napi_enable.

Signed-off-by: Bruce Rogers <brogers@novell.com>
Signed-off-by: Olaf Kirch <okir@suse.de>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
p54: fix sequence no. accounting off-by-one error 2011-02-17T23:14:27+00:00 Christian Lamparter chunkeey@googlemail.com 2011-01-06T22:47:52+00:00 99939b7d2b1b63c2f62aab32306f476d416f1491 commit 3b5c5827d1f80ad8ae844a8b1183f59ddb90fe25 upstream. P54_HDR_FLAG_DATA_OUT_SEQNR is meant to tell the firmware that "the frame's sequence number has already been set by the application." Whereas IEEE80211_TX_CTL_ASSIGN_SEQ is set for frames which lack a valid sequence number and either the driver or firmware has to assign one. Yup, it's the exact opposite! Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 3b5c5827d1f80ad8ae844a8b1183f59ddb90fe25 upstream.

P54_HDR_FLAG_DATA_OUT_SEQNR is meant to tell the
firmware that "the frame's sequence number has
already been set by the application."

Whereas IEEE80211_TX_CTL_ASSIGN_SEQ is set for
frames which lack a valid sequence number and
either the driver or firmware has to assign one.

Yup, it's the exact opposite!

Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
e1000: fix return value not set on error 2011-02-17T23:14:01+00:00 Dean Nelson dnelson@redhat.com 2010-11-11T05:50:25+00:00 eb9a2a905602b02474d257c4a26c90a8dc36c70c commit 19a0b67afd174c4db261d587b5c67704dcd53c17 upstream. Dean noticed that 'err' wasn't being set when the "goto err_dma" statement is executed in the following hunk from the commit. It's value will be zero as a result of a successful call to e1000_init_hw_struct(). This patch changes the error condition to be correctly propagated. Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 19a0b67afd174c4db261d587b5c67704dcd53c17 upstream.

Dean noticed that 'err' wasn't being set when the "goto err_dma"
statement is executed in the following hunk from the commit. It's value
will be zero as a result of a successful call to e1000_init_hw_struct().

This patch changes the error condition to be correctly propagated.

Signed-off-by:  Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ath: Missed to clear key4 of micentry 2011-02-17T23:13:56+00:00 Rajkumar Manoharan rmanoharan@atheros.com 2010-12-08T14:31:05+00:00 bcd4fd6f957ec3cccdfa99e9aecc712fe4a35225 commit 998d516d9546eba04dd99ae49a78acb0cf770478 upstream. key4 of micentry is used, if ATH_CRYPT_CAP_MIC_COMBINED is set. But is not cleared on key cache reset. Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 998d516d9546eba04dd99ae49a78acb0cf770478 upstream.

key4 of micentry is used, if ATH_CRYPT_CAP_MIC_COMBINED is set.
But is not cleared on key cache reset.

Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>