summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/realtek/r8169.c
AgeCommit message (Collapse)Author
2017-03-12r8169: replace init_timer with setup_timerZhu Yanjun
Replace init_timer with setup_timer to simplify the source code. Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-03-06net: realtek: r8169: use new api ethtool_{get|set}_link_ksettingsPhilippe Reynes
The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes <tremyfr@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-30drivers: net: generalize napi_complete_done()Eric Dumazet
napi_complete_done() allows to opt-in for gro_flush_timeout, added back in linux-3.19, commit 3b47d30396ba ("net: gro: add a per device gro flush timer") This allows for more efficient GRO aggregation without sacrifying latencies. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-09Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
2017-01-08net: make ndo_get_stats64 a void functionstephen hemminger
The network device operation for reading statistics is only called in one place, and it ignores the return value. Having a structure return value is potentially confusing because some future driver could incorrectly assume that the return value was used. Fix all drivers with ndo_get_stats64 to have a void function. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-05r8169: fix the typo in the commentZhu Yanjun
>From the realtek data sheet, the PID0 should be bit 0. Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-27r8169: add support for RTL8168 series add-on card.Chun-Hao Lin
This chip is the same as RTL8168, but its device id is 0x8161. Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-05r8169: Add support for restarting auto-negotiationFlorian Fainelli
Implement ethtooll::nway_restart by utilizing mii_nway_restart. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
Mostly simple overlapping changes. For example, David Ahern's adjacency list revamp in 'net-next' conflicted with an adjacency list traversal bug fix in 'net'. Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-18ethernet/realtek: use core min/max MTU checkingJarod Wilson
8139cp: min_mtu 60, max_mtu 4096 8139too: min_mtu 68, max_mtu 1770 r8169: min_mtu 60, max_mtu depends on chipset, 1500 to 9k-ish CC: netdev@vger.kernel.org CC: Realtek linux nic maintainers <nic_swsd@realtek.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-15r8169: set coherent DMA mask as well as streaming DMA maskArd Biesheuvel
PCI devices that are 64-bit DMA capable should set the coherent DMA mask as well as the streaming DMA mask. On some architectures, these are managed separately, and so the coherent DMA mask will be left at its default value of 32 if it is not set explicitly. This results in errors such as r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded hwdev DMA mask = 0x00000000ffffffff, dev_addr = 0x00000080fbfff000 swiotlb: coherent allocation failed for device 0000:02:00.0 size=4096 CPU: 0 PID: 1062 Comm: systemd-udevd Not tainted 4.8.0+ #35 Hardware name: AMD Seattle/Seattle, BIOS 10:53:24 Oct 13 2016 on systems without memory that is 32-bit addressable by PCI devices. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-07-31r8169: fix nic may not work after changing mac address.Chun-Hao Lin
When there is no AC power, NIC may not work after changing mac address. Please refer to following link. http://www.spinics.net/lists/netdev/msg356572.html This issue is caused by runtime power management. When there is no AC power, if we put NIC down (ifconfig down), the driver will be in runtime suspend state and hardware will be put into D3 state. During this time, driver cannot access hardware regisers. So if you set new mac address during this time, it will not be set to hardware. After resume, NIC will keep using the old mac address and the network will not work normally. In this patch I add detecting runtime pm status when setting mac address. If driver is in runtime suspend state, it will skip setting mac address, keep the new mac address, and set the new mac address during runtime resume. Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-07-31r8169: add checking driver's runtime pm status in rtl8169_get_ethtool_stats()Chun-Hao Lin
Not to call rtl8169_update_counters() to dump tally counter when driver is in runtime suspend state. Calling rtl8169_update_counters() in runtime suspend state will produce warning message "rtl_counters_cond == 1 (loop: 1000, delay: 10)". Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-07-31r8169: fix kernel log spam when set or get hardware wol setting.Chun-Hao Lin
NIC will be put into D3 state during runtime suspend state. When set or get hardware wol setting, driver will write or read hardware registers. If we set or get hardware wol setting in runtime suspend state, because NIC will in D3 state, the hardware registers read by driver will return all 0xff. That will let driver thinking register flag is not toggled and then prints the warning message "rtl_counters_cond == 1 (loop: 1000, delay: 10)" to kernel log. For fixing this issue, add checking driver's pm runtime status in rtl8169_get_wol() and rtl8169_set_wol(). Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-17r8169: default to 64-bit DMA on recent PCIe chipsArd Biesheuvel
The current logic around the 'use_dac' module parameter prevents the r81969 driver from being loadable on 64-bit systems without any RAM below 4 GB when the parameter is left at its default value. So introduce a new default value -1 which indicates that 64-bit DMA should be enabled on sufficiently recent PCIe chips, i.e., versions RTL_GIGA_MAC_VER_18 or later. Explicit param values of 0 or 1 retain the existing behavior of unconditionally enabling/disabling 64-bit DMA on 64-bit architectures (i.e., regardless of the type and version of the chip) Since PCIe chips do not need to CPlusCmd Dual Address Cycle to be set, make that conditional on the device type as well. Cc: Realtek linux nic maintainers <nic_swsd@realtek.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-13r8169:Remove unnecessary phy reset for pcie nic when setting link spped.Chun-Hao Lin
For pcie nic, after setting link speed and there is no link driver does not need to do phy reset until link up. For some pcie nics, to do this will also reset phy speed down counter and prevent phy from auto speed down. This patch fix the issue reported in following link. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1547151 Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-02r8169: Enable RX_MULTI_EN for RTL_GIGA_MAC_VER_41~48Chunhao Lin
For RTL8168G/RTL8168H/RTL8411B/RTL8107E, enable this flag to eliminate message "AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0002 address=0x0000000000003000 flags=0x0050] in dmesg. Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-25r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.Chun-Hao Lin
There will be a log spam when there is no cable plugged. Please refer to following links. https://bugzilla.kernel.org/show_bug.cgi?id=104351 https://bugzilla.kernel.org/show_bug.cgi?id=107421 This issue is caused by runtime power management. When there is no cable plugged, the driver will be suspend (runtime suspend) by OS and NIC will be put into the D3 state. During this time, if OS call rtl8169_get_stats64() to dump tally counter, because NIC is in D3 state, the register value read by driver will return all 0xff. This will let driver think tally counter flag is not toggled and then sends the warning message "rtl_counters_cond == 1 (loop: 1000, delay: 10)" to kernel log. For fixing this issue, 1.add checking driver's pm runtime status in rtl8169_get_stats64(). 2.dump tally counter before going runtime suspend for counter accuracy in runtime suspend. Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-13r8169:fix system hange problem.Chun-Hao Lin
There are typos in setting RTL8168H hardware parameters. If system install another version driver that may cuase system hang. Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-04r8169:Correct the way of setting RTL8168DP ephyChun-Hao Lin
The original way is wrong, it always writes ephy reg 0x03. Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-04r8169:Fix typo in setting RTL8168H PHY PFM mode.Chun-Hao Lin
The PHY PFM register is in PHY page 0x0a44 register 0x11, not 0x14. Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-04r8169:Fix typo in setting RTL8168EP and RTL8168H D3cold PFM modeChun-Hao Lin
The register for setting D3code PFM mode is MISC_1, not DLLPR. Signed-off-by: Chunhao Lin <hau@realtek.com> Reviewed-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-28r8169:Update the way of reading RTL8168H PHY register "rg_saw_cnt"Chun-Hao Lin
The vlaue of RTL8168H PHY register "rg_saw_cnt" only valid from bit0 to bit13. When read this register, add bitwise-anding its value with 0x3fff. Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-28r8169:Fix typo in setting RTL8168H PHY parameterChun-Hao Lin
In function "rtl8168h_2_hw_phy_config", there is a typo in setting RTL8168H PHY parameter. Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-12r8169: fix kasan reported skb use-after-free.françois romieu
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Reported-by: Dave Jones <davej@codemonkey.org.uk> Fixes: d7d2d89d4b0af ("r8169: Add software counter for multicast packages") Acked-by: Eric Dumazet <edumazet@google.com> Acked-by: Corinna Vinschen <vinschen@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-26r8169: fix handling rtl_readphy resultAndrzej Hajda
The function can return negative value. The problem has been detected using proposed semantic patch scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107 Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-10r8169: Fix sleeping function called during get_stats64, v2Corinna Vinschen
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104031 Fixes: 6e85d5ad36a26debc23a9a865c029cbe242b2dc8 Based on the discussion starting at http://www.spinics.net/lists/netdev/msg342193.html Tested locally on RTL8168evl/8111evl with various concurrent processes accessing /proc/net/dev while changing the link state as well as removing/reloading the r8169 module. Signed-off-by: Corinna Vinschen <vinschen@redhat.com> Tested-by: poma <pomidorabelisima@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-28r8169: Add software counter for multicast packagesCorinna Vinschen
The multicast hardware counter on 8168/8111 chips is only 32 bit while the statistics in struct rtnl_link_stats64 are 64 bit. Given that statistics are requested on an irregular basis, an overflow of the hardware counter can go unnoticed. To count even very large numbers of multicast packets reliably, add a software counter and remove previously applied code to fill the multicast field requested by @rtl8169_get_stats64 with the values read from the rx_multicast hardware counter. Signed-off-by: Corinna Vinschen <vinschen@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-25r8169: Add values missing in @get_stats64 from HW countersCorinna Vinschen
The r8169 driver collects statistical information returned by @get_stats64 by counting them in the driver itself, even though many (but not all) of the values are already collected by tally counters (TCs) in the NIC. Some of these TC values are not returned by @get_stats64. Especially the received multicast packages are missing from /proc/net/dev. Rectify this by fetching the TCs and returning them from rtl8169_get_stats64. The counters collected in the driver obviously disappear as soon as the driver is unloaded so after a driver is loaded the counters always start at 0. The TCs on the other hand are only reset by a power cycle. Without further considerations the values collected by the driver would not match up against the TC values. This patch introduces a new function rtl8169_reset_counters which resets the TCs. Also, since rtl8169_reset_counters shares most of its code with rtl8169_update_counters, refactor the shared code into two new functions rtl8169_map_counters and rtl8169_unmap_counters. Unfortunately chip versions prior to RTL_GIGA_MAC_VER_19 don't allow to reset the TCs programatically. Therefore introduce an addition to the rtl8169_private struct and a function rtl8169_init_counter_offsets to store the TCs at first rtl_open. Use these values as offsets in rtl8169_get_stats64. Propagate a failure to reset *and* update the counters up to rtl_open and emit a warning message, if so. Signed-off-by: Corinna Vinschen <vinschen@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-07r8169: enforce RX_MULTI_EN on rtl8168ep/8111ep chipsIvan Vecera
Enforcing this flag in RxConfig for the mentioned chips fixes netdev watchdog issues prepended with AMD IOMMU message(s) like: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x001d address=0x0000000000003000 flags=0x0050] Note that this flag is also set in Realtek's own driver for these chips. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Tested-by: Alexander Lindqvist <alexander@bitspace.se> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-04r8169: Do not use dev_kfree_skb in xmit pathAlexander Duyck
The function r8169_csum_workaround is called in the ndo_start_xmit path of the r8169 driver. As such it should not be using dev_kfree_skb as it is not irq safe, so instead we should be using dev_kfree_skb_any for freeing in the dropped path, and dev_consume_skb_any for any frames that were transmitted. Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-24r8169: Fix trivial typo in rtl_check_firmwareYannick Guerrini
Change 'firwmare' to 'firmware' Signed-off-by: Yannick Guerrini <yguerrini@tomshardware.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-22r8169: Revert BQL and xmit_more support.David S. Miller
There are certain regressions which are pointing to these two commits which we are having a hard time resolving. So revert them for now. Specifically this reverts: commit 0bec3b700d106a8b0a34227b2976d1a582f1aab7 Author: Florian Westphal <fw@strlen.de> Date: Wed Jan 7 10:49:49 2015 +0100 r8169: add support for xmit_more and commit 1e918876853aa85435e0f17fd8b4a92dcfff53d6 Author: Florian Westphal <fw@strlen.de> Date: Wed Oct 1 13:38:03 2014 +0200 r8169: add support for Byte Queue Limits There were some attempts by Eric Dumazet to address some obvious problems in the TX flow, to see if they would fix the problems, but none of them seem to help for the regression reporters. Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-10Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-nextLinus Torvalds
Pull networking updates from David Miller: 1) More iov_iter conversion work from Al Viro. [ The "crypto: switch af_alg_make_sg() to iov_iter" commit was wrong, and this pull actually adds an extra commit on top of the branch I'm pulling to fix that up, so that the pre-merge state is ok. - Linus ] 2) Various optimizations to the ipv4 forwarding information base trie lookup implementation. From Alexander Duyck. 3) Remove sock_iocb altogether, from CHristoph Hellwig. 4) Allow congestion control algorithm selection via routing metrics. From Daniel Borkmann. 5) Make ipv4 uncached route list per-cpu, from Eric Dumazet. 6) Handle rfs hash collisions more gracefully, also from Eric Dumazet. 7) Add xmit_more support to r8169, e1000, and e1000e drivers. From Florian Westphal. 8) Transparent Ethernet Bridging support for GRO, from Jesse Gross. 9) Add BPF packet actions to packet scheduler, from Jiri Pirko. 10) Add support for uniqu flow IDs to openvswitch, from Joe Stringer. 11) New NetCP ethernet driver, from Muralidharan Karicheri and Wingman Kwok. 12) More sanely handle out-of-window dupacks, which can result in serious ACK storms. From Neal Cardwell. 13) Various rhashtable bug fixes and enhancements, from Herbert Xu, Patrick McHardy, and Thomas Graf. 14) Support xmit_more in be2net, from Sathya Perla. 15) Group Policy extensions for vxlan, from Thomas Graf. 16) Remove Checksum Offload support for vxlan, from Tom Herbert. 17) Like ipv4, support lockless transmit over ipv6 UDP sockets. From Vlad Yasevich. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1494+1 commits) crypto: fix af_alg_make_sg() conversion to iov_iter ipv4: Namespecify TCP PMTU mechanism i40e: Fix for stats init function call in Rx setup tcp: don't include Fast Open option in SYN-ACK on pure SYN-data openvswitch: Only set TUNNEL_VXLAN_OPT if VXLAN-GBP metadata is set ipv6: Make __ipv6_select_ident static ipv6: Fix fragment id assignment on LE arches. bridge: Fix inability to add non-vlan fdb entry net: Mellanox: Delete unnecessary checks before the function call "vunmap" cxgb4: Add support in cxgb4 to get expansion rom version via ethtool ethtool: rename reserved1 memeber in ethtool_drvinfo for expansion ROM version net: dsa: Remove redundant phy_attach() IB/mlx4: Reset flow support for IB kernel ULPs IB/mlx4: Always use the correct port for mirrored multicast attachments net/bonding: Fix potential bad memory access during bonding events tipc: remove tipc_snprintf tipc: nl compat add noop and remove legacy nl framework tipc: convert legacy nl stats show to nl compat tipc: convert legacy nl net id get to nl compat tipc: convert legacy nl net id set to nl compat ...
2015-01-27r8169: use PCI define for Max_Read_Request_SizeRafał Miłecki
Replace a magic number with a PCI #define symbol. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: David S. Miller <davem@davemloft.net>
2015-01-13net: rename vlan_tx_* helpers since "tx" is misleading thereJiri Pirko
The same macros are used for rx as well. So rename it. Signed-off-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-08r8169: add support for xmit_moreFlorian Westphal
Delay update of hw tail descriptor if we know that another skb is going to be sent. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-11r8169:update rtl8168g pcie ephy parameterChun-Hao Lin
Add ephy parameter to rtl8168g. Also change the common function of rtl8168g from "rtl_hw_start_8168g_1" to "rtl_hw_start_8168g". And function "rtl_hw_start_8168g_1" is used for setting rtl8168g hardware parameters. Following is the explanation of what hardware parameter change for. rtl8168g may erroneous judge the PCIe signal quality and show the error bit on PCI configuration space when in PCIe low power mode. The following ephy parameters are for above issue. { 0x00, 0x0000, 0x0008 } { 0x0c, 0x37d0, 0x0820 } { 0x1e, 0x0000, 0x0001 } rtl8168g may return to PCIe L0 from PCIe L0s low power mode too slow. The following ephy parameter is for above issue. { 0x19, 0x8000, 0x0000 } Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-11r8169: Use dma_rmb() and dma_wmb() for DescOwn checksAlexander Duyck
The r8169 use a pair of wmb() calls when setting up the descriptor rings. The first is to synchronize the descriptor data with the descriptor status, and the second is to synchronize the descriptor status with the use of the MMIO doorbell to notify the device that descriptors are ready. This can come at a heavy price on some systems, and is not really necessary on systems such as x86 as a simple barrier() would suffice to order store/store accesses. As such we can replace the first memory barrier with dma_wmb() to reduce the cost for these accesses. In addition the r8169 uses a rmb() to prevent compiler optimization in the cleanup paths, however by moving the barrier down a few lines and replacing it with a dma_rmb() we should be able to use it to guarantee descriptor accesses do not occur until the device has updated the DescOwn bit from its end. One last change I made is to move the update of cur_tx in the xmit path to after the wmb. This way we can guarantee the device and all CPUs should see the DescOwn update before they see the cur_tx value update. Cc: Realtek linux nic maintainers <nic_swsd@realtek.com> Cc: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-10ethernet/realtek: use napi_alloc_skb instead of netdev_alloc_skb_ip_alignAlexander Duyck
This replaces most of the calls to netdev_alloc_skb_ip_align in the Realtek drivers. The one instance I didn't replace in 8139cp.c is because it was called as a part of init and as such is not always accessed from the softirq context. Cc: Realtek linux nic maintainers <nic_swsd@realtek.com> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-08r8169: Use eth_skb_pad functionAlexander Duyck
Replace rtl_skb_pad with eth_skb_pad since they do the same thing. Cc: Realtek linux nic maintainers <nic_swsd@realtek.com> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-08r8169:disable rtl8168ep cmac engineChun-Hao Lin
Cmac engine is the bridge between driver and dash firmware. Other os may not disable cmac when leave. And r8169 did not allocate any resources for cmac engine. Disable it to prevent abnormal system behavior. Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-08r8169:prevent enable hardware tx/rx too earlyChun-Hao Lin
For RTL8168G/GU/H/EP and RTL8411B remove enable tx/rx from its own hw_start function. This will prevent enable tx/rx before complete hardware tx/rx setting. Tx/Rx will be enabled in the end of function rtl_hw_start_8168. Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-08r8169:add support for RTL8168EPChun-Hao Lin
RTL8168EP is Realtek PCIe Gigabit Ethernet controller with DASH support. It is a successor chip of RTL8168DP. For RTL8168EP, the read/write ocp register is via eri channel type 2, so I move ocp_xxx() related functions under rtl_eri_xxx. And use r8168dp_ocp_xxx() for RTL8168DP ocp read/write, r8168ep_ocp_xxx() for RTL8168EP ocp read/write. The way of checking dash enable is different with RTL8168DP. I use r8168dp_check_dash()for RTL8168DP and r8168ep_check_dash() for RTL8168EP, to check if dash is enabled. The driver_start() and driver_stop() of RTL8168EP is also different with RTL8168DP. I use rtl8168dp_driver_xxx() for RTL8168DP and rtl8168ep_driver_xxx for RTL8168EP. Right now, RTL8168EP phy mcu did not need firmware code patch, so I did not add firmware code for it. so I did not add firmware code for it. Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-01r8169: add support for Byte Queue LimitsFlorian Westphal
tested on RTL8168d/8111d model using 'super_netperf 40' with TCP/UDP_STREAM. Output of while true; do for n in inflight limit; do echo -n $n\ ; cat $n; done; sleep 1; done during netperf run, 100mbit peer: inflight 0 limit 3028 inflight 6056 limit 4542 [ trimmed output for brevity, no limit/inflight changes during test steady-state ] limit 4542 inflight 3028 limit 6122 inflight 0 limit 6122 [ changed cable to 1gbit peer, restart netperf ] inflight 37850 limit 36336 inflight 33308 limit 31794 inflight 33308 limit 31794 inflight 27252 limit 25738 [ again, no changes during test ] inflight 27252 limit 25738 inflight 0 limit 28766 [ change cable to 100mbit peer, restart netperf ] limit 28766 inflight 27370 limit 28766 inflight 4542 limit 5990 inflight 6056 limit 4542 [ .. ] inflight 6056 limit 4542 inflight 0 [end of test] Cc: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes Wang <hayeswang@realtek.com> Signed-off-by: Florian Westphal <fw@strlen.de> Acked-by: Eric Dumazet <edumazet@google.com> Acked-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-01r8169:call "rtl8168_driver_start" "rtl8168_driver_stop" only when hardware ↵Chun-Hao Lin
dash function is enabled These two functions are used to inform dash firmware that driver is been brought up or brought down. So call these two functions only when hardware dash function is enabled. Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-01r8169:modify the behavior of function "rtl8168_oob_notify"Chun-Hao Lin
In function "rtl8168_oob_notify", using function "rtl_eri_write" to access eri register 0xe8, instead of using MAC register "ERIDR" and "ERIAR" to access it. For using function "rtl_eri_write" in function "rtl8168_oob_notify", need to move down "rtl8168_oob_notify" related functions under the function "rtl_eri_write". Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-01r8169:change the name of function "r8168dp_check_dash" to "r8168_check_dash"Chun-Hao Lin
DASH function not only RTL8168DP can support, but also RTL8168EP. So change the name of function "r8168dp_check_dash" to "r8168_check_dash". Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-01r8169:change the name of function"rtl_w1w0_eri"Chun-Hao Lin
Change the name of function "rtl_w1w0_eri" to "rtl_w0w1_eri". In this function, the local variable "val" is "write zeros then write ones". Please see below code. (val & ~m) | p In this patch, change the function name from "xx_w1w0_xx" to "xx_w0w1_xx". The changed function name is more suitable for it's behavior. Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-01r8169:for function "rtl_w1w0_phy" change its name and behaviorChun-Hao Lin
Change function name from "rtl_w1w0_phy" to "rtl_w0w1_phy". And its behavior from "write ones then write zeros" to "write zeros then write ones". In Realtek internal driver, bitwise operations are almost "write zeros then write ones". For easy to port hardware parameters from Realtek internal driver to Linux kernal driver "r8169", we would like to change this function's behavior and its name. Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>