linux.git/drivers/net/phy/realtek.c, branch v5.8

net: phy: realtek: add delay to resume path of certain internal PHY's

2020-04-20T18:12:29+00:00

Internal PHY's from RTL8168h up may not be instantly ready after calling
genphy_resume(). So far r8169 network driver adds the needed delay, but
better handle this in the PHY driver. The network driver may miss other
places where the PHY is resumed.

Signed-off-by: Heiner Kallweit 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller

net: phy: realtek: read actual speed to detect downshift

2020-03-19T00:05:34+00:00

At least some integrated PHY's in RTL8168/RTL8125 chip versions support
downshift, and the actual link speed can be read from a vendor-specific
register. Info about this register was provided by Realtek.
More details about downshift configuration (e.g. number of attempts)
aren't available, therefore the downshift tunable is not implemented.

Signed-off-by: Heiner Kallweit 
Signed-off-by: David S. Miller

net: phy: realtek: add support for configuring the RX delay on RTL8211F

2019-12-26T21:22:17+00:00

On RTL8211F the RX and TX delays (2ns) can be configured in two ways:
- pin strapping (RXD1 for the TX delay and RXD0 for the RX delay, LOW
  means "off" and HIGH means "on") which is read during PHY reset
- using software to configure the TX and RX delay registers

So far only the configuration using pin strapping has been supported.
Add support for enabling or disabling the RGMII RX delay based on the
phy-mode to be able to get the RX delay into a known state. This is
important because the RX delay has to be coordinated between the PHY,
MAC and the PCB design (trace length). With an invalid RX delay applied
(for example if both PHY and MAC add a 2ns RX delay) Ethernet may not
work at all.

Also add debug logging when configuring the RX delay (just like the TX
delay) because this is a common source of problems.

Signed-off-by: Martin Blumenstingl 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller

net: phy: realtek: add logging for the RGMII TX delay configuration

2019-12-26T21:22:17+00:00

RGMII requires a delay of 2ns between the data and the clock signal.
There are at least three ways this can happen. One possibility is by
having the PHY generate this delay.
This is a common source for problems (for example with slow TX speeds or
packet loss when sending data). The TX delay configuration of the
RTL8211F PHY can be set either by pin-strappping the RXD1 pin (HIGH
means enabled, LOW means disabled) or through configuring a paged
register. The setting from the RXD1 pin is also reflected in the
register.

Add debug logging to the TX delay configuration on RTL8211F so it's
easier to spot these issues (for example if the TX delay is enabled for
both, the RTL8211F PHY and the MAC).
This is especially helpful because there is no public datasheet for the
RTL8211F PHY available with all the RX/TX delay specifics.

Signed-off-by: Martin Blumenstingl 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller

net: phy: realtek: fix using paged operations with RTL8105e / RTL8208

2019-12-01T21:14:21+00:00

It was reported [0] that since the referenced commit a warning is
triggered in phylib that complains about paged operations being used
with a PHY driver that doesn't support this. The commit isn't wrong,
just for one chip version (RTL8105e) no dedicated PHY driver exists
yet. So add the missing PHY driver.

[0] https://bugzilla.kernel.org/show_bug.cgi?id=202103

Fixes: 3a129e3f9ac4 ("r8169: switch to phylib functions in more places")
Reported-by: jhdskag3 
Tested-by: jhdskag3 
Signed-off-by: Heiner Kallweit 
Signed-off-by: David S. Miller

net: phy: realtek: support NBase-T MMD EEE registers on RTL8125

2019-08-19T20:04:45+00:00

Emulate the 802.3bz MMD EEE registers for 2.5Gbps EEE on RTL8125.

Signed-off-by: Heiner Kallweit 
Signed-off-by: David S. Miller

net: phy: realtek: add support for EEE registers on integrated PHY's

2019-08-15T18:48:30+00:00

EEE-related registers on newer integrated PHY's have the standard
layout, but are accessible not via MMD but via vendor-specific
registers. Emulating the standard MMD registers allows to use the
generic functions for EEE control.

Signed-off-by: Heiner Kallweit 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller

net: phy: realtek: add NBase-T PHY auto-detection

2019-08-14T17:26:08+00:00

Realtek provided information on how the new NIC-integrated PHY's
expose whether they support 2.5G/5G/10G. This allows to automatically
differentiate 1Gbps and 2.5Gbps PHY's, and therefore allows to
remove the fake PHY ID mechanism for RTL8125.
So far RTL8125 supports 2.5Gbps only, but register layout for faster
modes has been defined already, so let's use this information to be
future-proof.

Signed-off-by: Heiner Kallweit 
Signed-off-by: David S. Miller

net: phy: realtek: add support for the 2.5Gbps PHY in RTL8125

2019-08-12T04:24:32+00:00

This adds support for the integrated 2.5Gbps PHY in Realtek RTL8125.
Advertisement of 2.5Gbps mode is done via a vendor-specific register.
Same applies to reading NBase-T link partner advertisement.
Unfortunately this 2.5Gbps PHY shares the PHY ID with the integrated
1Gbps PHY's in other Realtek network chips and so far no method is
known to differentiate them. As a workaround use a dedicated fake PHY ID
that is set by the network driver by intercepting the MDIO PHY ID read.

v2:
- Create dedicated PHY driver and use a fake PHY ID that is injected by
  the network driver. Suggested by Andrew Lunn.

Signed-off-by: Heiner Kallweit 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller

net: phy: realtek: Replace phy functions with non-locked version in rtl8211e_config_init()

2019-05-13T16:10:39+00:00

After calling phy_select_page() and until calling phy_restore_page(),
the mutex 'mdio_lock' is already locked, so the driver should use
non-locked version of phy functions. Or there will be a deadlock with
'mdio_lock'.

This replaces phy functions called from rtl8211e_config_init() to avoid
the deadlock issue.

Fixes: f81dadbcf7fd ("net: phy: realtek: Add rtl8211e rx/tx delays config")
Signed-off-by: Kunihiko Hayashi 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller