| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
SVN-Revision: 29541
|
|
|
|
| |
SVN-Revision: 29540
|
|
|
|
| |
SVN-Revision: 29539
|
|
|
|
| |
SVN-Revision: 29446
|
|
|
|
| |
SVN-Revision: 29415
|
|
|
|
| |
SVN-Revision: 29123
|
|
|
|
| |
SVN-Revision: 29122
|
|
|
|
| |
SVN-Revision: 29017
|
|
|
|
| |
SVN-Revision: 29015
|
|
|
|
| |
SVN-Revision: 29014
|
|
|
|
| |
SVN-Revision: 29013
|
|
|
|
|
|
| |
Also rename the corresponding callback functions.
SVN-Revision: 29012
|
|
|
|
| |
SVN-Revision: 29011
|
|
|
|
| |
SVN-Revision: 28977
|
|
|
|
| |
SVN-Revision: 28851
|
|
|
|
| |
SVN-Revision: 28850
|
|
|
|
|
|
|
|
|
|
|
| |
A fast stop/start cycle could leave the ag71xx interrupts and tx engine
disabled when using a phy driver with a fixed link and the start/stop
happens between two phy state machine polls.
Prevent this by always forcing the link down on stop regardless of phy
state and having a phy connected.
SVN-Revision: 28380
|
|
|
|
| |
SVN-Revision: 28213
|
|
|
|
| |
SVN-Revision: 27975
|
|
|
|
|
|
| |
fast reset takes care of DMA stuck issues
SVN-Revision: 27973
|
|
|
|
|
|
|
|
|
| |
When starting/stopping DMA sometimes the FIFO state gets corrupted,
leading to wildly fluctuating latencies or packet data corruption.
Fix this by issuing a fast MAC reset as soon as the link is detected
as up. Fixes #9689, #9405
SVN-Revision: 27896
|
|
|
|
|
|
|
|
|
|
|
| |
When the DMA engine state gets corrupted due to a hardware issues, it
often won't stop rx until a full reset is issued. In that case the hardware
must keep a valid descriptor, otherwise it will write to random places in
system RAM, triggering random crashes. To fix this, keep a dummy descriptor
without a buffer that keeps the DMA engine in a sane state until the reset
is done
SVN-Revision: 27895
|
|
|
|
| |
SVN-Revision: 27894
|
|
|
|
| |
SVN-Revision: 27705
|
|
|
|
| |
SVN-Revision: 27704
|
|
|
|
| |
SVN-Revision: 27703
|
|
|
|
|
|
| |
hardware reset
SVN-Revision: 27702
|
|
|
|
| |
SVN-Revision: 27701
|
|
|
|
| |
SVN-Revision: 27700
|
|
|
|
|
|
| |
the up the PHY state
SVN-Revision: 27568
|
|
|
|
|
|
| |
hopefully fix stability issues from #9405
SVN-Revision: 27567
|
|
|
|
|
|
| |
Also remove the old UART driver for ar933x.
SVN-Revision: 27314
|
|
|
|
| |
SVN-Revision: 27310
|
|
|
|
| |
SVN-Revision: 27222
|
|
|
|
| |
SVN-Revision: 27166
|
|
|
|
|
|
| |
Signed-off-by: Jonas Gorski <jonas.gorski+openwrt@gmail.com>
SVN-Revision: 27102
|
|
|
|
|
|
| |
It messes up the DMA state when the link goes down
SVN-Revision: 27088
|
|
|
|
| |
SVN-Revision: 27065
|
|
|
|
| |
SVN-Revision: 27060
|
|
|
|
|
|
|
|
|
|
|
|
| |
Newer WRT160NLs have a flash chip with 4K erase blocks instead of 64K,
resulting in miscalculated partition sizes.
Since the actual sizes did not change, hardcode them to their current
sizes, and make sure they are at least one erase block big (in case Cisco
decides to start to use chips with 128K erase blocks).
Signed-off-by: Jonas Gorski <jonas.gorski+openwrt@gmail.com>
SVN-Revision: 27049
|
|
|
|
| |
SVN-Revision: 27041
|
|
|
|
| |
SVN-Revision: 27040
|
|
|
|
|
|
| |
Reported-by: Dave Täht <dave.taht@gmail.com>
SVN-Revision: 27039
|
|
|
|
|
|
| |
condition that got rx stuck when the interface is brought up during lots of inbound traffic (thx, matteo)
SVN-Revision: 27035
|
|
|
|
|
|
| |
continously sending MAC pause frames
SVN-Revision: 27034
|
|
|
|
| |
SVN-Revision: 26922
|
|
|
|
| |
SVN-Revision: 26890
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reading of the PHY registers occasionally returns with bogus values
under heavy load. This misleads the PHY driver and thus causes false
link/speed change notifications which leads to performance loss.
This is easily noticable during an iperf session:
...
[ 3] 52.0-53.0 sec 11.3 MBytes 94.4 Mbits/sec
[ 3] 53.0-54.0 sec 11.4 MBytes 95.4 Mbits/sec
eth1: link down
br-lan: port 2(eth1) entering forwarding state
eth1: link up (100Mbps/Full duplex)
br-lan: port 2(eth1) entering forwarding state
br-lan: port 2(eth1) entering forwarding state
[ 3] 54.0-55.0 sec 6.75 MBytes 56.6 Mbits/sec
[ 3] 55.0-56.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 56.0-57.0 sec 10.5 MBytes 88.1 Mbits/sec
...
[ 3] 169.0-170.0 sec 11.4 MBytes 95.4 Mbits/sec
[ 3] 170.0-171.0 sec 11.4 MBytes 95.4 Mbits/sec
eth1: link up (10Mbps/Half duplex)
[ 3] 171.0-172.0 sec 7.63 MBytes 64.0 Mbits/sec
[ 3] 172.0-173.0 sec 9.38 MBytes 78.6 Mbits/sec
eth1: link up (100Mbps/Full duplex)
[ 3] 173.0-174.0 sec 11.3 MBytes 94.4 Mbits/sec
[ 3] 174.0-175.0 sec 11.4 MBytes 95.4 Mbits/sec
SVN-Revision: 26856
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function __devinit ag71xx_probe() references
a function __devexit ag71xx_phy_disconnect().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
ag71xx_phy_disconnect() so it may be used outside an exit section.
The function ag71xx_phy_disconnect() references a function in an exit
section.
Often the function ag71xx_ar7240_cleanup() has valid usage outside the
exit section
and the fix is to remove the __devexit annotation of
ag71xx_ar7240_cleanup.
SVN-Revision: 26855
|
|
|
|
| |
SVN-Revision: 26854
|