32-bit versus 64-bit ACPI tables

32-bit versus 64-bit ACPI tables

[Billie Alsup (balsup)]

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

Re: 32-bit versus 64-bit ACPI tables

[Armin Wolf]

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

Re: 32-bit versus 64-bit ACPI tables

[Rafael J. Wysocki]

On Sun, May 5, 2024 at 6:25 PM Armin Wolf <W_Armin@gmx.de> wrote:
>
> 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?

It's not just about the size of integers.

The size of integers was 4 bytes in ACPI 1.0 only, in ACPI 2.0 and
above integers are 64-bit.  If ACPI support in the platform is not
limited to ACPI 1.0, it must use 64-bit integers.

Thanks!

Re: 32-bit versus 64-bit ACPI tables

[Billie Alsup (balsup)]

>From: Armin Wolf <W_Armin@gmx.de>
>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.

I see you are correct.  The ACPI Spec 6.5 explicitly states as much.

>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?

It would be a convenience to encode a 64-bit match value in _ADR (for example, while
using acpi_find_child_device).  However, I can certainly use other attributes and walk
the child nodes myself.  In other cases, where I really want a 64-bit mask, I can resort
to an array, or distinct named fields.  It just seemed unnecessarily awkward.  I think
the real solution, as painful as it may seem, is to get our firmware team to switch to 
ComplianceRevision 2 for the DSDT.

Thanks for your insights!