linux-toradex.git/drivers/net, branch v2.6.24.4 Linux kernel for Apalis and Colibri modules macb: Fix speed setting 2008-03-24T18:47:33+00:00 Atsushi Nemoto anemo@mba.ocn.ne.jp 2008-03-03T15:51:48+00:00 40f3601686b66ffa7c2cab2bbdff5ec0fc52aa43 commit: 179956f498bd8cc55fb803c4ee0cf18be59c8b01 Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by conversion to generic PHY layer in kernel 2.6.23. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit: 179956f498bd8cc55fb803c4ee0cf18be59c8b01

Fix NCFGR.SPD setting on 10Mbps.  This bug was introduced by
conversion to generic PHY layer in kernel 2.6.23.

Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
b43: Backport bcm4311 fix 2008-03-24T18:47:31+00:00 Michael Buesch mb@bu3sch.de 2008-02-29T11:55:41+00:00 061e98a971b62ce4ee25c6cbd88b46d9870d5d9f This is a backport of upstream commit 013978b6 ("b43: Changes to enable BCM4311 rev 02 with wireless core revision 13") and the changes include the following: (1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43. (2) Add PHY revision 9 to the supported list. (3) Change the 2-bit routing code for address extensions to 0b10 rather than the 0b01 used for the 32-bit case. (4) Remove some magic numbers in the DMA setup. The DMA implementation for this chip supports full 64-bit addressing with one exception. Whenever the Descriptor Ring Buffer is in high memory, a fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due to code to "Bias the placement of kernel pages at lower PFNs". When commit 44048d70 reverted that code, the DMA error appeared. As a "fix", use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present, this problem is thought to arise from a hardware error. Signed-off-by: Michael Buesch <mb@bu3sch.de> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: John W. Linville <linville@tuxdriver.com> Cc: Alexey Zaytsev <alexey.zaytsev@gmail.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
This is a backport of upstream commit 013978b6 ("b43: Changes to enable
BCM4311 rev 02 with wireless core revision 13") and the changes include
the following:

(1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
(2) Add PHY revision 9 to the supported list.
(3) Change the 2-bit routing code for address extensions to 0b10 rather
    than the 0b01 used for the 32-bit case.
(4) Remove some magic numbers in the DMA setup.

The DMA implementation for this chip supports full 64-bit addressing with
one exception. Whenever the Descriptor Ring Buffer is in high memory, a
fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
to code to "Bias the placement of kernel pages at lower PFNs". When
commit 44048d70 reverted that code, the DMA error appeared. As a "fix",
use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present,
this problem is thought to arise from a hardware error.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: Alexey Zaytsev <alexey.zaytsev@gmail.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
e1000e: Fix CRC stripping in hardware context bug 2008-03-24T18:47:29+00:00 Auke Kok auke-jan.h.kok@intel.com 2008-02-12T23:20:24+00:00 535d75274d992be482951967af0ec4d99c99fadc CRC stripping was only correctly enabled for packet split recieves which is used when receiving jumbo frames. Correctly enable SECRC also for normal buffer packet receives. Tested by Andy Gospodarek and Johan Andersson, see bugzilla #9940. Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com> Signed-off-by: Jeff Garzik <jeff@garzik.org> Cc: Mike Pagano <mike@mpagano.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
CRC stripping was only correctly enabled for packet split recieves
which is used when receiving jumbo frames. Correctly enable SECRC
also for normal buffer packet receives.

Tested by Andy Gospodarek and Johan Andersson, see bugzilla #9940.

Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Cc: Mike Pagano <mike@mpagano.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
NIU: Bump driver version and release date. 2008-03-24T18:47:05+00:00 David S. Miller davem@davemloft.net 2008-03-05T22:49:01+00:00 887b7b08e75ee7dae5da7924291cd90d4bcb5b40 Upstream commit: a442585952f137bd4cdb1f2f3166e4157d383b82 Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
Upstream commit: a442585952f137bd4cdb1f2f3166e4157d383b82

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
NIU: Fix BMAC alternate MAC address indexing. 2008-03-24T18:47:05+00:00 Matheos Worku matheos.worku@sun.com 2008-03-05T22:47:36+00:00 6a9d3b1f4ec21b365f027d241bbfc871c4c91152 Upstream commit: 3b5bcedeeb755b6e813537fcf4c32f010b490aef BMAC port alternate MAC address index needs to start at 1. Index 0 is used for the main MAC address. Signed-off-by: Matheos Worku <matheos.worku@sun.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
Upstream commit: 3b5bcedeeb755b6e813537fcf4c32f010b490aef

BMAC port alternate MAC address index needs to start at 1. Index 0 is
used for the main MAC address.

Signed-off-by: Matheos Worku <matheos.worku@sun.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
NIU: More BMAC alt MAC address fixes. 2008-03-24T18:47:04+00:00 Matheos Worku Matheos.Worku@Sun.COM 2008-03-05T22:48:37+00:00 958346d4b18fa1474a706a535396e94a6eaf5fb4 Upstream commit: fa907895b7b776208a1406efe5ba7ffe0f49f507 From: Matheos Worku <Matheos.Worku@Sun.COM> 1) niu_enable_alt_mac() needs to be adjusted so that the mask is computed properly for the BMAC case. 2) BMAC has 6 alt MAC addresses available, not 7. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
Upstream commit: fa907895b7b776208a1406efe5ba7ffe0f49f507

From: Matheos Worku <Matheos.Worku@Sun.COM>

1) niu_enable_alt_mac() needs to be adjusted so that the mask
   is computed properly for the BMAC case.

2) BMAC has 6 alt MAC addresses available, not 7.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
bonding: fix NULL pointer deref in startup processing 2008-02-26T00:19:01+00:00 Jay Vosburgh fubar@us.ibm.com 2008-02-15T18:00:41+00:00 f7e1b66a194e38f9fa41f8144aa34b782fb4f53a patch 4fe4763cd8cacd81d892193efb48b99c99c15323 in mainline. Fix the "are we creating a duplicate" check to not compare the name if the name is NULL (meaning that the system should select a name). Bug reported by Benny Amorsen <benny+usenet@amorsen.dk>. Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
patch 4fe4763cd8cacd81d892193efb48b99c99c15323 in mainline.

	Fix the "are we creating a duplicate" check to not compare
the name if the name is NULL (meaning that the system should select
a name).  Bug reported by Benny Amorsen <benny+usenet@amorsen.dk>.

Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
PCMCIA: Fix station address detection in smc 2008-02-26T00:19:01+00:00 Chuck Ebbert cebbert@redhat.com 2008-02-22T00:33:00+00:00 80e9255328f9f1c2a6aa7422be1f0a87a4a9cb7b Commit: a1a98b72dbd17e53cd92b8e78f404525ebcfd981 Fix station address detection in smc Megahertz EM1144 PCMCIA ethernet adapter needs special handling because it has two VERS_1 tuples and the station address is in the second one. Conversion to generic handling of these fields broke it. Reverting that fixes the device. https://bugzilla.redhat.com/show_bug.cgi?id=233255 Thanks go to Jon Stanley for not giving up on this one until the problem was found. Signed-off-by: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Commit: a1a98b72dbd17e53cd92b8e78f404525ebcfd981

Fix station address detection in smc

Megahertz EM1144 PCMCIA ethernet adapter needs special handling
because it has two VERS_1 tuples and the station address is in
the second one. Conversion to generic handling of these fields
broke it. Reverting that fixes the device.

  https://bugzilla.redhat.com/show_bug.cgi?id=233255

Thanks go to Jon Stanley for not giving up on this one until the
problem was found.

Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix dl2k constants 2008-02-26T00:18:33+00:00 Al Viro viro@ZenIV.linux.org.uk 2008-02-01T07:05:44+00:00 0a2395cc34d5d170a6597c41435de9199f187437 patch 9c52fab2f187636b39afb0dcf562872ed42ab608 in mainline. The MSSR constants didn't match the reality - bitfield declarations used to be correct (1000BT_FD - bit 11, 1000BT_HD - bit 10), but enum had them the other way round. Went unnoticed until the switch from the bitfields use to the explicit arithmetics and I hadn't caught that one when verifying correctness of change... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
patch 9c52fab2f187636b39afb0dcf562872ed42ab608 in mainline.

The MSSR constants didn't match the reality - bitfield declarations
used to be correct (1000BT_FD - bit 11, 1000BT_HD - bit 10), but enum
had them the other way round.  Went unnoticed until the switch from
the bitfields use to the explicit arithmetics and I hadn't caught that one
when verifying correctness of change...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
b43: Reject new firmware early 2008-02-08T19:46:29+00:00 Michael Buesch mb@bu3sch.de 2008-01-26T12:54:52+00:00 5df1d0f87854e9bcd6b32ad0d2e1f8676dbe9ea6 (not in mainline, as it is not applicable.) We must reject new incompatible firmware early to avoid running into strange transmission failures. The current development tree supports newer firmware revisions. These revisions cause strange failures on the stable 2.6.24 kernel. Add a check to avoid confusing users a lot. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
(not in mainline, as it is not applicable.)

We must reject new incompatible firmware early to avoid
running into strange transmission failures.

The current development tree supports newer firmware revisions.
These revisions cause strange failures on the stable 2.6.24 kernel.
Add a check to avoid confusing users a lot.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>