[PATCH] net: phylink: Pass state to pcs_config
Sean Anderson
sean.anderson at seco.com
Thu Dec 16 09:02:55 PST 2021
On 12/14/21 8:12 PM, Russell King (Oracle) wrote:
> On Wed, Dec 15, 2021 at 12:49:14AM +0000, Russell King (Oracle) wrote:
>> On Tue, Dec 14, 2021 at 07:16:53PM -0500, Sean Anderson wrote:
>> > Ok, so let me clarify my understanding. Perhaps this can be eliminated
>> > through a different approach.
>> >
>> > When I read the datasheet for mvneta (which hopefully has the same
>> > logic here, since I could not find a datasheet for an mvpp2 device), I
>> > noticed that the Pause_Adv bit said
>> >
>> > > It is valid only if flow control mode is defined by Auto-Negotiation
>> > > (as defined by the <AnFcEn> bit).
>> >
>> > Which I interpreted to mean that if AnFcEn was clear, then no flow
>> > control was advertised. But perhaps it instead means that the logic is
>> > something like
>> >
>> > if (AnFcEn)
>> > Config_Reg.PAUSE = Pause_Adv;
>> > else
>> > Config_Reg.PAUSE = SetFcEn;
>> >
>> > which would mean that we can just clear AnFcEn in link_up if the
>> > autonegotiated pause settings are different from the configured pause
>> > settings.
>>
>> Having actually played with this hardware quite a bit and observed what
>> it sends, what it implements for advertising is:
>>
>> Config_Reg.PAUSE = Pause_Adv;
So the above note from the datasheet about Pause_Adv not being valid is
incorrect?
>> Config_Reg gets sent over the 1000BASE-X link to the link partner, and
>> we receive Remote_Reg from the link partner.
>>
>> Then, the hardware implements:
>>
>> if (AnFcEn)
>> MAC_PAUSE = Config_Reg.PAUSE & Remote_Reg.PAUSE;
>> else
>> MAC_PAUSE = SetFcEn;
>>
>> In otherwords, AnFcEn controls whether the result of autonegotiation
>> or the value of SetFcEn controls whether the MAC enables symmetric
>> pause mode.
>
> I should also note that in the Port Status register,
>
> TxFcEn = RxFcEn = MAC_PAUSE;
>
> So, the status register bits follow SetFcEn when AnFcEn is disabled.
>
> However, these bits are the only way to report the result of the
> negotiation, which is why we use them to report back whether flow
> control was enabled in mvneta_pcs_get_state(). These bits will be
> ignored by phylink when ethtool -A has disabled pause negotiation,
> and in that situation there is no way as I said to be able to read
> the negotiation result.
Ok, how about
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index b1cce4425296..9b41d8ee71fb 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -6226,8 +6226,7 @@ static int mvpp2_gmac_pcs_config(struct phylink_pcs *pcs, unsigned int mode,
* automatically or the bits in MVPP22_GMAC_CTRL_4_REG
* manually controls the GMAC pause modes.
*/
- if (permit_pause_to_mac)
- val |= MVPP2_GMAC_FLOW_CTRL_AUTONEG;
+ val |= MVPP2_GMAC_FLOW_CTRL_AUTONEG;
/* Configure advertisement bits */
mask |= MVPP2_GMAC_FC_ADV_EN | MVPP2_GMAC_FC_ADV_ASM_EN;
@@ -6525,6 +6524,9 @@ static void mvpp2_mac_link_up(struct phylink_config *config,
}
} else {
if (!phylink_autoneg_inband(mode)) {
+ bool cur_tx_pause, cur_rx_pause;
+ u32 status0 = readl(port->base + MVPP2_GMAC_STATUS0);
+
val = MVPP2_GMAC_FORCE_LINK_PASS;
if (speed == SPEED_1000 || speed == SPEED_2500)
@@ -6535,11 +6537,18 @@ static void mvpp2_mac_link_up(struct phylink_config *config,
if (duplex == DUPLEX_FULL)
val |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+ cur_tx_pause = status0 & MVPP2_GMAC_STATUS0_TX_PAUSE;
+ cur_rx_pause = status0 & MVPP2_GMAC_STATUS0_RX_PAUSE;
+ if (tx_pause == cur_tx_pause &&
+ rx_pause == cur_rx_pause)
+ val |= MVPP2_GMAC_FLOW_CTRL_AUTONEG;
+
mvpp2_modify(port->base + MVPP2_GMAC_AUTONEG_CONFIG,
MVPP2_GMAC_FORCE_LINK_DOWN |
MVPP2_GMAC_FORCE_LINK_PASS |
MVPP2_GMAC_CONFIG_MII_SPEED |
MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_FLOW_CTRL_AUTONEG |
MVPP2_GMAC_CONFIG_FULL_DUPLEX, val);
}
---
When we have MLO_PAUSE_AN, this is the same as before. For the other
case, consider the scenario where someone disables pause
autonegotiation, and then plugs in the cable. Here, we get the
negotiated pause from pcs_get_state, but it is overridden by
phylink_apply_manual_flow in phylink_resolve. Then, link_up may clear
AnFcEn, depending on if the pause mode matches. If it matches, then
future link_up events will look like what just happened. If it doesn't,
then we will ignore the negotiated pause mode for future link_up events
(that is, the result of pcs_get_state will not be what was negotiated).
This is OK, because we discard the result of negotiation anyway. If
someone enables pause autonegotiation again, then
phylink_ethtool_set_pauseparam will call phylink_change_inband_advert,
which call phylink_mac_pcs_an_restart since AnFcEn will be set again.
The downside to the above approach is that when MLO_PAUSE_AN is cleared
and we have had to clear AnFcEn, calling pcs_config will always trigger
autonegotiation to restart, even for no-op changes which would not
otherwise trigger a restart. I think this scenario is unlikely enough
not to be a big deal. Lastly, this also depends on
Config_Reg.PAUSE = Pause_Adv;
or at the very least, anything which is not
if (AnFcEn)
Config_Reg.PAUSE = Pause_Adv;
else
Config_Reg.PAUSE = 0;
> permit_pause_to_mac exists precisely because of the limitions of this
> hardware, and having it costs virtually nothing to other network
> drivers... except a parameter that others ignore.
>
> If we don't have permit_pause_to_mac in pcs_config() then we need to
> have it passed to the link_up() methods instead. There is no other
> option (other than breaking mvneta and mvpp2) here than to make the
> state of ethtool -A ... autoneg on|off known to the hardware.
Well, the original patch is primarily motivated by the terrible naming
and documentation regarding this parameter. I was only able to determine
the purpose of this parameter by reading the mvpp2 driver and consulting
the A370 datasheet. I think if it is possible to eliminate this
parameter (such as with the above patch), we should do so, since it will
make the API cleaner and easier to understand. Failing that, I will
submit a patch to improve the documentation (and perhaps rename the
parameter to something more descriptive).
--Sean
More information about the linux-arm-kernel
mailing list