[resend,net-next,v1,2/2] net: thunderbolt: Use separate header data type for the Rx
Message ID | 20221129161359.75792-2-andriy.shevchenko@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp434182wrr; Tue, 29 Nov 2022 08:15:55 -0800 (PST) X-Google-Smtp-Source: AA0mqf7OzJrhdytZxiqo3PpESJ8RVqyVrw9+kOlFWM6xljRwqf5oqr1zhBGadXVapQHeS9G1EHZB X-Received: by 2002:a17:906:2c51:b0:7b2:8c66:9bda with SMTP id f17-20020a1709062c5100b007b28c669bdamr7189384ejh.732.1669738555757; Tue, 29 Nov 2022 08:15:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669738555; cv=none; d=google.com; s=arc-20160816; b=JHU/2KyN8Ksk9MGwSw29V1wB/uRXb7uKsBnTsUGDNyixMDmvTCzcNpKOoC3DyoyxQQ n/zAT95s5kts8WF1ApQJa3q5G6J5G8BNMMjFG/nryPl6Cskqx/ALosJnufH8qoy57VpK qZGjP1G4ZD3Lq2FvzuqVNHP6cn5/DsRyeeqy6d1BehfPelbZXXJZ1VNZM2Yiox+tf0Vn vyojqrmdQ8VW19YjHE7MEydXT4SALr5Hk+eR7LRJhjR7KH4s2umeDkTpNFY+gx9thIoN i/JReN/5J8CbHG0tt7YJxLoUyY3gl7oKl0ztKhK0Rk3aRs2Jcdk6sxwhEdP4TLQyxPVX BJ7Q== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=dKyCifMRaYiEa9HWBwuqwgZFHTgAlGdkp8wfMPj54pw=; b=JrGgmbHsH9JhhPSulLmq+fdYOGdA8aRo1w9KwxQttTMiJ8/mOgOfuGFQ/wqbPsJwtV JM4kyVYFAMbAlDBrm1G2c1lhTKlB59LM1BwxFyhZ44kvH75G7yzKT04bu3FybghuJjc9 3trzWoON0O/sd8F7vAeBZMVwVVXcim6/M3ijGcy91WONGoA/spZluTMwLKqRguQa5hp4 vJ2Rv706+trlr/J1rDlQLalSosrrzJFlVefsdqc/6r/1D0bCz22TXEdtJXfOSMvaPvCL OoBt0usTx4E1U7hwA2QnddIOHO5a7jczRR4DYVTAeaLB/xg6zPBzk8EOzXrf4c+fOsJm Hv3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=gIN9xUrD; 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=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r18-20020a05640251d200b0046aaeca7d05si12388373edd.399.2022.11.29.08.15.31; Tue, 29 Nov 2022 08:15:55 -0800 (PST) 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=@intel.com header.s=Intel header.b=gIN9xUrD; 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=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235817AbiK2QOh (ORCPT <rfc822;rbbytesnap@gmail.com> + 99 others); Tue, 29 Nov 2022 11:14:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42290 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235891AbiK2QOO (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 29 Nov 2022 11:14:14 -0500 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3DBE65E53; Tue, 29 Nov 2022 08:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669738447; x=1701274447; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Su0Cw3MyHqpzsKA0PnsNlmYF5H+VQ8b4Iwhnm0qJsZk=; b=gIN9xUrDMmHCizqKmGnS2LVjmiRZd6wlzFkvWYA/UE8zMUz+AF+PvHtU 6ttR8G9v+r6FIgrFzkuBM7M4XsBfj5IsL3ca9bpr+edFMI5FIIvS95tg/ Kke30HvrvzUHNBi2bjHGXKHVoKJXXASryKeonl1/YcD91nE7JJfyNmDyx 7gXQWxGSr6WPu3Fp6yA31jNpbkbNpuohe5zV/komry1ciu7PnvwOTFjfm A3vzuqC3rV4ap8Vs9WR+YD+dwJA476yxagmdaUPgBomy9A57SwzgVyLB/ bFCxtzwNcjJuCdpoVFlZEPysjyCZ9r8mYJUGNrgjuqWcsXCiQP3epAUz1 Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10546"; a="302740399" X-IronPort-AV: E=Sophos;i="5.96,203,1665471600"; d="scan'208";a="302740399" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Nov 2022 08:13:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10546"; a="768476669" X-IronPort-AV: E=Sophos;i="5.96,203,1665471600"; d="scan'208";a="768476669" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga004.jf.intel.com with ESMTP; 29 Nov 2022 08:13:36 -0800 Received: by black.fi.intel.com (Postfix, from userid 1003) id 3868D179; Tue, 29 Nov 2022 18:14:03 +0200 (EET) From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Michael Jamet <michael.jamet@intel.com>, Mika Westerberg <mika.westerberg@linux.intel.com>, Yehezkel Bernat <YehezkelShB@gmail.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com> Subject: [resend, PATCH net-next v1 2/2] net: thunderbolt: Use separate header data type for the Rx Date: Tue, 29 Nov 2022 18:13:59 +0200 Message-Id: <20221129161359.75792-2-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20221129161359.75792-1-andriy.shevchenko@linux.intel.com> References: <20221129161359.75792-1-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE 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?1750847775512746965?= X-GMAIL-MSGID: =?utf-8?q?1750847775512746965?= |
Series |
[resend,net-next,v1,1/2] net: thunderbolt: Switch from __maybe_unused to pm_sleep_ptr() etc
|
|
Commit Message
Andy Shevchenko
Nov. 29, 2022, 4:13 p.m. UTC
The same data type structure is used for bitwise operations and
regular ones. It makes sparse unhappy, for example:
.../thunderbolt.c:718:23: warning: cast to restricted __le32
.../thunderbolt.c:953:23: warning: incorrect type in initializer (different base types)
.../thunderbolt.c:953:23: expected restricted __wsum [usertype] wsum
.../thunderbolt.c:953:23: got restricted __be32 [usertype]
Split the header to bitwise one and specific for Rx to make sparse
happy. Assure the layout by involving static_assert() against size
and offsets of the member of the structures.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/thunderbolt.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
Comments
On Tue, Nov 29, 2022 at 06:13:59PM +0200, Andy Shevchenko wrote: > The same data type structure is used for bitwise operations and > regular ones. It makes sparse unhappy, for example: > > .../thunderbolt.c:718:23: warning: cast to restricted __le32 > > .../thunderbolt.c:953:23: warning: incorrect type in initializer (different base types) > .../thunderbolt.c:953:23: expected restricted __wsum [usertype] wsum > .../thunderbolt.c:953:23: got restricted __be32 [usertype] > > Split the header to bitwise one and specific for Rx to make sparse > happy. Assure the layout by involving static_assert() against size > and offsets of the member of the structures. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > --- > drivers/net/thunderbolt.c | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) I would much rather keep the humans reading this happy than add 20+ lines just to silence a tool. Unless this of course is some kind of a real bug.
On Wed, Nov 30, 2022 at 09:46:16AM +0200, Mika Westerberg wrote: > On Tue, Nov 29, 2022 at 06:13:59PM +0200, Andy Shevchenko wrote: > > The same data type structure is used for bitwise operations and > > regular ones. It makes sparse unhappy, for example: > > > > .../thunderbolt.c:718:23: warning: cast to restricted __le32 > > > > .../thunderbolt.c:953:23: warning: incorrect type in initializer (different base types) > > .../thunderbolt.c:953:23: expected restricted __wsum [usertype] wsum > > .../thunderbolt.c:953:23: got restricted __be32 [usertype] > > > > Split the header to bitwise one and specific for Rx to make sparse > > happy. Assure the layout by involving static_assert() against size > > and offsets of the member of the structures. > I would much rather keep the humans reading this happy than add 20+ > lines just to silence a tool. Unless this of course is some kind of a > real bug. Actually, changing types to bitwise ones reduces the sparse noise (I will double check this) without reducing readability. Would it be accepted?
On Wed, Nov 30, 2022 at 12:51:06PM +0200, Andy Shevchenko wrote: > On Wed, Nov 30, 2022 at 09:46:16AM +0200, Mika Westerberg wrote: > > On Tue, Nov 29, 2022 at 06:13:59PM +0200, Andy Shevchenko wrote: > > > The same data type structure is used for bitwise operations and > > > regular ones. It makes sparse unhappy, for example: > > > > > > .../thunderbolt.c:718:23: warning: cast to restricted __le32 > > > > > > .../thunderbolt.c:953:23: warning: incorrect type in initializer (different base types) > > > .../thunderbolt.c:953:23: expected restricted __wsum [usertype] wsum > > > .../thunderbolt.c:953:23: got restricted __be32 [usertype] > > > > > > Split the header to bitwise one and specific for Rx to make sparse > > > happy. Assure the layout by involving static_assert() against size > > > and offsets of the member of the structures. > > > I would much rather keep the humans reading this happy than add 20+ > > lines just to silence a tool. Unless this of course is some kind of a > > real bug. > > Actually, changing types to bitwise ones reduces the sparse noise > (I will double check this) without reducing readability. > Would it be accepted? Sure if it makes it more readable and does not add too many lines :)
On Wed, Nov 30, 2022 at 01:09:59PM +0200, Mika Westerberg wrote: > On Wed, Nov 30, 2022 at 12:51:06PM +0200, Andy Shevchenko wrote: > > On Wed, Nov 30, 2022 at 09:46:16AM +0200, Mika Westerberg wrote: > > > On Tue, Nov 29, 2022 at 06:13:59PM +0200, Andy Shevchenko wrote: > > > > The same data type structure is used for bitwise operations and > > > > regular ones. It makes sparse unhappy, for example: > > > > > > > > .../thunderbolt.c:718:23: warning: cast to restricted __le32 > > > > > > > > .../thunderbolt.c:953:23: warning: incorrect type in initializer (different base types) > > > > .../thunderbolt.c:953:23: expected restricted __wsum [usertype] wsum > > > > .../thunderbolt.c:953:23: got restricted __be32 [usertype] > > > > > > > > Split the header to bitwise one and specific for Rx to make sparse > > > > happy. Assure the layout by involving static_assert() against size > > > > and offsets of the member of the structures. > > > > > I would much rather keep the humans reading this happy than add 20+ > > > lines just to silence a tool. Unless this of course is some kind of a > > > real bug. > > > > Actually, changing types to bitwise ones reduces the sparse noise > > (I will double check this) without reducing readability. > > Would it be accepted? > > Sure if it makes it more readable and does not add too many lines :) It replaces types u* by __le*, that's it: -4 +4 LoCs.
diff --git a/drivers/net/thunderbolt.c b/drivers/net/thunderbolt.c index 4dbc6c7f2e10..f7b3d0d4646c 100644 --- a/drivers/net/thunderbolt.c +++ b/drivers/net/thunderbolt.c @@ -58,12 +58,32 @@ * supported then @frame_id is filled, otherwise it stays %0. */ struct thunderbolt_ip_frame_header { + __le32 frame_size; + __le16 frame_index; + __le16 frame_id; + __le32 frame_count; +}; + +/* Same as &struct thunderbolt_ip_frame_header for Rx */ +struct thunderbolt_ip_frame_rx_hdr { u32 frame_size; u16 frame_index; u16 frame_id; u32 frame_count; }; +static_assert(sizeof(struct thunderbolt_ip_frame_header) == + sizeof(struct thunderbolt_ip_frame_rx_hdr)); + +#define TBIP_FRAME_HDR_MATCH(x) \ + static_assert(offsetof(struct thunderbolt_ip_frame_header, frame_##x) == \ + offsetof(struct thunderbolt_ip_frame_rx_hdr, frame_##x)) +TBIP_FRAME_HDR_MATCH(size); +TBIP_FRAME_HDR_MATCH(index); +TBIP_FRAME_HDR_MATCH(id); +TBIP_FRAME_HDR_MATCH(count); +#undef TBIP_FRAME_HDR_MATCH + enum thunderbolt_ip_frame_pdf { TBIP_PDF_FRAME_START = 1, TBIP_PDF_FRAME_END, @@ -193,7 +213,7 @@ struct tbnet { struct delayed_work login_work; struct work_struct connected_work; struct work_struct disconnect_work; - struct thunderbolt_ip_frame_header rx_hdr; + struct thunderbolt_ip_frame_rx_hdr rx_hdr; struct tbnet_ring rx_ring; atomic_t frame_id; struct tbnet_ring tx_ring;