Am 27.11.2013 11:15, schrieb Peter Maydell: > On 27 November 2013 09:42, Andreas Färber <afaer...@suse.de> wrote: >> If we turn it into a dynamic property, we could register it conditional >> to ARM_FEATURE_CBAR. > > Unfortunately feature flags only get set at realize (in the > per-cpu init function), so we don't know at the point where > we're registering properties whether to have this one or not.
1/6 sets it in instance_init actually. So instance_post_init might do. > The other option would be to define an a9 cpu class init fn to > put the property in. Is it A9-only or would A15, A7, A12, etc. also need it? >> The overall idea of the series makes sense to me. I would caution to >> think about the naming scheme though - we might want to have a "cbar" >> property to access the current value whereas we'll likely end up having >> several reset values to configure over time. > > Mmm, maybe. The approach I think we've taken in some other > places (eg the cache controller) is to have the property names > match the silicon's config or control signal names (which in > this case would be PERIPHBASE), but they are not always > consistent from CPU to CPU, so that might be more confusing > than helpful. I don't think I have a strong opinion here, so I'd > be happy with any vaguely consistent-looking plan. Whatever name you choose, I was rather thinking of whether you may want to call it, e.g., "foo-reset" or "reset-foo" to distinguish from plain "foo". (Igor's x86 properties series uses "feat-foo" on Anthony's suggestion to group and parse feature properties.) Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
