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>
It is currently limited to the tested 0x8136 and 0x8168. 8169sb/8110sb ought
to handle it as well where they support MSI.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Tester-Cc: Rolf Eike Beer <eike-kernel@sf-tec.de>
