On 5/29/19 8:08 AM, Markus Armbruster wrote:
> Peter Maydell writes:
>
>> On Mon, 27 May 2019 at 08:52, Markus Armbruster wrote:
>>>
>>> Peter Maydell writes:
Suggestions for how to restructure reset so this doesn't
happen are welcome... "reset follows the bus hierarchy"
works we
Peter Maydell writes:
> On Mon, 27 May 2019 at 08:52, Markus Armbruster wrote:
>>
>> Peter Maydell writes:
>> > Suggestions for how to restructure reset so this doesn't
>> > happen are welcome... "reset follows the bus hierarchy"
>> > works well in some places but is a bit weird in others
>> >
On 5/28/19 10:33 AM, Cornelia Huck wrote:
> On Tue, 28 May 2019 10:29:09 +0200
> David Hildenbrand wrote:
>
>> On 24.05.19 21:45, Christian Borntraeger wrote:
>>>
>>>
>>> On 24.05.19 21:00, David Hildenbrand wrote:
On 24.05.19 20:36, David Hildenbrand wrote:
> On 24.05.19 20:28, Chri
On Tue, 28 May 2019 10:29:09 +0200
David Hildenbrand wrote:
> On 24.05.19 21:45, Christian Borntraeger wrote:
> >
> >
> > On 24.05.19 21:00, David Hildenbrand wrote:
> >> On 24.05.19 20:36, David Hildenbrand wrote:
> >>> On 24.05.19 20:28, Christian Borntraeger wrote:
>
>
>
On 24.05.19 21:45, Christian Borntraeger wrote:
>
>
> On 24.05.19 21:00, David Hildenbrand wrote:
>> On 24.05.19 20:36, David Hildenbrand wrote:
>>> On 24.05.19 20:28, Christian Borntraeger wrote:
On 24.05.19 20:04, David Hildenbrand wrote:
> On 24.05.19 19:54, Philippe Mathieu
Peter Maydell writes:
> On Mon, 27 May 2019 at 08:52, Markus Armbruster wrote:
>>
>> Peter Maydell writes:
>> > Suggestions for how to restructure reset so this doesn't
>> > happen are welcome... "reset follows the bus hierarchy"
>> > works well in some places but is a bit weird in others
>> >
On Mon, 27 May 2019 at 08:52, Markus Armbruster wrote:
>
> Peter Maydell writes:
> > Suggestions for how to restructure reset so this doesn't
> > happen are welcome... "reset follows the bus hierarchy"
> > works well in some places but is a bit weird in others
> > (for SoC containers and the like
Cc'ing Damien who is working on "multi-phase reset mechanism".
On 5/27/19 9:52 AM, Markus Armbruster wrote:
> Peter Maydell writes:
>
>> On Fri, 24 May 2019 at 20:47, Christian Borntraeger
>> wrote:
>>> While this patch is certainly ok, I find it disturbing that qdev devices
>>> are being rese
Peter Maydell writes:
> On Fri, 24 May 2019 at 20:47, Christian Borntraeger
> wrote:
>> While this patch is certainly ok, I find it disturbing that qdev devices are
>> being resetted,
>> but qom devices not.
>
> It's not a qdev-vs-QOM thing. Anything which is a DeviceState
> has a reset method,
On Fri, 24 May 2019 at 20:47, Christian Borntraeger
wrote:
> While this patch is certainly ok, I find it disturbing that qdev devices are
> being resetted,
> but qom devices not.
It's not a qdev-vs-QOM thing. Anything which is a DeviceState
has a reset method, but only devices which are somewher
On 24.05.19 21:45, Christian Borntraeger wrote:
>
>
> On 24.05.19 21:00, David Hildenbrand wrote:
>> On 24.05.19 20:36, David Hildenbrand wrote:
>>> On 24.05.19 20:28, Christian Borntraeger wrote:
On 24.05.19 20:04, David Hildenbrand wrote:
> On 24.05.19 19:54, Philippe Mathieu
On 24.05.19 21:00, David Hildenbrand wrote:
> On 24.05.19 20:36, David Hildenbrand wrote:
>> On 24.05.19 20:28, Christian Borntraeger wrote:
>>>
>>>
>>> On 24.05.19 20:04, David Hildenbrand wrote:
On 24.05.19 19:54, Philippe Mathieu-Daudé wrote:
> Hi Christian,
>
> I'm having ha
On 24.05.19 20:36, David Hildenbrand wrote:
> On 24.05.19 20:28, Christian Borntraeger wrote:
>>
>>
>> On 24.05.19 20:04, David Hildenbrand wrote:
>>> On 24.05.19 19:54, Philippe Mathieu-Daudé wrote:
Hi Christian,
I'm having hard time to understand why the S390_IPL object calls
On 24.05.19 20:28, Christian Borntraeger wrote:
>
>
> On 24.05.19 20:04, David Hildenbrand wrote:
>> On 24.05.19 19:54, Philippe Mathieu-Daudé wrote:
>>> Hi Christian,
>>>
>>> I'm having hard time to understand why the S390_IPL object calls
>>> qemu_register_reset(qdev_reset_all_fn) in its realiz
On 5/24/19 8:04 PM, David Hildenbrand wrote:
> On 24.05.19 19:54, Philippe Mathieu-Daudé wrote:
>> Hi Christian,
>>
>> I'm having hard time to understand why the S390_IPL object calls
>> qemu_register_reset(qdev_reset_all_fn) in its realize() method, while
>> being QOM'ified (it has a reset method)
On 24.05.19 20:04, David Hildenbrand wrote:
> On 24.05.19 19:54, Philippe Mathieu-Daudé wrote:
>> Hi Christian,
>>
>> I'm having hard time to understand why the S390_IPL object calls
>> qemu_register_reset(qdev_reset_all_fn) in its realize() method, while
>> being QOM'ified (it has a reset metho
On 24.05.19 19:54, Philippe Mathieu-Daudé wrote:
> Hi Christian,
>
> I'm having hard time to understand why the S390_IPL object calls
> qemu_register_reset(qdev_reset_all_fn) in its realize() method, while
> being QOM'ified (it has a reset method).
>
> It doesn't seem to have a qdev children adde
Hi Christian,
I'm having hard time to understand why the S390_IPL object calls
qemu_register_reset(qdev_reset_all_fn) in its realize() method, while
being QOM'ified (it has a reset method).
It doesn't seem to have a qdev children added explicitly to it.
I see it is used as a singleton, what else
18 matches
Mail list logo
