Re: [PATCH net] net: macb: Properly handle phylink on at91rm9200

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Mon, Feb 17, 2020 at 02:03:47PM -0800, Florian Fainelli wrote:
> 
> 
> On 2/17/2020 2:43 AM, Alexandre Belloni wrote:
> > at91ether_init was handling the phy mode and speed but since the switch to
> > phylink, the NCFGR register got overwritten by macb_mac_config().
> > 
> > Add new phylink callbacks to handle emac and at91rm9200 properly.
> > 
> > Fixes: 7897b071ac3b ("net: macb: convert to phylink")
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > ---
> 
> [snip]
> 
> > +static void at91ether_mac_link_up(struct phylink_config *config,
> > +				  unsigned int mode,
> > +				  phy_interface_t interface,
> > +				  struct phy_device *phy)
> > +{
> > +	struct net_device *ndev = to_net_dev(config->dev);
> > +	struct macb *bp = netdev_priv(ndev);
> > +
> > +	/* Enable Rx and Tx */
> > +	macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(RE) | MACB_BIT(TE));
> > +
> > +	netif_tx_wake_all_queues(ndev);
> 
> So this happens to be copied from the mvpp2 driver, if this is a
> requirement, should not this be moved to the phylink implementation
> since it already manages the carrier? Those two drivers are the only
> ones doing this.

Looking at mvneta, it does stuff with managing the queues itself, and
I suspect adding that into phylink will mess that driver up.  Maybe
someone with more knowledge can take a look.

But, IMHO, two drivers doing something is not grounds for moving it
into higher layers.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel