Re: realtek PHY commit bbc4d71d63549 causes regression

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

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
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 
   a long time to remove)
2. Update DTE of all affected devices, backport it to stable and force users to
update
3. Revert the PHY commit

imho [3] is the least painful solution.

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 
upstream. I agree it's correct from a coding point of view, but it never 
actually fixes anything functionality wise of the affected platforms. 
On the contrary, it breaks platforms without warning.

Backporting it to stable is what is causing most of the issues today,
combined with a number of broken DT descriptions. So i would be happy
for stable to get a patch which looks at the strapping, sees ID is
enabled via strapping, warns the DT blob is FUBAR, and then ignores
the requested PHY-mode. That gives developers time to fix their broken
DT.

(Ard replied on this while I was typing)

	  Andrew

Cheers
/Ilias