[RFC] SBBR Test Case Additions to FWTS

[Supreeth Venkatesh]

Thanks for your feedback and comments.
If this email adds a footer regarding confidentiality notice, please
ignore them. Need to work through our IT after new email server changes
:). My response in-line.

On Tue, 2017-01-10 at 19:45 +0000, Leif Lindholm wrote:
> 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.
Thanks. I believe we have no issues with the approach of having --sbbr
switch. I will proceed to send out the patches soon(next week) for
review.

> > 
> > 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.)
> 
Yes. Before sending in the patches, I will make sure that we thoroughly
root cause this. More comments to follow before before pushing the
SMBIOS Patches.

> 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.
I guess that we should try using /sys as default on ARM systems, but it
requires a little bit more time to fix these up. More comments are
welcome, as we work through these. 
> /
>     Leif