public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <florian.fainelli@broadcom.com>
To: Jonas Gorski <jonas.gorski@gmail.com>, Andrew Lunn <andrew@lunn.ch>
Cc: "Vladimir Oltean" <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Vivien Didelot" <vivien.didelot@gmail.com>,
	"Álvaro Fernández Rojas" <noltari@gmail.com>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net 2/3] net: dsa: b53: fix configuring RGMII delay on bcm63xx
Date: Mon, 19 May 2025 14:38:00 -0700	[thread overview]
Message-ID: <446fcb22-3fb5-4a43-83c3-3b22152643cc@broadcom.com> (raw)
In-Reply-To: <CAOiHx=nwbs7030GKZHLc6Pc6LA6Hqq0NYfNSt=3zOgnj5zpAYQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4216 bytes --]

On 5/19/25 12:44, Jonas Gorski wrote:
> On Mon, May 19, 2025 at 9:14 PM Andrew Lunn <andrew@lunn.ch> wrote:
>>
>> On Mon, May 19, 2025 at 07:45:49PM +0200, Jonas Gorski wrote:
>>> The RGMII delay type of the PHY interface is intended for the PHY, not
>>> the MAC, so we need to configure the opposite. Else we double the delay
>>> or don't add one at all if the PHY also supports configuring delays.
>>>
>>> Additionally, we need to enable RGMII_CTRL_TIMING_SEL for the delay
>>> actually being effective.
>>>
>>> Fixes e.g. BCM54612E connected on RGMII ports that also configures RGMII
>>> delays in its driver.
>>
>> We have to be careful here not to cause regressions. It might be
>> wrong, but are there systems using this which actually work? Does this
>> change break them?
> 
> The only user (of bcm63xx and b53 dsa) I am aware of is OpenWrt, and
> we are capable of updating our dts files in case they were using
> broken configuration. Though having PHYs on the RGMII ports is a very
> rare configuration, and usually there is switch connected with a fixed
> link, so likely the issue was never detected.
> 
>>>
>>> Fixes: ce3bf94871f7 ("net: dsa: b53: add support for BCM63xx RGMIIs")
>>> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
>>> ---
>>>   drivers/net/dsa/b53/b53_common.c | 13 +++++++------
>>>   1 file changed, 7 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
>>> index a316f8c01d0a..b00975189dab 100644
>>> --- a/drivers/net/dsa/b53/b53_common.c
>>> +++ b/drivers/net/dsa/b53/b53_common.c
>>> @@ -1328,19 +1328,19 @@ static void b53_adjust_63xx_rgmii(struct dsa_switch *ds, int port,
>>>
>>>        switch (interface) {
>>>        case PHY_INTERFACE_MODE_RGMII_ID:
>>> -             rgmii_ctrl |= (RGMII_CTRL_DLL_RXC | RGMII_CTRL_DLL_TXC);
>>> +             rgmii_ctrl &= ~(RGMII_CTRL_DLL_RXC | RGMII_CTRL_DLL_TXC);
>>>                break;
>>>        case PHY_INTERFACE_MODE_RGMII_RXID:
>>> -             rgmii_ctrl &= ~(RGMII_CTRL_DLL_TXC);
>>> -             rgmii_ctrl |= RGMII_CTRL_DLL_RXC;
>>> +             rgmii_ctrl |= RGMII_CTRL_DLL_TXC;
>>> +             rgmii_ctrl &= ~RGMII_CTRL_DLL_RXC;
>>>                break;
>>>        case PHY_INTERFACE_MODE_RGMII_TXID:
>>> -             rgmii_ctrl &= ~(RGMII_CTRL_DLL_RXC);
>>> -             rgmii_ctrl |= RGMII_CTRL_DLL_TXC;
>>> +             rgmii_ctrl |= RGMII_CTRL_DLL_RXC;
>>> +             rgmii_ctrl &= ~RGMII_CTRL_DLL_TXC;
>>>                break;
>>>        case PHY_INTERFACE_MODE_RGMII:
>>>        default:
>>> -             rgmii_ctrl &= ~(RGMII_CTRL_DLL_RXC | RGMII_CTRL_DLL_TXC);
>>> +             rgmii_ctrl |= RGMII_CTRL_DLL_RXC | RGMII_CTRL_DLL_TXC;
>>>                break;
>>
>> These changes look wrong. There is more background here:
>>
>> https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
> 
> This is what makes it work for me (I tested all four modes, rgmii,
> rgmii-id, rgmii-txid and rgmii-rxid). Without this change, b53 will
> configure the same delays on the MAC layer as the PHY driver (bcm54xx,
> https://elixir.bootlin.com/linux/v6.15-rc7/source/drivers/net/phy/broadcom.c#L73
> ), which breaks connectivity at least for me.
> 
> E.g. with a phy-mode of "rgmii-id", both b53 and the PHY driver would
> enable rx and tx delays, causing the delays to be 4 ns instead of 2
> ns. So I don't see how this could have ever worked.

It's possible this was tested with an external PHY which was not 
configured by drivers/net/phy/broadcom.c?

> 
> Also note that b53_adjust_531x5_rgmii()
> https://elixir.bootlin.com/linux/v6.15-rc7/source/drivers/net/dsa/b53/b53_common.c#L1360
> already behaves that way, this just makes bcm63xx now work the same
> (so these functions could now even be merged).

Yes, I was going to suggest we should be doing that.

There are precedents with other Broadcom drivers for doing things 
incorrectly, and having to put quirks to deal with that, yours truly 
having greatly contributed to doing that:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b972b54a68b2512a7528658ecd023aea108c03a5
-- 
Florian

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4208 bytes --]

  parent reply	other threads:[~2025-05-19 21:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-19 17:45 [PATCH net 0/3] net: dsa: fix RGMII ports on BCM63xx Jonas Gorski
2025-05-19 17:45 ` [PATCH net 1/3] net: dsa: b53: do not enable EEE on bcm63xx Jonas Gorski
2025-05-19 21:40   ` Florian Fainelli
2025-05-19 17:45 ` [PATCH net 2/3] net: dsa: b53: fix configuring RGMII delay " Jonas Gorski
2025-05-19 19:14   ` Andrew Lunn
2025-05-19 19:44     ` Jonas Gorski
2025-05-19 20:34       ` Andrew Lunn
2025-05-19 21:43         ` Jonas Gorski
2025-05-20  0:15           ` Andrew Lunn
2025-05-23  9:08             ` Jonas Gorski
2025-05-23 13:24               ` Andrew Lunn
2025-05-19 21:38       ` Florian Fainelli [this message]
2025-05-19 17:45 ` [PATCH net 3/3] net: dsa: b53: allow RGMII for bcm63xx RGMII ports Jonas Gorski
2025-05-19 21:40   ` Florian Fainelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=446fcb22-3fb5-4a43-83c3-3b22152643cc@broadcom.com \
    --to=florian.fainelli@broadcom.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=jonas.gorski@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=noltari@gmail.com \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox