linux.git/drivers/net/phy/micrel.c, branch v6.9

net: phy: micrel: lan8814: Fix when enabling/disabling 1-step timestamping

2024-04-04T02:23:17+00:00

There are 2 issues with the blamed commit.
1. When the phy is initialized, it would enable the disabled of UDPv4
   checksums. The UDPv6 checksum is already enabled by default. So when
   1-step is configured then it would clear these flags.
2. After the 1-step is configured, then if 2-step is configured then the
   1-step would be still configured because it is not clearing the flag.
   So the sync frames will still have origin timestamps set.

Fix this by reading first the value of the register and then
just change bit 12 as this one determines if the timestamp needs to
be inserted in the frame, without changing any other bits.

Fixes: ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy")
Signed-off-by: Horatiu Vultur 
Reviewed-by: Divya Koppera 
Link: https://lore.kernel.org/r/20240402071634.2483524-1-horatiu.vultur@microchip.com
Signed-off-by: Jakub Kicinski

net: phy: micrel: Fix potential null pointer dereference

2024-04-02T03:41:49+00:00

In lan8814_get_sig_rx() and lan8814_get_sig_tx() ptp_parse_header() may
return NULL as ptp_header due to abnormal packet type or corrupted packet.
Fix this bug by adding ptp_header check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy")
Signed-off-by: Aleksandr Mishin 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/20240329061631.33199-1-amishin@t-argos.ru
Signed-off-by: Jakub Kicinski

net: phy: micrel: lan8814 cable improvement errata

2024-03-05T19:17:46+00:00

When the length of the cable is more than 100m and the lan8814 is
configured to run in 1000Base-T Slave then the register of the device
needs to be optimized.

Workaround this by setting the measure time to a value of 0xb. This
value can be set regardless of the configuration.

This issue is described in 'LAN8814 Silicon Errata and Data Sheet
Clarification' and according to that, this will not be corrected in a
future silicon revision.

Reviewed-by: Wojciech Drewek 
Signed-off-by: Horatiu Vultur 
Reviewed-by: Andrew Lunn 
Acked-by: Arun Ramadoss 
Link: https://lore.kernel.org/r/20240304091548.1386022-3-horatiu.vultur@microchip.com
Signed-off-by: Jakub Kicinski

net: phy: micrel: lan8814 led errata

2024-03-05T19:17:46+00:00

Lan8814 phy led behavior is not correct. It was noticed that the led
still remains ON when the cable is unplugged while there was traffic
passing at that time.

The fix consists in clearing bit 10 of register 0x38, in this way the
led behaviour is correct and gets OFF when there is no link.

Reviewed-by: Wojciech Drewek 
Signed-off-by: Horatiu Vultur 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/20240304091548.1386022-2-horatiu.vultur@microchip.com
Signed-off-by: Jakub Kicinski

net: micrel: Fix the frequency adjustments

2024-02-04T13:34:19+00:00

By default lan8841's 1588 clock frequency is 125MHz. But when adjusting
the frequency, it is using the 1PPM format of the lan8814. Which is the
wrong format as lan8814 has a 1588 clock frequency of 250MHz. So then
for each 1PPM adjustment would adjust less than expected.
Therefore fix this by using the correct 1PPM format for lan8841.

Signed-off-by: Horatiu Vultur 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller

net: micrel: Fix set/get PHC time for lan8814

2024-01-30T11:08:16+00:00

When setting or getting PHC time, the higher bits of the second time (>32
bits) they were ignored. Meaning that setting some time in the future like
year 2150, it was failing to set this.

The issue can be reproduced like this:

 # phc_ctl /dev/ptp1 set 10000000000
 phc_ctl[12.290]: set clock time to 10000000000.000000000 or Sat Nov 20 17:46:40 2286

 # phc_ctl /dev/ptp1 get
 phc_ctl[15.309]: clock time is 1410065411.018055420 or Sun Sep  7 04:50:11 2014

Signed-off-by: Horatiu Vultur 
Reviewed-by: Maxime Chevallier 
Reviewed-by: Divya Koppera 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/20240126073042.1845153-1-horatiu.vultur@microchip.com
Signed-off-by: Paolo Abeni

net: micrel: Fix PTP frame parsing for lan8814

2024-01-22T11:02:23+00:00

The HW has the capability to check each frame if it is a PTP frame,
which domain it is, which ptp frame type it is, different ip address in
the frame. And if one of these checks fail then the frame is not
timestamp. Most of these checks were disabled except checking the field
minorVersionPTP inside the PTP header. Meaning that once a partner sends
a frame compliant to 8021AS which has minorVersionPTP set to 1, then the
frame was not timestamp because the HW expected by default a value of 0
in minorVersionPTP. This is exactly the same issue as on lan8841.
Fix this issue by removing this check so the userspace can decide on this.

Fixes: ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy")
Signed-off-by: Horatiu Vultur 
Reviewed-by: Maxime Chevallier 
Reviewed-by: Divya Koppera 
Signed-off-by: David S. Miller

net: phy: micrel: populate .soft_reset for KSZ9131

2024-01-12T11:09:12+00:00

The RZ/G3S SMARC Module has 2 KSZ9131 PHYs. In this setup, the KSZ9131 PHY
is used with the ravb Ethernet driver. It has been discovered that when
bringing the Ethernet interface down/up continuously, e.g., with the
following sh script:

$ while :; do ifconfig eth0 down; ifconfig eth0 up; done

the link speed and duplex are wrong after interrupting the bring down/up
operation even though the Ethernet interface is up. To recover from this
state the following configuration sequence is necessary (executed
manually):

$ ifconfig eth0 down
$ ifconfig eth0 up

The behavior has been identified also on the Microchip SAMA7G5-EK board
which runs the macb driver and uses the same PHY.

The order of PHY-related operations in ravb_open() is as follows:
ravb_open() ->
  ravb_phy_start() ->
    ravb_phy_init() ->
      of_phy_connect() ->
        phy_connect_direct() ->
	  phy_attach_direct() ->
	    phy_init_hw() ->
	      phydev->drv->soft_reset()
	      phydev->drv->config_init()
	      phydev->drv->config_intr()
	    phy_resume()
	      kszphy_resume()

The order of PHY-related operations in ravb_close is as follows:
ravb_close() ->
  phy_stop() ->
    phy_suspend() ->
      kszphy_suspend() ->
        genphy_suspend()
	  // set BMCR_PDOWN bit in MII_BMCR

In genphy_suspend() setting the BMCR_PDWN bit in MII_BMCR switches the PHY
to Software Power-Down (SPD) mode (according to the KSZ9131 datasheet).
Thus, when opening the interface after it has been  previously closed (via
ravb_close()), the phydev->drv->config_init() and
phydev->drv->config_intr() reach the KSZ9131 PHY driver via the
ksz9131_config_init() and kszphy_config_intr() functions.

KSZ9131 specifies that the MII management interface remains operational
during SPD (Software Power-Down), but (according to manual):
- Only access to the standard registers (0 through 31) is supported.
- Access to MMD address spaces other than MMD address space 1 is possible
  if the spd_clock_gate_override bit is set.
- Access to MMD address space 1 is not possible.

The spd_clock_gate_override bit is not used in the KSZ9131 driver.

ksz9131_config_init() configures RGMII delay, pad skews and LEDs by
accessesing MMD registers other than those in address space 1.

The datasheet for the KSZ9131 does not specify what happens if registers
from an unsupported address space are accessed while the PHY is in SPD.

To fix the issue the .soft_reset method has been instantiated for KSZ9131,
too. This resets the PHY to the default state before doing any
configurations to it, thus switching it out of SPD.

Fixes: bff5b4b37372 ("net: phy: micrel: add Microchip KSZ9131 initial driver")
Signed-off-by: Claudiu Beznea 
Reviewed-by: Maxime Chevallier 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller

net: micrel: Fix PTP frame parsing for lan8841

2024-01-12T11:08:08+00:00

The HW has the capability to check each frame if it is a PTP frame,
which domain it is, which ptp frame type it is, different ip address in
the frame. And if one of these checks fail then the frame is not
timestamp. Most of these checks were disabled except checking the field
minorVersionPTP inside the PTP header. Meaning that once a partner sends
a frame compliant to 8021AS which has minorVersionPTP set to 1, then the
frame was not timestamp because the HW expected by default a value of 0
in minorVersionPTP.
Fix this issue by removing this check so the userspace can decide on this.

Fixes: cafc3662ee3f ("net: micrel: Add PHC support for lan8841")
Signed-off-by: Horatiu Vultur 
Reviewed-by: Divya Koppera 
Reviewed-by: Rahul Rameshbabu 
Signed-off-by: David S. Miller

net: phy: micrel: allow usage of generic ethernet-phy clock

2023-12-04T22:43:55+00:00

The generic ethernet-phy binding allows describing an external clock since
commit 350b7a258f20 ("dt-bindings: net: phy: Document support for external PHY clk")
for cases where the phy is not supplied by an oscillator but instead
by a clock from the host system.

And the old named "rmii-ref" clock from 2014 is only specified for phys
of the KSZ8021, KSZ8031, KSZ8081, KSZ8091 types.

So allow retrieving and enabling the optional generic clock on phys that
do not provide a rmii-ref clock.

Signed-off-by: Heiko Stuebner 
Reviewed-by: Florian Fainelli 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/20231201150131.326766-3-heiko@sntech.de
Signed-off-by: Jakub Kicinski