Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 165
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 14 3月, 2016 1 次提交
  3. 03 3月, 2016 1 次提交
  5. 26 2月, 2016 1 次提交
  7. 13 2月, 2016 1 次提交
  9. 05 1月, 2016 3 次提交
  11. 28 12月, 2015 2 次提交
  13. 13 11月, 2015 1 次提交
  15. 27 9月, 2015 1 次提交
  17. 11 9月, 2015 1 次提交
  19. 29 8月, 2015 1 次提交
    • C
      r8169: Add software counter for multicast packages · d7d2d89d
      由 Corinna 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: NCorinna Vinschen <vinschen@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d7d2d89d
  21. 26 8月, 2015 1 次提交
    • C
      r8169: Add values missing in @get_stats64 from HW counters · 6e85d5ad
      由 Corinna 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: NCorinna Vinschen <vinschen@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e85d5ad
  23. 07 8月, 2015 1 次提交
  25. 04 5月, 2015 1 次提交
  27. 25 2月, 2015 1 次提交
  29. 23 2月, 2015 1 次提交
    • D
      r8169: Revert BQL and xmit_more support. · 87cda7cb
      由 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 0bec3b70
	Author: Florian Westphal <fw@strlen.de>
	Date:   Wed Jan 7 10:49:49 2015 +0100

	    r8169: add support for xmit_more

and

	commit 1e918876
	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: NDavid S. Miller <davem@davemloft.net>
      87cda7cb
  31. 27 1月, 2015 1 次提交
  33. 14 1月, 2015 1 次提交
  35. 09 1月, 2015 1 次提交
  37. 12 12月, 2014 2 次提交
    • C
      r8169:update rtl8168g pcie ephy parameter · 5fbea337
      由 Chun-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: NChunhao Lin <hau@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5fbea337
    • A
      r8169: Use dma_rmb() and dma_wmb() for DescOwn checks · a0750138
      由 Alexander 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: NAlexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0750138
  39. 11 12月, 2014 1 次提交
  41. 09 12月, 2014 3 次提交
  43. 09 10月, 2014 1 次提交
    • C
      r8169:add support for RTL8168EP · 935e2218
      由 Chun-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: NChun-Hao Lin <hau@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      935e2218
  45. 02 10月, 2014 11 次提交
  47. 23 9月, 2014 1 次提交