[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e9a2b30f-71a1-4e3d-9754-a5d505ca6705@alliedtelesis.co.nz>
Date: Sun, 16 Jun 2024 21:24:53 +0000
From: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To: Marek Behún <kabel@...nel.org>, Paolo Abeni
<pabeni@...hat.com>
CC: "andrew@...n.ch" <andrew@...n.ch>, "hkallweit1@...il.com"
<hkallweit1@...il.com>, "linux@...linux.org.uk" <linux@...linux.org.uk>,
"davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
<edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"ericwouds@...il.com" <ericwouds@...il.com>
Subject: Re: [PATCH next-next] net: phy: realtek: add support for rtl8224
2.5Gbps PHY
On 14/06/24 20:25, Marek Behún wrote:
> On Fri, 14 Jun 2024 10:18:47 +0200
> Paolo Abeni <pabeni@...hat.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@...iedtelesis.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@...iedtelesis.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.
Powered by blists - more mailing lists