Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 18 Oct 2023 09:28:59 +0100 | Subject | Re: [PATCH] coresight: etm4x: Enable ETE device accessed via MMIO | From | Suzuki K Poulose <> |
| |
On 18/10/2023 08:05, Ruidong Tian wrote: > The ETM4X driver now assume that all ETE as CPU system instructions > accessed device, in fact the ETE device on some machines also accessed > via MMIO. > > Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com>
Why are we going backwards to MMIO from system instructions ? Is it because of an "unfriendly" hypervisor preventing access ?
As such, without a sufficiently acceptable explanation, I am reluctant to make this change
Suzuki
> --- > drivers/hwtracing/coresight/coresight-etm4x-core.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index 285539104bcc..ad298c9cc87e 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -1103,8 +1103,9 @@ static bool etm4_init_iomem_access(struct etmv4_drvdata *drvdata, > * with MMIO. But we cannot touch the OSLK until we are > * sure this is an ETM. So rely only on the TRCDEVARCH. > */ > - if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH) { > - pr_warn_once("TRCDEVARCH doesn't match ETMv4 architecture\n"); > + if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH && > + (devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETE_ARCH) { > + pr_warn_once("TRCDEVARCH doesn't match ETMv4/ETE architecture\n"); > return false; > } >
| ![\](/images/icornerr.gif) |