netdev - Re: [PATCH RFC net-next v2 3/8] net: stmmac: dwmac1000: convert sgmii/rgmii "pcs" to phylink

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: <doeizqmec22tqez5zwhysppmm2vg2rhzp2siy5ogdncitbtx5b@mycxnahybvlp>
Date: Fri, 14 Jun 2024 00:14:18 +0300
From: Serge Semin <fancer.lancer@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Halaney <ahalaney@...hat.com>, 
	Alexandre Torgue <alexandre.torgue@...s.st.com>, Jose Abreu <joabreu@...opsys.com>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Maxime Coquelin <mcoquelin.stm32@...il.com>, netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com, 
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RFC net-next v2 3/8] net: stmmac: dwmac1000: convert
 sgmii/rgmii "pcs" to phylink

On Wed, Jun 12, 2024 at 11:04:11PM +0100, Russell King (Oracle) wrote:
> On Tue, Jun 11, 2024 at 03:25:14PM +0300, Serge Semin wrote:
> > Hi Russell, Andrew
> >
> > Should we have a DW IP-core-specific getter like
> > stmmac_ops::pcs_get_config_reg() which would return the
> > tx_config_reg[15:0] field then we could have cleared the IRQ by just
> > calling it, we could have had the fields generically
> > parsed in the dwmac_pcs_isr() handler and in the
> > phylink_pcs_ops::pcs_get_state().
> 

> pcs_get_state() is not supposed to get some cached state,

It won't.

> but is
> supposed to return the real state at the time that it is called.

The idea is to implement the tx_config_reg[15:0] getter for DW GMAC
and DW QoS Eth. It will return the current link status retrieved from
the GMAC_RGSMIIIS and GMAC_PHYIF_CONTROL_STATUS registers. Like this:

GMAC:
u16 dwmac1000_pcs_get_config_reg(struct stmmac_priv *priv)
{
	return readl(priv->ioaddr + GMAC_RGSMIIIS);
}

DW QoS Eth:
u16 dwmac1000_pcs_get_config_reg(struct stmmac_priv *priv)
{
	return readl(priv->ioaddr + GMAC_PHYIF_CONTROL_STATUS) >> 16;
}

Then the dwmac_pcs_isr() can be updated as follows:

static inline void dwmac_pcs_isr(void __iomem *ioaddr, u32 reg,
                                 unsigned int intr_status,
                                 struct stmmac_extra_stats *x)
{
	...

	if (intr_status & PCS_RGSMIIIS_IRQ) {
		x->irq_rgmii_n++;
		/* The next will clear the PCS_RGSMIIIS_IRQ IRQ
		 * status. (It is done instead of dummy-reading the
		 * GMAC_RGSMIIIS/GMAC_PHYIF_CONTROL_STATUS registers
		 * in the DW GMAC/QoS Eth IRQ handlers.)
		 */
		(void)stmmac_pcs_get_config_reg(priv);
	}
}

Similarly the dwmac_pcs_get_state() method can now use the
stmmac_pcs_get_config_reg() function to retrieve the link state and
parse the data in a generic manner. Thus everything what is currently
done in dwmac1000_mii_pcs_get_state() and dwmac4_mii_pcs_get_state()
could be moved to dwmac_pcs_get_state(). By providing a single
STMMAC-driver callback stmmac_ops::pcs_get_config_reg(), we'll be able
to define the phylink_pcs_ops::{pcs_validate,pcs_config,pcs_get_state}
methods in the stmmac_pcs.c file.

> 
> There's a good reason for this - dealing with latched-low link failed
> indications, it's necessary that pcs_get_state() reports that the link
> failed if _sometime_ between the last time it was called and the next
> time the link has failed.
> 
> So, I'm afraid your idea of simplifying it doesn't sound to me like a
> good idea.

No caching or latched link state indications. Both the GMAC_RGSMIIIS
and GMAC_PHYIF_CONTROL_STATUS registers contain the actual link state
retrieved the PHY. stmmac_pcs_get_config_reg() will just return the
current link state.

Perhaps my suggestion might haven't been well described. Providing the
patches with the respective changes shall better describe what was
meant. So in a few days I'll submit an incremental patch(es) with the
proposed modifications for your series.

-Serge(y)

> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!