- 15 Dec, 2021 1 commit
-
-
Eric Dumazet authored
syzbot reminded me that rt6_probe() can run from atomic contexts. stack backtrace: CPU: 1 PID: 7461 Comm: syz-executor.2 Not tainted 5.16.0-rc4-next-20211210-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_usage_bug kernel/locking/lockdep.c:203 [inline] valid_state kernel/locking/lockdep.c:3945 [inline] mark_lock_irq kernel/locking/lockdep.c:4148 [inline] mark_lock.cold+0x61/0x8e kernel/locking/lockdep.c:4605 mark_usage kernel/locking/lockdep.c:4500 [inline] __lock_acquire+0x11d5/0x54a0 kernel/locking/lockdep.c:4981 lock_acquire kernel/locking/lockdep.c:5639 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5604 __fs_reclaim_acquire mm/page_alloc.c:4550 [inline] fs_reclaim_acquire+0x115/0x160 mm/page_alloc.c:4564 might_alloc include/linux/sched/mm.h:253 [inline] slab_pre_alloc_hook mm/slab.h:739 [inline] slab_alloc_node mm/slub.c:3145 [inline] slab_alloc mm/slub.c:3239 [inline] kmem_cache_alloc_trace+0x3b/0x2c0 mm/slub.c:3256 kmalloc include/linux/slab.h:581 [inline] kzalloc include/linux/slab.h:715 [inline] ref_tracker_alloc+0xe1/0x430 lib/ref_tracker.c:74 netdev_tracker_alloc include/linux/netdevice.h:3860 [inline] dev_hold_track include/linux/netdevice.h:3877 [inline] rt6_probe net/ipv6/route.c:661 [inline] find_match.part.0+0xac9/0xd00 net/ipv6/route.c:752 find_match net/ipv6/route.c:825 [inline] __find_rr_leaf+0x17f/0xd20 net/ipv6/route.c:826 find_rr_leaf net/ipv6/route.c:847 [inline] rt6_select net/ipv6/route.c:891 [inline] fib6_table_lookup+0x649/0xa20 net/ipv6/route.c:2185 ip6_pol_route+0x1c5/0x11e0 net/ipv6/route.c:2221 pol_lookup_func include/net/ip6_fib.h:580 [inline] fib6_rule_lookup+0x52a/0x6f0 net/ipv6/fib6_rules.c:120 ip6_route_output_flags_noref+0x2e2/0x380 net/ipv6/route.c:2629 ip6_route_output_flags+0x72/0x320 net/ipv6/route.c:2642 ip6_route_output include/net/ip6_route.h:98 [inline] ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1070 ip6_dst_lookup_flow+0x8c/0x1d0 net/ipv6/ip6_output.c:1200 geneve_get_v6_dst+0x46f/0x9a0 drivers/net/geneve.c:858 geneve6_xmit_skb drivers/net/geneve.c:991 [inline] geneve_xmit+0x520/0x3530 drivers/net/geneve.c:1074 __netdev_start_xmit include/linux/netdevice.h:4685 [inline] netdev_start_xmit include/linux/netdevice.h:4699 [inline] xmit_one net/core/dev.c:3473 [inline] dev_hard_start_xmit+0x1eb/0x920 net/core/dev.c:3489 __dev_queue_xmit+0x2983/0x3640 net/core/dev.c:4112 neigh_resolve_output net/core/neighbour.c:1522 [inline] neigh_resolve_output+0x50e/0x820 net/core/neighbour.c:1502 neigh_output include/net/neighbour.h:541 [inline] ip6_finish_output2+0x56e/0x14f0 net/ipv6/ip6_output.c:126 __ip6_finish_output net/ipv6/ip6_output.c:191 [inline] __ip6_finish_output+0x61e/0xe80 net/ipv6/ip6_output.c:170 ip6_finish_output+0x32/0x200 net/ipv6/ip6_output.c:201 NF_HOOK_COND include/linux/netfilter.h:296 [inline] ip6_output+0x1e4/0x530 net/ipv6/ip6_output.c:224 dst_output include/net/dst.h:451 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] ndisc_send_skb+0xa99/0x17f0 net/ipv6/ndisc.c:508 ndisc_send_rs+0x12e/0x6f0 net/ipv6/ndisc.c:702 addrconf_rs_timer+0x3f2/0x820 net/ipv6/addrconf.c:3898 call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1421 expire_timers kernel/time/timer.c:1466 [inline] __run_timers.part.0+0x675/0xa20 kernel/time/timer.c:1734 __run_timers kernel/time/timer.c:1715 [inline] run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1747 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 invoke_softirq kernel/softirq.c:432 [inline] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:637 irq_exit_rcu+0x5/0x20 kernel/softirq.c:649 sysvec_apic_timer_interrupt+0x93/0xc0 arch/x86/kernel/apic/apic.c:1097 </IRQ> Fixes: fb67510b ("ipv6: add net device refcount tracker to rt6_probe_deferred()") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Link: https://lore.kernel.org/r/20211214025806.3456382-1-eric.dumazet@gmail.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- 14 Dec, 2021 14 commits
-
-
Dany Madden authored
IBMVNIC_STATS_TIMEOUT and IBMVNIC_INIT_FAILED are not used in the driver. Remove them. Suggested-by:
Sukadev Bhattiprolu <sukadev@linux.ibm.com> Signed-off-by:
Dany Madden <drt@linux.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Dany Madden authored
Update return codes to be more informative. Signed-off-by:
Jacob Root <otis@otisroot.com> Signed-off-by:
-
David S. Miller authored
This reverts commit 13510fef. Causes build warnings. Signed-off-by:
-
Changcheng Deng authored
Use min() in order to make code cleaner. Issue found by coccinelle. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Changcheng Deng <deng.changcheng@zte.com.cn> Reviewed-by:
Muchun Song <songmuchun@bytedance.com> Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== DSA tagger-owned storage fixups It seems that the DSA tagger-owned storage changes were insufficiently tested and do not work in all cases. Specifically, the NXP Bluebox 3 (arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts) got broken by these changes, because (a) I forgot that DSA_TAG_PROTO_SJA1110 exists and differs from DSA_TAG_PROTO_SJA1105 (b) the Bluebox 3 uses a DSA switch tree with 2 switches, and the tagger-owned storage patches don't cover that use case well, it seems Therefore, I'm sorry to say that there needs to be an API fixup: tagging protocol drivers will from now on connect to individual switches from a tree, rather than to the tree as a whole. This is more robust against various ordering constraints in the DSA probe and teardown paths, and is also symmetrical with the connection API exposed to the switch drivers themselves, which is also per switch. With these changes, the Bluebox 3 also works fine. ==================== Signed-off-by: -
Vladimir Oltean authored
On the NXP Bluebox 3 board which uses a multi-switch setup with sja1105, the mechanism through which the tagger connects to the switch tree is broken, due to improper DSA code design. At the time when tag_ops->connect() is called in dsa_port_parse_cpu(), DSA hasn't finished "touching" all the ports, so it doesn't know how large the tree is and how many ports it has. It has just seen the first CPU port by this time. As a result, this function will call the tagger's ->connect method too early, and the tagger will connect only to the first switch from the tree. This could be perhaps addressed a bit more simply by just moving the tag_ops->connect(dst) call a bit later (for example in dsa_tree_setup), but there is already a design inconsistency at present: on the switch side, the notification is on a per-switch basis, but on the tagger side, it is on a per-tree basis. Furthermore, the persistent storage itself is per switch (ds->tagger_data). And the tagger connect and disconnect procedures (at least the ones that exist currently) could see a fair bit of simplification if they didn't have to iterate through the switches of a tree. To fix the issue, this change transforms tag_ops->connect(dst) into tag_ops->connect(ds) and moves it somewhere where we already iterate over all switches of a tree. That is in dsa_switch_setup_tag_protocol(), which is a good placement because we already have there the connection call to the switch side of things. As for the dsa_tree_bind_tag_proto() method (called from the code path that changes the tag protocol), things are a bit more complicated because we receive the tree as argument, yet when we unwind on errors, it would be nice to not call tag_ops->disconnect(ds) where we didn't previously call tag_ops->connect(ds). We didn't have this problem before because the tag_ops connection operations passed the entire dst before, and this is more fine grained now. To solve the error rewind case using the new API, we have to create yet one more cross-chip notifier for disconnection, and stay connected with the old tag protocol to all the switches in the tree until we've succeeded to connect with the new one as well. So if something fails half way, the whole tree is still connected to the old tagger. But there may still be leaks if the tagger fails to connect to the 2nd out of 3 switches in a tree: somebody needs to tell the tagger to disconnect from the first switch. Nothing comes for free, and this was previously handled privately by the tagging protocol driver before, but now we need to emit a disconnect cross-chip notifier for that, because DSA has to take care of the unwind path. We assume that the tagging protocol has connected to a switch if it has set ds->tagger_data to something, otherwise we avoid calling its disconnection method in the error rewind path. The rest of the changes are in the tagging protocol drivers, and have to do with the replacement of dst with ds. The iteration is removed and the error unwind path is simplified, as mentioned above. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
The driver was incorrectly converted assuming that "sja1105" is the only tagger supported by this driver. This results in SJA1110 switches failing to probe: sja1105 spi1.0: Unable to connect to tag protocol "sja1110": -EPROTONOSUPPORT sja1105: probe of spi1.2 failed with error -93 Add DSA_TAG_PROTO_SJA1110 to the list of supported taggers by the sja1105 driver. The sja1105_tagger_data structure format is common for the two tagging protocols. Fixes: c79e8486 ("net: dsa: tag_sja1105: convert to tagger-owned data") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
The method was meant to zeroize ds->tagger_data but got the wrong pointer. Fix this. Fixes: c79e8486 ("net: dsa: tag_sja1105: convert to tagger-owned data") Signed-off-by:
-
Guillaume Nault authored
Add missing extacks for common configuration errors. Signed-off-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
-
Jakub Kicinski authored
dev can be a NULL here, not all requests set require_dev. Fixes: e4b89540 ("netlink: add net device refcount tracker to struct ethnl_req_info") Signed-off-by:
-
Sebastian Andrzej Siewior authored
Change the order of arguments and make qdisc_is_running() appear first. This is more readable for the general case. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
David S. Miller authored
Hangbin Liu says: ==================== net: add new hwtstamp flag HWTSTAMP_FLAG_BONDED_PHC_INDEX This patchset add a new hwtstamp_config flag HWTSTAMP_FLAG_BONDED_PHC_INDEX. When user want to get bond active interface's PHC, they need to add this flag and aware the PHC index may changed. v3: Use bitwise test to check the flags validation v2: rename the flag to HWTSTAMP_FLAG_BONDED_PHC_INDEX ==================== Signed-off-by: -
Hangbin Liu authored
When there is a failover, the PHC index of bond active interface will be changed. This may break the user space program if the author didn't aware. By setting this flag, the user should aware that the PHC index get/set by syscall is not stable. And the user space is able to deal with it. Without this flag, the kernel will reject the request forwarding to bonding. Reported-by:
Hangbin Liu <liuhangbin@gmail.com> Signed-off-by:
-
Hangbin Liu authored
Since commit 94dd016a ("bond: pass get_ts_info and SIOC[SG]HWTSTAMP ioctl to active device") the user could get bond active interface's PHC index directly. But when there is a failover, the bond active interface will change, thus the PHC index is also changed. This may break the user's program if they did not update the PHC timely. This patch adds a new hwtstamp_config flag HWTSTAMP_FLAG_BONDED_PHC_INDEX. When the user wants to get the bond active interface's PHC, they need to add this flag and be aware the PHC index may be changed. With the new flag. All flag checks in current drivers are removed. Only the checking in net_hwtstamp_validate() is kept. Suggested-by:
-
- 13 Dec, 2021 23 commits
-
-
Lorenzo Bianconi authored
Improve the build testing of mtk_eth drivers by enabling them when COMPILE_TEST is selected. Moreover COMPILE_TEST will be useful for the driver development. Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
Sebastian Andrzej Siewior authored
The root-lock is dropped before dev_hard_start_xmit() is invoked and after setting the __QDISC___STATE_RUNNING bit. If the Qdisc owner is preempted by another sender/task with a higher priority then this new sender won't be able to submit packets to the NIC directly instead they will be enqueued into the Qdisc. The NIC will remain idle until the Qdisc owner is scheduled again and finishes the job. By serializing every task on the ->busylock then the task will be preempted by a sender only after the Qdisc has no owner. Always serialize on the busylock on PREEMPT_RT. Signed-off-by:
-
Yang Li authored
The code that uses variable queued has been removed, and "mt76_is_usb(dev) ? q->ndesc - q->queued : q->queued" didn't do anything, so all they should be removed as well. Eliminate the following clang warnings: drivers/net/wireless/mediatek/mt76/debugfs.c:77:9: warning: variable ‘queued’ set but not used. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Fixes: 2d8be76c ("mt76: debugfs: improve queue node readability") Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Suresh Kumar authored
Currently "bond_should_notify_peers: slave ..." messages are printed whenever "bond_should_notify_peers" function is called. +++ Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: (slave enp0s25): Received LACPDU on port 1 Dec 12 12:33:26 node1 kernel: bond0: (slave enp0s25): Rx Machine: Port=1, Last State=6, Curr State=6 Dec 12 12:33:26 node1 kernel: bond0: (slave enp0s25): partner sync=1 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 ... Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:30 node1 kernel: bond0: (slave enp4s3): Received LACPDU on port 2 Dec 12 12:33:30 node1 kernel: bond0: (slave enp4s3): Rx Machine: Port=2, Last State=6, Curr State=6 Dec 12 12:33:30 node1 kernel: bond0: (slave enp4s3): partner sync=1 Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 +++ This is confusing and can also clutter up debug logs. Print logs only when the peer notification happens. Signed-off-by:
Suresh Kumar <suresh2514@gmail.com> Signed-off-by:
-
Clément Léger authored
dma_addr was declared using DEFINE_DMA_UNMAP_ADDR() which requires to use dma_unmap_addr() to access it. Reported-by:
kernel test robot <lkp@intel.com> Fixes: 753a026c ("net: ocelot: add FDMA support") Signed-off-by:
Clément Léger <clement.leger@bootlin.com> Signed-off-by:
-
Horatiu Vultur authored
When inserting a SFP that runs at 2.5G, then the Serdes was still configured to run at 1G. Because the config->speed was 0, and then the speed of the serdes was not configured at all, it was using the default value which is 1G. This patch stop calling the serdes function set_speed and allow the serdes to figure out the speed based on the interface type. Fixes: d28d6d2e ("net: lan966x: add port module support") Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Willem de Bruijn authored
The test is currently run on a single host with private addresses, either over veth or by setting a nic in loopback mode with macvlan. Support running between two real devices. Allow overriding addresses. Also cut timeout to fail faster on error and explicitly log success. Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
David S. Miller authored
Stefan Wahren says: ==================== add Vertexcom MSE102x support This patch series adds support for the Vertexcom MSE102x Homeplug GreenPHY chips [1]. They can be connected either via RGMII, RMII or SPI to a host CPU. These patches handles only the last one, with an Ethernet over SPI protocol driver. The code has been tested only on Raspberry Pi boards, but should work on other platforms. Changes in V3: - drop IF_PORT_HOMEPLUG again, since it's actually not used Changes in V2: - improve lock handling for RX & TX path - add new patch to introduce IF_PORT_HOMEPLUG as suggested by Andrew Lunn - address all the comments by Jakub Kicinski, Andrew Lunn, Kernel test robot [1] - http://www.vertexcom.com/p_homeplug_plc_en.html ==================== Signed-off-by:
-
Stefan Wahren authored
This implements an SPI protocol driver for Vertexcom MSE102x Homeplug GreenPHY chip. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
-
Stefan Wahren authored
Add devicetree binding for the Vertexcom MSE102x Homeplug GreenPHY chip as SPI device. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Stefan Wahren authored
Add vendor prefix for Vertexcom Technologies, Inc [1]. [1] - http://www.vertexcom.com/Signed-off-by:
-
Russell King (Oracle) authored
mvneta provides mac_an_restart and mac_pcs_get_state methods, so needs to be marked as a legacy driver. Marek spotted that mvneta had stopped working in 2500base-X mode - thanks for reporting. Reported-by:
Marek Behún <kabel@kernel.org> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Russell King (Oracle) authored
axienet has a PCS, but does not make use of the phylink PCS support. Mark it was a pre-March 2020 driver. Signed-off-by:
-
Jason Wang authored
Static variables do not need to be initialised to 0, because compiler will initialise all uninitialised statics to 0. Thus, remove the unneeded initializations. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Signed-off-by:
-
Alex Elder authored
Update the definition of the IPA interconnects for IPA v4.5 so the path between IPA and system memory is represented by a single "memory" interconnect. Tested-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
The first two interconnects defined for IPA on the SDX55 SoC are really two parts of what should be represented as a single path between IPA and system memory. Fix this by combining the "memory-a" and "memory-b" interconnects into a single "memory" interconnect. Reported-by:
David Heidelberg <david@ixit.cz> Tested-by:
-
Joanne Koong authored
This patch enables the "/proc/sys/net/unix/max_dgram_qlen" sysctl to be exposed to non-init user namespaces. max_dgram_qlen is used as the default "sk_max_ack_backlog" value for when a unix socket is created. Currently, when a networking namespace is initialized, its unix sysctls are exposed only if the user namespace that "owns" it is the init user namespace. If there is an non-init user namespace that "owns" a networking namespace (for example, in the case after we call clone() with both CLONE_NEWUSER and CLONE_NEWNET set), the sysctls are hidden from view and not configurable. Exposing the unix sysctl is safe because any changes made to it will be limited in scope to the networking namespace the non-init user namespace "owns" and has privileges over (changes won't affect any other net namespace). There is also no possibility of a non-privileged user namespace messing up the net namespace sysctls it shares with its parent user namespace. When a new user namespace is created without unsharing the network namespace (eg calling clone() with CLONE_NEWUSER), the new user namespace shares its parent's network namespace. Write access is protected by the mode set in the sysctl's ctl_table (and enforced by procfs). Here in the case of "max_dgram_qlen", 0644 is set; only the user owner has write access. v1 -> v2: * Add more detail to commit message, specify the "/proc/sys/net/unix/max_dgram_qlen" sysctl in commit message. Signed-off-by:
Joanne Koong <joannekoong@fb.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
On PREEMPT_RT the seqcount_t for synchronisation is required on 32bit architectures even on UP because the softirq (and the threaded IRQ handler) can be preempted. With the seqcount_t for synchronisation, a reader with higher priority can preempt the writer and then spin endlessly in read_seqcount_begin() while the writer can't make progress. To avoid such a lock up on PREEMPT_RT the writer must disable preemption during the update. There is no need to disable interrupts because no writer is using this API in hard-IRQ context on PREEMPT_RT. Disable preemption on 32bit-RT within the u64_stats write section. Signed-off-by:
-
David S. Miller authored
Guillaume Nault says: ==================== bareudp: Remove unused code from header file Stop exporting unused functions and structures in bareudp.h. The only piece of bareudp.h that is actually used is netif_is_bareudp(). The rest can be moved to bareudp.c or even dropped entirely. ==================== Signed-off-by: -
Guillaume Nault authored
This structure is used only in bareudp.c. While there, adjust include files: we need netdevice.h, not skbuff.h. Signed-off-by:
-
Guillaume Nault authored
There's no user for this function. Signed-off-by:
-
Xin Long authored
When key_exchange is disabled, there is no reason to accept MSG_CRYPTO msgs if it doesn't send MSG_CRYPTO msgs. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Jon Maloy <jmaloy@redhat.com> Signed-off-by:
-
Xiaoliang Yang authored
In DMA threshold mode, frame underflow errors may sometimes occur when the TC(threshold control) value is not enough. The TC value need to be bumped up in this case. There is no underflow interrupt bit on DMA_CH(#i)_Status of dwmac4, so the DMA threshold cannot be bumped up in stmmac_dma_interrupt(). The i.mx8mp board observed an underflow error while running NFS boot, the NFS rootfs could not be mounted. The underflow error can be got from the DMA descriptor TDES3 on dwmac4. This patch bump up tc value once underflow error is got from TDES3. Signed-off-by:
Xiaoliang Yang <xiaoliang.yang_1@nxp.com> Signed-off-by:
-
- 12 Dec, 2021 2 commits
-
-
David S. Miller authored
Vladimir Oltean says: ==================== Replace DSA dp->priv with tagger-owned storage Ansuel's recent work on qca8k register access over Ethernet: https://patchwork.kernel.org/project/netdevbpf/cover/20211207145942.7444-1-ansuelsmth@gmail.com/ has triggered me to do something which I should've done for a longer time: https://patchwork.kernel.org/project/netdevbpf/patch/20211109095013.27829-7-martin.kaistra@linutronix.de/#24585521 which is to replace dp->priv with something that has less caveats. The dp->priv was introduced when sja1105 needed to hold stateful information in the tagging protocol driver. In that design, dp->priv held memory allocated by the switch driver, because the tagging protocol driver design was 100% stateless. Some years have passed and others have started to feel the need for stateful information kept by the tagger, as well as passing data back and forth between the tagging protocol driver and the switch driver. This isn't possible cleanly in DSA due to a circular dependency which leads to broken module autoloading: https://lore.kernel.org/netdev/20210908220834.d7gmtnwrorhharna@skbuf/ This patchset introduces a framework that resembles something normal, which allows data to be passed from the tagging protocol driver (things like switch management packets, which aren't intended for the network stack) to the switch driver, while the tagging protocol still remains more or less stateless. The overall design of the framework was discussed with Ansuel too and it appears to be flexible enough to cover the "register access over Ethernet" use case. Additionally, the existing uses of dp->priv, which have mainly to do with PTP timestamping, have also been migrated. Changes in v2: Fix transient build breakage in patch 5/11 due to a missing parenthesis, https://patchwork.hopto.org/static/nipa/592567/12665213/build_clang/ and another transient build warning in patch 4/11 that for some reason doesn't appear in my W=1 C=1 build. https://patchwork.hopto.org/static/nipa/592567/12665209/build_clang/stderr ==================== Signed-off-by:
-
Vladimir Oltean authored
All current in-tree uses of dp->priv have been replaced with ds->tagger_data, which provides for a safer API especially when the connection isn't the regular 1:1 link between one switch driver and one tagging protocol driver, but could be either one switch to many taggers, or many switches to one tagger. Therefore, we can remove this unused pointer. Signed-off-by:
-
