From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Martin Schiller <ms@dev.tdt.de>
Cc: hauke@hauke-m.de, martin.blumenstingl@googlemail.com,
f.fainelli@gmail.com, andrew@lunn.ch, hkallweit1@gmail.com,
davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] net: phy: intel-xway: Add RGMII internal delay configuration
Date: Fri, 9 Jul 2021 13:26:58 +0100 [thread overview]
Message-ID: <20210709122658.GA22278@shell.armlinux.org.uk> (raw)
In-Reply-To: <20210709115726.11897-1-ms@dev.tdt.de>
On Fri, Jul 09, 2021 at 01:57:26PM +0200, Martin Schiller wrote:
> +static int xway_gphy_of_reg_init(struct phy_device *phydev)
> +{
> + struct device *dev = &phydev->mdio.dev;
> + int delay_size = ARRAY_SIZE(xway_internal_delay);
> + s32 rx_int_delay;
> + s32 tx_int_delay;
> + int err = 0;
> + int val;
> +
> + if (phy_interface_is_rgmii(phydev)) {
> + val = phy_read(phydev, XWAY_MDIO_MIICTRL);
> + if (val < 0)
> + return val;
> + }
> +
> + /* Existing behavior was to use default pin strapping delay in rgmii
> + * mode, but rgmii should have meant no delay. Warn existing users.
> + */
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII) {
> + const u16 txskew = (val & XWAY_MDIO_MIICTRL_TXSKEW_MASK) >>
> + XWAY_MDIO_MIICTRL_TXSKEW_SHIFT;
> + const u16 rxskew = (val & XWAY_MDIO_MIICTRL_RXSKEW_MASK) >>
> + XWAY_MDIO_MIICTRL_RXSKEW_SHIFT;
> +
> + if (txskew > 0 || rxskew > 0)
> + phydev_warn(phydev,
> + "PHY has delays (e.g. via pin strapping), but phy-mode = 'rgmii'\n"
> + "Should be 'rgmii-id' to use internal delays txskew:%x rxskew:%x\n",
> + txskew, rxskew);
> + }
> +
> + /* RX delay *must* be specified if internal delay of RX is used. */
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
> + rx_int_delay = phy_get_internal_delay(phydev, dev,
> + &xway_internal_delay[0],
> + delay_size, true);
> +
> + if (rx_int_delay < 0) {
> + phydev_err(phydev, "rx-internal-delay-ps must be specified\n");
> + return rx_int_delay;
> + }
> +
> + val &= ~XWAY_MDIO_MIICTRL_RXSKEW_MASK;
> + val |= rx_int_delay << XWAY_MDIO_MIICTRL_RXSKEW_SHIFT;
> + }
> +
> + /* TX delay *must* be specified if internal delay of TX is used. */
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
> + tx_int_delay = phy_get_internal_delay(phydev, dev,
> + &xway_internal_delay[0],
> + delay_size, false);
> +
> + if (tx_int_delay < 0) {
> + phydev_err(phydev, "tx-internal-delay-ps must be specified\n");
> + return tx_int_delay;
> + }
> +
> + val &= ~XWAY_MDIO_MIICTRL_TXSKEW_MASK;
> + val |= tx_int_delay << XWAY_MDIO_MIICTRL_TXSKEW_SHIFT;
> + }
> +
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
> + err = phy_write(phydev, XWAY_MDIO_MIICTRL, val);
> +
> + return err;
> +}
Please reconsider the above. Maybe something like the following would
be better:
u16 mask = 0;
int val = 0;
if (!phy_interface_is_rgmii(phydev))
return;
if (phydev->interface == PHY_INTERFACE_MODE_RGMII) {
u16 txskew, rxskew;
val = phy_read(phydev, XWAY_MDIO_MIICTRL);
if (val < 0)
return val;
txskew = (val & XWAY_MDIO_MIICTRL_TXSKEW_MASK) >>
XWAY_MDIO_MIICTRL_TXSKEW_SHIFT;
rxskew = (val & XWAY_MDIO_MIICTRL_RXSKEW_MASK) >>
XWAY_MDIO_MIICTRL_RXSKEW_SHIFT;
if (txskew > 0 || rxskew > 0)
phydev_warn(phydev,
"PHY has delays (e.g. via pin strapping), but phy-mode = 'rgmii'\n"
"Should be 'rgmii-id' to use internal delays txskew:%x rxskew:%x\n",
txskew, rxskew);
return;
}
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
...
mask |= XWAY_MDIO_MIICTRL_RXSKEW_MASK;
val |= rx_int_delay << XWAY_MDIO_MIICTRL_RXSKEW_SHIFT;
}
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
...
mask |= XWAY_MDIO_MIICTRL_TXSKEW_MASK;
val |= rx_int_delay << XWAY_MDIO_MIICTRL_TXSKEW_SHIFT;
}
return phy_modify(phydev, XWAY_MDIO_MIICTRL, mask, val);
Using phy_modify() has the advantage that the read-modify-write is
done as a locked transaction on the bus, meaning that it is atomic.
There isn't a high cost to writing functions in a way that makes use
of that as can be seen from the above.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2021-07-09 12:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-09 11:57 [PATCH net-next] net: phy: intel-xway: Add RGMII internal delay configuration Martin Schiller
2021-07-09 12:26 ` Russell King (Oracle) [this message]
2021-07-09 13:01 ` Martin Schiller
2021-07-09 13:33 ` 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=20210709122658.GA22278@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hauke@hauke-m.de \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=ms@dev.tdt.de \
--cc=netdev@vger.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.