Il mer 2 lug 2025, 07:42 Xiaoyao Li <xiaoyao...@intel.com> ha scritto:
> Back to Paolo's example of "a compat property will be set on a device > *after* the class's post_init callback has run". I think the behavior of > compat property is applied after the class's post_init callback is also > what we want. If reversing the order, then compat prop can be > overwritten by subclass's post_init callback, and doesn't it fail the > purpose of compat prop? > I wrote the patch because of a latent issue with TDX. The issue was roughly that a compat property was overwriting the TDX-specific modifications to CPUID. I think this case shows that you *do* want the subclass to overwrite the compat property—of course the subclass code must be aware that compat properties exist and limit changes appropriately. In general I don't see how the reverse order makes sense: the subclass knows what the superclass does, so it can do the right thing if it runs last; but the superclass cannot know what all of its subclasses do in post_init, so it makes less sense to run it last. Paolo > So I think we might revert this patch, and document clearly the reverse > order of .post_instance_init() callback. > > > X86 CPUs have the issue (e.g., "vendor" doesn't work) now because > > they - as leaf class, don't care about the property values of > > superclass - the DeviceState. If a property is just for initialization, > > like "vendor", it should be placed in the instance_init() instead of > > instance_post_init(). > > > > In addition, if other places handle it similarly, the device's > > post_init seems pointless. :-( > > > > Thanks, > > Zhao > > > >
