Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3591703pxv; Mon, 5 Jul 2021 00:39:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwu1vg3Euou8JvE8IZJdq0A5XiaRhU3OY3bgfSNncgv9i6ExwKnurby9e2X9RI0jnwdNdKO X-Received: by 2002:a5d:9958:: with SMTP id v24mr10760868ios.4.1625470775329; Mon, 05 Jul 2021 00:39:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625470775; cv=none; d=google.com; s=arc-20160816; b=tRjLN5xA7zS5smERXGShxrTA2yeUz3hTwDQFFGDL/5mmqLjtDaNANgeKVNfqKYhMTC zEKzWxPKFnjwKvHplJTq/yVjYfT8qlwquMs74GlnVvItGvdg1xnKQqueMkvMKwCFJqy7 Nc9Fxf/edXqobuWjJpedr3c9rV2qdGMKYkUzhBPbW+1rV2P2YnOU/neHbejLJx/IXq8I IP1jD0kzs0UopA4QbP257MUt1TfdD/VE4VtNqxdjL6iBAPuwQu64sIa681LOVdzwUybn nmSDQ8/K7t4xUtsyGdcQgU/3cbSI27xCfDMq+uPe7B5K25JAZO7fL11eOMFpEB76IXeD Om+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:to; bh=8xDIgfPWoDiTda/xO/ZHiAUN+vViBjAaJrSNnWZKt3Q=; b=bLEGpVoewl/Zcgfogc0OqVNeaAhM9Q/sCzYaxZvKBceVr63H+Nib6pRoD8O4fyJSMJ EGJIhzkpG49n/KxPEjrir5BTN1E3P8Ec7C//eye9ASnzsXqJkRjhMRuh1T/1TCPZQmxr vr51oewBWx/GIuEAAknSTKYwZ7ZR7lj5L8N6ntAoyf4xez0xyRSPWGosQfCV+o7AXgws wuotC4WBq1GtxLzow7/4oUgaDc7KHffG7xfgDIJr2ZZ6YuioTglKaRwi2cCo33suVRLJ KOir8Vry9+i5yc0McTzVbfzQqZ28qd0jHhsFrKThrD20tffJqc0YdILyyzy/SsVvXLW9 1b0w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d12si12588326ils.58.2021.07.05.00.39.24; Mon, 05 Jul 2021 00:39:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229993AbhGEHlP (ORCPT + 99 others); Mon, 5 Jul 2021 03:41:15 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:47160 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229817AbhGEHlO (ORCPT ); Mon, 5 Jul 2021 03:41:14 -0400 Received: from [222.129.38.159] (helo=[192.168.1.18]) by youngberry.canonical.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1m0JBc-0001cn-4h; Mon, 05 Jul 2021 07:38:36 +0000 To: "Neftin, Sasha" , jesse.brandeburg@intel.com, anthony.l.nguyen@intel.com, davem@davemloft.net, kuba@kernel.org, intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Edri, Michael" , "Ruinskiy, Dima" References: <20210702045120.22855-1-aaron.ma@canonical.com> <20210702045120.22855-2-aaron.ma@canonical.com> <613e2106-940a-49ed-6621-0bb00bc7dca5@intel.com> From: Aaron Ma Subject: Re: [Intel-wired-lan] [PATCH 2/2] igc: wait for the MAC copy when enabled MAC passthrough Message-ID: Date: Mon, 5 Jul 2021 15:38:29 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <613e2106-940a-49ed-6621-0bb00bc7dca5@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/4/21 1:36 PM, Neftin, Sasha wrote: > On 7/2/2021 07:51, Aaron Ma wrote: >> Such as dock hot plug event when runtime, for hardware implementation, >> the MAC copy takes less than one second when BIOS enabled MAC passthrough. >> After test on Lenovo TBT4 dock, 600ms is enough to update the >> MAC address. >> Otherwise ethernet fails to work. >> >> Signed-off-by: Aaron Ma >> --- >>   drivers/net/ethernet/intel/igc/igc_main.c | 3 +++ >>   1 file changed, 3 insertions(+) >> >> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c >> index 606b72cb6193..c8bc5f089255 100644 >> --- a/drivers/net/ethernet/intel/igc/igc_main.c >> +++ b/drivers/net/ethernet/intel/igc/igc_main.c >> @@ -5468,6 +5468,9 @@ static int igc_probe(struct pci_dev *pdev, >>       memcpy(&hw->mac.ops, ei->mac_ops, sizeof(hw->mac.ops)); >>       memcpy(&hw->phy.ops, ei->phy_ops, sizeof(hw->phy.ops)); >> +    if (pci_is_thunderbolt_attached(pdev) > +        msleep(600); > I believe it is a bit fragile. I would recommend here look for another indication instead of delay. Can we poll for a 'pci_channel_io_normal' state? (igc->pdev->error_state == pci_channel_io_normal) Hi sasha, In this situation, the error_state is always pci_channel_io_normal. The delay is necessary. Refer to "627239-Intel® Ethernet Controller I225-MAC-Address-Passthrough-rev1.2" section "3.5 Timing Considerations": "For hardware implementation, when the operating system is already running, the MAC copy must happen not more than one second after TBT link is established. the I225 Windows driver prevents the operating system from detecting the I225 for one second. This allows enough time for hardware to update the MAC address." Thanks sasha, Aaron >> + >>       /* Initialize skew-specific constants */ >>       err = ei->get_invariants(hw); >>       if (err) >> > Thanks Aaron, > sasha