On 10/18/24 19:38, Zhen Lei wrote:
> Function devm_kzalloc() returns NULL instead of ERR_PTR() when it fails.
Right, devm_kzalloc() calls devm_kmalloc() with additional __GFP_ZERO which
returns NULL on error.
> The IS_ERR() test in the return value check should be replaced with NULL
> test.
>
> Fixes: 39744738a67d ("coresight: trbe: Allocate platform data per device")
> Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver")
Actually this problem is caused by the following commit which had replaced
coresight_get_platform_data() with devm_kzalloc() for a dummy 'desc.pdata'
allocation. Earlier IS_ERR() test for the return value, was correct for
coresight_get_platform_data() which returns ERR_PTR() on error, but then
it should have been changed for devm_kzalloc() into a NULL check instead.
4277f035d227 ("coresight: trbe: Add a representative coresight_platform_data for TRBE")
Please add "Fixes:" tag for the above commit instead.
> Signed-off-by: Zhen Lei <thunder.leizhen(a)huawei.com>
> ---
> drivers/hwtracing/coresight/coresight-trbe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
> index 96a32b213669940..93fe9860acf16bd 100644
> --- a/drivers/hwtracing/coresight/coresight-trbe.c
> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
> @@ -1266,7 +1266,7 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp
> * into the device for that purpose.
> */
> desc.pdata = devm_kzalloc(dev, sizeof(*desc.pdata), GFP_KERNEL);
> - if (IS_ERR(desc.pdata))
> + if (!desc.pdata)
> goto cpu_clear;
>
> desc.type = CORESIGHT_DEV_TYPE_SINK;
Reviewed-by: Anshuman Khandual <anshuman.khandual(a)arm.com>
On 18/10/2024 3:08 pm, Zhen Lei wrote:
> Function devm_kzalloc() returns NULL instead of ERR_PTR() when it fails.
> The IS_ERR() test in the return value check should be replaced with NULL
> test.
>
> Fixes: 39744738a67d ("coresight: trbe: Allocate platform data per device")
> Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver")
I don't think the code that this patches exists in 3fbf7f011f24, but it
looks ok for 39744738a67d.
> Signed-off-by: Zhen Lei <thunder.leizhen(a)huawei.com>
> ---
> drivers/hwtracing/coresight/coresight-trbe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
> index 96a32b213669940..93fe9860acf16bd 100644
> --- a/drivers/hwtracing/coresight/coresight-trbe.c
> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
> @@ -1266,7 +1266,7 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp
> * into the device for that purpose.
> */
> desc.pdata = devm_kzalloc(dev, sizeof(*desc.pdata), GFP_KERNEL);
> - if (IS_ERR(desc.pdata))
> + if (!desc.pdata)
> goto cpu_clear;
>
> desc.type = CORESIGHT_DEV_TYPE_SINK;
Reviewed-by: James Clark <james.clark(a)linaro.org>
On 18/10/2024 11:31, Krzysztof Kozlowski wrote:
> On 18/10/2024 12:08, Suzuki K Poulose wrote:
>> On 18/10/2024 11:05, Krzysztof Kozlowski wrote:
>>> On 17/10/2024 09:23, Tao Zhang wrote:
>>>>
>>>> On 10/9/2024 6:52 PM, Suzuki K Poulose wrote:
>>>>> Krzysztof
>>>>>
>>>>> On 22/08/2024 12:50, Suzuki K Poulose wrote:
>>>>>> On 22/08/2024 11:34, Suzuki K Poulose wrote:
>>>>>>> On 22/08/2024 08:08, Krzysztof Kozlowski wrote:
>>>>>>>> On Wed, Aug 21, 2024 at 11:38:55AM +0100, Suzuki K Poulose wrote:
>>>>>>>>> On 21/08/2024 04:13, Tao Zhang wrote:
>>>>>>>>>> The is some "magic" hard coded filtering in the replicators,
>>>>>>>>>> which only passes through trace from a particular "source". Add
>>>>>>>>>> a new property "filter-src" to label a phandle to the coresight
>>>>>>>>>> trace source device matching the hard coded filtering for the port.
>>>>>>>>>
>>>>>>>>> Minor nit: Please do not use abbreviate "source" in the bindings.
>>>>>>>>> I am not an expert on other changes below and will leave it to
>>>>>>>>> Rob/Krzysztof to comment.
>>>>>>>>>
>>>>>>>>> Rob, Krzysztof,
>>>>>>>>>
>>>>>>>>> We need someway to "link" (add a phandle) from a "port". The patch
>>>>>>>>> below
>>>>>>>>> is extending "standard" port to add a phandle. Please let us know if
>>>>>>>>> there is a better way.
>>>>>>>>>
>>>>>>>>> e.g.:
>>>>>>>>>
>>>>>>>>> filters = list of tuples of port, phandle. ?
>>>>>>>>>
>>>>>>>>> e.g.:
>>>>>>>>>
>>>>>>>>> filters = < 0, <&tpdm_video>,
>>>>>>>>> 1, <&tpdm_mdss>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>
>>>>>>>> Current solution feels like band-aid - what if next time you need some
>>>>>>>> second filter? Or "wall"? Or whatever? Next property?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Isn't filter just one endpoint in the graph?
>>>>>>>>
>>>>>>>> A <--> filter <--> B
>>>>>>>
>>>>>>> To be more precise, "Filter" is a "port (p0, p1, p2 below)" (among a
>>>>>>> multi output ports).
>>>>>>>
>>>>>>> For clearer example:
>>>>>>>
>>>>>>> A0 <--> .. <--> ..\ p0 / --> Filtered for (A1)
>>>>>>> <--> B1
>>>>>>> A1 <--> .. <--> .. - < L(filters> p1 - --> Filtered for (A2)
>>>>>>> <--> B2
>>>>>>> A2 <--> .. <--> ../ p2 \ --> Unfiltered
>>>>>>> <--> B0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Instead of
>>>>>>>>
>>>>>>>> A <----through-filter----> B?
>>>>>>>
>>>>>>> The problem is we need to know the components in the path from A0 to X
>>>>>>> through, (Not just A0 and L). And also we need to know "which port
>>>>>>> (p0 vs p1 vs p2)" does the traffic take from a source (A0/A1/A2) out
>>>>>>> of the
>>>>>>> link "L".
>>>>>>>
>>>>>>> So ideally, we need a way to tie p0 -> A1, p1 -> A2.
>>>>>>>
>>>>>>> would we need something else in the future ? I don't know for sure.
>>>>>>> People could design their own things ;-). But this was the first time
>>>>>>> ever in the last 12yrs since we supported coresight in the kernel.
>>>>>>> (there is always a first time).
>>>>>>>
>>>>>>> Fundamentally, the "ports" cannot have additional properties today.
>>>>>>> Not sure if there are other usecases (I don't see why). So, we have
>>>>>>> to manually extend like above, which I think is not nice.
>>>>>>
>>>>>> Replying to the other thread [0], made me realize that the above is not
>>>>>> true. Indeed it is possible to add properties for endpoints, e.g:
>>>>>>
>>>>>> e.g.: media/video-interfaces.yaml
>>>>>>
>>>>>> So extending the endpoint node is indeed acceptable (unlike I thought).
>>>>>> May be the we it is achieved in this patch is making it look otherwise.
>>>>>>
>>>>>> Suzuki
>>>>>> [0]
>>>>>> https://lkml.kernel.org/r/4b51d5a9-3706-4630-83c1-01b01354d9a4@arm.com
>>>>>
>>>>> Please could you let us know if it is acceptable to extend "endpoint"
>>>>> node to have an optional property ?
>>>>
>>>> Hi Krzysztof,
>>>>
>>>>
>>>> Kindly reminder, could you help comment on this?
>>>
>>> I don't have any smart ideas and with earlier explanation sounds ok.
>>
>> Just to confirm, are you OK with adding a property to the "endpoint"
>> node that will indicate a phandle that the device allows on this
>> endpoint ?
>
> You mean the filter property in endpoint? if so, then yes.
Thanks for confirming !
Cheers
Suzuki
>
> Best regards,
> Krzysztof
>
On 24/07/2024 20:13, Krzysztof Kozlowski wrote:
> On 03/07/2024 14:23, Mao Jinlong wrote:
>> Current name of coresight component's folder consists of prefix of
>> the device and the id in the device list. When run 'ls' command,
>> we can get the register address of the device. Take CTI for example,
>> if we want to set the config for modem CTI, but we can't know which
>> CTI is modem CTI from all current information.
>>
>> cti_sys0 -> ../../../devices/platform/soc(a)0/138f0000.cti/cti_sys0
>> cti_sys1 -> ../../../devices/platform/soc(a)0/13900000.cti/cti_sys1
>>
>> Add device-name in device tree which can provide a better description
>> of the coresight device. It can provide the info like the system or
>> HW it belongs to.
>>
>> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com>
>> ---
>> .../devicetree/bindings/arm/arm,coresight-cti.yaml | 6 ++++++
>> .../devicetree/bindings/arm/arm,coresight-dummy-source.yaml | 6 ++++++
>> .../devicetree/bindings/arm/arm,coresight-stm.yaml | 6 ++++++
>> .../devicetree/bindings/arm/qcom,coresight-tpdm.yaml | 6 ++++++
>> 4 files changed, 24 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
>> index 2d5545a2b49c..6a73eaa66a42 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
>> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
>> @@ -98,6 +98,12 @@ properties:
>> power-domains:
>> maxItems: 1
>>
>> + arm,cs-dev-name:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description:
>> + Define the name which can describe what kind of HW or system the
>> + coresight device belongs to.
>
> Don't we use already label for such cases? Power domains, input, leds,
> panels, IIO, hwmon and more.
We do and if we can get hold of them, that would be ideal. but do we get
them in the binary DT blob ? At least I couldn't see them on my Juno
dtb.
Cheers
Suzuki
>
> Best regards,
> Krzysztof
>
On 18/10/2024 11:05, Krzysztof Kozlowski wrote:
> On 17/10/2024 09:23, Tao Zhang wrote:
>>
>> On 10/9/2024 6:52 PM, Suzuki K Poulose wrote:
>>> Krzysztof
>>>
>>> On 22/08/2024 12:50, Suzuki K Poulose wrote:
>>>> On 22/08/2024 11:34, Suzuki K Poulose wrote:
>>>>> On 22/08/2024 08:08, Krzysztof Kozlowski wrote:
>>>>>> On Wed, Aug 21, 2024 at 11:38:55AM +0100, Suzuki K Poulose wrote:
>>>>>>> On 21/08/2024 04:13, Tao Zhang wrote:
>>>>>>>> The is some "magic" hard coded filtering in the replicators,
>>>>>>>> which only passes through trace from a particular "source". Add
>>>>>>>> a new property "filter-src" to label a phandle to the coresight
>>>>>>>> trace source device matching the hard coded filtering for the port.
>>>>>>>
>>>>>>> Minor nit: Please do not use abbreviate "source" in the bindings.
>>>>>>> I am not an expert on other changes below and will leave it to
>>>>>>> Rob/Krzysztof to comment.
>>>>>>>
>>>>>>> Rob, Krzysztof,
>>>>>>>
>>>>>>> We need someway to "link" (add a phandle) from a "port". The patch
>>>>>>> below
>>>>>>> is extending "standard" port to add a phandle. Please let us know if
>>>>>>> there is a better way.
>>>>>>>
>>>>>>> e.g.:
>>>>>>>
>>>>>>> filters = list of tuples of port, phandle. ?
>>>>>>>
>>>>>>> e.g.:
>>>>>>>
>>>>>>> filters = < 0, <&tpdm_video>,
>>>>>>> 1, <&tpdm_mdss>
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>> Current solution feels like band-aid - what if next time you need some
>>>>>> second filter? Or "wall"? Or whatever? Next property?
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Isn't filter just one endpoint in the graph?
>>>>>>
>>>>>> A <--> filter <--> B
>>>>>
>>>>> To be more precise, "Filter" is a "port (p0, p1, p2 below)" (among a
>>>>> multi output ports).
>>>>>
>>>>> For clearer example:
>>>>>
>>>>> A0 <--> .. <--> ..\ p0 / --> Filtered for (A1)
>>>>> <--> B1
>>>>> A1 <--> .. <--> .. - < L(filters> p1 - --> Filtered for (A2)
>>>>> <--> B2
>>>>> A2 <--> .. <--> ../ p2 \ --> Unfiltered
>>>>> <--> B0
>>>>>
>>>>>
>>>>>
>>>>>> Instead of
>>>>>>
>>>>>> A <----through-filter----> B?
>>>>>
>>>>> The problem is we need to know the components in the path from A0 to X
>>>>> through, (Not just A0 and L). And also we need to know "which port
>>>>> (p0 vs p1 vs p2)" does the traffic take from a source (A0/A1/A2) out
>>>>> of the
>>>>> link "L".
>>>>>
>>>>> So ideally, we need a way to tie p0 -> A1, p1 -> A2.
>>>>>
>>>>> would we need something else in the future ? I don't know for sure.
>>>>> People could design their own things ;-). But this was the first time
>>>>> ever in the last 12yrs since we supported coresight in the kernel.
>>>>> (there is always a first time).
>>>>>
>>>>> Fundamentally, the "ports" cannot have additional properties today.
>>>>> Not sure if there are other usecases (I don't see why). So, we have
>>>>> to manually extend like above, which I think is not nice.
>>>>
>>>> Replying to the other thread [0], made me realize that the above is not
>>>> true. Indeed it is possible to add properties for endpoints, e.g:
>>>>
>>>> e.g.: media/video-interfaces.yaml
>>>>
>>>> So extending the endpoint node is indeed acceptable (unlike I thought).
>>>> May be the we it is achieved in this patch is making it look otherwise.
>>>>
>>>> Suzuki
>>>> [0]
>>>> https://lkml.kernel.org/r/4b51d5a9-3706-4630-83c1-01b01354d9a4@arm.com
>>>
>>> Please could you let us know if it is acceptable to extend "endpoint"
>>> node to have an optional property ?
>>
>> Hi Krzysztof,
>>
>>
>> Kindly reminder, could you help comment on this?
>
> I don't have any smart ideas and with earlier explanation sounds ok.
Just to confirm, are you OK with adding a property to the "endpoint"
node that will indicate a phandle that the device allows on this
endpoint ?
Kind regards
Suzuki
>
> Best regards,
> Krzysztof
>
On 22/08/2024 08:08, Krzysztof Kozlowski wrote:
> On Wed, Aug 21, 2024 at 11:38:55AM +0100, Suzuki K Poulose wrote:
>> On 21/08/2024 04:13, Tao Zhang wrote:
>>> The is some "magic" hard coded filtering in the replicators,
>>> which only passes through trace from a particular "source". Add
>>> a new property "filter-src" to label a phandle to the coresight
>>> trace source device matching the hard coded filtering for the port.
>>
>> Minor nit: Please do not use abbreviate "source" in the bindings.
>> I am not an expert on other changes below and will leave it to
>> Rob/Krzysztof to comment.
>>
>> Rob, Krzysztof,
>>
>> We need someway to "link" (add a phandle) from a "port". The patch below
>> is extending "standard" port to add a phandle. Please let us know if
>> there is a better way.
>>
>> e.g.:
>>
>> filters = list of tuples of port, phandle. ?
>>
>> e.g.:
>>
>> filters = < 0, <&tpdm_video>,
>> 1, <&tpdm_mdss>
>> >
>>
>
> Current solution feels like band-aid - what if next time you need some
> second filter? Or "wall"? Or whatever? Next property?
>
> Isn't filter just one endpoint in the graph?
>
> A <--> filter <--> B
To be more precise, "Filter" is a "port (p0, p1, p2 below)" (among a
multi output ports).
For clearer example:
A0 <--> .. <--> ..\ p0 / --> Filtered for (A1) <--> B1
A1 <--> .. <--> .. - < L(filters> p1 - --> Filtered for (A2) <--> B2
A2 <--> .. <--> ../ p2 \ --> Unfiltered <--> B0
> Instead of
>
> A <----through-filter----> B?
The problem is we need to know the components in the path from A0 to X
through, (Not just A0 and L). And also we need to know "which port (p0
vs p1 vs p2)" does the traffic take from a source (A0/A1/A2) out of the
link "L".
So ideally, we need a way to tie p0 -> A1, p1 -> A2.
would we need something else in the future ? I don't know for sure.
People could design their own things ;-). But this was the first time
ever in the last 12yrs since we supported coresight in the kernel.
(there is always a first time).
Fundamentally, the "ports" cannot have additional properties today.
Not sure if there are other usecases (I don't see why). So, we have
to manually extend like above, which I think is not nice.
Happy to proceed with anything that seems acceptable for you folks.
Suzuki
>
> Best regards,
> Krzysztof
>
On 10/16/2024 10:51 AM, Namhyung Kim wrote:
> Hello,
>
> On Fri, Oct 11, 2024 at 11:17:10AM -0600, Steve Clevenger wrote:
>> Changes in V9:
>> - Removed V8 patch files 1/4 and 2/4.
>> - Modified set_sym_in_dict (trace-event-python.c) to add map_pgoff
>> in dictionary as-is without regard to MAPPING_IDENTITY. This patch
>> file is now patch 2/2.
>
> I think the previous version had Leo's Reviewed-by tag.
>
> Leo, can you confirm if it still holds?
>
> Thanks,
> Namhyung
It did. You can confirm there's no arm-cs-trace-python.py script change
from V8. Note the patch file numbering is different (since 2 patches
dropped). The trace-event-python.c patch file changed so I had to drop
out his "Reviewed-by" tag for that file. Due to the patch numbering
change, I didn't want to add confusion so I left it out.
Steve
>
>>
>> Changes in V8:
>> - in arm-cs-trace-disasm.py, ensure map_pgoff is not converted to
>> string.
>> - Remove map_pgoff integer conversion in dso not found print
>> message.
>>
>> Changes in V7:
>> - In arm-cs-trace-disasm.py, fix print message core dump resulting
>> from mixed type arithmetic.
>> - Modify CS_ETM_TRACE_ON filter to filter zero start_addr. The
>> CS_ETM_TRACE_ON message is changed to print only in verbose mode.
>> - Removed verbose mode only notification for start_addr/stop_addr
>> outside of dso address range.
>>
>> Changes in V6:
>> - In arm-cs-trace-disasm.py, zero map_pgoff for kernel files. Add
>> map_pgoff to start/end address for dso not found message.
>> - Added "Reviewed-by" trailer for patches 1-3 previously reviewed
>> by Leo Yan in V4 and V5.
>>
>> Changes in V5:
>> - In symbol-elf.c, branch to exit_close label if open file.
>> - In trace_event_python.c, correct indentation. set_sym_in_dict
>> call parameter "map_pgoff" renamed as "addr_map_pgoff" to
>> match local naming.
>>
>> Changes in V4:
>> - In trace-event-python.c, fixed perf-tools-next merge problem.
>>
>> Changes in V3:
>> - Rebased to linux-perf-tools branch.
>> - Squash symbol-elf.c and symbol.h into same commit.
>> - In map.c, merge dso__is_pie() call into existing if statement.
>> - In arm-cs-trace-disasm.py, remove debug artifacts.
>>
>> Changes in V2:
>> - In dso__is_pie() (symbol-elf.c), Decrease indentation, add null pointer
>> checks per Leo Yan review.
>> - Updated mailing list distribution.
>>
>> Steve Clevenger (2):
>> Add map_pgoff to python dictionary
>> Adjust objdump start/end address per map_pgoff parameter
>>
>> tools/perf/scripts/python/arm-cs-trace-disasm.py | 16 +++++++++++-----
>> .../util/scripting-engines/trace-event-python.c | 9 ++++++---
>> 2 files changed, 17 insertions(+), 8 deletions(-)
>>
>> --
>> 2.44.0
>>
Some HW has static trace id which cannot be changed via
software programming. For this case, configure the trace id
in device tree with "arm,static-trace-id = <xxx>", and
call coresight_trace_id_get_static_system_id with the trace id value
in device probe function. The id will be reserved for the HW
all the time if the device is probed.
Changes since V3:
1. Adda new API function
int coresight_trace_id_get_system_static_id(int trace_id).
2. Use the term "static trace id" for these devices where
the hardware sets a non-programmable trace ID.
Changes since V2:
1. Change "trace-id" to "arm,trace-id".
2. Add trace id flag for getting preferred id or ODD id.
Changes since V1:
1. Add argument to coresight_trace_id_get_system_id for preferred id
instead of adding new function coresight_trace_id_reserve_system_id.
2. Add constraint to trace-id in dt-binding file.
Mao Jinlong (3):
dt-bindings: arm: Add arm,trace-id for coresight dummy source
coresight: Add support to get static id for system trace sources
coresight: dummy: Add static trace id support for dummy source
.../sysfs-bus-coresight-devices-dummy-source | 15 +++++
.../arm/arm,coresight-dummy-source.yaml | 6 ++
drivers/hwtracing/coresight/coresight-dummy.c | 59 +++++++++++++++++--
.../hwtracing/coresight/coresight-platform.c | 26 ++++++++
.../hwtracing/coresight/coresight-trace-id.c | 38 ++++++++----
.../hwtracing/coresight/coresight-trace-id.h | 9 +++
include/linux/coresight.h | 1 +
7 files changed, 140 insertions(+), 14 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source
--
2.41.0
Changes in V9:
- Removed V8 patch files 1/4 and 2/4.
- Modified set_sym_in_dict (trace-event-python.c) to add map_pgoff
in dictionary as-is without regard to MAPPING_IDENTITY. This patch
file is now patch 2/2.
Changes in V8:
- in arm-cs-trace-disasm.py, ensure map_pgoff is not converted to
string.
- Remove map_pgoff integer conversion in dso not found print
message.
Changes in V7:
- In arm-cs-trace-disasm.py, fix print message core dump resulting
from mixed type arithmetic.
- Modify CS_ETM_TRACE_ON filter to filter zero start_addr. The
CS_ETM_TRACE_ON message is changed to print only in verbose mode.
- Removed verbose mode only notification for start_addr/stop_addr
outside of dso address range.
Changes in V6:
- In arm-cs-trace-disasm.py, zero map_pgoff for kernel files. Add
map_pgoff to start/end address for dso not found message.
- Added "Reviewed-by" trailer for patches 1-3 previously reviewed
by Leo Yan in V4 and V5.
Changes in V5:
- In symbol-elf.c, branch to exit_close label if open file.
- In trace_event_python.c, correct indentation. set_sym_in_dict
call parameter "map_pgoff" renamed as "addr_map_pgoff" to
match local naming.
Changes in V4:
- In trace-event-python.c, fixed perf-tools-next merge problem.
Changes in V3:
- Rebased to linux-perf-tools branch.
- Squash symbol-elf.c and symbol.h into same commit.
- In map.c, merge dso__is_pie() call into existing if statement.
- In arm-cs-trace-disasm.py, remove debug artifacts.
Changes in V2:
- In dso__is_pie() (symbol-elf.c), Decrease indentation, add null pointer
checks per Leo Yan review.
- Updated mailing list distribution.
Steve Clevenger (2):
Add map_pgoff to python dictionary
Adjust objdump start/end address per map_pgoff parameter
tools/perf/scripts/python/arm-cs-trace-disasm.py | 16 +++++++++++-----
.../util/scripting-engines/trace-event-python.c | 9 ++++++---
2 files changed, 17 insertions(+), 8 deletions(-)
--
2.44.0