The driver supports a new comp_mask: REQ_MASK_FIXED_QUE_ATTR.
The application sets this comp_mask bit in the CREATE_QP ureq
to indicate direct control of the QP. The driver goes through
the required processing for app allocated QPs (previous patches).
Only variable WQE mode is supported for these QPs.
This patch removes an unused comp_mask:
BNXT_RE_QP_REQ_MASK_VAR_WQE_SQ_SLOTS
Link: https://patch.msgid.link/r/20260519150041.7251-10-sriharsha.basavapatna@broadcom.com
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
App allocated QPs can use a separate doorbell for each QP.
This doorbell region can be passed through a new driver specific
DBR_HANDLE attribute, during QP creation. When this attribute
is set, associate the QP with the given doorbell region.
While the QP holds a reference to the dbr, the dbr itself
cannot be destroyed and is rejected with EBUSY error.
Link: https://patch.msgid.link/r/20260519150041.7251-9-sriharsha.basavapatna@broadcom.com
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
If the DPI is freed when the dbr object is freed, but if the
process has not unmapped the page yet, then the DPI slot could
get reallocated to another process while the original process
still has it mapped. To prevent this, save the DPI info in the
mmap entry during dbr allocation and free the DPI slot from
bnxt_re_mmap_free(), which enures that there are no references
to it.
This change is needed to support doorbell allocation to QPs
in the next patch.
Link: https://patch.msgid.link/r/20260519150041.7251-8-sriharsha.basavapatna@broadcom.com
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
The current logic in the doorbell cleanup function is not
sufficient for a change in a subsequent patch, that fails
doorbell remove operation in some conditions. The cleanup
should facilitate freeing of the dbr object when the caller
may not retry the teardown operation (implicit teardown:
process-exit/driver-removal).
Extend this counter to use kref mechanism so that the dbr
object gets freed (via kref callback) when there are no more
references to it, rather than directly freeing it in the
cleanup uapi.
Link: https://patch.msgid.link/r/20260519150041.7251-7-sriharsha.basavapatna@broadcom.com
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
The hwq depth shouldn't be computed using slots/round-up logic for
app allocated QPs, use the max_wqe value saved earlier.
Link: https://patch.msgid.link/r/20260519150041.7251-6-sriharsha.basavapatna@broadcom.com
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
For app allocated QPs, the driver shouldn't use slots/round-up logic
to compute the msn table size. The application handles this logic
and computes 'sq_npsn' and passes it to the driver using a new uapi
parameter.
Link: https://patch.msgid.link/r/20260519150041.7251-5-sriharsha.basavapatna@broadcom.com
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
For app allocated QPs, there's no need to reserve extra slots.
The application accounts for this while allocating the SQ.
Link: https://patch.msgid.link/r/20260519150041.7251-4-sriharsha.basavapatna@broadcom.com
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
For app allocated QPs, there's no need to add extra slots or
to round up the slot count. Use 'max_recv_wr' count provided
by the application as is.
Link: https://patch.msgid.link/r/20260519150041.7251-3-sriharsha.basavapatna@broadcom.com
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
The umem changes for CQ added a helper - bnxt_re_setup_sginfo().
Use the same helper for QP creation since we support only 4K
pages for QP ring memory too.
Add a new helper function bnxt_re_get_psn_bytes() to improve
readability as this code will be updated in subsequent patches.
Link: https://patch.msgid.link/r/20260519150041.7251-2-sriharsha.basavapatna@broadcom.com
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
The following scenarios will cause the call_rcu_tasks() boot-time
tests failed:
CPU0 CPU1
rcu_init_tasks_generic()
->rcu_tasks_initiate_self_tests()
->call_rcu_tasks_trace(&tests[1].rh, test_rcu_tasks_callback)
->call_rcu_tasks_generic()
->havekthread = smp_load_acquire(&rtp->kthread_ptr)
"The havekthread is false"
....
rcu_tasks_kthread()
->smp_store_release(&rtp->kthread_ptr, current)
->rcu_tasks_one_gp()
->rcuwait_wait_event()
->rcu_tasks_need_gpcb()
->for (cpu = 0; cpu < dequeue_limit; cpu++)
->rcu_segcblist_n_cbs(&rtpcp->cblist) == 0
->schedule()
->raw_spin_trylock_rcu_node()
->needwake = (func == wakeme_after_rcu) ||
(rcu_segcblist_n_cbs(&rtpcp->cblist) == rcu_task_lazy_lim)
"the rcu_task_lazy_lim default value is 32, and the
func pointer is test_rcu_tasks_callback, lead to needwake
is false."
->if (havekthread && !needwake && !timer_pending(&rtpcp->lazy_timer))
"the havekthread is false, will not enter here."
....
"the needwake is false lead to rtp_irq_work can not queue,
even if the rtp->kthread_ptr already exists at this point."
->if (needwake && READ_ONCE(rtp->kthread_ptr))
->irq_work_queue(&rtpcp->rtp_irq_work)
For the above scenarios, if the call_rcu_tasks() is not called again
afterward, the rcu_tasks_kthread will not have a chance to be wakeup,
the test_rcu_tasks_callback() will never be called, the boot-time tests
failed can happen, this commit therefore check havekthread variable, if
it's false and the rtpcp->cblist is empty, set needwake variable is true,
if the rtp->kthread_ptr exist, the rtpcp->rtp_irq_work can be queued to
wakeup rcu_tasks_kthread.
Signed-off-by: Zqiang <qiang.zhang@linux.dev>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Currently, rcu_normal_wake_from_gp is only enabled by default
on small systems(<= 16 CPUs) or when a user explicitly set it
enabled.
Introduce an adaptive latching mechanism:
* Track the number of in-flight synchronize_rcu() requests
using a new rcu_sr_normal_count counter;
* If the count reaches/exceeds RCU_SR_NORMAL_LATCH_THR(64),
it sets the rcu_sr_normal_latched, reverting new requests
onto the scaled wait_rcu_gp() path;
* The latch is cleared only when the pending requests are fully
drained(nr == 0);
* Enables rcu_normal_wake_from_gp by default for all systems,
relying on this dynamic throttling instead of static CPU
limits.
Testing(synthetic flood workload):
* Kernel version: 6.19.0-rc6
* Number of CPUs: 1536
* 60K concurrent synchronize_rcu() calls
Perf(cycles, system-wide):
total cycles: 932020263832
rcu_sr_normal_add_req(): 2650282811 cycles(~0.28%)
Perf report excerpt:
0.01% 0.01% sync_test/... [k] rcu_sr_normal_add_req
Measured overhead of rcu_sr_normal_add_req() remained ~0.28%
of total CPU cycles in this synthetic stress test.
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Tested-by: Samir M <samir@linux.ibm.com>
Suggested-by: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
This commit documents the rcu_access_pointer() use case for fetching the
old value of an RCU-protected pointer within a lockless updater for use
by an atomic cmpxchg() operation.
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Reported-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
This commit replaces a nested ?: sequence with clamp_val(). This does
not reduce the number of lines of code, but it does simplify the line
that it modifies.
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
This commit replaces a nested ?: sequence with clamp(). This does not
reduce the number of lines of code, but it does simplify the line that
it modifies.
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
It turns out that there are BPF use cases that rely on nesting RCU
Tasks Trace readers. These use cases are well-served by the old
rcu_read_lock_trace() and rcu_read_unlock_trace() functions that maintain
a nesting counter in the task_struct structure. But these use cases incur
a performance penalty when using the shiny new rcu_read_lock_tasks_trace()
and rcu_read_unlock_tasks_trace() functions, which nest in the same way
that SRCU does.
This means that rcu_read_lock_trace() and rcu_read_unlock_trace()
will be with us for some time. Therefore, remove the checkpatch.pl
deprecation.
Also, the rcu_read_lock_tasks_trace() and rcu_read_unlock_tasks_trace()
functions are intended for use only by BPF. Therefore, add them to
the list of functions that checkpatch complains about outside of BPF
(and of course, RCU).
Reported-by: Puranjay Mohan <puranjay@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Andy Whitcroft <apw@canonical.com>
Cc: Joe Perches <joe@perches.com>
Cc: Dwaipayan Ray <dwaipayanray1@gmail.com>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
s/srcu_read_lock_safe()/srcu_read_lock_fast_updown(), there being no
such thing as srcu_read_lock_safe().
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
This adds "--do-norm", --do-no-norm", and "--no-norm" synonyms for the
"--do-normal" group of torture.sh command-line arguments.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
The constraints on the arguments to kvm-series.sh are easy to forget,
so this commit adds examples in the header comment.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
This new torture_sched_set_normal() function clamps the nice value at
the MIN_NICE..MAX_NICE limits, splatting it these limits are exceeded.
It then invokes sched_set_normal() to set the new value. This prevents
more difficult-to-debug failures within the scheduler.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Currently, rcutorture bypasses lazy RCU by using call_rcu_hurry().
This works, avoiding the dreaded rtort_pipe_count WARN(), but fails to
fully test lazy RCU. The rtort_pipe_count WARN() splats because lazy RCU
could delay the start of an RCU grace period for a full stutter period,
which defaults to only three seconds.
This commit therefore reverts the call_rcu_hurry() instances
back to call_rcu(), but, in kernels built with CONFIG_RCU_LAZY=y,
queues a workqueue handler just before the call to stutter_wait() in
rcu_torture_writer(). This workqueue handler invokes rcu_barrier(),
which motivates any lingering lazy callbacks, thus avoiding the splat.
Reported-by: Saravana Kannan <saravanak@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Extend the binding to cover details specific to the Tenstorrent RISC-V
IOMMU. In particular, a second register range is added which contains
M-privileged registers, e.g., PMAs and PMPs.
The RISC-V spec S-privileged registers remain in the first register
range and are compatible with "riscv,iommu" so the Linux driver does not
notice any difference, but the binding will be used by OpenSBI and
potentially other M-mode software.
Reviewed-by: Joel Stanley <joel@jms.id.au>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[fustini: fix dt_binding_check errors]
Signed-off-by: Drew Fustini <fustini@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJPBAABCgA5FiEE8rQSAMVO+zA4DBdWxWXV+ddtWDsFAmoRu2cbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJEMVl1fnXbVg7jk0P/iokJwhO+YP7rdnDPAl6
wXYq/e4HxSl65//wwkR2Q7zc/GWOSdGZoP7fHCtXY52RERDKq2xrkQ+fBtnEMvS3
N6bwM0kVBoGPkXRHrf55SdfH7ITldeVAYIRIajO5bVT/j/F8l9s7ivXmI0Ep1xgZ
Eiv5MuOiW/kPLzYW1pHP+UniaUhIgQGTRcHs7NotAn55q2odnLdddRWx8NGT1kAe
Owydf6c0/B/+7NLhTLQl/w4WmeFL3OR0b0HuHiVYBNuQBkgCxwcUsERfPjnWpAbr
Pll32JKmJxH1Rthr8qA++Xv72D31VNAYVwxyieq/kPSFg6rwjcKw2lLdFKv99fCT
3OcDg0N9X20RK4ZcyMSwiCkS92DFStmVy4FtVIdNXbgpRcbw/jHNB6CnFq+RHOVU
wBNYdLte7zSmroDSQ/U2l/xY0n1KCf/KcYBxnkIkri6fdl/f2o8/monPfbsUvYiK
0qI3ODSomBpQRU0vYddJ28KfEx0iHqSQzmDyRFDlDuNb7M24d5W82jWLf60Nlk4h
ngehWVaVvLm8y4YiRteD10TGD7ClBE6ilu0t0dS2ys7o7stIAuXbjIP435tYz2T4
B0ddujn7S0mwNCoT+5yRfmxPQFJpyt93jU65VTJ95Mc7Pg43/D6b5ju7tvZlVdNw
NT4nY8sOiLy1KR72SvguXPSr
=hKb2
-----END PGP SIGNATURE-----
Merge tag 'for-7.1-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
"A batch of fixes to simple quotas:
- add conditional rescheduling point not dependent on the lock during
inode iterations to avoid delays with PREEMPT_NONE enabled
- fix subvolume deletion so it does not break the squota invariants
- properly handle enabling squota, tracking extents in the initial
transaction
- catch and warn about underflows, clamp to zero to avoid further
problems
And one fix to inode size handling:
- fix handling of preallocated extents beyond i_size when not using
the no-holes feature"
* tag 'for-7.1-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
btrfs: swallow btrfs_record_squota_delta() ENOENT
btrfs: clamp to avoid squota underflow
btrfs: fix squota accounting during enable generation
btrfs: check for subvolume before deleting squota qgroup
btrfs: always drop root->inodes lock before cond_resched()
btrfs: mark file extent range dirty after converting prealloc extents
Add a riscv,pmu device tree node with SBI PMU event mappings for the
SiFive X280 hardware performance counters. This enables OpenSBI to
expose the SBI PMU extension, allowing Linux perf to use the 4
programmable counters (mhpmcounter3-6) across 3 event classes:
instruction commit, microarchitectural, and memory system events.
Event encodings are derived from the SiFive Tenstorrent X280 MC Manual
(21G3.04.00) Table 13, section 3.10.5.
Assisted-by: Claude:claude-opus-4-6[1m]
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Drew Fustini <fustini@kernel.org>
Signed-off-by: Drew Fustini <fustini@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
-----BEGIN PGP SIGNATURE-----
iJUEABMJAB0WIQSmtYVZ/MfVMGUq1GNcsMJ8RxYuYwUCahG3QAAKCRBcsMJ8RxYu
Y92cAYC0vDsgBcwRgeLBhrEHmzvkNBwKJAqAvXzYoxP/ux+N7hvS3k7kieXXTmmw
v/fX7AMBf2C9hjNn6la4uRxR0kkQWneqQWAvkxiy/584xnCheCFR3D+olAgh0ySp
BWRCCbEzwg==
=lIaC
-----END PGP SIGNATURE-----
Merge tag 'xfs-fixes-7.1-rc5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
Pull xfs fix from Carlos Maiolino:
"A single fix for a race in xfs buffer cache which may lead to
filesystem shutdown due to inconsistent metadata if the buffer
lookup happens to find an old dead buffer still in the cache"
* tag 'xfs-fixes-7.1-rc5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: fix a buffer lookup against removal race
The assignment of strrchr() return values to non-const char * variables
triggers a -Werror=discarded-qualifiers warning when building with GCC
14.
This happens because in newer glibc versions, strrchr() returns a 'const
char *' if the input string is const.
Properly declare 'line2' and 'nl' as const char * to match the glibc
function signature and ensure type safety. This avoids the need for
explicit type casting and aligns with the design pattern of not
modifying read-only memory in the perf tool.
Reviewed-by: Ian Rogers <irogers@google.com>
Signed-off-by: Li Guan <guanli.oerv@isrc.iscas.ac.cn>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Fix a variable truncation when calculating period in microseconds as
part of the solution for the ERR051198 in .apply() callback.
Example scenario:
- Period of 3us (PWMPR = 196 and prescaler = 1)
- Expected value in tmp: 198000000000 (NSEC_PER_SEC * (196 + 2) * 1)
- Actual value is 431504384 (truncation to u32)
Signed-off-by: Ronaldo Nunez <rnunez@baylibre.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260522191348.6227-1-rnunez@baylibre.com
Fixes: a25351e4c7 ("pwm: imx27: Workaround of the pwm output bug when decrease the duty cycle")
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
PWMCON register Bit(3) is used to configure whether to pre divide
the clock source. Most revisions clear this bit to disable frequency
division. However, mt7628 needs to set this bit. Hence, we introduce
a new clksel_fixup flag to correctly configure the clock source for
mt7628.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Link: https://patch.msgid.link/OS7PR01MB136020DA816E8D601D5BA8BF4BC74A@OS7PR01MB13602.jpnprd01.prod.outlook.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
- Implement _THIS_IP_ for inline asm
- Add Simon Schuster as a maintainer and mark the NIOS2 as Supported
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEoHhMeiyk5VmwVMwNGZQEC4GjKPQFAmoRzqMACgkQGZQEC4Gj
KPT/zg//Y83pZF/w5pjBHDVtk9qn0wnoWCECYfigAjSywIRm4swBQcfA2XG8+mJ7
I6t5LyVhgSRKlm9Flk/YIwRbRQFjsSnMgQKE9I+tZhVMbzni4ilqgD30iEDAyHwt
34ezQUVpGrOytzsyM2SqK4ftGUgwSYMKuhyo5oqKKR5flBaP8b8DLpqLQmLlir/6
5PHQf6Z8o0G080s3GTOTRCFAfhFRvaq+lDc3koFZT8xO1dePLABEYRFoAKuzgOOl
I1amihW+dBZgXx4GwACLBn911IF77lwnTzc+I7Y/kokUuNCCGKloWtr1EDeM+w4k
CvtUaohhBRXCN8rSpdaaKxyBR9P1MZnfCxflOBXvNpfHPUvbDFD/aR5tQNW0Es+V
q9mxyeK0rwjo8lMOOZel98Bdq1KPygPW5RCBT9atoqpktYlmiBDYPIY3v2kANkZn
s3qJ0iVpAB2shHS3mTLP9BkW+alvJozaZAhKnGt2i87HiaVD5XL3aw1VVCR/JWuC
lcuR6GzjIoBneWK4CdgAnTqIziVwp50yM32DG2zrGSu8f32HsfrKSJO8auowXQJl
6g0YB4PBXTZgISIcamywEMX5Y7Gv3O77Se45qyvbl/zI2Ck94IDXbFoGZbh0dkXc
DnunewQU+ggTHrg5WexNmocrZnOw+vmHfevB9zhi+2DNuFqDyHQ=
=LDk6
-----END PGP SIGNATURE-----
Merge tag 'nios2_updates_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux
Pull nios2 fixes from Dinh Nguyen:
- Implement _THIS_IP_ for inline asm
- Add Simon Schuster as a maintainer and mark the NIOS2 as Supported
* tag 'nios2_updates_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux:
nios2: Implement _THIS_IP_ using inline asm
MAINTAINERS: arch/nios2: Add Simon Schuster as co-maintainer
The offset for the cleanup-label jump is computed before the MOV R7
instruction is emitted, but the JMP lands after it. Account for the
extra insn in the offset calculation (-2 instead of -1). Drop the
redundant self-loop in the else branch; gen->error = -ERANGE already
marks the generation as failed.
Fixes: fb2b0e2901 ("libbpf: Update light skeleton for signing")
Signed-off-by: KP Singh <kpsingh@kernel.org>
Link: https://lore.kernel.org/r/20260522215337.662271-2-kpsingh@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
- Remove the software node on platform device release(); without this,
the software node remains registered after the device is gone and a
subsequent platform_device_register_full() reusing the same node fails
with -EBUSY
- In sysfs_update_group(), do not remove a pre-existing directory when
create_files() fails; the previous code would silently destroy a sysfs
group that the caller did not create
- Set fwnode->secondary to NULL in fwnode_init() to avoid dereferencing
uninitialized memory (e.g. in dev_to_swnode()) when the firmware node
is allocated on the stack or via a non-zeroing allocator
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS2q/xV6QjXAdC7k+1FlHeO1qrKLgUCahGkDAAKCRBFlHeO1qrK
Ls4tAP0Ti0VhRJOHz2h3boyp0tXH1bIt082073oJGasHAjnoeQEAg0zbdA2Qkj9o
DDv5iX6KYGkeFUzv8MjuWUexc5HlYQ0=
=Lc0O
-----END PGP SIGNATURE-----
Merge tag 'driver-core-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core
Pull driver core fixes from Danilo Krummrich:
- Remove the software node on platform device release(); without this,
the software node remains registered after the device is gone and a
subsequent platform_device_register_full() reusing the same node
fails with -EBUSY
- In sysfs_update_group(), do not remove a pre-existing directory when
create_files() fails; the previous code would silently destroy a
sysfs group that the caller did not create
- Set fwnode->secondary to NULL in fwnode_init() to avoid dereferencing
uninitialized memory (e.g. in dev_to_swnode()) when the firmware node
is allocated on the stack or via a non-zeroing allocator
* tag 'driver-core-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core:
device property: set fwnode->secondary to NULL in fwnode_init()
sysfs: don't remove existing directory on update failure
driver core: platform: remove software node on release()
- syzbot triggred crash in rxe due to concurrent plug/unplug
- Possible non-zero'd memory exposed to userspace in bnxt_re
- Malicous 'magic packet' with SIW causes a buffer overflow
- Tighten the new uAPI validation code to not crash in debugging prints
and have the right module dependencies in drivers
- mana was missing the max_msg_sz report to userspace
- UAF in rtrs on an error path
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRRRCHOFoQz/8F5bUaFwuHvBreFYQUCahDmpgAKCRCFwuHvBreF
YRRTAP0YXV95Y5gcli55IhetKjJUzQbaREz2NueqIpf1IorMbAD+Lns4DgZCU0KW
bC81x7cGHBSyCju9zogIdBFJhsbxeQ4=
=MxJz
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Pull rdma fixes from Jason Gunthorpe:
- syzbot triggred crash in rxe due to concurrent plug/unplug
- Possible non-zero'd memory exposed to userspace in bnxt_re
- Malicous 'magic packet' with SIW causes a buffer overflow
- Tighten the new uAPI validation code to not crash in debugging prints
and have the right module dependencies in drivers
- mana was missing the max_msg_sz report to userspace
- UAF in rtrs on an error path
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
RDMA/rtrs: Fix use-after-free in path file creation cleanup
RDMA/mana_ib: Report max_msg_sz in mana_ib_query_port
RDMA/core: Do not read wild stack memory in uverbs_get_handler_fn()
RDMA/core: Move the _ib_copy_validate_udata* functions to ib_core_uverbs
RDMA/siw: Reject MPA FPDU length underflow before signed receive math
RDMA/bnxt_re: zero shared page before exposing to userspace
selftests/rdma: explicitly skip tests when required modules are missing
RDMA/nldev: Add mutual exclusion in nldev_dellink()
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Lines starting with '#' will be ignored.
-----BEGIN PGP SIGNATURE-----
iJUEABMJAB0WIQSmtYVZ/MfVMGUq1GNcsMJ8RxYuYwUCahG0TgAKCRBcsMJ8RxYu
Y18FAX0cD9LJOQetOPnFHYl6AdO4f0OmaBnjbyF19iRQjrLo9GthdiQf7WXD6QaG
b00H18ABgMYDhTO70T1zH2KkpaaVBOKHT9oFQ+Bzki6R1J+rCU2ZXOiQARmFLvd3
xE25p55FiQ==
=UWBN
-----END PGP SIGNATURE-----
Merge tag 'xfs-fixes-7.1-rc5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux into test_merge
xfs: fixes for v7.1-rc5
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Lines starting with '#' will be ignored.
- Buffer overflow due to missing input validation in pds
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRRRCHOFoQz/8F5bUaFwuHvBreFYQUCahDk/QAKCRCFwuHvBreF
YRxuAQCliGLeyivZ1BVcJ0rB7obSheMWS6drbJbw2H5LmRkAcwD/XHJeTHsu2Cqs
Pf8mZR5b+MZGm3SpAxYR+FJLxV4rmAc=
=CxSO
-----END PGP SIGNATURE-----
Merge tag 'for-linus-fwctl' of git://git.kernel.org/pub/scm/linux/kernel/git/fwctl/fwctl
Pull fwctl fix from Jason Gunthorpe:
- Buffer overflow due to missing input validation in pds
* tag 'for-linus-fwctl' of git://git.kernel.org/pub/scm/linux/kernel/git/fwctl/fwctl:
fwctl: pds: Validate RPC input size before parsing
When running on a GICv5 host, we push an arch-timer-specific interrupt
domain for the timer interrupts. This interrupt domain is used to mask
the host interrupt when a GICv5 guest is running. However, this
interrupt domain is still in place when running with a GICv3 guest on
GICv5 hardware. The result is that some interrupt state changes are
not correctly propragated to the host irqchip driver for legacy
guests.
Explicitly pass irqchip state changes though to the host irqchip
driver when running a GICv3-based guest on a GICv5 host. This bypasses
all masking, and thereby operates just as a native GICv3 guest would,
with the exception of having an additional irq domain in the
hierarchy.
Fixes: 9491c63b6c ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5")
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Link: https://lore.kernel.org/r/20260520091949.542365-19-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
With GICv5 an interrupt of equal or lower priority cannot be signalled
until there has been a priority drop. This is done via the GIC CDEOI
system instruction. Once this has been executed, the hardware is able
to signal the next interrupt if there is one.
As all interrupts are programmed to have the same priority, no new
interrupts can be signalled until the priority drop has happened. This
can cause issues when, for example, an interrupt remains active while
a long running process takes place, such as when injecting a physical
interrupt into a guest VM in software.
The GICv5 driver has so far done the priority drop as part of
irq_eoi(), i.e., at the same time as deactivating the interrupt. This
means that any long running process (or VM) could block incoming
interrupts, effectively causing a denial of service for all other
interrupts.
Rather than doing the EOI as part of irq_eoi() (which the name would
suggest would be a good place for it), move it to happen immediately
after acknowledging an interrupt in the main GICv5 interrupt
handler. The deactivation of interrupts (GIC CDDI) remains implemented
as part of irq_eoi(), which means that the same interrupt cannot be
signalled a second time until deactivated by software.
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Link: https://lore.kernel.org/r/20260520091949.542365-18-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
When running a GICv5-based guest, the PMU must use PPI 23. This,
however, must be communicated via the
KVM_ARM_VCPU_PMU_V3_CTRL->KVM_ARM_VCPU_PMU_V3_IRQ ioctl as a full
GICv5-style Interrupt ID. That is, 0x20000017. Optionally, the whole
ioctl can be skipped for GICv5.
This was previously not clearly documented, so bump the documentation
accordingly.
Fixes: 7c31c06e2d ("KVM: arm64: gic-v5: Mandate architected PPI for PMU emulation on GICv5")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Link: https://lore.kernel.org/r/20260520091949.542365-17-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
For GICv5 guests we make use of the DVI mechanism for PPIs where
possible. When mapping a virtual irq to a physical one for a GICv5
guest, the corresponding bit in the DVI bitmap is set. When unmapping,
said bit is cleared again. The key user of this mechanism is the arch
timer.
The existing code used the non-atomic __assign_bit() rather than doing
the update atomically. This could technically result in losing state
if a second PPI's DVI bit were being manipulated concurrently. Each
individual bit within the DVI bitmap is guarded using
vgic_irq->irq_lock, but there's no locking for the overall
bitmap. Therefore, switch to using the atomic assign_bit() function
instead.
Fixes: 5a98d0e17e ("KVM: arm64: gic-v5: Implement direct injection of PPIs")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Link: https://lore.kernel.org/r/20260520091949.542365-12-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
As things stand, there is no support for Nested Virt with GICv5 guests
yet. However, this is coming and therefore we need to be able to
correctly triage the traps when running with NV.
Add the missing fgtreg lookups required for that to
triage_sysreg_trap(). These are specific to the FGT regs added as part
of GICv5:
* ICH_HFGRTR_EL2
* ICH_HFGWTR_EL2
* ICH_HFGITR_EL2
Fixes: 9d6d9514c0 ("KVM: arm64: gic-v5: Support GICv5 FGTs & FGUs")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Link: https://lore.kernel.org/r/20260520091949.542365-11-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Fix multiple documentation build warnings.
Improve punctuation and formatting of the rendered output.
Documentation/arch/arm/zte/zx297520v3.rst:66: WARNING: Title underline too short.
3. Building for built-in U-Boot
--------------------------- [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:90: WARNING: Enumerated list ends without a blank line; unexpected unindent. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:116: WARNING: Inline literal start-string without end-string. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:137: ERROR: Unexpected indentation. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:138: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:164: WARNING: Inline literal start-string without end-string. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:164: WARNING: Inline interpreted text or phrase reference start-string without end-string. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:7: WARNING: Document or section may not begin with a transition. [docutils]
Fixes: 220ae5d36d ("ARM: zte: Add zx297520v3 platform support")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Stefan Dösinger <stefandoesinger@gmail.com>
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
pci_suspend_retains_context() lets PCI client drivers know if the platform
can retain the device context during suspend. This is decided based on
several factors like:
- Firmware involvement at the end of suspend
- Any platform limitation in waking from low power state (e.g., L1SS)
This API may be extended in the future to cover other platform specific
issues impacting the device low power mode during system suspend.
Use this API instead of checks like pm_suspend_via_firmware(). When
pci_suspend_retains_context() returns false, assume the platform cannot
retain the context and shutdown the controller. If it returns true, assume
that the context will be retained and keep the device in low power mode.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20260519-l1ss-fix-v2-4-b2c3a4bdeb15@oss.qualcomm.com
Qcom PCIe RCs can successfully exit from L1SS during OS runtime. However,
during system suspend, the Qcom PCIe RC driver may remove all resource
votes and turn off the PHY to maximize power savings.
Consequently, when the host is in system suspend with the link in L1SS and
the endpoint asserts CLKREQ#, the RC driver must restore the PHY and enable
the REFCLK. This recovery process causes the L1SS exit latency time to be
exceeded (roughly L10_REFCLK_ON + T_COMMONMODE). If the RC driver were to
retain all votes during suspend, L1SS exit would succeed without issue but
at the expense of higher power consumption.
When the host fails to move the link from L1SS to L0 within the
L10_REFCLK_ON + T_COMMONMODE time, the endpoint may treat it as a fatal
condition and trigger Link Down (LDn) during resume. This LDn results in a
reset that destroys the internal device state.
To ensure that the client drivers can properly handle this scenario, let
them know about this platform limitation by setting the
'pci_host_bridge::broken_l1ss_resume' flag.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260519-l1ss-fix-v2-3-b2c3a4bdeb15@oss.qualcomm.com
