[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based inte
From: |
David Gibson |
Subject: |
Re: [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface |
Date: |
Thu, 19 Dec 2019 16:14:44 +1100 |
On Thu, Dec 19, 2019 at 04:13:57PM +1100, David Gibson wrote:
> On Wed, Dec 18, 2019 at 08:59:18PM -0500, Stefan Berger wrote:
> > 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?
>
> Yes, that's what I'm suggesting.
Well, almost. Actually I'd suggest the other way around - call the
callback method, but if that's NULL, fallback to the static value.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
- [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface, (continued)
- [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface, Stefan Berger, 2019/12/12
- Re: [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface, Eric Blake, 2019/12/12
- Re: [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface, David Gibson, 2019/12/13
- Re: [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface, Stefan Berger, 2019/12/13
- Re: [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface, David Gibson, 2019/12/16
- Re: [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface, Stefan Berger, 2019/12/17
- Re: [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface, David Gibson, 2019/12/18
- Re: [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface, Stefan Berger, 2019/12/18
- Re: [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface, David Gibson, 2019/12/19
- Re: [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface,
David Gibson <=