thunderbolt: Add trace events support for the control channel

Sometimes it is useful to see the traffic happening inside the control
channel, especially when debugging a possible problem. This adds

thunderbolt: Add trace events support for the control channel

Sometimes it is useful to see the traffic happening inside the control
channel, especially when debugging a possible problem. This adds
tracepoints close to the hardware which can be enabled dynamically as
needed using the standard Linux trace events facility.

Signed-off-by: Gil Fine <[email protected]>
Co-developed-by: Mika Westerberg <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>

show more ...

thunderbolt: Move CLx support functions into clx.c

There really don't belong to switch.c so move them into their own file.
As we do this rename the functions to match the conventions used
elsewhere

thunderbolt: Move CLx support functions into clx.c

There really don't belong to switch.c so move them into their own file.
As we do this rename the functions to match the conventions used
elsewhere in the driver.

No functional changes.

Signed-off-by: Mika Westerberg <[email protected]>

show more ...

thunderbolt: build kunit tests without structleak plugin

The structleak plugin causes the stack frame size to grow immensely when
used with KUnit:

drivers/thunderbolt/test.c:1529:1: error: the fram

thunderbolt: build kunit tests without structleak plugin

The structleak plugin causes the stack frame size to grow immensely when
used with KUnit:

drivers/thunderbolt/test.c:1529:1: error: the frame size of 1176 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

Turn it off in this file.

Linus already split up tests in this file, so this change *should* be
redundant now.

Signed-off-by: Brendan Higgins <[email protected]>
Suggested-by: Arnd Bergmann <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

thunderbolt: Add USB4 port devices

Create devices for each USB4 port. This is needed when we add retimer
access when there is no device connected but may be useful for other
purposes too following w

thunderbolt: Add USB4 port devices

Create devices for each USB4 port. This is needed when we add retimer
access when there is no device connected but may be useful for other
purposes too following what USB subsystem does. This exports a single
attribute "link" that shows the type of the USB4 link (or "none" if
there is no cable connected).

Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>

show more ...

thunderbolt: Add DMA traffic test driver

This driver allows sending DMA traffic over XDomain connection.
Specifically over a loopback connection using either a Thunderbolt/USB4
cable that is connect

thunderbolt: Add DMA traffic test driver

This driver allows sending DMA traffic over XDomain connection.
Specifically over a loopback connection using either a Thunderbolt/USB4
cable that is connected back to the host router port, or a special
loopback dongle that has RX and TX lines crossed. This can be useful at
manufacturing floor to check whether Thunderbolt/USB4 ports are
functional.

The driver exposes debugfs directory under the XDomain service that can
be used to configure the driver, start the test and check the results.

If a loopback dongle is used the steps to send and receive 1000 packets
can be done like:

# modprobe thunderbolt_dma_test
# echo 1000 > /sys/kernel/debug/thunderbolt/<service_id>/dma_test/packets_to_receive
# echo 1000 > /sys/kernel/debug/thunderbolt/<service_id>/dma_test/packets_to_send
# echo 1 > /sys/kernel/debug/thunderbolt/<service_id>/dma_test/test
# cat /sys/kernel/debug/thunderbolt/<service_id>/dma_test/status

When a cable is connected back to host then there are two Thunderbolt
services, one is configured for receiving (does not matter which one):

# modprobe thunderbolt_dma_test
# echo 1000 > /sys/kernel/debug/thunderbolt/<service_a>/dma_test/packets_to_receive
# echo 1 > /sys/kernel/debug/thunderbolt/<service_a>/dma_test/test

The other one for sending:

# echo 1000 > /sys/kernel/debug/thunderbolt/<service_b>/dma_test/packets_to_send
# echo 1 > /sys/kernel/debug/thunderbolt/<service_b>/dma_test/test

Results can be read from both services status attributes.

Signed-off-by: Isaac Hazan <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
Acked-by: Yehezkel Bernat <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>

show more ...

thunderbolt: Allow KUnit tests to be built also when CONFIG_USB4=m

This adds a bit more build coverage for the tests even though these are
not expected to be enabled by normal users and distros. In

thunderbolt: Allow KUnit tests to be built also when CONFIG_USB4=m

This adds a bit more build coverage for the tests even though these are
not expected to be enabled by normal users and distros. In order to make
this working we need to open-code kunit_test_suite() and call the
relevant functions directly in the driver init/exit hook.

Signed-off-by: Mika Westerberg <[email protected]>

show more ...

thunderbolt: Add debugfs interface

This adds debugfs interface that can be used for debugging possible
issues in hardware/software. It exposes router and adapter config spaces
through files like thi

thunderbolt: Add debugfs interface

This adds debugfs interface that can be used for debugging possible
issues in hardware/software. It exposes router and adapter config spaces
through files like this:

/sys/kernel/debug/thunderbolt/<DEVICE>/regs
/sys/kernel/debug/thunderbolt/<DEVICE>/<PORT1>/regs
/sys/kernel/debug/thunderbolt/<DEVICE>/<PORT1>/path
/sys/kernel/debug/thunderbolt/<DEVICE>/<PORT1>/counters
/sys/kernel/debug/thunderbolt/<DEVICE>/<PORT2>/regs
/sys/kernel/debug/thunderbolt/<DEVICE>/<PORT2>/path
/sys/kernel/debug/thunderbolt/<DEVICE>/<PORT2>/counters
...

The "regs" is either the router or port configuration space register
dump. The "path" is the port path configuration space and "counters" is
the optional counters configuration space.

These files contains one register per line so it should be easy to use
normal filtering tools to find the registers of interest if needed.

The router and adapter regs file becomes writable when
CONFIG_USB4_DEBUGFS_WRITE is enabled (which is not supposed to be done
in production systems) and in this case the developer can write "offset
value" lines there to modify the hardware directly. For convenience this
also supports the long format the read side produces (but ignores the
additional fields). The counters file can be written even when
CONFIG_USB4_DEBUGFS_WRITE is not enabled and it is only used to clear
the counter values.

Signed-off-by: Gil Fine <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>

show more ...

thunderbolt: Create device links from ACPI description

The new way to describe relationship between tunneled ports and USB4 NHI
(Native Host Interface) is with ACPI _DSD looking like below for a PCI

thunderbolt: Create device links from ACPI description

The new way to describe relationship between tunneled ports and USB4 NHI
(Native Host Interface) is with ACPI _DSD looking like below for a PCIe
downstream port:

Scope (\_SB.PCI0)
{
Device (NHI0) { } // Thunderbolt NHI

Device (DSB0) // Hotplug downstream port
{
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"usb4-host-interface", \_SB.PCI0.NHI0},
...
}
})
}
}

This is "documented" in these [1] USB-IF slides and being used on
systems that ship with Windows.

The _DSD can be added to tunneled USB3 and PCIe ports, and is needed to
make sure the USB4 NHI is resumed before any of the tunneled ports so
the protocol tunnels get established properly before the actual port
itself is resumed. Othwerwise the USB/PCI core find the link may not be
established and starts tearing down the device stack.

This parses the ACPI description each time NHI is probed and tries to
find devices that has the property and it references the NHI in
question. For each matching device a device link from that device to the
NHI is created.

Since USB3 ports themselves do not get runtime suspended with the parent
device (hub) we do not add the link from the USB3 port to USB4 NHI but
instead we add the link from the xHCI device. This makes the device link
usable for runtime PM as well.

[1] https://www.usb.org/sites/default/files/D1T2-2%20-%20USB4%20on%20Windows.pdf

Signed-off-by: Mika Westerberg <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>

show more ...

thunderbolt: Add support for authenticate on disconnect

Some external devices can support completing thunderbolt authentication
when they are unplugged. For this to work though, the link controller

thunderbolt: Add support for authenticate on disconnect

Some external devices can support completing thunderbolt authentication
when they are unplugged. For this to work though, the link controller must
remain operational.

The only device known to support this right now is the Dell WD19TB, so add
a quirk for this.

Signed-off-by: Mario Limonciello <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>

show more ...

thunderbolt: Add support for on-board retimers

USB4 spec specifies standard access to retimers (both on-board and
cable) through USB4 port sideband access. This makes it possible to
upgrade their fi

thunderbolt: Add support for on-board retimers

USB4 spec specifies standard access to retimers (both on-board and
cable) through USB4 port sideband access. This makes it possible to
upgrade their firmware in the same way than we already do with the
routers.

This enumerates on-board retimers under each USB4 port when the link
comes up and adds them to the bus under the router the retimer belongs
to. Retimers are exposed in sysfs with name like <device>:<port>.<index>
where device is the router the retimer belongs to, port is the USB4 port
the retimer is connected to and index is the retimer index under that
port (starting from 1). This applies to the upstream USB4 port as well
so if there is on-board retimer between the port and the router it is
also added accordingly.

At this time we do not add cable retimers but there is no techincal
restriction to do so in the future if needed. It is not clear whether it
makes sense to upgrade their firmwares and at least Thunderbolt 3 cables
it has not been done outside of lab environments.

The sysfs interface is made to follow the router NVM upgrade to make it
easy to extend the existing userspace (fwupd) to handle these as well.

Signed-off-by: Kranthi Kuntala <[email protected]>
Co-developed-by: Mika Westerberg <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>

show more ...

thunderbolt: Split common NVM functionality into a separate file

We are going to reuse some of this functionality to implement retimer
NVM upgrade so move common NVM functionality into its own file.

thunderbolt: Split common NVM functionality into a separate file

We are going to reuse some of this functionality to implement retimer
NVM upgrade so move common NVM functionality into its own file. We also
rename the structure from tb_switch_nvm to tb_nvm to make it clear that
it is not just for switches.

Signed-off-by: Mika Westerberg <[email protected]>

show more ...

thunderbolt: Add KUnit tests for path walking

This adds KUnit tests for path walking which is only dependent on
software structures, so no hardware is needed to run these.

We make these available o

thunderbolt: Add KUnit tests for path walking

This adds KUnit tests for path walking which is only dependent on
software structures, so no hardware is needed to run these.

We make these available only when both KUnit and the driver itself are
built into the kernel image. The reason for this is that KUnit adds its
own module_init() call in kunit_test_suite() which generates linker
error because the driver does the same in nhi.c. This should be fine for
now because these tests are only meant to run by developers anyway.

Signed-off-by: Mika Westerberg <[email protected]>

show more ...

thunderbolt: Add support for Time Management Unit

Time Management Unit (TMU) is included in each USB4 router. It is used
to synchronize time across the USB4 fabric. By default when USB4 router
is pl

thunderbolt: Add support for Time Management Unit

Time Management Unit (TMU) is included in each USB4 router. It is used
to synchronize time across the USB4 fabric. By default when USB4 router
is plugged to the domain, its TMU is turned off. This differs from
Thunderbolt (1, 2 and 3) devices whose TMU is by default configured to
bi-directional HiFi mode. Since time synchronization is needed for
proper Display Port tunneling this means we need to configure the TMU on
USB4 compliant devices.

The USB4 spec allows some flexibility on how the TMU can be configured.
This makes it possible to enable link power management states (CLx) in
certain topologies, where for example DP tunneling is not used. TMU can
also be re-configured dynamicaly depending on types of tunnels created
over the USB4 fabric.

In this patch we simply configure the TMU to be in bi-directional HiFi
mode. This way we can tunnel any kind of traffic without need to perform
complex steps to re-configure the domain dynamically. We can add more
fine-grained TMU configuration later on when we start enabling CLx
states.

Signed-off-by: Rajmohan Mani <[email protected]>
Co-developed-by: Mika Westerberg <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

thunderbolt: Update Kconfig entries to USB4

Since the driver now supports USB4 which is the standard going forward,
update the Kconfig entry to mention this and rename the entry from
CONFIG_THUNDERB

thunderbolt: Update Kconfig entries to USB4

Since the driver now supports USB4 which is the standard going forward,
update the Kconfig entry to mention this and rename the entry from
CONFIG_THUNDERBOLT to CONFIG_USB4 instead to help people to find the
correct option if they want to enable USB4.

Also do the same for Thunderbolt network driver.

Signed-off-by: Mika Westerberg <[email protected]>
Cc: David S. Miller <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

thunderbolt: Add initial support for USB4

USB4 is the public specification based on Thunderbolt 3 protocol. There
are some differences in register layouts and flows. In addition to PCIe
and DP tunne

thunderbolt: Add initial support for USB4

USB4 is the public specification based on Thunderbolt 3 protocol. There
are some differences in register layouts and flows. In addition to PCIe
and DP tunneling, USB4 supports tunneling of USB 3.x. USB4 is also
backward compatible with Thunderbolt 3 (and older generations but the
spec only talks about 3rd generation). USB4 compliant devices can be
identified by checking USB4 version field in router configuration space.

This patch adds initial support for USB4 compliant hosts and devices
which enables following features provided by the existing functionality
in the driver:

- PCIe tunneling
- Display Port tunneling
- Host and device NVM firmware upgrade
- P2P networking

This brings the USB4 support to the same level that we already have for
Thunderbolt 1, 2 and 3 devices.

Note the spec talks about host and device "routers" but in the driver we
still use term "switch" in most places. Both can be used interchangeably.

Co-developed-by: Rajmohan Mani <[email protected]>
Signed-off-by: Rajmohan Mani <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

thunderbolt: Add support for Intel Ice Lake

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

thunderbolt: Add support for Intel Ice Lake

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 <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Yehezkel Bernat <[email protected]>
Tested-by: Mario Limonciello <[email protected]>

show more ...

treewide: Add SPDX license identifier - Makefile/Kconfig

Add SPDX license identifiers to all Make/Kconfig files which:

- Have no license information of any form

These files fall under the project

treewide: Add SPDX license identifier - Makefile/Kconfig

Add SPDX license identifiers to all Make/Kconfig files which:

- Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

GPL-2.0-only

Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

thunderbolt: Rename tunnel_pci to tunnel

In order to tunnel non-PCIe traffic as well rename tunnel_pci.[ch] to
tunnel.[ch] to reflect this fact. No functional changes.

Signed-off-by: Mika Westerber

thunderbolt: Rename tunnel_pci to tunnel

In order to tunnel non-PCIe traffic as well rename tunnel_pci.[ch] to
tunnel.[ch] to reflect this fact. No functional changes.

Signed-off-by: Mika Westerberg <[email protected]>

show more ...

thunderbolt: Move LC specific functionality into a separate file

We will be adding more link controller functionality in subsequent
patches and it does not make sense to keep all that in switch.c, s

thunderbolt: Move LC specific functionality into a separate file

We will be adding more link controller functionality in subsequent
patches and it does not make sense to keep all that in switch.c, so
separate LC functionality into its own file.

Signed-off-by: Mika Westerberg <[email protected]>

show more ...

thunderbolt: Add support for XDomain discovery protocol

When two hosts are connected over a Thunderbolt cable, there is a
protocol they can use to communicate capabilities supported by the host.
The

thunderbolt: Add support for XDomain discovery protocol

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 <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Yehezkel Bernat <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

thunderbolt: Add support for XDomain properties

Thunderbolt XDomain discovery protocol uses directories which contain
properties and other directories to exchange information about what
capabilities

thunderbolt: Add support for XDomain properties

Thunderbolt XDomain discovery protocol uses directories which contain
properties and other directories to exchange information about what
capabilities the remote host supports. This also includes identification
information like device ID and name.

This adds support for parsing and formatting these properties and
establishes an API drivers can use in addition to the core Thunderbolt
driver. This API is exposed in a new header: include/linux/thunderbolt.h.

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

Signed-off-by: Michael Jamet <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Yehezkel Bernat <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

thunderbolt: Add support for Internal Connection Manager (ICM)

Starting from Intel Falcon Ridge the internal connection manager running
on the Thunderbolt host controller has been supporting 4 secur

thunderbolt: Add support for Internal Connection Manager (ICM)

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 <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Yehezkel Bernat <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Andreas Noever <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

thunderbolt: Add support for DMA configuration based mailbox

The DMA (NHI) port of a switch provides access to the NVM of the host
controller (and devices starting from Intel Alpine Ridge). The NVM

thunderbolt: Add support for DMA configuration based mailbox

The DMA (NHI) port of a switch provides access to the NVM of the host
controller (and devices starting from Intel Alpine Ridge). The NVM
contains also more complete DROM for the root switch including vendor
and device identification strings.

This will look for the DMA port capability for each switch and if found
populates sw->dma_port. We then teach tb_drom_read() to read the DROM
information from NVM if available for the root switch.

The DMA port capability also supports upgrading the NVM for both host
controller and devices which will be added in subsequent patches.

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

Signed-off-by: Michael Jamet <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Yehezkel Bernat <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Andreas Noever <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

thunderbolt: Introduce thunderbolt bus and connection manager

Thunderbolt fabric consists of one or more switches. This fabric is
called domain and it is controlled by an entity called connection
ma

thunderbolt: Introduce thunderbolt bus and connection manager

Thunderbolt fabric consists of one or more switches. This fabric is
called domain and it is controlled by an entity called connection
manager. The connection manager can be either internal (driven by a
firmware running on the host controller) or external (software driver).
This driver currently implements support for the latter.

In order to manage switches and their properties more easily we model
this domain structure as a Linux bus. Each host controller adds a domain
device to this bus, and these devices are named as domainN where N
stands for index or id of the current domain.

We then abstract connection manager specific operations into a new
structure tb_cm_ops and convert the existing tb.c to fill those
accordingly. This makes it easier to add support for the internal
connection manager in subsequent patches.

Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Yehezkel Bernat <[email protected]>
Reviewed-by: Michael Jamet <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Andreas Noever <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

thunderbolt: Read switch uid from EEPROM

Add eeprom access code and read the uid during switch initialization.
The UID will be used to check device identity after suspend.

Signed-off-by: Andreas No

thunderbolt: Read switch uid from EEPROM

Add eeprom access code and read the uid during switch initialization.
The UID will be used to check device identity after suspend.

Signed-off-by: Andreas Noever <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...