linux.git/drivers/char/virtio_console.c, branch v4.0

virtio_console: avoid config access from irq

2015-03-05T03:06:18+00:00

when multiport is off, virtio console invokes config access from irq
context, config access is blocking on s390.
Fix this up by scheduling work from config irq - similar to what we do
for multiport configs.

Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Amit Shah 
Signed-off-by: Rusty Russell 
Cc: stable@kernel.org

virtio_console: init work unconditionally

2015-03-05T03:06:17+00:00

when multiport is off, we don't initialize config work,
but we then cancel uninitialized control_work on freeze.

Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Amit Shah 
Signed-off-by: Rusty Russell 
Cc: stable@kernel.org

virtio: don't require a config space on the console device.

2015-02-11T04:33:17+00:00

Strictly, it's only needed when we have features (size or multiport).

Signed-off-by: Rusty Russell

virtio/console: verify device has config space

2015-01-21T05:58:46+00:00

Some devices might not implement config space access
(e.g. remoteproc used not to - before 3.9).
virtio/console needs config space access so make it
fail gracefully if not there.

Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Rusty Russell

virtio_console: fix sparse warnings

2014-12-09T10:06:33+00:00

CHECK drivers/char/virtio_console.c
drivers/char/virtio_console.c:687:36: warning: incorrect type in
	argument 1 (different address spaces)
drivers/char/virtio_console.c:687:36:    expected void [noderef]
	*to
drivers/char/virtio_console.c:687:36:    got char *out_buf
drivers/char/virtio_console.c:790:35: warning: incorrect type in
	argument 2 (different address spaces)
drivers/char/virtio_console.c:790:35:    expected char *out_buf
drivers/char/virtio_console.c:790:35:    got char [noderef]
	*ubuf

fill_readbuf is reused with both kernel and userspace pointers,
depending on value of to_user flag.

Tag address parameter as __user, and cast to/from regular pointer type
when we know it's safe.

Signed-off-by: Michael S. Tsirkin

virtio: drop VIRTIO_F_VERSION_1 from drivers

2014-12-09T10:06:32+00:00

Core activates this bit automatically now,
drop it from drivers that set it explicitly.

Signed-off-by: Michael S. Tsirkin

virtio_console: virtio 1.0 support

2014-12-09T10:06:32+00:00

Pretty straight-forward, just use accessors for all fields.

Signed-off-by: Michael S. Tsirkin

virtio: use u32, not bitmap for features

2014-12-09T10:05:23+00:00

It seemed like a good idea to use bitmap for features
in struct virtio_device, but it's actually a pain,
and seems to become even more painful when we get more
than 32 feature bits.  Just change it to a u32 for now.

Based on patch by Rusty.

Suggested-by: David Hildenbrand 
Signed-off-by: Rusty Russell 
Signed-off-by: Cornelia Huck 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Cornelia Huck

virtio_console: move early VQ enablement

2014-11-13T07:53:26+00:00

Commit f5866db6 (virtio_console: enable VQs early) tried to make
sure that DRIVER_OK was set when virtio_console started using its
virtqueues. Doing this in add_port(), however, means that we try
to set DRIVER_OK again when when a port is dynamically added after
the probe function is done.

Let's move virtio_device_ready() to the probe function just before
trying to use the virtqueues instead. This is fine as nothing can
fail inbetween.

Reported-by: Thomas Graf 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Cornelia Huck 

Signed-off-by: Michael S. Tsirkin

virtio_console: enable VQs early on restore

2014-10-14T23:55:09+00:00

virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after resume returns, virtio console violated this
rule by adding inbufs, which causes the VQ to be used directly within
restore.

To fix, call virtio_device_ready before using VQs.

Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Rusty Russell