ACPICA usually defines any "related" data structures, just for user convenience.
> -----Original Message-----
> From: Jarkko Sakkinen [mailto:firstname.lastname@example.org]
> Sent: Tuesday, June 09, 2015 2:18 AM
> To: Moore, Robert
> Cc: Zheng, Lv; Wysocki, Rafael J; Len Brown; open list:ACPI COMPONENT
> AR...; open list:ACPI COMPONENT AR...; open list
> Subject: Re: [PATCH] acpi: update struct acpi_table_tpm2
> On Mon, Jun 08, 2015 at 08:52:02PM +0000, Moore, Robert wrote:
> > It looks like there is a change to the TCPA table also.
> Right. I'll update that too.
> I strongly think that the struct acpi_tpm2_control should not be in
> actbl3.h. It is not defined in the TCG ACPI specification. It is defined
> FIFO control structures are internal for to the TPM subsystem and so
> should be CRB control structures (and we have already inside tpm_crb.c).
> The structure ended up there probably because it was combined with the
> TPM2 table in that Microsoft specification.
It's not clear to me that this is the correct way to handle a segfault that
was reported to me via Fedora.
Using the ssdt9.dat file attached, a simple "iasl -d ssdt9.dat" will segfault
around calls to AcpiDmPromoteTarget -- and it turns out that the Target pointer
being passed into that function was sometimes null but not being checked in the
calling function, AcpiDmCheckForSymbolicOpcode. So, this patch adds in some
checks for null pointers and can now get through this particular problem.
However, I did not study AcpiDmCheckForSymbolicOpcode long enough to determine
if the Target pointer in that function should or should not ever be null. So,
this patch fixes this issue, but it may not be the proper long term solution.
Red Hat, Inc.