Simplifies allocation of struct tb_path by using a flexible array
member. Also added __counted_by for extra runtime analysis.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
tb_path_activate() currently logs failures with tb_WARN(), which triggers
a stack trace. Transient conditions such as lane bonding or Type-C link
hiccups can fail path activation briefly, and the resulting backtraces are
noisy without aiding diagnosis.
Switch to tb_warn() for all path activation failures. The error code is
already returned to callers, and the warning still shows the message
without the backtrace.
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This function can be used to clear path config space of an adapter. Make
it available for other files in this driver.
Signed-off-by: Sanath S <Sanath.S@amd.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
USB4 v2 spec allows USB4 links that are part of a pass through tunnel
(such as DisplayPort and USB 3.x Gen T) to enter lower CL states, which
provide better power management. For this USB4 v2 routers in their path
config space of lane 0 adapter include a new bit PMPS (PM packet
support) that needs to be set.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
If the boot firmware implements connection manager of its own it may not
create the paths in the same way or order we do. For example it may
create first PCIe tunnel and then USB3 tunnel. When we restore our
tunnels (first de-activating them) we may be doing that over completely
different tunnels and that leaves them possibly non-functional. For this
reason we re-use the tunnel discovery functionality and find out all the
existing tunnels, and tear them down. Once that is done we can restore
our tunnels.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
With the USB4 buffer allocation the number of credits (and non-flow
credits) may be different depending on the router buffer allocation
preferences. To allow this move the nfc_credits field to struct
tb_path_hop.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This makes it consistent with other debug logs that already are using
decimal number for adapters (ports).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
These fields are marked as vendor defined in the USB4 spec and should
not be modified by the software, so only clear them when we are dealing
with pre-USB4 hardware.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB3 supports both isochronous and non-isochronous traffic. The former
requires guaranteed bandwidth and can take up to 90% of the total
bandwidth. With USB4 USB3 is tunneled over USB4 fabric which means that
we need to make sure there is enough bandwidth allocated for the USB3
tunnels in addition to DisplayPort tunnels.
Whereas DisplayPort bandwidth management is static and done before the
DP tunnel is established, the USB3 bandwidth management is dynamic and
allows increasing and decreasing the allocated bandwidth according to
what is currently consumed. This is done through host router USB3
downstream adapter registers.
This adds USB3 bandwidth management to the software connection manager
so that we always try to allocate maximum bandwidth for DP tunnels and
what is left is allocated for USB3.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Add sanity check that given src and dst ports are reachable through path
walk before allocating a path. If they are not then bail out early.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
With USB4, topologies are not limited to daisy-chains anymore so when
calculating how many hops are between two ports we need to walk the
whole path instead.
Add helper function tb_for_each_port_on_path() that can be used to walk
over each port on a path and make tb_path_alloc() to use it.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Titan Ridge supports Display Port 1.4 which adds HBR3 (High Bit Rate)
rates that may be up to 8.1 Gb/s over 4 lanes. This translates to
effective data bandwidth of 25.92 Gb/s (as 8/10 encoding is removed by
the DP adapters when going over Thunderbolt fabric). If another high
rate monitor is connected we may need to reduce the bandwidth it
consumes so that it fits into the total 40 Gb/s available on the
Thunderbolt fabric.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Lane bonding allows aggregating two 10/20 Gb/s (depending on the
generation) lanes into a single 20/40 Gb/s bonded link. This allows
sharing the full bandwidth more efficiently. In order to establish lane
bonding we need to check that lane bonding is possible through link
controller and that both ends of the link actually supports 2x widths.
This also means that all the paths should be established through the
primary port so update tb_path_alloc() to handle this as well.
Lane bonding is supported starting from Falcon Ridge (2nd generation)
controllers.
We also expose the current speed and number of lanes under each device
except the host router following similar attribute naming than USB bus.
Expose speed and number of lanes for both directions to allow possibility
of asymmetric link in the future.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
While tb_dump_hop() prints out necessary information it is in format
that is quite hard to read from the logs especially when one needs to
follow the path to see that the setup is correct.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Now that the driver can handle every possible tunnel types there is no
point to log everything as info level so turn these to happen at debug
level instead.
While at it remove duplicated tunnel activation log message
(tb_tunnel_activate() calls tb_tunnel_restart() which print the same
message) and add one missing '\n' termination.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
In addition to PCIe and Display Port tunnels it is also possible to
create tunnels that forward DMA traffic from the host interface adapter
(NHI) to a NULL port that is connected to another domain through a
Thunderbolt cable. These tunnels can be used to carry software messages
such as networking packets.
To support this we introduce another tunnel type (TB_TUNNEL_DMA) that
supports paths from NHI to NULL port and back.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Now that we have capability to discover existing tunnels during driver
load there is no point tearing down tunnels when the driver gets
unloaded. Instead we can just leave them running. If user disconnects
devices while there is no Thunderbolt driver loaded, tunneled protocol
hotplug happens and is handled by the corresponding driver (pciehp in
case of PCIe tunnel, GFX driver in case of DP tunnel).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
In Apple Macs the boot firmware (EFI) connects all devices automatically
when the system is started, before it hands over to the OS. Instead of
ignoring we discover all those PCIe tunnels and record them using our
internal structures, just like we do when a device is connected after
the OS is already up.
By doing this we can properly tear down tunnels when devices are
disconnected. Also this allows us to resume the existing tunnels after
system suspend/resume cycle.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Now that we can allocate hop IDs per port on a path, we can take
advantage of this and create tunnels covering longer paths than just
between two adjacent switches. PCIe actually does not need this as it
is typically a daisy chain between two adjacent switches but this way we
do not need to hard-code creation of the tunnel.
While there add name to struct tb_path to make debugging easier, and
update kernel-doc comments.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Rosen PenevandMika Westerberg
Linus Torvalds
Kees Cook
Chia-Lin Kao (AceLan)andMika Westerberg
Alan BorzeszkowskiandMika Westerberg
Sanath SandMika Westerberg