summaryrefslogtreecommitdiff
path: root/drivers/thunderbolt
AgeCommit message (Collapse)Author
2025-01-28Merge tag 'driver-core-6.14-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core and debugfs updates from Greg KH: "Here is the big set of driver core and debugfs updates for 6.14-rc1. Included in here is a bunch of driver core, PCI, OF, and platform rust bindings (all acked by the different subsystem maintainers), hence the merge conflict with the rust tree, and some driver core api updates to mark things as const, which will also require some fixups due to new stuff coming in through other trees in this merge window. There are also a bunch of debugfs updates from Al, and there is at least one user that does have a regression with these, but Al is working on tracking down the fix for it. In my use (and everyone else's linux-next use), it does not seem like a big issue at the moment. Here's a short list of the things in here: - driver core rust bindings for PCI, platform, OF, and some i/o functions. We are almost at the "write a real driver in rust" stage now, depending on what you want to do. - misc device rust bindings and a sample driver to show how to use them - debugfs cleanups in the fs as well as the users of the fs api for places where drivers got it wrong or were unnecessarily doing things in complex ways. - driver core const work, making more of the api take const * for different parameters to make the rust bindings easier overall. - other small fixes and updates All of these have been in linux-next with all of the aforementioned merge conflicts, and the one debugfs issue, which looks to be resolved "soon"" * tag 'driver-core-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (95 commits) rust: device: Use as_char_ptr() to avoid explicit cast rust: device: Replace CString with CStr in property_present() devcoredump: Constify 'struct bin_attribute' devcoredump: Define 'struct bin_attribute' through macro rust: device: Add property_present() saner replacement for debugfs_rename() orangefs-debugfs: don't mess with ->d_name octeontx2: don't mess with ->d_parent or ->d_parent->d_name arm_scmi: don't mess with ->d_parent->d_name slub: don't mess with ->d_name sof-client-ipc-flood-test: don't mess with ->d_name qat: don't mess with ->d_name xhci: don't mess with ->d_iname mtu3: don't mess wiht ->d_iname greybus/camera - stop messing with ->d_iname mediatek: stop messing with ->d_iname netdevsim: don't embed file_operations into your structs b43legacy: make use of debugfs_get_aux() b43: stop embedding struct file_operations into their objects carl9170: stop embedding file_operations into their objects ...
2025-01-13Merge 6.13-rc7 into driver-core-nextGreg Kroah-Hartman
We need the debugfs / driver-core fixes in here as well for testing and to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-05thunderbolt: Expose router DROM through debugfsMika Westerberg
Router DROM contains information that might be usable for development and debugging purposes. For example when new entries are added to the USB4 spec it is useful to be able to look for them without need to change the kernel. For this reason expose the DROM through debugfs. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-01-03driver core: Constify API device_find_child() and adapt for various usagesZijun Hu
Constify the following API: struct device *device_find_child(struct device *dev, void *data, int (*match)(struct device *dev, void *data)); To : struct device *device_find_child(struct device *dev, const void *data, device_match_t match); typedef int (*device_match_t)(struct device *dev, const void *data); with the following reasons: - Protect caller's match data @*data which is for comparison and lookup and the API does not actually need to modify @*data. - Make the API's parameters (@match)() and @data have the same type as all of other device finding APIs (bus|class|driver)_find_device(). - All kinds of existing device match functions can be directly taken as the API's argument, they were exported by driver core. Constify the API and adapt for various existing usages. BTW, various subsystem changes are squashed into this commit to meet 'git bisect' requirement, and this commit has the minimal and simplest changes to complement squashing shortcoming, and that may bring extra code improvement. Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by: Uwe Kleine-König <ukleinek@kernel.org> # for drivers/pwm Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20241224-const_dfc_done-v5-4-6623037414d4@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-03thunderbolt: Handle DisplayPort tunnel activation asynchronouslyMika Westerberg
Sometimes setting up a DisplayPort tunnel may take quite long time. The reason is that the graphics driver (DPRX) is expected to issue read of certain monitor capabilities over the AUX channel and the "suggested" timeout from VESA is 5 seconds. If there is no graphics driver loaded this does not happen and currently we timeout and tear the tunnel down. The reason for this is that at least Intel discrete USB4 controllers do not send plug/unplug events about whether the DisplayPort cable from the GPU to the controller is connected or not, so in order to "release" the DisplayPort OUT adapter (the one that has monitor connected) we must tear the tunnel down after this timeout has been elapsed. In typical cases there is always graphics driver loaded, and also all the cables are connected but for instance in Intel graphics CI they only load the graphics driver after the system is fully booted up. This makes the driver to tear down the DisplayPort tunnel. To help this case we allow passing bigger or indefinite timeout through a new module parameter (dprx_timeout). To keep the driver bit more responsive during that time we change the way DisplayPort tunnels get activated. We first do the normal tunnel setup and then run the polling of DPRX capabilities read completion in a separate worker. This also makes the driver to accept bandwidth requests to already established DisplayPort tunnels more responsive. If the tunnel still fails to establish we will tear it down and remove the DisplayPort IN adapter from the dp_resource list to avoid using it again (unless we get hotplug to that adapter). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-01-03thunderbolt: Rework tb_tunnel_consumed_bandwidth()Mika Westerberg
Rework to avoid the goto as it only makes it confusing. Move logging to happen at the end so we can see all the tunnels this is being called. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-01-03thunderbolt: Move forward declarations in one placeMika Westerberg
Sometimes we need to have these but move them into one place so that the code is bit more understanable. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-01-03thunderbolt: Pass reason to tb_dp_resource_unavailable()Mika Westerberg
Since we are going to call this also when DisplayPort tunnel establishment fails it is useful to have the reason logged. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-01-03thunderbolt: Drop tb_tunnel_restart()Mika Westerberg
It is pretty much the same as tb_tunnel_activate() excepts does check for already activated paths. This is not needed anymore and makes it more streamlined so drop tb_tunnel_restart() in favour of tb_tunnel_activate(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-01-03thunderbolt: Rework how tunnel->[init|deinit] hooks are calledMika Westerberg
The way these are called is not exactly symmetric as it is supposed to be: the former is called when tunnel is being activated and the latter is called when it is being released (not when it is being de-activated). Furthermore host-to-host (DMA) tunnels are abusing the ->deinit hook to clear out the credits. This makes it quite hard to follow what is being called and when. For these reasons rework the two "init" hooks to be called symmetrically and rename them accordingly. For the DMA one, add a new hook that is specifically used to run clean up for the tunnel when its memory is being released. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-01-03thunderbolt: Show path name in debug log when path is deactivatedMika Westerberg
Similarly as we do when activating the path. Helps in debugging. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-01-03thunderbolt: Make tb_tunnel_one_dp() return voidMika Westerberg
The boolean return value is never used so we can make this return void instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-01-03thunderbolt: Increase DPRX capabilities read timeoutMika Westerberg
Some graphics drivers such as i915 support runtime power management and if there is nothing connected at the moment they will runtime suspend to save power. At least i915 is polling for new connections every 10 seconds if the hardware does support sending PME. To allow i915 and other graphics from detect the just established DisplayPort tunnel allow the DPRX capabilities read to take up to 12 seconds. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-01-03thunderbolt: Debug log an invalid config space reply just onceMika Westerberg
These can mess up the debug log if a router does not implement the config space register blocks fully and we are reading registers through debugfs. To avoid this, just log it once. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-01-03thunderbolt: Log config space when invalid config space reply is receivedMika Westerberg
For debugging purposes helps to see the config space that was being accessed. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-01-03thunderbolt: Drop doubled empty line from ctl.hMika Westerberg
No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-01-03thunderbolt: debugfs: Add write capability to path config spaceGil Fine
Currently debugfs interface allows writing of router, adapter and counters config spaces but not for paths. However, it can be useful during debugging to modify path config space so for this reason add this support to the debugfs interface as well. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-12-16thunderbolt: Improve redrive mode handlingMika Westerberg
When USB-C monitor is connected directly to Intel Barlow Ridge host, it goes into "redrive" mode that basically routes the DisplayPort signals directly from the GPU to the USB-C monitor without any tunneling needed. However, the host router must be powered on for this to work. Aaron reported that there are a couple of cases where this will not work with the current code: - Booting with USB-C monitor plugged in. - Plugging in USB-C monitor when the host router is in sleep state (runtime suspended). - Plugging in USB-C device while the system is in system sleep state. In all these cases once the host router is runtime suspended the picture on the connected USB-C display disappears too. This is certainly not what the user expected. For this reason improve the redrive mode handling to keep the host router from runtime suspending when detect that any of the above cases is happening. Fixes: a75e0684efe5 ("thunderbolt: Keep the domain powered when USB4 port is in redrive mode") Reported-by: Aaron Rainbolt <arainbolt@kfocus.org> Closes: https://lore.kernel.org/linux-usb/20241009220118.70bfedd0@kf-ir16/ Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-12-11thunderbolt: Don't display nvm_version unless upgrade supportedMario Limonciello
The read will never succeed if NVM wasn't initialized due to an unknown format. Add a new callback for visibility to only show when supported. Cc: stable@vger.kernel.org Fixes: aef9c693e7e5 ("thunderbolt: Move vendor specific NVM handling into nvm.c") Reported-by: Richard Hughes <hughsient@gmail.com> Closes: https://github.com/fwupd/fwupd/issues/8200 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-12-10thunderbolt: Add support for Intel Panther Lake-M/PMika Westerberg
Intel Panther Lake-M/P has the same integrated Thunderbolt/USB4 controller as Lunar Lake. Add these PCI IDs to the driver list of supported devices. Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-11-29Merge tag 'usb-6.13-rc1' of ↵Linus Torvalds
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.13-rc1. Overall, a pretty slow development cycle, the majority of the work going into the debugfs interface for the thunderbolt (i.e. USB4) code, to help with debugging the myrad ways that hardware vendors get their interfaces messed up. Other than that, here's the highlights: - thunderbolt changes and additions to debugfs interfaces - lots of device tree updates for new and old hardware - UVC configfs gadget updates and new apis for features - xhci driver updates and fixes - dwc3 driver updates and fixes - typec driver updates and fixes - lots of other small updates and fixes, full details in the shortlog All of these have been in linux-next for a while with no reported problems" * tag 'usb-6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (148 commits) usb: typec: tcpm: Add support for sink-bc12-completion-time-ms DT property dt-bindings: usb: maxim,max33359: add usage of sink bc12 time property dt-bindings: connector: Add time property for Sink BC12 detection completion usb: dwc3: gadget: Remove dwc3_request->needs_extra_trb usb: dwc3: gadget: Cleanup SG handling usb: dwc3: gadget: Fix looping of queued SG entries usb: dwc3: gadget: Fix checking for number of TRBs left usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED Revert "usb: gadget: composite: fix OS descriptors w_value logic" usb: ehci-spear: fix call balance of sehci clk handling routines USB: make to_usb_device_driver() use container_of_const() USB: make to_usb_driver() use container_of_const() USB: properly lock dynamic id list when showing an id USB: make single lock for all usb dynamic id lists drivers/usb/storage: refactor min with min_t drivers/usb/serial: refactor min with min_t drivers/usb/musb: refactor min/max with min_t/max_t drivers/usb/mon: refactor min with min_t drivers/usb/misc: refactor min with min_t drivers/usb/host: refactor min/max with min_t/max_t ...
2024-11-12Merge tag 'thunderbolt-for-v6.13-rc1' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next Mika writes: thunderbolt: Changes for v6.13 merge window This includes following USB4/Thunderbolt changes for the v6.13 merge window: - Add Gen 4 receiver lane margining support. - Replace usage of deprecated PCI functions. All these have been in linux-next with no reported issues. * tag 'thunderbolt-for-v6.13-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Replace deprecated PCI functions thunderbolt: debugfs: Implement asymmetric lane margining thunderbolt: debugfs: Don't hardcode margining results size thunderbolt: debugfs: Refactor hardware margining result parsing thunderbolt: debugfs: Replace margining lane numbers with an enum thunderbolt: debugfs: Replace "both lanes" with "all lanes" thunderbolt: debugfs: Implement Gen 4 margining eye selection thunderbolt: debugfs: Add USB4 Gen 4 margining capabilities thunderbolt: Don't hardcode margining capabilities size
2024-11-07Merge tag 'thunderbolt-for-v6.12-rc7' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-linus thunderbolt: Fixes for v6.12-rc7 This includes following USB4/Thunderbolt fixes for v6.12-rc7: - Fix for retimer enumeration. - Fix connection issue with Pluggable UD-4VPD USB4 dock. Both have been in linux-next with no reported issues. * tag 'thunderbolt-for-v6.12-rc7' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Fix connection issue with Pluggable UD-4VPD dock thunderbolt: Add only on-board retimers when !CONFIG_USB4_DEBUGFS_MARGINING
2024-11-07thunderbolt: Replace deprecated PCI functionsPhilipp Stanner
pcim_iomap_table() and pcim_request_regions() have been deprecated in commit e354bb84a4c1 ("PCI: Deprecate pcim_iomap_table(), pcim_iomap_regions_request_all()") and commit d140f80f60358 ("PCI: Deprecate pcim_iomap_regions() in favor of pcim_iomap_region()"). Replace these functions with pcim_iomap_region(). Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-11-05thunderbolt: Fix connection issue with Pluggable UD-4VPD dockMika Westerberg
Rick reported that his Pluggable USB4 dock does not work anymore after upgrading to v6.10 kernel. It looks like commit c6ca1ac9f472 ("thunderbolt: Increase sideband access polling delay") makes the device router enumeration happen later than what might be expected by the dock (although there is no such limit in the USB4 spec) which probably makes it assume there is something wrong with the high-speed link and reset it. After the link is reset the same issue happens again and again. For this reason lower the sideband access delay from 5ms to 1ms. This seems to work fine according to Rick's testing. Reported-by: Rick Lahaye <rick@581238.xyz> Closes: https://lore.kernel.org/linux-usb/000f01db247b$d10e1520$732a3f60$@581238.xyz/ Tested-by: Rick Lahaye <rick@581238.xyz> Fixes: c6ca1ac9f472 ("thunderbolt: Increase sideband access polling delay") Cc: stable@vger.kernel.org Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-11-01thunderbolt: debugfs: Implement asymmetric lane marginingAapo Vienamo
Add support for the RX2 receiver which is used as the third receiver in asymmetric links. This requires expanding the results array for the additional third data word of the hardware margining results. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-11-01thunderbolt: debugfs: Don't hardcode margining results sizeAapo Vienamo
Use ARRAY_SIZE() when available or pass in the array size derived from it. This is in preparation for adding another result data word for supporting Gen 4 asymmetric links with an additional lane. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-11-01thunderbolt: debugfs: Refactor hardware margining result parsingAapo Vienamo
Make the result parsing and formatting code less repetitive in preparation for adding another result for Gen 4 asymmetric link support. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-11-01thunderbolt: debugfs: Replace margining lane numbers with an enumAapo Vienamo
Replace the raw values and macros with an enum and use it consistently. No functional changes. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-11-01thunderbolt: debugfs: Replace "both lanes" with "all lanes"Aapo Vienamo
With USB4 Gen 4, the link can be configured into an asymmetric mode, where there are three receivers and only one transmitter. The USB4 specification also uses the "all lanes" nomenclature instead of "both lanes". Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-11-01thunderbolt: debugfs: Implement Gen 4 margining eye selectionAapo Vienamo
Add a debugfs knob for USB4 Gen 4 margining eye selection. Gen 4 uses 3-level pulse amplitude modulation (PAM3) which changes how margining measurements are made because PAM3 has two eyes per lane from which the margins can be measured. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-11-01thunderbolt: debugfs: Add USB4 Gen 4 margining capabilitiesAapo Vienamo
Parse the Gen 4 specific capabilities. Change the return types of independent_voltage_margins() and independent_time_margins() to enums that distinguish between the Gen 2/3 and Gen 4 margins since they behave differently between generations. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-11-01thunderbolt: Don't hardcode margining capabilities sizeAapo Vienamo
Use or pass ARRAY_SIZE() of the capabilities array instead of hardcoding it. USB4 Gen 4 introduces an additional data word, which requires expanding the capabilities array. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-10-29thunderbolt: Add only on-board retimers when !CONFIG_USB4_DEBUGFS_MARGININGMika Westerberg
Normally there is no need to enumerate retimers on the other side of the cable. This is only needed in special cases where user wants to run receiver lane margining against the downstream facing port of a retimer. Furthermore this might confuse the userspace tools such as fwupd because it cannot read the information it expects from these retimers. Fix this by changing the retimer enumeration code to add only on-board retimers when CONFIG_USB4_DEBUGFS_MARGINING is not enabled. Reported-by: AceLan Kao <acelan.kao@canonical.com> Tested-by: AceLan Kao <acelan.kao@canonical.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219420 Cc: stable@vger.kernel.org Fixes: ff6ab055e070 ("thunderbolt: Add receiver lane margining support for retimers") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-10-21thunderbolt: Honor TMU requirements in the domain when setting TMU modeGil Fine
Currently, when configuring TMU (Time Management Unit) mode of a given router, we take into account only its own TMU requirements ignoring other routers in the domain. This is problematic if the router we are configuring has lower TMU requirements than what is already configured in the domain. In the scenario below, we have a host router with two USB4 ports: A and B. Port A connected to device router #1 (which supports CL states) and existing DisplayPort tunnel, thus, the TMU mode is HiFi uni-directional. 1. Initial topology [Host] A/ / [Device #1] / Monitor 2. Plug in device #2 (that supports CL states) to downstream port B of the host router [Host] A/ B\ / \ [Device #1] [Device #2] / Monitor The TMU mode on port B and port A will be configured to LowRes which is not what we want and will cause monitor to start flickering. To address this we first scan the domain and search for any router configured to HiFi uni-directional mode, and if found, configure TMU mode of the given router to HiFi uni-directional as well. Cc: stable@vger.kernel.org Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-10-11thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan()Mika Westerberg
KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: <TASK> dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body. Fixes: ff6ab055e070 ("thunderbolt: Add receiver lane margining support for retimers") CC: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-09-11Merge tag 'thunderbolt-for-v6.12-rc1' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next Mika writes: thunderbolt: Changes for v6.12 merge window This includes following USB4/Thunderbolt changes for the v6.12 merge window: - Improvements for software receiver lane margining - Enable support for optional voltage offset range for receiver lane margining. All these have been in linux-next with no reported issues. * tag 'thunderbolt-for-v6.12-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Improve software receiver lane margining thunderbolt: Add optional voltage offset range for receiver lane margining thunderbolt: Consolidate margining parameters into a structure thunderbolt: Add missing usb4_port_sb_read() to usb4_port_sw_margin()
2024-09-03thunderbolt: Don't create device link from USB4 Host Interface to USB3 xHC hostMathias Nyman
USB core will create device links between tunneled USB3 devices and USB4 Host Interface during USB device creation. Those device links are removed with the tunneled USB3 devices, allowing USB4 Host Interface to runtime suspend if USB3 tunnels are not used. So remove device link creation between USB4 Host Interface and USB3 xHC during NHI probe Reported-by: Rajaram Regupathy <rajaram.regupathy@intel.com> Reported-by: Saranya Gopal <saranya.gopal@intel.com> Tested-by: Saranya Gopal <saranya.gopal@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240830152630.3943215-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-22thunderbolt: Improve software receiver lane marginingR Kannappan
USB4 specification defines the metadata needed to perform software margining, as well as the necessary steps which include waiting for dwell time. - Add dwell_time attribute to set the wait time while performing margining and checking for link errors. - Add error_counter attribute to configure error counter prior to margining test. - Add voltage_time_offset attribute to set the voltage or time offset steps before performing the software margining test. - Perform software margining test for dwell duration, break if there are link errors, stop the clocks and provide results. Below is a minimalistic example how this can be used. Note these values are just examples. The exact values in practice depend on host specific capabilities and the type of measurement to be performed. # cd /sys/kernel/debug/thunderbolt/ROUTER/portX/margining/ # echo software > mode # echo 400 > dwell_time # echo 1 > run As usual the results attribute contains the results of a succesfull run. Signed-off-by: R Kannappan <r.kannappan@intel.com> Co-developed-by: Rene Sapiens <rene.sapiens@intel.com> Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-08-22thunderbolt: Add optional voltage offset range for receiver lane marginingRene Sapiens
Add optional extended voltage offset range support for software and hardware margining as defined by the USB4 specification. If supported, it can be enabled like below: # cd /sys/kernel/debug/thunderbolt/ROUTER/portX/margining/ # echo Y > optional_voltage_offset Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: R Kannappan <r.kannappan@intel.com> Signed-off-by: R Kannappan <r.kannappan@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-08-22thunderbolt: Consolidate margining parameters into a structureRene Sapiens
Consolidate the hardware and software margining parameters into a single structure to reduce the number of parameters passed to the margining functions. Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-08-22thunderbolt: Add missing usb4_port_sb_read() to usb4_port_sw_margin()Aapo Vienamo
Synchronize the operation completion by reading back the software margining operation completion metadata into margining->results. Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Co-developed-by: R Kannappan <r.kannappan@intel.com> Signed-off-by: R Kannappan <r.kannappan@intel.com> Co-developed-by: Rene Sapiens <rene.sapiens@intel.com> Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-08-06thunderbolt: Mark XDomain as unplugged when router is removedMika Westerberg
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>
2024-08-02thunderbolt: Fix memory leaks in {port|retimer}_sb_regs_write()Aapo Vienamo
Add missing free_page() call for the memory allocated by validate_and_copy_from_user(). Fixes: 6d241fa00159 ("thunderbolt: Add sideband register access to debugfs") Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-25Merge tag 'driver-core-6.11-rc1' of ↵Linus Torvalds
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 ...
2024-07-03driver core: have match() callback in struct bus_type take a const *Greg Kroah-Hartman
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>
2024-06-19thunderbolt: debugfs: Use FIELD_GET()Aapo Vienamo
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>
2024-06-17thunderbolt: Add receiver lane margining support for retimersMika Westerberg
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>
2024-06-17thunderbolt: Make margining functions accept target and retimer indexMika Westerberg
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>
2024-06-17thunderbolt: Split out margining from USB4 portMika Westerberg
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>