linux-kernel - RE: [PATCH 3/8] x86/apic: allow use of lapic timer early calibration result

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: <43F901BD926A4E43B106BF17856F0755A74B28D6@orsmsx508.amr.corp.intel.com>
Date:	Tue, 11 May 2010 13:46:54 -0700
From:	"Pan, Jacob jun" <jacob.jun.pan@...el.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Jacob Pan <jacob.jun.pan@...ux.intel.com>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	"Du, Alek" <alek.du@...el.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	"Tang, Feng" <feng.tang@...el.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 3/8] x86/apic: allow use of lapic timer early
 calibration result

> 
> We do not have access to the clocksource at that point. But we do a
> calibration loop for TSC and for lapic timer. There is no reason why
> we can't do that in one go.
> 
I have a simple patch that uses HPET to calibrate both tsc and lapic timers in one
loop in native_calibrate_tsc(). Will send out for RFC.

The question I have is the reference clock used for calibrating those local timers,
PIT, HPET, PM timer how should they be ranked. Can we make those known freq
clocksource devices available at this point so that we can use the clocksource
abstraction and its ranking automatically?


> > > Aside of my general objection it'd be not a good idea to make this
> > > global w/o renaming it to something sensible like
> > > lapic_timer_frequency.
> > >
> > perhaps, the calibration data can directly be assigned to lapic timer
> > clock_event_device.mult? There is no need for the device specific
> result
> > scale (e.g. bus clocks per tick)
> 
> No. That needs an accessor function.
> 
Agreed, so you are ok with bypassing the existing calibration_result variable and use .mult
to carry the result?

--
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/