From: Dragan Simic <dsimic@manjaro.org>
To: Jonas Karlman <jonas@kwiboo.se>
Cc: Heiko Stuebner <heiko@sntech.de>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] Use DELAY_ENABLE macro for RK3328, RK3566/RK3568 and RK3588
Date: Thu, 06 Mar 2025 22:41:03 +0100 [thread overview]
Message-ID: <41bb2c8d963e890768bceb477488250e@manjaro.org> (raw)
In-Reply-To: <20250306203858.1677595-1-jonas@kwiboo.se>
Hello Jonas,
On 2025-03-06 21:38, Jonas Karlman wrote:
> Almost all Rockchip GMAC variants use the DELAY_ENABLE macro to help
> enable or disable use of MAC rx/tx delay. However, RK3328,
> RK3566/RK3568
> and RK3588 GMAC driver does not.
>
> Use of the DELAY_ENABLE macro help ensure the MAC rx/tx delay is
> disabled, instead of being enabled and using a zero delay, when
> RGMII_ID/RXID/TXID is used.
>
> RK3328 driver was merged around the same time as when DELAY_ENABLE was
> introduced so it is understandable why it was missed. Both
> RK3566/RK3568
> and RK3588 support were introduced much later yet they also missed
> using
> the DELAY_ENABLE macro (so did vendor kernel at that time).
>
> This series fixes all these cases to unify how GMAC delay feature is
> enabled or disabled across the different GMAC variants.
>
> Jonas Karlman (3):
> net: stmmac: dwmac-rk: Use DELAY_ENABLE macro for RK3328
> net: stmmac: dwmac-rk: Use DELAY_ENABLE macro for RK3566/RK3568
> net: stmmac: dwmac-rk: Use DELAY_ENABLE macro for RK3588
>
> .../net/ethernet/stmicro/stmmac/dwmac-rk.c | 19 ++++++++++---------
> 1 file changed, 10 insertions(+), 9 deletions(-)
As far as I can tell, the RV1126 GMAC should also be converted to use
the DELAY_ENABLE macro, which the vendor kernel already does. [*]
Perhaps
that could be performed in new patch 4/4 in this series?
BTW, it would be quite neat to introduce the DELAY_VALUE macro, which
makes the function calls a bit more compact. [*]
[*]
https://raw.githubusercontent.com/rockchip-linux/kernel/refs/heads/develop-5.10/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
WARNING: multiple messages have this Message-ID (diff)
From: Dragan Simic <dsimic@manjaro.org>
To: Jonas Karlman <jonas@kwiboo.se>
Cc: Heiko Stuebner <heiko@sntech.de>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] Use DELAY_ENABLE macro for RK3328, RK3566/RK3568 and RK3588
Date: Thu, 06 Mar 2025 22:41:03 +0100 [thread overview]
Message-ID: <41bb2c8d963e890768bceb477488250e@manjaro.org> (raw)
In-Reply-To: <20250306203858.1677595-1-jonas@kwiboo.se>
Hello Jonas,
On 2025-03-06 21:38, Jonas Karlman wrote:
> Almost all Rockchip GMAC variants use the DELAY_ENABLE macro to help
> enable or disable use of MAC rx/tx delay. However, RK3328,
> RK3566/RK3568
> and RK3588 GMAC driver does not.
>
> Use of the DELAY_ENABLE macro help ensure the MAC rx/tx delay is
> disabled, instead of being enabled and using a zero delay, when
> RGMII_ID/RXID/TXID is used.
>
> RK3328 driver was merged around the same time as when DELAY_ENABLE was
> introduced so it is understandable why it was missed. Both
> RK3566/RK3568
> and RK3588 support were introduced much later yet they also missed
> using
> the DELAY_ENABLE macro (so did vendor kernel at that time).
>
> This series fixes all these cases to unify how GMAC delay feature is
> enabled or disabled across the different GMAC variants.
>
> Jonas Karlman (3):
> net: stmmac: dwmac-rk: Use DELAY_ENABLE macro for RK3328
> net: stmmac: dwmac-rk: Use DELAY_ENABLE macro for RK3566/RK3568
> net: stmmac: dwmac-rk: Use DELAY_ENABLE macro for RK3588
>
> .../net/ethernet/stmicro/stmmac/dwmac-rk.c | 19 ++++++++++---------
> 1 file changed, 10 insertions(+), 9 deletions(-)
As far as I can tell, the RV1126 GMAC should also be converted to use
the DELAY_ENABLE macro, which the vendor kernel already does. [*]
Perhaps
that could be performed in new patch 4/4 in this series?
BTW, it would be quite neat to introduce the DELAY_VALUE macro, which
makes the function calls a bit more compact. [*]
[*]
https://raw.githubusercontent.com/rockchip-linux/kernel/refs/heads/develop-5.10/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-03-06 21:42 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 20:38 [PATCH 0/3] Use DELAY_ENABLE macro for RK3328, RK3566/RK3568 and RK3588 Jonas Karlman
2025-03-06 20:38 ` Jonas Karlman
2025-03-06 20:38 ` [PATCH 1/3] net: stmmac: dwmac-rk: Use DELAY_ENABLE macro for RK3328 Jonas Karlman
2025-03-06 20:38 ` Jonas Karlman
2025-03-06 21:09 ` Dragan Simic
2025-03-06 21:09 ` Dragan Simic
2025-03-06 22:25 ` Andrew Lunn
2025-03-06 22:25 ` Andrew Lunn
2025-03-06 23:28 ` Jonas Karlman
2025-03-06 23:28 ` Jonas Karlman
2025-03-07 13:52 ` Andrew Lunn
2025-03-07 13:52 ` Andrew Lunn
2025-03-06 20:38 ` [PATCH 2/3] net: stmmac: dwmac-rk: Use DELAY_ENABLE macro for RK3566/RK3568 Jonas Karlman
2025-03-06 20:38 ` Jonas Karlman
2025-03-06 21:26 ` Dragan Simic
2025-03-06 21:26 ` Dragan Simic
2025-03-06 20:38 ` [PATCH 3/3] net: stmmac: dwmac-rk: Use DELAY_ENABLE macro for RK3588 Jonas Karlman
2025-03-06 20:38 ` Jonas Karlman
2025-03-06 21:33 ` Dragan Simic
2025-03-06 21:33 ` Dragan Simic
2025-03-07 0:48 ` Sebastian Reichel
2025-03-07 0:48 ` Sebastian Reichel
2025-03-06 21:41 ` Dragan Simic [this message]
2025-03-06 21:41 ` [PATCH 0/3] Use DELAY_ENABLE macro for RK3328, RK3566/RK3568 and RK3588 Dragan Simic
2025-03-06 22:07 ` Jonas Karlman
2025-03-06 22:07 ` Jonas Karlman
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=41bb2c8d963e890768bceb477488250e@manjaro.org \
--to=dsimic@manjaro.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=heiko@sntech.de \
--cc=jonas@kwiboo.se \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.