search for: device_initialize

On Wed, 20 Dec 2017 12:26:25 +0800 weiping zhang <zwp10758 at gmail.com> wrote: [you used a different mail address in your From: than in your s-o-b:; same for the other patches] > In order to make caller do a simple cleanup, we split device_register > into device_initialize and device_add. device_initialize always sucess, s/success/succeeds/ > the caller can always use put_device when fail to register virtio_device "so the caller can always use put_device when register_virtio_device failed," > no matter fail at ida_simple_get or at device_add. &qu...

On Wed, 20 Dec 2017 12:26:25 +0800 weiping zhang <zwp10758 at gmail.com> wrote: [you used a different mail address in your From: than in your s-o-b:; same for the other patches] > In order to make caller do a simple cleanup, we split device_register > into device_initialize and device_add. device_initialize always sucess, s/success/succeeds/ > the caller can always use put_device when fail to register virtio_device "so the caller can always use put_device when register_virtio_device failed," > no matter fail at ida_simple_get or at device_add. &qu...

In order to make caller do a simple cleanup, we split device_register into device_initialize and device_add. device_initialize always succeeds, so the caller can always use put_device when register_virtio_device faild. Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> Suggested-by: Cornelia Huck <cohuck at redhat.com> --- drivers/virtio/virtio.c | 18 ++++++++++++...

In order to make caller do a simple cleanup, we split device_register into device_initialize and device_add. device_initialize always sucess, the caller can always use put_device when fail to register virtio_device no matter fail at ida_simple_get or at device_add. Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> Suggested-by: Cornelia Huck <cohuck at redhat.com>...

...Wed, 20 Dec 2017 12:26:25 +0800 > weiping zhang <zwp10758 at gmail.com> wrote: > > [you used a different mail address in your From: than in your s-o-b:; > same for the other patches] > >> In order to make caller do a simple cleanup, we split device_register >> into device_initialize and device_add. device_initialize always sucess, > > s/success/succeeds/ > >> the caller can always use put_device when fail to register virtio_device > > "so the caller can always use put_device when register_virtio_device > failed," > >> no matter fail a...

Hi, The main change is split device_register into 2 sperate calls: device_initalize() and device_add, and then the caller can use put_device safety when fail to register_virtio_device. v3->v4: * split device_register into device_initialize and devicea_add that the caller can always use put_device when fail to register virtio device. v2->v3: * virtio: add new helper do get device's status then determine use put_device or kfree. v1->v2: * virtio_pci: add comments in commit message for why using put_device * virt...

Hi, The main change is split device_register into 2 sperate calls: device_initalize() and device_add, and then the caller can use put_device safety when fail to register_virtio_device. v3->v4: * split device_register into device_initialize and devicea_add that the caller can always use put_device when fail to register virtio device. v2->v3: * virtio: add new helper do get device's status then determine use put_device or kfree. v1->v2: * virtio_pci: add comments in commit message for why using put_device * virt...

...iver core interaction; but we cannot do a put_device() either, since the refcount may not yet have been initialized -- unless we check the device status, which triggers I/O (at least on s390). We really want to do the same cleanup on error in every case. What about splitting device_register() into device_initialize() and device_add()? If we move device_initialize() before getting an index, we should be fine with doing put_device() on error in every case. > > Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> > --- > drivers/virtio/virtio.c | 13 +++++++++++++ > 1 file chang...

...iver core interaction; but we cannot do a put_device() either, since the refcount may not yet have been initialized -- unless we check the device status, which triggers I/O (at least on s390). We really want to do the same cleanup on error in every case. What about splitting device_register() into device_initialize() and device_add()? If we move device_initialize() before getting an index, we should be fine with doing put_device() on error in every case. > > Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> > --- > drivers/virtio/virtio.c | 13 +++++++++++++ > 1 file chang...

...> Normal we do cleanup for @vm_dev by contianer_of(@dev), but in this case > we need release @mem resource from @pdev and vm_dev->base. It make > @pdev->vm_dev.dev.release() too complicated, so put_device just put the > reference of register_virtio_device->device_register->device_initialize > and release all resource in virtio_mmio_probe. Releasing the resources when unwinding on error can work, but I think there still are some issues (more below). This is all very tangly code :( > > Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> > --- > driver...

...> Normal we do cleanup for @vm_dev by contianer_of(@dev), but in this case > we need release @mem resource from @pdev and vm_dev->base. It make > @pdev->vm_dev.dev.release() too complicated, so put_device just put the > reference of register_virtio_device->device_register->device_initialize > and release all resource in virtio_mmio_probe. Releasing the resources when unwinding on error can work, but I think there still are some issues (more below). This is all very tangly code :( > > Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> > --- > driver...

...Mueller <mimu at linux.ibm.com> wrote: > >> @@ -224,6 +226,8 @@ struct subchannel *css_alloc_subchannel(struct subchannel_id schid, > >> INIT_WORK(&sch->todo_work, css_sch_todo); > >> sch->dev.release = &css_subchannel_release; > >> device_initialize(&sch->dev); > > > > It might be helpful to add a comment why you use 31 bit here... > > @Halil, please let me know what comment you prefere here... > How about? /* * The physical addresses of some the dma structures that * can belong to a subchannel need to f...

...Mueller <mimu at linux.ibm.com> wrote: > >> @@ -224,6 +226,8 @@ struct subchannel *css_alloc_subchannel(struct subchannel_id schid, > >> INIT_WORK(&sch->todo_work, css_sch_todo); > >> sch->dev.release = &css_subchannel_release; > >> device_initialize(&sch->dev); > > > > It might be helpful to add a comment why you use 31 bit here... > > @Halil, please let me know what comment you prefere here... > How about? /* * The physical addresses of some the dma structures that * can belong to a subchannel need to f...

this patchset try to add cleanup for virtio_mmio driver, include virtio_mmio_probe and virtio_mmio_remove weiping zhang (2): virtio_mmio: add cleanup for virtio_mmio_probe virtio_mmio: add cleanup for virtio_mmio_remove drivers/virtio/virtio_mmio.c | 43 +++++++++++++++++++++++++++++++++++-------- 1 file changed, 35 insertions(+), 8 deletions(-) -- 2.9.4

this patchset try to add cleanup for virtio_mmio driver, include virtio_mmio_probe and virtio_mmio_remove weiping zhang (2): virtio_mmio: add cleanup for virtio_mmio_probe virtio_mmio: add cleanup for virtio_mmio_remove drivers/virtio/virtio_mmio.c | 43 +++++++++++++++++++++++++++++++++++-------- 1 file changed, 35 insertions(+), 8 deletions(-) -- 2.9.4

On Wed, Nov 29, 2017 at 10:50:44AM +0100, Cornelia Huck wrote: > On Wed, 29 Nov 2017 09:23:01 +0800 > weiping zhang <zwp10758 at gmail.com> wrote: > > > index can be reused by other virtio device. > > > > Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> > > Reviewed-by: Cornelia Huck <cohuck at redhat.com> > > > --- >

On Wed, Nov 29, 2017 at 10:50:44AM +0100, Cornelia Huck wrote: > On Wed, 29 Nov 2017 09:23:01 +0800 > weiping zhang <zwp10758 at gmail.com> wrote: > > > index can be reused by other virtio device. > > > > Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> > > Reviewed-by: Cornelia Huck <cohuck at redhat.com> > > > --- >

...ster into 2 sperate calls: device_initalize() and device_add, and then the caller can use put_device safety when fail to register_virtio_device. v4->v5: * virtio: correct some comments * virtio_remoteproc: use put_device directly, not use temp reg_dev v3->v4: * split device_register into device_initialize and devicea_add that the caller can always use put_device when fail to register virtio device. v2->v3: * virtio: add new helper do get device's status then determine use put_device or kfree. v1->v2: * virtio_pci: add comments in commit message for why using put_device * virt...

...; + if (!vdev) > + goto err; > + > + err = ida_simple_get(&vdpa_index_ida, 0, 0, GFP_KERNEL); > + if (err < 0) > + goto err_ida; > + > + vdev->dev.bus = &vdpa_bus; > + vdev->dev.parent = parent; > + vdev->dev.release = vdpa_release_dev; > + > + device_initialize(&vdev->dev); > + > + vdev->index = err; > + vdev->dma_dev = dma_dev; > + vdev->config = config; > + > + dev_set_name(&vdev->dev, "vdpa%u", vdev->index); Probably shouldn't ignore the error for dev_set_name ? err = dev_set_name() if (err) {...

Hi experts I use xen-4.0.0 and dom0 is 2.6.33 and domU is 2.6.34 #lspci ............... 01:00.0 Ethernet controller: Intel Corporation Unknown device 10a7 (rev 02) 01:00.1 Ethernet controller: Intel Corporation Unknown device 10a7 (rev 02) 05:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 05:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit