The temporary Tx descriptor array in an XSK buffer pool is currently
sized from the Tx ring of the socket that creates the pool.
This is insufficient for shared-UMEM Tx. A later socket may have a
larger Tx ring and submit a valid multi-buffer packet containing more
descriptors than the first socket's ring, while still remaining within
the device's xdp_zc_max_segs limit.
A packet-framed batch parser bounded by the temporary array cannot reach
the end-of-packet descriptor in that case. It leaves the packet on the
Tx ring and encounters the same packet on every subsequent attempt,
stalling Tx processing for that socket.
Size the temporary descriptor array to the larger of the first Tx ring
and the device's xdp_zc_max_segs capability. This keeps the array large
enough to inspect one maximum-sized valid packet. Larger shared Tx rings
do not require further resizing, as they can be processed over multiple
batches.
Following commit will actually address the data path side.
Fixes: d558196604 ("xsk: support ZC Tx multi-buffer in batch API")
Reviewed-by: Jason Xing <kernelxing@tencent.com>
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260719135609.147823-4-maciej.fijalkowski@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix generic xmit path multi-buffer logic when packets are either too big
(count of descriptors exceed MAX_SKB_FRAGS) or an invalid descriptor is
included in fragmented packet. Introduce xdp_sock::drain_cont and act
upon this flag - when it is set, keep on consuming descriptors from
AF_XDP Tx ring and put them directly onto Cq. Previously these
descriptors were silently lost and could never be reached again.
Fixes: cf24f5a5fe ("xsk: add support for AF_XDP multi-buffer on Tx path")
Closes: https://lore.kernel.org/all/20260425041726.85FB3C2BCB2@smtp.kernel.org/
Reviewed-by: Jason Xing <kernelxing@tencent.com>
Co-developed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> # wrapped cq addr submission onto routine
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Jason Xing <kernelxing@tencent.com>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260719135609.147823-3-maciej.fijalkowski@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch is inspired by the check[1] from sashiko. It says when
overflow happens, the address of cq to be published is invalid.
Actually the severer thing is the whole process of publishing the
address of cq in this particular case is not right: it should truely
publish the address and advance the cached_prod in cq as long as it
reads descriptors from txq.
The following is the full analysis.
xsk_drop_skb() is called in three places, which all discard a partially
built multi-buffer skb:
1) xsk_build_skb() -EOVERFLOW error path: packet exceeds MAX_SKB_FRAGS
2) __xsk_generic_xmit() post-loop cleanup: an invalid descriptor in
the TX ring prevents the partial packet from completing
3) xsk_release(): socket close while xs->skb holds an incomplete packet
In all three cases, the TX descriptors for the already-processed frags
have been consumed from the TX ring (xskq_cons_release), and CQ slots
have been reserved. However, xsk_drop_skb() calls xsk_consume_skb()
which cancels the CQ reservations via xsk_cq_cancel_locked(). Since
the buffer addresses never appear in the completion queue, userspace
permanently loses track of these buffers.
Fix this by letting consume_skb() trigger the existing xsk_destruct_skb
destructor, which already submits buffer addresses to the CQ via
xsk_cq_submit_addr_locked().
Note that cancelling the descriptors back to the TX ring (via
xskq_cons_cancel_n) is not a appropriate option because an oversized
packet that always exceeds MAX_SKB_FRAGS would be retried indefinitely,
which is an obviously deadlock bug in the TX path.
Also move the desc->addr assignment in xsk_build_skb() above the
overflow check so that the current descriptor's address is recorded
before a potential -EOVERFLOW jump to free_err, consistent with the
zerocopy path in xsk_build_skb_zerocopy().
[1]: https://lore.kernel.org/all/20260425041726.85FB3C2BCB2@smtp.kernel.org/
Fixes: cf24f5a5fe ("xsk: add support for AF_XDP multi-buffer on Tx path")
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Jason Xing <kernelxing@tencent.com>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260719135609.147823-2-maciej.fijalkowski@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The RK3308B is a revision of the RK3308 including different iomux
register layout.
Several pins (GPIO2_A2, GPIO2_A3, GPIO2_C0, GPIO3_B2, GPIO3_B3)
have 3-bit mux fields in new GRF registers (SOC_CON13 at 0x608 and
SOC_CON15 at 0x610) that override the standard 2-bit fields.
I believe the bootloader sets the sel_src_ctrl bits to activate these
new registers, which causes the kernel's writes to the old 2-bit iomux
registers to be silently ignored.
Without this patch, SPI1, I2C3, and other peripherals that depend on
these pins are completely non-functional on my RK3308B boards.
Detect the SoC variant at runtime by reading the chip_id register at GRF
offset 0x800 (0xcea = RK3308, 0x3308/0x3308c = RK3308B), as requested
by reviewers of the earlier series.
When RK3308B is detected, swap in the correct mux_recalced and mux_route
tables and write the sel_src_ctrl bits to ensure the 3-bit mux registers
are active.
This is a rework of Dmitry Yashin's series [1] which used a separate
device tree compatible string ("rockchip,rk3308b-pinctrl") to
distinguish the variants.
Reviewers Luca Ceresoli and Heiko Stuebner agreed that runtime detection
was preferable since boards are manufactured with both RK3308 and RK3308B
using the same device tree.
Jonas Karlman implemented runtime detection based on the GRF_CHIP_ID
register [2]. Reviewers asked for more changes (constifying some
arrays), but the series was never resubmitted and was dropped.
I run this patch on my Rock Pi S boards, the newer ones I've got in
2024 use the RK3308B. And thanks to runtime detection we should still
be compatible with older devices (but I couldn't test on RK3308 as I
don't have any).
[1] https://lore.kernel.org/all/20240515121634.23945-1-dmt.yashin@gmail.com/
[2] https://lore.kernel.org/all/20240604141020.21725-1-dmt.yashin@gmail.com/
Signed-off-by: Hugo VALTIER <hugo@ahdrone.com>
Tested-by: Dmitry Yashin <dmt.yashin@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Extract the per-bank recalced_mask and route_mask computation out of
rockchip_pinctrl_get_soc_data() into a separate function and call it
from rockchip_pinctrl_probe().
This allows SoC-specific init code to swap the mux tables before
the masks are computed.
No functional change intended.
Signed-off-by: Hugo VALTIER <hugo@ahdrone.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
The mux_recalced_data and mux_route_data arrays are never modified after
initialization. Mark them const so they can be placed in read-only
memory. Also constify the corresponding struct fields in
rockchip_pin_ctrl and local pointer variables.
This is inspired by review comments on Dmitry Yashin's earlier
RK3308B series [1].
[1] https://lore.kernel.org/all/20240515121634.23945-1-dmt.yashin@gmail.com/
Signed-off-by: Hugo VALTIER <hugo@ahdrone.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
scx_bpf_cidperf_set() reaches cpufreq with no cap check, so any cid-form
sub-sched can steer the frequency of any cid in its view, including ones it
holds nothing on.
Gate it behind a new SCX_CAP_PERF rather than SCX_CAP_BASE: hardware control
is a separate axis from queue access - a parent may well delegate scheduling
on a cid without handing over its frequency. PERF neither implies nor is
implied by the other caps. The check runs under the target rq's lock, which
ecaps updates are also folded under, so it is authoritative - a write can
never land after a revoke has taken effect. Denials are counted in
SCX_EV_SUB_CIDPERF_DENIED.
The operation is synchronous and the outcome is reported to the caller:
scx_bpf_cidperf_set() now returns 0 or -errno, -EACCES on denial. The
cid-form interface is still under initial development, so the signature is
changed in place without versioning.
scx_qmap grants PERF alongside its existing cid grants so the cpuperf demo
keeps working in sub-scheds.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
Factor the cpuperf target write out of scx_bpf_cpuperf_set() into
scx_cpuperf_set() which takes the acting sched and returns 0 or -errno, and
flatten the nested validation into early returns. No functional change.
Prep for gating the write behind a cap and reporting the outcome from the
cid-form kfunc.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
kick_one_cpu() silently skips a kick when the kicking sub-sched lacks
SCX_CAP_BASE on the target cid, as does kick_one_cpu_if_idle() for idle
kicks. The skips are sound with the same logic as the reenq gate but are
invisible today, unlike the preempt degradation counted in
SCX_EV_SUB_PREEMPT_DENIED. Count them in a new SCX_EV_SUB_KICK_DENIED event
so every cap denial is observable.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
scx_bpf_dsq_reenq() with an SCX_DSQ_LOCAL_ON target schedules deferred reenq
work on the cid's cpu, raising an IPI when the target rq isn't the locked
one. Nothing checks caps along the way, so a sub-sched holding no cap at all
on a cid can force its cpu to take IPIs and rq lock cycles at will. The
analogous scx_bpf_kick_cid() path gates delivery on SCX_CAP_BASE in
kick_one_cpu() to prevent exactly this.
Apply the same rule at the reenq scheduling point: if the calling sched
lacks SCX_CAP_BASE on the target cid, drop the reenq and count it in the new
SCX_EV_SUB_REENQ_DENIED event. The check is lockless, which is fine: a reenq
slipping through right after a revoke is harmless, and a wrong denial can't
happen - if the caller has seen its ownership of the cpu, the check sees it
too.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
The tools restart when the kernel exits the scheduler with
SCX_ECODE_ACT_RESTART. The restart decision doesn't consult exit_req, so an
exit request arriving while the restart condition persists is ignored and
the tool reloads in a tight loop. Test exit_req before restarting.
scx_userland needs more: its main loop never watches the kernel-side exit
and exit_req doubles as the stats printer's stop signal, set by the teardown
and reset on each restart. Add the missing UEI_EXITED() test and give the
printer its own stop flag so that exit_req only means an exit request and
stays latched like in the other tools.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
Add a regression test for the unix_listen() state check. The key case is
listen() on a bound socket that has already been connected: it is no
longer in TCP_CLOSE or TCP_LISTEN, so it must fail with EINVAL. A
prepare_peercred() call slipped in ahead of that check once left err at 0
and made listen() silently succeed there instead; this guards against a
repeat.
The neighbouring outcomes are covered too so they cannot regress the same
way: a bound socket in TCP_CLOSE listens fine, calling listen() again on a
socket already in TCP_LISTEN is allowed, and an unbound socket fails with
EINVAL.
Each case runs for both listenable socket types (SOCK_STREAM and
SOCK_SEQPACKET) and both pathname and abstract addresses.
Fixes: fd0a109a0f ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid")
Signed-off-by: John Ericson <mail@johnericson.me>
Link: https://patch.msgid.link/20260718182903.2295560-2-John.Ericson@Obsidian.Systems
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit fd0a109a0f ("net, pidfs: prepare for handing out pidfds for
reaped sk->sk_peer_pid") inserted a prepare_peercred() call between err
= -EINVAL and the socket-state check in unix_listen(). Since
prepare_peercred() leaves err at 0 on success, listen() on an AF_UNIX
socket that is not in TCP_CLOSE or TCP_LISTEN state (e.g. one that is
already connected) now silently returns success without doing anything,
instead of failing with EINVAL as it did before.
Fixes: fd0a109a0f ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid")
Signed-off-by: John Ericson <mail@johnericson.me>
Link: https://patch.msgid.link/20260718182903.2295560-1-John.Ericson@Obsidian.Systems
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which
drops and reacquires the socket lock. Its error path tries to decide
whether msg_tx names the local temporary message by comparing it with
the current value of psock->cork.
This comparison is unsafe when two threads send on the same socket:
Thread A Thread B
msg_tx = psock->cork
sk_msg_alloc() fails
sk_stream_wait_memory()
releases the socket lock acquires the socket lock
completes the cork
psock->cork = NULL
frees the cork
reacquires the socket lock
msg_tx != psock->cork
sk_msg_free(msg_tx)
The stale cork is therefore mistaken for the local temporary message
and freed again. KASAN reported:
BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50
Read of size 4 at addr ffff88810c908800 by task poc/90
Call Trace:
sk_msg_free+0x49/0x50
tcp_bpf_sendmsg+0x14f5/0x1cc0
__sys_sendto+0x32c/0x3a0
__x64_sys_sendto+0xdb/0x1b0
Allocated by task 89:
__kasan_kmalloc+0x8f/0xa0
tcp_bpf_sendmsg+0x16b3/0x1cc0
Freed by task 91:
__kasan_slab_free+0x43/0x70
kfree+0x131/0x3c0
tcp_bpf_sendmsg+0xec3/0x1cc0
msg_tx can only name the stack-local tmp or the shared cork. Check for
tmp directly so a changed psock->cork cannot turn a shared message into
an apparent local one.
Fixes: 604326b41a ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/87fr18lmzo.fsf%40cloudflare.com/
Link: https://lore.kernel.org/netdev/20260719161630.2901208-1-nicoyip.dev%40gmail.com/ [v1]
Link: https://patch.msgid.link/20260724103856.3399001-1-nicoyip.dev@gmail.com
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
nh_rt_cache_flush() walks nh->f6i_list during an RTNL-serialized nexthop
replace without holding nh->lock, racing the unlocked IPv6 route
add/delete that mutate the list under nh->lock and free fib6_info
entries (nh_rt_cache_flush() is inlined into rtm_new_nexthop()):
BUG: KASAN: slab-use-after-free in nh_rt_cache_flush (net/ipv4/nexthop.c:2243)
Read of size 8 at addr ffff888012953e18 by task exploit/146
nh_rt_cache_flush (net/ipv4/nexthop.c:2243)
replace_nexthop (net/ipv4/nexthop.c:2610)
rtm_new_nexthop (net/ipv4/nexthop.c:3323)
rtnetlink_rcv_msg (net/core/rtnetlink.c:7076)
Unlike the other f6i_list walks, this one bumps each route's sernum via
fib6_update_sernum_upto_root(), which needs tb6_lock; taking nh->lock
around it would invert the established tb6_lock -> nh->lock order and
deadlock. As the only purpose is to invalidate cached dsts, bump the
IPv6 sernum for the whole netns with rt_genid_bump_ipv6() instead,
mirroring the rt_cache_flush() already done for IPv4 just above.
Fixes: 081efd1832 ("ipv6: Protect nh->f6i_list with spinlock and flag.")
Reported-by: AutonomousCodeSecurity@microsoft.com
Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260722002951.2614721-2-xmei5@asu.edu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
fib6_check_nh_list() and __nexthop_replace_notify() walk nh->f6i_list
during an RTNL-serialized nexthop replace without holding nh->lock. IPv6
RTM_NEWROUTE/RTM_DELROUTE run without RTNL and mutate that list under
nh->lock (fib6_add_rt2node_nh(), fib6_purge_rt()), so both walks race a
concurrent route delete that unlinks and frees a fib6_info:
BUG: KASAN: slab-use-after-free in rt6_fill_node.isra.0 (net/ipv6/route.c:5799)
Read of size 4 at addr ffff888014607e64 by task exploit/143
rt6_fill_node.isra.0 (net/ipv6/route.c:5799)
fib6_rt_update (net/ipv6/route.c:6412)
__nexthop_replace_notify (net/ipv4/nexthop.c:2542)
rtm_new_nexthop (net/ipv4/nexthop.c:2554)
rtnetlink_rcv_msg (net/core/rtnetlink.c:7076)
BUG: KASAN: slab-use-after-free in fib6_check_nh_list (net/ipv4/nexthop.c:1605)
Read of size 8 at addr ffff888014a7d068 by task exploit/142
fib6_check_nh_list (net/ipv4/nexthop.c:1605)
rtm_new_nexthop (net/ipv4/nexthop.c:2575)
rtnetlink_rcv_msg (net/core/rtnetlink.c:7076)
Both walks only read the entries and take no tb6_lock, so protect them
with nh->lock; fib6_rt_update() uses gfp_any(), which returns GFP_ATOMIC
under the lock.
Fixes: 081efd1832 ("ipv6: Protect nh->f6i_list with spinlock and flag.")
Reported-by: AutonomousCodeSecurity@microsoft.com
Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260722002951.2614721-1-xmei5@asu.edu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
- Embed pins in the priv struct on RZ/A2.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCalihdAAKCRCKwlD9ZEnx
cOkyAQCyUWsVjxjqQydNOe/0UxRs62GLwUcvuUzrpyxzKd0/3wEAlAEH1IGx+Slh
QGrD9tThiWZKUn9bb3V4JHhajL34YAw=
=+DCW
-----END PGP SIGNATURE-----
Merge tag 'renesas-pinctrl-for-v7.3-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel
pinctrl: renesas: Updates for v7.3
- Embed pins in the priv struct on RZ/A2.
Signed-off-by: Linus Walleij <linusw@kernel.org>
Write permissions on the /dev/udmabuf device file are not required to
issue ioctls and allocate udmabufs. Applications should be opening this
file as O_RDONLY. The BPF dmabuf_iter selftest already does this. [1]
Users are pointing to these selftests as examples of how use udmabuf,
and encountering permission errors on systems where write permissions
are not available on /dev/udmabuf. Apply the principle of least
privilege to selftests which use udmabuf by removing the write access
mode from drivers/net/hw/ncdevmem.c.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/prog_tests/dmabuf_iter.c?h=v7.1#n49
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
Link: https://patch.msgid.link/20260722205442.1894665-1-tjmercier@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Due to a change in responsibilities, I can no longer serve as an SMC
maintainer and need to be removed from the MAINTAINERS list.
To reflect these organizational changes, promote Mahanta Jambigi
<mjambigi@linux.ibm.com> from reviewer to maintainer.
Acked-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Wenjia Zhang <wenjia@linux.ibm.com>
Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
Link: https://patch.msgid.link/20260724053752.3084-1-wenjia@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
These 4 options, PINCTRL_PIC32, PINCTRL_PIC32, PINCTRL_IPROC_GPIO, and
PINCTRL_NSP_GPIO all select GPIOLIB_IRQCHIP without ensuring GPIOLIB is
enabled, causing unmet dependencies, such as:
WARNING: unmet direct dependencies detected for GPIOLIB_IRQCHIP
Depends on [n]: GPIOLIB [=n]
Selected by [y]:
- PINCTRL_PIC32 [=y] && PINCTRL [=y] && OF [=y] && (MACH_PIC32 || COMPILE_TEST [=y])
Similar options in this subsystem select GPIOLIB, so let's do the same here.
These unmet dependency bugs were found by kconfirm, a static analysis tool for
Kconfig.
Fixes: 2ba384e6c3 ("pinctrl: pinctrl-pic32: Add PIC32 pin control driver")
Fixes: 1490d9f841 ("pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver")
Fixes: b64333ce76 ("pinctrl: cygnus: add gpio/pinconf driver")
Fixes: 8bfcbbbcab ("pinctrl: nsp: add gpio-a driver support for Broadcom NSP SoC")
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Use mux_state_try_select() instead of mux_state_select() so that the
consumer driver does not block during probe when the mux state has
already been selected.
mux_state_try_select() returns -EBUSY if the requested state is already
selected, allowing the driver to handle the condition without waiting.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Each DBNCS register programs debounce source selection for 16 GPIOs.
The current offset calculation advances the register address every four
GPIOs, so offsets 4-15 and 20-31 end up touching the wrong selector
register.
Advance the DBNCS offset per 16 GPIOs so each line uses the debounce
selector bank that matches the hardware layout.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Pins 136-140 and 142 are currently advertised as having both drive-
strength and slew-rate controls, while pins 141 and 143 expose no slew
control at all.
According to the hardware description, those pins only support slew-rate
configuration. Update the pin flags accordingly so pinconf exposes the
capabilities that the hardware actually implements.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
npcmgpio_irq_startup() calls pinctrl_gpio_direction_input(), which may
sleep while taking the pinctrl core mutex. That makes IRQ startup trip
lockdep when CONFIG_PROVE_LOCKING is enabled.
Move the direction change into irq_request_resources() and keep startup
limited to the ack and unmask operations that are safe in atomic
context.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
The pin description for GPIO7 spells the IOX2 output signal as D0.
The datasheet names that signal IOX2_DO, matching the rest of the IOX
naming scheme.
Rename the pin description accordingly.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
A bank may retain pending event status across resets of the GPIO block.
If probe leaves the old state in place, the chained IRQ handler can see
spurious events as soon as the irqchip is registered.
Disable event generation and clear EVST before wiring each GPIO bank
into gpiolib so the driver starts from a known state.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
RG2 pins 110-113 and 208-209 do not use the per-bank ODSC bit that the
driver relies on for the rest of the drive-strength handling. Their
strength is encoded in GCR_DSCNT[7:6] and supports four values: 8, 12,
16 and 24mA.
Mark those pins as a dedicated drive-strength class and translate the
pinconf get/set operations to the shared GCR_DSCNT field so the full
hardware range becomes available.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
NPCM8xx uses GCR_INTCR4 bits to release the R1, R2 and RMII3
transmit outputs from Hi-Z.
Those bits need to follow the mandatory r1, r2 and rmii3 pin
groups. The R1_OEn, R2_OEn and R3_OEn side groups are optional and
should not be required just to enable RMII transmit outputs.
Program the INTCR4 bits when the corresponding RMII groups are
selected and clear them again when those pins switch back to GPIO or
another shared function.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
The bmcuart1 group currently claims BU1_RTS and BU1_CTS in addition
to TXD and RXD. That prevents boards from using the modem-control
pins independently through the dedicated nbu1crts function.
Limit bmcuart1 to the TXD/RXD pair and let users opt into BU1_RTS
and BU1_CTS explicitly through the nbu1crts group when those signals
are needed.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
An early return triggered by read_prog_test_msg leaves uninitialized elements,
which leads to memory corruption during free_test_states cleanup.
Signed-off-by: Feng Yang <yangfeng@kylinos.cn>
Link: https://lore.kernel.org/bpf/20260723085100.482147-5-yangfeng59949@163.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
pthread_create returns 0 on success and a positive error code on failure;
it never returns a negative value. The current conditional branch can never be taken.
Failures during thread creation are silently ignored, which will lead to
invalid memory access when waiting on threads or dereferencing thread handles later.
Fixes: 91b2c0afd0 ("selftests/bpf: Add parallelism to test_progs")
Signed-off-by: Feng Yang <yangfeng@kylinos.cn>
Link: https://lore.kernel.org/bpf/20260723085100.482147-3-yangfeng59949@163.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
The name has already been freed in the free_subtest_state function
and does not need to be freed again. The extra free is noop since the
pointer was already set to NULL.
Signed-off-by: Feng Yang <yangfeng@kylinos.cn>
Link: https://lore.kernel.org/bpf/20260723085100.482147-2-yangfeng59949@163.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
MAINTAINERS:
- update address
ttm:
- backup pages using correct order
gpusvm:
- fix mm leak on eviction
- properly zero page array in mm scanning
tests:
- fix dma mask errors in tests
panel:
- fix dependency issues
- ilitek-ili9881c - fix probing
i915:
- Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for DPCD backlight
xe:
- Skip invalidation for purgeable state updates
- Add drm_dev guards when detaching CCS read / write buffers
- Alloc per domain unique i2c id
- Fix SVM leak on resv obj alloc failure in xe_vm_create
amdgpu:
- Fix a backport mistake for dm_gpureset_toggle_interrupts()
- Fix a failure on flip-done timeouts for mode1 reset
appletbdrm:
- fix issue in damage handling
amdxdna:
- fix command timeout race
imagination:
- fix gpu vm locking
vc4:
- prevent trusted bo from being mapped again
- prevent timer rearm on shutdown
v3d:
- fix NULL deref in unbind
- idle AXI before clock disable on suspend
- use proper GMP access for newer hw
vmwgfx:
- validate shader array size
ethosu:
- fix length calculations
- handle internal chaining buffers
gma500:
- return errors from HDMI i2c reads
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmpj0ckACgkQDHTzWXnE
hr7ExBAAo7QeJH9InKxqEv4Yt+JDcmGM4HhGhMoBkRp3YwgS0JDnUsTZeb2jGSbb
XgbgfrYa1E8tUYSUUoMRQoHBQffuAXCovsaKxL0WOBaT5S/pIfKYsHyQLEMIFaLs
/cTH0VZ49VVOrlNyiQp4tUwJTAalRhB4RS+hfDLQMsG2wHdK4jObmamdpNh71vsZ
K7vPUvhRqyim2r9nVa6pv/LXpjRbtf+tq8cQF0ywW4eybB1zfdk+t8QQlAqkhoph
FW6Wz8o6d/wFezOyFaItOfJyJS+RPeUIEwWnmqtUM1Qp26DpLmPlH9HPJMl7yjZm
vrxuCH9B5RBE75PvJX3p9lVgh7ZENtVYboh+YhMSFjqKtirJf4Nm+XoUHwq2bycp
q5Re9IRlfPacrKe33eetOREmw7nnAtg8mw4VTuZLuYM1MlwZqSRfxVvcBCy1QMOP
FNcHg63uGogrRj4vdbmDyqmf0hsK1ZeBMH6OKdCe3ABjytFIZ0TxTseytvx7tug1
ymt0t8W/lFrdZipN8oF36k2VQGLs5k3qAvV90b7RaEL7zpbZHu3H7FNsACk2vOcv
E5XpvsnVxlgbFUQMDrtV7YxyCrn4+ln9CrAI7St9fIAHNNS7BsmQWe06Co9Kjy+c
9/aOw4tsZ0GUaPodKQxvvQrTmExzqXMu5iYnm4JTXO2zuSAjFpk=
=iIeO
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2026-07-25' of https://gitlab.freedesktop.org/drm/kernel
Pull drm fixes from Dave Airlie:
"Weekly drm pull request, small and scattered seems to be the new
normal, the ttm change is probably the largest, with xe being the
most. Alex was out this week so amdgpu is smaller and only has some
urgent fixes.
MAINTAINERS:
- update mailmap address
ttm:
- backup pages using correct order
gpusvm:
- fix mm leak on eviction
- properly zero page array in mm scanning
tests:
- fix dma mask errors in tests
panel:
- fix dependency issues
- ilitek-ili9881c - fix probing
i915:
- Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for DPCD backlight
xe:
- Skip invalidation for purgeable state updates
- Add drm_dev guards when detaching CCS read / write buffers
- Alloc per domain unique i2c id
- Fix SVM leak on resv obj alloc failure in xe_vm_create
amdgpu:
- Fix a backport mistake for dm_gpureset_toggle_interrupts()
- Fix a failure on flip-done timeouts for mode1 reset
appletbdrm:
- fix issue in damage handling
amdxdna:
- fix command timeout race
imagination:
- fix gpu vm locking
vc4:
- prevent trusted bo from being mapped again
- prevent timer rearm on shutdown
v3d:
- fix NULL deref in unbind
- idle AXI before clock disable on suspend
- use proper GMP access for newer hw
vmwgfx:
- validate shader array size
ethosu:
- fix length calculations
- handle internal chaining buffers
gma500:
- return errors from HDMI i2c reads"
* tag 'drm-fixes-2026-07-25' of https://gitlab.freedesktop.org/drm/kernel: (31 commits)
drm/amd/display: Fix missing DCE check in dm_gpureset_toggle_interrupts()
drm/amd/display: Fix flip-done timeouts on mode1 reset
Revert "drm/pagemap: Guard HPAGE_PMD_ORDER use with CONFIG_ARCH_ENABLE_THP_MIGRATION"
drm/vc4: Shut down BO cache timer before teardown
drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem
drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()
drm/xe/i2c: Allow per domain unique id
drm/gma500: return errors from Oaktrail HDMI I2C reads
drm/vc4: hvs/v3d: Fix null dereference in unbind
drm/panel: fix unmet dependency bug for DRM_PANEL_HIMAX_HX83121A
drm/panel: s6e3ha8: fix unmet dependency on DRM_DISPLAY_HELPER
drm/panel: ilitek-ili9882t: fix unmet dependency for DRM_PANEL_ILITEK_ILI9882T
drm/panel: ilitek-ili9881c: do not fail probe if iovcc is absent
drm/v3d: Idle AXI transactions before disabling the clock on suspend
drm/v3d: Reach the GMP through the hub registers on V3D 7.x
mailmap: Update Maíra Canal's email address
drm/pagemap: Guard HPAGE_PMD_ORDER use with CONFIG_ARCH_ENABLE_THP_MIGRATION
drm/pagemap: Clear driver-provided PFNs from migration PFN array
drm/xe/vf: Add drm_dev guards when detaching CCS read/write buffers
accel: ethosu: Handle U85 internal chaining buffer
...
WA 14027054324 is implemented in the firmware and is applied before
EU stall sampling and reverted after EU stall sampling. The driver
needs to notify the firmware whenever EU stall sampling is being
enabled/disabled so that the firmware takes the necessary action.
The driver uses a scratch pad register to communicate with the firmware.
Before enabling EU stall sampling, write 0x20 to the SWF scratch pad
register to request the firmware to apply the workaround. The firmware
applies the workaround and sets the scratch pad register to 0x60
as an ACK.
Before disabling EU stall sampling, write 0x40 to the SWF scratch pad
register to request the firmware to revert the workaround. The firmware
reverts the workaround and sets the scratch pad register to 0 as an ACK.
The firmware is expected to take about 1 ms to apply/revert the
workaround. 10 ms timeout is used in the driver while waiting for an
ack from the firmware to have adequate grace period.
Bspec update for the SWF scratch pad register is still pending, but has
been confirmed offline with the firmware team.
Bspec: 53188
Signed-off-by: Harish Chegondi <harish.chegondi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/16b6b972691943daddebad6e7b93b9d73add5249.1784745545.git.harish.chegondi@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Maxim Khmelevskii says:
====================
s390/bpf: Support load-acquire and store-release instructions
Support load-acquire (BPF_LOAD_ACQ) and store-release (BPF_STORE_REL)
instructions. Since s390 has strong memory model, implement
them as regular BPF_LDX/BPF_STX instructions.
====================
Link: https://patch.msgid.link/20260723140648.583055-5-max@linux.ibm.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Add new functions for load and store to reuse
them in the load-acquire and store-release logic.
Signed-off-by: Maxim Khmelevskii <max@linux.ibm.com>
Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com>
Link: https://lore.kernel.org/bpf/20260723140648.583055-6-max@linux.ibm.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Currently, there is no RISC-V support for get_preempt_count() and
its fallback path always returns 0.
Add it so that bpf_in_interrupt(), bpf_in_nmi(), bpf_in_hardirq(),
bpf_in_serving_softirq(), and bpf_in_task() work for RISC-V as well.
Given that RISC-V has supported CONFIG_THREAD_INFO_IN_TASK since its
initial commit fbe934d69e ("RISC-V: Build Infrastructure") in 2017,
directly retrieve preempt_count from the thread_info embedded within
task_struct via bpf_get_current_task_btf().
This aligns the implementation with arm64, powerpc, and loongarch.
Tested on a RISC-V virtual machine.
Before:
$ sudo ./test_progs -t exe_ctx
...
#114 exe_ctx:FAIL
Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED
After:
$ sudo ./test_progs -t exe_ctx
#114 exe_ctx:OK
Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tested-by: Pu Lehui <pulehui@huawei.com>
Reviewed-by: Pu Lehui <pulehui@huawei.com>
Link: https://lore.kernel.org/bpf/20260722022906.8778-1-yangtiezhu@loongson.cn
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Rename node name display@0 to display0 since no reg under it. Rename mode0
to timing0.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/ls/ls1021a-iot.dtb: dcu@2ce0000 (fsl,ls1021a-dcu): 'display', 'display@0' do not match any of the regexes: '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/display/fsl,ls1021a-dcu.yaml
arch/arm/boot/dts/nxp/ls/ls1021a-iot.dtb: display-timings: 'mode0' does not match any of the regexes: '^pinctrl-[0-9]+$', '^timing'
from schema $id: http://devicetree.org/schemas/display/panel/display-timings.yaml
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Add deprecated property display and display0 to allow old platform lx1021a
(>10 years) to put display timing under dcu node.
Following patch rename display@0 to display0 and mode0 to timing0. Fix
below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/ls/ls1021a-iot.dtb: dcu@2ce0000 (fsl,ls1021a-dcu): 'display', 'display@0' do not match any of the regexes: '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/display/fsl,ls1021a-dcu.yaml
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Both platforms are maintained by the same people, and the two entries
contain largely identical information. Maintaining separate entries adds
unnecessary duplication.
Additionally, the standalone Layerscape entry does not include the
imx@lists.linux.dev mailing list, causing Layerscape patches to miss
NXP's Patchwork instance. Consolidating the entries ensures patches for
both platforms are routed consistently and reduces future maintenance
overhead.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Leon Hwang says:
====================
bpf: Fix WARNING in bpf_tracing_link_release
The trampoline could be corrupted by the blindly
'tr->flags = BPF_TRAMP_F_TAIL_CALL_CTX' in verifier.
1. A fexit attached to a tail_call_reachable prog. 'tr->flags' became
'BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_TAIL_CALL_CTX'. And, the
trampoline would poke the target prog's nop insn using jmp insn instead
of call insn.
2. Another fexit loaded with the same tail_call_reachable prog target.
'tr->flags' became 'BPF_TRAMP_F_TAIL_CALL_CTX'.
3. Close the first fexit link. Due to no BPF_TRAMP_F_CALL_ORIG in
'tr->flags', the trampoline will fail to restore the prog's nop insn
using call insn.
[ 3.410719] WARNING: kernel/bpf/syscall.c:3551 at bpf_tracing_link_release+0x53/0x60, CPU#1: test_progs/98
...
[ 3.428793] bpf_link_free+0x58/0x130
[ 3.429293] bpf_link_release+0x23/0x30
Fix the warning by updating 'tr->flags' with '|=' and lock.
Changes:
v1 -> v2:
* Update the patch #1 message with 'tr->flags' change. (per Jiri)
* Drop the 'link' and the last 'if' in patch #2. (per Jiri)
* v1: https://lore.kernel.org/bpf/20260721133036.49265-1-leon.hwang@linux.dev/
====================
Link: https://patch.msgid.link/20260722151909.69142-1-leon.hwang@linux.dev
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Add a test to verify that there's no WARNING when detaching fexit link by
following the repro steps of previous commit.
Without the fix, the WARNING could be triggered by this test.
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
Reviewed-by: Pu Lehui <pulehui@huawei.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/bpf/20260722151909.69142-3-leon.hwang@linux.dev
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
The trampoline could be corrupted by the blindly
'tr->flags = BPF_TRAMP_F_TAIL_CALL_CTX' in verifier.
1. A fexit attached to a tail_call_reachable prog. 'tr->flags' became
'BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_TAIL_CALL_CTX'. And, the
trampoline would poke the target prog's nop insn using jmp insn instead
of call insn.
2. Another fexit loaded with the same tail_call_reachable prog target.
'tr->flags' became 'BPF_TRAMP_F_TAIL_CALL_CTX'.
3. Close the first fexit link. Due to no BPF_TRAMP_F_CALL_ORIG in
'tr->flags', the trampoline will fail to restore the prog's nop insn
using call insn.
[ 3.410719] WARNING: kernel/bpf/syscall.c:3551 at bpf_tracing_link_release+0x53/0x60, CPU#1: test_progs/98
...
[ 3.428793] bpf_link_free+0x58/0x130
[ 3.429293] bpf_link_release+0x23/0x30
Fix the warning by updating 'tr->flags' with '|=' and lock.
Fixes: 2b5dcb31a1 ("bpf, x64: Fix tailcall infinite loop")
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
Reviewed-by: Pu Lehui <pulehui@huawei.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/bpf/20260722151909.69142-2-leon.hwang@linux.dev
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
For a good while the common for all NXP LPC32xx platforms lpc32xx.dtsi
file contains proper descriptions of DMA, SLC and MLC NAND controllers,
this allows to remove populated device tree nodes from platform code.
At the end of the last year it was announced that this change to happen,
unlikely there are still users with such old dtbs to be affected by this
change, but if there are such users, they should update board dtb file,
if DMA or NAND controller decriptions are not found in them.
Signed-off-by: Vladimir Zapolskiy <vz@kernel.org>
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
lpc32xx_check_uid() and lpc32xx_pm_init() are arch_initcalls that poke
LPC32xx-only registers. Since the multiplatform conversion they also
run on other ARCH_MULTI_V5 boards where access faults e.g. on versatile:
Unable to handle kernel paging request at virtual address f4004130
PC is at lpc32xx_check_uid+0x2c/0x9c
Drop the arch_initcall() registrations and call both functions directly
from lpc3250_machine_init(), the machine's .init_machine hook.
The calls are placed in link order (common.c, pm.c, phy3250.c) to
keep their previous relative ordering.
Fixes: 75bf1bd7d2 ("ARM: lpc32xx: allow multiplatform build")
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Vladimir Zapolskiy <vz@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
