On 28.02.2013 03:34, Greg KH wrote:
Possibly because staging drivers have a very low priority, and odds are,
the patch didn't apply.
Sorry - but r8169.c is not a staging driver.
The original patch cannot apply, because there were other changes in the
driver:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=f0298f8143e89ac4da306e14b9aa1927e93916d0
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=6f0333b8fde44b8c04a53b2461504f0e8f1cebe6
But I don't think, these changes are needed for the fix for rtl8102e.
Please resend this in a format we can apply it in (hint, it needs to be
at the root of the kernel source tree, read
Documentation/SubmittingPatches for how to properly create patches.)
Thank you, I'll try my best.
1.
Backport d24e9aafe5d5dfdf6d114b29e67f8afd5fae5ef0.
r8169: correct settings of rtl8102e.
Adjust and remove certain settings of RTL8102E which are for previous chips.
Signed-off-by: Hayes Wang <hayeswang@xxxxxxxxxxx>
Acked-off-by: Francois Romieu <romieu@xxxxxxxxxxxxx>
--- linux-2.6.32.60.org/drivers/net/r8169.c 2012-10-07
23:41:24.000000000 +0200
+++ linux-2.6.32.60/drivers/net/r8169.c 2013-02-28 22:58:02.000000000 +0100
@@ -3076,7 +3076,7 @@ rtl8169_init_one(struct pci_dev *pdev, c
goto err_out_mwi_3;
}
- tp->cp_cmd = PCIMulRW | RxChkSum;
+ tp->cp_cmd = RxChkSum;
if ((sizeof(dma_addr_t) > 4) &&
!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) && use_dac) {
@@ -3824,8 +3824,7 @@ static void rtl_hw_start_8168(struct net
Cxpl_dbg_sel | \
ASF | \
PktCntrDisable | \
- PCIDAC | \
- PCIMulRW)
+ Mac_dbgo_sel)
static void rtl_hw_start_8102e_1(void __iomem *ioaddr, struct pci_dev
*pdev)
{
@@ -3855,8 +3854,6 @@ static void rtl_hw_start_8102e_1(void __
if ((cfg1 & LEDS0) && (cfg1 & LEDS1))
RTL_W8(Config1, cfg1 & ~LEDS0);
- RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R810X_CPCMD_QUIRK_MASK);
-
rtl_ephy_init(ioaddr, e_info_8102e_1, ARRAY_SIZE(e_info_8102e_1));
}
@@ -3868,8 +3865,6 @@ static void rtl_hw_start_8102e_2(void __
RTL_W8(Config1, MEMMAP | IOMAP | VPD | PMEnable);
RTL_W8(Config3, RTL_R8(Config3) & ~Beacon_en);
-
- RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R810X_CPCMD_QUIRK_MASK);
}
static void rtl_hw_start_8102e_3(void __iomem *ioaddr, struct pci_dev
*pdev)
@@ -3895,6 +3890,8 @@ static void rtl_hw_start_8101(struct net
}
}
+ RTL_W8(Cfg9346, Cfg9346_Unlock);
+
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_07:
rtl_hw_start_8102e_1(ioaddr, pdev);
@@ -3909,14 +3906,13 @@ static void rtl_hw_start_8101(struct net
break;
}
- RTL_W8(Cfg9346, Cfg9346_Unlock);
+ RTL_W8(Cfg9346, Cfg9346_Lock);
RTL_W8(EarlyTxThres, EarlyTxThld);
rtl_set_rx_max_size(ioaddr, tp->rx_buf_sz);
- tp->cp_cmd |= rtl_rw_cpluscmd(ioaddr) | PCIMulRW;
-
+ tp->cp_cmd &= ~R810X_CPCMD_QUIRK_MASK;
RTL_W16(CPlusCmd, tp->cp_cmd);
RTL_W16(IntrMitigate, 0x0000);
@@ -3926,14 +3922,10 @@ static void rtl_hw_start_8101(struct net
RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
rtl_set_rx_tx_config_registers(tp);
- RTL_W8(Cfg9346, Cfg9346_Lock);
-
RTL_R8(IntrMask);
rtl_set_rx_mode(dev);
- RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
-
RTL_W16(MultiIntr, RTL_R16(MultiIntr) & 0xf000);
RTL_W16(IntrMask, tp->intr_event);
2.
Backport 3a42cce923b0242d0293cae0a162601afa89d552.
r8169: remove the obsolete and incorrect AMD workaround
[ 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@xxxxxx>
Acked-by: Francois Romieu <romieu@xxxxxxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
--- linux-2.6.32.60.org/drivers/net/r8169.c 2012-10-07
23:41:24.000000000 +0200
+++ linux-2.6.32.60/drivers/net/r8169.c 2013-02-28 23:19:46.000000000 +0100
@@ -4579,13 +4579,6 @@ static int rtl8169_rx_interrupt(struct n
dev->stats.rx_bytes += pkt_size;
dev->stats.rx_packets++;
}
-
- /* Work around for AMD plateform. */
- if ((desc->opts2 & cpu_to_le32(0xfffe000)) &&
- (tp->mac_version == RTL_GIGA_MAC_VER_05)) {
- desc->opts2 = 0;
- cur_rx++;
- }
}
count = cur_rx - tp->cur_rx;
3.
Backport 7106159f8bd33bd5e5b0ea2c87e499117fc22c69.
r8169: Add support for D-Link 530T rev C1 (Kernel Bug 38862)
[ 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@xxxxxxxxxxxxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
--- linux-2.6.32.60.org/drivers/net/r8169.c 2012-10-07
23:41:24.000000000 +0200
+++ linux-2.6.32.60/drivers/net/r8169.c 2013-02-28 23:22:39.000000000 +0100
@@ -176,6 +176,7 @@ static struct pci_device_id rtl8169_pci_
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), 0, 0, RTL_CFG_1 },
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), 0, 0, RTL_CFG_0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4302), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_AT, 0xc107), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(0x16ec, 0x0116), 0, 0, RTL_CFG_0 },
{ PCI_VENDOR_ID_LINKSYS, 0x1032,
4.
Backport 17c99297212a2d1b1779a08caf4b0d83a85545df.
r8169: incorrect identifier for a 8168dp
Merge error.
See CFG_METHOD_8 (0x3c800000 + 0x00300000) since version 8.002.00
of Realtek's driver.
Signed-off-by: Francois Romieu <romieu@xxxxxxxxxxxxx>
Cc: Hayes <hayeswang@xxxxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
--- linux-2.6.32.60.org/drivers/net/r8169.c 2012-10-07
23:41:24.000000000 +0200
+++ linux-2.6.32.60/drivers/net/r8169.c 2013-02-28 23:40:35.000000000 +0100
@@ -1306,7 +1306,7 @@ static void rtl8169_get_mac_version(stru
{ 0x7c800000, 0x28000000, RTL_GIGA_MAC_VER_26 },
/* 8168C family. */
- { 0x7cf00000, 0x3ca00000, RTL_GIGA_MAC_VER_24 },
+ { 0x7cf00000, 0x3cb00000, RTL_GIGA_MAC_VER_24 },
{ 0x7cf00000, 0x3c900000, RTL_GIGA_MAC_VER_23 },
{ 0x7cf00000, 0x3c800000, RTL_GIGA_MAC_VER_18 },
{ 0x7c800000, 0x3c800000, RTL_GIGA_MAC_VER_24 },
--
der tom
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html