An error occurred fetching the project authors.
  1. 09 Jun, 2023 1 commit
  2. 09 Sep, 2022 1 commit
  3. 22 Aug, 2022 1 commit
  4. 06 Jun, 2022 1 commit
  5. 15 Dec, 2021 1 commit
  6. 11 Jun, 2021 2 commits
  7. 18 Mar, 2021 2 commits
    • Mika Westerberg's avatar
      thunderbolt: Allow multiple DMA tunnels over a single XDomain connection · 180b0689
      Mika Westerberg authored
      Currently we have had an artificial limitation of a single DMA tunnel
      per XDomain connection. However, hardware wise there is no such limit
      and software based connection manager can take advantage of all the DMA
      rings available on the host to establish tunnels.
      
      For this reason make the tb_xdomain_[enable|disable]_paths() to take the
      DMA ring and HopID as parameter instead of storing them in the struct
      tb_xdomain. We also add API functions to allocate input and output
      HopIDs of the XDomain connection that the service drivers can use
      instead of hard-coding.
      
      Also convert the two existing service drivers over to this API.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      180b0689
    • Mika Westerberg's avatar
      thunderbolt: Decrease control channel timeout for software connection manager · 7f0a34d7
      Mika Westerberg authored
      When the firmware connection manager is not proxying between the
      software and the hardware we can decrease the timeout for control
      packets significantly. The USB4 spec recommends 10 ms +- 1 ms but we use
      slightly larger value (100 ms) which is recommendation from Intel
      Thunderbolt firmware folks. When firmware connection manager is running
      then we keep using the existing 5000 ms.
      
      To implement this we move the control channel allocation to
      tb_domain_alloc(), and pass the timeout from that function to the
      tb_ctl_alloc(). Then make both connection manager implementations pass
      the timeout when they alloc the domain structure.
      
      While there update kernel-doc of struct tb_ctl to match the reality.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      7f0a34d7
  8. 04 Feb, 2021 1 commit
  9. 28 Jan, 2021 1 commit
  10. 07 Jan, 2021 1 commit
  11. 30 Nov, 2020 5 commits
  12. 19 Nov, 2020 1 commit
    • Mika Westerberg's avatar
      thunderbolt: Fix use-after-free in remove_unplugged_switch() · 600c0849
      Mika Westerberg authored
      Paulian reported a crash that happens when a dock is unplugged during
      hibernation:
      
      [78436.228217] thunderbolt 0-1: device disconnected
      [78436.228365] BUG: kernel NULL pointer dereference, address: 00000000000001e0
      ...
      [78436.228397] RIP: 0010:icm_free_unplugged_children+0x109/0x1a0
      ...
      [78436.228432] Call Trace:
      [78436.228439]  icm_rescan_work+0x24/0x30
      [78436.228444]  process_one_work+0x1a3/0x3a0
      [78436.228449]  worker_thread+0x30/0x370
      [78436.228454]  ? process_one_work+0x3a0/0x3a0
      [78436.228457]  kthread+0x13d/0x160
      [78436.228461]  ? kthread_park+0x90/0x90
      [78436.228465]  ret_from_fork+0x1f/0x30
      
      This happens because remove_unplugged_switch() calls tb_switch_remove()
      that releases the memory pointed by sw so the following lines reference
      to a memory that might be released already.
      
      Fix this by saving pointer to the parent device before calling
      tb_switch_remove().
      Reported-by: default avatarPaulian Bogdan Marinca <paulian@marinca.net>
      Fixes: 4f7c2e0d ("thunderbolt: Make sure device runtime resume completes before taking domain lock")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      600c0849
  13. 06 Nov, 2020 1 commit
  14. 03 Sep, 2020 1 commit
  15. 23 Apr, 2020 1 commit
  16. 14 Feb, 2020 1 commit
  17. 02 Nov, 2019 2 commits
    • Mika Westerberg's avatar
      thunderbolt: Do not start firmware unless asked by the user · 354a7a77
      Mika Westerberg authored
      Since now we can do pretty much the same thing in the software
      connection manager than the firmware would do, there is no point
      starting it by default. Instead we can just continue using the software
      connection manager.
      
      Make it possible for user to switch between the two by adding a module
      pararameter (start_icm) which is by default false. Having this ability
      to enable the firmware may be useful at least when debugging possible
      issues with the software connection manager implementation.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      354a7a77
    • Mika Westerberg's avatar
      thunderbolt: Add support for lane bonding · 91c0c120
      Mika Westerberg authored
      Lane bonding allows aggregating two 10/20 Gb/s (depending on the
      generation) lanes into a single 20/40 Gb/s bonded link. This allows
      sharing the full bandwidth more efficiently. In order to establish lane
      bonding we need to check that lane bonding is possible through link
      controller and that both ends of the link actually supports 2x widths.
      This also means that all the paths should be established through the
      primary port so update tb_path_alloc() to handle this as well.
      
      Lane bonding is supported starting from Falcon Ridge (2nd generation)
      controllers.
      
      We also expose the current speed and number of lanes under each device
      except the host router following similar attribute naming than USB bus.
      Expose speed and number of lanes for both directions to allow possibility
      of asymmetric link in the future.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      91c0c120
  18. 01 Nov, 2019 2 commits
  19. 26 Aug, 2019 2 commits
  20. 14 Jun, 2019 1 commit
  21. 12 Jun, 2019 1 commit
    • Mika Westerberg's avatar
      thunderbolt: Make sure device runtime resume completes before taking domain lock · 4f7c2e0d
      Mika Westerberg authored
      When a device is authorized from userspace by writing to authorized
      attribute we first take the domain lock and then runtime resume the
      device in question. There are two issues with this.
      
      First is that the device connected notifications are blocked during this
      time which means we get them only after the authorization operation is
      complete. Because of this the authorization needed flag from the
      firmware notification is not reflecting the real authorization status
      anymore. So what happens is that the "authorized" keeps returning 0 even
      if the device was already authorized properly.
      
      Second issue is that each time the controller is runtime resumed the
      connection_id field of device connected notification may be different
      than in the previous resume. We need to use the latest connection_id
      otherwise the firmware rejects the authorization command.
      
      Fix these by moving runtime resume operations to happen before the
      domain lock is taken, and waiting for the updated device connected
      notification from the firmware before we allow runtime resume of a
      device to complete.
      
      While there add missing locking to tb_switch_nvm_read().
      
      Fixes: 09f11b6c ("thunderbolt: Take domain lock in switch sysfs attribute callbacks")
      Reported-by: default avatarPengfei Xu <pengfei.xu@intel.com>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      4f7c2e0d
  22. 18 Apr, 2019 6 commits
  23. 28 Mar, 2019 1 commit
  24. 02 Oct, 2018 2 commits
  25. 25 Jul, 2018 1 commit
    • Mika Westerberg's avatar
      thunderbolt: Add support for runtime PM · 2d8ff0b5
      Mika Westerberg authored
      When Thunderbolt host controller is set to RTD3 mode (Runtime D3) it is
      present all the time. Because of this it is important to runtime suspend
      the controller whenever possible. In case of ICM we have following rules
      which all needs to be true before the host controller can be put to D3:
      
        - The controller firmware reports to support RTD3
        - All the connected devices announce support for RTD3
        - There is no active XDomain connection
      
      Implement this using standard Linux runtime PM APIs so that when all the
      children devices are runtime suspended, the Thunderbolt host controller
      PCI device is runtime suspended as well. The ICM firmware then starts
      powering down power domains towards RTD3 but it can prevent this if it
      detects that there is an active Display Port stream (this is not visible
      to the software, though).
      
      The Thunderbolt host controller will be runtime resumed either when
      there is a remote wake event (device is connected or disconnected), or
      when there is access from userspace that requires hardware access.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d8ff0b5