Please consider pulling these changes from the signed vfs-7.3-rc1.lookup tag.
Thanks!
Christian
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCan7RJQAKCRCRxhvAZXjc
ouj6AQCnBHstCt5RRimywLYU+eTmdKe203zRQYxXpwlYOAzm7wEAm1mIC7/Of6bD
jkiJilcPDcyYcJsqwBw/Vcz5HR+v8wo=
=TX6K
-----END PGP SIGNATURE-----
Merge tag 'vfs-7.3-rc1.lookup' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull vfs lookup updates from Christian Brauner:
"This refactors lookup_open() and adds vfs_lookup_open() for nfsd.
mnt_want_write() and parent locking are moved into lookup_open()
itself.
audit_inode_child() is also now called in lookup_open() on failure.
That is the calling convention in vfs_create() and vfs_mkdir(), but
lookup_open() made no such call when atomic_open() should have created
a file and did not. And neither did the regular ->create() path fwiw.
This also contains work to remove the unneeded excl argument from the
->create() inode op"
* tag 'vfs-7.3-rc1.lookup' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
fs/namei.c: fix coding style in atomic_open() and lookup_open()
fs/namei.c: fix kerneldoc of atomic_open() and vfs_lookup_open()
fs/namei.c: update stale comments in lookup_open()
Remove excl arg to ->create inode_operation
fs/namei.c: update kerneldoc of atomic_open()
vfs: call audit_inode_child() in lookup_open() on failure
vfs: move create error && negative dentry case in lookup_open() up
VFS: add vfs_lookup_open() for nfsd
VFS: move delegated_inode retry loop into lookup_open()
VFS: move mnt_want_write() and locking into lookup_open()
nci: add data_len bound checks to activation parameter extractors
nci: fix double completion race in nci_data_exchange_complete
nci: fix out-of-bounds write in nci_target_auto_activated()
nci: fix uninit-value in the RF discover/activated NTF handlers
nci: fix use of uninitialized memory in CORE_INIT_RSP parsing
nci: free destination parameters when closing a connection
llcp: avoid userspace overflow on invalid optlen
llcp: bound SNL TLV parsing to the skb and add length checks
llcp: bound the connect_sn TLV walk to the skb
llcp: fix OOB read and u8 offset wrap in TLV parsers
llcp: read llcp_sock->local under the socket lock in getsockopt
llcp: reject PDUs shorter than the LLCP header
digital: Do not dump a NULL response in command completion
digital: clamp SENSF_RES length to the destination buffer
fdp: bound the device-reported read length and fix an skb leak
microread: validate target discovery payload lengths
pn533: hold a reference to the request skb during send_frame
pn533: purge fragmented skbs during cleanup
st21nfca: validate ATR_REQ length against the received frame
Signed-off-by: David Heidelberg <david@ixit.cz>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE13oJz+7cK71TpwR0YAI/xNNJIHIFAmp7TEMACgkQYAI/xNNJ
IHLe8A/+Nf5frmGy4C/J63sSWxFCvk1DXNp9zDkgQ5p5Tb2qcIxJzJsPeSyvQ7qG
B3NUQ6vPxJu5alkiYGkqnpFIEedIHvHE3maFQB4vqMiuxUqNFhNEk2CjlQde5K3Y
7exkGce57K/9ZkSp3wiz1OasCe0jI/Jo6wI1/t0oYXGo307OdGga39nXNtA1svha
3a82+ViWoZaole+zGLZLl8mrtJQwooMiW7UXlEvvyggQndP728jtK3gcGwMmylyE
tP8aDkJjcfe9L5TXHtom5NWEqN5PzzUu8qCGtnj9hC8OxOB3hFSyPeOvFwbiNbb7
ZkfAKNz02ifjUFw9TTwwjZDiISVpDmti8bOO88hHmaS8FzIkDrEX6/XGcdJzRQvM
r/5c7wBK6tlwaIRzVo2UtJ6E7fsRptTwmFXbCq4m1qzGrPJ4BefK8QAr0Dx6jk5h
IeXaERxuZus2t/8OdwN2vQ8+fFMtfMXytGWScpCQmIe19zBzvM+fPg5CNwqd5sor
ndNb1y8NjiifVAOdFuTS8023IPjQS2GRrMNaHiMP4t9Sht2ihScolzlCzhOYDw6Z
cLn6bmIUTuXnkyP+xBrb2pi25myPAJ94gNDjyY7bQVrkeT6p8S9cob4deh4wyQfK
GyAfIbVGQguL6KxR26Y2iX70iEJSCeB83+JtWNgWzDneSUiBwsY=
=A3SJ
-----END PGP SIGNATURE-----
Merge tag 'nfc-7.1-rc8' of https://codeberg.org/linux-nfc/linux
David Heidelberg says:
====================
Mostly security fixes.
nci: add data_len bound checks to activation parameter extractors
nci: fix double completion race in nci_data_exchange_complete
nci: fix out-of-bounds write in nci_target_auto_activated()
nci: fix uninit-value in the RF discover/activated NTF handlers
nci: fix use of uninitialized memory in CORE_INIT_RSP parsing
nci: free destination parameters when closing a connection
llcp: avoid userspace overflow on invalid optlen
llcp: bound SNL TLV parsing to the skb and add length checks
llcp: bound the connect_sn TLV walk to the skb
llcp: fix OOB read and u8 offset wrap in TLV parsers
llcp: read llcp_sock->local under the socket lock in getsockopt
llcp: reject PDUs shorter than the LLCP header
digital: Do not dump a NULL response in command completion
digital: clamp SENSF_RES length to the destination buffer
fdp: bound the device-reported read length and fix an skb leak
microread: validate target discovery payload lengths
pn533: hold a reference to the request skb during send_frame
pn533: purge fragmented skbs during cleanup
st21nfca: validate ATR_REQ length against the received frame
* tag 'nfc-7.1-rc8' of https://codeberg.org/linux-nfc/linux:
nfc: microread: validate target discovery payload lengths
nfc: nci: free destination parameters when closing a connection
nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing
nfc: pn533: purge fragmented skbs during cleanup
nfc: st21nfca: validate ATR_REQ length against the received frame
nfc: llcp: bound the connect_sn TLV walk to the skb
nfc: llcp: reject PDUs shorter than the LLCP header
nfc: digital: Do not dump a NULL response in command completion
nfc: pn533: hold a reference to the request skb during send_frame
nfc: nci: fix uninit-value in the RF discover/activated NTF handlers
nfc: fdp: bound the device-reported read length and fix an skb leak
nfc: nci: fix out-of-bounds write in nci_target_auto_activated()
nfc: nci: add data_len bound checks to activation parameter extractors
nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers
nfc: llcp: bound SNL TLV parsing to the skb and add length checks
nfc: digital: clamp SENSF_RES length to the destination buffer
nfc: nci: fix double completion race in nci_data_exchange_complete
nfc: llcp: read llcp_sock->local under the socket lock in getsockopt
nfc: llcp: avoid userspace overflow on invalid optlen
====================
Link: https://patch.msgid.link/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Please consider pulling these changes from the signed vfs-7.3-rc1.kthread tag.
Thanks!
Christian
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCan7RJQAKCRCRxhvAZXjc
ohHuAQCFeGhxqsb44KhuJaWXewiXbefr6eg31lXmxgSfg0DILAD/Tw/WmpiUbX5M
H+/jh6NmLKnQ/ADjlWFRy3R1K1Il3w4=
=jwPP
-----END PGP SIGNATURE-----
Merge tag 'vfs-7.3-rc1.kthread' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull kthread vfs updates from Christian Brauner:
"This stops kernel threads from sharing filesystem state with
userspace. This work is about 3 cycles old and has been in -next
for about that time.
When the kernel boots init_task creates PID 1 and then kthreadd. From
that point every kthread and PID 1 share the same fs_struct. That is
why pivot_root() has to rewrite the fs_struct of all kthreads. The
rewriting exists so that kthreads can use init's filesystem state when
they want to. It also means userspace can move the ground out from
under the kernel.
PID 1 now gets a completely separate fs_struct. All kthreads are
anchored in a private SB_KERNMOUNT instance of nullfs that cannot be
mounted on and cannot be used to follow other mounts. Userspace init
can no longer affect kthread filesystem state and kthreads can no
longer affect userspace fs state without explicit opting in to that.
Path lookup from a kthread now fails by default. It makes it
deliberately hard to offload security sensitive operations into init's
filesystem state from a kthread.
Places that legitimately need to look something up there opt in
through the new scoped_with_init_fs() which temporarily overrides the
caller's fs_struct with init's. usermodehelpers remain the only kernel
tasks that genuinely share init's filesystem state, since they execute
random binaries in the root filesystem (excellent...).
The visible result is that /proc/2/root is a nullfs with an empty
mountinfo while /proc/1/root is the real root"
* tag 'vfs-7.3-rc1.kthread' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (26 commits)
initramfs_test: use test init/exit hooks to override init fs
fs: stop rewriting paths for PF_EXITING | PF_DUMPCORE
fs: stop rewriting kthread fs structs
fs: start all kthreads in nullfs
nullfs: make nullfs multi-instance
devtmpfs: create private mount namespace
fs: add umh argument to struct kernel_clone_args
fs: stop sharing fs_struct between init_task and pid 1
af_unix: use scoped_with_init_fs() for coredump socket lookup
initramfs: use scoped_with_init_fs() for rootfs unpacking
pnfs/blocklayout: use scoped_with_init_fs() for SCSI device lookup
ksmbd: use scoped_with_init_fs() for VFS path operations
ksmbd: use scoped_with_init_fs() for filesystem info path lookup
ksmbd: use scoped_with_init_fs() for share path resolution
fs: use scoped_with_init_fs() for kernel_read_file_from_path_initns()
coredump: use scoped_with_init_fs() for coredump path resolution
btrfs: use scoped_with_init_fs() for update_dev_time()
scsi: target: use scoped_with_init_fs() for APTPL metadata
scsi: target: use scoped_with_init_fs() for ALUA metadata
crypto: ccp: use scoped_with_init_fs() for SEV file access
...
Previously, hinic3_send_one_skb() cached the skb fragment count before
calling hinic3_tx_offload(). If hinic3_tx_csum() falls back to
skb_checksum_help() for unsupported tunnel packets, the skb may be
linearized. Continuing to build the TX descriptor with the stale
fragment count leads to a descriptor mismatch, which can trigger
out-of-bounds DMA reads or IOMMU faults.
Furthermore, the old code ignored the return value of skb_checksum_help(),
transmitting corrupted packets with incomplete checksums upon failure.
Fix this by:
1. Moving the hinic3_tx_offload() call before calculating 'num_sge' to
ensure the correct fragment count is used if the SKB is linearized.
2. Propagating skb_checksum_help() errors and returning
HINIC3_TX_OFFLOAD_INVALID to properly drop the skb.
Fixes: 17fcb3dc12 ("hinic3: module initialization and tx/rx logic")
Co-developed-by: Teng Peisen <tengpeisen@huawei.com>
Signed-off-by: Teng Peisen <tengpeisen@huawei.com>
Co-developed-by: Wu Di <wudi234@huawei.com>
Signed-off-by: Wu Di <wudi234@huawei.com>
Signed-off-by: Fan Gong <gongfan1@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/78d8c61cab588240948eaddcb437d59add9f77ae.1786448013.git.tengpeisen@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
airoha_npu_load_firmware() maps a missing firmware file to -EPROBE_DEFER
so that the NPU can be brought up once the rootfs carrying /lib/firmware
has been mounted. That mapping holds only as long as request_firmware()
reports -ENOENT.
It does not when the sysfs fallback is in play. With
CONFIG_FW_LOADER_USER_HELPER_FALLBACK set, or with the fallback armed at
runtime through /proc/sys/kernel/firmware_config/force_sysfs_fallback,
request_firmware() hands the request to a userspace helper, waits out the
full loading_timeout and returns -ETIMEDOUT. The -ENOENT test no longer
matches, dev_err_probe() turns the result into a hard failure, and the
NPU is left unbound after stalling the boot for 60 seconds:
airoha-npu 1e900000.npu: Direct firmware load for airoha/en7581_npu_rv32.bin failed with error -2
airoha-npu 1e900000.npu: Falling back to sysfs fallback for: airoha/en7581_npu_rv32.bin
airoha-npu 1e900000.npu: error -ETIMEDOUT: failed to run npu firmware
airoha-npu 1e900000.npu: probe with driver airoha-npu failed with error -110
Clearing FW_LOADER_USER_HELPER in the configuration is not a dependable
guard against this, because unrelated drivers select it. On the affected
build the symbol was turned back on by LEDS_LP55XX_COMMON, even though
the platform had explicitly disabled it.
Use request_firmware_direct() instead. It sets FW_OPT_NOFALLBACK_SYSFS,
so a missing file is reported as -ENOENT whatever the firmware loader is
configured to do, and the deferred probe path works as intended.
Two consequences are worth stating plainly.
The helper is not merely bypassed for the boot-before-rootfs case.
fw_run_sysfs_fallback() returns early on FW_OPT_NOFALLBACK_SYSFS, so this
driver's firmware requests can no longer be served by a usermode helper
at all, including on a system where that is the only delivery route;
having no second firmware source, the driver would defer forever there.
That is a deliberate trade-off: the -ENOENT to -EPROBE_DEFER mapping was
written to wait for a filesystem, and the sysfs helper interface has had
no in-tree consumer since udev dropped firmware loading.
request_firmware_direct() also sets FW_OPT_NO_WARN, which drops the only
message naming the file that failed to load. Report it from the driver
instead, so the name lands in the deferred probe reason and shows up in
the "deferred probe pending" line emitted at
driver_deferred_probe_timeout. The generic report in airoha_npu_probe()
goes away with it, since it would otherwise overwrite that reason with a
message naming nothing; of the paths it covered, devm_ioremap_resource()
reports itself and the malformed firmware-name property now does too.
Measured on a Nokia XG-040G-MD with FW_LOADER_USER_HELPER=y and
FW_LOADER_USER_HELPER_FALLBACK=y forced on, two images from the same
tree differing only by this patch:
without: fallback at 2.477s -> -ETIMEDOUT at 64.555s -> probe failed
with -110, preinit at 69.6s, NPU unbound
with: no fallback, NPU fw version 1456.62 at 3.665s, preinit at
7.6s
Cc: stable+noautosel@kernel.org # never worked
Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In jumbo_frm() (implemented in both "chain_mode.c" and "ring_mode.c"),
there are places where a DMA descriptor is converted to little-endian
byte order in assignment. The DMA descriptor could be a 64-bit value,
which makes the 32-bit byte swapping operation seem a little sketchy.
Explicitly extract the low-order 32 bits of the dma_addr_t value being
converted into a u32 so it's crystal clear that we're doing the right
thing.
Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20260812163832.271742-3-elder@riscstar.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In jumbo_frm() (implemented in both "chain_mode.c" and "ring_mode.c"),
an unsigned integer local variable is used to hold the value returned
by dma_map_single(). On systems where a dma_addr_t is 64 bits, the
subsequent dma_mapping_error() check of the returned value operates
only on the low 32 bits (whose high bit won't be sign-extended). In
this case, dma_mapping_error() would return 0 (no error) even if there
were one.
Fix this in both spots by using a dma_addr_t for the local variable.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://lore.kernel.org/linux-devicetree/20260606010122.21A211F00899@smtp.kernel.org/
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20260812163832.271742-2-elder@riscstar.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fan Ye says:
====================
net: thunderbolt: two fixes for the failed bring-up path
Two separate defects reached through the same branch in
tbnet_connected_work(), found on an ASMedia ASM4242 host-to-host link
when the peer drops out while a connection is being brought up.
1 releases the HopID the allocator handed out when it is not the one
that was asked for. Today it stays allocated for the rest of the
XDomain connection.
2 marks the connection down on the failure paths, so the next
tbnet_tear_down() does not run a second teardown over work that was
already undone: stopping rings that are already stopped, which is
fatal under panic_on_warn, and handing back a HopID this connection
never owned.
Patch 2 edits the lines patch 1 adds, so it has to come second.
====================
Link: https://patch.msgid.link/20260811-b4-tbnet-hopid-v3-0-9e75d1b51331@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Every failure path in tbnet_connected_work() undoes its own work and
returns without clearing login_sent, so the connection still looks
established. The next tbnet_tear_down() therefore takes its main branch
and repeats a teardown that already happened: it stops rings that are
already stopped, which is a dev_WARN() and fatal under panic_on_warn,
and it releases net->remote_transmit_path even on the HopID mismatch
path, where this connection never owned that id, silently freeing one
that someone else is still using.
Clear login_sent on those paths. That is enough for tbnet_tear_down() to
leave the unwound state alone, and login_received has to stay set: it
records that the peer has logged in and carries the transmit path it gave
us, which nothing on this side can make the peer send again. Two things
change beyond keeping the teardown out of the way: the logout request in
that block is no longer sent, and the peer's next login request now
re-queues our login work rather than connected_work, giving the
connection a fresh login instead of a retry on stale state.
Fixes: e69b6c02b4 ("net: Add support for networking over Thunderbolt cable")
Cc: <stable@vger.kernel.org> # 5.13+
Signed-off-by: Fan Ye <fy15309206903@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260811-b4-tbnet-hopid-v3-2-9e75d1b51331@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
tb_xdomain_alloc_in_hopid() passes the wanted HopID to ida_alloc_range()
as the lower bound, so a taken id is not an error there: the allocator
returns the next free one above it. tbnet_connected_work() asks for the
peer's transmit path, treats any other id as a failure and returns
without releasing what it got, so that allocation stays live for the rest
of the XDomain connection with nothing left holding a reference to it.
Release the id when it is not the one we asked for, the same way the
error unwind at the end of the function releases the expected one.
Fixes: 180b068942 ("thunderbolt: Allow multiple DMA tunnels over a single XDomain connection")
Cc: stable@vger.kernel.org
Signed-off-by: Fan Ye <fy15309206903@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260811-b4-tbnet-hopid-v3-1-9e75d1b51331@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
rvu_mcs_set_lmac_bmap() declares lmac_bmap without initializing it and
only sets bits for valid lmacs with set_bit(), which ORs into the word
without clearing it first. Bits for invalid or skipped ports keep
whatever was on the stack, and the garbage is stored into
mcs->hw->lmac_bmap.
Initialize lmac_bmap to 0 so only valid lmacs are marked.
Found with Clang's -Wconditional-uninitialized.
Fixes: ca7f49ff88 ("octeontx2-af: cn10k: Introduce driver for macsec block.")
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Ratheesh Kannoth <rkannoth@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260812060730.6181-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
sparse reports:
net/psp/psp_nl.c:513:13: sparse: sparse: cast removes address space
'__rcu' of expression
cmpxchg() returns typeof(*ptr) and its internal casts strip the __rcu
annotation. Wrap it in unrcu_pointer(), the documented way to use an
__rcu pointer with xchg() and friends.
This was introduced by commit 06c2dce2d0 ("psp: add new netlink cmd
for dev-assoc and dev-disassoc").
No functional change intended.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608080910.l9KvOH7O-lkp@intel.com/
Signed-off-by: Wei Wang <weibunny@fb.com>
Link: https://patch.msgid.link/20260813193416.1544518-1-weibunny.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Please consider pulling these changes from the signed vfs-7.3-rc1.kfunc tag.
Thanks!
Christian
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCan7RJQAKCRCRxhvAZXjc
oqBnAQDzCTHIa0wColluZLaFVuL4pvipQzC7tjUUQCwPmy85EwEA2cyeguEkNYJZ
SK3m4z8kfuZjO2tEOig+XCkmtVrSMQQ=
=6gwq
-----END PGP SIGNATURE-----
Merge tag 'vfs-7.3-rc1.kfunc' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull vfs bpf access updates from Christian Brauner:
"This adds a bpf_sock_read_xattr() kfunc so a BPF LSM program can read
a user.* extended attribute from a socket's sockfs inode locklessly.
userspace already uses user.* xattrs on sockets to implement socket
rate limiting and to tag sockets for other purposes such as a varlink
registry. There has been no efficient way for a BPF program to read
those labels back. With this a listening socket marked from userspace
with fsetxattr() can be read back during bind or connect and acted
upon on the connecting socket. That lets userspace mark sockets and
later rediscover them or implement policy on them"
* tag 'vfs-7.3-rc1.kfunc' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
selftests/bpf: Add test for bpf_sock_read_xattr() kfunc
fs: Add bpf_sock_read_xattr() kfunc to read socket xattrs
No functional changes.
In code paths that use a psp_dev reference that wasn't obtained from
the psp_devs xarray, e.g. not via psp_device_get_and_lock(), there is
no guarantee that the psp_dev has not been unregistered. The check
here is correct, but it doesn't match other code paths that use
psp_dev_is_registered().
Commit b89769f936 ("net: psp: check for device unregister when
creating assoc") is an example of a fix that adds a check for this
after locking a psp_dev. if (psp_dev_is_registered(psd)) vs if
(psd->ops) makes it clear what we are really checking for.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260814-psp-dev-is-reg-v1-1-5029e1f1eb01@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ipv6_flowlabel_mgr used to be a component of a broader overall
flow label test, defined in the ipv6_flowlabel.sh file. This wrapper
script called tests defined on ipv6_flowlabel.c and
ipv6_flowlabel_mgr.c files, using predefined parameters and enforcing
the in_netns.sh helper to set network namespaces for each test env.
However, the ipv6_flowlabel_mgr.c was drastically changed recently.
These modifications led to the mgr tests becoming a self contained and
independent test suite, enforcing netns creation by itself and
not relying on the ipv6_flowlabel.sh wrapper for proper test execution
anymore. Therefore, remove the mgr tests from the wrapper and update
the Makefile to handle it as a standalone test program instead.
Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260813030708.37609-1-marcelomspessoto@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add support for reading the default unicast MCAM
rule associated with a NIX LF on non-CN20K silicon.
Signed-off-by: Satheesh Paul <psatheesh@marvell.com>
Signed-off-by: Nitin Shetty J <nshettyj@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260812053523.3329305-1-nshettyj@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
All bnxt devices support TSO packets with RFC 3168 ECN flags set. The
CWR flag is replicated only on the first segment.
Reviewed-by: Andy Gospodarek <gospo@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Link: https://patch.msgid.link/20260814215655.2331655-1-michael.chan@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski says:
====================
eth: bnxt: preserve IRQ affinity across IRQ reallocation
bnxt currently discards the IRQ affinity when changing ring count:
# ethtool -l ens9np0
[...] Combined: 8 [...]
# ynl --family netdev --dump napi-get --json '{"ifindex": 2}'
[...]
{'defer-hard-irqs': 0,
'gro-flush-timeout': 0,
'id': 70,
'ifindex': 2,
'irq': 170, << IRQ 170 is for NAPI 1 (second to last)
'irq-suspend-timeout': 0,
'threaded': 'disabled'},
{'defer-hard-irqs': 0,
'gro-flush-timeout': 0,
'id': 69,
'ifindex': 2,
'irq': 169,
'irq-suspend-timeout': 0,
'threaded': 'disabled'}]
# cat /proc/irq/170/smp_affinity_list
1 <<< system config script set CPU 1 for this IRQ
# ethtool -L ens9np0 combined 1
# ethtool -L ens9np0 combined 8
# cat /proc/irq/170/smp_affinity_list
0-31 <<< system has 32 CPUs
After this series:
# cat /proc/irq/170/smp_affinity_list
1
# ethtool -L ens9np0 combined 1
# ethtool -L ens9np0 combined 8
# cat /proc/irq/170/smp_affinity_list
1
We recently added the ability to networking core to track the affinity.
bnxt doesn't use it because it needs TPH programming as well.
Let's align its local behavior.
The loss of IRQ config is a real production problem, but it also breaks
some of the NIPA tests.
====================
Link: https://patch.msgid.link/20260813193248.2578626-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reconfiguring the rings frees the MSI-X vectors and allocates them
again. The IRQ descriptors go away with them, so the affinity user
space set is silently replaced by the driver's default NUMA spread.
This is painful to deal with for user space as seemingly arbitrary
NIC configuration changes lead to loss of configuration.
In NIPA (netdev CI) this results in the toeplitz test reporting:
Exception| net.lib.py.ksft.KsftFailEx: IRQ170 is not mapped to a single core: 0-31
if the test run after another test which reconfigured the device.
We configure the IRQ mapping at boot, but if the driver is not
preserving the config - it gets lost.
Record the affinity in the notifier and apply it when the IRQs are
requested again. The notifier has to be registered unconditionally
now, so far it was only installed when TPH was enabled. Drivers
which let the core manage the affinity (idpf, ice, iavf via
netif_set_affinity_auto()) work exactly like this,
napi_restore_config() reapplies napi_config.affinity_mask on every
napi_enable().
Note that the affinity is supposed to follow the NAPI / queue,
same as the napi_config behavior in drivers mentioned above.
If the user changes the affinity when the device is down -
we will override it on up. That's expected, the IRQs are not
associated with queues when device is down (no name, no entry
in /proc/interrupts, no entry in netdev netlink).
map_idx is ulp_msix + i, so the slot shifts whenever RoCE takes
or releases vectors and the mask would end up on a different ring.
Key using the completion ring id, which maps to the NAPI instance.
Note2: this restores the side effect fcf42409c6 ("bnxt_en: use
irq_update_affinity_hint()") removed, but not the problem it was
fixing. The complaint there was that reopening the device resets
the affinity and can move an IRQ onto a CPU irqbalance was told
to stay away from. We now replay what user space or irqbalance
last asked for, the driver's own placement is only used for
a ring nobody has configured.
Note3: the combined irq_set_affinity_and_hint() looks like
it may hide the failure from __irq_set_affinity(), but let's
assume the IRQ maintainers know what their doing - either
this can't happen or is intentional.
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Link: https://patch.msgid.link/20260813193248.2578626-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Handle the IRQ table allocation failure right away instead of
wrapping the rest of the function in an if. Purely to make
upcoming changes more readable.
While refactoring, drop the init of rc which is not necessary.
No functional changes.
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Link: https://patch.msgid.link/20260813193248.2578626-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Cover the two loads which used to lose the BPF_PROBE_MEM rewrite, both reached
from an RCU read-side critical section. The purpose of this patch is to assert
load success in order to make sure to not trigger verifier_bug_if() on
bpf_may_fault_on_deref() due to forgotten rewrite of a probed pointer.
# LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t rcu_read_lock
[...]
#332/1 rcu_read_lock/success:OK
#332/2 rcu_read_lock/rcuptr_acquire:OK
#332/3 rcu_read_lock/negative_tests_inproper_region:OK
#332/4 rcu_read_lock/negative_tests_rcuptr_misuse:OK
#332 rcu_read_lock:OK
Summary: 1/4 PASSED, 0 SKIPPED, 0/0 FAILED
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260817141015.878071-2-daniel@iogearbox.net
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
bpf_arena_spin_lock.h defines its 64KB qnodes array in the header, so
every translation unit including it emits a copy. __weak makes them all
resolve to one instance, but bpftool gen object merges only the symbols
and concatenates each input's .addr_space.1 bytes, leaving the surplus
copies unreferenced in the linked object.
libarena links ten such units, so nine copies were dead weight (bytes):
object before after
-----------------------------------------------------
.addr_space.1 in libarena.bpf.o 676200 86376
libarena.skel.h 2100123 892371
libarena_asan.skel.h 2641124 1466477
Declare qnodes in the header and let each program define it once:
libarena in src/common.bpf.c, and the arena_spin_lock test beside the
lock it guards.
Tested with test_progs -t arena_spin_lock and -t libarena.
Signed-off-by: Changwoo Min <changwoo@igalia.com>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/bpf/20260817160249.655916-1-changwoo@igalia.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
rtl8168_setup_ldev() and rtl8125_setup_led_ldev() build the LED device
name in a stack buffer and assign it to led_cdev->name.
The LED class device registration path reads led_cdev->name after it has
been assigned, and struct led_classdev stores the name as part of the LED
class device state. Do not keep a pointer to a setup function's stack
buffer there.
Store the name in struct r8169_led_classdev instead, so it remains valid
for the lifetime of the LED class device.
Signed-off-by: Zhixing Chen <running910@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260813100711.14724-1-running910@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet says:
====================
net: prevent lockless data races in net_device TC structures
This patch series resolves lockless data races between fast-path packet
processing / qdisc schedulers (e.g. taprio advance_sched(), XPS queue
lookups, skb_tx_hash()) and control-path updates modifying traffic class
configurations on a net_device.
syzbot / KCSAN reported a data-race between advance_sched() reading
dev->num_tc in netdev_get_num_tc() and control-path updates writing
dev->num_tc in netdev_set_num_tc():
==================================================================
BUG: KCSAN: data-race in advance_sched / netdev_set_num_tc
write to 0xffff88811ac5c036 of 2 bytes by task 4434 on cpu 0:
netdev_set_num_tc+0x... net/core/dev.c:3158
...
tc_modify_qdisc+0x102a/0x1550 net/sched/sch_api.c:1844
rtnetlink_rcv_msg+0x6a7/0x720 net/core/rtnetlink.c:7085
read to 0xffff88811ac5c036 of 2 bytes by interrupt on cpu 1:
netdev_get_num_tc include/linux/netdevice.h:2684 [inline]
taprio_set_budgets net/sched/sch_taprio.c:667 [inline]
advance_sched+0x58f/0x730 net/sched/sch_taprio.c:984
__run_hrtimer kernel/time/hrtimer.c:2032 [inline]
__hrtimer_run_queues+0x1f8/0x510 kernel/time/hrtimer.c:2096
value changed: 0x0000 -> 0x0001
==================================================================
Further inspection of the TC metadata structures on struct net_device
revealed three separate issues under concurrent lockless access:
1. struct netdev_tc_txq holds adjacent 16-bit offset and count fields
that are written separately in netdev_set_tc_queue() (and cleared
via memset() during reset), allowing lockless readers in fast-path
helpers and drivers to observe torn/inconsistent states. This is fixed
in Patch 1 by wrapping count and offset in a union with a u32
combined field manipulated atomically via READ_ONCE()/WRITE_ONCE().
2. dev->num_tc is read locklessly in fast-path lookups and timer
interrupts without READ_ONCE() annotations, while control paths modify
it using plain writes. Patch 2 adds READ_ONCE()/WRITE_ONCE()
annotations across core networking code and drivers.
3. dev->prio_tc_map is similarly read locklessly in fast-path helpers
such as skb_tx_hash() while control paths update entries or clear the
map via memset(). Patch 3 adds READ_ONCE()/WRITE_ONCE() annotations
to netdev_get_prio_tc_map() and netdev_set_prio_tc_map() and replaces
memset() with explicit atomic store loops.
Reported-by: syzbot+a181d44496a497911353@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a7c3457.d5f0ebe7.22d851.000a.GAE@google.com/T/#u
====================
Link: https://patch.msgid.link/20260812085440.3917924-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Concurrent fast-path readers access dev->prio_tc_map (e.g. via
skb_tx_hash(), netdev_get_prio_tc_map(), and qdiscs) while writers
update entries in dev->prio_tc_map or reset/clear the map via
netdev_reset_tc() and netdev_unbind_sb_channel().
Furthermore, memset() in netdev_reset_tc() and
netdev_unbind_sb_channel() provides no guarantee of performing
atomic word/byte stores.
Add READ_ONCE() and WRITE_ONCE() annotations to netdev_get_prio_tc_map()
and netdev_set_prio_tc_map(), replace memset() in dev.c with explicit
WRITE_ONCE() loops, and update direct array accesses in qdiscs to use
netdev_get_prio_tc_map().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260812085440.3917924-4-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Several fast-path and control-path lockless readers access dev->num_tc
(e.g., skb_tx_hash(), netdev_txq_to_tc(), netdev_get_num_tc(), and
qdisc/driver lookups) while concurrent writers update dev->num_tc
during TC setup, device reset, or channel configuration.
Add READ_ONCE() and WRITE_ONCE() annotations to prevent compiler
reordering and load/store tearing when accessing dev->num_tc.
Update inline helpers in netdevice.h (netdev_get_num_tc(),
netdev_set_prio_tc_map(), and netdev_get_sb_channel()) as well as
writers and lockless readers in core networking code and drivers.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260812085440.3917924-3-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
netdev_set_tc_queue() (and related helpers/drivers such as
netdev_bind_sb_channel_queue(), netdev_reset_tc(), and
netdev_unbind_sb_channel()) perform separate 16-bit writes to
dev->tc_to_txq[tc].count and dev->tc_to_txq[tc].offset.
Furthermore, memset() in netdev_reset_tc() and
netdev_unbind_sb_channel() provides no guarantee of performing
full 32-bit word stores.
Concurrent lockless readers (e.g. skb_tx_hash(), netdev_txq_to_tc(),
ixgbe_select_queue(), taprio, mqprio, FPE drivers) can observe torn
values where offset and count belong to inconsistent configurations.
Redefine struct netdev_tc_txq to embed count and offset inside a union
with a u32 combined field, allowing atomic manipulation via
READ_ONCE() and WRITE_ONCE().
Update all lockless readers and writers across the kernel to use
READ_ONCE() and WRITE_ONCE() on the combined field.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260812085440.3917924-2-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
driver_data is set to M_CAN_CLOCK_FREQ_EHL for all models. This change
was already five years ago, I don't expect any follow up models that
need to set a different frequency through the driver_data at this point.
Hardcode the M_CAN_CLOCK_FREQ_EHL. Once there are new models we can
evaluate what data needs to be in driver_data.
Acked-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Signed-off-by: Markus Schneider-Pargmann (The Capable Hub) <msp@baylibre.com>
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Link: https://patch.msgid.link/20260515-topic-mcan-pci-driverdata-v7-1-v2-1-e33e014ff328@baylibre.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The 'wakeup-source' property is declared as a phandle-array in both YAML
bindings and Device Tree source files. However, the driver currently
uses of_property_read_bool() to check for its existence.
According to the function's documentation, usage on non-boolean property
types is deprecated. Switch to of_property_present() to comply with the
recommended API for checking the presence of a property.
Fixes: 04d5826b07 ("can: m_can: Map WoL to device_set_wakeup_enable")
Reviewed-by: Kendall Willis <k-willis@ti.com>
Acked-by: Markus Schneider-Pargmann <msp@baylibre.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260708030512.8570-1-phucduc.bui@gmail.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Harini T <harini.t@amd.com> says:
The Xilinx CAN and CANFD controllers can be connected to an external CAN
transceiver on the board, described from the controller node via the
standard "phys" property. This binding-only series documents that property
and updates the Xilinx CAN driver maintainer.
Patch 1 replaces the maintainer of the Xilinx CAN driver in both the
MAINTAINERS entry and the binding's maintainers list.
Patch 2 documents the optional "phys" property (a single transceiver PHY).
Link: https://patch.msgid.link/20260717021415.2234865-1-harini.t@amd.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The Xilinx CAN and CANFD controllers can be connected to an external
CAN transceiver on the board. That connection is described with the
standard "phys" property on the controller node, pointing to a CAN
transceiver PHY node which models the transceiver and its control
lines (for example the standby/enable signals).
Describe the optional "phys" property (a single transceiver PHY) so
the on-board CAN transceiver can be described in the device tree.
Signed-off-by: Harini T <harini.t@amd.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260717021415.2234865-3-harini.t@amd.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Convert the Texas Instruments High End CAN Controller (HECC) bindings
to DT schema.
Signed-off-by: Eduard Bostina <egbostina@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260719140127.3558941-1-egbostina@gmail.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Replace Appana Durga Kedareswara rao with Harini T as the maintainer
of the Xilinx CAN driver. Kedar is no longer maintaining it.
Signed-off-by: Harini T <harini.t@amd.com>
Acked-by: Appana Durga Kedareswara rao <appana.durga.kedareswara.rao@amd.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260717021415.2234865-2-harini.t@amd.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Currently, vxcan_dellink() unregisters both local and peer devices
synchronously under RTNL.
Once RTNL is removed, it can be called concurrently from different
netns.
Let's use xchg() and unregister_netdevice_queue_net() to support
per-netns device unregistration.
This way, each device is queued for destruction only once by
the winner of the race.
Note that the extra netdev_hold() ensures that @peer obtained by
the first xchg() is not freed during the subsequent access to
netdev_priv(peer). The 2nd xchg() overwrites @dev to balance
the refcount.
Tested:
1. Create two vxcan pairs (vxcan1-2, vxcan3-4) between two netns
(ns1 & ns2).
# ip netns add ns1
# ip netns add ns2
# ip -n ns1 link add vxcan1 type vxcan peer vxcan2 netns ns2
# ip -n ns1 link add vxcan3 type vxcan peer vxcan4 netns ns2
2. Run bpftrace to check if the same process does NOT
unregister the paired vxcan devices
# bpftrace -e '#include <linux/netdevice.h>
kprobe:free_netdev {
$dev = (struct net_device *)arg0;
printf("PID: %d | DEV: %s%s\n", pid, $dev->name, kstack());
}'
3. Remove vxcan2 in ns2 and check bpftrace output
# ip -n ns2 link del vxcan2
PID: 1524 | DEV: vxcan2
free_netdev+5
netdev_run_todo+4798
rtnl_dellink+1507
rtnetlink_rcv_msg+1791
netlink_rcv_skb+504
...
PID: 453 | DEV: vxcan1
free_netdev+5
netdev_run_todo+4798
process_scheduled_works+2538
worker_thread+1906
kthread+806
ret_from_fork+805
ret_from_fork_asm+17
4. Remove ns2 (thus vxcan4) and check bpftrace output
# ip netns del ns2
PID: 12 | DEV: vxcan4
free_netdev+5
netdev_run_todo+4798
default_device_exit_batch+2271
ops_undo_list+993
cleanup_net+1122
process_scheduled_works+2538
worker_thread+1906
kthread+806
ret_from_fork+805
ret_from_fork_asm+17
...
PID: 462 | DEV: vxcan3
free_netdev+5
netdev_run_todo+4798
process_scheduled_works+2538
worker_thread+1906
kthread+806
ret_from_fork+805
ret_from_fork_asm+17
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260731231755.2474376-1-kuniyu@google.com
[mkl: fix indention struct vxcan_priv::peer_tracker]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Cunhao Lu <1579567540@qq.com> says:
Add support for the RK3588 CAN controller.
RK3588 integrates three CAN-FD controllers that are closely related to the
existing Rockchip CAN-FD IP already supported in the kernel. The RK3588
variant is not fully compatible with RK3568v2 because the RX FIFO count
register field has a different layout.
This series therefore:
- extends the existing Rockchip CAN-FD binding with the
rockchip,rk3588-canfd compatible
- adds a dedicated RK3588 match entry and devtype in the driver
RK3588 encodes RX_FIFO_CNT in bits 7:5 instead of 6:4. This difference was
found by comparing Rockchip's vendor kernel 6.1 CAN support for RK3568 and
RK3588, and was also confirmed by runtime testing.
RK3588 uses the existing erratum 5 empty-FIFO workaround. Based on Heiko's
testing, this series also enables the erratum 6 workaround for extended
frames being transmitted as standard frames.
CAN-FD is enabled for RK3588. The BRS bus-off issue seen in earlier testing
was caused by the transmit delay compensation setting. With
RKCANFD_REG_TRANSMIT_DELAY_COMPENSATION programmed to 0 on RK3588, CAN-FD
with BRS works in local testing.
Tested on an embedfire,rk3588-lubancat-5io board with can0/can1 directly
connected, no other device on the bus, 60 Ohm bus termination, and a 300
MHz CAN clock. The test used 500 kbit/s arbitration bitrate and 1, 3 and 5
Mbit/s data bitrates. The 5 Mbit/s data phase test ran for 15 minutes with:
| ip link set can0 type can bitrate 500000 sample-point 0.8 dbitrate 5000000 dsample-point 0.8 fd on berr-reporting on
| ip link set can1 type can bitrate 500000 sample-point 0.8 dbitrate 5000000 dsample-point 0.8 fd on berr-reporting on
| cangen can0 -I 2 -Li -Di -p 10 -f -g 1 -c32 -b
| cansequence -rv can1 -f
The receiver reported continuous sequence wrap-around messages up to
sequence wrap around (37219). Both interfaces reported 9528377 packets and
150667356 bytes, with 0 bus-errors, 0 error-warn, 0 error-pass and 0
bus-off events.
Link: https://patch.msgid.link/tencent_7BAA0052C402BFFD26291A64198084E39107@qq.com
[mkl: adjust commit message: don't merge DT changes]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The Inaccessible and Accessible legend colors has been swapped
for many years. As I have helped to clean the CTU CAN FD section
of official documentation for mass produced silicon (multiple
models of microcontrollers) with the company representatives,
I have found the problem and propagate correction bask to
the primary CTU CAN FD sources.
Signed-off-by: Pavel Pisa <ppisa@pikron.com>
Link: https://patch.msgid.link/d775feefa1c16d7ea7f42482483c81491f75ce6c.1785574572.git.pisa@cmp.felk.cvut.cz
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Add support for the RK3588 CAN controller by introducing a dedicated
model ID and OF match entry.
The block is closely related to the existing RK3568 variants, but it
cannot reuse their match data unchanged. In particular, RK3588
encodes RX_FIFO_CNT in bits 7:5 instead of 6:4, so the RX path needs
SoC-specific handling.
The RX FIFO count bitfield difference was found by comparing Rockchip's
vendor kernel 6.1 CAN support for RK3568 and RK3588. Runtime testing on
RK3588 also confirms that bits 7:5 are needed.
Enable the existing erratum 5 empty-FIFO workaround for RK3588.
Heiko reproduced erratum 6 on RK3588, so enable that workaround as
well.
CAN-FD is enabled for RK3588. The BRS bus-off issue seen in earlier
testing was caused by the transmit delay compensation setting. With
RKCANFD_REG_TRANSMIT_DELAY_COMPENSATION programmed to 0 on RK3588,
CAN-FD with BRS works in local testing.
Tested on an embedfire,rk3588-lubancat-5io board with can0/can1
directly connected, no other device on the bus, 60 Ohm bus
termination, and a 300 MHz CAN clock. Runtime testing used 500 kbit/s
arbitration bitrate and 1, 3 and 5 Mbit/s data bitrates. The 5 Mbit/s
data phase test ran for 15 minutes with cangen using BRS and
cansequence on the receiver. Both interfaces reported 9528377 packets
and 150667356 bytes, with 0 bus-errors, 0 error-warn, 0 error-pass and
0 bus-off events.
Co-developed-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Cunhao Lu <1579567540@qq.com>
Link: https://patch.msgid.link/tencent_207E464D12344B3228096E23A001D6882508@qq.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
RK3588 integrates a Rockchip CAN-FD controller variant that is not
fully compatible with RK3568v2. The RX FIFO count register field is
encoded in bits 7:5 on RK3588, while RK3568v2 uses bits 6:4.
Add a dedicated rockchip,rk3588-canfd compatible to describe this
variant. Do not use rockchip,rk3568v2-canfd as a fallback, because that
would describe a register layout that does not match the hardware.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Cunhao Lu <1579567540@qq.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/tencent_AE1A1199FC8C9ADC680C6458134A46B40309@qq.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Put the tcan4x5x transceiver into sleep mode when the driver is
removed, instead of leaving it in its current operating mode.
This reduces power consumption(3mA@12V) once the driver is
no longer bound to the device.
Signed-off-by: Sean Nyekjaer <sean@geanix.com>
Link: https://patch.msgid.link/20260805110708.3220251-1-sean@geanix.com
[mkl: tcan4x5x_power_enable(): reduce scope of ret]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
bpf_xdp_link_update() calls dev_xdp_install() directly and skips
dev_xdp_attach(), so the checks in dev_xdp_attach() do not run. A user can
make an XDP link with a normal program and then swap in an offloaded or
device-bound program with BPF_LINK_UPDATE, which puts it on the software
path.
dev_xdp_install() is the one place all three paths go through:
"ip link set xdp" and BPF_LINK_CREATE reach it via dev_xdp_attach(), and
BPF_LINK_UPDATE calls it directly. So move the program checks (offloaded,
bound to another device, device-bound in generic mode, native vs generic,
DEVMAP and CPUMAP) there, and keep only the netlink-flag check
(XDP_FLAGS_UPDATE_IF_NOEXIST) in dev_xdp_attach().
Fixes: 026a4c28e1 ("bpf, xdp: Implement LINK_UPDATE for BPF XDP link")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Please consider pulling these changes from the signed vfs-7.3-rc1.iomap tag.
Thanks!
Christian
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCan7RJQAKCRCRxhvAZXjc
oqOjAP9eZsO4M7OQpTKPgg3Sq2O9QCVgXBy4SVFba7DrbZHLZAEA/NWE+4udJzeL
j1Xb2VAyMc4S+Ze/O8sMml5Dyh4V5wE=
=34r1
-----END PGP SIGNATURE-----
Merge tag 'vfs-7.3-rc1.iomap' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull iomap updates from Christian Brauner:
"The bulk of this is the conversion of iomap to a single ->iomap_next()
callback and thus finishing the move to an iterator model.
Every iomap operation drove its iteration through a struct iomap_ops
holding ->iomap_begin() and ->iomap_end(). iomap_iter() only ever sees
those as pointers. That means every step of every iteration is an
indirect call.
This collapses both into one ->iomap_next() callback that finishes the
previous mapping and produces the next one. This lets callers inline
the iteration loop and pass its ->iomap_next() as a compile time
constant. That means the compiler can turn it into a direct and hence
inlineable call.
This also allows future callers to express custom logic to drive the
iteration forward better. xfs, btrfs, ext4, ext2, erofs, f2fs, gfs2,
hpfs, fuse, exfat, zonefs, ntfs, ntfs3 and the block device mapping
are all converted. No functional changes are intended.
This also adds a simple direct I/O path for small reads. On Gen5 NVMe
the __iomap_dio_rw() dominates 4K random reads. The same single-core
io_uring poll mode workload reaches ~3.2M IOPS against the raw block
device but only ~1.92M through ext4 or XFS.
__iomap_dio_rw(), iomap_iter(), iomap_dio_bio_iter() and kfree() were
at the top of the profile. The new path is very lightweight if no
special behavior is requested. The bio comes from a dedicated bioset
and laid out so the whole request is a single cacheline aligned
allocation. Completion runs inline.
That takes ext4 from 1.92M to 2.19M IOPS in the original workload. fio
shows around:
- 4% at libaio queue depths of 64 and up
- around 5% for io_uring
- up to 10% for io_uring poll mode at depth 256
on both ext4 and xfs.
A few other patches:
- iomap_folio_mark_uptodate() lets a filesystem that writes into the
page cache outside the iomap read and write paths keep iomap's
internal uptodate bitmap in sync, which fuse needs for
server-pushed notify stores before it can enable large folios;
- two fixes for iomap_bio_read_folio_range_sync(): a potential crash
when device integrity behavior is changed and a missing
bio_uninit().
- a folio batch release fix on iomap callback failures
- FGP_NOFS is dropped from iomap_get_folio()
- documentation fix"
* tag 'vfs-7.3-rc1.iomap' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (29 commits)
iomap: iomap_bio_read_folio_range_sync is missing a call to bio_uninit
iomap: don't free integrity payload that doesn't exist
docs: fix grammatical error in iomap docs
exfat: convert iomap ops to ->iomap_next()
fuse: convert iomap ops to ->iomap_next()
hpfs: convert iomap ops to ->iomap_next()
gfs2: convert iomap ops to ->iomap_next()
f2fs: convert iomap ops to ->iomap_next()
block: convert iomap ops to ->iomap_next()
ext2: convert iomap ops to ->iomap_next()
zonefs: convert iomap ops to ->iomap_next()
erofs: convert iomap ops to ->iomap_next()
ext4: convert iomap ops to ->iomap_next()
ntfs: convert iomap ops to ->iomap_next()
ntfs3: convert iomap ops to ->iomap_next()
btrfs: convert iomap ops to ->iomap_next()
xfs: convert iomap ops to ->iomap_next()
iomap: add ->iomap_next()
iomap: use GFP_NOWAIT when application for iomap_dio_simple allocations
iomap: decouple simple direct I/O reads from iomap_dio_rw
...
The probe drives WAKEUP high with GPIOD_OUT_HIGH, enables the input
supply, and then issues a regmap_update_bits() on INT_EN2 with no wait
anywhere in between. The TPS65185 data sheet (TI SLVSAQ8G, February
2011, revised September 2017), section 7.6 "Timing Requirements: Data
Transmission", Figure 2 "Power-Up and Power-Down Timing Diagram",
footnote 1, requires 1.8 ms minimum between the WAKEUP rising edge and
the IC being ready to accept an I2C transaction. The driver calls no
delay function anywhere, and nothing on that path is guaranteed to take
that long.
On an RK3026 board the first transfer was NAKed:
tps65185 0-0068: error -ENXIO: failed to enable temp irq
-ENXIO here is rk3x_i2c reporting REG_INT_NAKRCV. Probe failed, so
vposneg never registered and its consumer deferred indefinitely.
Wait after the supply rather than at the gpiod_get(). Figure 2 times
that 1.8 ms from a WAKEUP edge with VIN already up, whereas this driver
asserts WAKEUP before enabling vin-supply; the data sheet does not
describe that order, so on a board whose vin-supply is a switched
regulator that was off, a wait placed at the gpiod_get() could elapse
before the part had power. Waiting from whichever of the two comes last
satisfies the specified case and is the conservative choice in the
other.
It also goes above the interrupt request rather than immediately before
the INT_EN2 write, because that write is not necessarily the first
transfer: tps65185_irq_thread() reads INT1 and INT2, and it is
requested with IRQF_TRIGGER_LOW, so it can run as soon as the handler
is installed.
Tested on an ONYX BOOX C67ML (RK3026): the chip now probes, all three
regulators register and the EPD controller comes up.
Fixes: b0fc1e7701 ("regulator: Add TPS65185 driver")
Signed-off-by: Mario Rugiero <mrugiero@gmail.com>
Link: https://patch.msgid.link/20260815232229.68474-1-mrugiero@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Please consider pulling these changes from the signed vfs-7.3-rc1.fat tag.
Thanks!
Christian
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCan7RJAAKCRCRxhvAZXjc
onKkAP40wNdwV6l2ve+dioDeEAd7L8hBANbh6X6p7s8s1WUaQAEAtdq8PsA2UqBy
RjS/Mj5X+MTttydrrp3A7FQdhf5/lwQ=
=DHKe
-----END PGP SIGNATURE-----
Merge tag 'vfs-7.3-rc1.fat' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull FAT update from Christian Brauner:
"This rejects names longer than NAME_MAX in msdos_format_name().
The VFS only enforces PATH_MAX rather than the length of an individual
component. open() on such a path component reported success for a name
far longer than NAME_MAX"
* tag 'vfs-7.3-rc1.fat' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
fat: reject name longer than NAME_MAX in msdos_format_name()
With Michael Turquette stepping down as a clk co-maintainer, this
subsystem is big enough that it needs multiple people to keep the
clk community healthy. Add Brian and Jerome as co-maintainers.
Link: https://lore.kernel.org/linux-clk/anW-jTldkWSJK3wl@redhat.com/T/#m0ae01b8dd23c452d82f34b61844a8305977a53a4
Acked-by: Michael Turquette <mturquette@baylibre.com>
Signed-off-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Mike wasn't publically active for the clk subsystem since years. Stop
pretending that there is a maintainer team caring for clk.
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Acked-by: Michael Turquette <mturquette@baylibre.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Resolve parent clocks by their index into the device tree "clocks"
property rather than matching names as strings. This makes it consistent
with other parts of the same driver.
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
