Hi Suzuki,

On Wed, 23 Sep 2020 at 12:47, Suzuki K Poulose [off-list ref] wrote:

Hi Mike

On 09/18/2020 04:35 PM, Mike Leach wrote:

quoted

Hi Suzuki,

On Fri, 11 Sep 2020 at 09:41, Suzuki K Poulose [off-list ref] wrote:

quoted

Add support for devices with system instruction access only.
They don't have a memory mapped interface and thus are not
AMBA devices.

Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
  drivers/hwtracing/coresight/coresight-etm4x.c | 42 ++++++++++++++++++-
  1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index 7d5f942c2108..212713ffa37e 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c

@@ -26,6 +26,7 @@
  #include <linux/seq_file.h>
  #include <linux/uaccess.h>
  #include <linux/perf_event.h>
+#include <linux/platform_device.h>
  #include <linux/pm_runtime.h>
  #include <linux/property.h>
  #include <asm/sections.h>

@@ -1712,6 +1713,20 @@ static int etm4_probe_amba(struct amba_device *adev, const struct amba_id *id)
         return ret;
  }

+static int etm4_probe_platform_dev(struct platform_device *pdev)
+{
+       int ret;
+
+       pm_runtime_get_noresume(&pdev->dev);
+       pm_runtime_set_active(&pdev->dev);
+       pm_runtime_enable(&pdev->dev);
+

Right about here is where I would expect the sysreg access to
TRCDEVARCH etc, to determine if this is an ETM device that can be
supported by the driver.
This matches approximately the similar ID table checks that the AMBA
driver did to ensure a valid device match.

The problem is, we have to do this on the target CPU and later do another
one for feature check.

quoted

This logically separates "is this a device we support" from "what
features does this supported device have"

The additional point is that it also keeps the register access
specific code encapsulated in the register access specific area. The
whole point of the access abstraction is that the common code just
works.
Is it not better that the access decision is made as early as possible
and the access abstraction is set up, then the more code is common and
maintenance is easier going forwards?

While I understand the logical argument, it doesn't buy us much. Even now we do an
additional check on the supported architecture in the etm4x_probe() anyway and reject
the unsupported CPUs there.

I do question the value of that check. It's been around since the
start of the driver, but perhaps has outlived its usefulness.

Even in the AMBA memory mapped case, by the time we get there, we have
matched the device based on supplied part numbers & binding
information in the device tree, so checking 4 bits (major version
number) out of a register does seem curious! If we have somehow got a
bunch of other things wrong, there is a 1 in 16 chance that this check
will fail too with a false positive.

Obviously I can see why you wouldn't want to rely on just that to
validate the component type for register access - DEVARCH is far
better for that use case.

The etmv3 version is a little more interesting - it checks 8 bits,
both maj and min versions, with specific checks on 3.3, 3.5, 1.0 and
1.1 (pft),

The remainder of the coresight drivers simply trust the part number
detection mechanisms.
Would it not be more consistent to do the same for ETMv4 as well?

The only change here is we move the supported architecture
check in to the etm4_init_arch_data() and stop the hard work if it is not supported.

I would prefer to keep the current method if possible, while cleaning up the detection
of the supported (old) devices as agreed in the other patch.


Cheers
Suzuki

Cheers

Mike

-- 
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK

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