linux-kernel - Re: [PATCH v7 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <695b1680-9e5a-89bd-bd3b-e794200587dc@opensynergy.com>
Date:   Thu, 11 Mar 2021 10:55:48 +0100
From:   Peter Hilber <peter.hilber@...nsynergy.com>
To:     Jyoti Bhayana <jbhayana@...gle.com>
CC:     Jonathan Cameron <jic23@...nel.org>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Rob Herring <robh@...nel.org>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        <linux-kernel@...r.kernel.org>, <linux-iio@...r.kernel.org>,
        Cristian Marussi <cristian.marussi@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Enrico Granata <egranata@...gle.com>,
        Mikhail Golubev <mikhail.golubev@...nsynergy.com>,
        Igor Skalkin <Igor.Skalkin@...nsynergy.com>,
        Ankit Arora <ankitarora@...gle.com>,
        Guru Nagarajan <gurunagarajan@...gle.com>,
        kernel test robot <lkp@...el.com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH v7 1/1] iio/scmi: Adding support for IIO SCMI Based
 Sensors

On 10.03.21 18:19, Jyoti Bhayana wrote:
> Hi Peter,
> 
> As already discussed with ARM, the spec clearly mentions that it has
> to be uppercase and not case insensitive. So this patch is consistent
> with the specs and changing it with means that the spec would need to
> change as well. Therefore, there is no need for another version of the
> patch
> 
> "A NULL terminated UTF-8 format string with the sensor axis name, of
> up to 16 bytes. It is recommended that the name ends with ‘_’ followed
> by the axis of the sensor in uppercase.
> For example, the name for the x-axis of a triaxial accelerometer could
> be “acc_X” or “_X"
> 

My understanding of the part of the spec quoted above is different: The
spec only makes a recommendation and does allow additional or even
contradictory sensor axis naming schemes. So the change to the
implementation only would in principle be possible (disregarding
integration timeline constraints).

Best regards,

Peter

> Thanks,
> Jyoti
> 
> On Wed, Mar 10, 2021 at 3:16 AM Peter Hilber
> <peter.hilber@...nsynergy.com> wrote:
>>
>> On 10.03.21 00:12, Jyoti Bhayana wrote:
>>> This change provides ARM SCMI Protocol based IIO device.
>>> This driver provides support for Accelerometer and Gyroscope using
>>> SCMI Sensor Protocol extensions added in the SCMIv3.0 ARM specification
>>>
>>
>> [snip]
>>
>>> +
>>> +static int scmi_iio_get_chan_modifier(const char *name,
>>> +                                   enum iio_modifier *modifier)
>>> +{
>>> +     char *pch, mod;
>>> +
>>> +     if (!name)
>>> +             return -EINVAL;
>>> +
>>> +     pch = strrchr(name, '_');
>>> +     if (!pch)
>>> +             return -EINVAL;
>>> +
>>> +     mod = *(pch + 1);
>>> +     switch (mod) {
>>> +     case 'X':
>>> +             *modifier = IIO_MOD_X;
>>> +             return 0;
>>> +     case 'Y':
>>> +             *modifier = IIO_MOD_Y;
>>> +             return 0;
>>> +     case 'Z':
>>> +             *modifier = IIO_MOD_Z;
>>> +             return 0;
>>> +     default:
>>> +             return -EINVAL;
>>> +     }
>>> +}
>>> +
>>
>> Hi Jyoti,
>>
>> could you still change the above code to also accept lower case 'x',
>> 'y', 'z'?
>>
>> Supporting lower case as well would establish compatibility with the
>> lower case naming conventions used for IIO channels. By this change,
>> channels could be forwarded without name changes (as long as they fit
>> into the name field). I'm sorry to notice this only now.
>>
>> Best regards,
>>
>> Peter
>>
>