On Sat, Jul 23, 2016 at 1:30 AM, Viresh Kumar <[email protected]> wrote: > On 22-07-16, 23:46, Rafael J. Wysocki wrote: >> On Friday, July 22, 2016 02:28:52 PM Viresh Kumar wrote: >> > On 22-07-16, 23:31, Rafael J. Wysocki wrote: >> > > > cpufreq.c >> > > > >> > > > if (policy->governor->max_transition_latency && >> > > > policy->cpuinfo.transition_latency > >> > > > policy->governor->max_transition_latency) { >> > > > >> > > > - And this check will always fail, unless max_transition_latency is >> > > > zero. >> > > >> > > Why would it fail? If governor->max_transition_latency is non-zero, but >> > > less >> > > than UNIT_MAX, the condition checked will be true to my eyes. >> > >> > Bad wording. Sorry. >> > >> > I meant, this 'if' check will always succeed (as you also noted), and >> > so we will always get the error message reported in this patch. >> >> Not always, but for drivers setting cpuinfo.transition_latency to >> CPUFREQ_ETERNAL. > > So the drivers which have set their transition_latency to > CPUFREQ_ETERNAL, can't use ondemand governor unless > governor->max_transition_latency is set to 0 from userspace. > > What should be done about this patch then ? It broke in late 2015.
I'll apply the revert with a "Cc: stable" tag. Question is what to do about the other drivers setting cpuinfo.transition_latency to CPUFREQ_ETERNAL. Thanks, Rafael
