[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0gSNscOwpY9Edg4nLJWX8JMdo7v81vFrgzMLUkCMuFJ1Q@mail.gmail.com>
Date: Thu, 18 Feb 2016 21:45:59 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Matt Fleming <matt@...eblueprint.co.uk>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
"Zheng, Lv" <lv.zheng@...el.com>, Dave Young <dyoung@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
Josh Triplett <josh@...htriplett.org>,
Borislav Petkov <bp@...en8.de>,
Matthew Garrett <mjg59@...f.ucam.org>,
Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH 1/2] ACPICA: Tables: Add function to remove ACPI tables
On Thu, Feb 18, 2016 at 9:41 PM, Matt Fleming <matt@...eblueprint.co.uk> wrote:
> On Thu, 18 Feb, at 09:15:28PM, Rafael J. Wysocki wrote:
>>
>> Actually, the reason is that, as a rule, the process for ACPICA
>> patches is that they first go to upstream ACPICA and they are acquired
>> by Linux from there.
>>
>> While there are some exceptions from that process, there also are good
>> reasons for that process to be followed, including the licensing one
>> mentioned by Lv.
>>
>> All that said, Matt, if you agree that the patch can be applied under
>> the BSD license, I think we can offer help with converting it to the
>> upstream ACPICA coding conventions and applying it there. Lv, would
>> you be able to take care of that?
>
> I don't have any problem with that, but can we hold off on this patch
> for now? There's another approach to fixing the BGRT issue with kexec
> that's being discussed which would supersede this,
>
> https://lkml.kernel.org/r/20160218141544.GH2651@codeblueprint.co.uk
>
> Assuming this patch does get picked up again, I'm happy to respin it
> against upstream ACPICA, but how do I go about getting dependent
> patches merged, PATCH 2/2 in this case?
We generate a Linux version of the patch out of the upstream ACPICA
sources (semi-automatically) and that can be merged into Linux in
advance. We don't do that as a rule, but it can be done. That at
least ensures that we'll be consistent with future ACPICA updates from
the upstream.
Thanks,
Rafael
Powered by blists - more mailing lists