* [GIT PULL] Samsung fixes-4 for v3.16
From: Kukjin Kim @ 2014-07-18 23:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is a regression for v3.16 so please take this in -rc.
Thanks,
Kukjin
The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab:
Linux 3.16-rc5 (2014-07-13 14:04:33 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
tags/samsung-fixes-4
for you to fetch changes up to 4e3a498d6fc438d8c203c51aadc6ca8fb47b0577:
ARM: EXYNOS: Fix core ID used by platsmp and hotplug code (2014-07-16
02:59:18 +0900)
----------------------------------------------------------------
Samsung fixes-4 for v3.16
- Fix core ID for platsmp and hotplug
This fixes existing calculation of PMU register offsets on
exynos SoCs and this also fixes CPU hotplug with more than
2 cores, because it removes incorrect condition check in
platform_do_lowpower().
----------------------------------------------------------------
Tomasz Figa (1):
ARM: EXYNOS: Fix core ID used by platsmp and hotplug code
arch/arm/mach-exynos/hotplug.c | 10 ++++++----
arch/arm/mach-exynos/platsmp.c | 34 +++++++++++++++++++---------------
2 files changed, 25 insertions(+), 19 deletions(-)
^ permalink raw reply
* [PATCH 13/19] ARM: s5pv210: move debug-macro.S into the common space
From: Tomasz Figa @ 2014-07-18 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C9779E.7060400@samsung.com>
Hi Kukjin,
On 18.07.2014 21:38, Kukjin Kim wrote:
> On 07/16/14 09:56, Tomasz Figa wrote:
>> On 16.07.2014 02:53, Kukjin Kim wrote:
>>> Kukjin Kim wrote:
>>>>
>>>> On 07/05/14 02:48, Tomasz Figa wrote:
>>>>> Move debug-macro.S from mach/include to include/debug where
>>>>> all other common debug macros are.
>>>>>
>>>>> Signed-off-by: Tomasz Figa<t.figa@samsung.com>
>>>>> ---
>>>>> arch/arm/Kconfig.debug | 12 +++++--
>>>>> arch/arm/include/debug/s5pv210.S | 34
>>>>> ++++++++++++++++++++
>>>>> arch/arm/mach-s5pv210/include/mach/debug-macro.S | 41
>>>>> ------------------------
>>>>> 3 files changed, 44 insertions(+), 43 deletions(-)
>>>>> create mode 100644 arch/arm/include/debug/s5pv210.S
>>>>> delete mode 100644 arch/arm/mach-s5pv210/include/mach/debug-macro.S
>>>
>>> [...]
>>>
>>>> Tomasz,
>>>>
>>>> I couldn't apply this one from this your series because of conflict
>>>> with
>>>> others. Can you please respin this one?
>>>>
>>> One more note, since I didn't apply this, there is a build breakage for
>>> s5pv210_defconfig now...
>>>
>>> arch/arm/kernel/debug.S:24:33: fatal error: mach/debug-macro.S: No
>>> such file or directory
>>> compilation terminated.
>>> make[2]: *** [arch/arm/kernel/debug.o] Error 1
>>> make[1]: *** [arch/arm/kernel] Error 2
>>> make[1]: *** Waiting for unfinished jobs....
>>
>> Hmm? Are you sure previous patches applied correctly? I have tested this
>> series patch by patch on all affected configs and it built fine back
>> then. Maybe some conflict, I'll see tomorrow.
>>
> Tomasz, I've applied this whole series including this again. Can you
> please check my branch before sending pull-request to arm-soc for 3.17?
Thanks for applying this.
A quick look through the patches didn't reveal any issues.
s5pv210_defconfig builds fine too. I don't have any s5pv210-based board
at home, though, so I can't do anything else than compile testing until
Tuesday.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend
From: Stephen Boyd @ 2014-07-18 23:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C9A2E7.8020307@linaro.org>
On 07/18/14 15:42, John Stultz wrote:
> If its a regression (and needs -stable backports) it needs to go in via
> tip/timers/urgent, and not via the regular merge window.
>
> Whats the additional risk -stable wise for canceling the timer during
> suspend and starting it back up during resume?
>
I'd say close to zero given that we'd only be making the timer run a
little bit later and we have slack in there already. Here's that version.
----8<-----
Subject: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend
During suspend we call sched_clock_poll() to update the epoch and
accumulated time and reprogram the sched_clock_timer to fire
before the next wrap-around time. Unfortunately,
sched_clock_poll() doesn't restart the timer, instead it relies
on the hrtimer layer to do that and during suspend we aren't
calling that function from the hrtimer layer. Instead, we're
reprogramming the expires time while the hrtimer is enqueued,
which can cause the hrtimer tree to be corrupted. Furthermore, we
restart the timer during suspend but we update the epoch during
resume which seems counter-intuitive.
Let's fix this by saving the accumulated state and canceling the
timer during suspend. On resume we can update the epoch and
restart the timer similar to what we would do if we were starting
the clock for the first time.
Fixes: a08ca5d1089d "sched_clock: Use an hrtimer instead of timer"
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
kernel/time/sched_clock.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 445106d2c729..01d2d15aa662 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -191,7 +191,8 @@ void __init sched_clock_postinit(void)
static int sched_clock_suspend(void)
{
- sched_clock_poll(&sched_clock_timer);
+ update_sched_clock();
+ hrtimer_cancel(&sched_clock_timer);
cd.suspended = true;
return 0;
}
@@ -199,6 +200,7 @@ static int sched_clock_suspend(void)
static void sched_clock_resume(void)
{
cd.epoch_cyc = read_sched_clock();
+ hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
cd.suspended = false;
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* mvebu cpuidle and cpufreq branch handling for v3.17
From: Jason Cooper @ 2014-07-18 23:07 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof, Kevin,
I have two branches with the remaining mvebu SoC changes for v3.17.
They are mvebu/soc-cpuidle and mvebu/soc-cpufreq. Each branch is
slightly problematic because both contain changes to their respective
code in drivers/. To send the driver changes through the appropriate
subsystems would be a garish nightmare of branch on branch on branch.
Thankfully, the changes are isolated to drivers only mvebu uses, so
keeping it all together should cause minimal, if any, conflicts.
I've requested Acks from the appropriate maintainers but as it's summer
I'm not confident that we'll receive those Acks in time for the arm-soc
cutoff (-rc6 -ish).
As I see it, I could send arm-soc two topic branch pull requests, which
arm-soc would keep out separate on the remote chance of an objection.
Or, I could wait for the Acks (the code has already been in -next for
several days), merge it into mvebu/soc, and send a, most likely, late
pull request for it.
Which would you guys prefer?
The cpuidle branch and ML link:
git://git.infradead.org/linux-mvebu.git mvebu/soc-cpuidle
https://lkml.kernel.org/r/1404913221-17343-1-git-send-email-thomas.petazzoni at free-electrons.com
The cpufreq branch and ML link:
git://git.infradead.org/linux-mvebu.git mvebu/soc-cpufreq
https://lkml.kernel.org/r/1404920715-19834-1-git-send-email-thomas.petazzoni at free-electrons.com
thx,
Jason.
^ permalink raw reply
* [PATCH] arm64: Refactor compat.h into compat-types.h
From: Ian Campbell @ 2014-07-18 23:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717090758.GB21153@arm.com>
On Thu, 2014-07-17 at 10:07 +0100, Will Deacon wrote:
> On Thu, Jul 17, 2014 at 07:45:38AM +0100, Ian Campbell wrote:
> > This reduces the complexity of the includes needed for linux/stat.h and removes
> > some possibilities for causing include loops.
> >
> > One such issue was exposed by the Debian kernel's application of the aufs
> > patches which led to:
> >
> > In file included from /?PKGBUILDDIR?/include/linux/mm.h:23:0,
> > from /?PKGBUILDDIR?/include/linux/pid_namespace.h:6,
> > from /?PKGBUILDDIR?/include/linux/ptrace.h:9,
> > from /?PKGBUILDDIR?/arch/arm64/include/asm/compat.h:26,
> > from /?PKGBUILDDIR?/arch/arm64/include/asm/stat.h:23,
> > from /?PKGBUILDDIR?/include/linux/stat.h:5,
> > from /?PKGBUILDDIR?/include/linux/module.h:10,
> > from /?PKGBUILDDIR?/init/main.c:15:
> > /?PKGBUILDDIR?/include/linux/fs.h:1575:64: warning: 'struct kstat' declared inside parameter list [enabled by default]
> > int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *);
> > ^
> > /?PKGBUILDDIR?/include/linux/fs.h:1575:64: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> >
> > This is due to an extra fs.h include added to mm.h leading to a loop in the
> > includes. Splitting out the type defintions from compat.h into compat-types.h
> > allows asm/stat.h to only include the types header and avoids the loop.
> >
> > Full logs in http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=arm64&ver=3.14.12-1&stamp=1405234443
> >
> > Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: debian-kernel at lists.debian.org
>
> Looks good to me,
Thanks.
> but I note Arnd's prior comment about mm.h including fs.h
> being a bug. If that's true, then this patch isn't needed at all and aufs
> should be fixed instead.
That's true as well and I've got a fix on the aufs side in the works
too.
Simplifying the twisty header maze seems worthwhile in its own right too
though.
Ian.
^ permalink raw reply
* [PATCH] ARM: Don't oops when userspace executes kgdb break instructions.
From: Omar Sandoval @ 2014-07-18 22:51 UTC (permalink / raw)
To: linux-arm-kernel
Don't break into kgdb when userspace executes the kernel break instructions
(KGDB_BREAKINST and KGDB_COMPILED_BREAK). The kernel will oops in
kgdb_handle_exception.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
---
The following program will immediately cause a kernel oops:
.globl _start
_start:
udf #65006 @ KGDB_BREAKINST
arch/arm/kernel/kgdb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index 778c2f7..a74b53c 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -160,12 +160,16 @@ static int kgdb_compiled_brk_fn(struct pt_regs *regs, unsigned int instr)
static struct undef_hook kgdb_brkpt_hook = {
.instr_mask = 0xffffffff,
.instr_val = KGDB_BREAKINST,
+ .cpsr_mask = MODE_MASK,
+ .cpsr_val = SVC_MODE,
.fn = kgdb_brk_fn
};
static struct undef_hook kgdb_compiled_brkpt_hook = {
.instr_mask = 0xffffffff,
.instr_val = KGDB_COMPILED_BREAK,
+ .cpsr_mask = MODE_MASK,
+ .cpsr_val = SVC_MODE,
.fn = kgdb_compiled_brk_fn
};
--
2.0.1
^ permalink raw reply related
* [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend
From: John Stultz @ 2014-07-18 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C9A1EC.8060905@codeaurora.org>
On 07/18/2014 03:38 PM, Stephen Boyd wrote:
> On 07/18/14 15:25, John Stultz wrote:
>> On 07/18/2014 03:09 PM, Stephen Boyd wrote:
>>> During suspend we call sched_clock_poll() to update the epoch and
>>> accumulated time and reprogram the sched_clock_timer to fire
>>> before the next wrap-around time. Unfortunately,
>>> sched_clock_poll() doesn't restart the timer, instead it relies
>>> on the hrtimer layer to do that and during suspend we aren't
>>> calling that function from the hrtimer layer. Instead, we're
>>> reprogramming the expires time while the hrtimer is enqueued,
>>> which can cause the hrtimer tree to be corrupted. Fix this
>>> problem by updating the state via update_sched_clock() and
>>> properly restarting the timer via hrtimer_start().
>>>
>>> Fixes: a08ca5d1089d "sched_clock: Use an hrtimer instead of timer"
>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>>> ---
>>>
>>> I also wonder if we should be restarting the timer during resume
>>> instead of suspend given that the resume path modifies the epoch.
>>> At that point timers can't run because interrupts are disabled and
>>> we don't really care if the timer fires earlier than it's supposed
>>> to anyway because it's just there to avoid rollover events, but
>>> does it seem better to do it that way? I didn't send that version
>>> because this patch is to fix the code intention, but I'm curious
>>> if anyone else feels like it should be changed.
>> Yea, starting the timer on suspend seems unintuitive to me.
>>
>> Is this something you were hoping to get in for 3.17 or is this a urgent
>> 3.16 item?
> Ok I'll send a follow up patch to cancel during suspend and start during
> resume, unless you want that to be part of this fix? It's a regression
> back to v3.13 so I would think it's urgent, although I haven't seen any
> reports on the mailing list, just reports on some of our android kernels.
If its a regression (and needs -stable backports) it needs to go in via
tip/timers/urgent, and not via the regular merge window.
Whats the additional risk -stable wise for canceling the timer during
suspend and starting it back up during resume?
thanks
-john
^ permalink raw reply
* [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend
From: Stephen Boyd @ 2014-07-18 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C99EC5.2060602@linaro.org>
On 07/18/14 15:25, John Stultz wrote:
> On 07/18/2014 03:09 PM, Stephen Boyd wrote:
>> During suspend we call sched_clock_poll() to update the epoch and
>> accumulated time and reprogram the sched_clock_timer to fire
>> before the next wrap-around time. Unfortunately,
>> sched_clock_poll() doesn't restart the timer, instead it relies
>> on the hrtimer layer to do that and during suspend we aren't
>> calling that function from the hrtimer layer. Instead, we're
>> reprogramming the expires time while the hrtimer is enqueued,
>> which can cause the hrtimer tree to be corrupted. Fix this
>> problem by updating the state via update_sched_clock() and
>> properly restarting the timer via hrtimer_start().
>>
>> Fixes: a08ca5d1089d "sched_clock: Use an hrtimer instead of timer"
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>>
>> I also wonder if we should be restarting the timer during resume
>> instead of suspend given that the resume path modifies the epoch.
>> At that point timers can't run because interrupts are disabled and
>> we don't really care if the timer fires earlier than it's supposed
>> to anyway because it's just there to avoid rollover events, but
>> does it seem better to do it that way? I didn't send that version
>> because this patch is to fix the code intention, but I'm curious
>> if anyone else feels like it should be changed.
> Yea, starting the timer on suspend seems unintuitive to me.
>
> Is this something you were hoping to get in for 3.17 or is this a urgent
> 3.16 item?
Ok I'll send a follow up patch to cancel during suspend and start during
resume, unless you want that to be part of this fix? It's a regression
back to v3.13 so I would think it's urgent, although I haven't seen any
reports on the mailing list, just reports on some of our android kernels.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v2 8/7] seccomp: Document two-phase seccomp and arch-provided seccomp_data
From: Andy Lutomirski @ 2014-07-18 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1405717901.git.luto@amacapital.net>
The description of how arches should implement seccomp filters was
still strictly correct, but it failed to describe the newly
available optimizations.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
I lost this somehow. Here it as an an extra patch. If I end up sending
a v3, I'll fold it in.
arch/Kconfig | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index 0eae9df..05d7a8a 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -323,6 +323,17 @@ config HAVE_ARCH_SECCOMP_FILTER
results in the system call being skipped immediately.
- seccomp syscall wired up
+ For best performance, an arch should use seccomp_phase1 and
+ seccomp_phase2 directly. It should call seccomp_phase1 for all
+ syscalls if TIF_SECCOMP is set, but seccomp_phase1 does not
+ need to be called from a ptrace-safe context. It must then
+ call seccomp_phase2 if seccomp_phase1 returns anything other
+ than SECCOMP_PHASE1_OK or SECCOMP_PHASE1_SKIP.
+
+ As an additional optimization, an arch may provide seccomp_data
+ directly to seccomp_phase1; this avoids multiple calls
+ to the syscall_xyz helpers for every syscall.
+
config SECCOMP_FILTER
def_bool y
depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET
--
1.9.3
^ permalink raw reply related
* [PATCH] MAINTAINERS: Remove Kirkwood
From: Jason Cooper @ 2014-07-18 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMhGx_9eBhbJXd918un5JuP1jK2mpQ0gF6Z-Mp1=C-SjfQ@mail.gmail.com>
On Fri, Jul 18, 2014 at 02:43:26PM -0700, Olof Johansson wrote:
> On Thu, Jul 17, 2014 at 5:23 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> > All,
> >
> > Original patch bounced to arm-soc maintainers and their email alias.
>
> Either something happened to the bounce, or gmail ignored it, since I
> certainly didn't get a copy of the original email in my inbox (nor the
> arm at kernel.org folder).
hmmm, that's odd. I've bounced patches to ThomasP before, perhaps it's
on the gmail side?
> Anyway, I'll dig it out of the list folder and apply it.
Thanks, and sorry for the hassle.
thx,
Jason.
^ permalink raw reply
* [GIT PULL] ARM: mvebu: DT changes for v3.17 (round 2)
From: Jason Cooper @ 2014-07-18 22:27 UTC (permalink / raw)
To: linux-arm-kernel
All,
Here's the accumulated DT changes for v3.17.
Incremental pull request from tags/mvebu-dt-3.17 up to
tags/mvebu-dt-3.17-2 on the mvebu/dt branch.
Please pull.
thx,
Jason.
The following changes since commit d854fa8a1500bec982ed9cb26b82d96bd5ae8dab:
ARM: kirkwood: fix net5big regulator gpio assignments (2014-06-21 19:21:13 +0000)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-3.17-2
for you to fetch changes up to 3843607838cc5436d02a6771e661969a54c2fee0:
ARM: mvebu: update Armada XP DT for dynamic frequency scaling (2014-07-16 12:54:13 +0000)
----------------------------------------------------------------
mvebu DT changes for v3.17 (round 2)
- kirkwood
- Add d2 Network v2 board
- mvebu
- Add Armada 375 ethernet node
- Add CA9 MPcore SoC controller node
- Add support for dynamic freq scaling on Armada XP
----------------------------------------------------------------
Ezequiel Garcia (2):
ARM: mvebu: Add support for the network controller in Armada 375 SoC
ARM: mvebu: Enable the network controller in Armada 375 DB board
Gregory CLEMENT (1):
ARM: mvebu: add CA9 MPcore SoC Controller node
Simon Guinot (2):
ARM: Kirkwood: allow to use netxbig DTSI for d2net_v2 DTS
ARM: Kirkwood: add DT support for d2 Network v2
Thomas Petazzoni (1):
ARM: mvebu: update Armada XP DT for dynamic frequency scaling
.../bindings/arm/armada-380-mpcore-soc-ctrl.txt | 14 ++++++++
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-375-db.dts | 26 ++++++++++++++
arch/arm/boot/dts/armada-375.dtsi | 31 ++++++++++++++++
arch/arm/boot/dts/armada-38x.dtsi | 5 +++
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 2 ++
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 2 ++
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 4 +++
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
arch/arm/boot/dts/kirkwood-d2net.dts | 42 ++++++++++++++++++++++
arch/arm/boot/dts/kirkwood-net2big.dts | 30 ++++++++++++++++
arch/arm/boot/dts/kirkwood-net5big.dts | 28 +++++++++++++++
arch/arm/boot/dts/kirkwood-netxbig.dtsi | 26 --------------
13 files changed, 186 insertions(+), 27 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt
create mode 100644 arch/arm/boot/dts/kirkwood-d2net.dts
^ permalink raw reply
* [PATCH v2 3/7] seccomp: Allow arch code to provide seccomp_data
From: Andy Lutomirski @ 2014-07-18 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jLsnSujJdZmA=nzHw1_K3eYhSiUEnntJ3S2hCZ8DFVYpg@mail.gmail.com>
On Fri, Jul 18, 2014 at 3:16 PM, Kees Cook <keescook@chromium.org> wrote:
> On Fri, Jul 18, 2014 at 2:18 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> populate_seccomp_data is expensive: it works by inspecting
>> task_pt_regs and various other bits to piece together all the
>> information, and it's does so in multiple partially redundant steps.
>>
>> Arch-specific code in the syscall entry path can do much better.
>>
>> Admittedly this adds a bit of additional room for error, but the
>> speedup should be worth it.
>
> I still think we should gain either a note in the
> HAVE_ARCH_SECCOMP_FILTER help text in arch/Kconfig, or possibly a new
> section in Documentation/prctl/seccomp.txt (or similar) on how do
> implement filter support for an architecture, that mentions the
> arch-supplied seccomp_data and how two-phase can be done.
I would have sworn I did that. I distinctly remember typing that
text. I must have failed to commit it.
I'll send a followup patch.
--Andy
>
> -Kees
>
> --
> Kees Cook
> Chrome OS Security
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend
From: John Stultz @ 2014-07-18 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405721392-30795-1-git-send-email-sboyd@codeaurora.org>
On 07/18/2014 03:09 PM, Stephen Boyd wrote:
> During suspend we call sched_clock_poll() to update the epoch and
> accumulated time and reprogram the sched_clock_timer to fire
> before the next wrap-around time. Unfortunately,
> sched_clock_poll() doesn't restart the timer, instead it relies
> on the hrtimer layer to do that and during suspend we aren't
> calling that function from the hrtimer layer. Instead, we're
> reprogramming the expires time while the hrtimer is enqueued,
> which can cause the hrtimer tree to be corrupted. Fix this
> problem by updating the state via update_sched_clock() and
> properly restarting the timer via hrtimer_start().
>
> Fixes: a08ca5d1089d "sched_clock: Use an hrtimer instead of timer"
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> I also wonder if we should be restarting the timer during resume
> instead of suspend given that the resume path modifies the epoch.
> At that point timers can't run because interrupts are disabled and
> we don't really care if the timer fires earlier than it's supposed
> to anyway because it's just there to avoid rollover events, but
> does it seem better to do it that way? I didn't send that version
> because this patch is to fix the code intention, but I'm curious
> if anyone else feels like it should be changed.
Yea, starting the timer on suspend seems unintuitive to me.
Is this something you were hoping to get in for 3.17 or is this a urgent
3.16 item?
thanks
-john
^ permalink raw reply
* [GIT PULL RESEND] ARM: mvebu: DT changes for v3.17
From: Jason Cooper @ 2014-07-18 22:24 UTC (permalink / raw)
To: linux-arm-kernel
All,
After discussion with Arnd, this is a resend of my previous pull
request.
Please pull.
thx,
Jason.
The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-3.17
for you to fetch changes up to d854fa8a1500bec982ed9cb26b82d96bd5ae8dab:
ARM: kirkwood: fix net5big regulator gpio assignments (2014-06-21 19:21:13 +0000)
----------------------------------------------------------------
mvebu DT changes for v3.17
- kirkwood
- add boards net2big and net5big
- dove
- add vendor prefix for SolidRun
- split CuBox into it's variants
----------------------------------------------------------------
Andrew Lunn (1):
ARM: Kirkwood: Add DT descriptions for net2big and net5big.
Jason Cooper (1):
ARM: kirkwood: fix net5big regulator gpio assignments
Sebastian Hesselbarth (2):
dt-binding: add vendor prefix for SolidRun
ARM: dts: mvebu: split SolidRun CuBox into variants
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 3 +
arch/arm/boot/dts/dove-cubox-es.dts | 12 ++
arch/arm/boot/dts/dove-cubox.dts | 3 -
arch/arm/boot/dts/kirkwood-net2big.dts | 30 ++++
arch/arm/boot/dts/kirkwood-net5big.dts | 83 ++++++++++
arch/arm/boot/dts/kirkwood-netxbig.dtsi | 180 +++++++++++++++++++++
7 files changed, 309 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/boot/dts/dove-cubox-es.dts
create mode 100644 arch/arm/boot/dts/kirkwood-net2big.dts
create mode 100644 arch/arm/boot/dts/kirkwood-net5big.dts
create mode 100644 arch/arm/boot/dts/kirkwood-netxbig.dtsi
^ permalink raw reply
* [GIT PULL] ARM: mvebu: DT changes for v3.17
From: Olof Johansson @ 2014-07-18 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4961691.1JRP1YEOt8@wuerfel>
On Fri, Jul 18, 2014 at 03:29:53PM +0200, Arnd Bergmann wrote:
> On Thursday 17 July 2014 08:35:50 Jason Cooper wrote:
> > Olof, Arnd, please merge this request. I can re-send if you need.
> >
> > We have more changes pending in mvebu/dt on top of this, and we're
> > getting very close to the cutoff for the merge window.
>
> Please send both pull requests now so we can look at the whole
> picture. No need for you to wait for this to be merged before
> sending the follow-up pull request.
>
> I think we should just merge, there is no nice solution for
> the technical problem and the approach you have taken looks
> like the least problematic one to me.
>
> Olof, any further thoughts on this?
I have a CuBox, and based on USB id for the UART, it's an ES model.
Since the only thing that breaks seems to be SD, I can personally live with
that just fine even if I have to refer to the non-ES dtb for backwards
compatibility.
If this requires more discussion then the obvious solution is to leave out
these patches and send the superceding DT pull request of a branch that doesn't
have them. I think we can take this as it is for now though -- I suspect in
reality the number of affected ES owners should be pretty small?
-Olof
^ permalink raw reply
* [PATCH v2 3/7] seccomp: Allow arch code to provide seccomp_data
From: Kees Cook @ 2014-07-18 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ce65e0e8be18ae8fab437899db44ca41c912b506.1405717901.git.luto@amacapital.net>
On Fri, Jul 18, 2014 at 2:18 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> populate_seccomp_data is expensive: it works by inspecting
> task_pt_regs and various other bits to piece together all the
> information, and it's does so in multiple partially redundant steps.
>
> Arch-specific code in the syscall entry path can do much better.
>
> Admittedly this adds a bit of additional room for error, but the
> speedup should be worth it.
I still think we should gain either a note in the
HAVE_ARCH_SECCOMP_FILTER help text in arch/Kconfig, or possibly a new
section in Documentation/prctl/seccomp.txt (or similar) on how do
implement filter support for an architecture, that mentions the
arch-supplied seccomp_data and how two-phase can be done.
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* [GIT PULL] ARM: mvebu: defconfig changes for v3.17 (round 2)
From: Jason Cooper @ 2014-07-18 22:13 UTC (permalink / raw)
To: linux-arm-kernel
All,
Here's all the defconfig changes we have for mvebu this time around.
The big one is the removal of kirkwood_defconfig, cooresponding to the
mach-kirkwood/ removal in mvebu/soc.
This is an incremental pull request from tags/mvebu-defconfig-3.17 up to
tags/mvebu-defconfig-3.17-2 on the mvebu/defconfig branch.
Please pull.
thx,
Jason.
The following changes since commit 5658d58545388850c77a070fb3b882ddd958eb88:
ARM: multi_v5: Enable LaCie 2Big and 5Big Network v2 (2014-06-20 20:50:23 +0000)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-defconfig-3.17-2
for you to fetch changes up to c1eed8d2ff67b18f3892016f40ad6899ac6cf477:
ARM: mvebu: update mvebu_v7_defconfig with cpufreq support (2014-07-16 12:51:39 +0000)
----------------------------------------------------------------
mvebu defconfig changes for v3.17 (round 2)
- mvebu
- Add appended_dtb support
- Add devtmpfs support
- Add 375 network driver
- Add cpuidle support
- Add cpufreq support
- kirkwood
- Remove kirkwood_defconfig
----------------------------------------------------------------
Andrew Lunn (1):
ARM: Kirkwood: Remove kirkwood_defconfig
Gregory CLEMENT (1):
ARM: mvebu: defconfig: enable cpuidle support in mvebu_v7_defconfig
Marcin Wojtas (1):
ARM: mvebu: enable Armada 375 network driver in mvebu_v7_defconfig
Thomas Petazzoni (3):
ARM: mvebu: add appended DTB support in mvebu_v5_defconfig
ARM: mvebu: add devtmpfs to mvebu_v5_defconfig
ARM: mvebu: update mvebu_v7_defconfig with cpufreq support
arch/arm/configs/kirkwood_defconfig | 181 ------------------------------------
arch/arm/configs/mvebu_v5_defconfig | 4 +
arch/arm/configs/mvebu_v7_defconfig | 5 +
3 files changed, 9 insertions(+), 181 deletions(-)
delete mode 100644 arch/arm/configs/kirkwood_defconfig
^ permalink raw reply
* [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend
From: Stephen Boyd @ 2014-07-18 22:09 UTC (permalink / raw)
To: linux-arm-kernel
During suspend we call sched_clock_poll() to update the epoch and
accumulated time and reprogram the sched_clock_timer to fire
before the next wrap-around time. Unfortunately,
sched_clock_poll() doesn't restart the timer, instead it relies
on the hrtimer layer to do that and during suspend we aren't
calling that function from the hrtimer layer. Instead, we're
reprogramming the expires time while the hrtimer is enqueued,
which can cause the hrtimer tree to be corrupted. Fix this
problem by updating the state via update_sched_clock() and
properly restarting the timer via hrtimer_start().
Fixes: a08ca5d1089d "sched_clock: Use an hrtimer instead of timer"
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
I also wonder if we should be restarting the timer during resume
instead of suspend given that the resume path modifies the epoch.
At that point timers can't run because interrupts are disabled and
we don't really care if the timer fires earlier than it's supposed
to anyway because it's just there to avoid rollover events, but
does it seem better to do it that way? I didn't send that version
because this patch is to fix the code intention, but I'm curious
if anyone else feels like it should be changed.
kernel/time/sched_clock.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 445106d2c729..9e32ce88e9ee 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -191,7 +191,9 @@ void __init sched_clock_postinit(void)
static int sched_clock_suspend(void)
{
- sched_clock_poll(&sched_clock_timer);
+ update_sched_clock();
+ /* Restart the timer because we forced an update */
+ hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
cd.suspended = true;
return 0;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [GIT PULL] ARM: mvebu: SoC changes for v3.17 (round 2)
From: Jason Cooper @ 2014-07-18 22:05 UTC (permalink / raw)
To: linux-arm-kernel
All,
Yeah, it's just one patch, but it's a beautiful one! Thanks to the
efforts of many people over the last couple years, and in particular,
Andrew Lunn, Kirkwood has been completely converted to DT.
As usual, this is an incremental pull request from tags/mvebu-soc-3.17
up to tags/mvebu-soc-3.17-2 on the mvebu/soc branch.
Please pull.
thx,
Jason.
The following changes since commit e65714740d65237c40878b63acad6bf921481974:
ARM: mvebu: Staticize mvebu_cpu_reset_init (2014-06-30 17:41:04 +0000)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-soc-3.17-2
for you to fetch changes up to ba364fc752daeded072a5ef31e43b84cb1f9e5fd:
ARM: Kirkwood: Remove mach-kirkwood (2014-07-13 22:13:39 +0000)
----------------------------------------------------------------
mvebu SoC changes for v3.17 (round 2)
- kirkwood
- Remove mach-kirkwood/, It's fully supported in mach-mvebu/
----------------------------------------------------------------
Andrew Lunn (1):
ARM: Kirkwood: Remove mach-kirkwood
arch/arm/Kconfig | 18 -
arch/arm/Kconfig.debug | 5 +-
arch/arm/Makefile | 1 -
arch/arm/boot/dts/Makefile | 5 +-
arch/arm/mach-kirkwood/Kconfig | 111 ----
arch/arm/mach-kirkwood/Makefile | 14 -
arch/arm/mach-kirkwood/Makefile.boot | 3 -
arch/arm/mach-kirkwood/board-dt.c | 223 -------
arch/arm/mach-kirkwood/common.c | 746 ----------------------
arch/arm/mach-kirkwood/common.h | 74 ---
arch/arm/mach-kirkwood/d2net_v2-setup.c | 231 -------
arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 86 ---
arch/arm/mach-kirkwood/include/mach/entry-macro.S | 34 -
arch/arm/mach-kirkwood/include/mach/hardware.h | 14 -
arch/arm/mach-kirkwood/include/mach/irqs.h | 65 --
arch/arm/mach-kirkwood/include/mach/kirkwood.h | 142 ----
arch/arm/mach-kirkwood/include/mach/uncompress.h | 46 --
arch/arm/mach-kirkwood/irq.c | 82 ---
arch/arm/mach-kirkwood/lacie_v2-common.c | 114 ----
arch/arm/mach-kirkwood/lacie_v2-common.h | 16 -
arch/arm/mach-kirkwood/mpp.c | 43 --
arch/arm/mach-kirkwood/mpp.h | 348 ----------
arch/arm/mach-kirkwood/netxbig_v2-setup.c | 422 ------------
arch/arm/mach-kirkwood/openrd-setup.c | 255 --------
arch/arm/mach-kirkwood/pcie.c | 296 ---------
arch/arm/mach-kirkwood/pm.c | 76 ---
arch/arm/mach-kirkwood/pm.h | 26 -
arch/arm/mach-kirkwood/rd88f6192-nas-setup.c | 89 ---
arch/arm/mach-kirkwood/rd88f6281-setup.c | 128 ----
arch/arm/mach-kirkwood/t5325-setup.c | 216 -------
arch/arm/mach-kirkwood/ts219-setup.c | 142 ----
arch/arm/mach-kirkwood/ts41x-setup.c | 186 ------
arch/arm/mach-kirkwood/tsx1x-common.c | 113 ----
arch/arm/mach-kirkwood/tsx1x-common.h | 7 -
arch/arm/mm/Kconfig | 2 +-
35 files changed, 4 insertions(+), 4375 deletions(-)
delete mode 100644 arch/arm/mach-kirkwood/Kconfig
delete mode 100644 arch/arm/mach-kirkwood/Makefile
delete mode 100644 arch/arm/mach-kirkwood/Makefile.boot
delete mode 100644 arch/arm/mach-kirkwood/board-dt.c
delete mode 100644 arch/arm/mach-kirkwood/common.c
delete mode 100644 arch/arm/mach-kirkwood/common.h
delete mode 100644 arch/arm/mach-kirkwood/d2net_v2-setup.c
delete mode 100644 arch/arm/mach-kirkwood/include/mach/bridge-regs.h
delete mode 100644 arch/arm/mach-kirkwood/include/mach/entry-macro.S
delete mode 100644 arch/arm/mach-kirkwood/include/mach/hardware.h
delete mode 100644 arch/arm/mach-kirkwood/include/mach/irqs.h
delete mode 100644 arch/arm/mach-kirkwood/include/mach/kirkwood.h
delete mode 100644 arch/arm/mach-kirkwood/include/mach/uncompress.h
delete mode 100644 arch/arm/mach-kirkwood/irq.c
delete mode 100644 arch/arm/mach-kirkwood/lacie_v2-common.c
delete mode 100644 arch/arm/mach-kirkwood/lacie_v2-common.h
delete mode 100644 arch/arm/mach-kirkwood/mpp.c
delete mode 100644 arch/arm/mach-kirkwood/mpp.h
delete mode 100644 arch/arm/mach-kirkwood/netxbig_v2-setup.c
delete mode 100644 arch/arm/mach-kirkwood/openrd-setup.c
delete mode 100644 arch/arm/mach-kirkwood/pcie.c
delete mode 100644 arch/arm/mach-kirkwood/pm.c
delete mode 100644 arch/arm/mach-kirkwood/pm.h
delete mode 100644 arch/arm/mach-kirkwood/rd88f6192-nas-setup.c
delete mode 100644 arch/arm/mach-kirkwood/rd88f6281-setup.c
delete mode 100644 arch/arm/mach-kirkwood/t5325-setup.c
delete mode 100644 arch/arm/mach-kirkwood/ts219-setup.c
delete mode 100644 arch/arm/mach-kirkwood/ts41x-setup.c
delete mode 100644 arch/arm/mach-kirkwood/tsx1x-common.c
delete mode 100644 arch/arm/mach-kirkwood/tsx1x-common.h
^ permalink raw reply
* [PATCH v5 1/8] of: Add NVIDIA Tegra SATA controller binding
From: Tejun Heo @ 2014-07-18 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718150603.GA7196@ulmo>
On Fri, Jul 18, 2014 at 05:06:04PM +0200, Thierry Reding wrote:
> I think the following patches can go through your tree without causing
> breakage through unresolved dependencies:
>
> [PATCH v5 1/8] of: Add NVIDIA Tegra SATA controller binding
> [PATCH v3 6/8] ata: ahci_platform: Increase AHCI_MAX_CLKS to 4
> [PATCH v5 7/8] ata: Add support for the Tegra124 SATA controller
Applied to libata/for-3.17 w/ Hans' acks added. Please check the
following branch and give me a holler if something is amiss.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-3.17
Thanks.
--
tejun
^ permalink raw reply
* [RFC] cpufreq: Add bindings for CPU clock sharing topology
From: Olof Johansson @ 2014-07-18 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpo=MmoALOHg-=7cf0jm=OJO57TWQZQXqkRwhRwU-DGPMmA@mail.gmail.com>
On Thu, Jul 17, 2014 at 11:40 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 18 July 2014 11:47, Olof Johansson <olof@lixom.net> wrote:
>> Why complicate it by using two properties?
>>
>> If there is no property, then the CPUs are assumed to be controlled
>> independently.
>>
>> if there is a clock-master = <phandle> property, then that points at
>> the cpu that is the main one controlling clock for the group.
>>
>> There's really no need to label the master -- it will be the only one
>> with incoming links but nothing outgoing. And a master without slaves
>> is an independently controlled cpu so you should be fine in that
>> aspect too.
>
> I thought so earlier, but then I remembered something I read long back.
> Don't remember which thread now, but I *might* be wrong..
>
> "Bindings are like APIs and new bindings shouldn't break existing stuff.."
>
> And:
>
>> If there is no property, then the CPUs are assumed to be controlled
>> independently.
>
> seems to break the existing API.
What is the current API that is being broken, in your opinion?
> But if that isn't the case, the bindings are very simple & clear to handle.
> Diff for new bindings:
It's somewhat confusing to see a diff to the patch instead of a new
version. It seems to remove the cpu 0 entry now?
-Olof
^ permalink raw reply
* [PATCH] MAINTAINERS: Remove Kirkwood
From: Olof Johansson @ 2014-07-18 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717122313.GG13108@titan.lakedaemon.net>
On Thu, Jul 17, 2014 at 5:23 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> All,
>
> Original patch bounced to arm-soc maintainers and their email alias.
Either something happened to the bounce, or gmail ignored it, since I
certainly didn't get a copy of the original email in my inbox (nor the
arm at kernel.org folder).
Anyway, I'll dig it out of the list folder and apply it.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: imx: fixes for 3.16, 2nd take
From: Olof Johansson @ 2014-07-18 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718080754.GC8537@dragon>
On Fri, Jul 18, 2014 at 1:07 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
> The following changes since commit 4c834452aad01531db949414f94f817a86348d59:
>
> Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-3.16-2
>
> for you to fetch changes up to 03e97220b99b8b691ea5b130b7b4c135c9662792:
>
> ARM: clk-imx6q: parent lvds_sel input from upstream clock gates (2014-07-18 15:57:17 +0800)
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] at91: fixes for 3.16 #2
From: Olof Johansson @ 2014-07-18 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405692730-31284-1-git-send-email-nicolas.ferre@atmel.com>
On Fri, Jul 18, 2014 at 7:12 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> Arnd, Olof, Kevin,
>
> This is the latest regressions that we found while testing the at91sam9n12 and
> at91sam9x5 platforms following our move to CCF.
> I created a pull-request this time because I have 3 patches: there should be
> no conflict anyway. This tag does not contain the fix that Olof had taken during
> previous -rc cycle on purpose: this way it won't appear twice in the history.
>
> Thanks, best regards,
>
> The following changes since commit 971dc9ce106110745f246337f229013589354536:
>
> ARM: at91/dt: sam9261: remove slow RC osc (2014-06-25 18:00:17 +0200)
>
> are available in the git repository at:
>
> git://github.com/at91linux/linux-at91.git tags/at91-fixes
>
> for you to fetch changes up to e0d69e119fc6bf7cc3c9f791478108c1b925bb2e:
>
> ARM: at91/dt: add missing clocks property to pwm node in sam9x5.dtsi (2014-07-18 15:56:35 +0200)
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: Fixes for v3.16 (round 3)
From: Olof Johansson @ 2014-07-18 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718213214.GL24496@titan.lakedaemon.net>
On Fri, Jul 18, 2014 at 2:32 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> All,
>
> Here is hopefully the last round of fixes for mvebu.
>
> This is an incremental pull request from tags/mvebu-fixes-3.16-2 up to
> tags/mvebu-fixes-3.16-3 on the mvebu/fixes branch.
>
> Please pull.
>
> thx,
>
> Jason.
>
> The following changes since commit 6509dc74c9f55ffaa558738b96c4da8b98d39571:
>
> ARM: mvebu: fix cpuidle implementation to work on big-endian systems (2014-06-30 18:15:11 +0000)
>
> are available in the git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-3.16-3
>
> for you to fetch changes up to a728b977429383b3fe92b6e3bff9e69365609e0f:
>
> ARM: mvebu: Fix coherency bus notifiers by using separate notifiers (2014-07-08 13:53:53 +0000)
Merged, thanks.
-Olof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox