linux-kernel - Re: [PATCH 2/6] dt-bindings: timer: Add schema for realtek,otto-timer

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: <20240624-dining-bullseye-5397d0921701@spud>
Date: Mon, 24 Jun 2024 17:34:50 +0100
From: Conor Dooley <conor@...nel.org>
To: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc: "tglx@...utronix.de" <tglx@...utronix.de>,
	"robh@...nel.org" <robh@...nel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>,
	"tsbogend@...ha.franken.de" <tsbogend@...ha.franken.de>,
	"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
	"paulburton@...nel.org" <paulburton@...nel.org>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"mail@...ger-koblitz.de" <mail@...ger-koblitz.de>,
	"bert@...t.com" <bert@...t.com>,
	"john@...ozen.org" <john@...ozen.org>,
	"sander@...nheule.net" <sander@...nheule.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
	"kabel@...nel.org" <kabel@...nel.org>,
	"ericwouds@...il.com" <ericwouds@...il.com>
Subject: Re: [PATCH 2/6] dt-bindings: timer: Add schema for realtek,otto-timer

On Sun, Jun 23, 2024 at 09:23:55PM +0000, Chris Packham wrote:
> (resend as plain text)
> 
> On 23/06/24 00:11, Conor Dooley wrote:
> > On Fri, Jun 21, 2024 at 04:27:33PM +1200, Chris Packham wrote:
> >> Add the devicetree schema for the realtek,otto-timer present on a number
> >> of Realtek SoCs.
> >>
> >> Signed-off-by: Chris Packham<chris.packham@...iedtelesis.co.nz>
> >> ---
> >>   .../bindings/timer/realtek,otto-timer.yaml    | 54 +++++++++++++++++++
> >>   1 file changed, 54 insertions(+)
> >>   create mode 100644 Documentation/devicetree/bindings/timer/realtek,otto-timer.yaml
> >>
> >> diff --git a/Documentation/devicetree/bindings/timer/realtek,otto-timer.yaml b/Documentation/devicetree/bindings/timer/realtek,otto-timer.yaml
> >> new file mode 100644
> >> index 000000000000..b6e85aadbc99
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/timer/realtek,otto-timer.yaml
> >> @@ -0,0 +1,54 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id:http://devicetree.org/schemas/timer/realtek,otto-timer.yaml#
> >> +$schema:http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Realtek Otto SoCs Timer/Counter
> >> +
> >> +description:
> >> +  Realtek SoCs support a number of timers/counters. These are used
> >> +  as a per CPU clock event generator and an overall CPU clocksource.
> >> +
> >> +maintainers:
> >> +  - Chris Packham<chris.packham@...iedtelesis.co.nz>
> >> +
> >> +properties:
> >> +  $nodename:
> >> +    pattern: "^timer@[0-9a-f]+$"
> >> +
> >> +  compatible:
> >> +    items:
> >> +      - enum:
> >> +          - realtek,rtl930x-timer
> 
> I'll change this to rtl9302
> 
> >> +      - const: realtek,otto-timer
> >> +  reg:
> >> +    minItems: 5
> >> +    maxItems: 5
> > Since minitems == maxitems, can you just make this a list, and define
> > what they all are? Ditto interrupts.
> 
> This is where more conditions might need to be added. The rtl9302 is a 
> single core SoC. So technically it only needs 2 timers (the hardware 
> still has 5 but 3 would be unused at the moment). The rtl9312 is a dual 
> core SoC so needs 3 timers (I won't be looking at that platform for a 
> while). So I think maybe maxItems should stay at 5 but minItems should 
> be set based on the compatible.

Sounds good to me.

> > reg:
> >    items:
> >      - foo
> >      - bar
> >      - baz
> >
> > etc.
> 
> I can do. But they'd all be something like cpuN-event. The way the 
> driver is written it grabs a timer for each CPU and uses the next one 
> for a global timer.

I think it's fine if they all have very simplistic names, their roles
should be documented somehow.

Cheers,
Conor.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)