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;
MIME-Version: 1.0
References: <20220903222422.3426156-1-cmo@melexis.com> <20220904154923.33b79d83@jic23-huawei>
 <CAKv63uviUbiAy6tYjkqFP-Qgs7dwAV5BPrr2aTTxQyjPBeA+Og@mail.gmail.com> <20220904165634.5cde87fd@jic23-huawei>
In-Reply-To: <20220904165634.5cde87fd@jic23-huawei>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Sun, 4 Sep 2022 22:19:43 +0300
Message-ID: <CAHp75VdVLO5J-S7PPupJv0K0T5UAovCUP_0ZobyKaoHHtE-YuQ@mail.gmail.com>
Subject: Re: [PATCH v2 3/3] iio: temperature: mlx90632 Change return value of
 sensor measurement channel
To:     Jonathan Cameron <jic23@kernel.org>
Cc:     Crt Mori <cmo@melexis.com>, linux-iio <linux-iio@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, Sep 4, 2022 at 7:30 PM Jonathan Cameron <jic23@kernel.org> wrote:
> On Sun, 4 Sep 2022 17:27:28 +0200
> Crt Mori <cmo@melexis.com> wrote:
> > On Sun, 4 Sept 2022 at 17:23, Jonathan Cameron <jic23@kernel.org> wrote:
> > > On Sun,  4 Sep 2022 00:24:22 +0200
> > > cmo@melexis.com wrote:
> > >
> > > > From: Crt Mori <cmo@melexis.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@melexis.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