kernel/drivers/net/phy/phy.c, branch linux-4.16.y

net: phy: Tell caller result of phy_change()

2018-03-12T14:33:07Z

In 664fcf123a30e (net: phy: Threaded interrupts allow some simplification) the phy_interrupt system was changed to use a traditional threaded interrupt scheme instead of a workqueue approach. With this change, the phy status check moved into phy_change, which did not report back to the caller whether or not the interrupt was handled. This means that, in the case of a shared phy interrupt, only the first phydev's interrupt registers are checked (since phy_interrupt() would always return IRQ_HANDLED). This leads to interrupt storms when it is a secondary device that's actually the interrupt source. Signed-off-by: Brad Mouring Signed-off-by: David S. Miller

net: phy: Restore phy_resume() locking assumption

2018-02-27T19:32:09Z

commit f5e64032a799 ("net: phy: fix resume handling") changes the locking semantics for phy_resume() such that the caller now needs to hold the phy mutex. Not all call sites were adopted to this new semantic, resulting in warnings from the added WARN_ON(!mutex_is_locked(&phydev->lock)). Rather than change the semantics, add a __phy_resume() and restore the old behavior of phy_resume(). Reported-by: Heiner Kallweit Fixes: f5e64032a799 ("net: phy: fix resume handling") Signed-off-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller

net: phy: fix phy_start to consider PHY_IGNORE_INTERRUPT

2018-02-08T20:35:51Z

This condition wasn't adjusted when PHY_IGNORE_INTERRUPT (-2) was added long ago. In case of PHY_IGNORE_INTERRUPT the MAC interrupt indicates also PHY state changes and we should do what the symbol says. Fixes: 84a527a41f38 ("net: phylib: fix interrupts re-enablement in phy_start") Signed-off-by: Heiner Kallweit Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller

net: phy: remove parameter new_link from phy_mac_interrupt()

2018-01-15T18:45:03Z

I see two issues with parameter new_link: 1. It's not needed. See also phy_interrupt(), works w/o this parameter. phy_mac_interrupt sets the state to PHY_CHANGELINK and triggers the state machine which then calls phy_read_status. And phy_read_status updates the link state. 2. phy_mac_interrupt is used in interrupt context and getting the link state may sleep (at least when having to access the PHY registers via MDIO bus). So let's remove it. Signed-off-by: Heiner Kallweit Reviewed-by: Florian Fainelli Tested-by: Florian Fainelli Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2017-12-17T03:11:55Z

Three sets of overlapping changes, two in the packet scheduler and one in the meson-gxl PHY driver. Signed-off-by: David S. Miller

net: phy: fix resume handling

2017-12-13T20:00:10Z

When a PHY has the BMCR_PDOWN bit set, it may decide to ignore writes to other registers, or reset the registers to power-on defaults. Micrel PHYs do this for their interrupt registers. The current structure of phylib tries to enable interrupts before resuming (and releasing) the BMCR_PDOWN bit. This fails, causing Micrel PHYs to stop working after a suspend/resume sequence if they are using interrupts. Fix this by ensuring that the PHY driver resume methods do not take the phydev->lock mutex themselves, but the callers of phy_resume() take that lock. This then allows us to move the call to phy_resume() before we enable interrupts in phy_start(). Signed-off-by: Russell King Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller

net: phy: core: don't disable device interrupts in phy_change

2017-12-04T15:23:42Z

If state is not PHY_HALTED I see no need to temporarily disable interrupts on the device. As long as the current interrupt isn't acked on the device no new interrupt can happen anyway. In addition remove a unneeded enabling of interrupts in the state machine when handling state PHY_CHANGELINK. Tested on a Odroid-C2 with RTL8211F phy in interrupt mode. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller

net: phy: core: remove now uneeded disabling of interrupts

2017-12-04T15:23:41Z

After commits c974bdbc3e "net: phy: Use threaded IRQ, to allow IRQ from sleeping devices" and 664fcf123a30 "net: phy: Threaded interrupts allow some simplification" all relevant code pieces run in process context anyway and I don't think we need the disabling of interrupts any longer. Interestingly enough, latter commit already removed the comment explaining why interrupts need to be temporarily disabled. On my system phy interrupt mode works fine with this patch. However I may miss something, especially in the context of shared phy interrupts, therefore I'd appreciate if more people could test this. Signed-off-by: Heiner Kallweit Acked-by: Ard Biesheuvel Signed-off-by: David S. Miller

net: phy: core: use genphy version of callbacks read_status and config_aneg per default

2017-12-01T20:42:21Z

read_status and config_aneg are the only mandatory callbacks and most of the time the generic implementation is used by drivers. So make the core fall back to the generic version if a driver doesn't implement the respective callback. Also currently the core doesn't seem to verify that drivers implement the mandatory calls. If a driver doesn't do so we'd just get a NPE. With this patch this potential issue doesn't exit any longer. Signed-off-by: Heiner Kallweit Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller

net: phy: Keep reporting transceiver type

2017-09-21T22:20:40Z

With commit 2d55173e71b0 ("phy: add generic function to support ksetting support"), we lost the ability to report the transceiver type like we used to. Now that we have added back the transceiver type to ethtool_link_settings, we can report it back like we used to and have no loss of information. Fixes: 3f1ac7a700d0 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API") Fixes: 2d55173e71b0 ("phy: add generic function to support ksetting support") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller