netdev - Re: [PATCH net] r8169: fix rtl8168h wol fail

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 11 Jan 2023 20:40:44 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Hau <hau@...ltek.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        nic_swsd <nic_swsd@...ltek.com>, Andrew Lunn <andrew@...n.ch>
Subject: Re: [PATCH net] r8169: fix rtl8168h wol fail

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.
>>>