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