The QCA955X is affected by a hardware bug which causes link-loss of the
SGMII link between SoC and PHY. This happens on change of link-state or
speed.
It is not really known what causes this bug. It definitely occurs when
using a AR8033 Gigabit Ethernet PHY.
Qualcomm solves this Bug in a similar fashion. We need to apply the fix
on a per-device base via platform-data as performing the fixup work will
break connectivity in case the SGMII interface is connected to a Switch.
This bug was first proposed to be fixed by Sven Eckelmann in 2016.
https://patchwork.ozlabs.org/patch/604782/
Based-on-patch-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
Signed-off-by: David Bauer <mail@david-bauer.net>
With this change, the timestamp variable is only used in ag71xx_check_dma_stuck. Small tx speedup.
Based on a Qualcomm commit. ag->timestamp = jiffies was not replaced with netif_trans_update(dev) because of this quote:
It should be noted that after this series several instances
of netif_trans_update() are useless (if they occur in
.ndo_start_xmit and driver doesn't set LLTX flag -- stack already
did an update).
From: http://lists.openwall.net/netdev/2016/05/03/87
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Because the oldest supported kernel version on the ar71xx target is 4.4,
the condition that the kernel version is smaller than 4.2.0 is always
false. Remove the obsolete check from ag71xx_main.c to clean up the code
a bit.
Signed-off-by: Gabor Juhos <juhosg@freemail.hu>
The motivation for this was misguided. It turns out tuning the NAPI weight could be useful for testing purposes. Therefore reverting.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
This reverts commit 13e5e47369.
This commit causes a severe regression in LAN->WAN routing performance
for several devices. This appears to be caused by the extra requirement
to validate the SKB checksum early in the rx path, which the ethernet
hardware does not do
Signed-off-by: Felix Fietkau <nbd@nbd.name>
On a TL-WN710N, this patch increases iperf performance from ~92.5 to ~93.5 mbps. Keep in mind the WN710N is a 100mbps device. I expect greater numbers from gigabit devices.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Should fix LAN speed issues on some devices. This is an updated version
of the previously reverted commit with the same name.
It improves the check for MACs connected to a built-in switch
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Fully reset the chip like on a full up/down, but without the PHY
statemachine restart.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 48228
no-op since 2.6.35
removed in Kernel 4.1
see https://lwn.net/Articles/380931/
Signed-off-by: Dirk Neukirchen <dirkneukirchen@web.de>
SVN-Revision: 46280
I don't see that we're in an atomic context so there's no need to
busy-wait. Therefore replace the delay with sleep calls.
See also Documentation/timers/timers-howto.txt. It states:
"In general, use of mdelay is discouraged and code should
be refactored to allow for the use of msleep."
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
SVN-Revision: 43539
This improves performance when doing concurrent rx/tx on a single
ethernet MAC, e.g. when routing between VLANs.
Fixes#13072
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 42328
The r39147 commit introduces a regression: at lease on some routers
with ar8216 switch large packets get lost if 802.1q tagged port is
used on the interface connected to the aforementioned switch.
The r39147 changes code in the way so interface is set to accept
packets no longer than max ethernet frame length for a given mtu.
Unfortunately ar8216 has a feature: it sends two additional bytes
as a packet header and those this header needs to be added to the
max frame length. Otherwise long enough packets get lost.
The problem only manuifests itself if interface is used in vlan
tagged mode. If interface is untagged then ar8216's header fits
into space used by 802.1q tag and not packets are lost.
Include two additional bytes in the max frame length calculation
to fix the issue.
This patch is tested and works with Trendnet TEW-632BRP.
Signed-off-by Nikolay Martynov <mar.kolya@gmail.com>
Patchwork: http://patchwork.openwrt.org/patch/4656/
[juhosg:
- simplify the patch to include the additional bytes of the
switch header unconditionally,
- change subject and update commit message]
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 39219
Set the MAX_FRAME_LEN register to zero in ag71xx_hw_init()
and write the correct value into that from the ag71xx_open()
and ag71xx_fast_reset() functions.
Also recalculate the RX buffer size based on the actual
maximum frame length value to optimize memory allocation.
Additionaly, disallow to change the MTU value while the
interface it running.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 39147
The currently used bitmask is not correct for all SoCs.
Introduce a new field in struct ag71xx and store the
bitmask in that. Use the current value for now, it will
be adjusted for each SoCs in further patches.
Aslo use the new field directly in the ag71xx_rx_packets
and ag71xx_hard_start_xmit() functions and remove the
ag71xx_desc_pktlen() helper.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 39144
Currently, the AG71XX_RX_PKT_SIZE value limits the received
frame size to 1514/1516 bytes with/without a VLAN header
respectively. However the hardware limit is controlled by
the value the AG71XX_REG_MAC_MFL register which contains
the value of the max_frame_len field.
Compute the RX buffer size from the max_frame_len field
to get rid of the 1514/1516 byte limitation. Also remove
the unused AG71XX_RX_PKT_SIZE definition.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 39121
In particular, phy_connect before register_netdev. This is because
register_netdev runs the netdev notifiers, which can race with the rest of
the initialization in ag71xx_probe. In my case this manifested in two ways:
1) If ag71xx is compiled as a module and inserted after netifd has started,
netifd is notified by register_netdev before the call to
ag71xx_phy_connect. netifd tries to bring the interface up, which calls
ag71xx_open, which in turn enters ag71xx_phy_start. This keys off
ag->phy_dev (which is still NULL) and thinks this is a fixed-link board,
and enters ag71xx_link_adjust. This looks at ag->speed which is not yet
initialized and hits the BUG() in the switch (ag->speed) in
ag71xx_link_adjust.
This is the wrong code path for ag71xx_phy_start - my board has PHYs that
need to be brought up with phy_start. Doing ag71xx_phy_connect before
register_netdev ensures that ag->phy_dev is non-NULL before
ag71xx_phy_start is ever called.
2) When ag71xx is built into the kernel, and netconsole is enabled, there
is a gap in the initial burst of replayed printks right after the netdev
comes up. My assumption is that netconsole is also triggered by a netdev
notifier, and part of this printk burst happens before the call into
ag71xx_phy_connect, so part of the burst is lost while the PHY comes up.
This patch fixes the gap - all the printks before eth0 comes up are bursted
in full when netconsole initializes.
ag71xx_phy_connect_xxx no longer runs with a registered netdev, so the
logging has been adjusted accordingly to avoid "unregistered net_device" or
"eth%d" messages in dmesg.
Signed-off-by: Catalin Patulea <cat@vv.carleton.ca>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 38689
Petr Štetiar
David Bauer
Felix Fietkau
Rosen Penev
Gabor Juhos
Vittorio Gambaletta
Stephen Walker
Felix Fietkau
John Crispin
Gabor Juhos