RE: [PATCH net-next v8 3/7] r8169: add support for phylink

[Javen <javen_xu@realsil.com.cn>]

>
>On Mon, Aug 03, 2026 at 03:32:12AM +0000, Javen wrote:
>> >
>> >> +static void rtl_mac_link_up(struct phylink_config *config, struct
>> >> +phy_device
>> >*phydev,
>> >> +                         unsigned int mode, phy_interface_t interface,
>> >> +                         int speed, int duplex, bool tx_pause,
>> >> +bool
>> >> +rx_pause) {
>> >> +     struct rtl8169_private *tp = container_of(config, struct
>> >> +rtl8169_private,
>> >phylink_config);
>> >> +     struct device *d = tp_to_dev(tp);
>> >> +
>> >> +     tp->speed = speed;
>> >> +     rtl_link_chg_patch(tp, speed);
>> >> +
>> >> +     pm_request_resume(d);
>> >
>> >This does nothing with rx_pause and tx_pause. How is the MAC getting
>> >configured for flow control?
>>
>> To actually generate pause frames, the MAC needs Rx FIFO "Near Full" and
>"Near Empty" thresholds. The driver configures these statically during
>hardware initialization (rtl_hw_start_xxx) by writing to ERI registers 0xCC
>(RFIFONFULL_TH) and 0xD0 (RFIFOEMPTY_TH) via
>rtl8168g_set_pause_thresholds().
>>
>> Software enables/disables flow control by setting the Local PHY registers
>phy_set_asym_pause(). After auto-negotiation with the Link Partner, the PHY
>resolves the flow control capabilities. Once the link is up and flow control is
>negotiated, the integrated Realtek MAC hardware automatically reads the PHY
>result.
>>
>> Therefore, we don't need to do anything with tx_pause and rx_pause in
>mac_link_up.
>
>Yes you do.
>
>ethtool -A|--pause devname [autoneg on|off] [rx on|off] [tx on|off]
>
>Pause configuration falls into three major categories:
>
>1: The link is negotiated, and pause is negotiated
>2: The link is negotiated, but pause is forced. ethtool -A autoneg off ...
>3: The link is forced, ethtool -s autoneg off, and pause is forced, ethtool -A
>netneg off ...
>
>The PHY registers only tell you about 1:. phylink mac_link_up tells you the right
>thing to do for all three.

Hi Andrew,

Thanks for pointing this out. I have double-checked with our team, and the driver currently cannot handle Cases 2 & 3.

Here is the exact hardware limitation regarding flow control on our chip:
There are no independent software registers to configure Tx/Rx pause. The MAC hardware is completely hardwired:

When Autoneg is OFF (Forced mode): The hardware automatically locks Tx and Rx pause to DISABLED.
When Autoneg is ON: The MAC automatically polls the PHY and enables/disables flow control based purely on the negotiation result.
Because software cannot override this hardware behavior, we cannot explicitly force tx_pause or rx_pause via mac_link_up when autoneg is disabled.

How would you prefer I handle this limitation?
Should I just add a clear comment in mac_link_up explaining this, or is there a specific way in phylink to report that forced pause is unsupported so ethtool rejects Cases 2 & 3?

Best regards,
Javen

>
>    Andrew