drivers/net/phy/realtek/realtek_main.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
From: Javen Xu <javen_xu@realsil.com.cn>
Firmware execution routine unconditionally uses phy_modify_mmd() for
all OP_WRITE entries which introduces an unnecessary read transaction
when updating an entire 16-bit register. So we optimize this by
checking bitmask boundaries. Use phy_write_mmd() directly to speed up
firmware loading process.
Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
---
drivers/net/phy/realtek/realtek_main.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 27e31a799e2c..97b0b67b9900 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -548,8 +548,12 @@ static int rtl8261x_fw_execute_entry(struct phy_device *phydev,
switch (entry->type) {
case OP_WRITE:
- ret = phy_modify_mmd(phydev, dev, addr,
- GENMASK(msb, lsb), (value << lsb) & GENMASK(msb, lsb));
+ if (msb != 15 || lsb != 0)
+ ret = phy_modify_mmd(phydev, dev, addr, GENMASK(msb, lsb),
+ (value << lsb) & GENMASK(msb, lsb));
+ else
+ ret = phy_write_mmd(phydev, dev, addr, value);
+
if (ret)
return ret;
break;
--
2.43.0
On Thu, Sep 10, 2026 at 10:49:26AM +0800, javen wrote: > From: Javen Xu <javen_xu@realsil.com.cn> > > Firmware execution routine unconditionally uses phy_modify_mmd() for > all OP_WRITE entries which introduces an unnecessary read transaction > when updating an entire 16-bit register. So we optimize this by > checking bitmask boundaries. Use phy_write_mmd() directly to speed up > firmware loading process. For optimisations, it is normal to include some benchmark numbers to show how big a change it made. Is the added complexity worth the change? Andrew
> >On Thu, Sep 10, 2026 at 10:49:26AM +0800, javen wrote: >> From: Javen Xu <javen_xu@realsil.com.cn> >> >> Firmware execution routine unconditionally uses phy_modify_mmd() for >> all OP_WRITE entries which introduces an unnecessary read transaction >> when updating an entire 16-bit register. So we optimize this by >> checking bitmask boundaries. Use phy_write_mmd() directly to speed up >> firmware loading process. > >For optimisations, it is normal to include some benchmark numbers to show >how big a change it made. Is the added complexity worth the change? > I traced the actual MDC/MDIO hardware transactions during firmware loading process. Here are the benchmark numbers: - Unpatched : about 28,000 MDIO transactions. - Patched: about 9,600 MDIO transactions. This results in a 65% reduction in MDIO traffic. Thanks, Javen > Andrew
Hi Javen On 11.9.2026 07:51, Javen wrote: >> >> On Thu, Sep 10, 2026 at 10:49:26AM +0800, javen wrote: >>> From: Javen Xu <javen_xu@realsil.com.cn> >>> >>> Firmware execution routine unconditionally uses phy_modify_mmd() for >>> all OP_WRITE entries which introduces an unnecessary read transaction >>> when updating an entire 16-bit register. So we optimize this by >>> checking bitmask boundaries. Use phy_write_mmd() directly to speed up >>> firmware loading process. >> >> For optimisations, it is normal to include some benchmark numbers to >> show >> how big a change it made. Is the added complexity worth the change? >> > > I traced the actual MDC/MDIO hardware transactions during firmware > loading process. Here are the benchmark numbers: > > - Unpatched : about 28,000 MDIO transactions. > - Patched: about 9,600 MDIO transactions. > > This results in a 65% reduction in MDIO traffic. Can you please add these numbers to the commit? The patch itself looks fine and also compiles cleanly on my machine. So with the number added, I'd be happy to R-b. > > Thanks, > Javen > >> Andrew Thanks, Nicolai
> > >Hi Javen > >On 11.9.2026 07:51, Javen wrote: >>> >>> On Thu, Sep 10, 2026 at 10:49:26AM +0800, javen wrote: >>>> From: Javen Xu <javen_xu@realsil.com.cn> >>>> >>>> Firmware execution routine unconditionally uses phy_modify_mmd() for >>>> all OP_WRITE entries which introduces an unnecessary read >>>> transaction when updating an entire 16-bit register. So we optimize >>>> this by checking bitmask boundaries. Use phy_write_mmd() directly to >>>> speed up firmware loading process. >>> >>> For optimisations, it is normal to include some benchmark numbers to >>> show how big a change it made. Is the added complexity worth the >>> change? >>> >> >> I traced the actual MDC/MDIO hardware transactions during firmware >> loading process. Here are the benchmark numbers: >> >> - Unpatched : about 28,000 MDIO transactions. >> - Patched: about 9,600 MDIO transactions. >> >> This results in a 65% reduction in MDIO traffic. > >Can you please add these numbers to the commit? > >The patch itself looks fine and also compiles cleanly on my machine. >So with the number added, I'd be happy to R-b. > Hi Nicolai, Thanks for the review and testing. I will add these benchmark numbers to the commit message and send out a v2 patch. Thanks, Javen
© 2016 - 2026 Red Hat, Inc.