diff options
author | Jan Beulich <jbeulich@novell.com> | 2008-07-16 23:27:08 +0200 |
---|---|---|
committer | Andi Kleen <andi@basil.nowhere.org> | 2008-07-16 23:27:08 +0200 |
commit | 01a5bba576b9364b33f61f0cd9fa70c2cf5535e2 (patch) | |
tree | 3af27fec9e5b169d4e876a060ad1938307a14b1f /lib/int_sqrt.c | |
parent | 4d3870431d17346c4fdd80e087b7d76f1b5941d5 (diff) | |
download | linux-01a5bba576b9364b33f61f0cd9fa70c2cf5535e2.tar.bz2 |
Fix FADT parsing
The (1.0 inherited) separate length fields in the FADT are byte granular.
Further, PM1a/b may have distinct lengths and live in distinct address spaces.
acpi_tb_convert_fadt() should account for all of these conditions.
Apart from these changes I'm puzzled by the fact that, not just for
acpi_gbl_xpm1{a,b}_enable, acpi_hw_low_level_{read,write}() get an explicit
size passed rather than using the size found in the passed GAS. What happens
on a platform that defines PM1{a,b} wider than 16 bits? Of course,
acpi_hw_low_level_{read,write}() at present are entirely un-prepared to deal
with sizes other than 8, 16, or 32, not to speak of a non-zero bit_offset or
access_width...
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'lib/int_sqrt.c')
0 files changed, 0 insertions, 0 deletions