aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/r8169.c
Commit message (Collapse)AuthorAgeFilesLines
* r8169: fix vlan tag read ordering.Francois Romieu2013-05-191-7/+6
| | | | | | | | | | | | | | | | commit ce11ff5e5963e441feb591e76278528f876c332d upstream. Control of receive descriptor must not be returned to ethernet chipset before vlan tag processing is done. VLAN tag receive word is now reset both in normal and error path. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Spotted-by: Timo Teras <timo.teras@iki.fi> Cc: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: fix auto speed down issueHayes Wang2013-04-161-4/+26
| | | | | | | | | | | | | | | | | commit e2409d83434d77874b461b78af6a19cd6e6a1280 upstream. It would cause no link after suspending or shutdowning when the nic changes the speed to 10M and connects to a link partner which forces the speed to 100M. Check the link partner ability to determine which speed to set. The link speed down code path is not factored in this kernel version. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: remove the obsolete and incorrect AMD workaroundTimo Teräs2013-02-141-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 5d0feaff230c0abfe4a112e6f09f096ed99e0b2d ] This was introduced in commit 6dccd16 "r8169: merge with version 6.001.00 of Realtek's r8169 driver". I did not find the version 6.001.00 online, but in 6.002.00 or any later r8169 from Realtek this hunk is no longer present. Also commit 05af214 "r8169: fix Ethernet Hangup for RTL8110SC rev d" claims to have fixed this issue otherwise. The magic compare mask of 0xfffe000 is dubious as it masks parts of the Reserved part, and parts of the VLAN tag. But this does not make much sense as the VLAN tag parts are perfectly valid there. In matter of fact this seems to be triggered with any VLAN tagged packet as RxVlanTag bit is matched. I would suspect 0xfffe0000 was intended to test reserved part only. Finally, this hunk is evil as it can cause more packets to be handled than what was NAPI quota causing net/core/dev.c: net_rx_action(): WARN_ON_ONCE(work > weight) to trigger, and mess up the NAPI state causing device to hang. As result, any system using VLANs and having high receive traffic (so that NAPI poll budget limits rtl_rx) would result in device hang. Signed-off-by: Timo Teräs <timo.teras@iki.fi> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: use unlimited DMA burst for TXMichal Schmidt2012-11-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd upstream. The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have a box where this prevents the interface from using the gigabit line to its full potential. This patch solves the problem by setting TX_DMA_BURST to unlimited. The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl (XID 0c900880). TSO is enabled. I used netperf (TCP_STREAM test) to measure the dependency of TX throughput on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024, '7'=unlimited). This chart shows the results: http://michich.fedorapeople.org/r8169/r8169-effects-of-TX_DMA_BURST.png Interesting points: - With the current DMA burst limit (1024): - at the default MTU=1500 I get only 842 Mbit/s. - when going from small MTU, the performance rises monotonically with increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's a sudden drop to 762 MBit/s from which the throughput rises monotonically again with further MTU increases. - With a smaller DMA burst limit (512): - there's a similar peak at MTU=1076 and another one at MTU=564. - With unlimited DMA burst: - at the default MTU=1500 I get nice 940 Mbit/s. - the throughput rises monotonically with increasing MTU with no strange peaks. Notice that the peaks occur at MTU sizes that are multiples of the DMA burst limit plus 52. Why 52? Because: 20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52 The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too, except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes. CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B", i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs the smaller burst limit, or if any other versions have similar requirements. Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: call netif_napi_del at errpaths and at driver unloadDevendra Naga2012-10-131-0/+3
| | | | | | | | | | | | commit ad1be8d345416a794dea39761a374032aa471a76 upstream. When register_netdev fails, the init'ed NAPIs by netif_napi_add must be deleted with netif_napi_del, and also when driver unloads, it should delete the NAPI before unregistering netdevice using unregister_netdev. Signed-off-by: Devendra Naga <devendra.aaru@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: fix unsigned int wraparound with TSOJulien Ducourthial2012-10-131-6/+10
| | | | | | | | | | | | | | | | | | commit 477206a018f902895bfcd069dd820bfe94c187b1 upstream. The r8169 may get stuck or show bad behaviour after activating TSO : the net_device is not stopped when it has no more TX descriptors. This problem comes from TX_BUFS_AVAIL which may reach -1 when all transmit descriptors are in use. The patch simply tries to keep positive values. Tested with 8111d(onboard) on a D510MO, and with 8111e(onboard) on a Zotac 890GXITX. Signed-off-by: Julien Ducourthial <jducourt@free.fr> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: 8168c and later require bit 0x20 to be set in Config2 for PME signaling.Francois Romieu2012-10-131-0/+6
| | | | | | | | | | | commit d387b427c973974dd619a33549c070ac5d0e089f upstream. The new 84xx stopped flying below the radars. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes Wang <hayeswang@realtek.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: Config1 is read-only on 8168c and later.Francois Romieu2012-10-131-2/+13
| | | | | | | | | | | commit 851e60221926a53344b4227879858bef841b0477 upstream. Suggested by Hayes. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes Wang <hayeswang@realtek.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: runtime resume before shutdown.françois romieu2012-10-131-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | commit 2a15cd2ff488a9fdb55e5e34060f499853b27c77 upstream. With runtime PM, if the ethernet cable is disconnected, the device is transitioned to D3 state to conserve energy. If the system is shutdown in this state, any register accesses in rtl_shutdown are dropped on the floor. As the device was programmed by .runtime_suspend() to wake on link changes, it is thus brought back up as soon as the link recovers. Resuming every suspended device through the driver core would slow things down and it is not clear how many devices really need it now. Original report and D0 transition patch by Sameer Nanda. Patch has been changed to comply with advices by Rafael J. Wysocki and the PM folks. Reported-by: Sameer Nanda <snanda@chromium.org> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Hayes Wang <hayeswang@realtek.com> Cc: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: missing barriers.Francois Romieu2012-10-131-3/+2
| | | | | | | | | commit 1e874e041fc7c222cbd85b20c4406070be1f687a upstream. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes Wang <hayeswang@realtek.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: fix Config2 MSIEnable bit setting.françois romieu2012-10-131-6/+8
| | | | | | | | | | | | | | commit 2ca6cf06d988fea21e812a86be79353352677c9c upstream. The MSIEnable bit is only available for the 8169. Avoid Config2 writes for the post-8169 8168 and 810x. Reported-by: Su Kang Yin <cantona@cantona.net> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: Rx FIFO overflow fixes.Francois Romieu2012-10-131-30/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 811fd3010cf512f2e23e6c4c912aad54516dc706 upstream. Realtek has specified that the post 8168c gigabit chips and the post 8105e fast ethernet chips recover automatically from a Rx FIFO overflow. The driver does not need to clear the RxFIFOOver bit of IntrStatus and it should rather avoid messing it. The implementation deserves some explanation: 1. events outside of the intr_event bit mask are now ignored. It enforces a no-processing policy for the events that either should not be there or should be ignored. 2. RxFIFOOver was already ignored in rtl_cfg_infos[RTL_CFG_1] for the whole 8168 line of chips with two exceptions: - RTL_GIGA_MAC_VER_22 since b5ba6d12bdac21bc0620a5089e0f24e362645efd ("use RxFIFO overflow workaround for 8168c chipset."). This one should now be correctly handled. - RTL_GIGA_MAC_VER_11 (8168b) which requires a different Rx FIFO overflow processing. Though it does not conform to Realtek suggestion above, the updated driver includes no change for RTL_GIGA_MAC_VER_12 and RTL_GIGA_MAC_VER_17. Both are 8168b. RTL_GIGA_MAC_VER_12 is common and a bit old so I'd rather wait for experimental evidence that the change suggested by Realtek really helps or does not hurt in unexpected ways. Removed case statements in rtl8169_interrupt are only 8168 relevant. 3. RxFIFOOver is masked for post 8105e 810x chips, namely the sole 8105e (RTL_GIGA_MAC_VER_30) itself. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: hayeswang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: increase the delay parameter of pm_schedule_suspendhayeswang2012-10-131-1/+1
| | | | | | | | | | | | | | commit 10953db8e1a278742ef7e64a3d1491802bcfa98b upstream The link down would occur when reseting PHY. And it would take about 2 ~ 5 seconds from link down to link up. If the delay of pm_schedule_suspend is not long enough, the device would enter runtime_suspend before link up. After link up, the device would wake up and reset PHY again. Then, you would find the driver keep in a loop of runtime_suspend and rumtime_resume. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: expand received packet length indication.Francois Romieu2012-10-131-1/+1
| | | | | | | | | | | | | | | | | commit deb9d93c89d311714a60809b28160e538e1cbb43 upstream. 8168d and above allow jumbo frames beyond 8k. Bump the received packet length check before enabling jumbo frames on these chipsets. Frame length indication covers bits 0..13 of the first Rx descriptor 32 bits for the 8169 and 8168. I only have authoritative documentation for the allowed use of the extra (13) bit with the 8169 and 8168c. Realtek's drivers use the same mask for the 816x and the fast ethernet only 810x. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: jumbo fixes.Francois Romieu2012-10-131-55/+247
| | | | | | | | | | | | | | | | | | | commit d58d46b5d85139d18eb939aa7279c160bab70484 upstream. - fix features : jumbo frames and checksumming can not be used at the same time. - introduce hw_jumbo_{enable / disable} helpers. Their content has been creatively extracted from Realtek's own drivers. As an illustration, it would be nice to know how/if the MaxTxPacketSize register operates when the device can work with a 9k jumbo frame as its documentation (8168c) can not be applied beyond ~7k. - rtl_tx_performance_tweak is moved forward. No change. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: remove erroneous processing of always set bit.Francois Romieu2012-10-131-1/+6
| | | | | | | | | | | commit e03f33af79f0772156e1a1a1e36bdddf8012b2e4 upstream. When set, RxFOVF (resp. RxBOVF) is always 1 (resp. 0). Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes <hayeswang@realtek.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: don't enable rx when shutdown.Hayes Wang2012-10-131-2/+5
| | | | | | | | | | | commit aaa89c08d9ffa3739c93d65d98b73ec2aa2e93a5 upstream. Only 8111b needs to enable rx when shutdowning with WoL. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: fix wake on lan setting for non-8111E.Hayes Wang2012-10-131-2/+4
| | | | | | | | | | | | commit d4ed95d796e5126bba51466dc07e287cebc8bd19 upstream. Only 8111E needs enable RxConfig bit 0 ~ 3 when suspending or shutdowning for wake on lan. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* r8169: Add support for D-Link 530T rev C1 (Kernel Bug 38862)Lennart Sorensen2011-08-151-0/+1
| | | | | | | | | | | | | | | | | | | [ Upstream commit 93a3aa25933461d76141179fc94aa32d5f9d954a ] The D-Link DGE-530T rev C1 is a re-badged Realtek 8169 named DLG10028C, unlike the previous revisions which were skge based. It is probably the same as the discontinued DGE-528T (0x4300) other than the PCI ID. The PCI ID is 0x1186:0x4302. Adding it to r8169.c where 0x1186:0x4300 is already found makes the card be detected and work. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=38862 Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* r8169: fix wrong register use.Francois Romieu2011-06-241-1/+1
| | | | | Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
* r8169: fix static initializers.Francois Romieu2011-06-171-4/+6
| | | | Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
* Add appropriate <linux/prefetch.h> include for prefetch usersPaul Gortmaker2011-05-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After discovering that wide use of prefetch on modern CPUs could be a net loss instead of a win, net drivers which were relying on the implicit inclusion of prefetch.h via the list headers showed up in the resulting cleanup fallout. Give them an explicit include via the following $0.02 script. ========================================= #!/bin/bash MANUAL="" for i in `git grep -l 'prefetch(.*)' .` ; do grep -q '<linux/prefetch.h>' $i if [ $? = 0 ] ; then continue fi ( echo '?^#include <linux/?a' echo '#include <linux/prefetch.h>' echo . echo w echo q ) | ed -s $i > /dev/null 2>&1 if [ $? != 0 ]; then echo $i needs manual fixup MANUAL="$i $MANUAL" fi done echo ------------------- 8\<---------------------- echo vi $MANUAL ========================================= Signed-off-by: Paul <paul.gortmaker@windriver.com> [ Fixed up some incorrect #include placements, and added some non-network drivers and the fib_trie.c case - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* r8169: avoid late chip identifier initialisation.Francois Romieu2011-05-091-9/+9
| | | | | | | | Unknown 8168 chips did not have any PLL power method set as they did not inherit a default family soon enough. Fix it. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
* r8169: merge firmware information into the chipset description data.Francois Romieu2011-05-091-104/+110
| | | | | | | | | | | | | - RTL_GIGA_MAC_NONE is a fake index so put it at the end of the enumeration and shift everybody. - RTL_GIGA_MAC_VER_17 / RTL_GIGA_MAC_VER_16 ordering fixed. Though not wrong it was confusing enough to wonder if things were right. Renaming rtl_chip_info was not strictly necessary. It allows to check the patch for the correct use of the indexes though. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
* r8169: provide some firmware information via ethtool.Francois Romieu2011-05-091-20/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no real firmware version yet but the manpage of ethtool is rather terse about the driver information. Former output: $ ethtool -i eth1 driver: r8169 version: 2.3LK-NAPI firmware-version: bus-info: 0000:01:00.0 $ ethtool -i eth0 driver: r8169 version: 2.3LK-NAPI firmware-version: bus-info: 0000:03:00.0 Current output: $ ethtool -i eth1 driver: r8169 version: 2.3LK-NAPI firmware-version: N/A bus-info: 0000:01:00.0 $ ethtool -i eth0 driver: r8169 version: 2.3LK-NAPI firmware-version: rtl_nic/rtl8168d-1.fw bus-info: 0000:03:00.0 Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Fixed-by Ciprian Docan <docan@eden.rutgers.edu> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com> Cc: Fejes József <fejes@joco.name> Cc: Borislav Petkov <borislav.petkov@amd.com>
* r8169: remove non-NAPI context invocation of rtl8169_rx_interrupt.Francois Romieu2011-05-091-23/+9
| | | | | | | | | | | | | | | | Invocation of rtl8169_rx_interrupt from rtl8169_reset_task was originally intended to retrieve as much packets as possible from the rx ring when a reset was needed. Nowadays rtl8169_reset_task is only scheduled, with some delay a. from the tx timeout watchdog b. when resuming c. from rtl8169_rx_interrupt itself It's dubious that the loss of outdated packets will matter much for a) and b). c) does not need to call itself again. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
* r8169: link speed selection timer rework.Francois Romieu2011-05-091-35/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The implementation was a bit krusty. The 10s rtl8169_phy_timer timer has been (was ?) required with older 8169 for adequate phy operation when full gigabit is advertised in autonegotiated mode. The timer does nothing if the link is up. Otherwise it keeps resetting the phy until things improve. - the device private data field phy_1000_ctrl_reg was used to schedule the timer. Avoid it and save a few bytes. - rtl8169_set_settings pending timer is disabled before changing the link settings as rtl8169_phy_timer is not always needed (see the removed test in rtl8169_phy_timer). - rtl8169_set_speed the requested link parameters may not match the chipset : bail out early on failure. - rtl8169_open Calling rtl8169_request_timer is redundant with -> rtl8169_open -> rtl8169_init_phy -> rtl8169_set_speed -> mod_timer The latter always enables the phy timer whereas the former did not for RTL_GIGA_MAC_VER_01. It should not make things worse but only time will tell if reality agrees. - rtl8169_request_timer : unused yet. Removed. - rtl8169_delete_timer : useless. Bloat. Removed. Side effect : the timer may kick in if the TBI is enabled. I do not know if the TBI has ever been used in real life. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
* r8169: rtl8169_set_speed_xmii cleanup.Francois Romieu2011-05-091-10/+1
| | | | | | | | | | | | | | | | Shorten chipset version test. No functional change. Careful readers will notice that the 'supports_gmii' flag is deduced from the device PCI id. Though less specific than the chipset related RTL_GIGA_MAC_VER_XY, it is good enough to detect a GMII deprieved 810x. Some features push for a device specific configuration (improved jumbo frame support for instance). 'supports_gmii' will follow this path if / when the device PCI id test stops working. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
* r8169: remove some code duplication.Francois Romieu2011-05-091-23/+19
| | | | | Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
* r8169: style cleanups.Francois Romieu2011-05-091-108/+98
| | | | | Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
* ethtool: cosmetic: Use ethtool ethtool_cmd_speed APIDavid Decotigny2011-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | This updates the network drivers so that they don't access the ethtool_cmd::speed field directly, but use ethtool_cmd_speed() instead. For most of the drivers, these changes are purely cosmetic and don't fix any problem, such as for those 1GbE/10GbE drivers that indirectly call their own ethtool get_settings()/mii_ethtool_gset(). The changes are meant to enforce code consistency and provide robustness with future larger throughputs, at the expense of a few CPU cycles for each ethtool operation. All drivers compiled with make allyesconfig ion x86_64 have been updated. Tested: make allyesconfig on x86_64 + e1000e/bnx2x work Signed-off-by: David Decotigny <decot@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* ethtool: Use full 32 bit speed range in ethtool's set_settingsDavid Decotigny2011-04-291-1/+2
| | | | | | | | | | | | This makes sure the ethtool's set_settings() callback of network drivers don't ignore the 16 most significant bits when ethtool calls their set_settings(). All drivers compiled with make allyesconfig on x86_64 have been updated. Signed-off-by: David Decotigny <decot@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* r8169: fix merge conflict fix.Francois Romieu2011-04-271-20/+5
| | | | | | | | | | | - use adequate MAC_VER id (see 01dc7fec4025f6bb72b6b98ec88b375346b6dbbb) - remove duplicate rtl_firmware_info record - remove duplicate functions Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'master' of ↵David S. Miller2011-04-261-32/+76
|\ | | | | | | | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Resolved logic conflicts causing a build failure due to drivers/net/r8169.c changes using a patch from Stephen Rothwell. Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: don't request firmware when there's no userspace.François Romieu2011-04-241-28/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The firmware is cached during the first successfull call to open() and released once the network device is unregistered. The driver uses the cached firmware between open() and unregister_netdev(). So far the firmware is optional : a failure to load the firmware does not prevent open() to success. It is thus necessary to 1) unregister all 816x / 810[23] devices and 2) force a driver probe to issue a new firmware load. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Fixed-by: Ciprian Docan <docan@eden.rutgers.edu> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
* | r8169: TSO fixes.Francois Romieu2011-04-181-72/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - the MSS value is actually contained in a 11 bits wide (0x7ff) field. The extra bit in the former MSSMask did encompass the TSO command bit ("LargeSend") as well (0xfff). Oops. - the Tx descriptor layout is not the same through the whole chipset family. The 8169 documentation, the 8168c documentation and Realtek's drivers (8.020.00, 1.019.00, 6.014.00) highlight two layouts: 1. 8169, 8168 up to 8168b (included) and 8101 2. {8102e, 8168c} and beyond - notwithstanding the "first descriptor" and "last descriptor" bits, the same Tx descriptor content is enforced when a packet consists of several descriptors. The chipsets are documented to require it. Credits go to David Dillow <dave@thedillows.org> for the original patch. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Realtek <nic_swsd@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: r8169: convert to hw_featuresMichał Mirosław2011-04-101-62/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simple conversion with a bit of needed cleanup. This also fixes: - confusion around vlan_features in rtl8169_vlan_mode(), - problem with broken TSO for too big MTU (the limit is set at 0xFFF --- max MSS field value). SG+IP_CSUM+TSO is left disabled by default, based on suggestion by David Dillow. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net/r8169: support RTL8168Ehayeswang2011-03-301-5/+207
| | | | | | | | | | | | | | Support RTL8168E/RTL8111E. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net/r8169: add a new chip for RTL8168DPhayeswang2011-03-301-22/+76
| | | | | | | | | | | | | | Add a new chip for RTL8168DP. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net/r8169: add a new chip for RTL8105hayeswang2011-03-301-0/+1
|/ | | | | | | Add a new chip for RTL8105 whose settings are the same with RTL_GIGA_MAC_VER_30. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* r8169: fix a bug in rtl8169_init_phy()Eric Dumazet2011-03-201-2/+2
| | | | | | | | | | | | | commit 54405cde7624 (r8169: support control of advertising.) introduced a bug in rtl8169_init_phy() Reported-and-tested-by: Piotr Hosowicz <piotr@hosowicz.com> Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Acked-by:: Oliver Neukum <oliver@neukum.org> Cc: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Anca Emanuel <anca.emanuel@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge branch 'davem-next.r8169' of ↵David S. Miller2011-03-071-94/+178
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6
| * r8169: convert to new VLAN model.Francois Romieu2011-03-051-61/+49
| | | | | | | | | | Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Reviewed-by: Jesse Gross <jesse@nicira.com>
| * r8169: support control of advertising.Oliver Neukum2011-03-051-17/+37
| | | | | | | | | | | | | | | | This allows "ethtool advertise" to control the speed and duplex features the device offers the switch. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
| * r8169: support the new chips for RTL8105E.Hayes Wang2011-03-051-2/+90
| | | | | | | | | | Signed-off-by: Hayes Wang <hayeswang@realtek.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
| * r8169: adjust rtl8169_set_speed_xmii function.Hayes Wang2011-03-011-14/+2
| | | | | | | | | | | | | | | | | | - adjust code of rtl8169_set_speed_xmii function - remove parts of code which are done in rtl_pll_power_up function (8168 only) Signed-off-by: Hayes Wang <hayeswang@realtek.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
* | r8169: disable ASPMStanislaw Gruszka2011-03-031-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For some time is known that ASPM is causing troubles on r8169, i.e. make device randomly stop working without any errors in dmesg. Currently Tomi Leppikangas reports that system with r8169 device hangs with MCE errors when ASPM is enabled: https://bugzilla.redhat.com/show_bug.cgi?id=642861#c4 Lets disable ASPM for r8169 devices at all, to avoid problems with r8169 PCIe devices at least for some users. Reported-by: Tomi Leppikangas <tomi.leppikangas@gmail.com> Cc: stable@kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | r8169: fix RTL8168DP power off issue.Hayes Wang2011-02-231-3/+14
| | | | | | | | | | | | | | | | - fix the RTL8111DP turn off the power when DASH is enabled. - RTL_GIGA_MAC_VER_27 must wait for tx finish before reset. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
* | r8169: correct settings of rtl8102e.Hayes Wang2011-02-231-14/+6
| | | | | | | | | | | | | | Adjust and remove certain settings of RTL8102E which are for previous chips. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Acked-off-by: Francois Romieu <romieu@fr.zoreil.com>
* | r8169: fix incorrect args to oob notify.Hayes Wang2011-02-231-2/+3
|/ | | | | | | It results in the wrong point address and influences RTL8168DP. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
generated by cgit v1.1 at 2024-05-20 21:51:31 +0000