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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2e0f19bf-496c-f90a-3549-fe7ace346ff4@quicinc.com>
Date:   Thu, 30 Jun 2022 16:59:46 +0530
From:   Rajendra Nayak <quic_rjendra@...cinc.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        "Georgi Djakov" <djakov@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-pm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
CC:     Rob Herring <robh@...nel.org>
Subject: Re: [PATCH v6 1/4] dt-bindings: interconnect: qcom,msm8998-cpu-bwmon:
 add BWMON device



On 6/30/2022 4:53 PM, Krzysztof Kozlowski wrote:
> On 30/06/2022 13:14, Rajendra Nayak wrote:
>>
>> On 6/29/2022 7:32 PM, Krzysztof Kozlowski wrote:
>>> Add bindings for the Qualcomm Bandwidth Monitor device providing
>>> performance data on interconnects.  The bindings describe only BWMON CPU
>>> (version 4), e.g. the instance which appeared for the first on Qualcomm
>>> MSM8998 SoC and is also used on SDM845.  This BWMON device sits between
>>> CPU and Last Level Cache Controller.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>> Reviewed-by: Rob Herring <robh@...nel.org>
>>> Acked-by: Georgi Djakov <djakov@...nel.org>
>>> ---
>>>    .../interconnect/qcom,msm8998-llcc-bwmon.yaml | 85 +++++++++++++++++++
>>>    1 file changed, 85 insertions(+)
>>>    create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,msm8998-llcc-bwmon.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-llcc-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-llcc-bwmon.yaml
>>> new file mode 100644
>>> index 000000000000..76e09658d615
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-llcc-bwmon.yaml
>>> @@ -0,0 +1,85 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/interconnect/qcom,msm8998-llcc-bwmon.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Qualcomm Interconnect Bandwidth Monitor
>>> +
>>> +maintainers:
>>> +  - Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>> +
>>> +description: |
>>> +  Bandwidth Monitor measures current throughput on buses between various NoC
>>> +  fabrics and provides information when it crosses configured thresholds.
>>> +
>>> +  Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845::
>>> +   - Measuring the bandwidth between CPUs and Last Level Cache Controller -
>>> +     called LLCC BWMON,
>>> +   - Measuring the bandwidth between Last Level Cache Controller and memory (DDR).
>>> +
>>> +properties:
>>> +  compatible:
>>> +    oneOf:
>>> +      - items:
>>> +          - enum:
>>> +              - qcom,sdm845-llcc-bwmon
>>> +          - const: qcom,msm8998-llcc-bwmon
>>> +      - const: qcom,msm8998-llcc-bwmon       # BWMON v4
>>> +
>>> +  interconnects:
>>> +    maxItems: 1
>>> +
>>> +  interrupts:
>>> +    maxItems: 1
>>> +
>>> +  operating-points-v2: true
>>> +  opp-table: true
>>> +
>>> +  reg:
>>> +    # BWMON v4 (currently described) and BWMON v5 use one register address
>>> +    # space.  BWMON v2 uses two register spaces - not yet described.
>>> +    maxItems: 1
>>> +
>>> +required:
>>> +  - compatible
>>> +  - interconnects
>>> +  - interrupts
>>> +  - operating-points-v2
>>> +  - opp-table
>>> +  - reg
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> +  - |
>>> +    #include <dt-bindings/interconnect/qcom,sdm845.h>
>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>> +
>>> +    pmu@...6400 {
>>> +        compatible = "qcom,sdm845-llcc-bwmon", "qcom,msm8998-llcc-bwmon";
>>
>> so with this compatible fallback scheme, I am trying to understand what
>> do I need to do if I have to add support for another SoC for instance.
>>
>> I just update the binding with the new SoC compatible (lets say qcom,sc7280-llcc-bwmon)
>> and in the device tree node use it as
>> 	compatible = "qcom,sc7280-llcc-bwmon", "qcom,sdm845-llcc-bwmon", "qcom,msm8998-llcc-bwmon";
>> without any updates in the driver?
> 
> I expect:
> "qcom,sc7280-llcc-bwmon", "qcom,msm8998-llcc-bwmon";
> and you need to add sc7280 compatible to the driver. The actual proper
> solution in my patch would be to use msm8998 compatible in the driver,
> but I did not test MSM8998.
> 
> Maybe we should switch to that anyway?

Right, looks like without it every new SoC compatible added would need a dummy
update in the driver even though you really don't need to do anything different
in the driver.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ