Hi Mathieu,

On 16/01/2019 23:43, Mathieu Poirier wrote:
Good evening Suzuki,

On Wed, 16 Jan 2019 at 03:29, Suzuki K Poulose <suzuki.poul...@arm.com> wrote:



On 15/01/2019 23:07, Mathieu Poirier wrote:
Add a "sinks" directory entry so that users can see all the sinks
available in the system in a single place.  Individual sink are added
as they are registered with the coresight bus.

Signed-off-by: Mathieu Poirier <mathieu.poir...@linaro.org>

...

+static ssize_t etm_perf_sink_name_show(struct device *dev,
+                                    struct device_attribute *dattr,
+                                    char *buf)
+{
+     /* See function coresight_sink_by_id() to know where this is used */
+     u32 hash = hashlen_hash(hashlen_string(NULL, dattr->attr.name));
+
+     return scnprintf(buf, PAGE_SIZE, "%x\n", hash);
+}
+
+int etm_perf_symlink_sink(struct coresight_device *csdev)
+{
+     struct device *pmu_dev = etm_pmu.dev;
+     struct device *pdev = csdev->dev.parent;
+     struct device_attribute *dev_attr;
+
+     if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
+         csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
+             return -EINVAL;
+
+     if (!etm_perf_up)
+             return -EPROBE_DEFER;
+
+     dev_attr = kzalloc(sizeof(*dev_attr), GFP_KERNEL);
+     dev_attr->attr.name = kstrdup(dev_name(pdev), GFP_KERNEL);
+     dev_attr->attr.mode = 0444;
+     dev_attr->show = etm_perf_sink_name_show;

I would have  added the attribute to the csdev (say, sink_attr),
and add that to the group, so that it is easier to remove the
attribute when the sink device is removed from the system (when
we get there). It would be good to have something in place to remove the
attribute.

My hope was to avoid introducing a new field in the already bloated
coresight_device structure, and on top of things a component specific
field.  I think it would be worth it if we'd envision making the

I agree. May be we could add a union for the fields specific to the "Type" of
the device.

coresight drivers removable in a not so distant future.  But doing
something like that is quite tricky (as Kim quickly found out) and
skirts the bottom of the list of priorities, if on it at all.


I'll change it if you're really keen on it but it would be code that
is never used.

Yes, I understand. But we would want to get there sometime in the future,
in order to allow using the Coresight out of the box on Enterprise systems.
So it would be good to prepare towards that as we go.


Also, it makes the failure handling easier.

Cheers
Suzuki

Reply via email to