- 23 5月, 2011 2 次提交
-
-
由 Paul Gortmaker 提交于
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: NPaul <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: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Paul Gortmaker 提交于
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: NPaul <paul.gortmaker@windriver.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 10 5月, 2011 8 次提交
-
-
由 Francois Romieu 提交于
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: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
-
由 Francois Romieu 提交于
- 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: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
-
由 Francois Romieu 提交于
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: NFrancois 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>
-
由 Francois Romieu 提交于
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: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
-
由 Francois Romieu 提交于
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: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
-
由 Francois Romieu 提交于
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: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
-
由 Francois Romieu 提交于
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
-
由 Francois Romieu 提交于
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
-
- 30 4月, 2011 2 次提交
-
-
由 David Decotigny 提交于
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: NDavid Decotigny <decot@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David Decotigny 提交于
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: NDavid Decotigny <decot@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 28 4月, 2011 1 次提交
-
-
由 Francois Romieu 提交于
- use adequate MAC_VER id (see 01dc7fec) - remove duplicate rtl_firmware_info record - remove duplicate functions Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 24 4月, 2011 1 次提交
-
-
由 François Romieu 提交于
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: NFrancois Romieu <romieu@fr.zoreil.com> Fixed-by: NCiprian Docan <docan@eden.rutgers.edu> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
-
- 19 4月, 2011 1 次提交
-
-
由 Francois Romieu 提交于
- 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: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Realtek <nic_swsd@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 11 4月, 2011 1 次提交
-
-
由 Michał Mirosław 提交于
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: NMichał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 31 3月, 2011 3 次提交
-
-
由 hayeswang 提交于
Support RTL8168E/RTL8111E. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 hayeswang 提交于
Add a new chip for RTL8168DP. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 hayeswang 提交于
Add a new chip for RTL8105 whose settings are the same with RTL_GIGA_MAC_VER_30. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 21 3月, 2011 1 次提交
-
-
由 Eric Dumazet 提交于
commit 54405cde (r8169: support control of advertising.) introduced a bug in rtl8169_init_phy() Reported-and-tested-by: NPiotr Hosowicz <piotr@hosowicz.com> Reported-and-tested-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Acked-by: N: Oliver Neukum <oliver@neukum.org> Cc: Francois Romieu <romieu@fr.zoreil.com> Tested-by: NAnca Emanuel <anca.emanuel@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 20 3月, 2011 1 次提交
-
-
由 Eric Dumazet 提交于
commit 54405cde (r8169: support control of advertising.) introduced a bug in rtl8169_init_phy() Reported-by: NPiotr Hosowicz <piotr@hosowicz.com> Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Cc: Oliver Neukum <oliver@neukum.org> Cc: Francois Romieu <romieu@fr.zoreil.com> Tested-by: NAnca Emanuel <anca.emanuel@gmail.com> Tested-by: NPiotr Hosowicz <piotr@hosowicz.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 05 3月, 2011 3 次提交
-
-
由 Francois Romieu 提交于
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Reviewed-by: NJesse Gross <jesse@nicira.com>
-
由 Oliver Neukum 提交于
This allows "ethtool advertise" to control the speed and duplex features the device offers the switch. Signed-off-by: NOliver Neukum <oneukum@suse.de> Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
-
由 Hayes Wang 提交于
Signed-off-by: NHayes Wang <hayeswang@realtek.com> Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
-
- 04 3月, 2011 1 次提交
-
-
由 Stanislaw Gruszka 提交于
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: NTomi Leppikangas <tomi.leppikangas@gmail.com> Cc: stable@kernel.org Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 02 3月, 2011 1 次提交
-
-
由 Hayes Wang 提交于
- 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: NHayes Wang <hayeswang@realtek.com> Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
-
- 24 2月, 2011 3 次提交
-
-
由 Hayes Wang 提交于
- 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: NHayes Wang <hayeswang@realtek.com> Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
-
由 Hayes Wang 提交于
Adjust and remove certain settings of RTL8102E which are for previous chips. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Acked-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
-
由 Hayes Wang 提交于
It results in the wrong point address and influences RTL8168DP. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
-
- 18 2月, 2011 1 次提交
-
-
由 Ivan Vecera 提交于
Without calling of netif_carrier_off at the end of the probe the operstate is unknown when the device is initially opened. By default the carrier is on so when the device is opened and netif_carrier_on is called the link watch event is not fired and operstate remains zero (unknown). This patch fixes this behavior in forcedeth and r8169. Signed-off-by: NIvan Vecera <ivecera@redhat.com> Acked-by: NFrancois Romieu <romieu@fr.zoreil.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 04 2月, 2011 3 次提交
-
-
由 Francois Romieu 提交于
While the RxFIFO interruption is masked for most 8168, nothing prevents it to appear in the irq status word. This is no excuse to crash. Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Ivan Vecera <ivecera@redhat.com> Cc: Hayes <hayeswang@realtek.com>
-
由 Francois Romieu 提交于
Some experiment-based action to prevent my 8168 chipsets locking-up hard in the irq handler under load (pktgen ~1Mpps). Apparently a reset is not always mandatory (is it at all ?). - RTL_GIGA_MAC_VER_12 - RTL_GIGA_MAC_VER_25 Missed ~55% packets. Note: - this is an old SiS 965L motherboard - the 8168 chipset emits (lots of) control frames towards the sender - RTL_GIGA_MAC_VER_26 The chipset does not go into a frenzy of mac control pause when it crashes yet but it can still be crashed. It needs more work. Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Ivan Vecera <ivecera@redhat.com> Cc: Hayes <hayeswang@realtek.com>
-
由 Ivan Vecera 提交于
I found that one of the 8168c chipsets (concretely XID 1c4000c0) starts generating RxFIFO overflow errors. The result is an infinite loop in interrupt handler as the RxFIFOOver is handled only for ...MAC_VER_11. With the workaround everything goes fine. Signed-off-by: NIvan Vecera <ivecera@redhat.com> Acked-by: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Hayes <hayeswang@realtek.com>
-
- 14 1月, 2011 1 次提交
-
-
由 françois romieu 提交于
The firmware agent is not available during resume. Loading the firmware during open() (see eee3a96c) is not enough. close() is run during resume through rtl8169_reset_task(), whence the mildly natural release of firmware in the driver removal method instead. It will help with http://bugs.debian.org/609538. It will not avoid the 60 seconds delay when: - there is no firmware - the driver is loaded and the device is not up before a suspend/resume Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Tested-by: NJarek Kamiński <jarek@vilo.eu.org> Cc: Hayes <hayeswang@realtek.com> Cc: Ben Hutchings <benh@debian.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 11 1月, 2011 1 次提交
-
-
由 hayeswang 提交于
Update rtl_phy_write_fw function. The new function could parse the complex firmware which is used by RTL8111E and later. The new firmware may read data and do some operations, not just do writing only. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 10 1月, 2011 1 次提交
-
-
由 françois romieu 提交于
It workarounds the 60s firmware load failure timeout for the non-modular case. Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 05 1月, 2011 4 次提交
-
-
由 françois romieu 提交于
Adapted from version 8.019.00 of Realtek's r8168 driver Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Hayes <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 françois romieu 提交于
Newer 8168 needs a slightly different rtl_csi_access_enable. This patch separates some noise from the real thing. No functional change. Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Hayes <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 françois romieu 提交于
Adapted from version 8.019.00 of Realtek's r8168 driver. Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Hayes <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 françois romieu 提交于
Bits from : - version 8.019.00 of Realtek's 8168 driver - version 1.019.00 of Realtek's 8101 driver Plain old 8169 (PCI) devices do not seem to need anything akin to it. Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Hayes <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-