From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Horatiu Vultur <horatiu.vultur@microchip.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
andrew@lunn.ch, hkallweit1@gmail.com, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
richardcochran@gmail.com
Subject: Re: [PATCH net-next] net: phy: micrel: Add support for PTP_PF_PEROUT for lan8841
Date: Fri, 17 Feb 2023 13:30:06 +0000 [thread overview]
Message-ID: <Y++BXkdXO8oysQ8M@shell.armlinux.org.uk> (raw)
In-Reply-To: <20230217075213.2366042-1-horatiu.vultur@microchip.com>
On Fri, Feb 17, 2023 at 08:52:13AM +0100, Horatiu Vultur wrote:
> +static void lan8841_ptp_perout_off(struct kszphy_ptp_priv *ptp_priv, int pin)
> +{
> + struct phy_device *phydev = ptp_priv->phydev;
> + u16 tmp;
> +
> + tmp = phy_read_mmd(phydev, 2, LAN8841_GPIO_EN) & LAN8841_PTP_GPIO_MASK;
> + tmp &= ~BIT(pin);
> + phy_write_mmd(phydev, 2, LAN8841_GPIO_EN, tmp);
Problem 1: doesn't check the return value of phy_read_mmd(), so a
spurious error results in an error code written back to the register.
Issue 2: please use phy_modify_mmd() and definitions for the MMD. It
probably also makes sense to cache the mask. Thus, this whole thing
becomes:
u16 mask = ~(LAN8841_PTP_GPIO_MASK | BIT(pin));
phy_modify_mmd(phydev, MDIO_MMD_WIS, LAN8841_GPIO_EN, mask, 0);
phy_modify_mmd(phydev, MDIO_MMD_WIS, LAN8841_GPIO_DIR, mask, 0);
phy_modify_mmd(phydev, MDIO_MMD_WIS, LAN8841_GPIO_BUF, mask, 0);
although I'm not sure why you need to mask off bits 15:11.
> +
> + tmp = phy_read_mmd(phydev, 2, LAN8841_GPIO_DIR) & LAN8841_PTP_GPIO_MASK;
> + tmp &= ~BIT(pin);
> + phy_write_mmd(phydev, 2, LAN8841_GPIO_DIR, tmp);
> +
> + tmp = phy_read_mmd(phydev, 2, LAN8841_GPIO_BUF) & LAN8841_PTP_GPIO_MASK;
> + tmp &= ~BIT(pin);
> + phy_write_mmd(phydev, 2, LAN8841_GPIO_BUF, tmp);
> +}
> +
> +static void lan8841_ptp_perout_on(struct kszphy_ptp_priv *ptp_priv, int pin)
> +{
> + struct phy_device *phydev = ptp_priv->phydev;
> + u16 tmp;
> +
> + tmp = phy_read_mmd(phydev, 2, LAN8841_GPIO_EN) & LAN8841_PTP_GPIO_MASK;
> + tmp |= BIT(pin);
> + phy_write_mmd(phydev, 2, LAN8841_GPIO_EN, tmp);
> +
> + tmp = phy_read_mmd(phydev, 2, LAN8841_GPIO_DIR) & LAN8841_PTP_GPIO_MASK;
> + tmp |= BIT(pin);
> + phy_write_mmd(phydev, 2, LAN8841_GPIO_DIR, tmp);
> +
> + tmp = phy_read_mmd(phydev, 2, LAN8841_GPIO_BUF) & LAN8841_PTP_GPIO_MASK;
> + tmp |= BIT(pin);
> + phy_write_mmd(phydev, 2, LAN8841_GPIO_BUF, tmp);
Similar as above.
> +static void lan8841_ptp_remove_event(struct kszphy_ptp_priv *ptp_priv, int pin,
> + u8 event)
> +{
> + struct phy_device *phydev = ptp_priv->phydev;
> + u8 offset;
> + u16 tmp;
> +
> + /* Not remove pin from the event. GPIO_DATA_SEL1 contains the GPIO
> + * pins 0-4 while GPIO_DATA_SEL2 contains GPIO pins 5-9, therefore
> + * depending on the pin, it requires to read a different register
> + */
> + if (pin < 5) {
> + tmp = phy_read_mmd(phydev, 2, LAN8841_GPIO_DATA_SEL1);
> + offset = pin;
> + } else {
> + tmp = phy_read_mmd(phydev, 2, LAN8841_GPIO_DATA_SEL2);
> + offset = pin - 5;
> + }
> + tmp &= ~(LAN8841_GPIO_DATA_SEL_GPIO_DATA_SEL_EVENT_MASK << (3 * offset));
> + if (pin < 5)
> + phy_write_mmd(phydev, 2, LAN8841_GPIO_DATA_SEL1, tmp);
> + else
> + phy_write_mmd(phydev, 2, LAN8841_GPIO_DATA_SEL2, tmp);
This could be much simpler using phy_modify_mmd().
> +
> + /* Disable the event */
> + tmp = phy_read_mmd(phydev, 2, LAN8841_PTP_GENERAL_CONFIG);
> + if (event == LAN8841_EVENT_A) {
> + tmp &= ~LAN8841_PTP_GENERAL_CONFIG_LTC_EVENT_POL_A;
> + tmp &= ~LAN8841_PTP_GENERAL_CONFIG_LTC_EVENT_A_MASK;
> + } else {
> + tmp &= ~LAN8841_PTP_GENERAL_CONFIG_LTC_EVENT_POL_A;
> + tmp &= ~LAN8841_PTP_GENERAL_CONFIG_LTC_EVENT_A_MASK;
> + }
> + phy_write_mmd(phydev, 2, LAN8841_PTP_GENERAL_CONFIG, tmp);
Ditto... and the theme seems to continue throughout the rest of this
patch.
> +static int lan8841_ptp_perout(struct ptp_clock_info *ptp,
> + struct ptp_clock_request *rq, int on)
> +{
> + struct kszphy_ptp_priv *ptp_priv = container_of(ptp, struct kszphy_ptp_priv,
> + ptp_clock_info);
> + struct phy_device *phydev = ptp_priv->phydev;
> + struct timespec64 ts_on, ts_period;
> + s64 on_nsec, period_nsec;
> + int pulse_width;
> + int pin;
> +
> + if (rq->perout.flags & ~PTP_PEROUT_DUTY_CYCLE)
> + return -EOPNOTSUPP;
> +
> + pin = ptp_find_pin(ptp_priv->ptp_clock, PTP_PF_PEROUT, rq->perout.index);
> + if (pin == -1 || pin >= LAN8841_PTP_GPIO_NUM)
> + return -EINVAL;
> +
> + if (!on) {
> + lan8841_ptp_perout_off(ptp_priv, pin);
> + lan8841_ptp_remove_event(ptp_priv, LAN8841_EVENT_A, pin);
> + return 0;
> + }
> +
> + ts_on.tv_sec = rq->perout.on.sec;
> + ts_on.tv_nsec = rq->perout.on.nsec;
> + on_nsec = timespec64_to_ns(&ts_on);
> +
> + ts_period.tv_sec = rq->perout.period.sec;
> + ts_period.tv_nsec = rq->perout.period.nsec;
> + period_nsec = timespec64_to_ns(&ts_period);
> +
> + if (period_nsec < 200) {
> + phydev_warn(phydev,
> + "perout period too small, minimum is 200 nsec\n");
I'm not sure using the kernel log to print such things is a good idea,
especially without rate limiting.
> @@ -3874,7 +4220,24 @@ static int lan8841_probe(struct phy_device *phydev)
> priv = phydev->priv;
> ptp_priv = &priv->ptp_priv;
>
> + ptp_priv->pin_config = devm_kmalloc_array(&phydev->mdio.dev,
> + LAN8841_PTP_GPIO_NUM,
> + sizeof(*ptp_priv->pin_config),
> + GFP_KERNEL);
devm_kcalloc() to avoid the memset() below?
--
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:[~2023-02-17 13:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 7:52 [PATCH net-next] net: phy: micrel: Add support for PTP_PF_PEROUT for lan8841 Horatiu Vultur
2023-02-17 13:30 ` Russell King (Oracle) [this message]
2023-02-17 13:33 ` Russell King (Oracle)
2023-02-17 15:02 ` Horatiu Vultur
2023-02-18 0:55 ` Andrew Lunn
2023-02-18 12:10 ` Horatiu Vultur
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=Y++BXkdXO8oysQ8M@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=horatiu.vultur@microchip.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.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.