[RFC] SBBR Test Case Additions to FWTS

Jeffrey Hugo jhugo at codeaurora.org
Tue Jan 10 20:18:57 UTC 2017


On 1/10/2017 12:45 PM, Leif Lindholm wrote:
> On Tue, Jan 10, 2017 at 12:19:08PM -0700, Jeffrey Hugo wrote:
>> 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.

Why do you feel /dev/mem is invalid on ARM systems?  I notice that it is 
default y, and the ARM64 defconfig in upstream Linux does not disable 
it, so it would be enabled by default for every ARM system that didn't 
have some vendor/distro manually disable it.

I see CONFIG_DEVMEM is enabled on on our test builds, and it appears 
Ubuntu has it enabled as well.  I'm unfamiliar with LuvOS, but I suspect 
it relies on the default y behavior.

Off the top of my head, I have no issue with flipping that logic, but 
I'd want to test it first, since I know Fan just fixed the use of 
/dev/mem [1], and I wouldn't want to see a backward slide in how our 
platform tests in FWTS.

[1] https://lists.ubuntu.com/archives/fwts-devel/2016-November/008744.html

-- 
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.



More information about the fwts-devel mailing list