linux-kernel - Re: [RFC][PATCH 3/3] Try to convert non-trivial clocksources to clocksource_register

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: <1273536296.3843.66.camel@localhost.localdomain>
Date:	Mon, 10 May 2010 17:04:56 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Jim Cromie <jim.cromie@...il.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC][PATCH 3/3] Try to convert non-trivial clocksources to
 clocksource_register_hz

On Mon, 2010-05-10 at 17:33 -0400, Jim Cromie wrote:
> On Fri, Apr 30, 2010 at 9:36 PM, John Stultz <johnstul@...ibm.com> wrote:
> hi John,
> 
> On casual inspection, this looks good, however
> I wont be able to try it on the hardware til early June earliest.
> 
> I have a few qs, (idle musings really)
> 
> - scx200_hrt cannot be rmmod'd, due iirc to the clocksource design.
> This is not a problem, but I wonder if it might be added later, and what
> it might mean to the drivers (in a new module_exit())


I've not really heard much of a compelling argument for clocksource
driver removal, nor has anyone wanted to put much effort there so far.
That said, I'm not opposed to it right off.  It just not a priority.


> - HRT_SHIFT_1/_27 macros are removed, and now calculated in clocksource code.
> I chose a 1:16 shift ratio for the 1:27 input clocks.  I suppose I could have
> used 1:32, I dont recall thinking of it or trying it then.
> What would/should your new code do ?

I'm not sure I'm following what you mean with the ratios, but the new
code will select the largest shift value possible, where the resulting
mult won't overflow 64bits when multiplied against 5 seconds (that
interval length may be changed in the future) worth of cycles.


> - when writing scx200_hrt, I chose to adjust by ppm, not +/- hz
> partly cuz it was easier to describe in a 1-line mod-desc, and partly
> cuz 1/27ppm vernier-knob is overkill on a $0.25 crystal.
> The new API name (with _hz suffix) suggests that I could change
> the mod-param-name, and add it in after the 1:27 multiplier.

I believe its still mathematically identical to what you had before, but
let me know if I'm mistaken here.

thanks
-john


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/