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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YiYGYuOGLMaRz45W@lunn.ch>
Date:   Mon, 7 Mar 2022 14:19:30 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Divya.Koppera@...rochip.com
Cc:     netdev@...r.kernel.org, hkallweit1@...il.com,
        linux@...linux.org.uk, davem@...emloft.net, kuba@...nel.org,
        robh+dt@...nel.org, devicetree@...r.kernel.org,
        richardcochran@...il.com, linux-kernel@...r.kernel.org,
        UNGLinuxDriver@...rochip.com, Madhuri.Sripada@...rochip.com,
        Manohar.Puri@...rochip.com
Subject: Re: [PATCH net-next 3/3] net: phy: micrel: 1588 support for LAN8814
 phy

> > > +     /* 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