If USB3.x device references USB4 host interface, USB4 port can be
connected with appropriate Type-C port. By using component framework,
and in turn by creating symlinks, userspace can benefit from having
Thunderbolt/USB4 connection to Type-C ports.
Note: This change introduces dependency on Thunderbolt driver as it's
required to properly map USB4 port to Type-C port.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This function checks whether given USB4 port device matches with USB3.x
port device, using ACPI _DSD property.
It is designed to be used by component framework to match
USB4 ports with Type-C ports they are connected to.
Also, added USB4 config stub in case mapping function is not reachable.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Make usb4_port_index() available to other files in the driver, rename
and add function documentation.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cleans up the comments in both the c and the h file.
Standardises the comment type (/* */) and the indentation.
Signed-off-by: Ruben Wauters <rubenru09@aol.com>
Link: https://lore.kernel.org/r/20250415151246.30337-1-rubenru09@aol.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The blamed commit exposes a possible issue with flow_offload_teardown():
We might remove the offload bit of a conntrack entry that has been
offloaded again.
1. conntrack entry c1 is offloaded via flow f1 (f1->ct == c1).
2. f1 times out and is pushed back to slowpath, c1 offload bit is
removed. Due to bug, f1 is not unlinked from rhashtable right away.
3. a new packet arrives for the flow and re-offload is triggered, i.e.
f2->ct == c1. This is because lookup in flowtable skip entries with
teardown bit set.
4. Next flowtable gc cycle finds f1 again
5. flow_offload_teardown() is called again for f1 and c1 offload bit is
removed again, even though we have f2 referencing the same entry.
This is harmless, but clearly not correct.
Fix the bug that exposes this: set 'teardown = true' to have the gc
callback unlink the flowtable entry from the table right away instead of
the unintentional defer to the next round.
Also prevent flow_offload_teardown() from fixing up the ct state more than
once: We could also be called from the data path or a notifier, not only
from the flowtable gc callback.
NF_FLOW_TEARDOWN can never be unset, so we can use it as synchronization
point: if we observe did not see a 0 -> 1 transition, then another CPU
is already doing the ct state fixups for us.
Fixes: 03428ca5ce ("netfilter: conntrack: rework offload nf_conn timeout extension logic")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Resolved duplicate entry for IbaSPollBit vs IbaSpollBit.
Correct CamelCase for IBA enums
Adhere to Linux kernel coding style.
Reported by checkpatch
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250416203259.7862-2-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Removing gpib_interface_t to adhere to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-19-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-18-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-17-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-16-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-15-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-14-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-13-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-12-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-11-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-10-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-9-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-8-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-7-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-6-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-5-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-4-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-3-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
"Having the word "_struct" in the name of the struct doesn't add any
information so rename "struct gpib_interface_struct" to
"struct gpib_interface".
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-2-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix and improve documentation related to landlock_restrict_self(2)'s
flags. Update the LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF
documentation according to the current semantic.
Cc: Günther Noack <gnoack@google.com>
Cc: Paul Moore <paul@paul-moore.com>
Link: https://lore.kernel.org/r/20250416154716.1799902-3-mic@digikod.net
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Fix, deduplicate, and improve rendering of landlock_restrict_self(2)'s
flags documentation.
The flags are now rendered like the syscall's parameters and
description.
Cc: Günther Noack <gnoack@google.com>
Cc: Paul Moore <paul@paul-moore.com>
Link: https://lore.kernel.org/r/20250416154716.1799902-2-mic@digikod.net
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Move and fix the flags documentation, and improve formatting.
It makes more sense and it eases maintenance to document syscall flags
in landlock.h, where they are defined. This is already the case for
landlock_restrict_self(2)'s flags.
The flags are now rendered like the syscall's parameters and
description.
Cc: Günther Noack <gnoack@google.com>
Cc: Paul Moore <paul@paul-moore.com>
Link: https://lore.kernel.org/r/20250416154716.1799902-1-mic@digikod.net
Signed-off-by: Mickaël Salaün <mic@digikod.net>
This fixes an issue that's caused if there is a mismatch between the data
offset in the GRO header and the length fields in the regular sk_buff due
to the pskb_pull()/skb_push() calls. That's because the UDP GRO layer
stripped off the UDP header via skb_gro_pull() already while the UDP
header was explicitly not pulled/pushed in this function.
For example, an IKE packet that triggered this had len=data_len=1268 and
the data_offset in the GRO header was 28 (IPv4 + UDP). So pskb_pull()
was called with an offset of 28-8=20, which reduced len to 1248 and via
pskb_may_pull() and __pskb_pull_tail() it also set data_len to 1248.
As the ESP offload module was not loaded, the function bailed out and
called skb_push(), which restored len to 1268, however, data_len remained
at 1248.
So while skb_headlen() was 0 before, it was now 20. The latter caused a
difference of 8 instead of 28 (or 0 if pskb_pull()/skb_push() was called
with the complete GRO data_offset) in gro_try_pull_from_frag0() that
triggered a call to gro_pull_from_frag0() that corrupted the packet.
This change uses a more GRO-like approach seen in other GRO receivers
via skb_gro_header() to just read the actual data we are interested in
and does not try to "restore" the UDP header at this point to call the
existing function. If the offload module is not loaded, it immediately
bails out, otherwise, it only does a quick check to see if the packet
is an IKE or keepalive packet instead of calling the existing function.
Fixes: 172bf009c1 ("xfrm: Support GRO for IPv4 ESP in UDP encapsulation")
Fixes: 221ddb723d ("xfrm: Support GRO for IPv6 ESP in UDP encapsulation")
Signed-off-by: Tobias Brunner <tobias@strongswan.org>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Previously, migration related setup, such as updating family,
destination address, and source address, was performed after
the clone was created in `xfrm_state_migrate`. This change
moves this setup into the cloning function itself, improving
code locality and reducing redundancy.
The `xfrm_state_clone_and_setup` function now conditionally
applies the migration parameters from struct xfrm_migrate
if it is provided. This allows the function to be used both
for simple cloning and for cloning with migration setup.
Test: Tested with kernel test in the Android tree located
in https://android.googlesource.com/kernel/tests/
The xfrm_tunnel_test.py under the tests folder in
particular.
Signed-off-by: Chiachang Wang <chiachangwang@google.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Add hardware offload configuration to XFRM_MSG_MIGRATE
using an option netlink attribute XFRMA_OFFLOAD_DEV.
In the existing xfrm_state_migrate(), the xfrm_init_state()
is called assuming no hardware offload by default. Even the
original xfrm_state is configured with offload, the setting will
be reset. If the device is configured with hardware offload,
it's reasonable to allow the device to maintain its hardware
offload mode. But the device will end up with offload disabled
after receiving a migration event when the device migrates the
connection from one netdev to another one.
The devices that support migration may work with different
underlying networks, such as mobile devices. The hardware setting
should be forwarded to the different netdev based on the
migration configuration. This change provides the capability
for user space to migrate from one netdev to another.
Test: Tested with kernel test in the Android tree located
in https://android.googlesource.com/kernel/tests/
The xfrm_tunnel_test.py under the tests folder in
particular.
Signed-off-by: Chiachang Wang <chiachangwang@google.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
When the driver is built-in, it produces a W=1 warning:
drivers/comedi/drivers/ni_atmio.c:209:35: error: 'device_ids' defined but not used [-Werror=unused-const-variable=]
209 | static const struct pnp_device_id device_ids[] = {
The actual probe() function has a different way of identifying
the hardware, so just mark this one as __maybe_unused so it
can be dropped when built-in.
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250409122314.2848028-8-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver_version variable is only used inside of an #ifdef block, which
leads to a W=1 warning:
drivers/char/apm-emulation.c:144:19: error: 'driver_version' defined but not used [-Werror=unused-const-variable=]
Move this into the function using it.
Fixes: 7726942fb1 ("[APM] Add shared version of APM emulation")
Acked-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250409122314.2848028-9-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Introduce git-resolve.sh, a tool that resolves short git commit IDs to their
full SHA-1 hash. This is particularly useful for navigating references in commit
messages and verifying Fixes tags.
When faced with ambiguous commit IDs or imprecise references in messages,
this tool can help by resolving commit hashes based on not just the ID
itself but also the commit subject, making it more robust than standard
git rev-parse.
This is especially valuable for maintainers who need to verify Fixes tags
or cross-reference commits. Unlike proposals to add dates to Fixes tags
(which would break existing tooling), this script provides a way to
disambiguate commits without changing the established tag format.
The script includes several features:
- Resolves short commit IDs to full SHA-1 hashes
- Uses commit subjects to disambiguate between multiple potential matches
- Supports wildcard patterns in subjects with ellipsis (...)
- Provides a force mode to attempt resolution by subject when ID lookup fails
- Includes comprehensive self-tests
Signed-off-by: Sasha Levin <sashal@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20250311165336.248120-1-sashal@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hyper-V may offer a non latency sensitive device with subchannels without
monitor bit enabled. The decision is entirely on the Hyper-V host not
configurable within guest.
When a device has subchannels, also signal events for the subchannel
if its monitor bit is disabled.
This patch also removes the memory barrier when monitor bit is enabled
as it is not necessary. The memory barrier is only needed between
setting up interrupt mask and calling vmbus_set_event() when monitor
bit is disabled.
Signed-off-by: Long Li <longli@microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
Link: https://lore.kernel.org/r/1741644721-20389-1-git-send-email-longli@linuxonhyperv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
GCC 15's -Wunterminated-string-initialization warned about truncated
name strings. Instead of marking them with the "nonstring" attribute[1],
increase their length to correctly include enough space for the
terminating NUL character, as they are used with %s format specifiers
when showing resource allocations in /proc/ioports:
seq_printf(m, "%*s%0*llx-%0*llx : %s\n", ..., r->name);
The strings in eisa.ids have a max length of 73, and the 50 limit was an
arbitrary limit that was removed back in 2008 with commit ca52a49846
("driver core: remove DEVICE_NAME_SIZE define"). Change the limit to 74
so nothing is truncated any more.
Additionally fix the Makefile to use "if_changed" instead of "cmd"
to detect changes to the command line used to generate the target,
otherwise devlist.h won't be rebuilt.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Acked-by: Alejandro Colomar <alx@kernel.org>
Link: https://lore.kernel.org/r/20250407172926.it.281-kees@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use to_delayed_work() instead of open-coding it.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Acked-by: Eli Billauer <eli.billauer@gmail.com>
Link: https://lore.kernel.org/r/20250414074559.3954142-1-nichen@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
