[flashrom] DMI matching patch

[Carl-Daniel Hailfinger]

On 07.01.2010 16:46, Luc Verhaegen wrote:
> I do not expect DMI many match policy changes.
>
> * We've been relatively happy with pci subsystem ids for close to three 
>   years.
>   

Yes, but that isn't a match-any policy either. The subsystem ID in the
table must come from the same device as the main ID.


> * Our board enable table recently exploded, with the massive increase in 
>   flashrom uptake.

Yes, and I'm very happy about that.


>   But expect 30-40% of the board enables to be dropped 
>   soon (it8705f, w83627thf and itspi will be moved out), which will 
>   equally reduce our need to add entries to this table in future.
>   

Right.


> * Even then a very large proportion of the boards is and will be happy 
>   with just pci subsystem ids.
>   

Right.


> * 10-20% will be happy with pciids or pci subsystem ids and a simple DMI 
>   match.
>
> A few percent, which we still have to encounter in our board enable 
> table, will never be happy (like my jetway boards), and will always need 
> -m.
>
> The case where we need to match multiple strings just to be able to 
> identify a board also needs to happen still.
>   

OK, so let's archive all interesting DMI strings on the list so we can
investigate any overlaps that might happen in the future.

I would still like the match to be specific, though.


> Let us consider a board where subsystem ids are just copied from the 
> main ids (which is an issue of the bios, as the pci device default 
> might either be 0 or copied depending on implemention).
>
> Let's look at some use cases:
>
> 1)
>
> 0x1234, 0x5678, 0x1234, 0x5678,  0x1234, 0x5679, 0x1234, 0x5679
>
> If 0x1234 is a popular manufacturer, and the 5678/5679 northbridge 
> southbridge configuration is a popular product, then chances are that 
> a few bad manufacturers really are this bad. But you will not find more 
> than 2-3 vendors doing things this badly, at least not for the same 
> chips. Chances are then very very high that the model name is unique, or 
> that we can at least match the vendor.
>   

Note that our current DMI policy allows only either a vendor match or a
board match, not both of them.


> 2)
>
> If we have the following for board maker 0xABCD:
>
> 0x1234, 0x5678, 0xABCD, 0x5678,  0x1234, 0x5679, 0xABCD, 0x5679
>
> Then the match becomes a lot more unique already, and we should be able 
> to easily get away with just the DMI product id.
>   

Fully agreed.


> 3)
>
> Even for a vendor who creates tons of boards with the same subsystem 
> ids (and we know one which requires itspi a lot :)):
>
> 0x1234, 0x5678, 0xABCD, 0xEF12,  0x1234, 0x5679, 0xABCD, 0xEF12
>
> We can then try to use the DMI product to differentiate the boards 
> further (when choosing different pciids doesn't work, often due to added 
> raid or gigE, that is). Here the string wildcard matching will help us 
> out a lot, while the string selection will not.
>
> This pretty much maps all three situations, and a combination thereof 
> seems possible.
>
> Now go back and try to see what "bvbp:^DEVICE$:^PRODUCT$" will gain us 
> on top.
>
> My current answer to this: not much.
>   

Yes, the multi-match with "bvbp:foo:bar" is something I do not want
supported in current code. It may be useful sometime in the future, but
for now I want to avoid such matches (and we seem to agree here).


> Let's just see how it works out with simple matching with wildcards.
>
> We will be collecting the data, and when needed, when a valid case 
> turns up, we can expand.
>   

Do you remember the pain you felt when going through old board enables
which had missing subsystem IDs because back then people didn't
care/know? Sure, there's always the possibility to dig through the
mailing list archives, but it is rather painful. By specifying the
string to be matched, I hope to avoid such pains in the future.

To summarize:
- Specifying more than one DMI string for one board is hopefully
something we will never have to do.
- Not specifying which DMI string to match will be painful in case we
ever have to adapt our DMI infrastructure.

Regards,
Carl-Daniel

-- 
Developer quote of the year:
"We are juggling too many chainsaws and flaming arrows and tigers."