All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: marcandre.lureau@redhat.com, qemu-ppc@nongnu.org,
	qemu-devel@nongnu.org, Stefan Berger <stefanb@linux.vnet.ibm.com>
Subject: Re: [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface
Date: Wed, 18 Dec 2019 20:59:18 -0500	[thread overview]
Message-ID: <db0d3dbe-3b01-e62b-2cf0-3d0c50e3c4fb@linux.ibm.com> (raw)
In-Reply-To: <20191219015414.GC2321@umbus.fritz.box>

On 12/18/19 8:54 PM, David Gibson wrote:
> On Tue, Dec 17, 2019 at 02:44:04PM -0500, Stefan Berger wrote:
>> On 12/16/19 7:29 PM, David Gibson wrote:
>>
>>
>>> Since you need to change compatible based on an internal variable,
>>> we'd need to replace the static dt_compatible in the class with a
>>> callback.
>>
>> Why can we not initialize it once we know the version of TPM? From the
>> perspective of SLOF at least this seems to be building the device tree fine
>> since it sees the proper value...
> Because it's a serious layering / isolation violation.  You're
> modifying QOM type information from the runtime code of a specific
> instance.  You get away with it (now) because there's only one
> instance and the ordering of things happens to let it work, but that's
> assuming way too much about QOM's implementation details.
>
> As a rule, once the QOM classes are set up with their class_init
> function, they should never be modified.


If we now add a get_dt_compatible() callback to the class that gets 
invoked when dt_compatible is NULL, does this then solve the issue?




  reply	other threads:[~2019-12-19  2:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-12 20:24 [PATCH v5 0/5] Add vTPM emulator support for ppc64 platform Stefan Berger
2019-12-12 20:24 ` [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface Stefan Berger
2019-12-12 20:33   ` Eric Blake
2019-12-12 20:34     ` Stefan Berger
2019-12-13  5:34   ` David Gibson
2019-12-13 13:03     ` Stefan Berger
2019-12-17  0:29       ` David Gibson
2019-12-17 19:44         ` Stefan Berger
2019-12-19  1:54           ` David Gibson
2019-12-19  1:59             ` Stefan Berger [this message]
2019-12-19  5:13               ` David Gibson
2019-12-19  5:14                 ` David Gibson
2019-12-12 20:24 ` [PATCH v5 2/5] tpm: Return bool from tpm_backend_finish_sync Stefan Berger
2019-12-12 20:24 ` [PATCH v5 3/5] tpm_spapr: Support suspend and resume Stefan Berger
2019-12-13  5:39   ` David Gibson
2019-12-13 12:46     ` Stefan Berger
2019-12-17  0:53       ` David Gibson
2019-12-12 20:24 ` [PATCH v5 4/5] hw/ppc/Kconfig: Enable TPM_SPAPR as part of PSERIES config Stefan Berger
2019-12-12 20:24 ` [PATCH v5 5/5] docs: tpm: Add example command line for ppc64 and tpm-spapr Stefan Berger

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=db0d3dbe-3b01-e62b-2cf0-3d0c50e3c4fb@linux.ibm.com \
    --to=stefanb@linux.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=marcandre.lureau@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=stefanb@linux.vnet.ibm.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.