On Thu, Mar 12, 2015 at 01:19:14AM +, Bryan O'Donoghue wrote:
> On 11/03/15 23:10, Luis R. Rodriguez wrote:
>
> ACK the concept - the logic to compile up APIC support is circuitous
> to say the least.
It took me a while to grok this and indeed the goal was to make it
much simpler to read, but
On Wed, Mar 11, 2015 at 10:36:41PM -0700, David Rientjes wrote:
> On Wed, 11 Mar 2015, Luis R. Rodriguez wrote:
>
> > From: "Luis R. Rodriguez"
> >
> > X86_UP_IOAPIC is a way so that 32-bit UP systems can enable
> > X86_IOAPIC. X86_UP_IOAPIC is only as a visible user option if
> > you are on a 3
On Wed, 11 Mar 2015, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> X86_UP_IOAPIC is a way so that 32-bit UP systems can enable
> X86_IOAPIC. X86_UP_IOAPIC is only as a visible user option if
> you are on a 32-bit system but have X86_UP_APIC enabled. X86_UP_APIC
> will be enabled by fo
On 11/03/15 23:10, Luis R. Rodriguez wrote:
ACK the concept - the logic to compile up APIC support is circuitous to
say the least.
Personally think we should just always compile up the APIC code if the
arch declares support and let the bootstrap code interrogate CPUID. Who
in 2015 is really
From: "Luis R. Rodriguez"
X86_UP_IOAPIC is a way so that 32-bit UP systems can enable
X86_IOAPIC. X86_UP_IOAPIC is only as a visible user option if
you are on a 32-bit system but have X86_UP_APIC enabled. X86_UP_APIC
will be enabled by force if you have PCI_MSI on 32-bit systems
now, X86_UP_APIC
5 matches
Mail list logo
