This series delay timer_new from init into realize to avoid memleaks when we call 'device_list_properties'.
And do timer_free only in s390x_cpu_finalize because it's hotplugable. However, It's not valid in mos6522
if we move timer_new from init to realize, because it's never called at all. So we also add calls to mos6522_realize()
in mac_via_realize to make this move to be valid.

v1:
   - Delay timer_new() from init() to realize() to fix memleaks.
v2:
   - Similarly to other cleanups, move timer_new into realize in target/s390x/cpu.c (Suggested by Philippe Mathieu-Daudé).
   - Send these two patches as a series instead of send each as a single patch but with wrong subject in v1.
v3:
   - It's not valid in mos6522 if we move timer_new from init to realize, because it's never called at all.
     Thus, we remove null check in reset, and add calls to mos6522_realize() in mac_via_realize to make this move to be valid.
   - split patch by device to make it more clear.

Pan Nengyuan (6):
  s390x: fix memleaks in cpu_finalize
  hw/arm/pxa2xx: move timer_new from init() into realize() to avoid
    memleaks
  hw/arm/spitz: move timer_new from init() into realize() to avoid
    memleaks
  hw/arm/strongarm: move timer_new from init() into realize() to avoid
    memleaks
  hw/misc/mos6522: move timer_new from init() into realize() to avoid
    memleaks
  hw/timer/cadence_ttc: move timer_new from init() into realize() to
    avoid memleaks

 hw/arm/pxa2xx.c        | 17 +++++++++++------
 hw/arm/spitz.c         |  8 +++++++-
 hw/arm/strongarm.c     | 18 ++++++++++++------
 hw/misc/mac_via.c      |  5 +++++
 hw/misc/mos6522.c      |  6 ++++++
 hw/timer/cadence_ttc.c | 16 +++++++++++-----
 target/s390x/cpu.c     | 22 ++++++++++++++++++----
 7 files changed, 70 insertions(+), 22 deletions(-)

-- 
2.18.2

On Thu, 27 Feb 2020 at 02:35, Pan Nengyuan <pannengyuan@huawei.com> wrote:
>
> This series delay timer_new from init into realize to avoid memleaks when we call 'device_list_properties'.
> And do timer_free only in s390x_cpu_finalize because it's hotplugable. However, It's not valid in mos6522
> if we move timer_new from init to realize, because it's never called at all. So we also add calls to mos6522_realize()
> in mac_via_realize to make this move to be valid.
>
> v1:
>    - Delay timer_new() from init() to realize() to fix memleaks.
> v2:
>    - Similarly to other cleanups, move timer_new into realize in target/s390x/cpu.c (Suggested by Philippe Mathieu-Daudé).
>    - Send these two patches as a series instead of send each as a single patch but with wrong subject in v1.
> v3:
>    - It's not valid in mos6522 if we move timer_new from init to realize, because it's never called at all.
>      Thus, we remove null check in reset, and add calls to mos6522_realize() in mac_via_realize to make this move to be valid.
>    - split patch by device to make it more clear.

Hi; I've applied patches 2, 3, 4 and 6 to target-arm.next,
since I think those ones are OK and they're all arm related.

You've already got review comment for patch 1 (s390)
and 5 (m68k mac_via/mos6522).

thanks
-- PMM

On 3/2/2020 9:21 PM, Peter Maydell wrote:
> On Thu, 27 Feb 2020 at 02:35, Pan Nengyuan <pannengyuan@huawei.com> wrote:
>>
>> This series delay timer_new from init into realize to avoid memleaks when we call 'device_list_properties'.
>> And do timer_free only in s390x_cpu_finalize because it's hotplugable. However, It's not valid in mos6522
>> if we move timer_new from init to realize, because it's never called at all. So we also add calls to mos6522_realize()
>> in mac_via_realize to make this move to be valid.
>>
>> v1:
>>    - Delay timer_new() from init() to realize() to fix memleaks.
>> v2:
>>    - Similarly to other cleanups, move timer_new into realize in target/s390x/cpu.c (Suggested by Philippe Mathieu-Daudé).
>>    - Send these two patches as a series instead of send each as a single patch but with wrong subject in v1.
>> v3:
>>    - It's not valid in mos6522 if we move timer_new from init to realize, because it's never called at all.
>>      Thus, we remove null check in reset, and add calls to mos6522_realize() in mac_via_realize to make this move to be valid.
>>    - split patch by device to make it more clear.
> 
> Hi; I've applied patches 2, 3, 4 and 6 to target-arm.next,
> since I think those ones are OK and they're all arm related.
> 
> You've already got review comment for patch 1 (s390)
> and 5 (m68k mac_via/mos6522).

Fine, thanks.

> 
> thanks
> -- PMM
>