From: "Andreas Färber" <afaerber@suse.de>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Prerna Saxena <prerna@linux.vnet.ibm.com>,
qemu-ppc <qemu-ppc@nongnu.org>, Alexander Graf <agraf@suse.de>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 2/4] spapr: Use DeviceClass::fw_name for device tree CPU node
Date: Fri, 30 Aug 2013 15:58:40 +0200 [thread overview]
Message-ID: <5220A510.1040807@suse.de> (raw)
In-Reply-To: <5220A3BC.4070000@ozlabs.ru>
Am 30.08.2013 15:53, schrieb Alexey Kardashevskiy:
> On 08/30/2013 11:26 PM, Andreas Färber wrote:
>> Am 30.08.2013 15:21, schrieb Alexander Graf:
>>>
>>> On 16.08.2013, at 00:35, Andreas Färber 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 CPU'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 classes 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. Not
>> 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 okay
>> before.
>
> If we generated fw_name as it would have been done by the current helpers,
> 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
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2013-08-30 13:59 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-15 22:35 [Qemu-devel] [PATCH v2 0/4] target-ppc: Tidy sPAPR device tree CPU nodes Andreas Färber
2013-08-15 22:35 ` [Qemu-devel] [PATCH v2 1/4] target-ppc: Fill in OpenFirmware names for some PowerPCCPU families Andreas Färber
2013-09-10 4:15 ` Alexey Kardashevskiy
2013-09-16 14:16 ` Alexey Kardashevskiy
2013-09-25 9:01 ` Alexey Kardashevskiy
2013-09-30 17:55 ` Alexander Graf
2013-10-07 13:59 ` Alexey Kardashevskiy
2013-08-15 22:35 ` [Qemu-devel] [PATCH v2 2/4] spapr: Use DeviceClass::fw_name for device tree CPU node Andreas Färber
2013-08-29 4:29 ` Alexey Kardashevskiy
2013-08-29 5:30 ` Andreas Färber
2013-08-30 6:05 ` Alexey Kardashevskiy
2013-08-30 13:54 ` Alexander Graf
2013-08-30 14:00 ` Andreas Färber
2013-08-30 14:15 ` Alexander Graf
2013-08-30 13:21 ` Alexander Graf
2013-08-30 13:26 ` Andreas Färber
2013-08-30 13:52 ` Alexander Graf
2013-08-30 13:53 ` Alexey Kardashevskiy
2013-08-30 13:58 ` Andreas Färber [this message]
2013-08-30 14:03 ` Alexander Graf
2013-08-15 22:35 ` [Qemu-devel] [PATCH v2 3/4] spapr: Improve device tree CPU node for -cpu host with unknown OF name Andreas Färber
2013-08-15 22:40 ` Andreas Färber
2013-08-29 4:33 ` [Qemu-devel] [Qemu-ppc] " Alexey Kardashevskiy
2013-08-29 5:30 ` Andreas Färber
2013-08-15 22:35 ` [Qemu-devel] [PATCH v2 4/4] spapr: Suppress underscores in device tree CPU node Andreas Färber
2013-08-29 4:39 ` [Qemu-devel] [Qemu-ppc] " Alexey Kardashevskiy
2013-08-29 5:33 ` Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5220A510.1040807@suse.de \
--to=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=prerna@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.