Message ID | 20240301102505.591918-1-fabrice.gasnier@foss.st.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-88249-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2097:b0:108:e6aa:91d0 with SMTP id gs23csp983285dyb; Fri, 1 Mar 2024 02:27:02 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWkY1Lr2nLC6Pr7ytkQh/RVPLkcdIwWcW4tXQeJJvV2oBd3fsNZ+HHmcvS5CMzlnDnNHS1HqE2fgYht94n2VKGl/ngZbA== X-Google-Smtp-Source: AGHT+IF18/OZ0QMEVM9xJVeA1aBPylWHYcq1ITGkGLuju6hsqPdTjYrBzZVEs0TMTgM+Dz8egi2N X-Received: by 2002:aa7:c6d5:0:b0:566:9427:eb4 with SMTP id b21-20020aa7c6d5000000b0056694270eb4mr1027862eds.16.1709288821901; Fri, 01 Mar 2024 02:27:01 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709288821; cv=pass; d=google.com; s=arc-20160816; b=RE9Xk2Ny50Xhu1zZo1ca8wrMLfcZDX6wR0sXrxUaqgeaDDmE6Jv8plPjbEykT2qWTP lv2Z57IM/+ugFDx0+WM/QAtUo70YXzXgzwnKuODPyl/QdVFv7Mc5LwDfeHkp1d2dyG96 7yiI2KfLdCuCpRN1ep6WoZgwFY1EdSVlcAOQMZz0V6kdwvuPJpespf+a1T9A45vyl7vm aMk0bik33TbVece+06Je89aTNJOaTC0TBjTIZ1GsBawpl3IQibKSc2RMSq4TJMrPX02+ 4hXKpBXtsfvKh1AKiBDcTnvQ3pow9rprvzneV2N2PgG9vlP+IftlggcO8qCwJKFxExgs T9rg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=vp6qVxJ487N75yXFKor9ARqDlZLKEE+aQ/uMZChldUI=; fh=2Srb/HojV92fyGSX5JixQ50f0JC8E/4Fm+p3ee7pvDg=; b=r1p1bj3QBf4Ibod4xZxsjuiNvQFpEwfMhvsY78G4tS64X/tlJN7W3FO3YM+Zfbg0/W XkgCEy3wAzFC99CnZe+J0Fdu/MF39+gut2jlDF97oCV+O3lazUx+Jv2lMKR/E6EyoKNc +YEwXUiVPBg5FM1SljFSOEFyF3XE16pHmccfxAR/CzBqVVdAAvo2Ff2PBqbz07zYmYia bTI7gW0FkOUKU6yihZcFZZdbhUUqNrROas0YqBM4T+1IIQ5Np7ooudP9psepVfvlND2R ItvptzEbY7J2+4gre5N0XOCmuj56c8mVvtvuGJItwJJb4XBv3n3cQ2Aj/7bwaArNxUXv tPWA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=zZNq4TqU; arc=pass (i=1 spf=pass spfdomain=foss.st.com dkim=pass dkdomain=foss.st.com dmarc=pass fromdomain=foss.st.com); spf=pass (google.com: domain of linux-kernel+bounces-88249-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-88249-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id r15-20020a056402234f00b00566da1d12ddsi267416eda.572.2024.03.01.02.27.01 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 02:27:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-88249-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=zZNq4TqU; arc=pass (i=1 spf=pass spfdomain=foss.st.com dkim=pass dkdomain=foss.st.com dmarc=pass fromdomain=foss.st.com); spf=pass (google.com: domain of linux-kernel+bounces-88249-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-88249-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id DA2931F25459 for <ouuuleilei@gmail.com>; Fri, 1 Mar 2024 10:26:51 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8AD7E6BB3D; Fri, 1 Mar 2024 10:26:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=foss.st.com header.i=@foss.st.com header.b="zZNq4TqU" Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AD71723BD; Fri, 1 Mar 2024 10:26:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.132.182.106 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709288796; cv=none; b=FgnZogja+q0Or+mf6iXAjpvwahHEKF1ixxlGZER75OBsf1J+dO9nOpxDmZRBWEO/9SxmpUdWNsFkBiv3oq9ffhiEhURA3n1Vr90F6fQ7A0wdrJu7FAyR3cZ1aWd29umzO4FtglB0/840KmsiFZSvbfgFv+8GyqS1GtP3PYBYrOk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709288796; c=relaxed/simple; bh=jokYsqyurEXFxDPkRxZFI7C9kQPmyFxJWzMmRh4UsNU=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Z6V7dVUPuhIlmhK2WDbuML8ydxfUUFg7B+LMFdRZAFBFAN637JHeRn2vWX5Rj1WYWRScNHKIhZaDh9JkHwErw+DnkB3McNXOcXkub5R6EQZjp2dHktIDPOGEkbBAXco+2UHL5156t34xaEokvJF4awnUxCe0TZZRn4qdGcuwbNY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=foss.st.com; spf=pass smtp.mailfrom=foss.st.com; dkim=pass (2048-bit key) header.d=foss.st.com header.i=@foss.st.com header.b=zZNq4TqU; arc=none smtp.client-ip=185.132.182.106 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0288072.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 4219345a021497; Fri, 1 Mar 2024 11:26:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:content-type; s=selector1; bh=vp6qVxJ 487N75yXFKor9ARqDlZLKEE+aQ/uMZChldUI=; b=zZNq4TqUD3suEztwQFse5rO dyMvyXT4S5CPRCUwHnw3aAybLz3LdveJbu0AKfZWtLnXGWmga6A5CVXjExA7zFZ7 IIa9bLZahnWkwoFABBsEwmAH3Nm88Z1+b4tq4OABLc+M+fjSjwEmF4xYX6s/gCqj hm9BP/vOs7/xAADaRPBdfOqa6IzguLHLgptQbqg6Vqr8PmgJg/hd3Ho/P1g4suMm lMJQvy1n3troKACRd2vGqEuFspPnICLiSskCJpzmYuz8PbXEt+vmSwjheFST9CXU LmRsOutuRpxsa6Xlbe0W0LQ9/z4do0NQW35d9R1gHnkN55MiPmeqMPQIWg61/rw= = Received: from beta.dmz-ap.st.com (beta.dmz-ap.st.com [138.198.100.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3whf4bqdtx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Mar 2024 11:26:10 +0100 (CET) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-ap.st.com (STMicroelectronics) with ESMTP id 80BE640046; Fri, 1 Mar 2024 11:26:06 +0100 (CET) Received: from Webmail-eu.st.com (shfdag1node2.st.com [10.75.129.70]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id A80AA244B60; Fri, 1 Mar 2024 11:25:31 +0100 (CET) Received: from localhost (10.201.22.191) by SHFDAG1NODE2.st.com (10.75.129.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Fri, 1 Mar 2024 11:25:30 +0100 From: Fabrice Gasnier <fabrice.gasnier@foss.st.com> To: <william.gray@linaro.org> CC: <syednwaris@gmail.com>, <vigneshr@ti.com>, <jpanis@baylibre.com>, <alexandre.torgue@foss.st.com>, <fabrice.gasnier@foss.st.com>, <linux-iio@vger.kernel.org>, <linux-stm32@st-md-mailman.stormreply.com>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH v5] counter: Introduce the COUNTER_COMP_FREQUENCY() macro Date: Fri, 1 Mar 2024 11:25:05 +0100 Message-ID: <20240301102505.591918-1-fabrice.gasnier@foss.st.com> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SHFCAS1NODE2.st.com (10.75.129.73) To SHFDAG1NODE2.st.com (10.75.129.70) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-01_08,2024-03-01_01,2023-05-22_02 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792319235689592598 X-GMAIL-MSGID: 1792319235689592598 |
Series |
[v5] counter: Introduce the COUNTER_COMP_FREQUENCY() macro
|
|
Commit Message
Fabrice Gasnier
March 1, 2024, 10:25 a.m. UTC
Now that there are two users for the "frequency" extension, introduce a
new COUNTER_COMP_FREQUENCY() macro.
This extension is intended to be a read-only signal attribute.
Suggested-by: William Breathitt Gray <william.gray@linaro.org>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
---
Changes in v5
- "frequency" extension is read-only, so there's no need to provide
a write parameter.
- patch sent separately from "counter: Add stm32 timer events support" [1]
[1] https://lore.kernel.org/lkml/20240227173803.53906-2-fabrice.gasnier@foss.st.com/
---
include/linux/counter.h | 7 +++++++
1 file changed, 7 insertions(+)
Comments
On Fri, Mar 01, 2024 at 11:25:05AM +0100, Fabrice Gasnier wrote: > Now that there are two users for the "frequency" extension, introduce a > new COUNTER_COMP_FREQUENCY() macro. > This extension is intended to be a read-only signal attribute. > > Suggested-by: William Breathitt Gray <william.gray@linaro.org> > Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> > --- > Changes in v5 > - "frequency" extension is read-only, so there's no need to provide > a write parameter. > - patch sent separately from "counter: Add stm32 timer events support" [1] > [1] https://lore.kernel.org/lkml/20240227173803.53906-2-fabrice.gasnier@foss.st.com/ > --- > include/linux/counter.h | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/include/linux/counter.h b/include/linux/counter.h > index 702e9108bbb4..0ac36f815b7d 100644 > --- a/include/linux/counter.h > +++ b/include/linux/counter.h > @@ -602,6 +602,13 @@ struct counter_array { > #define COUNTER_COMP_FLOOR(_read, _write) \ > COUNTER_COMP_COUNT_U64("floor", _read, _write) > > +#define COUNTER_COMP_FREQUENCY(_read) \ > +{ \ > + .type = COUNTER_COMP_U64, \ > + .name = "frequency", \ > + .signal_u64_read = (_read), \ > +} > + > #define COUNTER_COMP_POLARITY(_read, _write, _available) \ > { \ > .type = COUNTER_COMP_SIGNAL_POLARITY, \ > -- > 2.25.1 Hi Fabrice, Setting the structure members directly works, but why not use COUNTER_COMP_SIGNAL_U64("frequency", _read, NULL) instead to keep the code more succinct? William Breathitt Gray
On 3/1/24 16:55, William Breathitt Gray wrote: > On Fri, Mar 01, 2024 at 11:25:05AM +0100, Fabrice Gasnier wrote: >> Now that there are two users for the "frequency" extension, introduce a >> new COUNTER_COMP_FREQUENCY() macro. >> This extension is intended to be a read-only signal attribute. >> >> Suggested-by: William Breathitt Gray <william.gray@linaro.org> >> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> >> --- >> Changes in v5 >> - "frequency" extension is read-only, so there's no need to provide >> a write parameter. >> - patch sent separately from "counter: Add stm32 timer events support" [1] >> [1] https://lore.kernel.org/lkml/20240227173803.53906-2-fabrice.gasnier@foss.st.com/ >> --- >> include/linux/counter.h | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/include/linux/counter.h b/include/linux/counter.h >> index 702e9108bbb4..0ac36f815b7d 100644 >> --- a/include/linux/counter.h >> +++ b/include/linux/counter.h >> @@ -602,6 +602,13 @@ struct counter_array { >> #define COUNTER_COMP_FLOOR(_read, _write) \ >> COUNTER_COMP_COUNT_U64("floor", _read, _write) >> >> +#define COUNTER_COMP_FREQUENCY(_read) \ >> +{ \ >> + .type = COUNTER_COMP_U64, \ >> + .name = "frequency", \ >> + .signal_u64_read = (_read), \ >> +} >> + >> #define COUNTER_COMP_POLARITY(_read, _write, _available) \ >> { \ >> .type = COUNTER_COMP_SIGNAL_POLARITY, \ >> -- >> 2.25.1 > > Hi Fabrice, > > Setting the structure members directly works, but why not use > COUNTER_COMP_SIGNAL_U64("frequency", _read, NULL) instead to keep the > code more succinct? Hi William, I originally wrote it this way, but I had a doubt since some macros use the structure members directly. I can update to use COUNTER_COMP_SIGNAL_U64() instead, that will spare few lines. Please let me know what you prefer (I guess your proposal above ?). Best Regards, Thanks, Fabrice > > William Breathitt Gray
On Mon, Mar 04, 2024 at 09:41:14AM +0100, Fabrice Gasnier wrote: > On 3/1/24 16:55, William Breathitt Gray wrote: > > On Fri, Mar 01, 2024 at 11:25:05AM +0100, Fabrice Gasnier wrote: > >> Now that there are two users for the "frequency" extension, introduce a > >> new COUNTER_COMP_FREQUENCY() macro. > >> This extension is intended to be a read-only signal attribute. > >> > >> Suggested-by: William Breathitt Gray <william.gray@linaro.org> > >> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> > >> --- > >> Changes in v5 > >> - "frequency" extension is read-only, so there's no need to provide > >> a write parameter. > >> - patch sent separately from "counter: Add stm32 timer events support" [1] > >> [1] https://lore.kernel.org/lkml/20240227173803.53906-2-fabrice.gasnier@foss.st.com/ > >> --- > >> include/linux/counter.h | 7 +++++++ > >> 1 file changed, 7 insertions(+) > >> > >> diff --git a/include/linux/counter.h b/include/linux/counter.h > >> index 702e9108bbb4..0ac36f815b7d 100644 > >> --- a/include/linux/counter.h > >> +++ b/include/linux/counter.h > >> @@ -602,6 +602,13 @@ struct counter_array { > >> #define COUNTER_COMP_FLOOR(_read, _write) \ > >> COUNTER_COMP_COUNT_U64("floor", _read, _write) > >> > >> +#define COUNTER_COMP_FREQUENCY(_read) \ > >> +{ \ > >> + .type = COUNTER_COMP_U64, \ > >> + .name = "frequency", \ > >> + .signal_u64_read = (_read), \ > >> +} > >> + > >> #define COUNTER_COMP_POLARITY(_read, _write, _available) \ > >> { \ > >> .type = COUNTER_COMP_SIGNAL_POLARITY, \ > >> -- > >> 2.25.1 > > > > Hi Fabrice, > > > > Setting the structure members directly works, but why not use > > COUNTER_COMP_SIGNAL_U64("frequency", _read, NULL) instead to keep the > > code more succinct? > > Hi William, > > I originally wrote it this way, but I had a doubt since some macros use > the structure members directly. Ah yes, the macros that use the members directly are typically the ones that are unique for their particular type. For example, the enum constant type COUNTER_COMP_COUNT_DIRECTION will only ever be used with the COUNTER_COMP_DIRECTION() macro. For macros that are based on general types such as COUNTER_COMP_U64, it's better to use the respective base macro such as COUNTER_COMP_SIGNAL_U64(). Not only is this more succinct and clearer of the intent, if the need arises in the future it allows us to upgrade the the underlying base macro and have those changes propagate to the macros that utilize it. > > I can update to use COUNTER_COMP_SIGNAL_U64() instead, that will spare > few lines. > > Please let me know what you prefer (I guess your proposal above ?). > > Best Regards, > Thanks, > Fabrice Update to use COUNTER_COMP_SIGNAL_U64() instead, and I should be able to pick it up quickly. Thanks, William Breathitt Gray
diff --git a/include/linux/counter.h b/include/linux/counter.h index 702e9108bbb4..0ac36f815b7d 100644 --- a/include/linux/counter.h +++ b/include/linux/counter.h @@ -602,6 +602,13 @@ struct counter_array { #define COUNTER_COMP_FLOOR(_read, _write) \ COUNTER_COMP_COUNT_U64("floor", _read, _write) +#define COUNTER_COMP_FREQUENCY(_read) \ +{ \ + .type = COUNTER_COMP_U64, \ + .name = "frequency", \ + .signal_u64_read = (_read), \ +} + #define COUNTER_COMP_POLARITY(_read, _write, _available) \ { \ .type = COUNTER_COMP_SIGNAL_POLARITY, \