microsoft
/
WSL2-Linux-Kernel
зеркало из https://github.com/microsoft/WSL2-Linux-Kernel.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
WSL2-Linux-Kernel/drivers/thunderbolt/Makefile

14 строки
595 B
Makefile
Исходник Обычный вид История

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 <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-19 15:07:45 +03:00
# SPDX-License-Identifier: GPL-2.0-only
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 <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-12-17 15:33:41 +03:00
obj-${CONFIG_USB4} := thunderbolt.o
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 <raanan.avargil@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com> Tested-by: Mario Limonciello <mario.limonciello@dell.com>
2018-01-16 23:19:00 +03:00
thunderbolt-objs := nhi.o nhi_ops.o ctl.o tb.o switch.o cap.o path.o tunnel.o eeprom.o
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 <rajmohan.mani@intel.com> Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20191217123345.31850-8-mika.westerberg@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17 15:33:43 +03:00
thunderbolt-objs += domain.o dma_port.o icm.o property.o xdomain.o lc.o tmu.o usb4.o
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 <mika.westerberg@linux.intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-01 17:34:20 +03:00
thunderbolt-objs += usb4_port.o nvm.o retimer.o quirks.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 <mika.westerberg@linux.intel.com>
2020-04-29 16:38:39 +03:00
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 <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-04-02 15:26:00 +03:00
thunderbolt-${CONFIG_ACPI} += acpi.o
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 <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-29 20:30:52 +03:00
thunderbolt-$(CONFIG_DEBUG_FS) += debugfs.o
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 <mika.westerberg@linux.intel.com>
2020-08-24 12:46:52 +03:00
thunderbolt-${CONFIG_USB4_KUNIT_TEST} += test.o
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 <brendanhiggins@google.com> Suggested-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-09-30 00:27:12 +03:00
CFLAGS_test.o += $(DISABLE_STRUCTLEAK_PLUGIN)
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 <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-24 11:44:02 +03:00
thunderbolt_dma_test-${CONFIG_USB4_DMA_TEST} += dma_test.o
obj-$(CONFIG_USB4_DMA_TEST) += thunderbolt_dma_test.o