Unlike other ethernet PHYs from TI, PHY dp83822x has WOL enabled
at reset. The driver explicitly disables WOL in config_init callback
which is called during init and during resume from suspend. Hence,
WOL is unconditionally disabled during resume, even if it was enabled
before the suspend. We make sure that WOL configuration is persistent
across suspends.
Signed-off-by: Catalin Popescu <[email protected]>
---
drivers/net/phy/dp83822.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/dp83822.c b/drivers/net/phy/dp83822.c
index 95178e26a060..618317c1e27f 100644
--- a/drivers/net/phy/dp83822.c
+++ b/drivers/net/phy/dp83822.c
@@ -136,6 +136,7 @@
struct dp83822_private {
bool fx_signal_det_low;
+ bool wol_enabled;
int fx_enabled;
u16 fx_sd_enable;
u8 cfg_dac_minus;
@@ -146,8 +147,10 @@ static int dp83822_set_wol(struct phy_device *phydev,
struct ethtool_wolinfo *wol)
{
struct net_device *ndev = phydev->attached_dev;
+ struct dp83822_private *dp83822 = phydev->priv;
u16 value;
const u8 *mac;
+ int ret;
if (wol->wolopts & (WAKE_MAGIC | WAKE_MAGICSECURE)) {
mac = (const u8 *)ndev->dev_addr;
@@ -193,11 +196,17 @@ static int dp83822_set_wol(struct phy_device *phydev,
value |= DP83822_WOL_EN | DP83822_WOL_INDICATION_SEL |
DP83822_WOL_CLR_INDICATION;
- return phy_write_mmd(phydev, DP83822_DEVADDR,
- MII_DP83822_WOL_CFG, value);
+ ret = phy_write_mmd(phydev, DP83822_DEVADDR,
+ MII_DP83822_WOL_CFG, value);
+ if (!ret)
+ dp83822->wol_enabled = true;
+ return ret;
} else {
- return phy_clear_bits_mmd(phydev, DP83822_DEVADDR,
- MII_DP83822_WOL_CFG, DP83822_WOL_EN);
+ ret = phy_clear_bits_mmd(phydev, DP83822_DEVADDR,
+ MII_DP83822_WOL_CFG, DP83822_WOL_EN);
+ if (!ret)
+ dp83822->wol_enabled = false;
+ return ret;
}
}
@@ -493,6 +502,9 @@ static int dp83822_config_init(struct phy_device *phydev)
return err;
}
}
+
+ if (dp83822->wol_enabled)
+ return 0;
return dp8382x_disable_wol(phydev);
}
@@ -572,11 +584,17 @@ static int dp83826_config_init(struct phy_device *phydev)
return ret;
}
+ if (dp83822->wol_enabled)
+ return 0;
return dp8382x_disable_wol(phydev);
}
static int dp8382x_config_init(struct phy_device *phydev)
{
+ struct dp83822_private *dp83822 = phydev->priv;
+
+ if (dp83822->wol_enabled)
+ return 0;
return dp8382x_disable_wol(phydev);
}
base-commit: 61996c073c9b070922ad3a36c981ca6ddbea19a5
prerequisite-patch-id: 0000000000000000000000000000000000000000
--
2.34.1
On Wed, Mar 06, 2024 at 06:14:46PM +0100, Catalin Popescu wrote:
> Unlike other ethernet PHYs from TI, PHY dp83822x has WOL enabled
> at reset.
This is rather odd behaviour. Is this stated in the datasheet?
> @@ -572,11 +584,17 @@ static int dp83826_config_init(struct phy_device *phydev)
> return ret;
> }
>
> + if (dp83822->wol_enabled)
> + return 0;
> return dp8382x_disable_wol(phydev);
> }
>
> static int dp8382x_config_init(struct phy_device *phydev)
> {
> + struct dp83822_private *dp83822 = phydev->priv;
> +
> + if (dp83822->wol_enabled)
> + return 0;
> return dp8382x_disable_wol(phydev);
Since it is rather odd behaviour, there might be some BIOSes which
disable WoL. So i would not rely on it being enabled by
default. Explicitly enable it.
Andrew
---
pw-bot: cr
On 07.03.24 00:04, Andrew Lunn wrote:
> This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email.
>
>
> On Wed, Mar 06, 2024 at 06:14:46PM +0100, Catalin Popescu wrote:
>> Unlike other ethernet PHYs from TI, PHY dp83822x has WOL enabled
>> at reset.
> This is rather odd behaviour. Is this stated in the datasheet?
Yes. I've checked all TI ethernet PHYs datasheets that are supported by
linux and they all, but dp8382x, have WOL disabled by default. Hence,
dp83822.c is the only driver that forcefully disable WOL at init.
>
>> @@ -572,11 +584,17 @@ static int dp83826_config_init(struct phy_device *phydev)
>> return ret;
>> }
>>
>> + if (dp83822->wol_enabled)
>> + return 0;
>> return dp8382x_disable_wol(phydev);
>> }
>>
>> static int dp8382x_config_init(struct phy_device *phydev)
>> {
>> + struct dp83822_private *dp83822 = phydev->priv;
>> +
>> + if (dp83822->wol_enabled)
>> + return 0;
>> return dp8382x_disable_wol(phydev);
> Since it is rather odd behaviour, there might be some BIOSes which
> disable WoL. So i would not rely on it being enabled by
> default. Explicitly enable it.
I see, I'll make the change.
>
> Andrew
>
> ---
> pw-bot: cr
On 07.03.24 09:30, POPESCU Catalin wrote:
> On 07.03.24 00:04, Andrew Lunn wrote:
>> This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email.
>>
>>
>> On Wed, Mar 06, 2024 at 06:14:46PM +0100, Catalin Popescu wrote:
>>> Unlike other ethernet PHYs from TI, PHY dp83822x has WOL enabled
>>> at reset.
>> This is rather odd behaviour. Is this stated in the datasheet?
> Yes. I've checked all TI ethernet PHYs datasheets that are supported by
> linux and they all, but dp8382x, have WOL disabled by default. Hence,
> dp83822.c is the only driver that forcefully disable WOL at init.
>>> @@ -572,11 +584,17 @@ static int dp83826_config_init(struct phy_device *phydev)
>>> return ret;
>>> }
>>>
>>> + if (dp83822->wol_enabled)
>>> + return 0;
>>> return dp8382x_disable_wol(phydev);
>>> }
>>>
>>> static int dp8382x_config_init(struct phy_device *phydev)
>>> {
>>> + struct dp83822_private *dp83822 = phydev->priv;
>>> +
>>> + if (dp83822->wol_enabled)
>>> + return 0;
>>> return dp8382x_disable_wol(phydev);
>> Since it is rather odd behaviour, there might be some BIOSes which
>> disable WoL. So i would not rely on it being enabled by
>> default. Explicitly enable it.
> I see, I'll make the change.
It looks like the issue I'm trying to address in this patch is not
specific to dp8382x. Right now, depending on if the PHY is reset or not
during resume (either through mdio_device reset_gpio/reset_ctrl or
phy_driver soft_reset callback), the WOL configuration is either the PHY
reset value or the BIOS value. I could still make the patch but it
doesn't really make sense to address only dp8382x.
Also, I'm a bit confused as I'm not sure if this issue is already
addressed by userspace or not (e.g. udevd that would reapply WOL
configuration after suspend).
If issue should be definitely addressed in the kernel instead of
userspace, then PAL should enforce WOL configuration for any PHY by
calling set_wol callback after soft_reset (probably, at the end of
phy_init_hw or after phy_resume).
>> Andrew
>>
>> ---
>> pw-bot: cr
>
Hi,
On 08/03/2024 17:50, POPESCU Catalin wrote:
> On 07.03.24 09:30, POPESCU Catalin wrote:
>> On 07.03.24 00:04, Andrew Lunn wrote:
>>> This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email.
>>>
>>>
>>> On Wed, Mar 06, 2024 at 06:14:46PM +0100, Catalin Popescu wrote:
>>>> Unlike other ethernet PHYs from TI, PHY dp83822x has WOL enabled
>>>> at reset.
>>> This is rather odd behaviour. Is this stated in the datasheet?
>> Yes. I've checked all TI ethernet PHYs datasheets that are supported by
>> linux and they all, but dp8382x, have WOL disabled by default. Hence,
>> dp83822.c is the only driver that forcefully disable WOL at init.
>>>> @@ -572,11 +584,17 @@ static int dp83826_config_init(struct phy_device *phydev)
>>>> return ret;
>>>> }
>>>>
>>>> + if (dp83822->wol_enabled)
>>>> + return 0;
>>>> return dp8382x_disable_wol(phydev);
>>>> }
>>>>
>>>> static int dp8382x_config_init(struct phy_device *phydev)
>>>> {
>>>> + struct dp83822_private *dp83822 = phydev->priv;
>>>> +
>>>> + if (dp83822->wol_enabled)
>>>> + return 0;
>>>> return dp8382x_disable_wol(phydev);
>>> Since it is rather odd behaviour, there might be some BIOSes which
>>> disable WoL. So i would not rely on it being enabled by
>>> default. Explicitly enable it.
>> I see, I'll make the change.
> It looks like the issue I'm trying to address in this patch is not
> specific to dp8382x. Right now, depending on if the PHY is reset or not
> during resume (either through mdio_device reset_gpio/reset_ctrl or
> phy_driver soft_reset callback), the WOL configuration is either the PHY
> reset value or the BIOS value. I could still make the patch but it
> doesn't really make sense to address only dp8382x.
>
> Also, I'm a bit confused as I'm not sure if this issue is already
> addressed by userspace or not (e.g. udevd that would reapply WOL
> configuration after suspend).
>
> If issue should be definitely addressed in the kernel instead of
> userspace, then PAL should enforce WOL configuration for any PHY by
> calling set_wol callback after soft_reset (probably, at the end of
> phy_init_hw or after phy_resume).
Does it make sense to address it in the kernel ?
>
>>> Andrew
>>>
>>> ---
>>> pw-bot: cr
> > It looks like the issue I'm trying to address in this patch is not
> > specific to dp8382x. Right now, depending on if the PHY is reset or not
> > during resume (either through mdio_device reset_gpio/reset_ctrl or
> > phy_driver soft_reset callback), the WOL configuration is either the PHY
> > reset value or the BIOS value. I could still make the patch but it
> > doesn't really make sense to address only dp8382x.
This is an interesting point. soft_reset the driver is in control
off. It can preserve the WoL setting over the soft reset.
A hardware reset is a different matter.
However, if we woke up due to WoL, the PHY never went to sleep, its
state is intact, so why are we doing a hardware reset?
Andrew
On 22/03/2024 16:56, Andrew Lunn wrote:
> [Some people who received this message don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email.
>
>
>>> It looks like the issue I'm trying to address in this patch is not
>>> specific to dp8382x. Right now, depending on if the PHY is reset or not
>>> during resume (either through mdio_device reset_gpio/reset_ctrl or
>>> phy_driver soft_reset callback), the WOL configuration is either the PHY
>>> reset value or the BIOS value. I could still make the patch but it
>>> doesn't really make sense to address only dp8382x.
> This is an interesting point. soft_reset the driver is in control
> off. It can preserve the WoL setting over the soft reset.
> A hardware reset is a different matter.
>
> However, if we woke up due to WoL, the PHY never went to sleep, its
> state is intact, so why are we doing a hardware reset?
I checked again the code and the datasheets and I was wrong: the driver
does a "digital" reset instead of "software hard" reset :
- "digital" reset : registers are preserved
- "software hard" reset : registers are reset
The names are misleading and explains why I made the mistake :)
So, it makes sense to provide a patch for dp8382x that ensure we don't
forcefully disable WOL on the resume path.
> Andrew
>