[GIT PULL] Allwinner Fixes for 5.10

[Arnd Bergmann]

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.

         Arnd