| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 31 Jan 2024 08:27:10 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Yang Jialong 杨佳龙 <jialong.yang@...ngroup.cn>,
Will Deacon <will@...nel.org>, Mark Rutland <mark.rutland@....com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>
Cc: shenghui.qu@...ngroup.cn, ke.zhao@...ngroup.cn, zhijie.ren@...ngroup.cn,
Rob Herring <robh@...nel.org>, linux-arm-kernel@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] perf/hx_arm_ni: Support uncore ARM NI-700 PMU
On 31/01/2024 03:57, Yang Jialong 杨佳龙 wrote:
>
>
> 在 2024/1/30 16:43, Krzysztof Kozlowski 写道:
>> On 30/01/2024 09:17, JiaLong.Yang wrote:
>>> This code is based on uncore PMUs arm_smmuv3_pmu and arm-cmn.
>>> One ni-700 can have many clock domains. Each of them has only one PMU.
>>> Here one PMU corresponds to one 'struct ni_pmu' instance.
>>> PMU name will be ni_pmu_N_M, which N means different NI-700s and M means
>>> different PMU in one NI-700. If only one NI-700 found in NI-700, name will
>>> be ni_pmu_N.
>>> Node interface event name will be xxni_N_eventname, such as asni_0_rdreq_any.
>>> There are many kinds of type of nodes in one clock domain. Also means that
>>> there are many kinds of that in one PMU. So we distinguish them by xxni string.
>>> Besides, maybe there are many nodes have same type. So we have number N in
>>> event name.
>>> By ni_pmu_0_0/asni_0_rdreq_any/, we can pinpoint accurate bus traffic.
>>> Example1: perf stat -a -e ni_pmu_0_0/asni_0_rdreq_any/,ni_pmu_0_0/cycles/
>>> EXample2: perf stat -a -e ni_pmu_0_0/asni,id=0,event=0x0/
>>>
>>> Signed-off-by: JiaLong.Yang <jialong.yang@...ngroup.cn>
>>> ---
>>> If I should send Doc*/bindings/perf/*.yaml seperately?
>>
>> Checkpatch tells you that, doesn't it?
> OK. I will send it seperately.
>>
>> Please run scripts/checkpatch.pl and fix reported warnings. Some
>> warnings can be ignored, but the code here looks like it needs a fix.
>> Feel free to get in touch if the warning is not clear.
> OK.
>>
>>>
>>> .../bindings/perf/hx,c2000-arm-ni.yaml | 58 +
>>> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
>>> MAINTAINERS | 6 +
>>> drivers/perf/Kconfig | 10 +
>>> drivers/perf/Makefile | 1 +
>>> drivers/perf/hx_arm_ni.c | 1308 +++++++++++++++++
>>> 6 files changed, 1385 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/perf/hx,c2000-arm-ni.yaml
>>> create mode 100644 drivers/perf/hx_arm_ni.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/perf/hx,c2000-arm-ni.yaml b/Documentation/devicetree/bindings/perf/hx,c2000-arm-ni.yaml
>>> new file mode 100644
>>> index 000000000000..1b145ecbfa83
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/perf/hx,c2000-arm-ni.yaml
>>> @@ -0,0 +1,58 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/perf/hx,c2000-arm-ni.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: HX-C2000 NI (Network-on_chip Interconnect) Performance Monitors
>>> +
>>> +maintainers:
>>> + - Jialong Yang <jialong.yang@...ngroup.cn>
>>> +
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - hx,c2000-arm-ni
>>> +
>>> + reg:
>>> + items:
>>> + - description: Physical address of the base (PERIPHBASE) and
>>> + size of the whole NI configuration address space.
>>> +
>>> + interrupts:
>>> + minItems: 1
>>
>> Why?
> According to hw, one PMU has one interrupt line. So one NI maybe has
> more than one. But actually it depends on hw implementation.
> And in C code, I will return error when there is no interrupt.
Different HW implementation would have different compatible, which is
not the case here. Your binding says there is only one implementation,
so how the same implementation can have different number of interrupts?
No, that does not look right.
>>
>>> + items:
>>> + - description: Overflow interrupt for clock domain 0
>>> + - description: Overflow interrupt for clock domain 1
>>> + - description: Overflow interrupt for clock domain 2
>>> + description: Generally, one interrupt line for one PMU. But this also
>>> + support one interrupt line for a NI if merged.
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - interrupts
>>> +
>>> +if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + const: hx,c2000-arm-ni
>>
>> Drop entire if. What is the point of it?
> This attribute is used to identify different NI in my company's product.
> But even if I don't give this attribute, nothing will be wrong in code.
What is the attribute? I don't understand.
> However if I do that, I will couldn't know the relation between sysfs
> file and hardware NI.
sysfs does not matter for the bindings.
>
> I will drop it. It will be as a normal way to identify NIs manually.
> If there is only one NI and not give pccs-id, no thing wrong will happen.
Your if just does not make sense. It's no-op.
>>
>>> +then:
>>> + required:
>>> + - pccs-id
No, move it to required properties.
..
>>> +static int ni_pmu_probe(struct platform_device *pdev)
>>> +{
>>> + int ret, cd_num, idx, irq_num, irq_idx;
>>> + void __iomem *periphbase;
>>> + struct global_ni *ni;
>>> + struct device *dev = &pdev->dev;
>>> + char *name;
>>> + static int id;
>>> + struct ni_pmu *ni_pmu;
>>> +
>>> + BUILD_BUG_ON(sizeof(long) == 4);
>>
>> I am sorry, but what?
> I only want to ensure 64 bit environment. Maybe there are many other way.
> I will ensure that in Kconfig.
Kconfig, but then NAK. Your code must be buildable everywhere. This is
not 1990-ties.
Best regards,
Krzysztof
Powered by blists - more mailing lists