[U-Boot] Pull request: u-boot-net.git master

Wed May 8 23:05:29 UTC 2019

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 at 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