search for: driver_data

To avoid direct access to the driver_data pointer in struct device, the functions dev_get_drvdata() and dev_set_drvdata() should be used. Signed-off-by: Roel Kluin <roel.kluin at gmail.com> --- diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8f90508..ff09809 100644 --- a/drivers/block/xen-blkfront.c ++...

To avoid direct access to the driver_data pointer in struct device, the functions dev_get_drvdata() and dev_set_drvdata() should be used. Signed-off-by: Roel Kluin <roel.kluin at gmail.com> --- diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8f90508..ff09809 100644 --- a/drivers/block/xen-blkfront.c ++...

To avoid direct access to the driver_data pointer in struct device, the functions dev_get_drvdata() and dev_set_drvdata() should be used. Signed-off-by: Roel Kluin <roel.kluin at gmail.com> --- diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8f90508..ff09809 100644 --- a/drivers/block/xen-blkfront.c ++...

In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at lists.xensource.com Cc: virtualization at lists.osdl.org Ac...

From: Greg Kroah-Hartman <gregkh at suse.de> In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at lists.xensource.com Cc: virtualization at lists.osdl.org Cc...

In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at lists.xensource.com Cc: virtualization at lists.osdl.org Ac...

In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at lists.xensource.com Cc: virtualization at lists.osdl.org Ac...

From: Greg Kroah-Hartman <gregkh at suse.de> In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at lists.xensource.com Cc: virtualization at lists.osdl.org Cc...

From: Greg Kroah-Hartman <gregkh at suse.de> In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at lists.xensource.com Cc: virtualization at lists.osdl.org Cc...

...nsole.c +++ b/drivers/tty/hvc/hvc_console.c @@ -766,12 +766,10 @@ int hvc_poll_init(struct tty_driver *driver, int line, char *options) static int hvc_poll_get_char(struct tty_driver *driver, int line) { - struct tty_struct *tty = driver->ttys[0]; - struct hvc_struct *hp = tty->driver_data; int n; char ch; - n = hp->ops->get_chars(hp->vtermno, &ch, 1); + n = cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1); if (n == 0) return NO_POLL_CHAR; @@ -781,12 +779,10 @@ static int hvc_poll_get_char(struct tty_d...

.. snip.. >> Both of them (acpi-cpufreq.c and powernow-k8.c) have a symbol >> dependency on drivers/acpi/processor.c > > But them being ''m'' or ''y'' shouldn''t matter in the end. I thought you were saying it matters - as it should be done around the same time as cpufreq drivers were loaded? .. snip.. >> For a), this would mean some

This patch should fix the bug reported in https://lkml.org/lkml/2014/9/11/249. Test is still pending. David Hildenbrand (1): blk-mq: Avoid race condition with uninitialized requests block/blk-mq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 1.8.5.5

This patch should fix the bug reported in https://lkml.org/lkml/2014/9/11/249. Test is still pending. David Hildenbrand (1): blk-mq: Avoid race condition with uninitialized requests block/blk-mq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 1.8.5.5

This is a subject that came up in the virtio BOF session at OLS. I decided to go forward and implement something that I like, based on the latest virtio proposal at the time, which was draft III. It's not a drop-in replacement, because it's missing a host implementation. I first started my own, which is not done yet, but wanted to do one for lguest and one for emulated PCI next. It's

This is a subject that came up in the virtio BOF session at OLS. I decided to go forward and implement something that I like, based on the latest virtio proposal at the time, which was draft III. It's not a drop-in replacement, because it's missing a host implementation. I first started my own, which is not done yet, but wanted to do one for lguest and one for emulated PCI next. It's

...), 1 deletion(-) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 4bc083b..bed6035 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -691,7 +691,8 @@ static int virtblk_map_queues(struct blk_mq_tag_set *set) { struct virtio_blk *vblk = set->driver_data; - return blk_mq_virtio_map_queues(&set->map[0], vblk->vdev, 0); + return blk_mq_virtio_map_queues(&set->map[HCTX_TYPE_DEFAULT], + vblk->vdev, 0); } #ifdef CONFIG_VIRTIO_BLK_SCSI -- 2.7.4

Has anyone else encountered a loop and failure to shutdown on CentOS4? This has occurred twice in the past month, but unfortunately I failed to write down the looping messages. The only relevant problems I found via Google reference raid controllers, and I have POI (plain ol' IDE). Doh! Obviously I wuill need to record the errors. My environment is run-level 5 with GDM, but I use IceWm

...(&qdev->ddev); + /* unbind vgacon to make sure it doesn't touch our vga registers */ + console_lock(); + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, true); + console_unlock(); + /* Complete initialization. */ ret = drm_dev_register(&qdev->ddev, ent->driver_data); if (ret) -- 2.9.3

...(&qdev->ddev); + /* unbind vgacon to make sure it doesn't touch our vga registers */ + console_lock(); + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, true); + console_unlock(); + /* Complete initialization. */ ret = drm_dev_register(&qdev->ddev, ent->driver_data); if (ret) -- 2.9.3

On 2020/6/8 ??5:54, Michael S. Tsirkin wrote: > On Mon, Jun 08, 2020 at 05:46:52PM +0800, Jason Wang wrote: >> On 2020/6/8 ??5:45, Michael S. Tsirkin wrote: >>> On Mon, Jun 08, 2020 at 05:43:58PM +0800, Jason Wang wrote: >>>>>> Looking at >>>>>> pci_match_one_device() it checks both subvendor and subdevice there. >>>>>>