| Message ID | 20220920134827.31738-1-james.clark@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | coresight: Use new autogenerated sysreg definitions | expand |
On Tue, Sep 20, 2022 at 02:48:27PM +0100, James Clark wrote: > Fix the build by updating registers to use the new autogenerated format. > > Fixes: c0357a73fa4a ("arm64/sysreg: Align field names in ID_AA64DFR0_EL1 with architecture") > Signed-off-by: James Clark <james.clark@arm.com> In general it's better to add the build error in the commit log. I'll add one as I can reproduce it. Since it's broken by the arm64 tree, I plan to add it to the same branch (for-next/sysreg). BTW, for some reason we don't have CoreSight enabled in defconfig, not even as a module. Would you mind sending a patch for this and enable (as modules) all the relevant drivers? We miss any test coverage here. Thanks.
On Tue, Sep 20, 2022 at 05:42:38PM +0100, Catalin Marinas wrote: > BTW, for some reason we don't have CoreSight enabled in defconfig, not > even as a module. Would you mind sending a patch for this and enable (as > modules) all the relevant drivers? We miss any test coverage here. The PMU counters are in the same camp. Enabling them breaks the kernel build. I wonder whether we should go for changing the default in Kconfig directly rather than defconfig.
On Tue, Sep 20, 2022 at 06:07:34PM +0100, Catalin Marinas wrote: > On Tue, Sep 20, 2022 at 05:42:38PM +0100, Catalin Marinas wrote: > > BTW, for some reason we don't have CoreSight enabled in defconfig, not > > even as a module. Would you mind sending a patch for this and enable (as > > modules) all the relevant drivers? We miss any test coverage here. > > The PMU counters are in the same camp. Enabling them breaks the kernel > build. I wonder whether we should go for changing the default in Kconfig > directly rather than defconfig. I sent a patch for the PMU counters defconfig yesterday.
On Tue, Sep 20, 2022 at 06:56:59PM +0100, Mark Brown wrote: > On Tue, Sep 20, 2022 at 06:07:34PM +0100, Catalin Marinas wrote: > > On Tue, Sep 20, 2022 at 05:42:38PM +0100, Catalin Marinas wrote: > > > BTW, for some reason we don't have CoreSight enabled in defconfig, not > > > even as a module. Would you mind sending a patch for this and enable (as > > > modules) all the relevant drivers? We miss any test coverage here. > > > > The PMU counters are in the same camp. Enabling them breaks the kernel > > build. I wonder whether we should go for changing the default in Kconfig > > directly rather than defconfig. > > I sent a patch for the PMU counters defconfig yesterday. The defconfig patches tend to fall through the cracks. I'll try to pick some of them up. BTW, do you plan to send a patch for the arm_spe_pmu build failures (unless you did already and I missed it): linux/drivers/perf/arm_spe_pmu.c: In function 'arm_spe_pmsevfr_res0': linux/drivers/perf/arm_spe_pmu.c:677:14: error: 'ID_AA64DFR0_PMSVER_8_2' undeclared (first use in this function); did you mean 'ID_AA64DFR0_EL1_PMSVer_IMP'? 677 | case ID_AA64DFR0_PMSVER_8_2: | ^~~~~~~~~~~~~~~~~~~~~~ | ID_AA64DFR0_EL1_PMSVer_IMP linux/drivers/perf/arm_spe_pmu.c:677:14: note: each undeclared identifier is reported only once for each function it appears in linux/drivers/perf/arm_spe_pmu.c:679:14: error: 'ID_AA64DFR0_PMSVER_8_3' undeclared (first use in this function); did you mean 'ID_AA64DFR0_EL1_PMSVer_IMP'? 679 | case ID_AA64DFR0_PMSVER_8_3: | ^~~~~~~~~~~~~~~~~~~~~~ | ID_AA64DFR0_EL1_PMSVer_IMP linux/drivers/perf/arm_spe_pmu.c: In function '__arm_spe_pmu_dev_probe': linux/drivers/perf/arm_spe_pmu.c:961:52: error: 'ID_AA64DFR0_PMSVER_SHIFT' undeclared (first use in this function); did you mean 'ID_AA64DFR0_EL1_PMSVer_SHIFT'? 961 | ID_AA64DFR0_PMSVER_SHIFT); | ^~~~~~~~~~~~~~~~~~~~~~~~ | ID_AA64DFR0_EL1_PMSVer_SHIFT
On Tue, Sep 20, 2022 at 02:48:27PM +0100, James Clark wrote:
> Fix the build by updating registers to use the new autogenerated format.
Nathan Chancellor already sent a patch for this and the PMU
yesterday.
On Tue, Sep 20, 2022 at 07:08:16PM +0100, Catalin Marinas wrote: > BTW, do you plan to send a patch for the arm_spe_pmu build failures > (unless you did already and I missed it): Nathan sent a patch for that yesterday, I was a bit surprised you didn't pick it up yet TBH.
On Tue, Sep 20, 2022 at 07:48:09PM +0100, Mark Brown wrote: > On Tue, Sep 20, 2022 at 07:08:16PM +0100, Catalin Marinas wrote: > > > BTW, do you plan to send a patch for the arm_spe_pmu build failures > > (unless you did already and I missed it): > > Nathan sent a patch for that yesterday, I was a bit surprised you > didn't pick it up yet TBH. That's 20220919160928.3905780-1-nathan@kernel.org ("arm64/sysreg: Fix a few missed conversions).
On Tue, Sep 20, 2022 at 08:11:26PM +0100, Mark Brown wrote: > On Tue, Sep 20, 2022 at 07:48:09PM +0100, Mark Brown wrote: > > On Tue, Sep 20, 2022 at 07:08:16PM +0100, Catalin Marinas wrote: > > > > > BTW, do you plan to send a patch for the arm_spe_pmu build failures > > > (unless you did already and I missed it): > > > > Nathan sent a patch for that yesterday, I was a bit surprised you > > didn't pick it up yet TBH. > > That's 20220919160928.3905780-1-nathan@kernel.org ("arm64/sysreg: > Fix a few missed conversions). Ah, yes. I flagged it up in my inbox but forgot about it. Thanks for the reminder. I'll queue it shortly.
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index d39660a3e50c..80fefaba58ee 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -966,7 +966,7 @@ static inline bool cpu_supports_sysreg_trace(void) { u64 dfr0 = read_sysreg_s(SYS_ID_AA64DFR0_EL1); - return ((dfr0 >> ID_AA64DFR0_TRACEVER_SHIFT) & 0xfUL) > 0; + return ((dfr0 >> ID_AA64DFR0_EL1_TraceVer_SHIFT) & 0xfUL) > 0; } static bool etm4_init_sysreg_access(struct etmv4_drvdata *drvdata, @@ -1054,7 +1054,7 @@ static void cpu_detect_trace_filtering(struct etmv4_drvdata *drvdata) u64 trfcr; drvdata->trfcr = 0; - if (!cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_TRACE_FILT_SHIFT)) + if (!cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceFilt_SHIFT)) return; /* diff --git a/drivers/hwtracing/coresight/coresight-trbe.h b/drivers/hwtracing/coresight/coresight-trbe.h index 30e4d7db4f8e..98ff1b17ad07 100644 --- a/drivers/hwtracing/coresight/coresight-trbe.h +++ b/drivers/hwtracing/coresight/coresight-trbe.h @@ -20,7 +20,8 @@ static inline bool is_trbe_available(void) { u64 aa64dfr0 = read_sysreg_s(SYS_ID_AA64DFR0_EL1); - unsigned int trbe = cpuid_feature_extract_unsigned_field(aa64dfr0, ID_AA64DFR0_TRBE_SHIFT); + unsigned int trbe = cpuid_feature_extract_unsigned_field(aa64dfr0, + ID_AA64DFR0_EL1_TraceBuffer_SHIFT); return trbe >= 0b0001; }
Fix the build by updating registers to use the new autogenerated format. Fixes: c0357a73fa4a ("arm64/sysreg: Align field names in ID_AA64DFR0_EL1 with architecture") Signed-off-by: James Clark <james.clark@arm.com> --- drivers/hwtracing/coresight/coresight-etm4x-core.c | 4 ++-- drivers/hwtracing/coresight/coresight-trbe.h | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-)