devicetree.vger.kernel.org archive mirror
 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, sudeep.holla@arm.com,
	robh@kernel.org, mark.rutland@arm.com, frowand.list@gmail.com,
	matt.sealey@arm.com, charles.garcia-tobin@arm.com,
	john.horley@arm.com, mike.leach@linaro.org,
	coresight@lists.linaro.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [RFC PATCH 7/8] dts: coresight: Define new bindings for direction of data flow
Date: Fri, 1 Jun 2018 14:39:28 -0600	[thread overview]
Message-ID: <20180601203928.GD9838@xps15> (raw)
In-Reply-To: <1527858967-16047-8-git-send-email-suzuki.poulose@arm.com>

On Fri, Jun 01, 2018 at 02:16:06PM +0100, Suzuki K Poulose wrote:
> So far we have relied on an undocumented property "slave-mode",
> to indicate if the given port is input or not. Since we are
> redefining the coresight bindings, define new property for the
> "direction" of data flow for a given connection endpoint in the
> device.
> 
> Each endpoint must define the following property.
> 
>  - "direction" : 0 => Port is input
> 		 1 => Port is output
> 
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>  drivers/hwtracing/coresight/of_coresight.c | 20 ++++++++++++++++----

You haven't documented the binding in bindings/arm/coresight.txt the same way
you did with "coresight,hwid".  I'm guessing you simply forgot to do a "git add"
on the file when preparing the patchset.

>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
> index 99d7a9c..63c1668 100644
> --- a/drivers/hwtracing/coresight/of_coresight.c
> +++ b/drivers/hwtracing/coresight/of_coresight.c
> @@ -52,7 +52,19 @@ of_coresight_get_endpoint_device(struct device_node *endpoint)
>  			       endpoint, of_dev_node_match);
>  }
>  
> -static void of_coresight_get_ports(const struct device_node *node,
> +static bool of_coresight_ep_is_input(struct device *dev, struct device_node *ep_node)

I suggested of_coresight_endpoint_get_port_id() in my review of 6/8.  I'm good
with either "ep" or "endpoint", as long as the names are consistent.

> +{
> +	u32 dir;
> +
> +	if (!of_property_read_u32(ep_node, "direction", &dir))
> +		return dir == 0;
> +
> +	dev_warn_once(dev, "Missing mandatory \"direction\" property!\n");
> +	return of_property_read_bool(ep_node, "slave-mode");
> +}
> +
> +static void of_coresight_get_ports(struct device *dev,
> +				   const struct device_node *node,
>  				   int *nr_inport, int *nr_outport)
>  {
>  	struct device_node *ep = NULL;
> @@ -63,7 +75,7 @@ static void of_coresight_get_ports(const struct device_node *node,
>  		if (!ep)
>  			break;
>  
> -		if (of_property_read_bool(ep, "slave-mode"))
> +		if (of_coresight_ep_is_input(dev, ep))
>  			in++;
>  		else
>  			out++;
> @@ -149,7 +161,7 @@ of_get_coresight_platform_data(struct device *dev,
>  	pdata->name = dev_name(dev);
>  
>  	/* Get the number of input and output port for this component */
> -	of_coresight_get_ports(node, &pdata->nr_inport, &pdata->nr_outport);
> +	of_coresight_get_ports(dev, node, &pdata->nr_inport, &pdata->nr_outport);
>  
>  	if (pdata->nr_outport) {
>  		ret = of_coresight_alloc_memory(dev, pdata);
> @@ -168,7 +180,7 @@ of_get_coresight_platform_data(struct device *dev,
>  			 * No need to deal with input ports, processing for as
>  			 * processing for output ports will deal with them.
>  			 */
> -			if (of_find_property(ep, "slave-mode", NULL))
> +			if (of_coresight_ep_is_input(dev, ep))
>  				continue;
>  
>  			outport = of_graph_ep_coresight_get_port_id(dev, ep);
> -- 
> 2.7.4
> 

  reply	other threads:[~2018-06-01 20:39 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-01 13:15 [RFC PATCH 0/8] coresight: Update device tree bindings Suzuki K Poulose
2018-06-01 13:16 ` [RFC PATCH 1/8] dts: binding: coresight: Document graph bindings Suzuki K Poulose
2018-06-01 16:14   ` Mathieu Poirier
2018-06-01 13:16 ` [RFC PATCH 2/8] coresight: Fix remote endpoint parsing Suzuki K Poulose
2018-06-01 19:38   ` Mathieu Poirier
2018-06-01 19:46     ` Mathieu Poirier
2018-06-04 10:34       ` Suzuki K Poulose
2018-06-01 13:16 ` [RFC PATCH 3/8] coresight: Cleanup platform description data Suzuki K Poulose
2018-06-01 13:16 ` [RFC PATCH 4/8] coresight: platform: Cleanup coresight connection handling Suzuki K Poulose
2018-06-01 13:16 ` [RFC PATCH 5/8] coresight: Handle errors in finding input/output ports Suzuki K Poulose
2018-06-01 13:16 ` [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings Suzuki K Poulose
2018-06-01 20:26   ` Mathieu Poirier
2018-06-12 20:48   ` Rob Herring
2018-06-13  9:45     ` Suzuki K Poulose
2018-06-13 12:49       ` Matt Sealey
2018-06-13 13:35         ` Suzuki K Poulose
2018-06-13 13:57           ` Rob Herring
2018-06-13 15:47           ` Matt Sealey
2018-06-13 17:07             ` Suzuki K Poulose
2018-06-13 19:40               ` Mathieu Poirier
2018-06-13 21:07                 ` Matt Sealey
2018-06-14  8:53                   ` Suzuki K Poulose
2018-06-14 13:59                     ` Rob Herring
2018-06-14 15:04                       ` Matt Sealey
2018-06-15  9:58                       ` Suzuki K Poulose
2018-07-03  9:44                       ` Suzuki K Poulose
2018-07-03 16:15                         ` Mathieu Poirier
2018-06-01 13:16 ` [RFC PATCH 7/8] dts: coresight: Define new bindings for direction of data flow Suzuki K Poulose
2018-06-01 20:39   ` Mathieu Poirier [this message]
2018-06-04 14:20     ` Suzuki K Poulose
2018-06-01 13:16 ` [RFC PATCH 8/8] dts: juno: Update coresight bindings for hw port Suzuki K Poulose
2018-06-01 20:59   ` Mathieu Poirier
2018-06-01 21:04 ` [RFC PATCH 0/8] coresight: Update device tree bindings Mathieu Poirier

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=20180601203928.GD9838@xps15 \
    --to=mathieu.poirier@linaro.org \
    --cc=charles.garcia-tobin@arm.com \
    --cc=coresight@lists.linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=john.horley@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=matt.sealey@arm.com \
    --cc=mike.leach@linaro.org \
    --cc=robh@kernel.org \
    --cc=sudeep.holla@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 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).