[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <17ca0940-e6eb-f810-b51b-b4d008b7b471@linux.vnet.ibm.com>
Date: Mon, 16 Oct 2017 12:09:07 -0400
From: Tony Krowiak <akrowiak@...ux.vnet.ibm.com>
To: Martin Schwidefsky <schwidefsky@...ibm.com>
Cc: linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, freude@...ibm.com, heiko.carstens@...ibm.com,
borntraeger@...ibm.com, cohuck@...hat.com, kwankhede@...dia.com,
bjsdjshi@...ux.vnet.ibm.com, pbonzini@...hat.com,
alex.williamson@...hat.com, pmorel@...ux.vnet.ibm.com,
alifm@...ux.vnet.ibm.com, mjrosato@...ux.vnet.ibm.com,
qemu-s390x@...gnu.org, jjherne@...ux.vnet.ibm.com,
thuth@...hat.com, pasic@...ux.vnet.ibm.com
Subject: Re: [RFC 06/19] s390/zcrypt: register matrix device with VFIO
mediated device framework
On 10/16/2017 05:03 AM, Martin Schwidefsky wrote:
> On Fri, 13 Oct 2017 13:38:51 -0400
> Tony Krowiak <akrowiak@...ux.vnet.ibm.com> wrote:
>
>> diff --git a/drivers/s390/crypto/ap_matrix_bus.c b/drivers/s390/crypto/ap_matrix_bus.c
>> index 66bfa54..418c23b 100644
>> --- a/drivers/s390/crypto/ap_matrix_bus.c
>> +++ b/drivers/s390/crypto/ap_matrix_bus.c
>> @@ -61,6 +61,7 @@ static int ap_matrix_dev_create(void)
>> matrix->device.bus = &ap_matrix_bus_type;
>> matrix->device.parent = ap_matrix_root_device;
>> matrix->device.release = ap_matrix_dev_release;
>> + INIT_LIST_HEAD(&matrix->queues);
>>
>> ret = device_register(&matrix->device);
>> if (ret) {
>> diff --git a/drivers/s390/crypto/ap_matrix_bus.h b/drivers/s390/crypto/ap_matrix_bus.h
>> index c2aff23..3eccc36 100644
>> --- a/drivers/s390/crypto/ap_matrix_bus.h
>> +++ b/drivers/s390/crypto/ap_matrix_bus.h
>> @@ -12,8 +12,12 @@
>>
>> #include <linux/device.h>
>>
>> +#include "ap_bus.h"
>> +
>> struct ap_matrix {
>> struct device device;
>> + spinlock_t qlock;
>> + struct list_head queues;
>> };
>>
>> struct ap_matrix *ap_matrix_get_device(void);
> Move these two hunks into patch #5 please. Yes, strictly speaking the two elements
> in the struct ap_matrix are needed only with patch #6, but it is fine to introduce
> an element with a new driver that is only exploited with a later patch.
Will do.
>
Powered by blists - more mailing lists