From: Peter Hilber <peter.hilber@opensynergy.com>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: mikhail.golubev@opensynergy.com, Igor.Skalkin@opensynergy.com,
jbhayana@google.com, sudeep.holla@arm.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, james.quinlan@broadcom.com,
Jonathan.Cameron@Huawei.com, egranata@google.com,
lukasz.luba@arm.com
Subject: Re: [PATCH v2 2/6] firmware: arm_scmi: add SCMIv3.0 Sensors descriptors extensions
Date: Tue, 10 Nov 2020 18:50:04 +0100 [thread overview]
Message-ID: <a51fecaa-4495-6d8e-9b16-598bbe47b1cd@opensynergy.com> (raw)
In-Reply-To: <20201110172120.GF42652@e120937-lin>
Hi Cristian,
sorry, I mistakenly used the wrong sender ("Mailing Lists") for the
original comment mail. Please see below for my reply.
On 10.11.20 18:21, Cristian Marussi wrote:
> On Tue, Nov 10, 2020 at 05:00:05PM +0100, Mailing Lists wrote:
>> On 26.10.20 21:10, Cristian Marussi wrote:
>>> Add support for new SCMIv3.0 Sensors extensions related to new sensors'
>>> features, like multiple axis and update intervals, while keeping
>>> compatibility with SCMIv2.0 features.
>>> While at that, refactor and simplify all the internal helpers macros and
>>> move struct scmi_sensor_info to use only non-fixed-size typing.
>>>
>>> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
>>> ---
>>> v1 --> v2
>>> - restrict segmented intervals descriptors to single triplet
>>> - add proper usage of scmi_reset_rx_to_maxsz
>>> ---
>>> drivers/firmware/arm_scmi/sensors.c | 391 ++++++++++++++++++++++++++--
>>> include/linux/scmi_protocol.h | 219 +++++++++++++++-
>>> 2 files changed, 584 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/drivers/firmware/arm_scmi/sensors.c b/drivers/firmware/arm_scmi/sensors.c
>>> index 6aaff478d032..5a18f8c84bef 100644
>>> --- a/drivers/firmware/arm_scmi/sensors.c
>>> +++ b/drivers/firmware/arm_scmi/sensors.c
>>> @@ -7,16 +7,21 @@
>>>
>>> #define pr_fmt(fmt) "SCMI Notifications SENSOR - " fmt
>>>
>>> +#include <linux/bitfield.h>
>>> #include <linux/scmi_protocol.h>
>>>
>>> #include "common.h"
>>> #include "notify.h"
>>>
>>> +#define SCMI_MAX_NUM_SENSOR_AXIS 64
>>
>> IMHO the related 6 bit wide fields, like SENSOR_DESCRIPTION_GET "Number
>> of axes", should determine the maximum value, so 64 -> 63.
>>
>
> Yes, bits [21:16] 'Number of Axes' in sensor_attributes_high, but this
> #define was meant to represent the maximum number of sensor axis (64...ranging
> from 0 to 63) not the highest possible numbered (63).
>
But in my understanding the actual maximum number of sensor axes is 63
due to the maximum value 63 of 'Number of Axes', 64 would overflow
already. The ids would range from 0 to 62.
That said, in my understanding there is no problem with retaining a
higher value ATM.
Best regards,
Peter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-11-10 17:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 20:10 [PATCH v2 0/6] SCMIv3.0 Sensor Extensions Cristian Marussi
2020-10-26 20:10 ` [PATCH v2 1/6] firmware: arm_scmi: rework scmi_sensors_protocol_init Cristian Marussi
2020-10-26 20:10 ` [PATCH v2 2/6] firmware: arm_scmi: add SCMIv3.0 Sensors descriptors extensions Cristian Marussi
2020-11-10 16:00 ` Mailing Lists
2020-11-10 17:21 ` Cristian Marussi
2020-11-10 17:50 ` Peter Hilber [this message]
2020-11-10 19:19 ` Cristian Marussi
2020-10-26 20:10 ` [PATCH v2 3/6] hwmon: scmi: update hwmon internal scale data type Cristian Marussi
2020-10-26 20:10 ` [PATCH v2 4/6] firmware: arm_scmi: add SCMIv3.0 Sensors timestamped reads Cristian Marussi
2020-11-10 16:01 ` Peter Hilber
2020-11-10 17:04 ` Cristian Marussi
2020-11-10 17:14 ` Peter Hilber
2020-10-26 20:10 ` [PATCH v2 5/6] firmware: arm_scmi: add SCMIv3.0 Sensor configuration support Cristian Marussi
2020-10-26 20:10 ` [PATCH v2 6/6] firmware: arm_scmi: add SCMIv3.0 Sensor notifications Cristian Marussi
2020-11-10 16:01 ` Peter Hilber
2020-11-10 17:09 ` Cristian Marussi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a51fecaa-4495-6d8e-9b16-598bbe47b1cd@opensynergy.com \
--to=peter.hilber@opensynergy.com \
--cc=Igor.Skalkin@opensynergy.com \
--cc=Jonathan.Cameron@Huawei.com \
--cc=cristian.marussi@arm.com \
--cc=egranata@google.com \
--cc=james.quinlan@broadcom.com \
--cc=jbhayana@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=mikhail.golubev@opensynergy.com \
--cc=sudeep.holla@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox