Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Sean V Kelley <sean.v.kelley@linux.intel.com>, bhelgaas@google.com,
        corbet@lwn.net, mingo@redhat.com, bp@alien8.de
Cc:     x86@kernel.org, linux-pci@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
        kar.hin.ong@ni.com, sassmann@kpanic.de,
        Sean V Kelley <sean.v.kelley@linux.intel.com>
Subject: Re: [PATCH 0/2] Add boot interrupt quirk mechanism for Xeon chipsets
In-Reply-To: <20200214213313.66622-1-sean.v.kelley@linux.intel.com>
References: <20200214213313.66622-1-sean.v.kelley@linux.intel.com>
Date:   Sat, 15 Feb 2020 10:24:57 +0100
Message-ID: <8736bctd7a.fsf@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Sean V Kelley <sean.v.kelley@linux.intel.com> writes:
> When IRQ lines on secondary or higher IO-APICs are masked (e.g.,
> Real-Time threaded interrupts), many chipsets redirect IRQs on
> this line to the legacy PCH and in turn the base IO-APIC in the
> system. The unhandled interrupts on the base IO-APIC will be
> identified by the Linux kernel as Spurious Interrupts and can
> lead to disabled IRQ lines.
>
> Disabling this legacy PCI interrupt routing is chipset-specific and
> varies in mechanism between chipset vendors and across generations.
> In some cases the mechanism is exposed to BIOS but not all BIOS
> vendors choose to pick it up. With the increasing usage of RT as it
> marches towards mainline, additional issues have been raised with
> more recent Xeon chipsets.
>
> This patchset disables the boot interrupt on these Xeon chipsets where
> this is possible with an additional mechanism.  In addition, this
> patchset includes documentation covering the background of this quirk.

Well done! The documentation is really appreciated!

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>