summaryrefslogtreecommitdiffstats
path: root/drivers (follow)
Commit message (Collapse)AuthorAgeFilesLines
* net: usb: qmi_wwan: add Telit 0x1080 compositionEnrico Sau2023-03-071-0/+1
| | | | | | | | | | Add the following Telit FE990 composition: 0x1080: tty, adb, rmnet, tty, tty, tty, tty Signed-off-by: Enrico Sau <enrico.sau@gmail.com> Link: https://lore.kernel.org/r/20230306120528.198842-1-enrico.sau@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: usb: cdc_mbim: avoid altsetting toggling for Telit FE990Enrico Sau2023-03-071-0/+5
| | | | | | | | | Add quirk CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE for Telit FE990 0x1081 composition in order to avoid bind error. Signed-off-by: Enrico Sau <enrico.sau@gmail.com> Link: https://lore.kernel.org/r/20230306115933.198259-1-enrico.sau@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: ethernet: mtk_eth_soc: fix RX data corruption issueDaniel Golle2023-03-062-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fix data corruption issue with SerDes connected PHYs operating at 1.25 Gbps speed where we could previously observe about 30% packet loss while the bad packet counter was increasing. As almost all boards with MediaTek MT7622 or MT7986 use either the MT7531 switch IC operating at 3.125Gbps SerDes rate or single-port PHYs using rate-adaptation to 2500Base-X mode, this issue only got exposed now when we started trying to use SFP modules operating with 1.25 Gbps with the BananaPi R3 board. The fix is to set bit 12 which disables the RX FIFO clear function when setting up MAC MCR, MediaTek SDK did the same change stating: "If without this patch, kernel might receive invalid packets that are corrupted by GMAC."[1] [1]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/d8a2975939a12686c4a95c40db21efdc3f821f63 Fixes: 42c03844e93d ("net-next: mediatek: add support for MediaTek MT7622 SoC") Tested-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/138da2735f92c8b6f8578ec2e5a794ee515b665f.1677937317.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: phy: smsc: fix link up detection in forced irq modeHeiner Kallweit2023-03-061-11/+3
| | | | | | | | | | | Currently link up can't be detected in forced mode if polling isn't used. Only link up interrupt source we have is aneg complete which isn't applicable in forced mode. Therefore we have to use energy-on as link up indicator. Fixes: 7365494550f6 ("net: phy: smsc: skip ENERGYON interrupt if disabled") Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bnxt_en: Fix the double free during device removalSelvin Xavier2023-03-062-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Following warning reported by KASAN during driver unload ================================================================== BUG: KASAN: double-free in bnxt_remove_one+0x103/0x200 [bnxt_en] Free of addr ffff88814e8dd4c0 by task rmmod/17469 CPU: 47 PID: 17469 Comm: rmmod Kdump: loaded Tainted: G S 6.2.0-rc7+ #2 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.3.10 08/15/2019 Call Trace: <TASK> dump_stack_lvl+0x33/0x46 print_report+0x17b/0x4b3 ? __call_rcu_common.constprop.79+0x27e/0x8c0 ? __pfx_free_object_rcu+0x10/0x10 ? __virt_addr_valid+0xe3/0x160 ? bnxt_remove_one+0x103/0x200 [bnxt_en] kasan_report_invalid_free+0x64/0xd0 ? bnxt_remove_one+0x103/0x200 [bnxt_en] ? bnxt_remove_one+0x103/0x200 [bnxt_en] __kasan_slab_free+0x179/0x1c0 ? bnxt_remove_one+0x103/0x200 [bnxt_en] __kmem_cache_free+0x194/0x350 bnxt_remove_one+0x103/0x200 [bnxt_en] pci_device_remove+0x62/0x110 device_release_driver_internal+0xf6/0x1c0 driver_detach+0x76/0xe0 bus_remove_driver+0x89/0x160 pci_unregister_driver+0x26/0x110 ? strncpy_from_user+0x188/0x1c0 bnxt_exit+0xc/0x24 [bnxt_en] __x64_sys_delete_module+0x21f/0x390 ? __pfx___x64_sys_delete_module+0x10/0x10 ? __pfx_mem_cgroup_handle_over_high+0x10/0x10 ? _raw_spin_lock+0x87/0xe0 ? __pfx__raw_spin_lock+0x10/0x10 ? __audit_syscall_entry+0x185/0x210 ? ktime_get_coarse_real_ts64+0x51/0x80 ? syscall_trace_enter.isra.18+0x126/0x1a0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7effcb6fd71b Code: 73 01 c3 48 8b 0d 6d 17 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 17 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffeada270b8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 00005623660e0750 RCX: 00007effcb6fd71b RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005623660e07b8 RBP: 0000000000000000 R08: 00007ffeada26031 R09: 0000000000000000 R10: 00007effcb771280 R11: 0000000000000206 R12: 00007ffeada272e0 R13: 00007ffeada28bc4 R14: 00005623660e02a0 R15: 00005623660e0750 </TASK> Auxiliary device structures are freed in bnxt_aux_dev_release. So avoid calling kfree from bnxt_remove_one. Also, set bp->edev to NULL before freeing the auxilary private structure. Fixes: d80d88b0dfff ("bnxt_en: Add auxiliary driver support") Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com> Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bnxt_en: Avoid order-5 memory allocation for TPA dataMichael Chan2023-03-061-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver needs to keep track of all the possible concurrent TPA (GRO/LRO) completions on the aggregation ring. On P5 chips, the maximum number of concurrent TPA is 256 and the amount of memory we allocate is order-5 on systems using 4K pages. Memory allocation failure has been reported: NetworkManager: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0-1 CPU: 15 PID: 2995 Comm: NetworkManager Kdump: loaded Not tainted 5.10.156 #1 Hardware name: Dell Inc. PowerEdge R660/0M1CC5, BIOS 0.2.25 08/12/2022 Call Trace: dump_stack+0x57/0x6e warn_alloc.cold.120+0x7b/0xdd ? _cond_resched+0x15/0x30 ? __alloc_pages_direct_compact+0x15f/0x170 __alloc_pages_slowpath.constprop.108+0xc58/0xc70 __alloc_pages_nodemask+0x2d0/0x300 kmalloc_order+0x24/0xe0 kmalloc_order_trace+0x19/0x80 bnxt_alloc_mem+0x1150/0x15c0 [bnxt_en] ? bnxt_get_func_stat_ctxs+0x13/0x60 [bnxt_en] __bnxt_open_nic+0x12e/0x780 [bnxt_en] bnxt_open+0x10b/0x240 [bnxt_en] __dev_open+0xe9/0x180 __dev_change_flags+0x1af/0x220 dev_change_flags+0x21/0x60 do_setlink+0x35c/0x1100 Instead of allocating this big chunk of memory and dividing it up for the concurrent TPA instances, allocate each small chunk separately for each TPA instance. This will reduce it to order-0 allocations. Fixes: 79632e9ba386 ("bnxt_en: Expand bnxt_tpa_info struct to support 57500 chips.") Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: phylib: get rid of unnecessary lockingRussell King (Oracle)2023-03-061-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The locking in phy_probe() and phy_remove() does very little to prevent any races with e.g. phy_attach_direct(), but instead causes lockdep ABBA warnings. Remove it. ====================================================== WARNING: possible circular locking dependency detected 6.2.0-dirty #1108 Tainted: G W E ------------------------------------------------------ ip/415 is trying to acquire lock: ffff5c268f81ef50 (&dev->lock){+.+.}-{3:3}, at: phy_attach_direct+0x17c/0x3a0 [libphy] but task is already holding lock: ffffaef6496cb518 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x154/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (rtnl_mutex){+.+.}-{3:3}: __lock_acquire+0x35c/0x6c0 lock_acquire.part.0+0xcc/0x220 lock_acquire+0x68/0x84 __mutex_lock+0x8c/0x414 mutex_lock_nested+0x34/0x40 rtnl_lock+0x24/0x30 sfp_bus_add_upstream+0x34/0x150 phy_sfp_probe+0x4c/0x94 [libphy] mv3310_probe+0x148/0x184 [marvell10g] phy_probe+0x8c/0x200 [libphy] call_driver_probe+0xbc/0x15c really_probe+0xc0/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120 __device_attach_driver+0xc4/0x160 bus_for_each_drv+0x80/0xe0 __device_attach+0xb0/0x1f0 device_initial_probe+0x1c/0x2c bus_probe_device+0xa4/0xb0 device_add+0x360/0x53c phy_device_register+0x60/0xa4 [libphy] fwnode_mdiobus_phy_device_register+0xc0/0x190 [fwnode_mdio] fwnode_mdiobus_register_phy+0x160/0xd80 [fwnode_mdio] of_mdiobus_register+0x140/0x340 [of_mdio] orion_mdio_probe+0x298/0x3c0 [mvmdio] platform_probe+0x70/0xe0 call_driver_probe+0x34/0x15c really_probe+0xc0/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120 __driver_attach+0x104/0x210 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x3c bus_add_driver+0x184/0x240 driver_register+0x80/0x13c __platform_driver_register+0x30/0x3c xt_compat_calc_jump+0x28/0xa4 [x_tables] do_one_initcall+0x50/0x1b0 do_init_module+0x50/0x1fc load_module+0x684/0x744 __do_sys_finit_module+0xc4/0x140 __arm64_sys_finit_module+0x28/0x34 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x6c/0x1b0 do_el0_svc+0x34/0x44 el0_svc+0x48/0xf0 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a0/0x1a4 -> #0 (&dev->lock){+.+.}-{3:3}: check_prev_add+0xb4/0xc80 validate_chain+0x414/0x47c __lock_acquire+0x35c/0x6c0 lock_acquire.part.0+0xcc/0x220 lock_acquire+0x68/0x84 __mutex_lock+0x8c/0x414 mutex_lock_nested+0x34/0x40 phy_attach_direct+0x17c/0x3a0 [libphy] phylink_fwnode_phy_connect.part.0+0x70/0xe4 [phylink] phylink_fwnode_phy_connect+0x48/0x60 [phylink] mvpp2_open+0xec/0x2e0 [mvpp2] __dev_open+0x104/0x214 __dev_change_flags+0x1d4/0x254 dev_change_flags+0x2c/0x7c do_setlink+0x254/0xa50 __rtnl_newlink+0x430/0x514 rtnl_newlink+0x58/0x8c rtnetlink_rcv_msg+0x17c/0x560 netlink_rcv_skb+0x64/0x150 rtnetlink_rcv+0x20/0x30 netlink_unicast+0x1d4/0x2b4 netlink_sendmsg+0x1a4/0x400 ____sys_sendmsg+0x228/0x290 ___sys_sendmsg+0x88/0xec __sys_sendmsg+0x70/0xd0 __arm64_sys_sendmsg+0x2c/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x6c/0x1b0 do_el0_svc+0x34/0x44 el0_svc+0x48/0xf0 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a0/0x1a4 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rtnl_mutex); lock(&dev->lock); lock(rtnl_mutex); lock(&dev->lock); *** DEADLOCK *** Fixes: 298e54fa810e ("net: phy: add core phylib sfp support") Reported-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: stmmac: add to set device wake up flag when stmmac init phyRongguang Wei2023-03-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | When MAC is not support PMT, driver will check PHY's WoL capability and set device wakeup capability in stmmac_init_phy(). We can enable the WoL through ethtool, the driver would enable the device wake up flag. Now the device_may_wakeup() return true. But if there is a way which enable the PHY's WoL capability derectly, like in BIOS. The driver would not know the enable thing and would not set the device wake up flag. The phy_suspend may failed like this: [ 32.409063] PM: dpm_run_callback(): mdio_bus_phy_suspend+0x0/0x50 returns -16 [ 32.409065] PM: Device stmmac-1:00 failed to suspend: error -16 [ 32.409067] PM: Some devices failed to suspend, or early wake event detected Add to set the device wakeup enable flag according to the get_wol function result in PHY can fix the error in this scene. v2: add a Fixes tag. Fixes: 1d8e5b0f3f2c ("net: stmmac: Support WOL with phy") Signed-off-by: Rongguang Wei <weirongguang@kylinos.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
* nfp: fix esp-tx-csum-offload doesn't take effectHuanhuan Wang2023-03-031-0/+4
| | | | | | | | | | | When esp-tx-csum-offload is set to on, the protocol stack shouldn't calculate the IPsec offload packet's csum, but it does. Because the callback `.ndo_features_check` incorrectly masked NETIF_F_CSUM_MASK bit. Fixes: 57f273adbcd4 ("nfp: add framework to support ipsec offloading") Signed-off-by: Huanhuan Wang <huanhuan.wang@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* nfp: fix incorrectly set csum flag for nfdk pathHuanhuan Wang2023-03-032-4/+10
| | | | | | | | | | | | | | The csum flag of IPsec packet are set repeatedly. Therefore, the csum flag set of IPsec and non-IPsec packet need to be distinguished. As the ipv6 header does not have a csum field, so l3-csum flag is not required to be set for ipv6 case. Fixes: 436396f26d50 ("nfp: support IPsec offloading for NFP3800") Signed-off-by: Huanhuan Wang <huanhuan.wang@corigine.com> Reviewed-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* nfp: fix incorrectly set csum flag for nfd3 pathHuanhuan Wang2023-03-032-5/+27
| | | | | | | | | | | | | | | | | | The csum flag of IPsec packet are set repeatedly. Therefore, the csum flag set of IPsec and non-IPsec packet need to be distinguished. As the ipv6 header does not have a csum field, so l3-csum flag is not required to be set for ipv6 case. L4-csum flag include the tcp csum flag and udp csum flag, we shouldn't set the udp and tcp csum flag at the same time for one packet, should set l4-csum flag according to the transport layer is tcp or udp. Fixes: 57f273adbcd4 ("nfp: add framework to support ipsec offloading") Signed-off-by: Huanhuan Wang <huanhuan.wang@corigine.com> Reviewed-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* ice: copy last block omitted in ice_get_module_eeprom()Petr Oros2023-03-031-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ice_get_module_eeprom() is broken since commit e9c9692c8a81 ("ice: Reimplement module reads used by ethtool") In this refactor, ice_get_module_eeprom() reads the eeprom in blocks of size 8. But the condition that should protect the buffer overflow ignores the last block. The last block always contains zeros. Bug uncovered by ethtool upstream commit 9538f384b535 ("netlink: eeprom: Defer page requests to individual parsers") After this commit, ethtool reads a block with length = 1; to read the SFF-8024 identifier value. unpatched driver: $ ethtool -m enp65s0f0np0 offset 0x90 length 8 Offset Values ------ ------ 0x0090: 00 00 00 00 00 00 00 00 $ ethtool -m enp65s0f0np0 offset 0x90 length 12 Offset Values ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c 00 00 00 00 $ $ ethtool -m enp65s0f0np0 Offset Values ------ ------ 0x0000: 11 06 06 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 08 00 0x0070: 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 patched driver: $ ethtool -m enp65s0f0np0 offset 0x90 length 8 Offset Values ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c $ ethtool -m enp65s0f0np0 offset 0x90 length 12 Offset Values ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c 61 6e 6f 78 $ ethtool -m enp65s0f0np0 Identifier : 0x11 (QSFP28) Extended identifier : 0x00 Extended identifier description : 1.5W max. Power consumption Extended identifier description : No CDR in TX, No CDR in RX Extended identifier description : High Power Class (> 3.5 W) not enabled Connector : 0x23 (No separable connector) Transceiver codes : 0x88 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Transceiver type : 40G Ethernet: 40G Base-CR4 Transceiver type : 25G Ethernet: 25G Base-CR CA-N Encoding : 0x05 (64B/66B) BR, Nominal : 25500Mbps Rate identifier : 0x00 Length (SMF,km) : 0km Length (OM3 50um) : 0m Length (OM2 50um) : 0m Length (OM1 62.5um) : 0m Length (Copper or Active cable) : 1m Transmitter technology : 0xa0 (Copper cable unequalized) Attenuation at 2.5GHz : 4db Attenuation at 5.0GHz : 5db Attenuation at 7.0GHz : 7db Attenuation at 12.9GHz : 10db ........ .... Fixes: e9c9692c8a81 ("ice: Reimplement module reads used by ethtool") Signed-off-by: Petr Oros <poros@redhat.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge tag 'ieee802154-for-net-2023-03-02' of ↵Jakub Kicinski2023-03-031-0/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan Stefan Schmidt says: ==================== ieee802154 for net 2023-03-02 Two small fixes this time. Alexander Aring fixed a potential negative array access in the ca8210 driver. Miquel Raynal fixed a crash that could have been triggered through the extended netlink API for 802154. This only came in this merge window. Found by syzkaller. * tag 'ieee802154-for-net-2023-03-02' of git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan: ieee802154: Prevent user from crashing the host ca8210: fix mac_len negative array access ==================== Link: https://lore.kernel.org/r/20230302153032.1312755-1-stefan@datenfreihafen.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * ca8210: fix mac_len negative array accessAlexander Aring2023-03-021-0/+2
| | | | | | | | | | | | | | | | | | | | This patch fixes a buffer overflow access of skb->data if ieee802154_hdr_peek_addrs() fails. Reported-by: lianhui tang <bluetlh@gmail.com> Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20230217042504.3303396-1-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
* | net: lan78xx: fix accessing the LAN7800's internal phy specific registers ↵Yuiko Oshino2023-03-032-26/+33
|/ | | | | | | | | | | | | | | | | | | | | | | from the MAC driver Move the LAN7800 internal phy (phy ID 0x0007c132) specific register accesses to the phy driver (microchip.c). Fix the error reported by Enguerrand de Ribaucourt in December 2022, "Some operations during the cable switch workaround modify the register LAN88XX_INT_MASK of the PHY. However, this register is specific to the LAN8835 PHY. For instance, if a DP8322I PHY is connected to the LAN7801, that register (0x19), corresponds to the LED and MAC address configuration, resulting in unapropriate behavior." I did not test with the DP8322I PHY, but I tested with an EVB-LAN7800 with the internal PHY. Fixes: 14437e3fa284 ("lan78xx: workaround of forced 100 Full/Half duplex mode error") Signed-off-by: Yuiko Oshino <yuiko.oshino@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230301154307.30438-1-yuiko.oshino@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: lan966x: Fix port police support using tc-matchallHoratiu Vultur2023-03-011-1/+1
| | | | | | | | | | | | | | | | | | When the police was removed from the port, then it was trying to remove the police from the police id and not from the actual police index. The police id represents the id of the police and police index represents the position in HW where the police is situated. The port police id can be any number while the port police index is a number based on the port chip port. Fix this by deleting the police from HW that is situated at the police index and not police id. Fixes: 5390334b59a3 ("net: lan966x: Add port police support using tc-matchall") Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: phy: unlock on error in phy_probe()Dan Carpenter2023-02-281-1/+1
| | | | | | | | | | | If genphy_c45_read_eee_adv() fails then we need to do a reset and unlock the &phydev->lock mutex before returning. Fixes: 3eeca4e199ce ("net: phy: do not force EEE support") Signed-off-by: Dan Carpenter <error27@gmail.com> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/Y/x/6kHCjnQHqOpF@kili Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* nfc: fdp: add null check of devm_kmalloc_array in ↵Kang Chen2023-02-281-0/+4
| | | | | | | | | | | | | | fdp_nci_i2c_read_device_properties devm_kmalloc_array may fails, *fw_vsc_cfg might be null and cause out-of-bounds write in device_property_read_u8_array later. Fixes: a06347c04c13 ("NFC: Add Intel Fields Peak NFC solution driver") Signed-off-by: Kang Chen <void0red@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230227093037.907654-1-void0red@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* bgmac: fix *initial* chip reset to support BCM5358Rafał Miłecki2023-02-282-2/+8
| | | | | | | | | | | | | | | | | | | | | | | While bringing hardware up we should perform a full reset including the switch bit (BGMAC_BCMA_IOCTL_SW_RESET aka SICF_SWRST). It's what specification says and what reference driver does. This seems to be critical for the BCM5358. Without this hardware doesn't get initialized properly and doesn't seem to transmit or receive any packets. Originally bgmac was calling bgmac_chip_reset() before setting "has_robosw" property which resulted in expected behaviour. That has changed as a side effect of adding platform device support which regressed BCM5358 support. Fixes: f6a95a24957a ("net: ethernet: bgmac: Add platform device support") Cc: Jon Mason <jdmason@kudzu.us> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230227091156.19509-1-zajec5@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* Merge tag 'net-6.3-rc1' of ↵Linus Torvalds2023-02-2734-168/+234
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from wireless and netfilter. The notable fixes here are the EEE fix which restores boot for many embedded platforms (real and QEMU); WiFi warning suppression and the ICE Kconfig cleanup. Current release - regressions: - phy: multiple fixes for EEE rework - wifi: wext: warn about usage only once - wifi: ath11k: allow system suspend to survive ath11k Current release - new code bugs: - mlx5: Fix memory leak in IPsec RoCE creation - ibmvnic: assign XPS map to correct queue index Previous releases - regressions: - netfilter: ip6t_rpfilter: Fix regression with VRF interfaces - netfilter: ctnetlink: make event listener tracking global - nf_tables: allow to fetch set elements when table has an owner - mlx5: - fix skb leak while fifo resync and push - fix possible ptp queue fifo use-after-free Previous releases - always broken: - sched: fix action bind logic - ptp: vclock: use mutex to fix "sleep on atomic" bug if driver also uses a mutex - netfilter: conntrack: fix rmmod double-free race - netfilter: xt_length: use skb len to match in length_mt6, avoid issues with BIG TCP Misc: - ice: remove unnecessary CONFIG_ICE_GNSS - mlx5e: remove hairpin write debugfs files - sched: act_api: move TCA_EXT_WARN_MSG to the correct hierarchy" * tag 'net-6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (53 commits) tcp: tcp_check_req() can be called from process context net: phy: c45: fix network interface initialization failures on xtensa, arm:cubieboard xen-netback: remove unused variables pending_idx and index net/sched: act_api: move TCA_EXT_WARN_MSG to the correct hierarchy net: dsa: ocelot_ext: remove unnecessary phylink.h include net: mscc: ocelot: fix duplicate driver name error net: dsa: felix: fix internal MDIO controller resource length net: dsa: seville: ignore mscc-miim read errors from Lynx PCS net/sched: act_sample: fix action bind logic net/sched: act_mpls: fix action bind logic net/sched: act_pedit: fix action bind logic wifi: wext: warn about usage only once wifi: mt76: usb: fix use-after-free in mt76u_free_rx_queue qede: avoid uninitialized entries in coal_entry array nfc: fix memory leak of se_io context in nfc_genl_se_io ice: remove unnecessary CONFIG_ICE_GNSS net/sched: cls_api: Move call to tcf_exts_miss_cookie_base_destroy() ibmvnic: Assign XPS map to correct queue index docs: net: fix inaccuracies in msg_zerocopy.rst tools: net: add __pycache__ to gitignore ...
| * net: phy: c45: fix network interface initialization failures on xtensa, ↵Oleksij Rempel2023-02-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arm:cubieboard Without proper initialization, "changed" returned random numbers and caused interface initialization failures. Fixes: 022c3f87f88e ("net: phy: add genphy_c45_ethtool_get/set_eee() support") Reported-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230225071644.2754893-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * xen-netback: remove unused variables pending_idx and indexTom Rix2023-02-271-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | building with gcc and W=1 reports drivers/net/xen-netback/netback.c:886:21: error: variable ‘pending_idx’ set but not used [-Werror=unused-but-set-variable] 886 | u16 pending_idx; | ^~~~~~~~~~~ pending_idx is not used so remove it. Since index was only used to set pending_idx, remove index as well. Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20230226163429.2351600-1-trix@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * Merge tag 'wireless-2023-02-27' of ↵Jakub Kicinski2023-02-272-1/+2
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Kalle Valo says: ==================== wireless fixes for v6.3 First set of fixes for v6.3. We have only three oneliners. The most important one is the patch reducing warnings about the Wireless Extensions usage, reported by Linus. * tag 'wireless-2023-02-27' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: wext: warn about usage only once wifi: mt76: usb: fix use-after-free in mt76u_free_rx_queue wifi: ath11k: allow system suspend to survive ath11k ==================== Link: https://lore.kernel.org/r/20230227131053.BD779C433D2@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| | * wifi: mt76: usb: fix use-after-free in mt76u_free_rx_queueLorenzo Bianconi2023-02-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following use-after-free issue in mt76u_free_rx_queue routine: usb 3-3.3.4: reset high-speed USB device number 8 using xhci_hcd iwlwifi 0000:05:00.0: Detected RF HR B3, rfid=0x10a100 iwlwifi 0000:05:00.0: base HW address: 50:eb:71:79:02:57 iwlwifi 0000:05:00.0 wlp5s0: renamed from wlan0 mt76x2u 3-3.3.4:1.0: ASIC revision: 76320044 usb 3-3.3.1: 1:3 : unsupported format bits 0x100000000 mt76x2u 3-3.3.4:1.0: could not get hardware semaphore for ROM PATCH ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 13 PID: 983 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 Modules linked in: snd_seq_midi snd_seq_midi_event mt76x2u(+) mt76x2_common mt76x02_usb mt76_usb iwlmvm mt76x02_lib mt76 snd_hda_codec_realtek intel_rapl_msr snd_hda_codec_generic snd_hda_codec_hdmi intel_rapl_common snd_hda_intel mac80211 snd_intel_dspcfg snd_usb_audio(+) snd_intel_sdw_acpi btusb edac_mce_amd snd_hda_codec btrtl btbcm snd_usbmidi_lib snd_hda_core btintel snd_rawmidi btmtk snd_hwdep libarc4 mc iwlwifi kvm_amd snd_seq vfat bluetooth eeepc_wmi asus_ec_sensors snd_seq_device fat kvm cfg80211 asus_wmi snd_pcm irqbypass ledtrig_audio sparse_keymap rapl wmi_bmof platform_profile xpad snd_timer k10temp ff_memless i2c_piix4 rfkill snd joydev soundcore acpi_cpufreq loop zram amdgpu crct10dif_pclmul crc32_pclmul crc32c_intel polyval_clmulni polyval_generic drm_ttm_helper ttm video iommu_v2 ucsi_ccg drm_buddy gpu_sched typec_ucsi ghash_clmulni_intel drm_display_helper igb sha512_ssse3 typec ccp nvme cec sp5100_tco nvme_core dca nvme_common wmi ip6_tables ip_tables fuse BTRFS info (device nvme1n1): enabling ssd optimizations CPU: 13 PID: 983 Comm: (udev-worker) Tainted: G W L ------- --- 6.3.0-0.rc0.20230222git5b7c4cabbb65.3.fc39.x86_64+debug BTRFS info (device nvme1n1): auto enabling async discard Hardware name: System manufacturer System Product Name/ROG STRIX X570-I GAMING, BIOS 4601 02/02/2023 RIP: 0010:refcount_warn_saturate+0xba/0x110 Code: 01 01 e8 69 a6 83 ff 0f 0b e9 52 f4 85 00 80 3d 69 6f ec 01 00 75 85 48 c7 c7 d0 25 b3 a9 c6 05 59 6f ec 01 01 e8 46 a6 83 ff <0f> 0b e9 2f f4 85 00 80 3d 47 6f ec 01 00 0f 85 5e ff ff ff 48 c7 RSP: 0018:ffffb4010456fb78 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000080000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: ffffffffa9b17e3e RDI: 00000000ffffffff RBP: ffff8d15877336c0 R08: 0000000000000000 R09: ffffb4010456fa00 R10: 0000000000000003 R11: ffff8d246e2fffe8 R12: 0000000000000080 R13: ffff8d15b42fd000 R14: 0000000000000000 R15: ffff8d1587736a58 FS: 00007fc05ae34940(0000) GS:ffff8d2425e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d801f1d540 CR3: 000000011df60000 CR4: 0000000000350ee0 Call Trace: <TASK> mt76u_queues_deinit+0x2a0/0x370 [mt76_usb] mt76x2u_probe+0xf3/0x130 [mt76x2u] usb_probe_interface+0xe8/0x300 really_probe+0x1b6/0x410 __driver_probe_device+0x78/0x170 driver_probe_device+0x1f/0x90 __driver_attach+0xd2/0x1c0 ? __pfx___driver_attach+0x10/0x10 bus_for_each_dev+0x8a/0xd0 bus_add_driver+0x141/0x230 driver_register+0x77/0x120 usb_register_driver+0xaf/0x170 ? __pfx_init_module+0x10/0x10 [mt76x2u] do_one_initcall+0x6e/0x350 do_init_module+0x4a/0x220 __do_sys_init_module+0x192/0x1c0 ? lock_is_held_type+0xce/0x120 do_syscall_64+0x5b/0x80 ? lock_is_held_type+0xce/0x120 ? asm_exc_page_fault+0x22/0x30 ? lockdep_hardirqs_on+0x7d/0x100 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7fc05b1351be Code: 48 8b 0d 4d 0c 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1a 0c 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd947c0988 EFLAGS: 00000246 ORIG_RAX: 00000000000000af RAX: ffffffffffffffda RBX: 000055d801f2b090 RCX: 00007fc05b1351be RDX: 00007fc05b65c07d RSI: 00000000000234be RDI: 000055d802c6b170 RBP: 00007ffd947c0a40 R08: 000055d8019b4690 R09: 0000000000022000 R10: 000000055d8019b4 R11: 0000000000000246 R12: 00007fc05b65c07d R13: 0000000000020000 R14: 000055d801f39770 R15: 000055d801f47780 </TASK> irq event stamp: 186313 hardirqs last enabled at (186323): [<ffffffffa81c675e>] __up_console_sem+0x5e/0x70 hardirqs last disabled at (186332): [<ffffffffa81c6743>] __up_console_sem+0x43/0x70 softirqs last enabled at (186022): [<ffffffffa811d2f7>] __irq_exit_rcu+0xd7/0x160 softirqs last disabled at (186017): [<ffffffffa811d2f7>] __irq_exit_rcu+0xd7/0x160 ---[ end trace 0000000000000000 ]--- mt76x2u: probe of 3-3.3.4:1.0 failed with error -110 usbcore: registered new interface driver mt76x2u kauditd_printk_skb: 32 callbacks suppressed Fixes: 2f5c3c77fc9b ("wifi: mt76: switch to page_pool allocator") Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/f2398f68011c976510c81e1964975b677e65860e.1677193208.git.lorenzo@kernel.org
| | * wifi: ath11k: allow system suspend to survive ath11kLen Brown2023-02-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When ath11k runs into internal errors upon suspend, it returns an error code to pci_pm_suspend, which aborts the entire system suspend. The driver should not abort system suspend, but should keep its internal errors to itself, and allow the system to suspend. Otherwise, a user can suspend a laptop by closing the lid and sealing it into a case, assuming that is will suspend, rather than heating up and draining the battery when in transit. In practice, the ath11k device seems to have plenty of transient errors, and subsequent suspend cycles after this failure often succeed. https://bugzilla.kernel.org/show_bug.cgi?id=216968 Fixes: d1b0c33850d29 ("ath11k: implement suspend for QCA6390 PCI devices") Signed-off-by: Len Brown <len.brown@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230201183201.14431-1-len.brown@intel.com
| * | net: dsa: ocelot_ext: remove unnecessary phylink.h includeRussell King (Oracle)2023-02-261-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During review of ocelot_ext, it created a private phylink instance that wasn't necessary. This was removed for subsequent postings, but the include file seems to have been left behind. Remove it. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: mscc: ocelot: fix duplicate driver name errorVladimir Oltean2023-02-262-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When compiling a kernel which has both CONFIG_NET_DSA_MSCC_OCELOT_EXT and CONFIG_MSCC_OCELOT_SWITCH enabled, the following error message will be printed: [ 5.266588] Error: Driver 'ocelot-switch' is already registered, aborting... Rename the ocelot_ext.c driver to "ocelot-ext-switch" to avoid the name duplication, and update the mfd_cell entry for its resources. Fixes: 3d7316ac81ac ("net: dsa: ocelot: add external ocelot switch control") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: dsa: felix: fix internal MDIO controller resource lengthVladimir Oltean2023-02-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The blamed commit did not properly convert the resource start/end format into the DEFINE_RES_MEM_NAMED() start/length format, resulting in a resource for vsc9959_imdio_res which is much longer than expected: $ cat /proc/iomem 1f8000000-1f815ffff : pcie@1f0000000 1f8140000-1f815ffff : 0000:00:00.5 1f8148030-1f815006f : imdio vs (correct) $ cat /proc/iomem 1f8000000-1f815ffff : pcie@1f0000000 1f8140000-1f815ffff : 0000:00:00.5 1f8148030-1f814803f : imdio Luckily it's not big enough to exceed the size of the parent resource (pci_resource_end(pdev, VSC9959_IMDIO_PCI_BAR)), and it doesn't overlap with anything else that the Linux driver uses currently, so the larger than expected size isn't a practical problem that I can see. Although it is clearly wrong in the /proc/iomem output. Fixes: 044d447a801f ("net: dsa: felix: use DEFINE_RES_MEM_NAMED for resources") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: dsa: seville: ignore mscc-miim read errors from Lynx PCSVladimir Oltean2023-02-262-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the refactoring in the commit below, vsc9953_mdio_read() was replaced with mscc_miim_read(), which has one extra step: it checks for the MSCC_MIIM_DATA_ERROR bits before returning the result. On T1040RDB, there are 8 QSGMII PCSes belonging to the switch, and they are organized in 2 groups. First group responds to MDIO addresses 4-7 because QSGMIIACR1[MDEV_PORT] is 1, and the second group responds to MDIO addresses 8-11 because QSGMIIBCR1[MDEV_PORT] is 2. I have double checked that these values are correctly set in the SERDES, as well as PCCR1[QSGMA_CFG] and PCCR1[QSGMB_CFG] are both 0b01. mscc_miim_read: phyad 8 reg 0x1 MIIM_DATA 0x2d mscc_miim_read: phyad 8 reg 0x5 MIIM_DATA 0x5801 mscc_miim_read: phyad 8 reg 0x1 MIIM_DATA 0x2d mscc_miim_read: phyad 8 reg 0x5 MIIM_DATA 0x5801 mscc_miim_read: phyad 9 reg 0x1 MIIM_DATA 0x2d mscc_miim_read: phyad 9 reg 0x5 MIIM_DATA 0x5801 mscc_miim_read: phyad 9 reg 0x1 MIIM_DATA 0x2d mscc_miim_read: phyad 9 reg 0x5 MIIM_DATA 0x5801 mscc_miim_read: phyad 10 reg 0x1 MIIM_DATA 0x2d mscc_miim_read: phyad 10 reg 0x5 MIIM_DATA 0x5801 mscc_miim_read: phyad 10 reg 0x1 MIIM_DATA 0x2d mscc_miim_read: phyad 10 reg 0x5 MIIM_DATA 0x5801 mscc_miim_read: phyad 11 reg 0x1 MIIM_DATA 0x2d mscc_miim_read: phyad 11 reg 0x5 MIIM_DATA 0x5801 mscc_miim_read: phyad 11 reg 0x1 MIIM_DATA 0x2d mscc_miim_read: phyad 11 reg 0x5 MIIM_DATA 0x5801 mscc_miim_read: phyad 4 reg 0x1 MIIM_DATA 0x3002d, ERROR mscc_miim_read: phyad 4 reg 0x5 MIIM_DATA 0x3da01, ERROR mscc_miim_read: phyad 5 reg 0x1 MIIM_DATA 0x3002d, ERROR mscc_miim_read: phyad 5 reg 0x5 MIIM_DATA 0x35801, ERROR mscc_miim_read: phyad 5 reg 0x1 MIIM_DATA 0x3002d, ERROR mscc_miim_read: phyad 5 reg 0x5 MIIM_DATA 0x35801, ERROR mscc_miim_read: phyad 6 reg 0x1 MIIM_DATA 0x3002d, ERROR mscc_miim_read: phyad 6 reg 0x5 MIIM_DATA 0x35801, ERROR mscc_miim_read: phyad 6 reg 0x1 MIIM_DATA 0x3002d, ERROR mscc_miim_read: phyad 6 reg 0x5 MIIM_DATA 0x35801, ERROR mscc_miim_read: phyad 7 reg 0x1 MIIM_DATA 0x3002d, ERROR mscc_miim_read: phyad 7 reg 0x5 MIIM_DATA 0x35801, ERROR mscc_miim_read: phyad 7 reg 0x1 MIIM_DATA 0x3002d, ERROR mscc_miim_read: phyad 7 reg 0x5 MIIM_DATA 0x35801, ERROR As can be seen, the data in MIIM_DATA is still valid despite having the MSCC_MIIM_DATA_ERROR bits set. The driver as introduced in commit 84705fc16552 ("net: dsa: felix: introduce support for Seville VSC9953 switch") was ignoring these bits, perhaps deliberately (although unbeknownst to me). This is an old IP and the hardware team cannot seem to be able to help me track down a plausible reason for these failures. I'll keep investigating, but in the meantime, this is a direct regression which must be restored to a working state. The only thing I can do is keep ignoring the errors as before. Fixes: b99658452355 ("net: dsa: ocelot: felix: utilize shared mscc-miim driver for indirect MDIO access") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | qede: avoid uninitialized entries in coal_entry arrayMichal Schmidt2023-02-261-14/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even after commit 908d4bb7c54c ("qede: fix interrupt coalescing configuration"), some entries of the coal_entry array may theoretically be used uninitialized: 1. qede_alloc_fp_array() allocates QEDE_MAX_RSS_CNT entries for coal_entry. The initial allocation uses kcalloc, so everything is initialized. 2. The user sets a small number of queues (ethtool -L). coal_entry is reallocated for the actual small number of queues. 3. The user sets a bigger number of queues. coal_entry is reallocated bigger. The added entries are not necessarily initialized. In practice, the reallocations will actually keep using the originally allocated region of memory, but we should not rely on it. The reallocation is unnecessary. coal_entry can always have QEDE_MAX_RSS_CNT entries. Fixes: 908d4bb7c54c ("qede: fix interrupt coalescing configuration") Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Nacked-by: Manish Chopra <manishc@marvell.com> Acked-by: Manish Chopra <manishc@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | Merge tag 'mlx5-fixes-2023-02-24' of ↵David S. Miller2023-02-2610-8/+40
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahemeed says: ==================== mlx5 fixes 2023-02-24 V1->V2: - Toss away arguably non-fixes patches This series provides bug fixes for mlx5 driver. Please pull and let me know if there is any problem. ====================
| | * | net/mlx5: Geneve, Fix handling of Geneve object id as error codeMaor Dickman2023-02-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On success, mlx5_geneve_tlv_option_create returns non negative Geneve object id. In case the object id is positive value the caller functions will handle it as an error (non zero) and will fail to offload the Geneve rule. Fix this by changing caller function ,mlx5_geneve_tlv_option_add, to return 0 in case valid non negative object id was provided. Fixes: 0ccc171ea6a2 ("net/mlx5: Geneve, Manage Geneve TLV options") Signed-off-by: Maor Dickman <maord@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| | * | net/mlx5e: Verify flow_source cap before using itRoi Dayan2023-02-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When adding send to vport rule verify flow_source matching is supported by checking the flow_source cap. Fixes: d04442540372 ("net/mlx5: E-Switch, set flow source for send to uplink rule") Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| | * | net/mlx5: ECPF, wait for VF pages only after disabling host PFsMaher Sanalla2023-02-242-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, during the early stages of their unloading, particularly during SRIOV disablement, PFs/ECPFs wait on the release of all of their VFs memory pages. Furthermore, ECPFs are considered the page supplier for host VFs, hence the host VFs memory pages are freed only during ECPF cleanup when host interfaces get disabled. Thus, disabling SRIOV early in unload timeline causes the DPU ECPF to stall on driver unload while waiting on the release of host VF pages that won't be freed before host interfaces get disabled later on. Therefore, for ECPFs, wait on the release of VFs pages only after the disablement of host PFs during ECPF cleanup flow. Then, host PFs and VFs are disabled and their memory shall be freed accordingly. Fixes: 143a41d7623d ("net/mlx5: Disable SRIOV before PF removal") Signed-off-by: Maher Sanalla <msanalla@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| | * | mlx5: fix possible ptp queue fifo use-after-freeVadim Fedorenko2023-02-244-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fifo indexes are not checked during pop operations and it leads to potential use-after-free when poping from empty queue. Such case was possible during re-sync action. WARN_ON_ONCE covers future cases. There were out-of-order cqe spotted which lead to drain of the queue and use-after-free because of lack of fifo pointers check. Special check and counter are added to avoid resync operation if SKB could not exist in the fifo because of OOO cqe (skb_id must be between consumer and producer index). Fixes: 58a518948f60 ("net/mlx5e: Add resiliency for PTP TX port timestamp") Signed-off-by: Vadim Fedorenko <vadfed@meta.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| | * | mlx5: fix skb leak while fifo resync and pushVadim Fedorenko2023-02-242-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During ptp resync operation SKBs were poped from the fifo but were never freed neither by napi_consume nor by dev_kfree_skb_any. Add call to napi_consume_skb to properly free SKBs. Another leak was happening because mlx5e_skb_fifo_has_room() had an error in the check. Comparing free running counters works well unless C promotes the types to something wider than the counter. In this case counters are u16 but the result of the substraction is promouted to int and it causes wrong result (negative value) of the check when producer have already overlapped but consumer haven't yet. Explicit cast to u16 fixes the issue. Fixes: 58a518948f60 ("net/mlx5e: Add resiliency for PTP TX port timestamp") Reviewed-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Vadim Fedorenko <vadfed@meta.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| | * | net/mlx5e: TC, fix return value check in mlx5e_tc_act_stats_create()Yang Yingliang2023-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | kvzalloc() returns NULL pointer not PTR_ERR() when it fails, so replace the IS_ERR() check with NULL pointer check. Fixes: d13674b1d14c ("net/mlx5e: TC, map tc action cookie to a hw counter") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| | * | net/mlx5: Remove NULL check before dev_{put, hold}Yang Li2023-02-241-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The call netdev_{put, hold} of dev_{put, hold} will check NULL, so there is no need to check before using dev_{put, hold}, remove it to silence the warning： ./drivers/net/ethernet/mellanox/mlx5/core/en/rep/tc.c:714:2-9: WARNING: NULL check before dev_{put, hold} functions is not needed. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4174 Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * | | nfc: fix memory leak of se_io context in nfc_genl_se_ioFedor Pchelkin2023-02-262-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The callback context for sending/receiving APDUs to/from the selected secure element is allocated inside nfc_genl_se_io and supposed to be eventually freed in se_io_cb callback function. However, there are several error paths where the bwi_timer is not charged to call se_io_cb later, and the cb_context is leaked. The patch proposes to free the cb_context explicitly on those error paths. At the moment we can't simply check 'dev->ops->se_io()' return value as it may be negative in both cases: when the timer was charged and was not. Fixes: 5ce3f32b5264 ("NFC: netlink: SE API implementation") Reported-by: syzbot+df64c0a2e8d68e78a4fa@syzkaller.appspotmail.com Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | ice: remove unnecessary CONFIG_ICE_GNSSJacob Keller2023-02-263-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CONFIG_ICE_GNSS was added by commit c7ef8221ca7d ("ice: use GNSS subsystem instead of TTY") as a way to allow the ice driver to optionally support GNSS features without forcing a dependency on CONFIG_GNSS. The original implementation of that commit at [1] used IS_REACHABLE. This was rejected by Olek at [2] with the suggested implementation of CONFIG_ICE_GNSS. Eventually after merging, Linus reported a .config which had CONFIG_ICE_GNSS = y when both GNSS = n and ICE = n. This confused him and he felt that the config option was not useful, and commented about it at [3]. CONFIG_ICE_GNSS is defined to y whenever GNSS = ICE. This results in it being set in cases where both options are not enabled. The goal of CONFIG_ICE_GNSS is to ensure that the GNSS support in the ice driver is enabled when GNSS is enabled. The complaint from Olek about the original IS_REACHABLE was due to the required IS_REACHABLE checks throughout the ice driver code and the fact that ice_gnss.c was compiled regardless of GNSS support. This can be fixed in the Makefile by using ice-$(CONFIG_GNSS) += ice_gnss.o In this case, if GNSS = m and ICE = y, we can result in some confusing behavior where GNSS support is not enabled because its not built in. See [4]. To disallow this, have CONFIG_ICE depend on GNSS || GNSS = n. This ensures that we cannot enable CONFIG_ICE as builtin while GNSS is a module. Drop CONFIG_ICE_GNSS, and replace the IS_ENABLED checks for it with checks for GNSS. Update the Makefile to add the ice_gnss.o object based on CONFIG_GNSS. This works to ensure that GNSS support can optionally be enabled, doesn't have an unnnecessary extra config option, and has Kbuild enforce the dependency such that you can't accidentally enable GNSS as a module and ICE as a builtin. [1] https://lore.kernel.org/intel-wired-lan/20221019095603.44825-1-arkadiusz.kubalewski@intel.com/ [2] https://lore.kernel.org/intel-wired-lan/20221028165706.96849-1-alexandr.lobakin@intel.com/ [3] https://lore.kernel.org/all/CAHk-=wi_410KZqHwF-WL5U7QYxnpHHHNP-3xL=g_y89XnKc-uw@mail.gmail.com/ [4] https://lore.kernel.org/netdev/20230223161309.0e439c5f@kernel.org/ Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Fixes: c7ef8221ca7d ("ice: use GNSS subsystem instead of TTY") Cc: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Cc: Alexander Lobakin <alexandr.lobakin@intel.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Anthony Nguyen <anthony.l.nguyen@intel.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | ibmvnic: Assign XPS map to correct queue indexNick Child2023-02-251-2/+2
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When setting the XPS map value for TX queues, use the index of the transmit queue. Previously, the function was passing the index of the loop that iterates over all queues (RX and TX). This was causing invalid XPS map values. Fixes: 6831582937bd ("ibmvnic: Toggle between queue types in affinity mapping") Signed-off-by: Nick Child <nnac123@linux.ibm.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://lore.kernel.org/r/20230223153944.44969-1-nnac123@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | net/mlx5e: Remove hairpin write debugfs filesGal Pressman2023-02-241-59/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Per the discussion in [1], hairpin parameters will be exposed using devlink, remove the debugfs files. [1] https://lore.kernel.org/all/20230111194608.7f15b9a1@kernel.org/ Signed-off-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/all/20230222230202.523667-1-saeed@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | octeontx2-pf: Use correct struct reference in test conditionDeepak R Varma2023-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the typo/copy-paste error by replacing struct variable ah_esp_mask name by ah_esp_hdr. Issue identified using doublebitand.cocci Coccinelle semantic patch. Fixes: b7cf966126eb ("octeontx2-pf: Add flow classification using IP next level protocol") Link: https://lore.kernel.org/all/20210111112537.3277-1-naveenm@marvell.com/ Signed-off-by: Deepak R Varma <drv@mailo.com> Link: https://lore.kernel.org/r/Y/YYkKddeHOt80cO@ubun2204.myguest.virtualbox.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | net: sunhme: Fix region requestSean Anderson2023-02-231-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | devm_request_region is for I/O regions. Use devm_request_mem_region instead. This fixes the driver failing to probe since 99df45c9e0a4 ("sunhme: fix an IS_ERR() vs NULL check in probe"), which checked the result. Fixes: 914d9b2711dd ("sunhme: switch to devres") Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://lore.kernel.org/r/20230222204242.2658247-1-seanga2@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | octeontx2-pf: Recalculate UDP checksum for ptp 1-step sync packetGeetha sowjanya2023-02-231-19/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When checksum offload is disabled in the driver via ethtool, the PTP 1-step sync packets contain incorrect checksum, since the stack calculates the checksum before driver updates PTP timestamp field in the packet. This results in PTP packets getting dropped at the other end. This patch fixes the issue by re-calculating the UDP checksum after updating PTP timestamp field in the driver. Fixes: 2958d17a8984 ("octeontx2-pf: Add support for ptp 1-step mode on CN10K silicon") Signed-off-by: Geetha sowjanya <gakula@marvell.com> Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by: Sai Krishna <saikrishnag@marvell.com> Link: https://lore.kernel.org/r/20230222113600.1965116-1-saikrishnag@marvell.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
| * | net: phy: c45: genphy_c45_ethtool_set_eee: validate EEE link modesOleksij Rempel2023-02-231-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, it is possible to let some PHYs to advertise not supported EEE link modes. So, validate them before overwriting existing configuration. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
| * | net: phy: do not force EEE supportOleksij Rempel2023-02-232-7/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With following patches: commit 9b01c885be36 ("net: phy: c22: migrate to genphy_c45_write_eee_adv()") commit 5827b168125d ("net: phy: c45: migrate to genphy_c45_write_eee_adv()") we set the advertisement to potentially supported values. This behavior may introduce new regressions on systems where EEE was disabled by default (BIOS or boot loader configuration or by other ways.) At same time, with this patches, we would overwrite EEE advertisement configuration made over ethtool. To avoid this issues, we need to cache initial and ethtool advertisement configuration and store it for later use. Fixes: 9b01c885be36 ("net: phy: c22: migrate to genphy_c45_write_eee_adv()") Fixes: 5827b168125d ("net: phy: c45: migrate to genphy_c45_write_eee_adv()") Fixes: 022c3f87f88e ("net: phy: add genphy_c45_ethtool_get/set_eee() support") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
| * | net: phy: c45: add genphy_c45_an_config_eee_aneg() functionOleksij Rempel2023-02-232-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add new genphy_c45_an_config_eee_aneg() function and replace some of genphy_c45_write_eee_adv() calls. This will be needed by the next patch. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
| * | net: phy: c45: use "supported_eee" instead of supported for access validationOleksij Rempel2023-02-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make sure we use proper variable to validate access to potentially not supported registers. Otherwise we will get false read/write errors. Reported-by: kernel test robot <yujie.liu@intel.com> Link: https://lore.kernel.org/oe-lkp/202302211644.c12d19de-yujie.liu@intel.com Fixes: 022c3f87f88e ("net: phy: add genphy_c45_ethtool_get/set_eee() support") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
| * | net/mlx5: Fix memory leak in IPsec RoCE creationPatrisious Haddad2023-02-231-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During IPsec RoCE TX creation a struct for the flow group creation is allocated, but never freed. Free that struct once it is no longer in use. Fixes: 22551e77e550 ("net/mlx5: Configure IPsec steering for egress RoCEv2 traffic") Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/a69739482cca7176d3a466f87bbf5af1250b09bb.1677056384.git.leon@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-17 00:55:05 +0100