From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Zheng, Lv" <lv.zheng@intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"Moore, Robert" <robert.moore@intel.com>
Subject: Re: [PATCH 0/4] ACPICA: Stable material of ACPI executer fixes for linux-3.8.
Date: Sat, 23 Nov 2013 19:21:53 -0800 [thread overview]
Message-ID: <20131124032153.GA25485@kroah.com> (raw)
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E880247A0C8@SHSMSX101.ccr.corp.intel.com>
On Fri, Nov 01, 2013 at 02:58:16AM +0000, Zheng, Lv wrote:
> > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > Sent: Thursday, October 31, 2013 8:22 PM
> >
> > On Thursday, October 31, 2013 05:08:50 AM Greg Kroah-Hartman wrote:
> > > On Thu, Oct 31, 2013 at 12:39:21PM +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, October 31, 2013 09:07:40 AM Lv Zheng wrote:
> > > > > There are bug-fixes for AML interpreter upstreamed, fixing some serious
> > > > > issues found in recent platforms. These fixes make Linux AML interpreter
> > > > > more ACPI 2.0 ASL concept compliant. Further AML interpreter fixes should
> > > > > be based on such improvements, thus they are good materials for stable.
> > > > >
> > > > > This patch set can be safely applied to linux-3.8:
> > > > > commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 upstream.
> > > > >
> > > > > The patch set has passed build/boot tests on the following machines:
> > > > > Dell Inspiron Mini 1010 (i386)
> > > > > HP Compaq 8200 Elite SFF PC (x86-64)
> > > > >
> > > > > Bob Moore (4):
> > > > > ACPICA: Interpreter: Fix Store() when implicit conversion is not
> > > > > possible.
> > > > > ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and
> > > > > BufferField refs.
> > > > > ACPICA: Return error if DerefOf resolves to a null package element.
> > > > > ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a
> > > > > field.
> > > >
> > > > Hi Greg,
> > > >
> > > > Please take patches [1-4/4] for stable.
> > >
> > > "Which" stable tree?
> > >
> > > I don't do 3.8, it's long been end-of-life, although one company is
> > > trying to keep it alive, but that's not me.
> > >
> > > I'm only handling 3.4, 3.10, and 3.11 stable trees right now, which
> > > one(s) should these be applied to?
> >
> > 3.10.x and 3.11.x then.
> >
> > Lv, do the original mainline commits apply to these kernels?
> >
> > Rafael
>
> Hi, Rafael and Greg
>
> I checked the back port dependencies since v3.8:
> 1. [PATCH 1] belongs to v3.9.
> 2. [PATCH 4] includes an empty line belonging to a coding style fix affecting this series (between [PATCH 3] and [PATCH 4]).
> Thus,
> 1. For v3.10:
> [PATCH 1]: It's already in the repo, so please drop it.
> [PATCH 2-4]: They can be used directly as 3.10.x stable materials.
> 2. For v3.11:
> [PATCH 1]: It's already in the repo, so please drop it.
> [PATCH 2-3]: They can be used directly as 3.11.x stable materials.
> [PATCH 4]: The original commit from Linus' tree should be used instead.
>
> I checked the commit log since v3.4.
> There is no functional change done to the AML executer between v3.4 and v3.8.
> The problem is there is a coding style fix affecting this series (between v3.4 and [PATCH 1]).
> I generated the following diff block before applying [PATCH 1], and obtained a successful build/boot to a v3.4 kernel with these patches applied.
> Thus,
> 1. For v3.4:
> [PATCH 1]: You can merge this diff block to [PATCH 1] or simply modify the [PATCH 1] by manually adding this white space.
> [PATCH 2-4]: They can be used directly as 3.4.x stable materials.
Ok, I think I have this all properly queued up for 3.4, 3.10, and
3.11-stable trees, can you please check and verify I didn't mess
anything up?
thanks,
greg k-h
next prev parent reply other threads:[~2013-11-24 3:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-31 1:07 [PATCH 0/4] ACPICA: Stable material of ACPI executer fixes for linux-3.8 Lv Zheng
2013-10-31 1:09 ` [PATCH 1/4] ACPICA: Interpreter: Fix Store() when implicit conversion is not possible Lv Zheng
2013-10-31 1:09 ` [PATCH 2/4] ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and BufferField refs Lv Zheng
2013-10-31 1:10 ` [PATCH 3/4] ACPICA: Return error if DerefOf resolves to a null package element Lv Zheng
2013-10-31 1:10 ` [PATCH 4/4] ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a field Lv Zheng
2013-10-31 11:39 ` [PATCH 0/4] ACPICA: Stable material of ACPI executer fixes for linux-3.8 Rafael J. Wysocki
2013-10-31 12:08 ` Greg Kroah-Hartman
2013-10-31 12:22 ` Rafael J. Wysocki
2013-11-01 2:58 ` Zheng, Lv
2013-11-24 3:21 ` Greg Kroah-Hartman [this message]
2013-11-25 2:51 ` Zheng, Lv
2013-10-31 16:12 ` Kamal Mostafa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131124032153.GA25485@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=rjw@rjwysocki.net \
--cc=robert.moore@intel.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox