Message ID | 20200123132823.1117486-1-damien.hedde@greensocs.com |
---|---|
Headers | show |
Series | Multi-phase reset mechanism | expand |
On Thu, 23 Jan 2020 at 13:28, Damien Hedde <damien.hedde@greensocs.com> wrote: > v8: > + patch 3&5: ResettableState::count type from uint32_t to unsigned > (Philippe) We'll have to change that back if we ever want to migrate the count (migration insists on fixed-sized types), but I guess we can do that when we get to it... -- PMM
On 1/24/20 11:05 AM, Peter Maydell wrote: > On Thu, 23 Jan 2020 at 13:28, Damien Hedde <damien.hedde@greensocs.com> wrote: >> v8: >> + patch 3&5: ResettableState::count type from uint32_t to unsigned >> (Philippe) > > We'll have to change that back if we ever want to migrate > the count (migration insists on fixed-sized types), but > I guess we can do that when we get to it... Oh I forgot about migration :( (this was just a suggestion, not a requirement). If you are happy with v7/v8 you can consider to apply v7 instead, the only difference is a one-line change in Makefile.objs (which ends no modified) and few Tested-by/Reviewed-by tags: https://patchew.org/QEMU/20200115123620.250132-1-damien.hedde@greensocs.com/diff/20200123132823.1117486-1-damien.hedde@greensocs.com/ Regards, Phil.
On Fri, 24 Jan 2020 at 10:17, Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > On 1/24/20 11:05 AM, Peter Maydell wrote: > > On Thu, 23 Jan 2020 at 13:28, Damien Hedde <damien.hedde@greensocs.com> wrote: > >> v8: > >> + patch 3&5: ResettableState::count type from uint32_t to unsigned > >> (Philippe) > > > > We'll have to change that back if we ever want to migrate > > the count (migration insists on fixed-sized types), but > > I guess we can do that when we get to it... > > Oh I forgot about migration :( (this was just a suggestion, not a > requirement). Migration handling is going to require changes anyway, flipping the type of the field will just be a minor part of that patch if/when it arrives. It seems easier to take v8 if it's otherwise OK. thanks -- PMM
On 1/24/20 11:17 AM, Philippe Mathieu-Daudé wrote: > On 1/24/20 11:05 AM, Peter Maydell wrote: >> On Thu, 23 Jan 2020 at 13:28, Damien Hedde >> <damien.hedde@greensocs.com> wrote: >>> v8: >>> + patch 3&5: ResettableState::count type from uint32_t to unsigned >>> (Philippe) >> >> We'll have to change that back if we ever want to migrate >> the count (migration insists on fixed-sized types), but >> I guess we can do that when we get to it... > > Oh I forgot about migration :( (this was just a suggestion, not a > requirement). I forgot it too, and I probably put a uint32_t in the first place because of migration in an earlier version of the patchset... Damien
On 1/24/20 11:18 AM, Peter Maydell wrote: > On Fri, 24 Jan 2020 at 10:17, Philippe Mathieu-Daudé <philmd@redhat.com> wrote: >> >> On 1/24/20 11:05 AM, Peter Maydell wrote: >>> On Thu, 23 Jan 2020 at 13:28, Damien Hedde <damien.hedde@greensocs.com> wrote: >>>> v8: >>>> + patch 3&5: ResettableState::count type from uint32_t to unsigned >>>> (Philippe) >>> >>> We'll have to change that back if we ever want to migrate >>> the count (migration insists on fixed-sized types), but >>> I guess we can do that when we get to it... >> >> Oh I forgot about migration :( (this was just a suggestion, not a >> requirement). > > Migration handling is going to require changes anyway, flipping > the type of the field will just be a minor part of that patch > if/when it arrives. It seems easier to take v8 if it's otherwise OK. > Hi Peter, For me v8 is ok. In which pull queue should it be taken ? Thanks, Damien
On Thu, 23 Jan 2020 at 13:28, Damien Hedde <damien.hedde@greensocs.com> 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. thanks -- PMM