summaryrefslogtreecommitdiff
path: root/drivers/thunderbolt/Kconfig
AgeCommit message (Collapse)Author
2020-11-11thunderbolt: Add DMA traffic test driverIsaac Hazan
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>
2020-09-16thunderbolt: Use "if USB4" instead of "depends on" in KconfigMika Westerberg
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>
2020-09-16thunderbolt: Allow KUnit tests to be built also when CONFIG_USB4=mMika Westerberg
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>
2020-09-03thunderbolt: Add debugfs interfaceGil Fine
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>
2020-06-22thunderbolt: Add KUnit tests for path walkingMika Westerberg
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>
2020-06-15thunderbolt: Improve USB4 config symbol help textGeert Uytterhoeven
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>
2020-05-13thunderbolt: Update Kconfig to allow building on other architectures.David Manouchehri
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>
2019-12-18thunderbolt: Update Kconfig entries to USB4Mika Westerberg
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>
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner
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>
2017-06-09thunderbolt: Add support for host and device NVM firmware upgradeMika Westerberg
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>
2017-06-09thunderbolt: Add support for Internal Connection Manager (ICM)Mika Westerberg
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>
2016-11-18thunderbolt: Compile on x86 onlyLukas Wunner
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>
2016-11-18thunderbolt, efi: Fix Kconfig dependencies harderLukas Wunner
Since commit c9cc3aaa0281 ("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 79f9cd35b05e ("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>
2016-11-15thunderbolt, efi: Fix Kconfig dependenciesLukas Wunner
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>
2016-11-13thunderbolt: Use Device ROM retrieved from EFILukas Wunner
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>
2014-06-21thunderbolt: select CRC32 in KconfigAndreas Noever
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>
2014-06-20thunderbolt: add PCI dependencyArnd Bergmann
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>
2014-06-19thunderbolt: Add initial cactus ridge NHI supportAndreas Noever
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>