[flashrom] DMI matching patch

Luc Verhaegen libv at skynet.be
Thu Jan 7 16:46:37 CET 2010


On Thu, Jan 07, 2010 at 04:01:10PM +0100, Carl-Daniel Hailfinger wrote:
> On 07.01.2010 15:47, Luc Verhaegen wrote:
> > On Thu, Jan 07, 2010 at 03:37:04PM +0100, Carl-Daniel Hailfinger wrote:
> >   
> >> On 07.01.2010 11:16, Michael Karcher wrote:
> >>     
> >>>   
> >>> That's what I expected, and that's why I didn't commit yet. I won't
> >>> commit until you and Carl-Daniel agree on the necessity of providing
> >>> which string to match, although I slightly prefer the explicit
> >>> specification of the string to match.
> >>>   
> >>>       
> >> The explicit string match has the advantage of being extensible. More below.
> >>
> >>     
> >>> Looking at the Asus P5A example (I know that this board is severly
> >>> outdated, which might make this point less strong) there are no
> >>> subsystem IDs at all in it. So when we start looking for DMI info we
> >>> don't have any indication yet that we are on an Asus board. If we really
> >>> have good subsystem IDs, we don't need DMI.
> >>>       
> >> Yes. And in case we ever want to match two strings at once, the "bp:^A8V
> >> MX$" can be extended easily to
> >> "bvbp:^ASUS$:^A8V MX$" without changing any structs at all. Especially
> >> in the case where there is no usable PCI subsystem ID (board vendor not
> >> present) this may come handy. I'd wait for such an extension until we
> >> really desperately need it, though.
> >>     
> >
> > >From some previous mail:
> >
> >   
> >>> I don't think we need the "any:" prefix (I think I would have written it
> >>> as "??:") at all. The match-any policy was in just to shorten the table
> >>> entry.
> >>>       
> >> This whole thing is why i was initially very weary of *^$ in these
> >> strings. People end up trying to go beyond when they see something like
> >> that, it's something psychological that i have seen at play more often
> >> in these cases.
> >>     
> 
> Ah, I understood "go beyond" as trying to use unsupported regexps, which
> will be caught during review.
> My extensibility point was about not having to mess with the whole table
> each time we need changes in the DMI match policy.

I do not expect DMI many match policy changes.

* We've been relatively happy with pci subsystem ids for close to three 
  years.
* Our board enable table recently exploded, with the massive increase in 
  flashrom uptake. 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.
* Even then a very large proportion of the boards is and will be happy 
  with just pci subsystem ids.
* 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.

As an example...

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.

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.

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.

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.

Let's say that 30% of boards really require a gpio line to be poked.
Of which 10% need dmi to help match the board. How high would you guess 
the amount of boards in those that cannot be helped with a simple match 
(with wildcards), but _can_ be helped with a more intricate match.

My current guess: 75% will work with a simple match. 10% will work when 
multiple entries are created. 10% will never work. The remaining 5%, 
and this is a _very_ _very_ high estimate, i expect it to be closer to 
1%, is where intricate matching will be needed.

5 % of 10% of 30% = .15%

So yes, it is statistically possible that we might need it, but the 
probability is becoming _very_ low already, and before we encounter it, 
we will have written a whole lot of board enables.

Luc Verhaegen.




More information about the flashrom mailing list