- 14 Feb, 2024 11 commits
-
-
Heiner Kallweit authored
This adds LED support for RTL8125/RTL8126. Note: Due to missing datasheets changing the 5Gbps link mode isn't supported for RTL8126. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/f982602c-9de3-4ca6-85a3-2c1d118dcb15@gmail.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Krzysztof Kozlowski authored
Convert the Qualcomm Atheros AR9331 built-in switch bindings to DT schema. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20240212182911.233819-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Csókás Bence authored
FEC_ENET_FCE is the Flow Control Enable bit (bit 5) of the RCR. This is now defined as FEC_RCR_FLOWCTL. Signed-off-by:
Csókás Bence <csokas.bence@prolan.hu> Reviewed-by:
-
Csókás Bence authored
Add defines for bits of ECR, RCR control registers, TX watermark etc. Signed-off-by:
-
Jakub Kicinski authored
Eric Dumazet says: ==================== net: adopt netdev_lockdep_set_classes() Instead of waiting for syzbot to discover lockdep false positives, make sure we use netdev_lockdep_set_classes() a bit more. ==================== Link: https://lore.kernel.org/r/20240212140700.2795436-1-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
Based on a syzbot report, it appears many virtual drivers do not yet use netdev_lockdep_set_classes(), triggerring lockdep false positives. WARNING: possible recursive locking detected 6.8.0-rc4-next-20240212-syzkaller #0 Not tainted syz-executor.0/19016 is trying to acquire lock: ffff8880162cb298 (_xmit_ETHER#2){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff8880162cb298 (_xmit_ETHER#2){+.-.}-{2:2}, at: __netif_tx_lock include/linux/netdevice.h:4452 [inline] ffff8880162cb298 (_xmit_ETHER#2){+.-.}-{2:2}, at: sch_direct_xmit+0x1c4/0x5f0 net/sched/sch_generic.c:340 but task is already holding lock: ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: __netif_tx_lock include/linux/netdevice.h:4452 [inline] ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: sch_direct_xmit+0x1c4/0x5f0 net/sched/sch_generic.c:340 other info that might help us debug this: Possible unsafe locking scenario: CPU0 lock(_xmit_ETHER#2); lock(_xmit_ETHER#2); *** DEADLOCK *** May be due to missing lock nesting notation 9 locks held by syz-executor.0/19016: #0: ffffffff8f385208 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock net/core/rtnetlink.c:79 [inline] #0: ffffffff8f385208 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x82c/0x1040 net/core/rtnetlink.c:6603 #1: ffffc90000a08c00 ((&in_dev->mr_ifc_timer)){+.-.}-{0:0}, at: call_timer_fn+0xc0/0x600 kernel/time/timer.c:1697 #2: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:298 [inline] #2: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:750 [inline] #2: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x45f/0x1360 net/ipv4/ip_output.c:228 #3: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: local_bh_disable include/linux/bottom_half.h:20 [inline] #3: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: rcu_read_lock_bh include/linux/rcupdate.h:802 [inline] #3: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x2c4/0x3b10 net/core/dev.c:4284 #4: ffff8880416e3258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: spin_trylock include/linux/spinlock.h:361 [inline] #4: ffff8880416e3258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: qdisc_run_begin include/net/sch_generic.h:195 [inline] #4: ffff8880416e3258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_xmit_skb net/core/dev.c:3771 [inline] #4: ffff8880416e3258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_queue_xmit+0x1262/0x3b10 net/core/dev.c:4325 #5: ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] #5: ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: __netif_tx_lock include/linux/netdevice.h:4452 [inline] #5: ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: sch_direct_xmit+0x1c4/0x5f0 net/sched/sch_generic.c:340 #6: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:298 [inline] #6: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:750 [inline] #6: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x45f/0x1360 net/ipv4/ip_output.c:228 #7: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: local_bh_disable include/linux/bottom_half.h:20 [inline] #7: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: rcu_read_lock_bh include/linux/rcupdate.h:802 [inline] #7: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x2c4/0x3b10 net/core/dev.c:4284 #8: ffff888014d9d258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: spin_trylock include/linux/spinlock.h:361 [inline] #8: ffff888014d9d258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: qdisc_run_begin include/net/sch_generic.h:195 [inline] #8: ffff888014d9d258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_xmit_skb net/core/dev.c:3771 [inline] #8: ffff888014d9d258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_queue_xmit+0x1262/0x3b10 net/core/dev.c:4325 stack backtrace: CPU: 1 PID: 19016 Comm: syz-executor.0 Not tainted 6.8.0-rc4-next-20240212-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 check_deadlock kernel/locking/lockdep.c:3062 [inline] validate_chain+0x15c1/0x58e0 kernel/locking/lockdep.c:3856 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e4/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] __netif_tx_lock include/linux/netdevice.h:4452 [inline] sch_direct_xmit+0x1c4/0x5f0 net/sched/sch_generic.c:340 __dev_xmit_skb net/core/dev.c:3784 [inline] __dev_queue_xmit+0x1912/0x3b10 net/core/dev.c:4325 neigh_output include/net/neighbour.h:542 [inline] ip_finish_output2+0xe66/0x1360 net/ipv4/ip_output.c:235 iptunnel_xmit+0x540/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x20ee/0x2960 net/ipv4/ip_tunnel.c:831 erspan_xmit+0x9de/0x1460 net/ipv4/ip_gre.c:720 __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3555 [inline] dev_hard_start_xmit+0x242/0x770 net/core/dev.c:3571 sch_direct_xmit+0x2b6/0x5f0 net/sched/sch_generic.c:342 __dev_xmit_skb net/core/dev.c:3784 [inline] __dev_queue_xmit+0x1912/0x3b10 net/core/dev.c:4325 neigh_output include/net/neighbour.h:542 [inline] ip_finish_output2+0xe66/0x1360 net/ipv4/ip_output.c:235 igmpv3_send_cr net/ipv4/igmp.c:723 [inline] igmp_ifc_timer_expire+0xb71/0xd90 net/ipv4/igmp.c:813 call_timer_fn+0x17e/0x600 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x621/0x830 kernel/time/timer.c:2038 run_timer_softirq+0x67/0xf0 kernel/time/timer.c:2051 __do_softirq+0x2bc/0x943 kernel/softirq.c:554 invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633 irq_exit_rcu+0x9/0x30 kernel/softirq.c:645 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1076 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1076 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0010:resched_offsets_ok kernel/sched/core.c:10127 [inline] RIP: 0010:__might_resched+0x16f/0x780 kernel/sched/core.c:10142 Code: 00 4c 89 e8 48 c1 e8 03 48 ba 00 00 00 00 00 fc ff df 48 89 44 24 38 0f b6 04 10 84 c0 0f 85 87 04 00 00 41 8b 45 00 c1 e0 08 <01> d8 44 39 e0 0f 85 d6 00 00 00 44 89 64 24 1c 48 8d bc 24 a0 00 RSP: 0018:ffffc9000ee069e0 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8880296a9e00 RDX: dffffc0000000000 RSI: ffff8880296a9e00 RDI: ffffffff8bfe8fa0 RBP: ffffc9000ee06b00 R08: ffffffff82326877 R09: 1ffff11002b5ad1b R10: dffffc0000000000 R11: ffffed1002b5ad1c R12: 0000000000000000 R13: ffff8880296aa23c R14: 000000000000062a R15: 1ffff92001dc0d44 down_write+0x19/0x50 kernel/locking/rwsem.c:1578 kernfs_activate fs/kernfs/dir.c:1403 [inline] kernfs_add_one+0x4af/0x8b0 fs/kernfs/dir.c:819 __kernfs_create_file+0x22e/0x2e0 fs/kernfs/file.c:1056 sysfs_add_file_mode_ns+0x24a/0x310 fs/sysfs/file.c:307 create_files fs/sysfs/group.c:64 [inline] internal_create_group+0x4f4/0xf20 fs/sysfs/group.c:152 internal_create_groups fs/sysfs/group.c:192 [inline] sysfs_create_groups+0x56/0x120 fs/sysfs/group.c:218 create_dir lib/kobject.c:78 [inline] kobject_add_internal+0x472/0x8d0 lib/kobject.c:240 kobject_add_varg lib/kobject.c:374 [inline] kobject_init_and_add+0x124/0x190 lib/kobject.c:457 netdev_queue_add_kobject net/core/net-sysfs.c:1706 [inline] netdev_queue_update_kobjects+0x1f3/0x480 net/core/net-sysfs.c:1758 register_queue_kobjects net/core/net-sysfs.c:1819 [inline] netdev_register_kobject+0x265/0x310 net/core/net-sysfs.c:2059 register_netdevice+0x1191/0x19c0 net/core/dev.c:10298 bond_newlink+0x3b/0x90 drivers/net/bonding/bond_netlink.c:576 rtnl_newlink_create net/core/rtnetlink.c:3506 [inline] __rtnl_newlink net/core/rtnetlink.c:3726 [inline] rtnl_newlink+0x158f/0x20a0 net/core/rtnetlink.c:3739 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6606 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3c/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 __sys_sendto+0x3a4/0x4f0 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2199 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fc3fa87fa9c Reported-by:syzbot <syzkaller@googlegroups.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20240212140700.2795436-4-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
br_set_lockdep_class() is missing many details. Use generic netdev_lockdep_set_classes() to not worry anymore. Signed-off-by:
-
Eric Dumazet authored
vlan uses vlan_dev_set_lockdep_class() which lacks qdisc_tx_busylock initialization. Use generic netdev_lockdep_set_classes() to not worry anymore. Signed-off-by:
-
Jakub Kicinski authored
Eric Dumazet says: ==================== net: use net->dev_by_index in two places Bring "ip link" ordering to /proc/net/dev one (by ifindexes). Do the same for /proc/net/vlan/config v2: https://lore.kernel.org/all/20240209142441.6c56435b@kernel.org/ ==================== Link: https://lore.kernel.org/r/20240211214404.1882191-1-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
Adopt net->dev_by_index as I did in commit 0e0939c0 ("net-procfs: use xarray iterator to implement /proc/net/dev") This makes sure an existing device is always visible in the dump, regardless of concurrent insertions/deletions. v2: added suggestions from Jakub Kicinski and Ido Schimmel, thanks for the help ! Link: https://lore.kernel.org/all/20240209142441.6c56435b@kernel.org/ Link: https://lore.kernel.org/all/ZckR-XOsULLI9EHc@shredder/Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20240211214404.1882191-3-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
Adopt net->dev_by_index as I did in commit 0e0939c0 ("net-procfs: use xarray iterator to implement /proc/net/dev") Not only this removes quadratic behavior, it also makes sure an existing vlan device is always visible in the dump, regardless of concurrent net->dev_base_head changes. Signed-off-by:
-
- 13 Feb, 2024 7 commits
-
-
Robert Marko authored
PMD Global Transmit Disable bit should be cleared for normal operation. This should be HW default, however I found that on Asus RT-AX89X that uses AQR113C PHY and firmware 5.4 this bit is set by default. With this bit set the AQR cannot achieve a link with its link-partner and it took me multiple hours of digging through the vendor GPL source to find this out, so lets always clear this bit during .config_init() to avoid a situation like this in the future. Signed-off-by:
Robert Marko <robimarko@gmail.com> Reviewed-by:
Paolo Abeni <pabeni@redhat.com>
-
Stephen Hemminger authored
The prologue to codel is using BSD-3 clause and GPL-2 boiler plate language. Replace it by using SPDX. The automated treewide scan in commit d2912cb1 ("treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500") did not pickup dual licensed code. Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> Acked-by:
Dave Taht <dave.taht@gmail.com> Link: https://lore.kernel.org/r/20240211172532.6568-1-stephen@networkplumber.orgSigned-off-by:
-
Heiner Kallweit authored
Use core-provided pcpu stats allocation instead of open-coding it in the driver. Signed-off-by:
-
Harshit Mogalapalli authored
After this commit ba24ea12 ("net/sched: Retire ipt action") NET_ACT_IPT is not needed anymore as the action is retired and the code is removed. Clean the Kconfig part as well. Signed-off-by:
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Acked-by:
Jamal Hadi Salim <jhs@mojatatu.com> Link: https://lore.kernel.org/r/20240209180656.867546-1-harshit.m.mogalapalli@oracle.comSigned-off-by:
-
Kurt Kanzenbach authored
Commit 8a7cb245 ("net: stmmac: Do not enable RX FIFO overflow interrupts") disabled the RX FIFO overflow interrupts. However, it left the status variable around, but never checks it. As stmmac_host_mtl_irq_status() returns only 0 now, the code can be simplified. Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Link: https://lore.kernel.org/r/20240208-stmmac_irq-v1-1-8bab236026d4@linutronix.deSigned-off-by:
-
Guillaume Nault authored
Set scope automatically in ip_route_output_ports() (using the socket SOCK_LOCALROUTE flag). This way, callers don't have to overload the tos with the RTO_ONLINK flag, like RT_CONN_FLAGS() does. For callers that don't pass a struct sock, this doesn't change anything as the scope is still set to RT_SCOPE_UNIVERSE when sk is NULL. Callers that passed a struct sock and used RT_CONN_FLAGS(sk) or RT_CONN_FLAGS_TOS(sk, tos) for the tos are modified to use ip_sock_tos(sk) and RT_TOS(tos) respectively, as overloading tos with the RTO_ONLINK flag now becomes unnecessary. In drivers/net/amt.c, all ip_route_output_ports() calls use a 0 tos parameter, ignoring the SOCK_LOCALROUTE flag of the socket. But the sk parameter is a kernel socket, which doesn't have any configuration path for setting SOCK_LOCALROUTE anyway. Therefore, ip_route_output_ports() will continue to initialise scope with RT_SCOPE_UNIVERSE and amt.c doesn't need to be modified. Also, remove RT_CONN_FLAGS() and RT_CONN_FLAGS_TOS() from route.h as these macros are now unused. The objective is to eventually remove RTO_ONLINK entirely to allow converting ->flowi4_tos to dscp_t. This will ensure proper isolation between the DSCP and ECN bits, thus minimising the risk of introducing bugs where TOS values interfere with ECN. Signed-off-by:
Guillaume Nault <gnault@redhat.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/dacfd2ab40685e20959ab7b53c427595ba229e7d.1707496938.git.gnault@redhat.comSigned-off-by:
-
Joe Damato authored
Make mlx5 compatible with the newly added netlink queue GET APIs. Signed-off-by:
Joe Damato <jdamato@fastly.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20240209202312.30181-1-jdamato@fastly.comSigned-off-by:
-
- 12 Feb, 2024 22 commits
-
-
David S. Miller authored
Eric Dumazet says: ==================== net: avoid slow rcu synchronizations in cleanup_net() RTNL is a contended mutex, we prefer to expedite rcu synchronizations in contexts we hold RTNL. Similarly, cleanup_net() is a single threaded critical component and should also use synchronize_rcu_expedited() even when not holding RTNL. First patch removes a barrier with no clear purpose in ipv6_mc_down() ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
nf_conntrack_cleanup_net_list() is calling synchronize_net() while RTNL is not held. This effectively calls synchronize_rcu(). synchronize_rcu() is much slower than synchronize_rcu_expedited(), and cleanup_net() is currently single threaded. In many workloads we want cleanup_net() to be faster, in order to free memory and various sysfs and procfs entries as fast as possible. Signed-off-by:
-
Eric Dumazet authored
cleanup_net() is calling synchronize_rcu() right before acquiring RTNL. synchronize_rcu() is much slower than synchronize_rcu_expedited(), and cleanup_net() is currently single threaded. In many workloads we want cleanup_net() to be fast, in order to free memory and various sysfs and procfs entries as fast as possible. Signed-off-by:
-
Eric Dumazet authored
tnode_free() should use synchronize_net() instead of syncronize_rcu() to release RTNL sooner. Signed-off-by:
-
Eric Dumazet authored
br_vlan_flush() and nbp_vlan_flush() should use synchronize_net() instead of syncronize_rcu() to release RTNL sooner. Signed-off-by:
Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by:
-
Eric Dumazet authored
dev_change_name() holds RTNL, we better use synchronize_net() instead of plain synchronize_rcu(). Signed-off-by:
-
Eric Dumazet authored
As discussed in the past (commit 2d3916f3 ("ipv6: fix skb drops in igmp6_event_query() and igmp6_event_report()")) I think the synchronize_net() call in ipv6_mc_down() is not needed. Under load, synchronize_net() can last between 200 usec and 5 ms. KASAN seems to agree as well. Fixes: f185de28 ("mld: add new workqueues for process mld events") Signed-off-by:
-
David S. Miller authored
Suraj Jaiswal says: ==================== Ethernet common fault IRQ support Changes since v13: - Update correct sender email Changes since v12: - Update correct sender email Changes since v11: - Update debug message print Changes since v10: - Update commit message Changes since v9: - prevent race condition of safety IRQ handling Changes since v8: - Use shared IRQ for sfty - update error message Changes since v7: - Add support of common sfty irq on stmmac_request_irq_multi_msi. - Remove uncecessary blank line. Changes since v6: - use name sfty_irq instead of safety_common_irq. Changes since v5: - Add description of ECC, DPP, FSM Changes since v4: - Fix DT_CHECKER warning - use name safety for the IRQ. ==================== Signed-off-by: -
Suraj Jaiswal authored
Add support to listen HW safety IRQ like ECC(error correction code), DPP(data path parity), FSM(finite state machine) fault in common IRQ line. Signed-off-by:
Suraj Jaiswal <quic_jsuraj@quicinc.com> Reviewed-by:
Serge Semin <fancer.lancer@gmail.com> Signed-off-by:
-
Suraj Jaiswal authored
Add binding doc for safety IRQ. The safety IRQ will be triggered for ECC(error correction code), DPP(data path parity), FSM(finite state machine) error. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Heiner Kallweit authored
The reported bug is caused by using mii_eee_cap1_mod_linkmode_t() with an uninitialized bitmap. Fix this by zero-initializing the struct containing the bitmap. Fixes: 9bc79134 ("tg3: convert EEE handling to use linkmode bitmaps") Reported-by:
Srikanth Aithal <sraithal@amd.com> Tested-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by:
-
David S. Miller authored
Luiz Angelo Daros de Luca says: ==================== net: dsa: realtek: variants to drivers, interfaces to a common module The current driver consists of two interface modules (SMI and MDIO) and two family/variant modules (RTL8365MB and RTL8366RB). The SMI and MDIO modules serve as the platform and MDIO drivers, respectively, calling functions from the variant modules. In this setup, one interface module can be loaded independently of the other, but both variants must be loaded (if not disabled at build time) for any type of interface. This approach doesn't scale well, especially with the addition of more switch variants (e.g., RTL8366B), leading to loaded but unused modules. Additionally, this also seems upside down, as the specific driver code normally depends on the more generic functions and not the other way around. Each variant module was converted into real drivers, serving as both a platform driver (for switches connected using the SMI interface) and an MDIO driver (for MDIO-connected switches). The relationship between the variant and interface modules is reversed, with the variant module now calling both interface functions (if not disabled at build time). While in most devices only one interface is likely used, the interface code is significantly smaller than a variant module, consuming fewer resources than the previous code. With variant modules now functioning as real drivers, compatible strings are published only in a single variant module, preventing conflicts. The patch series introduces a new common module for functions shared by both variants. This module also absorbs the two previous interface modules, as they would always be loaded anyway. The series relocates the user MII driver from realtek-smi to rtl83xx. It is now used by MDIO-connected switches instead of the generic DSA driver. There's a change in how this driver locates the MDIO node. It now only searches for a child node named "mdio". The dsa_switch in realtek_priv->ds is now embedded in the struct. It is always in use and avoids dynamic memory allocation. Testing has been performed with an RTL8367S (rtl8365mb) using MDIO interface and an RTL8366RB (rtl8366) with SMI interface. ==================== Signed-off-by: -
Luiz Angelo Daros de Luca authored
Embed dsa_switch within realtek_priv to eliminate the need for a second memory allocation. Suggested-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by:
Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Luiz Angelo Daros de Luca authored
The realtek-mdio will now use this driver instead of the generic DSA driver ("dsa user smi"), which should not be used with OF[1]. With a single ds_ops for both interfaces, the ds_ops in realtek_priv is no longer necessary. Now, the realtek_variant.ds_ops can be used directly. The realtek_priv.setup_interface() has been removed as we can directly call the new common function. [1] https://lkml.kernel.org/netdev/20220630200423.tieprdu5fpabflj7@bang-olufsen.dk/T/Signed-off-by: -
Luiz Angelo Daros de Luca authored
In the user MDIO driver, despite numerous references to SMI, including its compatible string, there's nothing inherently specific about the SMI interface in the user MDIO bus. Consequently, the code has been migrated to the rtl83xx module. All references to SMI have been eliminated. The MDIO bus id was changed from Realtek-<switch id> to the switch devname suffixed with :user_mii, giving more information about the bus it is referencing. Signed-off-by:
-
Luiz Angelo Daros de Luca authored
Remove the line assigning dev.of_node in mdio_bus as subsequent of_mdiobus_register will always overwrite it. As discussed in [1], allow the DSA core to be simplified, by not assigning ds->user_mii_bus when the MDIO bus is described in OF, as it is unnecessary. Since commit 3b73a7b8 ("net: mdio_bus: add refcounting for fwnodes to mdiobus"), we can put the "mdio" node just after the MDIO bus registration. [1] https://lkml.kernel.org/netdev/20231213120656.x46fyad6ls7sqyzv@skbuf/T/#uSigned-off-by:
-
Luiz Angelo Daros de Luca authored
The binding docs requires for SMI-connected devices that the switch must have a child node named "mdio" and with a compatible string of "realtek,smi-mdio". Meanwile, for MDIO-connected switches, the binding docs only requires a child node named "mdio". This patch changes the driver to use the common denominator for both interfaces, looking for the MDIO node by name, ignoring the compatible string. Signed-off-by:
Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by:
-
Luiz Angelo Daros de Luca authored
Since rtl83xx and realtek-{smi,mdio} are always loaded together, we can optimize resource usage by consolidating them into a single module. Signed-off-by: -
Luiz Angelo Daros de Luca authored
Some code can be shared between both interface modules (MDIO and SMI) and among variants. These interface functions migrated to a common module: - rtl83xx_lock - rtl83xx_unlock - rtl83xx_probe - rtl83xx_register_switch - rtl83xx_unregister_switch - rtl83xx_shutdown - rtl83xx_remove The reset during probe was moved to the end of the common probe. This way, we avoid a reset if anything else fails. Signed-off-by:
-
Luiz Angelo Daros de Luca authored
Instead of copying values from the variant, we can keep a reference in realtek_priv. This is a preliminary change for sharing code betwen interfaces. It will allow to move most of the probe into a common module while still allow code specific to each interface to read variant fields. Signed-off-by:
-
Luiz Angelo Daros de Luca authored
Previously, the interface modules realtek-smi and realtek-mdio served as a platform and an MDIO driver, respectively. Each interface module redundantly specified the same compatible strings for both variants and referenced symbols from the variants. Now, each variant module has been transformed into a unified driver serving both as a platform and an MDIO driver. This modification reverses the relationship between the interface and variant modules, with the variant module now utilizing symbols from the interface modules. Signed-off-by:
-
Luiz Angelo Daros de Luca authored
Create a namespace to group the exported symbols. Signed-off-by:
-
