16 Sep, 2020

1 commit

  • If the USB4 router downstream port is locked, sending configuration
    packet to a router below it causes ERR_LOCK to be sent. Instead of warn
    splat about unknown error we log the error (just warning level) and
    return -EACCESS instead. The idea is that we may want to do something
    when such error code is received, like perform unlock.

    Signed-off-by: Mika Westerberg

    Mika Westerberg
     

18 Dec, 2019

1 commit

  • USB4 1.0 section 6.4.2.7 specifies a new field (PG) in notification
    packet that is sent as response of hot plug/unplug events. This field
    tells whether the acknowledgment is for plug or unplug event. This needs
    to be set accordingly in order the router to send further hot plug
    notifications.

    To make it simpler we fill the field unconditionally. Legacy devices do
    not look at this field so there should be no problems with them.

    While there rename tb_cfg_error() to tb_cfg_ack_plug() and update the
    log message accordingly. The function is only used to ack plug/unplug
    events.

    Signed-off-by: Mika Westerberg
    Link: https://lore.kernel.org/r/20191217123345.31850-4-mika.westerberg@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman

    Mika Westerberg
     

02 Nov, 2019

1 commit

  • 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: Mika Westerberg

    Mika Westerberg
     

26 Aug, 2019

1 commit

  • The Thunderbolt controller is integrated into the Ice Lake CPU itself
    and requires special flows to power it on and off using force power bit
    in NHI VSEC registers. Runtime PM (RTD3) and Sx flows also differ from
    the discrete solutions. Now the firmware notifies the driver whether
    RTD3 entry or exit are possible. The driver is responsible of sending
    Go2Sx command through link controller mailbox when system enters Sx
    states (suspend-to-mem/disk). Rest of the ICM firwmare flows follow
    Titan Ridge.

    Signed-off-by: Raanan Avargil
    Signed-off-by: Mika Westerberg
    Reviewed-by: Yehezkel Bernat
    Tested-by: Mario Limonciello

    Mika Westerberg
     

18 Apr, 2019

1 commit

  • Currently ICM has been handling XDomain UUID exchange so there was no
    need to have it in the driver yet. However, since now we are going to
    add the same capabilities to the software connection manager it needs to
    be handled properly.

    For this reason modify the driver XDomain protocol handling so that if
    the remote domain UUID is not filled in the core will query it first and
    only then start the normal property exchange flow.

    Signed-off-by: Mika Westerberg

    Mika Westerberg
     

03 Oct, 2018

1 commit


25 Jul, 2018

1 commit

  • 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: Mika Westerberg
    Signed-off-by: Greg Kroah-Hartman

    Mika Westerberg
     

09 Mar, 2018

5 commits

  • Intel Titan Ridge is the next Thunderbolt 3 controller. The ICM firmware
    message format in Titan Ridge differs from Falcon Ridge and Alpine Ridge
    somewhat because it is using route strings addressing devices. In
    addition to that the DMA port of 4-channel (two port) controller is in
    different port number than the previous controllers. There are some
    other minor differences as well.

    This patch add support for Intel Titan Ridge and the new ICM firmware
    message format.

    Signed-off-by: Radion Mirchevsky
    Signed-off-by: Mika Westerberg
    Reviewed-by: Andy Shevchenko

    Radion Mirchevsky
     
  • Preboot ACL is a mechanism that allows connecting Thunderbolt devices
    boot time in more secure way than the legacy Thunderbolt boot support.
    As with the legacy boot option, this also needs to be enabled from the
    BIOS before booting is allowed. Difference to the legacy mode is that
    the userspace software explicitly adds device UUIDs by sending a special
    message to the ICM firmware. Only the devices listed in the boot ACL are
    connected automatically during the boot. This works in both "user" and
    "secure" security levels.

    We implement this in Linux by exposing a new sysfs attribute (boot_acl)
    below each Thunderbolt domain. The userspace software can then update
    the full list as needed.

    Signed-off-by: Mika Westerberg
    Reviewed-by: Andy Shevchenko

    Mika Westerberg
     
  • In various cases, Thunderbolt device can be connected by ICM on boot
    without waiting for approval from user. Most cases are related to
    OEM-specific BIOS configurations. This information is interesting for
    user-space as if the device isn't in SW ACL, it may create a friction in
    the user experience where the device is automatically authorized if it's
    connected on boot but requires an explicit user action if connected
    after OS is up. User-space can use this information to suggest adding
    the device to SW ACL for auto-authorization on later connections.

    Signed-off-by: Yehezkel Bernat
    Signed-off-by: Mika Westerberg
    Reviewed-by: Andy Shevchenko

    Yehezkel Bernat
     
  • Intel Titan Ridge uses slightly different format for ICM driver ready
    response, so add a new ->driver_ready() callback to struct icm and move
    the existing handling to a separate function which we then use in Falcon
    Ridge and Alpine Ridge.

    No functional changes intended.

    Signed-off-by: Mika Westerberg
    Reviewed-by: Andy Shevchenko

    Mika Westerberg
     
  • The ICM firmware rejects devices if the maximum topology limit is
    exceeded (more than 6 devices are connected). If that happens just log a
    message to the kernel message buffer and bail out.

    Signed-off-by: Mika Westerberg
    Reviewed-by: Andy Shevchenko

    Mika Westerberg
     

03 Oct, 2017

3 commits

  • When two hosts are connected over a Thunderbolt cable, there is a
    protocol they can use to communicate capabilities supported by the host.
    The discovery protocol uses automatically configured control channel
    (ring 0) and is build on top of request/response transactions using
    special XDomain primitives provided by the Thunderbolt base protocol.

    The capabilities consists of a root directory block of basic properties
    used for identification of the host, and then there can be zero or more
    directories each describing a Thunderbolt service and its capabilities.

    Once both sides have discovered what is supported the two hosts can
    setup high-speed DMA paths and transfer data to the other side using
    whatever protocol was agreed based on the properties. The software
    protocol used to communicate which DMA paths to enable is service
    specific.

    This patch adds support for the XDomain discovery protocol to the
    Thunderbolt bus. We model each remote host connection as a Linux XDomain
    device. For each Thunderbolt service found supported on the XDomain
    device, we create Linux Thunderbolt service device which Thunderbolt
    service drivers can then bind to based on the protocol identification
    information retrieved from the property directory describing the
    service.

    This code is based on the work done by Amir Levy and Michael Jamet.

    Signed-off-by: Michael Jamet
    Signed-off-by: Mika Westerberg
    Reviewed-by: Yehezkel Bernat
    Reviewed-by: Andy Shevchenko
    Signed-off-by: David S. Miller

    Mika Westerberg
     
  • These will be needed by Thunderbolt services when sending and receiving
    XDomain control messages. While there change TB_CFG_PKG_PREPARE_TO_SLEEP
    value to be decimal in order to be consistent with other members.

    Signed-off-by: Mika Westerberg
    Reviewed-by: Michael Jamet
    Reviewed-by: Yehezkel Bernat
    Reviewed-by: Andy Shevchenko
    Signed-off-by: David S. Miller

    Mika Westerberg
     
  • These messages are all 32-bit aligned and they should be packed without
    the __packed attribute just fine. It also allows compiler to generate
    better code on some architectures.

    Signed-off-by: Mika Westerberg
    Reviewed-by: Michael Jamet
    Reviewed-by: Yehezkel Bernat
    Reviewed-by: Andy Shevchenko
    Signed-off-by: David S. Miller

    Mika Westerberg
     

24 Jul, 2017

1 commit


09 Jun, 2017

2 commits

  • Starting from Intel Falcon Ridge the internal connection manager running
    on the Thunderbolt host controller has been supporting 4 security
    levels. One reason for this is to prevent DMA attacks and only allow
    connecting devices the user trusts.

    The internal connection manager (ICM) is the preferred way of connecting
    Thunderbolt devices over software only implementation typically used on
    Macs. The driver communicates with ICM using special Thunderbolt ring 0
    (control channel) messages. In order to handle these messages we add
    support for the ICM messages to the control channel.

    The security levels are as follows:

    none - No security, all tunnels are created automatically
    user - User needs to approve the device before tunnels are created
    secure - User need to approve the device before tunnels are created.
    The device is sent a challenge on future connects to be able
    to verify it is actually the approved device.
    dponly - Only Display Port and USB tunnels can be created and those
    are created automatically.

    The security levels are typically configurable from the system BIOS and
    by default it is set to "user" on many systems.

    In this patch each Thunderbolt device will have either one or two new
    sysfs attributes: authorized and key. The latter appears for devices
    that support secure connect.

    In order to identify the device the user can read identication
    information, including UUID and name of the device from sysfs and based
    on that make a decision to authorize the device. The device is
    authorized by simply writing 1 to the "authorized" sysfs attribute. This
    is following the USB bus device authorization mechanism. The secure
    connect requires an additional challenge step (writing 2 to the
    "authorized" attribute) in future connects when the key has already been
    stored to the NVM of the device.

    Non-ICM systems (before Alpine Ridge) continue to use the existing
    functionality and the security level is set to none. For systems with
    Alpine Ridge, even on Apple hardware, we will use ICM.

    This code is based on the work done by Amir Levy and Michael Jamet.

    Signed-off-by: Michael Jamet
    Signed-off-by: Mika Westerberg
    Reviewed-by: Yehezkel Bernat
    Reviewed-by: Andy Shevchenko
    Signed-off-by: Andreas Noever
    Signed-off-by: Greg Kroah-Hartman

    Mika Westerberg
     
  • We will be forwarding notifications received from the control channel to
    the connection manager implementations. This way they can decide what to
    do if anything when a notification is received.

    To be able to use control channel messages from other files, move them
    to tb_msgs.h.

    No functional changes intended.

    Signed-off-by: Mika Westerberg
    Reviewed-by: Yehezkel Bernat
    Reviewed-by: Michael Jamet
    Reviewed-by: Andy Shevchenko
    Signed-off-by: Andreas Noever
    Signed-off-by: Greg Kroah-Hartman

    Mika Westerberg