public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: [PATCH 2/3] vfio/mdev: inline needed class_compat functionality
Date: Wed, 4 Dec 2024 10:32:32 +0100	[thread overview]
Message-ID: <2024120430-boneless-wafer-bf0c@gregkh> (raw)
In-Reply-To: <0a14a4df-fbb5-4613-837f-f8025dc73380@gmail.com>

On Tue, Dec 03, 2024 at 09:11:47PM +0100, Heiner Kallweit wrote:
> vfio/mdev is the last user of class_compat, and it doesn't use it for
> the intended purpose. See kdoc of class_compat_register():
> Compatibility class are meant as a temporary user-space compatibility
> workaround when converting a family of class devices to a bus devices.

True, so waht is mdev doing here?

> In addition it uses only a part of the class_compat functionality.
> So inline the needed functionality, and afterwards all class_compat
> code can be removed.
> 
> No functional change intended. Compile-tested only.
> 
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
>  drivers/vfio/mdev/mdev_core.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index ed4737de4..a22c49804 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -18,7 +18,7 @@
>  #define DRIVER_AUTHOR		"NVIDIA Corporation"
>  #define DRIVER_DESC		"Mediated device Core Driver"
>  
> -static struct class_compat *mdev_bus_compat_class;
> +static struct kobject *mdev_bus_kobj;



>  
>  static LIST_HEAD(mdev_list);
>  static DEFINE_MUTEX(mdev_list_lock);
> @@ -76,7 +76,7 @@ int mdev_register_parent(struct mdev_parent *parent, struct device *dev,
>  	if (ret)
>  		return ret;
>  
> -	ret = class_compat_create_link(mdev_bus_compat_class, dev, NULL);
> +	ret = sysfs_create_link(mdev_bus_kobj, &dev->kobj, dev_name(dev));

This feels really wrong, why create a link to a random kobject?  Who is
using this kobject link?

>  	if (ret)
>  		dev_warn(dev, "Failed to create compatibility class link\n");
>  
> @@ -98,7 +98,7 @@ void mdev_unregister_parent(struct mdev_parent *parent)
>  	dev_info(parent->dev, "MDEV: Unregistering\n");
>  
>  	down_write(&parent->unreg_sem);
> -	class_compat_remove_link(mdev_bus_compat_class, parent->dev, NULL);
> +	sysfs_remove_link(mdev_bus_kobj, dev_name(parent->dev));
>  	device_for_each_child(parent->dev, NULL, mdev_device_remove_cb);
>  	parent_remove_sysfs_files(parent);
>  	up_write(&parent->unreg_sem);
> @@ -251,8 +251,8 @@ static int __init mdev_init(void)
>  	if (ret)
>  		return ret;
>  
> -	mdev_bus_compat_class = class_compat_register("mdev_bus");
> -	if (!mdev_bus_compat_class) {
> +	mdev_bus_kobj = class_pseudo_register("mdev_bus");

But this isn't a class, so let's not fake it please.  Let's fix this
properly, odds are all of this code can just be removed entirely, right?

thanks,

greg k-h

  reply	other threads:[~2024-12-04  9:32 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-03 20:08 [PATCH 0/3] driver core: class: remove class_compat code Heiner Kallweit
2024-12-03 20:10 ` [PATCH 1/3] driver core: class: add class_pseudo_register Heiner Kallweit
2024-12-04  9:33   ` Greg Kroah-Hartman
2024-12-04 17:04     ` Heiner Kallweit
2024-12-04 18:17       ` Greg Kroah-Hartman
2024-12-04 19:35         ` Heiner Kallweit
2024-12-03 20:11 ` [PATCH 2/3] vfio/mdev: inline needed class_compat functionality Heiner Kallweit
2024-12-04  9:32   ` Greg Kroah-Hartman [this message]
2024-12-04 17:01     ` Heiner Kallweit
2024-12-04 18:16       ` Greg Kroah-Hartman
2024-12-04 19:30         ` Alex Williamson
2024-12-06  7:35           ` Heiner Kallweit
2024-12-06  7:42             ` Greg Kroah-Hartman
2024-12-06 16:37               ` Alex Williamson
2024-12-07  8:38                 ` Greg Kroah-Hartman
2024-12-07 10:06                   ` Heiner Kallweit
2024-12-07 10:23                     ` Greg Kroah-Hartman
2024-12-12  4:42                     ` Christoph Hellwig
2024-12-12 18:12                       ` Alex Williamson
2024-12-12 18:21                         ` Greg Kroah-Hartman
2024-12-12 18:39                           ` Alex Williamson
2024-12-13 14:53                         ` Christoph Hellwig
2024-12-06 17:05               ` Heiner Kallweit
2024-12-04 19:35         ` Heiner Kallweit
2025-01-10 14:35   ` Greg Kroah-Hartman
2025-01-13 22:09     ` Alex Williamson
2024-12-03 20:12 ` [PATCH 3/3] driver core: class: remove class_compat code Heiner Kallweit
2024-12-12  4:27 ` [PATCH 0/3] " Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2024120430-boneless-wafer-bf0c@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=alex.williamson@redhat.com \
    --cc=hkallweit1@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox