1. 15 7月, 2021 2 次提交
  2. 18 6月, 2021 1 次提交
  3. 17 6月, 2021 1 次提交
  4. 02 6月, 2021 2 次提交
  5. 25 5月, 2021 1 次提交
  6. 26 4月, 2021 1 次提交
  7. 24 4月, 2021 2 次提交
  8. 23 4月, 2021 1 次提交
  9. 17 4月, 2021 6 次提交
  10. 20 3月, 2021 1 次提交
  11. 04 3月, 2021 1 次提交
    • H
      Revert "r8152: adjust the settings about MAC clock speed down for RTL8153" · 4b5dc1a9
      Hayes Wang 提交于
      This reverts commit 134f98bc.
      
      The r8153_mac_clk_spd() is used for RTL8153A only, because the register
      table of RTL8153B is different from RTL8153A. However, this function would
      be called when RTL8153B calls r8153_first_init() and r8153_enter_oob().
      That causes RTL8153B becomes unstable when suspending and resuming. The
      worst case may let the device stop working.
      
      Besides, revert this commit to disable MAC clock speed down for RTL8153A.
      It would avoid the known issue when enabling U1. The data of the first
      control transfer may be wrong when exiting U1.
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4b5dc1a9
  12. 24 2月, 2021 4 次提交
  13. 05 2月, 2021 2 次提交
  14. 03 2月, 2021 1 次提交
  15. 13 1月, 2021 1 次提交
  16. 06 11月, 2020 1 次提交
  17. 04 11月, 2020 2 次提交
  18. 24 8月, 2020 1 次提交
  19. 08 8月, 2020 1 次提交
  20. 20 5月, 2020 1 次提交
  21. 15 5月, 2020 1 次提交
  22. 07 3月, 2020 1 次提交
  23. 03 3月, 2020 1 次提交
  24. 01 3月, 2020 1 次提交
    • Y
      r8152: check disconnect status after long sleep · d64c7a08
      You-Sheng Yang 提交于
      Dell USB Type C docking WD19/WD19DC attaches additional peripherals as:
      
        /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
            |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
                |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
                |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class,
                    Driver=r8152, 5000M
      
      where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the dock.
      
      When hotplugging such dock with additional usb devices already attached on
      it, the probing process may reset usb 2.1 port, therefore r8152 ethernet
      device is also reset. However, during r8152 device init there are several
      for-loops that, when it's unable to retrieve hardware registers due to
      being disconnected from USB, may take up to 14 seconds each in practice,
      and that has to be completed before USB may re-enumerate devices on the
      bus. As a result, devices attached to the dock will only be available
      after nearly 1 minute after the dock was plugged in:
      
        [ 216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
        [ 216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
        [ 258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY not ready
        [ 258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Invalid header when reading pass-thru MAC addr
        [ 258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get ether addr fail
      
      This happens in, for example, r8153_init:
      
        static int generic_ocp_read(struct r8152 *tp, u16 index, u16 size,
      			    void *data, u16 type)
        {
          if (test_bit(RTL8152_UNPLUG, &tp->flags))
            return -ENODEV;
          ...
        }
      
        static u16 ocp_read_word(struct r8152 *tp, u16 type, u16 index)
        {
          u32 data;
          ...
          generic_ocp_read(tp, index, sizeof(tmp), &tmp, type | byen);
      
          data = __le32_to_cpu(tmp);
          ...
          return (u16)data;
        }
      
        static void r8153_init(struct r8152 *tp)
        {
          ...
          if (test_bit(RTL8152_UNPLUG, &tp->flags))
            return;
      
          for (i = 0; i < 500; i++) {
            if (ocp_read_word(tp, MCU_TYPE_PLA, PLA_BOOT_CTRL) &
                AUTOLOAD_DONE)
              break;
            msleep(20);
          }
          ...
        }
      
      Since ocp_read_word() doesn't check the return status of
      generic_ocp_read(), and the only exit condition for the loop is to have
      a match in the returned value, such loops will only ends after exceeding
      its maximum runs when the device has been marked as disconnected, which
      takes 500 * 20ms = 10 seconds in theory, 14 in practice.
      
      To solve this long latency another test to RTL8152_UNPLUG flag should be
      added after those 20ms sleep to skip unnecessary loops, so that the device
      probe can complete early and proceed to parent port reset/reprobe process.
      
      This can be reproduced on all kernel versions up to latest v5.6-rc2, but
      after v5.5-rc7 the reproduce rate is dramatically lowered to 1/30 or less
      while it was around 1/2.
      Signed-off-by: NYou-Sheng Yang <vicamo.yang@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d64c7a08
  25. 20 2月, 2020 1 次提交
  26. 04 2月, 2020 1 次提交
  27. 23 1月, 2020 1 次提交