[PATCH v1] cmd: acpi: Print revisions in hex format

[Wolfgang Wallner]

Hi Andy,

-----"Andy Shevchenko" <andy.shevchenko at gmail.com> schrieb: -----
> Betreff: Re: [PATCH v1] cmd: acpi: Print revisions in hex format
> 
> On Tue, Sep 08, 2020 at 05:32:08PM +0200, Wolfgang Wallner wrote:
> > -----"Andy Shevchenko" <andy.shevchenko at gmail.com> schrieb: -----
> > > On Tue, Sep 8, 2020 at 5:58 PM Wolfgang Wallner
> > > <wolfgang.wallner at br-automation.com> wrote:
> > > > -----"Andy Shevchenko" <andriy.shevchenko at linux.intel.com> schrieb: -----
> 
> ...
> 
> > > > Related to "acpi list":
> > > > During my recent ACPI debugging I found it very useful to have the checksum
> > > > printed for each table with "acpi list". Would there be interest to have that
> > > > upstream? If so I would send a patch.
> > > 
> > > Can you elaborate what was the problem that checksum helped?
> > 
> > Sure. I saw two strange things with the ACPI checksums:
> > 
> > 1) The DSDT length included uninitialized bytes from alignment. This is
> > described in the following link:
> > 
> >    https://lists.denx.de/pipermail/u-boot/2020-September/425378.html
> >    
> > This was the actual bug I was looking for.
> >    
> > 2) acpi_create_spcr() is missing a memset(). The other acpi_create_xxxx()
> > functions perform a memset on their structure, acpi_create_spcr() does not
> > and as a result the contents of this table are party uninitialized.
> > 
> > I plan to send a patch for both of them.
> 
> I'm not sure I understood how checksum pointed to uninitialized data?

After adding the checksums to "acpi list" I realized that the checksums for
DSDT and SPCR where different after every reset. Looking at the code each
turned out to be somehow related to uninitialized memory.

regards, Wolfgang

PS: My mail client has somehow corrupted your last mail, and I can't open it.
A colleague has forwarded it to me so I could reply. This is why I reply to my
own mail.