Retimers support lane margining as well so make this available through
debugfs in the same way as we do for the USB4 ports. When this is
enabled we also expose retimers on the other side of the cable because
typically margining is implemented only on direction towards the cable.
However, for the retimers on the other side of the cable we do not allow
NVM upgrade to avoid confusing the existing userspace (the same retimer
may now appear twice with different name) and is probably not a good
idea anyway.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This allows the interested parties to find the Thunderbolt/USB4
debugging tools (aka tbtools) easier in case they need to look at the
information under debugfs entries.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
This includes following Thunderbolt/USB4 changes for the v6.1 merge
window:
- Support for Intel Meteor Lake integrated Thunderbolt/USB4 controller
- Support for ASMedia USB4 controller NVM firmware upgrade
- Receiver lane margining support
- Few fixes and cleanups.
All these have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAmM0G3ogHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKAhEg/8CuUZvDwLog7O
SbpKAPqGOvDC3EM0VhtJyjJAUVWImVaRuSHAWEHn/XJAICaRTxMJJM7xoJnr+X7O
4VMFzPhF6oF+28VMzy8OLm15kiiNtpXimOKaXNXzoDzJ6aqjgr9KpHSpzhOx3MuF
HUzhoMWk2RHwnrkxlpewU9wJg8ZtG6syI5QV534KsqIwxOcO+8pr7nKz8V8HrUt9
EwFIgU4op/eKCsgeLmotw/8CXI33ezIheMeUdSit3Gqa3Ey9u/JtzVaN7siEOhxy
c3nBO8MgYhKaX0RCVKFGRm/YktFlrECStfDNhgtUbBS2lfoePcaeZGKwuCRpmhkj
WicPxph8m5slKborqGVaoZtgtxqftOt1tWmvnJntqSLcOycPM4bX8gDfWZmoi6JX
f+Vritdy9DDTCE00/Hc2gCpQG0rfX+DzpYvLz4Z8tIa5oU9X5CfCNs8qb20VSQAg
xgmyRe+6/UzJAMKQ7uPy8wSKt/rpKOxsIQC+bhhdiN9g000YS7A56juiC0Z8IfrH
rZae7pvtoD/r7lrJlRcFKtNPup+QrZZ/kdLzWpZbAmKYZ7DkI44KA4iHVBpt24rg
8e23s2/U6ezhNMcR0dLWwIrE+KoiB15BkX9/J1CJxhJLW9lw+fxlSfeZDI0rfjE2
HqcC/Fxx1dMNJykbXAyrO9HYmT551Vs=
=67d1
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next
Mika writes:
"thunderbolt: Changes for v6.1 merge window
This includes following Thunderbolt/USB4 changes for the v6.1 merge
window:
- Support for Intel Meteor Lake integrated Thunderbolt/USB4 controller
- Support for ASMedia USB4 controller NVM firmware upgrade
- Receiver lane margining support
- Few fixes and cleanups.
All these have been in linux-next with no reported issues."
* tag 'thunderbolt-for-v6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
thunderbolt: Explicitly enable lane adapter hotplug events at startup
thunderbolt: Use dev_err_probe()
thunderbolt: Convert to use sysfs_emit()/sysfs_emit_at() APIs
thunderbolt: Fix spelling mistake "simultaneusly" -> "simultaneously"
thunderbolt: debugfs: Fix spelling mistakes in seq_puts text
thunderbolt: Add support for ASMedia NVM image format
thunderbolt: Move vendor specific NVM handling into nvm.c
thunderbolt: Provide tb_retimer_nvm_read() analogous to tb_switch_nvm_read()
thunderbolt: Rename and make nvm_read() available for other files
thunderbolt: Extend NVM version fields to 32-bits
thunderbolt: Allow NVM upgrade of USB4 host routers
thunderbolt: Add support for receiver lane margining
thunderbolt: Add helper to check if CL states are enabled on port
thunderbolt: Pass CL state bitmask to tb_port_clx_supported()
thunderbolt: Move port CL state functions into correct place in switch.c
thunderbolt: Move tb_xdomain_parent() to tb.h
thunderbolt: Add support for Intel Meteor Lake
thunderbolt: Add comment where Thunderbolt 4 PCI IDs start
thunderbolt: Add DP OUT resource when DP tunnel is discovered
USB4 spec defines standard set of registers to be used for receiver lane
margining. This is useful for I/O interface quality and electrical
robustness validation during manufacturing. Expose receiver lane
margining through new debugfs directory "margining" that is added under
each connected USB4 port. Users can then run the margining by writing to
the exposed attributes under that directory.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Both the USB4 and Nitro Enclaves KUNIT tests are now able to be compiled
if KUNIT is compiled as a module. This leads to issues if KUNIT is being
packaged separately from the core kernel and when KUNIT is run baremetal
without the required driver compiled into the kernel.
Fixes: 635dcd1684 ("thunderbolt: test: Use kunit_test_suite() macro")
Fixes: fe5be808fa ("nitro_enclaves: test: Use kunit_test_suite() macro")
Signed-off-by: Nico Pache <npache@redhat.com>
Reviewed-by: David Gow <davidgow@google.com>
Reviewed-by: Andra Paraschiv <andraprs@amazon.com>
Acked-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The new implementation of kunit_test_suite() for modules no longer
conflicts with module_init, so can now be used by the thunderbolt tests.
Also update the Kconfig entry to enable the test when KUNIT_ALL_TESTS is
enabled.
This means that kunit_tool can now successfully run and parse the test
results with, for example:
./tools/testing/kunit/kunit.py run --arch=x86_64 \
--kconfig_add CONFIG_PCI=y --kconfig_add CONFIG_USB4=y \
'thunderbolt'
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Daniel Latypov <dlatypov@google.com>
Acked-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
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 <isaac.hazan@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This groups the USB4 options more nicely, and also does not require that
every config option lists explicit depends on USB4.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
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 <mika.westerberg@linux.intel.com>
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 <gil.fine@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <mika.westerberg@linux.intel.com>
Fix the spelling of "specification", and add a missing "the" article.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Thunderbolt 3 and USB4 shouldn't be x86 only.
Tested on a SolidRun HoneyComb (ARM Cortex-A72) with a
Gigabyte Titan Ridge Thunderbolt 3 PCIe card (JHL7540).
Signed-off-by: David Manouchehri <david.manouchehri@riseup.net>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
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 <mika.westerberg@linux.intel.com>
Cc: David S. Miller <davem@davemloft.net>
Link: https://lore.kernel.org/r/20191217123345.31850-6-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Starting from Intel Falcon Ridge the NVM firmware can be upgraded by
using DMA configuration based mailbox commands. If we detect that the
host or device (device support starts from Intel Alpine Ridge) has the
DMA configuration based mailbox we expose NVM information to the
userspace as two separate Linux NVMem devices: nvm_active and
nvm_non_active. The former is read-only portion of the active NVM which
firmware upgrade tools can be use to find out suitable NVM image if the
device identification strings are not enough.
The latter is write-only portion where the new NVM image is to be
written by the userspace. It is up to the userspace to find out right
NVM image (the kernel does very minimal validation). The ICM firmware
itself authenticates the new NVM firmware and fails the operation if it
is not what is expected.
We also expose two new sysfs files per each switch: nvm_version and
nvm_authenticate which can be used to read the active NVM version and
start the upgrade process.
We also introduce safe mode which is the mode a switch goes when it does
not have properly authenticated firmware. In this mode the switch only
accepts a couple of commands including flashing a new NVM firmware image
and triggering power cycle.
This code is based on the work done by Amir Levy and Michael Jamet.
Signed-off-by: Michael Jamet <michael.jamet@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Yehezkel Bernat <yehezkel.bernat@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <michael.jamet@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Yehezkel Bernat <yehezkel.bernat@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
So far Thunderbolt is (unfortunately) an Intel proprietary technology
that is only available on x86, so compiling on other arches is pointless
except for testing purposes. Amend Kconfig accordingly.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andreas Noever <andreas.noever@gmail.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/7dfda728d3ee8a33c80c49b224da7359c6015eea.1479456179.git.lukas@wunner.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Since commit c9cc3aaa02 ("thunderbolt: Use Device ROM retrieved from
EFI"), the THUNDERBOLT config option selects APPLE_PROPERTIES.
This broke the build for certain configs because APPLE_PROPERTIES is
located in a menu which depends on EFI: If EFI is not enabled, the
prerequisites needed for APPLE_PROPERTIES are not selected: Those are
EFI_DEV_PATH_PARSER and UCS2_STRING. Additionally EFI_DEV_PATH_PARSER
won't compile unless ACPI is enabled.
Commit 79f9cd35b0 ("thunderbolt, efi: Fix Kconfig dependencies")
sought to fix the breakage by making THUNDERBOLT select APPLE_PROPERTIES
only if EFI_STUB is enabled. On x86, EFI_STUB depends on EFI and EFI
depends on ACPI, so this fixed the build at least on this architecture.
However on arm and arm64, EFI_STUB does not depend on EFI, so once again
the prerequisites needed for APPLE_PROPERTIES are not selected.
Additionally ACPI is not available on arm and optional on arm64,
therefore EFI_DEV_PATH_PARSER won't compile.
Fix by selecting APPLE_PROPERTIES only on x86.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andreas Noever <andreas.noever@gmail.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/5c241cf92eb1dc2421218c1204c6a9d22c9f847b.1479456179.git.lukas@wunner.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Fix this EFI build failure on certain (rand)configs:
drivers/firmware/efi/apple-properties.c:149:9: error: implicit declaration of function ???efi_get_device_by_path??? [-Werror=implicit-function-declaration]
which is due to:
warning: (THUNDERBOLT) selects APPLE_PROPERTIES which has unmet direct dependencies (EFI && EFI_STUB && X86)
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Andreas Noever <andreas.noever@gmail.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Pedro Vilaça <reverser@put.as>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Pierre Moreau <pierre.morrow@free.fr> [MacBookPro11,3]
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20161114151033.GA10141@wunner.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Macs with Thunderbolt 1 do not have a unit-specific DROM: The DROM is
empty with uid 0x1000000000000. (Apple started factory-burning a unit-
specific DROM with Thunderbolt 2.)
Instead, the NHI EFI driver supplies a DROM in a device property. Use
it if available. It's only available when booting with the efistub.
If it's not available, silently fall back to our hardcoded DROM.
The size of the DROM is always 256 bytes. The number is hardcoded into
the NHI EFI driver. This commit can deal with an arbitrary size however,
just in case they ever change that.
Background information: The EFI firmware volume contains ROM files for
the NHI, GMUX and several other chips as well as key material. This
strategy allows Apple to deploy ROM or key updates by simply publishing
an EFI firmware update on their website. Drivers do not access those
files directly but rather through a file server via EFI protocol
AC5E4829-A8FD-440B-AF33-9FFE013B12D8. Files are identified by GUID, the
NHI DROM has 339370BD-CFC6-4454-8EF7-704653120818.
The NHI EFI driver amends that file with a unit-specific uid. The uid
has 64 bit but its entropy is much lower: 24 bit represent the model,
24 bit are taken from a serial number, 16 bit are fixed. The NHI EFI
driver obtains the serial number via the DataHub protocol, copies it
into the DROM, calculates the CRC and submits the result as a device
property.
A modification is needed in the resume code where we currently read the
uid of all switches in the hierarchy to detect plug events that occurred
during sleep. On Thunderbolt 1 root switches this will now lead to a
mismatch between the uid of the empty DROM and the EFI DROM. Exempt the
root switch from this check: It's built in, so the uid should never
change. However we continue to *read* the uid of the root switch, this
seems like a good way to test its reachability after resume.
Tested-by: Lukas Wunner <lukas@wunner.de> [MacBookPro9,1]
Tested-by: Pierre Moreau <pierre.morrow@free.fr> [MacBookPro11,3]
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Acked-by: Andreas Noever <andreas.noever@gmail.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pedro Vilaça <reverser@put.as>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20161112213237.8804-10-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
We use __crc32c_le in ctl.c. So make sure that the dependency is there.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The thunderbolt drivers cannot be built if CONFIG_PCI is disabled,
better add an explicit Kconfig dependency.
The "default no" line is redundant and can be removed at the same
time.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thunderbolt hotplug is supposed to be handled by the firmware. But Apple
decided to implement thunderbolt at the operating system level. The
firmare only initializes thunderbolt devices that are present at boot
time. This driver enables hotplug of thunderbolt of non-chained
thunderbolt devices on Apple systems with a cactus ridge controller.
This first patch adds the Kconfig file as well the parts of the driver
which talk directly to the hardware (that is pci device setup, interrupt
handling and RX/TX ring management).
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
