> > > Also commit message you can aim to wrap at 75 chars as per > > > submitting-patches.rst. > > > > > > > + return -ENODATA; > > > > > > Is this a new exit condition or the thing would exit on the !num_regs > > > check below anyway? Just wondering if the series is only about logging > > > changes or there is more to it. > > Its no different from previous behavior - and yes its about logging the > > missing reg lists for hw that needs it as we are > > missing this for DG2 we we didn't notice (we did a previous revert to > > remove these warnings but that time the warnings > > was too verbose - even complaining for the intentional empty lists and for > > VF cases that isnt supported). > > Okay think I get it, thanks. If the "positive match" logging of empty > list is more future proof than "negative - don't log these" you will > know better.
NOTE: John and I had an offline conversation and we are aware that there will still be a case where we can miss new-platform updates for guc-error-capture without being alerted by a warning: Let's take the example of the empty blitter's engine-class-register-list. We dont have such a thing on today's hardware.. we only have blitter's engine-register-list ... i.e. HEAD, TAIL etc. But if a future platform were to introduce a blitter engine-class-register-list, we wont get a warning since the empty list is there to prevent unnecessary warning for today's hardware. But we know this is better than having to explain unnecessary warnings (which was the reason why a more verbose version of this code was removed in the past). I believe we are good with this solution here for now.
