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