linux-kernel - Re: [PATCH 1/4] dt-bindings: rtc: add schema for NXP S32G2/S32G3 SoCs

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: <20240917130113daecdd5b@mail.local>
Date: Tue, 17 Sep 2024 15:01:13 +0200
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: Ciprian Marian Costea <ciprianmarian.costea@....nxp.com>
Cc: Conor Dooley <conor@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, linux-rtc@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	NXP S32 Linux Team <s32@....com>,
	Bogdan-Gabriel Roman <bogdan-gabriel.roman@....com>,
	Ghennadi Procopciuc <ghennadi.procopciuc@....com>
Subject: Re: [PATCH 1/4] dt-bindings: rtc: add schema for NXP S32G2/S32G3 SoCs

On 17/09/2024 10:21:32+0300, Ciprian Marian Costea wrote:
> On 9/12/2024 5:03 PM, Alexandre Belloni wrote:
> > On 12/09/2024 15:36:46+0300, Ciprian Marian Costea wrote:
> > > > Then should this mux be registered in the CCF so you can use the usual
> > > > clock node properties?
> > > 
> > > Hello Alexandre,
> > > 
> > > In hardware, these clock muxes and divisors are part of the RTC module
> > > itself and not external. Therefore, I would say no.
> > 
> > This is irrelevant, if this is a clock mux, it must be in the CCF, just
> > as when the RTC has a clock output.
> > 
> > 
> 
> I understand your point, but taking into account the fact that FIRC clock
> should be used in most scenarios, would it be acceptable to not export this
> 'clksel' property in the devicetree bindings and simply use the FIRC clock
> by default in the RTC driver ?
> 

No, this doesn't work for RTCs because their lifecycle is longer than the
system's and f you change a configuration from the default value without
providing a way to control it, we won't have any upgrade path without
breaking users.

> At least for this patchset, in order to ease the review process. If
> configurable clock source support would want to be enabled and exported via
> bindings for this S32G2/S32G3 RTC driver, then CCF registration for this clk
> mux could be added in future patches.

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