linux-kernel - Re: [PATCH v5 03/10] clk: renesas: clk-vbattb: Add VBATTB clock driver

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: <mg2ugyg65ke3tngzqyyixfkawf4iop4o373dc6fosy7bfydbe5@pm43dhkd7asu>
Date: Thu, 31 Oct 2024 08:48:01 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Claudiu <claudiu.beznea@...on.dev>
Cc: geert+renesas@...der.be, mturquette@...libre.com, sboyd@...nel.org, 
	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, 
	alexandre.belloni@...tlin.com, magnus.damm@...il.com, p.zabel@...gutronix.de, 
	linux-renesas-soc@...r.kernel.org, linux-clk@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-rtc@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: Re: [PATCH v5 03/10] clk: renesas: clk-vbattb: Add VBATTB clock
 driver

On Wed, Oct 30, 2024 at 01:01:13PM +0200, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> 
> The VBATTB IP of the Renesas RZ/G3S SoC controls the clock that is used
> by the RTC. The input to the VBATTB could be a 32KHz crystal
> or an external clock device.
> 
> The HW block diagram for the clock generator is as follows:
> 
>            +----------+ XC   `\
> RTXIN  --->|          |----->| \       +----+  VBATTCLK
>            | 32K clock|      |  |----->|gate|----------->
>            | osc      | XBYP |  |      +----+
> RTXOUT --->|          |----->| /
>            +----------+      ,
> 
> After discussions w/ Stephen Boyd the clock tree associated with this
> hardware block was exported in Linux as:
> 
> vbattb-xtal
>    xbyp
>    xc
>       mux
>          vbattbclk
> 
> where:
> - input-xtal is the input clock (connected to RTXIN, RTXOUT pins)
> - xc, xbyp are mux inputs
> - mux is the internal mux
> - vbattclk is the gate clock that feeds in the end the RTC
> 
> to allow selecting the input of the MUX though assigned-clock DT
> properties, using the already existing clock drivers and avoid adding
> other DT properties. If the crystal is connected on RTXIN,
> RTXOUT pins the XC will be selected as mux input. If an external clock
> device is connected on RTXIN, RTXOUT pins the XBYP will be selected as
> mux input.
> 
> The load capacitance of the internal crystal can be configured
> with renesas,vbattb-load-nanofarads DT property.
> 
> Reviewed-by: Geert Uytterhoeven <geert+renesas@...der.be>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> ---
> 
> Changes in v5:
> - collected tags
> 
> Changes in v4:
> - dropped oscillator from patch description
> - s/on-board/internal in patch description
> - updated dt-binding included file name in the driver as it has been
>   renamed to include/dt-bindings/clock/renesas,r9a08g045-vbattb.h
> - dropped the "_BIT" from driver macros
> - used "quartz-load-femtofarads" dt property instead of adding a new one
> - register the "vbattclk" as critical clock as this feeds the RTC counter
>   logic and it needs to stay on from the moment the RTC is configured;
>   along with it, added a comment to express this.
> 
> Changes in v3:
> - updated patch description
> - dropped dependency on MFD_RENESAS_VBATTB as now there is no
>   driver built under this flag
> - dropped include/clk.h
> - added pm_runtime and reset control support
> - updated register offsets
> - registered 4 clocks: xc, xbyp, mux, vbattclk using generic
>   clock drivers
> - added MODULE_DEVICE_TABLE()
> 
> Changes in v2:
> - updated patch description
> - added vendor name in Kconfig flag
> - used cleanup.h lock helpers
> - dropped the MFD code
> - updated registers offsets
> - added vbattb_clk_update_bits() and used it where possible
> - added vbattb_clk_need_bypass() to detect the bypass setup necessity
> - changed the compatible and driver names
> 
> 
>  drivers/clk/renesas/Kconfig      |   4 +
>  drivers/clk/renesas/Makefile     |   1 +
>  drivers/clk/renesas/clk-vbattb.c | 205 +++++++++++++++++++++++++++++++
>  3 files changed, 210 insertions(+)
>  create mode 100644 drivers/clk/renesas/clk-vbattb.c
> 
> diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
> index 76791a1c50ac..4e835a3f1ab4 100644
> --- a/drivers/clk/renesas/Kconfig
> +++ b/drivers/clk/renesas/Kconfig
> @@ -237,6 +237,10 @@ config CLK_RZV2H
>  	bool "RZ/V2H(P) family clock support" if COMPILE_TEST
>  	select RESET_CONTROLLER
>  
> +config CLK_RENESAS_VBATTB
> +	bool "Renesas VBATTB clock controller"

tristate

> +	select RESET_CONTROLLER
> +

...

> +
> +static const struct of_device_id vbattb_clk_match[] = {
> +	{ .compatible = "renesas,r9a08g045-vbattb" },
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, vbattb_clk_match);
> +
> +static struct platform_driver vbattb_clk_driver = {
> +	.driver		= {
> +		.name	= "renesas-vbattb-clk",
> +		.of_match_table = vbattb_clk_match,
> +	},
> +	.probe = vbattb_clk_probe,
> +};
> +module_platform_driver(vbattb_clk_driver);

That's a module, isn't it?

> +
> +MODULE_DESCRIPTION("Renesas VBATTB Clock Driver");
> +MODULE_AUTHOR("Claudiu Beznea <claudiu.beznea.uj@...renesas.com>");
> +MODULE_LICENSE("GPL");
> -- 
> 2.39.2
>