On 16/01/2025 3:01 am, Jie Gan wrote:
>
>
> On 1/15/2025 8:29 PM, James Clark wrote:
>>
>>
>> On 15/01/2025 1:44 am, Jie Gan wrote:
>>>
>>>
>>> On 1/14/2025 6:07 PM, James Clark wrote:
>>>>
>>>>
>>>> On 14/01/2025 2:51 am, Jie Gan wrote:
>>>>>
>>>>>
>>>>> On 1/13/2025 8:02 PM, James Clark wrote:
>>>>>>
>>>>>>
>>>>>> On 26/12/2024 1:10 am, Jie Gan wrote:
>>>>>>> Add 'trace_id' function pointer in ops. It's responsible for
>>>>>>> retrieving the device's trace ID.
>>>>>>>
>>>>>>> Add 'struct cs_sink_data' to store the data that is needed by
>>>>>>> coresight_enable_path/coresight_disable_path. The structure
>>>>>>> will be transmitted to the helper and sink device to enable
>>>>>>> related funcationalities.
>>>>>>>
>>>>>>
>>>>>> The new cs_sink_data struct is quite specific to this change. Can
>>>>>> we start passing the path around to enable/disable functions, that
>>>>>> will allow devices to gather anything they want in the future.
>>>>>> Because we already have coresight_get_sink(path),
>>>>>> coresight_get_source(path) etc.
>>>>>>
>>>>>> And see below, but for this case we can also change the path
>>>>>> struct to contain the trace ID. Then all the new functions,
>>>>>> allocations and searches for the trace ID are unecessary. The CTCU
>>>>>> will have access to the path, and by the time its enable function
>>>>>> is called the trace ID is already assigned.
>>>>>>
>>>>>> It's also easier to understand at which point a trace ID is
>>>>>> allocated, rather than adding the trace_id() callbacks from
>>>>>> everywhere which could potentially either read or allocate. I
>>>>>> suppose that's "safer" because maybe it's not allocated, but I
>>>>>> can't see what case it would happen in reverse.
>>>>>>
>>>>> Thank you for comment. I will try this solution.
>>>>> The biggest challenge for the patch is how to correctly read
>>>>> trace_id from source device and passthrough it to helper device as
>>>>> the source device always the last one to enable. I believe your
>>>>> proposed solution is better than mine and has minimal impact on the
>>>>> basic framework, but I think we still need read_trace in source_ops
>>>>> and link_ops. Then we can read the trace_id in coresight_build_path
>>>>> function and save it to the coresight_path to avoid redundant
>>>>> searching?
>>>>>
>>>>>
>>>>>>> Signed-off-by: Jie Gan <quic_jiegan(a)quicinc.com>
>>>>>>> ---
>>>>>>> drivers/hwtracing/coresight/coresight-core.c | 59 ++++++++++++
>>>>>>> + + +----
>>>>>>> drivers/hwtracing/coresight/coresight-etb10.c | 3 +-
>>>>>>> .../hwtracing/coresight/coresight-etm-perf.c | 37 ++++++++++--
>>>>>>> .../coresight/coresight-etm3x-core.c | 30 ++++++++++
>>>>>>> .../coresight/coresight-etm4x-core.c | 29 +++++++++
>>>>>>> drivers/hwtracing/coresight/coresight-priv.h | 13 +++-
>>>>>>> drivers/hwtracing/coresight/coresight-stm.c | 22 +++++++
>>>>>>> drivers/hwtracing/coresight/coresight-sysfs.c | 24 +++++++-
>>>>>>> .../hwtracing/coresight/coresight-tmc-etf.c | 3 +-
>>>>>>> .../hwtracing/coresight/coresight-tmc-etr.c | 6 +-
>>>>>>> drivers/hwtracing/coresight/coresight-tpda.c | 20 +++++++
>>>>>>> drivers/hwtracing/coresight/coresight-trbe.c | 4 +-
>>>>>>> drivers/hwtracing/coresight/ultrasoc-smb.c | 3 +-
>>>>>>> include/linux/coresight.h | 6 ++
>>>>>>> 14 files changed, 234 insertions(+), 25 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/
>>>>>>> drivers/ hwtracing/coresight/coresight-core.c
>>>>>>> index 0a9380350fb5..2e560b425fd4 100644
>>>>>>> --- a/drivers/hwtracing/coresight/coresight-core.c
>>>>>>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>>>>>>> @@ -23,6 +23,7 @@
>>>>>>> #include "coresight-etm-perf.h"
>>>>>>> #include "coresight-priv.h"
>>>>>>> #include "coresight-syscfg.h"
>>>>>>> +#include "coresight-trace-id.h"
>>>>>>> /*
>>>>>>> * Mutex used to lock all sysfs enable and disable actions and
>>>>>>> loading and
>>>>>>> @@ -331,12 +332,12 @@ static int coresight_enable_helper(struct
>>>>>>> coresight_device *csdev,
>>>>>>> return helper_ops(csdev)->enable(csdev, mode, data);
>>>>>>> }
>>>>>>> -static void coresight_disable_helper(struct coresight_device
>>>>>>> *csdev)
>>>>>>> +static void coresight_disable_helper(struct coresight_device
>>>>>>> *csdev, void *data)
>>>>>>> {
>>>>>>> - helper_ops(csdev)->disable(csdev, NULL);
>>>>>>> + helper_ops(csdev)->disable(csdev, data);
>>>>>>> }
>>>>>>> -static void coresight_disable_helpers(struct coresight_device
>>>>>>> *csdev)
>>>>>>> +static void coresight_disable_helpers(struct coresight_device
>>>>>>> *csdev, void *data)
>>>>>>> {
>>>>>>> int i;
>>>>>>> struct coresight_device *helper;
>>>>>>> @@ -344,7 +345,7 @@ static void coresight_disable_helpers(struct
>>>>>>> coresight_device *csdev)
>>>>>>> for (i = 0; i < csdev->pdata->nr_outconns; ++i) {
>>>>>>> helper = csdev->pdata->out_conns[i]->dest_dev;
>>>>>>> if (helper && coresight_is_helper(helper))
>>>>>>> - coresight_disable_helper(helper);
>>>>>>> + coresight_disable_helper(helper, data);
>>>>>>> }
>>>>>>> }
>>>>>>> @@ -361,7 +362,7 @@ static void coresight_disable_helpers(struct
>>>>>>> coresight_device *csdev)
>>>>>>> void coresight_disable_source(struct coresight_device *csdev,
>>>>>>> void *data)
>>>>>>> {
>>>>>>> source_ops(csdev)->disable(csdev, data);
>>>>>>> - coresight_disable_helpers(csdev);
>>>>>>> + coresight_disable_helpers(csdev, NULL);
>>>>>>> }
>>>>>>> EXPORT_SYMBOL_GPL(coresight_disable_source);
>>>>>>> @@ -371,7 +372,8 @@ EXPORT_SYMBOL_GPL(coresight_disable_source);
>>>>>>> * disabled.
>>>>>>> */
>>>>>>> static void coresight_disable_path_from(struct list_head *path,
>>>>>>> - struct coresight_node *nd)
>>>>>>> + struct coresight_node *nd,
>>>>>>> + void *sink_data)
>>>>>>> {
>>>>>>> u32 type;
>>>>>>> struct coresight_device *csdev, *parent, *child;
>>>>>>> @@ -417,13 +419,13 @@ static void
>>>>>>> coresight_disable_path_from(struct list_head *path,
>>>>>>> }
>>>>>>> /* Disable all helpers adjacent along the path last */
>>>>>>> - coresight_disable_helpers(csdev);
>>>>>>> + coresight_disable_helpers(csdev, sink_data);
>>>>>>> }
>>>>>>> }
>>>>>>> -void coresight_disable_path(struct list_head *path)
>>>>>>> +void coresight_disable_path(struct list_head *path, void
>>>>>>> *sink_data)
>>>>>>> {
>>>>>>> - coresight_disable_path_from(path, NULL);
>>>>>>> + coresight_disable_path_from(path, NULL, sink_data);
>>>>>>> }
>>>>>>> EXPORT_SYMBOL_GPL(coresight_disable_path);
>>>>>>> @@ -505,10 +507,47 @@ int coresight_enable_path(struct list_head
>>>>>>> *path, enum cs_mode mode,
>>>>>>> out:
>>>>>>> return ret;
>>>>>>> err:
>>>>>>> - coresight_disable_path_from(path, nd);
>>>>>>> + coresight_disable_path_from(path, nd, sink_data);
>>>>>>> goto out;
>>>>>>> }
>>>>>>> +int coresight_read_traceid(struct list_head *path, enum cs_mode
>>>>>>> mode,
>>>>>>> + struct coresight_trace_id_map *id_map)
>>>>>>> +{
>>>>>>> + int trace_id, type;
>>>>>>> + struct coresight_device *csdev;
>>>>>>> + struct coresight_node *nd;
>>>>>>> +
>>>>>>> + list_for_each_entry(nd, path, link) {
>>>>>>
>>>>>> What do you think about also changing the path to this:
>>>>>>
>>>>>> struct coresight_path {
>>>>>> struct list_head *path,
>>>>>> u8 trace_id
>>>>>> };
>>>>>>
>>>>> That's better, I can simplify the coresight_read_traceid function
>>>>> without traverse the path.
>>>>>
>>>>> But we still need to check the type of the coresight device,
>>>>> because the TPDM does not have traceid and we use the trace_id from
>>>>> the TPDA device that the TPDM connected. That's why I added
>>>>> trace_id to link_ops.
>>>>>
>>>>
>>>> But if any device that allocates a trace ID saves it into the path,
>>>> then as long as any other device that needs the ID is enabled after
>>>> that it just reads it from the path directly. Assuming we pass the
>>>> path to every enable and disable function.
>>>>
>>>> We wouldn't need coresight_read_traceid() if it always happens that
>>>> way around, which I think it currently does?
>>>>
>>> I got your point here. You are right. If we passed path to the helper
>>> device, just use coresight_get_source to obtain the source device,
>>> then call the source_ops->trace_id to obtain the trace_id. So we
>>> definitely dont need a standalone function, coresight_read_traceid().
>>>
>>> Besides, I still need a function to retrive the trace_id of the TPDA
>>> device if the source device is TPDM, right?
>>>
>>>
>>> Thanks,
>>> Jie
>>>
>>
>> Yes, and that would require a search as the TPDA not always at one end
>> of the path like coresight_get_source() and coresight_get_sink().
>> Which is why I was thinking it might be good to save the trace ID in
>> the path struct to avoid it.
>>
> As you proposed, I created coresight_path structure as below:
> struct coresight_path {
> struct perf_output_handle *handle;
What's the perf handle for? Seems like this change for the CTCU only
requires access to the trace_id which is added below.
> struct list_head *path;
> u8 trace_id;
> };
>
> In coresight_enable_path, I modified the parameters that transmitted to
> helper device:
> struct coresight_path *cs_path;
>
> coresight_enable_helpers(csdev, mode, sink_data) ->
> coresight_enable_helpers(csdev, mode, cs_path)
>
> The cs_path will be constructed and initialized in coresight_build_path
> function.
>
> For perf mode, the trace_id is collected within etm_setup_aux and stored
> in cs_path->trace_id to avoid extra cost of retrieving the trace_id;
>
Looks good.
> For sysfs mode, I let the CTCU device to retrieving the trace_id with
> path. The TPDA device is located close to the TPDM, making the cost of
> searching for the TPDA device acceptable.
>
> The cs_path will be stored in the same manner as the previous path.
>
> How do you think about this solution?
>
Can it not be done the same way as Perf, at least for consistency? If
the enable helper function already gets access to the path, and the path
already has the trace ID, why is any search required?
> Thanks,
> Jie
>
> [...]
>
From: Yuanfang Zhang <quic_yuanfang(a)quicinc.com>
As recommended by section 4.3.7 ("Synchronization when using system
instructions to progrom the trace unit") of ARM IHI 0064H.b, the
self-hosted trace analyzer must perform a Context synchronization
event between writing to the TRCPRGCTLR and reading the TRCSTATR.
Fixes: ebddaad09e10 ("coresight: etm4x: Add missing single-shot control API to sysfs")
Signed-off-by: Yuanfang Zhang <quic_yuanfang(a)quicinc.com>
---
Changes in V3:
1. Remove dsb(sy) after polling TRCSTATR.
2. Add isb() after polling TRCSTATR.
---
.../hwtracing/coresight/coresight-etm4x-core.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 66d44a404ad0..c6ea00bba0cc 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -531,7 +531,6 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
* As recommended by section 4.3.7 ("Synchronization when using the
* memory-mapped interface") of ARM IHI 0064D
*/
- dsb(sy);
isb();
done:
@@ -906,10 +905,25 @@ static void etm4_disable_hw(void *info)
tsb_csync();
etm4x_relaxed_write32(csa, control, TRCPRGCTLR);
+ /*
+ * As recommended by section 4.3.7 ("Synchronization when using system
+ * instructions to progrom the trace unit") of ARM IHI 0064H.b, the
+ * self-hosted trace analyzer must perform a Context synchronization
+ * event between writing to the TRCPRGCTLR and reading the TRCSTATR.
+ */
+ if (!csa->io_mem)
+ isb();
+
/* wait for TRCSTATR.PMSTABLE to go to '1' */
if (coresight_timeout(csa, TRCSTATR, TRCSTATR_PMSTABLE_BIT, 1))
dev_err(etm_dev,
"timeout while waiting for PM stable Trace Status\n");
+ /*
+ * As recommended by section 4.3.7 (Synchronization of register updates)
+ * of ARM IHI 0064H.b.
+ */
+ isb();
+
/* read the status of the single shot comparators */
for (i = 0; i < drvdata->nr_ss_cmp; i++) {
config->ss_status[i] =
--
2.34.1
On 14/01/2025 6:16 pm, Rob Herring wrote:
> On Mon, Jan 13, 2025 at 10:49 AM Marc Zyngier <maz(a)kernel.org> wrote:
>>
>> On Mon, 13 Jan 2025 15:43:39 +0000,
>> James Clark <james.clark(a)linaro.org> wrote:
>>>
>>>
>>>
>>> On 12/01/2025 12:49 pm, Marc Zyngier wrote:
>>>> On Tue, 07 Jan 2025 11:32:41 +0000,
>>>> James Clark <james.clark(a)linaro.org> wrote:
>>>>>
>>>>> From: James Clark <james.clark(a)arm.com>
>>>>>
>>>>> There are a few entries particularly at the end of the file that aren't
>>>>> in order. To avoid confusion, add a comment that might help new entries
>>>>> to be added in the right place.
>>>>>
>>>>> Reviewed-by: Mark Brown <broonie(a)kernel.org>
>>>>> Signed-off-by: James Clark <james.clark(a)arm.com>
>>>>> Signed-off-by: James Clark <james.clark(a)linaro.org>
>>>>> ---
>>>>> arch/arm64/tools/sysreg | 2 ++
>>>>> 1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
>>>>> index b081b54d6d22..4ba167089e2a 100644
>>>>> --- a/arch/arm64/tools/sysreg
>>>>> +++ b/arch/arm64/tools/sysreg
>>>>> @@ -48,6 +48,8 @@
>>>>> # feature that introduces them (eg, FEAT_LS64_ACCDATA introduces enumeration
>>>>> # item ACCDATA) though it may be more taseful to do something else.
>>>>> +# Please try to keep entries in this file sorted by sysreg
>>>>> encoding.
>>>>> +
>>>>> Sysreg OSDTRRX_EL1 2 0 0 0 2
>>>>> Res0 63:32
>>>>> Field 31:0 DTRRX
>>>>
>>>> "Do as I say, don't do as I do".
>>>>
>>>> I don't think this makes any sense if we don't actually sort the file
>>>> the first place.
>>>>
>>>> M.
>>>>
>>>
>>> I think it's ok if it avoids review comments that new entries should
>>> be sorted. Or maybe we do the opposite and the comment should say this
>>> file is allowed to be unsorted...
>>
>> The better option would be to add the comment *and* sort the file.
>> Leading by example has some value, it seems.
>
> IME, it's better if documentation just states what the tools enforce.
>
> Can't we add something like this to the header generation:
>
> $ grep '^Sysreg\s' arch/arm64/tools/sysreg | sort -n -k3 -k4 -k5 -k6 -k7 -c
> sort: -:22: disorder: Sysreg ID_MMFR4_EL1 3 0 0
> 2 6
>
> Rob
Actually I updated gen-sysreg.awk to fail the build if it's not sorted,
was just about to post it. I don't know if a build failure or a warning
is preferred but I can do either.
James
On Tue, Jan 14, 2025 at 11:35:44AM -0800, Charlie Jenkins wrote:
> The variables to make builds silent/verbose live inside
> tools/build/Makefile.build. Move those variables to the top-level
> Makefile.perf to be generally available.
>
> Committer testing:
Re-tested, now the lines below continue to appear, and also the 'make -C
tools/perf build-test' that was failiong on the first patch submission
is now ok as well, so I re issue my:
Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
At this point this will go thru Namhyung, that will process patches
while I'm in vacation for perf-tools-next as well, thanks!
- Arnaldo
> See the SYSCALL lines, now they are consistent with the other
> operations in other lines:
> SYSTBL /tmp/build/perf-tools-next/arch/x86/include/generated/asm/syscalls_32.h
> SYSTBL /tmp/build/perf-tools-next/arch/x86/include/generated/asm/syscalls_64.h
> GEN /tmp/build/perf-tools-next/common-cmds.h
> GEN /tmp/build/perf-tools-next/arch/arm64/include/generated/asm/sysreg-defs.h
> PERF_VERSION = 6.13.rc2.g3d94bb6ed1d0
> GEN perf-archive
> MKDIR /tmp/build/perf-tools-next/jvmti/
> MKDIR /tmp/build/perf-tools-next/jvmti/
> MKDIR /tmp/build/perf-tools-next/jvmti/
> MKDIR /tmp/build/perf-tools-next/jvmti/
> GEN perf-iostat
> CC /tmp/build/perf-tools-next/jvmti/libjvmti.o
>
> Reported-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
> Signed-off-by: Charlie Jenkins <charlie(a)rivosinc.com>
> Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
> ---
> tools/build/Makefile.build | 20 -----------------
> tools/perf/Makefile.perf | 37 ++++++++++++++++++++++++++++++-
> tools/perf/tests/shell/coresight/Makefile | 2 +-
> 3 files changed, 37 insertions(+), 22 deletions(-)
>
> diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
> index 5fb3fb3d97e0fd114e245805809e4fc926b4343e..e710ed67a1b49d9fda11db02821bbd8d36066b44 100644
> --- a/tools/build/Makefile.build
> +++ b/tools/build/Makefile.build
> @@ -12,26 +12,6 @@
> PHONY := __build
> __build:
>
> -ifeq ($(V),1)
> - quiet =
> - Q =
> -else
> - quiet=quiet_
> - Q=@
> -endif
> -
> -# If the user is running make -s (silent mode), suppress echoing of commands
> -# make-4.0 (and later) keep single letter options in the 1st word of MAKEFLAGS.
> -ifeq ($(filter 3.%,$(MAKE_VERSION)),)
> -short-opts := $(firstword -$(MAKEFLAGS))
> -else
> -short-opts := $(filter-out --%,$(MAKEFLAGS))
> -endif
> -
> -ifneq ($(findstring s,$(short-opts)),)
> - quiet=silent_
> -endif
> -
> build-dir := $(srctree)/tools/build
>
> # Define $(fixdep) for dep-cmd function
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index a449d0015536442273a9268b37be34e4757f577a..55d6ce9ea52fb2a57b8632cc6d0ddc501e29cbfc 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -161,12 +161,47 @@ export VPATH
> SOURCE := $(shell ln -sf $(srctree)/tools/perf $(OUTPUT)/source)
> endif
>
> +# Beautify output
> +# ---------------------------------------------------------------------------
> +#
> +# Most of build commands in Kbuild start with "cmd_". You can optionally define
> +# "quiet_cmd_*". If defined, the short log is printed. Otherwise, no log from
> +# that command is printed by default.
> +#
> +# e.g.)
> +# quiet_cmd_depmod = DEPMOD $(MODLIB)
> +# cmd_depmod = $(srctree)/scripts/depmod.sh $(DEPMOD) $(KERNELRELEASE)
> +#
> +# A simple variant is to prefix commands with $(Q) - that's useful
> +# for commands that shall be hidden in non-verbose mode.
> +#
> +# $(Q)$(MAKE) $(build)=scripts/basic
> +#
> +# To put more focus on warnings, be less verbose as default
> +# Use 'make V=1' to see the full commands
> +
> ifeq ($(V),1)
> + quiet =
> Q =
> else
> - Q = @
> + quiet=quiet_
> + Q=@
> endif
>
> +# If the user is running make -s (silent mode), suppress echoing of commands
> +# make-4.0 (and later) keep single letter options in the 1st word of MAKEFLAGS.
> +ifeq ($(filter 3.%,$(MAKE_VERSION)),)
> +short-opts := $(firstword -$(MAKEFLAGS))
> +else
> +short-opts := $(filter-out --%,$(MAKEFLAGS))
> +endif
> +
> +ifneq ($(findstring s,$(short-opts)),)
> + quiet=silent_
> +endif
> +
> +export quiet Q
> +
> # Do not use make's built-in rules
> # (this improves performance and avoids hard-to-debug behaviour);
> MAKEFLAGS += -r
> diff --git a/tools/perf/tests/shell/coresight/Makefile b/tools/perf/tests/shell/coresight/Makefile
> index b070e779703e9fbd70f88c826172b2150ee3d302..fa08fd9a5991dd889583edc1afe8304e72278f64 100644
> --- a/tools/perf/tests/shell/coresight/Makefile
> +++ b/tools/perf/tests/shell/coresight/Makefile
> @@ -24,6 +24,6 @@ CLEANDIRS = $(SUBDIRS:%=clean-%)
>
> clean: $(CLEANDIRS)
> $(CLEANDIRS):
> - $(call QUIET_CLEAN, test-$(@:clean-%=%)) $(Q)$(MAKE) -C $(@:clean-%=%) clean >/dev/null
> + $(call QUIET_CLEAN, test-$(@:clean-%=%)) $(MAKE) -C $(@:clean-%=%) clean >/dev/null
>
> .PHONY: all clean $(SUBDIRS) $(CLEANDIRS) $(INSTALLDIRS)
>
> ---
> base-commit: e9cbc854d8b148e3491291fb615e94261970fb54
> change-id: 20250114-perf_make_test-1141d4ad8877
> --
> - Charlie
On 10/01/2025 21:32, Ilkka Koskinen wrote:
>
> Hi Suzuko,
>
> On Fri, 10 Jan 2025, Suzuki K Poulose wrote:
>> On 09/01/2025 21:53, Ilkka Koskinen wrote:
>>> Trying to record a trace on kernel with 64k pages resulted in -ENOMEM.
>>> This happens due to a bug in calculating the number of table pages,
>>> which
>>> returns zero. Fix the issue by rounding up.
>>>
>>> $ perf record --kcore -e cs_etm/@tmc_etr55,cycacc,branch_broadcast/k
>>> --per-thread taskset --cpu-list 1 dd if=/dev/zero of=/dev/null
>>> failed to mmap with 12 (Cannot allocate memory)
>>>
>>
>> Needs a Fixes tag.
>>
>> Fixes : 8ed536b1e283 ("coresight: catu: Add support for scatter gather
>> tables")
>
> That's a good point
>
>>
>>> Signed-off-by: Ilkka Koskinen <ilkka(a)os.amperecomputing.com>
>>> ---
>>> drivers/hwtracing/coresight/coresight-catu.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/
>>> hwtracing/coresight/coresight-catu.c
>>> index 275cc0d9f505..3378bb77e6b4 100644
>>> --- a/drivers/hwtracing/coresight/coresight-catu.c
>>> +++ b/drivers/hwtracing/coresight/coresight-catu.c
>>> @@ -269,7 +269,7 @@ catu_init_sg_table(struct device *catu_dev, int
>>> node,
>>> * Each table can address upto 1MB and we can have
>>> * CATU_PAGES_PER_SYSPAGE tables in a system page.
>>> */
>>> - nr_tpages = DIV_ROUND_UP(size, SZ_1M) / CATU_PAGES_PER_SYSPAGE;
>>> + nr_tpages = DIV_ROUND_UP(size, CATU_PAGES_PER_SYSPAGE * SZ_1M);
>>> catu_table = tmc_alloc_sg_table(catu_dev, node, nr_tpages,
>>> size >> PAGE_SHIFT, pages);
>>> if (IS_ERR(catu_table))
>>
>> Looks good to me, I will queue this later for v6.15.
>>
>> Suzuki
>
> Sounds great. Just to confirm, are you ok to add the fixes line or would
> you prefer me to submit v2 with it?
No, not required. I have picked this up for v6.15, and will push it out
once v6.14-rc is out.
Suzuki
>
> Cheers, Ilkka
On 13/01/2025 3:28 pm, Marc Zyngier wrote:
> On Mon, 13 Jan 2025 15:07:21 +0000,
> Mark Brown <broonie(a)kernel.org> wrote:
>>
>> [1 <text/plain; us-ascii (quoted-printable)>]
>> On Mon, Jan 06, 2025 at 02:24:37PM +0000, James Clark wrote:
>>> From: James Clark <james.clark(a)arm.com>
>>>
>>> Created with the following:
>>>
>>> cp include/linux/kasan-tags.h tools/include/linux/
>>> cp arch/arm64/include/asm/sysreg.h tools/arch/arm64/include/asm/
>>>
>>> Update the tools copy of sysreg.h so that the next commit to add a new
>>> register doesn't have unrelated changes in it. Because the new version
>>> of sysreg.h includes kasan-tags.h, that file also now needs to be copied
>>> into tools.
>>
>> This breaks the build of the KVM selftests:
>>
>> aarch64/aarch32_id_regs.c:150:16: error: use of undeclared identifier 'ID_AA64PFR0_EL1_ELx_64BIT_ONLY'
>> 150 | return el0 == ID_AA64PFR0_EL1_ELx_64BIT_ONLY;
>> | ^
>> 1 warning and 1 error generated.
>>
>> since it's pulled over the changes in 056600ff7330 ("arm64/cpufeature:
>> Replace custom macros with fields from ID_AA64PFR0_EL1") but not updated
>> the test to reflect this.
>
> Thanks for the heads up. I've stashed a fix on top, which hopefully
> will be in next tomorrow.
>
> M.
>
Oops sorry about that. I only tested the Perf build and hadn't done the
self tests for a few versions.
Thanks for making the fix.
On 12/01/2025 12:49 pm, Marc Zyngier wrote:
> On Tue, 07 Jan 2025 11:32:41 +0000,
> James Clark <james.clark(a)linaro.org> wrote:
>>
>> From: James Clark <james.clark(a)arm.com>
>>
>> There are a few entries particularly at the end of the file that aren't
>> in order. To avoid confusion, add a comment that might help new entries
>> to be added in the right place.
>>
>> Reviewed-by: Mark Brown <broonie(a)kernel.org>
>> Signed-off-by: James Clark <james.clark(a)arm.com>
>> Signed-off-by: James Clark <james.clark(a)linaro.org>
>> ---
>> arch/arm64/tools/sysreg | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
>> index b081b54d6d22..4ba167089e2a 100644
>> --- a/arch/arm64/tools/sysreg
>> +++ b/arch/arm64/tools/sysreg
>> @@ -48,6 +48,8 @@
>> # feature that introduces them (eg, FEAT_LS64_ACCDATA introduces enumeration
>> # item ACCDATA) though it may be more taseful to do something else.
>>
>> +# Please try to keep entries in this file sorted by sysreg encoding.
>> +
>> Sysreg OSDTRRX_EL1 2 0 0 0 2
>> Res0 63:32
>> Field 31:0 DTRRX
>
> "Do as I say, don't do as I do".
>
> I don't think this makes any sense if we don't actually sort the file
> the first place.
>
> M.
>
I think it's ok if it avoids review comments that new entries should be
sorted. Or maybe we do the opposite and the comment should say this file
is allowed to be unsorted...