- 03 6月, 2021 4 次提交
-
-
由 Maxim Kochetkov 提交于
stable inclusion from stable-5.10.37 commit bfcb5a8cc7b669a30e3950fc9c2a421e3244dbc8 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit e7679c55 ] Changing downshift params without software reset has no effect, so call genphy_soft_reset() after change downshift params. As the datasheet says: Changes to these bits are disruptive to the normal operation therefore, any changes to these registers must be followed by software reset to take effect. Fixes: 5c6bc519 ("net: phy: marvell: add downshift support for M88E1111") Signed-off-by: NMaxim Kochetkov <fido_max@inbox.ru> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Maxim Kochetkov 提交于
stable inclusion from stable-5.10.37 commit 1157d01e04d90dde889b6bd5342df33b5db39949 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 990875b2 ] Changing downshift params without software reset has no effect, so call genphy_soft_reset() after change downshift params. As the datasheet says: Changes to these bits are disruptive to the normal operation therefore, any changes to these registers must be followed by software reset to take effect. Fixes: 911af5e1 ("net: phy: marvell: fix downshift function naming") Signed-off-by: NMaxim Kochetkov <fido_max@inbox.ru> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Martin Schiller 提交于
stable inclusion from stable-5.10.37 commit 7fe12d6db3f04b4c95a24532046a115443e70f5a bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 357a07c2 ] The Intel xway phys offer the possibility to deactivate the integrated LED function and to control the LEDs manually. If this was set by the bootloader, it must be ensured that the integrated LED function is enabled for all LEDs when loading the driver. Before commit 6e2d85ec ("net: phy: Stop with excessive soft reset") the LEDs were enabled by a soft-reset of the PHY (using genphy_soft_reset). Initialize the XWAY_MDIO_LED with it's default value (which is applied during a soft reset) instead of adding back the soft reset. This brings back the default LED configuration while still preventing an excessive amount of soft resets. Fixes: 6e2d85ec ("net: phy: Stop with excessive soft reset") Signed-off-by: NMartin Schiller <ms@dev.tdt.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Andre Edich 提交于
stable inclusion from stable-5.10.37 commit c45cb22a5500c6f45fa6e966400f6afd51e685ad bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit fdb5cc6a ] The function lan87xx_config_aneg_ext was introduced to configure LAN95xxA but as well writes to undocumented register of LAN87xx. This fix prevents that access. The function lan87xx_config_aneg_ext gets more suitable for the new behavior name. Reported-by: NMåns Rullgård <mans@mansr.com> Fixes: 05b35e7e ("smsc95xx: add phylib support") Signed-off-by: NAndre Edich <andre.edich@microchip.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 26 4月, 2021 4 次提交
-
-
由 Pali Rohár 提交于
stable inclusion from stable-5.10.32 commit 6ac98ee9cb7c62d2990e984b0df4d443a7769bc2 bugzilla: 51796 -------------------------------- commit 1fe976d3 upstream. Since commit fee2d546 ("net: phy: marvell: mv88e6390 temperature sensor reading"), Linux reports the temperature of Topaz hwmon as constant -75°C. This is because switches from the Topaz family (88E6141 / 88E6341) have the address of the temperature sensor register different from Peridot. This address is instead compatible with 88E1510 PHYs, as was used for Topaz before the above mentioned commit. Create a new mapping table between switch family and PHY ID for families which don't have a model number. And define PHY IDs for Topaz and Peridot families. Create a new PHY ID and a new PHY driver for Topaz's internal PHY. The only difference from Peridot's PHY driver is the HWMON probing method. Prior this change Topaz's internal PHY is detected by kernel as: PHY [...] driver [Marvell 88E6390] (irq=63) And afterwards as: PHY [...] driver [Marvell 88E6341 Family] (irq=63) Signed-off-by: NPali Rohár <pali@kernel.org> BugLink: https://github.com/globalscaletechnologies/linux/issues/1 Fixes: fee2d546 ("net: phy: marvell: mv88e6390 temperature sensor reading") Reviewed-by: NMarek Behún <kabel@kernel.org> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Russell King 提交于
stable inclusion from stable-5.10.31 commit 9d9facd32d89f737605c7135cee7f8189959d098 bugzilla: 51792 -------------------------------- commit 624407d2 upstream. The SFP MSA defines two option bits in byte 65 to indicate how the Rx_LOS signal on SFP pin 8 behaves: bit 2 - Loss of Signal implemented, signal inverted from standard definition in SFP MSA (often called "Signal Detect"). bit 1 - Loss of Signal implemented, signal as defined in SFP MSA (often called "Rx_LOS"). Clearly, setting both bits results in a meaningless situation: it would mean that LOS is implemented in both the normal sense (1 = signal loss) and inverted sense (0 = signal loss). Unfortunately, there are modules out there which set both bits, which will be initially interpret as "inverted" sense, and then, if the LOS signal changes state, we will toggle between LINK_UP and WAIT_LOS states. Change our LOS handling to give well defined behaviour: only interpret these bits as meaningful if exactly one is set, otherwise treat it as if LOS is not implemented. Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1kyYQa-0004iR-CU@rmk-PC.armlinux.org.ukSigned-off-by: NJakub Kicinski <kuba@kernel.org> Cc: Pali Rohár <pali@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Russell King 提交于
stable inclusion from stable-5.10.31 commit 2a60ab2dab3df84e6d6690ac7a23e1d921b25a36 bugzilla: 51792 -------------------------------- commit 7a77233e upstream. Do not check the encoding when deriving 1000BASE-X from the bitrate when no other modes are discovered. Some GPON modules (VSOL V2801F and CarlitoxxPro CPGOS03-0490 v2.0) indicate NRZ encoding with a 1200Mbaud bitrate, but should be driven with 1000BASE-X on the host side. Tested-by: NPali Rohár <pali@kernel.org> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Florian Fainelli 提交于
stable inclusion from stable-5.10.30 commit f295dfc831bc266810e354c59ec249eb6701d91d bugzilla: 51791 -------------------------------- [ Upstream commit c056d480 ] We should not be advertising EEE for modes that we do not support, correct that oversight by looking at the PHY device supported linkmodes. Fixes: 99cec8a4 ("net: phy: broadcom: Allow enabling or disabling of EEE") Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 19 4月, 2021 6 次提交
-
-
由 Florian Fainelli 提交于
stable inclusion from stable-5.10.27 commit 87771c9b09bbf4642433f49586124f36bdad650f bugzilla: 51493 -------------------------------- [ Upstream commit b1dd9bf6 ] The PHY driver entry for BCM50160 and BCM50610M calls bcm54xx_config_init() but does not call bcm54xx_config_clock_delay() in order to configuration appropriate clock delays on the PHY, fix that. Fixes: 73333626 ("net: phy: Allow BCM5481x PHYs to setup internal TX/RX clock delay") Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Robert Hancock 提交于
stable inclusion from stable-5.10.27 commit 485335a637c8f2909f7c1932b1820d1d9f9db9f8 bugzilla: 51493 -------------------------------- [ Upstream commit 3afd0218 ] The default configuration for the BCM54616S PHY may not match the desired mode when using 1000BaseX or SGMII interface modes, such as when it is on an SFP module. Add code to explicitly set the correct mode using programming sequences provided by Bel-Fuse: https://www.belfuse.com/resources/datasheets/powersolutions/ds-bps-sfp-1gbt-05-series.pdf https://www.belfuse.com/resources/datasheets/powersolutions/ds-bps-sfp-1gbt-06-series.pdfSigned-off-by: NRobert Hancock <robert.hancock@calian.com> Acked-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Florian Fainelli 提交于
stable inclusion from stable-5.10.27 commit 837a3ae33459f25ad895e828088b505b60349983 bugzilla: 51493 -------------------------------- [ Upstream commit 133bf7b4 ] Avoid a forward declaration by moving the callers of bcm54xx_config_clock_delay() below its body. Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Michael Walle 提交于
stable inclusion from stable-5.10.27 commit 9a5267264fc2f366b687b400487ec06747f054b6 bugzilla: 51493 -------------------------------- [ Upstream commit 4217a64e ] At the moment, PORT_MII is reported in the ethtool ops. This is odd because it is an interface between the MAC and the PHY and no external port. Some network card drivers will overwrite the port to twisted pair or fiber, though. Even worse, the MDI/MDIX setting is only used by ethtool if the port is twisted pair. Set the port to PORT_TP by default because most PHY drivers are copper ones. If there is fibre support and it is enabled, the PHY driver will set it to PORT_FIBRE. This will change reporting PORT_MII to either PORT_TP or PORT_FIBRE; except for the genphy fallback driver. Suggested-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NMichael Walle <michael@walle.cc> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ong Boon Leong 提交于
stable inclusion from stable-5.10.27 commit ddeba5b39ccadaac9abce231ead451a4baaff77c bugzilla: 51493 -------------------------------- [ Upstream commit d82c6c1a ] if pl->mac_ops->mac_finish() failed, phylink_err should use "mac_finish" instead of "mac_prepare". Fixes: b7ad14c2 ("net: phylink: re-implement interface configuration with PCS") Signed-off-by: NOng Boon Leong <boon.leong.ong@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Florian Fainelli 提交于
stable inclusion from stable-5.10.27 commit e64a5a5b8e93a4064da38cde8b25e68750c60d54 bugzilla: 51493 -------------------------------- [ Upstream commit 7a1468ba ] Per the datasheet, when we clear the power down bit, the PHY remains in an internal reset state for 40us and then resume normal operation. Account for that delay to avoid any issues in the future if genphy_resume() changes. Fixes: fe26821f ("net: phy: broadcom: Wire suspend/resume for BCM54810") Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 13 4月, 2021 1 次提交
-
-
由 Christian Melki 提交于
stable inclusion from stable-5.10.26 commit 8545519b1f51b73372c86d754bc9ee83c5d06760 bugzilla: 51363 -------------------------------- [ Upstream commit 764d31ca ] Following a similar reinstate for the KSZ9031. Older kernels would use the genphy_soft_reset if the PHY did not implement a .soft_reset. Bluntly removing that default may expose a lot of situations where various PHYs/board implementations won't recover on various changes. Like with this implementation during a 4.9.x to 5.4.x LTS transition. I think it's a good thing to remove unwanted soft resets but wonder if it did open a can of worms? Atleast this fixes one iMX6 FEC/RMII/8081 combo. Fixes: 6e2d85ec ("net: phy: Stop with excessive soft reset") Signed-off-by: NChristian Melki <christian.melki@t2data.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20210224205536.9349-1-christian.melki@t2data.comSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 09 4月, 2021 7 次提交
-
-
由 Arnd Bergmann 提交于
stable inclusion from stable-5.10.24 commit c1e1a64a23136b47844e71991b3cdd4acb2f57d8 bugzilla: 51348 -------------------------------- commit 7f654157 upstream. When CONFIG_PM_SLEEP is disabled, the compiler warns about unused functions: drivers/net/phy/phy_device.c:273:12: error: unused function 'mdio_bus_phy_suspend' [-Werror,-Wunused-function] static int mdio_bus_phy_suspend(struct device *dev) drivers/net/phy/phy_device.c:293:12: error: unused function 'mdio_bus_phy_resume' [-Werror,-Wunused-function] static int mdio_bus_phy_resume(struct device *dev) The logic is intentional, so just mark these two as __maybe_unused and remove the incorrect #ifdef. Fixes: 4c0d2e96 ("net: phy: consider that suspend2ram may cut off PHY power") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20210225145748.404410-1-arnd@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Guangbin Huang 提交于
stable inclusion from stable-5.10.24 commit 6aa23829949c2c0912e82866aeab4fd591595235 bugzilla: 51348 -------------------------------- commit d9032dba upstream. If phy uses generic driver and autoneg is on, enter command "ethtool -s eth0 speed 50" will not change phy speed actually, but command "ethtool eth0" shows speed is 50Mb/s because phydev->speed has been set to 50 and no update later. And duplex setting has same problem too. However, if autoneg is on, phy only changes speed and duplex according to phydev->advertising, but not phydev->speed and phydev->duplex. So in this case, phydev->speed and phydev->duplex don't need to be set in function phy_ethtool_ksettings_set() if autoneg is on. Fixes: 51e2a384 ("PHY: Avoid unnecessary aneg restarts") Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Pali Rohár 提交于
stable inclusion from stable-5.10.21 commit 2064bba25ac55d02dbec85c66fc20cff22e09f2d bugzilla: 50609 -------------------------------- [ Upstream commit 426c6cbc ] The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: NRussell King <rmk+kernel@armlinux.org.uk> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk> Signed-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Russell King 提交于
stable inclusion from stable-5.10.21 commit 113bcb8f65d47c8a143a15035d8865117778e288 bugzilla: 50609 -------------------------------- [ Upstream commit 0d035bed ] Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: NThomas Schreiber <tschreibe@gmail.com> Reported-by: NPali Rohár <pali@kernel.org> Tested-by: NPali Rohár <pali@kernel.org> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Pali Rohár 提交于
stable inclusion from stable-5.10.21 commit 6c15e41dc4ac38ad0d4a5790ebdf582c98f88d74 bugzilla: 50609 -------------------------------- [ Upstream commit f0b4f847 ] The Ubiquiti U-Fiber Instant SFP GPON module has nonsensical information stored in its EEPROM. It claims to support all transceiver types including 10G Ethernet. Clear all claimed modes and set only 1000baseX_Full, which is the only one supported. This module has also phys_id set to SFF, and the SFP subsystem currently does not allow to use SFP modules detected as SFFs. Add exception for this module so it can be detected as supported. This change finally allows to detect and use SFP GPON module Ubiquiti U-Fiber Instant on Linux system. EEPROM content of this SFP module is (where XX is serial number): 00: 02 04 0b ff ff ff ff ff ff ff ff 03 0c 00 14 c8 ???........??.?? 10: 00 00 00 00 55 42 4e 54 20 20 20 20 20 20 20 20 ....UBNT 20: 20 20 20 20 00 18 e8 29 55 46 2d 49 4e 53 54 41 .??)UF-INSTA 30: 4e 54 20 20 20 20 20 20 34 20 20 20 05 1e 00 36 NT 4 ??.6 40: 00 06 00 00 55 42 4e 54 XX XX XX XX XX XX XX XX .?..UBNTXXXXXXXX 50: 20 20 20 20 31 34 30 31 32 33 20 20 60 80 02 41 140123 `??A Signed-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Bjarni Jonasson 提交于
stable inclusion from stable-5.10.20 commit 7592f07e6d2cdda93e9f09105d88e83a38f12a8b bugzilla: 50608 -------------------------------- [ Upstream commit 3cc2c646 ] At Power-On Reset, transients may cause the LCPLL to lock onto a clock that is momentarily unstable. This is normally seen in QSGMII setups where the higher speed 6G SerDes is being used. This patch adds an initial LCPLL Reset to the PHY (first instance) to avoid this issue. Fixes: e4f9ba64 ("net: phy: mscc: add support for VSC8514 PHY.") Signed-off-by: NSteen Hegelund <steen.hegelund@microchip.com> Signed-off-by: NBjarni Jonasson <bjarni.jonasson@microchip.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Heiner Kallweit 提交于
stable inclusion from stable-5.10.20 commit 96fb2077a517862e51b9a136a581c713aa83bc4f bugzilla: 50608 -------------------------------- [ Upstream commit 4c0d2e96 ] Claudiu reported that on his system S2R cuts off power to the PHY and after resuming certain PHY settings are lost. The PM folks confirmed that cutting off power to selected components in S2R is a valid case. Therefore resuming from S2R, same as from hibernation, has to assume that the PHY has power-on defaults. As a consequence use the restore callback also as resume callback. In addition make sure that the interrupt configuration is restored. Let's do this in phy_init_hw() and ensure that after this call actual interrupt configuration is in sync with phydev->interrupts. Currently, if interrupt was enabled before hibernation, we would resume with interrupt disabled because that's the power-on default. This fix applies cleanly only after the commit marked as fixed. I don't have an affected system, therefore change is compile-tested only. [0] https://lore.kernel.org/netdev/1610120754-14331-1-git-send-email-claudiu.beznea@microchip.com/ Fixes: 611d779a ("net: phy: fix MDIO bus PM PHY resuming") Reported-by: NClaudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 29 1月, 2021 1 次提交
-
-
由 Marco Felsch 提交于
stable inclusion from stable-5.10.10 commit c469b23d1b541cbdd6831b468acd4bfb849180c6 bugzilla: 47610 -------------------------------- [ Upstream commit a18caa97 ] Commit bedd8d78 ("net: phy: smsc: LAN8710/20: add phy refclk in support") added the phy clk support. The commit already checks if clk_get_optional() throw an error but instead of returning the error it ignores it. Fixes: bedd8d78 ("net: phy: smsc: LAN8710/20: add phy refclk in support") Suggested-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20210111085932.28680-1-m.felsch@pengutronix.deSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
- 15 11月, 2020 1 次提交
-
-
由 Zhang Changzhong 提交于
Add the missing clk_disable_unprepare() before return from smsc_phy_probe() in the error handling case. Fixes: bedd8d78 ("net: phy: smsc: LAN8710/20: add phy refclk in support") Reported-by: NHulk Robot <hulkci@huawei.com> Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1605180239-1792-1-git-send-email-zhangchangzhong@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 14 11月, 2020 1 次提交
-
-
由 Steen Hegelund 提交于
Selecting VSC8575 as a MACSec PHY was not correct The relevant datasheet can be found here: - VSC8575: https://www.microchip.com/wwwproducts/en/VSC8575 History: v1 -> v2: - Corrected the sha in the "Fixes:" tag Fixes: 1bbe0ecc ("net: phy: mscc: macsec initialization") Signed-off-by: NSteen Hegelund <steen.hegelund@microchip.com> Reviewed-by: NAntoine Tenart <atenart@kernel.org> Link: https://lore.kernel.org/r/20201113091116.1102450-1-steen.hegelund@microchip.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 11 11月, 2020 1 次提交
-
-
由 Heiner Kallweit 提交于
The RTL8401-internal PHY identifies as RTL8201CP, and the init sequence in r8169, copied from vendor driver r8168, uses paged operations. Therefore set the same paged operation callbacks as for the other Realtek PHY's. Fixes: cdafdc29 ("r8169: sync support for RTL8401 with vendor driver") Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/69882f7a-ca2f-e0c7-ae83-c9b6937282cd@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 03 11月, 2020 1 次提交
-
-
由 YueHaibing 提交于
gpiod_to_irq() never return 0, but returns negative in case of error, check it and set gpio_irq to 0. Fixes: 73970055 ("sfp: add SFP module support") Signed-off-by: NYueHaibing <yuehaibing@huawei.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20201031031053.25264-1-yuehaibing@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 05 10月, 2020 1 次提交
-
-
由 Jisheng Zhang 提交于
Convert m88e1318_get_wol() to use the well implemented phy_read_paged() instead of open coding it. Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com> Reviewed-by: NMarek Behún <kabel@kernel.org> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 04 10月, 2020 1 次提交
-
-
由 Colin Ian King 提交于
Currently the comparisons of u16 integers value and sopass_val with less than zero for error checking is always false because the values are unsigned. Fix this by making these variables int. This does not affect the shift and mask operations performed on these variables Addresses-Coverity: ("Unsigned compared against zero") Fixes: 49fc2301 ("net: phy: dp83869: support Wake on LAN") Signed-off-by: NColin Ian King <colin.king@canonical.com> Acked-by: NDan Murphy <dmurphy@ti.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 02 10月, 2020 1 次提交
-
-
由 Willy Liu 提交于
Realtek single-chip Ethernet PHY solutions can be separated as below: 10M/100Mbps: RTL8201X 1Gbps: RTL8211X 2.5Gbps: RTL8226/RTL8221X RTL8226 is the first version for realtek that compatible 2.5Gbps single PHY. Since RTL8226 is single port only, realtek changes its name to RTL8221B from the second version. PHY ID for RTL8226 is 0x001cc800 and RTL8226B/RTL8221B is 0x001cc840. RTL8125 is not a single PHY solution, it integrates PHY/MAC/PCIE bus controller and embedded memory. Signed-off-by: NWilly Liu <willy.liu@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 30 9月, 2020 2 次提交
-
-
in_interrupt() is ill defined and does not provide what the name suggests. The usage especially in driver code is deprecated and a tree wide effort to clean up and consolidate the (ab)usage of in_interrupt() and related checks is happening. In this case the check covers only parts of the contexts in which these functions cannot be called. It fails to detect preemption or interrupt disabled invocations. As the functions which contain these warnings invoke mutex_lock() which contains a broad variety of checks (always enabled or debug option dependent) and therefore covers all invalid conditions already, there is no point in having inconsistent warnings in those drivers. The conditional return is not really valuable in practice either. Just remove them. Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Willy Liu 提交于
There are two chip pins named TXDLY and RXDLY which actually adds the 2ns delays to TXC and RXC for TXD/RXD latching. These two pins can config via 4.7k-ohm resistor to 3.3V hw setting, but also config via software setting (extension page 0xa4 register 0x1c bit13 12 and 11). The configuration register definitions from table 13 official PHY datasheet: PHYAD[2:0] = PHY Address AN[1:0] = Auto-Negotiation Mode = Interface Mode Select RX Delay = RX Delay TX Delay = TX Delay SELRGV = RGMII/GMII Selection This table describes how to config these hw pins via external pull-high or pull- low resistor. It is a misunderstanding that mapping it as register bits below: 8:6 = PHY Address 5:4 = Auto-Negotiation 3 = Interface Mode Select 2 = RX Delay 1 = TX Delay 0 = SELRGV So I removed these descriptions above and add related settings as below: 14 = reserved 13 = force Tx RX Delay controlled by bit12 bit11 12 = Tx Delay 11 = Rx Delay 10:0 = Test && debug settings reserved by realtek Test && debug settings are not recommend to modify by default. Fixes: f81dadbc ("net: phy: realtek: Add rtl8211e rx/tx delays config") Signed-off-by: NWilly Liu <willy.liu@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 29 9月, 2020 3 次提交
-
-
由 Wang Qing 提交于
Use kobj_to_dev() instead of container_of(). Signed-off-by: NWang Qing <wangqing@vivo.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Murphy 提交于
Set the speed optimization bit on the DP83869 PHY. Speed optimization, also known as link downshift, enables fallback to 100M operation after multiple consecutive failed attempts at Gigabit link establishment. Such a case could occur if cabling with only four wires (two twisted pairs) were connected instead of the standard cabling with eight wires (four twisted pairs). The number of failed link attempts before falling back to 100M operation is configurable. By default, four failed link attempts are required before falling back to 100M. Signed-off-by: NDan Murphy <dmurphy@ti.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Murphy 提交于
This adds WoL support on TI DP83869 for magic, magic secure, unicast and broadcast. Signed-off-by: NDan Murphy <dmurphy@ti.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 28 9月, 2020 1 次提交
-
-
由 Randy Dunlap 提交于
Fix build error by selecting MDIO_DEVRES for MDIO_THUNDER. Fixes this build error: ld: drivers/net/phy/mdio-thunder.o: in function `thunder_mdiobus_pci_probe': drivers/net/phy/mdio-thunder.c:78: undefined reference to `devm_mdiobus_alloc_size' Fixes: 379d7ac7 ("phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses.") Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: netdev@vger.kernel.org Cc: David Daney <david.daney@cavium.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 24 9月, 2020 1 次提交
-
-
由 Andrew Lunn 提交于
Add kerneldoc for the core PHY data structures, a few inline functions and exported functions which are not already documented. v2 Typos g/phy/PHY/s Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 22 9月, 2020 2 次提交
-
-
由 Florian Fainelli 提交于
BCM72113 features a 28nm integrated EPHY, add an entry to the driver for it. Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jisheng Zhang 提交于
Enable ALDPS(Advanced Link Down Power Saving) to save power when link down. Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 20 9月, 2020 1 次提交
-
-
由 Dan Murphy 提交于
Update the fiber advertisement for speed and duplex modes with the 100base-FX full and half linkmode entries. Signed-off-by: NDan Murphy <dmurphy@ti.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-