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