[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0jQErbC729H0JCjO-RqJRYZ8P2zHdJm0HopXNB781G_aw@mail.gmail.com>
Date: Wed, 15 Nov 2017 18:58:44 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: "Sajjan, Vikas C" <vikas.cha.sajjan@....com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Linux PM <linux-pm@...r.kernel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Seunghun Han <kkamagui@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
"Lakshminarasimha, Sunil Vishwanathpur" <sunil.vl@....com>,
"Attar, Abdul Lateef" <abdul-lateef.attar@....com>
Subject: Re: [PATCH] x86/acpi: Fix improper handling of SCI INT for platforms
supporting only IOAPIC mode
On Wed, Nov 15, 2017 at 6:30 PM, Sajjan, Vikas C
<vikas.cha.sajjan@....com> wrote:
> Hi Rafael,
>
> -----Original Message-----
> From: rjwysocki@...il.com [mailto:rjwysocki@...il.com] On Behalf Of Rafael J. Wysocki
> Sent: Wednesday, November 15, 2017 10:51 PM
> To: Sajjan, Vikas C <vikas.cha.sajjan@....com>
> Cc: Linux PM <linux-pm@...r.kernel.org>; ACPI Devel Maling List <linux-acpi@...r.kernel.org>; Rafael J. Wysocki <rjw@...ysocki.net>; Linux Kernel Mailing List <linux-kernel@...r.kernel.org>; Seunghun Han <kkamagui@...il.com>; Thomas Gleixner <tglx@...utronix.de>; Ingo Molnar <mingo@...nel.org>; Lakshminarasimha, Sunil Vishwanathpur <sunil.vl@....com>; Attar, Abdul Lateef <abdul-lateef.attar@....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@....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.
That would be useful I think in case someone wants to backport your
fix, for example.
Thanks,
Rafael
Powered by blists - more mailing lists