search for: config_block

...+------------------ 1 file changed, 96 insertions(+), 81 deletions(-) diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index 1f3e7d56924f..613b18001a0c 100644 --- a/drivers/s390/virtio/virtio_ccw.c +++ b/drivers/s390/virtio/virtio_ccw.c @@ -46,9 +46,15 @@ struct vq_config_block { #define VIRTIO_CCW_CONFIG_SIZE 0x100 /* same as PCI config space size, should be enough for all drivers */ +struct vcdev_dma_area { + unsigned long indicators; + unsigned long indicators2; + struct vq_config_block config_block; + __u8 status; +}; + struct virtio_ccw_device { struct virtio_...

...+------------------ 1 file changed, 96 insertions(+), 81 deletions(-) diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index e96a8cc56ec2..03c9f7001fb1 100644 --- a/drivers/s390/virtio/virtio_ccw.c +++ b/drivers/s390/virtio/virtio_ccw.c @@ -46,9 +46,15 @@ struct vq_config_block { #define VIRTIO_CCW_CONFIG_SIZE 0x100 /* same as PCI config space size, should be enough for all drivers */ +struct vcdev_dma_area { + unsigned long indicators; + unsigned long indicators2; + struct vq_config_block config_block; + __u8 status; +}; + struct virtio_ccw_device { struct virtio_...

...+------------------ 1 file changed, 96 insertions(+), 81 deletions(-) diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index e96a8cc56ec2..03c9f7001fb1 100644 --- a/drivers/s390/virtio/virtio_ccw.c +++ b/drivers/s390/virtio/virtio_ccw.c @@ -46,9 +46,15 @@ struct vq_config_block { #define VIRTIO_CCW_CONFIG_SIZE 0x100 /* same as PCI config space size, should be enough for all drivers */ +struct vcdev_dma_area { + unsigned long indicators; + unsigned long indicators2; + struct vq_config_block config_block; + __u8 status; +}; + struct virtio_ccw_device { struct virtio_...

...++++--------------- 1 file changed, 90 insertions(+), 81 deletions(-) diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index e96a8cc56ec2..e5e10aa54aa1 100644 --- a/drivers/s390/virtio/virtio_ccw.c +++ b/drivers/s390/virtio/virtio_ccw.c @@ -46,9 +46,15 @@ struct vq_config_block { #define VIRTIO_CCW_CONFIG_SIZE 0x100 /* same as PCI config space size, should be enough for all drivers */ +struct vcdev_dma_area { + unsigned long indicators; + unsigned long indicators2; + struct vq_config_block config_block; + __u8 status; +}; + struct virtio_ccw_device { struct virtio_...

...++++--------------- 1 file changed, 89 insertions(+), 80 deletions(-) diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index e96a8cc56ec2..800252955a2f 100644 --- a/drivers/s390/virtio/virtio_ccw.c +++ b/drivers/s390/virtio/virtio_ccw.c @@ -46,9 +46,15 @@ struct vq_config_block { #define VIRTIO_CCW_CONFIG_SIZE 0x100 /* same as PCI config space size, should be enough for all drivers */ +struct vcdev_dma_area { + unsigned long indicators; + unsigned long indicators2; + struct vq_config_block config_block; + __u8 status; +}; + struct virtio_ccw_device { struct virtio_...

In a Rails controller I set the scope on a model class in an around filter. I have defined expectations on the model classes, and ideally, I would add a further expectation for the scope. Is this already possible in some way? How would I go about adding support a scope expectation? Michael -- Michael Schuerig mailto:michael at schuerig.de http://www.schuerig.de/michael/

...30 100644 --- a/drivers/s390/virtio/virtio_ccw.c +++ b/drivers/s390/virtio/virtio_ccw.c @@ -400,12 +400,16 @@ static bool virtio_ccw_kvm_notify(struct virtqueue *vq) static int virtio_ccw_read_vq_conf(struct virtio_ccw_device *vcdev, struct ccw1 *ccw, int index) { + int ret; + vcdev->config_block->index = index; ccw->cmd_code = CCW_CMD_READ_VQ_CONF; ccw->flags = 0; ccw->count = sizeof(struct vq_config_block); ccw->cda = (__u32)(unsigned long)(vcdev->config_block); - ccw_io_helper(vcdev, ccw, VIRTIO_CCW_DOING_READ_VQ_CONF); + ret = ccw_io_helper(vcdev, ccw, VIRTIO_C...

Michael, here's a bugfix for the virtio-ccw driver. Question: How would you like to get patches? This one is formatted against your current linux-next branch; I can prepare a branch for you to pull from as well. Pierre Morel (1): virtio/s390: handle failures of READ_VQ_CONF ccw drivers/s390/virtio/virtio_ccw.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) -- 2.3.8

Michael, here's a bugfix for the virtio-ccw driver. Question: How would you like to get patches? This one is formatted against your current linux-next branch; I can prepare a branch for you to pull from as well. Pierre Morel (1): virtio/s390: handle failures of READ_VQ_CONF ccw drivers/s390/virtio/virtio_ccw.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) -- 2.3.8

...dev, > + DMA_BIT_MASK(32)); > + if (ret) { > + dev_warn(&cdev->dev, "Failed to enable 64-bit or 32-bit DMA. Trying to continue, but this might not work.\n"); This does not look like you'd try to continue? > + goto out_free; > + } > + > vcdev->config_block = kzalloc(sizeof(*vcdev->config_block), > GFP_DMA | GFP_KERNEL); > if (!vcdev->config_block) {

...t_free; > - } This means that vring structures now need to fit into 31 bits as well, I think? Is there any way to reserve the 31 bit restriction for channel subsystem structures and keep vring in the full 64 bit range? (Or am I fundamentally misunderstanding something?) > - > vcdev->config_block = kzalloc(sizeof(*vcdev->config_block), > GFP_DMA | GFP_KERNEL); > if (!vcdev->config_block) {

...t_free; > - } This means that vring structures now need to fit into 31 bits as well, I think? Is there any way to reserve the 31 bit restriction for channel subsystem structures and keep vring in the full 64 bit range? (Or am I fundamentally misunderstanding something?) > - > vcdev->config_block = kzalloc(sizeof(*vcdev->config_block), > GFP_DMA | GFP_KERNEL); > if (!vcdev->config_block) {

...mask = &vcdev->dma_mask; + /* we are fine with common virtio infrastructure using 64 bit DMA */ + ret = dma_set_mask_and_coherent(&cdev->dev, DMA_BIT_MASK(64)); + if (ret) { + dev_warn(&cdev->dev, "Failed to enable 64-bit DMA.\n"); + goto out_free; + } + vcdev->config_block = kzalloc(sizeof(*vcdev->config_block), GFP_DMA | GFP_KERNEL); if (!vcdev->config_block) { @@ -1272,7 +1281,6 @@ static int virtio_ccw_online(struct ccw_device *cdev) vcdev->is_thinint = virtio_ccw_use_airq; /* at least try */ - vcdev->vdev.dev.parent = &cdev->dev...

...s from ;). > > What would you prefer? Try to continue or fail right away? If it does not have a chance of working properly in the general case, I'd fail. > > Regards, > Halil > > > > + goto out_free; > > > + } > > > + > > > vcdev->config_block = kzalloc(sizeof(*vcdev->config_block), > > > GFP_DMA | GFP_KERNEL); > > > if (!vcdev->config_block) { > > >

Hi, I've got a Powerware Prestige 9 1kVA UPS that seems to not be working with nut. It's not in the current "supported hardware" list, but the old bcmxcp page lists it as being a UPS that speaks that protocol. I have the following in my ups.conf [powerware] driver = bcmxcp port = /dev/ttyS0 desc = "Powerware Prestige 9 EXT" baud_rate = 2400 And when I start the

...t was discussed in the RFC thread) is tricky because the ccw device may outlive the subchannel (all that orphan stuff). So the answer is: it is technically possible (e.g. see RFC) but it comes at a price, and I see no obviously brilliant solution. Regards, Halil > > - > > vcdev->config_block = kzalloc(sizeof(*vcdev->config_block), > > GFP_DMA | GFP_KERNEL); > > if (!vcdev->config_block) { >

Enhanced virtualization protection technology may require the use of bounce buffers for I/O. While support for this was built into the virtio core, virtio-ccw wasn't changed accordingly. Some background on technology (not part of this series) and the terminology used. * Protected Virtualization (PV): Protected Virtualization guarantees, that non-shared memory of a guest that operates in PV

Enhanced virtualization protection technology may require the use of bounce buffers for I/O. While support for this was built into the virtio core, virtio-ccw wasn't changed accordingly. Some background on technology (not part of this series) and the terminology used. * Protected Virtualization (PV): Protected Virtualization guarantees, that non-shared memory of a guest that operates in PV

Enhanced virtualization protection technology may require the use of bounce buffers for I/O. While support for this was built into the virtio core, virtio-ccw wasn't changed accordingly. Some background on technology (not part of this series) and the terminology used. * Protected Virtualization (PV): Protected Virtualization guarantees, that non-shared memory of a guest that operates in PV

Enhanced virtualization protection technology may require the use of bounce buffers for I/O. While support for this was built into the virtio core, virtio-ccw wasn't changed accordingly. Some background on technology (not part of this series) and the terminology used. * Protected Virtualization (PV): Protected Virtualization guarantees, that non-shared memory of a guest that operates in PV