BMC/Intel-BMC/linux.git/drivers/net, branch dev-5.14-intel

Return link speed and duplex settings for the NCSI channel

2021-10-19T22:10:33+00:00

The ftgmac100_open function initializes state for the NCSI channel. The get link settings function does not return this data. This caused the link speed, and the duplex value to be returned incorrectly by the PHY driver (0 Mbps, and duplex off). Update the driver to return either the PHY settings when not using NCSI, or the NCSI values that were assigned when the driver is opened. Signed-off-by: Johnathan Mantey

Merge tag 'v5.14.11' into dev-5.14

2021-10-11T05:22:51+00:00

This is the 5.14.11 stable release Signed-off-by: Joel Stanley

Revert "brcmfmac: use ISO3166 country code and 0 rev as fallback"

2021-10-09T13:02:42+00:00

commit 151a7c12c4fc8340b51e849e4d1fcb7d794777a5 upstream. This reverts commit b0b524f079a23e440dd22b04e369368dde847533. Commit b0b524f079a2 ("brcmfmac: use ISO3166 country code and 0 rev as fallback") changes country setup to directly use ISO3166 country codes if no more specific code is configured. This was done under the assumption that brcmfmac firmwares can handle such simple direct mapping from country codes to firmware ccode values. Unfortunately this is not true for all chipset/firmware combinations. E.g. BCM4359/9 devices stop working as access point with this change, so revert the offending commit to avoid the regression. Signed-off-by: Soeren Moch Cc: stable@vger.kernel.org # 5.14.x Acked-by: Shawn Guo Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210926201905.211605-1-smoch@web.de Signed-off-by: Greg Kroah-Hartman

xen-netback: correct success/error reporting for the SKB-with-fraglist case

2021-10-09T13:02:38+00:00

[ Upstream commit 3ede7f84c7c21f93c5eac611d60eba3f2c765e0f ] When re-entering the main loop of xenvif_tx_check_gop() a 2nd time, the special considerations for the head of the SKB no longer apply. Don't mistakenly report ERROR to the frontend for the first entry in the list, even if - from all I can tell - this shouldn't matter much as the overall transmit will need to be considered failed anyway. Signed-off-by: Jan Beulich Reviewed-by: Paul Durrant Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: mdio: introduce a shutdown method to mdio device drivers

2021-10-09T13:02:38+00:00

[ Upstream commit cf9579976f724ad517cc15b7caadea728c7e245c ] MDIO-attached devices might have interrupts and other things that might need quiesced when we kexec into a new kernel. Things are even more creepy when those interrupt lines are shared, and in that case it is absolutely mandatory to disable all interrupt sources. Moreover, MDIO devices might be DSA switches, and DSA needs its own shutdown method to unlink from the DSA master, which is a new requirement that appeared after commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"). So introduce a ->shutdown method in the MDIO device driver structure. Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

drivers: net: mhi: fix error path in mhi_net_newlink

2021-10-07T05:53:19+00:00

commit 4526fe74c3c5095cc55931a3a6fb4932f9e06002 upstream. Fix double free_netdev when mhi_prepare_for_transfer fails. Fixes: 3ffec6a14f24 ("net: Add mhi-net driver") Signed-off-by: Daniele Palmas Reviewed-by: Manivannan Sadhasivam Reviewed-by: Loic Poulain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

usb: hso: remove the bailout parameter

2021-10-07T05:53:18+00:00

commit dcb713d53e2eadf42b878c12a471e74dc6ed3145 upstream. There are two invocation sites of hso_free_net_device. After refactoring hso_create_net_device, this parameter is useless. Remove the bailout in the hso_free_net_device and change the invocation sites of this function. Signed-off-by: Dongliang Mu Signed-off-by: David S. Miller [Backport this cleanup patch to 5.10 and 5.14 in order to keep the codebase consistent with the 4.14/4.19/5.4 patchseries] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman

net: stmmac: fix EEE init issue when paired with EEE capable PHYs

2021-10-07T05:53:15+00:00

[ Upstream commit 656ed8b015f19bf3f6e6b3ddd9a4bb4aa5ca73e1 ] When STMMAC is paired with Energy-Efficient Ethernet(EEE) capable PHY, and the PHY is advertising EEE by default, we need to enable EEE on the xPCS side too, instead of having user to manually trigger the enabling config via ethtool. Fixed this by adding xpcs_config_eee() call in stmmac_eee_init(). Fixes: 7617af3d1a5e ("net: pcs: Introducing support for DWC xpcs Energy Efficient Ethernet") Cc: Michael Sit Wei Hong Signed-off-by: Wong Vee Khee Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: phy: bcm7xxx: Fixed indirect MMD operations

2021-10-07T05:53:15+00:00

[ Upstream commit d88fd1b546ff19c8040cfaea76bf16aed1c5a0bb ] When EEE support was added to the 28nm EPHY it was assumed that it would be able to support the standard clause 45 over clause 22 register access method. It turns out that the PHY does not support that, which is the very reason for using the indirect shadow mode 2 bank 3 access method. Implement {read,write}_mmd to allow the standard PHY library routines pertaining to EEE querying and configuration to work correctly on these PHYs. This forces us to implement a __phy_set_clr_bits() function that does not grab the MDIO bus lock since the PHY driver's {read,write}_mmd functions are always called with that lock held. Fixes: 83ee102a6998 ("net: phy: bcm7xxx: add support for 28nm EPHY") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: hns3: disable firmware compatible features when uninstall PF

2021-10-07T05:53:15+00:00

[ Upstream commit 0178839ccca36dee238a57e7f4c3c252f5dbbba6 ] Currently, the firmware compatible features are enabled in PF driver initialization process, but they are not disabled in PF driver deinitialization process and firmware keeps these features in enabled status. In this case, if load an old PF driver (for example, in VM) which not support the firmware compatible features, firmware will still send mailbox message to PF when link status changed and PF will print "un-supported mailbox message, code = 201". To fix this problem, disable these firmware compatible features in PF driver deinitialization process. Fixes: ed8fb4b262ae ("net: hns3: add link change event report") Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin