linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: olof@lixom.net (Olof Johansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] Samsung fixes for v3.4
Date: Sat, 12 May 2012 15:48:23 -0700	[thread overview]
Message-ID: <CAOesGMhhseR+WPru4xen7ijHCC91cBWqaZpJAHEAFLgyUiNQ3w@mail.gmail.com> (raw)
In-Reply-To: <4FAEF5FD.6070904@samsung.com>

On Sat, May 12, 2012 at 4:45 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> On 05/13/12 07:29, Olof Johansson wrote:
>>
>> Hi,
>>
>>
>> Since we are _so_ close to release, I am going to be picky about what
>> kind of patches we're going to accept for 3.4. See below.
>>
>> On Sat, May 12, 2012 at 2:42 PM, Kukjin Kim<kgene.kim@samsung.com> ?wrote:
>>
>>
>>> Changhwan Youn (1):
>>> ? ? ?ARM: EXYNOS: fix the hotplug for Cortex-A15
>>
>>
>> This is a feature, not a bug fix -- cpu hotplug has never worked for
>> A15 based on the patch description. So per definition it's 3.5
>> material.
>>
> Hmm, in this case, IMHO, it's hard to say whether it is not a bug fix
> because in current mach-exynos/ problem happens during cpu hotplug on
> exynos5250 without that...But, OK it will be queued for v3.5.

Agreed, it's a borderline case -- and earlier in the -rc cycle I would
have included this one without complaints.

>> Also, I'll send out a comment on the patch itself, it shouldn't check
>> for SoC version, it should check for core version. See separate email
>> shortly.
>>
> OK, thanks for your comments and will update it even though checking SoC
> version is enough in mach-exynos/ :)

Well, sort of -- you will need to add new checks when you add another
SoC with A15, and that's just messy. If you check for A15 instead,
then you won't have to modify that piece of code for every new SoC
(hopefully).

>>> Jose Miguel Goncalves (1):
>>> ? ? ?ARM: SAMSUNG: Fix for S3C2412 EBI memory mapping
>>
>>
>> This has been broken since 2.6.32. Please queue it up in a fixes
>> branch for the 3.5 merge window instead, it doesn't qualify as a
>> recent regression and thus we shouldn't try to squeeze it in before
>> the merge window closes.
>>
> OK, I agree.
>
>
>>> Kukjin Kim (1):
>>> ? ? ?ARM: EXYNOS: fix ctrlbit for exynos5_clk_pdma1
>>>
>>> Marek Szyprowski (1):
>>> ? ? ?ARM: EXYNOS: use s5p-timer for UniversalC210 board
>>
>>
>> Those two look appropriate. Please send a new pull request with those two.
>>
> I sent just now.

Thanks for the quick turnaround!


-Olof

      reply	other threads:[~2012-05-12 22:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-12 21:42 [GIT PULL] Samsung fixes for v3.4 Kukjin Kim
2012-05-12 22:29 ` Olof Johansson
2012-05-12 23:37   ` Kukjin Kim
2012-05-12 22:49     ` Olof Johansson
2012-05-12 23:45   ` Kukjin Kim
2012-05-12 22:48     ` Olof Johansson [this message]

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=CAOesGMhhseR+WPru4xen7ijHCC91cBWqaZpJAHEAFLgyUiNQ3w@mail.gmail.com \
    --to=olof@lixom.net \
    --cc=linux-arm-kernel@lists.infradead.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).