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 ? Thanks and Best Regards, Jose Miguel Abreu