From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFPDw-00088N-PF for qemu-devel@nongnu.org; Fri, 30 Aug 2013 09:59:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VFPDo-0007A3-Mi for qemu-devel@nongnu.org; Fri, 30 Aug 2013 09:58:52 -0400 Message-ID: <5220A510.1040807@suse.de> Date: Fri, 30 Aug 2013 15:58:40 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1376606111-3518-1-git-send-email-afaerber@suse.de> <1376606111-3518-3-git-send-email-afaerber@suse.de> <52209D6D.4020307@suse.de> <5220A3BC.4070000@ozlabs.ru> In-Reply-To: <5220A3BC.4070000@ozlabs.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 2/4] spapr: Use DeviceClass::fw_name for device tree CPU node List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: Prerna Saxena , qemu-ppc , Alexander Graf , qemu-devel@nongnu.org Am 30.08.2013 15:53, schrieb Alexey Kardashevskiy: > On 08/30/2013 11:26 PM, Andreas F=C3=A4rber wrote: >> Am 30.08.2013 15:21, schrieb Alexander Graf: >>> >>> On 16.08.2013, at 00:35, Andreas F=C3=A4rber wrote: >>> >>>> Instead of relying on cpu_model, obtain the device tree node label >>>> per CPU. Use DeviceClass::fw_name when available. This implicitly >>>> resolves HOST@0 node labels for those CPUs through inheritance. >>>> >>>> Whenever DeviceClass::fw_name is not available, derive it from the C= PU's >>>> type name and fill it in for that class with a "PowerPC," prefix for >>>> PAPR compliance. >>> >>> Could we just mandate the fw_name field to always be set for all clas= ses instead? >> >> Sure, we can assert it. But we would then need to set fw_name for the >> various 970 families at least, which I have been using with pseries in >> the past. Cell and POWER6 are TODO so I'm not concerned about them. No= t >> sure about RS64 that Alexey mentioned - I wouldn't be able to test. >> Would be bad to regress and abort with CPU models that were working ok= ay >> before. >=20 > If we generated fw_name as it would have been done by the current helpe= rs, > how would anything regress? Well, before, you were talking about assigning "reasonable fw_name values", and that would for me require knowledge of which value is reasonable (i.e., correct) for a certain CPU, and I don't have boards to check most of them. My proposal would be to just do it for the sPAPR-compatible (not sure if that is what you meant with "supported"?) CPUs (because that's where we intend to use it) and mark the ones we don't know exactly with /* ??? */ as done elsewhere in ppc code. 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