From: Shuah Khan <shuah.kh@samsung.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, stable@vger.kernel.org,
"shuahkhan@gmail.com" <shuahkhan@gmail.com>,
Shuah Khan <shuah.kh@samsung.com>
Subject: Re: [ 00/14] 3.4.61-stable review
Date: Fri, 06 Sep 2013 16:23:16 -0600 [thread overview]
Message-ID: <522A55D4.4000608@samsung.com> (raw)
In-Reply-To: <20130906184606.GB5274@kroah.com>
On 09/06/2013 12:46 PM, Greg Kroah-Hartman wrote:
> On Fri, Sep 06, 2013 at 11:47:01AM -0600, Shuah Khan wrote:
>> On 09/05/2013 02:28 PM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 3.4.61 release.
>>> There are 14 patches in this series, all will be posted as a response
>>> to this one. If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Sat Sep 7 20:25:41 UTC 2013.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.61-rc1.gz
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>> -------------
>>
>>
>> 3.4.61-rc1 applied cleanly to 3.4.60
>>
>> Compiled and booted on the following systems:
>>
>> Samsung Series 9 900X4C Intel Corei5
>> HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
>>
>> dmesgs look good. No regressions compared to the previous dmesgs for
>> this release. dmesg emerg, crit, alert, err are clean. No
>> regressions in warn.
>
> Thanks for testing and letting me know.
>
>> Compile tested on Samsung Chromebook Exynos5 (ARMv7):
>> 3.4.60 compile fail - it is not a regression. Existing issue in
>> 3.4.y It has to do with missing config selections in
>> arch/arm/mach-exynos/Kconfig for this system. Debugging now using
>> the Kconfig selections from 3.10.y for this file.
>
> Is there a patch I can backport for this to work properly? I'd like to
> get some type of ARM coverage if possible.
>
> thanks,
>
> greg k-h
>
Greg,
I did some debugging and found 3.4 needs several patches to that made
exynos4 support common for exynos4 and exynos5. It appears some changes
made it into 3.4, at least changing the directory name from mach-exynos4
to mach-exynos, however the rest of the support is not in 3.4. I
identified the following commits:
6f9e95e6ed34ceff090ec1a1d27dfc85828d1dbd
60e49ca654eea42e04912b259fa36bad2c3e56ef
20ef9e08d27b3f5e09c32d4d371fa97f610a3069
b1b3f49ce4606452279b58b17f2bbe2ba00304b
Essentially every single commit that adds support for these config options:
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index b8df521..3be8f7c 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -61,6 +61,11 @@ config SOC_EXYNOS5250
bool "SAMSUNG EXYNOS5250"
default y
depends on ARCH_EXYNOS5
+ select PM_GENERIC_DOMAINS if PM
+ select S5P_PM if PM
+ select S5P_SLEEP if PM
+ select S5P_DEV_MFC
+ select SAMSUNG_DMADEV
help
Enable EXYNOS5250 SoC support
I am guessing you wouldn't want to make such extensive changes to 3.4 to
add full support for Chromebook.
3.10.y has full support for all of the above.
Thoughts. Agree with my assessment?
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658
next prev parent reply other threads:[~2013-09-06 22:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-05 20:28 [ 00/14] 3.4.61-stable review Greg Kroah-Hartman
2013-09-05 20:28 ` [ 01/14] jfs: fix readdir cookie incompatibility with NFSv4 Greg Kroah-Hartman
2013-09-05 20:28 ` [ 02/14] ALSA: opti9xx: Fix conflicting driver object name Greg Kroah-Hartman
2013-09-05 20:28 ` [ 03/14] powerpc: Work around gcc miscompilation of __pa() on 64-bit Greg Kroah-Hartman
2013-09-05 20:28 ` [ 04/14] powerpc/hvsi: Increase handshake timeout from 200ms to 400ms Greg Kroah-Hartman
2013-09-05 20:28 ` [ 05/14] regmap: silence GCC warning Greg Kroah-Hartman
2013-09-05 20:28 ` [ 06/14] drivers/base/memory.c: fix show_mem_removable() to handle missing sections Greg Kroah-Hartman
2013-09-05 20:28 ` [ 07/14] drm/vmwgfx: Split GMR2_REMAP commands if they are to large Greg Kroah-Hartman
2013-09-05 20:28 ` [ 08/14] drm/i915: ivb: fix edp voltage swing reg val Greg Kroah-Hartman
2013-09-05 20:28 ` [ 09/14] SUNRPC: Fix memory corruption issue on 32-bit highmem systems Greg Kroah-Hartman
2013-09-05 20:28 ` [ 10/14] ath9k_htc: Restore skb headroom when returning skb to mac80211 Greg Kroah-Hartman
2013-09-05 20:28 ` [ 11/14] iwl4965: fix rfkill set state regression Greg Kroah-Hartman
2013-09-05 20:28 ` [ 12/14] ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT Greg Kroah-Hartman
2013-09-05 20:28 ` [ 13/14] target: Fix trailing ASCII space usage in INQUIRY vendor+model Greg Kroah-Hartman
2013-09-05 20:28 ` [ 14/14] SCSI: sg: Fix user memory corruption when SG_IO is interrupted by a signal Greg Kroah-Hartman
2013-09-05 22:56 ` [ 00/14] 3.4.61-stable review Guenter Roeck
2013-09-06 16:39 ` Greg Kroah-Hartman
2013-09-06 17:58 ` Guenter Roeck
2013-09-06 17:47 ` Shuah Khan
2013-09-06 18:46 ` Greg Kroah-Hartman
2013-09-06 22:23 ` Shuah Khan [this message]
2013-09-06 23:11 ` Greg Kroah-Hartman
2013-09-06 23:24 ` Shuah Khan
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=522A55D4.4000608@samsung.com \
--to=shuah.kh@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shuahkhan@gmail.com \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).