linux-stable.git/drivers/net/phy, branch v5.16.2

Revert "net: phy: fixed_phy: Fix NULL vs IS_ERR() checking in __fixed_phy_register"

2022-01-04T02:59:16+00:00

This reverts commit b45396afa4177f2b1ddfeff7185da733fade1dc3 ("net: phy:
fixed_phy: Fix NULL vs IS_ERR() checking in __fixed_phy_register")
since it prevents any system that uses a fixed PHY without a GPIO
descriptor from properly working:

[    5.971952] brcm-systemport 9300000.ethernet: failed to register fixed PHY
[    5.978854] brcm-systemport: probe of 9300000.ethernet failed with error -22
[    5.986047] brcm-systemport 9400000.ethernet: failed to register fixed PHY
[    5.992947] brcm-systemport: probe of 9400000.ethernet failed with error -22

Fixes: b45396afa417 ("net: phy: fixed_phy: Fix NULL vs IS_ERR() checking in __fixed_phy_register")
Signed-off-by: Florian Fainelli 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/20220103193453.1214961-1-f.fainelli@gmail.com
Signed-off-by: Jakub Kicinski

net: phy: fixed_phy: Fix NULL vs IS_ERR() checking in __fixed_phy_register

2021-12-24T22:52:10+00:00

The fixed_phy_get_gpiod function() returns NULL, it doesn't return error
pointers, using NULL checking to fix this.i

Fixes: 5468e82f7034 ("net: phy: fixed-phy: Drop GPIO from fixed_phy_add()")
Signed-off-by: Miaoqian Lin 
Link: https://lore.kernel.org/r/20211224021500.10362-1-linmq006@gmail.com
Signed-off-by: Jakub Kicinski

net: phy: add a note about refcounting

2021-12-13T14:58:07+00:00

Recently, a patch has been submitted to "fix" the refcounting for a DT
node in of_mdiobus_link_mdiodev(). This is not a leaked refcount. The
refcount is passed to the new device.

Sadly, coccicheck identifies this location as a leaked refcount, which
means we're likely to keep getting patches to "fix" this. However,
fixing this will cause breakage. Add a comment to state that the lack
of of_node_put() here is intentional.

Signed-off-by: Russell King (Oracle) 
Signed-off-by: David S. Miller

net: phy: Add the missing blank line in the phylink_suspend comment

2021-12-08T05:26:22+00:00

Fix warning as:

Documentation/networking/kapi:147: ./drivers/net/phy/phylink.c:1657: WARNING: Unexpected indentation.
Documentation/networking/kapi:147: ./drivers/net/phy/phylink.c:1658: WARNING: Block quote ends without a blank line; unexpected unindent.

Signed-off-by: Yanteng Si 
Signed-off-by: Jakub Kicinski

net: phylink: Force retrigger in case of latched link-fail indicator

2021-11-25T02:40:07+00:00

On mv88e6xxx 1G/2.5G PCS, the SerDes register 4.2001.2 has the following
description:
  This register bit indicates when link was lost since the last
  read. For the current link status, read this register
  back-to-back.

Thus to get current link state, we need to read the register twice.

But doing that in the link change interrupt handler would lead to
potentially ignoring link down events, which we really want to avoid.

Thus this needs to be solved in phylink's resolve, by retriggering
another resolve in the event when PCS reports link down and previous
link was up, and by re-reading PCS state if the previous link was down.

The wrong value is read when phylink requests change from sgmii to
2500base-x mode, and link won't come up. This fixes the bug.

Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Marek Behún 
Signed-off-by: Jakub Kicinski

net: phylink: Force link down and retrigger resolve on interface change

2021-11-25T02:40:06+00:00

On PHY state change the phylink_resolve() function can read stale
information from the MAC and report incorrect link speed and duplex to
the kernel message log.

Example with a Marvell 88X3310 PHY connected to a SerDes port on Marvell
88E6393X switch:
- PHY driver triggers state change due to PHY interface mode being
  changed from 10gbase-r to 2500base-x due to copper change in speed
  from 10Gbps to 2.5Gbps, but the PHY itself either hasn't yet changed
  its interface to the host, or the interrupt about loss of SerDes link
  hadn't arrived yet (there can be a delay of several milliseconds for
  this), so we still think that the 10gbase-r mode is up
- phylink_resolve()
  - phylink_mac_pcs_get_state()
    - this fills in speed=10g link=up
  - interface mode is updated to 2500base-x but speed is left at 10Gbps
  - phylink_major_config()
    - interface is changed to 2500base-x
  - phylink_link_up()
    - mv88e6xxx_mac_link_up()
      - .port_set_speed_duplex()
        - speed is set to 10Gbps
    - reports "Link is Up - 10Gbps/Full" to dmesg

Afterwards when the interrupt finally arrives for mv88e6xxx, another
resolve is forced in which we get the correct speed from
phylink_mac_pcs_get_state(), but since the interface is not being
changed anymore, we don't call phylink_major_config() but only
phylink_mac_config(), which does not set speed/duplex anymore.

To fix this, we need to force the link down and trigger another resolve
on PHY interface change event.

Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Marek Behún 
Signed-off-by: Jakub Kicinski

net: phy: fix duplex out of sync problem while changing settings

2021-11-04T23:46:29+00:00

As reported by Zhang there's a small issue if in forced mode the duplex
mode changes with the link staying up [0]. In this case the MAC isn't
notified about the change.

The proposed patch relies on the phylib state machine and ignores the
fact that there are drivers that uses phylib but not the phylib state
machine. So let's don't change the behavior for such drivers and fix
it w/o re-adding state PHY_FORCING for the case that phylib state
machine is used.

[0] https://lore.kernel.org/netdev/a5c26ffd-4ee4-a5e6-4103-873208ce0dc5@huawei.com/T/

Fixes: 2bd229df5e2e ("net: phy: remove state PHY_FORCING")
Reported-by: Zhang Changzhong 
Tested-by: Zhang Changzhong 
Signed-off-by: Heiner Kallweit 
Link: https://lore.kernel.org/r/7b8b9456-a93f-abbc-1dc5-a2c2542f932c@gmail.com
Signed-off-by: Jakub Kicinski

net: phy: microchip_t1: add lan87xx_config_rgmii_delay for lan87xx phy

2021-11-03T00:16:27+00:00

Add a function to initialize phy rgmii delay according to phydev->interface.

Signed-off-by: Yuiko Oshino 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/20211101162119.29275-1-yuiko.oshino@microchip.com
Signed-off-by: Jakub Kicinski

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

2021-11-02T03:05:14+00:00

Merge in the fixes we had queued in case there was another -rc.

Signed-off-by: Jakub Kicinski

net: phylink: avoid mvneta warning when setting pause parameters

2021-10-29T12:29:30+00:00

mvneta does not support asymetric pause modes, and it flags this by the
lack of AsymPause in the supported field. When setting pause modes, we
check that pause->rx_pause == pause->tx_pause, but only when pause
autoneg is enabled. When pause autoneg is disabled, we still allow
pause->rx_pause != pause->tx_pause, which is incorrect when the MAC
does not support asymetric pause, and causes mvneta to issue a warning.

Fix this by removing the test for pause->autoneg, so we always check
that pause->rx_pause == pause->tx_pause for network devices that do not
support AsymPause.

Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: Russell King (Oracle) 
Signed-off-by: David S. Miller