From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlcLi-0004Kt-Oc for qemu-devel@nongnu.org; Wed, 27 Nov 2013 05:28:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlcLc-0003Eo-9i for qemu-devel@nongnu.org; Wed, 27 Nov 2013 05:28:02 -0500 Received: from cantor2.suse.de ([195.135.220.15]:40328 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlcLb-0003Ek-Vm for qemu-devel@nongnu.org; Wed, 27 Nov 2013 05:27:56 -0500 Message-ID: <5295C927.6040101@suse.de> Date: Wed, 27 Nov 2013 11:27:51 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <5295BE86.9050109@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH arm-devs v1 2/6] target-arm/cpu: Convert reset CBAR to a property List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Igor Mammedov , Peter Crosthwaite , QEMU Developers , Mark Langsdorf Am 27.11.2013 11:15, schrieb Peter Maydell: > On 27 November 2013 09:42, Andreas F=C3=A4rber wrote= : >> If we turn it into a dynamic property, we could register it conditiona= l >> to ARM_FEATURE_CBAR. >=20 > 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 havin= g >> several reset values to configure over time. >=20 > 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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg