linux/drivers/net/phy, branch v4.20

net: phy: Fix the issue that netif always links up after resuming

2018-12-19T05:48:15Z

Even though the link is down before entering hibernation, there is an issue that the network interface always links up after resuming from hibernation. If the link is still down before enabling the network interface, and after resuming from hibernation, the phydev->state is forcibly set to PHY_UP in mdio_bus_phy_restore(), and the link becomes up. In suspend sequence, only if the PHY is attached, mdio_bus_phy_suspend() calls phy_stop_machine(), and mdio_bus_phy_resume() calls phy_start_machine(). In resume sequence, it's enough to do the same as mdio_bus_phy_resume() because the state has been preserved. This patch fixes the issue by calling phy_start_machine() in mdio_bus_phy_restore() in the same way as mdio_bus_phy_resume(). Fixes: bc87922ff59d ("phy: Move PHY PM operations into phy_device") Suggested-by: Heiner Kallweit Signed-off-by: Kunihiko Hayashi Signed-off-by: David S. Miller

phy: Revert toggling reset changes.

2018-12-04T16:47:44Z

This reverts: ef1b5bf506b1 ("net: phy: Fix not to call phy_resume() if PHY is not attached") 8c85f4b81296 ("net: phy: micrel: add toggling phy reset if PHY is not attached") Andrew Lunn informs me that there are alternative efforts underway to fix this more properly. Signed-off-by: David S. Miller

net: phy: micrel: add toggling phy reset if PHY is not attached

2018-12-03T23:20:18Z

This patch adds toggling phy reset if PHY is not attached. Otherwise, some boards (e.g. R-Car H3 Salvator-XS) cannot link up correctly if we do the following method: 1) Kernel boots by using initramfs. --> No open the nic, so phy_device_register() and phy_probe() deasserts the reset. 2) Kernel enters the suspend. --> So, keep the reset signal as deassert. --> On R-Car Salvator-XS board, unfortunately, the board power is turned off. 3) Kernel returns from suspend. 4) ifconfig eth0 up --> Then, since edge signal of the reset doesn't happen, it cannot link up. 5) ifconfig eth0 down 6) ifconfig eth0 up --> In this case, it can link up. Reported-by: Hiromitsu Yamasaki Signed-off-by: Yoshihiro Shimoda Signed-off-by: David S. Miller

net: phy: Fix not to call phy_resume() if PHY is not attached

2018-12-03T23:20:18Z

This patch fixes an issue that mdio_bus_phy_resume() doesn't call phy_resume() if the PHY is not attached. Fixes: 803dd9c77ac3 ("net: phy: avoid suspending twice a PHY") Signed-off-by: Yoshihiro Shimoda Signed-off-by: David S. Miller

net: phy: don't allow __set_phy_supported to add unsupported modes

2018-12-03T21:50:38Z

Currently __set_phy_supported allows to add modes w/o checking whether the PHY supports them. This is wrong, it should never add modes but only remove modes we don't want to support. The commit marked as fixed didn't do anything wrong, it just copied existing functionality to the helper which is being fixed now. Fixes: f3a6bd393c2c ("phylib: Add phy_set_max_speed helper") Signed-off-by: Heiner Kallweit Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller

net: phy: sfp: correct store of detected link modes

2018-11-29T18:47:44Z

The link modes that sfp_parse_support() detects are stored in the 'modes' bitmap. There is no reason to make an exception for 1000Base-PX or 1000Base-BX10. Fixes: 03145864bd0f ("sfp: support 1G BiDi (eg, FiberStore SFP-GE-BX) modules") Signed-off-by: Baruch Siach Acked-by: Russell King Signed-off-by: David S. Miller

net: phy: add workaround for issue where PHY driver doesn't bind to the device

2018-11-27T23:00:24Z

After switching the r8169 driver to use phylib some user reported that their network is broken. This was caused by the genphy PHY driver being used instead of the dedicated PHY driver for the RTL8211B. Users reported that loading the Realtek PHY driver module upfront fixes the issue. See also this mail thread: https://marc.info/?t=154279781800003&r=1&w=2 The issue is quite weird and the root cause seems to be somewhere in the base driver core. The patch works around the issue and may be removed once the actual issue is fixed. The Fixes tag refers to the first reported occurrence of the issue. The issue itself may have been existing much longer and it may affect users of other network chips as well. Users typically will recognize this issue only if their PHY stops working when being used with the genphy driver. Fixes: f1e911d5d0df ("r8169: add basic phylib support") Signed-off-by: Heiner Kallweit Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller

net: phy: mscc: fix deadlock in vsc85xx_default_config

2018-11-24T06:34:40Z

The vsc85xx_default_config function called in the vsc85xx_config_init function which is used by VSC8530, VSC8531, VSC8540 and VSC8541 PHYs mistakenly calls phy_read and phy_write in-between phy_select_page and phy_restore_page. phy_select_page and phy_restore_page actually take and release the MDIO bus lock and phy_write and phy_read take and release the lock to write or read to a PHY register. Let's fix this deadlock by using phy_modify_paged which handles correctly a read followed by a write in a non-standard page. Fixes: 6a0bfbbe20b0 ("net: phy: mscc: migrate to phy_select/restore_page functions") Signed-off-by: Quentin Schulz Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller

net: phy: mdio-gpio: Fix working over slow can_sleep GPIOs

2018-11-18T05:11:51Z

Up until commit 7e5fbd1e0700 ("net: mdio-gpio: Convert to use gpiod functions where possible"), the _cansleep variants of the gpio_ API was used. After that commit and the change to gpiod_ API, the _cansleep() was dropped. This then results in WARN_ON() when used with GPIO devices which do sleep. Add back the _cansleep() to avoid this. Fixes: 7e5fbd1e0700 ("net: mdio-gpio: Convert to use gpiod functions where possible") Signed-off-by: Martin Schiller Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller

Revert "net: phy: mdio-gpio: Fix working over slow can_sleep GPIOs"

2018-11-17T07:04:37Z

This reverts commit dfa0d55ff6be64e7b6881212a291cb95f8da3b08. Discussion still ongoing, I shouldn't have applied this. Signed-off-by: David S. Miller