All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suzuki Kuruppassery Poulose <suzuki.poulose@arm.com>
To: Mike Leach <mike.leach@linaro.org>,
	coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
	devicetree@vger.kernel.org, linux-doc@vger.kernel.org
Cc: mathieu.poirier@linaro.org
Subject: Re: [PATCH v5 08/14] coresight: cti: Enable CTI associated with devices.
Date: Fri, 29 Nov 2019 18:28:16 +0000	[thread overview]
Message-ID: <c48fe3ee-335b-3dfb-33c1-a2cd7d5a00e6@arm.com> (raw)
In-Reply-To: <20191119231912.12768-9-mike.leach@linaro.org>

On 19/11/2019 23:19, Mike Leach wrote:
> The CoreSight subsystem enables a path of devices from source to sink.
> Any CTI devices associated with the path devices must be enabled at the
> same time.
> 
> This patch adds an associated coresight_device element to the main
> coresight device structure, and uses this to create associations between
> the CTI and other devices based on the device tree data. The associated
> device element is used to enable CTI in conjunction with the path elements.
> 
> CTI devices are reference counted so where a single CTI is associated with
> multiple elements on the path, it will be enabled on the first associated
> device enable, and disabled with the last associated device disable.
> 
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
>   drivers/hwtracing/coresight/coresight-cti.c   | 87 +++++++++++++++++++
>   .../hwtracing/coresight/coresight-platform.c  | 23 +++++
>   drivers/hwtracing/coresight/coresight-priv.h  |  6 ++
>   drivers/hwtracing/coresight/coresight.c       | 58 +++++++++++--
>   include/linux/coresight.h                     |  5 ++
>   5 files changed, 173 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-cti.c b/drivers/hwtracing/coresight/coresight-cti.c
> index 369488dd7b8e..cf116463149a 100644
> --- a/drivers/hwtracing/coresight/coresight-cti.c
> +++ b/drivers/hwtracing/coresight/coresight-cti.c
> @@ -440,6 +440,90 @@ int cti_channel_setop(struct device *dev, enum cti_chan_set_op op,
>   	return err;
>   }
>   
> +/*
> + * Look for a matching connection device name in the list of
> + * connections. If found then swap in the csdev name and return
> + * found.
> + */
> +static bool
> +cti_match_con_name(struct cti_device *ctidev, const char *node_name,
> +		   const char *csdev_name)

Here we actually fixup the name of the connection, rather than simply 
matching it. So it may be apt to rename this to cti_match_fixup_name()

> +{
> +	struct cti_trig_con *trig_con;
> +
> +	list_for_each_entry(trig_con, &ctidev->trig_cons, node) {
> +		if (trig_con->con_dev_name) {
> +			if (!strcmp(node_name, trig_con->con_dev_name)) {

Can there be duplicate node_name's ? Does it make sense to store the 
fwhandle along with the "temporary node_name" to match it later while
fixing up ?

> +				/* match: so swap in csdev name */
> +				kfree(trig_con->con_dev_name);
> +				trig_con->con_dev_name =
> +					kstrdup(csdev_name, GFP_KERNEL);
> +				return true;
> +			}
> +		}
> +	}
> +	return false;
> +}


> +/*
> + * Search the cti list to add an associated CTI into the supplied CS device
> + * This will set the association if CTI declared before the CS device
> + */
> +void cti_add_assoc_to_csdev(struct coresight_device *csdev)
> +{

..

 > +	struct cti_drvdata *ect_item;
 > +	struct cti_device *ctidev;
 > +	const char *node_name = NULL, *csdev_name;
 > +
 > +	/* protect the list */
 > +	mutex_lock(&ect_mutex);
 > +
 > +	/* exit if current is an ECT device.*/
 > +	if ((csdev->type == CORESIGHT_DEV_TYPE_ECT) || list_empty(&ect_net))
 > +		goto cti_add_done;
 > +
 > +	/* if we didn't find the csdev previously we used the fwnode name */
 > +	node_name = coresight_get_fwnode_name(csdev->dev.parent);

We used "cti_plat_get_node_name()" when we added the name in the
absence of csdev in patch 7, could we not reuse the function here ?

 > +
 > +	if (!node_name)
 > +		goto cti_add_done;
 > +
 > +	/* this is the name we want to use for the association */
 > +	csdev_name = dev_name(&csdev->dev);


> +
> +	/* for each CTI in list... */
> +	list_for_each_entry(ect_item, &ect_net, node) {
> +		ctidev = &ect_item->ctidev;
> +		if (cti_match_con_name(ctidev, node_name, csdev_name)) {
> +			/*
> +			 * if we found a matching name then update the
> +			 * association pointers.
> +			 */
> +			csdev->ect_dev = ect_item->csdev;
> +			goto cti_add_done;

			break; instead ?

> +		}
> +	}
> +cti_add_done:
> +	mutex_unlock(&ect_mutex);
> +}
> +EXPORT_SYMBOL_GPL(cti_add_assoc_to_csdev);
> +
> +/*
> + * Update the cross references where the associated device was found
> + * while we were building the connection info. This will occur if the
> + * assoc device was registered before the CTI.
> + */
> +static void cti_update_conn_xrefs(struct cti_drvdata *drvdata)
> +{
> +	struct cti_trig_con *tc;
> +	struct cti_device *ctidev = &drvdata->ctidev;
> +
> +	list_for_each_entry(tc, &ctidev->trig_cons, node) {
> +		if (tc->con_dev)
> +			tc->con_dev->ect_dev = drvdata->csdev;
> +	}

Does this need to take the coresight_mutex to avoid racing against
a coresight_enable_path() ? Though this may be fine as long as the
CTI driver detects that that device was not enabled.

Also, it looks like we have a potential issue with perf vs sysfs mode.
The perf mode doesn't seem to take the coresight_mutex, for
build_path/enable_path operations. This is outside the scope of this
series though.

> +}
> +
>   /** cti ect operations **/
>   int cti_enable(struct coresight_device *csdev)
>   {
> @@ -574,6 +658,9 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
>   	drvdata->csdev_release = drvdata->csdev->dev.release;
>   	drvdata->csdev->dev.release = cti_device_release;
>   
> +	/* set any cross references */
> +	cti_update_conn_xrefs(drvdata);
> +
    	/* all done - dec pm refcount */
>   	pm_runtime_put(&adev->dev);
>   	dev_info(&drvdata->csdev->dev, "CTI initialized\n");
> diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c
> index 3c5bee429105..6721cb1af5fe 100644
> --- a/drivers/hwtracing/coresight/coresight-platform.c
> +++ b/drivers/hwtracing/coresight/coresight-platform.c
> @@ -293,6 +293,12 @@ static int of_get_coresight_platform_data(struct device *dev,
>   
>   	return 0;
>   }
> +
> +static inline const char *of_coresight_get_node_name(struct device *dev)
> +{
> +	return dev->of_node->full_name;
> +}
> +
>   #else
>   static inline int
>   of_get_coresight_platform_data(struct device *dev,
> @@ -305,6 +311,11 @@ static inline int of_coresight_get_cpu(struct device *dev)
>   {
>   	return -ENODEV;
>   }
> +
> +static inline const char *of_coresight_get_node_name(struct device *dev)
> +{
> +	return NULL;
> +}
>   #endif
>   
>   #ifdef CONFIG_ACPI
> @@ -766,6 +777,18 @@ static inline int acpi_coresight_get_cpu(struct device *dev)
>   }
>   #endif
>   
> +const char *coresight_get_fwnode_name(struct device *dev)

As mentioned above, please could we reuse the name helper we used
during the insertion rather than introducing a new wrapper which
effectively does the same thing ?

> +{
> +	const char *node_name = NULL;
> +	struct fwnode_handle *fwnode = dev_fwnode(dev);
> +
> +	if (is_of_node(fwnode))
> +		node_name = of_coresight_get_node_name(dev);
> +
> +	return node_name;
> +}
> +EXPORT_SYMBOL_GPL(coresight_get_fwnode_name);

Why does this get exported ? If a following patch needs it, you may
always do that when you need it.


Cheers
Suzuki

WARNING: multiple messages have this Message-ID (diff)
From: Suzuki Kuruppassery Poulose <suzuki.poulose@arm.com>
To: Mike Leach <mike.leach@linaro.org>,
	coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
	devicetree@vger.kernel.org, linux-doc@vger.kernel.org
Cc: mathieu.poirier@linaro.org
Subject: Re: [PATCH v5 08/14] coresight: cti: Enable CTI associated with devices.
Date: Fri, 29 Nov 2019 18:28:16 +0000	[thread overview]
Message-ID: <c48fe3ee-335b-3dfb-33c1-a2cd7d5a00e6@arm.com> (raw)
In-Reply-To: <20191119231912.12768-9-mike.leach@linaro.org>

On 19/11/2019 23:19, Mike Leach wrote:
> The CoreSight subsystem enables a path of devices from source to sink.
> Any CTI devices associated with the path devices must be enabled at the
> same time.
> 
> This patch adds an associated coresight_device element to the main
> coresight device structure, and uses this to create associations between
> the CTI and other devices based on the device tree data. The associated
> device element is used to enable CTI in conjunction with the path elements.
> 
> CTI devices are reference counted so where a single CTI is associated with
> multiple elements on the path, it will be enabled on the first associated
> device enable, and disabled with the last associated device disable.
> 
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
>   drivers/hwtracing/coresight/coresight-cti.c   | 87 +++++++++++++++++++
>   .../hwtracing/coresight/coresight-platform.c  | 23 +++++
>   drivers/hwtracing/coresight/coresight-priv.h  |  6 ++
>   drivers/hwtracing/coresight/coresight.c       | 58 +++++++++++--
>   include/linux/coresight.h                     |  5 ++
>   5 files changed, 173 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-cti.c b/drivers/hwtracing/coresight/coresight-cti.c
> index 369488dd7b8e..cf116463149a 100644
> --- a/drivers/hwtracing/coresight/coresight-cti.c
> +++ b/drivers/hwtracing/coresight/coresight-cti.c
> @@ -440,6 +440,90 @@ int cti_channel_setop(struct device *dev, enum cti_chan_set_op op,
>   	return err;
>   }
>   
> +/*
> + * Look for a matching connection device name in the list of
> + * connections. If found then swap in the csdev name and return
> + * found.
> + */
> +static bool
> +cti_match_con_name(struct cti_device *ctidev, const char *node_name,
> +		   const char *csdev_name)

Here we actually fixup the name of the connection, rather than simply 
matching it. So it may be apt to rename this to cti_match_fixup_name()

> +{
> +	struct cti_trig_con *trig_con;
> +
> +	list_for_each_entry(trig_con, &ctidev->trig_cons, node) {
> +		if (trig_con->con_dev_name) {
> +			if (!strcmp(node_name, trig_con->con_dev_name)) {

Can there be duplicate node_name's ? Does it make sense to store the 
fwhandle along with the "temporary node_name" to match it later while
fixing up ?

> +				/* match: so swap in csdev name */
> +				kfree(trig_con->con_dev_name);
> +				trig_con->con_dev_name =
> +					kstrdup(csdev_name, GFP_KERNEL);
> +				return true;
> +			}
> +		}
> +	}
> +	return false;
> +}


> +/*
> + * Search the cti list to add an associated CTI into the supplied CS device
> + * This will set the association if CTI declared before the CS device
> + */
> +void cti_add_assoc_to_csdev(struct coresight_device *csdev)
> +{

..

 > +	struct cti_drvdata *ect_item;
 > +	struct cti_device *ctidev;
 > +	const char *node_name = NULL, *csdev_name;
 > +
 > +	/* protect the list */
 > +	mutex_lock(&ect_mutex);
 > +
 > +	/* exit if current is an ECT device.*/
 > +	if ((csdev->type == CORESIGHT_DEV_TYPE_ECT) || list_empty(&ect_net))
 > +		goto cti_add_done;
 > +
 > +	/* if we didn't find the csdev previously we used the fwnode name */
 > +	node_name = coresight_get_fwnode_name(csdev->dev.parent);

We used "cti_plat_get_node_name()" when we added the name in the
absence of csdev in patch 7, could we not reuse the function here ?

 > +
 > +	if (!node_name)
 > +		goto cti_add_done;
 > +
 > +	/* this is the name we want to use for the association */
 > +	csdev_name = dev_name(&csdev->dev);


> +
> +	/* for each CTI in list... */
> +	list_for_each_entry(ect_item, &ect_net, node) {
> +		ctidev = &ect_item->ctidev;
> +		if (cti_match_con_name(ctidev, node_name, csdev_name)) {
> +			/*
> +			 * if we found a matching name then update the
> +			 * association pointers.
> +			 */
> +			csdev->ect_dev = ect_item->csdev;
> +			goto cti_add_done;

			break; instead ?

> +		}
> +	}
> +cti_add_done:
> +	mutex_unlock(&ect_mutex);
> +}
> +EXPORT_SYMBOL_GPL(cti_add_assoc_to_csdev);
> +
> +/*
> + * Update the cross references where the associated device was found
> + * while we were building the connection info. This will occur if the
> + * assoc device was registered before the CTI.
> + */
> +static void cti_update_conn_xrefs(struct cti_drvdata *drvdata)
> +{
> +	struct cti_trig_con *tc;
> +	struct cti_device *ctidev = &drvdata->ctidev;
> +
> +	list_for_each_entry(tc, &ctidev->trig_cons, node) {
> +		if (tc->con_dev)
> +			tc->con_dev->ect_dev = drvdata->csdev;
> +	}

Does this need to take the coresight_mutex to avoid racing against
a coresight_enable_path() ? Though this may be fine as long as the
CTI driver detects that that device was not enabled.

Also, it looks like we have a potential issue with perf vs sysfs mode.
The perf mode doesn't seem to take the coresight_mutex, for
build_path/enable_path operations. This is outside the scope of this
series though.

> +}
> +
>   /** cti ect operations **/
>   int cti_enable(struct coresight_device *csdev)
>   {
> @@ -574,6 +658,9 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
>   	drvdata->csdev_release = drvdata->csdev->dev.release;
>   	drvdata->csdev->dev.release = cti_device_release;
>   
> +	/* set any cross references */
> +	cti_update_conn_xrefs(drvdata);
> +
    	/* all done - dec pm refcount */
>   	pm_runtime_put(&adev->dev);
>   	dev_info(&drvdata->csdev->dev, "CTI initialized\n");
> diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c
> index 3c5bee429105..6721cb1af5fe 100644
> --- a/drivers/hwtracing/coresight/coresight-platform.c
> +++ b/drivers/hwtracing/coresight/coresight-platform.c
> @@ -293,6 +293,12 @@ static int of_get_coresight_platform_data(struct device *dev,
>   
>   	return 0;
>   }
> +
> +static inline const char *of_coresight_get_node_name(struct device *dev)
> +{
> +	return dev->of_node->full_name;
> +}
> +
>   #else
>   static inline int
>   of_get_coresight_platform_data(struct device *dev,
> @@ -305,6 +311,11 @@ static inline int of_coresight_get_cpu(struct device *dev)
>   {
>   	return -ENODEV;
>   }
> +
> +static inline const char *of_coresight_get_node_name(struct device *dev)
> +{
> +	return NULL;
> +}
>   #endif
>   
>   #ifdef CONFIG_ACPI
> @@ -766,6 +777,18 @@ static inline int acpi_coresight_get_cpu(struct device *dev)
>   }
>   #endif
>   
> +const char *coresight_get_fwnode_name(struct device *dev)

As mentioned above, please could we reuse the name helper we used
during the insertion rather than introducing a new wrapper which
effectively does the same thing ?

> +{
> +	const char *node_name = NULL;
> +	struct fwnode_handle *fwnode = dev_fwnode(dev);
> +
> +	if (is_of_node(fwnode))
> +		node_name = of_coresight_get_node_name(dev);
> +
> +	return node_name;
> +}
> +EXPORT_SYMBOL_GPL(coresight_get_fwnode_name);

Why does this get exported ? If a following patch needs it, you may
always do that when you need it.


Cheers
Suzuki

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

  parent reply	other threads:[~2019-11-29 18:28 UTC|newest]

Thread overview: 124+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-19 23:18 [PATCH v5 00/14] CoreSight CTI Driver Mike Leach
2019-11-19 23:18 ` Mike Leach
2019-11-19 23:18 ` [PATCH v5 01/14] coresight: cti: Initial " Mike Leach
2019-11-19 23:18   ` Mike Leach
2019-11-21 20:21   ` Mathieu Poirier
2019-11-21 20:21     ` Mathieu Poirier
2019-11-29 12:05     ` Mike Leach
2019-11-29 12:05       ` Mike Leach
2019-12-03 16:53       ` Mathieu Poirier
2019-12-03 16:53         ` Mathieu Poirier
2019-11-25 19:03   ` Suzuki Kuruppassery Poulose
2019-11-25 19:03     ` Suzuki Kuruppassery Poulose
2019-11-29 12:06     ` Mike Leach
2019-11-29 12:06       ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 02/14] coresight: cti: Add sysfs coresight mgmt reg access Mike Leach
2019-11-19 23:19   ` Mike Leach
2019-11-22 17:19   ` Mathieu Poirier
2019-11-22 17:19     ` Mathieu Poirier
2019-11-19 23:19 ` [PATCH v5 03/14] coresight: cti: Add sysfs access to program function regs Mike Leach
2019-11-19 23:19   ` Mike Leach
2019-11-27 18:26   ` Suzuki Kuruppassery Poulose
2019-11-27 18:26     ` Suzuki Kuruppassery Poulose
2019-11-29 12:47     ` Mike Leach
2019-11-29 12:47       ` Mike Leach
2019-11-28 10:54   ` Suzuki Kuruppassery Poulose
2019-11-28 10:54     ` Suzuki Kuruppassery Poulose
2019-11-28 17:20     ` Mathieu Poirier
2019-11-28 17:20       ` Mathieu Poirier
2019-11-28 18:00       ` Suzuki Kuruppassery Poulose
2019-11-28 18:00         ` Suzuki Kuruppassery Poulose
2019-11-29 12:50     ` Mike Leach
2019-11-29 12:50       ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 04/14] coresight: cti: Add sysfs trigger / channel programming API Mike Leach
2019-11-19 23:19   ` Mike Leach
2019-11-22 18:40   ` Mathieu Poirier
2019-11-22 18:40     ` Mathieu Poirier
2019-11-27 18:40   ` Suzuki Kuruppassery Poulose
2019-11-27 18:40     ` Suzuki Kuruppassery Poulose
2019-11-29 13:01     ` Mike Leach
2019-11-29 13:01       ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 05/14] dt-bindings: arm: Adds CoreSight CTI hardware definitions Mike Leach
2019-11-19 23:19   ` Mike Leach
2019-11-20 19:06   ` Mathieu Poirier
2019-11-20 19:06     ` Mathieu Poirier
2019-11-20 22:39     ` Mike Leach
2019-11-20 22:39       ` Mike Leach
2019-11-22 23:33   ` Rob Herring
2019-11-22 23:33     ` Rob Herring
2019-11-29 13:50     ` Mike Leach
2019-11-29 13:50       ` Mike Leach
2019-11-29 14:12       ` Suzuki Kuruppassery Poulose
2019-11-29 14:12         ` Suzuki Kuruppassery Poulose
2019-11-28 18:38   ` Suzuki Kuruppassery Poulose
2019-11-28 18:38     ` Suzuki Kuruppassery Poulose
2019-11-29 13:57     ` Mike Leach
2019-11-29 13:57       ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 06/14] coresight: cti: Add device tree support for v8 arch CTI Mike Leach
2019-11-19 23:19   ` Mike Leach
2019-11-25 19:00   ` Mathieu Poirier
2019-11-25 19:00     ` Mathieu Poirier
2019-11-29 11:33   ` Suzuki Kuruppassery Poulose
2019-11-29 11:33     ` Suzuki Kuruppassery Poulose
2019-12-03 10:59     ` Mike Leach
2019-12-03 10:59       ` Mike Leach
2019-12-03 11:28       ` Suzuki Kuruppassery Poulose
2019-12-03 11:28         ` Suzuki Kuruppassery Poulose
2019-12-03 12:25         ` Mike Leach
2019-12-03 12:25           ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 07/14] coresight: cti: Add device tree support for custom CTI Mike Leach
2019-11-19 23:19   ` Mike Leach
2019-11-25 21:22   ` Mathieu Poirier
2019-11-25 21:22     ` Mathieu Poirier
2019-11-29 14:16     ` Suzuki Kuruppassery Poulose
2019-11-29 14:16       ` Suzuki Kuruppassery Poulose
2019-11-29 21:11       ` Mathieu Poirier
2019-11-29 21:11         ` Mathieu Poirier
2019-11-29 14:18   ` Suzuki Kuruppassery Poulose
2019-11-29 14:18     ` Suzuki Kuruppassery Poulose
2019-12-03 14:05     ` Mike Leach
2019-12-03 14:05       ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 08/14] coresight: cti: Enable CTI associated with devices Mike Leach
2019-11-19 23:19   ` Mike Leach
2019-11-25 22:45   ` Mathieu Poirier
2019-11-25 22:45     ` Mathieu Poirier
2019-12-05 16:33     ` Mike Leach
2019-12-05 16:33       ` Mike Leach
2019-11-29 18:28   ` Suzuki Kuruppassery Poulose [this message]
2019-11-29 18:28     ` Suzuki Kuruppassery Poulose
2019-11-29 21:25     ` Mathieu Poirier
2019-11-29 21:25       ` Mathieu Poirier
2019-12-05 16:33     ` Mike Leach
2019-12-05 16:33       ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 09/14] coresight: cti: Add connection information to sysfs Mike Leach
2019-11-19 23:19   ` Mike Leach
2019-11-27 18:09   ` Mathieu Poirier
2019-11-27 18:09     ` Mathieu Poirier
2019-12-06 16:24     ` Mike Leach
2019-12-06 16:24       ` Mike Leach
2019-12-02  9:47   ` Suzuki Kuruppassery Poulose
2019-12-02  9:47     ` Suzuki Kuruppassery Poulose
2019-12-06 16:24     ` Mike Leach
2019-12-06 16:24       ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 10/14] dt-bindings: qcom: Add CTI options for qcom msm8916 Mike Leach
2019-11-19 23:19   ` Mike Leach
2019-11-27 18:18   ` Mathieu Poirier
2019-11-27 18:18     ` Mathieu Poirier
2019-11-19 23:19 ` [PATCH v5 11/14] dt-bindings: arm: Juno platform - add CTI entries to device tree Mike Leach
2019-11-19 23:19   ` Mike Leach
2019-11-27 18:25   ` Mathieu Poirier
2019-11-27 18:25     ` Mathieu Poirier
2019-11-19 23:19 ` [PATCH v5 12/14] dt-bindings: hisilicon: Add CTI bindings for hi-6220 Mike Leach
2019-11-19 23:19   ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 13/14] docs: coresight: Update documentation for CoreSight to cover CTI Mike Leach
2019-11-19 23:19   ` Mike Leach
2019-11-27 19:00   ` Mathieu Poirier
2019-11-27 19:00     ` Mathieu Poirier
2019-12-02 10:43   ` Suzuki Kuruppassery Poulose
2019-12-02 10:43     ` Suzuki Kuruppassery Poulose
2019-12-06 17:39     ` Mike Leach
2019-12-06 17:39       ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 14/14] docs: sysfs: coresight: Add sysfs ABI documentation for CTI Mike Leach
2019-11-19 23:19   ` Mike Leach
2019-11-27 19:08   ` Mathieu Poirier
2019-11-27 19:08     ` 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=c48fe3ee-335b-3dfb-33c1-a2cd7d5a00e6@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=coresight@lists.linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mike.leach@linaro.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.