RE: [PATCH] x86/acpi: Fix improper handling of SCI INT for platforms supporting only IOAPIC mode

["Sajjan, Vikas C" <vikas.cha.sajjan@hpe.com>]

Hi Rafael,

-----Original Message-----
From: rjwysocki@gmail.com [mailto:rjwysocki@gmail.com] On Behalf Of Rafael J. Wysocki
Sent: Wednesday, November 15, 2017 10:51 PM
To: Sajjan, Vikas C <vikas.cha.sajjan@hpe.com>
Cc: Linux PM <linux-pm@vger.kernel.org>; ACPI Devel Maling List <linux-acpi@vger.kernel.org>; Rafael J. Wysocki <rjw@rjwysocki.net>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Seunghun Han <kkamagui@gmail.com>; Thomas Gleixner <tglx@linutronix.de>; Ingo Molnar <mingo@kernel.org>; Lakshminarasimha, Sunil Vishwanathpur <sunil.vl@hpe.com>; Attar, Abdul Lateef <abdul-lateef.attar@hpe.com>
Subject: Re: [PATCH] x86/acpi: Fix improper handling of SCI INT for platforms supporting only IOAPIC mode

On Fri, Nov 10, 2017 at 10:38 AM, Vikas C Sajjan <vikas.cha.sajjan@hpe.com> wrote:
> The platforms which support only IOAPIC mode and whose SCI INT is 
> greater than 16, passes SCI INT via FADT and not via MADT int src 
> override structure. In such cases current logic fails to handle it and 
> throws error "Invalid bus_irq %u for legacy override". This patch 
> handles the above  mentioned case. While at it, also modify function 
> mp_override_legacy_irq() to use the newly introduced function mp_register_ioapic_irq().

Actually, is it necessary to make this extra change here?

How complicated would it be to separate it out?

I can move these extra changes into a separate patch and keep only the fix in this patch.

Thanks,
Rafael

Thanks,
Vikas Sajjan