On Wed, Feb 21, 2018 at 2:13 PM, Michael Ellerman [off-list ref] wrote:

"Rafael J. Wysocki" [off-list ref] writes:

quoted

On Wed, Feb 21, 2018 at 6:54 AM, Viresh Kumar [off-list ref] wrote:

quoted

On 21-02-18, 16:39, Michael Ellerman wrote:

quoted

Viresh Kumar [off-list ref] writes:

quoted

quoted

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.