diff mbox

macio: Convert to realize()

Message ID 87wq2gjcc8.fsf@blackfin.pond.sub.org
State New
Headers show

Commit Message

Markus Armbruster March 17, 2015, 7:46 a.m. UTC 
Alexander Graf <agraf@suse.de> writes:

> On 09.03.15 19:30, Markus Armbruster wrote:
>> Alexander Graf <agraf@suse.de> writes:
>> 
>>> On 27.02.15 13:43, Markus Armbruster wrote:
>>>> Convert device models "macio-oldworld" and "macio-newworld".
>>>>
>>>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>>>> ---
>>>> Depends on my "[PATCH 00/10] pci: Partial conversion to realize",
>>>> which is in Michael's latest pull request.
>>>
>>> Can you please poke me again when it landed?
>> 
>> Applies cleanly to master now (commit 277263e).
>
> Hrm, does not seem to apply cleanly now. How about we postpone this to
> 2.4? It's not really crucial for 2.3 and we're in hard freeze now.

Sad (it's been on list for almost three weeks, most of the time waiting
for the PCI pull), but it's clearly your choice to make.

git-am doesn't dare to apply the patch on list, but git-cherry-pick
applies the commit from which it was formatted without a peep.  Result
appended, just in case you'd like to consider it.




From f366a9732b6790609cc89e0c9272899cfbbe4e02 Mon Sep 17 00:00:00 2001
From: Markus Armbruster <armbru@redhat.com>
Date: Tue, 20 Jan 2015 16:27:56 +0100
Subject: [PATCH] macio: Convert to realize()

Convert device models "macio-oldworld" and "macio-newworld".

Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
 hw/misc/macio/macio.c | 71 +++++++++++++++++++++++++++------------------------
 1 file changed, 38 insertions(+), 33 deletions(-)

Comments

Alexander Graf March 17, 2015, 7:50 a.m. UTC | #1 
On 17.03.15 08:46, Markus Armbruster wrote:
> Alexander Graf <agraf@suse.de> writes:
> 
>> On 09.03.15 19:30, Markus Armbruster wrote:
>>> Alexander Graf <agraf@suse.de> writes:
>>>
>>>> On 27.02.15 13:43, Markus Armbruster wrote:
>>>>> Convert device models "macio-oldworld" and "macio-newworld".
>>>>>
>>>>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>>>>> ---
>>>>> Depends on my "[PATCH 00/10] pci: Partial conversion to realize",
>>>>> which is in Michael's latest pull request.
>>>>
>>>> Can you please poke me again when it landed?
>>>
>>> Applies cleanly to master now (commit 277263e).
>>
>> Hrm, does not seem to apply cleanly now. How about we postpone this to
>> 2.4? It's not really crucial for 2.3 and we're in hard freeze now.
> 
> Sad (it's been on list for almost three weeks, most of the time waiting
> for the PCI pull), but it's clearly your choice to make.

Yeah, but we're past hard freeze and I'd consider this not critical
enough to warrant potential breakage.

> git-am doesn't dare to apply the patch on list, but git-cherry-pick
> applies the commit from which it was formatted without a peep.  Result
> appended, just in case you'd like to consider it.

Awesome, that was quick. Thanks, applied to ppc-next-2.4.


Alex
Markus Armbruster May 15, 2015, 1:43 p.m. UTC | #2 
Alexander Graf <agraf@suse.de> writes:

> On 17.03.15 08:46, Markus Armbruster wrote:
>> Alexander Graf <agraf@suse.de> writes:
>> 
>>> On 09.03.15 19:30, Markus Armbruster wrote:
>>>> Alexander Graf <agraf@suse.de> writes:
>>>>
>>>>> On 27.02.15 13:43, Markus Armbruster wrote:
>>>>>> Convert device models "macio-oldworld" and "macio-newworld".
>>>>>>
>>>>>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>>>>>> ---
>>>>>> Depends on my "[PATCH 00/10] pci: Partial conversion to realize",
>>>>>> which is in Michael's latest pull request.
>>>>>
>>>>> Can you please poke me again when it landed?
>>>>
>>>> Applies cleanly to master now (commit 277263e).
>>>
>>> Hrm, does not seem to apply cleanly now. How about we postpone this to
>>> 2.4? It's not really crucial for 2.3 and we're in hard freeze now.
>> 
>> Sad (it's been on list for almost three weeks, most of the time waiting
>> for the PCI pull), but it's clearly your choice to make.
>
> Yeah, but we're past hard freeze and I'd consider this not critical
> enough to warrant potential breakage.
>
>> git-am doesn't dare to apply the patch on list, but git-cherry-pick
>> applies the commit from which it was formatted without a peep.  Result
>> appended, just in case you'd like to consider it.
>
> Awesome, that was quick. Thanks, applied to ppc-next-2.4.

Pull request ETA?  I don't mean to be pushy, but I've been trying to get
this in since February, and I got more work depending on it...
Alexander Graf May 16, 2015, 12:42 p.m. UTC | #3 
On 15.05.15 15:43, Markus Armbruster wrote:
> Alexander Graf <agraf@suse.de> writes:
> 
>> On 17.03.15 08:46, Markus Armbruster wrote:
>>> Alexander Graf <agraf@suse.de> writes:
>>>
>>>> On 09.03.15 19:30, Markus Armbruster wrote:
>>>>> Alexander Graf <agraf@suse.de> writes:
>>>>>
>>>>>> On 27.02.15 13:43, Markus Armbruster wrote:
>>>>>>> Convert device models "macio-oldworld" and "macio-newworld".
>>>>>>>
>>>>>>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>>>>>>> ---
>>>>>>> Depends on my "[PATCH 00/10] pci: Partial conversion to realize",
>>>>>>> which is in Michael's latest pull request.
>>>>>>
>>>>>> Can you please poke me again when it landed?
>>>>>
>>>>> Applies cleanly to master now (commit 277263e).
>>>>
>>>> Hrm, does not seem to apply cleanly now. How about we postpone this to
>>>> 2.4? It's not really crucial for 2.3 and we're in hard freeze now.
>>>
>>> Sad (it's been on list for almost three weeks, most of the time waiting
>>> for the PCI pull), but it's clearly your choice to make.
>>
>> Yeah, but we're past hard freeze and I'd consider this not critical
>> enough to warrant potential breakage.
>>
>>> git-am doesn't dare to apply the patch on list, but git-cherry-pick
>>> applies the commit from which it was formatted without a peep.  Result
>>> appended, just in case you'd like to consider it.
>>
>> Awesome, that was quick. Thanks, applied to ppc-next-2.4.
> 
> Pull request ETA?  I don't mean to be pushy, but I've been trying to get
> this in since February, and I got more work depending on it...

Some of the patches in David's latest spapr queue are regressing
compilation on older libfdt versions right now. If I don't see patches
to fix this, I'll just remove them from my queue again.

I could also use some help triaging the current autotest failures:

  https://lists.gnu.org/archive/html/qemu-ppc-autotest/2015-05/msg00003.html

A good amount of those is probably upstream kernel breakage, but it'd be
good to know for sure.


Alex
Thomas Huth May 18, 2015, 7:11 a.m. UTC | #4 
On Sat, 16 May 2015 14:42:35 +0200
Alexander Graf <agraf@suse.de> wrote:

> 
> 
> On 15.05.15 15:43, Markus Armbruster wrote:
> > Alexander Graf <agraf@suse.de> writes:
> > 
> >> On 17.03.15 08:46, Markus Armbruster wrote:
> >>> Alexander Graf <agraf@suse.de> writes:
> >>>
> >>>> On 09.03.15 19:30, Markus Armbruster wrote:
> >>>>> Alexander Graf <agraf@suse.de> writes:
> >>>>>
> >>>>>> On 27.02.15 13:43, Markus Armbruster wrote:
> >>>>>>> Convert device models "macio-oldworld" and "macio-newworld".
> >>>>>>>
> >>>>>>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> >>>>>>> ---
> >>>>>>> Depends on my "[PATCH 00/10] pci: Partial conversion to realize",
> >>>>>>> which is in Michael's latest pull request.
> >>>>>>
> >>>>>> Can you please poke me again when it landed?
> >>>>>
> >>>>> Applies cleanly to master now (commit 277263e).
> >>>>
> >>>> Hrm, does not seem to apply cleanly now. How about we postpone this to
> >>>> 2.4? It's not really crucial for 2.3 and we're in hard freeze now.
> >>>
> >>> Sad (it's been on list for almost three weeks, most of the time waiting
> >>> for the PCI pull), but it's clearly your choice to make.
> >>
> >> Yeah, but we're past hard freeze and I'd consider this not critical
> >> enough to warrant potential breakage.
> >>
> >>> git-am doesn't dare to apply the patch on list, but git-cherry-pick
> >>> applies the commit from which it was formatted without a peep.  Result
> >>> appended, just in case you'd like to consider it.
> >>
> >> Awesome, that was quick. Thanks, applied to ppc-next-2.4.
> > 
> > Pull request ETA?  I don't mean to be pushy, but I've been trying to get
> > this in since February, and I got more work depending on it...
> 
> Some of the patches in David's latest spapr queue are regressing
> compilation on older libfdt versions right now. If I don't see patches
> to fix this, I'll just remove them from my queue again.

David is on vacation this week ... but if you like, I can try to come
up with a patch that checks for libfdt version 1.4.0 in QEMU's
configure script - would that be enough to keep the patches?

 Thomas
Peter Maydell May 18, 2015, 8:59 a.m. UTC | #5 
On 18 May 2015 at 08:11, Thomas Huth <thuth@redhat.com> wrote:
> On Sat, 16 May 2015 14:42:35 +0200
> Alexander Graf <agraf@suse.de> wrote:
>> Some of the patches in David's latest spapr queue are regressing
>> compilation on older libfdt versions right now. If I don't see patches
>> to fix this, I'll just remove them from my queue again.
>
> David is on vacation this week ... but if you like, I can try to come
> up with a patch that checks for libfdt version 1.4.0 in QEMU's
> configure script - would that be enough to keep the patches?

If we take that approach then you'll need to also update the
version of libfdt in our dtc submodule, which right now is only 1.3.0.

-- PMM
Thomas Huth May 18, 2015, 9:28 a.m. UTC | #6 
On Mon, 18 May 2015 09:59:02 +0100
Peter Maydell <peter.maydell@linaro.org> wrote:

> On 18 May 2015 at 08:11, Thomas Huth <thuth@redhat.com> wrote:
> > On Sat, 16 May 2015 14:42:35 +0200
> > Alexander Graf <agraf@suse.de> wrote:
> >> Some of the patches in David's latest spapr queue are regressing
> >> compilation on older libfdt versions right now. If I don't see patches
> >> to fix this, I'll just remove them from my queue again.
> >
> > David is on vacation this week ... but if you like, I can try to come
> > up with a patch that checks for libfdt version 1.4.0 in QEMU's
> > configure script - would that be enough to keep the patches?
> 
> If we take that approach then you'll need to also update the
> version of libfdt in our dtc submodule, which right now is only 1.3.0.

Ok, right, I'll send a patch that updates that, too.

 Thomas
diff mbox

Patch

diff --git a/hw/misc/macio/macio.c b/hw/misc/macio/macio.c
index 063ad80..e9037b0 100644
--- a/hw/misc/macio/macio.c
+++ b/hw/misc/macio/macio.c
@@ -126,17 +126,18 @@  static void macio_bar_setup(MacIOState *macio_state)
     }
 }
 
-static int macio_common_initfn(PCIDevice *d)
+static void macio_common_realize(PCIDevice *d, Error **errp)
 {
     MacIOState *s = MACIO(d);
     SysBusDevice *sysbus_dev;
-    int ret;
+    Error *err = NULL;
 
     d->config[0x3d] = 0x01; // interrupt on pin 1
 
-    ret = qdev_init(DEVICE(&s->cuda));
-    if (ret < 0) {
-        return ret;
+    object_property_set_bool(OBJECT(&s->cuda), true, "realized", &err);
+    if (err) {
+        error_propagate(errp, err);
+        return;
     }
     sysbus_dev = SYS_BUS_DEVICE(&s->cuda);
     memory_region_add_subregion(&s->bar, 0x16000,
@@ -144,12 +145,11 @@  static int macio_common_initfn(PCIDevice *d)
 
     macio_bar_setup(s);
     pci_register_bar(d, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &s->bar);
-
-    return 0;
 }
 
-static int macio_initfn_ide(MacIOState *s, MACIOIDEState *ide, qemu_irq irq0,
-                            qemu_irq irq1, int dmaid)
+static void macio_realize_ide(MacIOState *s, MACIOIDEState *ide,
+                              qemu_irq irq0, qemu_irq irq1, int dmaid,
+                              Error **errp)
 {
     SysBusDevice *sysbus_dev;
 
@@ -157,27 +157,31 @@  static int macio_initfn_ide(MacIOState *s, MACIOIDEState *ide, qemu_irq irq0,
     sysbus_connect_irq(sysbus_dev, 0, irq0);
     sysbus_connect_irq(sysbus_dev, 1, irq1);
     macio_ide_register_dma(ide, s->dbdma, dmaid);
-    return qdev_init(DEVICE(ide));
+    object_property_set_bool(OBJECT(ide), true, "realized", errp);
 }
 
-static int macio_oldworld_initfn(PCIDevice *d)
+static void macio_oldworld_realize(PCIDevice *d, Error **errp)
 {
     MacIOState *s = MACIO(d);
     OldWorldMacIOState *os = OLDWORLD_MACIO(d);
+    Error *err = NULL;
     SysBusDevice *sysbus_dev;
     int i;
     int cur_irq = 0;
-    int ret = macio_common_initfn(d);
-    if (ret < 0) {
-        return ret;
+
+    macio_common_realize(d, &err);
+    if (err) {
+        error_propagate(errp, err);
+        return;
     }
 
     sysbus_dev = SYS_BUS_DEVICE(&s->cuda);
     sysbus_connect_irq(sysbus_dev, 0, os->irqs[cur_irq++]);
 
-    ret = qdev_init(DEVICE(&os->nvram));
-    if (ret < 0) {
-        return ret;
+    object_property_set_bool(OBJECT(&os->nvram), true, "realized", &err);
+    if (err) {
+        error_propagate(errp, err);
+        return;
     }
     sysbus_dev = SYS_BUS_DEVICE(&os->nvram);
     memory_region_add_subregion(&s->bar, 0x60000,
@@ -194,13 +198,12 @@  static int macio_oldworld_initfn(PCIDevice *d)
         qemu_irq irq0 = os->irqs[cur_irq++];
         qemu_irq irq1 = os->irqs[cur_irq++];
 
-        ret = macio_initfn_ide(s, &os->ide[i], irq0, irq1, 0x16 + (i * 4));
-        if (ret < 0) {
-            return ret;
+        macio_realize_ide(s, &os->ide[i], irq0, irq1, 0x16 + (i * 4), &err);
+        if (err) {
+            error_propagate(errp, err);
+            return;
         }
     }
-
-    return 0;
 }
 
 static void macio_init_ide(MacIOState *s, MACIOIDEState *ide, size_t ide_size,
@@ -268,17 +271,20 @@  static const MemoryRegionOps timer_ops = {
     .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-static int macio_newworld_initfn(PCIDevice *d)
+static void macio_newworld_realize(PCIDevice *d, Error **errp)
 {
     MacIOState *s = MACIO(d);
     NewWorldMacIOState *ns = NEWWORLD_MACIO(d);
+    Error *err = NULL;
     SysBusDevice *sysbus_dev;
     MemoryRegion *timer_memory = NULL;
     int i;
     int cur_irq = 0;
-    int ret = macio_common_initfn(d);
-    if (ret < 0) {
-        return ret;
+
+    macio_common_realize(d, &err);
+    if (err) {
+        error_propagate(errp, err);
+        return;
     }
 
     sysbus_dev = SYS_BUS_DEVICE(&s->cuda);
@@ -294,9 +300,10 @@  static int macio_newworld_initfn(PCIDevice *d)
         qemu_irq irq0 = ns->irqs[cur_irq++];
         qemu_irq irq1 = ns->irqs[cur_irq++];
 
-        ret = macio_initfn_ide(s, &ns->ide[i], irq0, irq1, 0x16 + (i * 4));
-        if (ret < 0) {
-            return ret;
+        macio_realize_ide(s, &ns->ide[i], irq0, irq1, 0x16 + (i * 4), &err);
+        if (err) {
+            error_propagate(errp, err);
+            return;
         }
     }
 
@@ -305,8 +312,6 @@  static int macio_newworld_initfn(PCIDevice *d)
     memory_region_init_io(timer_memory, OBJECT(s), &timer_ops, NULL, "timer",
                           0x1000);
     memory_region_add_subregion(&s->bar, 0x15000, timer_memory);
-
-    return 0;
 }
 
 static void macio_newworld_init(Object *obj)
@@ -352,7 +357,7 @@  static void macio_oldworld_class_init(ObjectClass *oc, void *data)
     PCIDeviceClass *pdc = PCI_DEVICE_CLASS(oc);
     DeviceClass *dc = DEVICE_CLASS(oc);
 
-    pdc->init = macio_oldworld_initfn;
+    pdc->realize = macio_oldworld_realize;
     pdc->device_id = PCI_DEVICE_ID_APPLE_343S1201;
     dc->vmsd = &vmstate_macio_oldworld;
 }
@@ -372,7 +377,7 @@  static void macio_newworld_class_init(ObjectClass *oc, void *data)
     PCIDeviceClass *pdc = PCI_DEVICE_CLASS(oc);
     DeviceClass *dc = DEVICE_CLASS(oc);
 
-    pdc->init = macio_newworld_initfn;
+    pdc->realize = macio_newworld_realize;
     pdc->device_id = PCI_DEVICE_ID_APPLE_UNI_N_KEYL;
     dc->vmsd = &vmstate_macio_newworld;
 }