Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12 |
|
#
3c1d704d |
| 13-Jan-2024 |
Sanath S <Sanath.S@amd.com> |
thunderbolt: Reset topology created by the boot firmware
commit 59a54c5f3dbde00b8ad30aef27fe35b1fe07bf5c upstream.
Boot firmware (typically BIOS) might have created tunnels of its own. The tunnel c
thunderbolt: Reset topology created by the boot firmware
commit 59a54c5f3dbde00b8ad30aef27fe35b1fe07bf5c upstream.
Boot firmware (typically BIOS) might have created tunnels of its own. The tunnel configuration that it does might be sub-optimal. For instance it may only support HBR2 monitors so the DisplayPort tunnels it created may limit Linux graphics drivers. In addition there is an issue on some AMD based systems where the BIOS does not allocate enough PCIe resources for future topology extension. By resetting the USB4 topology the PCIe links will be reset as well allowing Linux to re-allocate.
This aligns the behavior with Windows Connection Manager.
We already issued host router reset for USB4 v2 routers, now extend it to USB4 v1 routers as well. For pre-USB4 (that's Apple systems) we leave it as is and continue to discover the existing tunnels.
Suggested-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Sanath S <Sanath.S@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12 |
|
#
3c1d704d |
| 13-Jan-2024 |
Sanath S <Sanath.S@amd.com> |
thunderbolt: Reset topology created by the boot firmware
commit 59a54c5f3dbde00b8ad30aef27fe35b1fe07bf5c upstream.
Boot firmware (typically BIOS) might have created tunnels of its own. The tunnel c
thunderbolt: Reset topology created by the boot firmware
commit 59a54c5f3dbde00b8ad30aef27fe35b1fe07bf5c upstream.
Boot firmware (typically BIOS) might have created tunnels of its own. The tunnel configuration that it does might be sub-optimal. For instance it may only support HBR2 monitors so the DisplayPort tunnels it created may limit Linux graphics drivers. In addition there is an issue on some AMD based systems where the BIOS does not allocate enough PCIe resources for future topology extension. By resetting the USB4 topology the PCIe links will be reset as well allowing Linux to re-allocate.
This aligns the behavior with Windows Connection Manager.
We already issued host router reset for USB4 v2 routers, now extend it to USB4 v1 routers as well. For pre-USB4 (that's Apple systems) we leave it as is and continue to discover the existing tunnels.
Suggested-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Sanath S <Sanath.S@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12 |
|
#
3c1d704d |
| 13-Jan-2024 |
Sanath S <Sanath.S@amd.com> |
thunderbolt: Reset topology created by the boot firmware
commit 59a54c5f3dbde00b8ad30aef27fe35b1fe07bf5c upstream.
Boot firmware (typically BIOS) might have created tunnels of its own. The tunnel c
thunderbolt: Reset topology created by the boot firmware
commit 59a54c5f3dbde00b8ad30aef27fe35b1fe07bf5c upstream.
Boot firmware (typically BIOS) might have created tunnels of its own. The tunnel configuration that it does might be sub-optimal. For instance it may only support HBR2 monitors so the DisplayPort tunnels it created may limit Linux graphics drivers. In addition there is an issue on some AMD based systems where the BIOS does not allocate enough PCIe resources for future topology extension. By resetting the USB4 topology the PCIe links will be reset as well allowing Linux to re-allocate.
This aligns the behavior with Windows Connection Manager.
We already issued host router reset for USB4 v2 routers, now extend it to USB4 v1 routers as well. For pre-USB4 (that's Apple systems) we leave it as is and continue to discover the existing tunnels.
Suggested-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Sanath S <Sanath.S@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12 |
|
#
3c1d704d |
| 13-Jan-2024 |
Sanath S <Sanath.S@amd.com> |
thunderbolt: Reset topology created by the boot firmware
commit 59a54c5f3dbde00b8ad30aef27fe35b1fe07bf5c upstream.
Boot firmware (typically BIOS) might have created tunnels of its own. The tunnel c
thunderbolt: Reset topology created by the boot firmware
commit 59a54c5f3dbde00b8ad30aef27fe35b1fe07bf5c upstream.
Boot firmware (typically BIOS) might have created tunnels of its own. The tunnel configuration that it does might be sub-optimal. For instance it may only support HBR2 monitors so the DisplayPort tunnels it created may limit Linux graphics drivers. In addition there is an issue on some AMD based systems where the BIOS does not allocate enough PCIe resources for future topology extension. By resetting the USB4 topology the PCIe links will be reset as well allowing Linux to re-allocate.
This aligns the behavior with Windows Connection Manager.
We already issued host router reset for USB4 v2 routers, now extend it to USB4 v1 routers as well. For pre-USB4 (that's Apple systems) we leave it as is and continue to discover the existing tunnels.
Suggested-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Sanath S <Sanath.S@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12 |
|
#
3c1d704d |
| 13-Jan-2024 |
Sanath S <Sanath.S@amd.com> |
thunderbolt: Reset topology created by the boot firmware
commit 59a54c5f3dbde00b8ad30aef27fe35b1fe07bf5c upstream.
Boot firmware (typically BIOS) might have created tunnels of its own. The tunnel c
thunderbolt: Reset topology created by the boot firmware
commit 59a54c5f3dbde00b8ad30aef27fe35b1fe07bf5c upstream.
Boot firmware (typically BIOS) might have created tunnels of its own. The tunnel configuration that it does might be sub-optimal. For instance it may only support HBR2 monitors so the DisplayPort tunnels it created may limit Linux graphics drivers. In addition there is an issue on some AMD based systems where the BIOS does not allocate enough PCIe resources for future topology extension. By resetting the USB4 topology the PCIe links will be reset as well allowing Linux to re-allocate.
This aligns the behavior with Windows Connection Manager.
We already issued host router reset for USB4 v2 routers, now extend it to USB4 v1 routers as well. For pre-USB4 (that's Apple systems) we leave it as is and continue to discover the existing tunnels.
Suggested-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Sanath S <Sanath.S@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70 |
|
#
8283fb57 |
| 22-Sep-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
thunderbolt: Convert to use sysfs_emit()/sysfs_emit_at() APIs
Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting
thunderbolt: Convert to use sysfs_emit()/sysfs_emit_at() APIs
Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space.
While at it, use Elvis operator in some cases.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
Revision tags: v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54 |
|
#
635dcd16 |
| 08-Jul-2022 |
David Gow <davidgow@google.com> |
thunderbolt: test: Use kunit_test_suite() macro
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 upda
thunderbolt: test: Use kunit_test_suite() macro
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>
show more ...
|
Revision tags: v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36 |
|
#
86eaf4a5 |
| 25-Apr-2022 |
Robin Murphy <robin.murphy@arm.com> |
thunderbolt: Make iommu_dma_protection more accurate
Between me trying to get rid of iommu_present() and Mario wanting to support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown that
thunderbolt: Make iommu_dma_protection more accurate
Between me trying to get rid of iommu_present() and Mario wanting to support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown that the iommu_dma_protection attribute is being far too optimistic. Even if an IOMMU might be present for some PCI segment in the system, that doesn't necessarily mean it provides translation for the device(s) we care about. Furthermore, all that DMAR_PLATFORM_OPT_IN really does is tell us that memory was protected before the kernel was loaded, and prevent the user from disabling the intel-iommu driver entirely. While that lets us assume kernel integrity, what matters for actual runtime DMA protection is whether we trust individual devices, based on the "external facing" property that we expect firmware to describe for Thunderbolt ports.
It's proven challenging to determine the appropriate ports accurately given the variety of possible topologies, so while still not getting a perfect answer, by putting enough faith in firmware we can at least get a good bit closer. If we can see that any device near a Thunderbolt NHI has all the requisites for Kernel DMA Protection, chances are that it *is* a relevant port, but moreover that implies that firmware is playing the game overall, so we'll use that to assume that all Thunderbolt ports should be correctly marked and thus will end up fully protected.
CC: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/b153f208bc9eafab5105bad0358b77366509d2d4.1650878781.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50 |
|
#
fc7a6209 |
| 13-Jul-2021 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
bus: Make remove callback return void
The driver core ignores the return value of this callback because there is only little it can do when a device disappears.
This is the final bit of a long last
bus: Make remove callback return void
The driver core ignores the return value of this callback because there is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several buses were converted to also return void from their remove callback. Additionally some resource leaks were fixed that were caused by drivers returning an error code in the expectation that the driver won't go away.
With struct bus_type::remove returning void it's prevented that newly implemented buses return an ignored error code and so don't anticipate wrong expectations for driver authors.
Reviewed-by: Tom Rix <trix@redhat.com> (For fpga) Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> (For drivers/s390 and drivers/vfio) Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> (For ARM, Amba and related parts) Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Chen-Yu Tsai <wens@csie.org> (for sunxi-rsb) Acked-by: Pali Rohár <pali@kernel.org> Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org> (for media) Acked-by: Hans de Goede <hdegoede@redhat.com> (For drivers/platform) Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-By: Vinod Koul <vkoul@kernel.org> Acked-by: Juergen Gross <jgross@suse.com> (For xen) Acked-by: Lee Jones <lee.jones@linaro.org> (For mfd) Acked-by: Johannes Thumshirn <jth@kernel.org> (For mcb) Acked-by: Johan Hovold <johan@kernel.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> (For slimbus) Acked-by: Kirti Wankhede <kwankhede@nvidia.com> (For vfio) Acked-by: Maximilian Luz <luzmaximilian@gmail.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> (For ulpi and typec) Acked-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com> (For ipack) Acked-by: Geoff Levand <geoff@infradead.org> (For ps3) Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com> (For thunderbolt) Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> (For intel_th) Acked-by: Dominik Brodowski <linux@dominikbrodowski.net> (For pcmcia) Acked-by: Rafael J. Wysocki <rafael@kernel.org> (For ACPI) Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> (rpmsg and apr) Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> (For intel-ish-hid) Acked-by: Dan Williams <dan.j.williams@intel.com> (For CXL, DAX, and NVDIMM) Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> (For isa) Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (For firewire) Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> (For hid) Acked-by: Thorsten Scherer <t.scherer@eckelmann.de> (For siox) Acked-by: Sven Van Asbroeck <TheSven73@gmail.com> (For anybuss) Acked-by: Ulf Hansson <ulf.hansson@linaro.org> (For MMC) Acked-by: Wolfram Sang <wsa@kernel.org> # for I2C Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Finn Thain <fthain@linux-m68k.org> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20210713193522.1770306-6-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30 |
|
#
ccc5cb8a |
| 01-Apr-2021 |
Rajmohan Mani <rajmohan.mani@intel.com> |
thunderbolt: Add support for ACPI _DSM to power on/off retimers
Typically retimers can be accessed only when the USB4 link is up (e.g there is a cable connected). However, sometimes it is useful to
thunderbolt: Add support for ACPI _DSM to power on/off retimers
Typically retimers can be accessed only when the USB4 link is up (e.g there is a cable connected). However, sometimes it is useful to be able to access retimers even if there is nothing connected to the USB4 port. For instance we may still want to be able to upgrade the retimer NVM firmware even if the user does not have any USB4 devices. This is something that USB4 spec leaves to implementers.
In case of ACPI based systems, we can support this by providing a special _DSM method under each USB4 port. This _DSM can be used to turn on power to on-board retimers (and cycle it through different modes so that the sideband becomes usable).
This patch adds support for this _DSM and makes the functionality available to the rest of the driver through tb_acpi_power_[on|off]_retimers().
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> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10.27, v5.10.26 |
|
#
2e7a5b3e |
| 23-Mar-2021 |
Dan Carpenter <dan.carpenter@oracle.com> |
thunderbolt: Unlock on error path in tb_domain_add()
We accidentally deleted this unlock on the error path. Undelete it.
Fixes: 7f0a34d7900b ("thunderbolt: Decrease control channel timeout for sof
thunderbolt: Unlock on error path in tb_domain_add()
We accidentally deleted this unlock on the error path. Undelete it.
Fixes: 7f0a34d7900b ("thunderbolt: Decrease control channel timeout for software connection manager") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
Revision tags: v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
180b0689 |
| 08-Jan-2021 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Allow multiple DMA tunnels over a single XDomain connection
Currently we have had an artificial limitation of a single DMA tunnel per XDomain connection. However, hardware wise there is
thunderbolt: Allow multiple DMA tunnels over a single XDomain connection
Currently we have had an artificial limitation of a single DMA tunnel per XDomain connection. However, hardware wise there is no such limit and software based connection manager can take advantage of all the DMA rings available on the host to establish tunnels.
For this reason make the tb_xdomain_[enable|disable]_paths() to take the DMA ring and HopID as parameter instead of storing them in the struct tb_xdomain. We also add API functions to allocate input and output HopIDs of the XDomain connection that the service drivers can use instead of hard-coding.
Also convert the two existing service drivers over to this API.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
7f0a34d7 |
| 29-Dec-2020 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Decrease control channel timeout for software connection manager
When the firmware connection manager is not proxying between the software and the hardware we can decrease the timeout f
thunderbolt: Decrease control channel timeout for software connection manager
When the firmware connection manager is not proxying between the software and the hardware we can decrease the timeout for control packets significantly. The USB4 spec recommends 10 ms +- 1 ms but we use slightly larger value (100 ms) which is recommendation from Intel Thunderbolt firmware folks. When firmware connection manager is running then we keep using the existing 5000 ms.
To implement this we move the control channel allocation to tb_domain_alloc(), and pass the timeout from that function to the tb_ctl_alloc(). Then make both connection manager implementations pass the timeout when they alloc the domain structure.
While there update kernel-doc of struct tb_ctl to match the reality.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
Revision tags: v5.10, v5.8.17 |
|
#
5ca67688 |
| 22-Oct-2020 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Allow disabling XDomain protocol
This allows disabling XDomain protocol completely if the user does not plan to use the USB4/Thunderbolt peer-to-peer functionality, or for security reas
thunderbolt: Allow disabling XDomain protocol
This allows disabling XDomain protocol completely if the user does not plan to use the USB4/Thunderbolt peer-to-peer functionality, or for security reasons.
XDomain protocol is enabled by default but with this commit it is possible to disable it by passing "xdomain=0" as module parameter (or through the kernel command line).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
show more ...
|
Revision tags: v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7 |
|
#
3cd542e6 |
| 03-Sep-2020 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Add support for PCIe tunneling disabled (SL5)
Recent Intel Thunderbolt firmware connection manager has support for another security level, SL5, that disables PCIe tunneling. This option
thunderbolt: Add support for PCIe tunneling disabled (SL5)
Recent Intel Thunderbolt firmware connection manager has support for another security level, SL5, that disables PCIe tunneling. This option can be turned on from the BIOS.
When this is set the driver exposes a new security level "nopcie" to the userspace and hides the authorized attribute under connected devices.
While there we also hide it when "dponly" security level is enabled since it is not really usable in that case anyway.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
show more ...
|
#
3da88be2 |
| 10-Nov-2020 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Add support for de-authorizing devices
In some cases it is useful to be able de-authorize devices. For example if user logs out the userspace can have a policy that disconnects PCIe dev
thunderbolt: Add support for de-authorizing devices
In some cases it is useful to be able de-authorize devices. For example if user logs out the userspace can have a policy that disconnects PCIe devices until logged in again. This is only possible for software based connection manager as it directly controls the tunnels.
For this reason make the authorized attribute accept writing 0 which makes the software connection manager to tear down the corresponding PCIe tunnel. Userspace can check if this is supported by reading a new domain attribute deauthorization, that holds 1 in that case.
While there correct tb_domain_approve_switch() kernel-doc and description of authorized attribute to mention that it is only about PCIe tunnels.
Cc: Christian Kellner <christian@kellner.me> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
show more ...
|
#
6889e00f |
| 08-Jan-2021 |
Rikard Falkeborn <rikard.falkeborn@gmail.com> |
thunderbolt: Constify static attribute_group structs
The only usage of these is to put their addresses in arrays of pointers to const attribute_groups. Make them const to allow the compiler to put t
thunderbolt: Constify static attribute_group structs
The only usage of these is to put their addresses in arrays of pointers to const attribute_groups. Make them const to allow the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
Revision tags: v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61 |
|
#
2c6ea4e2 |
| 24-Aug-2020 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
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 <mika.westerberg@linux.intel.com>
show more ...
|
#
884e4d57 |
| 31-Aug-2020 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Only stop control channel when entering freeze
According to the kernel power management documentation freeze phase should only quiesce the device, no need to configure wakes or put it t
thunderbolt: Only stop control channel when entering freeze
According to the kernel power management documentation freeze phase should only quiesce the device, no need to configure wakes or put it to low power state. For this reason we simply stop the control channel and in case of Software Connection Manager also mark the hotplug disabled. This should align the driver better with the PM framework expectations.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
Revision tags: v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7 |
|
#
54e41810 |
| 29-Jun-2020 |
Gil Fine <gil.fine@intel.com> |
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 <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3 |
|
#
b2911a59 |
| 06-Dec-2019 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Enable wakes from system suspend
In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers
thunderbolt: Enable wakes from system suspend
In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another.
Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13.
While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
fff15f23 |
| 01-Sep-2020 |
Tian Tao <tiantao6@hisilicon.com> |
thunderbolt: Use kobj_to_dev() instead of container_of()
Doesn't really matter for an individual driver, but it may get coppied to lots more. I consider it's a little tidy up.
Signed-off-by: Tian T
thunderbolt: Use kobj_to_dev() instead of container_of()
Doesn't really matter for an individual driver, but it may get coppied to lots more. I consider it's a little tidy up.
Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
719a5fe8 |
| 05-Mar-2020 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
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 <mika.westerberg@linux.intel.com>
show more ...
|
#
30105189 |
| 11-Mar-2020 |
Takashi Iwai <tiwai@suse.de> |
thunderbolt: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given
thunderbolt: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf().
Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
Revision tags: v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8 |
|
#
877b5691 |
| 14-Apr-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: shash - remove shash_desc::flags
The flags field in 'struct shash_desc' never actually does anything. The only ostensibly supported flag is CRYPTO_TFM_REQ_MAY_SLEEP. However, no shash algori
crypto: shash - remove shash_desc::flags
The flags field in 'struct shash_desc' never actually does anything. The only ostensibly supported flag is CRYPTO_TFM_REQ_MAY_SLEEP. However, no shash algorithm ever sleeps, making this flag a no-op.
With this being the case, inevitably some users who can't sleep wrongly pass MAY_SLEEP. These would all need to be fixed if any shash algorithm actually started sleeping. For example, the shash_ahash_*() functions, which wrap a shash algorithm with the ahash API, pass through MAY_SLEEP from the ahash API to the shash API. However, the shash functions are called under kmap_atomic(), so actually they're assumed to never sleep.
Even if it turns out that some users do need preemption points while hashing large buffers, we could easily provide a helper function crypto_shash_update_large() which divides the data into smaller chunks and calls crypto_shash_update() and cond_resched() for each chunk. It's not necessary to have a flag in 'struct shash_desc', nor is it necessary to make individual shash algorithms aware of this at all.
Therefore, remove shash_desc::flags, and document that the crypto_shash_*() functions can be called from any context.
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|