From: Andrew Lunn <andrew@lunn.ch>
To: Ivan Bornyakov <i.bornyakov@metrotek.ru>
Cc: netdev@vger.kernel.org, system@metrotek.ru, hkallweit1@gmail.com,
linux@armlinux.org.uk, davem@davemloft.net, kuba@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] net: phy: add Marvell 88X2222 transceiver support
Date: Sat, 20 Feb 2021 17:27:36 +0100 [thread overview]
Message-ID: <YDE4eJFly/to0SMn@lunn.ch> (raw)
In-Reply-To: <20210220094621.tl6fawj7c5hjrp6s@dhcp-179.ddg>
Hi Ivan
> +static int sfp_module_insert(void *_priv, const struct sfp_eeprom_id *id)
> +{
> + struct phy_device *phydev = _priv;
> + struct device *dev = &phydev->mdio.dev;
> + struct mv2222_data *priv = phydev->priv;
> + phy_interface_t sfp_interface;
Reverse Christmas tree please. Which means you will need to move some
of the assignments to the body of the function. Please also drop the _
from _priv.
> +
> + __ETHTOOL_DECLARE_LINK_MODE_MASK(sfp_supported) = { 0, };
> +
> + sfp_parse_support(phydev->sfp_bus, id, sfp_supported);
> + sfp_interface = sfp_select_interface(phydev->sfp_bus, sfp_supported);
> +
> + dev_info(dev, "%s SFP module inserted", phy_modes(sfp_interface));
> +
> + switch (sfp_interface) {
> + case PHY_INTERFACE_MODE_10GBASER:
> + phydev->speed = SPEED_10000;
> + phy_write_mmd(phydev, MDIO_MMD_VEND2, MV_PCS_CONFIG,
> + MV_PCS_HOST_XAUI | MV_PCS_LINE_10GBR);
> + break;
> + case PHY_INTERFACE_MODE_1000BASEX:
> + phydev->speed = SPEED_1000;
> + phy_write_mmd(phydev, MDIO_MMD_VEND2, MV_PCS_CONFIG,
> + MV_PCS_HOST_XAUI | MV_PCS_LINE_1GBX_AN);
> + break;
> + case PHY_INTERFACE_MODE_SGMII:
> + phydev->speed = SPEED_1000;
SPEED_UNKNOWN might be better here, until auto negotiation has
completed and you then know if it is 10/100/1G.
> + phy_write_mmd(phydev, MDIO_MMD_VEND2, MV_PCS_CONFIG,
> + MV_PCS_HOST_XAUI | MV_PCS_LINE_SGMII_AN);
> + phy_modify_mmd(phydev, MDIO_MMD_PCS, MV_1GBX_CTRL,
> + BMCR_SPEED1000 | BMCR_SPEED100, BMCR_SPEED1000);
> + break;
> + default:
> + dev_err(dev, "Incompatible SFP module inserted\n");
> +
> + return -EINVAL;
> + }
> +
> + linkmode_and(phydev->supported, priv->supported, sfp_supported);
> + priv->line_interface = sfp_interface;
> +
> + return mv2222_soft_reset(phydev);
> +}
> +
> +static void sfp_module_remove(void *_priv)
> +{
> + struct phy_device *phydev = _priv;
> + struct mv2222_data *priv = phydev->priv;
More reverse christmass tree.
> +
> + priv->line_interface = PHY_INTERFACE_MODE_NA;
> + linkmode_copy(phydev->supported, priv->supported);
> +}
> +
> +static int mv2222_config_aneg(struct phy_device *phydev)
> +{
> + /* Try 10G first */
> + if (mv2222_is_10g_capable(phydev)) {
> + phydev->speed = SPEED_10000;
> + mv2222_update_interface(phydev);
> +
> + ret = phy_read_mmd(phydev, MDIO_MMD_PCS, MV_10GBR_STAT_RT);
> + if (ret < 0)
> + return ret;
> +
> + if (ret & MDIO_STAT1_LSTATUS) {
> + phydev->autoneg = AUTONEG_DISABLE;
> +
> + return mv2222_disable_aneg(phydev);
> + }
> +
> + /* 10G link was not established, switch back to 1G
> + * and proceed with true autonegotiation */
> + phydev->speed = SPEED_1000;
> + mv2222_update_interface(phydev);
So you are assuming the cable is plugged in and the peer is ready to
go? Try 10G once, and then fall back to 1G? This does not seem very
reliable, and likely to cause confusion. It works sometimes, not
others. I'm not sure this is a good idea.
> +static void mv2222_remove(struct phy_device *phydev)
> +{
> + struct device *dev = &phydev->mdio.dev;
> + struct mv2222_data *priv = phydev->priv;
> +
> + if (priv)
> + devm_kfree(dev, priv);
Why can devm_kfree(). The point of devm_ is that it frees itself.
Andrew
next prev parent reply other threads:[~2021-02-20 16:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-01 19:22 [PATCH] net: phy: add Marvell 88X2222 transceiver support Ivan Bornyakov
2021-02-01 22:56 ` Andrew Lunn
2021-02-02 15:32 ` Ivan Bornyakov
2021-02-02 16:48 ` Russell King - ARM Linux admin
2021-02-02 20:45 ` Ivan Bornyakov
2021-02-20 9:46 ` [PATCH v2] " Ivan Bornyakov
2021-02-20 11:53 ` Russell King - ARM Linux admin
2021-02-20 15:51 ` Ivan Bornyakov
2021-02-20 16:30 ` Andrew Lunn
2021-02-20 16:27 ` Andrew Lunn [this message]
2021-03-03 10:57 ` [PATCH v3] " Ivan Bornyakov
2021-03-03 11:36 ` Russell King - ARM Linux admin
2021-03-03 15:27 ` Ivan Bornyakov
2021-03-03 16:02 ` [PATCH v4] " Ivan Bornyakov
2021-03-10 9:33 ` Ivan Bornyakov
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=YDE4eJFly/to0SMn@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=i.bornyakov@metrotek.ru \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=system@metrotek.ru \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox