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]

Message-ID: <add32dc486bb4fc9abc283b2bb39efc3@realtek.com>
Date:   Wed, 11 Jan 2023 17:23:23 +0000
From:   Hau <hau@...ltek.com>
To:     Heiner Kallweit <hkallweit1@...il.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 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.

> > 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.
> >
------Please consider the environment before printing this e-mail.