From: "Marek Behún" <kabel@kernel.org>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: netdev@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
Jakub Kicinski <kuba@kernel.org>,
David Miller <davem@davemloft.net>,
Russell King <rmk+kernel@armlinux.org.uk>,
Rob Herring <robh+dt@kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH net-next 8/8] net: phy: marvell10g: select host interface configuration
Date: Thu, 18 Nov 2021 14:56:58 +0100 [thread overview]
Message-ID: <20211118145658.2a8b0498@thinkpad> (raw)
In-Reply-To: <20211118120334.jjujutp5cnjgwjq2@skbuf>
On Thu, 18 Nov 2021 14:03:34 +0200
Vladimir Oltean <olteanv@gmail.com> wrote:
> Hello,
>
> > +static int mv3310_select_mactype(unsigned long *interfaces)
> > +{
> > + if (test_bit(PHY_INTERFACE_MODE_USXGMII, interfaces))
> > + return MV_V2_33X0_PORT_CTRL_MACTYPE_USXGMII;
> > + else if (test_bit(PHY_INTERFACE_MODE_SGMII, interfaces) &&
> > + test_bit(PHY_INTERFACE_MODE_10GBASER, interfaces))
> > + return MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER;
> > + else if (test_bit(PHY_INTERFACE_MODE_SGMII, interfaces) &&
> > + test_bit(PHY_INTERFACE_MODE_RXAUI, interfaces))
> > + return MV_V2_33X0_PORT_CTRL_MACTYPE_RXAUI;
> > + else if (test_bit(PHY_INTERFACE_MODE_SGMII, interfaces) &&
> > + test_bit(PHY_INTERFACE_MODE_XAUI, interfaces))
> > + return MV_V2_3310_PORT_CTRL_MACTYPE_XAUI;
> > + else if (test_bit(PHY_INTERFACE_MODE_10GBASER, interfaces))
> > + return MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH;
> > + else if (test_bit(PHY_INTERFACE_MODE_RXAUI, interfaces))
> > + return MV_V2_33X0_PORT_CTRL_MACTYPE_RXAUI_RATE_MATCH;
> > + else if (test_bit(PHY_INTERFACE_MODE_XAUI, interfaces))
> > + return MV_V2_3310_PORT_CTRL_MACTYPE_XAUI_RATE_MATCH;
> > + else if (test_bit(PHY_INTERFACE_MODE_SGMII, interfaces))
> > + return MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER;
> > + else
> > + return -1;
> > +}
> > +
>
> I would like to understand this heuristic better. Both its purpose and
> its implementation.
>
> It says:
> (a) If the intersection between interface modes supported by the MAC and
> the PHY contains USXGMII, then use USXGMII as a MACTYPE
> (b) Otherwise, if the intersection contains both 10GBaseR and SGMII, then
> use 10GBaseR as MACTYPE
> (...)
> (c) Otherwise, if the intersection contains just 10GBaseR (no SGMII), then
> use 10GBaseR with rate matching as MACTYPE
> (...)
> (d) Otherwise, if the intersection contains just SGMII (no 10GBaseR), then
> use 10GBaseR as MACTYPE (no rate matching).
>
> First of all, what is MACTYPE exactly? And what is the purpose of
> changing it? What would happen if this configuration remained fixed, as
> it were?
>
> I see there is no MACTYPE definition for SGMII. Why is that? How does
> the PHY choose to use SGMII?
>
> Why is item (d) correct - use 10GBaseR as MACTYPE if the intersection
> only supports SGMII?
>
> A breakdown per link speed might be helpful in understanding the
> configurations being performed here.
Russell already explained this. I will put a better explanation into
the commit message in v2.
> > static int mv2110_init_interface(struct phy_device *phydev, int mactype)
> > {
> > struct mv3310_priv *priv = dev_get_drvdata(&phydev->mdio.dev);
> > @@ -674,10 +764,16 @@ static int mv3310_config_init(struct phy_device *phydev)
> > {
> > struct mv3310_priv *priv = dev_get_drvdata(&phydev->mdio.dev);
> > const struct mv3310_chip *chip = to_mv3310_chip(phydev);
> > + DECLARE_PHY_INTERFACE_MASK(interfaces);
> > int err, mactype;
> >
> > - /* Check that the PHY interface type is compatible */
> > - if (!test_bit(phydev->interface, priv->supported_interfaces))
> > + /* In case host didn't provide supported interfaces */
> > + __set_bit(phydev->interface, phydev->host_interfaces);
>
> Shouldn't phylib populate phydev->host_interfaces with
> phydev->interface, rather than requiring PHY drivers to do it?
I will look into this.
Marek
prev parent reply other threads:[~2021-11-18 13:57 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 22:50 [PATCH net-next 0/8] Extend `phy-mode` to string array Marek Behún
2021-11-17 22:50 ` [PATCH net-next 1/8] dt-bindings: ethernet-controller: support multiple PHY connection types Marek Behún
2021-11-18 16:27 ` Andrew Lunn
2021-11-17 22:50 ` [PATCH net-next 2/8] net: Update documentation for *_get_phy_mode() functions Marek Behún
2021-11-18 16:28 ` Andrew Lunn
2021-11-17 22:50 ` [PATCH net-next 3/8] device property: add helper function for getting phy mode bitmap Marek Behún
2021-11-18 16:31 ` Andrew Lunn
2021-11-17 22:50 ` [PATCH net-next 4/8] net: phylink: update supported_interfaces with modes from fwnode Marek Behún
2021-11-18 9:05 ` Russell King (Oracle)
2021-11-18 16:33 ` Andrew Lunn
2021-11-18 17:08 ` Russell King (Oracle)
2021-11-18 17:33 ` Marek Behún
2021-11-18 17:39 ` Russell King (Oracle)
2021-11-18 20:38 ` Sean Anderson
2021-11-17 22:50 ` [PATCH net-next 5/8] net: phylink: pass supported PHY interface modes to phylib Marek Behún
2021-11-18 9:32 ` Russell King (Oracle)
2021-11-18 16:27 ` Andrew Lunn
2021-11-18 16:28 ` Russell King (Oracle)
2021-11-17 22:50 ` [PATCH net-next 6/8] net: phy: marvell10g: Use generic macro for supported interfaces Marek Behún
2021-11-18 9:33 ` Russell King (Oracle)
2021-11-18 16:27 ` Andrew Lunn
2021-11-17 22:50 ` [PATCH net-next 7/8] net: phy: marvell10g: Use tabs instead of spaces for indentation Marek Behún
2021-11-18 9:34 ` Russell King (Oracle)
2021-11-17 22:50 ` [PATCH net-next 8/8] net: phy: marvell10g: select host interface configuration Marek Behún
2021-11-18 9:41 ` Russell King (Oracle)
2021-11-18 13:46 ` Marek Behún
2021-11-18 14:25 ` Russell King (Oracle)
2021-11-18 12:03 ` Vladimir Oltean
2021-11-18 13:22 ` Russell King (Oracle)
2021-11-18 14:20 ` Vladimir Oltean
2021-11-18 14:47 ` Russell King (Oracle)
2021-11-18 15:09 ` Vladimir Oltean
2021-11-18 15:20 ` Marek Behún
2021-11-18 15:59 ` Russell King (Oracle)
2021-11-18 13:56 ` Marek Behún [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=20211118145658.2a8b0498@thinkpad \
--to=kabel@kernel.org \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=robh+dt@kernel.org \
/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.