On Mon, 4 Jan 2021 15:45:07 +0100 Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Mon, Dec 14, 2020 at 5:34 PM Jonathan Cameron > <Jonathan.Cameron@xxxxxxxxxx> wrote: > > On Mon, 14 Dec 2020 16:30:22 +0100 Peter Rosin <peda@xxxxxxxxxx> wrote: > > > > >> And that gets transformed by the > > > >> rescaler into the processed values being presented as raw, with rescaling > > > >> added on top, but with the read_avail info for this new raw channel being > > > >> completely wrong. > > > >> > > > >> For the intended driver (ab8500-gpadc) this is not the case (it has no > > > >> read_avail for its raw channel). But it does have a raw channel, so adding > > > >> read_avail seems easy and I can easily see other drivers already doing it. > > > >> Haven't checked that though... > > > > > > > > Drat. I'd failed to register this is one of those corner cases. > > > > > > I'm not sure, I just browsed the code. Maybe I misread it? > > > > It's doing both - you were right. I think there are only a small number of > > drivers that have that history. > > > > Looks superficially like it's easy enough to catch this corner case and > > block it - so lets do that. > > Sorry if I am a bit confused here. I don't understand what I am supposed > to do to proceed with using this driver with the ab8500 GPADC... > > Shall I fix something in the AB8500 GPADC as a prerequisite? > In that case I think I need some more pointers... I confess I'm a bit lost, but I 'think' the problem we had left was around read_avail which doesn't play well if we it defined for the _raw value in the provider, but not the _processed value. So if we detect their is a _processed channel (which we are going to use) we just need to make sure that we don't pass the read_avail for _raw through to be exposed by the rescale driver as the consumer as it will be garbage. Best plan is probably to just pretend the read_avail for the provider doesn't exist in this case. @Peter, does that cover it of are there other similar cases? It definitely also wants a big fat comment saying why we are hiding this! Jonathan > > Yours, > Linus Walleij
