Re: [PATCH 3/3] iio: light: stk3310: support the Sensortek STK36C61

Jorijn van der Graaf <[email protected]>
Newsgroups org.kernel.vger.linux-hardening,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-iio,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On Mon, Aug 10, 2026 at 09:37:21PM +0300, Andy Shevchenko wrote:
> > -	if (chan->type != IIO_LIGHT && chan->type != IIO_PROXIMITY)
> > +	if (chan->type != IIO_LIGHT && chan->type != IIO_PROXIMITY &&
> > +	    chan->type != IIO_INTENSITY)
> >  		return -EINVAL;
>
> Is this now a duplicating a bit with the below choices?

A bit, in the int_time and scale arms. The check at the top is
pre-existing (this patch only adds IIO_INTENSITY to it) and is the
only type filter for the RAW case, which serves all three types
through chan->address with no per-type branching of its own.

> >  	case IIO_CHAN_INFO_INT_TIME:
> >  		if (chan->type == IIO_LIGHT)
> >  			ret = regmap_field_read(data->reg_als_it, &index);
> > -		else
> > +		else if (chan->type == IIO_PROXIMITY)
> >  			ret = regmap_field_read(data->reg_ps_it, &index);
> > +		else
> > +			return -EINVAL;
>
> If you want to keep a single point of return, use
>
> 			ret = -EINVAL;
>
> here and below in _read_raw().

Neither of the new else branches is reachable today: the colour
channels declare RAW only, so no int_time or scale attribute exists
for them, and in-kernel readers are gated by iio_channel_has_info().
I would rather keep them than have a bare else read as proximity for
a colour channel. v2 writes them with ret = -EINVAL as you suggest,
falling into the existing if (ret < 0) return ret.

Thanks,
Jorijn
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.