[GIT PULL] Allwinner Fixes for 5.10

[Ard Biesheuvel]

On Fri, 30 Oct 2020 at 10:45, Arnd Bergmann <arnd at kernel.org> wrote:
>
> 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.
>

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