Tony Nguyen says:
====================
ice: implement SRIOV VF Active-Active LAG
Dave Ertman says:
Implement support for SRIOV VFs over an Active-Active link aggregate.
The same restrictions apply as are in place for the support of
Active-Backup bonds.
- the two interfaces must be on the same NIC
- the FW LLDP engine needs to be disabled
- the DDP package that supports VF LAG must be loaded on device
- the two interfaces must have the same QoS config
- only the first interface added to the bond will have VF support
- the interface with VFs must be in switchdev mode
With the additional requirement of
- the version of the FW on the NIC needs to have VF Active/Active support
The balancing of traffic between the two interfaces is done on a queue
basis. Taking the queues allocated to all of the VFs as a whole, one
half of them will be distributed to each interface. When a link goes
down, then the queues allocated to the down interface will migrate to
the active port. When the down port comes back up, then the same
queues as were originally assigned there will be moved back.
Patch 1 cleans up void pointer casts
Patch 2 utilizes bool over u8 when appropriate
Patch 3 adds a driver prefix to a LAG define
Patch 4 pre-move a function to reduce delta in implementation patch
Patch 5 cleanup variable initialization in declaration block
Patch 6 cleanup capability parsing for LAG feature
Patch 7 is the implementation of the new functionality
* '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
ice: Implement support for SRIOV VFs across Active/Active bonds
ice: cleanup capabilities evaluation
ice: Cleanup variable initialization in LAG code
ice: move LAG function in code to prepare for Active-Active
ice: Add driver specific prefix to LAG defines
ice: replace u8 elements with bool where appropriate
ice: Remove casts on void pointers in LAG code
====================
Link: https://patch.msgid.link/20250814230855.128068-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The CI has hit a couple of cases of:
RUN global.data_steal ...
tls.c:2762:data_steal:Expected recv(cfd, buf2, sizeof(buf2), MSG_DONTWAIT) (20000) == -1 (-1)
data_steal: Test terminated by timeout
FAIL global.data_steal
Looks like the 2msec sleep is not long enough. Make the sleep longer,
and then instead of second sleep wait for the thieving process to exit.
That way we can be sure it called recv() before us.
While at it also avoid trying to steal more than a record, this seems
to be causing issues in manual testing as well.
Fixes: d7e82594a4 ("selftests: tls: test TCP stealing data from under the TLS socket")
Link: https://patch.msgid.link/20250814194323.2014650-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
During raid resync, if a disk becomes faulty, the operation is
briefly interrupted. The MD_RECOVERY_RECOVER flag triggered by
the disk failure causes sync_action to incorrectly show "recover"
instead of "resync". The same issue affects reshape operations.
Reproduction steps:
mdadm -Cv /dev/md1 -l1 -n4 -e1.2 /dev/sd{a..d} // -> resync happened
mdadm -f /dev/md1 /dev/sda // -> resync interrupted
cat sync_action
-> recover
Add progress checks in md_sync_action() for resync/recover/reshape
to ensure the interface correctly reports the actual operation type.
Fixes: 4b10a3bc67 ("md: ensure resync is prioritized over recovery")
Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
Link: https://lore.kernel.org/linux-raid/20250816002534.1754356-3-zhengqixing@huaweicloud.com
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
commit 907a99c314 ("md: rename recovery_cp to resync_offset") replaces
recovery_cp with resync_offset in mdp_superblock_s which is in md_p.h.
md_p.h is used in userspace too. So mdadm building fails because of this.
This patch revert this change.
Fixes: 907a99c314 ("md: rename recovery_cp to resync_offset")
Signed-off-by: Xiao Ni <xni@redhat.com>
Link: https://lore.kernel.org/linux-raid/20250815040028.18085-1-xni@redhat.com
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Yureka Lilian says:
====================
libbpf: fix reuse of DEVMAP
changes in v3:
- instead of setting BPF_F_RDONLY_PROG on both sides, just
clear BPF_F_RDONLY_PROG in map_info.map_flags as suggested
by Andrii Nakryiko
- in the test, use ASSERT_* instead of CHECK
- shorten the test by using open_and_load from the skel
- in the test, drop NULL check before unloading/destroying bpf objs
- start the commit messages with "libbpf" and "selftests/bpf"
respectively instead of just "bpf"
changes in v2:
- preserve compatibility with older kernels
- add a basic selftest covering the re-use of DEVMAP maps
====================
Link: https://patch.msgid.link/20250814180113.1245565-2-yuka@yuka.dev
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
The test covers basic re-use of a pinned DEVMAP map,
with both matching and mismatching parameters.
Signed-off-by: Yureka Lilian <yuka@yuka.dev>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20250814180113.1245565-4-yuka@yuka.dev
Previously, re-using pinned DEVMAP maps would always fail, because
get_map_info on a DEVMAP always returns flags with BPF_F_RDONLY_PROG set,
but BPF_F_RDONLY_PROG being set on a map during creation is invalid.
Thus, ignore the BPF_F_RDONLY_PROG flag in the flags returned from
get_map_info when checking for compatibility with an existing DEVMAP.
The same problem is handled in a third-party ebpf library:
- https://github.com/cilium/ebpf/issues/925
- https://github.com/cilium/ebpf/pull/930
Fixes: 0cdbb4b09a ("devmap: Allow map lookups from eBPF")
Signed-off-by: Yureka Lilian <yuka@yuka.dev>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20250814180113.1245565-3-yuka@yuka.dev
Graph tracer framework ensures we won't migrate, kprobe_multi_link_prog_run
called all the way from graph tracer, which disables preemption in
function_graph_enter_regs, as Jiri and Yonghong suggested, there is no
need to use migrate_disable. As a result, some overhead may will be reduced.
And add cant_sleep check for __this_cpu_inc_return.
Fixes: 0dcac27254 ("bpf: Add multi kprobe link")
Signed-off-by: Tao Chen <chen.dylane@linux.dev>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20250814121430.2347454-1-chen.dylane@linux.dev
Using device_find_child() and of_find_device_by_node() to locate
devices could cause an imbalance in the device's reference count.
device_find_child() and of_find_device_by_node() both call
get_device() to increment the reference count of the found device
before returning the pointer. In mtk_drm_get_all_drm_priv(), these
references are never released through put_device(), resulting in
permanent reference count increments. Additionally, the
for_each_child_of_node() iterator fails to release node references in
all code paths. This leaks device node references when loop
termination occurs before reaching MAX_CRTC. These reference count
leaks may prevent device/node resources from being properly released
during driver unbind operations.
As comment of device_find_child() says, 'NOTE: you will need to drop
the reference with put_device() after use'.
Cc: stable@vger.kernel.org
Fixes: 1ef7ed4835 ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support")
Signed-off-by: Ma Ke <make24@iscas.ac.cn>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Link: https://patchwork.kernel.org/project/dri-devel/patch/20250812071932.471730-1-make24@iscas.ac.cn/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
bridge:
- fix OF-node leak
- fix documentation
fbdev-emulation:
- pass correct format info to drm_helper_mode_fill_fb_struct()
panfrost:
- print correct RSS size
amdgpu:
- PSP fix
- VRAM reservation fix
- CSA fix
- Process kill fix
i915:
- Fix the implementation of wa_18038517565 [fbc]
- Do not trigger Frame Change events from frontbuffer flush [psr]
xe:
- Some more xe_migrate_access_memory fixes (Auld)
- Defer buffer object shrinker write-backs and GPU waits (Thomas)
- HWMON fix for clamping limits (Karthik)
- SRIOV-PF: Set VF LMEM BAR size (Michal)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmifpQsACgkQDHTzWXnE
hr63FA//SvXpA51XfZuF1gm6x3oeYuF1xGMLS34ol6EI4YwOQg7wke7IFMe12dMJ
X/1kZ48Ju1l9NLyuRQfC7zW1EAqN4HjrB62MdGxFv7+Ap/i5SiOow9zJRSg0a5Mq
qRNmyGSw4ch1sVnU4LN1+9rVqpMN/jo5ngEvSlLlUmDtG2Plg9PzqSGIGHGPgStL
DEQI9DHUzn1F6lVtvdj/rA1+EzxaPKQ1g/VHMbA8bR46xal4jJ1BOWUI2plG6dcf
OxfhNvdqETz7q1YFgbyMUSXaR2VcK9qM/ATSBV/CSYOz51cd11CE12FI+Fywfc0i
/Jgt3H1Ociis/x7BfuTaRL3FkVYgzq7UK4KHZVeASJch2AjSl5tyaLx+ghmr4+5i
bPgK5rcWof9XvxRHylzKUcJwg+1Tn3r280mwWS/RQuGDEAWkT/8IB7WO+Ol8tJ+v
UbSsODl2BkXnumZE7r/dOcYNaJNgRdE5Uvc7+jCnt67Rk1WHBS8BB82Cst285A9h
lJdNp+mvN10erfWfLYhEWaFs/E6Us0YyFxKui65ZJftS5ErsQBDKE7Va7MVz5AxM
Laa8/K+5Y6c/2WW1Z8Ayiua/KV2Y7b4oWlhUPu6V/rjZrHHYt2sE1KV/bBeBKlPo
Q1zjf8ECQW90lK7vLSxPfGID5LMQUhJbmpaEpfyjyU+Q9nYjl9Y=
=d48j
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2025-08-16' of https://gitlab.freedesktop.org/drm/kernel
Pull drm fixes from Dave Airlie:
"Relatively quiet week, usual amdgpu/i915/xe fixes along with a set of
fixes for fbdev format info, which fix some regressions seen in with
rc1.
bridge:
- fix OF-node leak
- fix documentation
fbdev-emulation:
- pass correct format info to drm_helper_mode_fill_fb_struct()
panfrost:
- print correct RSS size
amdgpu:
- PSP fix
- VRAM reservation fix
- CSA fix
- Process kill fix
i915:
- Fix the implementation of wa_18038517565 [fbc]
- Do not trigger Frame Change events from frontbuffer flush [psr]
xe:
- Some more xe_migrate_access_memory fixes (Auld)
- Defer buffer object shrinker write-backs and GPU waits (Thomas)
- HWMON fix for clamping limits (Karthik)
- SRIOV-PF: Set VF LMEM BAR size (Michal)"
* tag 'drm-fixes-2025-08-16' of https://gitlab.freedesktop.org/drm/kernel:
drm/xe/pf: Set VF LMEM BAR size
drm/amdgpu: fix task hang from failed job submission during process kill
drm/amdgpu: fix incorrect vm flags to map bo
drm/amdgpu: fix vram reservation issue
drm/amdgpu: Add PSP fw version check for fw reserve GFX command
drm/xe/hwmon: Add SW clamp for power limits writes
drm/xe: Defer buffer object shrinker write-backs and GPU waits
drm/xe/migrate: prevent potential UAF
drm/xe/migrate: don't overflow max copy size
drm/xe/migrate: prevent infinite recursion
drm/i915/psr: Do not trigger Frame Change events from frontbuffer flush
drm/i915/fbc: fix the implementation of wa_18038517565
drm/panfrost: Print RSS for tiler heap BO's in debugfs GEMS file
drm/radeon: Pass along the format info from .fb_create() to drm_helper_mode_fill_fb_struct()
drm/nouveau: Pass along the format info from .fb_create() to drm_helper_mode_fill_fb_struct()
drm/omap: Pass along the format info from .fb_create() to drm_helper_mode_fill_fb_struct()
drm/bridge: document HDMI CEC callbacks
drm/bridge: Describe the newly introduced drm_connector parameter for drm_bridge_detect
drm/bridge: fix OF node leak
The chrp,open-pic binding schema already supports the "fsl,mpic"
compatible. Add a couple of missing properties and support for 4
"#interrupt-cells" to the chrp,open-pic binding, so fsl/mpic.txt can be
removed.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20250814135157.2747346-2-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Some ARM Cortex CPUs including A72 have Error Detection And Correction (EDAC)
support on their L1 and L2 caches. That functionality is in implementation
defined registers, so using it is not safe in virtualized environments or when
EL3 already uses these registers. Add a edac-enabled flag which can be
explicitly set when EDAC can be used.
[ bp: Massage commit message. ]
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Vijay Balakrishna <vijayb@linux.microsoft.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/1752714390-27389-3-git-send-email-vijayb@linux.microsoft.com
The driver is designed to support error detection and reporting for
Cortex A72 cores, specifically within their L1 and L2 cache systems.
The errors are detected by reading CPU/L2 memory error syndrome
registers.
Unfortunately there is no robust way to inject errors into the caches,
so this driver doesn't contain any code to actually test it. It has
been tested though with code taken from an older version [1] of this
driver. For reasons stated in thread [1], the error injection code is
not suitable for mainline, so it is removed from the driver.
[1] https://lore.kernel.org/all/1521073067-24348-1-git-send-email-york.sun@nxp.com/#t
[ bp: minor touchups. ]
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Co-developed-by: Vijay Balakrishna <vijayb@linux.microsoft.com>
Signed-off-by: Vijay Balakrishna <vijayb@linux.microsoft.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/1752714390-27389-2-git-send-email-vijayb@linux.microsoft.com
In 32-bit arm, the build fails with:
error[E0308]: mismatched types
--> drivers/gpu/drm/nova/file.rs:42:28
|
42 | getparam.set_value(value);
| --------- ^^^^^ expected `u64`, found `u32`
| |
| arguments to this method are incorrect
|
note: method defined here
--> drivers/gpu/drm/nova/uapi.rs:29:12
|
29 | pub fn set_value(&self, v: u64) {
| ^^^^^^^^^ ------
help: you can convert a `u32` to a `u64`
|
42 | getparam.set_value(value.into());
| +++++++
The reason is that `Getparam::set_value` takes a `u64` (from the UAPI),
but `pci::Device::resource_len()` returns a `resource_size_t`, which is a
`phys_addr_t`, which may be 32- or 64-bit.
Thus add an `into()` call to support the 32-bit case, while allowing the
Clippy lint that complains in the 64-bit case where the type is the same.
Fixes: cdeaeb9dd7 ("drm: nova-drm: add initial driver skeleton")
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com>
Link: https://lore.kernel.org/r/20250724165441.2105632-1-ojeda@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
'-mpreferred-stack-boundary' (the GCC option) and '-mstack-alignment'
(the clang option) have been supported in their respective compilers for
some time, so it is unnecessary to check for support for them via
cc-option. '-mpreferred-stack-boundary=3' had a restriction on
'-mno-sse' until GCC 7.1 but that is irrelevant for most of the kernel,
which includes '-mno-sse'.
Move to simple Kconfig checks to avoid querying the compiler for the
flags that it supports.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/20250814-x86-min-ver-cleanups-v1-2-ff7f19457523@kernel.org
Update call sites in the driver-core files and its related samples
to import `ARef` and `AlwaysRefCounted` from `sync::aref`
instead of `types`.
This aligns with the ongoing effort to move `ARef` and
`AlwaysRefCounted` to sync.
Suggested-by: Benno Lossin <lossin@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1173
Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com>
Link: https://lore.kernel.org/r/20250814104615.355106-1-shankari.ak0208@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2290 was found in the field to also require this quirk, as long &
high-bandwidth workloads (e.g. USB ethernet) are consistently able to
crash the controller otherwise.
The same change has been made for a number of SoCs in [1], but QCM2290
somehow escaped the list (even though the very closely related SM6115
was there).
Upon a controller crash, the log would read:
xhci-hcd.12.auto: xHCI host not responding to stop endpoint command
xhci-hcd.12.auto: xHCI host controller not responding, assume dead
xhci-hcd.12.auto: HC died; cleaning up
Add snps,parkmode-disable-ss-quirk to the DWC3 instance in order to
prevent the aforementioned breakage.
[1] https://lore.kernel.org/all/20240704152848.3380602-1-quic_kriskura@quicinc.com/
Cc: stable@vger.kernel.org
Reported-by: Rob Clark <robin.clark@oss.qualcomm.com>
Fixes: a64a0192b7 ("arm64: dts: qcom: Add initial QCM2290 device tree")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250708-topic-2290_usb-v1-1-661e70a63339@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Based on a bisect, it appears that commit 7ee9887703 ("timers:
Implement the hierarchical pull model") has somehow inadvertently
broken BPF selftest test_tcpnotify_user. The error that is being
generated by this test is as follows:
FAILED: Wrong stats Expected 10 calls, got 8
It looks like the change allows timer functions to be run on CPUs
different from the one they are armed on. The test had pinned itself
to CPU 0, and in the past the retransmit attempts also occurred on CPU
0. The test had set the max_entries attribute for
BPF_MAP_TYPE_PERF_EVENT_ARRAY to 2 and was calling
bpf_perf_event_output() with BPF_F_CURRENT_CPU, so the entry was
likely to be in range. With the change to allow timers to run on other
CPUs, the current CPU tasked with performing the retransmit might be
bumped and in turn fall out of range, as the event will be filtered
out via __bpf_perf_event_output() using:
if (unlikely(index >= array->map.max_entries))
return -E2BIG;
A possible change would be to explicitly set the max_entries attribute
for perf_event_map in test_tcpnotify_kern.c to a value that's at least
as large as the number of CPUs. As it turns out however, if the field
is left unset, then the libbpf will determine the number of CPUs available
on the underlying system and update the max_entries attribute accordingly
in map_set_def_max_entries().
A further problem with the test is that it has a thread that continues
running up until the program exits. The main thread cleans up some
LIBBPF data structures, while the other thread continues to use them,
which inevitably will trigger a SIGSEGV. This can be dealt with by
telling the thread to run for as long as necessary and doing a
pthread_join on it before exiting the program.
Finally, I don't think binding the process to CPU 0 is meaningful for
this test any more, so get rid of that.
Fixes: 435f90a338 ("selftests/bpf: add a test case for sock_ops perf-event notification")
Signed-off-by: Matt Bobrowski <mattbobrowski@google.com>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/aJ8kHhwgATmA3rLf@google.com
Signed-off-by: Carlos Maiolino <cem@kernel.org>
-----BEGIN PGP SIGNATURE-----
iJUEABMJAB0WIQSmtYVZ/MfVMGUq1GNcsMJ8RxYuYwUCaJ8nJQAKCRBcsMJ8RxYu
Y91GAX4q+aKhXBJzzEYGaCGEajMNHlClPI9Ac5AlhSkzW/XdZdS8FhIgJMNegTst
yOKZ32kBgPoBtiVDbRs7h0USqmcd94f9IwmoLa+0miUKyHHJaZIR97of9F/P1o3q
Lx2dLf5hwQ==
=e0dN
-----END PGP SIGNATURE-----
Merge tag 'xfs-fixes-6.17-rc2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
Pull xfs fixes from Carlos Maiolino:
- Fix an assert trigger introduced during the merge window
- Prevent atomic writes to be used with DAX
- Prevent users from using the max_atomic_write mount option without
reflink, as atomic writes > 1block are not supported without reflink
- Fix a null-pointer-deref in a tracepoint
* tag 'xfs-fixes-6.17-rc2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: split xfs_zone_record_blocks
xfs: fix scrub trace with null pointer in quotacheck
xfs: reject max_atomic_write mount option for no reflink
xfs: disallow atomic writes on DAX
fs/dax: Reject IOCB_ATOMIC in dax_iomap_rw()
xfs: remove XFS_IBULK_SAME_AG
xfs: fully decouple XFS_IBULK* flags from XFS_IWALK* flags
xfs: fix frozen file system assert in xfs_trans_alloc
While trying to fill a random RSS key, the size of the pointer
is being used rather than the actual size of the RSS key.
Fix by passing an appropriate value of the RSS key.
This issue was reported by static coverity analyser.
Fixes: eb4898fde1 ("net: libwx: add wangxun vf common api")
Signed-off-by: Chandra Mohan Sundar <chandramohan.explore@gmail.com>
Link: https://patch.msgid.link/20250814163014.613004-1-chandramohan.explore@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace memset(0) followed by strscpy() with strscpy_pad() to improve
netdev_boot_setup_add(). This avoids zeroing the memory before copying
the string and ensures the destination buffer is only written to once,
simplifying the code and improving efficiency.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20250814180514.251000-2-thorsten.blum@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tariq Toukan says:
====================
net/mlx5: Support disabling host PFs
This small series by Daniel adds support for disabling host PFs.
If device is capable and configured, the driver won't access vports of
disabled host functions.
====================
Link: https://patch.msgid.link/1755112796-467444-1-git-send-email-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Some devices support disabling the physical function on the host. When
this is configured the vports for the host functions do not exist.
This patch checks if host functions are enabled before trying to access
their vports.
Signed-off-by: Daniel Jurgens <danielj@nvidia.com>
Reviewed-by: William Tu <witu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/1755112796-467444-3-git-send-email-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The host PF can be disabled, query firmware to check if the host PF of
this function exists.
Signed-off-by: Daniel Jurgens <danielj@nvidia.com>
Reviewed-by: William Tu <witu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/1755112796-467444-2-git-send-email-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A struct mii_bus doesn't need a parent, so we can simplify the code and
remove using a faux device. Only difference is the following in sysfs
under /sys/class/mdio_bus:
old: fixed-0 -> '../../devices/faux/Fixed MDIO bus/mdio_bus/fixed-0'
new: fixed-0 -> ../../devices/virtual/mdio_bus/fixed-0
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://patch.msgid.link/e9426bb9-f228-4b99-bc09-a80a958b5a93@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
vhca id is already cached in the vport structure no need to query on
every mlx5 layer, use the mlx5_vport_get_vhca_id, where possible.
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Reviewed-by: Parav Pandit <parav@nvidia.com>
Signed-off-by: Alexei Lazar <alazar@nvidia.com>
Reviewed-by: Feng Liu <feliu@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Dynamically created vports require vhca id as input to set/query other
vport hca cap, when FW is capable and the vhca id of a vport is valid
use it instead of the local function id.
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Adithya Jayachandran <ajayachandra@nvidia.com>
Reviewed-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Feng Liu <feliu@nvidia.com>
Reviewed-by: William Tu <witu@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
We need vhca_id to set up the vhca_id to vport mapping for every vport,
for that we query the firmware in mlx5_esw_vport_vhca_id_set, and it is
redundant since in esw_vport_setup, we already query hca caps which has
the vhca_id, cache it there and save 2 extra fw queries per vport.
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Reviewed-by: Parav Pandit <parav@nvidia.com>
Signed-off-by: Alexei Lazar <alazar@nvidia.com>
Reviewed-by: Feng Liu <feliu@nvidia.com>
Next patches will implement the discovery and creation of adjacent
functions vports, this patch introduces the hardware structures
definitions needed for the driver implementation.
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Reviewed-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Jack Morgenstein <jackm@nvidia.com>
Signed-off-by: Alexei Lazar <alazar@nvidia.com>
When converting a Box<T> into a void pointer, the allocator might
guarantee a higher alignment than the type itself does, and in that case
it is guaranteed that the void pointer has that higher alignment.
This is quite useful when combined with the XArray, which you can only
create using a ForeignOwnable whose FOREIGN_ALIGN is at least 4. This
means that you can now always use a Box<T> with the XArray no matter the
alignment of T.
Reviewed-by: Benno Lossin <lossin@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://lore.kernel.org/r/20250811-align-min-allocator-v2-2-3386cc94f4fc@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The kernel's allocators sometimes provide a higher alignment than the
end-user requested, so add a new constant on the Allocator trait to let
the allocator specify what its minimum guaranteed alignment is.
This allows the ForeignOwnable trait to provide a more accurate value of
FOREIGN_ALIGN when using a pointer type such as Box, which will be
useful with certain collections such as XArray that store its own data
in the low bits of pointers.
Reviewed-by: Benno Lossin <lossin@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://lore.kernel.org/r/20250811-align-min-allocator-v2-1-3386cc94f4fc@google.com
[ Add helper for ARCH_KMALLOC_MINALIGN; remove cast to usize. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
vcpu_write_sys_reg()'s signature is not totally obvious, and it
is rather easy to write something that looks correct, except that...
Oh wait...
Swap addr and FAR_EL2 to restore some sanity in the nested SEA
department.
Fixes: 9aba641b9e ("KVM: arm64: nv: Respect exception routing rules for SEAs")
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20250813163747.2591317-1-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Replace kfree() with kvfree() for memory allocated by kvmalloc().
Compile-tested only.
Cc: stable@vger.kernel.org
Fixes: 8a8b1ec526 ("drm/nouveau/gsp: split rpc handling out on its own")
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
Reviewed-by: Timur Tabi <ttabi@nvidia.com>
Acked-by: Zhi Wang <zhiw@nvidia.com>
Link: https://lore.kernel.org/r/20250813125412.96178-1-rongqianfeng@vivo.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add bindings to obtain a PCI device's resource start address, bus/
device function, revision ID and subsystem device and vendor IDs.
These will be used by the nova-core GPU driver which is currently in
development.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Krzysztof Wilczyński <kwilczynski@kernel.org>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: Alex Gaynor <alex.gaynor@gmail.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Gary Guo <gary@garyguo.net>
Cc: Björn Roy Baron <bjorn3_gh@protonmail.com>
Cc: Benno Lossin <lossin@kernel.org>
Cc: Andreas Hindborg <a.hindborg@kernel.org>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Trevor Gross <tmgross@umich.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: linux-pci@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://lore.kernel.org/r/20250730013417.640593-2-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Update PCI FFI callback signatures to use `c_` from the prelude,
instead of accessing it via `kernel::ffi::`.
Signed-off-by: Abhinav Ananthu <abhinav.ogl@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Link: https://lore.kernel.org/r/20250812033101.5257-1-abhinav.ogl@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Update auxiliary FFI callback signatures to reference the `c_` types
provided by the kernel prelude, rather than accessing them via
`kernel::ffi::`.
Signed-off-by: Abhinav Ananthu <abhinav.ogl@gmail.com>
Link: https://lore.kernel.org/r/20250812075109.4099-1-abhinav.ogl@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
- hci_conn: Fix running bis_cleanup for hci_conn->type PA_LINK
- hci_conn: Fix not cleaning up Broadcaster/Broadcast Source
- hci_core: Fix using {cis,bis}_capable for current settings
- hci_core: Fix using ll_privacy_capable for current settings
- hci_core: Fix not accounting for BIS/CIS/PA links separately
- hci_conn: do return error from hci_enhanced_setup_sync()
- hci_event: fix MTU for BN == 0 in CIS Established
- hci_sync: Fix scan state after PA Sync has been established
- hci_sync: Avoid adding default advertising on startup
- hci_sync: Prevent unintended PA sync when SID is 0xFF
- ISO: Fix getname not returning broadcast fields
- btmtk: Fix wait_on_bit_timeout interruption during shutdown
- btnxpuart: Uses threaded IRQ for host wakeup handling
-----BEGIN PGP SIGNATURE-----
iQJNBAABCgA3FiEE7E6oRXp8w05ovYr/9JCA4xAyCykFAmifQh4ZHGx1aXoudm9u
LmRlbnR6QGludGVsLmNvbQAKCRD0kIDjEDILKSpyD/4+a98UD/FMiu2MuowbCJvK
EWneAUc9l0j/bhVSaTnRzpXM6gov/SNdSFr9dLrTeYY75X+ky1YDFca/deP2fZzl
v+2H306yIw73k4DAEqkzOQk+YRpi/N7+rruytlZd7TC29zwer1IEg2Rv6hMqmZQt
bkFiEcR2HpIFaXGDAmsKmXEQ3xsNnbHpeuqQIYPC0uzTYDdW8O+vV/etgHeycfzc
dGDJOX+3oEAYCi3NtJY/DZLlIhKneLHRn7qGpDAXUWTRvzHESdzmOzSQ9wD0fVqD
pMMJv0dmaubH32JHafnIGixGb6LwhHWbse2yaei2uWfwukQJAzflfMwkManVsEBa
SM5mNXS586xeLfahLy1FmlbOaL5e7enL8Bhd4jZJGtIb1WRMZBsXCNKX0cZUKn8B
mNrM1zqQUvBrmS9G5KC2lAfgco0mqxoSKipgctJLamzNR2z6Yz4No0MLTzh89MnV
0waBToTn8sXidN/ENzOrxq6GGFZmaV0x3UXickwcbxLKC30+r3nXR4j0xK56N2ly
2sM+wU9CkXitQIW8PUWcYAWZ1k3/7ixv5/pIGVHnozQEcHiBX0OOmReauF3LWZjC
pWZU0/T7vduS4/3ThSBQNOjjWp3uhyKYCbbumMQsTVSsJ5MOgvf7IqLcVWAVi3Eg
1lbQkLQNC3uaosoV/JJfRg==
=ZtN+
-----END PGP SIGNATURE-----
Merge tag 'for-net-2025-08-15' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
Luiz Augusto von Dentz says:
====================
bluetooth pull request for net:
- hci_conn: Fix running bis_cleanup for hci_conn->type PA_LINK
- hci_conn: Fix not cleaning up Broadcaster/Broadcast Source
- hci_core: Fix using {cis,bis}_capable for current settings
- hci_core: Fix using ll_privacy_capable for current settings
- hci_core: Fix not accounting for BIS/CIS/PA links separately
- hci_conn: do return error from hci_enhanced_setup_sync()
- hci_event: fix MTU for BN == 0 in CIS Established
- hci_sync: Fix scan state after PA Sync has been established
- hci_sync: Avoid adding default advertising on startup
- hci_sync: Prevent unintended PA sync when SID is 0xFF
- ISO: Fix getname not returning broadcast fields
- btmtk: Fix wait_on_bit_timeout interruption during shutdown
- btnxpuart: Uses threaded IRQ for host wakeup handling
* tag 'for-net-2025-08-15' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth:
Bluetooth: hci_core: Fix not accounting for BIS/CIS/PA links separately
Bluetooth: btnxpuart: Uses threaded IRQ for host wakeup handling
Bluetooth: hci_conn: do return error from hci_enhanced_setup_sync()
Bluetooth: hci_event: fix MTU for BN == 0 in CIS Established
Bluetooth: hci_sync: Prevent unintended PA sync when SID is 0xFF
Bluetooth: hci_core: Fix using ll_privacy_capable for current settings
Bluetooth: hci_core: Fix using {cis,bis}_capable for current settings
Bluetooth: btmtk: Fix wait_on_bit_timeout interruption during shutdown
Bluetooth: hci_conn: Fix not cleaning up Broadcaster/Broadcast Source
Bluetooth: hci_conn: Fix running bis_cleanup for hci_conn->type PA_LINK
Bluetooth: ISO: Fix getname not returning broadcast fields
Bluetooth: hci_sync: Fix scan state after PA Sync has been established
Bluetooth: hci_sync: Avoid adding default advertising on startup
====================
Link: https://patch.msgid.link/20250815142229.253052-1-luiz.dentz@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Petr Machata says:
====================
mlxsw: spectrum: Forward packets with an IPv4 link-local source IP
By default, Spectrum devices do not forward IPv4 packets with a link-local
source IP (i.e., 169.254.0.0/16). This behavior does not align with the
kernel which does forward them. Fix the issue and add a selftest.
====================
Link: https://patch.msgid.link/cover.1755174341.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
By default, the device does not forward IPv4 packets with a link-local
source IP (i.e., 169.254.0.0/16). This behavior does not align with the
kernel which does forward them.
Fix by instructing the device to forward such packets instead of
dropping them.
Fixes: ca360db4b8 ("mlxsw: spectrum: Disable DIP_LINK_LOCAL check in hardware pipeline")
Reported-by: Zoey Mertes <zoey@cloudflare.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Petr Machata <petrm@nvidia.com>
Link: https://patch.msgid.link/6721e6b2c96feb80269e72ce8d0b426e2f32d99c.1755174341.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Skipped tests reported by kselftest.h use a different format than KTAP,
there is no explicit test name. Normally the test name is part of the
free-form string after the SKIP keyword:
ok 3 # SKIP test: some reason
Extend the parser to handle those correctly. Use the free-form string as
test name instead.
Link: https://lore.kernel.org/r/20250813-kunit-kselftesth-skip-v1-1-57ae3de4f109@linutronix.de
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
