[U-Boot] Pull request: u-boot-net.git master
Vladimir Oltean
vladimir.oltean at nxp.com
Thu Jul 25 22:40:45 UTC 2019
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 at 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 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
>>>>
>>>
>>> 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
More information about the U-Boot
mailing list