Good day to all,
The CS specification defines replicators that are not showing on the AMBA bus and can't be configured - they simply provide a hard wire between components. Earlier this week someone wrote to me on the open mailing list asking for guidance in dealing with a new type of funnel their company has introduced in a design. Just like a replicator it doesn't show up on the AMBA bus and can't be configured.
It makes sense to deal with this new component the same way we do with the above-mentioned replicator, i.e use a platform driver that does nothing and add it to the CS topology when specified in the device tree. It also make sense to re-use the same code [1] for that.
But moving forward with this also means we need to re-brand the current coresight-replicator.c file, along with adding new "compatible" strings. Here is what I suggest:
1) Keep the "arm,coresight-replicator" compatible string for backward compatibility (I'm seriously tempted not to [2]). 2) Add a new "arm,coresight-hw-replicator" compatible string for replicators that don't show up on the AMBA bus. 3) Add a new "arm,coresight-hw-funnel" compatible string for funnels that don't show up on the AMBA bus. 4) Use a match table to deal with the above two new compatible string and the old one (if we keep it around). 5) Rename coresight-replicator.c to coresight-hw-link.c.
I'm reaching out to the list because once we have a naming convention it is hard to modify it. Let me know what you think of the above.
Thanks, Mathieu
[1]. https://elixir.bootlin.com/linux/latest/source/drivers/hwtracing/coresight/c... [2]. We could also delete the old "arm,coresight-replicator" and make the changes in the DT for current users. People that haven't upstream their in-house solution will have to adapt, but that's something that happens with all the out-of-tree code.