I noticed that when we do discrete host router NVM upgrade and it gets
hot-removed from the PCIe side as a result of NVM firmware authentication,
if there is another host connected with enabled paths we hang in tearing
them down. This is due to fact that the Thunderbolt networking driver
also tries to cleanup the paths and ends up blocking in
tb_disconnect_xdomain_paths() waiting for the domain lock.
However, at this point we already cleaned the paths in tb_stop() so
there is really no need for tb_disconnect_xdomain_paths() to do that
anymore. Furthermore it already checks if the XDomain is unplugged and
bails out early so take advantage of that and mark the XDomain as
unplugged when we remove the parent router.
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Here is the big set of driver core changes for 6.11-rc1.
Lots of stuff in here, with not a huge diffstat, but apis are evolving
which required lots of files to be touched. Highlights of the changes
in here are:
- platform remove callback api final fixups (Uwe took many releases to
get here, finally!)
- Rust bindings for basic firmware apis and initial driver-core
interactions. It's not all that useful for a "write a whole driver
in rust" type of thing, but the firmware bindings do help out the
phy rust drivers, and the driver core bindings give a solid base on
which others can start their work. There is still a long way to go
here before we have a multitude of rust drivers being added, but
it's a great first step.
- driver core const api changes. This reached across all bus types,
and there are some fix-ups for some not-common bus types that
linux-next and 0-day testing shook out. This work is being done to
help make the rust bindings more safe, as well as the C code, moving
toward the end-goal of allowing us to put driver structures into
read-only memory. We aren't there yet, but are getting closer.
- minor devres cleanups and fixes found by code inspection
- arch_topology minor changes
- other minor driver core cleanups
All of these have been in linux-next for a very long time with no
reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZqH+aQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymoOQCfVBdLcBjEDAGh3L8qHRGMPy4rV2EAoL/r+zKm
cJEYtJpGtWX6aAtugm9E
=ZyJV
-----END PGP SIGNATURE-----
Merge tag 'driver-core-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here is the big set of driver core changes for 6.11-rc1.
Lots of stuff in here, with not a huge diffstat, but apis are evolving
which required lots of files to be touched. Highlights of the changes
in here are:
- platform remove callback api final fixups (Uwe took many releases
to get here, finally!)
- Rust bindings for basic firmware apis and initial driver-core
interactions.
It's not all that useful for a "write a whole driver in rust" type
of thing, but the firmware bindings do help out the phy rust
drivers, and the driver core bindings give a solid base on which
others can start their work.
There is still a long way to go here before we have a multitude of
rust drivers being added, but it's a great first step.
- driver core const api changes.
This reached across all bus types, and there are some fix-ups for
some not-common bus types that linux-next and 0-day testing shook
out.
This work is being done to help make the rust bindings more safe,
as well as the C code, moving toward the end-goal of allowing us to
put driver structures into read-only memory. We aren't there yet,
but are getting closer.
- minor devres cleanups and fixes found by code inspection
- arch_topology minor changes
- other minor driver core cleanups
All of these have been in linux-next for a very long time with no
reported problems"
* tag 'driver-core-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (55 commits)
ARM: sa1100: make match function take a const pointer
sysfs/cpu: Make crash_hotplug attribute world-readable
dio: Have dio_bus_match() callback take a const *
zorro: make match function take a const pointer
driver core: module: make module_[add|remove]_driver take a const *
driver core: make driver_find_device() take a const *
driver core: make driver_[create|remove]_file take a const *
firmware_loader: fix soundness issue in `request_internal`
firmware_loader: annotate doctests as `no_run`
devres: Correct code style for functions that return a pointer type
devres: Initialize an uninitialized struct member
devres: Fix memory leakage caused by driver API devm_free_percpu()
devres: Fix devm_krealloc() wasting memory
driver core: platform: Switch to use kmemdup_array()
driver core: have match() callback in struct bus_type take a const *
MAINTAINERS: add Rust device abstractions to DRIVER CORE
device: rust: improve safety comments
MAINTAINERS: add Danilo as FIRMWARE LOADER maintainer
MAINTAINERS: add Rust FW abstractions to FIRMWARE LOADER
firmware: rust: improve safety comments
...
In the match() callback, the struct device_driver * should not be
changed, so change the function callback to be a const *. This is one
step of many towards making the driver core safe to have struct
device_driver in read-only memory.
Because the match() callback is in all busses, all busses are modified
to handle this properly. This does entail switching some container_of()
calls to container_of_const() to properly handle the constant *.
For some busses, like PCI and USB and HV, the const * is cast away in
the match callback as those busses do want to modify those structures at
this point in time (they have a local lock in the driver structure.)
That will have to be changed in the future if they wish to have their
struct device * in read-only-memory.
Cc: Rafael J. Wysocki <rafael@kernel.org>
Reviewed-by: Alex Elder <elder@kernel.org>
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the FIELD_GET() macro instead of open coding the masks and shifts.
This makes the code more compact and improves readability as it avoids
the need to wrap excessively long lines.
Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
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>
In order to add lane margining support for retimers make the margining
functions take sideband target and retimer index as parameters. This
makes it possible to access both router and retimer sideband using the
same functions.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We are going to expand lane margining support for retimers too so split
out the generic margining functionality out of being specific to USB4
ports.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This makes it possible to read and write USB4 port and retimer sideband
registers through debugfs which is useful for debugging and manufacturing
purposes. We add "sb_regs" debugfs attribute under each USB4 port and
retimer that is used to access the sideband.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
It is supposed to be close with the other lane margining functions so
move it there. No functional changes.
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>
The margin debugfs node controls the "Enable Margin Test" field of the
lane margining operations. This field selects between either low or high
voltage margin values for voltage margin test or left or right timing
margin values for timing margin test.
According to the USB4 specification, whether or not the "Enable Margin
Test" control applies, depends on the values of the "Independent
High/Low Voltage Margin" or "Independent Left/Right Timing Margin"
capability fields for voltage and timing margin tests respectively. The
pre-existing condition enabled the debugfs node also in the case where
both low/high or left/right margins are returned, which is incorrect.
This change only enables the debugfs node in question, if the specific
required capability values are met.
Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com>
Fixes: d0f1e0c2a6 ("thunderbolt: Add support for receiver lane margining")
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This includes following USB4/Thunderbolt changes for the v6.10 merge
window:
- Enable NVM firmare upgrade on Intel Maple Ridge Thunderbolt 4
controller
- Improve USB3 tunnel bandwidth calculation
- Improve sideband access
- Minor cleanups and fixes.
All these have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAmY9p68gHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKAncQ/7BHfSiGFgAxo0
COALJ0sChaYBT7qOfnf6QVJv6jPV1pfRx21FrTwjbwQXGZVT+Q2QmMK66TvHviO2
5pCeJdpdphMpUR5ZQE1USY4Ig3DW3TBmDEx2HxtdOzl7ot60eVQNpcnrrp+wWJNO
ha1tWnDt2mTVsZoASDReztdZCZbZXS0zW3ODdfXMqaeRxI+/IwvmfmRo5YvL6qBG
ChdMHTMKEgPSvZY918fMVoJi46ugOiTJgXfk4X7fmGeRIMUPpcU5k6hk9TDxK9bV
L2Xi930AhSACzTNto+mLEyfdNeErkot2V4Yhx5OVaKPpLdjOjN6p1Lrh5GkcgP+F
mGG1as793JZX7VyBDrIhWp2wglELqQcZKTlmQJkuXPXyDCfLWeJTaqKDx9z1de4s
w0ltpS5cgDyeCRNLTTmY5ARq+CyUVMb/tE687ZkqWrrxYRaMfsHCZe0pupZgPVKA
OzH9ItC1xlDf7ErpiZI6whOeTunJ9pBRvhQmx2m5MYq+Gcs/kC/EH0NMO6nTjLz5
7bbTiih7WMgJUFR953dUbC/LqAo0Xg5V2dSlSU+rAJWQ4ocOVRasCK3jxp9StMzf
bdaJZbD7mDR5BT/xVhMYDYZnZiG2huwPag6L1OXyRSVPl1RLJpznIu3TvcqcunLN
MQPZKiW3S3tGPYlRmAhxmi+M2nwdbP4=
=fiCC
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next
Mika writes:
thunderbolt: Changes for v6.10 merge window
This includes following USB4/Thunderbolt changes for the v6.10 merge
window:
- Enable NVM firmare upgrade on Intel Maple Ridge Thunderbolt 4
controller
- Improve USB3 tunnel bandwidth calculation
- Improve sideband access
- Minor cleanups and fixes.
All these have been in linux-next with no reported issues.
* tag 'thunderbolt-for-v6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
thunderbolt: Correct trace output of firmware connection manager packets
thunderbolt: Fix kernel-doc for tb_tunnel_alloc_dp()
thunderbolt: Fix uninitialized variable in tb_tunnel_alloc_usb3()
thunderbolt: There are only 5 basic router registers in pre-USB4 routers
thunderbolt: No need to loop over all retimers if access fails
thunderbolt: Increase sideband access polling delay
thunderbolt: Get rid of TB_CFG_PKG_PREPARE_TO_SLEEP
thunderbolt: Use correct error code with ERROR_NOT_SUPPORTED
thunderbolt: Allow USB3 bandwidth to be lower than maximum supported
thunderbolt: Fix calculation of consumed USB3 bandwidth on a path
thunderbolt: Enable NVM upgrade support on Intel Maple Ridge
These are special packets that the drivers sends directly to the
firmware connection manager (ICM). These do not have route string
because they are always consumed by the firmware connection manager
running on the host router, so hard-code that in the output accordingly.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
In case of no bandwidth available for DP tunnel, the function get the arguments
@max_up and @max_down set to zero. Fix the kernel-doc to describe more
accurately the purpose of the function.
No functional changes.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently in case of no bandwidth available for USB3 tunnel, we are left
with uninitialized variable that can lead to huge negative allocated
bandwidth.
Fix this by initializing the variable to zero. While there, fix the
kernel-doc to describe more accurately the purpose of the function
tb_tunnel_alloc_usb3().
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/linux-usb/6289898b-cd63-4fb8-906a-1b6977321af9@moroto.mountain/
Fixes: 25d905d2b8 ("thunderbolt: Allow USB3 bandwidth to be lower than maximum supported")
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Intel pre-USB4 routers only have ROUTER_CS_0 up to ROUTER_CS_4 and it
immediately follows the TMU router registers. Correct this accordingly.
Reported-by: Rajaram Regupathy <rajaram.regupathy@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
When we read the NVM authentication status or unsetting the inbound SBTX
there is no point to continue the loop after first access to a retimer
fails because there won't be any more retimers after this anyway so bail
out from the loops early.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The USB4 sideband access is slow compared to the high-speed link and the
access timing parameters are tens of milliseconds according the spec. To
avoid too much unnecessary polling for the sideband pass the wait delay
to usb4_port_wait_for_bit() and use larger (5ms) value compared to the
high-speed access.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We check for -EOPNOTSUPP but tb_xdp_handle_error() translated it to
-ENOTSUPP instead which is dealt as "transient" error and retried after
a while. Fix this so that we bail out early when the other side clearly
tells us it is does not support this.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently USB3 tunnel setup fails if USB4 link available bandwidth is too low
to allow USB3 Maximum Supported Link Rate. In reality, this limitation is not
needed, and may cause failure of USB3 tunnel establishment, if USB4 link
available bandwidth is lower than USB3 Maximum Supported Link Rate. E.g. if we
connect to USB4 v1 host router, a USB4 v1 device router, via 10 Gb/s cable.
Hence, here we discard this limitation, and now we only limit USB3 bandwidth
allocation to be not higher than 90% of USB3 Max Supported Link Rate (for first
USB3 tunnel only).
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently, when setup a new USB3 tunnel that is starting from downstream USB3
adapter of first depth router (or deeper), to upstream USB3 adapter of a second
depth router (or deeper), we calculate consumed bandwidth. For this calculation
we take into account first USB3 tunnel consumed bandwidth while we shouldn't,
because we just recalculating the first USB3 tunnel allocated bandwidth.
Fix that, so that more bandwidth is available for the new USB3 tunnel being
setup.
While there, fix the kernel-doc to decribe more accurately the purpose of the
function.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently we notify PM core about occurred wakes after any resume. This
is not actually needed after resume from runtime suspend. Hence, notify
PM core about occurred wakes only after resume from system sleep. Also,
if the wake occurred in USB4 router upstream port, we don't notify the
PM core about it since it is not actually needed and can cause
unexpected autowake (e.g. if /sys/power/wakeup_count is used).
While there add the missing kernel-doc for tb_switch_resume().
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently we don't configure correctly the wake events after unplug of device
router. What can happen is that the downstream ports of host router will be
configured to wake on: USB4-wake and wake-on-disconnect, but not on
wake-on-connect. This may cause the later plugged device not to wake the
domain and fail in enumeration. Fix this by clearing downstream port's "USB4
Port is Configured" bit, after unplug of a device router.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Intel Maple Ridge supports NVM firmware upgrade with the same flows used
on previous discrete Thunderbolt contollers from Intel (such as Titan
Ridge). Advertise NVM upgrade support for Maple Ridge in icm_probe() to
expose the corresponding files in /sys/bus/thunderbolt. The NVM firmware
process was successfully tested on a system with a JHL8540 controller
(ASUS ProArt Z790-CREATOR).
Signed-off-by: Alex James <git@alextjam.es>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Probably due to a firmware bug Dell TB16 dock announces that one of its
DisplayPort adapters is actually DP IN. Now this is possible and used
with some external GPUs but not likely in this case as we are dealing
with a dock. Anyways the problem is that the driver tries to create a
DisplayPort tunnel between adapters of the same router which then shows
to user that there is no picture on the display (because there are no
available DP OUT adapters on the dock anymore).
Fix this by not creating DisplayPort tunnels between adapters that are
on the same router.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10265
Fixes: 274baf695b ("thunderbolt: Add DP IN added last in the head of the list of DP resources")
Cc: Gil Fine <gil.fine@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Here is the big set of USB and Thunderbolt changes for 6.9-rc1. Lots of
tiny changes and forward progress to support new hardware and better
support for existing devices. Included in here are:
- Thunderbolt (i.e. USB4) updates for newer hardware and uses as more
people start to use the hardware
- default USB authentication mode Kconfig and documentation update to
make it more obvious what is going on
- USB typec updates and enhancements
- usual dwc3 driver updates
- usual xhci driver updates
- function USB (i.e. gadget) driver updates and additions
- new device ids for lots of drivers
- loads of other small updates, full details in the shortlog
All of these, including a "last minute regression fix" have been in
linux-next with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZfwpzA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymS9QCdEuF6KJFLOrDrGS4NbZNSUPIVF6oAn350r4NX
CMZah37Dfr1VDCOOV4gQ
=HACL
-----END PGP SIGNATURE-----
Merge tag 'usb-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB / Thunderbolt updates from Greg KH:
"Here is the big set of USB and Thunderbolt changes for 6.9-rc1. Lots
of tiny changes and forward progress to support new hardware and
better support for existing devices. Included in here are:
- Thunderbolt (i.e. USB4) updates for newer hardware and uses as more
people start to use the hardware
- default USB authentication mode Kconfig and documentation update to
make it more obvious what is going on
- USB typec updates and enhancements
- usual dwc3 driver updates
- usual xhci driver updates
- function USB (i.e. gadget) driver updates and additions
- new device ids for lots of drivers
- loads of other small updates, full details in the shortlog
All of these, including a "last minute regression fix" have been in
linux-next with no reported issues"
* tag 'usb-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (185 commits)
usb: usb-acpi: Fix oops due to freeing uninitialized pld pointer
usb: gadget: net2272: Use irqflags in the call to net2272_probe_fin
usb: gadget: tegra-xudc: Fix USB3 PHY retrieval logic
phy: tegra: xusb: Add API to retrieve the port number of phy
USB: gadget: pxa27x_udc: Remove unused of_gpio.h
usb: gadget/snps_udc_plat: Remove unused of_gpio.h
usb: ohci-pxa27x: Remove unused of_gpio.h
usb: sl811-hcd: only defined function checkdone if QUIRK2 is defined
usb: Clarify expected behavior of dev_bin_attrs_are_visible()
xhci: Allow RPM on the USB controller (1022:43f7) by default
usb: isp1760: remove SLAB_MEM_SPREAD flag usage
usb: misc: onboard_hub: use pointer consistently in the probe function
usb: gadget: fsl: Increase size of name buffer for endpoints
usb: gadget: fsl: Add of device table to enable module autoloading
usb: typec: tcpm: add support to set tcpc connector orientatition
usb: typec: tcpci: add generic tcpci fallback compatible
dt-bindings: usb: typec-tcpci: add tcpci fallback binding
usb: gadget: fsl-udc: Replace custom log wrappers by dev_{err,warn,dbg,vdbg}
usb: core: Set connect_type of ports based on DT node
dt-bindings: usb: Add downstream facing ports to realtek binding
...
This includes following USB4/Thunderbolt changes for the v6.9 merge
window:
- Reset the topology also for USB4 v1 routers on driver load
- DisplayPort tunneling and bandwidth allocation mode improvements
- Tracepoint support for the control channel
- Couple of minor fixes and cleanups.
All these have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAmXgU5ogHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKCD/g/+O9AmkgQwyUr8
EoDHjFBRTomGMh/eR2g2JfEIpAj0hqRYDHxbSC5ZyWZWIaMuj7RiBBkU3aS+PioD
KAWm46NB80Un83fO2gGV+t0cCfcTqxdU2gtsK9TEAydkKctJ+HK+htMvJUaorJV0
35uPjCwuAWPrb0MINNysKbRy/QLrCU0+EF6Zl/1Kdg2M7DPNT15He4UTbwgFuIhp
aEyRz6221yA6FJB9oV7W7ajSnA7v4o8RmyAHN2yYHuHwAsvRaFFvuB2PMQLuA0G1
+HQLoZE/mse/2hwsGIk01peHkJd5nkntsOP4DvOAig7QV8A8INP29nh+5lGN+m0C
UN8TuFjpIMe3tfr5H8dosGoJH8o3+h22F2OdcGai0r5oCtAufv8OzOWNkEJACXcU
372raqDW7SXpSx0UdkHbJivOBG1xAMkqZxqV18SI5uDMEcxAw1kVp3J7+KDRfJyk
p9mgElW7qj20LQ7dF1kyWVu7TO12xRSGlbIHbGnXCDhMS3ZhKVwrOAXxnRGf0XBc
IHcPlQUTzjlc0n7MSzVQdFaeBLgtrqk23SGMPgxfgqPigtJCpi8E0E1d5SMyAiqE
YrnTkf+RY5vrfv8denKSWr0LTFFqdGq5asjoFhEWffxbMvaxi1y8v32haT+ddUFi
UYIV3yz419c60aiuEfswSg0J0TpvF44=
=9hHe
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next
Mika writes:
thunderbolt: Changes for v6.9 merge window
This includes following USB4/Thunderbolt changes for the v6.9 merge
window:
- Reset the topology also for USB4 v1 routers on driver load
- DisplayPort tunneling and bandwidth allocation mode improvements
- Tracepoint support for the control channel
- Couple of minor fixes and cleanups.
All these have been in linux-next with no reported issues.
* tag 'thunderbolt-for-v6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: (23 commits)
thunderbolt: Constify the struct device_type usage
thunderbolt: Add trace events support for the control channel
thunderbolt: Keep the domain powered when USB4 port is in redrive mode
thunderbolt: Improve DisplayPort tunnel setup process to be more robust
thunderbolt: Calculate DisplayPort tunnel bandwidth after DPRX capabilities read
thunderbolt: Reserve released DisplayPort bandwidth for a group for 10 seconds
thunderbolt: Introduce tb_tunnel_direction_downstream()
thunderbolt: Re-order bandwidth group functions
thunderbolt: Fail the failed bandwidth request properly
thunderbolt: Log an error if DPTX request is not cleared
thunderbolt: Handle bandwidth allocation mode disable request
thunderbolt: Re-calculate estimated bandwidth when allocation mode is enabled
thunderbolt: Use DP_LOCAL_CAP for maximum bandwidth calculation
thunderbolt: Correct typo in host_reset parameter
thunderbolt: Skip discovery also in USB4 v2 host
thunderbolt: Reset only non-USB4 host routers in resume
thunderbolt: Remove usage of the deprecated ida_simple_xx() API
thunderbolt: Fix rollback in tb_port_lane_bonding_enable() for lane 1
thunderbolt: Fix XDomain rx_lanes_show and tx_lanes_show
thunderbolt: Reset topology created by the boot firmware
...
This includes one USB4/Thunderbolt fix for v6.8-rc7:
- Fix NULL pointer dereference in tb_port_update_credits() on
Apple Thunderbolt 1 hardware.
This has been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAmXcWZkgHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKBaKBAAojQDV4aSxREQ
A2jGbef5PkEhhRS4ALddQqdAbVeB53IvdghnLUTQKQKlGI8HCnhrd4Q8Kc3zc0zV
hI7IUbO/S2IZ3iw16kIYTTWAAJGetSLneZ/5kd+UNc5aVcSqyw8er8IMT1IAUfKB
lLTJDu4sanb/pszyBfwNC0Ecp/CwpFQp6R27w4/ePUMw2Z09OlUdQjHWCmRnS8en
Vs3RssAdF7C9GylRgYi9GKgG6m9ZtxjFWD7QnjxVKChWlpoyZ3l9a6QDQRB1pdCC
kXA0qPvYsZAVqdwk0fHaMxfV2tYJcqsA8dG9NDj0J0tWryw62phc3esxX4FujClQ
X/1D2XOncwn1OIbW8debEEuTXJq8WnOaENX6NkLdMaXBPAR3maiTnKIO+drlaIQE
1eA6pu2vcuGq5BkHd4j1704S1GwymurpUtb421QKo7zVNLrUaMnjKxFdUawaOeji
Hw4eQFRoERhQ+SLc4r7f2H8hnR4ryUN6TC3F58hub8X4fFpNxTN92qc4Pht1WiNr
/Cb0sRwEMDGTiTiWupjLRsyYI6DS+8mSz7312FW/0c643IPz9zSt+dnjTepQGre1
0iy06xjYi/MXcYNps1kREAeBzKBQJ/WHjWZMJQMETK51bbIVylDfRCSHzTUxtzCP
Ny+rTa6hN0ISAMB2QGouMIXhMqgJ6dY=
=FddI
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-linus
Mika writes:
thunderbolt: Fix for v6.8-rc7
This includes one USB4/Thunderbolt fix for v6.8-rc7:
- Fix NULL pointer dereference in tb_port_update_credits() on
Apple Thunderbolt 1 hardware.
This has been in linux-next with no reported issues.
* tag 'thunderbolt-for-v6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
thunderbolt: Fix NULL pointer dereference in tb_port_update_credits()
Since commit aed65af1cc ("drivers: make device_type const"), the driver
core can properly handle constant struct device_type. Move the
tb_domain_type, tb_retimer_type, tb_switch_type, usb4_port_device_type,
tb_service_type and tb_xdomain_type variables to be constant structures as
well, placing it into read-only memory which can not be modified at
runtime.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
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 <gil.fine@linux.intel.com>
Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
If a DiplayPort cable is directly connected to the host routers USB4
port, there is no tunnel involved but the port is in "redrive" mode
meaning that it is re-driving the DisplayPort signals from its
DisplayPort source. In this case we need to keep the domain powered on
otherwise once the domain enters D3cold the connected monitor blanks
too.
Since this happens only on Intel Barlow Ridge add a quirk that takes
runtime PM reference if we detect that the USB4 port entered redrive
mode (and release it once it exits the mode).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
After DisplayPort tunnel setup, we add verification that the DPRX
capabilities read process completed. Otherwise, we bail out, teardown
the tunnel, and try setup another DisplayPort tunnel using next
available DP IN adapter. We do so till all DP IN adapters tried. This
way, we avoid allocating DP IN adapter and (bandwidth for it) for
unusable tunnel.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
According to USB4 Connection Manager guide, after DisplayPort tunnel was
setup, the DPRX capabilities read is performed by the DPTX. According to
VESA spec, this shall be completed within 5 seconds after the DisplayPort
tunnel was setup. Hence, if the bit: DPRX Capabilities Read Done, was
not set to '1' by this time, we timeout and fail calculating DisplayPort
tunnel consumed bandwidth.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The USB4 spec says that the Connection Manager should reserve the
bandwidth that is released in the same group for 10 seconds before it
can be shared with other groups. Add support for this. We also delay the
symmetric transition by that same 10 seconds to avoid any unnecessary
transitions (i.e if the released bandwidth is used by another
DisplayPort tunnel in the same group the link can stay asymmetric the
whole time).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This helper takes tunnel as parameter. Convert existing code to call
this where possible.
No functional changes.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This is needed by the following patches so that we do not have to add
forward declaratations for any of these. Separating the move and the
actual changes also makes it easier to review the code.
No functional changes.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The USB4 spec says that if the Connection Manager writes Allocated_BW
that is smaller than Requested_BW, the DisplayPort IN adapter signals
this failure back to the DPTX (graphics driver). Implement this by
rewriting the same allocated bandwidth values back.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Graphics can disable DisplayPort bandwidth allocation mode as well so if
this make sure to reset the tunnel state accordingly.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
When we program the initial bandwidth estimation the DPTX (graphics
driver) has not yet read the capabilities of the monitor so the values
used are the highest possible of the involved DisplayPort IN and OUT
adapters, not the actual monitor capabilities. To allow the graphics
more accurate bandwidth estimation re-calculate it once we receive the
bandwidth allocation mode enabled notification.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The DisplayPort IN adapter DP_LOCAL_CAP holds the aggregated
capabilities and gets updated after graphics side does the DPRX
capabilities read so we should use this to figure out the maximum
possible bandwidth for the DisplayPort tunnel.
While there make the variable name to match better what it is used for
and add kernel-doc comment to the function.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Olliver reported that his system crashes when plugging in Thunderbolt 1
device:
BUG: kernel NULL pointer dereference, address: 0000000000000020
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:tb_port_do_update_credits+0x1b/0x130 [thunderbolt]
Call Trace:
<TASK>
? __die+0x23/0x70
? page_fault_oops+0x171/0x4e0
? exc_page_fault+0x7f/0x180
? asm_exc_page_fault+0x26/0x30
? tb_port_do_update_credits+0x1b/0x130
? tb_switch_update_link_attributes+0x83/0xd0
tb_switch_add+0x7a2/0xfe0
tb_scan_port+0x236/0x6f0
tb_handle_hotplug+0x6db/0x900
process_one_work+0x171/0x340
worker_thread+0x27b/0x3a0
? __pfx_worker_thread+0x10/0x10
kthread+0xe5/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
</TASK>
This is due the fact that some Thunderbolt 1 devices only have one lane
adapter. Fix this by checking for the lane 1 before we read its credits.
Reported-by: Olliver Schinagl <oliver@schinagl.nl>
Closes: https://lore.kernel.org/linux-usb/c24c7882-6254-4e68-8f22-f3e8f65dc84f@schinagl.nl/
Fixes: 81af2952e6 ("thunderbolt: Add support for asymmetric link")
Cc: stable@vger.kernel.org
Cc: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
It should say USB4 now since we reset by default all USB4 host routers.
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
If the host router is reset, there is no point running discovery as the
links are down. Furthermore this prevents CL-state enabling. For this
reason skip discovery in USB4 v2 host the same way we do with USB4 v1.
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
There is no need to reset the USB4 host routers on resume because they
are reset already and this may cause problems if the link does not come
up soon enough. For this reason limit this to happen in non-USB4 host
routers only (that's Apple systems with Intel Thunderbolt controllers).
Fixes: 59a54c5f3d ("thunderbolt: Reset topology created by the boot firmware")
Cc: Sanath S <Sanath.S@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The bit 23, CM TBT3 Not Supported (CNS), in ROUTER_CS_5 indicates
whether a USB4 Connection Manager is TBT3-Compatible and should be:
0b for TBT3-Compatible
1b for Not TBT3-Compatible
Fixes: b04079837b ("thunderbolt: Add initial support for USB4")
Cc: stable@vger.kernel.org
Signed-off-by: Mohammad Rahimi <rahimi.mhmmd@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
ida_alloc() and ida_free() should be preferred to the deprecated
ida_simple_get() and ida_simple_remove().
Note that the upper limit of ida_simple_get() is exclusive, but the one of
ida_alloc_range()/ida_alloc_max() is inclusive. So a -1 has been added
when needed.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
