[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] macio: Convert to realize()

From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH] macio: Convert to realize()
Date: Sat, 16 May 2015 14:42:35 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 15.05.15 15:43, Markus Armbruster wrote:
> Alexander Graf <address@hidden> writes:
>> On 17.03.15 08:46, Markus Armbruster wrote:
>>> Alexander Graf <address@hidden> writes:
>>>> On 09.03.15 19:30, Markus Armbruster wrote:
>>>>> Alexander Graf <address@hidden> writes:
>>>>>> On 27.02.15 13:43, Markus Armbruster wrote:
>>>>>>> Convert device models "macio-oldworld" and "macio-newworld".
>>>>>>> Signed-off-by: Markus Armbruster <address@hidden>
>>>>>>> ---
>>>>>>> Depends on my "[PATCH 00/10] pci: Partial conversion to realize",
>>>>>>> which is in Michael's latest pull request.
>>>>>> Can you please poke me again when it landed?
>>>>> Applies cleanly to master now (commit 277263e).
>>>> Hrm, does not seem to apply cleanly now. How about we postpone this to
>>>> 2.4? It's not really crucial for 2.3 and we're in hard freeze now.
>>> Sad (it's been on list for almost three weeks, most of the time waiting
>>> for the PCI pull), but it's clearly your choice to make.
>> Yeah, but we're past hard freeze and I'd consider this not critical
>> enough to warrant potential breakage.
>>> git-am doesn't dare to apply the patch on list, but git-cherry-pick
>>> applies the commit from which it was formatted without a peep.  Result
>>> appended, just in case you'd like to consider it.
>> Awesome, that was quick. Thanks, applied to ppc-next-2.4.
> Pull request ETA?  I don't mean to be pushy, but I've been trying to get
> this in since February, and I got more work depending on it...

Some of the patches in David's latest spapr queue are regressing
compilation on older libfdt versions right now. If I don't see patches
to fix this, I'll just remove them from my queue again.

I could also use some help triaging the current autotest failures:


A good amount of those is probably upstream kernel breakage, but it'd be
good to know for sure.


reply via email to

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