1. 18 7月, 2018 1 次提交
  2. 05 7月, 2018 1 次提交
  3. 02 7月, 2018 1 次提交
    • H
      r8169: remove old PHY reset hack · 335c997d
      Heiner Kallweit 提交于
      This hack (affecting the non-PCIe models only) was introduced in 2004
      to deal with link negotiation failures in 1GBit mode. Based on a
      comment in the r8169 vendor driver I assume the issue affects RTL8169sb
      in combination with particular 1GBit switch models.
      
      Resetting the PHY every 10s and hoping that one fine day we will make
      it to establish the link seems to be very hacky to me. I'd say:
      If 1GBit doesn't work reliably in a users environment then the user
      should remove 1GBit from the advertised modes, e.g. by using
      ethtool -s <if> advertise <10/100 modes>
      
      If the issue affects one chip version only and that with most link
      partners, then we could also think of removing 1GBit from the
      advertised modes for this chip version in the driver.
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      335c997d
  4. 30 6月, 2018 2 次提交
    • H
      r8169: remove TBI 1000BaseX support · e397286b
      Heiner Kallweit 提交于
      The very first version of RTL8169 from 2002 (and only this one) has
      support for a TBI 1000BaseX fiber interface. The TBI support in the
      driver makes switching to phylib tricky, so best would be to get
      rid of it. I found no report from anybody using a device with RTL8169
      and fiber interface, also the vendor driver doesn't support this mode
      (any longer).
      So remove TBI support and bail out with a message if a card with
      activated TBI is detected. If there really should be any user of it
      out there, we could add a stripped-down version of the driver
      supporting chip version 01 and TBI only (and maybe move it to
      staging).
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e397286b
    • H
      r8169: use standard debug output functions · 49d17512
      Heiner Kallweit 提交于
      I see no need to define a private debug output symbol, let's use the
      standard debug output functions instead. In this context also remove
      the deprecated PFX define.
      
      The one assertion is wrong IMO anyway, this code path is used also
      by chip version 01.
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      49d17512
  5. 26 6月, 2018 1 次提交
  6. 25 6月, 2018 3 次提交
  7. 23 6月, 2018 2 次提交
  8. 22 6月, 2018 2 次提交
  9. 21 6月, 2018 1 次提交
  10. 21 5月, 2018 1 次提交
    • H
      r8169: fix network error on resume from suspend · 52f8560e
      Heiner Kallweit 提交于
      This commit removed calls to rtl_set_rx_mode(). This is ok for the
      standard path if the link is brought up, however it breaks system
      resume from suspend. Link comes up but no network traffic.
      
      Meanwhile common code from rtl_hw_start_8169/8101/8168() was moved
      to rtl_hw_start(), therefore re-add the call to rtl_set_rx_mode()
      there.
      
      Due to adding this call we have to move definition of rtl_hw_start()
      after definition of rtl_set_rx_mode().
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Fixes: 82d3ff6d ("r8169: remove calls to rtl_set_rx_mode")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      52f8560e
  11. 09 5月, 2018 1 次提交
    • H
      r8169: fix powering up RTL8168h · 3148dedf
      Heiner Kallweit 提交于
      Since commit a92a0849 "r8169: improve runtime pm in general and
      suspend unused ports" interfaces w/o link are runtime-suspended after
      10s. On systems where drivers take longer to load this can lead to the
      situation that the interface is runtime-suspended already when it's
      initially brought up.
      This shouldn't be a problem because rtl_open() resumes MAC/PHY.
      However with at least one chip version the interface doesn't properly
      come up, as reported here:
      https://bugzilla.kernel.org/show_bug.cgi?id=199549
      
      The vendor driver uses a delay to give certain chip versions some
      time to resume before starting the PHY configuration. So let's do
      the same. I don't know which chip versions may be affected,
      therefore apply this delay always.
      
      This patch was reported to fix the issue for RTL8168h.
      I was able to reproduce the issue on an Asus H310I-Plus which also
      uses a RTL8168h. Also in my case the patch fixed the issue.
      Reported-by: NSlava Kardakov <ojab@ojab.ru>
      Tested-by: NSlava Kardakov <ojab@ojab.ru>
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3148dedf
  12. 03 5月, 2018 10 次提交
  13. 30 4月, 2018 8 次提交
  14. 23 4月, 2018 1 次提交
  15. 19 4月, 2018 5 次提交