linux-kernel - Re: [PATCH] arm64: dts: allwinner: h6: tanix-tx6: Use internal oscillator

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: <20200117183901.lkieha3hu6nz2hoj@gilmour.lan>
Date:   Fri, 17 Jan 2020 19:39:01 +0100
From:   Maxime Ripard <mripard@...nel.org>
To:     Jernej Škrabec <jernej.skrabec@...l.net>
Cc:     wens@...e.org, robh+dt@...nel.org, mark.rutland@....com,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-sunxi@...glegroups.com
Subject: Re: [PATCH] arm64: dts: allwinner: h6: tanix-tx6: Use internal
 oscillator

Hi,

On Thu, Jan 16, 2020 at 05:47:12PM +0100, Jernej Škrabec wrote:
> Dne četrtek, 16. januar 2020 ob 09:06:52 CET je Maxime Ripard napisal(a):
> > Hi Jernej,
> >
> > On Mon, Jan 13, 2020 at 07:07:20PM +0100, Jernej Skrabec wrote:
> > > Tanix TX6 doesn't have external 32 kHz oscillator, so switch RTC clock
> > > to internal one.
> > >
> > > Signed-off-by: Jernej Skrabec <jernej.skrabec@...l.net>
> > > ---
> > >
> > > While this patch gives one possible solution, I mainly want to start
> > > discussion why Allwinner SoC dtsi reference external 32 kHz crystal
> > > although some boards don't have it. My proposal would be to make clock
> > > property optional, based on the fact if external crystal is present or
> > > not. However, I'm not sure if that is possible at this point or not.
> >
> > It's probably a bit of a dumb question but.. are you sure the crystal
> > is missing?
>
> Although I don't have schematic, I'm pretty sure. Without this patch or one at
> [1], RTC gives a lot of errors in dmesg. I think that unpopulated XC2 pads
> near SoC (see [2]) are probably reserved for crystal.
>
> With patch in [1], which enables automatic switching in case of error, I saw
> that on this box RTC always switched to internal RC.
>
> >
> > The H6 datasheet mentions that the 32kHz crystal needs to be there,
> > and it's part of the power sequence, so I'd expect all boards to have
> > it.
>
> Can you be more specific where it is stated that crystal is mandatory?

I was mostly referring to the power sequence mentionned in the H6
Datasheet (not the user manual, the smaller one).

https://linux-sunxi.org/images/5/5c/Allwinner_H6_V200_Datasheet_V1.1.pdf

Page 74

> Note that schematic of some boards, like OrangePi PC2 (H5) or OrangePi Zero
> (H3) don't even have 32K crystal in them.

And we can't use the compatible for these..

> >
> > > Driver also considers missing clock property as deprecated (old DT) [1],
> > > so this might complicate things even further.
> > >
> > > What do you think?
> >
> > I'm pretty sure (but that would need to be checked) that we never got
> > a node without the clocks property on the H6. If that's the case, then
> > we can add a check on the compatible.
>
> Yes, that would be nice solution. I can work something out if you agree that
> this is the way.

So if we want to have something that works for the H3 too, then I
guess we need to revert the patch that switches the 32kHz clock source
to the external one all the time, and do it only if we have a clock
provided.

If we don't, we would run from the internal oscillator (which would
work for both the H3 and H6 boards you have I guess?) and if we do we
will still use the better, more accurate, clock.

That would change a bit the behaviour of the old DTs again and revert
to the old behaviour we had, but we didn't hear anything the first
time we did, so I wouldn't be overly concerned.

Does that make sense?
Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)