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. > > --- > > drivers/iio/temperature/mlx90632.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/iio/temperature/mlx90632.c b/drivers/iio/temperature/mlx90632.c > > index 37edd324d6a1..d511d36942d3 100644 > > --- a/drivers/iio/temperature/mlx90632.c > > +++ b/drivers/iio/temperature/mlx90632.c > > @@ -435,7 +435,7 @@ static int mlx90632_channel_new_select(int perform_ret, uint8_t *channel_new, > > *channel_old = 1; > > break; > > default: > > - return -EINVAL; > > + return -ECHRNG; > > } > > > > return 0; >
