On 11/22/2013 04:15 PM, Rafael J. Wysocki wrote:
On Friday, November 22, 2013 10:53:09 AM Olof Johansson wrote:
On Fri, Nov 22, 2013 at 10:03 AM, Al Stone <al.stone@xxxxxxxxxx> wrote:
On 11/22/2013 06:25 AM, Rob Herring wrote:
On Thu, Nov 21, 2013 at 6:41 PM, <al.stone@xxxxxxxxxx> wrote:
From: Al Stone <al.stone@xxxxxxxxxx>
Modified #ifdef so that DMI is not used on ARM platforms which
are currently implementing ACPI reduced HW mode.
It is really not allowed or is optional? There are various people that
want DMI tables on ARM.
Rob
True. DMI is optional. I see it as orthogonal to
reduced HW mode; I have to hope that when DMI patches
are forthcoming they'll do the right thing here.
Is there a better way to do this in the #if ?
Doing all of these things at compile time seems odd, shouldn't it be
handled at runtime? What happens when someone wants to build a kernel
that boots both on the reduced hw mode platforms and regular ones?
I agree.
My suggestion would be to harden dmi_check_system() so that it works
if DMI is not present (if it doesn't already).
Thanks!
I agree -- runtime would be better. For dmi_check_system(), that
can be done and I'll look into that. I'll also go double check the
rest of my #ifdefs and see if I can remove any more of them from the
Linux side of the ACPI code.
For reduced hardware mode, however, I have to rely on the underlying
ACPICA reference implementation to behave properly. Right now, ACPICA
relies on compile time changes to implement either reduced HW mode or
legacy mode so I have to follow suit. When I looked at making ACPICA
change behavior at runtime, the changes became more and more invasive.
Since x86/ia64 depend on ACPICA to behave also, that seemed a far more
dangerous approach to me.
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone@xxxxxxxxxx
-----------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html