Re: Re: realtek PHY commit bbc4d71d63549 causes regression

On Thu, Nov 5, 2020 at 6:28 PM Jernej Škrabec [off-list ref] wrote:

Dne četrtek, 29. oktober 2020 ob 15:46:44 CET je Ilias Apalodimas napisal(a):

quoted

On Thu, Oct 29, 2020 at 03:39:34PM +0100, Andrew Lunn wrote:

quoted

quoted

What about reverting the realtek PHY commit from stable?
As Ard said it doesn't really fix anything (usage wise) and causes a

bunch of

quoted

quoted

quoted

problems.

If I understand correctly we have 3 options:
1. 'Hack' the  drivers in stable to fix it (and most of those hacks will

take

quoted

quoted

quoted

   a long time to remove)
2. Update DTE of all affected devices, backport it to stable and force

users to

quoted

quoted

quoted

update
3. Revert the PHY commit

imho [3] is the least painful solution.

There is also the option of patching the dtb in memory while booting one
of the affected machines.

quoted

quoted

The PHY commit is correct, in that it fixes a bug. So i don't want to
remove it.

Yea I meant revert the commit from were ever it was backported, not on

current

quoted

upstream. I agree it's correct from a coding point of view, but it never
actually fixes anything functionality wise of the affected platforms.

Sadly, there is one board - Pine64 Plus - where HW settings are wrong and it
actually needs SW override. Until this Realtek PHY driver fix was merged, it
was unclear what magic value provided by Realtek to board manufacturer does.

Reference:
https://lore.kernel.org/netdev/20191001082912.12905-3-icenowy@aosc.io/ (local)

I have merged the fixes from the allwinner tree now, but I still think we
need something better than this, as the current state breaks any existing
dtb file that has the incorrect values, and this really should not have been
considered for backporting to stable kernels.

       Arnd