From: David Gibson <david@gibson.dropbear.id.au>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Peter Maydell <peter.maydell@linaro.org>,
qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH] hw/intc/ppc-uic: Make default dcr-base 0xc0, not 0x30
Date: Tue, 12 Jan 2021 15:18:05 +1100 [thread overview]
Message-ID: <20210112041805.GM3051@yekko.fritz.box> (raw)
In-Reply-To: <alpine.LMD.2.03.2101120224300.11445@eik.bme.hu>
[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]
On Tue, Jan 12, 2021 at 02:25:58AM +0100, BALATON Zoltan wrote:
> On Tue, 12 Jan 2021, David Gibson wrote:
> > On Mon, Jan 11, 2021 at 09:30:07PM +0000, Peter Maydell wrote:
> > > In commit 34d0831f38fd8 the ppc-uic device was added, with a dcr-base
> > > property. The intention was that the default value of dcr-base should be
> > > the one that most of our boards need, so that in the common case they
> > > don't need to specify a property value.
> > >
> > > All QEMU boards with a UIC use a dcr-base of 0xc0, with the exception of
> > > sam460ex which has four UICs and so puts them at 0xc0, 0xd0, 0xe0, 0xf0.
> > > So 0xc0 is the obvious right choice for the default dcr-base.
> > >
> > > The board code conversions in commits 0270d74ef88623505 (bamboo) and
> > > c5ac9dc64fa552a6 (virtex_ml507) assumed that default was 0xc0. Unfortunately
> > > the actual default in 34d0831f38fd8 was 0x30, by mistake, so the
> > > bamboo and virtex_ml507 boards were broken as they were converted
> > > away from ppcuic_init() (which always specifies the dcr_base property
> > > value explicitly).
> > >
> > > Set the default dcr-base to 0xc0 as was intended, fixing bamboo and
> > > virtex_ml507.
> > >
> > > Fixes: 34d0831f38fd8
> > > Reported-by: Nathan Chancellor <natechancellor@gmail.com>
> > > Suggested-by: BALATON Zoltan <balaton@eik.bme.hu>
> > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> >
> > Applied, thanks.
>
> Will you take my series too?
>
> http://patchwork.ozlabs.org/project/qemu-devel/list/?series=223439
Huh. I will now I've seen it.
> I've cc'd you but your DNS seems to not return an MX record most of the time
> still so these are bouncing back.
Ugh. This is weird. I know the DNS went out for a little while, but
some of your mails have come through, and AFAICT it's been working for
most people most of the time since that incident. I'm wondering if
something on your side is negative caching for too long.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2021-01-12 4:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 21:30 [PATCH] hw/intc/ppc-uic: Make default dcr-base 0xc0, not 0x30 Peter Maydell
2021-01-12 0:12 ` David Gibson
2021-01-12 1:25 ` BALATON Zoltan
2021-01-12 4:18 ` David Gibson [this message]
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=20210112041805.GM3051@yekko.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=balaton@eik.bme.hu \
--cc=peter.maydell@linaro.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).