From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1757565AbcDGU7i (ORCPT <rfc822;w@1wt.eu>);
	Thu, 7 Apr 2016 16:59:38 -0400
Received: from mx2.suse.de ([195.135.220.15]:60157 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S932606AbcDGU7G (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 7 Apr 2016 16:59:06 -0400
Date: Thu, 7 Apr 2016 22:59:02 +0200
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Ingo Molnar <mingo@kernel.org>, David Vrabel <david.vrabel@citrix.com>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>, bp@alien8.de, hpa@zytor.com,
        tglx@linutronix.de, mingo@redhat.com, rusty@rustcorp.com.au,
        x86@kernel.org, linux-kernel@vger.kernel.org, luto@amacapital.net,
        boris.ostrovsky@oracle.com, david.vrabel@citrix.com,
        konrad.wilk@oracle.com, xen-devel@lists.xensource.com,
        lguest@lists.ozlabs.org,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Andrew Cooper <andrew.cooper3@citrix.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v3 01/11] x86/boot: enumerate documentation for the x86
 hardware_subarch
Message-ID: <20160407205902.GS1990@wotan.suse.de>
References: <1456212255-23959-1-git-send-email-mcgrof@kernel.org>
 <1456212255-23959-2-git-send-email-mcgrof@kernel.org>
 <20160223085119.GA10182@gmail.com>
 <20160223103409.GF25240@wotan.suse.de>
 <20160223204135.GH25240@wotan.suse.de>
 <20160224083259.GA20579@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160224083259.GA20579@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

David, please note below the highlighted code.

On Wed, Feb 24, 2016 at 09:32:59AM +0100, Ingo Molnar wrote:
> 
> * Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> For hard coded platform quirks I'd suggest we add x86_platform.quirks flags. For 
> example the F00F hack for Xen could be done via:
> 
> 	x86_platform.quirks.idt_remap = 0;
> 
> and would be set like this during early init:
> 
> void early_init_platform_quirks(void)
> {
> 	x86_platform.legacy.ebda_search = 0;
> 	x86_platform.quirks.idt_remap = 1;
> 
> 	switch (boot_params.hdr.hardware_subarch) {
> 		case X86_SUBARCH_PC:
> 			x86_platform.legacy.ebda_search = 1;
> 			break;
> 		case X86_SUBARCH_XEN:
> 			x86_platform.quirks.idt_remap = 0;
> 			break;
> 		case X86_SUBARCH_LGUEST:
> 			x86_platform.quirks.idt_remap = 0;
> 			break;
> 	}
> }
> 
> And if also add the legacy RTC flag, it becomes:
> 
> void early_init_hardcoded_platform_quirks(void)
> {
> 	x86_platform.legacy.ebda_search = 0;
> 	x86_platform.quirks.idt_remap = 1;
> 	x86_platform.legacy.rtc = 1;
> 
> 	switch (boot_params.hdr.hardware_subarch) {
> 		case X86_SUBARCH_PC:
> 			x86_platform.legacy.ebda_search = 1;
> 			break;
> 		case X86_SUBARCH_XEN:
> 			x86_platform.quirks.idt_remap = 0;
> 			x86_platform.legacy.rtc = 0;
> 			break;
> 		case X86_SUBARCH_LGUEST:
> 			x86_platform.quirks.idt_remap = 0;
> 			x86_platform.legacy.rtc = 0;
> 			break;
> 	}
> }
> 
> Note that both opt-in and opt-out quirks/legacies are possible this way, and note 
> how cleanly and consistently it's all organized: setup of all hard coded 
> legacies/quirks is concentrated in a single function, and the actual usage sites 
> don't know anything about subarchitectures.

<-- snip -- > 

So.. I went with Ingo's template.

> Furthermore we should probably move a few other existing legacies to this flag 
> space as well, to make all this more consistent.

And this suggestion should explain a bit of the effort I put into making
room for other legacy things, which I'll elaborate in the other thread.

  Luis