> Hi Abhash, > > I think I managed to confuse things with earlier reviews. > > We want a light channel here, but because the scaling is just linear > we want to provide it as in_illuminance_raw and in_illumiance_scale, > not a processed channel. > > Sometimes we have no alternative to a processed channel (typically non > linear maths) but when we can present the scaling via _scale (and > if needed _offset) then we do that. This avoids a bunch of future > problems: > 1 - Processed channels are a pain for buffered capture because they > often need a lot more bits to store. > 2 - Any events on this channel tend to require fiddly reverse lookups > to get from processed to the raw value that needs to be written > to the device. > > Also note we very rarely provide both processed and raw for a channel. > The only exceptions are corner cases such as having to maintain ABI > that we should have never have introduced in the first place. > > A few other comments inline. > > > Jonathan > Hi Jonathan, I have made the changes, can you look it over and tell me if it looks good. Link for v7: https://lore.kernel.org/linux-iio/20240804142321.54586-1-abhashkumarjha123@xxxxxxxxx/T/#t Thanks, Abhash
