[PATCH v1 0/7] ACPI: Use ACPI_COMPANION() directly to simplify code

[PATCH v1 0/7] ACPI: Use ACPI_COMPANION() directly to simplify code

[Rafael J. Wysocki]

Hi All,

The patches in this series are all independent, but they make
analogous changes, which are to replace the combination of
ACPI_HANDLE() and acpi_bus_get_device() with ACPI_COMPANION()
that gets the same result in a much simpler way.

Thanks!

[PATCH v1 1/7] gpio-amdpt: ACPI: Use the ACPI_COMPANION() macro directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael@kernel.org>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify pt_gpio_probe() accordingly (no intentional functional impact).

Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
---
 drivers/gpio/gpio-amdpt.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

Index: linux-pm/drivers/gpio/gpio-amdpt.c
===================================================================
--- linux-pm.orig/drivers/gpio/gpio-amdpt.c
+++ linux-pm/drivers/gpio/gpio-amdpt.c
@@ -72,12 +72,10 @@ static void pt_gpio_free(struct gpio_chi
 static int pt_gpio_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
-	struct acpi_device *acpi_dev;
-	acpi_handle handle = ACPI_HANDLE(dev);
 	struct pt_gpio_chip *pt_gpio;
 	int ret = 0;
 
-	if (acpi_bus_get_device(handle, &acpi_dev)) {
+	if (!ACPI_COMPANION(dev)) {
 		dev_err(dev, "PT GPIO device node not found\n");
 		return -ENODEV;
 	}

Re: [PATCH v1 1/7] gpio-amdpt: ACPI: Use the ACPI_COMPANION() macro directly

[Bartosz Golaszewski]

On Tue, Oct 12, 2021 at 7:51 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> From: Rafael J. Wysocki <rafael@kernel.org>
>
> The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
> macro and the ACPI handle produced by the former comes from the
> ACPI device object produced by the latter, so it is way more
> straightforward to evaluate the latter directly instead of passing
> the handle produced by the former to acpi_bus_get_device().
>
> Modify pt_gpio_probe() accordingly (no intentional functional impact).
>
> Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
> ---
>  drivers/gpio/gpio-amdpt.c |    4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> Index: linux-pm/drivers/gpio/gpio-amdpt.c
> ===================================================================
> --- linux-pm.orig/drivers/gpio/gpio-amdpt.c
> +++ linux-pm/drivers/gpio/gpio-amdpt.c
> @@ -72,12 +72,10 @@ static void pt_gpio_free(struct gpio_chi
>  static int pt_gpio_probe(struct platform_device *pdev)
>  {
>         struct device *dev = &pdev->dev;
> -       struct acpi_device *acpi_dev;
> -       acpi_handle handle = ACPI_HANDLE(dev);
>         struct pt_gpio_chip *pt_gpio;
>         int ret = 0;
>
> -       if (acpi_bus_get_device(handle, &acpi_dev)) {
> +       if (!ACPI_COMPANION(dev)) {
>                 dev_err(dev, "PT GPIO device node not found\n");
>                 return -ENODEV;
>         }
>
>
>

Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>

[PATCH v2 1/7] gpio-amdpt: ACPI: Use the ACPI_COMPANION() macro directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify pt_gpio_probe() accordingly (no intentional functional impact).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>
---

v1 -> v2:
   * Resend with a different From and S-o-b address and with ACK from Bart.
     No other changes.

---
 drivers/gpio/gpio-amdpt.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

Index: linux-pm/drivers/gpio/gpio-amdpt.c
===================================================================
--- linux-pm.orig/drivers/gpio/gpio-amdpt.c
+++ linux-pm/drivers/gpio/gpio-amdpt.c
@@ -72,12 +72,10 @@ static void pt_gpio_free(struct gpio_chi
 static int pt_gpio_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
-	struct acpi_device *acpi_dev;
-	acpi_handle handle = ACPI_HANDLE(dev);
 	struct pt_gpio_chip *pt_gpio;
 	int ret = 0;
 
-	if (acpi_bus_get_device(handle, &acpi_dev)) {
+	if (!ACPI_COMPANION(dev)) {
 		dev_err(dev, "PT GPIO device node not found\n");
 		return -ENODEV;
 	}

[PATCH v1 2/7] nouveau: ACPI: Use the ACPI_COMPANION() macro directly

From: Rafael J. Wysocki <rafael@kernel.org>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify nouveau_acpi_edid() accordingly (no intentional functional
impact).

Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
---
 drivers/gpu/drm/nouveau/nouveau_acpi.c |    9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

Index: linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
===================================================================
--- linux-pm.orig/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -364,7 +364,6 @@ void *
 nouveau_acpi_edid(struct drm_device *dev, struct drm_connector *connector)
 {
 	struct acpi_device *acpidev;
-	acpi_handle handle;
 	int type, ret;
 	void *edid;
 
@@ -377,12 +376,8 @@ nouveau_acpi_edid(struct drm_device *dev
 		return NULL;
 	}
 
-	handle = ACPI_HANDLE(dev->dev);
-	if (!handle)
-		return NULL;
-
-	ret = acpi_bus_get_device(handle, &acpidev);
-	if (ret)
+	acpidev = ACPI_COMPANION(dev->dev);
+	if (!acpidev)
 		return NULL;
 
 	ret = acpi_video_get_edid(acpidev, type, -1, &edid);

[Nouveau] [PATCH v1 2/7] nouveau: ACPI: Use the ACPI_COMPANION() macro directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael@kernel.org>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify nouveau_acpi_edid() accordingly (no intentional functional
impact).

Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
---
 drivers/gpu/drm/nouveau/nouveau_acpi.c |    9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

Index: linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
===================================================================
--- linux-pm.orig/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -364,7 +364,6 @@ void *
 nouveau_acpi_edid(struct drm_device *dev, struct drm_connector *connector)
 {
 	struct acpi_device *acpidev;
-	acpi_handle handle;
 	int type, ret;
 	void *edid;
 
@@ -377,12 +376,8 @@ nouveau_acpi_edid(struct drm_device *dev
 		return NULL;
 	}
 
-	handle = ACPI_HANDLE(dev->dev);
-	if (!handle)
-		return NULL;
-
-	ret = acpi_bus_get_device(handle, &acpidev);
-	if (ret)
+	acpidev = ACPI_COMPANION(dev->dev);
+	if (!acpidev)
 		return NULL;
 
 	ret = acpi_video_get_edid(acpidev, type, -1, &edid);

Re: [PATCH v1 2/7] nouveau: ACPI: Use the ACPI_COMPANION() macro directly

[Ben Skeggs]

On Wed, 13 Oct 2021 at 03:58, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> From: Rafael J. Wysocki <rafael@kernel.org>
>
> The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
> macro and the ACPI handle produced by the former comes from the
> ACPI device object produced by the latter, so it is way more
> straightforward to evaluate the latter directly instead of passing
> the handle produced by the former to acpi_bus_get_device().
>
> Modify nouveau_acpi_edid() accordingly (no intentional functional
> impact).
>
> Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>

> ---
>  drivers/gpu/drm/nouveau/nouveau_acpi.c |    9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)
>
> Index: linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
> ===================================================================
> --- linux-pm.orig/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -364,7 +364,6 @@ void *
>  nouveau_acpi_edid(struct drm_device *dev, struct drm_connector *connector)
>  {
>         struct acpi_device *acpidev;
> -       acpi_handle handle;
>         int type, ret;
>         void *edid;
>
> @@ -377,12 +376,8 @@ nouveau_acpi_edid(struct drm_device *dev
>                 return NULL;
>         }
>
> -       handle = ACPI_HANDLE(dev->dev);
> -       if (!handle)
> -               return NULL;
> -
> -       ret = acpi_bus_get_device(handle, &acpidev);
> -       if (ret)
> +       acpidev = ACPI_COMPANION(dev->dev);
> +       if (!acpidev)
>                 return NULL;
>
>         ret = acpi_video_get_edid(acpidev, type, -1, &edid);
>
>
>

Re: [Nouveau] [PATCH v1 2/7] nouveau: ACPI: Use the ACPI_COMPANION() macro directly

[Ben Skeggs]

On Wed, 13 Oct 2021 at 03:58, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> From: Rafael J. Wysocki <rafael@kernel.org>
>
> The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
> macro and the ACPI handle produced by the former comes from the
> ACPI device object produced by the latter, so it is way more
> straightforward to evaluate the latter directly instead of passing
> the handle produced by the former to acpi_bus_get_device().
>
> Modify nouveau_acpi_edid() accordingly (no intentional functional
> impact).
>
> Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>

> ---
>  drivers/gpu/drm/nouveau/nouveau_acpi.c |    9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)
>
> Index: linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
> ===================================================================
> --- linux-pm.orig/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -364,7 +364,6 @@ void *
>  nouveau_acpi_edid(struct drm_device *dev, struct drm_connector *connector)
>  {
>         struct acpi_device *acpidev;
> -       acpi_handle handle;
>         int type, ret;
>         void *edid;
>
> @@ -377,12 +376,8 @@ nouveau_acpi_edid(struct drm_device *dev
>                 return NULL;
>         }
>
> -       handle = ACPI_HANDLE(dev->dev);
> -       if (!handle)
> -               return NULL;
> -
> -       ret = acpi_bus_get_device(handle, &acpidev);
> -       if (ret)
> +       acpidev = ACPI_COMPANION(dev->dev);
> +       if (!acpidev)
>                 return NULL;
>
>         ret = acpi_video_get_edid(acpidev, type, -1, &edid);
>
>
>

[PATCH v2 2/7] nouveau: ACPI: Use the ACPI_COMPANION() macro directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify nouveau_acpi_edid() accordingly (no intentional functional
impact).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
---

v1 -> v2:
   * Resend with a different From and S-o-b address and with R-by from Ben.
     No other changes.

---
 drivers/gpu/drm/nouveau/nouveau_acpi.c |    9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

Index: linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
===================================================================
--- linux-pm.orig/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -364,7 +364,6 @@ void *
 nouveau_acpi_edid(struct drm_device *dev, struct drm_connector *connector)
 {
 	struct acpi_device *acpidev;
-	acpi_handle handle;
 	int type, ret;
 	void *edid;
 
@@ -377,12 +376,8 @@ nouveau_acpi_edid(struct drm_device *dev
 		return NULL;
 	}
 
-	handle = ACPI_HANDLE(dev->dev);
-	if (!handle)
-		return NULL;
-
-	ret = acpi_bus_get_device(handle, &acpidev);
-	if (ret)
+	acpidev = ACPI_COMPANION(dev->dev);
+	if (!acpidev)
 		return NULL;
 
 	ret = acpi_video_get_edid(acpidev, type, -1, &edid);

[Nouveau] [PATCH v2 2/7] nouveau: ACPI: Use the ACPI_COMPANION() macro directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify nouveau_acpi_edid() accordingly (no intentional functional
impact).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
---

v1 -> v2:
   * Resend with a different From and S-o-b address and with R-by from Ben.
     No other changes.

---
 drivers/gpu/drm/nouveau/nouveau_acpi.c |    9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

Index: linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
===================================================================
--- linux-pm.orig/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -364,7 +364,6 @@ void *
 nouveau_acpi_edid(struct drm_device *dev, struct drm_connector *connector)
 {
 	struct acpi_device *acpidev;
-	acpi_handle handle;
 	int type, ret;
 	void *edid;
 
@@ -377,12 +376,8 @@ nouveau_acpi_edid(struct drm_device *dev
 		return NULL;
 	}
 
-	handle = ACPI_HANDLE(dev->dev);
-	if (!handle)
-		return NULL;
-
-	ret = acpi_bus_get_device(handle, &acpidev);
-	if (ret)
+	acpidev = ACPI_COMPANION(dev->dev);
+	if (!acpidev)
 		return NULL;
 
 	ret = acpi_video_get_edid(acpidev, type, -1, &edid);

[PATCH v1 3/7] i2c: i2c-amd-mp2-plat: ACPI: Use ACPI_COMPANION() directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael@kernel.org>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify i2c_amd_probe() accordingly (no intentional functional impact).

Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
---
 drivers/i2c/busses/i2c-amd-mp2-plat.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

Index: linux-pm/drivers/i2c/busses/i2c-amd-mp2-plat.c
===================================================================
--- linux-pm.orig/drivers/i2c/busses/i2c-amd-mp2-plat.c
+++ linux-pm/drivers/i2c/busses/i2c-amd-mp2-plat.c
@@ -246,12 +246,11 @@ static int i2c_amd_probe(struct platform
 {
 	int ret;
 	struct amd_i2c_dev *i2c_dev;
-	acpi_handle handle = ACPI_HANDLE(&pdev->dev);
-	struct acpi_device *adev;
+	struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
 	struct amd_mp2_dev *mp2_dev;
 	const char *uid;
 
-	if (acpi_bus_get_device(handle, &adev))
+	if (!adev)
 		return -ENODEV;
 
 	/* The ACPI namespace doesn't contain information about which MP2 PCI

Re: [PATCH v1 3/7] i2c: i2c-amd-mp2-plat: ACPI: Use ACPI_COMPANION() directly

[Shyam Sundar S K]

On 10/12/2021 11:14 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael@kernel.org>
> 
> The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
> macro and the ACPI handle produced by the former comes from the
> ACPI device object produced by the latter, so it is way more
> straightforward to evaluate the latter directly instead of passing
> the handle produced by the former to acpi_bus_get_device().
> 
> Modify i2c_amd_probe() accordingly (no intentional functional impact).
> 
> Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>

Looks good to me.

Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>

> ---
>  drivers/i2c/busses/i2c-amd-mp2-plat.c |    5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> Index: linux-pm/drivers/i2c/busses/i2c-amd-mp2-plat.c
> ===================================================================
> --- linux-pm.orig/drivers/i2c/busses/i2c-amd-mp2-plat.c
> +++ linux-pm/drivers/i2c/busses/i2c-amd-mp2-plat.c
> @@ -246,12 +246,11 @@ static int i2c_amd_probe(struct platform
>  {
>  	int ret;
>  	struct amd_i2c_dev *i2c_dev;
> -	acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> -	struct acpi_device *adev;
> +	struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
>  	struct amd_mp2_dev *mp2_dev;
>  	const char *uid;
>  
> -	if (acpi_bus_get_device(handle, &adev))
> +	if (!adev)
>  		return -ENODEV;
>  
>  	/* The ACPI namespace doesn't contain information about which MP2 PCI
> 
> 
> 

[PATCH v2 3/7] i2c: i2c-amd-mp2-plat: ACPI: Use ACPI_COMPANION() directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify i2c_amd_probe() accordingly (no intentional functional impact).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
---

v1 -> v2:
   * Resend with a different From and S-o-b address and with maintainer ACK.
     No other changes.

---
 drivers/i2c/busses/i2c-amd-mp2-plat.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

Index: linux-pm/drivers/i2c/busses/i2c-amd-mp2-plat.c
===================================================================
--- linux-pm.orig/drivers/i2c/busses/i2c-amd-mp2-plat.c
+++ linux-pm/drivers/i2c/busses/i2c-amd-mp2-plat.c
@@ -246,12 +246,11 @@ static int i2c_amd_probe(struct platform
 {
 	int ret;
 	struct amd_i2c_dev *i2c_dev;
-	acpi_handle handle = ACPI_HANDLE(&pdev->dev);
-	struct acpi_device *adev;
+	struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
 	struct amd_mp2_dev *mp2_dev;
 	const char *uid;
 
-	if (acpi_bus_get_device(handle, &adev))
+	if (!adev)
 		return -ENODEV;
 
 	/* The ACPI namespace doesn't contain information about which MP2 PCI

Re: [PATCH v2 3/7] i2c: i2c-amd-mp2-plat: ACPI: Use ACPI_COMPANION() directly

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

On Wed, Oct 13, 2021 at 06:09:39PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
> macro and the ACPI handle produced by the former comes from the
> ACPI device object produced by the latter, so it is way more
> straightforward to evaluate the latter directly instead of passing
> the handle produced by the former to acpi_bus_get_device().
> 
> Modify i2c_amd_probe() accordingly (no intentional functional impact).
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>

Applied to for-next, thanks!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v1 4/7] surface: surface3-wmi: Use ACPI_COMPANION() directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael@kernel.org>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify s3_wmi_check_platform_device() accordingly (no intentional
functional impact).

Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
---
 drivers/platform/surface/surface3-wmi.c |    9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/platform/surface/surface3-wmi.c
===================================================================
--- linux-pm.orig/drivers/platform/surface/surface3-wmi.c
+++ linux-pm/drivers/platform/surface/surface3-wmi.c
@@ -139,13 +139,12 @@ static acpi_status s3_wmi_attach_spi_dev
 
 static int s3_wmi_check_platform_device(struct device *dev, void *data)
 {
-	struct acpi_device *adev, *ts_adev = NULL;
-	acpi_handle handle;
+	struct acpi_device *adev = ACPI_COMPANION(dev);
+	struct acpi_device *ts_adev = NULL;
 	acpi_status status;
 
 	/* ignore non ACPI devices */
-	handle = ACPI_HANDLE(dev);
-	if (!handle || acpi_bus_get_device(handle, &adev))
+	if (!adev)
 		return 0;
 
 	/* check for LID ACPI switch */
@@ -159,7 +158,7 @@ static int s3_wmi_check_platform_device(
 	    strlen(SPI_CTL_OBJ_NAME)))
 		return 0;
 
-	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
+	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, adev->handle, 1,
 				     s3_wmi_attach_spi_device, NULL,
 				     &ts_adev, NULL);
 	if (ACPI_FAILURE(status))

Re: [PATCH v1 4/7] surface: surface3-wmi: Use ACPI_COMPANION() directly

[Maximilian Luz]

On 10/12/21 19:44, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael@kernel.org>
> 
> The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
> macro and the ACPI handle produced by the former comes from the
> ACPI device object produced by the latter, so it is way more
> straightforward to evaluate the latter directly instead of passing
> the handle produced by the former to acpi_bus_get_device().
> 
> Modify s3_wmi_check_platform_device() accordingly (no intentional
> functional impact).
> 
> Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>

Looks good to me.

Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>

> ---
>   drivers/platform/surface/surface3-wmi.c |    9 ++++-----
>   1 file changed, 4 insertions(+), 5 deletions(-)
> 
> Index: linux-pm/drivers/platform/surface/surface3-wmi.c
> ===================================================================
> --- linux-pm.orig/drivers/platform/surface/surface3-wmi.c
> +++ linux-pm/drivers/platform/surface/surface3-wmi.c
> @@ -139,13 +139,12 @@ static acpi_status s3_wmi_attach_spi_dev
>   
>   static int s3_wmi_check_platform_device(struct device *dev, void *data)
>   {
> -	struct acpi_device *adev, *ts_adev = NULL;
> -	acpi_handle handle;
> +	struct acpi_device *adev = ACPI_COMPANION(dev);
> +	struct acpi_device *ts_adev = NULL;
>   	acpi_status status;
>   
>   	/* ignore non ACPI devices */
> -	handle = ACPI_HANDLE(dev);
> -	if (!handle || acpi_bus_get_device(handle, &adev))
> +	if (!adev)
>   		return 0;
>   
>   	/* check for LID ACPI switch */
> @@ -159,7 +158,7 @@ static int s3_wmi_check_platform_device(
>   	    strlen(SPI_CTL_OBJ_NAME)))
>   		return 0;
>   
> -	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
> +	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, adev->handle, 1,
>   				     s3_wmi_attach_spi_device, NULL,
>   				     &ts_adev, NULL);
>   	if (ACPI_FAILURE(status))
> 
> 
> 

[PATCH v2 4/7] surface: surface3-wmi: Use ACPI_COMPANION() directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify s3_wmi_check_platform_device() accordingly (no intentional
functional impact).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
---

v1 -> v2:
   * Resend with a different From and S-o-b address and with R-by from
     Maximilian.  No other changes.

---
 drivers/platform/surface/surface3-wmi.c |    9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/platform/surface/surface3-wmi.c
===================================================================
--- linux-pm.orig/drivers/platform/surface/surface3-wmi.c
+++ linux-pm/drivers/platform/surface/surface3-wmi.c
@@ -139,13 +139,12 @@ static acpi_status s3_wmi_attach_spi_dev
 
 static int s3_wmi_check_platform_device(struct device *dev, void *data)
 {
-	struct acpi_device *adev, *ts_adev = NULL;
-	acpi_handle handle;
+	struct acpi_device *adev = ACPI_COMPANION(dev);
+	struct acpi_device *ts_adev = NULL;
 	acpi_status status;
 
 	/* ignore non ACPI devices */
-	handle = ACPI_HANDLE(dev);
-	if (!handle || acpi_bus_get_device(handle, &adev))
+	if (!adev)
 		return 0;
 
 	/* check for LID ACPI switch */
@@ -159,7 +158,7 @@ static int s3_wmi_check_platform_device(
 	    strlen(SPI_CTL_OBJ_NAME)))
 		return 0;
 
-	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
+	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, adev->handle, 1,
 				     s3_wmi_attach_spi_device, NULL,
 				     &ts_adev, NULL);
 	if (ACPI_FAILURE(status))

Re: [PATCH v2 4/7] surface: surface3-wmi: Use ACPI_COMPANION() directly

[Hans de Goede]

Hi,

On 10/13/21 18:10, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
> macro and the ACPI handle produced by the former comes from the
> ACPI device object produced by the latter, so it is way more
> straightforward to evaluate the latter directly instead of passing
> the handle produced by the former to acpi_bus_get_device().
> 
> Modify s3_wmi_check_platform_device() accordingly (no intentional
> functional impact).
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans


> ---
> 
> v1 -> v2:
>    * Resend with a different From and S-o-b address and with R-by from
>      Maximilian.  No other changes.
> 
> ---
>  drivers/platform/surface/surface3-wmi.c |    9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> Index: linux-pm/drivers/platform/surface/surface3-wmi.c
> ===================================================================
> --- linux-pm.orig/drivers/platform/surface/surface3-wmi.c
> +++ linux-pm/drivers/platform/surface/surface3-wmi.c
> @@ -139,13 +139,12 @@ static acpi_status s3_wmi_attach_spi_dev
>  
>  static int s3_wmi_check_platform_device(struct device *dev, void *data)
>  {
> -	struct acpi_device *adev, *ts_adev = NULL;
> -	acpi_handle handle;
> +	struct acpi_device *adev = ACPI_COMPANION(dev);
> +	struct acpi_device *ts_adev = NULL;
>  	acpi_status status;
>  
>  	/* ignore non ACPI devices */
> -	handle = ACPI_HANDLE(dev);
> -	if (!handle || acpi_bus_get_device(handle, &adev))
> +	if (!adev)
>  		return 0;
>  
>  	/* check for LID ACPI switch */
> @@ -159,7 +158,7 @@ static int s3_wmi_check_platform_device(
>  	    strlen(SPI_CTL_OBJ_NAME)))
>  		return 0;
>  
> -	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
> +	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, adev->handle, 1,
>  				     s3_wmi_attach_spi_device, NULL,
>  				     &ts_adev, NULL);
>  	if (ACPI_FAILURE(status))
> 
> 
> 

[PATCH v1 5/7] surface: surface3_power: Use ACPI_COMPANION() directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael@kernel.org>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify mshw0011_notify() accordingly (no intentional functional
impact).

Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
---
 drivers/platform/surface/surface3_power.c |    9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/platform/surface/surface3_power.c
===================================================================
--- linux-pm.orig/drivers/platform/surface/surface3_power.c
+++ linux-pm/drivers/platform/surface/surface3_power.c
@@ -160,15 +160,14 @@ mshw0011_notify(struct mshw0011_data *cd
 {
 	union acpi_object *obj;
 	struct acpi_device *adev;
-	acpi_handle handle;
 	unsigned int i;
 
-	handle = ACPI_HANDLE(&cdata->adp1->dev);
-	if (!handle || acpi_bus_get_device(handle, &adev))
+	adev = ACPI_COMPANION(&cdata->adp1->dev);
+	if (!adev)
 		return -ENODEV;
 
-	obj = acpi_evaluate_dsm_typed(handle, &mshw0011_guid, arg1, arg2, NULL,
-				      ACPI_TYPE_BUFFER);
+	obj = acpi_evaluate_dsm_typed(adev->handle, &mshw0011_guid, arg1, arg2,
+				      NULL, ACPI_TYPE_BUFFER);
 	if (!obj) {
 		dev_err(&cdata->adp1->dev, "device _DSM execution failed\n");
 		return -ENODEV;

Re: [PATCH v1 5/7] surface: surface3_power: Use ACPI_COMPANION() directly

[Maximilian Luz]

On 10/12/21 19:46, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael@kernel.org>
> 
> The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
> macro and the ACPI handle produced by the former comes from the
> ACPI device object produced by the latter, so it is way more
> straightforward to evaluate the latter directly instead of passing
> the handle produced by the former to acpi_bus_get_device().
> 
> Modify mshw0011_notify() accordingly (no intentional functional
> impact).
> 
> Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>

Looks mostly good to me, small comment/question inline.

> ---
>   drivers/platform/surface/surface3_power.c |    9 ++++-----
>   1 file changed, 4 insertions(+), 5 deletions(-)
> 
> Index: linux-pm/drivers/platform/surface/surface3_power.c
> ===================================================================
> --- linux-pm.orig/drivers/platform/surface/surface3_power.c
> +++ linux-pm/drivers/platform/surface/surface3_power.c
> @@ -160,15 +160,14 @@ mshw0011_notify(struct mshw0011_data *cd
>   {
>   	union acpi_object *obj;
>   	struct acpi_device *adev;
> -	acpi_handle handle;
>   	unsigned int i;
>   
> -	handle = ACPI_HANDLE(&cdata->adp1->dev);
> -	if (!handle || acpi_bus_get_device(handle, &adev))
> +	adev = ACPI_COMPANION(&cdata->adp1->dev);
> +	if (!adev)
>   		return -ENODEV;

Do we need to get the ACPI device (adev) here? To me it looks like only
its handle is actually used so why not keep ACPI_HANDLE() and remove the
acpi_bus_get_device() call instead?

>   
> -	obj = acpi_evaluate_dsm_typed(handle, &mshw0011_guid, arg1, arg2, NULL,
> -				      ACPI_TYPE_BUFFER);
> +	obj = acpi_evaluate_dsm_typed(adev->handle, &mshw0011_guid, arg1, arg2,
> +				      NULL, ACPI_TYPE_BUFFER);
>   	if (!obj) {
>   		dev_err(&cdata->adp1->dev, "device _DSM execution failed\n");
>   		return -ENODEV;
> 
> 
> 

Regards,
Max

Re: [PATCH v1 5/7] surface: surface3_power: Use ACPI_COMPANION() directly

[Rafael J. Wysocki]

On Tue, Oct 12, 2021 at 8:21 PM Maximilian Luz <luzmaximilian@gmail.com> wrote:
>
> On 10/12/21 19:46, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael@kernel.org>
> >
> > The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
> > macro and the ACPI handle produced by the former comes from the
> > ACPI device object produced by the latter, so it is way more
> > straightforward to evaluate the latter directly instead of passing
> > the handle produced by the former to acpi_bus_get_device().
> >
> > Modify mshw0011_notify() accordingly (no intentional functional
> > impact).
> >
> > Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
>
> Looks mostly good to me, small comment/question inline.
>
> > ---
> >   drivers/platform/surface/surface3_power.c |    9 ++++-----
> >   1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > Index: linux-pm/drivers/platform/surface/surface3_power.c
> > ===================================================================
> > --- linux-pm.orig/drivers/platform/surface/surface3_power.c
> > +++ linux-pm/drivers/platform/surface/surface3_power.c
> > @@ -160,15 +160,14 @@ mshw0011_notify(struct mshw0011_data *cd
> >   {
> >       union acpi_object *obj;
> >       struct acpi_device *adev;
> > -     acpi_handle handle;
> >       unsigned int i;
> >
> > -     handle = ACPI_HANDLE(&cdata->adp1->dev);
> > -     if (!handle || acpi_bus_get_device(handle, &adev))
> > +     adev = ACPI_COMPANION(&cdata->adp1->dev);
> > +     if (!adev)
> >               return -ENODEV;
>
> Do we need to get the ACPI device (adev) here? To me it looks like only
> its handle is actually used so why not keep ACPI_HANDLE() and remove the
> acpi_bus_get_device() call instead?

It actually doesn't really matter, but you're right,
acpi_bus_get_device() is simply redundant here, so ACPI_HANDLE() is
sufficient.

I'll send a v2 of this one.

> >
> > -     obj = acpi_evaluate_dsm_typed(handle, &mshw0011_guid, arg1, arg2, NULL,
> > -                                   ACPI_TYPE_BUFFER);
> > +     obj = acpi_evaluate_dsm_typed(adev->handle, &mshw0011_guid, arg1, arg2,
> > +                                   NULL, ACPI_TYPE_BUFFER);
> >       if (!obj) {
> >               dev_err(&cdata->adp1->dev, "device _DSM execution failed\n");
> >               return -ENODEV;
> >
> >
> >
>
> Regards,
> Max

[PATCH v2 5/7] surface: surface3_power: Drop redundant acpi_bus_get_device() call

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael@kernel.org>

If the ACPI companion of a given device is not present, the result
of the ACPI_HANDLE() evaluation for it will be NULL, so calling
acpi_bus_get_device() on ACPI_HANDLE() result in order to validate
it is redundant.

Drop the redundant acpi_bus_get_device() call from mshw0011_notify()
along with a local variable related to it.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
---

v1 -> v2:
   * Instead of switching over to using ACPI_COMPANION(), just drop the
     redundant acpi_bus_get_device() call from mshw0011_notify() and
     update the subject and changelog accordingly.

---
 drivers/platform/surface/surface3_power.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Index: linux-pm/drivers/platform/surface/surface3_power.c
===================================================================
--- linux-pm.orig/drivers/platform/surface/surface3_power.c
+++ linux-pm/drivers/platform/surface/surface3_power.c
@@ -159,12 +159,11 @@ mshw0011_notify(struct mshw0011_data *cd
 		unsigned int *ret_value)
 {
 	union acpi_object *obj;
-	struct acpi_device *adev;
 	acpi_handle handle;
 	unsigned int i;
 
 	handle = ACPI_HANDLE(&cdata->adp1->dev);
-	if (!handle || acpi_bus_get_device(handle, &adev))
+	if (!handle)
 		return -ENODEV;
 
 	obj = acpi_evaluate_dsm_typed(handle, &mshw0011_guid, arg1, arg2, NULL,

Re: [PATCH v2 5/7] surface: surface3_power: Drop redundant acpi_bus_get_device() call

[Maximilian Luz]

On 10/12/21 21:32, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael@kernel.org>
> 
> If the ACPI companion of a given device is not present, the result
> of the ACPI_HANDLE() evaluation for it will be NULL, so calling
> acpi_bus_get_device() on ACPI_HANDLE() result in order to validate
> it is redundant.
> 
> Drop the redundant acpi_bus_get_device() call from mshw0011_notify()
> along with a local variable related to it.
> 
> No intentional functional impact.
> 
> Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
> ---
> 
> v1 -> v2:
>     * Instead of switching over to using ACPI_COMPANION(), just drop the
>       redundant acpi_bus_get_device() call from mshw0011_notify() and
>       update the subject and changelog accordingly.
> 

Thanks, looks good to me!

Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>

> ---
>   drivers/platform/surface/surface3_power.c |    3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> Index: linux-pm/drivers/platform/surface/surface3_power.c
> ===================================================================
> --- linux-pm.orig/drivers/platform/surface/surface3_power.c
> +++ linux-pm/drivers/platform/surface/surface3_power.c
> @@ -159,12 +159,11 @@ mshw0011_notify(struct mshw0011_data *cd
>   		unsigned int *ret_value)
>   {
>   	union acpi_object *obj;
> -	struct acpi_device *adev;
>   	acpi_handle handle;
>   	unsigned int i;
>   
>   	handle = ACPI_HANDLE(&cdata->adp1->dev);
> -	if (!handle || acpi_bus_get_device(handle, &adev))
> +	if (!handle)
>   		return -ENODEV;
>   
>   	obj = acpi_evaluate_dsm_typed(handle, &mshw0011_guid, arg1, arg2, NULL,
> 
> 
> 

[PATCH v3 5/7] surface: surface3_power: Drop redundant acpi_bus_get_device() call

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

If the ACPI companion of a given device is not present, the result
of the ACPI_HANDLE() evaluation for it will be NULL, so calling
acpi_bus_get_device() on ACPI_HANDLE() result in order to validate
it is redundant.

Drop the redundant acpi_bus_get_device() call from mshw0011_notify()
along with a local variable related to it.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
---

v2 -> v3:
   * Resend with a different From and S-o-b address and with R-by from
     Maximilian.  No other changes.

---
 drivers/platform/surface/surface3_power.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Index: linux-pm/drivers/platform/surface/surface3_power.c
===================================================================
--- linux-pm.orig/drivers/platform/surface/surface3_power.c
+++ linux-pm/drivers/platform/surface/surface3_power.c
@@ -159,12 +159,11 @@ mshw0011_notify(struct mshw0011_data *cd
 		unsigned int *ret_value)
 {
 	union acpi_object *obj;
-	struct acpi_device *adev;
 	acpi_handle handle;
 	unsigned int i;
 
 	handle = ACPI_HANDLE(&cdata->adp1->dev);
-	if (!handle || acpi_bus_get_device(handle, &adev))
+	if (!handle)
 		return -ENODEV;
 
 	obj = acpi_evaluate_dsm_typed(handle, &mshw0011_guid, arg1, arg2, NULL,

Re: [PATCH v3 5/7] surface: surface3_power: Drop redundant acpi_bus_get_device() call

[Hans de Goede]

Hi,

On 10/13/21 18:12, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> If the ACPI companion of a given device is not present, the result
> of the ACPI_HANDLE() evaluation for it will be NULL, so calling
> acpi_bus_get_device() on ACPI_HANDLE() result in order to validate
> it is redundant.
> 
> Drop the redundant acpi_bus_get_device() call from mshw0011_notify()
> along with a local variable related to it.
> 
> No intentional functional impact.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans


> ---
> 
> v2 -> v3:
>    * Resend with a different From and S-o-b address and with R-by from
>      Maximilian.  No other changes.
> 
> ---
>  drivers/platform/surface/surface3_power.c |    3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> Index: linux-pm/drivers/platform/surface/surface3_power.c
> ===================================================================
> --- linux-pm.orig/drivers/platform/surface/surface3_power.c
> +++ linux-pm/drivers/platform/surface/surface3_power.c
> @@ -159,12 +159,11 @@ mshw0011_notify(struct mshw0011_data *cd
>  		unsigned int *ret_value)
>  {
>  	union acpi_object *obj;
> -	struct acpi_device *adev;
>  	acpi_handle handle;
>  	unsigned int i;
>  
>  	handle = ACPI_HANDLE(&cdata->adp1->dev);
> -	if (!handle || acpi_bus_get_device(handle, &adev))
> +	if (!handle)
>  		return -ENODEV;
>  
>  	obj = acpi_evaluate_dsm_typed(handle, &mshw0011_guid, arg1, arg2, NULL,
> 
> 
> 

[PATCH v1 6/7] platform: x86: ideapad-laptop: Use ACPI_COMPANION() directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael@kernel.org>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify ideapad_acpi_add() accordingly (no intentional functional
impact).

Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
---
 drivers/platform/x86/ideapad-laptop.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

Index: linux-pm/drivers/platform/x86/ideapad-laptop.c
===================================================================
--- linux-pm.orig/drivers/platform/x86/ideapad-laptop.c
+++ linux-pm/drivers/platform/x86/ideapad-laptop.c
@@ -1534,17 +1534,13 @@ static void ideapad_check_features(struc
 
 static int ideapad_acpi_add(struct platform_device *pdev)
 {
+	struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
 	struct ideapad_private *priv;
-	struct acpi_device *adev;
 	acpi_status status;
 	unsigned long cfg;
 	int err, i;
 
-	err = acpi_bus_get_device(ACPI_HANDLE(&pdev->dev), &adev);
-	if (err)
-		return -ENODEV;
-
-	if (eval_int(adev->handle, "_CFG", &cfg))
+	if (!adev || eval_int(adev->handle, "_CFG", &cfg))
 		return -ENODEV;
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);

[PATCH v2 6/7] platform: x86: ideapad-laptop: Use ACPI_COMPANION() directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify ideapad_acpi_add() accordingly (no intentional functional
impact).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

v1 -> v2:
   * Resend with a different From and S-o-b address.  No other changes.

---
 drivers/platform/x86/ideapad-laptop.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

Index: linux-pm/drivers/platform/x86/ideapad-laptop.c
===================================================================
--- linux-pm.orig/drivers/platform/x86/ideapad-laptop.c
+++ linux-pm/drivers/platform/x86/ideapad-laptop.c
@@ -1534,17 +1534,13 @@ static void ideapad_check_features(struc
 
 static int ideapad_acpi_add(struct platform_device *pdev)
 {
+	struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
 	struct ideapad_private *priv;
-	struct acpi_device *adev;
 	acpi_status status;
 	unsigned long cfg;
 	int err, i;
 
-	err = acpi_bus_get_device(ACPI_HANDLE(&pdev->dev), &adev);
-	if (err)
-		return -ENODEV;
-
-	if (eval_int(adev->handle, "_CFG", &cfg))
+	if (!adev || eval_int(adev->handle, "_CFG", &cfg))
 		return -ENODEV;
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);

Re: [PATCH v2 6/7] platform: x86: ideapad-laptop: Use ACPI_COMPANION() directly

[Hans de Goede]

Hi,

On 10/13/21 18:13, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
> macro and the ACPI handle produced by the former comes from the
> ACPI device object produced by the latter, so it is way more
> straightforward to evaluate the latter directly instead of passing
> the handle produced by the former to acpi_bus_get_device().
> 
> Modify ideapad_acpi_add() accordingly (no intentional functional
> impact).
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans


> ---
> 
> v1 -> v2:
>    * Resend with a different From and S-o-b address.  No other changes.
> 
> ---
>  drivers/platform/x86/ideapad-laptop.c |    8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> Index: linux-pm/drivers/platform/x86/ideapad-laptop.c
> ===================================================================
> --- linux-pm.orig/drivers/platform/x86/ideapad-laptop.c
> +++ linux-pm/drivers/platform/x86/ideapad-laptop.c
> @@ -1534,17 +1534,13 @@ static void ideapad_check_features(struc
>  
>  static int ideapad_acpi_add(struct platform_device *pdev)
>  {
> +	struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
>  	struct ideapad_private *priv;
> -	struct acpi_device *adev;
>  	acpi_status status;
>  	unsigned long cfg;
>  	int err, i;
>  
> -	err = acpi_bus_get_device(ACPI_HANDLE(&pdev->dev), &adev);
> -	if (err)
> -		return -ENODEV;
> -
> -	if (eval_int(adev->handle, "_CFG", &cfg))
> +	if (!adev || eval_int(adev->handle, "_CFG", &cfg))
>  		return -ENODEV;
>  
>  	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> 
> 
> 

[PATCH v1 7/7] perf: qcom_l2_pmu: ACPI: Use ACPI_COMPANION() directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael@kernel.org>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify l2_cache_pmu_probe_cluster() accordingly (no intentional
functional impact).

While at it, rename the ACPI device pointer to adev for more
clarity.

Signed-off-by: Rafael J. Wysocki <rafael@kernel.org>
---
 drivers/perf/qcom_l2_pmu.c |    7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/perf/qcom_l2_pmu.c
===================================================================
--- linux-pm.orig/drivers/perf/qcom_l2_pmu.c
+++ linux-pm/drivers/perf/qcom_l2_pmu.c
@@ -840,17 +840,14 @@ static int l2_cache_pmu_probe_cluster(st
 {
 	struct platform_device *pdev = to_platform_device(dev->parent);
 	struct platform_device *sdev = to_platform_device(dev);
+	struct acpi_device *adev = ACPI_COMPANION(dev);
 	struct l2cache_pmu *l2cache_pmu = data;
 	struct cluster_pmu *cluster;
-	struct acpi_device *device;
 	unsigned long fw_cluster_id;
 	int err;
 	int irq;
 
-	if (acpi_bus_get_device(ACPI_HANDLE(dev), &device))
-		return -ENODEV;
-
-	if (kstrtoul(device->pnp.unique_id, 10, &fw_cluster_id) < 0) {
+	if (!adev || kstrtoul(adev->pnp.unique_id, 10, &fw_cluster_id) < 0) {
 		dev_err(&pdev->dev, "unable to read ACPI uid\n");
 		return -ENODEV;
 	}

[PATCH v2 7/7] perf: qcom_l2_pmu: ACPI: Use ACPI_COMPANION() directly

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().

Modify l2_cache_pmu_probe_cluster() accordingly (no intentional
functional impact).

While at it, rename the ACPI device pointer to adev for more
clarity.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

v1 -> v2:
   * Resend with a different From and S-o-b address.  No other changes.

---
 drivers/perf/qcom_l2_pmu.c |    7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/perf/qcom_l2_pmu.c
===================================================================
--- linux-pm.orig/drivers/perf/qcom_l2_pmu.c
+++ linux-pm/drivers/perf/qcom_l2_pmu.c
@@ -840,17 +840,14 @@ static int l2_cache_pmu_probe_cluster(st
 {
 	struct platform_device *pdev = to_platform_device(dev->parent);
 	struct platform_device *sdev = to_platform_device(dev);
+	struct acpi_device *adev = ACPI_COMPANION(dev);
 	struct l2cache_pmu *l2cache_pmu = data;
 	struct cluster_pmu *cluster;
-	struct acpi_device *device;
 	unsigned long fw_cluster_id;
 	int err;
 	int irq;
 
-	if (acpi_bus_get_device(ACPI_HANDLE(dev), &device))
-		return -ENODEV;
-
-	if (kstrtoul(device->pnp.unique_id, 10, &fw_cluster_id) < 0) {
+	if (!adev || kstrtoul(adev->pnp.unique_id, 10, &fw_cluster_id) < 0) {
 		dev_err(&pdev->dev, "unable to read ACPI uid\n");
 		return -ENODEV;
 	}

Re: [PATCH v2 7/7] perf: qcom_l2_pmu: ACPI: Use ACPI_COMPANION() directly

[Rafael J. Wysocki]

On Wed, Oct 13, 2021 at 6:16 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
> macro and the ACPI handle produced by the former comes from the
> ACPI device object produced by the latter, so it is way more
> straightforward to evaluate the latter directly instead of passing
> the handle produced by the former to acpi_bus_get_device().
>
> Modify l2_cache_pmu_probe_cluster() accordingly (no intentional
> functional impact).
>
> While at it, rename the ACPI device pointer to adev for more
> clarity.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

If nobody nas any concerns regarding this patch, I will queue it up
for 5.16 in the ACPI tree, because it is requisite for further
changes.

Thanks!

> ---
>
> v1 -> v2:
>    * Resend with a different From and S-o-b address.  No other changes.
>
> ---
>  drivers/perf/qcom_l2_pmu.c |    7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> Index: linux-pm/drivers/perf/qcom_l2_pmu.c
> ===================================================================
> --- linux-pm.orig/drivers/perf/qcom_l2_pmu.c
> +++ linux-pm/drivers/perf/qcom_l2_pmu.c
> @@ -840,17 +840,14 @@ static int l2_cache_pmu_probe_cluster(st
>  {
>         struct platform_device *pdev = to_platform_device(dev->parent);
>         struct platform_device *sdev = to_platform_device(dev);
> +       struct acpi_device *adev = ACPI_COMPANION(dev);
>         struct l2cache_pmu *l2cache_pmu = data;
>         struct cluster_pmu *cluster;
> -       struct acpi_device *device;
>         unsigned long fw_cluster_id;
>         int err;
>         int irq;
>
> -       if (acpi_bus_get_device(ACPI_HANDLE(dev), &device))
> -               return -ENODEV;
> -
> -       if (kstrtoul(device->pnp.unique_id, 10, &fw_cluster_id) < 0) {
> +       if (!adev || kstrtoul(adev->pnp.unique_id, 10, &fw_cluster_id) < 0) {
>                 dev_err(&pdev->dev, "unable to read ACPI uid\n");
>                 return -ENODEV;
>         }
>
>
>