Message ID | 20230417072641.1656960-1-horatiu.vultur@microchip.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1944438vqo; Mon, 17 Apr 2023 00:39:33 -0700 (PDT) X-Google-Smtp-Source: AKy350ZBFp3dqfCXmENyMd2d5hUaFLywcy0C8Pgc+lMm6TpX6Wz9mcRcAwvw2p6WMCF/j4TaAfBc X-Received: by 2002:a17:903:11d0:b0:1a6:9671:253e with SMTP id q16-20020a17090311d000b001a69671253emr14246734plh.47.1681717173293; Mon, 17 Apr 2023 00:39:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681717173; cv=none; d=google.com; s=arc-20160816; b=ORnGFh7rP/F3n4eVjen1iuoBWdsv86Cbtwb3IxM4RAsuRzLiJ8Yb0hN6qm4TIFJp9z XIgon7ihNnKrB00Tmc6OSQ0CY0tSZlo/jQQ2ME69ER0yZaR9nnMoTwkXaBO3i0a5YP+U RsSJ8BSxwDlb8bXNkWepZHCJN9GY3vf4M6sPCVfs9OEodIrM5uBQ3UALPctdPqHTU3zK KBzItTcTXqw8Ywx7hDZmDuwiBelENs89PWkHGVobLKwsEDyIBBvvldty7uM3ogWn0viJ HOC7eivWQlg6dtGLXJeEF8lwSmd9LZOCQ5uI4Mk8asHdUVXFR2+AS9DXv4Oh/raicnFY jVfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=yd9rVaaSd3sow06sBU1ZJ5sY43UjivKjWPeNwpViHL0=; b=WJJtobvqpgvomYrhHTpNhBiZZt3ZEFLS+FPV3gAydC1paapv/h8rKSA4kKnMOonela OzaT0NDU9pvbYOGbjDZ/UXMpIaPZg8lUluIx/+rXTpFbbDzYx0E+jkC53pjWfYusvYZw xknW2YCdvdw1lkPOgLRJr/jaAx5WeWM34BfoDyT1kvE2md+Gs2OK9LKxMXScxet9SiHn N+9c0E5txEROhmh3vlHPtQELC7L4a5dzf9s/TY16Zf6HUNQVnsGSe/3Ef/QyUSdt09q5 YlyAx+sr8Yhvdvy4mcInN46nmIjJnnuQ8CGiFxiW2ZesmTS+P0kZPWvtdrPQo1gGTB2y molw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=iz7mtkQl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f3-20020a170902e98300b001a50a33295esi10965100plb.278.2023.04.17.00.39.20; Mon, 17 Apr 2023 00:39:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=iz7mtkQl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230305AbjDQH1W (ORCPT <rfc822;leviz.kernel.dev@gmail.com> + 99 others); Mon, 17 Apr 2023 03:27:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41404 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230342AbjDQH1F (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 17 Apr 2023 03:27:05 -0400 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22C34423B; Mon, 17 Apr 2023 00:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1681716407; x=1713252407; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=jRW6cL+cIiKb2Ng2FGwD0jd41pvkdwoEaHwYjvdHuow=; b=iz7mtkQle6pOkEIwFsj8gZ+gRKttmiPbE8anBJnA4Nc6yFDoaQYqOlBX ZHqCuEydYe51nnHeHHbCgkkiOXAk4oNGTRx4gNSIKSZv3H9bCW0uY9Djl ef5RYYY4bGFwuNy+O2jvUaCRoik5Rm4dkmSU3NH0QFw6QjgFCwSlxe570 A292+cdpdRH0Dcj/znygbRA0kfnph0EgbLZvtQsyESGsg9L0jRdosIUme gfO3mLL/Vw3ndcIBbBq6QF6HgrdM1SF2JgGyAbQIF/CclGNpgilWi0VZk Rino57rCx/5m+fqH5YM9t+GAcSU+oj/xa4q731rpLRXEEIiVwW3dlMrKk A==; X-IronPort-AV: E=Sophos;i="5.99,203,1677567600"; d="scan'208,223";a="210729526" Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa2.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 17 Apr 2023 00:26:46 -0700 Received: from chn-vm-ex01.mchp-main.com (10.10.85.143) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Mon, 17 Apr 2023 00:26:45 -0700 Received: from soft-dev3-1.microsemi.net (10.10.115.15) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server id 15.1.2507.21 via Frontend Transport; Mon, 17 Apr 2023 00:26:43 -0700 From: Horatiu Vultur <horatiu.vultur@microchip.com> To: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org> CC: <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>, <UNGLinuxDriver@microchip.com>, <aleksander.lobakin@intel.com>, Horatiu Vultur <horatiu.vultur@microchip.com> Subject: [PATCH net-next v2] net: lan966x: Fix lan966x_ifh_get Date: Mon, 17 Apr 2023 09:26:41 +0200 Message-ID: <20230417072641.1656960-1-horatiu.vultur@microchip.com> X-Mailer: git-send-email 2.38.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763139915327819162?= X-GMAIL-MSGID: =?utf-8?q?1763408266869641328?= |
Series |
[net-next,v2] net: lan966x: Fix lan966x_ifh_get
|
|
Commit Message
Horatiu Vultur
April 17, 2023, 7:26 a.m. UTC
From time to time, it was observed that the nanosecond part of the
received timestamp, which is extracted from the IFH, it was actually
bigger than 1 second. So then when actually calculating the full
received timestamp, based on the nanosecond part from IFH and the second
part which is read from HW, it was actually wrong.
The issue seems to be inside the function lan966x_ifh_get, which
extracts information from an IFH(which is an byte array) and returns the
value in a u64. When extracting the timestamp value from the IFH, which
starts at bit 192 and have the size of 32 bits, then if the most
significant bit was set in the timestamp, then this bit was extended
then the return value became 0xffffffff... . And the reason of this is
because constants without any postfix are treated as signed longs and
that is the reason why '1 << 31' becomes 0xffffffff80000000.
This is fixed by adding the postfix 'ULL' to 1.
Fixes: fd7627833ddf ("net: lan966x: Stop using packing library")
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
---
v1->v2:
- use postfix ULL when setting the bit in the val instead of masking in
the end the val.
---
drivers/net/ethernet/microchip/lan966x/lan966x_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Hello: This patch was applied to netdev/net-next.git (main) by David S. Miller <davem@davemloft.net>: On Mon, 17 Apr 2023 09:26:41 +0200 you wrote: > From time to time, it was observed that the nanosecond part of the > received timestamp, which is extracted from the IFH, it was actually > bigger than 1 second. So then when actually calculating the full > received timestamp, based on the nanosecond part from IFH and the second > part which is read from HW, it was actually wrong. > > The issue seems to be inside the function lan966x_ifh_get, which > extracts information from an IFH(which is an byte array) and returns the > value in a u64. When extracting the timestamp value from the IFH, which > starts at bit 192 and have the size of 32 bits, then if the most > significant bit was set in the timestamp, then this bit was extended > then the return value became 0xffffffff... . And the reason of this is > because constants without any postfix are treated as signed longs and > that is the reason why '1 << 31' becomes 0xffffffff80000000. > This is fixed by adding the postfix 'ULL' to 1. > > [...] Here is the summary with links: - [net-next,v2] net: lan966x: Fix lan966x_ifh_get https://git.kernel.org/netdev/net-next/c/99676a576641 You are awesome, thank you!
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c index 80e2ea7e6ce8a..5f01b21acdd1b 100644 --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c @@ -605,7 +605,7 @@ static u64 lan966x_ifh_get(u8 *ifh, size_t pos, size_t length) v = ifh[IFH_LEN_BYTES - (j / 8) - 1]; if (v & (1 << k)) - val |= (1 << i); + val |= (1ULL << i); } return val;