linux-kernel - RE: [PATCH] tick: add check for the existence of broadcast clock event device

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <43F901BD926A4E43B106BF17856F07556340868E@orsmsx508.amr.corp.intel.com>
Date:	Mon, 8 Jun 2009 17:21:37 -0700
From:	"Pan, Jacob jun" <jacob.jun.pan@...el.com>
To:	Thomas Gleixner <tglx@...utronix.de>,
	"Tang, Feng" <feng.tang@...el.com>
CC:	"mingo@...e.hu" <mingo@...e.hu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Li, Shaohua" <shaohua.li@...el.com>
Subject: RE: [PATCH] tick: add check for the existence of broadcast clock
 event device

>I understand that, but HPET does not rely on some magic events
>happening. That's what I'm worried about. The boot code is fragile and
>I prefer some explicit setup call over a fragile solution which
>happens to work.
>
>There is not much to complain about a platform specific function call
>to set up special devices if there is a requirement for a call order.
>
>In fact you can avoid setting up the local APIC timer at all. So what
>you want is something like the patch below. You can set the
>setup_secondary_clock pointer in the quirks structure when you detect
>that you are running on such a system.
>
[[JPAN]] Hi Thomas, I have been developing the APB timer driver as Feng mentioned, thank you for the suggestions. 
I agree with you that direct setting up secondary clockevent is a better solution.

But maybe I misunderstand the HPET code, isn't it true that per CPU HPET timer also rely on IPI? In hpet_cpuhp_notify().

Also for using x86_quirks, I think the default quirks are more generic in the sense of x86 platform, but here we are really choosing timer device, so can we switch based on availability of the timer devices instead of quirks? Otherwise, if more platforms share the same setup_secondary_clock() quirk, we would have to check for timer devices anyway.

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