Re: [PATCH v7 06/10] iio: adc: Support ROHM BD79124 ADC
From: Jonathan Cameron
Date: Sun Mar 30 2025 - 12:04:54 EST
On Mon, 17 Mar 2025 13:24:07 +0200
Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote:
> On 16/03/2025 13:02, Jonathan Cameron wrote:
> > On Thu, 13 Mar 2025 09:19:03 +0200
> > Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote:
>
> ...
>
> >> +static int bd79124_write_int_to_reg(struct bd79124_data *data, int reg,
> >> + unsigned int val)
> > ..
> >> +static int bd79124_read_event_config(struct iio_dev *iio_dev,
> >> + const struct iio_chan_spec *chan,
> >> + enum iio_event_type type,
> >> + enum iio_event_direction dir)
> >> +{
> >> + struct bd79124_data *data = iio_priv(iio_dev);
> >> +
> >> + if (chan->channel >= BD79124_MAX_NUM_CHANNELS)
> >> + return -EINVAL;
> >> +
> >> + return (data->alarm_monitored[chan->channel] & BIT(dir));
> >
> > Drop the outer brackets as not adding anything.
>
> I just noticed that the integer returned from here is directly provided
> to the user-space. I don't know the history, but it feels a bit off to
> me. I mean, I would expect the read from sysfs file "*_en" to return '1'
> or '0' - not 0x04.
>
> Oh well, I suppose it's too late to change this in the IIO core - but
> I'll do:
> return !!(data->alarm_monitored[chan->channel] & BIT(dir));
Agreed it should be returning 1 or 0.
This stuff is a little bit messy. I'd not be against that ABI
cleanup if we squashed the values to 0,1 in the core as a follow up.
I doubt anyone relies on getting 0x4 as that would be very driver
specific userspace code!
Jonathan
>
> in v8.
>
>
> Yours,
> -- Matti