netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Hau <hau@realtek.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	nic_swsd <nic_swsd@realtek.com>, Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCH net] r8169: fix rtl8168h wol fail
Date: Wed, 11 Jan 2023 20:40:44 +0100	[thread overview]
Message-ID: <e201750b-f3be-b62d-4dc6-2a00f4834256@gmail.com> (raw)
In-Reply-To: <add32dc486bb4fc9abc283b2bb39efc3@realtek.com>

On 11.01.2023 18:23, Hau wrote:
>>
>> On 10.01.2023 18:03, Hau wrote:
>>>> On 06.01.2023 07:53, Hau wrote:
>>>>>>>> rtl8168h has an application that it will connect to rtl8211fs
>>>>>>>> through mdi interface. And rtl8211fs will connect to fiber
>>>>>>>> through serdes
>>>>>> interface.
>>>>>>>> In this application, rtl8168h revision id will be set to 0x2a.
>>>>>>>>
>>>>>>>> Because rtl8211fs's firmware will set link capability to 100M and
>>>>>>>> GIGA when link is from off to on. So when system suspend and wol
>>>>>>>> is enabled, rtl8168h will speed down to 100M (because rtl8211fs
>>>>>>>> advertise 100M and GIGA to rtl8168h). If the link speed between
>>>>>> rtl81211fs and fiber is GIGA.
>>>>>>>> The link speed between rtl8168h and fiber will mismatch. That
>>>>>>>> will cause wol fail.
>>>>>>>>
>>>>>>>> In this patch, if rtl8168h is in this kind of application, driver
>>>>>>>> will not speed down phy when wol is enabled.
>>>>>>>>
>>>>>>> I think the patch title is inappropriate because WoL works
>>>>>>> normally on RTL8168h in the standard setup.
>>>>>>> What you add isn't a fix but a workaround for a firmware bug in
>>>> RTL8211FS.
>>>>>>> As mentioned in a previous review comment: if speed on fibre side
>>>>>>> is 1Gbps then RTL8211FS shouldn't advertise 100Mbps on MDI/UTP
>> side.
>>>>>>> Last but not least the user can still use e.g. ethtool to change
>>>>>>> the speed to 100Mbps thus breaking the link.
>>>>>>
>>>>>> I agree with Heiner here. I assume you cannot fix the firmware?
>>>>>>
>>>>>> So can we detect the broken firmware and correctly set
>>>>>> phydev->advertising? That will fix WoL and should prevent the user
>>>>>> from using ethtool to select a slower speed.
>>>>>>
>>>>> It is a rtl8211fs's firmware bug. Because in this application it
>>>>> will support both 100M and GIGA fiber module, so it cannot just set
>>>>> phydev->advertising to 100M or GIGA. We  may need to use bit-bang
>>>> MDIO
>>>>> to detect fiber link speed and set phydev->advertising properly. But
>>>>> it will
>>>> let this patch become more complicated.
>>>>>
>>>> I think there's also a userspace workaround for your problem.
>>>> You can use "ethtool -s <if> advertise .." to adjust what the
>>>> internal PHY advertises.
>>>> phy_speed_down() considers only modes that are currently advertised.
>>>>
>>>> In your case with a 1Gbps fibre module you could set the
>>>> advertisement to 1Gbps/full only.
>>>> Then phy_speed_down() wouldn't change the speed.
>>>>
>>> In this application(rtl8168h + rtl8211fs) it also supports 100Mbps fiber
>> module.
>>
>> Does RTL8211FS advertise 100Mbps and 1Gbps on the UTP/MDI side in case
>> of a 100Mbps fiber module?
> Yes.
> 
I think in this case internal PHY and RTL8211FS would negotiate 1Gbps,
not matching the speed of the 100Mbps fiber module.
How does this work?

>>> So userspace workaround is good but it may not always work for this issue.
>>
>> When would it not work? If you know the fiber module speed you can set
>> the advertisement accordingly.
> Sure, user can set internal PHY advertisement according to fiber module speed.
> But we would like to have a solution that does not need user to do anything.
> So this userspace workaround may not meet our need.
> 
>>> Not speed down during system suspend may be the simplest workaround
>> for this issue.
>>>


  reply	other threads:[~2023-01-11 20:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05 18:04 [PATCH net] r8169: fix rtl8168h wol fail Chunhao Lin
2023-01-05 19:37 ` Heiner Kallweit
2023-01-05 21:26   ` Andrew Lunn
2023-01-06  6:53     ` Hau
2023-01-06 14:03       ` Andrew Lunn
2023-01-06 18:40       ` Heiner Kallweit
2023-01-10 17:03         ` Hau
2023-01-10 21:59           ` Heiner Kallweit
2023-01-11 17:23             ` Hau
2023-01-11 19:40               ` Heiner Kallweit [this message]
2023-01-11 21:40                 ` Andrew Lunn
2023-01-13 16:23                   ` Hau
2023-01-13 16:36                     ` Andrew Lunn
2023-01-13 22:28                       ` Heiner Kallweit
2023-01-16 17:04                         ` Hau
2023-01-16 17:59                           ` Heiner Kallweit
2023-01-18 16:57                             ` Hau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e201750b-f3be-b62d-4dc6-2a00f4834256@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=hau@realtek.com \
    --cc=netdev@vger.kernel.org \
    --cc=nic_swsd@realtek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).