qemu-devel
[Top][All Lists]
Advanced

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

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


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

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.

Thank you,
BALATON Zoltan


reply via email to

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