[Top][All Lists]

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

Re: [PATCH v8 00/11] Multi-phase reset mechanism

From: Peter Maydell
Subject: Re: [PATCH v8 00/11] Multi-phase reset mechanism
Date: Thu, 30 Jan 2020 14:29:49 +0000

On Thu, 23 Jan 2020 at 13:28, Damien Hedde <address@hidden> wrote:
> Hi all,
> The purpose of this series is to split the current reset procedure
> into multiple phases. This will help to solve some ordering
> difficulties we have during reset.
> This is a ready to merge version. I've taken the few remarks of
> Philippe about v7 in account. Thanks to him for all the tests he did.
> This series adds resettable interface and transitions base Device and
> Bus classes (sysbus subclasses are ok too). It provides new reset
> functions but does not switch anymore the old functions
> (device_reset() and qdev/qbus_reset_all()) to resettable interface.
> These functions keep the exact same behavior as before.
> The series also transition the main reset handlers registration which
> has no impact until devices and buses are transitioned.
> The series is organized as follows:
> Patch 1 prepare the reset transition. Patch 2 adds some utility trace
> events. Patches 3 to 8 adds resettable api in devices and buses. Patch
> 9 adds some documentation. Patches 10 and 11 transition the call sites
> of qemu_register_reset(qdev/qbus_reset_all_fn, ...).
> After this series, the plan is then to transition devices, buses and
> legacy reset call sites. Devices and buses have to be transitioned
> from mother class to daughter classes order but until the final
> (daughter) class is transitioned, old monolitic reset behavior will
> be kept for this class.

Applied to target-arm.next, thanks (it seems the easiest way
to take the series). I made a few minor fixups for textual
conflicts with other patches that have already hit master.

-- PMM

reply via email to

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