[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57075201.5080207@suse.com>
Date: Fri, 8 Apr 2016 08:38:57 +0200
From: Juergen Gross <jgross@...e.com>
To: "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc: Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Rusty Russell <rusty@...tcorp.com.au>, X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
David Vrabel <david.vrabel@...rix.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
lguest@...ts.ozlabs.org,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Joey Lee <jlee@...e.com>, Gary Lin <glin@...e.com>,
Matt Fleming <matt@...eblueprint.co.uk>,
Andrew Cooper <andrew.cooper3@...rix.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>,
"Moore, Robert" <robert.moore@...el.com>,
Lv Zheng <lv.zheng@...el.com>, Toshi Kani <toshi.kani@...com>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
kozerkov@...allels.com, Josh Triplett <josh@...htriplett.org>,
Joerg Roedel <joro@...tes.org>
Subject: Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with
platform legacy quirk
On 08/04/16 08:29, Luis R. Rodriguez wrote:
> On Thu, Apr 7, 2016 at 10:18 PM, Juergen Gross <jgross@...e.com> wrote:
>> On 08/04/16 02:32, Luis R. Rodriguez wrote:
>>> This highlights a semantic gap issue. From a quick cursory review, I think
>>> we can address this temporarily by just using a check:
>>>
>>> void __init x86_early_init_platform_quirks(void)
>>> {
>>> x86_platform.legacy.rtc = 1;
>>>
>>> switch (boot_params.hdr.hardware_subarch) {
>>> case X86_SUBARCH_XEN:
>>> case X86_SUBARCH_LGUEST:
>>> case X86_SUBARCH_INTEL_MID:
>>> - x86_platform.legacy.rtc = 0;
>>> + if (x86_init.mpparse.get_smp_config != x86_init_uint_noop)
>>> + x86_platform.legacy.rtc = 0;
>>
>> No! Why don't you just use the explicit test xen_initial_domain() ?
>
> Because we don't want to sprinkle Xen specific code outside of Xen
> code. What do you think about the second possibility I listed?
> Otherwise, any other ideas?
Don't try to guess.
In case you don't want to inject Xen internals here, just call a Xen
function to either return the correct value, or to set all structure
elements correctly.
Thinking more about it: why not do that for all the subarchs? You'd
have the specific settings where they belong: in a subarch specific
source. Just do the default settings in x86_early_init_platform_quirks()
and let the subarch functions set the non-default values.
Juergen
Powered by blists - more mailing lists