[PATCH v2] realtek: do not reset SerDes on link change

Sander Vanheule sander at svanheule.net
Sun May 8 04:11:03 PDT 2022


Sorry I didn't get back to this any sooner.

On Wed, 2022-04-27 at 20:16 +0200, Birger Koblitz wrote:
> Hi,
> there are presently no working 1GBit SFP modules in master for RTL9300
> (this patch only affects RTL93xx SoCs). On the Ubiquiti USW switch
> only the 10GBit modules are set up by u-boot and they continue to work.
> The setup really only does a setup of the link not the entire serdes. The initial reset
> was done on initialization of the internal PHY associated with the SerDes
> via rtl9300_configure_serdes() calling rtl9300_sds_rst() during the PHY
> probe. So calling rtl9300_sds_rst() for every link change was anyway too much.
> Complete control over SFP+ ports to allow 10G, 1G, Copper modules, and
> DAC cables will only be available with the latest developments which were
> posted in the forum recently and should lead to a PR soon. For this to work
> the SerDes-MAC link needs to be switched and then this link re-calibrated
> which I only figured out recently.

It's still not clear to me what issue or issues you are fixing exactly with this patch,
and in what way.

Is the suggested change in behaviour required for SFP+ modules to completely fix bringing
up new links? Or is this only part of the solution? Your reply makes me think it's the
latter. If the changed behaviour for SFP+ modules here is fixing an issue, please describe
the issue as well as you can in this patch, and also describe any remaining issues.
Otherwise, if this change by itself leaves SFP+ equally broken as before, please just have
this patch fix the GbE links, and keep other changes for a later patch.

The network code on this platform is really not my area of expertise, so any explanation
on what is wrong, and why it needs to be fixed in this way, can help me understand. It can
also provide crucial information for others working on this code, since I think we need to
use every opportunity to (publicly) document the behaviour of this hardware.


More information about the openwrt-devel mailing list