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
| ||
|
Date: Fri, 21 Feb 2020 17:10:24 +0000 From: Russell King - ARM Linux admin <linux@...linux.org.uk> To: Florian Fainelli <f.fainelli@...il.com> Cc: Alexandre Belloni <alexandre.belloni@...tlin.com>, "David S. Miller" <davem@...emloft.net>, Nicolas Ferre <nicolas.ferre@...rochip.com>, Antoine Ténart <antoine.tenart@...tlin.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org Subject: Re: [PATCH net] net: macb: Properly handle phylink on at91rm9200 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@...tlin.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
Powered by blists - more mailing lists