qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/3] aspeed: cleanups and extensions


From: Cédric Le Goater
Subject: Re: [Qemu-devel] [PATCH v2 0/3] aspeed: cleanups and extensions
Date: Mon, 20 May 2019 15:11:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

Hello,

On 5/20/19 1:09 PM, Philippe Mathieu-Daudé wrote:
> On 5/20/19 9:47 AM, Cédric Le Goater wrote:
>> Hello,
>>
>> On 5/6/19 4:20 PM, Cédric Le Goater wrote:
>>> Hello,
>>>
>>> Here is a series adding a couple of cleanups to the Aspeed SoCs to
>>> prepare ground for extensions and new SoCs.
>>>
>>> Thanks,
>>>
>>> C.
>>>
>>> Changes since v1:
>>>
>>>  - moved enum defining the Aspeed controller names under aspeed_soc.h
>>>  - removed AspeedSoCInfo 'sdram_base' field
>>>  - fixed clang compilation
>>>
>>> Cédric Le Goater (3):
>>>   aspeed: add a per SoC mapping for the interrupt space
>>>   aspeed: add a per SoC mapping for the memory space
>>
>> I think these two patches are fine to go even if Philippe's comments 
>> are not addressed. There are valid but not a blocker to me.  
> 
> OK, so:
> 
> patches 1 & 2:
> Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
> 
> Peter, can you apply them?
> 
>>
>>>   aspeed: use sysbus_init_child_obj() to initialize children
>>
>> Philippe has taken over this patch in a larger series which will go 
>> through Eduardo's tree, if I understood well the emails. When merged, 
>> we can try to re-merge the RTC patchset from Joel. I think we made 
>> things a little more complex than they should have been. 
> 
> Sorry if I made things more complex. I went on PTO after sending

PTO ?

> "hw/arm: Use object_initialize_child for correct reference counting" [*]
> then was slow to address Thomas/Markus comments.
> Then maybe I should start pinging maintainer more aggressively when my
> series are reviewed but not merged, to not delay further developments.

Well, I don't know if there is a good method for transversal patchsets 
like this one. I guess it depends on the area. 

The overall merging process became more complex that expected after our 
three simple patchsets (Yours, Joel's and mine) collided. 
 
> I took note of your comment and will try to keep things simple the next
> time.

It's not a big issue. We have time to provide fixes before 4.1 is out. 
Let's put some energy to move on and get code merged.

Peter, 

do you want me to resend with only the two first patches and include 
Joel's in the same series ? I would leave out the part Philippe is 
covering in his object_initialize_child() patchset.

Thanks,

C.




reply via email to

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