linux-kernel - Re: [PATCH 02/12] dt-bindings: clock: renesas,rzg3s-vbattb-clk: Document the 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: <CAMuHMdXOiuORjLo2nRAFxtXmn5rRm7U-CEHqfX2DoXHmQyfdRQ@mail.gmail.com>
Date: Tue, 18 Jun 2024 09:56:07 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: claudiu beznea <claudiu.beznea@...on.dev>
Cc: Conor Dooley <conor@...nel.org>, mturquette@...libre.com, sboyd@...nel.org, 
	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, lee@...nel.org, 
	alexandre.belloni@...tlin.com, magnus.damm@...il.com, 
	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 02/12] dt-bindings: clock: renesas,rzg3s-vbattb-clk:
 Document the VBATTB clock driver

Hi Claudiu,

On Tue, Jun 18, 2024 at 9:34 AM claudiu beznea <claudiu.beznea@...on.dev> wrote:
> On 17.06.2024 18:19, Conor Dooley wrote:
> > On Mon, Jun 17, 2024 at 10:02:47AM +0300, claudiu beznea wrote:
> >> On 15.06.2024 15:17, Conor Dooley wrote:
> >>> On Fri, Jun 14, 2024 at 10:19:22AM +0300, Claudiu wrote:
> >>>> From: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> >>>>
> >>>> The VBATTB IP of the Renesas RZ/G3S SoC controls the clock that feeds
> >>>> the RTC and the tamper detector. Add documentation for the VBATTB clock
> >>>> driver.
> >>>>
> >>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> >>>> ---
> >>>>  .../clock/renesas,rzg3s-vbattb-clk.yaml       | 90 +++++++++++++++++++
> >>>>  1 file changed, 90 insertions(+)
> >>>>  create mode 100644 Documentation/devicetree/bindings/clock/renesas,rzg3s-vbattb-clk.yaml
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/clock/renesas,rzg3s-vbattb-clk.yaml b/Documentation/devicetree/bindings/clock/renesas,rzg3s-vbattb-clk.yaml
> >>>> new file mode 100644
> >>>> index 000000000000..ef52a0c0f874
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/clock/renesas,rzg3s-vbattb-clk.yaml
> >>>> +  renesas,vbattb-osc-bypass:
> >>>> +    description: set when external clock is connected to RTXOUT pin

FTR, this contradicts the explanation below, which states the external
clock oscillator is connected to RTXIN.

> >>>> +    type: boolean
> >>>
> >>> When you say "external clock", is that an input or an output?
> >>
> >> I took that statement from the HW manual. As of the HW manual [1], table
> >> 42.2, that would be an input.
> >
> > Forgive me for not wanting to open the zip etc and find the information
> > in the document, but why do you need an extra property? Is it not
> > something you can determine from the clocks/clock-names properties?
>
> It can't be determined from clocks/clock-names as of my understanding. It
> depends on the type of the input clock (crystal oscillator or external
> hardware device generating the clock).
>
> > It sounds like an additional clock from your description, is it actually
> > different way to provide the second clock you mention above?
>
> This is the block diagram (see [1], only picture this time) of the module
> controlling the clock. Please open it, it helps in understanding what I'll
> explain above.
>
> The VBATTB blocks controlling the VBATTBCLK are:
> - 32KHz-clock oscillator
> - the mux controlled by BKSCCR.SOSEL
> - the gate who's input is the mux output and XOSCCR.OUTEN
>
> To the 32 KHz-clock oscillator block could be connected:
> 1/ either a crystal oscillator in which case it will be connected to both
> RTXIN and RTXOUT pins (the direction of RTXOUT is wrong in this picture for
> this case)
> 2/ or a device (like [2]) generating a clock which has a single output and,
> from my understanding and experience with devices like this, only RTXIN is
> needed, RTXOUT is connected to the ground; for this case the 32KHz-clock
> oscillator block from [1] need to be bypassed in which case the newly
> introduced property will be used; this will select the XBYP on the mux.

Sounds similar to the RAA215300 PMIC, which includes an ISL1208-derived
RTC, where this was handled using two different clock names:
https://elixir.bootlin.com/linux/v6.10-rc1/source/Documentation/devicetree/bindings/regulator/renesas,raa215300.yaml#L49
https://elixir.bootlin.com/linux/v6.10-rc1/source/drivers/rtc/rtc-isl1208.c#L869

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds