- 07 Jan, 2021 17 commits
-
-
Alaa Hleihel authored
Adding vf VLANID for the first time, or after having cleared previously defined VLANID works fine, however, attempting to change an existing vf VLANID clears the rules on the firmware, but does not add new rules for the new vf VLANID. Fix this by changing the logic in function esw_acl_egress_lgcy_setup() so that it will always configure egress rules. Fixes: ea651a86 ("net/mlx5: E-Switch, Refactor eswitch egress acl codes") Signed-off-by:
Alaa Hleihel <alaa@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Moshe Shemesh authored
In case WQE includes inline header the vlan is inserted by driver even if vlan offload is set. On geneve over vlan interface where software parser is used the SWP offsets should be updated according to the added vlan. Fixes: e3cfc7e6 ("net/mlx5e: TX, Add geneve tunnel stateless offload support") Signed-off-by:
Moshe Shemesh <moshe@mellanox.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
-
Oz Shlomo authored
Connection counters may be shared for both directions when the counter is used for connection aging purposes. However, if TC flow accounting is enabled then a unique counter is required per direction. Instantiate a unique counter per direction if the conntrack accounting extension is enabled. Use a shared counter when the connection accounting extension is disabled. Fixes: 1edae233 ("net/mlx5e: CT: Use the same counter for both directions") Signed-off-by:
Oz Shlomo <ozsh@nvidia.com> Reported-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Reviewed-by:
Roi Dayan <roid@nvidia.com> Reviewed-by:
Paul Blakey <paulb@nvidia.com> Signed-off-by:
-
Mark Zhang authored
In multi-port mode, FW reports syndrome 0x2ea48 (invalid vhca_port_number) if the port_num is not 1 or 2. Fixes: 80f09dfc ("net/mlx5: Eswitch, enable RoCE loopback traffic") Signed-off-by:
Mark Zhang <markzhang@nvidia.com> Reviewed-by:
Maor Gottlieb <maorg@nvidia.com> Signed-off-by:
-
Aya Levin authored
Expose firmware indication that it supports setting eswitch uplink state to follow (follow the physical link). Condition setting the eswitch uplink admin-state with this capability bit. Older FW may not support the uplink state setting. Fixes: 7d0314b1 ("net/mlx5e: Modify uplink state on interface up/down") Signed-off-by:
Aya Levin <ayal@nvidia.com> Reviewed-by:
Moshe Shemesh <moshe@nvidia.com> Signed-off-by:
-
Mark Zhang authored
This patch fixes a memleak issue by preventing to create a lag and add PFs if lag is not supported. comm “python3”, pid 349349, jiffies 4296985507 (age 1446.976s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [<000000005b216ae7>] mlx5_lag_add+0x1d5/0×3f0 [mlx5_core] [<000000000445aa55>] mlx5e_nic_enable+0x66/0×1b0 [mlx5_core] [<00000000c56734c3>] mlx5e_attach_netdev+0x16e/0×200 [mlx5_core] [<0000000030439d1f>] mlx5e_attach+0x5c/0×90 [mlx5_core] [<0000000018fd8615>] mlx5e_add+0x1a4/0×410 [mlx5_core] [<0000000068bc504b>] mlx5_add_device+0x72/0×120 [mlx5_core] [<000000009fce51f9>] mlx5_register_device+0x77/0xb0 [mlx5_core] [<00000000d0d81ff3>] mlx5_load_one+0xc58/0×1eb0 [mlx5_core] [<0000000045077adc>] init_one+0x3ea/0×920 [mlx5_core] [<0000000043287674>] pci_device_probe+0xcd/0×150 [<00000000dafd3279>] really_probe+0x1c9/0×4b0 [<00000000f06bdd84>] driver_probe_device+0x5d/0×140 [<00000000e3d508b6>] device_driver_attach+0x4f/0×60 [<0000000084fba0f0>] bind_store+0xbf/0×120 [<00000000bf6622b3>] kernfs_fop_write+0x114/0×1b0 Fixes: 9b412cc3 ("net/mlx5e: Add LAG warning if bond slave is not lag master") Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Reviewed-by:
-
Sean Tranchetti authored
Adds new 2 new tests to the PTMU script: pmtu_ipv4/6_route_change. These tests explicitly test for a recently discovered problem in the IPv6 routing framework where PMTU exceptions were not properly released when replacing a route via "ip route change ...". After creating PMTU exceptions, the route from the device A to R1 will be replaced with a new route, then device A will be deleted. If the PMTU exceptions were properly cleaned up by the kernel, this device deletion will succeed. Otherwise, the unregistration of the device will stall, and messages such as the following will be logged in dmesg: unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 4 Signed-off-by:
Sean Tranchetti <stranche@codeaurora.org> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/1609892546-11389-2-git-send-email-stranche@quicinc.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Sean Tranchetti authored
Route removal is handled by two code paths. The main removal path is via fib6_del_route() which will handle purging any PMTU exceptions from the cache, removing all per-cpu copies of the DST entry used by the route, and releasing the fib6_info struct. The second removal location is during fib6_add_rt2node() during a route replacement operation. This path also calls fib6_purge_rt() to handle cleaning up the per-cpu copies of the DST entries and releasing the fib6_info associated with the older route, but it does not flush any PMTU exceptions that the older route had. Since the older route is removed from the tree during the replacement, we lose any way of accessing it again. As these lingering DSTs and the fib6_info struct are holding references to the underlying netdevice struct as well, unregistering that device from the kernel can never complete. Fixes: 2b760fcf ("ipv6: hook up exception table to store dst cache") Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-fixes-for-5.11-20210107' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2021-01-07 The first patch is by me for the m_can driver and removes an erroneous m_can_clk_stop() from the driver's unregister function. The second patch targets the tcan4x5x driver, is by me, and fixes the bit timing constant parameters. The next two patches are by me, target the mcp251xfd driver, and fix a race condition in the optimized TEF path (which was added in net-next for v5.11). The similar code in the RX path is changed to look the same, although it doesn't suffer from the race condition. A patch by Lad Prabhakar updates the description and help text for the rcar CAN driver to reflect all supported SoCs. In the last patch Sriram Dash transfers the maintainership of the m_can driver to Pankaj Sharma. * tag 'linux-can-fixes-for-5.11-20210107' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: MAINTAINERS: Update MCAN MMIO device driver maintainer can: rcar: Kconfig: update help description for CAN_RCAR config can: mcp251xfd: mcp251xfd_handle_rxif_ring(): first increment RX tail pointer in HW, then in driver can: mcp251xfd: mcp251xfd_handle_tefif(): fix TEF vs. TX race condition can: tcan4x5x: fix bittiming const, use common bittiming from m_can driver can: m_can: m_can_class_unregister(): remove erroneous m_can_clk_stop() ==================== Link: https://lore.kernel.org/r/20210107103451.183477-1-mkl@pengutronix.deSigned-off-by:
-
Sriram Dash authored
Update Pankaj Sharma as maintainer for mcan mmio device driver as I will be moving to a different role. Signed-off-by:
Sriram Dash <sriram.dash@samsung.com> Acked-by:
Pankaj Sharma <pankj.sharma@samsung.com> Link: https://lore.kernel.org/r/20210104123134.16930-1-sriram.dash@samsung.comSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Lad Prabhakar authored
The rcar_can driver also supports RZ/G SoC's, update the description to reflect this. Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210104090327.6547-1-prabhakar.mahadev-lad.rj@bp.renesas.comSigned-off-by:
-
Marc Kleine-Budde authored
The previous patch fixes a TEF vs. TX race condition, by first updating the TEF tail pointer in hardware, and then updating the driver internal pointer. The same pattern exists in the RX-path, too. This should be no problem, as the driver accesses the RX-FIFO from the interrupt handler only, thus the access is properly serialized. Fix the order here, too, so that the TEF- and RX-path look similar. Fixes: 1f652bb6 ("can: mcp25xxfd: rx-path: reduce number of SPI core requests to set UINC bit") Link: https://lore.kernel.org/r/20210105214138.3150886-3-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
The mcp251xfd driver uses a TX FIFO for sending CAN frames and a TX Event FIFO (TEF) for completed TX-requests. The TEF event handling in the mcp251xfd_handle_tefif() function has a race condition. It first increments the tx-ring's tail counter to signal that there's room in the TX and TEF FIFO, then it increments the TEF FIFO in hardware. A running mcp251xfd_start_xmit() on a different CPU might not stop the txqueue (as the tx-ring still shows free space). The next mcp251xfd_start_xmit() will push a message into the chip and the TX complete event might overflow the TEF FIFO. This patch changes the order to fix the problem. Fixes: 68c0c1c7 ("can: mcp251xfd: tef-path: reduce number of SPI core requests to set UINC bit") Link: https://lore.kernel.org/r/20210105214138.3150886-2-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
According to the TCAN4550 datasheet "SLLSF91 - DECEMBER 2018" the tcan4x5x has the same bittiming constants as a m_can revision 3.2.x/3.3.0. The tcan4x5x chip I'm using identifies itself as m_can revision 3.2.1, so remove the tcan4x5x specific bittiming values and rely on the values in the m_can driver, which are selected according to core revision. Fixes: 5443c226 ("can: tcan4x5x: Add tcan4x5x driver to the kernel") Cc: Dan Murphy <dmurphy@ti.com> Reviewed-by:
Sean Nyekjaer <sean@geanix.com> Link: https://lore.kernel.org/r/20201215103238.524029-3-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
In m_can_class_register() the clock is started, but stopped on exit. When calling m_can_class_unregister(), the clock is stopped a second time. This patch removes the erroneous m_can_clk_stop() in m_can_class_unregister(). Fixes: f524f829 ("can: m_can: Create a m_can platform framework") Cc: Dan Murphy <dmurphy@ti.com> Cc: Sriram Dash <sriram.dash@samsung.com> Reviewed-by:
-
Randy Dunlap authored
ptp_ines.c uses devm_platform_ioremap_resource(), which is only built/available when CONFIG_HAS_IOMEM is enabled. CONFIG_HAS_IOMEM is not enabled for arch/s390/, so builds on S390 have a build error: s390-linux-ld: drivers/ptp/ptp_ines.o: in function `ines_ptp_ctrl_probe': ptp_ines.c:(.text+0x17e6): undefined reference to `devm_platform_ioremap_resource' Prevent builds of ptp_ines.c when HAS_IOMEM is not set. Fixes: bad1eaa6 ("ptp: Add a driver for InES time stamping IP core.") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kernel test robot <lkp@intel.com> Link: lore.kernel.org/r/202101031125.ZEFCUiKi-lkp@intel.com Acked-by:
Richard Cochran <richardcochran@gmail.com> Link: https://lore.kernel.org/r/20210106042531.1351-1-rdunlap@infradead.orgSigned-off-by:
-
Randy Dunlap authored
Fix build errors when LEDS_CLASS=m and NET_DSA_HIRSCHMANN_HELLCREEK=y. This limits the latter to =m when LEDS_CLASS=m. microblaze-linux-ld: drivers/net/dsa/hirschmann/hellcreek_ptp.o: in function `hellcreek_ptp_setup': (.text+0xf80): undefined reference to `led_classdev_register_ext' microblaze-linux-ld: (.text+0xf94): undefined reference to `led_classdev_register_ext' microblaze-linux-ld: drivers/net/dsa/hirschmann/hellcreek_ptp.o: in function `hellcreek_ptp_free': (.text+0x1018): undefined reference to `led_classdev_unregister' microblaze-linux-ld: (.text+0x1024): undefined reference to `led_classdev_unregister' Signed-off-by:
-
- 06 Jan, 2021 18 commits
-
-
Jakub Kicinski authored
.dellink does not get called after .newlink fails, bareudp_newlink() must undo what bareudp_configure() has done if bareudp_link_config() fails. v2: call bareudp_dellink(), like bareudp_dev_create() does Fixes: 571912c6 ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Link: https://lore.kernel.org/r/20210105190725.1736246-1-kuba@kernel.orgSigned-off-by:
-
Marek Behún authored
The error message says that "Jumbo frames are not supported on XDP", but the code checks for mtu > MVNETA_MAX_RX_BUF_SIZE, not mtu > 1500. Fix this error message. Signed-off-by:
Marek Behún <kabel@kernel.org> Fixes: 0db51da7 ("net: mvneta: add basic XDP support") Cc: Lorenzo Bianconi <lorenzo@kernel.org> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Link: https://lore.kernel.org/r/20210105172333.21613-1-kabel@kernel.orgSigned-off-by:
-
Po-Hsu Lin authored
The udpgro.sh will always return 0 (unless the bpf selftest was not build first) even if there are some failed sub test-cases. Therefore the kselftest framework will report this case is OK. Check and return the exit status of each test to make it easier to spot real failures. Signed-off-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michael Ellerman authored
Since commit 1d6cd392 ("modpost: turn missing MODULE_LICENSE() into error") the ppc32_allmodconfig build fails with: ERROR: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/freescale/fs_enet/mii-fec.o ERROR: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/freescale/fs_enet/mii-bitbang.o Add the missing MODULE_LICENSEs to fix the build. Both files include a copyright header indicating they are GPL v2. Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Qinglang Miao authored
A null-ptr-deref bug is reported by Hulk Robot like this: -------------- KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] Call Trace: qrtr_ns_remove+0x22/0x40 [ns] qrtr_proto_fini+0xa/0x31 [qrtr] __x64_sys_delete_module+0x337/0x4e0 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x468ded -------------- When qrtr_ns_init fails in qrtr_proto_init, qrtr_ns_remove which would be called later on would raise a null-ptr-deref because qrtr_ns.workqueue has been destroyed. Fix it by making qrtr_ns_init have a return value and adding a check in qrtr_proto_init. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by:
-
Jouni K. Seppänen authored
Aligning to tx_ndp_modulus is not sufficient because the next align call can be cdc_ncm_align_tail, which can add up to ctx->tx_modulus + ctx->tx_remainder - 1 bytes. This used to lead to occasional crashes on a Huawei 909s-120 LTE module as follows: - the condition marked /* if there is a remaining skb [...] */ is true so the swaps happen - skb_out is set from ctx->tx_curr_skb - skb_out->len is exactly 0x3f52 - ctx->tx_curr_size is 0x4000 and delayed_ndp_size is 0xac (note that the sum of skb_out->len and delayed_ndp_size is 0x3ffe) - the for loop over n is executed once - the cdc_ncm_align_tail call marked /* align beginning of next frame */ increases skb_out->len to 0x3f56 (the sum is now 0x4002) - the condition marked /* check if we had enough room left [...] */ is false so we break out of the loop - the condition marked /* If requested, put NDP at end of frame. */ is true so the NDP is written into skb_out - now skb_out->len is 0x4002, so padding_count is minus two interpreted as an unsigned number, which is used as the length argument to memset, leading to a crash with various symptoms but usually including > Call Trace: > <IRQ> > cdc_ncm_fill_tx_frame+0x83a/0x970 [cdc_ncm] > cdc_mbim_tx_fixup+0x1d9/0x240 [cdc_mbim] > usbnet_start_xmit+0x5d/0x720 [usbnet] The cdc_ncm_align_tail call first aligns on a ctx->tx_modulus boundary (adding at most ctx->tx_modulus-1 bytes), then adds ctx->tx_remainder bytes. Alternatively, the next alignment call can occur in cdc_ncm_ndp16 or cdc_ncm_ndp32, in which case at most ctx->tx_ndp_modulus-1 bytes are added. A similar problem has occurred before, and the code is nontrivial to reason about, so add a guard before the crashing call. By that time it is too late to prevent any memory corruption (we'll have written past the end of the buffer already) but we can at least try to get a warning written into an on-disk log by avoiding the hard crash caused by padding past the buffer with a huge number of zeros. Signed-off-by:
Jouni K. Seppänen <jks@iki.fi> Fixes: 4a0e3e98 ("cdc_ncm: Add support for moving NDP to end of NCM frame") Link: https://bugzilla.kernel.org/show_bug.cgi?id=209407Reported-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: fixes for -net There are some bugfixes for the HNS3 ethernet driver. ==================== Signed-off-by: -
Jian Shen authored
For DEVICE_VERSION_V2, the hardware only supports src-ip, dst-ip and verification-tag for rss tuple set of sctp6 packet. For DEVICE_VERSION_V3, the hardware supports src-port and dst-port as well. Currently, when user queries the sctp6 rss tuples info, some unsupported information will be showed on V2. So add a check for hardware version when initializing and queries sctp6 rss tuple to fix this issue. Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Yufeng Mo authored
HCLGE_MBX_MAX_ARQ_MSG_NUM is used to apply memory for the number of queues used by ARQ(Asynchronous Receive Queue), so the head and tail pointers should also use this macro. Fixes: 07a0556a ("net: hns3: Changes to support ARQ(Asynchronous Receive Queue)") Signed-off-by:
Yufeng Mo <moyufeng@huawei.com> Signed-off-by:
-
Yonglong Liu authored
When phy driver does not implement the set_loopback interface, phy loopback test will return -EOPNOTSUPP, and the loopback test will fail. So when phy driver does not implement the set_loopback interface, don't do phy loopback test. Fixes: c9765a89 ("net: hns3: add phy selftest function") Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Signed-off-by:
-
Jakub Kicinski authored
Fix calling context. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
David S. Miller authored
Samuel Holland says: ==================== Fixes for dwmac-sun8i suspend/resume This series fixes issues preventing dwmac-sun8i from working after a suspend/resume cycle. Those issues include the PHY being left powered off, the MAC syscon configuration being reset, and the reference to the reset controller being improperly dropped. They also fix related issues in probe error handling and driver removal. ==================== Signed-off-by: -
Samuel Holland authored
Previously, sun8i_dwmac_set_syscon was called from a chain of functions in several different files: sun8i_dwmac_probe stmmac_dvr_probe stmmac_hw_init stmmac_hwif_init sun8i_dwmac_setup sun8i_dwmac_set_syscon which made the lifetime of the syscon values hard to reason about. Part of the problem is that there is no similar platform driver callback from stmmac_dvr_remove. As a result, the driver unset the syscon value in sun8i_dwmac_exit, but this leaves it uninitialized after a suspend/ resume cycle. It was also unset a second time (outside sun8i_dwmac_exit) in the probe error path. Move the init to the earliest available place in sun8i_dwmac_probe (after stmmac_probe_config_dt, which initializes plat_dat), and the deinit to the corresponding position in the cleanup order. Since priv is not filled in until stmmac_dvr_probe, this requires changing the sun8i_dwmac_set_syscon parameters to priv's two relevant members. Fixes: 9f93ac8d ("net-next: stmmac: Add dwmac-sun8i") Fixes: 634db83b ("net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs") Signed-off-by:Samuel Holland <samuel@sholland.org> Signed-off-by:
-
Samuel Holland authored
sun8i_dwmac_exit calls sun8i_dwmac_unpower_internal_phy, but sun8i_dwmac_init did not call sun8i_dwmac_power_internal_phy. This caused PHY power to remain off after a suspend/resume cycle. Fix this by recording if PHY power should be restored, and if so, restoring it. Fixes: 634db83b ("net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs") Signed-off-by:
-
Samuel Holland authored
While stmmac_pltfr_remove calls sun8i_dwmac_exit, the sun8i_dwmac_init and sun8i_dwmac_exit functions are also called by the stmmac_platform suspend/resume callbacks. They may be called many times during the device's lifetime and should not release resources used by the driver. Furthermore, there was no error handling in case registering the MDIO mux failed during probe, and the EPHY clock was never released at all. Fix all of these issues by moving the deinitialization code to a driver removal callback. Also ensure the EPHY is powered down before removal. Fixes: 634db83b ("net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Samuel Holland authored
stmmac_pltfr_remove does three things in one function, making it inapproprate for unwinding the steps in the probe function. Currently, a failure before the call to stmmac_dvr_probe would leak OF node references due to missing a call to stmmac_remove_config_dt. And an error in stmmac_dvr_probe would cause the driver to attempt to remove a netdevice that was never added. Fix these by reordering the init and splitting out the error handling steps. Fixes: 9f93ac8d ("net-next: stmmac: Add dwmac-sun8i") Fixes: 40a1dcee ("net: ethernet: dwmac-sun8i: Use the correct function in exit path") Signed-off-by:
-
Jakub Kicinski authored
VLAN checks for NETREG_UNINITIALIZED to distinguish between registration failure and unregistration in progress. Since commit cb626bf5 ("net-sysfs: Fix reference count leak") registration failure may, however, result in NETREG_UNREGISTERED as well as NETREG_UNINITIALIZED. This fix is similer to cebb6975 ("rtnetlink: Fix memory(net_device) leak when ->newlink fails") Fixes: cb626bf5 ("net-sysfs: Fix reference count leak") Signed-off-by:
-
Jakub Kicinski authored
From the existing definitions it's unclear which stat to use to report filtering based on L2 dst addr in old broadcast-medium Ethernet. Signed-off-by:
-
- 05 Jan, 2021 5 commits
-
-
Christophe JAILLET authored
A call to dma_alloc_coherent() is wrapped by sonic_alloc_descriptors(). This is correctly freed in the remove function, but not in the error handling path of the probe function. Fix this by adding the missing dma_free_coherent() call. While at it, rename a label in order to be slightly more informative. Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Chris Zankel <chris@zankel.net> References: commit 10e3cc18 ("net/sonic: Fix a resource leak in an error handling path in 'jazz_sonic_probe()'") Fixes: 74f2a5f0 ("xtensa: Add support for the Sonic Ethernet device for the XT2000 board.") Fixes: efcce839 ("[PATCH] macsonic/jazzsonic network drivers update") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Signed-off-by:
-
Arnd Bergmann authored
Without this, the driver runs into a link failure arm-linux-gnueabi-ld: drivers/net/wan/slic_ds26522.o: in function `slic_ds26522_probe': slic_ds26522.c:(.text+0x100c): undefined reference to `byte_rev_table' arm-linux-gnueabi-ld: slic_ds26522.c:(.text+0x1cdc): undefined reference to `byte_rev_table' arm-linux-gnueabi-ld: drivers/net/wan/slic_ds26522.o: in function `slic_write': slic_ds26522.c:(.text+0x1e4c): undefined reference to `byte_rev_table' Fixes: c37d4a00 ("Maxim/driver: Add driver for maxim ds26522") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
Without this, we run into a link error arm-linux-gnueabi-ld: drivers/isdn/mISDN/dsp_audio.o: in function `dsp_audio_generate_law_tables': (.text+0x30c): undefined reference to `byte_rev_table' arm-linux-gnueabi-ld: drivers/isdn/mISDN/dsp_audio.o:(.text+0x5e4): more undefined references to `byte_rev_table' follow Signed-off-by:
-
Arnd Bergmann authored
Without crc32 support, this fails to link: arm-linux-gnueabi-ld: net/wireless/scan.o: in function `cfg80211_scan_6ghz': scan.c:(.text+0x928): undefined reference to `crc32_le' Fixes: c8cb5b85 ("nl80211/cfg80211: support 6 GHz scanning") Signed-off-by:
-
Arnd Bergmann authored
Without crc32, the driver fails to link: arm-linux-gnueabi-ld: drivers/net/wireless/ath/wil6210/fw.o: in function `wil_fw_verify': fw.c:(.text+0x74c): undefined reference to `crc32_le' arm-linux-gnueabi-ld: drivers/net/wireless/ath/wil6210/fw.o:fw.c:(.text+0x758): more undefined references to `crc32_le' follow Fixes: 151a9706 ("wil6210: firmware download") Signed-off-by:
-
