lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BYAPR21MB1688962642EBF09FA8C7FAEBD7BE9@BYAPR21MB1688.namprd21.prod.outlook.com>
Date:   Tue, 14 Mar 2023 21:21:32 +0000
From:   "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To:     Saurabh Sengar <ssengar@...ux.microsoft.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        "wei.liu@...nel.org" <wei.liu@...nel.org>,
        Dexuan Cui <decui@...rosoft.com>,
        "daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "lenb@...nel.org" <lenb@...nel.org>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: RE: [PATCH v8 5/5] Driver: VMBus: Add Devicetree support

From: Saurabh Sengar <ssengar@...ux.microsoft.com> Sent: Tuesday, March 14, 2023 2:16 AM
> 
> Update the driver to support Devicetree boot as well along with ACPI.
> At present the Devicetree parsing only provides the mmio region info
> and is not the exact copy of ACPI parsing. This is sufficient to cater
> all the current Devicetree usecases for VMBus.
> 
> Currently Devicetree is supported only for x86 systems.
> 
> Signed-off-by: Saurabh Sengar <ssengar@...ux.microsoft.com>
> ---
> [V8]
> - Remove the auto select of CONFIG_OF
> - Remove the dependency on !ACPI for OF_EARLY_FLATTREE
> - Used acpi_disabled instead of #ifdef and hence added a dummy function
>   for vmbus_acpi_add
> - GFP_ATOMIC -> GFP_KERNEL
> - used range.flags instead of hard coding flags
> - used __maybe_unused for acpi device id, removed #ifdef
> 
>  drivers/hv/Kconfig     |  5 ++--
>  drivers/hv/vmbus_drv.c | 64 +++++++++++++++++++++++++++++++++++++++---
>  2 files changed, 63 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index 0747a8f1fcee..47132b30b7ee 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -4,11 +4,12 @@ menu "Microsoft Hyper-V guest support"
> 
>  config HYPERV
>  	tristate "Microsoft Hyper-V client drivers"
> -	depends on ACPI && ((X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
> -		|| (ARM64 && !CPU_BIG_ENDIAN))
> +	depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
> +		|| (ACPI && ARM64 && !CPU_BIG_ENDIAN)
>  	select PARAVIRT
>  	select X86_HV_CALLBACK_VECTOR if X86
>  	select VMAP_PFN
> +	select OF_EARLY_FLATTREE if OF
>  	help
>  	  Select this option to run Linux as a Hyper-V client operating
>  	  system.
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 3ad2fa2b92e7..15097e1f3f2b 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -20,6 +20,7 @@
>  #include <linux/completion.h>
>  #include <linux/hyperv.h>
>  #include <linux/kernel_stat.h>
> +#include <linux/of_address.h>
>  #include <linux/clockchips.h>
>  #include <linux/cpu.h>
>  #include <linux/sched/isolation.h>
> @@ -2143,7 +2144,7 @@ void vmbus_device_unregister(struct hv_device *device_obj)
>  	device_unregister(&device_obj->device);
>  }
> 
> -
> +#ifdef CONFIG_ACPI
>  /*
>   * VMBUS is an acpi enumerated device. Get the information we
>   * need from DSDT.
> @@ -2253,6 +2254,7 @@ static acpi_status vmbus_walk_resources(struct acpi_resource
> *res, void *ctx)
> 
>  	return AE_OK;
>  }
> +#endif
> 
>  static void vmbus_mmio_remove(void)
>  {
> @@ -2273,7 +2275,7 @@ static void vmbus_mmio_remove(void)
>  	}
>  }
> 
> -static void vmbus_reserve_fb(void)
> +static void __maybe_unused vmbus_reserve_fb(void)
>  {
>  	resource_size_t start = 0, size;
>  	struct pci_dev *pdev;
> @@ -2433,6 +2435,7 @@ void vmbus_free_mmio(resource_size_t start, resource_size_t
> size)
>  }
>  EXPORT_SYMBOL_GPL(vmbus_free_mmio);
> 
> +#ifdef CONFIG_ACPI
>  static int vmbus_acpi_add(struct platform_device *pdev)
>  {
>  	acpi_status result;
> @@ -2485,10 +2488,52 @@ static int vmbus_acpi_add(struct platform_device *pdev)
>  		vmbus_mmio_remove();
>  	return ret_val;
>  }
> +#else
> +static int vmbus_acpi_add(struct platform_device *pdev)
> +{
> +	return 0;
> +}
> +#endif
> +
> +static int vmbus_device_add(struct platform_device *pdev)
> +{
> +	struct resource **cur_res = &hyperv_mmio;
> +	struct of_range range;
> +	struct of_range_parser parser;
> +	struct device_node *np = pdev->dev.of_node;
> +	int ret;
> +
> +	hv_dev = &pdev->dev;
> +
> +	ret = of_range_parser_init(&parser, np);
> +	if (ret)
> +		return ret;
> +
> +	for_each_of_range(&parser, &range) {
> +		struct resource *res;
> +
> +		res = kzalloc(sizeof(*res), GFP_KERNEL);
> +		if (!res)
> +			return -ENOMEM;

I should have looked at this more closely in the previous
revision.  But if this error path is taken, does any cleanup
need to be done of 'res' entries that were allocated in
previous iterations of the for_each_of_range() loop?  It
seems like the cleanup and releasing of previously allocated
memory should be done.

> +
> +		res->name = "hyperv mmio";
> +		res->flags = range.flags;
> +		res->start = range.cpu_addr;
> +		res->end = range.cpu_addr + range.size;
> +
> +		*cur_res = res;
> +		cur_res = &res->sibling;
> +	}
> +
> +	return ret;
> +}
> 
>  static int vmbus_platform_driver_probe(struct platform_device *pdev)
>  {
> -	return vmbus_acpi_add(pdev);
> +	if (!acpi_disabled)
> +		return vmbus_acpi_add(pdev);
> +	else
> +		return vmbus_device_add(pdev);

Nit: Usually when there's a negated test with if/else, it's best to flip the
if and else clauses so as to eliminate the negation.  It's just slightly less
semantic load for the human reader to parse through.  So:

	if (acpi_disabled)
		return vmbus_device_add(pdev);
	else
		return vmbus_acpi_add(pdev);

Everything else looks good to me.

Michael

>  }
> 
>  static int vmbus_platform_driver_remove(struct platform_device *pdev)
> @@ -2634,7 +2679,17 @@ static int vmbus_bus_resume(struct device *dev)
>  #define vmbus_bus_resume NULL
>  #endif /* CONFIG_PM_SLEEP */
> 
> -static const struct acpi_device_id vmbus_acpi_device_ids[] = {
> +static const __maybe_unused struct of_device_id vmbus_of_match[] = {
> +	{
> +		.compatible = "microsoft,vmbus",
> +	},
> +	{
> +		/* sentinel */
> +	},
> +};
> +MODULE_DEVICE_TABLE(of, vmbus_of_match);
> +
> +static const __maybe_unused struct acpi_device_id vmbus_acpi_device_ids[] = {
>  	{"VMBUS", 0},
>  	{"VMBus", 0},
>  	{"", 0},
> @@ -2668,6 +2723,7 @@ static struct platform_driver vmbus_platform_driver = {
>  	.driver = {
>  		.name = "vmbus",
>  		.acpi_match_table = ACPI_PTR(vmbus_acpi_device_ids),
> +		.of_match_table = of_match_ptr(vmbus_of_match),
>  		.pm = &vmbus_bus_pm,
>  		.probe_type = PROBE_FORCE_SYNCHRONOUS,
>  	}
> --
> 2.34.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ