From Supreeth.Venkatesh at arm.com Tue Jan 10 17:09:33 2017 From: Supreeth.Venkatesh at arm.com (Supreeth Venkatesh) Date: Tue, 10 Jan 2017 17:09:33 +0000 Subject: [RFC] SBBR Test Case Additions to FWTS Message-ID: This Server Base Boot Requirements (SBBR) specification is intended for SBSA-compliant 64-bit ARMv8 servers. It defines the base firmware requirements for out-of-box support of any ARM SBSA-compatible Operating System or hypervisor. The requirements in this specification are expected to be minimal yet complete for booting a multi-core ARMv8 server platform, while leaving plenty of room for OEM or ODM innovations and design details. For more information, download the SBBR specification 1. This specification is closely aligned with ACPI 6.0 Specification. However, there are slight variations in some of the test cases. For instance, Existing FWTS Implementation just logs a warning message for SPCR missing table, However, as per the SBBR specification, we will need to fail the test. Question: What's the recommendation for handling these kind of variations? a) Should we create a transient branch(SBBR) in FWTS specific to ARMv8? b) Should we separate at runtime this by adding a command line parameter -sbbr? 2. SMBIOS test cases present in FWTS currently employ /dev/mem based on legacy x86 methods. However, in ARMv8 implementation, we will need to disable mem feature in kernel and modify it slightly from existing implementation. How do you suggest we go about it? a) Compile time separation using AARCH64 or similar switch? b) Runtime separation if(ARCH == AARCH64) or something similar? 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. Supreeth Venkatesh (8) : src/acpi/acpitables/acpitables.c src/acpi/dbg2/dbg2.c src/acpi/fadt/fadt.c src/acpi/method/method.c src/acpi/rsdp/rsdp.c src/acpi/xsdt/xsdt.c src/dmi/dmicheck/dmicheck.c src/lib/src/fwts_smbios.c 8 files changed. -- 1.9.1 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From jhugo at codeaurora.org Tue Jan 10 19:19:08 2017 From: jhugo at codeaurora.org (Jeffrey Hugo) Date: Tue, 10 Jan 2017 12:19:08 -0700 Subject: [RFC] SBBR Test Case Additions to FWTS In-Reply-To: <20170110181659.GH1905@bivouac.eciton.net> References: <20170110181659.GH1905@bivouac.eciton.net> Message-ID: <48a0f7a0-7bf8-bc1a-573f-b32c9af08e2a@codeaurora.org> 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. 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 >> >> 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. From alex.hung at canonical.com Tue Jan 10 20:01:02 2017 From: alex.hung at canonical.com (Alex Hung) Date: Tue, 10 Jan 2017 12:01:02 -0800 Subject: [RFC] SBBR Test Case Additions to FWTS In-Reply-To: <48a0f7a0-7bf8-bc1a-573f-b32c9af08e2a@codeaurora.org> References: <20170110181659.GH1905@bivouac.eciton.net> <48a0f7a0-7bf8-bc1a-573f-b32c9af08e2a@codeaurora.org> Message-ID: On Tue, Jan 10, 2017 at 11:19 AM, Jeffrey Hugo 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 > > 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 >>> >>> 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 > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/fwts-discuss > -- Cheers, Alex Hung From colin.king at canonical.com Tue Jan 10 20:08:08 2017 From: colin.king at canonical.com (Colin Ian King) Date: Tue, 10 Jan 2017 20:08:08 +0000 Subject: [RFC] SBBR Test Case Additions to FWTS In-Reply-To: References: <20170110181659.GH1905@bivouac.eciton.net> <48a0f7a0-7bf8-bc1a-573f-b32c9af08e2a@codeaurora.org> Message-ID: On 10/01/17 20:01, Alex Hung wrote: > > > On Tue, Jan 10, 2017 at 11:19 AM, Jeffrey Hugo > 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 > > > 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 > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/fwts-discuss > > > > > > -- > Cheers, > Alex Hung > > From supreeth.venkatesh at arm.com Tue Jan 10 20:14:42 2017 From: supreeth.venkatesh at arm.com (Supreeth Venkatesh) Date: Tue, 10 Jan 2017 14:14:42 -0600 Subject: [RFC] SBBR Test Case Additions to FWTS In-Reply-To: <20170110194510.GA24544@bivouac.eciton.net> References: <20170110181659.GH1905@bivouac.eciton.net> <48a0f7a0-7bf8-bc1a-573f-b32c9af08e2a@codeaurora.org> <20170110194510.GA24544@bivouac.eciton.net> Message-ID: <1484079282.3096.13.camel@arm.com> 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 From supreeth.venkatesh at arm.com Tue Jan 10 20:12:21 2017 From: supreeth.venkatesh at arm.com (Supreeth Venkatesh) Date: Tue, 10 Jan 2017 14:12:21 -0600 Subject: [RFC] SBBR Test Case Additions to FWTS In-Reply-To: <20170110194510.GA24544@bivouac.eciton.net> References: <20170110181659.GH1905@bivouac.eciton.net> <48a0f7a0-7bf8-bc1a-573f-b32c9af08e2a@codeaurora.org> <20170110194510.GA24544@bivouac.eciton.net> Message-ID: <1484079141.3096.12.camel@arm.com> 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 From jhugo at codeaurora.org Tue Jan 10 20:18:57 2017 From: jhugo at codeaurora.org (Jeffrey Hugo) Date: Tue, 10 Jan 2017 13:18:57 -0700 Subject: [RFC] SBBR Test Case Additions to FWTS In-Reply-To: <20170110194510.GA24544@bivouac.eciton.net> References: <20170110181659.GH1905@bivouac.eciton.net> <48a0f7a0-7bf8-bc1a-573f-b32c9af08e2a@codeaurora.org> <20170110194510.GA24544@bivouac.eciton.net> Message-ID: <5f776d78-5672-9edb-d58b-3c58e152a848@codeaurora.org> 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.