[GIT PULL] Allwinner Fixes for 5.10

Arnd Bergmann arnd at kernel.org
Fri Oct 30 06:15:29 EDT 2020


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

       Arnd



More information about the linux-arm-kernel mailing list