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. -- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel