All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Sean Anderson <sean.anderson@seco.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Claudiu Beznea <claudiu.beznea@microchip.com>,
	Antoine Tenart <atenart@kernel.org>
Subject: Re: [PATCH v4] net: macb: Fix several edge cases in validate
Date: Tue, 26 Oct 2021 16:51:08 +0100	[thread overview]
Message-ID: <YXgj7HUkcRLdq+eB@shell.armlinux.org.uk> (raw)
In-Reply-To: <4e430fbb-0908-fd3b-bb6e-ec316ea8d66a@seco.com>

On Tue, Oct 26, 2021 at 11:30:08AM -0400, Sean Anderson wrote:
> I don't know if it's a "fix" per se. The current logic isn't wrong,
> since I believe that the configurations where the above patch would make
> a difference do not exist. However, as noted in the commit message, this
> makes refactoring difficult. For example, one might want to implement
> supported_interfaces like
> 
>        if (bp->caps & MACB_CAPS_HIGH_SPEED &&
>            bp->caps & MACB_CAPS_PCS)
>                __set_bit(PHY_INTERFACE_MODE_10GBASER, supported);
>        if (macb_is_gem(bp) && bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE) {
>                __set_bit(PHY_INTERFACE_MODE_GMII, supported);
> 		phy_interface_set_rgmii(supported);
>                if (bp->caps & MACB_CAPS_PCS)
>                        __set_bit(PHY_INTERFACE_MODE_SGMII, supported);
>        }
>        __set_bit(PHY_INTERFACE_MODE_MII, supported);
>        __set_bit(PHY_INTERFACE_MODE_RMII, supported);
> 
> but then you still need to check for GIGABIT_MODE in validate to
> determine whether 10GBASER should "support" 10/100. See [1] for more
> discussion.

However, 10GBASE-R doesn't support anything except 10G speeds, except
if the PHY itself does rate matching to achieve the slower speeds.
Then you need pause frames between the MAC and PHY to control the MAC
sending rate - which isn't something that the phylib model supports
particularly well.

The current code and your patched code conforms to this when
state->interface is 10GBASE-R _and_ MACB_CAPS_GIGABIT_MODE_AVAILABLE
is set, then we only end up with 10G linkmodes being allowed.

The problem case occurs in current code when
MACB_CAPS_GIGABIT_MODE_AVAILABLE is _not_ set, but state->interface
is 10GBASE-R. Current code ends up saying that 10GBASE-R supports
10/100 link modes, which is wrong.

The existing code:

        if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE &&
            (state->interface == PHY_INTERFACE_MODE_NA ||
             state->interface == PHY_INTERFACE_MODE_10GBASER)) {
                phylink_set(mask, 10000baseCR_Full);
                phylink_set(mask, 10000baseER_Full);
                phylink_set(mask, 10000baseKR_Full);
                phylink_set(mask, 10000baseLR_Full);
                phylink_set(mask, 10000baseLRM_Full);
                phylink_set(mask, 10000baseSR_Full);
                phylink_set(mask, 10000baseT_Full);
                if (state->interface != PHY_INTERFACE_MODE_NA)
                        goto out;
        }

        phylink_set(mask, 10baseT_Half);
        phylink_set(mask, 10baseT_Full);
        phylink_set(mask, 100baseT_Half);
        phylink_set(mask, 100baseT_Full);

Would have been better written as:

	if (state->interface == PHY_INTERFACE_MODE_NA ||
	    state->interface == PHY_INTERFACE_MODE_10GBASER) {
		if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE) {
	                phylink_set(mask, 10000baseCR_Full);
	                phylink_set(mask, 10000baseER_Full);
	                phylink_set(mask, 10000baseKR_Full);
	                phylink_set(mask, 10000baseLR_Full);
	                phylink_set(mask, 10000baseLRM_Full);
	                phylink_set(mask, 10000baseSR_Full);
	                phylink_set(mask, 10000baseT_Full);
		}
                if (state->interface != PHY_INTERFACE_MODE_NA)
                        goto out;
        }

        phylink_set(mask, 10baseT_Half);
        phylink_set(mask, 10baseT_Full);
        phylink_set(mask, 100baseT_Half);
        phylink_set(mask, 100baseT_Full);

which would have avoided getting to the code that sets 10/100 link
modes when state->interface is 10GBASE-R.

The same transformation is probably applicable to the next if ()
block as well.

If I truely understood exactly what MACB_CAPS_GIGABIT_MODE_AVAILABLE,
MACB_CAPS_HIGH_SPEED, and MACB_CAPS_PCS were indicating and how they
relate to what is supported, I might be tempted to come up with a
better implementation myself. However, every time I look at the
existing code, it just confuses me - it seems to me that the use of
those capability bits is entirely inconsistent in the current
macb_validate() implementation.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

      parent reply	other threads:[~2021-10-26 15:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-25 17:24 [PATCH v4] net: macb: Fix several edge cases in validate Sean Anderson
2021-10-25 21:19 ` Russell King (Oracle)
2021-10-25 21:35   ` Sean Anderson
2021-10-26 16:37     ` Nicolas Ferre
2021-10-26 17:04       ` Russell King (Oracle)
2021-10-26 17:28         ` Sean Anderson
2021-10-26 17:46           ` Russell King (Oracle)
2021-10-26 17:49             ` Sean Anderson
2021-10-26 18:28               ` Russell King (Oracle)
2021-10-26 18:52                 ` Sean Anderson
2021-10-27  7:02                   ` Nicolas.Ferre
2021-10-26  0:44 ` Jakub Kicinski
2021-10-26 15:30   ` Sean Anderson
2021-10-26 15:39     ` Jakub Kicinski
2021-10-26 16:32       ` Nicolas Ferre
2021-10-26 15:51     ` Russell King (Oracle) [this message]

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=YXgj7HUkcRLdq+eB@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=atenart@kernel.org \
    --cc=claudiu.beznea@microchip.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=sean.anderson@seco.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.