[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y889m+CUSTbuv9Db@lunn.ch>
Date: Tue, 24 Jan 2023 03:08:27 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Alexandru Tachici <alexandru.tachici@...log.com>
Cc: linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, richardcochran@...il.com,
yangyingliang@...wei.com, weiyongjun1@...wei.com,
robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
devicetree@...r.kernel.org, lennart@...omain.com
Subject: Re: [net-next 1/3] net: ethernet: adi: adin1110: add PTP clock
support
> +static int adin1110_enable_perout(struct adin1110_priv *priv,
> + struct ptp_perout_request perout,
> + int on)
> +{
> + u32 on_nsec;
> + u32 phase;
> + u32 mask;
> + int ret;
> +
> + if (priv->cfg->id == ADIN2111_MAC) {
> + ret = phy_clear_bits_mmd(priv->ports[0]->phydev, MDIO_MMD_VEND1,
> + ADIN2111_LED_CNTRL,
> + ADIN2111_LED_CNTRL_LED0_FUNCTION);
> + if (ret < 0)
> + return ret;
> +
> + ret = phy_set_bits_mmd(priv->ports[0]->phydev, MDIO_MMD_VEND1,
> + ADIN2111_LED_CNTRL,
> + on ? ADIN2111_LED_CNTRL_TS_TIMER : 0);
I normally say a MAC driver should not be accessing PHY register...
You have the advantage of knowing it is integrated, so you know
exactly what PHY it is. But you still have a potential race condition
sometime in the future. You are not taking the phydev->lock, which is
something phylib nearly always does before accessing a PHY. If you
ever add control of the LEDs, that lack of locking could get you in
trouble.
Is this functionality always on LED0? It cannot be LED1 or LED2?
Andrew
Powered by blists - more mailing lists