linux-kernel - Re: [PATCH v2 3/3] iio: temperature: mlx90632 Change return value of sensor measurement channel

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] [day] [month] [year] [list]

Message-ID: <CAHp75VdVLO5J-S7PPupJv0K0T5UAovCUP_0ZobyKaoHHtE-YuQ@mail.gmail.com>
Date:   Sun, 4 Sep 2022 22:19:43 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Jonathan Cameron <jic23@...nel.org>
Cc:     Crt Mori <cmo@...exis.com>, linux-iio <linux-iio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] iio: temperature: mlx90632 Change return value of
 sensor measurement channel

On Sun, Sep 4, 2022 at 7:30 PM Jonathan Cameron <jic23@...nel.org> wrote:
> On Sun, 4 Sep 2022 17:27:28 +0200
> Crt Mori <cmo@...exis.com> wrote:
> > On Sun, 4 Sept 2022 at 17:23, Jonathan Cameron <jic23@...nel.org> wrote:
> > > On Sun,  4 Sep 2022 00:24:22 +0200
> > > cmo@...exis.com wrote:
> > >
> > > > From: Crt Mori <cmo@...exis.com>
> > > >
> > > > The current EINVAL value is more applicable to embedded library, where
> > > > user can actually put the fixed value to the sensor. In case of the
> > > > driver if the value of the channel is invalid it is better in inform
> > > > userspace that Channel was out of range as that implies more to internal
> > > > driver error than invalid input. It also makes for easier debugging of
> > > > where the error comes from during the development.
> > > >
> > > > Signed-off-by: Crt Mori <cmo@...exis.com>
> > > Hmm. That's an obscure return value - I think it's mostly going to confuse
> > > anyone who ever gets it.  So not sure this change is wise even though the
> > > descriptive text for that one does seem very much suited to this usecase.
> > >
> > I did get it few times during the development due to read when sensor
> > is not busy, but the measurement data not yet updated correctly due to
> > powermode switch. I think I added enough delays all around to avoid
> > hitting it and with proper power mode switching, but there might be a
> > case, so it will be easier to spot in the source code in future. I
> > would not remove it, if that is what you are proposing.
>
> I meant leave it as EINVAL. The users of ECHRNG are very very
> few in number, so I don't have a good understanding of it's expected
> uses..

The problem with EINVAL is that it happens in 95% of error cases and
you really need to rebuild the module to get it where it occurs. I
kinda tend to acknowledge the patch, because we still miss the JSON
error reporting in the kernel which would fix most annoying problems
with debugging kernel code.

-- 
With Best Regards,
Andy Shevchenko