[GIT PULL] Allwinner Fixes for 5.10

[Ard Biesheuvel]

On Fri, 30 Oct 2020 at 11:15, Arnd Bergmann <arnd at kernel.org> wrote:
>
> On Fri, Oct 30, 2020 at 11:03 AM Ard Biesheuvel <ardb at kernel.org> wrote:
> > On Fri, 30 Oct 2020 at 10:45, Arnd Bergmann <arnd at kernel.org> wrote:
>
> > >
> > > So I suppose the best workaround we can hope for would be
> > > to have a list of board compatible strings on which we remove
> > > any phy-mode="rgmii" properties but leave everything alone?
> > >
> > > We shouldn't have different behavior between stable kernels and
> > > future kernels looking at the same DTB, so I'd hope that would
> > > work in all combinations.
> >
> > I think it would be better to redefine 'rgmii' as 'delay unspecified',
> > and add 'rgmii-noid' which means that tx/rx delay should be disabled
> > even when it is set by straps. The reason is that I don't think the
> > latter will ever be used in practice - TX/RX delay is a h/w
> > integration choice, and I don't see why you would enable it in
> > hardware only to disable it again in software. But of course, I'm not
> > really a networking person :-)
>
> I think the meaning of "rgmii" would need to be "phy driver specific
> delay for backwards compatibility", but I'm not sure how many extra
> strings need to be defined, possibly three, to mean:
>
> a. rgmii, but leave delay unchanged from firmware
> b. rgmii, but use delay as configured from strapping pins
> c. rgmii, but turn off internal delay
>
> I also wonder if there could be more than one of these in order
> to work with older kernels that do not understand the new strings.
> How would existing kernels deal with this?
>
>      phy-mode = "rgmii", "rgmii-noid";
>
> (note that this would be slightly backwards, using the more generic
>  string before the more specific one).
>

I think this is all making it needlessly complicated, especially
because it is really only needed to fix problems created by a patch
that was backported without any evidence that it fixes any issues in
practice.

Basically, the Realtek PHY driver has always ignored the TX/RX delay
settings given by software, even after the original fix went in for
v5.2. Therefore, the followup fix fixed a theoretical issue, which
could never have been the cause of a regression because the first fix
was broken in the first place.

Adhering strictly to the PHY mode going forward is fine. Backporting a
change that knowingly breaks platforms, without evidence that it
actually fixes any is just another symptom of our -stable disease,
where everything that applies lexically is considered for -stable,
without regards for what the change actually does.