Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91725C433EF for ; Wed, 12 Jan 2022 18:26:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244328AbiALS0x (ORCPT ); Wed, 12 Jan 2022 13:26:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238538AbiALSZ6 (ORCPT ); Wed, 12 Jan 2022 13:25:58 -0500 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A741C061748 for ; Wed, 12 Jan 2022 10:25:58 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id p14so5181997plf.3 for ; Wed, 12 Jan 2022 10:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gateworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t7riP9B4hsvG3qfLdbEnZvp9wjNoyW2lbflNMHW39W8=; b=LBtirDp/PTk9KEi34QLQbuOhPPu+AMulIJ/xPckEDw1TwMcMQY/5ywr4YRWMpfwodt 96mes91QC04PFSDdvQIAixfp4kHrYOL9KeZTb5elcOoapSEEVPn2X2lAcPSWKaNdeXIk 13e0ypnAqoody2uFNiBD0nZcgdOsqjQXGqvHowltFdOoh8qSRYFQ5t30eWuh32YL2YP5 HK5bqWHxOKRK6pElqxm41spg+55WYbHRd92ySsZhcbuQXQ6XDONC6DRsTX/xknVZz+FN 0jTleVMUynsW1r5aJBVggbKoaSbbKOWJtIweBxCJ1GuiI89jGdPXhnU3ZEYk3YONh9BB 2qAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t7riP9B4hsvG3qfLdbEnZvp9wjNoyW2lbflNMHW39W8=; b=0LqupEwybizQ3uczB3x03QV7jVoslCDWW8mift6u0V8pJNDMVm1Fz2upKC4Ja9spa5 a4W0jICdAQrwBzknxAMykuvSvj9tH2VDm+cRIPZmW05FkErJe12w2YYhinLkNmoNO4r9 v6gqA5XWX8Lo8nwUTcRTsL7FmtIy/CpzmkJlIbsV+WnImNQtcAfcVza5l2KEDTZC0ZOO tEZ8v0z76CY6N1nYnmHVYVpCMOKbnLPxrmQYErURl4y2HD9Npu2vgkEB0MGs4XHsGpAO klmkL8kheAxr5S0c5avAqihBstzJ/yUC7YHY6Dtc++i+y3LTapoQuyWHL0KZ3CNhCbPD 033g== X-Gm-Message-State: AOAM530Vy3KW47j5m7YyZhS+XdiGrdISePAbAwhnU8+6CBylR0T5H+jk 1OyZG0P5PG/9YF2GEXL8yxoRLQYkMPK5bbqClA508w== X-Google-Smtp-Source: ABdhPJyjyv7NrFCdZ4Lz45io4ag12WYI5HWn85TJF1pRqOoZZe8eIxQkcTz2QYyELGuhHu4dMOoYI+pjQ95pIIpL+CU= X-Received: by 2002:a17:90b:e89:: with SMTP id fv9mr876098pjb.155.1642011957942; Wed, 12 Jan 2022 10:25:57 -0800 (PST) MIME-Version: 1.0 References: <20210719082756.15733-1-ms@dev.tdt.de> <94120968908a8ab073fa2fc0dd56b17d@dev.tdt.de> In-Reply-To: From: Tim Harvey Date: Wed, 12 Jan 2022 10:25:45 -0800 Message-ID: Subject: Re: [PATCH net-next v6] net: phy: intel-xway: Add RGMII internal delay configuration To: "Russell King (Oracle)" Cc: Martin Schiller , Hauke Mehrtens , martin.blumenstingl@googlemail.com, Florian Fainelli , Andrew Lunn , hkallweit1@gmail.com, David Miller , kuba@kernel.org, netdev , open list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 12, 2022 at 5:46 AM Russell King (Oracle) wrote: > > On Tue, Jan 11, 2022 at 11:12:33AM -0800, Tim Harvey wrote: > > I added a debug statement in xway_gphy_rgmii_init and here you can see > > it gets called 'before' the link comes up from the NIC on a board that > > has a cable plugged in at power-on. I can tell from testing that the > > rx_delay/tx_delay set in xway_gphy_rgmii_init does not actually take > > effect unless I then bring the link down and up again manually as you > > indicate. > > > > # dmesg | egrep "xway|nicvf" > > [ 6.855971] xway_gphy_rgmii_init mdio_thunder MDI_MIICTRL:0xb100 > > rx_delay=1500 tx_delay=500 > > [ 6.999651] nicvf, ver 1.0 > > [ 7.002478] nicvf 0000:05:00.1: Adding to iommu group 7 > > [ 7.007785] nicvf 0000:05:00.1: enabling device (0004 -> 0006) > > [ 7.053189] nicvf 0000:05:00.2: Adding to iommu group 8 > > [ 7.058511] nicvf 0000:05:00.2: enabling device (0004 -> 0006) > > [ 11.044616] nicvf 0000:05:00.2 eth1: Link is Up 1000 Mbps Full duplex > > Does the kernel message about the link coming up reflect what is going > on physically with the link though? > > If a network interface is down, it's entirely possible that the link is > already established at the hardware level, buit the "Link is Up" message > gets reported when the network interface is later brought up. So, > debugging this by looking at the kernel messages is unreliable. > Russell, You are correct... the link doesn't come up at that point its already linked. So we need to force a reset or an auto negotiation reset after modifying the delays. Tim