qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PULL 00/24] ppc-for-2.12 queue 20180302


From: BALATON Zoltan
Subject: Re: [Qemu-ppc] [PULL 00/24] ppc-for-2.12 queue 20180302
Date: Fri, 2 Mar 2018 22:51:42 +0100 (CET)
User-agent: Alpine 2.21 (BSF 202 2017-01-01)

On Fri, 2 Mar 2018, BALATON Zoltan wrote:
On Fri, 2 Mar 2018, Peter Maydell wrote:
On 2 March 2018 at 06:03, David Gibson <address@hidden> wrote:
The following changes since commit 0dc8ae5e8e693737dfe65ba02d0c6eccb58a9c67:

Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20180301-v2' into staging (2018-03-01 17:08:16 +0000)

are available in the Git repository at:

  git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180302

for you to fetch changes up to 57ae75b2e401f1d04f37a8cd26212eb3134c51a6:

hw/ppc/spapr,e500: Use new property "stdout-path" for boot console (2018-03-02 12:24:44 +1100)

----------------------------------------------------------------
ppc patch queue 2018-03-02

Here's the next batch of accumulated spapr and ppc patches.
Highlights are:
    * New Sam460ex machine type
    * Yet more fixes related to vcpu id allocation for spapr
    * Numerous macio cleanupsr
    * Some enhancements to the Spectre/Meltdown fixes for pseries,
      allowing use of a better mitigation for indirect branch based
      exploits
    * New pseries machine types with Spectre/Meltdown mitigations
      enabled (stop gap until libvirt and management understands the
      machine options)
    * A handful of other fixes


Hi. This generates a compile error from some compilers in my test set
(I think just the older gccs):

/home/petmay01/linaro/qemu-for-merges/hw/ppc/ppc440_uc.c: In function
‘ppc460ex_pcie_realize’:
/home/petmay01/linaro/qemu-for-merges/hw/ppc/ppc440_uc.c:1054:5:
error: ‘id’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
    snprintf(buf, sizeof(buf), "pcie%d-io", id);
    ^
cc1: all warnings being treated as errors

Looks like a valid complaint to me -- the realize function
should check that dcrn_base was set to a valid value, fail
realize if it wasn't, and have a 'default:' case in the
switch with g_assert_not_reached().

I've sent an updated patch (v3) that should fix this.

Wait, I've just realised this is not even in this pull request but already in master but it was not compiled before the machine that uses it was added now. So a v3 of the original patch is not appropriate. Instead, I've sent a fixup patch now that should be applied before this pull request to hopefully fix the problem. Sorry for the inconvenience this caused.

Thank you,
BALATON Zoltan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]