On 08/04/16 08:29, Luis R. Rodriguez wrote:
> On Thu, Apr 7, 2016 at 10:18 PM, Juergen Gross <jgross@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
