- 05 Sep, 2019 3 commits
-
-
Lorenzo Bianconi authored
Introduce mt7615_regd_notifier callback. This is a preliminary patch to add radar detection support to mt7615 driver Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Lorenzo Bianconi authored
Fix the following sparse warning in __mt7615_mcu_msg_send: drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:78:15: sparse: warning: restricted __le16 degrades to integer drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:78:15: sparse: warning: cast from restricted __le16 Fixes: 04b8e659 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
When beacon length is not a multiple of 4, the beacon could be sent with the last 1-3 bytes corrupted. The skb data is guaranteed to have enough room for reading beyond the end, because it is always followed by skb_shared_info, so rounding up is safe. All other callers of mt76_wr_copy have multiple-of-4 length already. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
- 03 Sep, 2019 32 commits
-
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct usb_int_regs { ... struct reg_data regs[0]; } __packed; Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. So, replace the following function: static int usb_int_regs_length(unsigned int count) { return sizeof(struct usb_int_regs) + count * sizeof(struct reg_data); } with: struct_size(regs, regs, count) This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Rafał Miłecki authored
Getting RAM info just once per driver's lifetime (during chip recognition) is not enough as it may get adjusted later (depending on the used firmware). Subsequent inits may load different firmwares so a full RAM recognition is required on every PCIe setup. This is especially important since implementing hardware reset on a firmware crash. Moreover calling brcmf_chip_get_raminfo() makes sure that RAM core is up. It's important as having BCMA_CORE_SYS_MEM down on BCM4366 was resulting in firmware failing to initialize and following error: [ 65.657546] brcmfmac 0000:01:00.0: brcmf_pcie_download_fw_nvram: Invalid shared RAM address 0x04000001 This change makes brcmf_chip_get_raminfo() call during chip recognition redundant for PCIe devices but SDIO and USB still need it and it's a very small overhead anyway. Fixes: 4684997d ("brcmfmac: reset PCIe bus on a firmware crash") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Colin Ian King authored
An earlier commit re-worked the setting of the bitmask and is now assigning v with some bit flags rather than bitwise or-ing them into v, consequently the earlier bit-settings of v are being lost. Fix this by replacing an assignment with the bitwise or instead. Addresses-Coverity: ("Unused value") Fixes: 2be25cac ("bcma: add constants for PCI and use them") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Xulin Sun authored
The strncpy() may truncate the copied string, replace it by the safer strscpy(). To avoid below compile warning with gcc 8.2: drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:In function 'brcmf_vndr_ie': drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:4227:2: warning: 'strncpy' output truncated before terminating nul copying 3 bytes from a string of the same length [-Wstringop-truncation] strncpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN - 1); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Xulin Sun <xulin.sun@windriver.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Stanislaw Gruszka authored
According to documentation IEEE80211_TX_STAT_AMPDU_NO_BACK is suppose to be used when we do not recive BA (BlockAck). However on rt2x00 we use it when remote station fail to decode one or more subframes within AMPDU (some bits are not set in BlockAck bitmap). Setting the flag result in sent of BAR (BlockAck Request) frame and this might result of abuse of BA session, since remote station can sent BA with incorrect sequence numbers after receiving BAR. This problem is visible especially when connecting two rt2800 devices. Previously I observed some performance benefits when using the flag when connecting with iwlwifi devices. But currently possibly due to reacent changes in rt2x00 removing the flag has no effect on those test cases. So remove the IEEE80211_TX_STAT_AMPDU_NO_BACK. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Colin Ian King authored
There is a spelling mistake in an IPW_DEBUG_INFO message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Wenwen Wang authored
In proc_BSSList_open(), 'file->private_data' is allocated through kzalloc() and 'data->rbuffer' is allocated through kmalloc(). In the following execution, if an error occurs, they are not deallocated, leading to memory leaks. To fix this issue, free the allocated memory regions before returning the error. Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Oliver Neukum authored
The function is called before the lock which is asserted was ever used. Just remove it. Reported-by: syzbot+74c65761783d66a9c97c@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Colin Ian King authored
The pointer hash is being initialized with a value that is never read and is being re-assigned a little later on. The assignment is redundant and hence can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
YueHaibing authored
drivers/bcma/driver_mips.c:70:18: warning: ipsflag_irq_shift defined but not used [-Wunused-const-variable=] drivers/bcma/driver_mips.c:62:18: warning: ipsflag_irq_mask defined but not used [-Wunused-const-variable=] They are never used, so can be removed. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Jia-Ju Bai authored
In wlc_phy_radio_init_2056(), regs_SYN_2056_ptr, regs_TX_2056_ptr and regs_RX_2056_ptr may be not assigned, and thus they are still NULL. Then, they are used on lines 20042-20050: wlc_phy_init_radio_regs(pi, regs_SYN_2056_ptr, (u16) RADIO_2056_SYN); wlc_phy_init_radio_regs(pi, regs_TX_2056_ptr, (u16) RADIO_2056_TX0); wlc_phy_init_radio_regs(pi, regs_TX_2056_ptr, (u16) RADIO_2056_TX1); wlc_phy_init_radio_regs(pi, regs_RX_2056_ptr, (u16) RADIO_2056_RX0); wlc_phy_init_radio_regs(pi, regs_RX_2056_ptr, (u16) RADIO_2056_RX1); Thus, possible null-pointer dereferences may occur. To avoid these bugs, when these variables are not assigned, wlc_phy_radio_init_2056() directly returns. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Yu-Yen Ting authored
MSI interrupt should be enabled on certain platform. Add a module parameter disable_msi to disable MSI interrupt, driver will then use legacy interrupt instead. One could rebind the PCI device, probe() will pick up the new value of the module parameter. Such as: echo '0000:01:00.0' > /sys/bus/pci/drivers/rtw_pci/unbind echo '0000:01:00.0' > /sys/bus/pci/drivers/rtw_pci/bind Tested-by: Ján Veselý <jano.vesely@gmail.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Yu-Yen Ting <steventing@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Jian-Hong Pan authored
There is a mass of jobs between spin lock and unlock in the hardware IRQ which will occupy much time originally. To make system work more efficiently, this patch moves the jobs to the soft IRQ (bottom half) to reduce the time in hardware IRQ. Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Colin Ian King authored
Pointer debugfs_topdir is initialized to a value that is never read and it is re-assigned later. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Guenter Roeck authored
0day reports: sparse warnings: drivers/net/wireless/realtek/rtw88/coex.c:2457:6: sparse: symbol 'rtw_coex_coex_dm_reset' was not declared. Should it be static? rtw_coex_coex_dm_reset() is not called. Remove it. Fixes: 4136214f ("rtw88: add BT co-existence support") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Dan Carpenter authored
The WARN_ON() macro takes a condition, not a warning message. I've changed this to use WARN() instead. Fixes: 4136214f ("rtw88: add BT co-existence support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
In commit 98fd8db5 ("rtlwifi: rtl8192ce: Convert macros that set descriptor"), all the routines that get fields from a descriptor were changed to return signed integer values. This is incorrect for the routines that get the entire 32-bit word. In this case, an unsigned quantity is required. Fixes: 98fd8db5 ("rtlwifi: rtl8192ce: Convert macros that set descriptor") Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
In commit 36eda756 ("rtlwifi: rtl8188ee: Convert macros that set descriptor"), all the routines that get fields from a descriptor were changed to return signed integer values. This is incorrect for the routines that get the entire 32-bit word. In this case, an unsigned quantity is required. Fixes: 36eda756 ("rtlwifi: rtl8188ee: Convert macros that set descriptor") Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
In commit bd421dab ("rtlwifi: rtl8821ae: Convert macros that set descriptor"), all the routines that get fields from a descriptor were changed to return signed integer values. This is incorrect for the routines that get the entire 32-bit word. In this case, an unsigned quantity is required. Fixes: bd421dab ("rtlwifi: rtl8821ae: Convert macros that set descriptor") Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
In this step, the read/write routines for the descriptors are converted to use __le32 quantities, thus a lot of casts can be removed. Callback routines still use the 8-bit arrays, but these are changed within the specified routine. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
As a first step in the conversion, the macros that set the RX and TX descriptors are converted to static inline routines, and the names are changed from upper to lower case. To minimize the changes in a given step, the input descriptor information is left as as a byte array (u8 *), even though it should be a little-endian word array (__le32 *). That will be changed in the next patch. Several places where checkpatch.pl complains about a space after a cast and other warnings are fixed. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
This driver uses a set of local macros to manipulate the TX and RX descriptors, which are all little-endian quantities. These macros are replaced by the bitfield macros le32p_replace_bits() and le32_get_bits(). In several places, the macros operated on an entire 32-bit word. In these cases, a direct read or replacement is used. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
As the first step in converting from macros that get/set information in the RX and TX descriptors, unused macros are being removed. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
A number of variables are initialized when declared that set later in the routine, thus the initialization can be removed. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
In this step, the read/write routines for the descriptors are converted to use __le32 quantities, thus a lot of casts can be removed. Callback routines still use the 8-bit arrays, but these are changed within the specified routine. The macro that cleared a descriptor has now been converted into an inline routine. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
As a first step in the conversion, the macros that set the RX and TX descriptors are converted to static inline routines, and the names are changed from upper to lower case. To minimize the changes in a given step, the input descriptor information is left as as a byte array (u8 *), even though it should be a little-endian word array (__le32 *). That will be changed in the next patch. Several places where checkpatch.pl reports lines too long are fixed. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
This driver uses a set of local macros to manipulate the RX and TX descriptors, which are all little-endian quantities. These macros are replaced by the bitfield macros le32p_replace_bits() and le32_get_bits(). In several places, the macros operated on an entire 32-bit word. In these cases, a direct read or replacement is used. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
As the first step in converting from macros that get/set information in the RX and TX descriptors, unused macros are being removed. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
If the call to hw_init() fails for any of the drivers, the driver will leak memory that was allocated in BT coexistence setup. Technically, each of the drivers should have done this free; however placing it in rtl_pci fixes all the drivers with only a single patch. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
YueHaibing authored
drivers/net/wireless/realtek/rtlwifi/efuse.c:16:31: warning: RTL8712_SDIO_EFUSE_TABLE defined but not used [-Wunused-const-variable=] drivers/net/wireless/realtek/rtlwifi/efuse.c:9:17: warning: MAX_PGPKT_SIZE defined but not used [-Wunused-const-variable=] They are never used, so can be removed. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Larry Finger authored
In the process of converting the bit manipulation macros were converted to use GENMASK(), the compiler reported a value too big for the field. The offending statement was trying to write 0x100 into a 5-bit field. An accompaning comment says to set bit 3, thus the code is changed appropriately. This error has been in the driver since its initial submission. Fixes: 29d00a3e ("rtlwifi: rtl8192cu: Add routine trx") Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Valdis Klētnieks authored
Fix spurious warning message when building with W=1: CC [M] drivers/net/wireless/realtek/rtlwifi/usb.o drivers/net/wireless/realtek/rtlwifi/usb.c:243: warning: Cannot understand * on line 243 - I thought it was a doc line drivers/net/wireless/realtek/rtlwifi/usb.c:760: warning: Cannot understand * on line 760 - I thought it was a doc line drivers/net/wireless/realtek/rtlwifi/usb.c:790: warning: Cannot understand * on line 790 - I thought it was a doc line Clean up the comment format. Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 02 Sep, 2019 5 commits
-
-
David S. Miller authored
Matteo Croce says: ==================== mvpp2: per-cpu buffers This patchset workarounds an PP2 HW limitation which prevents to use per-cpu rx buffers. The first patch is just a refactor to prepare for the second one. The second one allocates percpu buffers if the following conditions are met: - CPU number is less or equal 4 - no port is using jumbo frames If the following conditions are not met at load time, of jumbo frame is enabled later on, the shared allocation is reverted. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Matteo Croce authored
Every mvpp2 unit can use up to 8 buffers mapped by the BM (the HW buffer manager). The HW will place the frames in the buffer pool depending on the frame size: short (< 128 bytes), long (< 1664) or jumbo (up to 9856). As any unit can have up to 4 ports, the driver allocates only 2 pools, one for small and one long frames, and share them between ports. When the first port MTU is set higher than 1664 bytes, a third pool is allocated for jumbo frames. This shared allocation makes impossible to use percpu allocators, and creates contention between HW queues. If possible, i.e. if the number of possible CPU are less than 8 and jumbo frames are not used, switch to a new scheme: allocate 8 per-cpu pools for short and long frames and bind every pool to an RXQ. When the first port MTU is set higher than 1664 bytes, the allocation scheme is reverted to the old behaviour (3 shared pools), and when all ports MTU are lowered, the per-cpu buffers are allocated again. Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Matteo Croce authored
Refactor mvpp2_bm_pool_create(), mvpp2_bm_pool_destroy() and mvpp2_bm_pools_init() so that they accept a struct device instead of a struct platform_device, as they just need platform_device->dev. Removing such dependency makes the BM code more reusable in context where we don't have a pointer to the platform_device. Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
When a function such as dsa_slave_create fails, currently the following stack trace can be seen: [ 2.038342] sja1105 spi0.1: Probed switch chip: SJA1105T [ 2.054556] sja1105 spi0.1: Reset switch and programmed static config [ 2.063837] sja1105 spi0.1: Enabled switch tagging [ 2.068706] fsl-gianfar soc:ethernet@2d90000 eth2: error -19 setting up slave phy [ 2.076371] ------------[ cut here ]------------ [ 2.080973] WARNING: CPU: 1 PID: 21 at net/core/devlink.c:6184 devlink_free+0x1b4/0x1c0 [ 2.088954] Modules linked in: [ 2.092005] CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 5.3.0-rc6-01360-g41b52e38d2b6-dirty #1746 [ 2.100912] Hardware name: Freescale LS1021A [ 2.105162] Workqueue: events deferred_probe_work_func [ 2.110287] [<c03133a4>] (unwind_backtrace) from [<c030d8cc>] (show_stack+0x10/0x14) [ 2.117992] [<c030d8cc>] (show_stack) from [<c10b08d8>] (dump_stack+0xb4/0xc8) [ 2.125180] [<c10b08d8>] (dump_stack) from [<c0349d04>] (__warn+0xe0/0xf8) [ 2.132018] [<c0349d04>] (__warn) from [<c0349e34>] (warn_slowpath_null+0x40/0x48) [ 2.139549] [<c0349e34>] (warn_slowpath_null) from [<c0f19d74>] (devlink_free+0x1b4/0x1c0) [ 2.147772] [<c0f19d74>] (devlink_free) from [<c1064fc0>] (dsa_switch_teardown+0x60/0x6c) [ 2.155907] [<c1064fc0>] (dsa_switch_teardown) from [<c1065950>] (dsa_register_switch+0x8e4/0xaa8) [ 2.164821] [<c1065950>] (dsa_register_switch) from [<c0ba7fe4>] (sja1105_probe+0x21c/0x2ec) [ 2.173216] [<c0ba7fe4>] (sja1105_probe) from [<c0b35948>] (spi_drv_probe+0x80/0xa4) [ 2.180920] [<c0b35948>] (spi_drv_probe) from [<c0a4c1cc>] (really_probe+0x108/0x400) [ 2.188711] [<c0a4c1cc>] (really_probe) from [<c0a4c694>] (driver_probe_device+0x78/0x1bc) [ 2.196933] [<c0a4c694>] (driver_probe_device) from [<c0a4a3dc>] (bus_for_each_drv+0x58/0xb8) [ 2.205414] [<c0a4a3dc>] (bus_for_each_drv) from [<c0a4c024>] (__device_attach+0xd0/0x168) [ 2.213637] [<c0a4c024>] (__device_attach) from [<c0a4b1d0>] (bus_probe_device+0x84/0x8c) [ 2.221772] [<c0a4b1d0>] (bus_probe_device) from [<c0a4b72c>] (deferred_probe_work_func+0x84/0xc4) [ 2.230686] [<c0a4b72c>] (deferred_probe_work_func) from [<c03650a4>] (process_one_work+0x218/0x510) [ 2.239772] [<c03650a4>] (process_one_work) from [<c03660d8>] (worker_thread+0x2a8/0x5c0) [ 2.247908] [<c03660d8>] (worker_thread) from [<c036b348>] (kthread+0x148/0x150) [ 2.255265] [<c036b348>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c) [ 2.262444] Exception stack(0xea965fb0 to 0xea965ff8) [ 2.267466] 5fa0: 00000000 00000000 00000000 00000000 [ 2.275598] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.283729] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 2.290333] ---[ end trace ca5d506728a0581a ]--- devlink_free is complaining right here: WARN_ON(!list_empty(&devlink->port_list)); This happens because devlink_port_unregister is no longer done right away in dsa_port_setup when a DSA_PORT_TYPE_USER has failed. Vivien said about this change that: Also no need to call devlink_port_unregister from within dsa_port_setup as this step is inconditionally handled by dsa_port_teardown on error. which is not really true. The devlink_port_unregister function _is_ being called unconditionally from within dsa_port_setup, but not for this port that just failed, just for the previous ones which were set up. ports_teardown: for (i = 0; i < port; i++) dsa_port_teardown(&ds->ports[i]); Initially I was tempted to fix this by extending the "for" loop to also cover the port that failed during setup. But this could have potentially unforeseen consequences unrelated to devlink_port or even other types of ports than user ports, which I can't really test for. For example, if for some reason devlink_port_register itself would fail, then unconditionally unregistering it in dsa_port_teardown would not be a smart idea. The list might go on. So just make dsa_port_setup undo the setup it had done upon failure, and let the for loop undo the work of setting up the previous ports, which are guaranteed to be brought up to a consistent state. Fixes: 955222ca ("net: dsa: use a single switch statement for port setup") Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
Take only FIB events that are happening in init_net into account. No other namespaces are supported. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Roi Dayan <roid@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-