search for: device_release

The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <jg1.han at samsung.com> --- drivers/virtio/virtio_pci.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c...

The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <jg1.han at samsung.com> --- drivers/virtio/virtio_pci.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c...

...ang wrote: > > The ida_simple_remove should probably be part of the class release > > function to make everything work right > > It looks to me bus instead of class is the correct abstraction here since > the devices share a set of programming interface but not the semantics. device_release() doesn't call the bus release? You have dev, type or class to choose from. Type is rarely used and doesn't seem to be used by vdpa, so class seems the right choice Jason

...ang wrote: > > The ida_simple_remove should probably be part of the class release > > function to make everything work right > > It looks to me bus instead of class is the correct abstraction here since > the devices share a set of programming interface but not the semantics. device_release() doesn't call the bus release? You have dev, type or class to choose from. Type is rarely used and doesn't seem to be used by vdpa, so class seems the right choice Jason

...45] [<ffffffff8139f8a2>] kobject_cleanup+0x82/0x1c0 [ 165.633045] [<ffffffff8139f730>] kobject_put+0x30/0x70 [ 165.633045] [<ffffffff81369495>] blk_put_queue+0x15/0x20 [ 165.633045] [<ffffffff8137e033>] disk_release+0x93/0xd0 [ 165.633045] [<ffffffff814d27de>] device_release+0x3e/0xc0 [ 165.633045] [<ffffffff8139f8a2>] kobject_cleanup+0x82/0x1c0 [ 165.633045] [<ffffffff8139f730>] kobject_put+0x30/0x70 [ 165.633045] [<ffffffff8137c797>] put_disk+0x17/0x20 [ 165.633045] [<ffffffff812278a5>] __blkdev_put+0x125/0x1b0 [ 165.633045] [<fff...

...45] [<ffffffff8139f8a2>] kobject_cleanup+0x82/0x1c0 [ 165.633045] [<ffffffff8139f730>] kobject_put+0x30/0x70 [ 165.633045] [<ffffffff81369495>] blk_put_queue+0x15/0x20 [ 165.633045] [<ffffffff8137e033>] disk_release+0x93/0xd0 [ 165.633045] [<ffffffff814d27de>] device_release+0x3e/0xc0 [ 165.633045] [<ffffffff8139f8a2>] kobject_cleanup+0x82/0x1c0 [ 165.633045] [<ffffffff8139f730>] kobject_put+0x30/0x70 [ 165.633045] [<ffffffff8137c797>] put_disk+0x17/0x20 [ 165.633045] [<ffffffff812278a5>] __blkdev_put+0x125/0x1b0 [ 165.633045] [<fff...

...gt;>> The ida_simple_remove should probably be part of the class release >>> function to make everything work right >> It looks to me bus instead of class is the correct abstraction here since >> the devices share a set of programming interface but not the semantics. > device_release() doesn't call the bus release? What it did is: ??????? if (dev->release) ??????????????? dev->release(dev); ??????? else if (dev->type && dev->type->release) ??????????????? dev->type->release(dev); ??????? else if (dev->class && dev->class-&g...

...39f8a2>] kobject_cleanup+0x82/0x1c0 > [ 165.633045] [<ffffffff8139f730>] kobject_put+0x30/0x70 > [ 165.633045] [<ffffffff81369495>] blk_put_queue+0x15/0x20 > [ 165.633045] [<ffffffff8137e033>] disk_release+0x93/0xd0 > [ 165.633045] [<ffffffff814d27de>] device_release+0x3e/0xc0 > [ 165.633045] [<ffffffff8139f8a2>] kobject_cleanup+0x82/0x1c0 > [ 165.633045] [<ffffffff8139f730>] kobject_put+0x30/0x70 > [ 165.633045] [<ffffffff8137c797>] put_disk+0x17/0x20 > [ 165.633045] [<ffffffff812278a5>] __blkdev_put+0x125/0x1b0 >...

...39f8a2>] kobject_cleanup+0x82/0x1c0 > [ 165.633045] [<ffffffff8139f730>] kobject_put+0x30/0x70 > [ 165.633045] [<ffffffff81369495>] blk_put_queue+0x15/0x20 > [ 165.633045] [<ffffffff8137e033>] disk_release+0x93/0xd0 > [ 165.633045] [<ffffffff814d27de>] device_release+0x3e/0xc0 > [ 165.633045] [<ffffffff8139f8a2>] kobject_cleanup+0x82/0x1c0 > [ 165.633045] [<ffffffff8139f730>] kobject_put+0x30/0x70 > [ 165.633045] [<ffffffff8137c797>] put_disk+0x17/0x20 > [ 165.633045] [<ffffffff812278a5>] __blkdev_put+0x125/0x1b0 >...

On Mon, Feb 10, 2020 at 11:56:06AM +0800, Jason Wang wrote: > +/** > + * vdpa_register_device - register a vDPA device > + * Callers must have a succeed call of vdpa_init_device() before. > + * @vdev: the vdpa device to be registered to vDPA bus > + * > + * Returns an error when fail to add to vDPA bus > + */ > +int vdpa_register_device(struct vdpa_device *vdev) > +{

On Mon, Feb 10, 2020 at 11:56:06AM +0800, Jason Wang wrote: > +/** > + * vdpa_register_device - register a vDPA device > + * Callers must have a succeed call of vdpa_init_device() before. > + * @vdev: the vdpa device to be registered to vDPA bus > + * > + * Returns an error when fail to add to vDPA bus > + */ > +int vdpa_register_device(struct vdpa_device *vdev) > +{

...mode_config_cleanup+0x1fa/0x260 [..] Call Trace: nouveau_display_destroy+0x41/0x80 [nouveau] nouveau_drm_unload+0x6b/0xd0 [nouveau] drm_dev_unregister+0x3c/0xe0 drm_put_dev+0x2e/0x60 nouveau_drm_device_remove+0x37/0x50 [nouveau] pci_device_remove+0x36/0xb0 device_release_driver_internal+0x160/0x230 driver_detach+0x3a/0x70 bus_remove_driver+0x58/0xd0 pci_unregister_driver+0x3b/0x90 nouveau_drm_exit+0x15/0x432 [nouveau] SyS_delete_module+0x16c/0x230 Issue 8 - acpi: sleeping function in atomic context. (Issue is likely not related to this pat...

...c/0x270 [ 468.048180] do_init_module+0xf4/0x329 [ 468.051019] INFO: Freed in virtio_pci_release_dev+0x12/0x20 [virtio_pci] age=0 cpu=0 pid=12507 [ 468.054736] __slab_free+0x175/0x280 [ 468.057449] kfree+0x1a6/0x1c0 [ 468.060003] virtio_pci_release_dev+0x12/0x20 [virtio_pci] [ 468.062743] device_release+0x4a/0xf0 [ 468.064653] kobject_release+0xad/0x200 [ 468.066405] kobject_put+0x30/0x60 [ 468.068327] device_unregister+0x2c/0x70 [ 468.071058] unregister_virtio_device+0x20/0x40 [virtio] [ 468.074097] virtio_pci_remove+0x2b/0x70 [virtio_pci] [ 468.076138] pci_device_remove+0x61/0x100 [...

...c/0x270 [ 468.048180] do_init_module+0xf4/0x329 [ 468.051019] INFO: Freed in virtio_pci_release_dev+0x12/0x20 [virtio_pci] age=0 cpu=0 pid=12507 [ 468.054736] __slab_free+0x175/0x280 [ 468.057449] kfree+0x1a6/0x1c0 [ 468.060003] virtio_pci_release_dev+0x12/0x20 [virtio_pci] [ 468.062743] device_release+0x4a/0xf0 [ 468.064653] kobject_release+0xad/0x200 [ 468.066405] kobject_put+0x30/0x60 [ 468.068327] device_unregister+0x2c/0x70 [ 468.071058] unregister_virtio_device+0x20/0x40 [virtio] [ 468.074097] virtio_pci_remove+0x2b/0x70 [virtio_pci] [ 468.076138] pci_device_remove+0x61/0x100 [...

...o_init_module+0xf4/0x329 > [ 468.051019] INFO: Freed in virtio_pci_release_dev+0x12/0x20 [virtio_pci] age=0 cpu=0 pid=12507 > [ 468.054736] __slab_free+0x175/0x280 > [ 468.057449] kfree+0x1a6/0x1c0 > [ 468.060003] virtio_pci_release_dev+0x12/0x20 [virtio_pci] > [ 468.062743] device_release+0x4a/0xf0 > [ 468.064653] kobject_release+0xad/0x200 > [ 468.066405] kobject_put+0x30/0x60 > [ 468.068327] device_unregister+0x2c/0x70 > [ 468.071058] unregister_virtio_device+0x20/0x40 [virtio] > [ 468.074097] virtio_pci_remove+0x2b/0x70 [virtio_pci] > [ 468.076138] p...

Modernize vga_switcheroo by using a device link to enforce a runtime PM dependency from an HDA controller to the GPU it's integrated into, v2. Changes since v1: - Replace patch [1/7] to use pci_save_state() / pci_restore_state() for consistency between runtime PM code path of bound and unbound devices. (Rafael, Bjorn) - Patch [5/7]: Drop an unnecessary initialization. (Bjorn) Rephrase