On Tue, Mar 31, 2020 at 10:07:37AM +0200, Wolfgang Wallner wrote:
> >+struct __packed acpi_global_nvs {
> >+ /* Miscellaneous */
> >+ u8 pcnt; /* 0x00 - Processor Count */
> >+ u8 ppcm; /* 0x01 - Max PPC State */
> >+ u8 lids; /* 0x02 - LID State */
> >+ u8 pwrs; /* 0x03 - AC Power State */
> >+ u8 dpte; /* 0x04 - Enable DPTF */
> >+ u32 cbmc; /* 0x05 - 0x08 - U-Boot Console */
> >+ u64 pm1i; /* 0x09 - 0x10 - System Wake Source - PM1 Index */
> >+ u64 gpei; /* 0x11 - 0x18 - GPE Wake Source */
> >+ u64 nhla; /* 0x19 - 0x20 - NHLT Address */
> >+ u32 nhll; /* 0x21 - 0x24 - NHLT Length */
> >+ u32 prt0; /* 0x25 - 0x28 - PERST_0 Address */
> >+ u8 scdp; /* 0x29 - SD_CD GPIO portid */
> >+ u8 scdo; /* 0x2A - GPIO pad offset relative to the community */
> >+ u8 uior; /* 0x2B - UART debug controller init on S3 resume */
> >+ u8 ecps; /* 0x2C - SGX Enabled status */
> >+ u64 emna; /* 0x2D - 0x34 EPC base address */
> >+ u64 elng; /* 0x35 - 0x3C EPC Length */
> >+ u8 unused[195];
> >+ u8 unused2[0xf00];
>
> Nit 1: Something is still wrong with the indentation of unused2.
>
> Nit 2: Could you please add comments on why the values 195 and 0xf00 were
> chosen? I would assume 195 was selected so that unused2 starts on
> a 256-byte boundary? But that is only a guess.
Better to calculate them (I mean 195). In Linux kernel, for instance, a trick
is being used for that.
The rest is not simply boundary but rather 256 vs 4096 size of NVS. The
previous (small one) is what being used by U-Boot. I don't remember what ACPI
spec dictates about this (i.o.w. if it depends to the ACPI version in use).
> >+};
--
With Best Regards,
Andy Shevchenko
