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

[BALATON Zoltan <balaton@eik.bme.hu>]

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 <david@gibson.dropbear.id.au> 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