Re: Feature request, "create on mount" to create mount point directory on mount, implied remove on unmount
On Mon, 06 Jul 2015 03:34:59 +0100, jon said: > I remember "virtual memory" and even "virtual addressing" but I think > the term "virtual machine" is modern, maybe someone else knows, google > did not help me much trying to prove it one way or the other. Hardly. IBM was working with virtual machines as far back as the IBM S360/67 in the late 60s (and even a highly modified /40), and released VM/370 in 1972. They used the term 'Virtual Machine' as early as 1966: R. J. Adair, R. U. Bayles, L. W. Comeau, and R. J. Creasy, A Virtual Machine System for the 360/40, IBM Corporation, Cambridge Scientific Center Report No. 320-2007 (May 1966) https://en.wikipedia.org/wiki/VM_%28operating_system%29 (And that's just what I'm familiar with from being a VM jock from 1982 to 2000, I'm sure there's earlier references...) pgpnAks7uCodE.pgp Description: PGP signature
Re: [PATCH RESEND] sched: prefer an idle cpu vs an idle sibling for BALANCE_WAKE
Hm. Piddling with pgbench, which doesn't seem to collapse into a quivering heap when load exceeds cores these days, deltas weren't all that impressive, but it does appreciate the extra effort a bit, and a bit more when clients receive it as well. If you test, and have time to piddle, you could try letting wake_wide() return 1 + sched_feat(WAKE_WIDE_IDLE) instead of adding only if wakee is the dispatcher. Numbers from my little desktop box. NO_WAKE_WIDE_IDLE postgres@homer:~> pgbench.sh clients 8 tps = 116697.697662 clients 12 tps = 115160.230523 clients 16 tps = 115569.804548 clients 20 tps = 117879.230514 clients 24 tps = 118281.753040 clients 28 tps = 116974.796627 clients 32 tps = 119082.163998 avg 117092.239 1.000 WAKE_WIDE_IDLE postgres@homer:~> pgbench.sh clients 8 tps = 124351.735754 clients 12 tps = 124419.673135 clients 16 tps = 125050.716498 clients 20 tps = 124813.042352 clients 24 tps = 126047.442307 clients 28 tps = 125373.719401 clients 32 tps = 126711.243383 avg 125252.510 1.069 1.000 WAKE_WIDE_IDLE (clients as well as server) postgres@homer:~> pgbench.sh clients 8 tps = 130539.795246 clients 12 tps = 128984.648554 clients 16 tps = 130564.386447 clients 20 tps = 129149.693118 clients 24 tps = 130211.119780 clients 28 tps = 130325.355433 clients 32 tps = 129585.656963 avg 129908.665 1.109 1.037 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] clk: exynos4: Fix wrong clock for Exynos4x12 ADC
2015-07-06 13:03 GMT+09:00 Krzysztof Kozlowski :
> 2015-06-12 14:46 GMT+09:00 Javier Martinez Canillas :
>> Hello Krzysztof,
>>
>> On Fri, Jun 12, 2015 at 3:53 AM, Krzysztof Kozlowski
>> wrote:
>>> The TSADC gate clock was used in Exynos4x12 DTSI for exynos-adc driver.
>>> However TSADC is present only on Exynos4210 so on Trats2 board (with
>>> Exynos4412 SoC) the exynos-adc driver could not be probed:
>>>ERROR: could not get clock /adc@126C:adc(0)
>>>exynos-adc 126c.adc: failed getting clock, err = -2
>>>exynos-adc: probe of 126c.adc failed with error -2
>>>
>>> Instead on Exynos4x12 SoCs the main clock used by Analog to Digital
>>> Converter is located in different register and it is named in datasheet
>>> as PCLK_ADC. Regardless of the name the purpose of this PCLK_ADC clock
>>> is the same as purpose of TSADC from Exynos4210.
>>>
>>> The patch adds gate clock for Exynos4x12 using the proper register so
>>> backward compatibility is preserved. This fixes the probe of exynos-adc
>>> driver on Exynos4x12 boards and allows accessing sensors connected to it
>>> on Trats2 board (ntc,ncp15wb473 AP and battery thermistors).
>>>
>>> Signed-off-by: Krzysztof Kozlowski
>>> Cc:
>>> Fixes: c63c57433003 ("ARM: dts: Add ADC's dt data to read raw data for
>>> exynos4x12")
>>> Link: https://lkml.org/lkml/2015/6/11/85
>>>
>>> ---
>>>
>>> Changes since v1:
>>> 1. After discussion on LKML this solution was chosen because it smaller,
>>>simpler, self-contained (one patch to fix issue) and maintains backward
>>>compatibility. Thanks to Javier Martinez Canillas and Tomasz Figa for
>>>valuable comments.
>>> 2. Dropped patch 2/2 because now it is not needed. The clock id "TSADC"
>>>will be used on all Exynos4 boards.
>>> 3. Added CC-stable.
>>> ---
>>> drivers/clk/samsung/clk-exynos4.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>
>> Patch looks good to me.
>>
>> Reviewed-by: Javier Martinez Canillas
>
> Hi Tomasz and Sylwester,
>
> Any comments on this version of patch?
> Tomasz, you gave me comments on previous version. Are their satisfied?
Acked-by: Tomasz Figa
Thanks for pinging.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] arm64: Make all entry code as non-kprobe-able
Entry symbols are not kprobe safe. So blacklist them for kprobing.
Signed-off-by: Pratyush Anand
---
arch/arm64/kernel/entry.S | 3 +++
arch/arm64/kernel/kprobes.c | 9 +
arch/arm64/kernel/vmlinux.lds.S | 1 +
3 files changed, 13 insertions(+)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index a7691a378668..2ea24f6bc06b 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -202,6 +202,7 @@ tsk .reqx28 // current thread_info
* Exception vectors.
*/
+ .section ".entry.text", "ax"
.align 11
ENTRY(vectors)
ventry el1_sync_invalid// Synchronous EL1t
@@ -737,3 +738,5 @@ ENTRY(sys_rt_sigreturn_wrapper)
mov x0, sp
b sys_rt_sigreturn
ENDPROC(sys_rt_sigreturn_wrapper)
+
+ .section ".text", "ax"
diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
index 6c9f8b5f04ce..9bc02c151f7f 100644
--- a/arch/arm64/kernel/kprobes.c
+++ b/arch/arm64/kernel/kprobes.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "kprobes.h"
#include "kprobes-arm64.h"
@@ -661,6 +662,14 @@ int __kprobes arch_trampoline_kprobe(struct kprobe *p)
return 0;
}
+bool arch_within_kprobe_blacklist(unsigned long addr)
+{
+ return (addr >= (unsigned long)__kprobes_text_start &&
+addr < (unsigned long)__kprobes_text_end) ||
+ (addr >= (unsigned long)__entry_text_start &&
+addr < (unsigned long)__entry_text_end);
+}
+
int __init arch_init_kprobes(void)
{
return 0;
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 1fa6adc7aa83..11fb2b0117d0 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -97,6 +97,7 @@ SECTIONS
*(.exception.text)
__exception_text_end = .;
IRQENTRY_TEXT
+ ENTRY_TEXT
TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] arm64: Blacklist non-kprobe-able symbols
Add all function symbols which are called from do_debug_exception under
NOKPROBE_SYMBOL, as they can not kprobed.
Signed-off-by: Pratyush Anand
---
arch/arm64/kernel/debug-monitors.c | 18 ++
arch/arm64/kernel/hw_breakpoint.c | 8
arch/arm64/kernel/kgdb.c | 4
arch/arm64/mm/fault.c | 1 +
4 files changed, 31 insertions(+)
diff --git a/arch/arm64/kernel/debug-monitors.c
b/arch/arm64/kernel/debug-monitors.c
index 237a21f675fd..6d356b2cc674 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -47,6 +48,7 @@ static void mdscr_write(u32 mdscr)
asm volatile("msr mdscr_el1, %0" :: "r" (mdscr));
local_dbg_restore(flags);
}
+NOKPROBE_SYMBOL(mdscr_write);
static u32 mdscr_read(void)
{
@@ -54,6 +56,7 @@ static u32 mdscr_read(void)
asm volatile("mrs %0, mdscr_el1" : "=r" (mdscr));
return mdscr;
}
+NOKPROBE_SYMBOL(mdscr_read);
/*
* Allow root to disable self-hosted debug from userspace.
@@ -102,6 +105,7 @@ void enable_debug_monitors(enum debug_elx el)
mdscr_write(mdscr);
}
}
+NOKPROBE_SYMBOL(enable_debug_monitors);
void disable_debug_monitors(enum debug_elx el)
{
@@ -122,6 +126,7 @@ void disable_debug_monitors(enum debug_elx el)
mdscr_write(mdscr);
}
}
+NOKPROBE_SYMBOL(disable_debug_monitors);
/*
* OS lock clearing.
@@ -173,6 +178,7 @@ static void set_regs_spsr_ss(struct pt_regs *regs)
spsr |= DBG_SPSR_SS;
regs->pstate = spsr;
}
+NOKPROBE_SYMBOL(set_regs_spsr_ss);
static void clear_regs_spsr_ss(struct pt_regs *regs)
{
@@ -182,6 +188,7 @@ static void clear_regs_spsr_ss(struct pt_regs *regs)
spsr &= ~DBG_SPSR_SS;
regs->pstate = spsr;
}
+NOKPROBE_SYMBOL(clear_regs_spsr_ss);
/* EL1 Single Step Handler hooks */
static LIST_HEAD(step_hook);
@@ -224,6 +231,7 @@ static int call_step_hook(struct pt_regs *regs, unsigned
int esr)
return retval;
}
+NOKPROBE_SYMBOL(call_step_hook);
static int single_step_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
@@ -270,6 +278,7 @@ static int single_step_handler(unsigned long addr, unsigned
int esr,
return 0;
}
+NOKPROBE_SYMBOL(single_step_handler);
/*
* Breakpoint handler is re-entrant as another breakpoint can
@@ -306,6 +315,7 @@ static int call_break_hook(struct pt_regs *regs, unsigned
int esr)
return fn ? fn(regs, esr) : DBG_HOOK_ERROR;
}
+NOKPROBE_SYMBOL(call_break_hook);
static int brk_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
@@ -338,6 +348,7 @@ static int brk_handler(unsigned long addr, unsigned int esr,
return 0;
}
+NOKPROBE_SYMBOL(brk_handler);
int aarch32_break_handler(struct pt_regs *regs)
{
@@ -382,6 +393,7 @@ int aarch32_break_handler(struct pt_regs *regs)
force_sig_info(SIGTRAP, , current);
return 0;
}
+NOKPROBE_SYMBOL(aarch32_break_handler);
static int __init debug_traps_init(void)
{
@@ -403,6 +415,7 @@ void user_rewind_single_step(struct task_struct *task)
if (test_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP))
set_regs_spsr_ss(task_pt_regs(task));
}
+NOKPROBE_SYMBOL(user_rewind_single_step);
void user_fastforward_single_step(struct task_struct *task)
{
@@ -418,6 +431,7 @@ void kernel_enable_single_step(struct pt_regs *regs)
mdscr_write(mdscr_read() | DBG_MDSCR_SS);
enable_debug_monitors(DBG_ACTIVE_EL1);
}
+NOKPROBE_SYMBOL(kernel_enable_single_step);
void kernel_disable_single_step(void)
{
@@ -425,12 +439,14 @@ void kernel_disable_single_step(void)
mdscr_write(mdscr_read() & ~DBG_MDSCR_SS);
disable_debug_monitors(DBG_ACTIVE_EL1);
}
+NOKPROBE_SYMBOL(kernel_disable_single_step);
int kernel_active_single_step(void)
{
WARN_ON(!irqs_disabled());
return mdscr_read() & DBG_MDSCR_SS;
}
+NOKPROBE_SYMBOL(kernel_active_single_step);
/* ptrace API */
void user_enable_single_step(struct task_struct *task)
@@ -438,8 +454,10 @@ void user_enable_single_step(struct task_struct *task)
set_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP);
set_regs_spsr_ss(task_pt_regs(task));
}
+NOKPROBE_SYMBOL(user_enable_single_step);
void user_disable_single_step(struct task_struct *task)
{
clear_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP);
}
+NOKPROBE_SYMBOL(user_disable_single_step);
diff --git a/arch/arm64/kernel/hw_breakpoint.c
b/arch/arm64/kernel/hw_breakpoint.c
index 43b74a3ddaef..91b4c418abcb 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -139,6 +140,7 @@ static u64 read_wb_reg(int reg, int n)
[PATCH 0/2] arm64: some symbols blacklisted for kprobing
Functions which are called from do_debug_execptions and all entry routines must not allow to insert kprobe in it, otherwise we may witness a system hang. This patch set blacklist such symbols. Patches should be applied on top of arm64 kprobe patches [1]. [1] https://lkml.org/lkml/2015/6/15/514 Pratyush Anand (2): arm64: Blacklist non-kprobe-able symbols arm64: Make all entry code as non-kprobe-able arch/arm64/kernel/debug-monitors.c | 18 ++ arch/arm64/kernel/entry.S | 3 +++ arch/arm64/kernel/hw_breakpoint.c | 8 arch/arm64/kernel/kgdb.c | 4 arch/arm64/kernel/kprobes.c| 9 + arch/arm64/kernel/vmlinux.lds.S| 1 + arch/arm64/mm/fault.c | 1 + 7 files changed, 44 insertions(+) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: macb: Add SG support for Zynq SOC family
Enable SG support for Zynq SOC family devices.
Signed-off-by: Punnaiah Choudary Kalluri
---
drivers/net/ethernet/cadence/macb.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index caeb395..a4e3f86 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2741,8 +2741,7 @@ static const struct macb_config emac_config = {
static const struct macb_config zynqmp_config = {
- .caps = MACB_CAPS_SG_DISABLED | MACB_CAPS_GIGABIT_MODE_AVAILABLE |
- MACB_CAPS_JUMBO,
+ .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_JUMBO,
.dma_burst_length = 16,
.clk_init = macb_clk_init,
.init = macb_init,
@@ -2750,8 +2749,7 @@ static const struct macb_config zynqmp_config = {
};
static const struct macb_config zynq_config = {
- .caps = MACB_CAPS_SG_DISABLED | MACB_CAPS_GIGABIT_MODE_AVAILABLE |
- MACB_CAPS_NO_GIGABIT_HALF,
+ .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_NO_GIGABIT_HALF,
.dma_burst_length = 16,
.clk_init = macb_clk_init,
.init = macb_init,
--
1.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression due to "tick: broadcast: Prevent livelock from event handler"
Hi Geert, On Sat, Jul 4, 2015 at 2:02 AM, Geert Uytterhoeven wrote: > Hi Wolfram, > > On Fri, Jul 3, 2015 at 4:37 PM, Wolfram Sang wrote: >>> So this is a single core machine and uses the em_sti timer w/o the >>> broadcast nonsense. In Simons case it looks like em_sti is used as >>> broadcast device. >> >> We use the same board. Just my kernel has SMP=n. > > Unlike our other multi-core A9 SoCs, emev2.dtsi doesn't have a node > for the arm,cortex-a9-twd-timer? That's right, the TWD was never enabled on upstream EMEV2. I believe it is documented in the data sheet though, however the actual vendor-specific glue is a bit different compared to other SoCs from Renesas Electronics - this most likely since EMEV2 was initially made by NEC Electronics instead of Renesas. I've been told that it was one of the earlier Cortex-A9 designs around so some special surprises may exist! Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression due to "tick: broadcast: Prevent livelock from event handler"
Hi Wolfram, Thanks for investigating this. On Sat, Jul 4, 2015 at 12:09 AM, Wolfram Sang wrote: > >> Ok. So it's unrelated to deep idle states. Any chance of poking with >> JTAG at the frozen box? If not, are there GPIOs which you could use to >> monitor certain state? > > No JTAGger here at the moment. And no manual/schematics for this board > :( Since EMEV2 includes a dual Cortex-A9 you can use OpenOCD with a Flyswatter JTAG. I've tried the following lines for the openocd configuration file, if you need any help let me know! # --- emev2 (CA9 Dual) on KZM9D --- #target create emev2.cpu0 cortex_a -chain-position auto0.tap -dbgbase 0x8001 -coreid 0 #target create emev2.cpu1 cortex_a -chain-position auto0.tap -dbgbase 0x80012000 -coreid 1 Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc/powernv: Fix race in updating core_idle_state
> > What are the symptoms of this bug? > In the cases where we hit this race and the core enters fastsleep, code mistakes an idle thread as running. Because of this, the first thread waking up from fastsleep which is supposed to resync timebase skips it. So we can end up having a core with stale timebase value. We suspect this is causing soft lockups with call stacks similar to this- [126529.208714] NMI watchdog: BUG: soft lockup - CPU#8 stuck for 22s! [opal_errd:7722] [126529.208849] CPU: 8 PID: 7722 Comm: opal_errd [126529.208853] task: c0bf67803a80 ti: c0bf6788c000 task.ti: c0bf6788c000 [126529.208856] NIP: c015a180 LR: c015a0d0 CTR: c001ed70 [126529.208859] REGS: c0bf6788faa0 TRAP: 0901 Not tainted (3.18.13-336.el7_1.pkvm3_1_0.2000.1.ppc64le) [126529.208860] MSR: 90009033 CR: 24004824 XER: 2000 [126529.208871] CFAR: c015a194 SOFTE: 1 GPR00: c02db9e8 c0bf6788fd20 c12b1800 3af5b88f569e GPR04: 00d3dbb8 3af5c236ca0b 0001ee28 GPR08: 3b9ac9ff 5bfc723fba82c8f9 c06f2b88 c09908c8 GPR12: c001ed70 c7da4c00 [126529.208896] NIP [c015a180] ktime_get_ts64+0x130/0x1f0 [126529.208899] LR [c015a0d0] ktime_get_ts64+0x80/0x1f0 [126529.208902] Call Trace: [126529.208909] [c0bf6788fd20] [c019c0e4] __audit_syscall_exit+0x214/0x2e0 (unreliable) [126529.208916] [c0bf6788fda0] [c02db9e8] poll_select_set_timeout+0x98/0xe0 [126529.208919] [c0bf6788fde0] [c02dcf7c] SyS_poll+0x8c/0x160 [126529.208925] [c0bf6788fe30] [c0009358] syscall_exit+0x0/0x98 [126529.208927] Instruction dump: [126529.208930] 7d29ea14 6108c9ff 3940 7fa94040 409d0038 481c 6000 6000 [126529.208936] 6000 6000 6000 6042 <3d29c465> 394a0001 39293600 794a0020 > I assume they're not good. In which case this should go to stable, shouldn't > it? If so which versions? > Yes this should go into stable. 3.19+ > And which commit introduced the bug? > 77b54e9f213f76a powernv/powerpc: Add winkle support for offline cpus Thanks, Shreyas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf record: Allow passing perf's own pid to '--filter'
This patch allows passing perf's own PID to '--filter' by using
'@PERFPID'. This should be useful when system-widely capturing
tracepoints events.
Before this patch, when doing something like:
# perf record -a -e syscalls:sys_enter_write
One could easily get result like this:
# /tmp/perf report --stdio
...
# Overhead Command Shared Object Symbol
# ... ..
#
99.99% perf libpthread-2.18.so [.] __write_nocancel
0.01% ls libc-2.18.so[.] write
0.01% sshd libc-2.18.so[.] write
...
Where most events are generated by perf itself.
A shell trick can be done to filter perf itself out:
# cat << EOF > ./tmp
> #!/bin/sh
> exec perf record -e ... --filter="common_pid != \$\$" -a sleep 10
> EOF
# chmod a+x ./tmp
# ./tmp
However, doing so is user unfriendly.
This patch introduces '@PERFPID' placeholder to '--filter' options. Now
user is allowed to the above work with:
# perf record -e ... --filter="common_pid != @PERFPID' sleep 10
Signed-off-by: Wang Nan
---
tools/perf/Documentation/perf-record.txt | 1 +
tools/perf/util/parse-events.c | 96
2 files changed, 97 insertions(+)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 9b9d9d0..c2902d2 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -62,6 +62,7 @@ OPTIONS
--filter=::
Event filter.
+String '@PERFPID' is allowed to be used to represent pid of 'perf'
itself.
-a::
--all-cpus::
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index aaee24c..2d62957 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1175,6 +1175,101 @@ int parse_events_option(const struct option *opt, const
char *str,
return ret;
}
+#ifndef PAGE_SIZE
+# define PAGE_SIZE 4096
+#endif
+static int
+postproc_filter_append_token(const char *key, char *new_filter,
+ssize_t *pspace)
+{
+ if (strcmp(key, "PERFPID") == 0) {
+ char pid_buf[32];
+ pid_t self_pid = getpid();
+
+ snprintf(pid_buf, 32, "%d", self_pid);
+ strncat(new_filter, pid_buf, *pspace);
+ *pspace -= strlen(pid_buf);
+ if (*pspace < 0)
+ return -1;
+ return 0;
+ }
+
+ return -1;
+}
+
+static void postproc_filter(struct perf_evsel *evsel)
+{
+ char *at = NULL, *sep = NULL, *old_filter, *new_filter;
+ ssize_t space;
+
+ if (!evsel->filter)
+ return;
+
+ old_filter = evsel->filter;
+ at = strchr(old_filter, '@');
+ if (!at)
+ return;
+
+ /*
+* See perf_event_set_filter(). Length of a valid filter is
+* limited by PAGE_SIZE.
+*/
+ new_filter = malloc(PAGE_SIZE);
+ if (!new_filter) {
+ fprintf(stderr, "No enough memory for post proc filter '%s'\n",
+ old_filter);
+ return;
+ }
+ *new_filter = '\0';
+ space = PAGE_SIZE - 1;
+
+ while (1) {
+ if (at)
+ *at = '\0';
+ strncat(new_filter, old_filter, space);
+ space -= strlen(old_filter);
+ if (space < 0)
+ goto errout;
+ if (!at)
+ break;
+ *at = '@';
+
+ sep = strchr(at + 1, ' ');
+ if (sep)
+ *sep = '\0';
+
+ if (postproc_filter_append_token(at + 1, new_filter, ))
+ goto errout;
+
+ if (!sep)
+ break;
+ *sep = ' ';
+
+ old_filter = sep;
+ at = strchr(old_filter, '@');
+ }
+
+ free(evsel->filter);
+ /*
+* It is safe to use new_filter directly. However, try to
+* release some memory by strdup() a smaller string and free
+* new_filter, which takes a full page.
+*/
+ evsel->filter = strdup(new_filter);
+ if (!evsel->filter)
+ evsel->filter = new_filter;
+ else
+ free(new_filter);
+ return;
+errout:
+ if (at)
+ *at = '@';
+ if (sep)
+ *sep = ' ';
+ fprintf(stderr, "Can't post proc filter '%s'\n", evsel->filter);
+ free(new_filter);
+}
+
int parse_filter(const struct option *opt, const char *str,
int unset __maybe_unused)
{
@@ -1196,6 +1291,7 @@ int parse_filter(const struct option *opt, const char
*str,
return -1;
}
+ postproc_filter(last);
return 0;
}
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
[PATCH v3 2/2] irqchip: dw-apb-ictl: add irq_set_affinity support
On Marvell Berlin SoCs, the cpu's local timer is shutdown when the cpu goes to a deep idle state, then the timer framework will be notified to use a broadcast timer instead. In our case, the broadcast timer uses dw-apb-ictl as interrupt chip. This patch adds irq_set_affinity support so that the going to deep idle state cpu can set the interrupt affinity of the broadcast interrupt to avoid unnecessary wakeups and IPIs. NOTE: We achieved this by changing the parent interrupt affinity of a chained interrupt, so it migrates every interrupt on the child interrupt controller which isn't a good thing to do as pointed out by Russell King. Thomas pointed out "we should at least make that an opt-in behaviour and not enabled by default", this patch adds a device tree option for this purpose. If "migrates every interrupt on the child interrupt controller" doesn't matter, turning on the option would add irq_set_affinity support which might be useful in some cases (EG: can save reduce power consumption on Marvell Berlin SoCs). A simple test: ~ # rm /tmp/test.sh ~ # cat > /tmp/test.sh cat /proc/interrupts for i in `seq 10` ; do sleep $i; done cat /proc/interrupts ~ # chmod +x /tmp/test.sh ~ # taskset 0x2 /tmp/test.sh without the patch: CPU0 CPU1 27:115 36 GIC 27 arch_timer 45: 62 0 GIC 45 mmc0 160: 88 0 interrupt-controller 8 timer 227: 0 0 interrupt-controller 4 f7e81400.i2c 228: 0 0 interrupt-controller 5 f7e81800.i2c 229: 0 0 interrupt-controller 7 dw_spi65535 230: 0 0 interrupt-controller 21 f7e84000.i2c 231: 0 0 interrupt-controller 20 f7e84800.i2c 265:445 0 interrupt-controller 8 serial IPI0: 0 0 CPU wakeup interrupts IPI1: 0 11 Timer broadcast interrupts IPI2: 56104 Rescheduling interrupts IPI3: 0 0 Function call interrupts IPI4: 0 4 Single function call interrupts IPI5: 0 0 CPU stop interrupts IPI6: 25 27 IRQ work interrupts IPI7: 0 0 completion interrupts IPI8: 0 0 CPU backtrace Err: 0 CPU0 CPU1 27:115 38 GIC 27 arch_timer 45: 62 0 GIC 45 mmc0 160:160 0 interrupt-controller 8 timer 227: 0 0 interrupt-controller 4 f7e81400.i2c 228: 0 0 interrupt-controller 5 f7e81800.i2c 229: 0 0 interrupt-controller 7 dw_spi65535 230: 0 0 interrupt-controller 21 f7e84000.i2c 231: 0 0 interrupt-controller 20 f7e84800.i2c 265:514 0 interrupt-controller 8 serial IPI0: 0 0 CPU wakeup interrupts IPI1: 0 83 Timer broadcast interrupts IPI2: 56104 Rescheduling interrupts IPI3: 0 0 Function call interrupts IPI4: 0 4 Single function call interrupts IPI5: 0 0 CPU stop interrupts IPI6: 25 46 IRQ work interrupts IPI7: 0 0 completion interrupts IPI8: 0 0 CPU backtrace Err: 0 cpu0 get 160-88=72 timer interrupts, CPU1 got 83-11=72 broadcast timer IPIs. So, overall system got 72+72=144 wake ups and 72 broadcast timer IPIs With the patch: CPU0 CPU1 27:107 37 GIC 27 arch_timer 45: 62 0 GIC 45 mmc0 160: 66 7 interrupt-controller 8 timer 227: 0 0 interrupt-controller 4 f7e81400.i2c 228: 0 0 interrupt-controller 5 f7e81800.i2c 229: 0 0 interrupt-controller 7 dw_spi65535 230: 0 0 interrupt-controller 21 f7e84000.i2c 231: 0 0 interrupt-controller 20 f7e84800.i2c 265:311 0 interrupt-controller 8 serial IPI0: 0 0 CPU wakeup interrupts IPI1: 2 4 Timer broadcast interrupts IPI2: 58100 Rescheduling interrupts IPI3: 0 0 Function call interrupts IPI4: 0 4 Single function call interrupts IPI5: 0 0 CPU stop interrupts IPI6: 21 24 IRQ work interrupts IPI7: 0 0 completion interrupts IPI8: 0 0 CPU backtrace Err: 0 CPU0 CPU1 27:107 39 GIC 27 arch_timer 45: 62 0 GIC 45 mmc0 160: 69 75 interrupt-controller 8 timer 227: 0 0 interrupt-controller 4 f7e81400.i2c 228: 0 0 interrupt-controller 5 f7e81800.i2c 229: 0 0 interrupt-controller 7 dw_spi65535 230:
[PATCH v3 0/2] irqchip: dw-apb-ictl: add irq_set_affinity support
On Marvell Berlin SoCs, the cpu's local timer is shutdown when the cpu goes to a deep idle state, then the timer framework will be notified to use a broadcast timer instead. In our case, the broadcast timer uses dw-apb-ictl as the interrupt chip. These patches try to add irq_set_affinity support so that the going to deep idle state cpu can set the interrupt affinity of the broadcast interrupt to avoid unnecessary wakeups and IPIs. Changes since v2: - Add a DT option to indicate whether we want to set the irq affinity. Changes since v1: - Add a simple test and its result into the second patch's commit msg. Jisheng Zhang (2): irqchip: dw-apb-ictl: add private data structure irqchip: dw-apb-ictl: add irq_set_affinity support .../interrupt-controller/snps,dw-apb-ictl.txt | 5 +++ drivers/irqchip/irq-dw-apb-ictl.c | 51 +++--- 2 files changed, 51 insertions(+), 5 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] irqchip: dw-apb-ictl: add private data structure
This patch adds struct dw_apb_ictl_priv definition, now it only has one
member: the irq domain. Then make the generic irq chip gc->private to point
to the struct. This is to prepare for the next patch which will implement
irq_set_affinity.
Signed-off-by: Jisheng Zhang
---
drivers/irqchip/irq-dw-apb-ictl.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-dw-apb-ictl.c
b/drivers/irqchip/irq-dw-apb-ictl.c
index 53bb732..8bef7f7 100644
--- a/drivers/irqchip/irq-dw-apb-ictl.c
+++ b/drivers/irqchip/irq-dw-apb-ictl.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "irqchip.h"
@@ -26,11 +27,16 @@
#define APB_INT_FINALSTATUS_L 0x30
#define APB_INT_FINALSTATUS_H 0x34
+struct dw_apb_ictl_priv {
+ struct irq_domain *domain;
+};
+
static void dw_apb_ictl_handler(unsigned int irq, struct irq_desc *desc)
{
struct irq_chip *chip = irq_get_chip(irq);
struct irq_chip_generic *gc = irq_get_handler_data(irq);
- struct irq_domain *d = gc->private;
+ struct dw_apb_ictl_priv *priv = gc->private;
+ struct irq_domain *d = priv->domain;
u32 stat;
int n;
@@ -71,27 +77,34 @@ static int __init dw_apb_ictl_init(struct device_node *np,
unsigned int clr = IRQ_NOREQUEST | IRQ_NOPROBE | IRQ_NOAUTOEN;
struct resource r;
struct irq_domain *domain;
+ struct dw_apb_ictl_priv *priv;
struct irq_chip_generic *gc;
void __iomem *iobase;
int ret, nrirqs, irq;
u32 reg;
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
/* Map the parent interrupt for the chained handler */
irq = irq_of_parse_and_map(np, 0);
if (irq <= 0) {
pr_err("%s: unable to parse irq\n", np->full_name);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_free;
}
ret = of_address_to_resource(np, 0, );
if (ret) {
pr_err("%s: unable to get resource\n", np->full_name);
- return ret;
+ goto err_free;
}
if (!request_mem_region(r.start, resource_size(), np->full_name)) {
pr_err("%s: unable to request mem region\n", np->full_name);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_free;
}
iobase = ioremap(r.start, resource_size());
@@ -138,7 +151,8 @@ static int __init dw_apb_ictl_init(struct device_node *np,
}
gc = irq_get_domain_generic_chip(domain, 0);
- gc->private = domain;
+ priv->domain = domain;
+ gc->private = priv;
gc->reg_base = iobase;
gc->chip_types[0].regs.mask = APB_INT_MASK_L;
@@ -164,6 +178,8 @@ err_unmap:
iounmap(iobase);
err_release:
release_mem_region(r.start, resource_size());
+err_free:
+ kfree(priv);
return ret;
}
IRQCHIP_DECLARE(dw_apb_ictl,
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH?] Livelock in pick_next_task_fair() / idle_balance()
Hi Morten, On Fri, Jul 03, 2015 at 10:34:41AM +0100, Morten Rasmussen wrote: > > > IOW, since task groups include blocked load in the load_avg_contrib (see > > > __update_group_entity_contrib() and __update_cfs_rq_tg_load_contrib()) the > > > imbalance includes blocked load and hence env->imbalance >= > > > sum(task_h_load(p)) for all tasks p on the rq. Which leads to > > > detach_tasks() emptying the rq completely in the reported scenario where > > > blocked load > runnable load. > > > > Whenever I want to know the load avg concerning task group, I need to > > walk through the complete codes again, I prefer not to do it this time. > > But it should not be that simply to say "the 118 comes from the blocked > > load". > > But the whole hierarchy of group entities is updated each time we enqueue > or dequeue a task. I don't see how the group entity load_avg_contrib is > not up to date? Why do you need to update it again? > > In any case, we have one task in the group hierarchy which has a > load_avg_contrib of 0 and the grand-grand parent group entity has a > load_avg_contrib of 118 and no additional tasks. That load contribution > must be from tasks which are no longer around on the rq? No? load_avg_contrib has WEIGHT inside, so the most I can say is: SE: 8f456e00's load_avg_contrib 118 = (its cfs_rq's runnable + blocked) / (tg->load_avg + 1) * tg->shares The tg->shares is probably 1024 (at least 911). So we are just left with: cfs_rq / tg = 11.5% I myself did question the sudden jump from 0 to 118 (see a previous reply). But anyway, this really is irrelevant to the discusstion. > > Anyway, with blocked load, yes, we definitely can't move (or even find) some > > ammount of the imbalance if we only look at the tasks on the queue. But this > > may or may not be a problem. > > > > Firstly, the question comes to whether we want blocked load anywhere. > > This is just about a "now vs. average" question. > > That is what I meant in the paragraph below. It is a scheduling policy > question. > > > Secondly, if we stick to average, we just need to treat the blocked load > > consistently, not that group SE has it, but task SE does not, or somewhere > > has it, others not. > > I agree that inconsistent use of blocked load will lead us into trouble. > The problem is that none of the load-balance logic was designed for > blocked load. It was written to deal load that is currently on the rq > and slightly biased by average cpu load, not dealing with load > contribution of tasks which we can't migrate at the moment because they > are blocked. The load-balance code has to be updated to deal with > blocked load. We will run into all sorts of issues if we don't and roll > out use of blocked load everywhere. > > However, before we can rework the load-balance code, we have to agree on > the now vs average balance policy. > > Your proposed patch implements a policy somewhere in between. We try to > balance based on average, but we don't allow idle_balance() to empty a > cpu completely. A pure average balance policy would allow a cpu to go > idle even if we could do have tasks waiting on other rqs if the blocked > load indicates that other task will show up shortly one the cpu. A pure > "now" balance would balance based on runnable_load_avg for all entities > including groups ignoring all blocked load, but that goes against the > PELT group balancing design. > > I'm not against having a policy that sits somewhere in between, we just > have to agree it is the right policy and clean up the load-balance code > such that the implemented policy is clear. The proposed patch sits in between? I agree, but would rather see it from another perspective. First, I don't think it merits a solution/policy. It is just a cheap "last guard" to protect the "king" - no crash. Second, a "pure average" policy is pretty fine in general, but it does not mean we would simply allow a CPU to be pulled empty, that is because we are making a bet from a prediction (average) here. By prediction, it basically means sometimes it fails. As the failure could lead to a disater, without blaming the prediction, it is reasonable we make a sort of "damage control". Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] clk: exynos4: Fix wrong clock for Exynos4x12 ADC
2015-06-12 14:46 GMT+09:00 Javier Martinez Canillas :
> Hello Krzysztof,
>
> On Fri, Jun 12, 2015 at 3:53 AM, Krzysztof Kozlowski
> wrote:
>> The TSADC gate clock was used in Exynos4x12 DTSI for exynos-adc driver.
>> However TSADC is present only on Exynos4210 so on Trats2 board (with
>> Exynos4412 SoC) the exynos-adc driver could not be probed:
>>ERROR: could not get clock /adc@126C:adc(0)
>>exynos-adc 126c.adc: failed getting clock, err = -2
>>exynos-adc: probe of 126c.adc failed with error -2
>>
>> Instead on Exynos4x12 SoCs the main clock used by Analog to Digital
>> Converter is located in different register and it is named in datasheet
>> as PCLK_ADC. Regardless of the name the purpose of this PCLK_ADC clock
>> is the same as purpose of TSADC from Exynos4210.
>>
>> The patch adds gate clock for Exynos4x12 using the proper register so
>> backward compatibility is preserved. This fixes the probe of exynos-adc
>> driver on Exynos4x12 boards and allows accessing sensors connected to it
>> on Trats2 board (ntc,ncp15wb473 AP and battery thermistors).
>>
>> Signed-off-by: Krzysztof Kozlowski
>> Cc:
>> Fixes: c63c57433003 ("ARM: dts: Add ADC's dt data to read raw data for
>> exynos4x12")
>> Link: https://lkml.org/lkml/2015/6/11/85
>>
>> ---
>>
>> Changes since v1:
>> 1. After discussion on LKML this solution was chosen because it smaller,
>>simpler, self-contained (one patch to fix issue) and maintains backward
>>compatibility. Thanks to Javier Martinez Canillas and Tomasz Figa for
>>valuable comments.
>> 2. Dropped patch 2/2 because now it is not needed. The clock id "TSADC"
>>will be used on all Exynos4 boards.
>> 3. Added CC-stable.
>> ---
>> drivers/clk/samsung/clk-exynos4.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>
> Patch looks good to me.
>
> Reviewed-by: Javier Martinez Canillas
Hi Tomasz and Sylwester,
Any comments on this version of patch?
Tomasz, you gave me comments on previous version. Are their satisfied?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc/powernv: Fix race in updating core_idle_state
On Wed, 2015-01-07 at 06:34:10 UTC, "Shreyas B. Prabhu" wrote: > core_idle_state is maintained for each core. It uses 0-7 bits to track > whether a thread in the core has entered fastsleep or winkle. 8th bit is > used as a lock bit. > The lock bit is set in these 2 scenarios- > - The thread is first in subcore to wakeup from sleep/winkle. > - If its the last thread in the core about to enter sleep/winkle > > While the lock bit is set, if any other thread in the core wakes up, it > loops until the lock bit is cleared before proceeding in the wakeup > path. This helps prevent race conditions w.r.t fastsleep workaround and > prevents threads from switching to process context before core/subcore > resources are restored. > > But, in the path to sleep/winkle entry, we currently don't check for > lock-bit. This exposes us to following race when running with subcore > on- > > First thread in the subcorea Another thread in the same > waking up core entering sleep/winkle > > lwarx r15,0,r14 > ori r15,r15,PNV_CORE_IDLE_LOCK_BIT > stwcx. r15,0,r14 > [Code to restore subcore state] > > lwarx r15,0,r14 > [clear thread bit] > stwcx. r15,0,r14 > > andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS > stw r15,0(r14) > > Here, after the thread entering sleep clears its thread bit in > core_idle_state, the value is overwritten by the thread waking up. > This patch fixes the above race by looping on the lock bit even while > entering the idle states. What are the symptoms of this bug? I assume they're not good. In which case this should go to stable, shouldn't it? If so which versions? And which commit introduced the bug? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] mm: nommu: fix typos in comment blocks
continguos -> contiguous
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Remove '.' from the end of the subject
mm/nommu.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index 58ea364..0b34f40 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -324,12 +324,12 @@ long vwrite(char *buf, char *addr, unsigned long count)
}
/*
- * vmalloc - allocate virtually continguos memory
+ * vmalloc - allocate virtually contiguous memory
*
* @size: allocation size
*
* Allocate enough pages to cover @size from the page level
- * allocator and map them into continguos kernel virtual space.
+ * allocator and map them into contiguous kernel virtual space.
*
* For tight control over page level allocator and protection flags
* use __vmalloc() instead.
@@ -341,12 +341,12 @@ void *vmalloc(unsigned long size)
EXPORT_SYMBOL(vmalloc);
/*
- * vzalloc - allocate virtually continguos memory with zero fill
+ * vzalloc - allocate virtually contiguous memory with zero fill
*
* @size: allocation size
*
* Allocate enough pages to cover @size from the page level
- * allocator and map them into continguos kernel virtual space.
+ * allocator and map them into contiguous kernel virtual space.
* The memory allocated is set to zero.
*
* For tight control over page level allocator and protection flags
@@ -420,7 +420,7 @@ void *vmalloc_exec(unsigned long size)
* @size: allocation size
*
* Allocate enough 32bit PA addressable pages to cover @size from the
- * page level allocator and map them into continguos kernel virtual space.
+ * page level allocator and map them into contiguous kernel virtual space.
*/
void *vmalloc_32(unsigned long size)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: nommu: fix typos in comment blocks.
continguos -> contiguous
Signed-off-by: Masahiro Yamada
---
mm/nommu.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index 58ea364..0b34f40 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -324,12 +324,12 @@ long vwrite(char *buf, char *addr, unsigned long count)
}
/*
- * vmalloc - allocate virtually continguos memory
+ * vmalloc - allocate virtually contiguous memory
*
* @size: allocation size
*
* Allocate enough pages to cover @size from the page level
- * allocator and map them into continguos kernel virtual space.
+ * allocator and map them into contiguous kernel virtual space.
*
* For tight control over page level allocator and protection flags
* use __vmalloc() instead.
@@ -341,12 +341,12 @@ void *vmalloc(unsigned long size)
EXPORT_SYMBOL(vmalloc);
/*
- * vzalloc - allocate virtually continguos memory with zero fill
+ * vzalloc - allocate virtually contiguous memory with zero fill
*
* @size: allocation size
*
* Allocate enough pages to cover @size from the page level
- * allocator and map them into continguos kernel virtual space.
+ * allocator and map them into contiguous kernel virtual space.
* The memory allocated is set to zero.
*
* For tight control over page level allocator and protection flags
@@ -420,7 +420,7 @@ void *vmalloc_exec(unsigned long size)
* @size: allocation size
*
* Allocate enough 32bit PA addressable pages to cover @size from the
- * page level allocator and map them into continguos kernel virtual space.
+ * page level allocator and map them into contiguous kernel virtual space.
*/
void *vmalloc_32(unsigned long size)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thermal: exynos: Disable the regulator on probe failure
2015-06-09 1:14 GMT+09:00 Lukasz Majewski :
> Hi Krzysztof,
>
>> During probe the regulator (if present) was enabled but not disabled
>> in case of failure. So an unsuccessful probe lead to enabling the
>> regulator which was actually not needed because the device was not
>> enabled.
>>
>> Additionally each deferred probe lead to increase of regulator enable
>> count so it would not be effectively disabled during removal of the
>> device.
>
> Thanks for catching this.
>
>>
>> Signed-off-by: Krzysztof Kozlowski
>> Fixes: 498d22f616f6 ("thermal: exynos: Support for TMU regulator
>> defined at device tree") Cc:
>>
>> ---
>>
>> I am not entirely convinced that this should go to stable. Leaving a
>> regulator enabled in case of probe failure (no exynos TMU device) or
>> after deferred probe (regulator won't be disabled during device
>> removal) is not a critical issue, just leaks power.
>> ---
>> drivers/thermal/samsung/exynos_tmu.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
>> b/drivers/thermal/samsung/exynos_tmu.c index
>> 531f4b179871..13c3aceed19d 100644 ---
>> a/drivers/thermal/samsung/exynos_tmu.c +++
>> b/drivers/thermal/samsung/exynos_tmu.c @@ -1392,6 +1392,8 @@
>> err_clk_sec: if (!IS_ERR(data->clk_sec))
>> clk_unprepare(data->clk_sec);
>> err_sensor:
>> + if (!IS_ERR_OR_NULL(data->regulator))
>> + regulator_disable(data->regulator);
>> thermal_zone_of_sensor_unregister(>dev, data->tzd);
>>
>> return ret;
>
> Acked-by: Lukasz Majewski
>
> I will test it and afterwards add to samsung-thermal tree.
Hi Łukasz,
I can't find this patch in v4.2-rc1 or your tree. What happened?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jul 6
Hi all, Now that -rc1 is out, please clean up your trees if necessary. Changes since 20150703: I have started doing a build of tools/perf between each merge. My fixes tree contains: staging: board: Kconfig: Let STAGING_BOARD depend on CLKDEV_LOOKUP tools/perf, rbtree: Add RCU wrappers to make rbtree.h usable in user-space The device-mapper tree gained a build failure so I used the version from next-20160703. Non-merge commits (relative to Linus' tree): 859 557 files changed, 48664 insertions(+), 4154 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 221 trees (counting Linus' and 31 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (d770e558e219 Linux 4.2-rc1) Merging fixes/master (9c006c240d7c staging: board: Kconfig: Let STAGING_BOARD depend on CLKDEV_LOOKUP) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (11b8b25ce4f8 ARM: fix lockdep unannotated irqs-off warning) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge-mpe/fixes (b953c0d234bc Linux 4.1) Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (4a10a91756ef Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit) Merging net/master (fda8b18c515a cxgb4: Fix incorrect sequence numbers shown in devlog) Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at start of day.) Merging sound-current/for-linus (0689a86ae814 ALSA: usb-audio: Add MIDI support for Steinberg MI2/MI4) Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during alignment reordering) Merging wireless-drivers/master (38fe44e61a89 Merge tag 'iwlwifi-for-kalle-2015-05-28' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (d4a4f75cd8f2 Linux 4.1-rc7) Merging tty.current/tty-linus (d4a4f75cd8f2 Linux 4.1-rc7) Merging usb.current/usb-linus (d4a4f75cd8f2 Linux 4.1-rc7) Merging usb-gadget-fixes/fixes (c94e289f195e usb: gadget: remove incorrect __init/__exit annotations) Merging usb-serial-fixes/usb-linus (0f57d86787d8 Linux 4.1-rc8) Merging staging.current/staging-linus (6aaf0da8728c Merge tag 'md/4.2' of git://neil.brown.name/md) Merging char-misc.current/char-misc-linus (2a298679b411 Merge tag 'usb-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb) Merging input-current/for-linus (a5cba18c4de2 Merge branch 'next' into for-linus) Merging crypto-current/master (0fbafd06bdde crypto: aesni - fix failing setkey for rfc4106-gcm-aesni) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (f36963c9d3f6 cpumask_set_cpu_local_first => cpumask_local_spread, lament) Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible timeout) Merging kselftest-fixes/fixes (ba155e2d21f6 Linux 4.1-rc5) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM) Merging drm-intel-fixes/for-linux-next-fixes (b953c0d234bc Linux 4.1) Merging
[PATCH 0/3] ARM: add UART and EHCI support for UniPhier DTS and enable them.
The basic support for UniPhier SoC family (arch/arm/mach-uniphier) was mainlined at Linux 4.1-rc1. I am now tackling some drivers to support them in the mainline. I've got UART and EHCI done, so I'd like to enable them from the ARM-SOC subsystem. Masahiro Yamada (3): ARM: multi_v7_defconfig: enable UniPhier UART driver ARM: dts: UniPhier: add on-chip UART device nodes ARM: dts: UniPhier: add USB EHCI device nodes arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 29 +++-- arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 63 + arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 29 +++-- arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 56 + arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 36 +++-- arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 61 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 33 +-- arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 63 + arch/arm/configs/multi_v7_defconfig | 1 + 9 files changed, 359 insertions(+), 12 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: multi_v7_defconfig: enable UniPhier UART driver
The UniPhier on-chip UART driver was merged into the mainline by commit 1a8d2903cb6a (serial: 8250_uniphier: add UniPhier serial driver). Enable it from multi_v7_defconfig. Signed-off-by: Masahiro Yamada --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 6d83a1b..9311cd9 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -251,6 +251,7 @@ CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DW=y CONFIG_SERIAL_8250_EM=y CONFIG_SERIAL_8250_MT6577=y +CONFIG_SERIAL_8250_UNIPHIER=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_SERIAL_ATMEL=y -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: dts: UniPhier: add on-chip UART device nodes
The UniPhier on-chip UART driver was merged into the mainline by
commit 1a8d2903cb6a (serial: 8250_uniphier: add UniPhier serial
driver).
Add device nodes to make it really available.
We no longer have to depend on the on-board UART device (16550A),
so let's change the chosen and aliases to point to the on-chip ones.
Also, turn on the on-board Ethernet device.
Signed-off-by: Masahiro Yamada
---
arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 21 ---
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 42 +
arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 21 ---
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 42 +
arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 20 +++---
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 33 +++
arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 21 ---
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 42 +
8 files changed, 230 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
index 200b0c9..0cd385a9 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -57,11 +57,14 @@
chosen {
bootargs = "console=ttyS0,115200";
- stdout-path =
+ stdout-path =
};
aliases {
- serial0 =
+ serial0 =
+ serial1 =
+ serial2 =
+ serial3 =
};
};
@@ -74,6 +77,18 @@
ranges = <0x 1 0x03f0 0x0010>;
};
- {
+ {
interrupts = <0 49 4>;
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index 6a34c56..1261e6d 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -64,6 +64,12 @@
compatible = "fixed-clock";
clock-frequency = <5000>;
};
+
+ uart_clk: uart_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <36864000>;
+ };
};
soc {
@@ -79,6 +85,42 @@
#size-cells = <1>;
};
+ serial0: serial@54006800 {
+ compatible = "socionext,uniphier-uart";
+ status = "disabled";
+ reg = <0x54006800 0x40>;
+ interrupts = <0 33 4>;
+ clocks = <_clk>;
+ fifo-size = <64>;
+ };
+
+ serial1: serial@54006900 {
+ compatible = "socionext,uniphier-uart";
+ status = "disabled";
+ reg = <0x54006900 0x40>;
+ interrupts = <0 35 4>;
+ clocks = <_clk>;
+ fifo-size = <64>;
+ };
+
+ serial2: serial@54006a00 {
+ compatible = "socionext,uniphier-uart";
+ status = "disabled";
+ reg = <0x54006a00 0x40>;
+ interrupts = <0 37 4>;
+ clocks = <_clk>;
+ fifo-size = <64>;
+ };
+
+ serial3: serial@54006b00 {
+ compatible = "socionext,uniphier-uart";
+ status = "disabled";
+ reg = <0x54006b00 0x40>;
+ interrupts = <0 29 4>;
+ clocks = <_clk>;
+ fifo-size = <64>;
+ };
+
system-bus-controller-misc@5980 {
compatible =
"socionext,uniphier-system-bus-controller-misc",
"syscon";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
index d891135..0951cbf 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
@@ -57,11 +57,14 @@
chosen {
bootargs = "console=ttyS0,115200";
- stdout-path =
+ stdout-path =
};
aliases {
- serial0 =
+ serial0 =
+ serial1 =
+ serial2 =
+ serial3 =
};
};
@@ -74,6 +77,18 @@
ranges = <0x 1 0x03f0 0x0010>;
};
- {
+ {
interrupts = <0 50 4>;
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
[PATCH 3/3] ARM: dts: UniPhier: add USB EHCI device nodes
Get USB 2.0 host controllers available with generic-ehci bindings.
Signed-off-by: Masahiro Yamada
---
arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 8
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 21 +
arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 8
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 14 ++
arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 16
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 28
arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 12
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 21 +
8 files changed, 128 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
index 0cd385a9..7ac053d 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -92,3 +92,11 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index 1261e6d..b042711 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -127,6 +127,27 @@
reg = <0x5980 0x2000>;
};
+ usb0: usb@5a800100 {
+ compatible = "generic-ehci";
+ status = "disabled";
+ reg = <0x5a800100 0x100>;
+ interrupts = <0 80 4>;
+ };
+
+ usb1: usb@5a810100 {
+ compatible = "generic-ehci";
+ status = "disabled";
+ reg = <0x5a810100 0x100>;
+ interrupts = <0 81 4>;
+ };
+
+ usb2: usb@5a820100 {
+ compatible = "generic-ehci";
+ status = "disabled";
+ reg = <0x5a820100 0x100>;
+ interrupts = <0 82 4>;
+ };
+
timer@6200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x6200 0x20>;
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
index 0951cbf..b669d32 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
@@ -92,3 +92,11 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index acd2c06..85db033 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -134,6 +134,20 @@
reg = <0x5980 0x2000>;
};
+ usb2: usb@5a800100 {
+ compatible = "generic-ehci";
+ status = "disabled";
+ reg = <0x5a800100 0x100>;
+ interrupts = <0 80 4>;
+ };
+
+ usb3: usb@5a810100 {
+ compatible = "generic-ehci";
+ status = "disabled";
+ reg = <0x5a810100 0x100>;
+ interrupts = <0 81 4>;
+ };
+
timer@6200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x6200 0x20>;
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
index 47a44da..48f7361 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
@@ -92,3 +92,19 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
index feb253b..d0c2f11 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
@@ -146,5 +146,33 @@
"syscon";
reg = <0x5980 0x2000>;
};
+
+ usb0: usb@5a800100 {
+ compatible = "generic-ehci";
+ status = "disabled";
+ reg = <0x5a800100 0x100>;
+ interrupts = <0 80 4>;
+ };
+
+ usb1: usb@5a810100 {
+ compatible = "generic-ehci";
+ status = "disabled";
+ reg = <0x5a810100 0x100>;
+ interrupts = <0 81 4>;
+ };
+
+ usb2: usb@5a820100 {
+ compatible = "generic-ehci";
+ status =
[PATCH] ARM: rockchip: fix broken build
The following was seen in branch[0] build. arch/arm/mach-rockchip/platsmp.c:154:23: error: 'rockchip_secondary_startup' undeclared (first use in this function) branch[0]: git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git v4.3-armsoc/soc The broken build is caused by the commit (fe4407c0dc58215a7abfb7532740d79ddabe7a7a) Signed-off-by: Caesar Wang --- arch/arm/mach-rockchip/platsmp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c index 7ebd1c1..3e7a4b7 100644 --- a/arch/arm/mach-rockchip/platsmp.c +++ b/arch/arm/mach-rockchip/platsmp.c @@ -152,8 +152,7 @@ static int rockchip_boot_secondary(unsigned int cpu, struct task_struct *idle) */ mdelay(1); /* ensure the cpus other than cpu0 to startup */ - writel(virt_to_phys(rockchip_secondary_startup), - sram_base_addr + 8); + writel(virt_to_phys(secondary_startup), sram_base_addr + 8); writel(0xDEADBEAF, sram_base_addr + 4); dsb_sev(); } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] arm: dts: ls1021a: Add LTC2945 node for LS1021A TWR board
LTC2945 is replaced by INA220 in rev2.0.
Please note it as "Superseded" in patchworks.
Thanks.
---
Best Regards,
Hongtao
> -Original Message-
> From: Alison Wang [mailto:b18...@freescale.com]
> Sent: Monday, July 06, 2015 10:38 AM
> To: shawn@linaro.org; Jin Zhengxiong-R64188; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: Jia Hongtao-B38951
> Subject: [PATCH] arm: dts: ls1021a: Add LTC2945 node for LS1021A TWR
> board
>
> From: Jia Hongtao
>
> This patch adds LTC2945 node for LS1021A TWR board.
>
> Signed-off-by: Jia Hongtao
> ---
> arch/arm/boot/dts/ls1021a-twr.dts | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
> b/arch/arm/boot/dts/ls1021a-twr.dts
> index a0d9ad6..938b16a 100644
> --- a/arch/arm/boot/dts/ls1021a-twr.dts
> +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> @@ -160,6 +160,13 @@
> };
> };
>
> + {
> + status = "okay";
> + monitor: ltc2945@67 {
> + reg = <0x67>;
> + };
> +};
> +
> {
> #address-cells = <2>;
> #size-cells = <1>;
> --
> 2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Feature request, "create on mount" to create mount point directory on mount, implied remove on unmount
On Mon, Jul 06, 2015 at 03:34:59AM +0100, jon wrote: > > It is true if and only if clone(2) gets CLONE_FILES in its arguments. > > Sharing address space is controlled by CLONE_VM and these can be used > > independently; pthreads set both at the same time, but you can have shared > > descriptor table without shared memory and vice versa. Most of the time > > you use shared descriptor tables, you want shared memory as well, but > > it's not universally true. > I mainly use fork(), file descriptors are copied (forward) but memory > not shared. fork() doesn't pass either. Both the address space and descriptor table are copied. > > > Ok, I follow that :-) But logically it must be done with two functions > > > or handlers or something, so I would assume that my proposed "remove > > > mount directory" would simply hang off whatever call truly discards the > > > file system from the kernel. > > > > Er... _Which_ mount directory would you have removed > The one that was passed as "target" in the call ? I assume the kernel > stores that ? Which time? You can mount the same fs many times, at many places, unmounting them whenever you like... mount -t ramfs none /mnt mkdir /mnt/a mount /dev/sda1 /tmp/a mkdir /tmp/b mount /dev/sda1 /tmp/b umount /mnt/a umount /mnt and you've got sda1 active through all of that, with the original mountpoint not busy anymore (moreover, the filesystem it used to be on already shut down). What's more, there's mount --bind (attach a subtree to new location) and mount --move (move whatever's mounted at place to place). Basically, you have a (system-wide) set of active filesystems. Mount trees consist of subtrees in that forest (normally - entire trees) pasted together. The same subtree (or smaller subtrees) might be seen any number of times at any places. You can say e.g. mount -t xfs /dev/sda1 /mnt mount --bind /mnt/a /usr mount --bind /mnt/b /var umount /mnt and you'll get an active fs from sda1, with two subtrees (rooted at a and b resp.) attached at /usr and /var. By the end of that, the entire tree isn't attached anywhere. Seriously, say man mount and play with what's described there. The model is fairly simple, really... As an aside, it's a bleeding shame that even as late as '79 *all* filesystems on a box had to be of the same type; that's pretty much _the_ place where Unix history went wrong - mount(2) had remained an afterthought (albeit a very early one) all the way until v7. Hell, as late as in v6 mounting something on /usr and opening /usr/.. gave you /usr, not / It was kludged up in iget(9), of all things - mount table basically had been "when doing iget() of this inumber on this device, use root directory inumber on that device instead". Consistent handling of .. had appeared only in v7. It was very much _not_ a first-class operation. As far as I know, the real pressure to support heterogenous filesystem mix had been created only by the need to support network filesystems. Sure, as soon as it had appeared in what was to become v8 (circa 82 or so?), a filesystem to get rid of ptrace(2) (aka procfs) had appeared. But it really had been too late by then - to have netfs, you really need to have some kind of networking API (if nothing else, to be able to implement userland servers). And having _that_ happen before the "filesystem as a first-class object" had pretty much doomed us to really shitty APIs. Pity it hadn't happened in opposite order - very good reasons to do something like e.g. procfs had all been there. Take a look at v7 /usr/src/cmd/ps.c someday... And as soon as mount as the first-class operation would've been there, a _lot_ of API design would've gone a different way... Fucking shame it hadn't happened in v7 - after that it had been too damn late ;-/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm: dts: ls1021a: add wakeup device ftm0 node for ls1021a
From: Wang Dongsheng
Add ftm0 node, cause of ftm0 can be set as a alarm before system
going to deep sleep.
Signed-off-by: Wang Dongsheng
---
arch/arm/boot/dts/ls1021a-qds.dts | 4
arch/arm/boot/dts/ls1021a.dtsi| 8
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a-qds.dts
b/arch/arm/boot/dts/ls1021a-qds.dts
index 9533f1d..e2ccae6 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -146,6 +146,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
status = "okay";
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 4ad30d0..707850f 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -335,6 +335,14 @@
status = "disabled";
};
+ ftm0: ftm0@29d {
+ compatible = "fsl,ftm-alarm";
+ reg = <0x0 0x29d 0x0 0x1>;
+ interrupts = ;
+ big-endian;
+ status = "disabled";
+ };
+
wdog0: watchdog@2ad {
compatible = "fsl,imx21-wdt";
reg = <0x0 0x2ad 0x0 0x1>;
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched,fair: Remove > u32 weight handling for delta
scaled down weight 'fact' would not be > u32 rather than unlikely as the
values being passed for delta is either NICE_O_LOAD or the weight of the
'se' which would be a value that can be accomodated in a u32. Remove the
initial > u32 handling on 'fact'.
9dbdb15553239 ("sched/fair: Rework sched_fair time accounting") in
addition to fixing the original issue of time moving backwards elsewhere
in the code, handled delta > u32 case (due to NO_HZ_FULL) which brought
in as it's part the change changed here. The hunk being removed here
would not make a difference to it as this is on scaled weight > u32.
And pre-"9dbdb15553239" doesn't seem to have logical equivalent of hunk
removed here either.
Signed-off-by: Afzal Mohammed
---
System here (that mainly does kernel build) has been running with this
change for last couple of weeks without any issue observed.
kernel/sched/fair.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3d57cc0ca0a6..0cc58a7bdd16 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -218,13 +218,6 @@ static u64 __calc_delta(u64 delta_exec, unsigned long
weight, struct load_weight
__update_inv_weight(lw);
- if (unlikely(fact >> 32)) {
- while (fact >> 32) {
- fact >>= 1;
- shift--;
- }
- }
-
/* hint to use a 32x32->64 mul */
fact = (u64)(u32)fact * lw->inv_weight;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm: dts: ls1021a: Add LTC2945 node for LS1021A TWR board
From: Jia Hongtao
This patch adds LTC2945 node for LS1021A TWR board.
Signed-off-by: Jia Hongtao
---
arch/arm/boot/dts/ls1021a-twr.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
b/arch/arm/boot/dts/ls1021a-twr.dts
index a0d9ad6..938b16a 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -160,6 +160,13 @@
};
};
+ {
+ status = "okay";
+ monitor: ltc2945@67 {
+ reg = <0x67>;
+ };
+};
+
{
#address-cells = <2>;
#size-cells = <1>;
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Feature request, "create on mount" to create mount point directory on mount, implied remove on unmount
On Mon, 2015-07-06 at 02:08 +0100, Al Viro wrote: > On Mon, Jul 06, 2015 at 12:35:48AM +0100, jon wrote: > > > Anyway, the underlying model hasn't changed much since _way_ back; each > > > thread of execution is a virtual machine of its own, with actual CPUs > > > switched between those. > > Ok, not sure I quite follow. What do you mean virtual machine ? > Anything timesharing, starting with 7094 running CTSS. Hypervisors allow to > virtualize priveleged mode parts of processor; it's a different beast. This was my point. To me "virtual machine" is a modern term that describes something running with a hypervisor. My confusion is you are retrospectively applying it to time sharing. I managed to find the article that first taught me about schedulers, the 1979 Byte article "Introduction to Multiprogrammig" https://archive.org/details/byte-magazine-1979-09 Searching for the pdf for the term "virtual" gives one result, not in that article. I remember "virtual memory" and even "virtual addressing" but I think the term "virtual machine" is modern, maybe someone else knows, google did not help me much trying to prove it one way or the other. > It's considerably older than hypervisors (and both are much older than > x86). Yes it is, but it was not called "virtual machine" at the time in anything I personally read. > I was not aware that the parent > > could see file descriptors created by the child, is this always true or > > only true if the parent and child are explicitly a shared memory > > process. > > It is true if and only if clone(2) gets CLONE_FILES in its arguments. > Sharing address space is controlled by CLONE_VM and these can be used > independently; pthreads set both at the same time, but you can have shared > descriptor table without shared memory and vice versa. Most of the time > you use shared descriptor tables, you want shared memory as well, but > it's not universally true. I mainly use fork(), file descriptors are copied (forward) but memory not shared. > > Ok, I follow that :-) But logically it must be done with two functions > > or handlers or something, so I would assume that my proposed "remove > > mount directory" would simply hang off whatever call truly discards the > > file system from the kernel. > > Er... _Which_ mount directory would you have removed The one that was passed as "target" in the call ? I assume the kernel stores that ? int mount(const char *source, const char *target, > (and what's to > guarantee that all filesystems it had been mounted on are still alive > when the last mount goes away)? ?The same rules that would be in play if it was cross mounted in some other way, or am I being dumb here? I assume Linux will not let me unmount a mount point from lower in the directory tree. I've not tried in living memory so lets give it a go root@jonspc:/# mkdir mounttest root@jonspc:/# cd mounttest/ root@jonspc:/mounttest# mkdir firstmount root@jonspc:/mounttest# mount /dev/sdb1 /mounttest/firstmount root@jonspc:/mounttest# cd firstmount/ root@jonspc:/mounttest/firstmount# mkdir secondmount root@jonspc:/mounttest/firstmount# mount /dev/sdb1 /mounttest/firstmount/secondmount/ root@jonspc:/mounttest/firstmount# cd .. root@jonspc:/mounttest# umount /mounttest/firstmount umount: /mounttest/firstmount: device is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) It fails, as I expected. Also rmdir would fail if the mount point had was anything other than empty, mkdir would fail if the mount point was already created. I don't see how the kernel doing a pre mount mkdir and a post mount rmdir would differ in outcome from user space performing the same operations regardless of convoluted configuration was in use. Like I said I dont use containers or Zen so can you show me a (preferably simple) scenario that my proposal breaks. I assume an entry in a table in the kernel is the source of the above "device is busy" message, is this not also true if the name spaces differ but the same file system is mounted in multiple places? I would expect unmount to unmount all mounted references to that device and umount to remove just that mountpoint or am I miss remembering -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: board: Kconfig: Let STAGING_BOARD depend on CLKDEV_LOOKUP
On 07/06/2015 06:48 AM, Stephen Rothwell wrote: > Hi all, > > On Sun, 5 Jul 2015 18:57:51 +0200 Geert Uytterhoeven > wrote: >> >> On Sat, Jul 4, 2015 at 11:35 PM, Chen Gang >> wrote: >>> It needs clk_add_alias() from clk drivers, which is implemented in >>> "drivers/clk/clkdev.c" which depends on CLKDEV_LOOKUP. >>> >>> Normally, archs and clk driver its own will decide whether select >>> CLKDEV_LOOKUP, and common drivers will decide whether depend on it. >>> >>> The related error (with allmodconfig under cris for next-20150702): >>> >>> drivers/built-in.o: In function `board_staging_register_clock': >>> drivers/staging/board/board.c:131: undefined reference to `clk_add_alias' >>> >>> >>> Signed-off-by: Chen Gang >> >> Fix available for the last 15 days: >> >> https://lkml.org/lkml/2015/6/20/215 > > I added Chen's patch to my fixes tree today (only because I couldn't > easily find a copy of Paul's patch (sorry Paul) i.e. how does one get a > full mail message from lkml.org? Or Geert, maybe that is not the best > place to link to. > For me, I still suggest to use Paul's patch (if it is OK, too). He sent the patch more than 10 days, and was still waiting patiently. There will be a little more work, but I guess, it is necessary. And I shall try to send another patches for Linux kernel. :-) Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ext4:Make the function ext4_ext_tree_init have a return type of void
On Sun, Jul 05, 2015 at 09:09:04PM -0400, Nicholas Krause wrote: > This makes the function ext4_ext_tree_init have a return type of > void due to this function always completed its intended work of > intialzing a ext4_extent_header structue pointer off its passed > arguments of a inode and handle_t pointer. > > Signed-off-by: Nicholas Krause Nick, You *promised* you would give up on sending cleanup patches. Clearly, you can't be trusted. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] net: dsa: mv88e6xxx: add switchdev VLAN operations
This commit implements the switchdev operations to add, delete and dump
VLANs for the Marvell 88E6352 and compatible switch chips.
This allows to access the switch VLAN Table Unit from standard userspace
commands such as "bridge vlan".
A configuration like "1t 2t 3t 4u" for VLAN 10 is achieved like this:
# bridge vlan add dev swp1 vid 10 master
# bridge vlan add dev swp2 vid 10 master
# bridge vlan add dev swp3 vid 10 master
# bridge vlan add dev swp4 vid 10 master untagged pvid
This calls port_vlan_add() for each command. Removing the port 3 from
VLAN 10 is done with:
# bridge vlan del dev swp3 vid 10
This calls port_vlan_del() for port 3. Dumping VLANs is done with:
# bridge vlan show
portvlan ids
swp0None
swp0
swp1 10
swp1 10
swp2 10
swp2 10
swp3None
swp3
swp4 10 PVID Egress Untagged
swp4 10 PVID Egress Untagged
br0 None
This calls port_vlan_dump() for each ports.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6123_61_65.c | 3 +
drivers/net/dsa/mv88e6131.c | 3 +
drivers/net/dsa/mv88e6171.c | 3 +
drivers/net/dsa/mv88e6352.c | 3 +
drivers/net/dsa/mv88e6xxx.c | 152 ++
drivers/net/dsa/mv88e6xxx.h | 5 ++
6 files changed, 169 insertions(+)
diff --git a/drivers/net/dsa/mv88e6123_61_65.c
b/drivers/net/dsa/mv88e6123_61_65.c
index 71a29a7..8e679ff 100644
--- a/drivers/net/dsa/mv88e6123_61_65.c
+++ b/drivers/net/dsa/mv88e6123_61_65.c
@@ -134,6 +134,9 @@ struct dsa_switch_driver mv88e6123_61_65_switch_driver = {
#endif
.get_regs_len = mv88e6xxx_get_regs_len,
.get_regs = mv88e6xxx_get_regs,
+ .port_vlan_add = mv88e6xxx_port_vlan_add,
+ .port_vlan_del = mv88e6xxx_port_vlan_del,
+ .port_vlan_dump = mv88e6xxx_port_vlan_dump,
};
MODULE_ALIAS("platform:mv88e6123");
diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index 32f4a08..c4d914b 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -182,6 +182,9 @@ struct dsa_switch_driver mv88e6131_switch_driver = {
.get_strings= mv88e6xxx_get_strings,
.get_ethtool_stats = mv88e6xxx_get_ethtool_stats,
.get_sset_count = mv88e6xxx_get_sset_count,
+ .port_vlan_add = mv88e6xxx_port_vlan_add,
+ .port_vlan_del = mv88e6xxx_port_vlan_del,
+ .port_vlan_dump = mv88e6xxx_port_vlan_dump,
};
MODULE_ALIAS("platform:mv88e6085");
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index 1c78084..7701ce6 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -119,6 +119,9 @@ struct dsa_switch_driver mv88e6171_switch_driver = {
.fdb_add= mv88e6xxx_port_fdb_add,
.fdb_del= mv88e6xxx_port_fdb_del,
.fdb_getnext= mv88e6xxx_port_fdb_getnext,
+ .port_vlan_add = mv88e6xxx_port_vlan_add,
+ .port_vlan_del = mv88e6xxx_port_vlan_del,
+ .port_vlan_dump = mv88e6xxx_port_vlan_dump,
};
MODULE_ALIAS("platform:mv88e6171");
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 632815c..b981be4a 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -392,6 +392,9 @@ struct dsa_switch_driver mv88e6352_switch_driver = {
.fdb_add= mv88e6xxx_port_fdb_add,
.fdb_del= mv88e6xxx_port_fdb_del,
.fdb_getnext= mv88e6xxx_port_fdb_getnext,
+ .port_vlan_add = mv88e6xxx_port_vlan_add,
+ .port_vlan_del = mv88e6xxx_port_vlan_del,
+ .port_vlan_dump = mv88e6xxx_port_vlan_dump,
};
MODULE_ALIAS("platform:mv88e6352");
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index ffd9fc6..d5812ba 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1544,6 +1544,158 @@ static int _mv88e6xxx_vtu_loadpurge(struct dsa_switch
*ds,
return _mv88e6xxx_vtu_cmd(ds, GLOBAL_VTU_OP_VTU_LOAD_PURGE);
}
+int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port, u16 vid,
+ u16 bridge_flags)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ struct mv88e6xxx_vtu_entry entry = { 0 };
+ int prev_vid = vid ? vid - 1 : 0xfff;
+ int i, ret;
+
+ mutex_lock(>smi_mutex);
+ ret = _mv88e6xxx_vtu_getnext(ds, prev_vid, );
+ if (ret < 0)
+ goto unlock;
+
+ /* If the VLAN does not exist, re-initialize the entry for addition */
+ if (entry.vid != vid || !entry.valid) {
+ memset(, 0, sizeof(entry));
+ entry.valid = true;
+ entry.vid = vid;
+ entry.fid = vid; /* We use one FID per VLAN at the moment */
+
[PATCH v3 1/3] net: dsa: mv88e6xxx: add debugfs interface for VTU
Implement the Get Next and Load Purge operations for the VLAN Table
Unit, and a "vtu" debugfs file to read and write the hardware VLANs.
A populated VTU look like this:
# cat /sys/kernel/debug/dsa0/vtu
VID FID SID 0 1 2 3 4 5 6
550 5620 x x x u x t x
1000 10120 x x t x x t x
1200 12120 x x t x t t x
Where "t", "u", "x", "-", respectively means that the port is tagged,
untagged, excluded or unmodified, for a given VLAN entry.
VTU entries can be added by echoing the same format:
echo 1300 1312 0 x x t x t t x > vtu
and can be deleted by echoing only the VID:
echo 1000 > vtu
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 311
drivers/net/dsa/mv88e6xxx.h | 24
2 files changed, 335 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 8c130c0..ffd9fc6 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -2,6 +2,9 @@
* net/dsa/mv88e6xxx.c - Marvell 88e6xxx switch chip support
* Copyright (c) 2008 Marvell Semiconductor
*
+ * Copyright (c) 2015 CMC Electronics, Inc.
+ * Added support for 802.1Q VLAN Table Unit
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -1366,6 +1369,181 @@ static void mv88e6xxx_bridge_work(struct work_struct
*work)
}
}
+static int _mv88e6xxx_vtu_wait(struct dsa_switch *ds)
+{
+ return _mv88e6xxx_wait(ds, REG_GLOBAL, GLOBAL_VTU_OP,
+ GLOBAL_VTU_OP_BUSY);
+}
+
+static int _mv88e6xxx_vtu_cmd(struct dsa_switch *ds, u16 op)
+{
+ int ret;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_OP, op);
+ if (ret < 0)
+ return ret;
+
+ return _mv88e6xxx_vtu_wait(ds);
+}
+
+static int _mv88e6xxx_stu_loadpurge(struct dsa_switch *ds, u8 sid, bool valid)
+{
+ int ret, data;
+
+ ret = _mv88e6xxx_vtu_wait(ds);
+ if (ret < 0)
+ return ret;
+
+ data = sid & GLOBAL_VTU_SID_MASK;
+ if (valid)
+ data |= GLOBAL_VTU_VID_VALID;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_VID, data);
+ if (ret < 0)
+ return ret;
+
+ /* Unused (yet) data registers */
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_DATA_0_3, 0);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_DATA_4_7, 0);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_DATA_8_11, 0);
+ if (ret < 0)
+ return ret;
+
+ return _mv88e6xxx_vtu_cmd(ds, GLOBAL_VTU_OP_STU_LOAD_PURGE);
+}
+
+static int _mv88e6xxx_vtu_getnext(struct dsa_switch *ds, u16 vid,
+ struct mv88e6xxx_vtu_entry *entry)
+{
+ int ret, i;
+
+ ret = _mv88e6xxx_vtu_wait(ds);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_VID,
+ vid & GLOBAL_VTU_VID_MASK);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_vtu_cmd(ds, GLOBAL_VTU_OP_VTU_GET_NEXT);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_VID);
+ if (ret < 0)
+ return ret;
+
+ entry->vid = ret & GLOBAL_VTU_VID_MASK;
+ entry->valid = !!(ret & GLOBAL_VTU_VID_VALID);
+
+ if (entry->valid) {
+ /* Ports 0-3, offsets 0, 4, 8, 12 */
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_DATA_0_3);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < 4; ++i)
+ entry->tags[i] = (ret >> (i * 4)) & 3;
+
+ /* Ports 4-6, offsets 0, 4, 8 */
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_DATA_4_7);
+ if (ret < 0)
+ return ret;
+
+ for (i = 4; i < 7; ++i)
+ entry->tags[i] = (ret >> ((i - 4) * 4)) & 3;
+
+ if (mv88e6xxx_6097_family(ds) || mv88e6xxx_6165_family(ds) ||
+ mv88e6xxx_6351_family(ds) || mv88e6xxx_6352_family(ds)) {
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL,
+ GLOBAL_VTU_FID);
+ if (ret < 0)
+ return ret;
+
+ entry->fid = ret & GLOBAL_VTU_FID_MASK;
+
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL,
+ GLOBAL_VTU_SID);
+ if (ret < 0)
+ return ret;
+
+
[PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
Hi all, This patchset brings full support for hardware VLANs in DSA, and the Marvell 88E6xxx compatible switch chips. The first patch adds the VTU operations to the mv88e6xxx code, as well as a "vtu" debugfs file to read and modify the hardware VLAN table. The second patch adds the glue between DSA and the switchdev VLAN objects. The third patch finally implements the necessary functions in the mv88e6xxx code to interact with the hardware VLAN through switchdev, from userspace commands such as "bridge vlan". Below is an example of what can be done with this patchset. "VID 550: 1t 3u" "VID 1000: 2t" "VID 1200: 2t 4t" The VLAN setup above can be achieved with the following bridge commands: bridge vlan add vid 550 dev swp1 master bridge vlan add vid 550 dev swp3 master untagged pvid bridge vlan add vid 1000 dev swp2 master bridge vlan add vid 1200 dev swp2 master bridge vlan add vid 1200 dev swp4 master Removing the port 1 from VLAN 550 is done with: bridge vlan del vid 550 dev swp1 The bridge command would output the following setup: # bridge vlan portvlan ids swp0None swp0 swp1None swp1 swp21000 1200 swp21000 1200 swp3550 PVID Egress Untagged swp3550 PVID Egress Untagged swp41200 swp41200 br0 None Assuming that swp5 is the CPU port, the "vtu" debugfs file would show: # cat /sys/kernel/debug/dsa0/vtu VID FID SID 0 1 2 3 4 5 6 550 550 0x x x u x t x 1000 1000 0x x t x x t x 1200 1200 0x x t x t t x Cheers, -v Vivien Didelot (3): net: dsa: mv88e6xxx: add debugfs interface for VTU net: dsa: add support for switchdev VLAN objects net: dsa: mv88e6xxx: add switchdev VLAN operations drivers/net/dsa/mv88e6123_61_65.c | 3 + drivers/net/dsa/mv88e6131.c | 3 + drivers/net/dsa/mv88e6171.c | 3 + drivers/net/dsa/mv88e6352.c | 3 + drivers/net/dsa/mv88e6xxx.c | 463 ++ drivers/net/dsa/mv88e6xxx.h | 29 +++ include/net/dsa.h | 9 + net/dsa/dsa_priv.h| 6 + net/dsa/slave.c | 137 +++ 9 files changed, 656 insertions(+) -- 2.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] net: dsa: add support for switchdev VLAN objects
This patch adds the glue between DSA and switchdev operations to add,
delete and dump SWITCHDEV_OBJ_PORT_VLAN objects.
This is a first step to link the "bridge vlan" command with hardware
entries for DSA compatible switch chips.
Signed-off-by: Vivien Didelot
---
include/net/dsa.h | 9
net/dsa/dsa_priv.h | 6 +++
net/dsa/slave.c| 137 +
3 files changed, 152 insertions(+)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index fbca63b..cabf2a5 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -302,6 +302,15 @@ struct dsa_switch_driver {
const unsigned char *addr, u16 vid);
int (*fdb_getnext)(struct dsa_switch *ds, int port,
unsigned char *addr, bool *is_static);
+
+ /*
+* VLAN support
+*/
+ int (*port_vlan_add)(struct dsa_switch *ds, int port, u16 vid,
+u16 bridge_flags);
+ int (*port_vlan_del)(struct dsa_switch *ds, int port, u16 vid);
+ int (*port_vlan_dump)(struct dsa_switch *ds, int port, u16 vid,
+ u16 *bridge_flags);
};
void register_switch_driver(struct dsa_switch_driver *type);
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index d5f1f9b..9029717 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -13,6 +13,7 @@
#include
#include
+#include
struct dsa_device_ops {
netdev_tx_t (*xmit)(struct sk_buff *skb, struct net_device *dev);
@@ -47,6 +48,11 @@ struct dsa_slave_priv {
int old_duplex;
struct net_device *bridge_dev;
+
+ /*
+* Which VLANs this port is a member of.
+*/
+ DECLARE_BITMAP(vlan_bitmap, VLAN_N_VID);
};
/* dsa.c */
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 04ffad3..47c459b 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "dsa_priv.h"
/* slave mii_bus handling ***/
@@ -363,6 +364,136 @@ static int dsa_slave_port_attr_set(struct net_device *dev,
return ret;
}
+static int dsa_slave_port_vlans_add(struct net_device *dev,
+struct switchdev_obj *obj)
+{
+ struct switchdev_obj_vlan *vlan = >u.vlan;
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_switch *ds = p->parent;
+ int vid, err = 0;
+
+ if (!ds->drv->port_vlan_add)
+ return -EOPNOTSUPP;
+
+ for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
+ err = ds->drv->port_vlan_add(ds, p->port, vid, vlan->flags);
+ if (err)
+ break;
+ set_bit(vid, p->vlan_bitmap);
+ }
+
+ return err;
+}
+
+static int dsa_slave_port_obj_add(struct net_device *dev,
+ struct switchdev_obj *obj)
+{
+ int err;
+
+ /*
+* Skip the prepare phase, since currently the DSA drivers don't need to
+* allocate any memory for operations and they will not fail to HW
+* (unless something horrible goes wrong on the MDIO bus, in which case
+* the prepare phase wouldn't have been able to predict anyway).
+*/
+ if (obj->trans != SWITCHDEV_TRANS_COMMIT)
+ return 0;
+
+ switch (obj->id) {
+ case SWITCHDEV_OBJ_PORT_VLAN:
+ err = dsa_slave_port_vlans_add(dev, obj);
+ break;
+ default:
+ err = -EOPNOTSUPP;
+ break;
+ }
+
+ return err;
+}
+
+static int dsa_slave_port_vlans_del(struct net_device *dev,
+struct switchdev_obj *obj)
+{
+ struct switchdev_obj_vlan *vlan = >u.vlan;
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_switch *ds = p->parent;
+ int vid, err = 0;
+
+ if (!ds->drv->port_vlan_del)
+ return -EOPNOTSUPP;
+
+ for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
+ err = ds->drv->port_vlan_del(ds, p->port, vid);
+ if (err)
+ break;
+ clear_bit(vid, p->vlan_bitmap);
+ }
+
+ return err;
+}
+
+static int dsa_slave_port_obj_del(struct net_device *dev,
+ struct switchdev_obj *obj)
+{
+ int err;
+
+ switch (obj->id) {
+ case SWITCHDEV_OBJ_PORT_VLAN:
+ err = dsa_slave_port_vlans_del(dev, obj);
+ break;
+ default:
+ err = -EOPNOTSUPP;
+ break;
+ }
+
+ return err;
+}
+
+static int dsa_slave_port_vlans_dump(struct net_device *dev,
+struct switchdev_obj *obj)
+{
+ struct switchdev_obj_vlan *vlan = >u.vlan;
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct
[PATCH] ASoC: dpcm: Add checks of playback/capture before dpcm_get_be
In dpcm_get_be(), it looks for a BE rtd that has the DAI widget
according to current stream type. Only playback_widgets are searched
in the case of playback stream and vice versa. However, the DAI widget
itself can be playback or capture.
If the DAI widget is capture, but current stream type is playback,
dpcm_get_be() will always fail to find a rtd, print error messages,
and continue to the next DAI widget in list. We can just skip this
DAI widget to further suppress error messages. This happens in a
special case when 2 codecs are inter-connected, and the 1st codec's
"capture" widget is used to send data to the 2nd codec during "playback":
mtk-rt5650-rt5676 sound: ASoC: can't get playback BE for Sub AIF2 Capture
rt5650_rt5676 Playback: ASoC: no BE found for Sub AIF2 Capture
Add checks to continue to next DAI widget if current DAI widget's
direction does not match the stream type.
Signed-off-by: Koro Chen
---
sound/soc/soc-pcm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index 256b9c9..a6d3313 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -1306,7 +1306,12 @@ static int dpcm_add_paths(struct snd_soc_pcm_runtime
*fe, int stream,
switch (list->widgets[i]->id) {
case snd_soc_dapm_dai_in:
+ if (stream != SNDRV_PCM_STREAM_PLAYBACK)
+ continue;
+ break;
case snd_soc_dapm_dai_out:
+ if (stream != SNDRV_PCM_STREAM_CAPTURE)
+ continue;
break;
default:
continue;
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] csiostor:Make the function csio_ln_prep_ecwr have a return type of void
Acked-by: Anish Bhatt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][v2] asus-rbtn: new driver for asus radio button for Windows 8
ATK4001 is an ACPI device for wireless hotkey, similar to how Dell and HP are doing it. It is just ASUS who decides LED should be controlled by software unlike HP whose LED is driven by hardware pins on mini card. On Fri, Jul 3, 2015 at 3:25 PM, Pali Rohár wrote: > On Thursday 02 July 2015 15:10:39 Alex Hung wrote: >> Thanks for the support. I will create v3 based with LED triggers. >> >> Just for information. ASUS's wording is as below: >> >> Fn+F2 can be used to turn on or off all radio capabilities in the >> device (as known as airplane mode switch). I don't have any >> preferences on the name. We may use the term airplane-mode do if >> asus-rbtn is not preferred. Let me know if there are any suggestions. >> > > This is OK, but I though that ACPI ATK4001 device is some > multifunctional device, which is doing more then LED control... (At > least I understand it from your comments). So in this case I would not > call driver led/radio related. Right? > >> >> On Wed, Jul 1, 2015 at 7:48 PM, Pali Rohár wrote: >> > On Wednesday 01 July 2015 00:09:41 Alex Hung wrote: >> >> ATK4001 is an independent ACPI device, and Method(HSWC) is its method >> >> to control LED (actually it has other functions but only LED is needed >> >> so far). >> > >> > If this driver is for supporting ACPI ATK4001 device (which has couple >> > of methods, not only LED) it is really good idea to name it asus-rbtn? >> > >> > Darren, you as maintainer of platform drivers, what do you think? I >> > believe in future this driver will be extended to support more functions >> > and so name asus-rbtn will be confusing. >> > >> > -- >> > Pali Rohár >> > pali.ro...@gmail.com >> > > -- > Pali Rohár > pali.ro...@gmail.com -- Cheers, Alex Hung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 0/2] Implement sample time consideration for Vybrid's ADC
From: Sanchayan Maity Sent: Wednesday, June 24, 2015 4:34 PM > To: ji...@kernel.org > Cc: shawn@linaro.org; ker...@pengutronix.de; robh...@kernel.org; > pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; > ga...@codeaurora.org; Duan Fugang-B38611; devicet...@vger.kernel.org; > linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org; ste...@agner.ch; Sanchayan Maity > Subject: [PATCH v2 0/2] Implement sample time consideration for Vybrid's > ADC > > Hello, > > This patchset adds a dt binding for specifying sample time for the vybrid > adc driver and takes this into account for sampling frequency calculation > and related configuration in the driver. > > The patchset is based on top of Stefan's patches here > http://lkml.iu.edu/hypermail/linux/kernel/1505.3/02043.html > > which got recently applied. Tested with shawn's for-next branch. > > Changes since v1: > > Change from a vendor specific fsl,min-sample-time to non vendor specific > min-sample-time. > > Version 1 of the patchset can be found here > http://lkml.iu.edu/hypermail/linux/kernel/1506.1/00026.html > > - Sanchayan. > > Sanchayan Maity (2): > iio: adc: Determine sampling frequencies by using minimum sample time > ARM: dts: vfxxx: Add property for minimum sample time > > .../devicetree/bindings/iio/adc/vf610-adc.txt | 6 ++ > arch/arm/boot/dts/vfxxx.dtsi | 2 + > drivers/iio/adc/vf610_adc.c| 74 > -- > 3 files changed, 78 insertions(+), 4 deletions(-) The patch set looks fine. Thanks Sanchayan add this new interface for user that is more options for user case. Acked-by: Fugang Duan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Feature request, "create on mount" to create mount point directory on mount, implied remove on unmount
On Mon, Jul 06, 2015 at 12:35:48AM +0100, jon wrote: > > Anyway, the underlying model hasn't changed much since _way_ back; each > > thread of execution is a virtual machine of its own, with actual CPUs > > switched between those. > Ok, not sure I quite follow. What do you mean virtual machine ? > My understanding was that a true VM has a hypervisor and I though also > required some extra processor instructions to basically do an "outer" > context switch (and some memory fiddling to fake up unqique address > spaces) while the operating systems within the VMs own scheduler is > doing the "inner" context switch (IE push/pop all on Intel style CPU). > Not all architectures have any VM capability. > Are you talking about kernels on Intel with SMP enabled only ? Anything timesharing, starting with 7094 running CTSS. Hypervisors allow to virtualize priveleged mode parts of processor; it's a different beast. Each process sees CPU and memory of its own; what the kernel does to give them such an illusion depends upon the system (up to and including full write of registers and user memory to disk, followed by reading that of the next process back from disk - remember where the name "swap" had originally come from?), but no matter how you do that, you give process a virtual CPU of its own and multiplex the actual processor(s) between those. >From the process' point of view system call is just a weird instruction that has rather convoluted side effects. The fact that it actually triggers a trap on the underlying hardware CPU, switches to kernel mode, marshals the arguments, arranges execution environment for C code, executes it, etc. is immaterial - as far as userland code is concerned, the kernel is a black box. For all it cares, there might be another CPU sitting there, with entirely different instruction set and something running on it. With "system call" insn on your CPU raising a signal to attract attention of the priveleged one and stopping itself until the priveleged one tells it to resume. It's considerably older than hypervisors (and both are much older than x86). > > Parts of those virtual machines can be shared - e.g. you can have descriptor > > table not just identical to that of parent at the time of clone(), but > > actually shared with it, so e.g. open() in child makes the resulting > > descriptor > > visible to parent as well. > Ok, I follow you. I often dont need anything more complex than fork(), > when I thread I use pthreads so have not dug around into what is > actually happening at the kernel level. I was not aware that the parent > could see file descriptors created by the child, is this always true or > only true if the parent and child are explicitly a shared memory > process. It is true if and only if clone(2) gets CLONE_FILES in its arguments. Sharing address space is controlled by CLONE_VM and these can be used independently; pthreads set both at the same time, but you can have shared descriptor table without shared memory and vice versa. Most of the time you use shared descriptor tables, you want shared memory as well, but it's not universally true. > Ok, I follow that :-) But logically it must be done with two functions > or handlers or something, so I would assume that my proposed "remove > mount directory" would simply hang off whatever call truly discards the > file system from the kernel. Er... _Which_ mount directory would you have removed (and what's to guarantee that all filesystems it had been mounted on are still alive when the last mount goes away)? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] ARM: dts: mediatek: add 6580 support
> > Change-Id: Ic5c93eb5d1e6e23503dabd28d41c30a7f02e9c18
>
> Please delete the change-id.
> > + uart0: serial@11005000 {
> > + compatible = "mediatek,mt6580-uart",
> > +"mediatek,mt6577-uart";
>
> Please update the dts documentation about the compatible string.
> Apart from that it looks fine for me.
>
I will fix these two and send another patch soon.
Thanks for comments.
> Cheers,
> Matthias
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [[PATCH 2/2] kvm: enable preemption to register/unregister preempt notifier
On 2015/7/3 19:23, Paolo Bonzini wrote:
On 03/07/2015 10:56, Tiejun Chen wrote:
After commit 1cde2930e154 ("sched/preempt: Add static_key() to
preempt_notifiers") is introduced, preempt_notifier_{register, unregister}
always hold a mutex, jump_label_mutex. So in current case this shouldn't
work further under the circumstance of disabled preemption, and its also
safe since we're just handling a per-vcpu stuff with holding vcpu->mutex.
Otherwise, some warning messages are posted like this,
BUG: scheduling while atomic: qemu-system-x86/17177/0x0002
2 locks held by qemu-system-x86/17177:
#0: (>mutex){+.+.+.}, at: [] vcpu_load+0x28/0xf0
[kvm]
#1: (jump_label_mutex){+.+.+.}, at: []
static_key_slow_inc+0xc4/0x140
Modules linked in: x86_pkg_temp_thermal kvm_intel kvm
Preemption disabled at:[] kvm_vcpu_ioctl+0x7e/0xeb0 [kvm]
Thanks for your work Tiejun. However, the original patch is crap. I've
asked to revert it.
Yeah, its better to revert that commit since finally this also trigger a
bug 100671: vmwrite error in vmx_vcpu_run.
Thanks
Tiejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND] xen-netback: remove duplicated function definition
There are two duplicated xenvif_zerocopy_callback() definitions. Remove one of them. Signed-off-by: Liang Li --- drivers/net/xen-netback/common.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h index 8a495b3..c6cb85a 100644 --- a/drivers/net/xen-netback/common.h +++ b/drivers/net/xen-netback/common.h @@ -325,9 +325,6 @@ static inline pending_ring_idx_t nr_pending_reqs(struct xenvif_queue *queue) queue->pending_prod + queue->pending_cons; } -/* Callback from stack when TX packet can be released */ -void xenvif_zerocopy_callback(struct ubuf_info *ubuf, bool zerocopy_success); - irqreturn_t xenvif_interrupt(int irq, void *dev_id); extern bool separate_tx_rx_irq; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm/page_alloc: deferred meminit: replace rwsem with completion
Commit 0e1cc95b4cc7
("mm: meminit: finish initialisation of struct pages before basic setup")
introduced a rwsem to signal completion of the initialization workers.
Lockdep complains about possible recursive locking:
=
[ INFO: possible recursive locking detected ]
4.1.0-12802-g1dc51b8 #3 Not tainted
-
swapper/0/1 is trying to acquire lock:
(pgdat_init_rwsem){.+},
at: [] page_alloc_init_late+0xc7/0xe6
but task is already holding lock:
(pgdat_init_rwsem){.+},
at: [] page_alloc_init_late+0x3e/0xe6
Replace the rwsem by a completion together with an atomic
"outstanding work counter".
Signed-off-by: Nicolai Stange
---
mm/page_alloc.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 506eac8..3886e66 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -18,7 +18,9 @@
#include
#include
#include
-#include
+#include
+#include
+#include
#include
#include
#include
@@ -1062,7 +1064,20 @@ static void __init deferred_free_range(struct page *page,
__free_pages_boot_core(page, pfn, 0);
}
-static __initdata DECLARE_RWSEM(pgdat_init_rwsem);
+/* counter and completion tracking outstanding deferred_init_memmap()
+ threads */
+static atomic_t pgdat_init_n_undone __initdata;
+static __initdata DECLARE_COMPLETION(pgdat_init_all_done_comp);
+
+static inline void __init pgdat_init_report_one_done(void)
+{
+ /* Write barrier is paired with read barrier in
+ page_alloc_init_late(). It makes all writes visible to
+ readers seeing our decrement on pgdat_init_n_undone. */
+ smp_wmb();
+ if (atomic_dec_and_test(_init_n_undone))
+ complete(_init_all_done_comp);
+}
/* Initialise remaining memory on a node */
static int __init deferred_init_memmap(void *data)
@@ -1079,7 +1094,7 @@ static int __init deferred_init_memmap(void *data)
const struct cpumask *cpumask = cpumask_of_node(pgdat->node_id);
if (first_init_pfn == ULONG_MAX) {
- up_read(_init_rwsem);
+ pgdat_init_report_one_done();
return 0;
}
@@ -1179,7 +1194,8 @@ free_range:
pr_info("node %d initialised, %lu pages in %ums\n", nid, nr_pages,
jiffies_to_msecs(jiffies - start));
- up_read(_init_rwsem);
+
+ pgdat_init_report_one_done();
return 0;
}
@@ -1187,14 +1203,18 @@ void __init page_alloc_init_late(void)
{
int nid;
+ /* There will be num_node_state(N_MEMORY) threads */
+ atomic_set(_init_n_undone, num_node_state(N_MEMORY));
for_each_node_state(nid, N_MEMORY) {
- down_read(_init_rwsem);
kthread_run(deferred_init_memmap, NODE_DATA(nid),
"pgdatinit%d", nid);
}
/* Block until all are initialised */
- down_write(_init_rwsem);
- up_write(_init_rwsem);
+ wait_for_completion(_init_all_done_comp);
+
+ /* Paired with write barrier in deferred_init_memmap(),
+ ensures a consistent view of all its writes. */
+ smp_rmb();
}
#endif /* CONFIG_DEFERRED_STRUCT_PAGE_INIT */
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
kernel/sched/core.c
between commit:
2ecd9d29abb1 ("sched, preempt_notifier: separate notifier registration from
static_key inc/dec")
from Linus' tree and commit:
6efde1d3716b ("sched/preempt, kvm: Fix KVM preempt_notifier usage")
from the tip tree.
I fixed it up (maybe - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc kernel/sched/core.c
index 78b4bad10081,850e54b89a11..
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@@ -2338,10 -2326,13 +2338,15 @@@ EXPORT_SYMBOL_GPL(preempt_notifier_dec)
*/
void preempt_notifier_register(struct preempt_notifier *notifier)
{
- static_key_slow_inc(_notifier_key);
+ if (!static_key_false(_notifier_key))
+ WARN(1, "registering preempt_notifier while notifiers
disabled\n");
+
+ /*
+* Avoid preemption while changing the preempt notifier list.
+*/
+ preempt_disable();
hlist_add_head(>link, >preempt_notifiers);
+ preempt_enable();
}
EXPORT_SYMBOL_GPL(preempt_notifier_register);
@@@ -2353,7 -2344,14 +2358,12 @@@
*/
void preempt_notifier_unregister(struct preempt_notifier *notifier)
{
+ /*
+* Avoid preemption while changing the preempt notifier list.
+*/
+ preempt_disable();
hlist_del(>link);
+ preempt_enable();
-
- static_key_slow_dec(_notifier_key);
}
EXPORT_SYMBOL_GPL(preempt_notifier_unregister);
pgpndyfYs0C4c.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/1] suspend: delete sys_sync()
On Sat, Jul 04, 2015 at 03:03:46AM +0200, Rafael J. Wysocki wrote: > On Friday, July 03, 2015 11:42:50 AM Dave Chinner wrote: > > On Wed, Jul 01, 2015 at 11:07:29PM -0400, Len Brown wrote: > > > >> The _vast_ majority of systems using Linux suspend today are under > > > >> an Android user-space. Android has no assumption that that suspend to > > > >> mem will necessarily stay suspended for a long time. > > > > > > > > Indeed, however your change was not android-specific, and it is not > > > > "comfortable" on x86-style hardware and usage patterns. > > > > > > "comfortable on x86-style and usage patterns"? > > > If you mean "traditional" instead of "comfortable", > > > where "tradition" is based on 10-year old systems, then sure. > > > > Even if this were true(*) we don't break things that currently work > > just because something different is "just around the corner". e.g. > > if you shut the lid on your laptop and it suspends to RAM, you can > > pull the USB drive out that you just copied stuff to and plug it > > into another machine and find all the data you copied there is > > present. > > > > Remove the sync() from the freeze code, and this isn't guaranteed to > > work anymore. It is now dependent on userspace implementations for > > this to work, and we know what userspace developers will choose in > > this situation. i.e. fast and "works for me", not "safe for > > everyone". > > > > (*) Which it clearly isn't true because, as this example shows, my > > shiny new laptop still has exactly the same data integrity > > requirements as the laptop I was using 10 years ago. > > > > Just because there are lots of Android or Chrome out there it > > doesn't mean we can just ignore the requirements of everything > > else... > > > > > > That said, as long as x86 will still try to safeguard my data during mem > > > > sleep/resume as it does today, I have no strong feelings about > > > > light/heavy-weight "mem" sleep being strictly a compile-time selectable > > > > thing, or a more flexible runtime-selectable behavior. > > > > > > The observation here is that the kernel should not force every system > > > to sys_sync() on every suspend. The only question is how to best > > > implement that. > > > > No, your observation was that "sync is slow". Your *solution* is "we > > need to remove sync". > > Not only slow, but pointless too. The argument goes: "It is slow and > pointless and so it may be dropped." > > Now, I can agree that it wasn't clearly demonstrated that the unconditional > sys_sync() in the suspend code path was pointless, but it also has never > been clearly shown why it is not pointless on systems that suspend and resume > reliably. I just gave you an example of why sync is needed: Suspend, pull out USB drive when putting laptop in bag. > [The argument that the user can pull removable storage devices out of the > system while suspended doesn't hold any water to me, because the user can > pull them out of the system when not suspended just as well and cause the > same kind of damage to happen.] How many times have you forgotten to pull a usb stick out of a laptop before putting it away? I've done that several times in the past few months, and so I've *personally* pulled the USB sticks out of suspended machines. This is a *common occurrence* and it currently works just fine, so changing sync behaviour is something that will directly impact me *as a user*. Not to mention hybrid suspend (i.e write suspend image to disk, then suspend to RAM for fast resume, but if power is lost resume from disk image) both images have exactly the same filesystem state in them and that is an absolute requirement for a hybrid suspend... > Moreover, question is if we really need to carry out the sync on *every* > suspend even if it is not pointless overall. That shouldn't really be > necessary if we suspend and resume often enough or if we resume only for > a while and then suspend again. Maybe it should be rate limited somehow > at least? If you suspend and resume frequently, then the cost of the sync shoul dbe negliable because the amount of data dirtied between resume/suspend shoul dbe negliable. hence my questions about where sync is spending too much time, and whether we've actually fixed those problems or not. If sync speed on clean filesystems is a problem then we need to fix sync, not work around it. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
recent kernel - multiboot elf
Hi, I have to load linux from a multiboot boot loader. The last work I saw in this regard is a patch for 2.4.14. Does anyone have a current proof of concept multiboot patch? if not, what are the steps involved to make a bootable multiboot elf kernel? Is there any way I can get the final file size inside of header.S? Where would the multiboot entry be? Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Feature request, "create on mount" to create mount point directory on mount, implied remove on unmount
On Sun, 2015-07-05 at 18:39 +0100, Al Viro wrote: > On Sun, Jul 05, 2015 at 04:46:50PM +0100, jon wrote: > > > I should have titled it "Feature request from a simple minded user" > > > > I have not the slightest idea what you are talking about. > > > > When I learnt *nix it did not have "name spaces" in reference to process > > tables. I understand the theory of VM a bit, the model in my mind each > > "machine", be that one kernel on a true processor or a VM instance has > > "a process table" and "a file descriptor table" etc - anything more is > > beyond my current level of knowledge. > > File descriptor table isn't something system-wide - it belongs to a process... Ok, true... I guess it is not DOS or CP/M ;-) > > Containers are basically glorified process groups. > > Anyway, the underlying model hasn't changed much since _way_ back; each > thread of execution is a virtual machine of its own, with actual CPUs > switched between those. Ok, not sure I quite follow. What do you mean virtual machine ? My understanding was that a true VM has a hypervisor and I though also required some extra processor instructions to basically do an "outer" context switch (and some memory fiddling to fake up unqique address spaces) while the operating systems within the VMs own scheduler is doing the "inner" context switch (IE push/pop all on Intel style CPU). Not all architectures have any VM capability. Are you talking about kernels on Intel with SMP enabled only ? > Each of them has memory, ports (== file descriptors) > and traps (== signal handlers). The main primitives are > clone() (== rfork() in other branches; plain fork() is just the most > common case) - create a copy of the virtual machine, in the state identical > to that of caller with the exception of different return values given to > child and parent. > exit() - terminate the virtual machine > execve() - load a new program Ok, I think I follow that. > Parts of those virtual machines can be shared - e.g. you can have descriptor > table not just identical to that of parent at the time of clone(), but > actually shared with it, so e.g. open() in child makes the resulting > descriptor > visible to parent as well. Ok, I follow you. I often dont need anything more complex than fork(), when I thread I use pthreads so have not dug around into what is actually happening at the kernel level. I was not aware that the parent could see file descriptors created by the child, is this always true or only true if the parent and child are explicitly a shared memory process. > Or you can have memory (address space) shared, > so that something like mmap() in parent would affect the memory mappings of > child, etc. Which components are to be shared and which - copied is selected > by clone() argument. OK. I have used that to create parent child processes with shared memory, but I did cut the initial code from a googled example rather an apply any true skill ;-) > unshare() allows to switch to using a private copy of chosen components > - e.g. you might say "from now on, I want my file descriptor table to be > private". In e.g. Plan 9 that's expressed via rfork() as well. unshare() is new to me but I see the logic. > Less obvious componets including current directory and root. Normally, these > are not shared; chdir() done in child won't affect the parent and vice versa. > You could ask them to be shared, though - for multithreaded program it could > be convenient. OK. > > Different processes might see different parts of the mount tree since v7 had > introduced chroot(2). Namespaces simply allow to have a *forest* - different > groups of processes seeing different mount trees in that forest. The same > filesystem may be mounted in many places, and the same directory might be > a mountpoint in an instance visible to one process and not a mountpoint > in an instance visible to another (or a mountpoint with something entirely > different mounted in an instance visible to somebody else). Ok, I follow that. I have used chroot but only very sparingly, I have never used a machine (to my knowledge) with the same file system mounted onto multiple mount points so I had not considered that. > Mount tree is yet another component; the difference is that normally it *is* > shared on clone(), rather than being copied. I.e. mount() done by child > affects the mount tree visible to parent. But you still can ask for > a new private copy of mount tree via clone() or unshare(). When the > last process sharing that mount tree exits, it gets dissolved, same as > every file descriptor in a descriptor table gets closed when the last > thread sharing that descriptor table exits (or asks for unshared copy of > descriptor table, e.g. as a side effect of execve()). Just as with > file descriptors close() does not necessary close the opened file > descriptor's connected to (that happens only when all descriptors connected > to given opened file
linux-next: build failure after merge of the device-mapper tree
Hi all,
After merging the device-mapper tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/md/dm-thin.c: In function '__pool_destroy':
drivers/md/dm-thin.c:2780:2: error: implicit declaration of function 'vfree'
[-Werror=implicit-function-declaration]
vfree(pool->cell_sort_array);
^
drivers/md/dm-thin.c: In function 'pool_create':
drivers/md/dm-thin.c:2893:2: error: implicit declaration of function 'vmalloc'
[-Werror=implicit-function-declaration]
pool->cell_sort_array = vmalloc(sizeof(*pool->cell_sort_array) *
CELL_SORT_ARRAY_SIZE);
^
drivers/md/dm-thin.c:2893:24: warning: assignment makes pointer from integer
without a cast
pool->cell_sort_array = vmalloc(sizeof(*pool->cell_sort_array) *
CELL_SORT_ARRAY_SIZE);
^
Caused by commit
94212d3b6054 ("dm thin: allocate the cell_sort_array dynamically")
Forgot to include vmalloc.h
I have used the device-mapper from next-20150703 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpqni3a_DHx9.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/2] ACPI: memhotplug.c: Fixed flying pointer issue. Coding style issue.
On Sunday, July 05, 2015 07:37:27 PM Daniel Machon wrote: > Fixed coding style issue. > > Signed-off-by: Daniel Machon So had I though that these things were worth "fixing", I'd have done it myself already. I'm not going to apply patches like this one unless you can explain to me what *real* problems you're fixing. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] PM / Runtime: Add pm_runtime_enable_recursive
On Saturday, July 04, 2015 10:37:55 AM Alan Stern wrote: > On Sat, 4 Jul 2015, Rafael J. Wysocki wrote: > > > > >> > Perhaps the pm_runtime_suspended_if_enabled() test should be changed > > > >> > to > > > >> > pm_runtime_status_suspended(). Then it won't matter whether the > > > >> > descendant devices are enabled for runtime PM. > > > >> > > > >> Yeah, that would remove the need for messing with the runtime PM > > > >> enable status of descendant devices, but I wonder why Rafael went that > > > >> way initially. > > > > > > > > I forget the details. Probably it was just to be safe. We probably > > > > thought that if a device was disabled for runtime PM then its runtime > > > > PM status might not be accurate. But if direct_complete is set then it > > > > may be reasonable to assume that the runtime PM status _is_ accurate. > > > > > > Cool. > > > > We're walking a grey area here. What exactly does power.direct_complete > > mean > > for devices whose runtime PM is disabled? > > > > Let's see what Rafael thinks about these two issues. It seems to me > > > that the hardest part is dealing with drivers/subsystems that have no > > > runtime PM support. In such cases, we have to be very careful not to > > > use direct_complete unless we know that the device does no power > > > management at all. > > > > Precisely. > > All right, we can make a decision and document it. The following seems > reasonable to me: > > If dev->power.direct_complete is set then the PM core will > assume that dev->power.rpm_status is accurate even when > dev->power.disable_depth > 0. The core will obey the > .direct_complete setting regardless of .disable_depth. > > As a consequence, devices that support system sleep but don't > support runtime PM must _never_ have .direct_complete set. > > On the other hand, if a device (such as a "virtual" device) > requires no callbacks for either system sleep or runtime PM, > then there is no harm in setting .direct_complete. Indeed, > doing so may help speed up an ancestor device's sleep > transition. > > How does that sound? It would be workable I think, but I'd prefer the core to be told directly about devices whose runtime PM status doesn't matter (because nothing changes between "suspended" and "active"), so they may be treated in a special way safely. If we had that information, no special rules other than "that is a device whose runtime PM status doesn't matter, so treat it accordingly" would be necessary. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 4.2-rc1
On Sun, Jul 05, 2015 at 01:22:48PM -0700, Linus Torvalds wrote: > It's Sunday, two weeks have passed, and the merge window is closed. I > just pushed out the tag to the git trees, and tar-balls and patches > should be mirroring out too. > Testing doesn't look bad for -rc1. Build results: total: 130 pass: 125 fail: 5 Failed builds: alpha:allmodconfig m68k:allmodconfig mips:allmodconfig powerpc:allmodconfig s390:allmodconfig Qemu tests: total: 31 pass: 31 fail: 0 There are more new allmodconfig (and probably allyesconfig) build errors, but those all boil down to two problems, and patches are available for both. staging: make board support depend on OF_IRQ and CLKDEV_LOOKUP [1] by Paul Gortmaker staging:lustre: remove irq.h from socklnd.h [2] by James Simmons Both patches should be in Greg's patch queue. Guenter --- [1] https://lkml.org/lkml/2015/6/20/215 [2] https://lkml.org/lkml/2015/6/25/621 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] suspend: delete sys_sync()
On Saturday, July 04, 2015 10:19:55 AM Alan Stern wrote: > On Sat, 4 Jul 2015, Rafael J. Wysocki wrote: > > > The only argument against dropping sys_sync() from the suspend code path > > I've seen in this thread that I entirely agree with is that it may lead to > > regressions, because we've done it practically forever and it may hide > > latent > > bugs somewhere in block drivers etc. Dropping it, though, is the only way > > to see those bugs, if any, and if we want to ever fix them, we need to see > > them. That's why I think that it may be a good idea to allow people to > > drop it if they are willing to accept some extra risk (via the kernel > > command line, for example). > > I'd be perfectly happy to have the sync selectable at runtime, one way > or another. The three most reasonable options seem to be: > > kernel command line > > sysfs file > > sysctl setting > > The command line is less flexible (it can't be changed after booting). > Either of the other two would be fine with me. We'll probably use a sysfs file (possibly plus a Kconfig option to set the boot time default). > > Moreover, question is if we really need to carry out the sync on *every* > > suspend even if it is not pointless overall. That shouldn't really be > > necessary if we suspend and resume often enough or if we resume only for > > a while and then suspend again. Maybe it should be rate limited somehow > > at least? > > For example, skip the sync if the system has been awake for < 100 ms? Yes, something like that. > The cutoff time could also be controlled by the sysfs file: -1 => > never sync, 0 => always sync, > 0 => sync if the system has been awake > longer than the value. That sounds like a good idea to me. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] suspend: delete sys_sync()
On Saturday, July 04, 2015 10:50:36 AM Geert Uytterhoeven wrote: > On Sat, Jul 4, 2015 at 3:03 AM, Rafael J. Wysocki wrote: > > [The argument that the user can pull removable storage devices out of the > > system while suspended doesn't hold any water to me, because the user can > > pull them out of the system when not suspended just as well and cause the > > same kind of damage to happen.] > > The user may not notice the difference between a suspended and powered > off machine, and thus think it's safe to unplug the USB memory stick while > the machine appears off. > > If that's considered a valid use case, this would be a regression. Well, if user space configures the system to use suspend as a "power off flavor" and doesn't even try to ensure the filesystems to be synced before suspending (in that mode), that's on the edge of insanity. And it falls into the "latent bugs that may be there because we've always synced before suspending" category in my view. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: board: Kconfig: Let STAGING_BOARD depend on CLKDEV_LOOKUP
Hi all, On Sun, 5 Jul 2015 18:57:51 +0200 Geert Uytterhoeven wrote: > > On Sat, Jul 4, 2015 at 11:35 PM, Chen Gang > wrote: > > It needs clk_add_alias() from clk drivers, which is implemented in > > "drivers/clk/clkdev.c" which depends on CLKDEV_LOOKUP. > > > > Normally, archs and clk driver its own will decide whether select > > CLKDEV_LOOKUP, and common drivers will decide whether depend on it. > > > > The related error (with allmodconfig under cris for next-20150702): > > > > drivers/built-in.o: In function `board_staging_register_clock': > > drivers/staging/board/board.c:131: undefined reference to `clk_add_alias' > > > > > > Signed-off-by: Chen Gang > > Fix available for the last 15 days: > > https://lkml.org/lkml/2015/6/20/215 I added Chen's patch to my fixes tree today (only because I couldn't easily find a copy of Paul's patch (sorry Paul) i.e. how does one get a full mail message from lkml.org? Or Geert, maybe that is not the best place to link to. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp3K7rM0mCJJ.pgp Description: OpenPGP digital signature
[GIT PULL] ext4 bug fixes for 4.2-rc2
The following changes since commit a2fd66d069d86d793e9d39d4079b96f46d13f237: ext4: set lazytime on remount if MS_LAZYTIME is set by mount (2015-06-23 11:03:54 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus_stable for you to fetch changes up to 7444a072c387a93ebee7066e8aee776954ab0e41: ext4: replace open coded nofail allocation in ext4_free_blocks() (2015-07-05 12:33:44 -0400) Bug fixes (all for stable kernels) for ext4: * address corner cases for indirect blocks->extent migration * fix reserved block accounting invalidate_page when page_size != block_size (i.e., ppc or 1k block size file systems) * fix deadlocks when a memcg is under heavy memory pressure * fix fencepost error in lazytime optimization Eryu Guan (2): ext4: be more strict when migrating to non-extent based file ext4: correctly migrate a file with a hole at the beginning Lukas Czerner (1): ext4: fix reservation release on invalidatepage for delalloc fs Michal Hocko (1): ext4: replace open coded nofail allocation in ext4_free_blocks() Nikolay Borisov (2): bufferhead: Add _gfp version for sb_getblk() ext4: avoid deadlocks in the writeback path by using sb_getblk_gfp Theodore Ts'o (1): ext4: fix fencepost error in lazytime optimization fs/ext4/extents.c | 6 +++--- fs/ext4/inode.c | 22 ++ fs/ext4/mballoc.c | 16 +--- fs/ext4/migrate.c | 17 ++--- include/linux/buffer_head.h | 7 +++ 5 files changed, 47 insertions(+), 21 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/2] at91: make using irqs for clock handling optional
On Fri, 3 Jul 2015, David Dueck wrote: > Deactivating the use of interrupts here fixes a crash on early boot with > RT-Preempt. Again, you completely fail to explain WHAT the problem is and WHY you think that your patch is a proper solution. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] at91: use request_irq/free_irq instead of setup_irq/remove_irq
On Fri, 3 Jul 2015, David Dueck wrote: > This fixes a warning when using RT-Preempt. That's not a proper explanation for the patch and by all means it cannot fix anything because free_irq() is just a different wrapper around __free_irq() than remove_irq(). So how on earth fixes that the problem at hand? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] trace/events: add chip name and hwirq to irq entry tracepoint
On Wed, 24 Jun 2015, Steven Rostedt wrote: > > + > > +#define show_chip_name(irq)\ > > + (irq_get_irq_data(irq) \ > > +? irq_get_irq_data(irq)->chip->name\ > > +: "NULL") > > + > > +#define show_hwirq(irq)\ > > + (irq_get_irq_data(irq) \ > > +? irq_get_irq_data(irq)->hwirq \ > > +: -ENODEV) > > Note these magic functions will only be useful for the tracefs reads of > the trace files. Userspace tools that extract the data (like perf and > trace-cmd), will have no idea of how to parse it. > > I'm not against doing this, but I'm just letting you know what the > effect of this change will be. What's worse is, that they are racy against a concurrent teardown of the interrupt. Not a good idea ... Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kernel coding style: prefer array to [0] ?
Anotherpattern that occurred to me is, eg info->MS_Status = *(struct MS_STATUS *)[0]; where buf is an array. I find this in 11 files. julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ext4: replace open coded nofail allocation
On Tue, Jun 23, 2015 at 11:50:37AM +0200, Michal Hocko wrote: > ext4_free_blocks is looping around the allocation request and mimics > __GFP_NOFAIL behavior without any allocation fallback strategy. Let's > remove the open coded loop and replace it with __GFP_NOFAIL. Without > the flag the allocator has no way to find out never-fail requirement > and cannot help in any way. > > Signed-off-by: Michal Hocko Thanks, applied. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] tick/broadcast: Prevent deep idle states if no broadcast device available
If no broadcast device is installed and the cpu local timers stop in
deeper idle states, then there is currently nothing telling the idle
code that it should not go into deep idle states, so the timers stop
and nothing wakes up the cpus.
Make the broadcast_enter/exit() functions independent of the
configuration options and always check on enter:
- whether the cpu local device is affected by idle states
- whether a broadcast device is available
This covers all possible config combinations including
CONFIG_BROADCAST=n.
Reported-by: Sudeep Holla
Signed-off-by: Thomas Gleixner
Cc: Suzuki Poulose
Cc: Lorenzo Pieralisi
Cc: Catalin Marinas
Cc: Rafael J. Wysocki
---
include/linux/tick.h |4 -
kernel/time/tick-broadcast.c | 97 +--
kernel/time/tick-common.c| 21 +
kernel/time/tick-sched.h | 10
4 files changed, 88 insertions(+), 44 deletions(-)
Index: tip/include/linux/tick.h
===
--- tip.orig/include/linux/tick.h
+++ tip/include/linux/tick.h
@@ -63,11 +63,7 @@ extern void tick_broadcast_control(enum
static inline void tick_broadcast_control(enum tick_broadcast_mode mode) { }
#endif /* BROADCAST */
-#if defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST) &&
defined(CONFIG_TICK_ONESHOT)
extern int tick_broadcast_oneshot_control(enum tick_broadcast_state state);
-#else
-static inline int tick_broadcast_oneshot_control(enum tick_broadcast_state
state) { return 0; }
-#endif
static inline void tick_broadcast_enable(void)
{
Index: tip/kernel/time/tick-broadcast.c
===
--- tip.orig/kernel/time/tick-broadcast.c
+++ tip/kernel/time/tick-broadcast.c
@@ -359,7 +359,14 @@ void tick_broadcast_control(enum tick_br
case TICK_BROADCAST_ON:
cpumask_set_cpu(cpu, tick_broadcast_on);
if (!cpumask_test_and_set_cpu(cpu, tick_broadcast_mask)) {
- if (tick_broadcast_device.mode ==
+ /*
+* Only shutdown the cpu local device, if the
+* broadcast device exists and is in periodic
+* mode. The latter check prevents a hickup
+* during the switch from periodic to oneshot
+* mode.
+*/
+ if (bc != NULL && tick_broadcast_device.mode ==
TICKDEV_MODE_PERIODIC)
clockevents_shutdown(dev);
}
@@ -662,46 +669,43 @@ static void broadcast_shutdown_local(str
clockevents_switch_state(dev, CLOCK_EVT_STATE_SHUTDOWN);
}
-/**
- * tick_broadcast_oneshot_control - Enter/exit broadcast oneshot mode
- * @state: The target state (enter/exit)
- *
- * The system enters/leaves a state, where affected devices might stop
- * Returns 0 on success, -EBUSY if the cpu is used to broadcast wakeups.
- *
- * Called with interrupts disabled, so clockevents_lock is not
- * required here because the local clock event device cannot go away
- * under us.
- */
-int tick_broadcast_oneshot_control(enum tick_broadcast_state state)
+int __tick_broadcast_oneshot_control(enum tick_broadcast_state state)
{
struct clock_event_device *bc, *dev;
- struct tick_device *td;
int cpu, ret = 0;
ktime_t now;
/*
-* Periodic mode does not care about the enter/exit of power
-* states
+* If there is no broadcast device, tell the caller not to go
+* into deep idle.
*/
- if (tick_broadcast_device.mode == TICKDEV_MODE_PERIODIC)
- return 0;
-
- /*
-* We are called with preemtion disabled from the depth of the
-* idle code, so we can't be moved away.
-*/
- td = this_cpu_ptr(_cpu_device);
- dev = td->evtdev;
+ if (!tick_broadcast_device.evtdev)
+ return -EBUSY;
- if (!(dev->features & CLOCK_EVT_FEAT_C3STOP))
- return 0;
+ dev = this_cpu_ptr(_cpu_device)->evtdev;
raw_spin_lock(_broadcast_lock);
bc = tick_broadcast_device.evtdev;
cpu = smp_processor_id();
if (state == TICK_BROADCAST_ENTER) {
+ /*
+* If the current CPU owns the hrtimer broadcast
+* mechanism, it cannot go deep idle and we do not add
+* the CPU to the broadcast mask. We don't have to go
+* through the EXIT path as the local timer is not
+* shutdown.
+*/
+ ret = broadcast_needs_cpu(bc, cpu);
+
+ /*
+* If the hrtimer broadcast check tells us that the
+* cpu cannot go deep idle, or if the broadcast device
+* is in periodic mode, we just return.
+*/
+ if (ret ||
[patch 0/2] tic/broadcast: Plug a few corner cases which cause malfunction
The following two patches address shortcomings in the tick broadcast code, which were reported and analyzed by Sudeep Holla and Andriy Gapon. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/2] tick/broadcast: Handle spurious interrupts gracefully
Andriy reported that on a virtual machine the warning about negative
expiry time in the clock events programming code triggered:
hpet: hpet0 irq 40 for MSI
hpet: hpet1 irq 41 for MSI
Switching to clocksource hpet
WARNING: at kernel/time/clockevents.c:239
[] clockevents_program_event+0xdb/0xf0
[] tick_handle_periodic_broadcast+0x41/0x50
[] timer_interrupt+0x15/0x20
When the second hpet is installed as a per cpu timer the broadcast
event is not longer required and stopped, which sets the next_evt of
the broadcast device to KTIME_MAX.
If after that a spurious interrupt happens on the broadcast device,
then the current code blindly handles it and tries to reprogram the
broadcast device afterwards, which adds the period to
next_evt. KTIME_MAX + period results in a negative expiry value
causing the WARN_ON in the clockevents code to trigger.
Add a proper check for the state of the broadcast device into the
interrupt handler and return if the interrupt is spurious.
Reported-by: Andriy Gapon
Signed-off-by: Thomas Gleixner
---
kernel/time/tick-broadcast.c |7 +++
1 file changed, 7 insertions(+)
Index: tip/kernel/time/tick-broadcast.c
===
--- tip.orig/kernel/time/tick-broadcast.c
+++ tip/kernel/time/tick-broadcast.c
@@ -301,6 +301,13 @@ static void tick_handle_periodic_broadca
bool bc_local;
raw_spin_lock(_broadcast_lock);
+
+ /* Handle spurious interrupts gracefully */
+ if (clockevent_state_shutdown(_broadcast_device.evtdev)) {
+ raw_spin_unlock(_broadcast_lock);
+ return;
+ }
+
bc_local = tick_do_periodic_broadcast();
if (clockevent_state_oneshot(dev)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] GPU-DRM-IMX: Delete an unnecessary check before drm_fbdev_cma_restore_mode()
From: Markus Elfring Date: Sun, 5 Jul 2015 22:45:23 +0200 The drm_fbdev_cma_restore_mode() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/gpu/drm/imx/imx-drm-core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c index 74f505b..9172c0e 100644 --- a/drivers/gpu/drm/imx/imx-drm-core.c +++ b/drivers/gpu/drm/imx/imx-drm-core.c @@ -63,8 +63,7 @@ static void imx_drm_driver_lastclose(struct drm_device *drm) #if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER) struct imx_drm_device *imxdrm = drm->dev_private; - if (imxdrm->fbhelper) - drm_fbdev_cma_restore_mode(imxdrm->fbhelper); + drm_fbdev_cma_restore_mode(imxdrm->fbhelper); #endif } -- 2.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 4.2-rc1
It's Sunday, two weeks have passed, and the merge window is closed. I just pushed out the tag to the git trees, and tar-balls and patches should be mirroring out too. I thought this release would be one of the biggest ones ever, but it turns out that it will depend on how you count. Just counting pure commits, it is indeed one of the bigger rc1's in recent history, but 3.10-rc1 was almost as big, and then the final 3.10 grew from that more than most. I doubt we'll match the 3.10 release, since we have been getting progressively better at *not* merging tons of stuff after -rc1. And it turns out v3.15-rc1 had more commits than 4.2-rc1 does (by a hair), so even there this isn't the biggest rc1 ever, if you count the number of commits. But it's certainly up there with the best of them. It's much too big to post the shortlog, so as usual for rc1, appended is just my "mergelog", with the people who are credited being the people I merge from, which is usually not necessarily at all the same thing as the people who actually authored the code. You'll need to go look at the details in the git tree for that. However, if you count the size in pure number of lines changed, this really seems to be the biggest rc we've ever had, with over a million lines added (and about a quarter million removed). That beats the previous champion (3.11-rc1) that was huge mainly due to Lustre being added to the staging tree. The reason for that huge number of lines is largely a single source: the bulk of this by far is from the new amd gpu register description headers. In fact, just those register descriptor headers alone are about 41% of the entire patch. The rest of the new amdgpu driver itself is another 8% of the total, so we're in the somewhat odd situation where a single driver is about half of the whole rc1 in number of lines. Aside from that unusual anomaly, the rest looks fairly normal - mainly drivers and architecture updates. The Renesas H8/300 architecture came back in a newly cleaned-up form, so we have some new(ish) architecture support, but that's tiny and the bulk is ARM (with x86 a distant second). Interestingly, there was quite a bit of low-level x86 changes: both source code re-organization for x86 entry code and lots of FPU handling cleanups. That's fairly unusual, with low-level x86 code being fairly stable and seldom seeing those kinds of big changes. Outside of the "drivers and architectures", there's a fair amount of filesystem stuff, including some fundamental changes and cleanups to symlink handling by Al. And all the usual updates to various filesystems, networking, crypto, tools, testing, you name it. Linus --- Al Viro (2): vfs updates more vfs updates Alex Deucher (1): radeon and amdgpu fixes Alex Williamson (1): VFIO updates Alexandre Belloni (1): RTC updates Andrew Morton (3): first patchbomb second patchbomb third patchbomb Bjorn Helgaas (1): PCI updates Bob Peterson (1): GFS2 updates Borislav Petkov (2): EDAC updates EDAC fix Brian Norris (1): MTD updates Bruce Fields (1): nfsd updates Bryan Wu (1): LED subsystem updates Catalin Marinas (2): arm64 updates arm64 fixes (and cleanups) Chris Mason (1): btrfs updates Chris Metcalf (1): arch/tile updates Dan Williams (1): libnvdimm subsystem Daniel Vetter (1): drm EDID fix Darren Hart (2): x86 platform driver updates late x86 platform driver updates Dave Airlie (1): drm updates David Miller (3): networking updates sparc fixes networking fixes David Vrabel (1): xen updates Dmitry Torokhov (2): input subsystem updates second round of input updates Dominik Brodowski (1): PCMCIA update Doug Ledford (1): rdma updates Eric Biederman (1): user namespace updates Geert Uytterhoeven (1): m68k update Grant Likely (1): devicetree updates Greg KH (5): char/misc driver updates driver core updates staging driver updates tty/serial driver updates USB updates Greg Ungerer (1): m68knommu updates Guenter Roeck (2): hwmon updates hwmon fixes Herbert Xu (3): crypto update crypto fixes crypto fixes Ingo Molnar (17): RCU updates locking updates perf updates perf fixes scheduler updates x86 cleanups x86 CPU features x86 debugging documentation updates x86 EFI updates x86 FPU updates x86 kdump updates x86 warning fixlet x86 core updates max log buf size increase perf updates scheduler fixes x86 fixes Jaegeuk Kim (1): f2fs updates James Bottomley (1): SCSI updates James Morris (1): security subsystem updates Jan Kara (1): UDF fixes and cleanups Jani Nikula (1): intel drm fixes Jassi Brar (1): mailbox updates Jean Delvare (2): DMI updates more hwmon updates Jens Axboe (6): core block IO update block driver updates asm/scatterlist.h removal cgroup writeback support more block layer patches block fixes Jiri Kosina (3): HID updates livepatching fixes trivial tree
[PATCH] x86: Fix detection of GCC -mpreferred-stack-boundary support
As per https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383, GCC only
allows -mpreferred-stack-boundary=3 on x86_64 if -mno-sse is set.
That means that cc-option will not detect
-mpreferred-stack-boundary=3 support, because we test for it before
setting -mno-sse.
Fix it by reordering the Makefile bits.
Compile-tested only. This should help avoid code generation issues
such as the one that was worked around in b96fecbfa8c8 ("x86/fpu:
Fix boot crash in the early FPU code").
I'm a bit concerned that we could still have problems on older GCC
versions given that our asm code does not respect GCC's idea of the
ABI-required stack alignment.
Cc: Linus Torvalds
Cc: Jan Kara
Cc: Ingo Molnar
Cc: Borislav Petkov
Signed-off-by: Andy Lutomirski
---
arch/x86/Makefile | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 118e6debc483..344dd2110b2a 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -39,6 +39,12 @@ ifdef CONFIG_X86_NEED_RELOCS
LDFLAGS_vmlinux := --emit-relocs
endif
+# prevent gcc from generating any FP code by mistake
+# This must be before we try -mpreferred-stack-boundary -- see
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
+KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
+KBUILD_CFLAGS += $(call cc-option,-mno-avx,)
+
ifeq ($(CONFIG_X86_32),y)
BITS := 32
UTS_MACHINE := i386
@@ -167,9 +173,6 @@ KBUILD_CFLAGS += -pipe
KBUILD_CFLAGS += -Wno-sign-compare
#
KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
-# prevent gcc from generating any FP code by mistake
-KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
-KBUILD_CFLAGS += $(call cc-option,-mno-avx,)
KBUILD_CFLAGS += $(mflags-y)
KBUILD_AFLAGS += $(mflags-y)
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Non-booting current Linus' tree
On 07/03/2015 02:40 PM, Linus Torvalds wrote: > On Fri, Jul 3, 2015 at 8:23 AM, Jan Kara wrote: >> >> Because the address isn't 32-byte aligned (which I assume is the >> requirement from looking into the code). So clearly my gcc messed up and >> miscompiled the thing by ignoring the alignment attribute. > > Well, it's probably a mistake to begin with to expect gcc to get stack > alignment right. Especially since we tell gcc to not align the stack > as much as it usually wants to with -mpreferred-stack-boundary=2. > Are you sure? The 64-bit part of arch/x86/Makefile contains: # Use -mpreferred-stack-boundary=3 if supported. KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=3) but make V=1 isn't showing -mpreferred-stack-boundary=3. This may be because: error: -mpreferred-stack-boundary=3 is not between 4 and 12 extern int bar(const char *); ^ I found: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 and, indeed, -mno-sse -mpreferred-stack-boundary=3 is accepted. This make me think that the makefile is broken -- cc-option isn't working because it doesn't check -mpreferred-stack-boundary in conjunction with -mno-sse. Given that -mpreferred-stack-boundary=3 doesn't appear to being set, I think this is really our bug: our asm code makes no effort to align the stack to a 16-byte boundary as required by the ABI, and we're not overriding the ABI correctly. I'll send a patch for the Makefile issue. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] GPU-DRM: Delete an unnecessary check before drm_property_unreference_blob()
From: Markus Elfring Date: Sun, 5 Jul 2015 21:55:10 +0200 The drm_property_unreference_blob() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/gpu/drm/drm_crtc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 2d57fc5..6e4c8b0 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -4469,9 +4469,7 @@ static int drm_property_replace_global_blob(struct drm_device *dev, goto err_created; } - if (old_blob) - drm_property_unreference_blob(old_blob); - + drm_property_unreference_blob(old_blob); *replace = new_blob; return 0; -- 2.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen-netback: remove duplicated function definition
On Sat, Jul 04, 2015 at 03:33:00AM +0800, Liang Li wrote: > There are two duplicated xenvif_zerocopy_callback() definitions. > Remove one of them. > > Signed-off-by: Liang Li Acked-by: Wei Liu Please fix the time of your computer and resend. Wei. > --- > drivers/net/xen-netback/common.h | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/net/xen-netback/common.h > b/drivers/net/xen-netback/common.h > index 8a495b3..c6cb85a 100644 > --- a/drivers/net/xen-netback/common.h > +++ b/drivers/net/xen-netback/common.h > @@ -325,9 +325,6 @@ static inline pending_ring_idx_t nr_pending_reqs(struct > xenvif_queue *queue) > queue->pending_prod + queue->pending_cons; > } > > -/* Callback from stack when TX packet can be released */ > -void xenvif_zerocopy_callback(struct ubuf_info *ubuf, bool zerocopy_success); > - > irqreturn_t xenvif_interrupt(int irq, void *dev_id); > > extern bool separate_tx_rx_irq; > -- > 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] KVM: arm/arm64: gsi routing support
On Mon, Jun 29, 2015 at 05:37:10PM +0200, Eric Auger wrote: > With the advent of GICv3 ITS in-kernel emulation, KVM GSI routing > appears to be requested. More specifically MSI routing is needed. > irqchip routing does not sound to be really useful on arm but usage of > MSI routing also mandates to integrate irqchip routing. The initial > implementation of irqfd on arm must be upgraded with the integration > of kvm irqchip.c code and the implementation of its standard hooks > in the architecture specific part. > > In case KVM_SET_GSI_ROUTING ioctl is not called, a default routing > table with flat irqchip routing entries is built enabling to inject gsi > corresponding to the SPI indexes seen by the guest. > > As soon as KVM_SET_GSI_ROUTING is called, user-space overwrites this > default routing table and is responsible for building the whole routing > table. > > for arm/arm64 KVM_SET_GSI_ROUTING has a limited support: > - only applies to KVM_IRQFD and not to KVM_IRQ_LINE > > - irqchip routing was tested on Calxeda midway (VFIO with irqfd) > - MSI routing without GICv3 ITS was tested using APM Xgene-I > (qemu VIRTIO-PCI vhost net without gsi_direct_mapping). > - MSI routing with GICv2 ITS is NOT yet tested. Do you mean GICv3 ITS here? > > Code can be found at > https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.1-gsi-routing-patch > > It applies on Andre's [PATCH 00/13] arm64: KVM: GICv3 ITS emulation > (http://www.spinics.net/lists/kvm/msg117402.html) > > History: > > RFC -> PATCH: > - clearly state limited support on arm/arm64: > KVM_IRQ_LINE not impacted by GSI routing > - add default routing table feature (new patch file) > - changed uapi to use padding field area > - reword api.txt > > > Eric Auger (7): > KVM: api: add kvm_irq_routing_extended_msi > KVM: kvm_host: add kvm_extended_msi > KVM: irqchip: convey devid to kvm_set_msi > KVM: arm/arm64: enable irqchip routing > KVM: arm/arm64: build a default routing table > KVM: arm/arm64: enable MSI routing > KVM: arm: implement kvm_set_msi by gsi direct mapping > > Documentation/virtual/kvm/api.txt | 30 -- > arch/arm/include/asm/kvm_host.h | 2 + > arch/arm/kvm/Kconfig | 3 + > arch/arm/kvm/Makefile | 2 +- > arch/arm64/include/asm/kvm_host.h | 1 + > arch/arm64/kvm/Kconfig| 2 + > arch/arm64/kvm/Makefile | 2 +- > include/kvm/arm_vgic.h| 9 --- > include/linux/kvm_host.h | 10 > include/uapi/linux/kvm.h | 6 +- > virt/kvm/arm/vgic.c | 117 > -- > virt/kvm/irqchip.c| 20 +-- > 12 files changed, 154 insertions(+), 50 deletions(-) > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
lock-up with module: Optimize __module_address() using a latched RB-tree
On this machine, a single core Athlon 64 with a 32 bit current Linus' git head kernel, I get a lock-up early in the boot process. (A dmesg output of a successful boot-up of kernel 4.1.0 up to and slightly passed the point where the git head kernel locks up is attached). A photo of the lock-up appears at: http://www.users.on.net/~arthur.marsh/20150706462.jpg git-bisect reveals the bad commit as: git bisect good 93c2e105f6bcee231c951ba0e56e84505c4b0483 is the first bad commit commit 93c2e105f6bcee231c951ba0e56e84505c4b0483 Author: Peter Zijlstra Date: Wed May 27 11:09:37 2015 +0930 module: Optimize __module_address() using a latched RB-tree Currently __module_address() is using a linear search through all modules in order to find the module corresponding to the provided address. With a lot of modules this can take a lot of time. One of the users of this is kernel_text_address() which is employed in many stack unwinders; which in turn are used by perf-callchain and ftrace (possibly from NMI context). So by optimizing __module_address() we optimize many stack unwinders which are used by both perf and tracing in performance sensitive code. Cc: Rusty Russell Cc: Steven Rostedt Cc: Mathieu Desnoyers Cc: Oleg Nesterov Cc: "Paul E. McKenney" Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Rusty Russell :04 04 1d6863a47d8521a4edbe44f9e7c3422ad1421d61 a209090da5e67f56f0997671f5a8b510338511ba M include :04 04 da680638e9cebc8da54d43cc0e67b77b953430fa 31063f7ed575d22f0d27b24c76b9a0fb68c7cd40 M kernel I am happy to supply further details and run further tests. Arthur. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.1.0 (root@am64) (gcc version 5.1.1 20150616 (Debian 5.1.1-11) ) #1772 SMP PREEMPT Mon Jun 22 22:42:18 ACST 2015 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x3ffa] usable [0.00] BIOS-e820: [mem 0x3ffb-0x3ffbdfff] ACPI data [0.00] BIOS-e820: [mem 0x3ffbe000-0x3ffd] ACPI NVS [0.00] BIOS-e820: [mem 0x3ffe-0x3fff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xff78-0x] reserved [0.00] Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel! [0.00] SMBIOS 2.3 present. [0.00] DMI: System manufacturer System Product Name/A8V-MX, BIOS 0503 12/06/2005 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x3ffb0 max_arch_pfn = 0x10 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-E uncachable [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask FFC000 write-back [0.00] 1 base 00D000 mask FFF000 write-combining [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] PAT configuration [0-7]: WB WC UC- UC WB WC UC- UC [0.00] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [c00ff780] [0.00] initial memory mapped: [mem 0x-0x023f] [0.00] Base memory trampoline at [c009b000] 9b000 size 16384 [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] init_memory_mapping: [mem 0x35c0-0x35ff] [0.00] [mem 0x35c0-0x35ff] page 4M [0.00] init_memory_mapping: [mem 0x0010-0x35bf] [0.00] [mem 0x0010-0x003f] page 4k [0.00] [mem 0x0040-0x35bf] page 4M [0.00] init_memory_mapping: [mem 0x3600-0x377fdfff] [0.00] [mem 0x3600-0x373f] page 4M [0.00] [mem 0x3740-0x377fdfff] page 4k [0.00] BRK [0x02059000, 0x02059fff] PGTABLE [0.00] RAMDISK: [mem 0x3614a000-0x3709cfff] [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000FAC60 24 (v02 ACPIAM) [0.00] ACPI: XSDT 0x3FFB0100 3C (v01 A M I OEMXSDT 12000506 MSFT
[PATCH v2 2/4] media: pxa_camera: move interrupt to tasklet
From: Robert Jarzmik
In preparation for dmaengine conversion, move the camera interrupt
handling into a tasklet. This won't change the global flow, as this
interrupt is only used to detect the end of frame and activate DMA fifos
handling.
Signed-off-by: Robert Jarzmik
---
drivers/media/platform/soc_camera/pxa_camera.c | 44 +-
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index 3ca33f0..c0c0f0f 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -223,6 +223,7 @@ struct pxa_camera_dev {
struct pxa_buffer *active;
struct pxa_dma_desc *sg_tail[3];
+ struct tasklet_struct task_eof;
u32 save_cicr[5];
};
@@ -605,6 +606,7 @@ static void pxa_camera_start_capture(struct pxa_camera_dev
*pcdev)
unsigned long cicr0;
dev_dbg(pcdev->soc_host.v4l2_dev.dev, "%s\n", __func__);
+ __raw_writel(__raw_readl(pcdev->base + CISR), pcdev->base + CISR);
/* Enable End-Of-Frame Interrupt */
cicr0 = __raw_readl(pcdev->base + CICR0) | CICR0_ENB;
cicr0 &= ~CICR0_EOFM;
@@ -922,13 +924,35 @@ static void pxa_camera_deactivate(struct pxa_camera_dev
*pcdev)
clk_disable_unprepare(pcdev->clk);
}
-static irqreturn_t pxa_camera_irq(int irq, void *data)
+static void pxa_camera_eof(unsigned long arg)
{
- struct pxa_camera_dev *pcdev = data;
- unsigned long status, cifr, cicr0;
+ struct pxa_camera_dev *pcdev = (struct pxa_camera_dev *)arg;
+ unsigned long cifr;
struct pxa_buffer *buf;
struct videobuf_buffer *vb;
+ dev_dbg(pcdev->soc_host.v4l2_dev.dev,
+ "Camera interrupt status 0x%x\n",
+ __raw_readl(pcdev->base + CISR));
+
+ /* Reset the FIFOs */
+ cifr = __raw_readl(pcdev->base + CIFR) | CIFR_RESET_F;
+ __raw_writel(cifr, pcdev->base + CIFR);
+
+ pcdev->active = list_first_entry(>capture,
+struct pxa_buffer, vb.queue);
+ vb = >active->vb;
+ buf = container_of(vb, struct pxa_buffer, vb);
+ pxa_videobuf_set_actdma(pcdev, buf);
+
+ pxa_dma_start_channels(pcdev);
+}
+
+static irqreturn_t pxa_camera_irq(int irq, void *data)
+{
+ struct pxa_camera_dev *pcdev = data;
+ unsigned long status, cicr0;
+
status = __raw_readl(pcdev->base + CISR);
dev_dbg(pcdev->soc_host.v4l2_dev.dev,
"Camera interrupt status 0x%lx\n", status);
@@ -939,20 +963,9 @@ static irqreturn_t pxa_camera_irq(int irq, void *data)
__raw_writel(status, pcdev->base + CISR);
if (status & CISR_EOF) {
- /* Reset the FIFOs */
- cifr = __raw_readl(pcdev->base + CIFR) | CIFR_RESET_F;
- __raw_writel(cifr, pcdev->base + CIFR);
-
- pcdev->active = list_first_entry(>capture,
- struct pxa_buffer, vb.queue);
- vb = >active->vb;
- buf = container_of(vb, struct pxa_buffer, vb);
- pxa_videobuf_set_actdma(pcdev, buf);
-
- pxa_dma_start_channels(pcdev);
-
cicr0 = __raw_readl(pcdev->base + CICR0) | CICR0_EOFM;
__raw_writel(cicr0, pcdev->base + CICR0);
+ tasklet_schedule(>task_eof);
}
return IRQ_HANDLED;
@@ -1834,6 +1847,7 @@ static int pxa_camera_probe(struct platform_device *pdev)
pcdev->soc_host.priv= pcdev;
pcdev->soc_host.v4l2_dev.dev= >dev;
pcdev->soc_host.nr = pdev->id;
+ tasklet_init(>task_eof, pxa_camera_eof, (unsigned long)pcdev);
err = soc_camera_host_register(>soc_host);
if (err)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] media: pxa_camera: conversion to dmaengine
Convert pxa_camera to dmaengine. This removes all DMA registers
manipulation in favor of the more generic dmaengine API.
The functional level should be the same as before. The biggest change is
in the videobuf_sg_splice() function, which splits a videobuf-dma into
several scatterlists for 3 planes captures (Y, U, V).
Signed-off-by: Robert Jarzmik
---
Since v1: Guennadi's fixes
dma tasklet functions prototypes change (trivial move)
---
drivers/media/platform/soc_camera/pxa_camera.c | 438 -
1 file changed, 215 insertions(+), 223 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index 1ab4f9d..76b2b7b 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -28,6 +28,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -38,7 +41,6 @@
#include
-#include
#include
#define PXA_CAM_VERSION "0.0.6"
@@ -175,21 +177,16 @@ enum pxa_camera_active_dma {
DMA_V = 0x4,
};
-/* descriptor needed for the PXA DMA engine */
-struct pxa_cam_dma {
- dma_addr_t sg_dma;
- struct pxa_dma_desc *sg_cpu;
- size_t sg_size;
- int sglen;
-};
-
/* buffer for one video frame */
struct pxa_buffer {
/* common v4l buffer stuff -- must be first */
struct videobuf_buffer vb;
u32 code;
/* our descriptor lists for Y, U and V channels */
- struct pxa_cam_dma dmas[3];
+ struct dma_async_tx_descriptor *descs[3];
+ dma_cookie_tcookie[3];
+ struct scatterlist *sg[3];
+ int sg_len[3];
int inwork;
enum pxa_camera_active_dma active_dma;
};
@@ -207,7 +204,7 @@ struct pxa_camera_dev {
void __iomem*base;
int channels;
- unsigned intdma_chans[3];
+ struct dma_chan *dma_chans[3];
struct pxacamera_platform_data *pdata;
struct resource *res;
@@ -222,7 +219,6 @@ struct pxa_camera_dev {
spinlock_t lock;
struct pxa_buffer *active;
- struct pxa_dma_desc *sg_tail[3];
struct tasklet_struct task_eof;
u32 save_cicr[5];
@@ -259,7 +255,6 @@ static int pxa_videobuf_setup(struct videobuf_queue *vq,
unsigned int *count,
static void free_buffer(struct videobuf_queue *vq, struct pxa_buffer *buf)
{
struct soc_camera_device *icd = vq->priv_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct videobuf_dmabuf *dma = videobuf_to_dma(>vb);
int i;
@@ -276,59 +271,99 @@ static void free_buffer(struct videobuf_queue *vq, struct
pxa_buffer *buf)
if (buf->vb.state == VIDEOBUF_NEEDS_INIT)
return;
- for (i = 0; i < ARRAY_SIZE(buf->dmas); i++) {
- if (buf->dmas[i].sg_cpu)
- dma_free_coherent(ici->v4l2_dev.dev,
- buf->dmas[i].sg_size,
- buf->dmas[i].sg_cpu,
- buf->dmas[i].sg_dma);
- buf->dmas[i].sg_cpu = NULL;
+ for (i = 0; i < 3 && buf->descs[i]; i++) {
+ async_tx_ack(buf->descs[i]);
+ kfree(buf->sg[i]);
+ buf->descs[i] = NULL;
+ buf->sg[i] = NULL;
+ buf->sg_len[i] = 0;
}
videobuf_dma_unmap(vq->dev, dma);
videobuf_dma_free(dma);
buf->vb.state = VIDEOBUF_NEEDS_INIT;
+
+ dev_dbg(icd->parent, "%s end (vb=0x%p) 0x%08lx %d\n", __func__,
+ >vb, buf->vb.baddr, buf->vb.bsize);
}
-static int calculate_dma_sglen(struct scatterlist *sglist, int sglen,
- int sg_first_ofs, int size)
+static struct scatterlist *videobuf_sg_cut(struct scatterlist *sglist,
+ int sglen, int offset, int size,
+ int *new_sg_len)
{
- int i, offset, dma_len, xfer_len;
- struct scatterlist *sg;
+ struct scatterlist *sg0, *sg, *sg_first = NULL;
+ int i, dma_len, dropped_xfer_len, dropped_remain, remain;
+ int nfirst = -1, nfirst_offset = 0, xfer_len;
- offset = sg_first_ofs;
+ *new_sg_len = 0;
+ dropped_remain = offset;
+ remain = size;
for_each_sg(sglist, sg, sglen, i) {
dma_len = sg_dma_len(sg);
-
/* PXA27x Developer's Manual 27.4.4.1: round up to 8 bytes */
- xfer_len = roundup(min(dma_len - offset, size), 8);
+ dropped_xfer_len = roundup(min(dma_len, dropped_remain), 8);
+ if
[PATCH v2 1/4] media: pxa_camera: fix the buffer free path
From: Robert Jarzmik
Fix the error path where the video buffer wasn't allocated nor
mapped. In this case, in the driver free path don't try to unmap memory
which was not mapped in the first place.
Signed-off-by: Robert Jarzmik
---
drivers/media/platform/soc_camera/pxa_camera.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index 8d6e343..3ca33f0 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -272,8 +272,8 @@ static void free_buffer(struct videobuf_queue *vq, struct
pxa_buffer *buf)
* longer in STATE_QUEUED or STATE_ACTIVE
*/
videobuf_waiton(vq, >vb, 0, 0);
- videobuf_dma_unmap(vq->dev, dma);
- videobuf_dma_free(dma);
+ if (buf->vb.state == VIDEOBUF_NEEDS_INIT)
+ return;
for (i = 0; i < ARRAY_SIZE(buf->dmas); i++) {
if (buf->dmas[i].sg_cpu)
@@ -283,6 +283,8 @@ static void free_buffer(struct videobuf_queue *vq, struct
pxa_buffer *buf)
buf->dmas[i].sg_dma);
buf->dmas[i].sg_cpu = NULL;
}
+ videobuf_dma_unmap(vq->dev, dma);
+ videobuf_dma_free(dma);
buf->vb.state = VIDEOBUF_NEEDS_INIT;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] media: pxa_camera conversion to dmaengine
Hi Guennadi, This is the next round. Most of your comments are addressed or answered, the one big thing left apart is the videobuf_sg_cut() implementation and complexity. If you have a better idea, I'm all ears. One thing that changed since v1 is that pxa_dma driver was accepted into dmaengine tree and merged, as well as the dma buffer "reusability" stuff. This begins round 2 of dmaengine conversion of pxa_camera, happy review. Cheers. -- Robert Robert Jarzmik (4): media: pxa_camera: fix the buffer free path media: pxa_camera: move interrupt to tasklet media: pxa_camera: trivial move of dma irq functions media: pxa_camera: conversion to dmaengine drivers/media/platform/soc_camera/pxa_camera.c | 522 + 1 file changed, 267 insertions(+), 255 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] media: pxa_camera: trivial move of dma irq functions
From: Robert Jarzmik
This moves the dma irq handling functions up in the source file, so that
they are available before DMA preparation functions. It prepares the
conversion to DMA engine, where the descriptors are populated with these
functions as callbacks.
Signed-off-by: Robert Jarzmik
---
Since v1: fixed prototypes change
---
drivers/media/platform/soc_camera/pxa_camera.c | 40 ++
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index c0c0f0f..1ab4f9d 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -311,6 +311,28 @@ static int calculate_dma_sglen(struct scatterlist *sglist,
int sglen,
BUG_ON(size != 0);
return i + 1;
+static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev,
+ enum pxa_camera_active_dma act_dma);
+
+static void pxa_camera_dma_irq_y(int channel, void *data)
+{
+ struct pxa_camera_dev *pcdev = data;
+
+ pxa_camera_dma_irq(pcdev, DMA_Y);
+}
+
+static void pxa_camera_dma_irq_u(int channel, void *data)
+{
+ struct pxa_camera_dev *pcdev = data;
+
+ pxa_camera_dma_irq(pcdev, DMA_U);
+}
+
+static void pxa_camera_dma_irq_v(int channel, void *data)
+{
+ struct pxa_camera_dev *pcdev = data;
+
+ pxa_camera_dma_irq(pcdev, DMA_V);
}
/**
@@ -810,24 +832,6 @@ out:
spin_unlock_irqrestore(>lock, flags);
}
-static void pxa_camera_dma_irq_y(int channel, void *data)
-{
- struct pxa_camera_dev *pcdev = data;
- pxa_camera_dma_irq(channel, pcdev, DMA_Y);
-}
-
-static void pxa_camera_dma_irq_u(int channel, void *data)
-{
- struct pxa_camera_dev *pcdev = data;
- pxa_camera_dma_irq(channel, pcdev, DMA_U);
-}
-
-static void pxa_camera_dma_irq_v(int channel, void *data)
-{
- struct pxa_camera_dev *pcdev = data;
- pxa_camera_dma_irq(channel, pcdev, DMA_V);
-}
-
static struct videobuf_queue_ops pxa_videobuf_ops = {
.buf_setup = pxa_videobuf_setup,
.buf_prepare= pxa_videobuf_prepare,
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cris: arch-v10: kernel: kgdb: let is_dyn_brkp as extern variable
On Sun, 05 Jul 2015 06:07:54 +0800, Chen Gang said: > For upstream cris toolchain (gcc is 6.0 typo? pgpqUqjfv2xqt.pgp Description: PGP signature
[PATCH] GPU-DRM-nouveau: Delete unnecessary checks before two function calls
From: Markus Elfring
Date: Sun, 5 Jul 2015 20:15:12 +0200
The functions nvkm_namedb_put() and pci_dev_put() test whether their
argument is NULL and then return immediately.
Thus the test around the calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +--
drivers/gpu/drm/nouveau/nvkm/core/handle.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 36b40c9..8ca3d0c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -515,8 +515,7 @@ nouveau_drm_unload(struct drm_device *dev)
nouveau_vga_fini(drm);
nvif_device_fini(>device);
- if (drm->hdmi_device)
- pci_dev_put(drm->hdmi_device);
+ pci_dev_put(drm->hdmi_device);
nouveau_cli_destroy(>client);
return 0;
}
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/handle.c
b/drivers/gpu/drm/nouveau/nvkm/core/handle.c
index dc7ff10..165f3ff 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/handle.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/handle.c
@@ -216,6 +216,5 @@ nvkm_handle_get_cinst(struct nvkm_object *engctx, u32 cinst)
void
nvkm_handle_put(struct nvkm_handle *handle)
{
- if (handle)
- nvkm_namedb_put(handle);
+ nvkm_namedb_put(handle);
}
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: dgnc: Replace macro with flow control statement by a function
This patch fixes the checkpatch.pl warning:
WARNING: Macros with flow control statements should be avoided
Replace the macro with a function doing the exact same task as the
macro.
Signed-off-by: Arjun Krishna Babu
---
drivers/staging/dgnc/dgnc_sysfs.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_sysfs.c
b/drivers/staging/dgnc/dgnc_sysfs.c
index 44db870..8ab0922 100644
--- a/drivers/staging/dgnc/dgnc_sysfs.c
+++ b/drivers/staging/dgnc/dgnc_sysfs.c
@@ -92,19 +92,17 @@ void dgnc_remove_driver_sysfiles(struct pci_driver
*dgnc_driver)
}
-#define DGNC_VERIFY_BOARD(p, bd) \
- do {\
- if (!p) \
- return 0; \
- \
- bd = dev_get_drvdata(p);\
- if (!bd || bd->magic != DGNC_BOARD_MAGIC) \
- return 0; \
- if (bd->state != BOARD_READY) \
- return 0; \
- } while (0)
-
+static int DGNC_VERIFY_BOARD(struct device *p, struct dgnc_board *bd)
+{
+ if (!p)
+ return 0;
+ bd = dev_get_drvdata(p);
+ if (!bd || bd->magic != DGNC_BOARD_MAGIC)
+ return 0;
+ if (bd->state != BOARD_READY)
+ return 0;
+}
static ssize_t dgnc_vpd_show(struct device *p, struct device_attribute *attr,
char *buf)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ACPI: custom_method.c, osl.c: Fixed coding style issues.
Fixed coding style issues.
Signed-off-by: Daniel Machon
---
drivers/acpi/custom_method.c | 2 +-
drivers/acpi/osl.c | 32
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
index c68e724..d0ae76c 100644
--- a/drivers/acpi/custom_method.c
+++ b/drivers/acpi/custom_method.c
@@ -19,7 +19,7 @@ static struct dentry *cm_dentry;
/* /sys/kernel/debug/acpi/custom_method */
-static ssize_t cm_write(struct file *file, const char __user * user_buf,
+static ssize_t cm_write(struct file *file, const char __user *user_buf,
size_t count, loff_t *ppos)
{
static char *buf;
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index c262e4a..65b3847 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -519,7 +519,7 @@ EXPORT_SYMBOL(acpi_os_unmap_generic_address);
#ifdef ACPI_FUTURE_USAGE
acpi_status
-acpi_os_get_physical_address(void *virt, acpi_physical_address * phys)
+acpi_os_get_physical_address(void *virt, acpi_physical_address *phys)
{
if (!phys || !virt)
return AE_BAD_PARAMETER;
@@ -725,8 +725,8 @@ static void acpi_table_taint(struct acpi_table_header
*table)
acpi_status
-acpi_os_table_override(struct acpi_table_header * existing_table,
- struct acpi_table_header ** new_table)
+acpi_os_table_override(struct acpi_table_header *existing_table,
+ struct acpi_table_header **new_table)
{
if (!existing_table || !new_table)
return AE_BAD_PARAMETER;
@@ -900,7 +900,7 @@ u64 acpi_os_get_timer(void)
return time_ns;
}
-acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width)
+acpi_status acpi_os_read_port(acpi_io_address port, u32 *value, u32 width)
{
u32 dummy;
@@ -1057,7 +1057,7 @@ acpi_os_write_memory(acpi_physical_address phys_addr, u64
value, u32 width)
}
acpi_status
-acpi_os_read_pci_configuration(struct acpi_pci_id * pci_id, u32 reg,
+acpi_os_read_pci_configuration(struct acpi_pci_id *pci_id, u32 reg,
u64 *value, u32 width)
{
int result, size;
@@ -1085,11 +1085,11 @@ acpi_os_read_pci_configuration(struct acpi_pci_id *
pci_id, u32 reg,
reg, size, );
*value = value32;
- return (result ? AE_ERROR : AE_OK);
+ return result ? AE_ERROR : AE_OK;
}
acpi_status
-acpi_os_write_pci_configuration(struct acpi_pci_id * pci_id, u32 reg,
+acpi_os_write_pci_configuration(struct acpi_pci_id *pci_id, u32 reg,
u64 value, u32 width)
{
int result, size;
@@ -1112,7 +1112,7 @@ acpi_os_write_pci_configuration(struct acpi_pci_id *
pci_id, u32 reg,
PCI_DEVFN(pci_id->device, pci_id->function),
reg, size, value);
- return (result ? AE_ERROR : AE_OK);
+ return result ? AE_ERROR : AE_OK;
}
static void acpi_os_execute_deferred(struct work_struct *work)
@@ -1258,7 +1258,7 @@ bool acpi_queue_hotplug_work(struct work_struct *work)
}
acpi_status
-acpi_os_create_semaphore(u32 max_units, u32 initial_units, acpi_handle *
handle)
+acpi_os_create_semaphore(u32 max_units, u32 initial_units, acpi_handle *handle)
{
struct semaphore *sem = NULL;
@@ -1752,7 +1752,7 @@ void acpi_os_release_lock(acpi_spinlock lockp,
acpi_cpu_flags flags)
**/
acpi_status
-acpi_os_create_cache(char *name, u16 size, u16 depth, acpi_cache_t ** cache)
+acpi_os_create_cache(char *name, u16 size, u16 depth, acpi_cache_t **cache)
{
*cache = kmem_cache_create(name, size, 0, 0, NULL);
if (*cache == NULL)
@@ -1773,10 +1773,10 @@ acpi_os_create_cache(char *name, u16 size, u16 depth,
acpi_cache_t ** cache)
*
**/
-acpi_status acpi_os_purge_cache(acpi_cache_t * cache)
+acpi_status acpi_os_purge_cache(acpi_cache_t *cache)
{
kmem_cache_shrink(cache);
- return (AE_OK);
+ return AE_OK;
}
/***
@@ -1792,10 +1792,10 @@ acpi_status acpi_os_purge_cache(acpi_cache_t * cache)
*
**/
-acpi_status acpi_os_delete_cache(acpi_cache_t * cache)
+acpi_status acpi_os_delete_cache(acpi_cache_t *cache)
{
kmem_cache_destroy(cache);
- return (AE_OK);
+ return AE_OK;
}
/***
@@ -1812,10 +1812,10 @@ acpi_status acpi_os_delete_cache(acpi_cache_t * cache)
*
**/
-acpi_status acpi_os_release_object(acpi_cache_t * cache, void *object)
+acpi_status
[BUG] [PATCH] iio: mma8452: use iio event type IIO_EV_TYPE_MAG
IIO_EV_TYPE_THRESH in rising direction describes an event where the
threshold is crossed in rising direction, positive or negative values
being possible. This is not the case here.
Since the threshold is no signed value and only the magnitude is compared,
IIO_EV_TYPE_MAG is what describes the behaviour of these devices, see the
sysfs-bus-iio ABI Documentation.
Signed-off-by: Martin Kepplinger
Signed-off-by: Christoph Muellner
Cc: sta...@vger.kernel.org
---
if we can resolve this quickly, I know what to base my work on ;)
thanks!
drivers/iio/accel/mma8452.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index e8e2077..13ea1ea 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -557,21 +557,21 @@ static void mma8452_transient_interrupt(struct iio_dev
*indio_dev)
if (src & MMA8452_TRANSIENT_SRC_XTRANSE)
iio_push_event(indio_dev,
IIO_MOD_EVENT_CODE(IIO_ACCEL, 0, IIO_MOD_X,
- IIO_EV_TYPE_THRESH,
+ IIO_EV_TYPE_MAG,
IIO_EV_DIR_RISING),
ts);
if (src & MMA8452_TRANSIENT_SRC_YTRANSE)
iio_push_event(indio_dev,
IIO_MOD_EVENT_CODE(IIO_ACCEL, 0, IIO_MOD_Y,
- IIO_EV_TYPE_THRESH,
+ IIO_EV_TYPE_MAG,
IIO_EV_DIR_RISING),
ts);
if (src & MMA8452_TRANSIENT_SRC_ZTRANSE)
iio_push_event(indio_dev,
IIO_MOD_EVENT_CODE(IIO_ACCEL, 0, IIO_MOD_Z,
- IIO_EV_TYPE_THRESH,
+ IIO_EV_TYPE_MAG,
IIO_EV_DIR_RISING),
ts);
}
@@ -644,7 +644,7 @@ static int mma8452_reg_access_dbg(struct iio_dev *indio_dev,
static const struct iio_event_spec mma8452_transient_event[] = {
{
- .type = IIO_EV_TYPE_THRESH,
+ .type = IIO_EV_TYPE_MAG,
.dir = IIO_EV_DIR_RISING,
.mask_separate = BIT(IIO_EV_INFO_ENABLE),
.mask_shared_by_type = BIT(IIO_EV_INFO_VALUE) |
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] console_codes.4: Add CSI sequence for cursor blink interval
On Thu, 26 Mar 2015, Scot Doyle wrote:
> Add a Console Private CSI sequence to specify the current console's
> cursor blink interval. The interval is specified as a number of
> milliseconds until the next cursor display state toggle, from 50 to
> 65535.
>
> Signed-off-by: Scot Doyle
> ---
> man4/console_codes.4 | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/man4/console_codes.4 b/man4/console_codes.4
> index 34f7535..7d05076 100644
> --- a/man4/console_codes.4
> +++ b/man4/console_codes.4
> @@ -377,6 +377,7 @@ ESC [ 15 ]T{
> Bring the previous console to the front
> (since Linux 2.6.0).
> T}
> +ESC [ 16 ; \fIn\fP ] Set the cursor blink interval in milliseconds.
> .TE
> .SS Character sets
> The kernel knows about 4 translations of bytes into console-screen
> --
> 2.1.0
>
Hi Michael,
Will you apply now that Linus has pulled the rest?
(see bd63364caa8df38bad2b25b11b2a1b849475cce5)
Thank you,
Scot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Feature request, "create on mount" to create mount point directory on mount, implied remove on unmount
On Sun, Jul 05, 2015 at 04:46:50PM +0100, jon wrote: > I should have titled it "Feature request from a simple minded user" > > I have not the slightest idea what you are talking about. > > When I learnt *nix it did not have "name spaces" in reference to process > tables. I understand the theory of VM a bit, the model in my mind each > "machine", be that one kernel on a true processor or a VM instance has > "a process table" and "a file descriptor table" etc - anything more is > beyond my current level of knowledge. File descriptor table isn't something system-wide - it belongs to a process... Containers are basically glorified process groups. Anyway, the underlying model hasn't changed much since _way_ back; each thread of execution is a virtual machine of its own, with actual CPUs switched between those. Each of them has memory, ports (== file descriptors) and traps (== signal handlers). The main primitives are clone() (== rfork() in other branches; plain fork() is just the most common case) - create a copy of the virtual machine, in the state identical to that of caller with the exception of different return values given to child and parent. exit() - terminate the virtual machine execve() - load a new program Parts of those virtual machines can be shared - e.g. you can have descriptor table not just identical to that of parent at the time of clone(), but actually shared with it, so e.g. open() in child makes the resulting descriptor visible to parent as well. Or you can have memory (address space) shared, so that something like mmap() in parent would affect the memory mappings of child, etc. Which components are to be shared and which - copied is selected by clone() argument. unshare() allows to switch to using a private copy of chosen components - e.g. you might say "from now on, I want my file descriptor table to be private". In e.g. Plan 9 that's expressed via rfork() as well. Less obvious componets including current directory and root. Normally, these are not shared; chdir() done in child won't affect the parent and vice versa. You could ask them to be shared, though - for multithreaded program it could be convenient. Different processes might see different parts of the mount tree since v7 had introduced chroot(2). Namespaces simply allow to have a *forest* - different groups of processes seeing different mount trees in that forest. The same filesystem may be mounted in many places, and the same directory might be a mountpoint in an instance visible to one process and not a mountpoint in an instance visible to another (or a mountpoint with something entirely different mounted in an instance visible to somebody else). Mount tree is yet another component; the difference is that normally it *is* shared on clone(), rather than being copied. I.e. mount() done by child affects the mount tree visible to parent. But you still can ask for a new private copy of mount tree via clone() or unshare(). When the last process sharing that mount tree exits, it gets dissolved, same as every file descriptor in a descriptor table gets closed when the last thread sharing that descriptor table exits (or asks for unshared copy of descriptor table, e.g. as a side effect of execve()). Just as with file descriptors close() does not necessary close the opened file descriptor's connected to (that happens only when all descriptors connected to given opened file are closed), umount() does not necessary shut the filesystem down; that happens only if it's not mounted elsewhere. With something like Plan 9 that would be pretty much all you need for isolating process groups into separate environments - just give each the set of filesystems they should be seeing and be done with that. We, unfortunately, can't drop certain FPOS APIs (starting with sockets, with their "network interfaces are magical sets of named objects, names are not experssed as pathnames, access control and visibility completely ad-hoc, ditto for listing and renaming" shite), so we get more state components ;-/ Which leads to e.g. "network namespace" and similar complications; that crap should've been dealt with in _filesystem_ namespace, but Occam Razor be damned, we need to support every misdesigned interface that got there, no matter how many entities it breeds and how convoluted the result becomes... In principle, though, it's still the same model - only with more components to be possibly shared. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ACPI: battery.c: Fixed flying pointer mark issue. Coding style issue.
Fixed coding style issue.
Signed-off-by: Daniel Machon
---
drivers/acpi/battery.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index b3628cc..0447c6a 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -918,8 +918,8 @@ static int acpi_battery_print_alarm(struct seq_file *seq,
int result)
}
static ssize_t acpi_battery_write_alarm(struct file *file,
- const char __user * buffer,
- size_t count, loff_t * ppos)
+ const char __user *buffer,
+ size_t count, loff_t *ppos)
{
int result = 0;
char alarm_string[12] = { '\0' };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ACPI: memhotplug.c: Fixed flying pointer issue. Coding style issue.
Fixed coding style issue.
Signed-off-by: Daniel Machon
---
drivers/acpi/acpi_memhotplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index ee28f4d..5faf598 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -79,7 +79,7 @@ struct acpi_memory_info {
};
struct acpi_memory_device {
- struct acpi_device * device;
+ struct acpi_device *device;
unsigned int state; /* State of the memory device */
struct list_head res_list;
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] of: add HAS_IOMEM depends to OF_ADDRESS
On UML builds, of_address.c fails to compile: ../drivers/of/address.c:873:2: error: implicit declaration of function ‘ioremap’ [-Werror=implicit-function-declaration] This is due to CONFIG_OF now being user selectable. Add a dependency on HAS_IOMEM to OF_ADDRESS in order to fix this. Signed-off-by: Rob Herring Cc: Grant Likely --- drivers/of/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig index 8df1b17..59bb855 100644 --- a/drivers/of/Kconfig +++ b/drivers/of/Kconfig @@ -47,7 +47,7 @@ config OF_DYNAMIC config OF_ADDRESS def_bool y - depends on !SPARC + depends on !SPARC && HAS_IOMEM select OF_ADDRESS_PCI if PCI config OF_ADDRESS_PCI -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kvm/x86: add support for MONITOR_TRAP_FLAG
Allow a nested hypervisor to single step its guests.
Signed-off-by: Mihai Donțu
---
This patch applies on top of current linux-next.
---
arch/x86/include/asm/vmx.h | 1 +
arch/x86/include/uapi/asm/vmx.h | 2 ++
arch/x86/kvm/vmx.c | 10 +-
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index da772ed..9299ae5 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -47,6 +47,7 @@
#define CPU_BASED_MOV_DR_EXITING0x0080
#define CPU_BASED_UNCOND_IO_EXITING 0x0100
#define CPU_BASED_USE_IO_BITMAPS0x0200
+#define CPU_BASED_MONITOR_TRAP_FLAG 0x0800
#define CPU_BASED_USE_MSR_BITMAPS 0x1000
#define CPU_BASED_MONITOR_EXITING 0x2000
#define CPU_BASED_PAUSE_EXITING 0x4000
diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index 1fe9218..37fee27 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -58,6 +58,7 @@
#define EXIT_REASON_INVALID_STATE 33
#define EXIT_REASON_MSR_LOAD_FAIL 34
#define EXIT_REASON_MWAIT_INSTRUCTION 36
+#define EXIT_REASON_MONITOR_TRAP_FLAG 37
#define EXIT_REASON_MONITOR_INSTRUCTION 39
#define EXIT_REASON_PAUSE_INSTRUCTION 40
#define EXIT_REASON_MCE_DURING_VMENTRY 41
@@ -106,6 +107,7 @@
{ EXIT_REASON_MSR_READ, "MSR_READ" }, \
{ EXIT_REASON_MSR_WRITE, "MSR_WRITE" }, \
{ EXIT_REASON_MWAIT_INSTRUCTION, "MWAIT_INSTRUCTION" }, \
+ { EXIT_REASON_MONITOR_TRAP_FLAG, "MONITOR_TRAP_FLAG" }, \
{ EXIT_REASON_MONITOR_INSTRUCTION, "MONITOR_INSTRUCTION" }, \
{ EXIT_REASON_PAUSE_INSTRUCTION, "PAUSE_INSTRUCTION" }, \
{ EXIT_REASON_MCE_DURING_VMENTRY,"MCE_DURING_VMENTRY" }, \
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e856dd5..6d7c650 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2443,7 +2443,7 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx
*vmx)
CPU_BASED_CR8_LOAD_EXITING | CPU_BASED_CR8_STORE_EXITING |
#endif
CPU_BASED_MOV_DR_EXITING | CPU_BASED_UNCOND_IO_EXITING |
- CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_EXITING |
+ CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_TRAP_FLAG |
CPU_BASED_MONITOR_EXITING |
CPU_BASED_RDPMC_EXITING | CPU_BASED_RDTSC_EXITING |
CPU_BASED_PAUSE_EXITING | CPU_BASED_TPR_SHADOW |
CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
@@ -6246,6 +6246,11 @@ static int handle_mwait(struct kvm_vcpu *vcpu)
return handle_nop(vcpu);
}
+static int handle_monitor_trap(struct kvm_vcpu *vcpu)
+{
+ return 1;
+}
+
static int handle_monitor(struct kvm_vcpu *vcpu)
{
printk_once(KERN_WARNING "kvm: MONITOR instruction emulated as NOP!\n");
@@ -7282,6 +7287,7 @@ static int (*const kvm_vmx_exit_handlers[])(struct
kvm_vcpu *vcpu) = {
[EXIT_REASON_EPT_MISCONFIG] = handle_ept_misconfig,
[EXIT_REASON_PAUSE_INSTRUCTION] = handle_pause,
[EXIT_REASON_MWAIT_INSTRUCTION] = handle_mwait,
+ [EXIT_REASON_MONITOR_TRAP_FLAG] = handle_monitor_trap,
[EXIT_REASON_MONITOR_INSTRUCTION] = handle_monitor,
[EXIT_REASON_INVEPT] = handle_invept,
[EXIT_REASON_INVVPID] = handle_invvpid,
@@ -7542,6 +7548,8 @@ static bool nested_vmx_exit_handled(struct kvm_vcpu *vcpu)
return true;
case EXIT_REASON_MWAIT_INSTRUCTION:
return nested_cpu_has(vmcs12, CPU_BASED_MWAIT_EXITING);
+ case EXIT_REASON_MONITOR_TRAP_FLAG:
+ return nested_cpu_has(vmcs12, CPU_BASED_MONITOR_TRAP_FLAG);
case EXIT_REASON_MONITOR_INSTRUCTION:
return nested_cpu_has(vmcs12, CPU_BASED_MONITOR_EXITING);
case EXIT_REASON_PAUSE_INSTRUCTION:
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 2/4] x86: Plug irq vector hotplug race
Jin debugged a nasty cpu hotplug race which results in leaking a irq
vector on the newly hotplugged cpu.
cpu N cpu M
native_cpu_up device_shutdown
do_boot_cpu free_msi_irqs
start_secondary arch_teardown_msi_irqs
smp_callindefault_teardown_msi_irqs
setup_vector_irq arch_teardown_msi_irq
__setup_vector_irq native_teardown_msi_irq
lock(vector_lock) destroy_irq
install vectors
unlock(vector_lock)
lock(vector_lock)
---> __clear_irq_vector
unlock(vector_lock)
lock(vector_lock)
set_cpu_online
unlock(vector_lock)
This leaves the irq vector(s) which are torn down on CPU M stale in
the vector array of CPU N, because CPU M does not see CPU N online
yet. There is a similar issue with concurrent newly setup interrupts.
The alloc/free protection of irq descriptors does not prevent the
above race, because it merily prevents interrupt descriptors from
going away or changing concurrently.
Prevent this by moving the call to setup_vector_irq() into the
vector_lock held region which protects set_cpu_online():
cpu N cpu M
native_cpu_up device_shutdown
do_boot_cpu free_msi_irqs
start_secondary arch_teardown_msi_irqs
smp_callindefault_teardown_msi_irqs
lock(vector_lock)arch_teardown_msi_irq
setup_vector_irq()
__setup_vector_irq native_teardown_msi_irq
install vectorsdestroy_irq
set_cpu_online
unlock(vector_lock)
lock(vector_lock)
__clear_irq_vector
unlock(vector_lock)
So cpu M either sees the cpu N online before clearing the vector or
cpu N installs the vectors after cpu M has cleared it.
Reported-by: xiao jin
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/vector.c | 10 ++
arch/x86/kernel/smpboot.c | 13 +
2 files changed, 7 insertions(+), 16 deletions(-)
Index: tip/arch/x86/kernel/apic/vector.c
===
--- tip.orig/arch/x86/kernel/apic/vector.c
+++ tip/arch/x86/kernel/apic/vector.c
@@ -409,12 +409,6 @@ static void __setup_vector_irq(int cpu)
int irq, vector;
struct apic_chip_data *data;
- /*
-* vector_lock will make sure that we don't run into irq vector
-* assignments that might be happening on another cpu in parallel,
-* while we setup our initial vector to irq mappings.
-*/
- raw_spin_lock(_lock);
/* Mark the inuse vectors */
for_each_active_irq(irq) {
data = apic_chip_data(irq_get_irq_data(irq));
@@ -436,16 +430,16 @@ static void __setup_vector_irq(int cpu)
if (!cpumask_test_cpu(cpu, data->domain))
per_cpu(vector_irq, cpu)[vector] = VECTOR_UNDEFINED;
}
- raw_spin_unlock(_lock);
}
/*
- * Setup the vector to irq mappings.
+ * Setup the vector to irq mappings. Must be called with vector_lock held.
*/
void setup_vector_irq(int cpu)
{
int irq;
+ lockdep_assert_held(_lock);
/*
* On most of the platforms, legacy PIC delivers the interrupts on the
* boot cpu. But there are certain platforms where PIC interrupts are
Index: tip/arch/x86/kernel/smpboot.c
===
--- tip.orig/arch/x86/kernel/smpboot.c
+++ tip/arch/x86/kernel/smpboot.c
@@ -171,11 +171,6 @@ static void smp_callin(void)
apic_ap_setup();
/*
-* Need to setup vector mappings before we enable interrupts.
-*/
- setup_vector_irq(smp_processor_id());
-
- /*
* Save our processor parameters. Note: this information
* is needed for clock calibration.
*/
@@ -246,11 +241,13 @@ static void notrace start_secondary(void
#endif
/*
-* We need to hold vector_lock so there the set of online cpus
-* does not change while we are assigning vectors to cpus. Holding
-* this lock ensures we don't half assign or remove an irq from a cpu.
+* Lock vector_lock and initialize the vectors on this cpu
+* before setting the cpu online. We must set it online with
+* vector_lock held to prevent a concurrent setup/teardown
+* from seeing a half valid vector space.
*/
lock_vector_lock();
+ setup_vector_irq(smp_processor_id());
set_cpu_online(smp_processor_id(), true);
[patch 0/4] x86/irq: Plug a couple of cpu hotplug races
Jin debugged a subtle race in the cpu hotplug code which caused my to look deeper into this. So I unearthed quite a few racy constructs. Aside of the x86 specific problems I discovered a generic issue which needs to be addressed in the cpu hotplug code. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 4/4] x86/irq: Retrieve irq data after locking irq_desc
irq_data is protected by irq_desc->lock, so retrieving the irq chip
from irq_data outside the lock is racy vs. an concurrent update. Move
it into the lock held region.
While at it add a comment why the vector walk does not require
vector_lock.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/irq.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: tip/arch/x86/kernel/irq.c
===
--- tip.orig/arch/x86/kernel/irq.c
+++ tip/arch/x86/kernel/irq.c
@@ -497,6 +497,11 @@ void fixup_irqs(void)
*/
mdelay(1);
+ /*
+* We can walk the vector array of this cpu without holding
+* vector_lock because the cpu is already marked !online, so
+* nothing else will touch it.
+*/
for (vector = FIRST_EXTERNAL_VECTOR; vector < NR_VECTORS; vector++) {
unsigned int irr;
@@ -508,9 +513,9 @@ void fixup_irqs(void)
irq = __this_cpu_read(vector_irq[vector]);
desc = irq_to_desc(irq);
+ raw_spin_lock(>lock);
data = irq_desc_get_irq_data(desc);
chip = irq_data_get_irq_chip(data);
- raw_spin_lock(>lock);
if (chip->irq_retrigger) {
chip->irq_retrigger(data);
__this_cpu_write(vector_irq[vector],
VECTOR_RETRIGGERED);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 3/4] x86/irq: Use proper locking in check_irq_vectors_for_cpu_disable()
It's unsafe to examine fields in the irq descriptor w/o holding the
descriptor lock. Add proper locking.
While at it add a comment why the vector check can run lock less
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/irq.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
Index: tip/arch/x86/kernel/irq.c
===
--- tip.orig/arch/x86/kernel/irq.c
+++ tip/arch/x86/kernel/irq.c
@@ -347,14 +347,22 @@ int check_irq_vectors_for_cpu_disable(vo
if (!desc)
continue;
+ /*
+* Protect against concurrent action removal,
+* affinity changes etc.
+*/
+ raw_spin_lock(>lock);
data = irq_desc_get_irq_data(desc);
cpumask_copy(_new, data->affinity);
cpumask_clear_cpu(this_cpu, _new);
/* Do not count inactive or per-cpu irqs. */
- if (!irq_has_action(irq) || irqd_is_per_cpu(data))
+ if (!irq_has_action(irq) || irqd_is_per_cpu(data)) {
+ raw_spin_unlock(>lock);
continue;
+ }
+ raw_spin_unlock(>lock);
/*
* A single irq may be mapped to multiple
* cpu's vector_irq[] (for example IOAPIC cluster
@@ -385,6 +393,9 @@ int check_irq_vectors_for_cpu_disable(vo
* vector. If the vector is marked in the used vectors
* bitmap or an irq is assigned to it, we don't count
* it as available.
+*
+* As this is an inaccurate snapshot anyway, we can do
+* this w/o holding vector_lock.
*/
for (vector = FIRST_EXTERNAL_VECTOR;
vector < first_system_vector; vector++) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/4] hotplug: Prevent alloc/free of irq descriptors during cpu up/down
When a cpu goes up some architectures (e.g. x86) have to walk the irq
space to set up the vector space for the cpu. While this needs extra
protection at the architecture level we can avoid a few race
conditions by preventing the concurrent allocation/free of irq
descriptors and the associated data.
When a cpu goes down it moves the interrupts which are targeted to
this cpu away by reassigning the affinities. While this happens
interrupts can be allocated and freed, which opens a can of race
conditions in the code which reassignes the affinities because
interrupt descriptors might be freed underneath.
Example:
CPU1CPU2
cpu_up/down
irq_desc = irq_to_desc(irq);
remove_from_radix_tree(desc);
raw_spin_lock(>lock);
free(desc);
We could protect the irq descriptors with RCU, but that would require
a full tree change of all accesses to interrupt descriptors. But
fortunately these kind of race conditions are rather limited to a few
things like cpu hotplug. The normal setup/teardown is very well
serialized. So the simpler and obvious solution is:
Prevent allocation and freeing of interrupt descriptors accross cpu
hotplug.
Signed-off-by: Thomas Gleixner
---
include/linux/irqdesc.h |7 ++-
kernel/cpu.c| 21 -
kernel/irq/internals.h |4
3 files changed, 26 insertions(+), 6 deletions(-)
Index: tip/include/linux/irqdesc.h
===
--- tip.orig/include/linux/irqdesc.h
+++ tip/include/linux/irqdesc.h
@@ -90,7 +90,12 @@ struct irq_desc {
const char *name;
} cacheline_internodealigned_in_smp;
-#ifndef CONFIG_SPARSE_IRQ
+#ifdef CONFIG_SPARSE_IRQ
+extern void irq_lock_sparse(void);
+extern void irq_unlock_sparse(void);
+#else
+static inline void irq_lock_sparse(void) { }
+static inline void irq_unlock_sparse(void) { }
extern struct irq_desc irq_desc[NR_IRQS];
#endif
Index: tip/kernel/cpu.c
===
--- tip.orig/kernel/cpu.c
+++ tip/kernel/cpu.c
@@ -392,13 +392,19 @@ static int __ref _cpu_down(unsigned int
smpboot_park_threads(cpu);
/*
-* So now all preempt/rcu users must observe !cpu_active().
+* Prevent irq alloc/free while the dying cpu reorganizes the
+* interrupt affinities.
*/
+ irq_lock_sparse();
+ /*
+* So now all preempt/rcu users must observe !cpu_active().
+*/
err = __stop_machine(take_cpu_down, _param, cpumask_of(cpu));
if (err) {
/* CPU didn't die: tell everyone. Can't complain. */
cpu_notify_nofail(CPU_DOWN_FAILED | mod, hcpu);
+ irq_unlock_sparse();
goto out_release;
}
BUG_ON(cpu_online(cpu));
@@ -415,6 +421,9 @@ static int __ref _cpu_down(unsigned int
smp_mb(); /* Read from cpu_dead_idle before __cpu_die(). */
per_cpu(cpu_dead_idle, cpu) = false;
+ /* Interrupts are moved away from the dying cpu, reenable alloc/free */
+ irq_unlock_sparse();
+
hotplug_cpu__broadcast_tick_pull(cpu);
/* This actually kills the CPU. */
__cpu_die(cpu);
@@ -517,8 +526,18 @@ static int _cpu_up(unsigned int cpu, int
goto out_notify;
}
+ /*
+* Some architectures have to walk the irq descriptors to
+* setup the vector space for the cpu which comes online.
+* Prevent irq alloc/free across the bringup.
+*/
+ irq_lock_sparse();
+
/* Arch-specific enabling code. */
ret = __cpu_up(cpu, idle);
+
+ irq_unlock_sparse();
+
if (ret != 0)
goto out_notify;
BUG_ON(!cpu_online(cpu));
Index: tip/kernel/irq/internals.h
===
--- tip.orig/kernel/irq/internals.h
+++ tip/kernel/irq/internals.h
@@ -76,12 +76,8 @@ extern void unmask_threaded_irq(struct i
#ifdef CONFIG_SPARSE_IRQ
static inline void irq_mark_irq(unsigned int irq) { }
-extern void irq_lock_sparse(void);
-extern void irq_unlock_sparse(void);
#else
extern void irq_mark_irq(unsigned int irq);
-static inline void irq_lock_sparse(void) { }
-static inline void irq_unlock_sparse(void) { }
#endif
extern void init_kstat_irqs(struct irq_desc *desc, int node, int nr);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: board: Kconfig: Let STAGING_BOARD depend on CLKDEV_LOOKUP
On Sat, Jul 4, 2015 at 11:35 PM, Chen Gang wrote:
> It needs clk_add_alias() from clk drivers, which is implemented in
> "drivers/clk/clkdev.c" which depends on CLKDEV_LOOKUP.
>
> Normally, archs and clk driver its own will decide whether select
> CLKDEV_LOOKUP, and common drivers will decide whether depend on it.
>
> The related error (with allmodconfig under cris for next-20150702):
>
> drivers/built-in.o: In function `board_staging_register_clock':
> drivers/staging/board/board.c:131: undefined reference to `clk_add_alias'
>
>
> Signed-off-by: Chen Gang
Fix available for the last 15 days:
https://lkml.org/lkml/2015/6/20/215
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] dt-bindings: ARM: Mediatek: Document devicetree bindings for spi bus
Hi, On Mon, Jun 29, 2015 at 3:04 PM, Leilk Liu wrote: > Signed-off-by: Leilk Liu > --- > .../devicetree/bindings/spi/spi-mt65xx.txt | 32 > ++ > 1 file changed, 32 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-mt65xx.txt > > diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt > b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt > new file mode 100644 > index 000..04c28fd > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt > @@ -0,0 +1,32 @@ > +MTK SPI device "SPI device" lets me think "SPI slave device", not "SPI master controller", so maybe call it "MTK SPI Controller"? > + > +Required properties: > +- compatible: should be one of the following. > +- mediatek,mt8173-spi: for mt8173 platforms > +- mediatek,mt8135-spi: for mt8135 platforms > +- mediatek,mt6589-spi: for mt6589 platforms > + > +- reg: Address and length of the register set for the device > + > +- interrupts: Should contain spi interrupt > + > +- clock-names: tuple listing input clock names. > + Required elements: "main" > + > +- clocks: phandles to input clocks. > + > +- pad-select: should specify spi pad used, only required for MT8173. > + This value should be 0~3. AFAIK device-specific non-generic properties should be vendor-prefixed, i.e. it should be "mediatek,pad-select", not just "pad-select". Regards Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:
- Original Message - I NEED YOUR HELP = -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: avoid setting up anonymous pages into file mapping
On 07/05/2015 06:44 PM, Kirill A. Shutemov wrote:
>> Again that could mean a theoretical regression for some in-tree driver,
>> do you know of any such driver?
>
> I did very little testing with the patch: boot kvm with Fedora and run
> trinity there for a while. More testing is required.
>
It seems more likely to be a bug in some obscure real HW driver, then
anything virtualized.
Let me run a quick search and see if I can see any obvious candidates
for this ...
static struct vm_operations_struct gate_vma_ops = {
.name = gate_vma_name,
};
Perhaps it was done for this one
static struct vm_operations_struct mpx_vma_ops = {
.name = mpx_mapping_name,
};
Or this
static const struct vm_operations_struct pci_mmap_ops = {
static const struct vm_operations_struct mmap_mem_ops = {
...
I was looking in-tree for any vm_operations_struct declaration without a .fault
member, there are these above and a slue of HW drivers that only have an .open
and .close so those might populate at open time and never actually ever fault.
Please have a quick look, I did not. I agree about the possible security
badness.
Thanks
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
