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: <CAKYiA1CTWeGPQDsNGzJwjwJgW7SGTPCH3NQ0rFqKQVHbgWh9sw@mail.gmail.com>
Date:   Fri, 20 Jan 2023 14:12:09 -0500
From:   Dennis Lambe <dennis@...rkcharge.io>
To:     Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc:     Alessandro Zummo <a.zummo@...ertech.it>,
        Atsushi Nemoto <atsushi.nemoto@...d.co.jp>,
        Gary Bisson <gary.bisson@...ndarydevices.com>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Troy Kisky <troy.kisky@...ndarydevices.com>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-rtc@...r.kernel.org
Subject: Re: [PATCH v3 0/3] rtc: Set M41T82 & M41T83 xtal load capacitance
 from DT

On Thu, Jan 19, 2023 at 6:52 PM Alexandre Belloni
<alexandre.belloni@...tlin.com> wrote:
> On 19/01/2023 18:27:44-0500, Dennis Lambe wrote:
> > 2. Analog calibration -- that's what the datasheet calls it, but the
> > range on it is very big -- 3.5 pF all the way up to 17.4 pF -- and
> > their reference design uses it as the only xtal load capacitance in
> > the circuit. Most of the values you could set for this would be wildly
> > inappropriate for any given design's choice of xtal oscillator.

I think I should start with an apology, almost everything I wrote
yesterday was in error one way or another. I was conflating this RTC
with I'm also working with. I see now that the datasheet for this one
clearly states that it's only to be used with 12.5 pF crystals, and
that the analog adjustments are meant exclusively for calibration. I
get what you mean about wanting it to be a new runtime interface and
it not making sense to put in the DeviceTree.

I also see what you mean about the datasheet not providing a good
capacitance vs. ppm table. The graph is approximate at best, and ST's
appnote recommends an iterative tuning procedure rather than just
assuming a certain value gives exactly a certain ppm adjustment. I see
why you would want to avoid using 'offset' for this.

I'll hold off on submitting any more patches for this until you've had
a chance to think about how you would want a new interface to work.
Would it be useful to you if I start working up a patchset that makes
a new rtc sysfs attribute and wires the m41t80 driver into it so that
I'm ready to adapt it to whatever naming, scaling, semantics,
interpretation, etc. you decide is right for it?

> I advocate against merging as is without more thought because changing
> anything later will mean breaking the DT ABI and this is not allowed.

Me too, thanks for taking the time to get through to me about it.
-- 

Dennis Lambe (He/Him)
Lead Firmware Engineer
sparkcharge.io

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ