The magic write to register 0x82 will often cause PCI config space on
my 8168 (PCI ID 10ec:8168, revision 2. mounted in an LG P300 laptop)
to be filled with ones during driver load, and thus breaking NIC
operation until reboot. If it does not happen on first driver load it
can easily be reproduced by unloading and loading the driver a few
times.
The magic write was added long ago by this commit:
Author: François Romieu <romieu@fr.zoreil.com>
Date: Sat Jan 10 06:00:46 2004 -0500
[netdrvr r8169] Merge of changes done by Realtek to rtl8169_init_one():
- phy capability settings allows lower or equal capability as suggested
in Realtek's changes;
- I/O voodoo;
- no need to s/mdio_write/RTL8169_WRITE_GMII_REG/;
- s/rtl8169_hw_PHY_config/rtl8169_hw_phy_config/;
- rtl8169_hw_phy_config(): ad-hoc struct "phy_magic" to limit duplication
of code (yep, the u16 -> int conversions should work as expected);
- variable renames and whitepace changes ignored.
As the 8168 wasn't supported by that version this patch simply removes
the bogus write from mac versions <= RTL_GIGA_MAC_VER_06.
[The change above makes sense for the 8101/8102 too -- Ueimor]
Signed-off-by: Marcus Sundberg <marcus@ingate.com>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
The layout of the 8101 series is identical to that of the 8168 one,
thus allowing to pack everything not 8169 related above MAC_VER_06.
New 810x and 8168 chipsets should automagically behave correctly.
It matches code in Realtek's 1.008.00 8101 and 8.007.00 8168 drivers.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
It will almost unavoidably cause some breakage but it
is long overdue.
The driver identification string has been updated, a
lost tabulation and some unused code have been removed.
Otherwise the code paths should stay the same.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
r8169_get_mac_version crashes when it meets an unknown MAC
due to tp->pci_dev not being set. Initialize it early.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
When we add the generic napi_disable_pending() breakout
logic to net_rx_action() it means that napi_disable()
can cause NAPI poll interrupt events to be disabled.
And this is exactly what we want. If a napi_disable()
is pending, and we are looping in the ->poll(), we want
->poll() event interrupts to stay disabled and we want
to complete the NAPI poll ASAP.
When ->poll() break out during device down was being handled on a
per-driver basis, often these drivers would turn interrupts back on
when '!netif_running()' was detected.
And this would just cause a reschedule of the NAPI ->poll() in the
interrupt handler before the napi_disable() could get in there and
grab the NAPI_STATE_SCHED bit.
The vast majority of drivers don't care if napi_disable() might have
the side effect of disabling NAPI ->poll() event interrupts. In all
such cases, when a napi_disable() is performed, the driver just
disabled interrupts or is about to.
However there were three exceptions to this in PCNET32, R8169, and
SKY2. To fix those cases, at the subsequent napi_enable() points, I
added code to ensure that the ->poll() interrupt events are enabled in
the hardware.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Don Fry <pcnet32@verizon.net>
Oops.
The current code does not like being given an u16 with the highest
bit set as an argument to mdio_write. Let's enforce a correct range of
values for both the register address and value (resp. 5 and 16 bits).
The callers are currently left as-is.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Various symptoms depending on the .config options:
- the card stops working after some (short) time
- the card does not work at all
- the card disappears (nothing in lspci/dmesg)
A real power-off is needed to recover the card.
Signed-off-by: Mark Lord <mlord@pobox.com>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
The 8168c and the 8100e choke on it. I have not seen an indication
nor received a report that the TBI is being actively used on the
remaining 8168b and 8110. Let's disable it for now until someone
complains.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Matthias Winkler <m.winkler@unicon-ka.de>
Cc: Maarten Vanraes <maarten.vanraes@gmail.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Realtek's r8168 driver version 8.003.00 adds new init sequences
(they do not appear in version 8.002.00).
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
The values have been updated between version 8.002.00 and version
8.003.00 of Realtek's r8168 driver. This modification syncs the
8168C with version 8.003.00.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
The code is reworked to easily add phy-dependant init changes.
No change of behavior should be noticed.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
The identifiers have been extracted from Realtek's drivers:
- version 8.002.00 of the r8168 driver
- version 6.002.00 of the r8169 driver
- version 1.002.00 of the r8101 driver
1. RTL_GIGA_MAC_VER_17 (8168Bf) is isolated from RTL_GIGA_MAC_VER_12 (8168Be)
Both are still handled the same in rtl8169_set_speed_xmii and in
rtl_set_rx_mode to avoid changes of behavior in this patch.
2. RTL_GIGA_MAC_VER_16 (8101Ec) is isolated from RTL_GIGA_MAC_VER_13 (8101Eb)
Same thing as above with relation to rtl8169_set_speed_xmii,
rtl_set_rx_mode and rtl_hw_start_8101.
3. The remaining new identifiers should not hurt.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Marcus Sundberg
Francois Romieu
Ivan Vecera
Roel Kluin
David S. Miller
Al Viro
Mark Lord
Ciaran McCreesh
Stephen Hemminger