[flashrom] DMI matching patch

[Carl-Daniel Hailfinger]

On 07.01.2010 11:13, Luc Verhaegen wrote:
> On Fri, Jan 01, 2010 at 01:27:44AM +0100, Michael Karcher wrote:
>   
>>> I believe the substring match is suboptimal.
>>>       
>> You got a point there.
>>     
>
> I wouldn't use any word related to optimal in relationship to the board 
> enable table.
>   

Heh. I tried to be polite.


> I would like to see a single string match, because this maximalises our 
> effectivity, while minimising the impact on our already large board 
> enable table.
>
> That being said, sticking the dmi substring selection in the matching 
> string, is contrived and will only lead to problems. If this really is 
> what is wanted, then please use an enum.
>   

The enum will clutter up the table a lot more than 3 chars at the
beginning of the DMI string, so I'd rather avoid it.

> But for the time being, i believe that it is not needed. And it can be 
> added easily later on if we start collecting dmi info.
>   

We really need a database of all that stuff (DMI, PCIID, SuperIO) and
not only something googleable. If google indexes the database, yay for
us, but the ability to do systematic data mining does make stuff a lot
easier.


>>> I'd make that warning conditional on the absence of a coreboot table.
>>> Otherwise you'll get a warning on a lot of systems with coreboot.
>>>       
>> You will only get that warning if the PCI IDs match and the DMI is
>> missing.
>> When you run on coreboot, you don't even get into
>> board_match_pci_card_ids(), as board_match_coreboot_name() already has
>> chosen the right board.
>>     
>
> Sounds all good.
>
> The matching functions is also still on my todo list. Splitting the 
> matching functions from two (named/coreboot, pciid) into three 
> (coreboot, named, pciid), to tighten up the board enable table.

Sorry, -ENOPARSE.

Regards,
Carl-Daniel

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