linux-kernel - Re: [PATCH v2 2/4] dt-bindings: rtc: lpc32xx-rtc: convert to dtschema

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] [day] [month] [year] [list]

Message-ID: <20240412214300a31799c2@mail.local>
Date: Fri, 12 Apr 2024 23:43:00 +0200
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Javier Carrasco <javier.carrasco.cruz@...il.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Jiaxun Yang <jiaxun.yang@...goat.com>,
	Vladimir Zapolskiy <vz@...ia.com>, Joel Stanley <joel@....id.au>,
	Andrew Jeffery <andrew@...econstruct.com.au>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	linux-rtc@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-aspeed@...ts.ozlabs.org,
	linux-stm32@...md-mailman.stormreply.com
Subject: Re: [PATCH v2 2/4] dt-bindings: rtc: lpc32xx-rtc: convert to dtschema

On 11/04/2024 08:17:55+0200, Krzysztof Kozlowski wrote:
> On 10/04/2024 22:43, Alexandre Belloni wrote:
> > On 10/04/2024 17:55:34+0200, Javier Carrasco wrote:
> >> Convert existing binding to dtschema to support validation.
> >>
> >> Add the undocumented 'clocks' property.
> >>
> >> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@...il.com>
> >> ---
> >>  .../devicetree/bindings/rtc/lpc32xx-rtc.txt        | 15 --------
> >>  .../devicetree/bindings/rtc/nxp,lpc32xx-rtc.yaml   | 41 ++++++++++++++++++++++
> >>  2 files changed, 41 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt b/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt
> >> deleted file mode 100644
> >> index a87a1e9bc060..000000000000
> >> --- a/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt
> >> +++ /dev/null
> >> @@ -1,15 +0,0 @@
> >> -* NXP LPC32xx SoC Real Time Clock controller
> >> -
> >> -Required properties:
> >> -- compatible: must be "nxp,lpc3220-rtc"
> >> -- reg: physical base address of the controller and length of memory mapped
> >> -  region.
> >> -- interrupts: The RTC interrupt
> >> -
> >> -Example:
> >> -
> >> -	rtc@...24000 {
> >> -		compatible = "nxp,lpc3220-rtc";
> >> -		reg = <0x40024000 0x1000>;
> >> -		interrupts = <52 0>;
> >> -	};
> >> diff --git a/Documentation/devicetree/bindings/rtc/nxp,lpc32xx-rtc.yaml b/Documentation/devicetree/bindings/rtc/nxp,lpc32xx-rtc.yaml
> >> new file mode 100644
> >> index 000000000000..62ddeef961e9
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/rtc/nxp,lpc32xx-rtc.yaml
> >> @@ -0,0 +1,41 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/rtc/nxp,lpc32xx-rtc.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: NXP LPC32xx SoC Real Time Clock
> >> +
> >> +maintainers:
> >> +  - Javier Carrasco <javier.carrasco.cruz@...il.com>
> >> +
> >> +allOf:
> >> +  - $ref: rtc.yaml#
> >> +
> >> +properties:
> >> +  compatible:
> >> +    const: nxp,lpc3220-rtc
> >> +
> >> +  reg:
> >> +    maxItems: 1
> >> +
> >> +  interrupts:
> >> +    maxItems: 1
> >> +
> >> +  clocks:
> >> +    maxItems: 1
> > 
> > As I explained the clock doesn't really exist, there is no control over
> > it, it is a fixed 32768 Hz crystal, there is no point in describing it
> > as this is already the input clock of the SoC.
> 
> That's common for many SoCs but it is still (at least for them) input to
> the RTC. On some SoC boards 32 kHz is controllable.
> 

There is n way this can be controlled at the board level as the soc
mandates a crystal. There is a control for the oscillator but it is not
functional. This would be bit 5 of RTC_CTRL which is documented as such:

"5 Not used. Write is don’t care, Read returns random value."

Even so, the clock wouldn't be an input to the RTC but it is provided by
the RTC.

I guess because it was easer to d so, the clock is defined in the clock
controller driver:
https://elixir.bootlin.com/linux/latest/source/drivers/clk/nxp/clk-lpc32xx.c#L1222

but, from an HW point of view, this is not correct.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com