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
next prev 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: linkBe 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.