[GIT PULL] Allwinner Fixes for 5.10

[Ard Biesheuvel]

On Thu, 29 Oct 2020 at 23:56, Arnd Bergmann <arnd at kernel.org> wrote:
>
> On Thu, Oct 29, 2020 at 11:03 PM Ard Biesheuvel <ardb at kernel.org> wrote:
> > On Thu, 29 Oct 2020 at 22:41, Arnd Bergmann <arnd at kernel.org> wrote:
> > > On Thu, Oct 29, 2020 at 10:23 PM Arnd Bergmann <arnd at kernel.org> wrote:
> > > > On Thu, Oct 29, 2020 at 8:06 PM Maxime Ripard <mripard at kernel.org> wrote:
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > Mostly some fixes for a fallout in a PHY driver that pointed out errors
> > > > > in our DTs.
> > > >
> > > > Can you clarify what this means for compatibility of the dtb files?
> > > >
> > > > I would assume that the modified .dts files all work on older kernels
> > > > because you fix the setting, but at least some of them require
> > > > the patch with newer kernels, right?
> > > >
> > > > Are they all broken without the change? Are other platforms
> > > > likely to suffer the same problem? IIRC seems that at least
> > > > the SynQuacer box had the same issue, but I don't yet
> > > > understand how common the problem is.
> > >
> > > To clarify: I had pulled the branch already when I replied, but the
> > > automated email for that apparently did not trigger.
> > >
> > > I would like to know the background here mainly so I can put
> > > it into my pull request to Linus.
> > >
> >
> > The Realtek PHY driver used to ignore the TX/RX delay settings implied
> > by the xxx in the the different rgmii-xxx phy-mode settings, and a
> > failed attempt was made in the v5.2 timeframe to change this, and so
> > the -xxx part has been effectively ignored all this time, meaning you
> > could get away with providing the wrong value.
> >
> > Even though no platform appears to have been affected by this
> > incorrect patch, the followup fix that repairs it has been backported
> > to -stable, breaking all the formerly working platforms incorporating
> > this PHY that describe the mode as 'rgmii' instead of 'rgmii-id'. I
> > have argued that the backport of the followup fix should be reverted,
> > given that there is a risk that production systems tracking a -stable
> > release may be affected by this if they don't take their DT directly
> > from the upstream kernel.
> >
> > I think this PR is fine, though - fixing the DTs going forward is
> > needed in any case (although I think backporting DT changes to -stable
> > is a bad idea but that is just my opinion)
>
> Hmm, that sounds much worse than I understood first. I think the
> mainline driver needs to be patched back to restore the previous
> behavior, and that backported to stable kernels if they are already
> broken by the backport.
>
> While I had already pulled these fixes, I'm dropping them now.
> It should have been clear that this kind of driver change is not
> acceptable.
>

This is what Ilias and I tried to argue [0] earlier today, but Andrew
has a different view.

[0] https://lore.kernel.org/netdev/CAMj1kXGQDeOGj+2+tMnPhjoPJRX+eTh8-94yaH_bGwDATL7pkg@mail.gmail.com/