linux-kernel - RE: [PATCH v3 05/10] dt-bindings: timer: Add HPE GXP Timer Binding

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: <PH0PR84MB1718CAA1172CE891AA4E361C880C9@PH0PR84MB1718.NAMPRD84.PROD.OUTLOOK.COM>
Date:   Fri, 11 Mar 2022 16:22:12 +0000
From:   "Hawkins, Nick" <nick.hawkins@....com>
To:     Rob Herring <robh@...nel.org>
CC:     "Verdun, Jean-Marie" <verdun@....com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: RE: [PATCH v3 05/10] dt-bindings: timer: Add HPE GXP Timer Binding

On Thu, Mar 10, 2022 at 01:52:24PM -0600, nick.hawkins@....com wrote:
>> From: Nick Hawkins <nick.hawkins@....com>>
>> 
>> Creating binding for gxp timer in device tree hpe,gxp-timer Although 
>> there are multiple times on the SoC we are only enabling one at this 
>> time.
>> 
>> Signed-off-by: Nick Hawkins <nick.hawkins@....com>>
>> 
>> ----
>> 
>> v2:
>>  *Removed maintainer change from patch  *Verified there was no 
>> compilation errors  *Added reference code in separate patch of 
>> patchset
>> ---
>>  .../bindings/timer/hpe,gxp-timer.yaml         | 45 +++++++++++++++++++
>>  1 file changed, 45 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
>> 
>> diff --git 
>> a/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml 
>> b/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
>> new file mode 100644
>> index 000000000000..1f4e345c5fb8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
>> @@ -0,0 +1,45 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
>> +---
>> +$id: 
>> +INVALID URI REMOVED
>> +xp-timer.yaml*__;Iw!!NpxR!yaItMPvjqEf3fKyp1xDQAzawRQDd8uDGTNKMlVPpn5Y
>> +56IUABMYbali7jonBl20K$
>> +$schema: 
>> +INVALID URI REMOVED
>> +aml*__;Iw!!NpxR!yaItMPvjqEf3fKyp1xDQAzawRQDd8uDGTNKMlVPpn5Y56IUABMYba
>> +li7jmX565-G$
>> +
>> +title: HPE GXP TIMER
>> +
>> +maintainers:
>> +  - Nick Hawkins <nick.hawkins@....com>>
>> +  - Jean-Marie Verdun <verdun@....com>>
>> +
>> +properties:
>> +  compatible:
>> +    const: hpe,gxp-timer
>> +
>> +  reg:
>> +    items:
>> +      - description: T0CNT register
>> +      - description: T0CS register
>> +      - description: TIMELO register

> Is the spec public to know what T0CNT, T0CS, and TIMELO are?
No it is not, should I not mention the register descriptions at all?

>> +
>> +  interrupts:
>> +    maxItems: 1
>> +
>> +  clock-frequency:
>> +    description: The frequency of the clock that drives the counter, in Hz.
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - interrupts
>> +  - clock-frequency
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    timer@...03000 {
>> +        compatible = "hpe,gxp-timer";
>> +        reg = <0xc0000080 0x1>>, <0xc0000094 0x01>>, <0xc0000088 0x08>>;

> Based on the driver these are 4 bytes, 1 byte, 4 bytes in size.

> Are there other registers in 0x80-0x95 range or do these offsets change in other chips? If not, just 1 entry covering the whole thing would be better.
There are other registers in this range that cover different timers/clocks, for the most part between chip generations the offsets remain the same unless there is an architectural issue.
Can you provide a quick example of what one entry would be?

>> +        interrupts = <0>>;
>> +        interrupt-parent = <&vic0>>;
>> +        clock-frequency = <400000000>>;
>> +    };
>> --
>> 2.17.1
>> 
>> 

Regards,

Nick Hawkins