Re: [PATCH net-next 3/3] net: phy: micrel: 1588 support for LAN8814 phy

Andrew Lunn
2022-03-07T13:19:38Z

> > > + /* Make sure the PHY is not broken. Read idle error count,
> > > + * and reset the PHY if it is maxed out.
> > > + */
> > > + regval = phy_read(phydev, MII_STAT1000);
> > > + if ((regval & 0xFF) == 0xFF) {
> > > + phy_init_hw(phydev);
> > > + phydev->link = 0;
> > > + if (phydev->drv->config_intr && phy_interrupt_is_valid(phydev))
> > > + phydev->drv->config_intr(phydev);
> > > + return genphy_config_aneg(phydev);
> > > + }
> >
> > Is this related to PTP? Or is the PHY broken in general? This looks like it should
> > be something submitted to stable.
> >
>
> Previously lan8814 phy used kszphy_read_status, we have reused the same function and added new
> Changes related to latency with new function lan8814_read_status.

Ah, ksz9031_read_status() already has this workaround. How important
is the ordering here? Rather than cut/paste the code, why not actually
call ksz9031_read_status() to get the basic link status and then
append the additional information in this function.

> > > +static int lan8814_config_init(struct phy_device *phydev) {
> > > + int val;
> > > +
> > > + /* Reset the PHY */
> > > + val = lanphy_read_page_reg(phydev, 4, LAN8814_QSGMII_SOFT_RESET);
> > > + val |= LAN8814_QSGMII_SOFT_RESET_BIT;
> > > + lanphy_write_page_reg(phydev, 4, LAN8814_QSGMII_SOFT_RESET,
> > > + val);
> > > +
> > > + /* Disable ANEG with QSGMII PCS Host side */
> > > + val = lanphy_read_page_reg(phydev, 5,
> > LAN8814_QSGMII_PCS1G_ANEG_CONFIG);
> > > + val &= ~LAN8814_QSGMII_PCS1G_ANEG_CONFIG_ANEG_ENA;
> > > + lanphy_write_page_reg(phydev, 5,
> > > + LAN8814_QSGMII_PCS1G_ANEG_CONFIG, val);
> > > +
> > > + /* MDI-X setting for swap A,B transmit */
> > > + val = lanphy_read_page_reg(phydev, 2, LAN8814_ALIGN_SWAP);
> > > + val &= ~LAN8814_ALIGN_TX_A_B_SWAP_MASK;
> > > + val |= LAN8814_ALIGN_TX_A_B_SWAP;
> > > + lanphy_write_page_reg(phydev, 2, LAN8814_ALIGN_SWAP, val);
> >
> > This does not look related to PTP. If David has not ready merged this, i would
> > of said you should of submitted this as a separate patch.
> >
>
> This code already present in lan8814 phy code. I think due to movement of function from up to down.
> This change reflected here.

I don't remember seeing the same code with - at the beginning. In
general, it is better to have lots of small patches, each being
obviously correct. If you need to move a function earlier/later, do it
in a patch of its own. It is obviously correct, so takes 0 time to
review, and makes the remaining patches simpler, so also easier to
review.

Andrew