Re: Re: realtek PHY commit bbc4d71d63549 causes regression

From: "Jernej Škrabec" <jernej.skrabec@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>, netdev@vger.kernel.org
Cc: "Ard Biesheuvel" <ardb@kernel.org>,
	"Daniel Thompson" <daniel.thompson@linaro.org>,
	"Sumit Garg" <sumit.garg@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Steve McIntyre" <steve@einval.com>,
	"open list:BPF JIT for MIPS (32-BIT AND 64-BIT)"
	<netdev@vger.kernel.org>, "Willy Liu" <willy.liu@realtek.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Sasha Levin" <sashal@kernel.org>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Masahisa Kojima" <masahisa.kojima@linaro.org>,
	"Ilias Apalodimas" <ilias.apalodimas@linaro.org>
Subject: Re: Re: realtek PHY commit bbc4d71d63549 causes regression
Date: Thu, 05 Nov 2020 18:31:28 +0100
Message-ID: <2697795.ZkNf1YqPoC@kista> (raw)
In-Reply-To: <20201029144644.GA70799@apalos.home>

Hi!

Dne četrtek, 29. oktober 2020 ob 15:46:44 CET je Ilias Apalodimas napisal(a):
> On Thu, Oct 29, 2020 at 03:39:34PM +0100, Andrew Lunn wrote:
> > > 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. 

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/

Best regards,
Jernej

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