summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2021-07-25net: qcom/emac: fix UAF in emac_removePavel Skripkin1-1/+2
commit ad297cd2db8953e2202970e9504cab247b6c7cb4 upstream. adpt is netdev private data and it cannot be used after free_netdev() call. Using adpt after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. Fixes: 54e19bc74f33 ("net: qcom/emac: do not use devm on internal phy pdev") Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25net: moxa: fix UAF in moxart_mac_probePavel Skripkin1-3/+1
commit c78eaeebe855fd93f2e77142ffd0404a54070d84 upstream. In case of netdev registration failure the code path will jump to init_fail label: init_fail: netdev_err(ndev, "init failed\n"); moxart_mac_free_memory(ndev); irq_map_fail: free_netdev(ndev); return ret; So, there is no need to call free_netdev() before jumping to error handling path, since it can cause UAF or double-free bug. Fixes: 6c821bd9edc9 ("net: Add MOXA ART SoCs ethernet driver") Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25net: bcmgenet: Ensure all TX/RX queues DMAs are disabledFlorian Fainelli1-0/+6
commit 2b452550a203d88112eaf0ba9fc4b750a000b496 upstream. Make sure that we disable each of the TX and RX queues in the TDMA and RDMA control registers. This is a correctness change to be symmetrical with the code that enables the TX and RX queues. Tested-by: Maxime Ripard <maxime@cerno.tech> Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25net: netdevsim: use xso.real_dev instead of xso.dev in callback functions of ↵Taehee Yoo1-4/+4
struct xfrmdev_ops commit 09adf7566d436322ced595b166dea48b06852efe upstream. There are two pointers in struct xfrm_state_offload, *dev, *real_dev. These are used in callback functions of struct xfrmdev_ops. The *dev points whether bonding interface or real interface. If bonding ipsec offload is used, it points bonding interface If not, it points real interface. And real_dev always points real interface. So, netdevsim should always use real_dev instead of dev. Of course, real_dev always not be null. Test commands: ip netns add A ip netns exec A bash modprobe netdevsim echo "1 1" > /sys/bus/netdevsim/new_device ip link add bond0 type bond mode active-backup ip link set eth0 master bond0 ip link set eth0 up ip link set bond0 up ip x s add proto esp dst 14.1.1.1 src 15.1.1.1 spi 0x07 mode \ transport reqid 0x07 replay-window 32 aead 'rfc4106(gcm(aes))' \ 0x44434241343332312423222114131211f4f3f2f1 128 sel src 14.0.0.52/24 \ dst 14.0.0.70/24 proto tcp offload dev bond0 dir in Splat looks like: BUG: spinlock bad magic on CPU#5, kworker/5:1/53 lock: 0xffff8881068c2cc8, .magic: 11121314, .owner: <none>/-1, .owner_cpu: -235736076 CPU: 5 PID: 53 Comm: kworker/5:1 Not tainted 5.13.0-rc3+ #1168 Workqueue: events linkwatch_event Call Trace: dump_stack+0xa4/0xe5 do_raw_spin_lock+0x20b/0x270 ? rwlock_bug.part.1+0x90/0x90 _raw_spin_lock_nested+0x5f/0x70 bond_get_stats+0xe4/0x4c0 [bonding] ? rcu_read_lock_sched_held+0xc0/0xc0 ? bond_neigh_init+0x2c0/0x2c0 [bonding] ? dev_get_alias+0xe2/0x190 ? dev_get_port_parent_id+0x14a/0x360 ? rtnl_unregister+0x190/0x190 ? dev_get_phys_port_name+0xa0/0xa0 ? memset+0x1f/0x40 ? memcpy+0x38/0x60 ? rtnl_phys_switch_id_fill+0x91/0x100 dev_get_stats+0x8c/0x270 rtnl_fill_stats+0x44/0xbe0 ? nla_put+0xbe/0x140 rtnl_fill_ifinfo+0x1054/0x3ad0 [ ... ] Fixes: 272c2330adc9 ("xfrm: bail early on slave pass over skb") Signed-off-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25vmxnet3: fix cksum offload issues for tunnels with non-default udp portsRonak Doshi1-2/+20
commit b22580233d473dbf7bbfa4f6549c09e2c80e9e64 upstream. Commit dacce2be3312 ("vmxnet3: add geneve and vxlan tunnel offload support") added support for encapsulation offload. However, the inner offload capability is to be restricted to UDP tunnels with default Vxlan and Geneve ports. This patch fixes the issue for tunnels with non-default ports using features check capability and filtering appropriate features for such tunnels. Fixes: dacce2be3312 ("vmxnet3: add geneve and vxlan tunnel offload support") Signed-off-by: Ronak Doshi <doshir@vmware.com> Acked-by: Guolin Yang <gyang@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25net: dsa: mv88e6xxx: enable devlink ATU hash param for TopazMarek Behún1-0/+4
commit c07fff3492acae41cedbabea395b644dd5872b8c upstream. Commit 23e8b470c7788 ("net: dsa: mv88e6xxx: Add devlink param for ATU hash algorithm.") introduced ATU hash algorithm access via devlink, but did not enable it for Topaz. Enable this feature also for Topaz. Signed-off-by: Marek Behún <kabel@kernel.org> Fixes: 23e8b470c7788 ("net: dsa: mv88e6xxx: Add devlink param for ATU hash algorithm.") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25net: dsa: mv88e6xxx: enable .rmu_disable() on TopazMarek Behún1-0/+2
commit 3709488790022c85720f991bff50d48ed5a36e6a upstream. Commit 9e5baf9b36367 ("net: dsa: mv88e6xxx: add RMU disable op") introduced .rmu_disable() method with implementation for several models, but forgot to add Topaz, which can use the Peridot implementation. Use the Peridot implementation of .rmu_disable() on Topaz. Signed-off-by: Marek Behún <kabel@kernel.org> Fixes: 9e5baf9b36367 ("net: dsa: mv88e6xxx: add RMU disable op") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25net: dsa: mv88e6xxx: use correct .stats_set_histogram() on TopazMarek Behún1-2/+2
commit 11527f3c4725640e6c40a2b7654e303f45e82a6c upstream. Commit 40cff8fca9e3 ("net: dsa: mv88e6xxx: Fix stats histogram mode") introduced wrong .stats_set_histogram() method for Topaz family. The Peridot method should be used instead. Signed-off-by: Marek Behún <kabel@kernel.org> Fixes: 40cff8fca9e3 ("net: dsa: mv88e6xxx: Fix stats histogram mode") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25net: dsa: mv88e6xxx: enable .port_set_policy() on TopazMarek Behún1-0/+2
commit 7da467d82d1ed4fb317aff836f99709169e73f10 upstream. Commit f3a2cd326e44 ("net: dsa: mv88e6xxx: introduce .port_set_policy") introduced .port_set_policy() method with implementation for several models, but forgot to add Topaz, which can use the 6352 implementation. Use the 6352 implementation of .port_set_policy() on Topaz. Signed-off-by: Marek Behún <kabel@kernel.org> Fixes: f3a2cd326e44 ("net: dsa: mv88e6xxx: introduce .port_set_policy") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25net: bcmgenet: ensure EXT_ENERGY_DET_MASK is clearDoug Berger2-21/+2
commit 5a3c680aa2c12c90c44af383fe6882a39875ab81 upstream. Setting the EXT_ENERGY_DET_MASK bit allows the port energy detection logic of the internal PHY to prevent the system from sleeping. Some internal PHYs will report that energy is detected when the network interface is closed which can prevent the system from going to sleep if WoL is enabled when the interface is brought down. Since the driver does not support waking the system on this logic, this commit clears the bit whenever the internal PHY is powered up and the other logic for manipulating the bit is removed since it serves no useful function. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger <opendmb@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-20virtio_net: move tx vq operation under tx queue lockMichael S. Tsirkin1-1/+21
[ Upstream commit 5a2f966d0f3fa0ef6dada7ab9eda74cacee96b8a ] It's unsafe to operate a vq from multiple threads. Unfortunately this is exactly what we do when invoking clean tx poll from rx napi. Same happens with napi-tx even without the opportunistic cleaning from the receive interrupt: that races with processing the vq in start_xmit. As a fix move everything that deals with the vq to under tx lock. Fixes: b92f1e6751a6 ("virtio-net: transmit napi") Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20virtio_net: Fix error handling in virtnet_restore()Xie Yongji1-1/+4
[ Upstream commit 3f2869cace829fb4b80fc53b3ddaa7f4ba9acbf1 ] Do some cleanups in virtnet_restore() when virtnet_cpu_notif_add() failed. Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Link: https://lore.kernel.org/r/20210517084516.332-1-xieyongji@bytedance.com Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19i40e: fix PTP on 5Gb linksJesse Brandeburg1-2/+6
commit 26b0ce8dd3dd704393dbace4dc416adfeffe531f upstream. As reported by Alex Sergeev, the i40e driver is incrementing the PTP clock at 40Gb speeds when linked at 5Gb. Fix this bug by making sure that the right multiplier is selected when linked at 5Gb. Fixes: 3dbdd6c2f70a ("i40e: Add support for 5Gbps cards") Cc: stable@vger.kernel.org Reported-by: Alex Sergeev <asergeev@carbonrobotics.com> Suggested-by: Alex Sergeev <asergeev@carbonrobotics.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-19ath11k: unlock on error path in ath11k_mac_op_add_interface()Dan Carpenter1-2/+2
commit 59ec8e2fa5aaed6afd18d5362dc131aab92406e7 upstream. These error paths need to drop the &ar->conf_mutex before returning. Fixes: 690ace20ff79 ("ath11k: peer delete synchronization with firmware") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/X85sVGVP/0XvlrEJ@mwanda Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-19mac80211_hwsim: add concurrent channels scanning support over virtioWeilun Du1-10/+38
[ Upstream commit 626c30f9e77354301ff9162c3bdddaf92d9b5cf3 ] This fixed the crash when setting channels to 2 or more when communicating over virtio. Signed-off-by: Weilun Du <wdu@google.com> Link: https://lore.kernel.org/r/20210506180530.3418576-1-wdu@google.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19sfc: error code if SRIOV cannot be disabledÍñigo Huguet1-4/+11
[ Upstream commit 1ebe4feb8b442884f5a28d2437040096723dd1ea ] If SRIOV cannot be disabled during device removal or module unloading, return error code so it can be logged properly in the calling function. Note that this can only happen if any VF is currently attached to a guest using Xen, but not with vfio/KVM. Despite that in that case the VFs won't work properly with PF removed and/or the module unloaded, I have let it as is because I don't know what side effects may have changing it, and also it seems to be the same that other drivers are doing in this situation. In the case of being called during SRIOV reconfiguration, the behavior hasn't changed because the function is called with force=false. Signed-off-by: Íñigo Huguet <ihuguet@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19sfc: avoid double pci_remove of VFsÍñigo Huguet1-9/+1
[ Upstream commit 45423cff1db66cf0993e8a9bd0ac93e740149e49 ] If pci_remove was called for a PF with VFs, the removal of the VFs was called twice from efx_ef10_sriov_fini: one directly with pci_driver->remove and another implicit by calling pci_disable_sriov, which also perform the VFs remove. This was leading to crashing the kernel on the second attempt. Given that pci_disable_sriov already calls to pci remove function, get rid of the direct call to pci_driver->remove from the driver. 2 different ways to trigger the bug: - Create one or more VFs, then attach the PF to a virtual machine (at least with qemu/KVM) - Create one or more VFs, then remove the PF with: echo 1 > /sys/bus/pci/devices/PF_PCI_ID/remove Removing sfc module does not trigger the error, at least for me, because it removes the VF first, and then the PF. Example of a log with the error: list_del corruption, ffff967fd20a8ad0->next is LIST_POISON1 (dead000000000100) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:47! [...trimmed...] RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x4c [...trimmed...] Call Trace: efx_dissociate+0x1f/0x140 [sfc] efx_pci_remove+0x27/0x150 [sfc] pci_device_remove+0x3b/0xc0 device_release_driver_internal+0x103/0x1f0 pci_stop_bus_device+0x69/0x90 pci_stop_and_remove_bus_device+0xe/0x20 pci_iov_remove_virtfn+0xba/0x120 sriov_disable+0x2f/0xe0 efx_ef10_pci_sriov_disable+0x52/0x80 [sfc] ? pcie_aer_is_native+0x12/0x40 efx_ef10_sriov_fini+0x72/0x110 [sfc] efx_pci_remove+0x62/0x150 [sfc] pci_device_remove+0x3b/0xc0 device_release_driver_internal+0x103/0x1f0 unbind_store+0xf6/0x130 kernfs_fop_write+0x116/0x190 vfs_write+0xa5/0x1a0 ksys_write+0x4f/0xb0 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca Signed-off-by: Íñigo Huguet <ihuguet@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19iwlwifi: pcie: fix context info freeingJohannes Berg1-1/+2
[ Upstream commit 26d18c75a7496c4c52b0b6789e713dc76ebfbc87 ] After firmware alive, iwl_trans_pcie_gen2_fw_alive() is called to free the context info. However, on gen3 that will then free the context info with the wrong size. Since we free this allocation later, let it stick around until the device is stopped for now, freeing some of it earlier is a separate change. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618105614.afb63fb8cbc1.If4968db8e09f4ce2a1d27a6d750bca3d132d7d70@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19iwlwifi: pcie: free IML DMA memory allocationJohannes Berg2-5/+13
[ Upstream commit 310f60f53a86eba680d9bc20a371e13b06a5f903 ] In the case of gen3 devices with image loader (IML) support, we were leaking the IML DMA allocation and never freeing it. Fix that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618105614.07e117dbedb7.I7bb9ebbe0617656986c2a598ea5e827b533bd3b9@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19iwlwifi: mvm: fix error print when session protection endsShaul Triebitz1-0/+4
[ Upstream commit 976ac0af7ba2c5424bc305b926c0807d96fdcc83 ] When the session protection ends and the Driver is not associated or a beacon was not heard, the Driver prints "No beacons heard...". That's confusing for the case where not associated. Change the print when not associated to "Not associated...". Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210617100544.41a5a5a894fa.I9eabb76e7a3a7f4abbed8f2ef918f1df8e825726@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19iwlwifi: mvm: don't change band on bound PHY contextsJohannes Berg1-6/+18
[ Upstream commit 8835a64f74c46baebfc946cd5a2c861b866ebcee ] When we have a P2P Device active, we attempt to only change the PHY context it uses when we get a new remain-on-channel, if the P2P Device is the only user of the PHY context. This is fine if we're switching within a band, but if we're switching bands then the switch implies a removal and re-add of the PHY context, which isn't permitted by the firmware while it's bound to an interface. Fix the code to skip the unbind/release/... cycle only if the band doesn't change (or we have old devices that can switch the band on the fly as well.) Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210612142637.e9ac313f70f3.I713b9d109957df7e7d9ed0861d5377ce3f8fccd3@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19net: fec: add ndo_select_queue to fix TX bandwidth fluctuationsFugang Duan1-0/+32
[ Upstream commit 52c4a1a85f4b346c39c896c0168f4a843b3385ff ] As we know that AVB is enabled by default, and the ENET IP design is queue 0 for best effort, queue 1&2 for AVB Class A&B. Bandwidth of each queue 1&2 set in driver is 50%, TX bandwidth fluctuated when selecting tx queues randomly with FEC_QUIRK_HAS_AVB quirk available. This patch adds ndo_select_queue callback to select queues for transmitting to fix this issue. It will always return queue 0 if this is not a vlan packet, and return queue 1 or 2 based on priority of vlan packet. You may complain that in fact we only use single queue for trasmitting if we are not targeted to VLAN. Yes, but seems we have no choice, since AVB is enabled when the driver probed, we can't switch this feature dynamicly. After compare multiple queues to single queue, TX throughput almost no improvement. One way we can implemet is to configure the driver to multiple queues with Round-robin scheme by default. Then add ndo_setup_tc callback to enable/disable AVB feature for users. Unfortunately, ENET AVB IP seems not follow the standard 802.1Qav spec. We only can program DMAnCFG[IDLE_SLOPE] field to calculate bandwidth fraction. And idle slope is restricted to certain valus (a total of 19). It's far away from CBS QDisc implemented in Linux TC framework. If you strongly suggest to do this, I think we only can support limited numbers of bandwidth and reject others, but it's really urgly and wried. With this patch, VLAN tagged packets route to queue 0/1/2 based on vlan priority; VLAN untagged packets route to queue 0. Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> Reported-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19rtl8xxxu: Fix device info for RTL8192EU devicesPascal Terjan2-14/+56
[ Upstream commit c240b044edefa3c3af4014a4030e017dd95b59a1 ] Based on 2001:3319 and 2357:0109 which I used to test the fix and 0bda:818b and 2357:0108 for which I found efuse dumps online. == 2357:0109 == === Before === Vendor: Realtek Product: \x03802.11n NI Serial: === After === Vendor: Realtek Product: 802.11n NIC Serial not available. == 2001:3319 == === Before === Vendor: Realtek Product: Wireless N Serial: no USB Adap === After === Vendor: Realtek Product: Wireless N Nano USB Adapter Serial not available. Signed-off-by: Pascal Terjan <pterjan@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210424172959.1559890-1-pterjan@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19mt76: mt7915: fix IEEE80211_HE_PHY_CAP7_MAX_NC for station modeRyder Lee1-3/+3
[ Upstream commit 2707ff4dd7b1479dbd44ebb3c74788084cc95245 ] The value of station mode is always 0. Fixed: 00b2e16e0063 ("mt76: mt7915: add TxBF capabilities") Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19net: ipa: Add missing of_node_put() in ipa_firmware_load()Yang Yingliang1-0/+1
[ Upstream commit b244163f2c45c12053cb0291c955f892e79ed8a9 ] This node pointer is returned by of_parse_phandle() with refcount incremented in this function. of_node_put() on it before exiting this function. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Acked-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19mt76: mt7615: fix fixed-rate tx status reportingFelix Fietkau1-6/+4
[ Upstream commit ec8f1a90d006f7cedcf86ef19fd034a406a213d6 ] Rely on the txs fixed-rate bit instead of info->control.rates Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19ice: mark PTYPE 2 as reservedJacob Keller1-1/+1
[ Upstream commit 0c526d440f76676733cb470b454db9d5507a3a50 ] The entry for PTYPE 2 in the ice_ptype_lkup table incorrectly states that this is an L2 packet with no payload. According to the datasheet, this PTYPE is actually unused and reserved. Fix the lookup entry to indicate this is an unused entry that is reserved. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19ice: fix incorrect payload indicator on PTYPEJacob Keller1-1/+1
[ Upstream commit 638a0c8c8861cb8a3b54203e632ea5dcc23d8ca5 ] The entry for PTYPE 90 indicates that the payload is layer 3. This does not match the specification in the datasheet which indicates the packet is a MAC, IPv6, UDP packet, with a payload in layer 4. Fix the lookup table to match the data sheet. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19cw1200: add missing MODULE_DEVICE_TABLEZou Wei1-0/+1
[ Upstream commit dd778f89225cd258e8f0fed2b7256124982c8bb5 ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1620788714-14300-1-git-send-email-zou_wei@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19wl1251: Fix possible buffer overflow in wl1251_cmd_scanLee Gibson1-3/+6
[ Upstream commit d10a87a3535cce2b890897914f5d0d83df669c63 ] Function wl1251_cmd_scan calls memcpy without checking the length. Harden by checking the length is within the maximum allowed size. Signed-off-by: Lee Gibson <leegib@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210428115508.25624-1-leegib@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19wlcore/wl12xx: Fix wl12xx get_mac error if device is in ELPTony Lindgren1-0/+7
[ Upstream commit 11ef6bc846dcdce838f0b00c5f6a562c57e5d43b ] At least on wl12xx, reading the MAC after boot can fail with a warning at drivers/net/wireless/ti/wlcore/sdio.c:78 wl12xx_sdio_raw_read. The failed call comes from wl12xx_get_mac() that wlcore_nvs_cb() calls after request_firmware_work_func(). After the error, no wireless interface is created. Reloading the wl12xx module makes the interface work. Turns out the wlan controller can be in a low-power ELP state after the boot from the bootloader or kexec, and needs to be woken up first. Let's wake the hardware and add a sleep after that similar to wl12xx_pre_boot() is already doing. Note that a similar issue could exist for wl18xx, but I have not seen it so far. And a search for wl18xx_get_mac and wl12xx_sdio_raw_read did not produce similar errors. Cc: Carl Philipp Klemm <philipp@uvos.xyz> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210603062814.19464-1-tony@atomide.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19r8169: avoid link-up interrupt issue on RTL8106e if user enables ASPMHeiner Kallweit1-1/+0
[ Upstream commit 1ee8856de82faec9bc8bd0f2308a7f27e30ba207 ] It has been reported that on RTL8106e the link-up interrupt may be significantly delayed if the user enables ASPM L1. Per default ASPM is disabled. The change leaves L1 enabled on the PCIe link (thus still allowing to reach higher package power saving states), but the NIC won't actively trigger it. Reported-by: Koba Ko <koba.ko@canonical.com> Tested-by: Koba Ko <koba.ko@canonical.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19fjes: check return value after calling platform_get_resource()Yang Yingliang1-0/+4
[ Upstream commit f18c11812c949553d2b2481ecaa274dd51bed1e7 ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19net: sgi: ioc3-eth: check return value after calling platform_get_resource()Yang Yingliang1-0/+4
[ Upstream commit db8f7be1e1d64fbf113a456ef94534fbf5e9a9af ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19net: phy: realtek: add delay to fix RXC generation issueJoakim Zhang1-1/+14
[ Upstream commit 6813cc8cfdaf401476e1a007cec8ae338cefa573 ] PHY will delay about 11.5ms to generate RXC clock when switching from power down to normal operation. Read/write registers would also cause RXC become unstable and stop for a while during this process. Realtek engineer suggests 15ms or more delay can workaround this issue. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19net: moxa: Use devm_platform_get_and_ioremap_resource()Yang Yingliang1-3/+2
[ Upstream commit 35cba15a504bf4f585bb9d78f47b22b28a1a06b2 ] Use devm_platform_get_and_ioremap_resource() to simplify code and avoid a null-ptr-deref by checking 'res' in it. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19net: micrel: check return value after calling platform_get_resource()Yang Yingliang1-0/+4
[ Upstream commit 20f1932e2282c58cb5ac59517585206cf5b385ae ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19net: mvpp2: check return value after calling platform_get_resource()Yang Yingliang1-0/+4
[ Upstream commit 0bb51a3a385790a4be20085494cf78f70dadf646 ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19net: bcmgenet: check return value after calling platform_get_resource()Yang Yingliang1-0/+4
[ Upstream commit 74325bf0104573c6dfce42837139aeef3f34be76 ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19net: mscc: ocelot: check return value after calling platform_get_resource()Yang Yingliang1-0/+5
[ Upstream commit f1fe19c2cb3fdc92a614cf330ced1613f8f1a681 ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19virtio_net: Remove BUG() to avoid machine deadXianting Tian1-1/+1
[ Upstream commit 85eb1389458d134bdb75dad502cc026c3753a619 ] We should not directly BUG() when there is hdr error, it is better to output a print when such error happens. Currently, the caller of xmit_skb() already did it. Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19ice: fix clang warning regarding deadcode.DeadStoresPaul M Stillwell Jr1-5/+1
[ Upstream commit 7e94090ae13e1ae5fe8bd3a9cd08136260bb7039 ] clang generates deadcode.DeadStores warnings when a variable is used to read a value, but then that value isn't used later in the code. Fix this warning. Signed-off-by: Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19ice: set the value of global config lock timeout longerLiwei Song1-1/+1
[ Upstream commit fb3612840d4f587a0af9511a11d7989d1fa48206 ] It may need hold Global Config Lock a longer time when download DDP package file, extend the timeout value to 5000ms to ensure that download can be finished before other AQ command got time to run, this will fix the issue below when probe the device, 5000ms is a test value that work with both Backplane and BreakoutCable NVM image: ice 0000:f4:00.0: VSI 12 failed lan queue config, error ICE_ERR_CFG ice 0000:f4:00.0: Failed to delete VSI 12 in FW - error: ICE_ERR_AQ_TIMEOUT ice 0000:f4:00.0: probe failed due to setup PF switch: -12 ice: probe of 0000:f4:00.0 failed with error -12 Signed-off-by: Liwei Song <liwei.song@windriver.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19virtio-net: Add validation for used lengthXie Yongji1-7/+13
[ Upstream commit ad993a95c508417acdeb15244109e009e50d8758 ] This adds validation for used length (might come from an untrusted device) to avoid data corruption or loss. Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Acked-by: Jason Wang <jasowang@redhat.com> Link: https://lore.kernel.org/r/20210531135852.113-1-xieyongji@bytedance.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19net: stmmac: the XPCS obscures a potential "PHY not found" errorVladimir Oltean1-6/+15
[ Upstream commit 4751d2aa321f2828d8c5d2f7ce4ed18a01e47f46 ] stmmac_mdio_register() has logic to search for PHYs on the MDIO bus and assign them IRQ lines, as well as to set priv->plat->phy_addr. If no PHY is found, the "found" variable remains set to 0 and the function errors out. After the introduction of commit f213bbe8a9d6 ("net: stmmac: Integrate it with DesignWare XPCS"), the "found" variable was immediately reused for searching for a PCS on the same MDIO bus. This can result in 2 types of potential problems (none of them seems to be seen on the only Intel system that sets has_xpcs = true, otherwise it would have been reported): 1. If a PCS is found but a PHY is not, then the code happily exits with no error. One might say "yes, but this is not possible, because of_mdiobus_register will probe a PHY for all MDIO addresses, including for the XPCS, so if an XPCS exists, then a PHY certainly exists too". Well, that is not true, see intel_mgbe_common_data(): /* Ensure mdio bus scan skips intel serdes and pcs-xpcs */ plat->mdio_bus_data->phy_mask = 1 << INTEL_MGBE_ADHOC_ADDR; plat->mdio_bus_data->phy_mask |= 1 << INTEL_MGBE_XPCS_ADDR; 2. A PHY is found but an MDIO device with the XPCS PHY ID isn't, and in that case, the error message will be "No PHY found". Confusing. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20210527155959.3270478-1-olteanv@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19net/mlx5: Fix lag port remapping logicEli Cohen1-6/+13
[ Upstream commit 8613641063617c1dfc731b403b3ee4935ef15f87 ] Fix the logic so that if both ports netdevices are enabled or disabled, use the trivial mapping without swapping. If only one of the netdevice's tx is enabled, use it to remap traffic to that port. Signed-off-by: Eli Cohen <elic@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19net/mlx5e: IPsec/rep_tc: Fix rep_tc_update_skb drops IPsec packetHuy Nguyen1-2/+4
[ Upstream commit c07274ab1ab2c38fb128e32643c22c89cb319384 ] rep_tc copy REG_C1 to REG_B. IPsec crypto utilizes the whole REG_B register with BIT31 as IPsec marker. rep_tc_update_skb drops IPsec because it thought REG_B contains bad value. In previous patch, BIT 31 of REG_C1 is reserved for IPsec. Skip the rep_tc_update_skb if BIT31 of REG_B is set. Signed-off-by: Huy Nguyen <huyn@nvidia.com> Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19igb: fix assignment on big endian machinesJesse Brandeburg1-2/+2
[ Upstream commit b514958dd1a3bd57638b0e63b8e5152b1960e6aa ] The igb driver was trying hard to be sparse correct, but somehow ended up converting a variable into little endian order and then tries to OR something with it. A much plainer way of doing things is to leave all variables and OR operations in CPU (non-endian) mode, and then convert to little endian only once, which is what this change does. This probably fixes a bug that might have been seen only on big endian systems. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Dave Switzer <david.switzer@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19igb: handle vlan types with checker enabledJesse Brandeburg2-4/+5
[ Upstream commit c7cbfb028b95360403d579c47aaaeef1ff140964 ] The sparse build (C=2) finds some issues with how the driver dealt with the (very difficult) hardware that in some generations uses little-endian, and in others uses big endian, for the VLAN field. The code as written picks __le16 as a type and for some hardware revisions we override it to __be16 as done in this patch. This impacted the VF driver as well so fix it there too. Also change the vlan_tci assignment to override the sparse warning without changing functionality. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Dave Switzer <david.switzer@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19e100: handle eeprom as little endianJesse Brandeburg1-6/+6
[ Upstream commit d4ef55288aa2e1b76033717242728ac98ddc4721 ] Sparse tool was warning on some implicit conversions from little endian data read from the EEPROM on the e100 cards. Fix these by being explicit about the conversions using le16_to_cpu(). Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-26 19:23:58 +0000