On Wed, May 05, 2021 at 07:18:30AM -0700, Andi Kleen wrote:
Increase all the latency fields to 8 members, which is enough for SKL.
I don't know if they are correctly initialized upto 8, but dev_priv should start out as zero, so presumably they will be zero.
Thanks, the warning should be fixed by commit
c6deb5e97ded ("drm/i915/pm: Make the wm parameter of print_wm_latency a pointer")
in drm-intel-next.
That's just hiding the problem.
There doesn't actually seem to be a bug here,
Can you explain that please?
This is the loop in question
max_level = ilk_wm_max_level(dev_priv);
for (level = 0; level <= max_level; level++) { unsigned int latency = wm[level]; if (latency == 0) { drm_dbg_kms(&dev_priv->drm, "%s WM%d latency not provided\n", name, level); continue; } ...}
(no other loop termination condition)
and ilk_wm_max_level is
int ilk_wm_max_level(const struct drm_i915_private *dev_priv) { /* how many WM levels are we expecting */ if (INTEL_GEN(dev_priv) >= 9) return 7; else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) return 4; else if (INTEL_GEN(dev_priv) >= 6) return 3; else return 2; }
There is no loop termination in the loop above, it will always read every member through the max level reported. And on GEN>=9 it will be 7, while the input array for several of the cases has only 5 members.
So it will read beyond the array and gcc is correct in complaining.
What do I miss when you say there is no bug?
We always use dev_priv->wm.skl_latency[] for gen9+. See {pri,spr,cur}_wm_latency_show(), skl_setup_wm_latency(), etc.