Re: [PATCH v3 3/5] thermal: rockchip: fixes invalid temperature case

From: Eduardo Valentin
Date: Wed Nov 30 2016 - 01:27:27 EST


Hello,

On Tue, Nov 29, 2016 at 09:59:28PM -0800, Brian Norris wrote:
> On Tue, Nov 29, 2016 at 09:02:42PM -0800, Eduardo Valentin wrote:
> > On Tue, Nov 29, 2016 at 01:57:45PM -0800, Brian Norris wrote:
> > > I was thinking while reviewing that the binary search serves more to
> > > complicate things than to help -- it's much harder to read (and validate
> > > that the loop termination logic is correct). And searching through a few
> > > dozen table entries doesn't really get much benefit from a O(n) ->
> > > O(log(n)) speed improvement.
> >
> > true. but if in your code path you do several walks in the table just to
> > check if parameters are valid, given that you could simply decide if
> > they are valid or not with simpler if condition, then, still worth, no?
> > :-)
>
> Yes, your suggestions seems like they would have made the code both (a
> little) more straightforward and efficient. But...
>
> > > Anyway, I'm not sure if you were thinking along the same lines as me.
> > >
> >
> > Something like that, except I though of something even simpler:
> > + if ((temp % table->step) != 0)
> > + return -ERANGE;
> >
> > If temp passes that check, then you go to the temp -> code conversion.
>
> ...that check isn't valid as of patch 4, where Caesar adds handling for
> intermediate steps. We really never should have been strictly snapping
> to the 5C steps in the first place; intermediate values are OK.
>
> So, we still need some kind of search to find the right step -- or
> closest bracketing range, to compute the interpolated value. We should
> only reject temperatures that are too high or too low for the ADC to
> represent.

Ok. got it. check small comment on patch 4 then.

>
>
> --- Side track ---
>
> BTW, when we're considering rejecting temperatures here: shouldn't this
> be fed back to the upper layers more nicely? We're improving the error
> handling for this driver in this series, but it still leaves things
> behaving a little odd. When I tested, I can do:
>
> ## set something obviously way too high
> echo 700000 > trip_point_X_temp
>
> and get a 0 (success) return code from the sysfs write() syscall, even
> though the rockchip driver rejected it with -ERANGE. Is there really no
> way to feed back thermal range limits of a sensor to the of-thermal
> framework?
>

well, that is a bit strange to me. Are you sure you are returning the
-ERANGE? Because, my assumption is that the following of-thermal code
path would return the error code back to core:
328 if (data->ops->set_trip_temp) {
329 int ret;
330
331 ret = data->ops->set_trip_temp(data->sensor_data, trip, temp);
332 if (ret)
333 return ret;
334 }

And this part of thermal core would return it back to sysfs layer:
757 ret = tz->ops->set_trip_temp(tz, trip, temperature);
758 if (ret)
759 return ret;

or am I missing something?

> Brian