All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Sinan Kaya <okaya@codeaurora.org>
Cc: kvm@vger.kernel.org, timur@codeaurora.org, cov@codeaurora.org,
	jcm@redhat.com, eric.auger@redhat.com,
	linux-acpi@vger.kernel.org, agross@codeaurora.org,
	linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Baptiste Reynal <b.reynal@virtualopensystems.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V10 4/9] vfio: platform: add support for ACPI probe
Date: Mon, 18 Jul 2016 18:00:49 -0600	[thread overview]
Message-ID: <20160718180049.78db3dfb@t450s.home> (raw)
In-Reply-To: <1468883367-2854-5-git-send-email-okaya@codeaurora.org>

On Mon, 18 Jul 2016 19:09:22 -0400
Sinan Kaya <okaya@codeaurora.org> wrote:

> The code is using the compatible DT string to associate a reset driver
> with the actual device itself. The compatible string does not exist on
> ACPI based systems. HID is the unique identifier for a device driver
> instead.
> 
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
>  drivers/vfio/platform/vfio_platform_common.c  | 69 +++++++++++++++++++++++++--
>  drivers/vfio/platform/vfio_platform_private.h |  1 +
>  2 files changed, 65 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
> index 6be92c3..a5299f6 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -13,6 +13,7 @@
>   */
>  
>  #include <linux/device.h>
> +#include <linux/acpi.h>
>  #include <linux/iommu.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> @@ -49,6 +50,32 @@ static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char *compat,
>  	return reset_fn;
>  }
>  
> +static int vfio_platform_acpi_probe(struct vfio_platform_device *vdev,
> +				    struct device *dev)
> +{
> +	struct acpi_device *adev;
> +
> +	if (acpi_disabled)
> +		return -EPERM;
> +
> +	adev = ACPI_COMPANION(dev);

I didn't necessarily have a problem with this being set in the
declaration.

> +	if (!adev) {
> +		pr_err("VFIO: ACPI companion device not found for %s\n",
> +			vdev->name);
> +		return -ENODEV;
> +	}
> +
> +#ifdef CONFIG_ACPI
> +	vdev->acpihid = acpi_device_hid(adev);
> +	if (!vdev->acpihid) {
> +		pr_err("VFIO: cannot find ACPI HID for %s\n",
> +		       vdev->name);
> +		return -EINVAL;
> +	}
> +#endif
> +	return WARN_ON(!vdev->acpihid) ? -ENOENT : 0;

?!?!  The point was that that entire if{} branch is unnecessary.  The
WARN_ON handles the (impossible) case of !vdev->acpihid.  We just need:

#ifdef CONFIG_ACPI
	vdev->acpihid = acpi_device_hid(adev);
#endif
	return WARN_ON(!vdev->acpihid) ? -ENOENT : 0;

nit, might make sense to replace EPERM with ENOENT and use EINVAL here.

> +}
> +
>  static bool vfio_platform_has_reset(struct vfio_platform_device *vdev)
>  {
>  	return vdev->of_reset ? true : false;
> @@ -547,6 +574,37 @@ static const struct vfio_device_ops vfio_platform_ops = {
>  	.mmap		= vfio_platform_mmap,
>  };
>  
> +int vfio_platform_of_probe(struct vfio_platform_device *vdev,
> +			   struct device *dev)
> +{
> +	int ret;
> +
> +	ret = device_property_read_string(dev, "compatible",
> +					  &vdev->compat);
> +	if (ret)
> +		pr_err("VFIO: cannot retrieve compat for %s\n",
> +			vdev->name);
> +
> +	return ret;
> +}
> +
> +/*
> + * There can be two kernel build combinations. One build where
> + * ACPI is not selected in Kconfig and another one with the ACPI Kconfig.
> + *
> + * In the first case, vfio_platform_acpi_probe will return since
> + * acpi_disabled is 1. DT user will not see any kind of messages from
> + * ACPI.
> + *
> + * In the second case, both DT and ACPI is compiled in but the system is
> + * booting with any of these combinations.
> + *
> + * If the firmware is DT type, then acpi_disabled is 1. The ACPI probe routine
> + * terminates immediately without any messages.
> + *
> + * If the firmware is ACPI type, then acpi_disabled is 0. All other checks are
> + * valid checks. We cannot claim that this system is DT.
> + */
>  int vfio_platform_probe_common(struct vfio_platform_device *vdev,
>  			       struct device *dev)
>  {
> @@ -556,11 +614,12 @@ int vfio_platform_probe_common(struct vfio_platform_device *vdev,
>  	if (!vdev)
>  		return -EINVAL;
>  
> -	ret = device_property_read_string(dev, "compatible", &vdev->compat);
> -	if (ret) {
> -		pr_err("VFIO: cannot retrieve compat for %s\n", vdev->name);
> -		return -EINVAL;
> -	}
> +	ret = vfio_platform_acpi_probe(vdev, dev);
> +	if (ret)
> +		ret = vfio_platform_of_probe(vdev, dev);
> +
> +	if (ret)
> +		return ret;
>  
>  	vdev->device = dev;
>  
> diff --git a/drivers/vfio/platform/vfio_platform_private.h b/drivers/vfio/platform/vfio_platform_private.h
> index 71ed7d1..ba9e4f8 100644
> --- a/drivers/vfio/platform/vfio_platform_private.h
> +++ b/drivers/vfio/platform/vfio_platform_private.h
> @@ -58,6 +58,7 @@ struct vfio_platform_device {
>  	struct mutex			igate;
>  	struct module			*parent_module;
>  	const char			*compat;
> +	const char			*acpihid;
>  	struct module			*reset_module;
>  	struct device			*device;
>  

WARNING: multiple messages have this Message-ID (diff)
From: alex.williamson@redhat.com (Alex Williamson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V10 4/9] vfio: platform: add support for ACPI probe
Date: Mon, 18 Jul 2016 18:00:49 -0600	[thread overview]
Message-ID: <20160718180049.78db3dfb@t450s.home> (raw)
In-Reply-To: <1468883367-2854-5-git-send-email-okaya@codeaurora.org>

On Mon, 18 Jul 2016 19:09:22 -0400
Sinan Kaya <okaya@codeaurora.org> wrote:

> The code is using the compatible DT string to associate a reset driver
> with the actual device itself. The compatible string does not exist on
> ACPI based systems. HID is the unique identifier for a device driver
> instead.
> 
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
>  drivers/vfio/platform/vfio_platform_common.c  | 69 +++++++++++++++++++++++++--
>  drivers/vfio/platform/vfio_platform_private.h |  1 +
>  2 files changed, 65 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
> index 6be92c3..a5299f6 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -13,6 +13,7 @@
>   */
>  
>  #include <linux/device.h>
> +#include <linux/acpi.h>
>  #include <linux/iommu.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> @@ -49,6 +50,32 @@ static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char *compat,
>  	return reset_fn;
>  }
>  
> +static int vfio_platform_acpi_probe(struct vfio_platform_device *vdev,
> +				    struct device *dev)
> +{
> +	struct acpi_device *adev;
> +
> +	if (acpi_disabled)
> +		return -EPERM;
> +
> +	adev = ACPI_COMPANION(dev);

I didn't necessarily have a problem with this being set in the
declaration.

> +	if (!adev) {
> +		pr_err("VFIO: ACPI companion device not found for %s\n",
> +			vdev->name);
> +		return -ENODEV;
> +	}
> +
> +#ifdef CONFIG_ACPI
> +	vdev->acpihid = acpi_device_hid(adev);
> +	if (!vdev->acpihid) {
> +		pr_err("VFIO: cannot find ACPI HID for %s\n",
> +		       vdev->name);
> +		return -EINVAL;
> +	}
> +#endif
> +	return WARN_ON(!vdev->acpihid) ? -ENOENT : 0;

?!?!  The point was that that entire if{} branch is unnecessary.  The
WARN_ON handles the (impossible) case of !vdev->acpihid.  We just need:

#ifdef CONFIG_ACPI
	vdev->acpihid = acpi_device_hid(adev);
#endif
	return WARN_ON(!vdev->acpihid) ? -ENOENT : 0;

nit, might make sense to replace EPERM with ENOENT and use EINVAL here.

> +}
> +
>  static bool vfio_platform_has_reset(struct vfio_platform_device *vdev)
>  {
>  	return vdev->of_reset ? true : false;
> @@ -547,6 +574,37 @@ static const struct vfio_device_ops vfio_platform_ops = {
>  	.mmap		= vfio_platform_mmap,
>  };
>  
> +int vfio_platform_of_probe(struct vfio_platform_device *vdev,
> +			   struct device *dev)
> +{
> +	int ret;
> +
> +	ret = device_property_read_string(dev, "compatible",
> +					  &vdev->compat);
> +	if (ret)
> +		pr_err("VFIO: cannot retrieve compat for %s\n",
> +			vdev->name);
> +
> +	return ret;
> +}
> +
> +/*
> + * There can be two kernel build combinations. One build where
> + * ACPI is not selected in Kconfig and another one with the ACPI Kconfig.
> + *
> + * In the first case, vfio_platform_acpi_probe will return since
> + * acpi_disabled is 1. DT user will not see any kind of messages from
> + * ACPI.
> + *
> + * In the second case, both DT and ACPI is compiled in but the system is
> + * booting with any of these combinations.
> + *
> + * If the firmware is DT type, then acpi_disabled is 1. The ACPI probe routine
> + * terminates immediately without any messages.
> + *
> + * If the firmware is ACPI type, then acpi_disabled is 0. All other checks are
> + * valid checks. We cannot claim that this system is DT.
> + */
>  int vfio_platform_probe_common(struct vfio_platform_device *vdev,
>  			       struct device *dev)
>  {
> @@ -556,11 +614,12 @@ int vfio_platform_probe_common(struct vfio_platform_device *vdev,
>  	if (!vdev)
>  		return -EINVAL;
>  
> -	ret = device_property_read_string(dev, "compatible", &vdev->compat);
> -	if (ret) {
> -		pr_err("VFIO: cannot retrieve compat for %s\n", vdev->name);
> -		return -EINVAL;
> -	}
> +	ret = vfio_platform_acpi_probe(vdev, dev);
> +	if (ret)
> +		ret = vfio_platform_of_probe(vdev, dev);
> +
> +	if (ret)
> +		return ret;
>  
>  	vdev->device = dev;
>  
> diff --git a/drivers/vfio/platform/vfio_platform_private.h b/drivers/vfio/platform/vfio_platform_private.h
> index 71ed7d1..ba9e4f8 100644
> --- a/drivers/vfio/platform/vfio_platform_private.h
> +++ b/drivers/vfio/platform/vfio_platform_private.h
> @@ -58,6 +58,7 @@ struct vfio_platform_device {
>  	struct mutex			igate;
>  	struct module			*parent_module;
>  	const char			*compat;
> +	const char			*acpihid;
>  	struct module			*reset_module;
>  	struct device			*device;
>  

  reply	other threads:[~2016-07-19  0:00 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-18 23:09 [PATCH V10 0/9] vfio, platform: add ACPI support Sinan Kaya
2016-07-18 23:09 ` Sinan Kaya
2016-07-18 23:09 ` [PATCH V10 1/9] vfio: platform: rename reset function Sinan Kaya
2016-07-18 23:09   ` Sinan Kaya
2016-07-18 23:09 ` [PATCH V10 2/9] vfio: platform: move reset call to a common function Sinan Kaya
2016-07-18 23:09   ` Sinan Kaya
2016-07-18 23:09 ` [PATCH V10 3/9] vfio: platform: determine reset capability Sinan Kaya
2016-07-18 23:09   ` Sinan Kaya
2016-07-18 23:09 ` [PATCH V10 4/9] vfio: platform: add support for ACPI probe Sinan Kaya
2016-07-18 23:09   ` Sinan Kaya
2016-07-19  0:00   ` Alex Williamson [this message]
2016-07-19  0:00     ` Alex Williamson
2016-07-19  0:16     ` okaya
2016-07-19  0:16       ` okaya at codeaurora.org
2016-07-19  0:24       ` Alex Williamson
2016-07-19  0:24         ` Alex Williamson
2016-07-19 14:49         ` Sinan Kaya
2016-07-19 14:49           ` Sinan Kaya
2016-07-19 15:28           ` Alex Williamson
2016-07-19 15:28             ` Alex Williamson
2016-07-19 15:29             ` Sinan Kaya
2016-07-19 15:29               ` Sinan Kaya
2016-07-18 23:09 ` [PATCH V10 5/9] vfio: platform: add extra debug info argument to call reset Sinan Kaya
2016-07-18 23:09   ` Sinan Kaya
2016-07-18 23:09 ` [PATCH V10 6/9] vfio: platform: call _RST method when using ACPI Sinan Kaya
2016-07-18 23:09   ` Sinan Kaya
2016-07-18 23:09 ` [PATCH V10 7/9] vfio, platform: make reset driver a requirement by default Sinan Kaya
2016-07-18 23:09   ` Sinan Kaya
2016-07-18 23:09   ` Sinan Kaya
2016-07-18 23:09 ` [PATCH V10 8/9] vfio: platform: check reset call return code during open Sinan Kaya
2016-07-18 23:09   ` Sinan Kaya
2016-07-18 23:09   ` Sinan Kaya
2016-07-18 23:09 ` [PATCH V10 9/9] vfio: platform: check reset call return code during release Sinan Kaya
2016-07-18 23:09   ` Sinan Kaya

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=20160718180049.78db3dfb@t450s.home \
    --to=alex.williamson@redhat.com \
    --cc=agross@codeaurora.org \
    --cc=b.reynal@virtualopensystems.com \
    --cc=cov@codeaurora.org \
    --cc=eric.auger@redhat.com \
    --cc=jcm@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=okaya@codeaurora.org \
    --cc=timur@codeaurora.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.