amdsmu: Fix model-specific matching

[olce]

Summary

For Krackan Point, model-specific matching would not work because
amdsmu_match() browses amdsmu_products[] in order and returns the first
match, and the Krackan Point's 'struct amdsmu_product' object variant
with a 'model' field of 0, indicating that any model matches, is listed
before the variant with model 0x70 in amdsmu_products[].

In practice, this means that reporting of IP blocks for Krackan Point
model 0x70 only was broken. Specifically, not all the existing blocks
were reported and most statistics were not attributed to the right
blocks.

Fix this by making amdsmu_match() parse amdsmu_products[] in reverse, so
model-generic entries can continue to appear first.

While here, since the CPU model is between 0 and 255, change the type
used for CPU models to an 'int' and use the special value -1 to skip
model match, as there exist CPUs reporting 0 as the model (even if, to
our knowledge, only old CPUs seem to be doing that).

While here, fix alignement and whitespace in amdsmu_products[]'s
initializers.

Fixes: 9c77fb6aaa36 ("amdsmu: Add Krackan Point support")

[obiwac]

does it not make more sense to go through amdsmu_products forwards and just reverse the list? then the list can read more naturally as "the product will be the first one that matches an element in this list"

[olce]

In D59788#1372277, @obiwac wrote:

does it not make more sense to go through amdsmu_products forwards and just reverse the list? then the list can read more naturally as "the product will be the first one that matches an element in this list"

My first version was actually doing that, but then I had to exchange the two Krackan Point lines and looking at the result, it felt odd to have 0x70 before 0x0 (or -1 after my change), with the number of IP blocks of 0x70 being greater.

I also reasoned that, going forward, we would probably be first adding support for a new generation, and then only refine it per model as necessary, in a kind of chronological order, so reading from the end would probably allow to most of the time add new refinements at the end of the array instead of before existing entries (except of course in the case of model refinement for older platforms, but then the alternative has the same problem).

[obiwac]

ok, that works for me!