Message ID | 20230202145412.87569-1-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:eb09:0:0:0:0:0 with SMTP id s9csp289526wrn; Thu, 2 Feb 2023 07:04:35 -0800 (PST) X-Google-Smtp-Source: AK7set8KCi37fAN0ldkKzLzbJv0sG8AFVXheN0+Oq/5pz/tu67XvduoNXbCLyjzhM0HdGvTvXpAk X-Received: by 2002:a17:90b:201:b0:22c:8ba9:4ce8 with SMTP id fy1-20020a17090b020100b0022c8ba94ce8mr2291249pjb.15.1675350274927; Thu, 02 Feb 2023 07:04:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675350274; cv=none; d=google.com; s=arc-20160816; b=edAagGyvDcC2nguGLuNM/WTBRUcX5i3ok1mihu90aRxczfCLfAoWHnlHfWdGF1c5ID +7kj6NBE52Hx9HMgMBFc8mFo1UwTf66eTbKGH2MR0/c59uF3FuRAZAJ2AXrO5Nlbyncn 3TspjyFapDu6iD1YZ/1/0qgEiBcjPw0FKfbJMbTRMEpFNaAf4pk7CddkqhwvCJeHSsIQ zsRdFdMpc3Vj4Hua/Nm+7dyQNTVNty5Sf3YDOY8uiPINNytiKHVaLgiHbn0LKlYAQNPY bDRSB8yqLQBhZtnHihIfrY0DjcbSxxkh4bgJIrEE8cAIWOnP/6Ia/ekXEwYzlN9Pvw20 ROIw== 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=OsopVIbYvGXq9AXAzlzaIWogwk8GE7EXp+WbpRMuTYI=; b=WJJMl+rodUs3vnlQnNQgRjozOlamCDWnJJLr90JxWXW16l/fqlgKggpLatSG641wCF TOxR/6dpd8g5AKGa1le+3E5kO6fdN77ab0JUsqnp3O+C6OmWigzdAJBc3/n6lUhQdnXc XR38u2VjorsoQn/2RE7+DGzccaSWnA0hccSjp/pACeLK9r+53+KjNe8eB5KJGPPYPk8w eG4wywcuF4Yz1ejHOWMJVRKviBWoKeu+wcn8fvo6E3AXMkqhJx33MGeEk/EahBGpg2vC xmEwzu6SigxRznpNNo+tO/pPVqbdro/Xoi7sjIUu6g3vuwiVaeQ9ZG/wx0+KaWNwM6K9 xhmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=A97lEMyF; 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 i198-20020a639dcf000000b0049df87734d2si22755766pgd.271.2023.02.02.07.04.17; Thu, 02 Feb 2023 07:04:34 -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=A97lEMyF; 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 S231841AbjBBO5K (ORCPT <rfc822;il.mystafa@gmail.com> + 99 others); Thu, 2 Feb 2023 09:57:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230456AbjBBO5I (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 2 Feb 2023 09:57:08 -0500 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD3B9C150 for <linux-kernel@vger.kernel.org>; Thu, 2 Feb 2023 06:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675349801; x=1706885801; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=dGH+MnuXdnPeliogyF4d/7loFr8yDkivZc2cFA6iOrs=; b=A97lEMyFHSO1aOxlcGcU/Guln1a3f6Cdu9wYmD3TaL5Rrwto1EDUE8cF n3JxgeiqiG189PVmfj8rc+7IIXh1iRfMqcgHxRKrxndr9gvF7+wYbQdYs 1OSr0vf33L+Ps+MQ5cnmBdToOsm8owvvfHf9hbcZt0J4QJZYP1eU62JfK l+5Hs2H3lJxicTrBuPLP9kjAqLgdH3ZgjUitbiYu41XyuRsnbHM8zTsFM u342JP11qoQeJKf93J36NQHKlBppzRYbd2hk3LAqX1Xcs9PW+8c6xMziO vp3FcvV97KiQDxftUk2wQ1gJaj0K1ESw4oicqtO8EpZDjjd8JrmOfbP1u Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10608"; a="308111371" X-IronPort-AV: E=Sophos;i="5.97,267,1669104000"; d="scan'208";a="308111371" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Feb 2023 06:53:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10608"; a="615305708" X-IronPort-AV: E=Sophos;i="5.97,267,1669104000"; d="scan'208";a="615305708" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga003.jf.intel.com with ESMTP; 02 Feb 2023 06:53:48 -0800 Received: by black.fi.intel.com (Postfix, from userid 1003) id 972FE337; Thu, 2 Feb 2023 16:54:25 +0200 (EET) From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>, Alexander Usyskin <alexander.usyskin@intel.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, linux-kernel@vger.kernel.org Cc: Tomas Winkler <tomas.winkler@intel.com>, Arnd Bergmann <arnd@arndb.de>, Christoph Hellwig <hch@lst.de> Subject: [PATCH v1 1/1] mei: Move uuid_le_cmp() to its only user Date: Thu, 2 Feb 2023 16:54:12 +0200 Message-Id: <20230202145412.87569-1-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.39.1 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,SPF_HELO_PASS, 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?1756732089942131005?= X-GMAIL-MSGID: =?utf-8?q?1756732089942131005?= |
Series |
[v1,1/1] mei: Move uuid_le_cmp() to its only user
|
|
Commit Message
Andy Shevchenko
Feb. 2, 2023, 2:54 p.m. UTC
There is only a single user of uuid_le_cmp() API, let's make it private
to that user.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/misc/mei/mei_dev.h | 5 +++++
include/linux/uuid.h | 5 -----
2 files changed, 5 insertions(+), 5 deletions(-)
Comments
On Thu, Feb 02, 2023 at 04:54:12PM +0200, Andy Shevchenko wrote: > There is only a single user of uuid_le_cmp() API, let's make it private > to that user. Any reason this code can't just use guid_t and guid_equal?
On Thu, Feb 02, 2023 at 04:17:59PM +0100, Christoph Hellwig wrote: > On Thu, Feb 02, 2023 at 04:54:12PM +0200, Andy Shevchenko wrote: > > There is only a single user of uuid_le_cmp() API, let's make it private > > to that user. > > Any reason this code can't just use guid_t and guid_equal? It's part of ABI, while guid_* are for the internal use. Eventually they may switch to the internal types, but it's up to MEI.
On Thu, Feb 02, 2023 at 05:21:52PM +0200, Andy Shevchenko wrote: > On Thu, Feb 02, 2023 at 04:17:59PM +0100, Christoph Hellwig wrote: > > On Thu, Feb 02, 2023 at 04:54:12PM +0200, Andy Shevchenko wrote: > > > There is only a single user of uuid_le_cmp() API, let's make it private > > > to that user. > > > > Any reason this code can't just use guid_t and guid_equal? > > It's part of ABI, while guid_* are for the internal use. > > Eventually they may switch to the internal types, but it's up to MEI. How can a type name be part of a binary interface?
On Thu, Feb 02, 2023 at 04:22:34PM +0100, Christoph Hellwig wrote: > On Thu, Feb 02, 2023 at 05:21:52PM +0200, Andy Shevchenko wrote: > > On Thu, Feb 02, 2023 at 04:17:59PM +0100, Christoph Hellwig wrote: > > > On Thu, Feb 02, 2023 at 04:54:12PM +0200, Andy Shevchenko wrote: > > > > There is only a single user of uuid_le_cmp() API, let's make it private > > > > to that user. > > > > > > Any reason this code can't just use guid_t and guid_equal? > > > > It's part of ABI, while guid_* are for the internal use. > > > > Eventually they may switch to the internal types, but it's up to MEI. > > How can a type name be part of a binary interface? If I'm not mistaken there is a difference between simple __u8[16] and struct { __u8[16] } due to alignment. But data wise it's the same, of course. That said, it depends on how this type is being used in the any of ABI. From the API perspective the guid_* are not visible to uAPI.
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h index 996b70a988be..895011b7a0bf 100644 --- a/drivers/misc/mei/mei_dev.h +++ b/drivers/misc/mei/mei_dev.h @@ -13,6 +13,11 @@ #include <linux/mei.h> #include <linux/mei_cl_bus.h> +static inline int uuid_le_cmp(const uuid_le u1, const uuid_le u2) +{ + return memcmp(&u1, &u2, sizeof(uuid_le)); +} + #include "hw.h" #include "hbm.h" diff --git a/include/linux/uuid.h b/include/linux/uuid.h index 5be158a49e11..6b1a3efa1e0b 100644 --- a/include/linux/uuid.h +++ b/include/linux/uuid.h @@ -110,9 +110,4 @@ int uuid_parse(const char *uuid, uuid_t *u); /* MEI UUID type, don't use anywhere else */ #include <uapi/linux/uuid.h> -static inline int uuid_le_cmp(const uuid_le u1, const uuid_le u2) -{ - return memcmp(&u1, &u2, sizeof(uuid_le)); -} - #endif