linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v3 0/1] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem
@ 2019-02-21 14:14 Pierre Morel
  2019-02-21 14:14 ` [PATCH v3 1/1] " Pierre Morel
  0 siblings, 1 reply; 6+ messages in thread
From: Pierre Morel @ 2019-02-21 14:14 UTC (permalink / raw)
  To: borntraeger
  Cc: cohuck, linux-kernel, linux-s390, frankja, akrowiak, pasic,
	david, schwidefsky, heiko.carstens, freude

The goal of this patch is to standardize the device-driver interface
for the VFIO_AP ap_matrix_device to satisfy user-land tools working on
hot-plug (UDEV/LIBVIRT).

Christian Borntraeger reported libvirt looping when a matrix device
was available before the libvirt start.

Marc Hartmayer debugged this and circumvented this in libvirt:
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html


Pierre Morel (1):
  s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem

 drivers/s390/crypto/vfio_ap_drv.c     | 44 ++++++++++++++++++++++++++++-------
 drivers/s390/crypto/vfio_ap_ops.c     |  4 ++--
 drivers/s390/crypto/vfio_ap_private.h |  1 +
 3 files changed, 38 insertions(+), 11 deletions(-)

-- 
2.7.4


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH v3 1/1] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem
  2019-02-21 14:14 [PATCH v3 0/1] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem Pierre Morel
@ 2019-02-21 14:14 ` Pierre Morel
  2019-02-21 15:09   ` Cornelia Huck
                     ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Pierre Morel @ 2019-02-21 14:14 UTC (permalink / raw)
  To: borntraeger
  Cc: cohuck, linux-kernel, linux-s390, frankja, akrowiak, pasic,
	david, schwidefsky, heiko.carstens, freude

Libudev relies on having a subsystem link for non-root devices. To
avoid libudev (and potentially other userspace tools) choking on the
matrix device let us introduce a matrix bus and with it the matrix
bus subsytem. Also make the matrix device reside within the matrix
bus.

Doing this we remove the forced link from the matrix device to the
vfio_ap driver and the device_type we do not need anymore.

Since the associated matrix driver is not the vfio_ap driver any more,
we have to change the search for the devices on the vfio_ap driver in
the function vfio_ap_verify_queue_reserved.

Fixes: 1fde573413b5 ("s390: vfio-ap: base implementation of VFIO AP device driver")

Cc: stable@vger.kernel.org

Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Halil Pasic <pasic@linux.ibm.com>
---
 drivers/s390/crypto/vfio_ap_drv.c     | 44 ++++++++++++++++++++++++++++-------
 drivers/s390/crypto/vfio_ap_ops.c     |  4 ++--
 drivers/s390/crypto/vfio_ap_private.h |  1 +
 3 files changed, 38 insertions(+), 11 deletions(-)

diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
index 31c6c84..e9824c3 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -15,7 +15,6 @@
 #include "vfio_ap_private.h"
 
 #define VFIO_AP_ROOT_NAME "vfio_ap"
-#define VFIO_AP_DEV_TYPE_NAME "ap_matrix"
 #define VFIO_AP_DEV_NAME "matrix"
 
 MODULE_AUTHOR("IBM Corporation");
@@ -24,10 +23,6 @@ MODULE_LICENSE("GPL v2");
 
 static struct ap_driver vfio_ap_drv;
 
-static struct device_type vfio_ap_dev_type = {
-	.name = VFIO_AP_DEV_TYPE_NAME,
-};
-
 struct ap_matrix_dev *matrix_dev;
 
 /* Only type 10 adapters (CEX4 and later) are supported
@@ -62,6 +57,22 @@ static void vfio_ap_matrix_dev_release(struct device *dev)
 	kfree(matrix_dev);
 }
 
+static int matrix_bus_match(struct device *dev, struct device_driver *drv)
+{
+	return 1;
+}
+
+static struct bus_type matrix_bus = {
+	.name = "matrix",
+	.match = &matrix_bus_match,
+};
+
+static struct device_driver matrix_driver = {
+	.name = "vfio_ap",
+	.bus = &matrix_bus,
+	.suppress_bind_attrs = true,
+};
+
 static int vfio_ap_matrix_dev_create(void)
 {
 	int ret;
@@ -71,6 +82,10 @@ static int vfio_ap_matrix_dev_create(void)
 	if (IS_ERR(root_device))
 		return PTR_ERR(root_device);
 
+	ret = bus_register(&matrix_bus);
+	if (ret)
+		goto bus_register_err;
+
 	matrix_dev = kzalloc(sizeof(*matrix_dev), GFP_KERNEL);
 	if (!matrix_dev) {
 		ret = -ENOMEM;
@@ -87,30 +102,41 @@ static int vfio_ap_matrix_dev_create(void)
 	mutex_init(&matrix_dev->lock);
 	INIT_LIST_HEAD(&matrix_dev->mdev_list);
 
-	matrix_dev->device.type = &vfio_ap_dev_type;
 	dev_set_name(&matrix_dev->device, "%s", VFIO_AP_DEV_NAME);
 	matrix_dev->device.parent = root_device;
+	matrix_dev->device.bus = &matrix_bus;
 	matrix_dev->device.release = vfio_ap_matrix_dev_release;
-	matrix_dev->device.driver = &vfio_ap_drv.driver;
+	matrix_dev->vfio_ap_drv = &vfio_ap_drv;
 
 	ret = device_register(&matrix_dev->device);
 	if (ret)
 		goto matrix_reg_err;
 
+	ret = driver_register(&matrix_driver);
+	if (ret)
+		goto matrix_drv_err;
+
 	return 0;
 
+matrix_drv_err:
+	device_unregister(&matrix_dev->device);
 matrix_reg_err:
 	put_device(&matrix_dev->device);
 matrix_alloc_err:
+	bus_unregister(&matrix_bus);
+bus_register_err:
 	root_device_unregister(root_device);
-
 	return ret;
 }
 
 static void vfio_ap_matrix_dev_destroy(void)
 {
+	struct device *root_device = matrix_dev->device.parent;
+
+	driver_unregister(&matrix_driver);
 	device_unregister(&matrix_dev->device);
-	root_device_unregister(matrix_dev->device.parent);
+	bus_unregister(&matrix_bus);
+	root_device_unregister(root_device);
 }
 
 static int __init vfio_ap_init(void)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index 272ef42..900b9cf 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -198,8 +198,8 @@ static int vfio_ap_verify_queue_reserved(unsigned long *apid,
 	qres.apqi = apqi;
 	qres.reserved = false;
 
-	ret = driver_for_each_device(matrix_dev->device.driver, NULL, &qres,
-				     vfio_ap_has_queue);
+	ret = driver_for_each_device(&matrix_dev->vfio_ap_drv->driver, NULL,
+				     &qres, vfio_ap_has_queue);
 	if (ret)
 		return ret;
 
diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h
index 5675492..76b7f98 100644
--- a/drivers/s390/crypto/vfio_ap_private.h
+++ b/drivers/s390/crypto/vfio_ap_private.h
@@ -40,6 +40,7 @@ struct ap_matrix_dev {
 	struct ap_config_info info;
 	struct list_head mdev_list;
 	struct mutex lock;
+	struct ap_driver  *vfio_ap_drv;
 };
 
 extern struct ap_matrix_dev *matrix_dev;
-- 
2.7.4


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH v3 1/1] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem
  2019-02-21 14:14 ` [PATCH v3 1/1] " Pierre Morel
@ 2019-02-21 15:09   ` Cornelia Huck
  2019-02-21 15:21     ` Halil Pasic
  2019-02-21 16:18   ` Tony Krowiak
  2019-02-21 16:47   ` Christian Borntraeger
  2 siblings, 1 reply; 6+ messages in thread
From: Cornelia Huck @ 2019-02-21 15:09 UTC (permalink / raw)
  To: Pierre Morel
  Cc: borntraeger, linux-kernel, linux-s390, frankja, akrowiak, pasic,
	david, schwidefsky, heiko.carstens, freude

On Thu, 21 Feb 2019 15:14:54 +0100
Pierre Morel <pmorel@linux.ibm.com> wrote:

> Libudev relies on having a subsystem link for non-root devices. To
> avoid libudev (and potentially other userspace tools) choking on the
> matrix device let us introduce a matrix bus and with it the matrix
> bus subsytem. Also make the matrix device reside within the matrix
> bus.
> 
> Doing this we remove the forced link from the matrix device to the
> vfio_ap driver and the device_type we do not need anymore.
> 
> Since the associated matrix driver is not the vfio_ap driver any more,
> we have to change the search for the devices on the vfio_ap driver in
> the function vfio_ap_verify_queue_reserved.
> 
> Fixes: 1fde573413b5 ("s390: vfio-ap: base implementation of VFIO AP device driver")
> 
> Cc: stable@vger.kernel.org
> 

I'd kill the two empty lines.

> Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
> Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
> Acked-by: Halil Pasic <pasic@linux.ibm.com>
> ---
>  drivers/s390/crypto/vfio_ap_drv.c     | 44 ++++++++++++++++++++++++++++-------
>  drivers/s390/crypto/vfio_ap_ops.c     |  4 ++--
>  drivers/s390/crypto/vfio_ap_private.h |  1 +
>  3 files changed, 38 insertions(+), 11 deletions(-)

Otherwise, still looks good.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3 1/1] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem
  2019-02-21 15:09   ` Cornelia Huck
@ 2019-02-21 15:21     ` Halil Pasic
  0 siblings, 0 replies; 6+ messages in thread
From: Halil Pasic @ 2019-02-21 15:21 UTC (permalink / raw)
  To: Cornelia Huck
  Cc: Pierre Morel, borntraeger, linux-kernel, linux-s390, frankja,
	akrowiak, david, schwidefsky, heiko.carstens, freude

On Thu, 21 Feb 2019 16:09:10 +0100
Cornelia Huck <cohuck@redhat.com> wrote:

> On Thu, 21 Feb 2019 15:14:54 +0100
> Pierre Morel <pmorel@linux.ibm.com> wrote:
> 
> > Libudev relies on having a subsystem link for non-root devices. To
> > avoid libudev (and potentially other userspace tools) choking on the
> > matrix device let us introduce a matrix bus and with it the matrix
> > bus subsytem. Also make the matrix device reside within the matrix
> > bus.
> > 
> > Doing this we remove the forced link from the matrix device to the
> > vfio_ap driver and the device_type we do not need anymore.
> > 
> > Since the associated matrix driver is not the vfio_ap driver any more,
> > we have to change the search for the devices on the vfio_ap driver in
> > the function vfio_ap_verify_queue_reserved.
> > 
> > Fixes: 1fde573413b5 ("s390: vfio-ap: base implementation of VFIO AP device driver")
> > 
> > Cc: stable@vger.kernel.org
> > 
> 
> I'd kill the two empty lines.

The summary/title line is a bit weird. It says link to the vfio_ap bus
subsystem, which sounds like establishing a relationship between two
pre-existing entities.  But this change actually introduces the vfio_bus.
I would prefer something like "introduce vfio_ap bus".

I don't feel strongly about it.

Regards,
Halil

> 
> > Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
> > Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
> > Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> > Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
> > Reviewed-by: Cornelia Huck <cohuck@redhat.com>
> > Acked-by: Halil Pasic <pasic@linux.ibm.com>
> > ---
> >  drivers/s390/crypto/vfio_ap_drv.c     | 44 ++++++++++++++++++++++++++++-------
> >  drivers/s390/crypto/vfio_ap_ops.c     |  4 ++--
> >  drivers/s390/crypto/vfio_ap_private.h |  1 +
> >  3 files changed, 38 insertions(+), 11 deletions(-)
> 
> Otherwise, still looks good.
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3 1/1] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem
  2019-02-21 14:14 ` [PATCH v3 1/1] " Pierre Morel
  2019-02-21 15:09   ` Cornelia Huck
@ 2019-02-21 16:18   ` Tony Krowiak
  2019-02-21 16:47   ` Christian Borntraeger
  2 siblings, 0 replies; 6+ messages in thread
From: Tony Krowiak @ 2019-02-21 16:18 UTC (permalink / raw)
  To: Pierre Morel, borntraeger
  Cc: cohuck, linux-kernel, linux-s390, frankja, pasic, david,
	schwidefsky, heiko.carstens, freude

On 2/21/19 9:14 AM, Pierre Morel wrote:
> Libudev relies on having a subsystem link for non-root devices. To
> avoid libudev (and potentially other userspace tools) choking on the
> matrix device let us introduce a matrix bus and with it the matrix
> bus subsytem. Also make the matrix device reside within the matrix
> bus.
> 
> Doing this we remove the forced link from the matrix device to the
> vfio_ap driver and the device_type we do not need anymore.
> 
> Since the associated matrix driver is not the vfio_ap driver any more,
> we have to change the search for the devices on the vfio_ap driver in
> the function vfio_ap_verify_queue_reserved.
> 
> Fixes: 1fde573413b5 ("s390: vfio-ap: base implementation of VFIO AP device driver")
> 
> Cc: stable@vger.kernel.org
> 
> Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
> Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com>

> Acked-by: Halil Pasic <pasic@linux.ibm.com>
> ---
>   drivers/s390/crypto/vfio_ap_drv.c     | 44 ++++++++++++++++++++++++++++-------
>   drivers/s390/crypto/vfio_ap_ops.c     |  4 ++--
>   drivers/s390/crypto/vfio_ap_private.h |  1 +
>   3 files changed, 38 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
> index 31c6c84..e9824c3 100644
> --- a/drivers/s390/crypto/vfio_ap_drv.c
> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> @@ -15,7 +15,6 @@
>   #include "vfio_ap_private.h"
>   
>   #define VFIO_AP_ROOT_NAME "vfio_ap"
> -#define VFIO_AP_DEV_TYPE_NAME "ap_matrix"
>   #define VFIO_AP_DEV_NAME "matrix"
>   
>   MODULE_AUTHOR("IBM Corporation");
> @@ -24,10 +23,6 @@ MODULE_LICENSE("GPL v2");
>   
>   static struct ap_driver vfio_ap_drv;
>   
> -static struct device_type vfio_ap_dev_type = {
> -	.name = VFIO_AP_DEV_TYPE_NAME,
> -};
> -
>   struct ap_matrix_dev *matrix_dev;
>   
>   /* Only type 10 adapters (CEX4 and later) are supported
> @@ -62,6 +57,22 @@ static void vfio_ap_matrix_dev_release(struct device *dev)
>   	kfree(matrix_dev);
>   }
>   
> +static int matrix_bus_match(struct device *dev, struct device_driver *drv)
> +{
> +	return 1;
> +}
> +
> +static struct bus_type matrix_bus = {
> +	.name = "matrix",

I'm sorry, I'm late to the game due to being in a time zone six hours
behind you all, but my preference would be 'ap_matrix' for the name
of the bus. It seems odd to have the bus and the device both named
'matrix'. It's just my opinion and not a show stopper.

> +	.match = &matrix_bus_match,
> +};
> +
> +static struct device_driver matrix_driver = {
> +	.name = "vfio_ap",
> +	.bus = &matrix_bus,
> +	.suppress_bind_attrs = true,
> +};
> +
>   static int vfio_ap_matrix_dev_create(void)
>   {
>   	int ret;
> @@ -71,6 +82,10 @@ static int vfio_ap_matrix_dev_create(void)
>   	if (IS_ERR(root_device))
>   		return PTR_ERR(root_device);
>   
> +	ret = bus_register(&matrix_bus);
> +	if (ret)
> +		goto bus_register_err;
> +
>   	matrix_dev = kzalloc(sizeof(*matrix_dev), GFP_KERNEL);
>   	if (!matrix_dev) {
>   		ret = -ENOMEM;
> @@ -87,30 +102,41 @@ static int vfio_ap_matrix_dev_create(void)
>   	mutex_init(&matrix_dev->lock);
>   	INIT_LIST_HEAD(&matrix_dev->mdev_list);
>   
> -	matrix_dev->device.type = &vfio_ap_dev_type;
>   	dev_set_name(&matrix_dev->device, "%s", VFIO_AP_DEV_NAME);
>   	matrix_dev->device.parent = root_device;
> +	matrix_dev->device.bus = &matrix_bus;
>   	matrix_dev->device.release = vfio_ap_matrix_dev_release;
> -	matrix_dev->device.driver = &vfio_ap_drv.driver;
> +	matrix_dev->vfio_ap_drv = &vfio_ap_drv;
>   
>   	ret = device_register(&matrix_dev->device);
>   	if (ret)
>   		goto matrix_reg_err;
>   
> +	ret = driver_register(&matrix_driver);
> +	if (ret)
> +		goto matrix_drv_err;
> +
>   	return 0;
>   
> +matrix_drv_err:
> +	device_unregister(&matrix_dev->device);
>   matrix_reg_err:
>   	put_device(&matrix_dev->device);
>   matrix_alloc_err:
> +	bus_unregister(&matrix_bus);
> +bus_register_err:
>   	root_device_unregister(root_device);
> -
>   	return ret;
>   }
>   
>   static void vfio_ap_matrix_dev_destroy(void)
>   {
> +	struct device *root_device = matrix_dev->device.parent;
> +
> +	driver_unregister(&matrix_driver);
>   	device_unregister(&matrix_dev->device);
> -	root_device_unregister(matrix_dev->device.parent);
> +	bus_unregister(&matrix_bus);
> +	root_device_unregister(root_device);
>   }
>   
>   static int __init vfio_ap_init(void)
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 272ef42..900b9cf 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -198,8 +198,8 @@ static int vfio_ap_verify_queue_reserved(unsigned long *apid,
>   	qres.apqi = apqi;
>   	qres.reserved = false;
>   
> -	ret = driver_for_each_device(matrix_dev->device.driver, NULL, &qres,
> -				     vfio_ap_has_queue);
> +	ret = driver_for_each_device(&matrix_dev->vfio_ap_drv->driver, NULL,
> +				     &qres, vfio_ap_has_queue);
>   	if (ret)
>   		return ret;
>   
> diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h
> index 5675492..76b7f98 100644
> --- a/drivers/s390/crypto/vfio_ap_private.h
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -40,6 +40,7 @@ struct ap_matrix_dev {
>   	struct ap_config_info info;
>   	struct list_head mdev_list;
>   	struct mutex lock;
> +	struct ap_driver  *vfio_ap_drv;
>   };
>   
>   extern struct ap_matrix_dev *matrix_dev;
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3 1/1] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem
  2019-02-21 14:14 ` [PATCH v3 1/1] " Pierre Morel
  2019-02-21 15:09   ` Cornelia Huck
  2019-02-21 16:18   ` Tony Krowiak
@ 2019-02-21 16:47   ` Christian Borntraeger
  2 siblings, 0 replies; 6+ messages in thread
From: Christian Borntraeger @ 2019-02-21 16:47 UTC (permalink / raw)
  To: Pierre Morel
  Cc: cohuck, linux-kernel, linux-s390, frankja, akrowiak, pasic,
	david, schwidefsky, heiko.carstens, freude



On 21.02.2019 15:14, Pierre Morel wrote:
> Libudev relies on having a subsystem link for non-root devices. To
> avoid libudev (and potentially other userspace tools) choking on the
> matrix device let us introduce a matrix bus and with it the matrix
> bus subsytem. Also make the matrix device reside within the matrix
> bus.
> 
> Doing this we remove the forced link from the matrix device to the
> vfio_ap driver and the device_type we do not need anymore.
> 
> Since the associated matrix driver is not the vfio_ap driver any more,
> we have to change the search for the devices on the vfio_ap driver in
> the function vfio_ap_verify_queue_reserved.
> 
> Fixes: 1fde573413b5 ("s390: vfio-ap: base implementation of VFIO AP device driver")
> 
> Cc: stable@vger.kernel.org
> 
> Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
> Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
> Acked-by: Halil Pasic <pasic@linux.ibm.com>

New version still works fine. Please consider the latest comments (e.g. ap_matrix
for the bus name, remove the empty lines) and push to Martins tree.

> ---
>  drivers/s390/crypto/vfio_ap_drv.c     | 44 ++++++++++++++++++++++++++++-------
>  drivers/s390/crypto/vfio_ap_ops.c     |  4 ++--
>  drivers/s390/crypto/vfio_ap_private.h |  1 +
>  3 files changed, 38 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
> index 31c6c84..e9824c3 100644
> --- a/drivers/s390/crypto/vfio_ap_drv.c
> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> @@ -15,7 +15,6 @@
>  #include "vfio_ap_private.h"
>  
>  #define VFIO_AP_ROOT_NAME "vfio_ap"
> -#define VFIO_AP_DEV_TYPE_NAME "ap_matrix"
>  #define VFIO_AP_DEV_NAME "matrix"
>  
>  MODULE_AUTHOR("IBM Corporation");
> @@ -24,10 +23,6 @@ MODULE_LICENSE("GPL v2");
>  
>  static struct ap_driver vfio_ap_drv;
>  
> -static struct device_type vfio_ap_dev_type = {
> -	.name = VFIO_AP_DEV_TYPE_NAME,
> -};
> -
>  struct ap_matrix_dev *matrix_dev;
>  
>  /* Only type 10 adapters (CEX4 and later) are supported
> @@ -62,6 +57,22 @@ static void vfio_ap_matrix_dev_release(struct device *dev)
>  	kfree(matrix_dev);
>  }
>  
> +static int matrix_bus_match(struct device *dev, struct device_driver *drv)
> +{
> +	return 1;
> +}
> +
> +static struct bus_type matrix_bus = {
> +	.name = "matrix",
> +	.match = &matrix_bus_match,
> +};
> +
> +static struct device_driver matrix_driver = {
> +	.name = "vfio_ap",
> +	.bus = &matrix_bus,
> +	.suppress_bind_attrs = true,
> +};
> +
>  static int vfio_ap_matrix_dev_create(void)
>  {
>  	int ret;
> @@ -71,6 +82,10 @@ static int vfio_ap_matrix_dev_create(void)
>  	if (IS_ERR(root_device))
>  		return PTR_ERR(root_device);
>  
> +	ret = bus_register(&matrix_bus);
> +	if (ret)
> +		goto bus_register_err;
> +
>  	matrix_dev = kzalloc(sizeof(*matrix_dev), GFP_KERNEL);
>  	if (!matrix_dev) {
>  		ret = -ENOMEM;
> @@ -87,30 +102,41 @@ static int vfio_ap_matrix_dev_create(void)
>  	mutex_init(&matrix_dev->lock);
>  	INIT_LIST_HEAD(&matrix_dev->mdev_list);
>  
> -	matrix_dev->device.type = &vfio_ap_dev_type;
>  	dev_set_name(&matrix_dev->device, "%s", VFIO_AP_DEV_NAME);
>  	matrix_dev->device.parent = root_device;
> +	matrix_dev->device.bus = &matrix_bus;
>  	matrix_dev->device.release = vfio_ap_matrix_dev_release;
> -	matrix_dev->device.driver = &vfio_ap_drv.driver;
> +	matrix_dev->vfio_ap_drv = &vfio_ap_drv;
>  
>  	ret = device_register(&matrix_dev->device);
>  	if (ret)
>  		goto matrix_reg_err;
>  
> +	ret = driver_register(&matrix_driver);
> +	if (ret)
> +		goto matrix_drv_err;
> +
>  	return 0;
>  
> +matrix_drv_err:
> +	device_unregister(&matrix_dev->device);
>  matrix_reg_err:
>  	put_device(&matrix_dev->device);
>  matrix_alloc_err:
> +	bus_unregister(&matrix_bus);
> +bus_register_err:
>  	root_device_unregister(root_device);
> -
>  	return ret;
>  }
>  
>  static void vfio_ap_matrix_dev_destroy(void)
>  {
> +	struct device *root_device = matrix_dev->device.parent;
> +
> +	driver_unregister(&matrix_driver);
>  	device_unregister(&matrix_dev->device);
> -	root_device_unregister(matrix_dev->device.parent);
> +	bus_unregister(&matrix_bus);
> +	root_device_unregister(root_device);
>  }
>  
>  static int __init vfio_ap_init(void)
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 272ef42..900b9cf 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -198,8 +198,8 @@ static int vfio_ap_verify_queue_reserved(unsigned long *apid,
>  	qres.apqi = apqi;
>  	qres.reserved = false;
>  
> -	ret = driver_for_each_device(matrix_dev->device.driver, NULL, &qres,
> -				     vfio_ap_has_queue);
> +	ret = driver_for_each_device(&matrix_dev->vfio_ap_drv->driver, NULL,
> +				     &qres, vfio_ap_has_queue);
>  	if (ret)
>  		return ret;
>  
> diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h
> index 5675492..76b7f98 100644
> --- a/drivers/s390/crypto/vfio_ap_private.h
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -40,6 +40,7 @@ struct ap_matrix_dev {
>  	struct ap_config_info info;
>  	struct list_head mdev_list;
>  	struct mutex lock;
> +	struct ap_driver  *vfio_ap_drv;
>  };
>  
>  extern struct ap_matrix_dev *matrix_dev;
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-02-21 16:47 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-21 14:14 [PATCH v3 0/1] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem Pierre Morel
2019-02-21 14:14 ` [PATCH v3 1/1] " Pierre Morel
2019-02-21 15:09   ` Cornelia Huck
2019-02-21 15:21     ` Halil Pasic
2019-02-21 16:18   ` Tony Krowiak
2019-02-21 16:47   ` Christian Borntraeger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).