An error occurred fetching the project authors.
  1. 18 Dec, 2019 2 commits
  2. 19 Nov, 2019 1 commit
  3. 02 Nov, 2019 3 commits
    • Mika Westerberg's avatar
      thunderbolt: Add Display Port adapter pairing and resource management · 8afe909b
      Mika Westerberg authored
      To perform proper Display Port tunneling for Thunderbolt 3 devices we
      need to allocate DP resources for DP IN port before they can be used.
      The reason for this is that the user can also connect a monitor directly
      to the Type-C ports in which case the Thunderbolt controller acts as
      re-driver for Display Port (no tunneling takes place) taking the DP
      sinks away from the connection manager. This allocation is done using
      special sink allocation registers available through the link controller.
      
      We can pair DP IN to DP OUT only if
      
       * DP IN has sink allocated via link controller
       * DP OUT port receives hotplug event
      
      For DP IN adapters (only for the host router) we first query whether
      there is DP resource available (it may be the previous instance of the
      driver for example already allocated it) and if it is we add it to the
      list. We then update the list when after each plug/unplug event to a DP
      IN/OUT adapter. Each time the list is updated we try to find additional
      DP IN <-> DP OUT pairs for tunnel establishment. This strategy also
      makes it possible to establish another tunnel in case there are 3
      monitors connected and one gets unplugged releasing the DP IN adapter
      for the new tunnel.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      8afe909b
    • Mika Westerberg's avatar
      thunderbolt: Add default linking between lane adapters if not provided by DROM · 0d46c08d
      Mika Westerberg authored
      We currently read how sibling lane adapter ports relate each other from
      DROM (Device ROM). If the two lane adapter ports go through the same
      physical connector these lanes can then be bonded together. However,
      some cases DROM does not provide this information or it is missing
      completely (host routers typically do not have DROM). In this case we
      have hard-coded the relationship.
      
      Expand this to work with both legacy devices where lane adapter ports 1
      and 2, and 3 and 4 are always linked together, and with USB4 devices
      where lane adapter 1 is always following lane adapter 0 or is disabled
      completely (see USB4 section 5.2.1 for more information).
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      0d46c08d
    • 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
  4. 01 Nov, 2019 6 commits
  5. 09 Oct, 2019 1 commit
  6. 08 Oct, 2019 2 commits
    • Mika Westerberg's avatar
      thunderbolt: Fix lockdep circular locking depedency warning · 6f670973
      Mika Westerberg authored
      When lockdep is enabled, plugging Thunderbolt dock on Dominik's laptop
      triggers following splat:
      
        ======================================================
        WARNING: possible circular locking dependency detected
        5.3.0-rc6+ #1 Tainted: G                T
        ------------------------------------------------------
        pool-/usr/lib/b/1258 is trying to acquire lock:
        000000005ab0ad43 (pci_rescan_remove_lock){+.+.}, at: authorized_store+0xe8/0x210
      
        but task is already holding lock:
        00000000bfb796b5 (&tb->lock){+.+.}, at: authorized_store+0x7c/0x210
      
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
      
        -> #1 (&tb->lock){+.+.}:
               __mutex_lock+0xac/0x9a0
               tb_domain_add+0x2d/0x130
               nhi_probe+0x1dd/0x330
               pci_device_probe+0xd2/0x150
               really_probe+0xee/0x280
               driver_probe_device+0x50/0xc0
               bus_for_each_drv+0x84/0xd0
               __device_attach+0xe4/0x150
               pci_bus_add_device+0x4e/0x70
               pci_bus_add_devices+0x2e/0x66
               pci_bus_add_devices+0x59/0x66
               pci_bus_add_devices+0x59/0x66
               enable_slot+0x344/0x450
               acpiphp_check_bridge.part.0+0x119/0x150
               acpiphp_hotplug_notify+0xaa/0x140
               acpi_device_hotplug+0xa2/0x3f0
               acpi_hotplug_work_fn+0x1a/0x30
               process_one_work+0x234/0x580
               worker_thread+0x50/0x3b0
               kthread+0x10a/0x140
               ret_from_fork+0x3a/0x50
      
        -> #0 (pci_rescan_remove_lock){+.+.}:
               __lock_acquire+0xe54/0x1ac0
               lock_acquire+0xb8/0x1b0
               __mutex_lock+0xac/0x9a0
               authorized_store+0xe8/0x210
               kernfs_fop_write+0x125/0x1b0
               vfs_write+0xc2/0x1d0
               ksys_write+0x6c/0xf0
               do_syscall_64+0x50/0x180
               entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
        other info that might help us debug this:
         Possible unsafe locking scenario:
               CPU0                    CPU1
               ----                    ----
          lock(&tb->lock);
                                       lock(pci_rescan_remove_lock);
                                       lock(&tb->lock);
          lock(pci_rescan_remove_lock);
      
         *** DEADLOCK ***
        5 locks held by pool-/usr/lib/b/1258:
         #0: 000000003df1a1ad (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x4d/0x60
         #1: 0000000095a40b02 (sb_writers#6){.+.+}, at: vfs_write+0x185/0x1d0
         #2: 0000000017a7d714 (&of->mutex){+.+.}, at: kernfs_fop_write+0xf2/0x1b0
         #3: 000000004f262981 (kn->count#208){.+.+}, at: kernfs_fop_write+0xfa/0x1b0
         #4: 00000000bfb796b5 (&tb->lock){+.+.}, at: authorized_store+0x7c/0x210
      
        stack backtrace:
        CPU: 0 PID: 1258 Comm: pool-/usr/lib/b Tainted: G                T 5.3.0-rc6+ #1
      
      On an system using ACPI hotplug the host router gets hotplugged first and then
      the firmware starts sending notifications about connected devices so the above
      scenario should not happen in reality. However, after taking a second
      look at commit a03e8289 ("thunderbolt: Serialize PCIe tunnel
      creation with PCI rescan") that introduced the locking, I don't think it
      is actually correct. It may have cured the symptom but probably the real
      root cause was somewhere closer to PCI stack and possibly is already
      fixed with recent kernels. I also tried to reproduce the original issue
      with the commit reverted but could not.
      
      So to keep lockdep happy and the code bit less complex drop calls to
      pci_lock_rescan_remove()/pci_unlock_rescan_remove() in
      tb_switch_set_authorized() effectively reverting a03e8289.
      
      Link: https://lkml.org/lkml/2019/8/30/513
      Fixes: a03e8289 ("thunderbolt: Serialize PCIe tunnel creation with PCI rescan")
      Reported-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      6f670973
    • Mika Westerberg's avatar
      thunderbolt: Read DP IN adapter first two dwords in one go · fd5c46b7
      Mika Westerberg authored
      When we discover existing DP tunnels the code checks whether DP IN
      adapter port is enabled by calling tb_dp_port_is_enabled() before it
      continues the discovery process. On Light Ridge (gen 1) controller
      reading only the first dword of the DP IN config space causes subsequent
      access to the same DP IN port path config space to fail or return
      invalid data as can be seen in the below splat:
      
        thunderbolt 0000:07:00.0: CFG_ERROR(0:d): Invalid config space or offset
        Call Trace:
         tb_cfg_read+0xb9/0xd0
         __tb_path_deactivate_hop+0x98/0x210
         tb_path_activate+0x228/0x7d0
         tb_tunnel_restart+0x95/0x200
         tb_handle_hotplug+0x30e/0x630
         process_one_work+0x1b4/0x340
         worker_thread+0x44/0x3d0
         kthread+0xeb/0x120
         ? process_one_work+0x340/0x340
         ? kthread_park+0xa0/0xa0
         ret_from_fork+0x1f/0x30
      
      If both DP In adapter config dwords are read in one go the issue does
      not reproduce. This is likely firmware bug but we can work it around by
      always reading the two dwords in one go. There should be no harm for
      other controllers either so can do it unconditionally.
      
      Link: https://lkml.org/lkml/2019/8/28/160Reported-by: default avatarBrad Campbell <lists2009@fnarfbargle.com>
      Tested-by: default avatarBrad Campbell <lists2009@fnarfbargle.com>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      fd5c46b7
  7. 26 Aug, 2019 4 commits
  8. 24 Jun, 2019 1 commit
    • Suzuki K Poulose's avatar
      bus_find_device: Unify the match callback with class_find_device · 418e3ea1
      Suzuki K Poulose authored
      There is an arbitrary difference between the prototypes of
      bus_find_device() and class_find_device() preventing their callers
      from passing the same pair of data and match() arguments to both of
      them, which is the const qualifier used in the prototype of
      class_find_device().  If that qualifier is also used in the
      bus_find_device() prototype, it will be possible to pass the same
      match() callback function to both bus_find_device() and
      class_find_device(), which will allow some optimizations to be made in
      order to avoid code duplication going forward.  Also with that, constify
      the "data" parameter as it is passed as a const to the match function.
      
      For this reason, change the prototype of bus_find_device() to match
      the prototype of class_find_device() and adjust its callers to use the
      const qualifier in accordance with the new prototype of it.
      
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Andreas Noever <andreas.noever@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Corey Minyard <minyard@acm.org>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: David Kershner <david.kershner@unisys.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Harald Freudenberger <freude@linux.ibm.com>
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Heiko Stuebner <heiko@sntech.de>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michael Jamet <michael.jamet@intel.com>
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: Peter Oberparleiter <oberpar@linux.ibm.com>
      Cc: Sebastian Ott <sebott@linux.ibm.com>
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Cc: Yehezkel Bernat <YehezkelShB@gmail.com>
      Cc: rafael@kernel.org
      Acked-by: default avatarCorey Minyard <minyard@acm.org>
      Acked-by: default avatarDavid Kershner <david.kershner@unisys.com>
      Acked-by: default avatarMark Brown <broonie@kernel.org>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Acked-by: Wolfram Sang <wsa@the-dreams.de> # for the I2C parts
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      418e3ea1
  9. 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
  10. 18 Apr, 2019 19 commits