On Tue, Oct 23, 2018 at 11:17:50AM +0100, Jose Abreu wrote: > On 22-10-2018 18:13, Florian Fainelli wrote: > > On 10/22/18 8:48 AM, Russell King - ARM Linux wrote: > >> On Mon, Oct 22, 2018 at 01:47:48PM +0100, Jose Abreu wrote: > >>> Hello, > >>> > >>> On 22-10-2018 13:28, Andrew Lunn wrote: > >>>>> EXPORT_SYMBOL_GPL(gen10g_resume); > >>>>> @@ -327,7 +381,7 @@ struct phy_driver genphy_10g_driver = { > >>>>> .phy_id = 0xffffffff, > >>>>> .phy_id_mask = 0xffffffff, > >>>>> .name = "Generic 10G PHY", > >>>>> - .soft_reset = gen10g_no_soft_reset, > >>>>> + .soft_reset = gen10g_soft_reset, > >>>>> .config_init = gen10g_config_init, > >>>>> .features = 0, > >>>>> .aneg_done = genphy_c45_aneg_done, > >>>> Hi Jose > >>>> > >>>> You need to be careful here. There is a reason this is called > >>>> gen10g_no_soft_reset, rather than having an empty > >>>> gen10g_soft_reset. Some PHYs break when you do a reset. So adding a > >>>> gen10g_soft_reset is fine, but don't change this here, without first > >>>> understanding the history, and talking to Russell King. > >>> Hmm, the reset function only interacts with standard PCS > >>> registers, which should always be available ... > >>> > >>> >From my tests I need to do at least 1 reset during power-up so in > >>> ultimate case I can add a feature quirk or similar. > >>> > >>> Russell, can you please comment ? > >> Setting the reset bit on 88x3310 causes the entire device to become > >> completely inaccessible until hardware reset. Therefore, this bit > >> must _never_ be set for these devices. That said, we have a separate > >> driver for these PHYs, but that will only be used for them if it's > >> present in the kernel. If we accidentally fall back to the generic > >> driver, then we'll screw the 88x3310 until a full hardware reset. > >> > >> We also have a bunch of net devices that make use of this crippled > >> "generic" 10G support - we don't know whether resetting the PHY > >> for those systems will cause a regression - maybe board firmware > >> already configured the PHY? I can't say either way on that, except > >> that we've had crippled 10G support in PHYLIB for a number of years > >> now _with_ users, and adding reset support drastically changes the > >> subsystem's behaviour for these users. > >> > >> I would recommend not touching the generic 10G driver, but instead > >> implement your own driver for your PHY to avoid causing regressions. > >> > > Agreed. > > What about .suspend / .resume ?
I have no idea what you're proposing there - your patches weren't copied to me. -- RMK's Patch system: http://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