Here is the big set of USB and Thunderbolt driver updates for 6.15-rc1.
Included in here are:
- Thunderbolt driver and core api updates for new hardware and
features
- usb-storage const array cleanups
- typec driver updates
- dwc3 driver updates
- xhci driver updates and bugfixes
- small USB documentation updates
- usb cdns3 driver updates
- usb gadget driver updates
- other small driver updates and fixes
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZ+2Zaw8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynIgQCaAyMozdrZtTiOs1OcZEuTkoCtKrEAniqe0OiL
s7R6j2NoOIwo9d6hBsjh
=IH7I
-----END PGP SIGNATURE-----
Merge tag 'usb-6.15-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 driver updates for
6.15-rc1. Included in here are:
- Thunderbolt driver and core api updates for new hardware and
features
- usb-storage const array cleanups
- typec driver updates
- dwc3 driver updates
- xhci driver updates and bugfixes
- small USB documentation updates
- usb cdns3 driver updates
- usb gadget driver updates
- other small driver updates and fixes
All of these have been in linux-next for a while with no reported
issues"
* tag 'usb-6.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (92 commits)
thunderbolt: Do not add non-active NVM if NVM upgrade is disabled for retimer
thunderbolt: Scan retimers after device router has been enumerated
usb: host: cdns3: forward lost power information to xhci
usb: host: xhci-plat: allow upper layers to signal power loss
usb: xhci: change xhci_resume() parameters to explicit the desired info
usb: cdns3-ti: run HW init at resume() if HW was reset
usb: cdns3-ti: move reg writes to separate function
usb: cdns3: call cdns_power_is_lost() only once in cdns_resume()
usb: cdns3: rename hibernated argument of role->resume() to lost_power
usb: xhci: tegra: rename `runtime` boolean to `is_auto_runtime`
usb: host: xhci-plat: mvebu: use ->quirks instead of ->init_quirk() func
usb: dwc3: Don't use %pK through printk
usb: core: Don't use %pK through printk
usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev()
dt-bindings: usb: qcom,dwc3: Synchronize minItems for interrupts and -names
usb: common: usb-conn-gpio: switch psy_cfg from of_node to fwnode
usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running
usb: xhci: Don't change the status of stalled TDs on failed Stop EP
xhci: Avoid queuing redundant Stop Endpoint command for stalled endpoint
xhci: Handle spurious events on Etron host isoc enpoints
...
Another set of improvements to the kernel's CRC (cyclic redundancy
check) code:
- Rework the CRC64 library functions to be directly optimized, like what
I did last cycle for the CRC32 and CRC-T10DIF library functions.
- Rewrite the x86 PCLMULQDQ-optimized CRC code, and add VPCLMULQDQ
support and acceleration for crc64_be and crc64_nvme.
- Rewrite the riscv Zbc-optimized CRC code, and add acceleration for
crc_t10dif, crc64_be, and crc64_nvme.
- Remove crc_t10dif and crc64_rocksoft from the crypto API, since they
are no longer needed there.
- Rename crc64_rocksoft to crc64_nvme, as the old name was incorrect.
- Add kunit test cases for crc64_nvme and crc7.
- Eliminate redundant functions for calculating the Castagnoli CRC32,
settling on just crc32c().
- Remove unnecessary prompts from some of the CRC kconfig options.
- Further optimize the x86 crc32c code.
-----BEGIN PGP SIGNATURE-----
iIoEABYIADIWIQSacvsUNc7UX4ntmEPzXCl4vpKOKwUCZ+CGGhQcZWJpZ2dlcnNA
Z29vZ2xlLmNvbQAKCRDzXCl4vpKOK3wRAP4tbnzawUmlIHIF0hleoADXehUgAhMt
NZn15mGvyiuwIQEA8W9qvnLdFXZkdxhxAEvDDFjyrRauL6eGtr/GvCx4AQY=
=wmKG
-----END PGP SIGNATURE-----
Merge tag 'crc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux
Pull CRC updates from Eric Biggers:
"Another set of improvements to the kernel's CRC (cyclic redundancy
check) code:
- Rework the CRC64 library functions to be directly optimized, like
what I did last cycle for the CRC32 and CRC-T10DIF library
functions
- Rewrite the x86 PCLMULQDQ-optimized CRC code, and add VPCLMULQDQ
support and acceleration for crc64_be and crc64_nvme
- Rewrite the riscv Zbc-optimized CRC code, and add acceleration for
crc_t10dif, crc64_be, and crc64_nvme
- Remove crc_t10dif and crc64_rocksoft from the crypto API, since
they are no longer needed there
- Rename crc64_rocksoft to crc64_nvme, as the old name was incorrect
- Add kunit test cases for crc64_nvme and crc7
- Eliminate redundant functions for calculating the Castagnoli CRC32,
settling on just crc32c()
- Remove unnecessary prompts from some of the CRC kconfig options
- Further optimize the x86 crc32c code"
* tag 'crc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: (36 commits)
x86/crc: drop the avx10_256 functions and rename avx10_512 to avx512
lib/crc: remove unnecessary prompt for CONFIG_CRC64
lib/crc: remove unnecessary prompt for CONFIG_LIBCRC32C
lib/crc: remove unnecessary prompt for CONFIG_CRC8
lib/crc: remove unnecessary prompt for CONFIG_CRC7
lib/crc: remove unnecessary prompt for CONFIG_CRC4
lib/crc7: unexport crc7_be_syndrome_table
lib/crc_kunit.c: update comment in crc_benchmark()
lib/crc_kunit.c: add test and benchmark for crc7_be()
x86/crc32: optimize tail handling for crc32c short inputs
riscv/crc64: add Zbc optimized CRC64 functions
riscv/crc-t10dif: add Zbc optimized CRC-T10DIF function
riscv/crc32: reimplement the CRC32 functions using new template
riscv/crc: add "template" for Zbc optimized CRC functions
x86/crc: add ANNOTATE_NOENDBR to suppress objtool warnings
x86/crc32: improve crc32c_arch() code generation with clang
x86/crc64: implement crc64_be and crc64_nvme using new template
x86/crc-t10dif: implement crc_t10dif using new template
x86/crc32: implement crc32_le using new template
x86/crc: add "template" for [V]PCLMULQDQ based CRC functions
...
This is only used to write a new NVM in order to upgrade the retimer
firmware. It does not make sense to expose it if upgrade is disabled.
This also makes it consistent with the router NVM upgrade.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Thomas reported connection issues on AMD system with Pluggable UD-4VPD
dock. After some experiments it looks like the device has some sort of
internal timeout that triggers reconnect. This is completely against the
USB4 spec, as there is no requirement for the host to enumerate the
device right away or even at all.
In Linux case the delay is caused by scanning of retimers on the link so
we can work this around by doing the scanning after the device router
has been enumerated.
Reported-by: Thomas Lynema <lyz27@yahoo.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219748
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Kenneth noticed that his laptop crashes randomly when resuming from
hibernate if there is device connected and display tunneled. I was able
to reproduce this as well with the following steps:
1. Boot the system up, nothing connected.
2. Connect Thunderbolt 4 dock to the host.
3. Connect monitor to the Thunderbolt 4 dock.
4. Verify that there is picture on the screen.
5. Enter hibernate.
6. Exit hibernate.
7. Wait for the system to resume.
Expectation: System resumes just fine, the connected monitor still
shows screen.
Actual result: There is crash during resume, screen is blank.
What happens is that during resume from hibernate we tear down any
existing tunnels created by the boot kernel and this ends up calling
tb_dp_dprx_stop() which calls tb_tunnel_put() dropping the reference
count to zero even though we never called tb_dp_dprx_start() for it (we
never do that for discovery). This makes the discovered DP tunnel memory
to be released and any access after that causes use-after-free and
possible crash.
Fix this so that we only stop DPRX flow if it has been started in the
first place.
Reported-by: Kenneth Crudup <kenny@panix.com>
Closes: https://lore.kernel.org/linux-usb/8e175721-806f-45d6-892a-bd3356af80c9@panix.com/
Cc: stable@vger.kernel.org
Fixes: d6d458d42e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously")
Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Make the tb_tunnel_alloc_usb3() error codepaths consistent with the
DisplayPort and PCIe counterparts.
No functional changes.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
For historical reasons, the Castagnoli CRC32 is available under 3 names:
crc32c(), crc32c_le(), and __crc32c_le(). Most callers use crc32c().
The more verbose versions are not really warranted; there is no "_be"
version that the "_le" version needs to be differentiated from, and the
leading underscores are pointless.
Therefore, let's standardize on just crc32c(). Remove the other two
names, and update callers accordingly.
Specifically, the new crc32c() comes from what was previously
__crc32c_le(), so compared to the old crc32c() it now takes a size_t
length rather than unsigned int, and it's now in linux/crc32.h instead
of just linux/crc32c.h (which includes linux/crc32.h).
Later patches will also rename __crc32c_le_combine(), crc32c_le_base(),
and crc32c_le_arch().
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20250208024911.14936-5-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Here is the big set of driver core and debugfs updates for 6.14-rc1.
It's coming late in the merge cycle as there are a number of merge
conflicts with your tree now, and I wanted to make sure they were
working properly. To resolve them, look in linux-next, and I will send
the "fixup" patch as a response to the pull request.
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 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".
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZ5koPA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymFHACfT5acDKf2Bov2Lc/5u3vBW/R6ChsAnj+LmgVI
hcDSPodj4szR40RRnzBd
=u5Ey
-----END PGP SIGNATURE-----
Merge tag 'driver-core-6.14-rc1' of 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
...
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: a75e0684ef ("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>
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: aef9c693e7 ("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>
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>
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.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZ0lBqA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynTXQCfSs0ldBqZoINU/22q8BUg7ybb+pcAoL5EbbEm
b2igfp6YIEWAtUkactmO
=gwwq
-----END PGP SIGNATURE-----
Merge tag 'usb-6.13-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.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
...
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.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAmczF0UgHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKCsPxAAicCjT5tCbClp
oACICjaCNjqCh/8Bl9DApKwmi1SkWYXqbV7N5rUY+2QObPSGJLBV1U3G/PBuuqo9
QL7mj9zGQVpeSHmwqsrTO7WfgxQOvOWS9tvRXjey6lbpNlkT6+yZSCVngIS4UyYe
oUk/9gNCLTQA2QDKXdruh0vN+/EE5L9gsdKBg9pODA84HtcfW9L9dB0Q8T6hD6vI
SZpOuAQ216DNuimfUbj0YZPwjp0jr5/hjx8grc5S0g+hbbjJ3srobPU17sec+qTX
Yu1m+GyKohS4kd31+Ym8v4OZg9M+mF5neRT/booyGztHXPkuy7Yir5LyCmKPixFh
ysVU0u2qIpNOMHMWg+8RjIgKtGpj9cdVJH63eeTytPLdSgH+jl6318LOpVTWBpYH
j446DKfL8X4q15lDsxkyJ4kcJ37J7j317XDAMfdJXAAN4mISOI1vgCauJRWCzMTJ
ToSnH3Dh1VgeLjGpW/bzjb8kUH72OFejGl8hKl3qRKfrhHk/9dl2QOWaRXHVp/2O
gqPmALyrrAmAakC3g2Tr94usJHcO6LlS7S1+/+cMe2Es4da3YAl70fLJrex7yCcH
MMV+Z0VALpVCAzLhwBZMpmJhbiX4LkdJape8A0qmSQS5fv74w3Estf/Ae46ByPM6
jpbrfq/JzmrcgsbyCDEJc2s529QO6aw=
=B882
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v6.13-rc1' of 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
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.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAmcsjQIgHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKDBYw/9GC5UoKtAJQwX
/FyJBHxmy6EKgnx0YF7pREn+gv4Ryn7kseRhasqsxvW/3JDW+G3Vk+S0uRWQh7lf
DIniv7JikL/Fn5ZGUW4qO8mNxB/4NHEIii6EuQyrthA5dZPeV8Y5eYBWXLvzD/0i
jqH0rZCFevuMlXYqcX9SOxZQDBA41HBSqyX/t5QLLO4dlPu/AeDkQKKNtsob3dUO
cvnt92Hb7yPG7kmT7WIQHgAGd9qKrU/hYMiQIVzY3naD103jWa+Z8JcsDas5DJho
efYiiX4EhajMuoiOxtLKFoqxhk0y6xCdqzF/CbTdGHkl92dU5+ZlTMnn6wM8PY1K
6C/FLzs2KqiF71sLuTGSz2E9NjHY8ZG51csyzcfNCNVEpo74J4siS4DDtd/bGOgh
s5BhviQEQQP7dgqD0ZgV6uZFwfdpCHEankjyevIoSZyKl42LaEicRh9hJnEyLoai
inzbfTVswnQIpnhoWytUTmm7oP/IFTLMyb4qiemyZI0hKUuSPoMLw+RL3NERLY5M
HAhR2QbFFNvbYuUOSMYLxMyCYtVdQPorrsE8LxkStpO2O5Tno5xFCMxQHQV0rAA+
zKWOkos0mcWRRmjHC/T1RXrY2W0AWZ+9NLDG3+vTDeVNivfZ07LW5n5fl+f6zXBT
yFM/yIMND/FRSC8U0a+e8mSi4y0FzLA=
=TWJK
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v6.12-rc7' of 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
pcim_iomap_table() and pcim_request_regions() have been deprecated in
commit e354bb84a4 ("PCI: Deprecate pcim_iomap_table(),
pcim_iomap_regions_request_all()") and commit d140f80f60 ("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>
Rick reported that his Pluggable USB4 dock does not work anymore after
upgrading to v6.10 kernel.
It looks like commit c6ca1ac9f4 ("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: c6ca1ac9f4 ("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>
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>
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>
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>
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>
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>
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>
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>
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>
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: ff6ab055e0 ("thunderbolt: Add receiver lane margining support for retimers")
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
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>
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: ff6ab055e0 ("thunderbolt: Add receiver lane margining support for retimers")
CC: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
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.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAmbgDt0gHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKBbUA//Y+q9ZywuKtRb
sTFttZgr82BDo1cEb2mrpxFkH9veL0cUSwAaLut9xaNwcAoGxBKbhVRE8g5G1p3W
2zGxyGcWusPe9PMLybjpfWOy5iczU3YNA6zqppimprkA1edkppv7BBzunGiVEPW8
hs54/rp7AhtphPQI/2HCifQ6YuJ3GpnrF/GgRgePvkbMoAXxq1GnrNBN3L2X1UNz
gxEtykUz8bXRwTKwP6EqdQA4cVSXhWQefXNDbgnVhbwGQLuF4aYfDU2G4Zdv02UD
NpU9h8UJ5zOFHHsYVaPicJSFTS7n0Saqt379utSuUJkKYvn6kXqFsuW6cGDc4lET
N35LH04X9HTDlwCBYF9bVe6vsxVxnBaOJ/N8kbSkkdr53H6MnD7lQqMgSbCO0opH
f/ziJNVEUAFvdjykUIE58HXICT+kmF/IWUdJnUfsx3z1wHk0XUgpO/tJVjGSA1OC
VOowGuokES7XvU5gyZ3RbEEhKz0mYjw1r14cQULy5POF/B402BGjQLqB1ThNNN0e
ynIWLFsRDFdaDw3NG1P5qZhK8TgLQ/yoLJ+OrzMPsbRtd64tGUGx3ULzBxUDZaNg
diFH9oX6iaQ1yIX5c7iYGKVtmTrMF+6NqQ3TaFwdVps8N4n+CkZKwjxaqiBkKao1
cUzOByKSehj7Qdi2DcyQvN+tuwxSops=
=bn+4
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v6.12-rc1' of 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()
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>
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>
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>
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>
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>
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>
Linus Torvalds
Mika Westerberg
Alan Borzeszkowski
Eric Biggers
Greg Kroah-Hartman
Zijun Hu
Gil Fine
Mario Limonciello
Philipp Stanner
Aapo Vienamo
Mathias Nyman
R Kannappan
Rene Sapiens
Aapo Vienamo