Re: [PATCH net-next v2] net: phy: motorcomm: enable the reference clock for YT8521 and YT8531

Gavin Gao <[email protected]>
Newsgroups org.infradead.lists.linux-rockchip,org.kernel.vger.linux-kernel,org.kernel.vger.netdev
Message-ID <CAK2JjQVsJbC5wuLs1wFvose0S9ho6FDNPbhteveWOttE0prjeA@mail.gmail.com>
Hi Alexey,

I slightly prefer keeping the helper.

This looks like a common pattern for the Motorcomm family rather than a
YT8521/YT8531-specific detail. Other PHYs in the same series may need the
same optional reference clock handling later, and a small helper keeps
that path easy to reuse without duplicating the same code.

Best Regards,
Gavin Gao

On Tue, Jul 28, 2026 at 12:16 PM Alexey Charkov <[email protected]> wrote:
>
> Hi Jaxing,
>
> On Tue, Jul 28, 2026 at 1:04 AM Jiaxing Hu <[email protected]> wrote:
> >
> > These PHYs need a 25 MHz reference. On boards without a local crystal
> > it is fed from the SoC and described as a clock on the PHY node. Get and
> > enable it in probe, via a small helper called from both yt8521_probe and
> > yt8531_probe, so the PHY is clocked before its registers are accessed.
> > The clock is optional, so crystal-clocked boards are unaffected.
> >
> > Reviewed-by: Andrew Lunn <[email protected]>
> > Signed-off-by: Jiaxing Hu <[email protected]>
> > ---
> >
> > Changes in v2:
> > - Factor the clock enable into ytphy_get_and_enable_refclk() and call it
> >   from yt8521_probe as well, so the YT8521 is covered too, not only the
> >   YT8531. v1 only touched yt8531_probe.
> > - Carried Andrew's Reviewed-by; the enable itself is unchanged, only
> >   moved into the helper.
> >
> > v1: https://lore.kernel.org/all/[email protected]/
> >
> > A second crystal-less RK3576 board with a YT8521 needs the same handling
> > (see the RK3576 GMAC 25M refout thread [1]), so v2 covers both PHYs. This
> > supersedes the withdrawn dwmac-rk MAC-side series. The DTS that consumes
> > the clock (rk3576-armsom-cm5) goes to the rockchip tree separately; the
> > clock is optional so this patch stands alone. The YT8531 path is tested
> > on an ArmSoM CM5-IO (links at 1000 Mbit/s).
> >
> > [1] https://lore.kernel.org/all/[email protected]/
> >
> >  drivers/net/phy/motorcomm.c | 33 +++++++++++++++++++++++++++++++++
> >  1 file changed, 33 insertions(+)
> >
> > diff --git a/drivers/net/phy/motorcomm.c b/drivers/net/phy/motorcomm.c
> > index 708491bc1..32eb5ce93 100644
> > --- a/drivers/net/phy/motorcomm.c
> > +++ b/drivers/net/phy/motorcomm.c
> > @@ -6,6 +6,7 @@
> >   * Author: Frank <[email protected]>
> >   */
> >
> > +#include <linux/clk.h>
> >  #include <linux/etherdevice.h>
> >  #include <linux/kernel.h>
> >  #include <linux/module.h>
> > @@ -1043,6 +1044,29 @@ static int yt8531_set_ds(struct phy_device *phydev)
> >         return 0;
> >  }
> >
> > +/**
> > + * ytphy_get_and_enable_refclk() - get and enable the PHY reference clock
> > + * @phydev: a pointer to a &struct phy_device
> > + *
> > + * A crystal-less YT8521/YT8531 takes its 25 MHz reference from the SoC. When
> > + * that reference is described as a clock, enable it for the life of the
> > + * device. It is optional, so crystal-clocked boards are unaffected.
> > + *
> > + * returns 0 or negative errno code
> > + */
> > +static int ytphy_get_and_enable_refclk(struct phy_device *phydev)
> > +{
> > +       struct device *dev = &phydev->mdio.dev;
> > +       struct clk *clk;
> > +
> > +       clk = devm_clk_get_optional_enabled(dev, NULL);
> > +       if (IS_ERR(clk))
> > +               return dev_err_probe(dev, PTR_ERR(clk),
> > +                                    "failed to get and enable the reference clock\n");
>
> A helper for a single-line function call looks like an overkill, and
> requires scrolling to understand what is going on where an open-coded
> version would be self-explanatory at the first glance.
>
> Maybe fold it into the two caller functions instead?
>
> Best regards,
> Alexey

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.