| Age | Commit message (Collapse) | Author |
|---|
|
Conversion of the old orion5x board files to devicetree has
stalled over the past few years, so it seems better to remove
the remaining ones in order to allow cleaning up the device
drivers.
Debian and OpenWRT no longer support orion5x, and buildroot
could keep using linux-7.3-LTS for a few more years.
Jeremy Peper still plans to convert the Terastation 2 Pro
to devicetree in the future, but that can be done even
after it is removed.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
In the 2021 board file removal, the gumstix and sharpsl
support was left around in order to make it easier to convert
more of the PXA platform to device tree, given that both
platforms had some level of support in qemu.
As far as I can tell, nobody has worked on additional DT
conversion in that time, and qemu has in turn deprecated
the entire PXA platform.
Schedule the remaining board files for removal now, as they
are unlikely to be of any help in the future. If anyone
wants to revive support for these machines, they can
obviously still contribute device tree based code and
work on updating the corresponding drivers.
Any drivers that are only usable on legacy PXA board files
can also get removed along with the boards, or saved by
adding devicetree support.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The Marvell Armada 510 (Dove) platform is supported both as devicetree
and atags/boardfile variants, with varying degrees of hardware support.
Russell was the last known user of the board file version, and there
are very few users overall. Unless Russell still needs this variant,
let's remove after the next LTS kernel, leaving the CONFIG_MACH_DOVE
variant with devicetree.
Reviewed-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
With no remaining users and support getting removed from future compilers,
there seems little point in keeping iwmmxt around much longer.
On the other hand, the iwmmxt support in the kernel rarely gets in the
way, so there is little cost, so set a removal date of early 2027 for
the moment. If anyone is still using this, it can be extended as long
there is binutils support.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The help text is seriously outdated and predates the introduction of
VFP floating point units that were available as early as some ARM926
based systems.
Change the help text to reflect that this is now a legacy feature
and that it will go away along with OABI support in the future.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Ralph Siemsen <ralphs@netwinder.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Mark Brown is still using this machine for regular work, so it should
not be removed as originally scheduled.
Give the platform another year, with the option to extend it further
based on the state of ATAGS support next year.
I expect that we end up removing all of s3c64xx when either Mark has
moved his test setup to other hardware, or when all other ATAGS based
machines are getting removed.
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This configuration option is for the older boot method that preceeded
ATAGS. This was scheduled for removal back in 2001, but the removal
never happened, presumably because nobody cared enough to actually do it,
not because there are any users left.
Add "(DEPRECATED)' to the Kconfig line and update the timeline so we can
remove it next year along with the other options that are not scheduled
for that timeframe.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Following the deprecation of big-endian ARMv8 mode in arch/arm64 in commit
1cf89b6bf660 ("arm64: Kconfig: Make CPU_BIG_ENDIAN depend on BROKEN"),
this does the same for ARMv7 (and v6), leaving the code around but
disabled by default: There are no known products that make use of this
mode any more, and it only hangs around for testing that it still works.
At the moment, there are no known bugs with big-endian ARMv7 mode, but
it does break occasionally and require someone to fix it. By marking
the code as 'depends on BROKEN' now, it will no longer be covered by CI
testing. If any users remain, they can keep patching out the dependency
but are more likely to run into regressions.
The big-endian ARMv5 support (CONFIG_CPU_ENDIAN_BE32) in contrast is
still used on Intel IXP4xx platform, and is the only currently supported
mode there, so this one can still be enabled.
There is no timeline for actually removing the code at this point,
we will likely debate this if we ever remove IXP4xx support on arm,
or big-endian support on ARM64.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Only a very small number of machines remain that rely on
traditional board files with the ATAGS boot data instead
of devicetree, and we have not accepted new ones for
a decade.
Most of the remaining ones are on their way out of the
kernel, but the Kconfig option that controls ATAGS
is still enabled by default.
To reflect the actual status of ATAGS support and alert
the remaining users of upstream and out-of-tree platforms
with this, change it to being default-disabled and
add a dependency on CONFIG_EXPERT.
The board specific defconfig files that rely on ATAGS
are changed to turn on both EXPERT and ATAGS if they
were not doing that already, and the ones that explicitly
turned it off before no longer need to.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This CPU revision remains a special case as it is now incompatible
with CONFIG_SMP. Only the Nokia N8x0 is used in practice, and even
that one is fairly rare these days, so let's plan to remove all of
them after the 2026 LTS kernel release.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Vladimir Zapolskiy <vz@mleia.com> # Freescale i.MX31
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Support for SMP on ARM1136r0 has been broken for a while, and nobody
is working on fixing it. I had a plan to change ARMv6 support to no
longer coexist in a common kernel with ARMv7 CPUs but instead ARMv5 and
below. This would have addressed the problem, but after a recent mailing
list discussion, we concluded that an easier approach is to just forbid
ARM1136r0 CPU support on SMP-enabled kernels.
This mainly affects users of the Nokia N800/N810 tablets using an
OMAP2420 SoC, which is the only commercial product with an ARM1136r0
that is still supported by the kernel.
The other machines that are still in the same hardware catogory are:
- TI OMAP2420 H4 reference board
- TI OMAP2430 SDP software development platform
- Freescale/NXP i.MX31 Lite Development Kit
- Buglabs i.MX31 Bug 1.x prototype
- Arm Integrator/AP with CM1136JF-S core module
To my knowledge, none of these have any actual users aside from
reference boards being used to more easily test the platforms.
There are also a few ARM1136r1 machines, which implement the
ARMv6K SMP support (barriers, atomics and TLS):
- Eukrea CPUIMX35 reference platform
- Freescale/NXP i.MX35 Product Development Kit
- ARM Integrator/CP/IM-LT3 with ARM1136J Core Tile
- ARM Realview/EB with ARM1136J Core Tile
Again, these are mainly reference implementations rather than
actual products, but since they support ARMv6K, they should
continue to work correctly in SMP-enabled kernels. For the
ARM Core Tile, I have not found a datasheet but instead use
the revision based on what the respective virtual models
report.
All the other ARMv6 platforms use an ARM1176 with ARMv6K,
VMSAv7 and Trustzone support.
To avoid the broken configuration, annotate the ARM1136 based
machines with specific CPU_ARM1136R0 or CPU_ARM1136R2 symbols
in Kconfig and make the r0 variants depend on !SMP.
Link: https://lore.kernel.org/linux-arm-kernel/2831c5a6-cfbf-4fe0-b51c-0396e5b0aeb7@app.fastmail.com/T/
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
As discussed on the mailing lists, there is no way to build OABI userspace
binaries any more since gcc-4.8, and now support is also getting dropped in
binutils, which will make it impossible to build pure OABI kernels at some
point in the future.
I found no evidence of anyone still sing OABI userspace on embedded systems
that keep getting kernel updates, but there are a few desktop-class machines
that date back to the 1990s using Intel StrongARM processors that were
supported by old versions of Debian, Red Hat or the official Corel
Netwinder distribution.
Add a much stricter Kconfig dependency for both native OABI and OABI_COMPAT
enabled kernels, only allowing either of them to be selected when building
a kernel that targets a StrongARM based machine.
Link: https://lore.kernel.org/lkml/2831c5a6-cfbf-4fe0-b51c-0396e5b0aeb7@app.fastmail.com/
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
On ARMv4 and ARMv5, the default is still to build for OABI, with
CONFIG_AEABI disabled, even though distros and toolchains no longer
support OABI as a target.
Change the default to EABI for all architecture levels and change
the defconfig entries as follows:
- All machines that used to explicitly enable EABI can drop that line now
- Machines that are likely to actually use old distros and had NWFPE
enabled in combination with OABI (rpc, footrbridge, netwinder,
assabet, neponset) explicitly turn it on now.
- Machines that already had both EABI and NWFPE disabled in defconfig
(spear3xx, spear6xx) were likely not usable with either OABI or
EABI and now use EABI instead implicitly, making it more likely that
they could work.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP
Acked-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
As part of driver initialization, e.g. st_lsm6dsx_init_shub() selects
the shub register page using st_lsm6dsx_set_page(). Selecting the shub
register page shadows the regular register space so whoami, among other
registers, is no longer accessible.
In applications where the IMU is permanently powered separately from the
processor, there is a window where a reset of the CPU leaves the IMU in
the shub register page. Once this occurs, any subsequent probe attempt
fails because of the register shadowing.
Using the ism330dlc, the error typically looks like
st_lsm6dsx_i2c 3-006a: unsupported whoami [10]
with the unknown whoami read from a reserved register in the shub page.
The reset register is also shadowed by the page select, preventing a
reset from recovering the chip.
Unconditionally clear the shub page before the whoami readout to ensure
normal register access and allow the initialization to proceed.
Place the fix in st_lsm6dsx_check_whoami() before the whoami check
because hw->settings, which st_lsm6dsx_set_page() relies on, is first
assigned in that function.
Placing the fix in a more logical place than the whoami check would
require a bigger restructuring of the code.
Fixes: c91c1c844ebd ("iio: imu: st_lsm6dsx: add i2c embedded controller support")
Signed-off-by: Andreas Kempe <andreas.kempe@actia.se>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Fixes "ERROR: A level 2 section cannot be used here".
Equal signs are reserved for document titles.
This file docs gets imported by driver-uapi.rst,
and the page title is defined there.
Signed-off-by: Rafael Passos <rafael@rcpassos.me>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260701012141.167868-1-rafael@rcpassos.me
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo modified the subject while pushing it]
|
|
Merge an ACPI TAD (Time and Alarm Device) driver fix for 7.2-rc2.
* acpi-tad:
ACPI: TAD: Check AC wake capability before enabling wakeup
|
|
xe_pci.c includes <kunit/test-bug.h> twice, separated only by the
<kunit/test.h> include. Drop the redundant second include; this is a
non-functional cleanup flagged by scripts/checkincludes.pl.
Fixes: 6cad22853cb8 ("drm/xe/kunit: Add stub to read_gmdid")
Signed-off-by: Anas Khan <anxkhn28@gmail.com>
Link: https://patch.msgid.link/20260702112820.34675-1-anxkhn28@gmail.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
The DW HDMI QP TX library was developed for and is currently only used
by Rockchip platforms. Add it to the Rockchip DRM drivers section to
ensure all relevant parties are kept in the loop on any changes.
As its file paths fall outside the generic wildcard patterns defined in
the ARM/Rockchip SoC support section, also add the
linux-rockchip@lists.infradead.org mailing list to avoid any
notification gaps.
Acked-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260612-maintainers-rk-drm-upd-v2-1-3ff65fc41a93@collabora.com
|
|
Before arming a user job, xe_exec_ioctl() only added the VM's
dma-resv KERNEL slot as a dependency. That slot covers rebinds and
the kernel operations of the VM's private BOs, but not external BOs
(bo->vm == NULL), which carry their kernel operations (evictions,
moves, ...) in their own dma-resv KERNEL slot.
The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for
memory management operations that must complete before the BO or its
backing store may be used: any accessor is required to wait on the
KERNEL fences before touching the resv. By skipping the external BOs'
KERNEL slots, the exec path violated that contract and could schedule
a user job while a kernel operation on an external BO mapped by the VM
was still in flight, racing against it and potentially reading or
writing memory that was being moved.
Replace the VM-only dependency with an iteration over every object
locked by the exec, adding each object's KERNEL slot as a job
dependency. This covers the VM resv (rebinds and private BOs) as well
as every external BO, mirroring the drm_gpuvm_resv_add_fence() call
that later publishes the job fence to the same set of objects.
Long-running mode continues to skip this, as before.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Cc: stable@vger.kernel.org
Assisted-by: GitHub_Copilot:claude-opus-4.8
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260702215805.4011228-1-matthew.brost@intel.com
|
|
__nolibc_syscall0() does not set the arg1 variable before passing it to
the asm block. This uninitialized variable read is undefined behavior.
Clang can miscompile this.
Mark the asm operand as write-only to fix this.
Fixes: 8e1930296f92 ("tools/nolibc: Add support for SPARC")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://patch.msgid.link/20260703-nolibc-sparc-asm-v1-1-c7fe73e2e777@weissschuh.net
|
|
Add a test that uses both getcwd() and readlink() so that both
are exercised.
First the happy path is tested by fetching what should be the
same string via getcwd() and readlink() and checking they match.
Then a few different combinations of bad parameters are passed to
getcwd() to make sure it returns NULL and sets errno in those
cases.
Signed-off-by: Daniel Palmer <daniel@thingy.jp>
Link: https://patch.msgid.link/20260702085101.3304547-4-daniel@thingy.jp
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
|
|
Cross-merge BPF and other fixes after downstream PR.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
|
Replace hardcoded fixed usleep_range() delays during clock recovery and
channel equalization with drm_dp_link_train_clock_recovery_delay()
and drm_dp_link_train_channel_eq_delay() helpers.
The original fixed delays are only valid for the case where bit[6:0] of
DPCD TRAINING_AUX_RD_INTERVAL(0000Eh) is 0x00, while core helpers apply
spec-compliant timings matching actual receiver capability values.
Additionally, add dpcd buffer to struct analogix_dp_device to cache
receiver capabilities. Call drm_dp_read_dpcd_caps() at commit entry to
populate cached DPCD data for subsequent link training steps, and
prepare for further usage of other DP helper APIs.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Tested-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260623075207.320603-1-damon.ding@rock-chips.com
|
|
'net-mlx5e-fix-crashes-in-dynamic-per-channel-stats-and-hv-vhca-agent'
Tariq Toukan says:
====================
net/mlx5e: Fix crashes in dynamic per-channel stats and HV VHCA agent
Since per-channel stats were converted to be allocated and published
lazily at first channel open in commit fa691d0c9c08 ("net/mlx5e:
Allocate per-channel stats dynamically at first usage"),
priv->channel_stats[] and priv->stats_nch are filled in
incrementally during interface bring-up. This opened a window in
which the various stats readers - most of them reachable from
userspace via netlink/netdev stats queries - can race with
mlx5e_open_channel() on another CPU and observe partially
initialized state. The HV VHCA stats agent, which is created
before the channels are opened, hits related problems of its own.
This series by Feng fixes the resulting crashes.
V3: https://lore.kernel.org/all/20260622083646.593220-1-tariqt@nvidia.com/
V2: https://lore.kernel.org/all/20260617140127.573117-1-tariqt@nvidia.com/
====================
Link: https://patch.msgid.link/20260630115151.729219-1-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
mlx5e_channel_stats_alloc() publishes a new entry to
priv->channel_stats[] and then increments priv->stats_nch as a
publication token, but neither store carries any memory barrier:
priv->channel_stats[ix] = kvzalloc_node(...);
if (!priv->channel_stats[ix])
return -ENOMEM;
priv->stats_nch++;
Concurrent readers compute the loop bound from priv->stats_nch and
then dereference priv->channel_stats[i] using plain accesses, e.g.
for (i = 0; i < priv->stats_nch; i++) {
struct mlx5e_channel_stats *cs = priv->channel_stats[i];
... cs->rq.packets ...
}
On weakly-ordered architectures (ARM, PowerPC, RISC-V) the writes to
channel_stats[ix] and stats_nch may become visible to other CPUs out
of program order. A reader can observe stats_nch == N while still
seeing channel_stats[N-1] == NULL, leading to a NULL pointer
dereference in the channel_stats loop.
This has been observed in production on BlueField-3 DPUs (arm64),
where ovs-vswitchd queries netdev statistics over netlink during NIC
bringup, racing mlx5e_open_channel() -> mlx5e_channel_stats_alloc()
on another CPU:
Unable to handle kernel NULL pointer dereference at virtual address 0x840
Hardware name: BlueField-3 DPU
pc : mlx5e_fold_sw_stats64+0x30/0x180 [mlx5_core]
Call trace:
mlx5e_fold_sw_stats64+0x30/0x180 [mlx5_core]
dev_get_stats+0x50/0xc0
ovs_vport_get_stats+0x38/0xac [openvswitch]
ovs_vport_cmd_fill_info+0x194/0x290 [openvswitch]
ovs_vport_cmd_get+0xbc/0x10c [openvswitch]
genl_family_rcv_msg_doit+0xd0/0x160
genl_rcv_msg+0xec/0x1f0
netlink_rcv_skb+0x64/0x130
genl_rcv+0x40/0x60
netlink_unicast+0x2fc/0x370
netlink_sendmsg+0x1dc/0x454
...
__arm64_sys_sendmsg+0x2c/0x40
Add mlx5e_stats_nch_write() and mlx5e_stats_nch_read() helpers in en.h
that wrap the smp_store_release()/smp_load_acquire() pair on stats_nch.
The release/acquire pair establishes the contract:
stats_nch == N => channel_stats[0..N-1] are visible and non-NULL.
Publish the stats_nch increment via mlx5e_stats_nch_write() in the
writer (mlx5e_channel_stats_alloc()), and read stats_nch via
mlx5e_stats_nch_read() in all readers: mlx5e RX/TX queue stats,
mlx5e_get_base_stats(), ethtool channels stats, IPoIB stats, the
sw_stats fold and the HV VHCA stats agent.
Fixes: fa691d0c9c08 ("net/mlx5e: Allocate per-channel stats dynamically at first usage")
Signed-off-by: Feng Liu <feliu@nvidia.com>
Reviewed-by: Eran Ben Elisha <eranbe@nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260630115151.729219-4-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
mlx5e_hv_vhca_stats_create() registers the stats agent through
mlx5_hv_vhca_agent_create(). The helper publishes the agent in
hv_vhca->agents[type] under agents_lock and immediately schedules an
asynchronous control invalidation on the HV VHCA workqueue before
returning to mlx5e.
The asynchronous invalidation invokes the control agent's invalidate
callback, which reads the hypervisor control block and forwards the
command to mlx5e_hv_vhca_stats_control(). That callback may either:
- call cancel_delayed_work_sync(&priv->stats_agent.work), or
- call queue_delayed_work(priv->wq, &sagent->work, sagent->delay).
However, the delayed_work and priv->stats_agent.agent are only
initialized after mlx5_hv_vhca_agent_create() returns to mlx5e:
agent = mlx5_hv_vhca_agent_create(...); /* publish + invalidate */
...
priv->stats_agent.agent = agent; /* too late */
INIT_DELAYED_WORK(&priv->stats_agent.work, ...); /* too late */
If the asynchronous control path runs before the two assignments
above, it can:
- Operate on an uninitialized delayed_work whose timer.function is
NULL. queue_delayed_work() calls add_timer() unconditionally, so
when the timer expires the timer softirq invokes a NULL function
pointer.
- Re-initialize the timer later through INIT_DELAYED_WORK() while
the timer is already enqueued in the timer wheel, corrupting the
hlist (entry.pprev cleared while the previous bucket node still
points at this entry).
- When the worker eventually runs, mlx5e_hv_vhca_stats_work() reads
sagent->agent (NULL) and dereferences it inside
mlx5_hv_vhca_agent_write().
Fix this by:
- Initializing priv->stats_agent.work before invoking
mlx5_hv_vhca_agent_create(), so the work is always in a valid
state when the control callback observes it.
- Adding a struct mlx5_hv_vhca_agent **ctx_update out-parameter
to mlx5_hv_vhca_agent_create(). The helper writes the agent
pointer to *ctx_update before publishing into hv_vhca->agents[]
and triggering the agents_update flow, so any callback
subsequently invoked from that flow already sees a valid
priv->stats_agent.agent. This avoids having the control
callback participate in agent initialization.
While at it, access priv->stats_agent.agent with
READ_ONCE()/WRITE_ONCE() for the cross-CPU access with the worker, and
clear priv->stats_agent.buf on the agent_create() failure path.
Fixes: cef35af34d6d ("net/mlx5e: Add mlx5e HV VHCA stats agent")
Signed-off-by: Feng Liu <feliu@nvidia.com>
Reviewed-by: Eran Ben Elisha <eranbe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260630115151.729219-3-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
mlx5e_hv_vhca_stats_create() is called from mlx5e_nic_enable(),
before mlx5e_open(). At that point priv->stats_nch is still zero,
because it is only ever incremented in mlx5e_channel_stats_alloc(),
which is reached only from mlx5e_open_channel().
mlx5e_hv_vhca_stats_buf_size() therefore returns 0, and
kvzalloc(0, GFP_KERNEL) returns ZERO_SIZE_PTR ((void *)16) rather
than NULL. The "if (!buf)" guard does not catch this, and
mlx5e_hv_vhca_stats_create() completes "successfully" with
priv->stats_agent.buf set to ZERO_SIZE_PTR.
Once channels are opened (priv->stats_nch > 0) and the hypervisor
enables stats reporting, mlx5e_hv_vhca_stats_work() recomputes
buf_len using the new non-zero stats_nch and calls
memset(buf, 0, buf_len) on ZERO_SIZE_PTR, faulting at address 0x10.
Allocate the buffer based on priv->max_nch, which is set in
mlx5e_priv_init() and is the upper bound on stats_nch:
- Add a separate helper mlx5e_hv_vhca_stats_buf_max_size() that
returns sizeof(per_ring_stats) * max(max_nch, stats_nch), and
use it for the kvzalloc() in mlx5e_hv_vhca_stats_create().
- Keep mlx5e_hv_vhca_stats_buf_size() (which returns based on
stats_nch) for the worker's active payload size, so the wire
format (block->rings = stats_nch) and the amount of data filled
by mlx5e_hv_vhca_fill_stats() are unchanged.
The max(max_nch, stats_nch) guard handles the rare case where
mlx5e_attach_netdev() recomputes max_nch downward across a
detach/resume cycle while priv->stats_nch persists (mlx5e_detach_netdev
does not call mlx5e_priv_cleanup, so stats_nch is only reset when
the netdev is destroyed). Without the guard, the worker could compute
buf_len from stats_nch and overrun the smaller buffer allocated based
on the reduced max_nch.
Allocating a non-zero buffer also makes the kvzalloc() failure path in
mlx5e_hv_vhca_stats_create() reachable for the first time: it returns
early without (re)creating the agent. Clear
priv->stats_agent.{agent,buf} in mlx5e_hv_vhca_stats_destroy() after
freeing them, so that if a later create() bails out on this path, a
subsequent teardown does not double-free the stale agent/buffer left
from a previous enable/disable cycle.
This mirrors the existing mlx5e pattern of preallocating arrays of
size max_nch (e.g. priv->channel_stats) and lazily populating
entries up to stats_nch on demand.
Fixes: fa691d0c9c08 ("net/mlx5e: Allocate per-channel stats dynamically at first usage")
Signed-off-by: Feng Liu <feliu@nvidia.com>
Reviewed-by: Eran Ben Elisha <eranbe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260630115151.729219-2-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
VS/PE values returned by drm_dp_get_adjust_request_voltage() and
drm_dp_get_adjust_request_pre_emphasis() are already encoded to their
native DPCD register bit positions. However, DPCD_VOLTAGE_SWING_SET /
DPCD_PRE_EMPHASIS_SET macros perform an extra internal shift. Feeding
the raw offset-bearing values directly leads to overlapping bitfields
and invalid lane training configuration, causing link training failures
and black screen.
Add right shift using DP_TRAIN_*_SHIFT constants to strip the DPCD bit
offsets before passing values to the SET macros and subsequent checks.
Apply this fix for both clock recovery and adjust training code paths.
Reported-by: Vicente Bergas <vicencb@gmail.com>
Closes: https://lore.kernel.org/all/CAAMcf8D-d+5n=H44KeKBSqWY42m+o32W+mO-r15VqWNyYhJL7Q@mail.gmail.com/
Fixes: d84b087c7662 ("drm/bridge: analogix_dp: Apply DP helper APIs to get adjusted voltages and pre-emphasises")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Link: https://lore.kernel.org/all/CAAMcf8D-d+5n=H44KeKBSqWY42m+o32W+mO-r15VqWNyYhJL7Q@mail.gmail.com/
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260623023506.309858-1-damon.ding@rock-chips.com
|
|
Add READ_ONCE()/WRITE_ONCE() annotations on fields that can be
changed concurrently in macsec_changelink() and macsec_update_offload():
- secy->key_len
- secy->xpn
- tx_sc->encoding_sa
- tx_sc->encrypt
- secy->protect_frames
- tx_sc->send_sci
- tx_sc->end_station
- tx_sc->scb
- secy->replay_protect
- secy->validate_frames
- secy->replay_window
- macsec->offload
This allows macsec_fill_info() to run locklessly without RTNL.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Sabrina Dubroca <sd@queasysnail.net>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Link: https://patch.msgid.link/20260701094341.3218199-1-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Tariq Toukan says:
====================
net/mlx5: LAG bug fixes
Three bug fixes by Shay in the mlx5 LAG subsystem.
Patch 1 fixes an off-by-one in the error rollback path of
mlx5_lag_create_single_fdb_filter(): the loop started from the
failed index i, potentially operating on uninitialized state or
double-tearing-down an entry that had already self-rolled-back.
The rollback should start from i - 1.
Patch 2 fixes a hang in mlx5_mpesw_work(): when
mlx5_lag_get_devcom_comp() returns NULL the function returned
early without calling complete(), blocking any caller waiting on
mpesww->comp indefinitely.
Patch 3 fixes a kernel crash during teardown when
mlx5_lag_get_dev_seq() returns an error because no device is
marked as master or the peer is no longer in the LAG. The peer
flow cleanup is now skipped instead of proceeding with a bad
pointer.
This series by Shay fixes three bugs in the mlx5 LAG subsystem.
v1: https://lore.kernel.org/all/20260617063204.547427-2-tariqt@nvidia.com/
====================
Link: https://patch.msgid.link/20260630112917.698313-1-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
mlx5_lag_get_dev_seq() will return error when the peer isn't in the LAG
or when no device is marked as master. Result bad memory access and kernel
crash[1].
Hence, skip the peer when lookup fails.
Note: In case there are peer flows, they are cleaned before LAG cleared
the master mark.
[1]
RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0x3d/0x350 [mlx5_core]
Call Trace:
<TASK>
mlx5e_tc_clean_fdb_peer_flows+0xc1/0x130 [mlx5_core]
mlx5_esw_offloads_unpair+0x3a/0x400 [mlx5_core]
mlx5_esw_offloads_devcom_event+0xee/0x360 [mlx5_core]
mlx5_devcom_send_event+0x7a/0x140 [mlx5_core]
mlx5_esw_offloads_devcom_cleanup+0x2f/0x90 [mlx5_core]
mlx5e_tc_esw_cleanup+0x28/0xf0 [mlx5_core]
mlx5e_rep_tc_cleanup+0x19/0x30 [mlx5_core]
mlx5e_cleanup_uplink_rep_tx+0x36/0x40 [mlx5_core]
mlx5e_cleanup_rep_tx+0x55/0x60 [mlx5_core]
mlx5e_detach_netdev+0x96/0xf0 [mlx5_core]
mlx5e_netdev_change_profile+0x5b/0x120 [mlx5_core]
mlx5e_netdev_attach_nic_profile+0x1b/0x30 [mlx5_core]
mlx5e_vport_rep_unload+0xdd/0x110 [mlx5_core]
__esw_offloads_unload_rep+0x81/0xb0 [mlx5_core]
mlx5_eswitch_unregister_vport_reps+0x1d7/0x220 [mlx5_core]
mlx5e_rep_remove+0x22/0x30 [mlx5_core]
device_release_driver_internal+0x194/0x1f0
bus_remove_device+0xe8/0x1b0
device_del+0x159/0x3c0
mlx5_rescan_drivers_locked+0xbc/0x2d0 [mlx5_core]
mlx5_unregister_device+0x54/0x80 [mlx5_core]
mlx5_uninit_one+0x73/0x130 [mlx5_core]
remove_one+0x78/0xe0 [mlx5_core]
pci_device_remove+0x39/0xa0
Fixes: 971b28accc09 ("net/mlx5: LAG, replace mlx5_get_dev_index with LAG sequence number")
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260630112917.698313-4-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
mlx5_mpesw_work() returned without calling complete() when
mlx5_lag_get_devcom_comp() returned NULL. A caller that queued the
work and waited on mpesww->comp would block indefinitely.
Funnel the early-return path through a new "complete" label so the
waiter is always woken.
Fixes: b430c1b4f63b ("net/mlx5: Replace global mlx5_intf_lock with HCA devcom component lock")
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260630112917.698313-3-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
On failure at index i, the reverse cleanup loop in
mlx5_lag_create_single_fdb() starts from i, so the failed index
itself is rolled back. That can operate on uninitialized state or
double-tear-down a rule the add_one path already self-rolled-back.
Start the rollback from i - 1 so only successfully-installed entries
are undone.
Fixes: ddbb5ddc43ad ("net/mlx5: LAG, Refactor lag logic")
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260630112917.698313-2-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Vijendar Mukunda <Vijendar.Mukunda@amd.com> says:
This patch series adds Sound Open Firmware (SOF) enablement for AMD
ACP7.B/ACP7.F platforms by introducing a dedicated ACP7x PCI driver/ops
layer built on the existing ACP SOF infrastructure, plus required IPC3
topology/token extensions for ACP7x I2S/TDM.
Changes:
- Add new ACP7x PCI driver + DSP ops, including suspend/resume and
IRQ handling paths.
- Extend AMD ACP firmware loading logic for signed images and
SRAM-based data loading on ACP7x.
- Introduce a new SOF DAI type for AMD I2S/TDM and extend IPC3
topology tokens to carry an ACP TDM/I2S format field.
Link: https://github.com/thesofproject/linux/pull/5813
Link: https://patch.msgid.link/20260701095759.1012929-1-Vijendar.Mukunda@amd.com
|
|
Add amd_sof_acp7x_suspend() and amd_sof_acp7x_resume() for ACP7.B/7.F
platforms power management.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-17-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add SOF_DAI_AMD_I2S DAI type for ACP7.B/7.F I2S/TDM interfaces.
Register the ACPTDM topology DAI name and map it to SOF_DAI_AMD_I2S;
IPC3 continues to parse ACP I2S link parameters through SOF_ACPI2S_TOKENS
(including the format token from the prior commit), not a new token
group named after ACPTDM. Add sof_link_acp_i2s_load() and the
SOF_DAI_AMD_I2S PCM dai link fixup path.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-16-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add format field to sof_ipc_dai_acp_params for ACP I2S format selection.
Add SOF_TKN_AMD_ACPI2S_FORMAT (1703) to the existing SOF_ACPI2S_TOKENS
tuple and wire it into acpi2s_tokens[] so integrators continue using the
same ACPI2S token group as earlier ACP I2S topologies, not a separate
ACPTDM-specific token set.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-15-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
ACP7.B and ACP7.F signed firmware data blocks must be written to SRAM
instead of DRAM. Select SOF_FW_BLK_TYPE_SRAM for PCI revision 0x7B and
above in acp_sof_load_signed_firmware().
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-14-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Read ACPI property acp-sof-signed-firmware-image in sof_acp7x_ops_init()
and register acp_sof_load_signed_firmware as the load_firmware callback
only when the property is set.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-13-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Check adata->acp_sof_signed_firmware_image alongside the existing quirk
flag so that ACP7.B/7.F platforms configured through ACPI also get the
SHA DMA header included during signed firmware loading.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-12-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add sof_acp7x_post_fw_run_delay() to introduce a small delay after
firmware boot completion on resume to avoid DSP entering an
unrecoverable state.
Register it as post_fw_run callback only when the ACPI property
acp-sof-post_fw_run_delay is set, following the same pattern used
by the Vangogh platform.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-11-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The ACP7.B/7.F ACPI signed path already reads SizeFWSigned from the image
header into size_fw. Before adding ACP_IMAGE_HEADER_SIZE for SHA DMA,
reject payload size zero or any size_fw with size_fw > fw_bin_size -
ACP_IMAGE_HEADER_SIZE, so size_fw + ACP_IMAGE_HEADER_SIZE cannot exceed the
supplied firmware buffer.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-10-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
ACP7.B/7.F signed images read SizeFWSigned from a fixed offset inside
the ACP header. Reject firmware buffers shorter than the header so we
never read past the end of the supplied image.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-9-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Parse SizeFWSigned from the ACP image header when loading signed
firmware on ACP7.B/7.F platforms. Keep the legacy
ACP_FIRMWARE_SIGNATURE subtraction for pre-7B platforms using quirks.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-8-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add acp7x_irq_handler() and register it from amd_sof_acp7x_probe() for
DSP doorbell IPC interrupts on ACP7.B/7.F.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-7-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add amd_sof_acp7x_probe() and amd_sof_acp7x_remove() for ACP7.B/7.F.
Wire probe and remove into sof_acp7x_ops_init().
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-6-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Replace the open-coded pci_rev comparison with a switch statement for
clearing ACP_SW1_I2S_ERROR_REASON. This makes the per-platform control
explicit and easier to extend.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-5-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
For ACP7.B/7.F, poll only the PGFSM tile status bits (P0-P4) and
consider the tiles powered on when the masked status becomes 0.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-4-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add SOF support for ACP7.B and ACP7.F PCI revision based platforms.
This covers Kconfig/Makefile entries, register offset definitions,
DMA descriptor/channel/status paths, PGFSM power-on handling,
PCI device driver, I2S/DMIC DAI definitions, and IPC SW interrupt
trigger offset selection for ACP7.B/7.F.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-3-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add snd_soc_acpi_amd_acp7x_sof_machines[] ACPI machine table for ACP7.B
and ACP7.F PCI revision based platforms. Add the extern declaration to
mach-config.h so that it can be referenced from the SOF PCI driver.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260701095759.1012929-2-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
