Re: 32-bit versus 64-bit ACPI tables

[Armin Wolf <W_Armin@gmx.de>]

Am 01.01.70 um 01:00 schrieb :

> My hardware comes with a DSDT with 32-bit tables, however I would like to add a
> 64-bit table via SSDT.  Although, my SSDT compiles and loads successfully, the
> kernel truncates my 64-bit values because it apparently remembers that the DSDT
> used 32-bit tables.  Is there a way to have a 64-bit SSDT, to augment a 32-bit DSDT?
>
> I don't quite understand the reason for truncating the SSDT values.  The original
> code (from 2005!) warns that this is potentially a serious problem in the ACPI
> table(s) due to (possibly) buggy ASL compilers.  However, in my case, I want
> to explicitly have a 64-bit SSDT, and set the ComplianceRevision to 2 specifically
> to support 64-bit integers.  But alas, they are still truncated due to a global
> setting of
>
>                  acpi_gbl_integer_bit_width = 32;
>                  acpi_gbl_integer_nybble_width = 8;
>                  acpi_gbl_integer_byte_width = 4;
>
> versus having table specific settings.  Is there a workaround for this issue?
>
> It would be quite painful (both for me, and for customers) to get new firmware
> with a higher ComplianceRevision in the DSDT.  I wonder if there is an acceptable
> alternative.  For example, is truncation really required still (are we still dealing with
> buggy ASL compilers after 19 more years have elapsed?). Should there be a
> kernel command line parameter, or a kernel config option, to disable truncation?
> Should these acpi_gbl_integer_* variables be table specific, rather than global?
>
> I would appreciate any insights or advice you can offer me. Thanks in advance!
>
> Some additional references:
>
> 1. truncation occurs in file drivers/acpi/acpica/exutils.c
>      function acpi_ex_truncate_for32bit_table
> 2. initial setting of the globals occurs in file drivers/acpi/utilities/utmisc.c
>      function acpi_ut_set_integer_width

Hi,

the ACPI specification says that the integer length for _both_ DSDT and SSDT tables
is controlled by the revision field of the DSDT, so your 32-bit DSDT prevents your
SSDT from using 64-bit integers.

The only solution for this would be to not use 64-bit values inside your SSDT, is
there a reason why you absolutely need 64-bit integers in your DSDT?

Thanks,
Armin Wolf