[GIT PULL] Allwinner Fixes for 5.10

[Arnd Bergmann]

On Fri, Oct 30, 2020 at 10:14 AM Ard Biesheuvel <ardb at kernel.org> wrote:
> On Fri, 30 Oct 2020 at 10:06, Arnd Bergmann <arnd at kernel.org> wrote:
> >
> > On Thu, Oct 29, 2020 at 11:59 PM Ard Biesheuvel <ardb at kernel.org> wrote:
> > >
> > > 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/
> >
> > Could we work around it in by updating the DT contents at boot time before it
> > gets to the driver? We've done that in the past on specific machines to avoid
> > breaking DT compatibility, though I don't like the idea of doing it
> > for everyone.
> >
> > Is there a safe fallback? I.e. would it break other platforms if we were to
> > always replace phy-mode="rgmii" with phy-mode="rgmii-id"? I suppose we
> > have no way of detecting the actual phy from early DT code in order to
> > figure out if the device behind the mdio bus is affected. The best we could
> > do might be either a list of affected boards or a list of affected ethernet
> > controllers for which this gets updated.
> >
>
> The root of the issue is that the followup fix that was backported
> overrides the TX/RX delay setting configured by h/w straps.
>
> So 'rgmii' used to mean 'don't enable TX/RX delay in software' but now
> it means 'disable TX/RX delay in software even if it was enabled using
> h/w straps'.
>
> Omitting the phy-mode string entirely would help, as the PHY layer
> interprets this as 'leave the delay setting alone'. However, there are
> cases where the MAC driver may interpret this property as well, as it
> may have to apply the delay at the MAC end if the PHY is programmed
> for no delay. Also, it may need to distinguish between gmii and rgmii.
>
> So we cannot replace rgmii with anything else in the general case, the
> only thing we can do is leave the TX/RX delay setting alone if we
> detect that it is enabled by h/w straps. According to Andrew, this is
> possible, and he is willing to accept a patch that implements this for
> backporting to -stable, but otherwise treats it as someone else's
> problem.

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.

      Arnd