On Sun, May 5, 2024 at 6:25 PM Armin Wolf <W_Armin@xxxxxx> 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!
