[GIT PULL] Allwinner Fixes for 5.10

[GIT PULL] Allwinner Fixes for 5.10

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 4229 bytes --]

Hi Arnd, Olof,

Please pull the following changes for the current release.

Thanks!
Maxime

The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:

  Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git refs/tags/sunxi-fixes-for-5.10-1

for you to fetch changes up to 107954afc5df667da438644aa4982606663f9b17:

  arm64: dts: allwinner: h5: OrangePi Prime: Fix ethernet node (2020-10-29 10:29:49 +0100)

----------------------------------------------------------------
Mostly some fixes for a fallout in a PHY driver that pointed out errors
in our DTs. Along with that, Jernej agreed to be a reviewer!
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX5sSewAKCRDj7w1vZxhR
xV+IAP4g+HPbxIJBN5RjLJG+ONRV4DqHa5124e/VidlsnMTt6QEApuJVqK5suuJJ
71vmTxbLGS9TwerbFMLyw41hNf9egQQ=
=Rx6E
-----END PGP SIGNATURE-----

----------------------------------------------------------------
Chen-Yu Tsai (10):
      Revert "arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high"
      ARM: dts: sun6i: a31-hummingbird: Enable RGMII RX/TX delay on Ethernet PHY
      ARM: dts: sun7i: cubietruck: Enable RGMII RX/TX delay on Ethernet PHY
      ARM: dts: sun7i: bananapi-m1-plus: Enable RGMII RX/TX delay on Ethernet PHY
      ARM: dts: sun8i: h3: orangepi-plus2e: Enable RGMII RX/TX delay on Ethernet PHY
      ARM: dts: sun8i: a83t: Enable both RGMII RX/TX delay on Ethernet PHY
      ARM: dts: sun9i: Enable both RGMII RX/TX delay on Ethernet PHY
      ARM: dts: sunxi: bananapi-m2-plus: Enable RGMII RX/TX delay on Ethernet PHY
      arm64: dts: allwinner: h5: libretech-all-h5-cc: Enable RGMII RX/TX delay on PHY
      arm64: dts: allwinner: a64: bananapi-m64: Enable RGMII RX/TX delay on PHY

Clément Péron (2):
      arm64: dts: allwinner: pinetab: Drop unnecessary address/size-cells information
      arm64: dts: allwinner: beelink-gs1: Enable both RGMII RX/TX delay

Corentin Labbe (1):
      arm64: dts: allwinner: Pine H64: Enable both RGMII RX/TX delay

Jernej Skrabec (4):
      arm64: dts: allwinner: a64: OrangePi Win: Fix ethernet node
      arm64: dts: allwinner: a64: Pine64 Plus: Fix ethernet node
      arm64: dts: allwinner: h5: OrangePi PC2: Fix ethernet node
      ARM: dts: sun8i: r40: bananapi-m2-ultra: Fix ethernet node

Maxime Ripard (1):
      MAINTAINERS: Add Jernej Škrabec as a reviewer for Allwinner SoCs support

Nenad Peric (1):
      arm64: dts: allwinner: h5: OrangePi Prime: Fix ethernet node


 MAINTAINERS                                                     | 1 +
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts                     | 2 +-
 arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts                | 2 +-
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts                      | 2 +-
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts                    | 2 +-
 arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts                | 2 +-
 arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts                 | 5 -----
 arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts                  | 2 +-
 arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts               | 2 +-
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts                     | 2 +-
 arch/arm/boot/dts/sun9i-a80-optimus.dts                         | 2 +-
 arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi                   | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts       | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts       | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts        | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts            | 3 ---
 arch/arm64/boot/dts/allwinner/sun50i-h5-libretech-all-h5-cc.dts | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts        | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts      | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts         | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts            | 2 +-
 21 files changed, 19 insertions(+), 26 deletions(-)



[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Arnd Bergmann]

On Thu, Oct 29, 2020 at 8:06 PM Maxime Ripard <mripard@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.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Arnd Bergmann]

On Thu, Oct 29, 2020 at 10:23 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Thu, Oct 29, 2020 at 8:06 PM Maxime Ripard <mripard@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.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Ard Biesheuvel]

On Thu, 29 Oct 2020 at 22:41, Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Thu, Oct 29, 2020 at 10:23 PM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > On Thu, Oct 29, 2020 at 8:06 PM Maxime Ripard <mripard@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)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Arnd Bergmann]

On Thu, Oct 29, 2020 at 11:03 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> On Thu, 29 Oct 2020 at 22:41, Arnd Bergmann <arnd@kernel.org> wrote:
> > On Thu, Oct 29, 2020 at 10:23 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > On Thu, Oct 29, 2020 at 8:06 PM Maxime Ripard <mripard@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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Ard Biesheuvel]

On Thu, 29 Oct 2020 at 23:56, Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Thu, Oct 29, 2020 at 11:03 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > On Thu, 29 Oct 2020 at 22:41, Arnd Bergmann <arnd@kernel.org> wrote:
> > > On Thu, Oct 29, 2020 at 10:23 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > > On Thu, Oct 29, 2020 at 8:06 PM Maxime Ripard <mripard@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/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Arnd Bergmann]

On Thu, Oct 29, 2020 at 11:59 PM Ard Biesheuvel <ardb@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.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Ard Biesheuvel]

On Fri, 30 Oct 2020 at 10:06, Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Thu, Oct 29, 2020 at 11:59 PM Ard Biesheuvel <ardb@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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Arnd Bergmann]

On Fri, Oct 30, 2020 at 10:14 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> On Fri, 30 Oct 2020 at 10:06, Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > On Thu, Oct 29, 2020 at 11:59 PM Ard Biesheuvel <ardb@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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Ard Biesheuvel]

On Fri, 30 Oct 2020 at 10:45, Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Fri, Oct 30, 2020 at 10:14 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> > On Fri, 30 Oct 2020 at 10:06, Arnd Bergmann <arnd@kernel.org> wrote:
> > >
> > > On Thu, Oct 29, 2020 at 11:59 PM Ard Biesheuvel <ardb@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 :-)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Arnd Bergmann]

On Fri, Oct 30, 2020 at 11:03 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> On Fri, 30 Oct 2020 at 10:45, Arnd Bergmann <arnd@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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Ard Biesheuvel]

On Fri, 30 Oct 2020 at 11:15, Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Fri, Oct 30, 2020 at 11:03 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> > On Fri, 30 Oct 2020 at 10:45, Arnd Bergmann <arnd@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).
>

I think this is all making it needlessly complicated, especially
because it is really only needed to fix problems created by a patch
that was backported without any evidence that it fixes any issues in
practice.

Basically, the Realtek PHY driver has always ignored the TX/RX delay
settings given by software, even after the original fix went in for
v5.2. Therefore, the followup fix fixed a theoretical issue, which
could never have been the cause of a regression because the first fix
was broken in the first place.

Adhering strictly to the PHY mode going forward is fine. Backporting a
change that knowingly breaks platforms, without evidence that it
actually fixes any is just another symptom of our -stable disease,
where everything that applies lexically is considered for -stable,
without regards for what the change actually does.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

On Thu, 29 Oct 2020 20:06:01 +0100, Maxime Ripard wrote:
> Please pull the following changes for the current release.
> 
> Thanks!
> Maxime
> 
> The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
> 
>   Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
> 
> [...]

Merged into arm/fixes, thanks!

merge commit: b57d5437e3740bffed60ceedf74f881ab5bd6122

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Arnd Bergmann]

On Fri, Oct 30, 2020 at 11:29 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> On Fri, 30 Oct 2020 at 11:15, Arnd Bergmann <arnd@kernel.org> wrote:
> > On Fri, Oct 30, 2020 at 11:03 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > On Fri, 30 Oct 2020 at 10:45, Arnd Bergmann <arnd@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).
> >
>
> I think this is all making it needlessly complicated, especially
> because it is really only needed to fix problems created by a patch
> that was backported without any evidence that it fixes any issues in
> practice.
>
> Basically, the Realtek PHY driver has always ignored the TX/RX delay
> settings given by software, even after the original fix went in for
> v5.2. Therefore, the followup fix fixed a theoretical issue, which
> could never have been the cause of a regression because the first fix
> was broken in the first place.
>
> Adhering strictly to the PHY mode going forward is fine. Backporting a
> change that knowingly breaks platforms, without evidence that it
> actually fixes any is just another symptom of our -stable disease,
> where everything that applies lexically is considered for -stable,
> without regards for what the change actually does.

Sorry for delaying this, I ended up merging the fixes now as it seems
worse to not have it fixed in v5.10.

I actually still disagree with the driver fix even in mainline, we should
really not break existing systems that are deployed with dtb files
that only work by accident. Having the driver work the same way
in stable and in mainline doesn't bother me as long as it doesn't
regress but only warns about cases that are possibly broken.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] Allwinner Fixes for 5.10

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

On Sat, 28 Nov 2020 11:57:09 +0100, Maxime Ripard wrote:
> Please pull the following changes for the current release.
> 
> Thanks!
> Maxime
> 
> The following changes since commit 107954afc5df667da438644aa4982606663f9b17:
> 
>   arm64: dts: allwinner: h5: OrangePi Prime: Fix ethernet node (2020-10-29 10:29:49 +0100)
> 
> [...]

Merged into arm/fixes, thanks!

merge commit: b11ddaac893ada234895bcfc3be3358957e80717

       Arnd

Re: [GIT PULL] Allwinner Fixes for 5.10

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

On Sat, 28 Nov 2020 11:57:09 +0100, Maxime Ripard wrote:
> Please pull the following changes for the current release.
> 
> Thanks!
> Maxime
> 
> The following changes since commit 107954afc5df667da438644aa4982606663f9b17:
> 
>   arm64: dts: allwinner: h5: OrangePi Prime: Fix ethernet node (2020-10-29 10:29:49 +0100)
> 
> [...]

Merged into arm/fixes, thanks!

merge commit: b11ddaac893ada234895bcfc3be3358957e80717

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[GIT PULL] Allwinner Fixes for 5.10

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]

Hi Arnd, Olof,

Please pull the following changes for the current release.

Thanks!
Maxime

The following changes since commit 107954afc5df667da438644aa4982606663f9b17:

  arm64: dts: allwinner: h5: OrangePi Prime: Fix ethernet node (2020-10-29 10:29:49 +0100)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git refs/tags/sunxi-fixes-for-5.10-2

for you to fetch changes up to a7361b9c4615951f52ffd2b1afa09a1384c7b4e4:

  ARM: dts: sun7i: pcduino3-nano: enable RGMII RX/TX delay on PHY (2020-11-24 15:24:28 +0100)

----------------------------------------------------------------
A few more RGMII-ID fixes, and a bunch of other more random fixes
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX8Is4AAKCRDj7w1vZxhR
xbAjAP4ohHei2PZ3mHF6wU9kBv4lM2aV60mqvKDFirMdfQBNoAD/Y5fMBAVp6yJn
lRECtoJdPWI4x97ZNZMR4xX1XVSXoQk=
=aO5k
-----END PGP SIGNATURE-----

----------------------------------------------------------------
Adam Sampson (1):
      ARM: dts: sun7i: pcduino3-nano: enable RGMII RX/TX delay on PHY

Icenowy Zheng (1):
      ARM: dts: sun8i: v3s: fix GIC node memory range

Jernej Skrabec (1):
      arm64: dts: allwinner: h6: orangepi-one-plus: Fix ethernet

Matteo Scordino (1):
      ARM: dts: s3: pinecube: align compatible property to other S3 boards

Pablo Greco (3):
      ARM: dts: sun7i: bananapi: Enable RGMII RX/TX delay on Ethernet PHY
      ARM: dts: sun8i: r40: bananapi-m2-berry: Fix dcdc1 regulator
      ARM: dts: sun8i: v40: bananapi-m2-berry: Fix ethernet node

Paul Kocialkowski (1):
      ARM: sunxi: Add machine match for the Allwinner V3 SoC


 arch/arm/boot/dts/sun7i-a20-bananapi.dts                      |  2 +-
 arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts                 |  4 ++--
 arch/arm/boot/dts/sun8i-s3-pinecube.dts                       |  2 +-
 arch/arm/boot/dts/sun8i-v3s.dtsi                              |  2 +-
 arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts             | 12 ++++++------
 arch/arm/mach-sunxi/sunxi.c                                   |  1 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts |  2 +-
 7 files changed, 13 insertions(+), 12 deletions(-)



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[GIT PULL] Allwinner Fixes for 5.10

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 2216 bytes --]

Hi Arnd, Olof,

Please pull the following changes for the current release.

Thanks!
Maxime

The following changes since commit 107954afc5df667da438644aa4982606663f9b17:

  arm64: dts: allwinner: h5: OrangePi Prime: Fix ethernet node (2020-10-29 10:29:49 +0100)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git refs/tags/sunxi-fixes-for-5.10-2

for you to fetch changes up to a7361b9c4615951f52ffd2b1afa09a1384c7b4e4:

  ARM: dts: sun7i: pcduino3-nano: enable RGMII RX/TX delay on PHY (2020-11-24 15:24:28 +0100)

----------------------------------------------------------------
A few more RGMII-ID fixes, and a bunch of other more random fixes
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX8Is4AAKCRDj7w1vZxhR
xbAjAP4ohHei2PZ3mHF6wU9kBv4lM2aV60mqvKDFirMdfQBNoAD/Y5fMBAVp6yJn
lRECtoJdPWI4x97ZNZMR4xX1XVSXoQk=
=aO5k
-----END PGP SIGNATURE-----

----------------------------------------------------------------
Adam Sampson (1):
      ARM: dts: sun7i: pcduino3-nano: enable RGMII RX/TX delay on PHY

Icenowy Zheng (1):
      ARM: dts: sun8i: v3s: fix GIC node memory range

Jernej Skrabec (1):
      arm64: dts: allwinner: h6: orangepi-one-plus: Fix ethernet

Matteo Scordino (1):
      ARM: dts: s3: pinecube: align compatible property to other S3 boards

Pablo Greco (3):
      ARM: dts: sun7i: bananapi: Enable RGMII RX/TX delay on Ethernet PHY
      ARM: dts: sun8i: r40: bananapi-m2-berry: Fix dcdc1 regulator
      ARM: dts: sun8i: v40: bananapi-m2-berry: Fix ethernet node

Paul Kocialkowski (1):
      ARM: sunxi: Add machine match for the Allwinner V3 SoC


 arch/arm/boot/dts/sun7i-a20-bananapi.dts                      |  2 +-
 arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts                 |  4 ++--
 arch/arm/boot/dts/sun8i-s3-pinecube.dts                       |  2 +-
 arch/arm/boot/dts/sun8i-v3s.dtsi                              |  2 +-
 arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts             | 12 ++++++------
 arch/arm/mach-sunxi/sunxi.c                                   |  1 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts |  2 +-
 7 files changed, 13 insertions(+), 12 deletions(-)



[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel