From: Andrew Lunn <andrew@lunn.ch>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Antoine Tenart <antoine.tenart@bootlin.com>,
netdev@vger.kernel.org, gregory.clement@bootlin.com,
Russell King <linux@armlinux.org.uk>,
linux-kernel@vger.kernel.org, nadavh@marvell.com,
thomas.petazzoni@bootlin.com, miquel.raynal@bootlin.com,
stefanc@marvell.com, mw@semihalf.com, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org,
Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH net-next 4/7] net: phy: marvell10g: Add support for 2.5GBASET and 5GBASET
Date: Mon, 21 Jan 2019 21:17:15 +0100 [thread overview]
Message-ID: <20190121201715.GA20277@lunn.ch> (raw)
In-Reply-To: <20190118152352.26417-5-maxime.chevallier@bootlin.com>
> @@ -264,8 +265,10 @@ static int mv3310_config_init(struct phy_device *phydev)
> if (ret)
> return ret;
>
> - linkmode_and(phydev->advertising, phydev->advertising,
> - phydev->supported);
> + /* Make sure we advertise all the supported modes, and not just the
> + * default one specified in the driver's .features.
> + */
> + linkmode_copy(phydev->advertising, phydev->supported);
Hi Maxime
What Russell is referring to is:
static int phy_probe(struct device *dev)
{
..
/* Start out supporting everything. Eventually,
* a controller will attach, and may modify one
* or both of these values
*/
linkmode_copy(phydev->supported, phydrv->features);
of_set_phy_supported(phydev);
linkmode_copy(phydev->advertising, phydev->supported);
/* Get the EEE modes we want to prohibit. We will ask
* the PHY stop advertising these mode later on
*/
of_set_phy_eee_broken(phydev);
/* The Pause Frame bits indicate that the PHY can support passing
* pause frames. During autonegotiation, the PHYs will determine if
* they should allow pause frames to pass. The MAC driver should then
* use that result to determine whether to enable flow control via
* pause frames.
*
* Normally, PHY drivers should not set the Pause bits, and instead
* allow phylib to do that. However, there may be some situations
* (e.g. hardware erratum) where the driver wants to set only one
* of these bits.
*/
if (test_bit(ETHTOOL_LINK_MODE_Pause_BIT, phydrv->features) ||
test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, phydrv->features)) {
linkmode_clear_bit(ETHTOOL_LINK_MODE_Pause_BIT,
phydev->supported);
linkmode_clear_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
phydev->supported);
if (test_bit(ETHTOOL_LINK_MODE_Pause_BIT, phydrv->features))
linkmode_set_bit(ETHTOOL_LINK_MODE_Pause_BIT,
phydev->supported);
if (test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
phydrv->features))
linkmode_set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
phydev->supported);
} else {
linkmode_set_bit(ETHTOOL_LINK_MODE_Pause_BIT,
phydev->supported);
linkmode_set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
phydev->supported);
}
So by doing a copy of supported into advertising, you can stomping
over any restrictions applied via of_set_phy_supported(),
of_set_phy_eee_broken(phydev), and any pause control settings which
might of happened.
What might make sense here is that a PHY driver can replace its
.features member at run time, in its config_init() call. The core then
needs to perform these evaluations. So i'm guessing we need to split
this code out of probe() and move it into phy_init_hw()?
Heiner, you know this code better than anybody. What do you think?
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
Florian Fainelli <f.fainelli@gmail.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
linux-arm-kernel@lists.infradead.org,
Antoine Tenart <antoine.tenart@bootlin.com>,
thomas.petazzoni@bootlin.com, gregory.clement@bootlin.com,
miquel.raynal@bootlin.com, nadavh@marvell.com,
stefanc@marvell.com, mw@semihalf.com
Subject: Re: [PATCH net-next 4/7] net: phy: marvell10g: Add support for 2.5GBASET and 5GBASET
Date: Mon, 21 Jan 2019 21:17:15 +0100 [thread overview]
Message-ID: <20190121201715.GA20277@lunn.ch> (raw)
In-Reply-To: <20190118152352.26417-5-maxime.chevallier@bootlin.com>
> @@ -264,8 +265,10 @@ static int mv3310_config_init(struct phy_device *phydev)
> if (ret)
> return ret;
>
> - linkmode_and(phydev->advertising, phydev->advertising,
> - phydev->supported);
> + /* Make sure we advertise all the supported modes, and not just the
> + * default one specified in the driver's .features.
> + */
> + linkmode_copy(phydev->advertising, phydev->supported);
Hi Maxime
What Russell is referring to is:
static int phy_probe(struct device *dev)
{
..
/* Start out supporting everything. Eventually,
* a controller will attach, and may modify one
* or both of these values
*/
linkmode_copy(phydev->supported, phydrv->features);
of_set_phy_supported(phydev);
linkmode_copy(phydev->advertising, phydev->supported);
/* Get the EEE modes we want to prohibit. We will ask
* the PHY stop advertising these mode later on
*/
of_set_phy_eee_broken(phydev);
/* The Pause Frame bits indicate that the PHY can support passing
* pause frames. During autonegotiation, the PHYs will determine if
* they should allow pause frames to pass. The MAC driver should then
* use that result to determine whether to enable flow control via
* pause frames.
*
* Normally, PHY drivers should not set the Pause bits, and instead
* allow phylib to do that. However, there may be some situations
* (e.g. hardware erratum) where the driver wants to set only one
* of these bits.
*/
if (test_bit(ETHTOOL_LINK_MODE_Pause_BIT, phydrv->features) ||
test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, phydrv->features)) {
linkmode_clear_bit(ETHTOOL_LINK_MODE_Pause_BIT,
phydev->supported);
linkmode_clear_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
phydev->supported);
if (test_bit(ETHTOOL_LINK_MODE_Pause_BIT, phydrv->features))
linkmode_set_bit(ETHTOOL_LINK_MODE_Pause_BIT,
phydev->supported);
if (test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
phydrv->features))
linkmode_set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
phydev->supported);
} else {
linkmode_set_bit(ETHTOOL_LINK_MODE_Pause_BIT,
phydev->supported);
linkmode_set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
phydev->supported);
}
So by doing a copy of supported into advertising, you can stomping
over any restrictions applied via of_set_phy_supported(),
of_set_phy_eee_broken(phydev), and any pause control settings which
might of happened.
What might make sense here is that a PHY driver can replace its
.features member at run time, in its config_init() call. The core then
needs to perform these evaluations. So i'm guessing we need to split
this code out of probe() and move it into phy_init_hw()?
Heiner, you know this code better than anybody. What do you think?
Andrew
next prev parent reply other threads:[~2019-01-21 20:17 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-18 15:23 [PATCH net-next 0/7] net: phy: Add support for 2.5GBASET PHYs Maxime Chevallier
2019-01-18 15:23 ` Maxime Chevallier
2019-01-18 15:23 ` [PATCH net-next 1/7] net: phy: Extract genphy_c45_read_abilities from marvell10g Maxime Chevallier
2019-01-18 15:23 ` Maxime Chevallier
2019-01-20 18:51 ` Andrew Lunn
2019-01-20 18:51 ` Andrew Lunn
2019-01-21 16:20 ` Maxime Chevallier
2019-01-21 16:20 ` Maxime Chevallier
2019-01-21 16:28 ` Andrew Lunn
2019-01-21 16:28 ` Andrew Lunn
2019-01-18 15:23 ` [PATCH net-next 2/7] net: phy: Add generic support for 2.5GBaseT and 5GBaseT Maxime Chevallier
2019-01-18 15:23 ` Maxime Chevallier
2019-01-18 15:23 ` [PATCH net-next 3/7] net: phy: Read 2.5G and 5G extended abilities Maxime Chevallier
2019-01-18 15:23 ` Maxime Chevallier
2019-01-18 15:23 ` [PATCH net-next 4/7] net: phy: marvell10g: Add support for 2.5GBASET and 5GBASET Maxime Chevallier
2019-01-18 15:23 ` Maxime Chevallier
2019-01-18 15:51 ` Russell King - ARM Linux admin
2019-01-18 15:51 ` Russell King - ARM Linux admin
2019-01-21 20:17 ` Andrew Lunn [this message]
2019-01-21 20:17 ` Andrew Lunn
2019-01-22 10:08 ` Maxime Chevallier
2019-01-22 10:08 ` Maxime Chevallier
2019-01-18 15:23 ` [PATCH net-next 5/7] net: phy: marvell10g: Force reading of 2.5/5G PMA extended abilities Maxime Chevallier
2019-01-18 15:23 ` Maxime Chevallier
2019-01-20 19:08 ` Andrew Lunn
2019-01-20 19:08 ` Andrew Lunn
2019-01-21 10:35 ` Maxime Chevallier
2019-01-21 10:35 ` Maxime Chevallier
2019-01-21 10:52 ` Russell King - ARM Linux admin
2019-01-21 10:52 ` Russell King - ARM Linux admin
2019-01-21 12:29 ` Maxime Chevallier
2019-01-21 12:29 ` Maxime Chevallier
2019-01-21 13:00 ` Russell King - ARM Linux admin
2019-01-21 13:00 ` Russell King - ARM Linux admin
2019-01-28 14:26 ` Maxime Chevallier
2019-01-28 14:26 ` Maxime Chevallier
2019-02-07 23:37 ` Russell King - ARM Linux admin
2019-02-07 23:37 ` Russell King - ARM Linux admin
2019-01-18 15:23 ` [PATCH net-next 6/7] net: mvpp2: Add 2.5GBaseT support Maxime Chevallier
2019-01-18 15:23 ` Maxime Chevallier
2019-01-18 15:23 ` [PATCH net-next 7/7] net: phy: marvell10g: add support for the 88x2110 PHY Maxime Chevallier
2019-01-18 15:23 ` Maxime Chevallier
2019-01-20 19:10 ` Andrew Lunn
2019-01-20 19:10 ` Andrew Lunn
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=20190121201715.GA20277@lunn.ch \
--to=andrew@lunn.ch \
--cc=antoine.tenart@bootlin.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=gregory.clement@bootlin.com \
--cc=hkallweit1@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=miquel.raynal@bootlin.com \
--cc=mw@semihalf.com \
--cc=nadavh@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=stefanc@marvell.com \
--cc=thomas.petazzoni@bootlin.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.