[PATCH 2.6.26-rc9] r8169: Avoid thrashing PCI conf space on RTL_GIGA_MAC_VER_20. - Kernel

This is a discussion on [PATCH 2.6.26-rc9] r8169: Avoid thrashing PCI conf space on RTL_GIGA_MAC_VER_20. - Kernel ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: [PATCH 2.6.26-rc9] r8169: Avoid thrashing PCI conf space on RTL_GIGA_MAC_VER_20.

  1. [PATCH 2.6.26-rc9] r8169: Avoid thrashing PCI conf space on RTL_GIGA_MAC_VER_20.

    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
    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.

    Signed-off-by: Marcus Sundberg
    ---
    The magic write is not present in the r8168 driver from RealTek either.
    Does anyone know what it's supposed to do?

    //Marcus

    drivers/net/r8169.c | 6 ++++--
    1 files changed, 4 insertions(+), 2 deletions(-)

    diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
    index 6572425..42d7c0a 100644
    --- a/drivers/net/r8169.c
    +++ b/drivers/net/r8169.c
    @@ -1438,8 +1438,10 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)

    rtl_hw_phy_config(dev);

    - dprintk("Set MAC Reg C+CR Offset 0x82h = 0x01h\n");
    - RTL_W8(0x82, 0x01);
    + if (tp->mac_version <= RTL_GIGA_MAC_VER_06) {
    + dprintk("Set MAC Reg C+CR Offset 0x82h = 0x01h\n");
    + RTL_W8(0x82, 0x01);
    + }

    pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);

    --
    ---------------------------------------+--------------------------
    Marcus Sundberg | Firewalls with SIP & NAT
    Software Developer, Ingate Systems AB | http://www.ingate.com/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH 2.6.26-rc9] r8169: Avoid thrashing PCI conf space on RTL_GIGA_MAC_VER_20.

    Marcus Sundberg :
    > 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.


    Nice. Thanks.

    [...]
    > ---
    > The magic write is not present in the r8168 driver from RealTek either.
    > Does anyone know what it's supposed to do?


    No idea. It is not used in the 8101/8102 driver either.

    --
    Ueimor
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH 2.6.26-rc9] r8169: Avoid thrashing PCI conf space on RTL_GIGA_MAC_VER_20.

    Marcus Sundberg :
    > 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.


    I have added it at the root of the 'r8169' branch in repository:

    git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git r8169

    The branch is described below (on top of davem's 'next' branch).

    The whole serie is available as a patck-kit on top of 2.6.26-rc9 at:

    http://userweb.kernel.org/~romieu/r8...-rc9/20080710/


    Diffstat
    --------

    drivers/net/r8169.c | 496 ++++++++++++++++++++++++++++++++++++++++++++++++---
    1 files changed, 470 insertions(+), 26 deletions(-)

    Shortlog
    --------

    Francois Romieu (12):
    r8169: update phy init parameters
    r8169: new phy init parameters for the 8168b
    r8169: shuffle some registers handling around (8168 operation only)
    r8169: add 8168 registers description
    r8169: make room for more specific 8168 hardware start procedure
    r8169: Tx performance tweak
    r8169: sync existing 8168 device hardware start sequences with vendor driver
    r8169: add a new 8168 flavor
    r8169: add a new 8168 flavor (bis)
    r8169: add a new 8168 flavor (ter)
    r8169: change default behavior for mildly identified 8168c chipsets
    r8169: use pci_find_capability for the PCI-E features

    Marcus Sundberg (1):
    r8169: avoid thrashing PCI conf space above RTL_GIGA_MAC_VER_06

    --
    Ueimor
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread