From: Stefan Berger <stefanb@linux.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Ani Sinha <ani@anisinha.ca>,
marcandre.lureau@redhat.com, Igor Mammedov <imammedo@redhat.com>,
qemu-devel@nongnu.org, Shannon Zhao <shannon.zhaosl@gmail.com>
Subject: Re: [PATCH v2 2/3] acpi: tpm: Add missing device identification objects
Date: Tue, 9 Nov 2021 09:26:46 -0500 [thread overview]
Message-ID: <5f10eeed-e83c-e2c8-b4bb-23116fdcbc51@linux.ibm.com> (raw)
In-Reply-To: <20211109091432-mutt-send-email-mst@kernel.org>
On 11/9/21 09:20, Michael S. Tsirkin wrote:
> On Tue, Nov 09, 2021 at 09:01:51AM -0500, Stefan Berger wrote:
>> Add missing device identification objects _STR and _UID. They will appear
>> as files 'description' and 'uid' under Linux sysfs.
>>
>> Cc: Shannon Zhao <shannon.zhaosl@gmail.com>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Cc: Igor Mammedov <imammedo@redhat.com>
>> Cc: Ani Sinha <ani@anisinha.ca>
>> Fixes: https://gitlab.com/qemu-project/qemu/-/issues/708
>> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> Do you want this in 6.2?
Yes.
>
>> ---
>> hw/arm/virt-acpi-build.c | 1 +
>> hw/i386/acpi-build.c | 8 ++++++++
>> 2 files changed, 9 insertions(+)
>>
>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
>> index 674f902652..09456424aa 100644
>> --- a/hw/arm/virt-acpi-build.c
>> +++ b/hw/arm/virt-acpi-build.c
>> @@ -228,6 +228,7 @@ static void acpi_dsdt_add_tpm(Aml *scope, VirtMachineState *vms)
>>
>> Aml *dev = aml_device("TPM0");
>> aml_append(dev, aml_name_decl("_HID", aml_string("MSFT0101")));
>> + aml_append(dev, aml_name_decl("_STR", aml_string("TPM 2.0 Device")));
>> aml_append(dev, aml_name_decl("_UID", aml_int(0)));
>>
>> Aml *crs = aml_resource_template();
>> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
>> index a3ad6abd33..5bd2160a89 100644
>> --- a/hw/i386/acpi-build.c
>> +++ b/hw/i386/acpi-build.c
>> @@ -1808,11 +1808,15 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
>> dev = aml_device("TPM");
>> aml_append(dev, aml_name_decl("_HID",
>> aml_string("MSFT0101")));
>> + aml_append(dev,
>> + aml_name_decl("_STR",
>> + aml_string("TPM 2.0 Device")));
>
> When we support more versions, won't this make us
> do annoying tricks to say so in the string?
> Why not just "TPM device" to future-proof it?
I am not sure what other version there will be and I haven't seen any
other descriptions than the one reported here:
https://gitlab.com/qemu-project/qemu/-/issues/708
That's why I took TPM 2.0 device. My TPM 1.2 machine doesn't report it
for a TPM 1.2.
>
>> haven } else {
>> dev = aml_device("ISA.TPM");
>> aml_append(dev, aml_name_decl("_HID",
>> aml_eisaid("PNP0C31")));
>> }
>> + aml_append(dev, aml_name_decl("_UID", aml_int(1)));
>>
> The ACPI spec mentions also matching on _CID.
"6.1.2 _CID (Compatible ID)
This optional object is used to supply OSPM with a device?s Plug and
Play-Compatible Device ID. Use _CID
objects when a device has no other defined hardware standard method to
report its compatible IDs"
6.1.12 _UID (Unique ID)
This object provides OSPM with a logical device ID that does not change
across reboots. This object is
optional, but is required when the device has no other way to report a
persistent unique device ID. The
_UID must be unique across all devices with either a common _HID or _CID.
Is _CID a must-have for TPM now? We have _HID.
>
>> aml_append(dev, aml_name_decl("_STA", aml_int(0xF)));
>> crs = aml_resource_template();
>> @@ -1840,6 +1844,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
>> if (TPM_IS_CRB(tpm)) {
>> dev = aml_device("TPM");
>> aml_append(dev, aml_name_decl("_HID", aml_string("MSFT0101")));
>> + aml_append(dev, aml_name_decl("_STR",
>> + aml_string("TPM 2.0 Device")));
>> crs = aml_resource_template();
>> aml_append(crs, aml_memory32_fixed(TPM_CRB_ADDR_BASE,
>> TPM_CRB_ADDR_SIZE, AML_READ_WRITE));
>> @@ -1847,6 +1853,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
>>
>> aml_append(dev, aml_name_decl("_STA", aml_int(0xf)));
>>
>> + aml_append(dev, aml_name_decl("_UID", aml_int(1)));
>> +
>> tpm_build_ppi_acpi(tpm, dev);
>>
>> aml_append(sb_scope, dev);
>> --
>> 2.31.1
next prev parent reply other threads:[~2021-11-09 14:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-09 14:01 [PATCH v2 0/3] tpm: Add missing ACPI device identification objects Stefan Berger
2021-11-09 14:01 ` [PATCH v2 1/3] tests: acpi: prepare for updated TPM related tables Stefan Berger
2021-11-09 14:11 ` Michael S. Tsirkin
2021-11-09 14:30 ` Stefan Berger
2021-11-10 12:15 ` Michael S. Tsirkin
2021-11-09 14:01 ` [PATCH v2 2/3] acpi: tpm: Add missing device identification objects Stefan Berger
2021-11-09 14:20 ` Michael S. Tsirkin
2021-11-09 14:26 ` Stefan Berger [this message]
2021-11-10 12:17 ` Michael S. Tsirkin
2021-11-09 14:01 ` [PATCH v2 3/3] tests: acpi: Add updated TPM related tables Stefan Berger
2021-11-09 14:14 ` Michael S. Tsirkin
2021-11-09 14:29 ` Daniel P. Berrangé
2021-11-09 14:56 ` Ani Sinha
2021-11-09 15:05 ` Daniel P. Berrangé
2021-11-09 16:14 ` Michael S. Tsirkin
2021-11-09 16:05 ` Michael S. Tsirkin
2021-11-09 16:16 ` Daniel P. Berrangé
2021-11-09 16:49 ` Ani Sinha
2021-11-09 16:50 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5f10eeed-e83c-e2c8-b4bb-23116fdcbc51@linux.ibm.com \
--to=stefanb@linux.ibm.com \
--cc=ani@anisinha.ca \
--cc=imammedo@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=shannon.zhaosl@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.