linux/drivers/net/phy, branch v6.0

net: phy: Don't WARN for PHY_UP state in mdio_bus_phy_resume()

2022-09-27T08:48:38Z

Commit 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state") introduced a WARN() on resume from system sleep if a PHY is not in PHY_HALTED state. Commit 6dbe852c379f ("net: phy: Don't WARN for PHY_READY state in mdio_bus_phy_resume()") added an exemption for PHY_READY state from the WARN(). It turns out PHY_UP state needs to be exempted as well because the following may happen on suspend: mdio_bus_phy_suspend() phy_stop_machine() phydev->state = PHY_UP # if (phydev->state >= PHY_UP) Fixes: 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state") Reported-by: Marek Szyprowski Tested-by: Marek Szyprowski Link: https://lore.kernel.org/netdev/2b1a1588-505e-dff3-301d-bfc1fb14d685@samsung.com/ Signed-off-by: Lukas Wunner Acked-by: Florian Fainelli Cc: Xiaolei Wang Link: https://lore.kernel.org/r/8128fdb51eeebc9efbf3776a4097363a1317aaf1.1663905575.git.lukas@wunner.de Signed-off-by: Paolo Abeni

net: phy: micrel: fix shared interrupt on LAN8814

2022-09-22T13:36:32Z

Since commit ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy") the handler always returns IRQ_HANDLED, except in an error case. Before that commit, the interrupt status register was checked and if it was empty, IRQ_NONE was returned. Restore that behavior to play nice with the interrupt line being shared with others. Fixes: ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy") Signed-off-by: Michael Walle Reviewed-by: Andrew Lunn Reviewed-by: Horatiu Vultur Reviewed-by: Divya Koppera Link: https://lore.kernel.org/r/20220920141619.808117-1-michael@walle.cc Signed-off-by: Jakub Kicinski

net: phy: aquantia: wait for the suspend/resume operations to finish

2022-09-13T07:55:34Z

The Aquantia datasheet notes that after issuing a Processor-Intensive MDIO operation, like changing the low-power state of the device, the driver should wait for the operation to finish before issuing a new MDIO command. The new aqr107_wait_processor_intensive_op() function is added which can be used after these kind of MDIO operations. At the moment, we are only adding it at the end of the suspend/resume calls. The issue was identified on a board featuring the AQR113C PHY, on which commands like 'ip link (..) up / down' issued without any delays between them would render the link on the PHY to remain down. The issue was easy to reproduce with a one-liner: $ ip link set dev ethX down; ip link set dev ethX up; \ ip link set dev ethX down; ip link set dev ethX up; Fixes: ac9e81c230eb ("net: phy: aquantia: add suspend / resume callbacks for AQR107 family") Signed-off-by: Ioana Ciornei Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20220906130451.1483448-1-ioana.ciornei@nxp.com Signed-off-by: Paolo Abeni

net: phy: lan87xx: change interrupt src of link_up to comm_ready

2022-09-08T09:02:44Z

Currently phy link up/down interrupt is enabled using the LAN87xx_INTERRUPT_MASK register. In the lan87xx_read_status function, phy link is determined using the T1_MODE_STAT_REG register comm_ready bit. comm_ready bit is set using the loc_rcvr_status & rem_rcvr_status. Whenever the phy link is up, LAN87xx_INTERRUPT_SOURCE link_up bit is set first but comm_ready bit takes some time to set based on local and remote receiver status. As per the current implementation, interrupt is triggered using link_up but the comm_ready bit is still cleared in the read_status function. So, link is always down. Initially tested with the shared interrupt mechanism with switch and internal phy which is working, but after implementing interrupt controller it is not working. It can fixed either by updating the read_status function to read from LAN87XX_INTERRUPT_SOURCE register or enable the interrupt mask for comm_ready bit. But the validation team recommends the use of comm_ready for link detection. This patch fixes by enabling the comm_ready bit for link_up in the LAN87XX_INTERRUPT_MASK_2 register (MISC Bank) and link_down in LAN87xx_INTERRUPT_MASK register. Fixes: 8a1b415d70b7 ("net: phy: added ethtool master-slave configuration support") Signed-off-by: Arun Ramadoss Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20220905152750.5079-1-arun.ramadoss@microchip.com Signed-off-by: Paolo Abeni

Revert "net: phy: meson-gxl: improve link-up behavior"

2022-09-02T03:55:12Z

This reverts commit 2c87c6f9fbddc5b84d67b2fa3f432fcac6d99d93. Meanwhile it turned out that the following commit is the proper workaround for the issue that 2c87c6f9fbdd tries to address. a3a57bf07de2 ("net: stmmac: work around sporadic tx issue on link-up") It's nor clear why the to be reverted commit helped for one user, for others it didn't make a difference. Fixes: 2c87c6f9fbdd ("net: phy: meson-gxl: improve link-up behavior") Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/8deeeddc-6b71-129b-1918-495a12dc11e3@gmail.com Signed-off-by: Jakub Kicinski

net: phy: micrel: Make the GPIO to be non-exclusive

2022-08-31T05:49:50Z

The same GPIO line can be shared by multiple phys for the coma mode pin. If that is the case then, all the other phys that share the same line will failed to be probed because the access to the gpio line is not non-exclusive. Fix this by making access to the gpio line to be nonexclusive using flag GPIOD_FLAGS_BIT_NONEXCLUSIVE. This allows all the other PHYs to be probed. Fixes: 738871b09250ee ("net: phy: micrel: add coma mode GPIO") Reviewed-by: Andrew Lunn Signed-off-by: Horatiu Vultur Link: https://lore.kernel.org/r/20220830064055.2340403-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski

net: phy: Don't WARN for PHY_READY state in mdio_bus_phy_resume()

2022-08-23T01:14:10Z

For some MAC drivers, they set the mac_managed_pm to true in its ->ndo_open() callback. So before the mac_managed_pm is set to true, we still want to leverage the mdio_bus_phy_suspend()/resume() for the phy device suspend and resume. In this case, the phy device is in PHY_READY, and we shouldn't warn about this. It also seems that the check of mac_managed_pm in WARN_ON is redundant since we already check this in the entry of mdio_bus_phy_resume(), so drop it. Fixes: 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state") Signed-off-by: Xiaolei Wang Acked-by: Florian Fainelli Link: https://lore.kernel.org/r/20220819082451.1992102-1-xiaolei.wang@windriver.com Signed-off-by: Jakub Kicinski

net: phy: dp83867: fix get nvmem cell fail

2022-08-09T03:57:03Z

If CONFIG_NVMEM is not set of_nvmem_cell_get, of_nvmem_device_get functions will return ERR_PTR(-EOPNOTSUPP) and "failed to get nvmem cell io_impedance_ctrl" error would be reported despite "io_impedance_ctrl" is completely missing in Device Tree and we should use default values. Check -EOPNOTSUPP togather with -ENOENT to avoid this situation. Fixes: 5c2d0a6a0701 ("net: phy: dp83867: implement support for io_impedance_ctrl nvmem cell") Signed-off-by: Nikita Shubin Acked-by: Rasmus Villemoes Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20220805084843.24542-1-nikita.shubin@maquefel.me Signed-off-by: Jakub Kicinski

net: phy: c45 baset1: do not skip aneg configuration if clock role is not specified

2022-08-09T03:54:28Z

In case master/slave clock role is not specified (which is default), the aneg registers will not be written. The visible impact of this is missing pause advertisement. So, rework genphy_c45_baset1_an_config_aneg() to be able to write advertisement registers even if clock role is unknown. Fixes: 3da8ffd8545f ("net: phy: Add 10BASE-T1L support in phy-c45") Signed-off-by: Oleksij Rempel Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20220805073159.908643-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski

net: phy: Warn about incorrect mdio_bus_phy_resume() state

2022-08-04T02:20:41Z

Calling mdio_bus_phy_resume() with neither the PHY state machine set to PHY_HALTED nor phydev->mac_managed_pm set to true is a good indication that we can produce a race condition looking like this: CPU0 CPU1 bcmgenet_resume -> phy_resume -> phy_init_hw -> phy_start -> phy_resume phy_start_aneg() mdio_bus_phy_resume -> phy_resume -> phy_write(..., BMCR_RESET) -> usleep() -> phy_read() with the phy_resume() function triggering a PHY behavior that might have to be worked around with (see bf8bfc4336f7 ("net: phy: broadcom: Fix brcm_fet_config_init()") for instance) that ultimately leads to an error reading from the PHY. Fixes: fba863b81604 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM") Signed-off-by: Florian Fainelli Link: https://lore.kernel.org/r/20220801233403.258871-1-f.fainelli@gmail.com Signed-off-by: Jakub Kicinski