On 11/14/2013 03:27 AM, Tomasz Nowicki wrote:
On 14.11.2013 10:10, Graeme Gregory wrote:
On Wed, Nov 13, 2013 at 01:08:25PM -0700, Al Stone wrote:
On 11/13/2013 01:44 AM, Hanjun Guo wrote:
On 2013-11-13 15:59, Andrea Gallo wrote:
Al
I am not sure about this.
What if one day we have ARM vendors showing up with x86-like fake registers just to be fully fixed hw profile compliant and feeling they could be safer than with the resuced hw profile, for whichever reason?
I would suggest we have two flags, which would be both set in 99.9% of ARM platforms but maybe there could be a 0.1% where it is ARM and fixed profile one day?
I agree with Andrea. we can't just let ARM = HW-reduced, some OEM vendors may implement ACPI hardware one day.
Thanks Hanjun
Hrm. I was unaware that some vendors were already going down the path of full ACPI hardware. In that case, we should leave things as they are and if a particular vendor wants to have reduced HW the default (or not), then they can do that in their specific Kconfig items. So, I'm withdrawing this patch as unneeded.
I very much disagree with Andrea and Hanjun, we cannot design software for an infinite number of "what if?". Especially when its a complex system which requires testing. I very much doubt someone will come up with an emulated non reduced hardware platform on arm that just works on first boot. Considering they will have to do a lot of testing and probably code changes then one line in a config file is not a major extra bit of work.
Also consider if we do not push this patch we will be answering the question approximately once a day of why our ARM acpi code core dumps due to random memory access because someone forgot to set that flag in their .config.
Graeme
I also would like to see hardware reduce selected along with ARM. This way vendors are somehow forced to implement new feature in generic way, what means all flavour of ARM platforms can use it (eventual others platforms too). Personally, my feeling is that fixed version of ACPI is only for x86 and hardware reduce is right direction.
Tomasz
I think I may have answered in haste (it has been a *long* week already and I've been tired).
The more I think about this, I realize I have to withdraw my withdrawal :). The issue is that the reduced HW profile is meant to be more architecturally neutral, while the full ACPI profile is actually x86-dependent. Not only is it x86 specific, it carries with it a whole raft of baggage from pre-ACPI 5.0 legacy systems (there are Atom systems using reduced HW mode just to avoid this cruft).
As the most egregious example, if an ARM vendor is to make an SoC that implements the full ACPI profile, they *must* implement an NMI interrupt line that behaves like a real NMI (none of this priority stuff). If they do, is that really an ARM processor? I don't think so -- it's some sort of hybrid beast. The same problem exists for SCI, and possibly MCE and others that are very specific to x86 *and* impose HW requirements on the SoC vendors to step outside of a normal ARM implementation.
The next layer is that the FACS table would also impose the requirement to implement various registers with very specific semantics, again specific to x86, and outside the definition of ARM.
The final thought that occurs to me is that without reduced HW profile, we *must* implement a single global lock in ACPI. That lock could be abused in a bazillion different ways that would end up creating a single global lock in the kernel. Since there is by definition no ACPI global lock in reduced HW, that cannot happen.
So, now that I think about it more, we *must* link reduced HW and ARM ACPI unless we want to force HW requirements on SoC vendors that would (a) force them to add x86-specific features to their ARM hardware, and (b) force them to support legacy x86 hardware features that even Intel is moving away from.