[RFC] SBBR Test Case Additions to FWTS

[Leif Lindholm]

On Tue, Jan 10, 2017 at 12:19:08PM -0700, Jeffrey Hugo wrote:
> Being that SBBR is ARM specific, and not even all ARM systems need to
> conform to SBBR as its a server specification (ie an ARM phone SoC), I
> personally do not feel as though changing the default behavior of FWTS is
> what I would like to see.

The implementation in arm-enterprise-acs is unconditional mainly
because it felt unnecessary to try to design a conditional variety
before:
1) it was known what additions were actually required to verify SBBR
   compliance.
2) we had established what the best way of doing so was. (This, to
   some extent is the reason for the current thread.)

> SPCR for example, is an optional table per my reading of the ACPI spec.

Exactly.

> Therefore, I believe FWTS does the correct thing, today.  Since SBBR adds
> additional requirements, ie requires SPCR to be implemented, and and only
> applies to a small subset of FWTS consumers, then I feel that SBBR testing
> in FWTS should be an explicit thing that the user invokes - an "expert
> option" if you will.
> 
> Off the top of my head, it would probably be more useful to me if SBBR were
> a separate test within FWTS (ie "fwts sbbr"), but a command line switch
> ("fwts --sbbr") seems acceptable to me.  Given that it sounds like FWTS does
> 95% of what you want already, the command line switch may be easier to
> implement.

I'd be completely happy with that.

> I guess that is a partial answer from be concerning Question 1 posed by
> Supreeth.  I would prefer option 1B.  I would not advise a separate branch
> as that seems to be a lot of cost for no real benefit as far as I can tell.

Yes, that would just move the pain from one tree to another.

> Regarding question 2, I'm not sure what the issue with the SMBIOS test is,
> it currently works on our ARM64 platform. If the issue is specific to the
> ARM arch as a whole, then compile time separation seems appropriate, however
> if the issue is specific to SBBR testing, then the switch should be done
> based on the fact that the user requested SBBR testing, since the issue
> won't apply to all platforms as discussed above.
>
> I think I'd need to see code addressing the issue with SMBIOS to comment
> more.

Hmm, looking at the code in src/dmi/dmicheck/dmicheck.c it seems to
try to mmap /dev/mem first and if that fails go on to sysfs.

Supreeth: is it possible the LuvOS kernel has /dev/mem support
enabled? If so, disabling that should resolve the issue.
(Ensure CONFIG_DEVMEM is not set in kernel config.)

Alternatively, would it be acceptable to flip that logic?
/sys is definitely the preferable method to access both ACPI and
SMBIOS, and the only one that should be used on any ARM system.

/
    Leif