On Mon, 13 Jul 2015 18:06:45 +0200
Andreas Färber wrote:
> Found it. So the problem *is* different from what I understood! It's not
> directly attached to /machine by s390x code, but rather instantiated via
> -device by the user.
>
> Peter C. suggested you to do it in realize, which affects all
Am 13.07.2015 um 16:37 schrieb Cornelia Huck:
> On Mon, 13 Jul 2015 16:20:09 +0200
> Andreas Färber wrote:
>
>> Am 13.07.2015 um 16:11 schrieb Cornelia Huck:
>>> On Mon, 13 Jul 2015 14:22:05 +0200
>>> Christian Borntraeger wrote:
>>>
>>> Any objections against taking this through s390-next? I'd
On 13 July 2015 at 16:38, Cornelia Huck wrote:
> So why does a pure Device have a reset callback then that is not called
> by default?
This is (as I understand it) basically historical legacy from
qdev. The qdev model puts every device on a bus of some kind,
and then says that it's the bus that h
Am 13.07.2015 um 17:38 schrieb Cornelia Huck:
> Really, I think we're moving in circles here. First, the device should
> not live on the sysbus as it does not fit the perceived sysbus
> semantics. As there is no natural bus for it to live on, it becomes a
> pure device. Which is not reset, because
On Mon, 13 Jul 2015 17:05:31 +0200
Andreas Färber wrote:
> Am 13.07.2015 um 16:30 schrieb Christian Borntraeger:
> > Am 13.07.2015 um 16:20 schrieb Andreas Färber:
> >> Am 13.07.2015 um 16:11 schrieb Cornelia Huck:
> >>> On Mon, 13 Jul 2015 14:22:05 +0200
> >>> Christian Borntraeger wrote:
> >>>
Am 13.07.2015 um 16:30 schrieb Christian Borntraeger:
> Am 13.07.2015 um 16:20 schrieb Andreas Färber:
>> Am 13.07.2015 um 16:11 schrieb Cornelia Huck:
>>> On Mon, 13 Jul 2015 14:22:05 +0200
>>> Christian Borntraeger wrote:
>>>
Am 09.07.2015 um 18:51 schrieb Cornelia Huck:
> Devices that
On Mon, 13 Jul 2015 16:20:09 +0200
Andreas Färber wrote:
> Am 13.07.2015 um 16:11 schrieb Cornelia Huck:
> > On Mon, 13 Jul 2015 14:22:05 +0200
> > Christian Borntraeger wrote:
> >
> >> Am 09.07.2015 um 18:51 schrieb Cornelia Huck:
> >>> Devices that don't live on a bus aren't caught by the nor
Am 13.07.2015 um 16:20 schrieb Andreas Färber:
> Am 13.07.2015 um 16:11 schrieb Cornelia Huck:
>> On Mon, 13 Jul 2015 14:22:05 +0200
>> Christian Borntraeger wrote:
>>
>>> Am 09.07.2015 um 18:51 schrieb Cornelia Huck:
Devices that don't live on a bus aren't caught by the normal device
re
On 09/07/2015 20:53, Peter Crosthwaite wrote:
>
> Any reason to not just rip though the whole QOM tree and reset every
> device regardless of bus/containuer arch? IIRC the semantics for
> ->reset (and at least devices_reset()) are "pull the plug out of wall
> and put it back in again" so there i
Am 13.07.2015 um 16:11 schrieb Cornelia Huck:
> On Mon, 13 Jul 2015 14:22:05 +0200
> Christian Borntraeger wrote:
>
>> Am 09.07.2015 um 18:51 schrieb Cornelia Huck:
>>> Devices that don't live on a bus aren't caught by the normal device
>>> reset logic. Let's register a reset handler for those de
On Mon, 13 Jul 2015 14:22:05 +0200
Christian Borntraeger wrote:
> Am 09.07.2015 um 18:51 schrieb Cornelia Huck:
> > Devices that don't live on a bus aren't caught by the normal device
> > reset logic. Let's register a reset handler for those devices during
> > device realization that calls the re
Am 09.07.2015 um 18:51 schrieb Cornelia Huck:
> Devices that don't live on a bus aren't caught by the normal device
> reset logic. Let's register a reset handler for those devices during
> device realization that calls the reset handler for the associated
> device class.
>
> Suggested-by: Peter Cr
On Thu, Jul 9, 2015 at 9:59 AM, Andreas Färber wrote:
> Am 09.07.2015 um 18:51 schrieb Cornelia Huck:
>> Devices that don't live on a bus aren't caught by the normal device
>> reset logic. Let's register a reset handler for those devices during
>> device realization that calls the reset handler fo
Am 09.07.2015 um 18:51 schrieb Cornelia Huck:
> Devices that don't live on a bus aren't caught by the normal device
> reset logic. Let's register a reset handler for those devices during
> device realization that calls the reset handler for the associated
> device class.
>
> Suggested-by: Peter Cr
Devices that don't live on a bus aren't caught by the normal device
reset logic. Let's register a reset handler for those devices during
device realization that calls the reset handler for the associated
device class.
Suggested-by: Peter Crosthwaite
Signed-off-by: Cornelia Huck
---
hw/core/qdev
15 matches
Mail list logo