[RFC] SBBR Test Case Additions to FWTS

[Colin Ian King]

On 10/01/17 20:01, Alex Hung wrote:
> 
> 
> On Tue, Jan 10, 2017 at 11:19 AM, Jeffrey Hugo <jhugo at codeaurora.org
> <mailto:jhugo at codeaurora.org>> wrote:
> 
>     On 1/10/2017 11:17 AM, Leif Lindholm wrote:
> 
>         Hi Jeffrey,
> 
>         On Tue, Jan 10, 2017 at 11:00:19AM -0700, Jeffrey Hugo wrote:
> 
>                 Once, the above two questions have been answered and we
>                 arrive at a
>                 solution which is easier to maintain, will send out a
>                 list of patches
>                 related to SBBR.
> 
>                 Thanks in advance for your inputs.
> 
> 
>             Can you elaborate on the motivation for adding SBBR
>             compliance to FWTS?
> 
>             SBBR is ARM specific, yet FWTS is architecture agnostic in
>             its purpose.
>             While my primary interest is ARM, it sounds like to add SBBR
>             testing to FWTS
>             requires the addition of a bunch of ARM specific tweaks that
>             don't play well
>             with other architectures.  Greater ARM support is nice, but
>             not at the cost
>             of not playing well with others.
> 
> 
>         To clarify - this isn't a "test all of SBBR compliance using FWTS"
>         thing, it's a "test the bits that FWTS are already looking for, but
>         make the absence of certain tables result in reported test
>         failures".
> 
> 
>     Hmm, I guess my perception of running the SBBR compliance testing is
>     not accurate.
> 
>     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.
> 
>     SPCR for example, is an optional table per my reading of the ACPI
>     spec. 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.
> 
> 
> ​fwts has --uefitests (for all uefi tests) and --acpitests (for all acpi
> tests), and I do not see problems with --sbbr or --sbbrtests for SBBR at all

+1 on 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.
> 
>     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.
> 
> 
>         The other part of SBBR compliance validation runs in a UEFI SCT
>         context.
> 
>             Additionally, ARM (the company) has already published a SBBR
>             compliance test
>             at https://github.com/ARM-software/arm-enterprise-acs
>             <https://github.com/ARM-software/arm-enterprise-acs>
> 
>             Why duplicate that in FWTS?
> 
> 
>         Because that compliance test is based to a larger extent on FWTS and
>         ARM does not want to maintain a non-upstream branch in perpetuity if
>         it can be avoided.
> 
>         This pre-RFC is for investigating possibilities for getting away
>         from
>         carrying patches against FWTS as part of that compliance test suite.
> 
> 
>     Ah, sadly I haven't currently dug into the compliance test as much
>     as I would like.  I see, so the test currently has a fork of FWTS,
>     and you'd prefer to be using mainline for reasons which are now
>     obvious. Motivation sufficiently explained.  Thank you.
> 
>     As a FWTS user, I'm interested to see where this goes.  I'm looking
>     forward to seeing patches.
> 
>     -- 
>     Jeffrey Hugo
>     Qualcomm Datacenter Technologies as an affiliate of Qualcomm
>     Technologies, Inc.
>     Qualcomm Technologies, Inc. is a member of the
>     Code Aurora Forum, a Linux Foundation Collaborative Project.
> 
>     -- 
>     fwts-discuss mailing list
>     fwts-discuss at lists.ubuntu.com <mailto:fwts-discuss at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/fwts-discuss
>     <https://lists.ubuntu.com/mailman/listinfo/fwts-discuss>
> 
> 
> 
> 
> -- 
> Cheers,
> Alex Hung
> 
>