firmware-testing-team team mailing list archive

[Colin Ian King <colin.king@xxxxxxxxxxxxx>]

I've been thinking a lot about this a lot while I'm currently in bed 
fighting a bad case of shingles :-/

fwts was designed to catch firmware errors - from my perspective it was 
a way to automate the kind of work I did in HWE to catch any problem 
early in the enablement phase so we could get firmware fixed or detect 
issues that we could fix in the kernel before we shipped a product. The 
mind set to fwts is: "automatically spot potential errors and get them 
fixed early".   Honestly, it looks *REALLY* poor if the kernel spews out 
lots of warning and error messages on hardware that we've enabled.

This is a different use-case from what CERT requires.  The firmware is 
not really fixable - the machine is already released and on the market 
and firmware upgrades are less likely.

From the enablement viewpoint, I wrote fwts to be pedantic so we can 
spot specific issues (such as missing controls like _BQC) because the 
kernel has to bodge and work around this features (it kind of works, but 
is not ideal) and it is good to get these fixed in firmware if we can. 
This is obviously not the case in the certification phase.

Some issues are marked "CRITICAL" such as _OSC as it most probably (or 
though possibly not) may lead to a poor configuration (e.g. poor power 
configuration) and it requires an engineer to look at.  We don't want to 
fail energy star compliance tests do we? :-)

So, I think once you understand that fwts was designed to catch 
potential poorly written firmware issues so that can be investigated and 
fixed you can see that design feature does not match the requirements of 
certification.   I suspect we may need to add a profile setting to fwts 
so it can be used for different use-cases.

Anyhow, that's just my view.  Others may disagree. I'm very happy to 
discuss this and thrash out some kind of workable solution.

Colin