* [U-Boot] Pull request: u-boot-net.git master
@ 2019-05-07 22:09 Joe Hershberger
2019-05-08 22:24 ` Joe Hershberger
0 siblings, 1 reply; 21+ messages in thread
From: Joe Hershberger @ 2019-05-07 22:09 UTC (permalink / raw
To: u-boot
Hi Tom,
The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
I rebased on your master and built for BB Black. DHCP seems to work fine.
MLO also now fits again.
Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
are available in the git repository at:
git://git.denx.de/u-boot-net.git master
for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
----------------------------------------------------------------
Carlo Caione (4):
net: phy: Add generic helpers to access MMD PHY registers
net: phy: ti: use generic helpers to access MMD registers
cmd: mdio: Switch to generic helpers when accessing the registers
net: phy: realtek: Introduce quirk to mark RXC not stoppable
James Byrne (2):
net: phy: micrel: Use correct skew values on KSZ9021
net: phy: micrel: Find Micrel PHY node correctly
Murali Karicheri (2):
ARM: k2g-gp-evm: update to rgmii pinmux configuration
ARM: k2g-ice: Add pinmux support for rgmii interface
Pankaj Bansal (1):
drivers: net: ldpaa_eth: fix resource leak
Siva Durga Prasad Paladugu (2):
net: phy: Reloc next and prev pointers inside phy_drivers
net: phy: Fix return value check phy_probe
Valentin-catalin Neacsu (1):
net: phy: aquantia: Set only autoneg on in register 4.c441
Vladimir Oltean (6):
net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
net: phy: ar803x: Use common functions for RGMII internal delays
net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
net: phy: ar803x: Explicitly disable RGMII delays
net: phy: ar803x: Clarify the intention of ar8021_config
arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
board/ti/ks2_evm/mux-k2g.h | 36 +++----
cmd/mdio.c | 27 +++--
doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
drivers/net/phy/Kconfig | 41 ++++++++
drivers/net/phy/aquantia.c | 7 +-
drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
drivers/net/phy/phy.c | 21 +++-
drivers/net/phy/realtek.c | 19 ++++
drivers/net/phy/ti.c | 130 +++++-------------------
include/phy.h | 70 +++++++++++++
19 files changed, 394 insertions(+), 221 deletions(-)
Thanks!
-Joe
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-05-07 22:09 [U-Boot] Pull request: u-boot-net.git master Joe Hershberger
@ 2019-05-08 22:24 ` Joe Hershberger
2019-05-08 22:37 ` Tom Rini
2019-05-08 22:40 ` [U-Boot] [EXT] " Vladimir Oltean
0 siblings, 2 replies; 21+ messages in thread
From: Joe Hershberger @ 2019-05-08 22:24 UTC (permalink / raw
To: u-boot
On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
>
> Hi Tom,
>
> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
>
> I rebased on your master and built for BB Black. DHCP seems to work fine.
> MLO also now fits again.
>
> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-net.git master
>
> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
>
> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
>
> ----------------------------------------------------------------
> Carlo Caione (4):
> net: phy: Add generic helpers to access MMD PHY registers
> net: phy: ti: use generic helpers to access MMD registers
> cmd: mdio: Switch to generic helpers when accessing the registers
> net: phy: realtek: Introduce quirk to mark RXC not stoppable
>
> James Byrne (2):
> net: phy: micrel: Use correct skew values on KSZ9021
> net: phy: micrel: Find Micrel PHY node correctly
>
> Murali Karicheri (2):
> ARM: k2g-gp-evm: update to rgmii pinmux configuration
> ARM: k2g-ice: Add pinmux support for rgmii interface
>
> Pankaj Bansal (1):
> drivers: net: ldpaa_eth: fix resource leak
>
> Siva Durga Prasad Paladugu (2):
> net: phy: Reloc next and prev pointers inside phy_drivers
> net: phy: Fix return value check phy_probe
>
> Valentin-catalin Neacsu (1):
> net: phy: aquantia: Set only autoneg on in register 4.c441
>
> Vladimir Oltean (6):
> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
> net: phy: ar803x: Use common functions for RGMII internal delays
> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
> net: phy: ar803x: Explicitly disable RGMII delays
Tom, this [1] is the patch that is breaking the evm. It doesn't affect
BB Black because it uses an SMSC phy, where as this evm uses an
AR8031/AR8033.
Is it possible the device tree [2] is wrong for the board? It lists
'phy-mode = "rgmii-txid";', so that means that with this patch the RX
delay is now being disabled.
Any thoughts, Vladimir?
Thanks,
-Joe
[1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
[2] arch/arm/dts/am335x-evm.dts
> net: phy: ar803x: Clarify the intention of ar8021_config
>
> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
> board/ti/ks2_evm/mux-k2g.h | 36 +++----
> cmd/mdio.c | 27 +++--
> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
> drivers/net/phy/Kconfig | 41 ++++++++
> drivers/net/phy/aquantia.c | 7 +-
> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
> drivers/net/phy/phy.c | 21 +++-
> drivers/net/phy/realtek.c | 19 ++++
> drivers/net/phy/ti.c | 130 +++++-------------------
> include/phy.h | 70 +++++++++++++
> 19 files changed, 394 insertions(+), 221 deletions(-)
>
> Thanks!
> -Joe
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-05-08 22:24 ` Joe Hershberger
@ 2019-05-08 22:37 ` Tom Rini
2019-05-08 22:40 ` [U-Boot] [EXT] " Vladimir Oltean
1 sibling, 0 replies; 21+ messages in thread
From: Tom Rini @ 2019-05-08 22:37 UTC (permalink / raw
To: u-boot
On Wed, May 08, 2019 at 10:24:29PM +0000, Joe Hershberger wrote:
> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
> >
> > Hi Tom,
> >
> > The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
> >
> > I rebased on your master and built for BB Black. DHCP seems to work fine.
> > MLO also now fits again.
> >
> > Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
> >
> > are available in the git repository at:
> >
> > git://git.denx.de/u-boot-net.git master
> >
> > for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
> >
> > net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
> >
> > ----------------------------------------------------------------
> > Carlo Caione (4):
> > net: phy: Add generic helpers to access MMD PHY registers
> > net: phy: ti: use generic helpers to access MMD registers
> > cmd: mdio: Switch to generic helpers when accessing the registers
> > net: phy: realtek: Introduce quirk to mark RXC not stoppable
> >
> > James Byrne (2):
> > net: phy: micrel: Use correct skew values on KSZ9021
> > net: phy: micrel: Find Micrel PHY node correctly
> >
> > Murali Karicheri (2):
> > ARM: k2g-gp-evm: update to rgmii pinmux configuration
> > ARM: k2g-ice: Add pinmux support for rgmii interface
> >
> > Pankaj Bansal (1):
> > drivers: net: ldpaa_eth: fix resource leak
> >
> > Siva Durga Prasad Paladugu (2):
> > net: phy: Reloc next and prev pointers inside phy_drivers
> > net: phy: Fix return value check phy_probe
> >
> > Valentin-catalin Neacsu (1):
> > net: phy: aquantia: Set only autoneg on in register 4.c441
> >
> > Vladimir Oltean (6):
> > net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
> > net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
> > net: phy: ar803x: Use common functions for RGMII internal delays
> > net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
> > net: phy: ar803x: Explicitly disable RGMII delays
>
> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
> BB Black because it uses an SMSC phy, where as this evm uses an
> AR8031/AR8033.
>
> Is it possible the device tree [2] is wrong for the board? It lists
> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
> delay is now being disabled.
>
> Any thoughts, Vladimir?
>
> Thanks,
> -Joe
>
> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
> [2] arch/arm/dts/am335x-evm.dts
Thanks for tracking this down. I believe the DTS is right as it matches
the kernel in this regard. That said, it's the Bone which has the
schematic available and not the EVM so I can't point at that for
further digging.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190508/de98264b/attachment.sig>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [EXT] Re: Pull request: u-boot-net.git master
2019-05-08 22:24 ` Joe Hershberger
2019-05-08 22:37 ` Tom Rini
@ 2019-05-08 22:40 ` Vladimir Oltean
2019-05-08 22:42 ` Tom Rini
1 sibling, 1 reply; 21+ messages in thread
From: Vladimir Oltean @ 2019-05-08 22:40 UTC (permalink / raw
To: u-boot
On 5/9/19 1:24 AM, Joe Hershberger wrote:
> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
>>
>> Hi Tom,
>>
>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
>>
>> I rebased on your master and built for BB Black. DHCP seems to work fine.
>> MLO also now fits again.
>>
>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
>>
>> are available in the git repository at:
>>
>> git://git.denx.de/u-boot-net.git master
>>
>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
>>
>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
>>
>> ----------------------------------------------------------------
>> Carlo Caione (4):
>> net: phy: Add generic helpers to access MMD PHY registers
>> net: phy: ti: use generic helpers to access MMD registers
>> cmd: mdio: Switch to generic helpers when accessing the registers
>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
>>
>> James Byrne (2):
>> net: phy: micrel: Use correct skew values on KSZ9021
>> net: phy: micrel: Find Micrel PHY node correctly
>>
>> Murali Karicheri (2):
>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
>> ARM: k2g-ice: Add pinmux support for rgmii interface
>>
>> Pankaj Bansal (1):
>> drivers: net: ldpaa_eth: fix resource leak
>>
>> Siva Durga Prasad Paladugu (2):
>> net: phy: Reloc next and prev pointers inside phy_drivers
>> net: phy: Fix return value check phy_probe
>>
>> Valentin-catalin Neacsu (1):
>> net: phy: aquantia: Set only autoneg on in register 4.c441
>>
>> Vladimir Oltean (6):
>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
>> net: phy: ar803x: Use common functions for RGMII internal delays
>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
>> net: phy: ar803x: Explicitly disable RGMII delays
>
> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
> BB Black because it uses an SMSC phy, where as this evm uses an
> AR8031/AR8033.
>
> Is it possible the device tree [2] is wrong for the board? It lists
> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
> delay is now being disabled.
>
> Any thoughts, Vladimir?
>
> Thanks,
> -Joe
>
> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
> [2] arch/arm/dts/am335x-evm.dts
>
>> net: phy: ar803x: Clarify the intention of ar8021_config
>>
>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
>> cmd/mdio.c | 27 +++--
>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
>> drivers/net/phy/Kconfig | 41 ++++++++
>> drivers/net/phy/aquantia.c | 7 +-
>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
>> drivers/net/phy/phy.c | 21 +++-
>> drivers/net/phy/realtek.c | 19 ++++
>> drivers/net/phy/ti.c | 130 +++++-------------------
>> include/phy.h | 70 +++++++++++++
>> 19 files changed, 394 insertions(+), 221 deletions(-)
>>
>> Thanks!
>> -Joe
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>
Hi Joe, Tom,
It sounds like what Joe pointed to (my patch) has a high chance of
causing link failure.
If the board is relying on RX delays in the Atheros PHY to ensure
correct RGMII timing budget, then for sure it was working before and now
it is broken. In that case, it was working by mistake; the DT blob is
broken and should be corrected.
Sorry for the trouble this has caused.
Regards,
-Vladimir
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [EXT] Re: Pull request: u-boot-net.git master
2019-05-08 22:40 ` [U-Boot] [EXT] " Vladimir Oltean
@ 2019-05-08 22:42 ` Tom Rini
2019-05-08 22:45 ` [U-Boot] " Vladimir Oltean
0 siblings, 1 reply; 21+ messages in thread
From: Tom Rini @ 2019-05-08 22:42 UTC (permalink / raw
To: u-boot
On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
> On 5/9/19 1:24 AM, Joe Hershberger wrote:
> > On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
> >>
> >> Hi Tom,
> >>
> >> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
> >>
> >> I rebased on your master and built for BB Black. DHCP seems to work fine.
> >> MLO also now fits again.
> >>
> >> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
> >>
> >> are available in the git repository at:
> >>
> >> git://git.denx.de/u-boot-net.git master
> >>
> >> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
> >>
> >> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
> >>
> >> ----------------------------------------------------------------
> >> Carlo Caione (4):
> >> net: phy: Add generic helpers to access MMD PHY registers
> >> net: phy: ti: use generic helpers to access MMD registers
> >> cmd: mdio: Switch to generic helpers when accessing the registers
> >> net: phy: realtek: Introduce quirk to mark RXC not stoppable
> >>
> >> James Byrne (2):
> >> net: phy: micrel: Use correct skew values on KSZ9021
> >> net: phy: micrel: Find Micrel PHY node correctly
> >>
> >> Murali Karicheri (2):
> >> ARM: k2g-gp-evm: update to rgmii pinmux configuration
> >> ARM: k2g-ice: Add pinmux support for rgmii interface
> >>
> >> Pankaj Bansal (1):
> >> drivers: net: ldpaa_eth: fix resource leak
> >>
> >> Siva Durga Prasad Paladugu (2):
> >> net: phy: Reloc next and prev pointers inside phy_drivers
> >> net: phy: Fix return value check phy_probe
> >>
> >> Valentin-catalin Neacsu (1):
> >> net: phy: aquantia: Set only autoneg on in register 4.c441
> >>
> >> Vladimir Oltean (6):
> >> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
> >> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
> >> net: phy: ar803x: Use common functions for RGMII internal delays
> >> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
> >> net: phy: ar803x: Explicitly disable RGMII delays
> >
> > Tom, this [1] is the patch that is breaking the evm. It doesn't affect
> > BB Black because it uses an SMSC phy, where as this evm uses an
> > AR8031/AR8033.
> >
> > Is it possible the device tree [2] is wrong for the board? It lists
> > 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
> > delay is now being disabled.
> >
> > Any thoughts, Vladimir?
> >
> > Thanks,
> > -Joe
> >
> > [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
> > [2] arch/arm/dts/am335x-evm.dts
> >
> >> net: phy: ar803x: Clarify the intention of ar8021_config
> >>
> >> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
> >> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
> >> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
> >> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
> >> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
> >> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
> >> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
> >> board/ti/ks2_evm/mux-k2g.h | 36 +++----
> >> cmd/mdio.c | 27 +++--
> >> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
> >> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
> >> drivers/net/phy/Kconfig | 41 ++++++++
> >> drivers/net/phy/aquantia.c | 7 +-
> >> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
> >> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
> >> drivers/net/phy/phy.c | 21 +++-
> >> drivers/net/phy/realtek.c | 19 ++++
> >> drivers/net/phy/ti.c | 130 +++++-------------------
> >> include/phy.h | 70 +++++++++++++
> >> 19 files changed, 394 insertions(+), 221 deletions(-)
> >>
> >> Thanks!
> >> -Joe
> >> _______________________________________________
> >> U-Boot mailing list
> >> U-Boot at lists.denx.de
> >> https://lists.denx.de/listinfo/u-boot
> >
>
> Hi Joe, Tom,
>
> It sounds like what Joe pointed to (my patch) has a high chance of
> causing link failure.
> If the board is relying on RX delays in the Atheros PHY to ensure
> correct RGMII timing budget, then for sure it was working before and now
> it is broken. In that case, it was working by mistake; the DT blob is
> broken and should be corrected.
> Sorry for the trouble this has caused.
How is this handled in the Linux kernel and/or why doesn't it fail
there?
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190508/c7c50dfa/attachment.sig>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-05-08 22:42 ` Tom Rini
@ 2019-05-08 22:45 ` Vladimir Oltean
2019-05-08 22:48 ` Tom Rini
0 siblings, 1 reply; 21+ messages in thread
From: Vladimir Oltean @ 2019-05-08 22:45 UTC (permalink / raw
To: u-boot
On 5/9/19 1:42 AM, Tom Rini wrote:
> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
>>>>
>>>> Hi Tom,
>>>>
>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
>>>>
>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
>>>> MLO also now fits again.
>>>>
>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
>>>>
>>>> are available in the git repository at:
>>>>
>>>> git://git.denx.de/u-boot-net.git master
>>>>
>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
>>>>
>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
>>>>
>>>> ----------------------------------------------------------------
>>>> Carlo Caione (4):
>>>> net: phy: Add generic helpers to access MMD PHY registers
>>>> net: phy: ti: use generic helpers to access MMD registers
>>>> cmd: mdio: Switch to generic helpers when accessing the registers
>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
>>>>
>>>> James Byrne (2):
>>>> net: phy: micrel: Use correct skew values on KSZ9021
>>>> net: phy: micrel: Find Micrel PHY node correctly
>>>>
>>>> Murali Karicheri (2):
>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
>>>>
>>>> Pankaj Bansal (1):
>>>> drivers: net: ldpaa_eth: fix resource leak
>>>>
>>>> Siva Durga Prasad Paladugu (2):
>>>> net: phy: Reloc next and prev pointers inside phy_drivers
>>>> net: phy: Fix return value check phy_probe
>>>>
>>>> Valentin-catalin Neacsu (1):
>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
>>>>
>>>> Vladimir Oltean (6):
>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
>>>> net: phy: ar803x: Use common functions for RGMII internal delays
>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
>>>> net: phy: ar803x: Explicitly disable RGMII delays
>>>
>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
>>> BB Black because it uses an SMSC phy, where as this evm uses an
>>> AR8031/AR8033.
>>>
>>> Is it possible the device tree [2] is wrong for the board? It lists
>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
>>> delay is now being disabled.
>>>
>>> Any thoughts, Vladimir?
>>>
>>> Thanks,
>>> -Joe
>>>
>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
>>> [2] arch/arm/dts/am335x-evm.dts
>>>
>>>> net: phy: ar803x: Clarify the intention of ar8021_config
>>>>
>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
>>>> cmd/mdio.c | 27 +++--
>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
>>>> drivers/net/phy/Kconfig | 41 ++++++++
>>>> drivers/net/phy/aquantia.c | 7 +-
>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
>>>> drivers/net/phy/phy.c | 21 +++-
>>>> drivers/net/phy/realtek.c | 19 ++++
>>>> drivers/net/phy/ti.c | 130 +++++-------------------
>>>> include/phy.h | 70 +++++++++++++
>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
>>>>
>>>> Thanks!
>>>> -Joe
>>>> _______________________________________________
>>>> U-Boot mailing list
>>>> U-Boot at lists.denx.de
>>>> https://lists.denx.de/listinfo/u-boot
>>>
>>
>> Hi Joe, Tom,
>>
>> It sounds like what Joe pointed to (my patch) has a high chance of
>> causing link failure.
>> If the board is relying on RX delays in the Atheros PHY to ensure
>> correct RGMII timing budget, then for sure it was working before and now
>> it is broken. In that case, it was working by mistake; the DT blob is
>> broken and should be corrected.
>> Sorry for the trouble this has caused.
>
> How is this handled in the Linux kernel and/or why doesn't it fail
> there?
>
On the latest net-next, it's handled the same: disable everything and
enable only what's specified in phy-mode. I didn't keep track of older
versions.
-Vladimir
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-05-08 22:45 ` [U-Boot] " Vladimir Oltean
@ 2019-05-08 22:48 ` Tom Rini
2019-05-08 22:52 ` Vladimir Oltean
0 siblings, 1 reply; 21+ messages in thread
From: Tom Rini @ 2019-05-08 22:48 UTC (permalink / raw
To: u-boot
On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
> On 5/9/19 1:42 AM, Tom Rini wrote:
> > On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
> >> On 5/9/19 1:24 AM, Joe Hershberger wrote:
> >>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
> >>>>
> >>>> Hi Tom,
> >>>>
> >>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
> >>>>
> >>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
> >>>> MLO also now fits again.
> >>>>
> >>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
> >>>>
> >>>> are available in the git repository at:
> >>>>
> >>>> git://git.denx.de/u-boot-net.git master
> >>>>
> >>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
> >>>>
> >>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> Carlo Caione (4):
> >>>> net: phy: Add generic helpers to access MMD PHY registers
> >>>> net: phy: ti: use generic helpers to access MMD registers
> >>>> cmd: mdio: Switch to generic helpers when accessing the registers
> >>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
> >>>>
> >>>> James Byrne (2):
> >>>> net: phy: micrel: Use correct skew values on KSZ9021
> >>>> net: phy: micrel: Find Micrel PHY node correctly
> >>>>
> >>>> Murali Karicheri (2):
> >>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
> >>>> ARM: k2g-ice: Add pinmux support for rgmii interface
> >>>>
> >>>> Pankaj Bansal (1):
> >>>> drivers: net: ldpaa_eth: fix resource leak
> >>>>
> >>>> Siva Durga Prasad Paladugu (2):
> >>>> net: phy: Reloc next and prev pointers inside phy_drivers
> >>>> net: phy: Fix return value check phy_probe
> >>>>
> >>>> Valentin-catalin Neacsu (1):
> >>>> net: phy: aquantia: Set only autoneg on in register 4.c441
> >>>>
> >>>> Vladimir Oltean (6):
> >>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
> >>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
> >>>> net: phy: ar803x: Use common functions for RGMII internal delays
> >>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
> >>>> net: phy: ar803x: Explicitly disable RGMII delays
> >>>
> >>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
> >>> BB Black because it uses an SMSC phy, where as this evm uses an
> >>> AR8031/AR8033.
> >>>
> >>> Is it possible the device tree [2] is wrong for the board? It lists
> >>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
> >>> delay is now being disabled.
> >>>
> >>> Any thoughts, Vladimir?
> >>>
> >>> Thanks,
> >>> -Joe
> >>>
> >>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
> >>> [2] arch/arm/dts/am335x-evm.dts
> >>>
> >>>> net: phy: ar803x: Clarify the intention of ar8021_config
> >>>>
> >>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
> >>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
> >>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
> >>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
> >>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
> >>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
> >>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
> >>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
> >>>> cmd/mdio.c | 27 +++--
> >>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
> >>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
> >>>> drivers/net/phy/Kconfig | 41 ++++++++
> >>>> drivers/net/phy/aquantia.c | 7 +-
> >>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
> >>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
> >>>> drivers/net/phy/phy.c | 21 +++-
> >>>> drivers/net/phy/realtek.c | 19 ++++
> >>>> drivers/net/phy/ti.c | 130 +++++-------------------
> >>>> include/phy.h | 70 +++++++++++++
> >>>> 19 files changed, 394 insertions(+), 221 deletions(-)
> >>>>
> >>>> Thanks!
> >>>> -Joe
> >>>> _______________________________________________
> >>>> U-Boot mailing list
> >>>> U-Boot at lists.denx.de
> >>>> https://lists.denx.de/listinfo/u-boot
> >>>
> >>
> >> Hi Joe, Tom,
> >>
> >> It sounds like what Joe pointed to (my patch) has a high chance of
> >> causing link failure.
> >> If the board is relying on RX delays in the Atheros PHY to ensure
> >> correct RGMII timing budget, then for sure it was working before and now
> >> it is broken. In that case, it was working by mistake; the DT blob is
> >> broken and should be corrected.
> >> Sorry for the trouble this has caused.
> >
> > How is this handled in the Linux kernel and/or why doesn't it fail
> > there?
>
> On the latest net-next, it's handled the same: disable everything and
> enable only what's specified in phy-mode. I didn't keep track of older
> versions.
So you would expect the network to be broken on net-next with this DTS?
Because that's not allowed...
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190508/15d72237/attachment.sig>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-05-08 22:48 ` Tom Rini
@ 2019-05-08 22:52 ` Vladimir Oltean
2019-05-08 22:54 ` Tom Rini
0 siblings, 1 reply; 21+ messages in thread
From: Vladimir Oltean @ 2019-05-08 22:52 UTC (permalink / raw
To: u-boot
On 5/9/19 1:48 AM, Tom Rini wrote:
> On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
>> On 5/9/19 1:42 AM, Tom Rini wrote:
>>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
>>>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
>>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
>>>>>>
>>>>>> Hi Tom,
>>>>>>
>>>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
>>>>>>
>>>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
>>>>>> MLO also now fits again.
>>>>>>
>>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
>>>>>>
>>>>>> are available in the git repository at:
>>>>>>
>>>>>> git://git.denx.de/u-boot-net.git master
>>>>>>
>>>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
>>>>>>
>>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
>>>>>>
>>>>>> ----------------------------------------------------------------
>>>>>> Carlo Caione (4):
>>>>>> net: phy: Add generic helpers to access MMD PHY registers
>>>>>> net: phy: ti: use generic helpers to access MMD registers
>>>>>> cmd: mdio: Switch to generic helpers when accessing the registers
>>>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
>>>>>>
>>>>>> James Byrne (2):
>>>>>> net: phy: micrel: Use correct skew values on KSZ9021
>>>>>> net: phy: micrel: Find Micrel PHY node correctly
>>>>>>
>>>>>> Murali Karicheri (2):
>>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
>>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
>>>>>>
>>>>>> Pankaj Bansal (1):
>>>>>> drivers: net: ldpaa_eth: fix resource leak
>>>>>>
>>>>>> Siva Durga Prasad Paladugu (2):
>>>>>> net: phy: Reloc next and prev pointers inside phy_drivers
>>>>>> net: phy: Fix return value check phy_probe
>>>>>>
>>>>>> Valentin-catalin Neacsu (1):
>>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
>>>>>>
>>>>>> Vladimir Oltean (6):
>>>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
>>>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
>>>>>> net: phy: ar803x: Use common functions for RGMII internal delays
>>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
>>>>>> net: phy: ar803x: Explicitly disable RGMII delays
>>>>>
>>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
>>>>> BB Black because it uses an SMSC phy, where as this evm uses an
>>>>> AR8031/AR8033.
>>>>>
>>>>> Is it possible the device tree [2] is wrong for the board? It lists
>>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
>>>>> delay is now being disabled.
>>>>>
>>>>> Any thoughts, Vladimir?
>>>>>
>>>>> Thanks,
>>>>> -Joe
>>>>>
>>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
>>>>> [2] arch/arm/dts/am335x-evm.dts
>>>>>
>>>>>> net: phy: ar803x: Clarify the intention of ar8021_config
>>>>>>
>>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
>>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
>>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
>>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
>>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
>>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
>>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
>>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
>>>>>> cmd/mdio.c | 27 +++--
>>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
>>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
>>>>>> drivers/net/phy/Kconfig | 41 ++++++++
>>>>>> drivers/net/phy/aquantia.c | 7 +-
>>>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
>>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
>>>>>> drivers/net/phy/phy.c | 21 +++-
>>>>>> drivers/net/phy/realtek.c | 19 ++++
>>>>>> drivers/net/phy/ti.c | 130 +++++-------------------
>>>>>> include/phy.h | 70 +++++++++++++
>>>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
>>>>>>
>>>>>> Thanks!
>>>>>> -Joe
>>>>>> _______________________________________________
>>>>>> U-Boot mailing list
>>>>>> U-Boot at lists.denx.de
>>>>>> https://lists.denx.de/listinfo/u-boot
>>>>>
>>>>
>>>> Hi Joe, Tom,
>>>>
>>>> It sounds like what Joe pointed to (my patch) has a high chance of
>>>> causing link failure.
>>>> If the board is relying on RX delays in the Atheros PHY to ensure
>>>> correct RGMII timing budget, then for sure it was working before and now
>>>> it is broken. In that case, it was working by mistake; the DT blob is
>>>> broken and should be corrected.
>>>> Sorry for the trouble this has caused.
>>>
>>> How is this handled in the Linux kernel and/or why doesn't it fail
>>> there?
>>
>> On the latest net-next, it's handled the same: disable everything and
>> enable only what's specified in phy-mode. I didn't keep track of older
>> versions.
>
> So you would expect the network to be broken on net-next with this DTS?
> Because that's not allowed...
>
Yes, if it's the same problem, the behavior should be the same.
I see net-next is only rejecting the bad DT since 2019-02-21:
https://patchwork.kernel.org/patch/10819279/
So it depends when you checked it last time.
-Vladimir
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-05-08 22:52 ` Vladimir Oltean
@ 2019-05-08 22:54 ` Tom Rini
2019-05-08 23:05 ` Vladimir Oltean
0 siblings, 1 reply; 21+ messages in thread
From: Tom Rini @ 2019-05-08 22:54 UTC (permalink / raw
To: u-boot
On Wed, May 08, 2019 at 10:52:28PM +0000, Vladimir Oltean wrote:
> On 5/9/19 1:48 AM, Tom Rini wrote:
> > On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
> >> On 5/9/19 1:42 AM, Tom Rini wrote:
> >>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
> >>>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
> >>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
> >>>>>>
> >>>>>> Hi Tom,
> >>>>>>
> >>>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
> >>>>>>
> >>>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
> >>>>>> MLO also now fits again.
> >>>>>>
> >>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
> >>>>>>
> >>>>>> are available in the git repository at:
> >>>>>>
> >>>>>> git://git.denx.de/u-boot-net.git master
> >>>>>>
> >>>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
> >>>>>>
> >>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
> >>>>>>
> >>>>>> ----------------------------------------------------------------
> >>>>>> Carlo Caione (4):
> >>>>>> net: phy: Add generic helpers to access MMD PHY registers
> >>>>>> net: phy: ti: use generic helpers to access MMD registers
> >>>>>> cmd: mdio: Switch to generic helpers when accessing the registers
> >>>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
> >>>>>>
> >>>>>> James Byrne (2):
> >>>>>> net: phy: micrel: Use correct skew values on KSZ9021
> >>>>>> net: phy: micrel: Find Micrel PHY node correctly
> >>>>>>
> >>>>>> Murali Karicheri (2):
> >>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
> >>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
> >>>>>>
> >>>>>> Pankaj Bansal (1):
> >>>>>> drivers: net: ldpaa_eth: fix resource leak
> >>>>>>
> >>>>>> Siva Durga Prasad Paladugu (2):
> >>>>>> net: phy: Reloc next and prev pointers inside phy_drivers
> >>>>>> net: phy: Fix return value check phy_probe
> >>>>>>
> >>>>>> Valentin-catalin Neacsu (1):
> >>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
> >>>>>>
> >>>>>> Vladimir Oltean (6):
> >>>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
> >>>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
> >>>>>> net: phy: ar803x: Use common functions for RGMII internal delays
> >>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
> >>>>>> net: phy: ar803x: Explicitly disable RGMII delays
> >>>>>
> >>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
> >>>>> BB Black because it uses an SMSC phy, where as this evm uses an
> >>>>> AR8031/AR8033.
> >>>>>
> >>>>> Is it possible the device tree [2] is wrong for the board? It lists
> >>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
> >>>>> delay is now being disabled.
> >>>>>
> >>>>> Any thoughts, Vladimir?
> >>>>>
> >>>>> Thanks,
> >>>>> -Joe
> >>>>>
> >>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
> >>>>> [2] arch/arm/dts/am335x-evm.dts
> >>>>>
> >>>>>> net: phy: ar803x: Clarify the intention of ar8021_config
> >>>>>>
> >>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
> >>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
> >>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
> >>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
> >>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
> >>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
> >>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
> >>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
> >>>>>> cmd/mdio.c | 27 +++--
> >>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
> >>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
> >>>>>> drivers/net/phy/Kconfig | 41 ++++++++
> >>>>>> drivers/net/phy/aquantia.c | 7 +-
> >>>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
> >>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
> >>>>>> drivers/net/phy/phy.c | 21 +++-
> >>>>>> drivers/net/phy/realtek.c | 19 ++++
> >>>>>> drivers/net/phy/ti.c | 130 +++++-------------------
> >>>>>> include/phy.h | 70 +++++++++++++
> >>>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
> >>>>>>
> >>>>>> Thanks!
> >>>>>> -Joe
> >>>>>> _______________________________________________
> >>>>>> U-Boot mailing list
> >>>>>> U-Boot at lists.denx.de
> >>>>>> https://lists.denx.de/listinfo/u-boot
> >>>>>
> >>>>
> >>>> Hi Joe, Tom,
> >>>>
> >>>> It sounds like what Joe pointed to (my patch) has a high chance of
> >>>> causing link failure.
> >>>> If the board is relying on RX delays in the Atheros PHY to ensure
> >>>> correct RGMII timing budget, then for sure it was working before and now
> >>>> it is broken. In that case, it was working by mistake; the DT blob is
> >>>> broken and should be corrected.
> >>>> Sorry for the trouble this has caused.
> >>>
> >>> How is this handled in the Linux kernel and/or why doesn't it fail
> >>> there?
> >>
> >> On the latest net-next, it's handled the same: disable everything and
> >> enable only what's specified in phy-mode. I didn't keep track of older
> >> versions.
> >
> > So you would expect the network to be broken on net-next with this DTS?
> > Because that's not allowed...
> >
>
> Yes, if it's the same problem, the behavior should be the same.
> I see net-next is only rejecting the bad DT since 2019-02-21:
> https://patchwork.kernel.org/patch/10819279/
> So it depends when you checked it last time.
I'll see about testing eth in Linux with net-next tomorrow, but, uh, is
there some work-around for the DTS so that ethernet works? You cannot
break existing DTs.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190508/6fd7f0b5/attachment.sig>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-05-08 22:54 ` Tom Rini
@ 2019-05-08 23:05 ` Vladimir Oltean
2019-05-09 2:38 ` Tom Rini
2019-05-09 12:51 ` Vladimir Oltean
0 siblings, 2 replies; 21+ messages in thread
From: Vladimir Oltean @ 2019-05-08 23:05 UTC (permalink / raw
To: u-boot
On 5/9/19 1:55 AM, Tom Rini wrote:
> On Wed, May 08, 2019 at 10:52:28PM +0000, Vladimir Oltean wrote:
>> On 5/9/19 1:48 AM, Tom Rini wrote:
>>> On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
>>>> On 5/9/19 1:42 AM, Tom Rini wrote:
>>>>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
>>>>>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
>>>>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
>>>>>>>>
>>>>>>>> Hi Tom,
>>>>>>>>
>>>>>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
>>>>>>>>
>>>>>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
>>>>>>>> MLO also now fits again.
>>>>>>>>
>>>>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
>>>>>>>>
>>>>>>>> are available in the git repository at:
>>>>>>>>
>>>>>>>> git://git.denx.de/u-boot-net.git master
>>>>>>>>
>>>>>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
>>>>>>>>
>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> Carlo Caione (4):
>>>>>>>> net: phy: Add generic helpers to access MMD PHY registers
>>>>>>>> net: phy: ti: use generic helpers to access MMD registers
>>>>>>>> cmd: mdio: Switch to generic helpers when accessing the registers
>>>>>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
>>>>>>>>
>>>>>>>> James Byrne (2):
>>>>>>>> net: phy: micrel: Use correct skew values on KSZ9021
>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly
>>>>>>>>
>>>>>>>> Murali Karicheri (2):
>>>>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
>>>>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
>>>>>>>>
>>>>>>>> Pankaj Bansal (1):
>>>>>>>> drivers: net: ldpaa_eth: fix resource leak
>>>>>>>>
>>>>>>>> Siva Durga Prasad Paladugu (2):
>>>>>>>> net: phy: Reloc next and prev pointers inside phy_drivers
>>>>>>>> net: phy: Fix return value check phy_probe
>>>>>>>>
>>>>>>>> Valentin-catalin Neacsu (1):
>>>>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
>>>>>>>>
>>>>>>>> Vladimir Oltean (6):
>>>>>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
>>>>>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
>>>>>>>> net: phy: ar803x: Use common functions for RGMII internal delays
>>>>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
>>>>>>>> net: phy: ar803x: Explicitly disable RGMII delays
>>>>>>>
>>>>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
>>>>>>> BB Black because it uses an SMSC phy, where as this evm uses an
>>>>>>> AR8031/AR8033.
>>>>>>>
>>>>>>> Is it possible the device tree [2] is wrong for the board? It lists
>>>>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
>>>>>>> delay is now being disabled.
>>>>>>>
>>>>>>> Any thoughts, Vladimir?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Joe
>>>>>>>
>>>>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
>>>>>>> [2] arch/arm/dts/am335x-evm.dts
>>>>>>>
>>>>>>>> net: phy: ar803x: Clarify the intention of ar8021_config
>>>>>>>>
>>>>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
>>>>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
>>>>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
>>>>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
>>>>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
>>>>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
>>>>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
>>>>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
>>>>>>>> cmd/mdio.c | 27 +++--
>>>>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
>>>>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
>>>>>>>> drivers/net/phy/Kconfig | 41 ++++++++
>>>>>>>> drivers/net/phy/aquantia.c | 7 +-
>>>>>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
>>>>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
>>>>>>>> drivers/net/phy/phy.c | 21 +++-
>>>>>>>> drivers/net/phy/realtek.c | 19 ++++
>>>>>>>> drivers/net/phy/ti.c | 130 +++++-------------------
>>>>>>>> include/phy.h | 70 +++++++++++++
>>>>>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> -Joe
>>>>>>>> _______________________________________________
>>>>>>>> U-Boot mailing list
>>>>>>>> U-Boot at lists.denx.de
>>>>>>>> https://lists.denx.de/listinfo/u-boot
>>>>>>>
>>>>>>
>>>>>> Hi Joe, Tom,
>>>>>>
>>>>>> It sounds like what Joe pointed to (my patch) has a high chance of
>>>>>> causing link failure.
>>>>>> If the board is relying on RX delays in the Atheros PHY to ensure
>>>>>> correct RGMII timing budget, then for sure it was working before and now
>>>>>> it is broken. In that case, it was working by mistake; the DT blob is
>>>>>> broken and should be corrected.
>>>>>> Sorry for the trouble this has caused.
>>>>>
>>>>> How is this handled in the Linux kernel and/or why doesn't it fail
>>>>> there?
>>>>
>>>> On the latest net-next, it's handled the same: disable everything and
>>>> enable only what's specified in phy-mode. I didn't keep track of older
>>>> versions.
>>>
>>> So you would expect the network to be broken on net-next with this DTS?
>>> Because that's not allowed...
>>>
>>
>> Yes, if it's the same problem, the behavior should be the same.
>> I see net-next is only rejecting the bad DT since 2019-02-21:
>> https://patchwork.kernel.org/patch/10819279/
>> So it depends when you checked it last time.
>
> I'll see about testing eth in Linux with net-next tomorrow, but, uh, is
> there some work-around for the DTS so that ethernet works?
Work-around in Linux or in U-boot?
U-boot can fix up the DT for Linux and replace "rgmii-txid" with
"rgmii-id", whereas neither Linux nor U-boot can do anything for
themselves except either load a correct DT blob, or not use (revert, not
upgrade to, etc) the enforcing patch.
> You cannot break existing DTs
RGMII delay breakages happen all the time. To play the devil's advocate,
protecting against them should be done by observing the semantics
described in the devicetree/bindings document.
If you follow Linux net-next, a breakage for RTL8211F is planned out
right as we speak.
But let's wait until we know for sure that this is what's causing the
issues.
Regards,
-Vladimir
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-05-08 23:05 ` Vladimir Oltean
@ 2019-05-09 2:38 ` Tom Rini
2019-05-09 12:51 ` Vladimir Oltean
1 sibling, 0 replies; 21+ messages in thread
From: Tom Rini @ 2019-05-09 2:38 UTC (permalink / raw
To: u-boot
+ Rob
On Wed, May 08, 2019 at 11:05:29PM +0000, Vladimir Oltean wrote:
> On 5/9/19 1:55 AM, Tom Rini wrote:
> > On Wed, May 08, 2019 at 10:52:28PM +0000, Vladimir Oltean wrote:
> >> On 5/9/19 1:48 AM, Tom Rini wrote:
> >>> On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
> >>>> On 5/9/19 1:42 AM, Tom Rini wrote:
> >>>>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
> >>>>>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
> >>>>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
> >>>>>>>>
> >>>>>>>> Hi Tom,
> >>>>>>>>
> >>>>>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
> >>>>>>>>
> >>>>>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
> >>>>>>>> MLO also now fits again.
> >>>>>>>>
> >>>>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
> >>>>>>>>
> >>>>>>>> are available in the git repository at:
> >>>>>>>>
> >>>>>>>> git://git.denx.de/u-boot-net.git master
> >>>>>>>>
> >>>>>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
> >>>>>>>>
> >>>>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
> >>>>>>>>
> >>>>>>>> ----------------------------------------------------------------
> >>>>>>>> Carlo Caione (4):
> >>>>>>>> net: phy: Add generic helpers to access MMD PHY registers
> >>>>>>>> net: phy: ti: use generic helpers to access MMD registers
> >>>>>>>> cmd: mdio: Switch to generic helpers when accessing the registers
> >>>>>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
> >>>>>>>>
> >>>>>>>> James Byrne (2):
> >>>>>>>> net: phy: micrel: Use correct skew values on KSZ9021
> >>>>>>>> net: phy: micrel: Find Micrel PHY node correctly
> >>>>>>>>
> >>>>>>>> Murali Karicheri (2):
> >>>>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
> >>>>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
> >>>>>>>>
> >>>>>>>> Pankaj Bansal (1):
> >>>>>>>> drivers: net: ldpaa_eth: fix resource leak
> >>>>>>>>
> >>>>>>>> Siva Durga Prasad Paladugu (2):
> >>>>>>>> net: phy: Reloc next and prev pointers inside phy_drivers
> >>>>>>>> net: phy: Fix return value check phy_probe
> >>>>>>>>
> >>>>>>>> Valentin-catalin Neacsu (1):
> >>>>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
> >>>>>>>>
> >>>>>>>> Vladimir Oltean (6):
> >>>>>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
> >>>>>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
> >>>>>>>> net: phy: ar803x: Use common functions for RGMII internal delays
> >>>>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
> >>>>>>>> net: phy: ar803x: Explicitly disable RGMII delays
> >>>>>>>
> >>>>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
> >>>>>>> BB Black because it uses an SMSC phy, where as this evm uses an
> >>>>>>> AR8031/AR8033.
> >>>>>>>
> >>>>>>> Is it possible the device tree [2] is wrong for the board? It lists
> >>>>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
> >>>>>>> delay is now being disabled.
> >>>>>>>
> >>>>>>> Any thoughts, Vladimir?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> -Joe
> >>>>>>>
> >>>>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
> >>>>>>> [2] arch/arm/dts/am335x-evm.dts
> >>>>>>>
> >>>>>>>> net: phy: ar803x: Clarify the intention of ar8021_config
> >>>>>>>>
> >>>>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
> >>>>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
> >>>>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
> >>>>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
> >>>>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
> >>>>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
> >>>>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
> >>>>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
> >>>>>>>> cmd/mdio.c | 27 +++--
> >>>>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
> >>>>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
> >>>>>>>> drivers/net/phy/Kconfig | 41 ++++++++
> >>>>>>>> drivers/net/phy/aquantia.c | 7 +-
> >>>>>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
> >>>>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
> >>>>>>>> drivers/net/phy/phy.c | 21 +++-
> >>>>>>>> drivers/net/phy/realtek.c | 19 ++++
> >>>>>>>> drivers/net/phy/ti.c | 130 +++++-------------------
> >>>>>>>> include/phy.h | 70 +++++++++++++
> >>>>>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
> >>>>>>>>
> >>>>>>>> Thanks!
> >>>>>>>> -Joe
> >>>>>>>> _______________________________________________
> >>>>>>>> U-Boot mailing list
> >>>>>>>> U-Boot at lists.denx.de
> >>>>>>>> https://lists.denx.de/listinfo/u-boot
> >>>>>>>
> >>>>>>
> >>>>>> Hi Joe, Tom,
> >>>>>>
> >>>>>> It sounds like what Joe pointed to (my patch) has a high chance of
> >>>>>> causing link failure.
> >>>>>> If the board is relying on RX delays in the Atheros PHY to ensure
> >>>>>> correct RGMII timing budget, then for sure it was working before and now
> >>>>>> it is broken. In that case, it was working by mistake; the DT blob is
> >>>>>> broken and should be corrected.
> >>>>>> Sorry for the trouble this has caused.
> >>>>>
> >>>>> How is this handled in the Linux kernel and/or why doesn't it fail
> >>>>> there?
> >>>>
> >>>> On the latest net-next, it's handled the same: disable everything and
> >>>> enable only what's specified in phy-mode. I didn't keep track of older
> >>>> versions.
> >>>
> >>> So you would expect the network to be broken on net-next with this DTS?
> >>> Because that's not allowed...
> >>>
> >>
> >> Yes, if it's the same problem, the behavior should be the same.
> >> I see net-next is only rejecting the bad DT since 2019-02-21:
> >> https://patchwork.kernel.org/patch/10819279/
> >> So it depends when you checked it last time.
> >
> > I'll see about testing eth in Linux with net-next tomorrow, but, uh, is
> > there some work-around for the DTS so that ethernet works?
>
> Work-around in Linux or in U-boot?
> U-boot can fix up the DT for Linux and replace "rgmii-txid" with
> "rgmii-id", whereas neither Linux nor U-boot can do anything for
> themselves except either load a correct DT blob, or not use (revert, not
> upgrade to, etc) the enforcing patch.
>
> > You cannot break existing DTs
> RGMII delay breakages happen all the time. To play the devil's advocate,
> protecting against them should be done by observing the semantics
> described in the devicetree/bindings document.
> If you follow Linux net-next, a breakage for RTL8211F is planned out
> right as we speak.
>
> But let's wait until we know for sure that this is what's causing the
> issues.
OK, so net-next works. Looking harder that's because of:
commit 37685f6a63eeca2135d1f704e7638409a071b1f6
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date: Tue Feb 19 08:46:33 2019 -0800
ARM: dts: am335x-evm: Fix PHY mode for ethernet
which changes:
&cpsw_emac0 {
phy-handle = <ðphy0>;
- phy-mode = "rgmii-txid";
+ phy-mode = "rgmii-id";
};
Which explains why things work but I still cannot believe that despite
"DT is ABI" and "You cannot break existing DT binaries" we're apparently
breaking existing DT binaries.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190508/0da6914d/attachment.sig>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-05-08 23:05 ` Vladimir Oltean
2019-05-09 2:38 ` Tom Rini
@ 2019-05-09 12:51 ` Vladimir Oltean
2019-05-10 21:50 ` Joe Hershberger
1 sibling, 1 reply; 21+ messages in thread
From: Vladimir Oltean @ 2019-05-09 12:51 UTC (permalink / raw
To: u-boot
On 09.05.2019 02:05, Vladimir Oltean wrote:
> On 5/9/19 1:55 AM, Tom Rini wrote:
>> On Wed, May 08, 2019 at 10:52:28PM +0000, Vladimir Oltean wrote:
>>> On 5/9/19 1:48 AM, Tom Rini wrote:
>>>> On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
>>>>> On 5/9/19 1:42 AM, Tom Rini wrote:
>>>>>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
>>>>>>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
>>>>>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Tom,
>>>>>>>>>
>>>>>>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
>>>>>>>>>
>>>>>>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
>>>>>>>>> MLO also now fits again.
>>>>>>>>>
>>>>>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
>>>>>>>>>
>>>>>>>>> are available in the git repository at:
>>>>>>>>>
>>>>>>>>> git://git.denx.de/u-boot-net.git master
>>>>>>>>>
>>>>>>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
>>>>>>>>>
>>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>> Carlo Caione (4):
>>>>>>>>> net: phy: Add generic helpers to access MMD PHY registers
>>>>>>>>> net: phy: ti: use generic helpers to access MMD registers
>>>>>>>>> cmd: mdio: Switch to generic helpers when accessing the registers
>>>>>>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
>>>>>>>>>
>>>>>>>>> James Byrne (2):
>>>>>>>>> net: phy: micrel: Use correct skew values on KSZ9021
>>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly
>>>>>>>>>
>>>>>>>>> Murali Karicheri (2):
>>>>>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
>>>>>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
>>>>>>>>>
>>>>>>>>> Pankaj Bansal (1):
>>>>>>>>> drivers: net: ldpaa_eth: fix resource leak
>>>>>>>>>
>>>>>>>>> Siva Durga Prasad Paladugu (2):
>>>>>>>>> net: phy: Reloc next and prev pointers inside phy_drivers
>>>>>>>>> net: phy: Fix return value check phy_probe
>>>>>>>>>
>>>>>>>>> Valentin-catalin Neacsu (1):
>>>>>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
>>>>>>>>>
>>>>>>>>> Vladimir Oltean (6):
>>>>>>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
>>>>>>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
>>>>>>>>> net: phy: ar803x: Use common functions for RGMII internal delays
>>>>>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
>>>>>>>>> net: phy: ar803x: Explicitly disable RGMII delays
>>>>>>>>
>>>>>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
>>>>>>>> BB Black because it uses an SMSC phy, where as this evm uses an
>>>>>>>> AR8031/AR8033.
>>>>>>>>
>>>>>>>> Is it possible the device tree [2] is wrong for the board? It lists
>>>>>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
>>>>>>>> delay is now being disabled.
>>>>>>>>
>>>>>>>> Any thoughts, Vladimir?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Joe
>>>>>>>>
>>>>>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
>>>>>>>> [2] arch/arm/dts/am335x-evm.dts
>>>>>>>>
>>>>>>>>> net: phy: ar803x: Clarify the intention of ar8021_config
>>>>>>>>>
>>>>>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
>>>>>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
>>>>>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
>>>>>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
>>>>>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
>>>>>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
>>>>>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
>>>>>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
>>>>>>>>> cmd/mdio.c | 27 +++--
>>>>>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
>>>>>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
>>>>>>>>> drivers/net/phy/Kconfig | 41 ++++++++
>>>>>>>>> drivers/net/phy/aquantia.c | 7 +-
>>>>>>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
>>>>>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
>>>>>>>>> drivers/net/phy/phy.c | 21 +++-
>>>>>>>>> drivers/net/phy/realtek.c | 19 ++++
>>>>>>>>> drivers/net/phy/ti.c | 130 +++++-------------------
>>>>>>>>> include/phy.h | 70 +++++++++++++
>>>>>>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> -Joe
>>>>>>>>> _______________________________________________
>>>>>>>>> U-Boot mailing list
>>>>>>>>> U-Boot at lists.denx.de
>>>>>>>>> https://lists.denx.de/listinfo/u-boot
>>>>>>>>
>>>>>>>
>>>>>>> Hi Joe, Tom,
>>>>>>>
>>>>>>> It sounds like what Joe pointed to (my patch) has a high chance of
>>>>>>> causing link failure.
>>>>>>> If the board is relying on RX delays in the Atheros PHY to ensure
>>>>>>> correct RGMII timing budget, then for sure it was working before and now
>>>>>>> it is broken. In that case, it was working by mistake; the DT blob is
>>>>>>> broken and should be corrected.
>>>>>>> Sorry for the trouble this has caused.
>>>>>>
>>>>>> How is this handled in the Linux kernel and/or why doesn't it fail
>>>>>> there?
>>>>>
>>>>> On the latest net-next, it's handled the same: disable everything and
>>>>> enable only what's specified in phy-mode. I didn't keep track of older
>>>>> versions.
>>>>
>>>> So you would expect the network to be broken on net-next with this DTS?
>>>> Because that's not allowed...
>>>>
>>>
>>> Yes, if it's the same problem, the behavior should be the same.
>>> I see net-next is only rejecting the bad DT since 2019-02-21:
>>> https://patchwork.kernel.org/patch/10819279/
>>> So it depends when you checked it last time.
>>
>> I'll see about testing eth in Linux with net-next tomorrow, but, uh, is
>> there some work-around for the DTS so that ethernet works?
>
> Work-around in Linux or in U-boot?
> U-boot can fix up the DT for Linux and replace "rgmii-txid" with
> "rgmii-id", whereas neither Linux nor U-boot can do anything for
> themselves except either load a correct DT blob, or not use (revert, not
> upgrade to, etc) the enforcing patch.
>
>> You cannot break existing DTs
> RGMII delay breakages happen all the time. To play the devil's advocate,
> protecting against them should be done by observing the semantics
> described in the devicetree/bindings document.
> If you follow Linux net-next, a breakage for RTL8211F is planned out
> right as we speak.
>
> But let's wait until we know for sure that this is what's causing the
> issues.
>
> Regards,
> -Vladimir
>
Hi Tom,
I understand now what you mean by "workaround".
Yes you can enable RGMII delays by hand in U-boot:
Check if RX delay is enabled (bit 15 of debug register 0):
=> mdio write eTSEC1 0x1D 0
=> mdio read eTSEC1 0x1E
=> mdio write eTSEC1 0x1E <new value>
Check if TX delay is enabled (bit 8 of debug register 5):
=> mdio write eTSEC1 0x1D 5
=> mdio read eTSEC1 0x1E
=> mdio write eTSEC1 0x1E <new value>
Replace eTSEC1 with your net device from "mdio list".
Regards,
-Vladimir
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-05-09 12:51 ` Vladimir Oltean
@ 2019-05-10 21:50 ` Joe Hershberger
2019-05-15 14:58 ` Tom Rini
0 siblings, 1 reply; 21+ messages in thread
From: Joe Hershberger @ 2019-05-10 21:50 UTC (permalink / raw
To: u-boot
Hi Vladimir and Tom,
On Thu, May 9, 2019 at 7:51 AM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
>
> On 09.05.2019 02:05, Vladimir Oltean wrote:
> > On 5/9/19 1:55 AM, Tom Rini wrote:
> >> On Wed, May 08, 2019 at 10:52:28PM +0000, Vladimir Oltean wrote:
> >>> On 5/9/19 1:48 AM, Tom Rini wrote:
> >>>> On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
> >>>>> On 5/9/19 1:42 AM, Tom Rini wrote:
> >>>>>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
> >>>>>>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
> >>>>>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
> >>>>>>>>>
> >>>>>>>>> Hi Tom,
> >>>>>>>>>
> >>>>>>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
> >>>>>>>>>
> >>>>>>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
> >>>>>>>>> MLO also now fits again.
> >>>>>>>>>
> >>>>>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
> >>>>>>>>>
> >>>>>>>>> are available in the git repository at:
> >>>>>>>>>
> >>>>>>>>> git://git.denx.de/u-boot-net.git master
> >>>>>>>>>
> >>>>>>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
> >>>>>>>>>
> >>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
> >>>>>>>>>
> >>>>>>>>> ----------------------------------------------------------------
> >>>>>>>>> Carlo Caione (4):
> >>>>>>>>> net: phy: Add generic helpers to access MMD PHY registers
> >>>>>>>>> net: phy: ti: use generic helpers to access MMD registers
> >>>>>>>>> cmd: mdio: Switch to generic helpers when accessing the registers
> >>>>>>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
> >>>>>>>>>
> >>>>>>>>> James Byrne (2):
> >>>>>>>>> net: phy: micrel: Use correct skew values on KSZ9021
> >>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly
> >>>>>>>>>
> >>>>>>>>> Murali Karicheri (2):
> >>>>>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
> >>>>>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
> >>>>>>>>>
> >>>>>>>>> Pankaj Bansal (1):
> >>>>>>>>> drivers: net: ldpaa_eth: fix resource leak
> >>>>>>>>>
> >>>>>>>>> Siva Durga Prasad Paladugu (2):
> >>>>>>>>> net: phy: Reloc next and prev pointers inside phy_drivers
> >>>>>>>>> net: phy: Fix return value check phy_probe
> >>>>>>>>>
> >>>>>>>>> Valentin-catalin Neacsu (1):
> >>>>>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
> >>>>>>>>>
> >>>>>>>>> Vladimir Oltean (6):
> >>>>>>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
> >>>>>>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
> >>>>>>>>> net: phy: ar803x: Use common functions for RGMII internal delays
> >>>>>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
> >>>>>>>>> net: phy: ar803x: Explicitly disable RGMII delays
> >>>>>>>>
> >>>>>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
> >>>>>>>> BB Black because it uses an SMSC phy, where as this evm uses an
> >>>>>>>> AR8031/AR8033.
> >>>>>>>>
> >>>>>>>> Is it possible the device tree [2] is wrong for the board? It lists
> >>>>>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
> >>>>>>>> delay is now being disabled.
> >>>>>>>>
> >>>>>>>> Any thoughts, Vladimir?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> -Joe
> >>>>>>>>
> >>>>>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
> >>>>>>>> [2] arch/arm/dts/am335x-evm.dts
> >>>>>>>>
> >>>>>>>>> net: phy: ar803x: Clarify the intention of ar8021_config
> >>>>>>>>>
> >>>>>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
> >>>>>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
> >>>>>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
> >>>>>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
> >>>>>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
> >>>>>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
> >>>>>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
> >>>>>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
> >>>>>>>>> cmd/mdio.c | 27 +++--
> >>>>>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
> >>>>>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
> >>>>>>>>> drivers/net/phy/Kconfig | 41 ++++++++
> >>>>>>>>> drivers/net/phy/aquantia.c | 7 +-
> >>>>>>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
> >>>>>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
> >>>>>>>>> drivers/net/phy/phy.c | 21 +++-
> >>>>>>>>> drivers/net/phy/realtek.c | 19 ++++
> >>>>>>>>> drivers/net/phy/ti.c | 130 +++++-------------------
> >>>>>>>>> include/phy.h | 70 +++++++++++++
> >>>>>>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
> >>>>>>>>>
> >>>>>>>>> Thanks!
> >>>>>>>>> -Joe
> >>>>>>>>> _______________________________________________
> >>>>>>>>> U-Boot mailing list
> >>>>>>>>> U-Boot at lists.denx.de
> >>>>>>>>> https://lists.denx.de/listinfo/u-boot
> >>>>>>>>
> >>>>>>>
> >>>>>>> Hi Joe, Tom,
> >>>>>>>
> >>>>>>> It sounds like what Joe pointed to (my patch) has a high chance of
> >>>>>>> causing link failure.
> >>>>>>> If the board is relying on RX delays in the Atheros PHY to ensure
> >>>>>>> correct RGMII timing budget, then for sure it was working before and now
> >>>>>>> it is broken. In that case, it was working by mistake; the DT blob is
> >>>>>>> broken and should be corrected.
> >>>>>>> Sorry for the trouble this has caused.
> >>>>>>
> >>>>>> How is this handled in the Linux kernel and/or why doesn't it fail
> >>>>>> there?
> >>>>>
> >>>>> On the latest net-next, it's handled the same: disable everything and
> >>>>> enable only what's specified in phy-mode. I didn't keep track of older
> >>>>> versions.
> >>>>
> >>>> So you would expect the network to be broken on net-next with this DTS?
> >>>> Because that's not allowed...
> >>>>
> >>>
> >>> Yes, if it's the same problem, the behavior should be the same.
> >>> I see net-next is only rejecting the bad DT since 2019-02-21:
> >>> https://patchwork.kernel.org/patch/10819279/
> >>> So it depends when you checked it last time.
> >>
> >> I'll see about testing eth in Linux with net-next tomorrow, but, uh, is
> >> there some work-around for the DTS so that ethernet works?
> >
> > Work-around in Linux or in U-boot?
> > U-boot can fix up the DT for Linux and replace "rgmii-txid" with
> > "rgmii-id", whereas neither Linux nor U-boot can do anything for
> > themselves except either load a correct DT blob, or not use (revert, not
> > upgrade to, etc) the enforcing patch.
> >
> >> You cannot break existing DTs
> > RGMII delay breakages happen all the time. To play the devil's advocate,
> > protecting against them should be done by observing the semantics
> > described in the devicetree/bindings document.
> > If you follow Linux net-next, a breakage for RTL8211F is planned out
> > right as we speak.
> >
> > But let's wait until we know for sure that this is what's causing the
> > issues.
> >
> > Regards,
> > -Vladimir
> >
>
> Hi Tom,
>
> I understand now what you mean by "workaround".
> Yes you can enable RGMII delays by hand in U-boot:
>
> Check if RX delay is enabled (bit 15 of debug register 0):
> => mdio write eTSEC1 0x1D 0
> => mdio read eTSEC1 0x1E
> => mdio write eTSEC1 0x1E <new value>
>
> Check if TX delay is enabled (bit 8 of debug register 5):
> => mdio write eTSEC1 0x1D 5
> => mdio read eTSEC1 0x1E
> => mdio write eTSEC1 0x1E <new value>
>
> Replace eTSEC1 with your net device from "mdio list".
I'm not sure what the follow-on action is here. I'll hold off on
Vladimir's series until there is a resolution that everyone is
satisfied with.
Cheers,
-Joe
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-05-10 21:50 ` Joe Hershberger
@ 2019-05-15 14:58 ` Tom Rini
2019-07-25 22:40 ` Vladimir Oltean
2019-11-02 13:17 ` Michael Walle
0 siblings, 2 replies; 21+ messages in thread
From: Tom Rini @ 2019-05-15 14:58 UTC (permalink / raw
To: u-boot
On Fri, May 10, 2019 at 09:50:45PM +0000, Joe Hershberger wrote:
> Hi Vladimir and Tom,
>
> On Thu, May 9, 2019 at 7:51 AM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> >
> > On 09.05.2019 02:05, Vladimir Oltean wrote:
> > > On 5/9/19 1:55 AM, Tom Rini wrote:
> > >> On Wed, May 08, 2019 at 10:52:28PM +0000, Vladimir Oltean wrote:
> > >>> On 5/9/19 1:48 AM, Tom Rini wrote:
> > >>>> On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
> > >>>>> On 5/9/19 1:42 AM, Tom Rini wrote:
> > >>>>>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
> > >>>>>>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
> > >>>>>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
> > >>>>>>>>>
> > >>>>>>>>> Hi Tom,
> > >>>>>>>>>
> > >>>>>>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
> > >>>>>>>>>
> > >>>>>>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
> > >>>>>>>>> MLO also now fits again.
> > >>>>>>>>>
> > >>>>>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
> > >>>>>>>>>
> > >>>>>>>>> are available in the git repository at:
> > >>>>>>>>>
> > >>>>>>>>> git://git.denx.de/u-boot-net.git master
> > >>>>>>>>>
> > >>>>>>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
> > >>>>>>>>>
> > >>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
> > >>>>>>>>>
> > >>>>>>>>> ----------------------------------------------------------------
> > >>>>>>>>> Carlo Caione (4):
> > >>>>>>>>> net: phy: Add generic helpers to access MMD PHY registers
> > >>>>>>>>> net: phy: ti: use generic helpers to access MMD registers
> > >>>>>>>>> cmd: mdio: Switch to generic helpers when accessing the registers
> > >>>>>>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
> > >>>>>>>>>
> > >>>>>>>>> James Byrne (2):
> > >>>>>>>>> net: phy: micrel: Use correct skew values on KSZ9021
> > >>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly
> > >>>>>>>>>
> > >>>>>>>>> Murali Karicheri (2):
> > >>>>>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
> > >>>>>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
> > >>>>>>>>>
> > >>>>>>>>> Pankaj Bansal (1):
> > >>>>>>>>> drivers: net: ldpaa_eth: fix resource leak
> > >>>>>>>>>
> > >>>>>>>>> Siva Durga Prasad Paladugu (2):
> > >>>>>>>>> net: phy: Reloc next and prev pointers inside phy_drivers
> > >>>>>>>>> net: phy: Fix return value check phy_probe
> > >>>>>>>>>
> > >>>>>>>>> Valentin-catalin Neacsu (1):
> > >>>>>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
> > >>>>>>>>>
> > >>>>>>>>> Vladimir Oltean (6):
> > >>>>>>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
> > >>>>>>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
> > >>>>>>>>> net: phy: ar803x: Use common functions for RGMII internal delays
> > >>>>>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
> > >>>>>>>>> net: phy: ar803x: Explicitly disable RGMII delays
> > >>>>>>>>
> > >>>>>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
> > >>>>>>>> BB Black because it uses an SMSC phy, where as this evm uses an
> > >>>>>>>> AR8031/AR8033.
> > >>>>>>>>
> > >>>>>>>> Is it possible the device tree [2] is wrong for the board? It lists
> > >>>>>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
> > >>>>>>>> delay is now being disabled.
> > >>>>>>>>
> > >>>>>>>> Any thoughts, Vladimir?
> > >>>>>>>>
> > >>>>>>>> Thanks,
> > >>>>>>>> -Joe
> > >>>>>>>>
> > >>>>>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
> > >>>>>>>> [2] arch/arm/dts/am335x-evm.dts
> > >>>>>>>>
> > >>>>>>>>> net: phy: ar803x: Clarify the intention of ar8021_config
> > >>>>>>>>>
> > >>>>>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
> > >>>>>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
> > >>>>>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
> > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
> > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
> > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
> > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
> > >>>>>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
> > >>>>>>>>> cmd/mdio.c | 27 +++--
> > >>>>>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
> > >>>>>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
> > >>>>>>>>> drivers/net/phy/Kconfig | 41 ++++++++
> > >>>>>>>>> drivers/net/phy/aquantia.c | 7 +-
> > >>>>>>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
> > >>>>>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
> > >>>>>>>>> drivers/net/phy/phy.c | 21 +++-
> > >>>>>>>>> drivers/net/phy/realtek.c | 19 ++++
> > >>>>>>>>> drivers/net/phy/ti.c | 130 +++++-------------------
> > >>>>>>>>> include/phy.h | 70 +++++++++++++
> > >>>>>>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
> > >>>>>>>>>
> > >>>>>>>>> Thanks!
> > >>>>>>>>> -Joe
> > >>>>>>>>> _______________________________________________
> > >>>>>>>>> U-Boot mailing list
> > >>>>>>>>> U-Boot at lists.denx.de
> > >>>>>>>>> https://lists.denx.de/listinfo/u-boot
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> Hi Joe, Tom,
> > >>>>>>>
> > >>>>>>> It sounds like what Joe pointed to (my patch) has a high chance of
> > >>>>>>> causing link failure.
> > >>>>>>> If the board is relying on RX delays in the Atheros PHY to ensure
> > >>>>>>> correct RGMII timing budget, then for sure it was working before and now
> > >>>>>>> it is broken. In that case, it was working by mistake; the DT blob is
> > >>>>>>> broken and should be corrected.
> > >>>>>>> Sorry for the trouble this has caused.
> > >>>>>>
> > >>>>>> How is this handled in the Linux kernel and/or why doesn't it fail
> > >>>>>> there?
> > >>>>>
> > >>>>> On the latest net-next, it's handled the same: disable everything and
> > >>>>> enable only what's specified in phy-mode. I didn't keep track of older
> > >>>>> versions.
> > >>>>
> > >>>> So you would expect the network to be broken on net-next with this DTS?
> > >>>> Because that's not allowed...
> > >>>>
> > >>>
> > >>> Yes, if it's the same problem, the behavior should be the same.
> > >>> I see net-next is only rejecting the bad DT since 2019-02-21:
> > >>> https://patchwork.kernel.org/patch/10819279/
> > >>> So it depends when you checked it last time.
> > >>
> > >> I'll see about testing eth in Linux with net-next tomorrow, but, uh, is
> > >> there some work-around for the DTS so that ethernet works?
> > >
> > > Work-around in Linux or in U-boot?
> > > U-boot can fix up the DT for Linux and replace "rgmii-txid" with
> > > "rgmii-id", whereas neither Linux nor U-boot can do anything for
> > > themselves except either load a correct DT blob, or not use (revert, not
> > > upgrade to, etc) the enforcing patch.
> > >
> > >> You cannot break existing DTs
> > > RGMII delay breakages happen all the time. To play the devil's advocate,
> > > protecting against them should be done by observing the semantics
> > > described in the devicetree/bindings document.
> > > If you follow Linux net-next, a breakage for RTL8211F is planned out
> > > right as we speak.
> > >
> > > But let's wait until we know for sure that this is what's causing the
> > > issues.
> > >
> > > Regards,
> > > -Vladimir
> > >
> >
> > Hi Tom,
> >
> > I understand now what you mean by "workaround".
> > Yes you can enable RGMII delays by hand in U-boot:
> >
> > Check if RX delay is enabled (bit 15 of debug register 0):
> > => mdio write eTSEC1 0x1D 0
> > => mdio read eTSEC1 0x1E
> > => mdio write eTSEC1 0x1E <new value>
> >
> > Check if TX delay is enabled (bit 8 of debug register 5):
> > => mdio write eTSEC1 0x1D 5
> > => mdio read eTSEC1 0x1E
> > => mdio write eTSEC1 0x1E <new value>
> >
> > Replace eTSEC1 with your net device from "mdio list".
>
> I'm not sure what the follow-on action is here. I'll hold off on
> Vladimir's series until there is a resolution that everyone is
> satisfied with.
While I personally think this breaks the "DT is ABI" model, the required
change has already been merged into Linus' tree so we just need to
re-sync the am335x DTS files again and then we can apply these changes.
I'll put it on my TODO list.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190515/188c38a1/attachment.sig>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-05-15 14:58 ` Tom Rini
@ 2019-07-25 22:40 ` Vladimir Oltean
2019-07-25 23:12 ` Tom Rini
2019-11-02 13:17 ` Michael Walle
1 sibling, 1 reply; 21+ messages in thread
From: Vladimir Oltean @ 2019-07-25 22:40 UTC (permalink / raw
To: u-boot
On 5/15/19 5:58 PM, Tom Rini wrote:
> On Fri, May 10, 2019 at 09:50:45PM +0000, Joe Hershberger wrote:
>> Hi Vladimir and Tom,
>>
>> On Thu, May 9, 2019 at 7:51 AM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
>>>
>>> On 09.05.2019 02:05, Vladimir Oltean wrote:
>>>> On 5/9/19 1:55 AM, Tom Rini wrote:
>>>>> On Wed, May 08, 2019 at 10:52:28PM +0000, Vladimir Oltean wrote:
>>>>>> On 5/9/19 1:48 AM, Tom Rini wrote:
>>>>>>> On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
>>>>>>>> On 5/9/19 1:42 AM, Tom Rini wrote:
>>>>>>>>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
>>>>>>>>>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
>>>>>>>>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Tom,
>>>>>>>>>>>>
>>>>>>>>>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
>>>>>>>>>>>>
>>>>>>>>>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
>>>>>>>>>>>> MLO also now fits again.
>>>>>>>>>>>>
>>>>>>>>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
>>>>>>>>>>>>
>>>>>>>>>>>> are available in the git repository at:
>>>>>>>>>>>>
>>>>>>>>>>>> git://git.denx.de/u-boot-net.git master
>>>>>>>>>>>>
>>>>>>>>>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
>>>>>>>>>>>>
>>>>>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
>>>>>>>>>>>>
>>>>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>>>>> Carlo Caione (4):
>>>>>>>>>>>> net: phy: Add generic helpers to access MMD PHY registers
>>>>>>>>>>>> net: phy: ti: use generic helpers to access MMD registers
>>>>>>>>>>>> cmd: mdio: Switch to generic helpers when accessing the registers
>>>>>>>>>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
>>>>>>>>>>>>
>>>>>>>>>>>> James Byrne (2):
>>>>>>>>>>>> net: phy: micrel: Use correct skew values on KSZ9021
>>>>>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly
>>>>>>>>>>>>
>>>>>>>>>>>> Murali Karicheri (2):
>>>>>>>>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
>>>>>>>>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
>>>>>>>>>>>>
>>>>>>>>>>>> Pankaj Bansal (1):
>>>>>>>>>>>> drivers: net: ldpaa_eth: fix resource leak
>>>>>>>>>>>>
>>>>>>>>>>>> Siva Durga Prasad Paladugu (2):
>>>>>>>>>>>> net: phy: Reloc next and prev pointers inside phy_drivers
>>>>>>>>>>>> net: phy: Fix return value check phy_probe
>>>>>>>>>>>>
>>>>>>>>>>>> Valentin-catalin Neacsu (1):
>>>>>>>>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
>>>>>>>>>>>>
>>>>>>>>>>>> Vladimir Oltean (6):
>>>>>>>>>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
>>>>>>>>>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
>>>>>>>>>>>> net: phy: ar803x: Use common functions for RGMII internal delays
>>>>>>>>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
>>>>>>>>>>>> net: phy: ar803x: Explicitly disable RGMII delays
>>>>>>>>>>>
>>>>>>>>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
>>>>>>>>>>> BB Black because it uses an SMSC phy, where as this evm uses an
>>>>>>>>>>> AR8031/AR8033.
>>>>>>>>>>>
>>>>>>>>>>> Is it possible the device tree [2] is wrong for the board? It lists
>>>>>>>>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
>>>>>>>>>>> delay is now being disabled.
>>>>>>>>>>>
>>>>>>>>>>> Any thoughts, Vladimir?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> -Joe
>>>>>>>>>>>
>>>>>>>>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
>>>>>>>>>>> [2] arch/arm/dts/am335x-evm.dts
>>>>>>>>>>>
>>>>>>>>>>>> net: phy: ar803x: Clarify the intention of ar8021_config
>>>>>>>>>>>>
>>>>>>>>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
>>>>>>>>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
>>>>>>>>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
>>>>>>>>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
>>>>>>>>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
>>>>>>>>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
>>>>>>>>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
>>>>>>>>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
>>>>>>>>>>>> cmd/mdio.c | 27 +++--
>>>>>>>>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
>>>>>>>>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
>>>>>>>>>>>> drivers/net/phy/Kconfig | 41 ++++++++
>>>>>>>>>>>> drivers/net/phy/aquantia.c | 7 +-
>>>>>>>>>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
>>>>>>>>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
>>>>>>>>>>>> drivers/net/phy/phy.c | 21 +++-
>>>>>>>>>>>> drivers/net/phy/realtek.c | 19 ++++
>>>>>>>>>>>> drivers/net/phy/ti.c | 130 +++++-------------------
>>>>>>>>>>>> include/phy.h | 70 +++++++++++++
>>>>>>>>>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>> -Joe
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> U-Boot mailing list
>>>>>>>>>>>> U-Boot at lists.denx.de
>>>>>>>>>>>> https://lists.denx.de/listinfo/u-boot
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Joe, Tom,
>>>>>>>>>>
>>>>>>>>>> It sounds like what Joe pointed to (my patch) has a high chance of
>>>>>>>>>> causing link failure.
>>>>>>>>>> If the board is relying on RX delays in the Atheros PHY to ensure
>>>>>>>>>> correct RGMII timing budget, then for sure it was working before and now
>>>>>>>>>> it is broken. In that case, it was working by mistake; the DT blob is
>>>>>>>>>> broken and should be corrected.
>>>>>>>>>> Sorry for the trouble this has caused.
>>>>>>>>>
>>>>>>>>> How is this handled in the Linux kernel and/or why doesn't it fail
>>>>>>>>> there?
>>>>>>>>
>>>>>>>> On the latest net-next, it's handled the same: disable everything and
>>>>>>>> enable only what's specified in phy-mode. I didn't keep track of older
>>>>>>>> versions.
>>>>>>>
>>>>>>> So you would expect the network to be broken on net-next with this DTS?
>>>>>>> Because that's not allowed...
>>>>>>>
>>>>>>
>>>>>> Yes, if it's the same problem, the behavior should be the same.
>>>>>> I see net-next is only rejecting the bad DT since 2019-02-21:
>>>>>> https://patchwork.kernel.org/patch/10819279/
>>>>>> So it depends when you checked it last time.
>>>>>
>>>>> I'll see about testing eth in Linux with net-next tomorrow, but, uh, is
>>>>> there some work-around for the DTS so that ethernet works?
>>>>
>>>> Work-around in Linux or in U-boot?
>>>> U-boot can fix up the DT for Linux and replace "rgmii-txid" with
>>>> "rgmii-id", whereas neither Linux nor U-boot can do anything for
>>>> themselves except either load a correct DT blob, or not use (revert, not
>>>> upgrade to, etc) the enforcing patch.
>>>>
>>>>> You cannot break existing DTs
>>>> RGMII delay breakages happen all the time. To play the devil's advocate,
>>>> protecting against them should be done by observing the semantics
>>>> described in the devicetree/bindings document.
>>>> If you follow Linux net-next, a breakage for RTL8211F is planned out
>>>> right as we speak.
>>>>
>>>> But let's wait until we know for sure that this is what's causing the
>>>> issues.
>>>>
>>>> Regards,
>>>> -Vladimir
>>>>
>>>
>>> Hi Tom,
>>>
>>> I understand now what you mean by "workaround".
>>> Yes you can enable RGMII delays by hand in U-boot:
>>>
>>> Check if RX delay is enabled (bit 15 of debug register 0):
>>> => mdio write eTSEC1 0x1D 0
>>> => mdio read eTSEC1 0x1E
>>> => mdio write eTSEC1 0x1E <new value>
>>>
>>> Check if TX delay is enabled (bit 8 of debug register 5):
>>> => mdio write eTSEC1 0x1D 5
>>> => mdio read eTSEC1 0x1E
>>> => mdio write eTSEC1 0x1E <new value>
>>>
>>> Replace eTSEC1 with your net device from "mdio list".
>>
>> I'm not sure what the follow-on action is here. I'll hold off on
>> Vladimir's series until there is a resolution that everyone is
>> satisfied with.
>
> While I personally think this breaks the "DT is ABI" model, the required
> change has already been merged into Linus' tree so we just need to
> re-sync the am335x DTS files again and then we can apply these changes.
> I'll put it on my TODO list.
>
Hi Tom, Joe,
It's been a long while - what is the latest news on RGMII delays for the
am335x + Atheros PHY? I'd like to know whether Joe can pick up these
patches again. As you more-or-less admitted, it's not really ABI
breakage if the DT semantics were never properly followed in the first
place.
Thanks,
-Vladimir
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-07-25 22:40 ` Vladimir Oltean
@ 2019-07-25 23:12 ` Tom Rini
0 siblings, 0 replies; 21+ messages in thread
From: Tom Rini @ 2019-07-25 23:12 UTC (permalink / raw
To: u-boot
On Thu, Jul 25, 2019 at 10:40:45PM +0000, Vladimir Oltean wrote:
> On 5/15/19 5:58 PM, Tom Rini wrote:
> > On Fri, May 10, 2019 at 09:50:45PM +0000, Joe Hershberger wrote:
> >> Hi Vladimir and Tom,
> >>
> >> On Thu, May 9, 2019 at 7:51 AM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> >>>
> >>> On 09.05.2019 02:05, Vladimir Oltean wrote:
> >>>> On 5/9/19 1:55 AM, Tom Rini wrote:
> >>>>> On Wed, May 08, 2019 at 10:52:28PM +0000, Vladimir Oltean wrote:
> >>>>>> On 5/9/19 1:48 AM, Tom Rini wrote:
> >>>>>>> On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
> >>>>>>>> On 5/9/19 1:42 AM, Tom Rini wrote:
> >>>>>>>>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
> >>>>>>>>>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
> >>>>>>>>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Tom,
> >>>>>>>>>>>>
> >>>>>>>>>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
> >>>>>>>>>>>>
> >>>>>>>>>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
> >>>>>>>>>>>> MLO also now fits again.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
> >>>>>>>>>>>>
> >>>>>>>>>>>> are available in the git repository at:
> >>>>>>>>>>>>
> >>>>>>>>>>>> git://git.denx.de/u-boot-net.git master
> >>>>>>>>>>>>
> >>>>>>>>>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
> >>>>>>>>>>>>
> >>>>>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
> >>>>>>>>>>>>
> >>>>>>>>>>>> ----------------------------------------------------------------
> >>>>>>>>>>>> Carlo Caione (4):
> >>>>>>>>>>>> net: phy: Add generic helpers to access MMD PHY registers
> >>>>>>>>>>>> net: phy: ti: use generic helpers to access MMD registers
> >>>>>>>>>>>> cmd: mdio: Switch to generic helpers when accessing the registers
> >>>>>>>>>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
> >>>>>>>>>>>>
> >>>>>>>>>>>> James Byrne (2):
> >>>>>>>>>>>> net: phy: micrel: Use correct skew values on KSZ9021
> >>>>>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly
> >>>>>>>>>>>>
> >>>>>>>>>>>> Murali Karicheri (2):
> >>>>>>>>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
> >>>>>>>>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
> >>>>>>>>>>>>
> >>>>>>>>>>>> Pankaj Bansal (1):
> >>>>>>>>>>>> drivers: net: ldpaa_eth: fix resource leak
> >>>>>>>>>>>>
> >>>>>>>>>>>> Siva Durga Prasad Paladugu (2):
> >>>>>>>>>>>> net: phy: Reloc next and prev pointers inside phy_drivers
> >>>>>>>>>>>> net: phy: Fix return value check phy_probe
> >>>>>>>>>>>>
> >>>>>>>>>>>> Valentin-catalin Neacsu (1):
> >>>>>>>>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
> >>>>>>>>>>>>
> >>>>>>>>>>>> Vladimir Oltean (6):
> >>>>>>>>>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
> >>>>>>>>>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
> >>>>>>>>>>>> net: phy: ar803x: Use common functions for RGMII internal delays
> >>>>>>>>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
> >>>>>>>>>>>> net: phy: ar803x: Explicitly disable RGMII delays
> >>>>>>>>>>>
> >>>>>>>>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
> >>>>>>>>>>> BB Black because it uses an SMSC phy, where as this evm uses an
> >>>>>>>>>>> AR8031/AR8033.
> >>>>>>>>>>>
> >>>>>>>>>>> Is it possible the device tree [2] is wrong for the board? It lists
> >>>>>>>>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
> >>>>>>>>>>> delay is now being disabled.
> >>>>>>>>>>>
> >>>>>>>>>>> Any thoughts, Vladimir?
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> -Joe
> >>>>>>>>>>>
> >>>>>>>>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
> >>>>>>>>>>> [2] arch/arm/dts/am335x-evm.dts
> >>>>>>>>>>>
> >>>>>>>>>>>> net: phy: ar803x: Clarify the intention of ar8021_config
> >>>>>>>>>>>>
> >>>>>>>>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
> >>>>>>>>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
> >>>>>>>>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
> >>>>>>>>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
> >>>>>>>>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
> >>>>>>>>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
> >>>>>>>>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
> >>>>>>>>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
> >>>>>>>>>>>> cmd/mdio.c | 27 +++--
> >>>>>>>>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
> >>>>>>>>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
> >>>>>>>>>>>> drivers/net/phy/Kconfig | 41 ++++++++
> >>>>>>>>>>>> drivers/net/phy/aquantia.c | 7 +-
> >>>>>>>>>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
> >>>>>>>>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
> >>>>>>>>>>>> drivers/net/phy/phy.c | 21 +++-
> >>>>>>>>>>>> drivers/net/phy/realtek.c | 19 ++++
> >>>>>>>>>>>> drivers/net/phy/ti.c | 130 +++++-------------------
> >>>>>>>>>>>> include/phy.h | 70 +++++++++++++
> >>>>>>>>>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks!
> >>>>>>>>>>>> -Joe
> >>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>> U-Boot mailing list
> >>>>>>>>>>>> U-Boot at lists.denx.de
> >>>>>>>>>>>> https://lists.denx.de/listinfo/u-boot
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Hi Joe, Tom,
> >>>>>>>>>>
> >>>>>>>>>> It sounds like what Joe pointed to (my patch) has a high chance of
> >>>>>>>>>> causing link failure.
> >>>>>>>>>> If the board is relying on RX delays in the Atheros PHY to ensure
> >>>>>>>>>> correct RGMII timing budget, then for sure it was working before and now
> >>>>>>>>>> it is broken. In that case, it was working by mistake; the DT blob is
> >>>>>>>>>> broken and should be corrected.
> >>>>>>>>>> Sorry for the trouble this has caused.
> >>>>>>>>>
> >>>>>>>>> How is this handled in the Linux kernel and/or why doesn't it fail
> >>>>>>>>> there?
> >>>>>>>>
> >>>>>>>> On the latest net-next, it's handled the same: disable everything and
> >>>>>>>> enable only what's specified in phy-mode. I didn't keep track of older
> >>>>>>>> versions.
> >>>>>>>
> >>>>>>> So you would expect the network to be broken on net-next with this DTS?
> >>>>>>> Because that's not allowed...
> >>>>>>>
> >>>>>>
> >>>>>> Yes, if it's the same problem, the behavior should be the same.
> >>>>>> I see net-next is only rejecting the bad DT since 2019-02-21:
> >>>>>> https://patchwork.kernel.org/patch/10819279/
> >>>>>> So it depends when you checked it last time.
> >>>>>
> >>>>> I'll see about testing eth in Linux with net-next tomorrow, but, uh, is
> >>>>> there some work-around for the DTS so that ethernet works?
> >>>>
> >>>> Work-around in Linux or in U-boot?
> >>>> U-boot can fix up the DT for Linux and replace "rgmii-txid" with
> >>>> "rgmii-id", whereas neither Linux nor U-boot can do anything for
> >>>> themselves except either load a correct DT blob, or not use (revert, not
> >>>> upgrade to, etc) the enforcing patch.
> >>>>
> >>>>> You cannot break existing DTs
> >>>> RGMII delay breakages happen all the time. To play the devil's advocate,
> >>>> protecting against them should be done by observing the semantics
> >>>> described in the devicetree/bindings document.
> >>>> If you follow Linux net-next, a breakage for RTL8211F is planned out
> >>>> right as we speak.
> >>>>
> >>>> But let's wait until we know for sure that this is what's causing the
> >>>> issues.
> >>>>
> >>>> Regards,
> >>>> -Vladimir
> >>>>
> >>>
> >>> Hi Tom,
> >>>
> >>> I understand now what you mean by "workaround".
> >>> Yes you can enable RGMII delays by hand in U-boot:
> >>>
> >>> Check if RX delay is enabled (bit 15 of debug register 0):
> >>> => mdio write eTSEC1 0x1D 0
> >>> => mdio read eTSEC1 0x1E
> >>> => mdio write eTSEC1 0x1E <new value>
> >>>
> >>> Check if TX delay is enabled (bit 8 of debug register 5):
> >>> => mdio write eTSEC1 0x1D 5
> >>> => mdio read eTSEC1 0x1E
> >>> => mdio write eTSEC1 0x1E <new value>
> >>>
> >>> Replace eTSEC1 with your net device from "mdio list".
> >>
> >> I'm not sure what the follow-on action is here. I'll hold off on
> >> Vladimir's series until there is a resolution that everyone is
> >> satisfied with.
> >
> > While I personally think this breaks the "DT is ABI" model, the required
> > change has already been merged into Linus' tree so we just need to
> > re-sync the am335x DTS files again and then we can apply these changes.
> > I'll put it on my TODO list.
> >
>
> Hi Tom, Joe,
>
> It's been a long while - what is the latest news on RGMII delays for the
> am335x + Atheros PHY? I'd like to know whether Joe can pick up these
> patches again. As you more-or-less admitted, it's not really ABI
> breakage if the DT semantics were never properly followed in the first
> place.
It's ABI breakage that no one cared about. At this point, it's blocked
until the am335x DTS files get a resync from the kernel and that's
somewhere on my TODO list.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190725/2013d04d/attachment.sig>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-05-15 14:58 ` Tom Rini
2019-07-25 22:40 ` Vladimir Oltean
@ 2019-11-02 13:17 ` Michael Walle
2019-11-02 14:12 ` Tom Rini
1 sibling, 1 reply; 21+ messages in thread
From: Michael Walle @ 2019-11-02 13:17 UTC (permalink / raw
To: u-boot
Am 2019-05-15 16:58, schrieb Tom Rini:
> On Fri, May 10, 2019 at 09:50:45PM +0000, Joe Hershberger wrote:
>> Hi Vladimir and Tom,
>>
>> On Thu, May 9, 2019 at 7:51 AM Vladimir Oltean
>> <vladimir.oltean@nxp.com> wrote:
>> >
>> > On 09.05.2019 02:05, Vladimir Oltean wrote:
>> > > On 5/9/19 1:55 AM, Tom Rini wrote:
>> > >> On Wed, May 08, 2019 at 10:52:28PM +0000, Vladimir Oltean wrote:
>> > >>> On 5/9/19 1:48 AM, Tom Rini wrote:
>> > >>>> On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
>> > >>>>> On 5/9/19 1:42 AM, Tom Rini wrote:
>> > >>>>>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
>> > >>>>>>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
>> > >>>>>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
>> > >>>>>>>>>
>> > >>>>>>>>> Hi Tom,
>> > >>>>>>>>>
>> > >>>>>>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
>> > >>>>>>>>>
>> > >>>>>>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
>> > >>>>>>>>> MLO also now fits again.
>> > >>>>>>>>>
>> > >>>>>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
>> > >>>>>>>>>
>> > >>>>>>>>> are available in the git repository at:
>> > >>>>>>>>>
>> > >>>>>>>>> git://git.denx.de/u-boot-net.git master
>> > >>>>>>>>>
>> > >>>>>>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
>> > >>>>>>>>>
>> > >>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
>> > >>>>>>>>>
>> > >>>>>>>>> ----------------------------------------------------------------
>> > >>>>>>>>> Carlo Caione (4):
>> > >>>>>>>>> net: phy: Add generic helpers to access MMD PHY registers
>> > >>>>>>>>> net: phy: ti: use generic helpers to access MMD registers
>> > >>>>>>>>> cmd: mdio: Switch to generic helpers when accessing the registers
>> > >>>>>>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
>> > >>>>>>>>>
>> > >>>>>>>>> James Byrne (2):
>> > >>>>>>>>> net: phy: micrel: Use correct skew values on KSZ9021
>> > >>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly
>> > >>>>>>>>>
>> > >>>>>>>>> Murali Karicheri (2):
>> > >>>>>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
>> > >>>>>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
>> > >>>>>>>>>
>> > >>>>>>>>> Pankaj Bansal (1):
>> > >>>>>>>>> drivers: net: ldpaa_eth: fix resource leak
>> > >>>>>>>>>
>> > >>>>>>>>> Siva Durga Prasad Paladugu (2):
>> > >>>>>>>>> net: phy: Reloc next and prev pointers inside phy_drivers
>> > >>>>>>>>> net: phy: Fix return value check phy_probe
>> > >>>>>>>>>
>> > >>>>>>>>> Valentin-catalin Neacsu (1):
>> > >>>>>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
>> > >>>>>>>>>
>> > >>>>>>>>> Vladimir Oltean (6):
>> > >>>>>>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
>> > >>>>>>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
>> > >>>>>>>>> net: phy: ar803x: Use common functions for RGMII internal delays
>> > >>>>>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
>> > >>>>>>>>> net: phy: ar803x: Explicitly disable RGMII delays
>> > >>>>>>>>
>> > >>>>>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
>> > >>>>>>>> BB Black because it uses an SMSC phy, where as this evm uses an
>> > >>>>>>>> AR8031/AR8033.
>> > >>>>>>>>
>> > >>>>>>>> Is it possible the device tree [2] is wrong for the board? It lists
>> > >>>>>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
>> > >>>>>>>> delay is now being disabled.
>> > >>>>>>>>
>> > >>>>>>>> Any thoughts, Vladimir?
>> > >>>>>>>>
>> > >>>>>>>> Thanks,
>> > >>>>>>>> -Joe
>> > >>>>>>>>
>> > >>>>>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
>> > >>>>>>>> [2] arch/arm/dts/am335x-evm.dts
>> > >>>>>>>>
>> > >>>>>>>>> net: phy: ar803x: Clarify the intention of ar8021_config
>> > >>>>>>>>>
>> > >>>>>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
>> > >>>>>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
>> > >>>>>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
>> > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
>> > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
>> > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
>> > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
>> > >>>>>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
>> > >>>>>>>>> cmd/mdio.c | 27 +++--
>> > >>>>>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
>> > >>>>>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
>> > >>>>>>>>> drivers/net/phy/Kconfig | 41 ++++++++
>> > >>>>>>>>> drivers/net/phy/aquantia.c | 7 +-
>> > >>>>>>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
>> > >>>>>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
>> > >>>>>>>>> drivers/net/phy/phy.c | 21 +++-
>> > >>>>>>>>> drivers/net/phy/realtek.c | 19 ++++
>> > >>>>>>>>> drivers/net/phy/ti.c | 130 +++++-------------------
>> > >>>>>>>>> include/phy.h | 70 +++++++++++++
>> > >>>>>>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
>> > >>>>>>>>>
>> > >>>>>>>>> Thanks!
>> > >>>>>>>>> -Joe
>> > >>>>>>>>> _______________________________________________
>> > >>>>>>>>> U-Boot mailing list
>> > >>>>>>>>> U-Boot at lists.denx.de
>> > >>>>>>>>> https://lists.denx.de/listinfo/u-boot
>> > >>>>>>>>
>> > >>>>>>>
>> > >>>>>>> Hi Joe, Tom,
>> > >>>>>>>
>> > >>>>>>> It sounds like what Joe pointed to (my patch) has a high chance of
>> > >>>>>>> causing link failure.
>> > >>>>>>> If the board is relying on RX delays in the Atheros PHY to ensure
>> > >>>>>>> correct RGMII timing budget, then for sure it was working before and now
>> > >>>>>>> it is broken. In that case, it was working by mistake; the DT blob is
>> > >>>>>>> broken and should be corrected.
>> > >>>>>>> Sorry for the trouble this has caused.
>> > >>>>>>
>> > >>>>>> How is this handled in the Linux kernel and/or why doesn't it fail
>> > >>>>>> there?
>> > >>>>>
>> > >>>>> On the latest net-next, it's handled the same: disable everything and
>> > >>>>> enable only what's specified in phy-mode. I didn't keep track of older
>> > >>>>> versions.
>> > >>>>
>> > >>>> So you would expect the network to be broken on net-next with this DTS?
>> > >>>> Because that's not allowed...
>> > >>>>
>> > >>>
>> > >>> Yes, if it's the same problem, the behavior should be the same.
>> > >>> I see net-next is only rejecting the bad DT since 2019-02-21:
>> > >>> https://patchwork.kernel.org/patch/10819279/
>> > >>> So it depends when you checked it last time.
>> > >>
>> > >> I'll see about testing eth in Linux with net-next tomorrow, but, uh, is
>> > >> there some work-around for the DTS so that ethernet works?
>> > >
>> > > Work-around in Linux or in U-boot?
>> > > U-boot can fix up the DT for Linux and replace "rgmii-txid" with
>> > > "rgmii-id", whereas neither Linux nor U-boot can do anything for
>> > > themselves except either load a correct DT blob, or not use (revert, not
>> > > upgrade to, etc) the enforcing patch.
>> > >
>> > >> You cannot break existing DTs
>> > > RGMII delay breakages happen all the time. To play the devil's advocate,
>> > > protecting against them should be done by observing the semantics
>> > > described in the devicetree/bindings document.
>> > > If you follow Linux net-next, a breakage for RTL8211F is planned out
>> > > right as we speak.
>> > >
>> > > But let's wait until we know for sure that this is what's causing the
>> > > issues.
>> > >
>> > > Regards,
>> > > -Vladimir
>> > >
>> >
>> > Hi Tom,
>> >
>> > I understand now what you mean by "workaround".
>> > Yes you can enable RGMII delays by hand in U-boot:
>> >
>> > Check if RX delay is enabled (bit 15 of debug register 0):
>> > => mdio write eTSEC1 0x1D 0
>> > => mdio read eTSEC1 0x1E
>> > => mdio write eTSEC1 0x1E <new value>
>> >
>> > Check if TX delay is enabled (bit 8 of debug register 5):
>> > => mdio write eTSEC1 0x1D 5
>> > => mdio read eTSEC1 0x1E
>> > => mdio write eTSEC1 0x1E <new value>
>> >
>> > Replace eTSEC1 with your net device from "mdio list".
>>
>> I'm not sure what the follow-on action is here. I'll hold off on
>> Vladimir's series until there is a resolution that everyone is
>> satisfied with.
>
> While I personally think this breaks the "DT is ABI" model, the
> required
> change has already been merged into Linus' tree so we just need to
> re-sync the am335x DTS files again and then we can apply these changes.
> I'll put it on my TODO list.
Hi,
sorry for pulling up such an old thread. Are there any news on this?
Because I've had the same fix for the atheros PHYs posted to the u-boot
mailing list lately (without knowing anything about this thread).
So with that rule "don't break old (and very wrong!) DT blobs" we seem
not to be able to fix any serious errors. Because while it works for the
most cases eg. phy-mode = rgmii-id, it wont work (and cant be fixed!)
for rgmii-txid (or was it rxid? the one where the hardware default is
enabled).
I could also post my series without fixing that issue and just adding
clock support. But I'd rather see that fixed.
Thats just my two cents.
-michael
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-11-02 13:17 ` Michael Walle
@ 2019-11-02 14:12 ` Tom Rini
2019-11-02 14:30 ` Vladimir Oltean
0 siblings, 1 reply; 21+ messages in thread
From: Tom Rini @ 2019-11-02 14:12 UTC (permalink / raw
To: u-boot
On Sat, Nov 02, 2019 at 02:17:28PM +0100, Michael Walle wrote:
> Am 2019-05-15 16:58, schrieb Tom Rini:
> > On Fri, May 10, 2019 at 09:50:45PM +0000, Joe Hershberger wrote:
> > > Hi Vladimir and Tom,
> > >
> > > On Thu, May 9, 2019 at 7:51 AM Vladimir Oltean
> > > <vladimir.oltean@nxp.com> wrote:
> > > >
> > > > On 09.05.2019 02:05, Vladimir Oltean wrote:
> > > > > On 5/9/19 1:55 AM, Tom Rini wrote:
> > > > >> On Wed, May 08, 2019 at 10:52:28PM +0000, Vladimir Oltean wrote:
> > > > >>> On 5/9/19 1:48 AM, Tom Rini wrote:
> > > > >>>> On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
> > > > >>>>> On 5/9/19 1:42 AM, Tom Rini wrote:
> > > > >>>>>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
> > > > >>>>>>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
> > > > >>>>>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>> Hi Tom,
> > > > >>>>>>>>>
> > > > >>>>>>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
> > > > >>>>>>>>>
> > > > >>>>>>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
> > > > >>>>>>>>> MLO also now fits again.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
> > > > >>>>>>>>>
> > > > >>>>>>>>> are available in the git repository at:
> > > > >>>>>>>>>
> > > > >>>>>>>>> git://git.denx.de/u-boot-net.git master
> > > > >>>>>>>>>
> > > > >>>>>>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
> > > > >>>>>>>>>
> > > > >>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
> > > > >>>>>>>>>
> > > > >>>>>>>>> ----------------------------------------------------------------
> > > > >>>>>>>>> Carlo Caione (4):
> > > > >>>>>>>>> net: phy: Add generic helpers to access MMD PHY registers
> > > > >>>>>>>>> net: phy: ti: use generic helpers to access MMD registers
> > > > >>>>>>>>> cmd: mdio: Switch to generic helpers when accessing the registers
> > > > >>>>>>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
> > > > >>>>>>>>>
> > > > >>>>>>>>> James Byrne (2):
> > > > >>>>>>>>> net: phy: micrel: Use correct skew values on KSZ9021
> > > > >>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly
> > > > >>>>>>>>>
> > > > >>>>>>>>> Murali Karicheri (2):
> > > > >>>>>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
> > > > >>>>>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
> > > > >>>>>>>>>
> > > > >>>>>>>>> Pankaj Bansal (1):
> > > > >>>>>>>>> drivers: net: ldpaa_eth: fix resource leak
> > > > >>>>>>>>>
> > > > >>>>>>>>> Siva Durga Prasad Paladugu (2):
> > > > >>>>>>>>> net: phy: Reloc next and prev pointers inside phy_drivers
> > > > >>>>>>>>> net: phy: Fix return value check phy_probe
> > > > >>>>>>>>>
> > > > >>>>>>>>> Valentin-catalin Neacsu (1):
> > > > >>>>>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
> > > > >>>>>>>>>
> > > > >>>>>>>>> Vladimir Oltean (6):
> > > > >>>>>>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
> > > > >>>>>>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
> > > > >>>>>>>>> net: phy: ar803x: Use common functions for RGMII internal delays
> > > > >>>>>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
> > > > >>>>>>>>> net: phy: ar803x: Explicitly disable RGMII delays
> > > > >>>>>>>>
> > > > >>>>>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
> > > > >>>>>>>> BB Black because it uses an SMSC phy, where as this evm uses an
> > > > >>>>>>>> AR8031/AR8033.
> > > > >>>>>>>>
> > > > >>>>>>>> Is it possible the device tree [2] is wrong for the board? It lists
> > > > >>>>>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
> > > > >>>>>>>> delay is now being disabled.
> > > > >>>>>>>>
> > > > >>>>>>>> Any thoughts, Vladimir?
> > > > >>>>>>>>
> > > > >>>>>>>> Thanks,
> > > > >>>>>>>> -Joe
> > > > >>>>>>>>
> > > > >>>>>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
> > > > >>>>>>>> [2] arch/arm/dts/am335x-evm.dts
> > > > >>>>>>>>
> > > > >>>>>>>>> net: phy: ar803x: Clarify the intention of ar8021_config
> > > > >>>>>>>>>
> > > > >>>>>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
> > > > >>>>>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
> > > > >>>>>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
> > > > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
> > > > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
> > > > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
> > > > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
> > > > >>>>>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
> > > > >>>>>>>>> cmd/mdio.c | 27 +++--
> > > > >>>>>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
> > > > >>>>>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
> > > > >>>>>>>>> drivers/net/phy/Kconfig | 41 ++++++++
> > > > >>>>>>>>> drivers/net/phy/aquantia.c | 7 +-
> > > > >>>>>>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
> > > > >>>>>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
> > > > >>>>>>>>> drivers/net/phy/phy.c | 21 +++-
> > > > >>>>>>>>> drivers/net/phy/realtek.c | 19 ++++
> > > > >>>>>>>>> drivers/net/phy/ti.c | 130 +++++-------------------
> > > > >>>>>>>>> include/phy.h | 70 +++++++++++++
> > > > >>>>>>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
> > > > >>>>>>>>>
> > > > >>>>>>>>> Thanks!
> > > > >>>>>>>>> -Joe
> > > > >>>>>>>>> _______________________________________________
> > > > >>>>>>>>> U-Boot mailing list
> > > > >>>>>>>>> U-Boot at lists.denx.de
> > > > >>>>>>>>> https://lists.denx.de/listinfo/u-boot
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> Hi Joe, Tom,
> > > > >>>>>>>
> > > > >>>>>>> It sounds like what Joe pointed to (my patch) has a high chance of
> > > > >>>>>>> causing link failure.
> > > > >>>>>>> If the board is relying on RX delays in the Atheros PHY to ensure
> > > > >>>>>>> correct RGMII timing budget, then for sure it was working before and now
> > > > >>>>>>> it is broken. In that case, it was working by mistake; the DT blob is
> > > > >>>>>>> broken and should be corrected.
> > > > >>>>>>> Sorry for the trouble this has caused.
> > > > >>>>>>
> > > > >>>>>> How is this handled in the Linux kernel and/or why doesn't it fail
> > > > >>>>>> there?
> > > > >>>>>
> > > > >>>>> On the latest net-next, it's handled the same: disable everything and
> > > > >>>>> enable only what's specified in phy-mode. I didn't keep track of older
> > > > >>>>> versions.
> > > > >>>>
> > > > >>>> So you would expect the network to be broken on net-next with this DTS?
> > > > >>>> Because that's not allowed...
> > > > >>>>
> > > > >>>
> > > > >>> Yes, if it's the same problem, the behavior should be the same.
> > > > >>> I see net-next is only rejecting the bad DT since 2019-02-21:
> > > > >>> https://patchwork.kernel.org/patch/10819279/
> > > > >>> So it depends when you checked it last time.
> > > > >>
> > > > >> I'll see about testing eth in Linux with net-next tomorrow, but, uh, is
> > > > >> there some work-around for the DTS so that ethernet works?
> > > > >
> > > > > Work-around in Linux or in U-boot?
> > > > > U-boot can fix up the DT for Linux and replace "rgmii-txid" with
> > > > > "rgmii-id", whereas neither Linux nor U-boot can do anything for
> > > > > themselves except either load a correct DT blob, or not use (revert, not
> > > > > upgrade to, etc) the enforcing patch.
> > > > >
> > > > >> You cannot break existing DTs
> > > > > RGMII delay breakages happen all the time. To play the devil's advocate,
> > > > > protecting against them should be done by observing the semantics
> > > > > described in the devicetree/bindings document.
> > > > > If you follow Linux net-next, a breakage for RTL8211F is planned out
> > > > > right as we speak.
> > > > >
> > > > > But let's wait until we know for sure that this is what's causing the
> > > > > issues.
> > > > >
> > > > > Regards,
> > > > > -Vladimir
> > > > >
> > > >
> > > > Hi Tom,
> > > >
> > > > I understand now what you mean by "workaround".
> > > > Yes you can enable RGMII delays by hand in U-boot:
> > > >
> > > > Check if RX delay is enabled (bit 15 of debug register 0):
> > > > => mdio write eTSEC1 0x1D 0
> > > > => mdio read eTSEC1 0x1E
> > > > => mdio write eTSEC1 0x1E <new value>
> > > >
> > > > Check if TX delay is enabled (bit 8 of debug register 5):
> > > > => mdio write eTSEC1 0x1D 5
> > > > => mdio read eTSEC1 0x1E
> > > > => mdio write eTSEC1 0x1E <new value>
> > > >
> > > > Replace eTSEC1 with your net device from "mdio list".
> > >
> > > I'm not sure what the follow-on action is here. I'll hold off on
> > > Vladimir's series until there is a resolution that everyone is
> > > satisfied with.
> >
> > While I personally think this breaks the "DT is ABI" model, the required
> > change has already been merged into Linus' tree so we just need to
> > re-sync the am335x DTS files again and then we can apply these changes.
> > I'll put it on my TODO list.
>
> Hi,
>
> sorry for pulling up such an old thread. Are there any news on this? Because
> I've had the same fix for the atheros PHYs posted to the u-boot mailing list
> lately (without knowing anything about this thread).
>
> So with that rule "don't break old (and very wrong!) DT blobs" we seem not
> to be able to fix any serious errors. Because while it works for the most
> cases eg. phy-mode = rgmii-id, it wont work (and cant be fixed!) for
> rgmii-txid (or was it rxid? the one where the hardware default is enabled).
>
> I could also post my series without fixing that issue and just adding clock
> support. But I'd rather see that fixed.
So, there's patches to fix / keep cpsw working in U-Boot. So while I
believe that Linux broke the rule of "DT is ABI" I've also gone
(virtually) hoarse pointing this out to the people that were supposed to
care. So it's on my short list to grab the changes that are needed for
the TI platforms and we can grab all of the other changes as well.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191102/4abd329d/attachment.sig>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-11-02 14:12 ` Tom Rini
@ 2019-11-02 14:30 ` Vladimir Oltean
2019-11-02 15:05 ` Tom Rini
0 siblings, 1 reply; 21+ messages in thread
From: Vladimir Oltean @ 2019-11-02 14:30 UTC (permalink / raw
To: u-boot
On Sat, 2 Nov 2019 at 16:12, Tom Rini <trini@konsulko.com> wrote:
>
> On Sat, Nov 02, 2019 at 02:17:28PM +0100, Michael Walle wrote:
> > Am 2019-05-15 16:58, schrieb Tom Rini:
> > > On Fri, May 10, 2019 at 09:50:45PM +0000, Joe Hershberger wrote:
> > > > Hi Vladimir and Tom,
> > > >
> > > > On Thu, May 9, 2019 at 7:51 AM Vladimir Oltean
> > > > <vladimir.oltean@nxp.com> wrote:
> > > > >
> > > > > On 09.05.2019 02:05, Vladimir Oltean wrote:
> > > > > > On 5/9/19 1:55 AM, Tom Rini wrote:
> > > > > >> On Wed, May 08, 2019 at 10:52:28PM +0000, Vladimir Oltean wrote:
> > > > > >>> On 5/9/19 1:48 AM, Tom Rini wrote:
> > > > > >>>> On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
> > > > > >>>>> On 5/9/19 1:42 AM, Tom Rini wrote:
> > > > > >>>>>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
> > > > > >>>>>>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
> > > > > >>>>>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Hi Tom,
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
> > > > > >>>>>>>>> MLO also now fits again.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> are available in the git repository at:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> git://git.denx.de/u-boot-net.git master
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> ----------------------------------------------------------------
> > > > > >>>>>>>>> Carlo Caione (4):
> > > > > >>>>>>>>> net: phy: Add generic helpers to access MMD PHY registers
> > > > > >>>>>>>>> net: phy: ti: use generic helpers to access MMD registers
> > > > > >>>>>>>>> cmd: mdio: Switch to generic helpers when accessing the registers
> > > > > >>>>>>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> James Byrne (2):
> > > > > >>>>>>>>> net: phy: micrel: Use correct skew values on KSZ9021
> > > > > >>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Murali Karicheri (2):
> > > > > >>>>>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
> > > > > >>>>>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Pankaj Bansal (1):
> > > > > >>>>>>>>> drivers: net: ldpaa_eth: fix resource leak
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Siva Durga Prasad Paladugu (2):
> > > > > >>>>>>>>> net: phy: Reloc next and prev pointers inside phy_drivers
> > > > > >>>>>>>>> net: phy: Fix return value check phy_probe
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Valentin-catalin Neacsu (1):
> > > > > >>>>>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Vladimir Oltean (6):
> > > > > >>>>>>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
> > > > > >>>>>>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
> > > > > >>>>>>>>> net: phy: ar803x: Use common functions for RGMII internal delays
> > > > > >>>>>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
> > > > > >>>>>>>>> net: phy: ar803x: Explicitly disable RGMII delays
> > > > > >>>>>>>>
> > > > > >>>>>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
> > > > > >>>>>>>> BB Black because it uses an SMSC phy, where as this evm uses an
> > > > > >>>>>>>> AR8031/AR8033.
> > > > > >>>>>>>>
> > > > > >>>>>>>> Is it possible the device tree [2] is wrong for the board? It lists
> > > > > >>>>>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
> > > > > >>>>>>>> delay is now being disabled.
> > > > > >>>>>>>>
> > > > > >>>>>>>> Any thoughts, Vladimir?
> > > > > >>>>>>>>
> > > > > >>>>>>>> Thanks,
> > > > > >>>>>>>> -Joe
> > > > > >>>>>>>>
> > > > > >>>>>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
> > > > > >>>>>>>> [2] arch/arm/dts/am335x-evm.dts
> > > > > >>>>>>>>
> > > > > >>>>>>>>> net: phy: ar803x: Clarify the intention of ar8021_config
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
> > > > > >>>>>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
> > > > > >>>>>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
> > > > > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
> > > > > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
> > > > > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
> > > > > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
> > > > > >>>>>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
> > > > > >>>>>>>>> cmd/mdio.c | 27 +++--
> > > > > >>>>>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
> > > > > >>>>>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
> > > > > >>>>>>>>> drivers/net/phy/Kconfig | 41 ++++++++
> > > > > >>>>>>>>> drivers/net/phy/aquantia.c | 7 +-
> > > > > >>>>>>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
> > > > > >>>>>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
> > > > > >>>>>>>>> drivers/net/phy/phy.c | 21 +++-
> > > > > >>>>>>>>> drivers/net/phy/realtek.c | 19 ++++
> > > > > >>>>>>>>> drivers/net/phy/ti.c | 130 +++++-------------------
> > > > > >>>>>>>>> include/phy.h | 70 +++++++++++++
> > > > > >>>>>>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Thanks!
> > > > > >>>>>>>>> -Joe
> > > > > >>>>>>>>> _______________________________________________
> > > > > >>>>>>>>> U-Boot mailing list
> > > > > >>>>>>>>> U-Boot at lists.denx.de
> > > > > >>>>>>>>> https://lists.denx.de/listinfo/u-boot
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>> Hi Joe, Tom,
> > > > > >>>>>>>
> > > > > >>>>>>> It sounds like what Joe pointed to (my patch) has a high chance of
> > > > > >>>>>>> causing link failure.
> > > > > >>>>>>> If the board is relying on RX delays in the Atheros PHY to ensure
> > > > > >>>>>>> correct RGMII timing budget, then for sure it was working before and now
> > > > > >>>>>>> it is broken. In that case, it was working by mistake; the DT blob is
> > > > > >>>>>>> broken and should be corrected.
> > > > > >>>>>>> Sorry for the trouble this has caused.
> > > > > >>>>>>
> > > > > >>>>>> How is this handled in the Linux kernel and/or why doesn't it fail
> > > > > >>>>>> there?
> > > > > >>>>>
> > > > > >>>>> On the latest net-next, it's handled the same: disable everything and
> > > > > >>>>> enable only what's specified in phy-mode. I didn't keep track of older
> > > > > >>>>> versions.
> > > > > >>>>
> > > > > >>>> So you would expect the network to be broken on net-next with this DTS?
> > > > > >>>> Because that's not allowed...
> > > > > >>>>
> > > > > >>>
> > > > > >>> Yes, if it's the same problem, the behavior should be the same.
> > > > > >>> I see net-next is only rejecting the bad DT since 2019-02-21:
> > > > > >>> https://patchwork.kernel.org/patch/10819279/
> > > > > >>> So it depends when you checked it last time.
> > > > > >>
> > > > > >> I'll see about testing eth in Linux with net-next tomorrow, but, uh, is
> > > > > >> there some work-around for the DTS so that ethernet works?
> > > > > >
> > > > > > Work-around in Linux or in U-boot?
> > > > > > U-boot can fix up the DT for Linux and replace "rgmii-txid" with
> > > > > > "rgmii-id", whereas neither Linux nor U-boot can do anything for
> > > > > > themselves except either load a correct DT blob, or not use (revert, not
> > > > > > upgrade to, etc) the enforcing patch.
> > > > > >
> > > > > >> You cannot break existing DTs
> > > > > > RGMII delay breakages happen all the time. To play the devil's advocate,
> > > > > > protecting against them should be done by observing the semantics
> > > > > > described in the devicetree/bindings document.
> > > > > > If you follow Linux net-next, a breakage for RTL8211F is planned out
> > > > > > right as we speak.
> > > > > >
> > > > > > But let's wait until we know for sure that this is what's causing the
> > > > > > issues.
> > > > > >
> > > > > > Regards,
> > > > > > -Vladimir
> > > > > >
> > > > >
> > > > > Hi Tom,
> > > > >
> > > > > I understand now what you mean by "workaround".
> > > > > Yes you can enable RGMII delays by hand in U-boot:
> > > > >
> > > > > Check if RX delay is enabled (bit 15 of debug register 0):
> > > > > => mdio write eTSEC1 0x1D 0
> > > > > => mdio read eTSEC1 0x1E
> > > > > => mdio write eTSEC1 0x1E <new value>
> > > > >
> > > > > Check if TX delay is enabled (bit 8 of debug register 5):
> > > > > => mdio write eTSEC1 0x1D 5
> > > > > => mdio read eTSEC1 0x1E
> > > > > => mdio write eTSEC1 0x1E <new value>
> > > > >
> > > > > Replace eTSEC1 with your net device from "mdio list".
> > > >
> > > > I'm not sure what the follow-on action is here. I'll hold off on
> > > > Vladimir's series until there is a resolution that everyone is
> > > > satisfied with.
> > >
> > > While I personally think this breaks the "DT is ABI" model, the required
> > > change has already been merged into Linus' tree so we just need to
> > > re-sync the am335x DTS files again and then we can apply these changes.
> > > I'll put it on my TODO list.
> >
> > Hi,
> >
> > sorry for pulling up such an old thread. Are there any news on this? Because
> > I've had the same fix for the atheros PHYs posted to the u-boot mailing list
> > lately (without knowing anything about this thread).
> >
> > So with that rule "don't break old (and very wrong!) DT blobs" we seem not
> > to be able to fix any serious errors. Because while it works for the most
> > cases eg. phy-mode = rgmii-id, it wont work (and cant be fixed!) for
> > rgmii-txid (or was it rxid? the one where the hardware default is enabled).
> >
> > I could also post my series without fixing that issue and just adding clock
> > support. But I'd rather see that fixed.
>
> So, there's patches to fix / keep cpsw working in U-Boot. So while I
> believe that Linux broke the rule of "DT is ABI" I've also gone
> (virtually) hoarse pointing this out to the people that were supposed to
> care. So it's on my short list to grab the changes that are needed for
> the TI platforms and we can grab all of the other changes as well.
>
> --
Tom,
How come the people who proclaim that DT is ABI (which it is, nobody
is saying otherwise) are the same as (or do it in the name of) those
who don't follow it?
Had your boards been written with the correct phy-mode in the first
place, no breakage would have happened, and maybe the Atheros PHY
driver bugs would have been caught earlier.
I agree with Michael that interpreting the "DT is ABI" phrase as "be
compatible with past mistakes" (which are not in the ABI
specification, but in its interpretation, at that!) is only going to
lead to a cacophony of incoherent interpretations, which at some point
will become impossible to reconcile.
And for U-Boot, I guess the point is moot, since the DT blob is
typically packaged with the bootloader binary anyway.
> Tom
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
Thanks,
-Vladimir
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-11-02 14:30 ` Vladimir Oltean
@ 2019-11-02 15:05 ` Tom Rini
2019-11-03 15:22 ` Michael Walle
0 siblings, 1 reply; 21+ messages in thread
From: Tom Rini @ 2019-11-02 15:05 UTC (permalink / raw
To: u-boot
On Sat, Nov 02, 2019 at 04:30:11PM +0200, Vladimir Oltean wrote:
> On Sat, 2 Nov 2019 at 16:12, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sat, Nov 02, 2019 at 02:17:28PM +0100, Michael Walle wrote:
> > > Am 2019-05-15 16:58, schrieb Tom Rini:
> > > > On Fri, May 10, 2019 at 09:50:45PM +0000, Joe Hershberger wrote:
> > > > > Hi Vladimir and Tom,
> > > > >
> > > > > On Thu, May 9, 2019 at 7:51 AM Vladimir Oltean
> > > > > <vladimir.oltean@nxp.com> wrote:
> > > > > >
> > > > > > On 09.05.2019 02:05, Vladimir Oltean wrote:
> > > > > > > On 5/9/19 1:55 AM, Tom Rini wrote:
> > > > > > >> On Wed, May 08, 2019 at 10:52:28PM +0000, Vladimir Oltean wrote:
> > > > > > >>> On 5/9/19 1:48 AM, Tom Rini wrote:
> > > > > > >>>> On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote:
> > > > > > >>>>> On 5/9/19 1:42 AM, Tom Rini wrote:
> > > > > > >>>>>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote:
> > > > > > >>>>>>> On 5/9/19 1:24 AM, Joe Hershberger wrote:
> > > > > > >>>>>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger <joe.hershberger@ni.com> wrote:
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Hi Tom,
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> I rebased on your master and built for BB Black. DHCP seems to work fine.
> > > > > > >>>>>>>>> MLO also now fits again.
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400)
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> are available in the git repository at:
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> git://git.denx.de/u-boot-net.git master
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011:
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500)
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> ----------------------------------------------------------------
> > > > > > >>>>>>>>> Carlo Caione (4):
> > > > > > >>>>>>>>> net: phy: Add generic helpers to access MMD PHY registers
> > > > > > >>>>>>>>> net: phy: ti: use generic helpers to access MMD registers
> > > > > > >>>>>>>>> cmd: mdio: Switch to generic helpers when accessing the registers
> > > > > > >>>>>>>>> net: phy: realtek: Introduce quirk to mark RXC not stoppable
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> James Byrne (2):
> > > > > > >>>>>>>>> net: phy: micrel: Use correct skew values on KSZ9021
> > > > > > >>>>>>>>> net: phy: micrel: Find Micrel PHY node correctly
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Murali Karicheri (2):
> > > > > > >>>>>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration
> > > > > > >>>>>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Pankaj Bansal (1):
> > > > > > >>>>>>>>> drivers: net: ldpaa_eth: fix resource leak
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Siva Durga Prasad Paladugu (2):
> > > > > > >>>>>>>>> net: phy: Reloc next and prev pointers inside phy_drivers
> > > > > > >>>>>>>>> net: phy: Fix return value check phy_probe
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Valentin-catalin Neacsu (1):
> > > > > > >>>>>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Vladimir Oltean (6):
> > > > > > >>>>>>>>> net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
> > > > > > >>>>>>>>> net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
> > > > > > >>>>>>>>> net: phy: ar803x: Use common functions for RGMII internal delays
> > > > > > >>>>>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
> > > > > > >>>>>>>>> net: phy: ar803x: Explicitly disable RGMII delays
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect
> > > > > > >>>>>>>> BB Black because it uses an SMSC phy, where as this evm uses an
> > > > > > >>>>>>>> AR8031/AR8033.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Is it possible the device tree [2] is wrong for the board? It lists
> > > > > > >>>>>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX
> > > > > > >>>>>>>> delay is now being disabled.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Any thoughts, Vladimir?
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Thanks,
> > > > > > >>>>>>>> -Joe
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays"
> > > > > > >>>>>>>> [2] arch/arm/dts/am335x-evm.dts
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> net: phy: ar803x: Clarify the intention of ar8021_config
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++---
> > > > > > >>>>>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++---
> > > > > > >>>>>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +-
> > > > > > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +-
> > > > > > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +-
> > > > > > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +-
> > > > > > >>>>>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +-
> > > > > > >>>>>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++----
> > > > > > >>>>>>>>> cmd/mdio.c | 27 +++--
> > > > > > >>>>>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++
> > > > > > >>>>>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
> > > > > > >>>>>>>>> drivers/net/phy/Kconfig | 41 ++++++++
> > > > > > >>>>>>>>> drivers/net/phy/aquantia.c | 7 +-
> > > > > > >>>>>>>>> drivers/net/phy/atheros.c | 128 ++++++++++++++++-------
> > > > > > >>>>>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++-
> > > > > > >>>>>>>>> drivers/net/phy/phy.c | 21 +++-
> > > > > > >>>>>>>>> drivers/net/phy/realtek.c | 19 ++++
> > > > > > >>>>>>>>> drivers/net/phy/ti.c | 130 +++++-------------------
> > > > > > >>>>>>>>> include/phy.h | 70 +++++++++++++
> > > > > > >>>>>>>>> 19 files changed, 394 insertions(+), 221 deletions(-)
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Thanks!
> > > > > > >>>>>>>>> -Joe
> > > > > > >>>>>>>>> _______________________________________________
> > > > > > >>>>>>>>> U-Boot mailing list
> > > > > > >>>>>>>>> U-Boot at lists.denx.de
> > > > > > >>>>>>>>> https://lists.denx.de/listinfo/u-boot
> > > > > > >>>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>> Hi Joe, Tom,
> > > > > > >>>>>>>
> > > > > > >>>>>>> It sounds like what Joe pointed to (my patch) has a high chance of
> > > > > > >>>>>>> causing link failure.
> > > > > > >>>>>>> If the board is relying on RX delays in the Atheros PHY to ensure
> > > > > > >>>>>>> correct RGMII timing budget, then for sure it was working before and now
> > > > > > >>>>>>> it is broken. In that case, it was working by mistake; the DT blob is
> > > > > > >>>>>>> broken and should be corrected.
> > > > > > >>>>>>> Sorry for the trouble this has caused.
> > > > > > >>>>>>
> > > > > > >>>>>> How is this handled in the Linux kernel and/or why doesn't it fail
> > > > > > >>>>>> there?
> > > > > > >>>>>
> > > > > > >>>>> On the latest net-next, it's handled the same: disable everything and
> > > > > > >>>>> enable only what's specified in phy-mode. I didn't keep track of older
> > > > > > >>>>> versions.
> > > > > > >>>>
> > > > > > >>>> So you would expect the network to be broken on net-next with this DTS?
> > > > > > >>>> Because that's not allowed...
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>> Yes, if it's the same problem, the behavior should be the same.
> > > > > > >>> I see net-next is only rejecting the bad DT since 2019-02-21:
> > > > > > >>> https://patchwork.kernel.org/patch/10819279/
> > > > > > >>> So it depends when you checked it last time.
> > > > > > >>
> > > > > > >> I'll see about testing eth in Linux with net-next tomorrow, but, uh, is
> > > > > > >> there some work-around for the DTS so that ethernet works?
> > > > > > >
> > > > > > > Work-around in Linux or in U-boot?
> > > > > > > U-boot can fix up the DT for Linux and replace "rgmii-txid" with
> > > > > > > "rgmii-id", whereas neither Linux nor U-boot can do anything for
> > > > > > > themselves except either load a correct DT blob, or not use (revert, not
> > > > > > > upgrade to, etc) the enforcing patch.
> > > > > > >
> > > > > > >> You cannot break existing DTs
> > > > > > > RGMII delay breakages happen all the time. To play the devil's advocate,
> > > > > > > protecting against them should be done by observing the semantics
> > > > > > > described in the devicetree/bindings document.
> > > > > > > If you follow Linux net-next, a breakage for RTL8211F is planned out
> > > > > > > right as we speak.
> > > > > > >
> > > > > > > But let's wait until we know for sure that this is what's causing the
> > > > > > > issues.
> > > > > > >
> > > > > > > Regards,
> > > > > > > -Vladimir
> > > > > > >
> > > > > >
> > > > > > Hi Tom,
> > > > > >
> > > > > > I understand now what you mean by "workaround".
> > > > > > Yes you can enable RGMII delays by hand in U-boot:
> > > > > >
> > > > > > Check if RX delay is enabled (bit 15 of debug register 0):
> > > > > > => mdio write eTSEC1 0x1D 0
> > > > > > => mdio read eTSEC1 0x1E
> > > > > > => mdio write eTSEC1 0x1E <new value>
> > > > > >
> > > > > > Check if TX delay is enabled (bit 8 of debug register 5):
> > > > > > => mdio write eTSEC1 0x1D 5
> > > > > > => mdio read eTSEC1 0x1E
> > > > > > => mdio write eTSEC1 0x1E <new value>
> > > > > >
> > > > > > Replace eTSEC1 with your net device from "mdio list".
> > > > >
> > > > > I'm not sure what the follow-on action is here. I'll hold off on
> > > > > Vladimir's series until there is a resolution that everyone is
> > > > > satisfied with.
> > > >
> > > > While I personally think this breaks the "DT is ABI" model, the required
> > > > change has already been merged into Linus' tree so we just need to
> > > > re-sync the am335x DTS files again and then we can apply these changes.
> > > > I'll put it on my TODO list.
> > >
> > > Hi,
> > >
> > > sorry for pulling up such an old thread. Are there any news on this? Because
> > > I've had the same fix for the atheros PHYs posted to the u-boot mailing list
> > > lately (without knowing anything about this thread).
> > >
> > > So with that rule "don't break old (and very wrong!) DT blobs" we seem not
> > > to be able to fix any serious errors. Because while it works for the most
> > > cases eg. phy-mode = rgmii-id, it wont work (and cant be fixed!) for
> > > rgmii-txid (or was it rxid? the one where the hardware default is enabled).
> > >
> > > I could also post my series without fixing that issue and just adding clock
> > > support. But I'd rather see that fixed.
> >
> > So, there's patches to fix / keep cpsw working in U-Boot. So while I
> > believe that Linux broke the rule of "DT is ABI" I've also gone
> > (virtually) hoarse pointing this out to the people that were supposed to
> > care. So it's on my short list to grab the changes that are needed for
> > the TI platforms and we can grab all of the other changes as well.
> >
> > --
>
> Tom,
>
> How come the people who proclaim that DT is ABI (which it is, nobody
> is saying otherwise) are the same as (or do it in the name of) those
> who don't follow it?
It's a good question, and I don't know why no one cared.
> Had your boards been written with the correct phy-mode in the first
> place, no breakage would have happened, and maybe the Atheros PHY
> driver bugs would have been caught earlier.
Yes, it's true that had the problem been caught 6 years ago, a lot of
things would have been better. But it wasn't.
> I agree with Michael that interpreting the "DT is ABI" phrase as "be
> compatible with past mistakes" (which are not in the ABI
> specification, but in its interpretation, at that!) is only going to
> lead to a cacophony of incoherent interpretations, which at some point
> will become impossible to reconcile.
Part of the problem here is that I was not one of the people at the time
saying that "DT must be ABI". I was in fact worried that there would be
a pain to fix broken DT files once they were out in the wild. Other
people said it would be fine and that it had been done for a long while.
And that future break would be handled in a backwards compatible way.
But here we are.
> And for U-Boot, I guess the point is moot, since the DT blob is
> typically packaged with the bootloader binary anyway.
Right, so that's the whole problem. You can't pass the old DTB to the
new kernel and have things work. Since the example in question is an
EVM rather than shipping HW platform based on the EVM, we can say "No
one shipped the DTB embedded in to the physical HW, just pass along the
new DTB!". I am far from convinced that there's not custom hardware
based on the EVM design and reference dts file that won't hit a problem
here when moving up.
But again, I've given up. I say that the ABI meant that the wrong value
was supposed to work since that's what happened and a new version of the
binding needed to be used where the right value must be used. Others
disagree. I'm not holding U-Boot up on the new changes over this, I
just haven't put together the PR. It's on my short list now.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191102/9614db58/attachment.sig>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] Pull request: u-boot-net.git master
2019-11-02 15:05 ` Tom Rini
@ 2019-11-03 15:22 ` Michael Walle
0 siblings, 0 replies; 21+ messages in thread
From: Michael Walle @ 2019-11-03 15:22 UTC (permalink / raw
To: u-boot
Am 2019-11-02 16:05, schrieb Tom Rini:
[snip]
> But again, I've given up. I say that the ABI meant that the wrong
> value
> was supposed to work since that's what happened and a new version of
> the
> binding needed to be used where the right value must be used. Others
> disagree. I'm not holding U-Boot up on the new changes over this, I
> just haven't put together the PR. It's on my short list now.
I want to rebase my cleanup and device tree support for the Atheros PHY
onto the patches by Vladimir. Although I do have some problems/questions
now:
- will the whole series [1] be pulled altogether?
- there is a kconfig option to control the EEE option. Wouldn't it be
better to put that into a device tree property option too?
- there were some cleanups I'd do another way, for example the clock
enumeration uses "BIT(0) | BIT(1)" instead of 3. I'd use a mask and the
correct enumeration and FIELD_PREP(). So should I base my patch on
Vladimirs patch? Should Vladimir post a new patch?
To be frank, I'd rather pull Vladimirs patches and change (or drop them
if they are superseeded mine), if everyone is ok with that. I'd propose
the following:
- I rebase my patches onto Vladimirs patches
- change some of Vladimirs patches
- privately, mail the patch series to Vladimir, then he can review
them, add SOB or other tags
- If he is ok with the changes, I'll post another "atheros PHY cleanup
and device tree support" series with patches from Vladimir and myself.
I don't really want to hijack any patches, but patching the patch seems
to be not really good.
Does anybody know if the "disable smartEEE" should go into the linux phy
driver too? As far as I understand it, linux configures the complete phy
itself, (eg. it might even do a hardware reset).
--
-michael
[1] https://patchwork.ozlabs.org/cover/1031360/
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2019-11-03 15:22 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-05-07 22:09 [U-Boot] Pull request: u-boot-net.git master Joe Hershberger
2019-05-08 22:24 ` Joe Hershberger
2019-05-08 22:37 ` Tom Rini
2019-05-08 22:40 ` [U-Boot] [EXT] " Vladimir Oltean
2019-05-08 22:42 ` Tom Rini
2019-05-08 22:45 ` [U-Boot] " Vladimir Oltean
2019-05-08 22:48 ` Tom Rini
2019-05-08 22:52 ` Vladimir Oltean
2019-05-08 22:54 ` Tom Rini
2019-05-08 23:05 ` Vladimir Oltean
2019-05-09 2:38 ` Tom Rini
2019-05-09 12:51 ` Vladimir Oltean
2019-05-10 21:50 ` Joe Hershberger
2019-05-15 14:58 ` Tom Rini
2019-07-25 22:40 ` Vladimir Oltean
2019-07-25 23:12 ` Tom Rini
2019-11-02 13:17 ` Michael Walle
2019-11-02 14:12 ` Tom Rini
2019-11-02 14:30 ` Vladimir Oltean
2019-11-02 15:05 ` Tom Rini
2019-11-03 15:22 ` Michael Walle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.