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]
Date:   Mon, 15 Apr 2019 16:18:12 +0800
From:   Chen-Yu Tsai <>
To:     Ondřej Jirman <>
Cc:     Alessandro Zummo <>,
        Alexandre Belloni <>,
        Rob Herring <>,
        Mark Rutland <>,
        Maxime Ripard <>,, devicetree <>,
        linux-arm-kernel <>,
        linux-kernel <>,
        linux-sunxi <>
Subject: Re: [linux-sunxi] [PATCH 0/3] Add basic support for RTC on Allwinner
 H6 SoC

On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
<> wrote:
> From: Ondrej Jirman <>
> I went through the datasheets for H6 and H5, and compared the differences.
> RTCs are largely similar, but not entirely compatible. Incompatibilities
> are in details not yet implemented by the rtc driver though.
> I also corrected the clock tree in H6 DTSI.

Please also add DCXO clock input/output and XO clock input to the bindings
and DT, and also fix up the clock tree. You can skip them in the driver for
now, but please add a TODO. As long as you don't change the clock-output-name
of osc24M, everything should work as before.

We just want the DT to describe what is actually there. For the XO input,
you could just directly reference the external crystal node. The gate for
it is likely somewhere in the PRCM block, which we don't have docs for.

> There's a small detail here, that's not described absolutely correctly in
> DTSI, but the difference is not really that material. ext_osc32k is
> originally modelled as a fixed clock that feeds into RTC module, but in
> reality it's the RTC module that implements via its registers enabling and
> disabling of this oscillator/clock.
> Though:
> - there's no other possible user of ext_osc32k than RTC module
> - there's no other possible external configuration for the crystal
>   circuit that would need to be handled in the dts per board
> So I guess, while the description is not perfect, this patch series still
> improves the current situation. Or maybe I'm misunderstanding something,
> and &ext_osc32k node just describes a fact that there's a crystal on
> the board. Then, everything is perhaps fine. :)

Correct. The external clock nodes are modeling the crystal, not the internal
clock gate / distributor.

Were the vendor to not include the crystal (for whatever reasons), the DT
should be able to describe it via the absence of the clock input, and the
driver should correctly use the internal (inaccurate) oscillator. I realize
the clocks property is required, and the driver doesn't handle this case
either, so we might have to fix that if it were to appear in the wild.

> For now, the enable bit for this oscillator is toggled by the re-parenting
> code automatically, as needed.

That's fine. No need to increase the clock tree depth.


> This patchset is necessary for implementing the WiFi/Bluetooth support
> on boards using H6 SoC.
> Please take a look.
> Thank you and regards,
>   Ondrej Jirman
> Ondrej Jirman (3):
>   dt-bindings: Add compatible for H6 RTC
>   rtc: sun6i: Add support for H6 RTC
>   arm64: dts: sun50i-h6: Add support for RTC and fix the clock tree
>  .../devicetree/bindings/rtc/sun6i-rtc.txt     |  1 +
>  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 30 +++++++-------
>  drivers/rtc/rtc-sun6i.c                       | 40 ++++++++++++++++++-
>  3 files changed, 55 insertions(+), 16 deletions(-)
> --
> 2.21.0
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> For more options, visit

Powered by blists - more mailing lists