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.olt...@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.hershber...@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@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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot