- 20 Jul, 2022 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsecDavid S. Miller authored
Steffen Klassert says: ==================== pull request (net): ipsec 2022-07-20 1) Fix a policy refcount imbalance in xfrm_bundle_lookup. From Hangyu Hua. 2) Fix some clang -Wformat warnings. Justin Stitt ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queueJakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-07-18 This series contains updates to iavf driver only. Przemyslaw fixes handling of multiple VLAN requests to account for individual errors instead of rejecting them all. He removes incorrect implementations of ETHTOOL_COALESCE_MAX_FRAMES and ETHTOOL_COALESCE_MAX_FRAMES_IRQ. He also corrects an issue with NULL pointer caused by improper handling of dummy receive descriptors. Finally, he corrects debug prints reporting an unknown state. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: iavf: Fix missing state logs iavf: Fix handling of dummy receive descriptors iavf: Disallow changing rx/tx-frames and rx/tx-frames-irq iavf: Fix VLAN_V2 addition/rejection ==================== Link: https://lore.kernel.org/r/20220718174807.4113582-1-anthony.l.nguyen@intel.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Xin Long authored
UDP doesn't support tx memory accounting, and sysctl udp_wmem_min is not really used anywhere. So we should fix the description in ip-sysctl.rst accordingly. Fixes: 95766fff ("[UDP]: Add memory accounting.") Signed-off-by:
Xin Long <lucien.xin@gmail.com> Link: https://lore.kernel.org/r/c880a963d9b1fb5f442ae3c9e4dfa70d45296a16.1658167019.git.lucien.xin@gmail.comSigned-off-by:
-
Lorenzo Bianconi authored
odev pointer can be NULL in mtk_flow_offload_replace routine according to the flower action rules. Fix possible NULL pointer dereference in mtk_flow_get_wdma_info. Fixes: a333215e ("net: ethernet: mtk_eth_soc: implement flow offloading to WED devices") Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/4e1685bc4976e21e364055f6bee86261f8f9ee93.1658137753.git.lorenzo@kernel.orgSigned-off-by:
-
Hayes Wang authored
This fixes that the platform is waked by an unexpected packet. The size and range of FIFO is different when the device enters S3 state, so it is necessary to correct some settings when suspending. Regardless of jumbo frame, set RMS to 1522 and MTPS to MTPS_DEFAULT. Besides, enable MCU_BORW_EN to update the method of calculating the pointer of data. Then, the hardware could get the correct data. Fixes: 195aae32 ("r8152: support new chips") Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Link: https://lore.kernel.org/r/20220718082120.10957-391-nic_swsd@realtek.comSigned-off-by:
-
- 19 Jul, 2022 25 commits
-
-
Paolo Abeni authored
Taehee Yoo says: ==================== amt: fix validation and synchronization bugs There are some synchronization issues in the amt module. Especially, an amt gateway doesn't well synchronize its own variables and status(amt->status). It tries to use a workqueue for handles in a single thread. A global lock is also good, but it would occur complex locking complex. In this patchset, only the gateway uses workqueue. The reason why only gateway interface uses workqueue is that gateway should manage its own states and variables a little bit statefully. But relay doesn't need to manage tunnels statefully, stateless is okay. So, relay side message handlers are okay to be called concurrently. But it doesn't mean that no lock is needed. Only amt multicast data message type will not be processed by the work queue because It contains actual multicast data. So, it should be processed immediately. When any amt gateway events are triggered(sending discovery message by delayed_work, sending request message by delayed_work and receiving messages), it stores event and skb into the event queue(amt->events[16]). Then, workqueue processes these events one by one. The first patch is to use the work queue. The second patch is to remove unnecessary lock due to a previous patch. The third patch is to use READ_ONCE() in the amt module. Even if the amt module uses a single thread, some variables (ready4, ready6, amt->status) can be accessed concurrently. The fourth patch is to add missing nonce generation logic when it sends a new request message. The fifth patch is to drop unexpected advertisement messages. advertisement message should be received only after the gateway sends a discovery message first. So, the gateway should drop advertisement messages if it has never sent a discovery message and it also should drop duplicate advertisement messages. Using nonce is good to distinguish whether a received message is an expected message or not. The sixth patch is to drop unexpected query messages. This is the same behavior as the fourth patch. Query messages should be received only after the gateway sends a request message first. The nonce variable is used to distinguish whether it is a reply to a previous request message or not. amt->ready4 and amt->ready6 are used to distinguish duplicate messages. The seventh patch is to drop unexpected multicast data. AMT gateway should not receive multicast data message type before establish between gateway and relay. In order to drop unexpected multicast data messages, it checks amt->status. The last patch is to fix a locking problem on the relay side. amt->nr_tunnels variable is protected by amt->lock. But amt_request_handler() doesn't protect this variable. v2: - Use local_bh_disable() instead of rcu_read_lock_bh() in amt_membership_query_handler. - Fix using uninitialized variables. - Fix unexpectedly start the event_wq after stopping. - Fix possible deadlock in amt_event_work(). - Add a limit variable in amt_event_work() to prevent infinite working. - Rename amt_queue_events() to amt_queue_event(). ==================== Link: https://lore.kernel.org/r/20220717160910.19156-1-ap420073@gmail.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Taehee Yoo authored
amt->nr_tunnels is protected by amt->lock. But, amt_request_handler() has been using this variable without the amt->lock. So, it expands context of amt->lock in the amt_request_handler() to protect amt->nr_tunnels variable. Fixes: cbc21dc1 ("amt: add data plane of amt interface") Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Signed-off-by:
-
Taehee Yoo authored
AMT gateway interface should not receive unexpected multicast data. Multicast data message type should be received after sending an update message, which means all establishment between gateway and relay is finished. So, amt_multicast_data_handler() checks amt->status. Fixes: cbc21dc1 ("amt: add data plane of amt interface") Signed-off-by:
-
Taehee Yoo authored
AMT gateway interface should not receive unexpected query messages. In order to drop unexpected query messages, it checks nonce. And it also checks ready4 and ready6 variables to drop duplicated messages. Fixes: cbc21dc1 ("amt: add data plane of amt interface") Signed-off-by:
-
Taehee Yoo authored
AMT gateway interface should not receive unexpected advertisement messages. In order to drop these packets, it should check nonce and amt->status. Fixes: cbc21dc1 ("amt: add data plane of amt interface") Signed-off-by:
-
Taehee Yoo authored
When AMT gateway starts sending a new request message, it should regenerate the nonce variable. Fixes: cbc21dc1 ("amt: add data plane of amt interface") Signed-off-by:
-
Taehee Yoo authored
There are some data races in the amt module. amt->ready4, amt->ready6, and amt->status can be accessed concurrently without locks. So, it uses READ_ONCE() and WRITE_ONCE(). Fixes: cbc21dc1 ("amt: add data plane of amt interface") Signed-off-by:
-
Taehee Yoo authored
By the previous patch, amt gateway handlers are changed to worked by a single thread. So, most locks for gateway are not needed. So, it removes. Fixes: cbc21dc1 ("amt: add data plane of amt interface") Signed-off-by:
-
Taehee Yoo authored
There are some synchronization issues(amt->status, amt->req_cnt, etc) if the interface is in gateway mode because gateway message handlers are processed concurrently. This applies a work queue for processing these messages instead of expanding the locking context. So, the purposes of this patch are to fix exist race conditions and to make gateway to be able to validate a gateway status more correctly. When the AMT gateway interface is created, it tries to establish to relay. The establishment step looks stateless, but it should be managed well. In order to handle messages in the gateway, it saves the current status(i.e. AMT_STATUS_XXX). This patch makes gateway code to be worked with a single thread. Now, all messages except the multicast are triggered(received or delay expired), and these messages will be stored in the event queue(amt->events). Then, the single worker processes stored messages asynchronously one by one. The multicast data message type will be still processed immediately. Now, amt->lock is only needed to access the event queue(amt->events) if an interface is the gateway mode. Fixes: cbc21dc1 ("amt: add data plane of amt interface") Signed-off-by:
-
Oleksij Rempel authored
Add spi_device_id entries to silent SPI warnings. Fixes: 5fa6863b ("spi: Check we have a spi_device_id for each DT compatible") Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20220717135831.2492844-2-o.rempel@pengutronix.deSigned-off-by:
-
Oleksij Rempel authored
Add spi_device_id entries to silent following warnings: SPI driver sja1105 has no spi_device_id for nxp,sja1105e SPI driver sja1105 has no spi_device_id for nxp,sja1105t SPI driver sja1105 has no spi_device_id for nxp,sja1105p SPI driver sja1105 has no spi_device_id for nxp,sja1105q SPI driver sja1105 has no spi_device_id for nxp,sja1105r SPI driver sja1105 has no spi_device_id for nxp,sja1105s SPI driver sja1105 has no spi_device_id for nxp,sja1110a SPI driver sja1105 has no spi_device_id for nxp,sja1110b SPI driver sja1105 has no spi_device_id for nxp,sja1110c SPI driver sja1105 has no spi_device_id for nxp,sja1110d Fixes: 5fa6863b ("spi: Check we have a spi_device_id for each DT compatible") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20220717135831.2492844-1-o.rempel@pengutronix.deSigned-off-by:
-
Hristo Venev authored
be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case. Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only copy the bytes once. Fixes: e36edd9d ("be2net: add ethtool "-m" option support") Signed-off-by:
Hristo Venev <hristo@venev.name> Link: https://lore.kernel.org/r/20220716085134.6095-1-hristo@venev.nameSigned-off-by:
-
Wong Vee Khee authored
Disable is done in stmmac_init_eee() on the event of MAC link down. Since setting enable/disable EEE via ethtool will eventually trigger a MAC down, removing this redunctant call in stmmac_ethtool.c to avoid calling xpcs_config_eee() twice. Fixes: d4aeaed8 ("net: stmmac: trigger PCS EEE to turn off on link down") Signed-off-by:
Wong Vee Khee <vee.khee.wong@linux.intel.com> Link: https://lore.kernel.org/r/20220715122402.1017470-1-vee.khee.wong@linux.intel.comSigned-off-by:
-
Jakub Kicinski authored
Vladimir Oltean says: ==================== Fix 2 DSA issues with vlan_filtering_is_global This patch set fixes 2 issues with vlan_filtering_is_global switches. Both are regressions introduced by refactoring commit d0004a02 ("net: dsa: remove the "dsa_to_port in a loop" antipattern from the core"), which wasn't tested on a wide enough variety of switches. Tested on the sja1105 driver. ==================== Link: https://lore.kernel.org/r/20220715151659.780544-1-vladimir.oltean@nxp.comSigned-off-by:
-
Vladimir Oltean authored
The "ds" iterator variable used in dsa_port_reset_vlan_filtering() -> dsa_switch_for_each_port() overwrites the "dp" received as argument, which is later used to call dsa_port_vlan_filtering() proper. As a result, switches which do enter that code path (the ones with vlan_filtering_is_global=true) will dereference an invalid dp in dsa_port_reset_vlan_filtering() after leaving a VLAN-aware bridge. Use a dedicated "other_dp" iterator variable to avoid this from happening. Fixes: d0004a02 ("net: dsa: remove the "dsa_to_port in a loop" antipattern from the core") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
The blamed refactoring commit changed a "port" iterator with "other_dp", but still looked at the slave_dev of the dp outside the loop, instead of other_dp->slave from the loop. As a result, dsa_port_vlan_filtering() would not call dsa_slave_manage_vlan_filtering() except for the port in cause, and not for all switch ports as expected. Fixes: d0004a02 ("net: dsa: remove the "dsa_to_port in a loop" antipattern from the core") Reported-by:
Lucian Banu <Lucian.Banu@westermo.com> Signed-off-by:
-
Piotr Skajewski authored
It is possible to disable VFs while the PF driver is processing requests from the VF driver. This can result in a panic. BUG: unable to handle kernel paging request at 000000000000106c PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 8 PID: 0 Comm: swapper/8 Kdump: loaded Tainted: G I --------- - Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020 RIP: 0010:ixgbe_msg_task+0x4c8/0x1690 [ixgbe] Code: 00 00 48 8d 04 40 48 c1 e0 05 89 7c 24 24 89 fd 48 89 44 24 10 83 ff 01 0f 84 b8 04 00 00 4c 8b 64 24 10 4d 03 a5 48 22 00 00 <41> 80 7c 24 4c 00 0f 84 8a 03 00 00 0f b7 c7 83 f8 08 0f 84 8f 0a RSP: 0018:ffffb337869f8df8 EFLAGS: 00010002 RAX: 0000000000001020 RBX: 0000000000000000 RCX: 000000000000002b RDX: 0000000000000002 RSI: 0000000000000008 RDI: 0000000000000006 RBP: 0000000000000006 R08: 0000000000000002 R09: 0000000000029780 R10: 00006957d8f42832 R11: 0000000000000000 R12: 0000000000001020 R13: ffff8a00e8978ac0 R14: 000000000000002b R15: ffff8a00e8979c80 FS: 0000000000000000(0000) GS:ffff8a07dfd00000(0000) knlGS:00000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000106c CR3: 0000000063e10004 CR4: 00000000007726e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? ttwu_do_wakeup+0x19/0x140 ? try_to_wake_up+0x1cd/0x550 ? ixgbevf_update_xcast_mode+0x71/0xc0 [ixgbevf] ixgbe_msix_other+0x17e/0x310 [ixgbe] __handle_irq_event_percpu+0x40/0x180 handle_irq_event_percpu+0x30/0x80 handle_irq_event+0x36/0x53 handle_edge_irq+0x82/0x190 handle_irq+0x1c/0x30 do_IRQ+0x49/0xd0 common_interrupt+0xf/0xf This can be eventually be reproduced with the following script: while : do echo 63 > /sys/class/net/<devname>/device/sriov_numvfs sleep 1 echo 0 > /sys/class/net/<devname>/device/sriov_numvfs sleep 1 done Add lock when disabling SR-IOV to prevent process VF mailbox communication. Fixes: d773d131 ("ixgbe: Fix memory leak when SR-IOV VFs are direct assigned") Signed-off-by:Piotr Skajewski <piotrx.skajewski@intel.com> Tested-by:
Marek Szlosek <marek.szlosek@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20220715214456.2968711-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Dawid Lukwinski authored
Fix an issue when driver incorrectly detects state of recovery process and erroneously reinitializes interrupts, which results in a kernel error and call trace message. The issue was caused by a combination of two factors: 1. Assuming the EMP reset issued after completing firmware recovery means the whole recovery process is complete. 2. Erroneous reinitialization of interrupt vector after detecting the above mentioned EMP reset. Fixes (1) by changing how recovery state change is detected and (2) by adjusting the conditional expression to ensure using proper interrupt reinitialization method, depending on the situation. Fixes: 4ff0ee1a ("i40e: Introduce recovery mode support") Signed-off-by:
Dawid Lukwinski <dawid.lukwinski@intel.com> Signed-off-by:
Jan Sokolowski <jan.sokolowski@intel.com> Tested-by:
Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by:
-
Tom Rix authored
In mtk_wed_tx_ring_setup(.., int idx, ..), idx is used as an index here struct mtk_wed_ring *ring = &dev->tx_ring[idx]; The bounds of idx are checked here BUG_ON(idx > ARRAY_SIZE(dev->tx_ring)); If idx is the size of the array, it will pass this check and overflow. So change the check to >= . Fixes: 804775df ("net: ethernet: mtk_eth_soc: add support for Wireless Ethernet Dispatch (WED)") Signed-off-by:
Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20220716214654.1540240-1-trix@redhat.comSigned-off-by:
-
Jakub Kicinski authored
Horatiu Vultur says: ==================== net: lan966x: Fix issues with MAC table The patch series fixes 2 issues: - when an entry was forgotten the irq thread was holding a spin lock and then was talking also rtnl_lock. - the access to the HW MAC table is indirect, so the access to the HW MAC table was not synchronized, which means that there could be race conditions. ==================== Link: https://lore.kernel.org/r/20220714194040.231651-1-horatiu.vultur@microchip.comSigned-off-by:
-
Horatiu Vultur authored
When the SW bridge was trying to add/remove entries to/from HW, the access to HW was not protected by any lock. In this way, it was possible to have race conditions. Fix this by using the lan966x->mac_lock to protect parallel access to HW for this cases. Fixes: 25ee9561 ("net: lan966x: More MAC table functionality") Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by:
-
Horatiu Vultur authored
The problem with this spin lock is that it was just protecting the list of the MAC entries in SW and not also the access to the MAC entries in HW. Because the access to HW is indirect, then it could happen to have race conditions. For example when SW introduced an entry in MAC table and the irq mac is trying to read something from the MAC. Update such that also the access to MAC entries in HW is protected by this lock. Fixes: 5ccd66e0 ("net: lan966x: add support for interrupts from analyzer") Signed-off-by:
-
Horatiu Vultur authored
To remove an entry to the MAC table, it is required first to setup the entry and then issue a command for the MAC to forget the entry. So if it happens for two threads to remove simultaneously an entry in MAC table then it would be a race condition. Fix this by using lan966x->mac_lock to protect the HW access. Fixes: e18aba89 ("net: lan966x: add mactable support") Signed-off-by:
-
Horatiu Vultur authored
To add an entry to the MAC table, it is required first to setup the entry and then issue a command for the MAC to learn the entry. So if it happens for two threads to add simultaneously an entry in MAC table then it would be a race condition. Fix this by using lan966x->mac_lock to protect the HW access. Fixes: fc0c3fe7 ("net: lan966x: Add function lan966x_mac_ip_learn()") Signed-off-by:
-
Horatiu Vultur authored
When the HW deletes an entry in MAC table then it generates an interrupt. The SW will go through it's own list of MAC entries and if it is not found then it would notify the listeners about this. The problem is that when the SW will go through it's own list it would take a spin lock(lan966x->mac_lock) and when it notifies that the entry is deleted. But to notify the listeners it taking the rtnl_lock which is illegal. This is fixed by instead of notifying right away that the entry is deleted, move the entry on a temp list and once, it checks all the entries then just notify that the entries from temp list are deleted. Fixes: 5ccd66e0 ("net: lan966x: add support for interrupts from analyzer") Signed-off-by:
-
- 18 Jul, 2022 10 commits
-
-
Przemyslaw Patynowski authored
Fix debug prints, by adding missing state prints. Extend iavf_state_str by strings for __IAVF_INIT_EXTENDED_CAPS and __IAVF_INIT_CONFIG_ADAPTER. Without this patch, when enabling debug prints for iavf.h, user will see: iavf 0000:06:0e.0: state transition from:__IAVF_INIT_GET_RESOURCES to:__IAVF_UNKNOWN_STATE iavf 0000:06:0e.0: state transition from:__IAVF_UNKNOWN_STATE to:__IAVF_UNKNOWN_STATE Fixes: 605ca7c5 ("iavf: Fix kernel BUG in free_msi_irqs") Signed-off-by:
Przemyslaw Patynowski <przemyslawx.patynowski@intel.com> Signed-off-by:
Jun Zhang <xuejun.zhang@intel.com> Tested-by:
-
Przemyslaw Patynowski authored
Fix memory leak caused by not handling dummy receive descriptor properly. iavf_get_rx_buffer now sets the rx_buffer return value for dummy receive descriptors. Without this patch, when the hardware writes a dummy descriptor, iavf would not free the page allocated for the previous receive buffer. This is an unlikely event but can still happen. [Jesse: massaged commit message] Fixes: efa14c39 ("iavf: allow null RX descriptors") Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by:
-
Przemyslaw Patynowski authored
Remove from supported_coalesce_params ETHTOOL_COALESCE_MAX_FRAMES and ETHTOOL_COALESCE_MAX_FRAMES_IRQ. As tx-frames-irq allowed user to change budget for iavf_clean_tx_irq, remove work_limit and use define for budget. Without this patch there would be possibility to change rx/tx-frames and rx/tx-frames-irq, which for rx/tx-frames did nothing, while for rx/tx-frames-irq it changed rx/tx-frames and only changed budget for cleaning NAPI poll. Fixes: fbb7ddfe ("i40evf: core ethtool functionality") Signed-off-by:
-
Przemyslaw Patynowski authored
Fix VLAN addition, so that PF driver does not reject whole VLAN batch. Add VLAN reject handling, so rejected VLANs, won't litter VLAN filter list. Fix handling of active_(c/s)vlans, so it will be possible to re-add VLAN filters for user. Without this patch, after changing trust to off, with VLAN filters saturated, no VLAN is added, due to PF rejecting addition. Fixes: 92fc5085 ("iavf: Restrict maximum VLAN filters for VIRTCHNL_VF_OFFLOAD_VLAN_V2") Signed-off-by:
Jedrzej Jagielski <jedrzej.jagielski@intel.com> Tested-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Update DSA documentation These are some updates of dsa.rst, since it hasn't kept up with development (in some cases, even since 2017). I've added Fixes: tags as I thought was appropriate. ==================== Signed-off-by: -
Vladimir Oltean authored
The blamed commit updated the way in which VLANs are handled at the cross-chip notifier layer and didn't update the documentation to say that. Fix it. Fixes: 134ef238 ("net: dsa: add explicit support for host bridge VLANs") Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
-
Vladimir Oltean authored
Returning -EOPNOTSUPP does *NOT* mean anything special. port_vlan_add() is actually called from 2 code paths, one is vlan_vid_add() from 8021q module and the other is br_switchdev_port_vlan_add() from switchdev. The bridge has a wrapper __vlan_vid_add() which first tries via switchdev, then if that returns -EOPNOTSUPP, tries again via the VLAN RX filters in the 8021q module. But DSA doesn't distinguish between one call path and the other when calling the driver's port_vlan_add(), so if the driver returns -EOPNOTSUPP to switchdev, it also returns -EOPNOTSUPP to the 8021q module. And the latter is a hard error. port_fdb_add() is called from the deferred dsa_owq only, so obviously its return code isn't propagated anywhere, and cannot be interpreted in any way. The return code from port_mdb_add() is propagated to the bridge, but again, this doesn't do anything special when -EOPNOTSUPP is returned, but rather, br_switchdev_mdb_notify() returns void. Signed-off-by:
-
Vladimir Oltean authored
Switchdev has changed radically from its initial implementation, and the currently provided definition is incorrect and very confusing. Rewrite it in light of what it actually does. Fixes: 2bedde1a ("net: dsa: Move FDB dump implementation inside DSA") Signed-off-by:
-
Vladimir Oltean authored
The given definition for what VID 0 represents in the current port_fdb_add and port_mdb_add is blatantly wrong. Delete it and explain the concepts surrounding DSA's understanding of FDB isolation. Fixes: c2693363 ("net: dsa: request drivers to perform FDB isolation") Signed-off-by:
-
Vladimir Oltean authored
This was deleted in 2017, stop documenting it. Fixes: dc0cbff3 ("net: dsa: Remove redundant MDB dump support") Signed-off-by:
-
