| Age | Commit message (Collapse) | Author |
|---|
|
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: e69b6c02b4c3 ("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: 180b0689425c ("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: ca7f49ff8846 ("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 06c2dce2d0f6 ("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>
|
|
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 b89769f936a8 ("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 fcf42409c6e1 ("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 store which used to be left as a plain BPF_STX without an
exception table entry:
1: R1=trusted_ptr_Qdisc()
; struct Qdisc *next = sch->next_sched;
1: (79) r1 = *(u64 *)(r1 +216) ; R1=ptr_Qdisc()
; next->limit = 1000;
3: (63) *(u32 *)(r1 +20) = r2 ; R1=ptr_Qdisc() R2=1000
Assert that it is rejected now.
# LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t ns_bpf_qdisc
[...]
#257/1 ns_bpf_qdisc/fifo:OK
#257/2 ns_bpf_qdisc/fq:OK
#257/3 ns_bpf_qdisc/attach to mq:OK
#257/4 ns_bpf_qdisc/attach to non root:OK
#257/5 ns_bpf_qdisc/incompl_ops:OK
#257/6 ns_bpf_qdisc/invalid_dynptr:OK
#257/7 ns_bpf_qdisc/invalid_dynptr_cross_frame:OK
#257/8 ns_bpf_qdisc/invalid_dynptr_slice:OK
#257/9 ns_bpf_qdisc/untrusted_write:OK
#257/10 ns_bpf_qdisc/dynptr_use_after_invalidate_clone:OK
#257 ns_bpf_qdisc:OK
Summary: 1/10 PASSED, 0 SKIPPED, 0/0 FAILED
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20260817141015.878071-3-daniel@iogearbox.net
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
|
|
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>
|
|
Cover the ways in which the type recorded for a shared load used to lose
the BPF_PROBE_MEM rewrite which would then trigger a NULL deref if not
handled properly.
# LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t mem_rdonly_untrusted
[...]
#242/1 mem_rdonly_untrusted/btf_id_to_ptr_mem:OK
#242/2 mem_rdonly_untrusted/ldx_is_ok_bad_addr:OK
#242/3 mem_rdonly_untrusted/ldx_is_ok_good_addr:OK
#242/4 mem_rdonly_untrusted/offset_not_tracked:OK
#242/5 mem_rdonly_untrusted/stx_not_ok:OK
#242/6 mem_rdonly_untrusted/atomic_not_ok:OK
#242/7 mem_rdonly_untrusted/atomic_rmw_not_ok:OK
#242/8 mem_rdonly_untrusted/kfunc_param_not_ok:OK
#242/9 mem_rdonly_untrusted/mixed_mem_type:OK
#242/10 mem_rdonly_untrusted/mixed_mem_untrusted_btf_id_type:OK
#242/11 mem_rdonly_untrusted/mixed_mem_btf_id_type:OK
#242/12 mem_rdonly_untrusted/mixed_rdonly_mem_btf_id_type:OK
#242/13 mem_rdonly_untrusted/mixed_mem_mem_type:OK
#242/14 mem_rdonly_untrusted/mixed_map_value_mem_type:OK
#242/15 mem_rdonly_untrusted/mixed_stack_mem_type:OK
#242/16 mem_rdonly_untrusted/diff_size_access:OK
#242/17 mem_rdonly_untrusted/misaligned_access:OK
#242/18 mem_rdonly_untrusted/null_check:OK
#242/19 mem_rdonly_untrusted/ldx_is_ok_commuted_addr:OK
#242/20 mem_rdonly_untrusted/helper_param_not_ok:OK
#242 mem_rdonly_untrusted:OK
Summary: 1/20 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-1-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>
|
|
Fix typo in the error messag.
Signed-off-by: Fanbo He <hefanbo@gmail.com>
Link: https://patch.msgid.link/20260702031306.18988-1-hefanbo@gmail.com
[mkl: add commit message]
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: 04d5826b074e ("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>
|
|
maintainer"
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: 026a4c28e1db3 ("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>
|
|
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: b0fc1e770194 ("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>
|
|
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()
|
|
subsystem
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>
|
|
Resolve parent clocks by their index into the device tree "clocks"
property rather than matching names as strings. Name-based matching is
fragile because a clock's "clock-output-names" value in its provider
node can differ from the name used to reference it in a consumer node,
and because names must be globally unique across all clock providers.
On AM335x, this caused broken clock trees where some clocks failed to
enable because their parents could not be found.
Replace of_clk_parent_fill() with a clk_parent_data array that sets
.index to the array position.
Fixes: ec7aa25fa483 ("ARM: dts: Use clock-output-names for am3")
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>
|
|
devm_clk_get_optional_enabled_with_rate() registers its cleanup action
before setting the clock rate. If setting the rate fails, it attempts to
disable and unprepare a clock that was never enabled. This issue was
spotted while reviewing "rust: clk: add devres-managed clks" [1].
Register the cleanup action only after successfully preparing and enabling
the clock.
[1]: https://lore.kernel.org/rust-for-linux/20260706-clk-type-state-v5-3-67c5f326a16c@collabora.com
Fixes: 9934a1bd45b2 ("clk: provide devm_clk_get_optional_enabled_with_rate()")
Signed-off-by: Onur Özkan <work@onurozkan.dev>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Convert Texas Instruments keystone PSC clock binding to DT schema.
The vendor-specific 'domain-id' property is intentionally kept without a
"ti," prefix to preserve existing ABI since driver and existing board
file use property without "ti," prefix.
Also update the reference to this binding in ti,keystone-rproc.txt to
point at the new filename.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Convert the Texas Instruments APLL clock bindings to DT schema.
Signed-off-by: Eduard Bostina <egbostina@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Commit 1547747b55d5 ("clk: zynq: pll: convert from round_rate() to
determine_rate()") replaced zynq_pll_round_rate() with
zynq_pll_determine_rate() but left its kernel-doc block behind, so the
block still names the old function and documents the removed @rate and
@prate parameters instead of @req.
Retitle the block and describe @req. The Return: line described a
frequency and referenced the removed @rate; the function returns 0
unconditionally and the rounded rate comes back in @req.
No functional changes.
Assisted-by: Claude:claude-opus-5 [kernel-doc]
Signed-off-by: Babanpreet Singh <bbnpreetsingh@gmail.com>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Convert TI clockdomain to yaml DT schema. Drop '#clock-cells' from the
required list as this binding doesn't define a new clock binding type,
it is used to group existing clock nodes under hardware hierarchy. Most
existing dts omit '#clock-cells'.
Update the reference to the old legacy text binding in the description
of bindings/clock/ti/ti,gate-clock.yaml to point to the new YAML file.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Correct a few white-space issues, like double space after '=' or before
bracket '{' characters, which will be flagged by dt-check-style. No
functional changes.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
