All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	coresight@lists.linaro.org, mike.leach@linaro.org,
	robert.walker@arm.com, "Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH 23/25] coresight: stm: ACPI support for parsing stimulus base
Date: Thu, 28 Mar 2019 14:41:51 -0600	[thread overview]
Message-ID: <20190328204151.GA7163@xps15> (raw)
In-Reply-To: <1553107783-3340-24-git-send-email-suzuki.poulose@arm.com>

On Wed, Mar 20, 2019 at 06:49:40PM +0000, Suzuki K Poulose wrote:
> The stimulus base for STM device must be listed as the second memory
> resource, followed by the programming base address. Add support for
> parsing the information for ACPI.
> 
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>  drivers/hwtracing/coresight/coresight-stm.c | 43 +++++++++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
> index d94ae22..995443a 100644
> --- a/drivers/hwtracing/coresight/coresight-stm.c
> +++ b/drivers/hwtracing/coresight/coresight-stm.c
> @@ -16,6 +16,7 @@
>   * (C) 2015-2016 Chunyan Zhang <zhang.chunyan@linaro.org>
>   */
>  #include <asm/local.h>
> +#include <linux/acpi.h>
>  #include <linux/amba/bus.h>
>  #include <linux/bitmap.h>
>  #include <linux/clk.h>
> @@ -717,10 +718,52 @@ static inline int of_stm_get_stimulus_area(struct device *dev,
>  }
>  #endif
>  
> +#ifdef CONFIG_ACPI
> +static int acpi_stm_get_stimulus_area(struct device *dev, struct resource *res)
> +{
> +	int rc;
> +	bool found_base = false;
> +	struct resource_entry *rent;
> +	LIST_HEAD(res_list);
> +
> +	struct acpi_device *adev = ACPI_COMPANION(dev);
> +
> +	if (!adev)
> +		return -ENODEV;
> +	rc = acpi_dev_get_resources(adev, &res_list, NULL, NULL);
> +	if (rc < 0)
> +		return rc;
> +
> +	rc = -ENOENT;
> +	list_for_each_entry(rent, &res_list, node) {
> +		if (resource_type(rent->res) != IORESOURCE_MEM)
> +			continue;
> +		if (found_base) {
> +			*res = *rent->res;
> +			rc = 0;
> +			break;
> +		}
> +
> +		found_base = true;

Is the ACPI binding crystal clear on the fact that the second resource region
has to be for stimulus ports?

> +	}
> +
> +	acpi_dev_free_resource_list(&res_list);
> +	return rc;
> +}
> +#else
> +static inline int acpi_stm_get_stimulus_area(struct device *dev,
> +					     struct resource *res)
> +{
> +	return -ENOENT;
> +}
> +#endif
> +
>  static int stm_get_stimulus_area(struct device *dev, struct resource *res)
>  {
>  	if (dev->of_node)

Wouldn't it be better to use is_of_node()?

>  		return of_stm_get_stimulus_area(dev, res);
> +	else if (is_acpi_node(dev->fwnode)

is_acpi_device_node()?

> +		return acpi_stm_get_stimulus_area(dev, res);
>  	return -ENOENT;
>  }
>  
> -- 
> 2.7.4
> 

WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: coresight@lists.linaro.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	robert.walker@arm.com, linux-arm-kernel@lists.infradead.org,
	mike.leach@linaro.org
Subject: Re: [PATCH 23/25] coresight: stm: ACPI support for parsing stimulus base
Date: Thu, 28 Mar 2019 14:41:51 -0600	[thread overview]
Message-ID: <20190328204151.GA7163@xps15> (raw)
In-Reply-To: <1553107783-3340-24-git-send-email-suzuki.poulose@arm.com>

On Wed, Mar 20, 2019 at 06:49:40PM +0000, Suzuki K Poulose wrote:
> The stimulus base for STM device must be listed as the second memory
> resource, followed by the programming base address. Add support for
> parsing the information for ACPI.
> 
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>  drivers/hwtracing/coresight/coresight-stm.c | 43 +++++++++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
> index d94ae22..995443a 100644
> --- a/drivers/hwtracing/coresight/coresight-stm.c
> +++ b/drivers/hwtracing/coresight/coresight-stm.c
> @@ -16,6 +16,7 @@
>   * (C) 2015-2016 Chunyan Zhang <zhang.chunyan@linaro.org>
>   */
>  #include <asm/local.h>
> +#include <linux/acpi.h>
>  #include <linux/amba/bus.h>
>  #include <linux/bitmap.h>
>  #include <linux/clk.h>
> @@ -717,10 +718,52 @@ static inline int of_stm_get_stimulus_area(struct device *dev,
>  }
>  #endif
>  
> +#ifdef CONFIG_ACPI
> +static int acpi_stm_get_stimulus_area(struct device *dev, struct resource *res)
> +{
> +	int rc;
> +	bool found_base = false;
> +	struct resource_entry *rent;
> +	LIST_HEAD(res_list);
> +
> +	struct acpi_device *adev = ACPI_COMPANION(dev);
> +
> +	if (!adev)
> +		return -ENODEV;
> +	rc = acpi_dev_get_resources(adev, &res_list, NULL, NULL);
> +	if (rc < 0)
> +		return rc;
> +
> +	rc = -ENOENT;
> +	list_for_each_entry(rent, &res_list, node) {
> +		if (resource_type(rent->res) != IORESOURCE_MEM)
> +			continue;
> +		if (found_base) {
> +			*res = *rent->res;
> +			rc = 0;
> +			break;
> +		}
> +
> +		found_base = true;

Is the ACPI binding crystal clear on the fact that the second resource region
has to be for stimulus ports?

> +	}
> +
> +	acpi_dev_free_resource_list(&res_list);
> +	return rc;
> +}
> +#else
> +static inline int acpi_stm_get_stimulus_area(struct device *dev,
> +					     struct resource *res)
> +{
> +	return -ENOENT;
> +}
> +#endif
> +
>  static int stm_get_stimulus_area(struct device *dev, struct resource *res)
>  {
>  	if (dev->of_node)

Wouldn't it be better to use is_of_node()?

>  		return of_stm_get_stimulus_area(dev, res);
> +	else if (is_acpi_node(dev->fwnode)

is_acpi_device_node()?

> +		return acpi_stm_get_stimulus_area(dev, res);
>  	return -ENOENT;
>  }
>  
> -- 
> 2.7.4
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-03-28 20:41 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-20 18:49 [PATCH 00/25] coresight: Support for ACPI bindings Suzuki K Poulose
2019-03-20 18:49 ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 01/25] coresight: tmc: Report DMA setup failures Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 02/25] coresight: dynamic-replicator: Clean up error handling Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 03/25] coresight: replicator: Prepare for merging with dynamic-replicator Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 04/25] coresight: dynamic-replicator: Prepare for merging with static replicator Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 05/25] coresight: Merge the static and dynamic replicator drivers Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-27 15:27   ` Mathieu Poirier
2019-03-27 15:27     ` Mathieu Poirier
2019-03-27 17:33     ` Suzuki K Poulose
2019-03-27 17:33       ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 06/25] coresight: funnel: Clean up device book keeping Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 07/25] coresight: replicator: Cleanup device tracking Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 08/25] coresight: tmc: Clean up device specific data Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-26 21:53   ` Mathieu Poirier
2019-03-26 21:53     ` Mathieu Poirier
2019-03-27 11:45     ` Suzuki K Poulose
2019-03-27 11:45       ` Suzuki K Poulose
2019-03-27 14:42     ` Suzuki K Poulose
2019-03-27 14:42       ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 09/25] coresight: catu: Cleanup " Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 10/25] coresight: tpiu: Clean up " Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-26 21:54   ` Mathieu Poirier
2019-03-26 21:54     ` Mathieu Poirier
2019-03-27 11:52     ` Suzuki K Poulose
2019-03-27 11:52       ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 11/25] coresight: stm: Cleanup " Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 12/25] coresight: etm: Clean up " Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 13/25] coresight: etb10: " Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-27 21:39   ` Mathieu Poirier
2019-03-27 21:39     ` Mathieu Poirier
2019-03-28 11:09     ` Suzuki K Poulose
2019-03-28 11:09       ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 14/25] coresight: Rename of_coresight to coresight-platform Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 15/25] coresight: etm3x: Rearrange cp14 access detection Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-27 22:05   ` Mathieu Poirier
2019-03-27 22:05     ` Mathieu Poirier
2019-03-28 11:03     ` Suzuki K Poulose
2019-03-28 11:03       ` Suzuki K Poulose
2019-03-28 11:03       ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 16/25] coresight: stm: Rearrange probing the stimulus area Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 17/25] coresight: tmc-etr: Rearrange probing default buffer size Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 18/25] coresight: Introduce generic platform data helper Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-27 22:57   ` Mathieu Poirier
2019-03-27 22:57     ` Mathieu Poirier
2019-03-28 10:59     ` Suzuki K Poulose
2019-03-28 10:59       ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 19/25] coresight: Make device to CPU mapping generic Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 20/25] coresight: platform: Use fwnode handle for device search Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 21/25] coresight: Use fwnode handle instead of device names Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-28 17:42   ` Mathieu Poirier
2019-03-28 17:42     ` Mathieu Poirier
2019-03-28 18:42     ` Suzuki K Poulose
2019-03-28 18:42       ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 22/25] coresight: Use platform agnostic names Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-28 19:43   ` Mathieu Poirier
2019-03-28 19:43     ` Mathieu Poirier
2019-03-20 18:49 ` [PATCH 23/25] coresight: stm: ACPI support for parsing stimulus base Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-28 20:41   ` Mathieu Poirier [this message]
2019-03-28 20:41     ` Mathieu Poirier
2019-04-04 11:27     ` Suzuki K Poulose
2019-04-04 11:27       ` Suzuki K Poulose
2019-03-20 18:49 ` [PATCH 24/25] coresight: Support for ACPI bindings Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-29 19:09   ` Mathieu Poirier
2019-03-29 19:09     ` Mathieu Poirier
2019-03-20 18:49 ` [PATCH 25/25] coresight: acpi: Support for components Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-20 18:49 ` [TEST PATCH 26/25] edk2-platform: juno: Update ACPI CoreSight Bindings Suzuki K Poulose
2019-03-20 18:49   ` Suzuki K Poulose
2019-03-22 10:13 ` [PATCH 00/25] coresight: Support for ACPI bindings Suzuki K Poulose
2019-03-22 10:13   ` Suzuki K Poulose

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=20190328204151.GA7163@xps15 \
    --to=mathieu.poirier@linaro.org \
    --cc=coresight@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.leach@linaro.org \
    --cc=rjw@rjwysocki.net \
    --cc=robert.walker@arm.com \
    --cc=suzuki.poulose@arm.com \
    /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.