Re: [PATCH next-next] net: phy: realtek: add support for rtl8224 2.5Gbps PHY

["Marek Behún" <kabel@kernel.org>]

On Sun, 16 Jun 2024 21:24:53 +0000
Chris Packham <Chris.Packham@alliedtelesis.co.nz> wrote:

> On 14/06/24 20:25, Marek Behún wrote:
> > On Fri, 14 Jun 2024 10:18:47 +0200
> > Paolo Abeni <pabeni@redhat.com> wrote:
> >  
> >> On Wed, 2024-06-12 at 09:07 +0200, Marek Behún wrote:  
> >>> On Tue, 11 Jun 2024 20:42:43 +0000
> >>> Chris Packham <Chris.Packham@alliedtelesis.co.nz> wrote:
> >>>      
> >>>> +cc Eric W and Marek.
> >>>>
> >>>> On 11/06/24 17:34, Chris Packham wrote:  
> >>>>> The Realtek RTL8224 PHY is a 2.5Gbps capable PHY. It only uses the
> >>>>> clause 45 MDIO interface and can leverage the support that has already
> >>>>> been added for the other 822x PHYs.
> >>>>>
> >>>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> >>>>> ---
> >>>>>
> >>>>> Notes:
> >>>>>       I'm currently testing this on an older kernel because the board I'm
> >>>>>       using has a SOC/DSA switch that has a driver in openwrt for Linux 5.15.
> >>>>>       I have tried to selectively back port the bits I need from the other
> >>>>>       rtl822x work so this should be all that is required for the rtl8224.
> >>>>>       
> >>>>>       There's quite a lot that would need forward porting get a working system
> >>>>>       against a current kernel so hopefully this is small enough that it can
> >>>>>       land while I'm trying to figure out how to untangle all the other bits.
> >>>>>       
> >>>>>       One thing that may appear lacking is the lack of rate_matching support.
> >>>>>       According to the documentation I have know the interface used on the
> >>>>>       RTL8224 is (q)uxsgmii so no rate matching is required. As I'm still
> >>>>>       trying to get things completely working that may change if I get new
> >>>>>       information.
> >>>>>
> >>>>>    drivers/net/phy/realtek.c | 8 ++++++++
> >>>>>    1 file changed, 8 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> >>>>> index 7ab41f95dae5..2174893c974f 100644
> >>>>> --- a/drivers/net/phy/realtek.c
> >>>>> +++ b/drivers/net/phy/realtek.c
> >>>>> @@ -1317,6 +1317,14 @@ static struct phy_driver realtek_drvs[] = {
> >>>>>    		.resume         = rtlgen_resume,
> >>>>>    		.read_page      = rtl821x_read_page,
> >>>>>    		.write_page     = rtl821x_write_page,
> >>>>> +	}, {
> >>>>> +		PHY_ID_MATCH_EXACT(0x001ccad0),
> >>>>> +		.name		= "RTL8224 2.5Gbps PHY",
> >>>>> +		.get_features   = rtl822x_c45_get_features,
> >>>>> +		.config_aneg    = rtl822x_c45_config_aneg,
> >>>>> +		.read_status    = rtl822x_c45_read_status,
> >>>>> +		.suspend        = genphy_c45_pma_suspend,
> >>>>> +		.resume         = rtlgen_c45_resume,
> >>>>>    	}, {
> >>>>>    		PHY_ID_MATCH_EXACT(0x001cc961),
> >>>>>    		.name		= "RTL8366RB Gigabit Ethernet"  
> >>> Don't you need rtl822xb_config_init for serdes configuration?  
> >> Marek, I read the above as you would prefer to have such support
> >> included from the beginning, as such I'm looking forward a new version
> >> of this patch.
> >>
> >> Please raise a hand if I read too much in your reply.  
> > I am raising my hand :) I just wanted to point it out.
> > If this code works for Chris' hardware, it is okay even without the
> > .config_init.  
> 
> I did look into this. The SERDES configuration seems to be different 
> between the RTL8221 and RTL8224. I think that might be because the 
> RTL8221 can do a few different host interfaces whereas the RTL8224 is 
> really only USXGMII. There are some configurable parameters but they 
> appear to be done differently.
> 
> Having said that I definitely don't have a system working end to end. I 
> know the line side stuff is working well (auto-negotiating speeds from 
> 10M to 2.5B) but I'm not getting anything on the host side. I'm not sure 
> if that's a problem with the switch driver or with the PHY.
> 
> I'd like this to go in as it shouldn't regress anything but I can 
> understand if the bar is "needs to be 100% working" I'll just have to 
> carry this locally until I can be sure.

If it doesn't work, it can confuse people that it is working if it is
accepted...

Try to contact Realtek via the contact I sent you in the private
e-mail, maybe you'll be able to make this work.

Marek