On Wed, Feb 21, 2018 at 2:13 PM, Michael Ellerman <m...@ellerman.id.au> wrote: > "Rafael J. Wysocki" <raf...@kernel.org> writes: > >> On Wed, Feb 21, 2018 at 6:54 AM, Viresh Kumar <viresh.ku...@linaro.org> >> wrote: >>> On 21-02-18, 16:39, Michael Ellerman wrote: >>>> Viresh Kumar <viresh.ku...@linaro.org> writes: >>> >>>> > AFAICT, you will get -1 here only if the freq table had no valid >>>> > frequencies (or the freq table is empty). Why would that happen ? >>>> >>>> Bugs? >>> >>> The cupfreq driver shouldn't have registered itself in that case (i.e. >>> if the cpufreq table is empty). >> >> To be precise, ->init() should fail as that's where the table is >> created. The registration fails as a result then. >> >> But what if the bug is that ->init() doesn't fail when it should? >> >> I guess the core could double check the frequency table after ->init() >> if ->target_index is not NULL. >> >> The overall point here is that if you get a negative index in >> ->fast_switch(), that's way too late anyway and we should be able to >> catch that error much earlier. > > OK. > > Still it's one thing for the driver to print a warning and bail out, > it's another to access off the front of an array and keep running using > some junk values, or oops (though not in this case because the array > happens to be static).
Well, let me rephrase. If ->fast_switch() runs, then it must not be possible to get a negative index in it. That has to be guaranteed by the core.
