virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Kelley \(LINUX\) via Virtualization" <virtualization@lists.linux-foundation.org>
To: Saurabh Sengar <ssengar@linux.microsoft.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"krzysztof.kozlowski+dt@linaro.org"
	<krzysztof.kozlowski+dt@linaro.org>,
	KY Srinivasan <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	"wei.liu@kernel.org" <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	Saurabh Singh Sengar <ssengar@microsoft.com>
Subject: RE: [PATCH v2 3/6] Drivers: hv: vmbus: Convert acpi_device to platform_device
Date: Wed, 1 Feb 2023 18:32:29 +0000	[thread overview]
Message-ID: <BYAPR21MB1688C6978F68D904ABC00911D7D19@BYAPR21MB1688.namprd21.prod.outlook.com> (raw)
In-Reply-To: <1675188609-20913-4-git-send-email-ssengar@linux.microsoft.com>

From: Saurabh Sengar <ssengar@linux.microsoft.com> Sent: Tuesday, January 31, 2023 10:10 AM
> 
> Use more generic platform device instead of acpi device. Also rename the
> function vmbus_acpi_remove to more generic name vmbus_mmio_remove.
> 
> Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
> ---
>  drivers/hv/vmbus_drv.c | 78 +++++++++++++++++++++++++-----------------
>  1 file changed, 46 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index d24dd65b33d4..49030e756b9f 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -12,6 +12,7 @@
>  #include <linux/init.h>
>  #include <linux/module.h>
>  #include <linux/device.h>
> +#include <linux/platform_device.h>
>  #include <linux/interrupt.h>
>  #include <linux/sysctl.h>
>  #include <linux/slab.h>
> @@ -44,7 +45,7 @@ struct vmbus_dynid {
>  	struct hv_vmbus_device_id id;
>  };
> 
> -static struct acpi_device  *hv_acpi_dev;
> +static struct platform_device  *hv_dev;
> 
>  static int hyperv_cpuhp_online;
> 
> @@ -143,7 +144,7 @@ static DEFINE_MUTEX(hyperv_mmio_lock);
> 
>  static int vmbus_exists(void)
>  {
> -	if (hv_acpi_dev == NULL)
> +	if (hv_dev == NULL)
>  		return -ENODEV;
> 
>  	return 0;
> @@ -932,7 +933,7 @@ static int vmbus_dma_configure(struct device *child_device)
>  	 * On x86/x64 coherence is assumed and these calls have no effect.
>  	 */
>  	hv_setup_dma_ops(child_device,
> -		device_get_dma_attr(&hv_acpi_dev->dev) == DEV_DMA_COHERENT);
> +		device_get_dma_attr(&hv_dev->dev) == DEV_DMA_COHERENT);
>  	return 0;
>  }
> 
> @@ -2090,7 +2091,7 @@ int vmbus_device_register(struct hv_device
> *child_device_obj)
>  		     &child_device_obj->channel->offermsg.offer.if_instance);
> 
>  	child_device_obj->device.bus = &hv_bus;
> -	child_device_obj->device.parent = &hv_acpi_dev->dev;
> +	child_device_obj->device.parent = &hv_dev->dev;
>  	child_device_obj->device.release = vmbus_device_release;
> 
>  	child_device_obj->device.dma_parms = &child_device_obj->dma_parms;
> @@ -2262,7 +2263,7 @@ static acpi_status vmbus_walk_resources(struct
> acpi_resource *res, void *ctx)
>  	return AE_OK;
>  }
> 
> -static void vmbus_acpi_remove(struct acpi_device *device)
> +static void vmbus_mmio_remove(void)
>  {
>  	struct resource *cur_res;
>  	struct resource *next_res;
> @@ -2441,13 +2442,15 @@ void vmbus_free_mmio(resource_size_t start,
> resource_size_t size)
>  }
>  EXPORT_SYMBOL_GPL(vmbus_free_mmio);
> 
> -static int vmbus_acpi_add(struct acpi_device *device)
> +static int vmbus_acpi_add(struct platform_device *pdev)
>  {
>  	acpi_status result;
>  	int ret_val = -ENODEV;
> -	struct acpi_device *ancestor;
> +	struct platform_device *ancestor;
> +	struct acpi_device *adev = to_acpi_device(&pdev->dev);

This doesn't work.  The argument to vmbus_acpi_add() is a struct
platform_device, which has a struct device embedded in it (not a
pointer).   to_acpi_device() takes a struct device as an argument,
assuming that the struct device is embedded in a struct
acpi_device, which is not the case here.  The resulting local
variable adev is actually pointing to some (perhaps negative)
offset within the struct platform_device, and uses of adev are
getting unknown random data from within (or before) the
struct platform_device.

> 
> -	hv_acpi_dev = device;
> +	hv_dev = pdev;
> +	adev->fwnode.dev = &pdev->dev;
> 
>  	/*
>  	 * Older versions of Hyper-V for ARM64 fail to include the _CCA
> @@ -2456,15 +2459,16 @@ static int vmbus_acpi_add(struct acpi_device *device)
>  	 * up the ACPI device to behave as if _CCA is present and indicates
>  	 * hardware coherence.
>  	 */
> -	ACPI_COMPANION_SET(&device->dev, device);
> +	ACPI_COMPANION_SET(&pdev->dev, ACPI_COMPANION(&pdev->dev));

This statement seems tautological.  If ACPI_COMPANION(&pdev->dev)
returns a valid result,  why would the ACPI companion for &pdev->dev
need to be set?  The original code was setting the ACPI companion for the
embedded struct device to be the struct acpi_device.   I forget why this
wasn't already done for the VMBus device when it was originally parsed
from the ACPI DSDT ... 

>  	if (IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED) &&
> -	    device_get_dma_attr(&device->dev) == DEV_DMA_NOT_SUPPORTED) {
> +	    device_get_dma_attr(&pdev->dev) == DEV_DMA_NOT_SUPPORTED) {
> +		struct acpi_device *adev_node = ACPI_COMPANION(&pdev->dev);

If earlier code in this function can get a correct pointer to the struct acpi_device,
then this statement shouldn't be necessary.  You already have it.

>  		pr_info("No ACPI _CCA found; assuming coherent device I/O\n");
> -		device->flags.cca_seen = true;
> -		device->flags.coherent_dma = true;
> +		adev_node->flags.cca_seen = true;
> +		adev_node->flags.coherent_dma = true;
>  	}
> 
> -	result = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> +	result = acpi_walk_resources(ACPI_HANDLE(&pdev->dev), METHOD_NAME__CRS,

Again, if you have a correct pointer to the struct acpi_device, then adev->handle
(like the original code) should be simpler than looking it up again with ACPI_HANDLE().  

>  					vmbus_walk_resources, NULL);
> 
>  	if (ACPI_FAILURE(result))
> @@ -2473,9 +2477,9 @@ static int vmbus_acpi_add(struct acpi_device *device)
>  	 * Some ancestor of the vmbus acpi device (Gen1 or Gen2
>  	 * firmware) is the VMOD that has the mmio ranges. Get that.
>  	 */
> -	for (ancestor = acpi_dev_parent(device); ancestor;
> -	     ancestor = acpi_dev_parent(ancestor)) {
> -		result = acpi_walk_resources(ancestor->handle, METHOD_NAME__CRS,
> +	for (ancestor = to_platform_device(pdev->dev.parent); ancestor;
> +	     ancestor = to_platform_device(ancestor->dev.parent)) {
> +		result = acpi_walk_resources(ACPI_HANDLE(&ancestor->dev), METHOD_NAME__CRS,

Similarly, if you get a correct pointer to the struct acpi_device, does the above
code need any changes?  I'm hoping not.

>  					     vmbus_walk_resources, NULL);
> 
>  		if (ACPI_FAILURE(result))
> @@ -2489,10 +2493,21 @@ static int vmbus_acpi_add(struct acpi_device *device)
> 
>  acpi_walk_err:
>  	if (ret_val)
> -		vmbus_acpi_remove(device);
> +		vmbus_mmio_remove();
>  	return ret_val;
>  }
> 
> +static int vmbus_platform_driver_probe(struct platform_device *pdev)
> +{
> +	return vmbus_acpi_add(pdev);
> +}
> +
> +static int vmbus_platform_driver_remove(struct platform_device *pdev)
> +{
> +	vmbus_mmio_remove();
> +	return 0;
> +}
> +
>  #ifdef CONFIG_PM_SLEEP
>  static int vmbus_bus_suspend(struct device *dev)
>  {
> @@ -2658,15 +2673,15 @@ static const struct dev_pm_ops vmbus_bus_pm = {
>  	.restore_noirq	= vmbus_bus_resume
>  };
> 
> -static struct acpi_driver vmbus_acpi_driver = {
> -	.name = "vmbus",
> -	.ids = vmbus_acpi_device_ids,
> -	.ops = {
> -		.add = vmbus_acpi_add,
> -		.remove = vmbus_acpi_remove,
> -	},
> -	.drv.pm = &vmbus_bus_pm,
> -	.drv.probe_type = PROBE_FORCE_SYNCHRONOUS,
> +static struct platform_driver vmbus_platform_driver = {
> +	.probe = vmbus_platform_driver_probe,
> +	.remove = vmbus_platform_driver_remove,
> +	.driver = {
> +		.name = "vmbus",
> +		.acpi_match_table = ACPI_PTR(vmbus_acpi_device_ids),
> +		.pm = &vmbus_bus_pm,
> +		.probe_type = PROBE_FORCE_SYNCHRONOUS,
> +	}
>  };
> 
>  static void hv_kexec_handler(void)
> @@ -2750,12 +2765,11 @@ static int __init hv_acpi_init(void)
>  	/*
>  	 * Get ACPI resources first.
>  	 */
> -	ret = acpi_bus_register_driver(&vmbus_acpi_driver);
> -
> +	ret = platform_driver_register(&vmbus_platform_driver);
>  	if (ret)
>  		return ret;
> 
> -	if (!hv_acpi_dev) {
> +	if (!hv_dev) {
>  		ret = -ENODEV;
>  		goto cleanup;
>  	}
> @@ -2785,8 +2799,8 @@ static int __init hv_acpi_init(void)
>  	return 0;
> 
>  cleanup:
> -	acpi_bus_unregister_driver(&vmbus_acpi_driver);
> -	hv_acpi_dev = NULL;
> +	platform_driver_unregister(&vmbus_platform_driver);
> +	hv_dev = NULL;
>  	return ret;
>  }
> 
> @@ -2839,7 +2853,7 @@ static void __exit vmbus_exit(void)
> 
>  	cpuhp_remove_state(hyperv_cpuhp_online);
>  	hv_synic_free();
> -	acpi_bus_unregister_driver(&vmbus_acpi_driver);
> +	platform_driver_unregister(&vmbus_platform_driver);
>  }
> 
> 
> --
> 2.25.1

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

      parent reply	other threads:[~2023-02-01 18:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1675188609-20913-1-git-send-email-ssengar@linux.microsoft.com>
     [not found] ` <1675188609-20913-5-git-send-email-ssengar@linux.microsoft.com>
2023-01-31 19:57   ` [PATCH v2 4/6] dt-bindings: hypervisor: Rename virtio to hypervisor Rob Herring
     [not found] ` <CAL_JsqKL3JA6nAkEHuuyxbs8-Mm=Q-nNkCmpnDApNUDVbLsvKw@mail.gmail.com>
     [not found]   ` <20230201020449.GC20379@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
2023-02-01 14:51     ` [PATCH v2 0/6] Device tree support for Hyper-V VMBus driver Rob Herring
     [not found]       ` <20230201163455.GA21409@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
2023-02-07 17:53         ` Rob Herring
     [not found] ` <1675188609-20913-7-git-send-email-ssengar@linux.microsoft.com>
     [not found]   ` <CAL_JsqK_7eTTrSd6EKDGy9A8kC5w6cjVEtSi3CB1M7Awj+zg6g@mail.gmail.com>
     [not found]     ` <20230201165133.GA24116@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
2023-02-01 17:46       ` [PATCH v2 6/6] Driver: VMBus: Add device tree support Rob Herring
     [not found]         ` <20230203173616.GA8582@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
2023-02-07 17:38           ` Rob Herring
     [not found] ` <1675188609-20913-3-git-send-email-ssengar@linux.microsoft.com>
2023-02-01 17:47   ` [PATCH v2 2/6] Drivers: hv: allow non ACPI compilation for hv_is_hibernation_supported Michael Kelley (LINUX) via Virtualization
     [not found]     ` <20230202144843.GA11173@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
2023-02-02 15:33       ` Michael Kelley (LINUX) via Virtualization
     [not found] ` <1675188609-20913-4-git-send-email-ssengar@linux.microsoft.com>
2023-02-01 18:32   ` Michael Kelley (LINUX) via Virtualization [this message]

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=BYAPR21MB1688C6978F68D904ABC00911D7D19@BYAPR21MB1688.namprd21.prod.outlook.com \
    --to=virtualization@lists.linux-foundation.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=decui@microsoft.com \
    --cc=devicetree@vger.kernel.org \
    --cc=haiyangz@microsoft.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikelley@microsoft.com \
    --cc=robh+dt@kernel.org \
    --cc=ssengar@linux.microsoft.com \
    --cc=ssengar@microsoft.com \
    --cc=tglx@linutronix.de \
    --cc=wei.liu@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;
as well as URLs for NNTP newsgroup(s).