[PATCH v2 18/52] x86, intel, uncore: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(_cpu_notifier);
cpu_notifier_register_done();
Fix the uncore code in intel-x86 by using this latter form of callback
registration.
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Signed-off-by: Srivatsa S. Bhat
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 29c2487..83c3c8b 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -3808,7 +3808,7 @@ static int __init uncore_cpu_init(void)
if (ret)
return ret;
- get_online_cpus();
+ cpu_notifier_register_begin();
for_each_online_cpu(cpu) {
int i, phys_id = topology_physical_package_id(cpu);
@@ -3827,9 +3827,9 @@ static int __init uncore_cpu_init(void)
}
on_each_cpu(uncore_cpu_setup, NULL, 1);
- register_cpu_notifier(_cpu_nb);
+ __register_cpu_notifier(_cpu_nb);
- put_online_cpus();
+ cpu_notifier_register_done();
return 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 v2 14/52] powerpc, sysfs: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(_cpu_notifier);
cpu_notifier_register_done();
Fix the sysfs code in powerpc by using this latter form of callback
registration.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Olof Johansson
Cc: Wang Dongsheng
Cc: Ingo Molnar
Cc: linuxppc-...@lists.ozlabs.org
Acked-by: Madhavan Srinivasan
Signed-off-by: Srivatsa S. Bhat
---
arch/powerpc/kernel/sysfs.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 97e1dc9..d90d4b7 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -975,7 +975,8 @@ static int __init topology_init(void)
int cpu;
register_nodes();
- register_cpu_notifier(_cpu_nb);
+
+ cpu_notifier_register_begin();
for_each_possible_cpu(cpu) {
struct cpu *c = _cpu(cpu_devices, cpu);
@@ -999,6 +1000,11 @@ static int __init topology_init(void)
if (cpu_online(cpu))
register_cpu_online(cpu);
}
+
+ __register_cpu_notifier(_cpu_nb);
+
+ cpu_notifier_register_done();
+
#ifdef CONFIG_PPC64
sysfs_create_dscr_default();
#endif /* CONFIG_PPC64 */
--
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 15/52] x86, msr: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(_cpu_notifier);
cpu_notifier_register_done();
Fix the msr code in x86 by using this latter form of callback registration.
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: x...@kernel.org
Signed-off-by: Srivatsa S. Bhat
---
arch/x86/kernel/msr.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 05266b5..c9603ac 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -259,14 +259,15 @@ static int __init msr_init(void)
goto out_chrdev;
}
msr_class->devnode = msr_devnode;
- get_online_cpus();
+
+ cpu_notifier_register_begin();
for_each_online_cpu(i) {
err = msr_device_create(i);
if (err != 0)
goto out_class;
}
- register_hotcpu_notifier(_class_cpu_notifier);
- put_online_cpus();
+ __register_hotcpu_notifier(_class_cpu_notifier);
+ cpu_notifier_register_done();
err = 0;
goto out;
@@ -275,7 +276,7 @@ out_class:
i = 0;
for_each_online_cpu(i)
msr_device_destroy(i);
- put_online_cpus();
+ cpu_notifier_register_done();
class_destroy(msr_class);
out_chrdev:
__unregister_chrdev(MSR_MAJOR, 0, NR_CPUS, "cpu/msr");
@@ -286,13 +287,14 @@ out:
static void __exit msr_exit(void)
{
int cpu = 0;
- get_online_cpus();
+
+ cpu_notifier_register_begin();
for_each_online_cpu(cpu)
msr_device_destroy(cpu);
class_destroy(msr_class);
__unregister_chrdev(MSR_MAJOR, 0, NR_CPUS, "cpu/msr");
- unregister_hotcpu_notifier(_class_cpu_notifier);
- put_online_cpus();
+ __unregister_hotcpu_notifier(_class_cpu_notifier);
+ cpu_notifier_register_done();
}
module_init(msr_init);
--
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 17/52] x86, vsyscall: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(_cpu_notifier);
cpu_notifier_register_done();
Fix the vsyscall code in x86 by using this latter form of callback
registration.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Signed-off-by: Srivatsa S. Bhat
---
arch/x86/kernel/vsyscall_64.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 1f96f93..556eaf2 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -393,9 +393,13 @@ static int __init vsyscall_init(void)
{
BUG_ON(VSYSCALL_ADDR(0) != __fix_to_virt(VSYSCALL_FIRST_PAGE));
+ cpu_notifier_register_begin();
+
on_each_cpu(cpu_vsyscall_init, NULL, 1);
/* notifier priority > KVM */
- hotcpu_notifier(cpu_vsyscall_notifier, 30);
+ __hotcpu_notifier(cpu_vsyscall_notifier, 30);
+
+ cpu_notifier_register_done();
return 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 v2 13/52] sparc, sysfs: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(_cpu_notifier);
cpu_notifier_register_done();
Fix the sysfs code in sparc by using this latter form of callback
registration.
Cc: "David S. Miller"
Cc: Ingo Molnar
Cc: sparcli...@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat
---
arch/sparc/kernel/sysfs.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/sysfs.c b/arch/sparc/kernel/sysfs.c
index c21c673..a364000 100644
--- a/arch/sparc/kernel/sysfs.c
+++ b/arch/sparc/kernel/sysfs.c
@@ -300,7 +300,7 @@ static int __init topology_init(void)
check_mmu_stats();
- register_cpu_notifier(_cpu_nb);
+ cpu_notifier_register_begin();
for_each_possible_cpu(cpu) {
struct cpu *c = _cpu(cpu_devices, cpu);
@@ -310,6 +310,10 @@ static int __init topology_init(void)
register_cpu_online(cpu);
}
+ __register_cpu_notifier(_cpu_nb);
+
+ cpu_notifier_register_done();
+
return 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 v2 09/52] arm, hw-breakpoint: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(_cpu_notifier);
cpu_notifier_register_done();
Fix the hw-breakpoint code in arm by using this latter form of callback
registration.
Cc: Russell King
Cc: Ingo Molnar
Cc: linux-arm-ker...@lists.infradead.org
Acked-by: Will Deacon
Signed-off-by: Srivatsa S. Bhat
---
arch/arm/kernel/hw_breakpoint.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 3d44660..3702de8 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -1072,6 +1072,8 @@ static int __init arch_hw_breakpoint_init(void)
core_num_brps = get_num_brps();
core_num_wrps = get_num_wrps();
+ cpu_notifier_register_begin();
+
/*
* We need to tread carefully here because DBGSWENABLE may be
* driven low on this core and there isn't an architected way to
@@ -1088,6 +1090,7 @@ static int __init arch_hw_breakpoint_init(void)
if (!cpumask_empty(_err_mask)) {
core_num_brps = 0;
core_num_wrps = 0;
+ cpu_notifier_register_done();
return 0;
}
@@ -1107,7 +1110,10 @@ static int __init arch_hw_breakpoint_init(void)
TRAP_HWBKPT, "breakpoint debug exception");
/* Register hotplug and PM notifiers. */
- register_cpu_notifier(_reset_nb);
+ __register_cpu_notifier(_reset_nb);
+
+ cpu_notifier_register_done();
+
pm_init();
return 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 v2 12/52] s390, smp: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(_cpu_notifier);
cpu_notifier_register_done();
Fix the smp code in s390 by using this latter form of callback registration.
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: linux-s...@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat
---
arch/s390/kernel/smp.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index a7125b6..e10be35 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -1057,19 +1057,24 @@ static DEVICE_ATTR(rescan, 0200, NULL, rescan_store);
static int __init s390_smp_init(void)
{
- int cpu, rc;
+ int cpu, rc = 0;
- hotcpu_notifier(smp_cpu_notify, 0);
#ifdef CONFIG_HOTPLUG_CPU
rc = device_create_file(cpu_subsys.dev_root, _attr_rescan);
if (rc)
return rc;
#endif
+ cpu_notifier_register_begin();
for_each_present_cpu(cpu) {
rc = smp_add_present_cpu(cpu);
if (rc)
- return rc;
+ goto out;
}
- return 0;
+
+ __hotcpu_notifier(smp_cpu_notify, 0);
+
+out:
+ cpu_notifier_register_done();
+ return rc;
}
subsys_initcall(s390_smp_init);
--
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 11/52] s390, cacheinfo: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform initialization for the CPUs that are already online, often do it as shown below: get_online_cpus(); for_each_online_cpu(cpu) init_cpu(cpu); register_cpu_notifier(_cpu_notifier); put_online_cpus(); This is wrong, since it is prone to ABBA deadlocks involving the cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently with CPU hotplug operations). Instead, the correct and race-free way of performing the callback registration is: cpu_notifier_register_begin(); for_each_online_cpu(cpu) init_cpu(cpu); /* Note the use of the double underscored version of the API */ __register_cpu_notifier(_cpu_notifier); cpu_notifier_register_done(); Fix the cacheinfo code in s390 by using this latter form of callback registration. Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Ingo Molnar Cc: linux-s...@vger.kernel.org Signed-off-by: Srivatsa S. Bhat --- arch/s390/kernel/cache.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/s390/kernel/cache.c b/arch/s390/kernel/cache.c index 3a414c0..c0b03c2 100644 --- a/arch/s390/kernel/cache.c +++ b/arch/s390/kernel/cache.c @@ -378,9 +378,12 @@ static int __init cache_init(void) if (!test_facility(34)) return 0; cache_build_info(); + + cpu_notifier_register_begin(); for_each_online_cpu(cpu) cache_add_cpu(cpu); - hotcpu_notifier(cache_hotplug, 0); + __hotcpu_notifier(cache_hotplug, 0); + cpu_notifier_register_done(); return 0; } device_initcall(cache_init); -- 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 07/52] ia64, topology: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(_cpu_notifier);
cpu_notifier_register_done();
Fix the topology code in ia64 by using this latter form of callback
registration.
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Ingo Molnar
Cc: linux-i...@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat
---
arch/ia64/kernel/topology.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/ia64/kernel/topology.c b/arch/ia64/kernel/topology.c
index ca69a5a..f295f9a 100644
--- a/arch/ia64/kernel/topology.c
+++ b/arch/ia64/kernel/topology.c
@@ -454,12 +454,16 @@ static int __init cache_sysfs_init(void)
{
int i;
+ cpu_notifier_register_begin();
+
for_each_online_cpu(i) {
struct device *sys_dev = get_cpu_device((unsigned int)i);
cache_add_dev(sys_dev);
}
- register_hotcpu_notifier(_cpu_notifier);
+ __register_hotcpu_notifier(_cpu_notifier);
+
+ cpu_notifier_register_done();
return 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 v2 08/52] ia64, err-inject: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(_cpu_notifier);
cpu_notifier_register_done();
Fix the error injection code in ia64 by using this latter form of callback
registration.
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Ingo Molnar
Cc: linux-i...@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat
---
arch/ia64/kernel/err_inject.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kernel/err_inject.c b/arch/ia64/kernel/err_inject.c
index f59c0b8..0c161ed 100644
--- a/arch/ia64/kernel/err_inject.c
+++ b/arch/ia64/kernel/err_inject.c
@@ -269,12 +269,17 @@ err_inject_init(void)
#ifdef ERR_INJ_DEBUG
printk(KERN_INFO "Enter error injection driver.\n");
#endif
+
+ cpu_notifier_register_begin();
+
for_each_online_cpu(i) {
err_inject_cpu_callback(_inject_cpu_notifier, CPU_ONLINE,
(void *)(long)i);
}
- register_hotcpu_notifier(_inject_cpu_notifier);
+ __register_hotcpu_notifier(_inject_cpu_notifier);
+
+ cpu_notifier_register_done();
return 0;
}
@@ -288,11 +293,17 @@ err_inject_exit(void)
#ifdef ERR_INJ_DEBUG
printk(KERN_INFO "Exit error injection driver.\n");
#endif
+
+ cpu_notifier_register_begin();
+
for_each_online_cpu(i) {
sys_dev = get_cpu_device(i);
sysfs_remove_group(_dev->kobj, _inject_attr_group);
}
- unregister_hotcpu_notifier(_inject_cpu_notifier);
+
+ __unregister_hotcpu_notifier(_inject_cpu_notifier);
+
+ cpu_notifier_register_done();
}
module_init(err_inject_init);
--
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/
use {readl|writel}_relaxed instead of readl/writel in i2c-designware-core ?
Hi all, The writel/readl is too expensive especially on Cortex A9 w/ outer L2 cache. This introduce i2c read/write error on Marvell Berlin SoCs when there are L2 cache maintenance operations at the same time. In our internal berlin bsp, we just replaced readl/writel with the relaxed version. But AFAIK, the "relaxed" version doesn't exist on all architectures. How to handle this issue? Any suggestions are appreciated. Thanks in advance, Jisheng -- 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 06/52] ia64, palinfo: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(_cpu_notifier);
cpu_notifier_register_done();
Fix the palinfo code in ia64 by using this latter form of callback
registration.
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Ingo Molnar
Cc: linux-i...@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat
---
arch/ia64/kernel/palinfo.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/ia64/kernel/palinfo.c b/arch/ia64/kernel/palinfo.c
index ab33328..c39c3cd 100644
--- a/arch/ia64/kernel/palinfo.c
+++ b/arch/ia64/kernel/palinfo.c
@@ -996,13 +996,17 @@ palinfo_init(void)
if (!palinfo_dir)
return -ENOMEM;
+ cpu_notifier_register_begin();
+
/* Create palinfo dirs in /proc for all online cpus */
for_each_online_cpu(i) {
create_palinfo_proc_entries(i);
}
/* Register for future delivery via notify registration */
- register_hotcpu_notifier(_cpu_notifier);
+ __register_hotcpu_notifier(_cpu_notifier);
+
+ cpu_notifier_register_done();
return 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 v2 03/52] Doc/cpu-hotplug: Specify race-free way to register CPU hotplug callbacks
Recommend the usage of the new CPU hotplug callback registration APIs
(__register_cpu_notifier() etc), when subsystems need to also perform
initialization for already online CPUs. Provide examples of correct
and race-free ways of achieving this, and point out the kinds of code
that are error-prone.
Cc: Rob Landley
Cc: Ingo Molnar
Cc: linux-...@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat
---
Documentation/cpu-hotplug.txt | 45 +
1 file changed, 45 insertions(+)
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index be675d2..a0b005d 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -312,12 +312,57 @@ things will happen if a notifier in path sent a BAD
notify code.
Q: I don't see my action being called for all CPUs already up and running?
A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined.
If you need to perform some action for each cpu already in the system, then
+ do this:
for_each_online_cpu(i) {
foobar_cpu_callback(_cpu_notifier, CPU_UP_PREPARE, i);
foobar_cpu_callback(_cpu_notifier, CPU_ONLINE, i);
}
+ However, if you want to register a hotplug callback, as well as perform
+ some initialization for CPUs that are already online, then do this:
+
+ Version 1: (Correct)
+ -
+
+ cpu_notifier_register_begin();
+
+ for_each_online_cpu(i) {
+ foobar_cpu_callback(_cpu_notifier,
+ CPU_UP_PREPARE, i);
+ foobar_cpu_callback(_cpu_notifier,
+ CPU_ONLINE, i);
+ }
+
+ /* Note the use of the double underscored version of the API */
+ __register_cpu_notifier(_cpu_notifier);
+
+ cpu_notifier_register_done();
+
+ Note that the following code is *NOT* the right way to achieve this,
+ because it is prone to an ABBA deadlock between the cpu_add_remove_lock
+ and the cpu_hotplug.lock.
+
+ Version 2: (Wrong!)
+ -
+
+ get_online_cpus();
+
+ for_each_online_cpu(i) {
+ foobar_cpu_callback(_cpu_notifier,
+ CPU_UP_PREPARE, i);
+ foobar_cpu_callback(_cpu_notifier,
+ CPU_ONLINE, i);
+ }
+
+ register_cpu_notifier(_cpu_notifier);
+
+ put_online_cpus();
+
+So always use the first version shown above when you want to register
+callbacks as well as initialize the already online CPUs.
+
+
Q: If i would like to develop cpu hotplug support for a new architecture,
what do i need at a minimum?
A: The following are what is required for CPU hotplug infrastructure to work
--
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 02/52] CPU hotplug: Provide lockless versions of callback registration functions
The following method of CPU hotplug callback registration is not safe
due to the possibility of an ABBA deadlock involving the cpu_add_remove_lock
and the cpu_hotplug.lock.
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
put_online_cpus();
The deadlock is shown below:
CPU 0 CPU 1
- -
Acquire cpu_hotplug.lock
[via get_online_cpus()]
CPU online/offline operation
takes cpu_add_remove_lock
[via cpu_maps_update_begin()]
Try to acquire
cpu_add_remove_lock
[via register_cpu_notifier()]
CPU online/offline operation
tries to acquire cpu_hotplug.lock
[via cpu_hotplug_begin()]
*** DEADLOCK! ***
The problem here is that callback registration takes the locks in one order
whereas the CPU hotplug operations take the same locks in the opposite order.
To avoid this issue and to provide a race-free method to register CPU hotplug
callbacks (along with initialization of already online CPUs), introduce new
variants of the callback registration APIs that simply register the callbacks
without holding the cpu_add_remove_lock during the registration. That way,
we can avoid the ABBA scenario. However, we will need to hold the
cpu_add_remove_lock throughout the entire critical section, to protect updates
to the callback/notifier chain.
This can be achieved by writing the callback registration code as follows:
cpu_maps_update_begin(); [ or cpu_notifier_register_begin(); see below ]
for_each_online_cpu(cpu)
init_cpu(cpu);
/* This doesn't take the cpu_add_remove_lock */
__register_cpu_notifier(_cpu_notifier);
cpu_maps_update_done(); [ or cpu_notifier_register_done(); see below ]
Note that we can't use get_online_cpus() here instead of cpu_maps_update_begin()
because the cpu_hotplug.lock is dropped during the invocation of CPU_POST_DEAD
notifiers, and hence get_online_cpus() cannot provide the necessary
synchronization to protect the callback/notifier chains against concurrent
reads and writes. On the other hand, since the cpu_add_remove_lock protects
the entire hotplug operation (including CPU_POST_DEAD), we can use
cpu_maps_update_begin/done() to guarantee proper synchronization.
Also, since cpu_maps_update_begin/done() is like a super-set of
get/put_online_cpus(), the former naturally protects the critical sections
from concurrent hotplug operations.
Since the names cpu_maps_update_begin/done() don't make much sense in CPU
hotplug callback registration scenarios, we'll introduce new APIs named
cpu_notifier_register_begin/done() and map them to cpu_maps_update_begin/done().
In summary, introduce the lockless variants of un/register_cpu_notifier() and
also export the cpu_notifier_register_begin/done() APIs for use by modules.
This way, we provide a race-free way to register hotplug callbacks as well as
perform initialization for the CPUs that are already online.
Cc: Thomas Gleixner
Cc: Toshi Kani
Cc: "Rafael J. Wysocki"
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Ingo Molnar
Acked-by: Oleg Nesterov
Signed-off-by: Srivatsa S. Bhat
---
include/linux/cpu.h | 47 +++
kernel/cpu.c| 21 +++--
2 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 03e235ad..488d6eb 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -122,26 +122,46 @@ enum {
{ .notifier_call = fn, .priority = pri }; \
register_cpu_notifier(##_nb);\
}
+
+#define __cpu_notifier(fn, pri) { \
+ static struct notifier_block fn##_nb = \
+ { .notifier_call = fn, .priority = pri }; \
+ __register_cpu_notifier(##_nb); \
+}
#else /* #if defined(CONFIG_HOTPLUG_CPU) || !defined(MODULE) */
#define cpu_notifier(fn, pri) do { (void)(fn); } while (0)
+#define __cpu_notifier(fn, pri)do { (void)(fn); } while (0)
#endif /* #else #if defined(CONFIG_HOTPLUG_CPU) || !defined(MODULE) */
+
#ifdef CONFIG_HOTPLUG_CPU
extern int register_cpu_notifier(struct notifier_block *nb);
+extern int __register_cpu_notifier(struct notifier_block *nb);
extern void unregister_cpu_notifier(struct notifier_block *nb);
+extern void __unregister_cpu_notifier(struct notifier_block *nb);
#else
#ifndef MODULE
extern int register_cpu_notifier(struct notifier_block *nb);
+extern int __register_cpu_notifier(struct
[PATCH v2 01/52] CPU hotplug: Add lockdep annotations to get/put_online_cpus()
From: Gautham R. Shenoy
Add lockdep annotations for get/put_online_cpus() and
cpu_hotplug_begin()/cpu_hotplug_end().
Cc: Ingo Molnar
Reviewed-by: Oleg Nesterov
Signed-off-by: Gautham R. Shenoy
Signed-off-by: Srivatsa S. Bhat
---
kernel/cpu.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index deff2e6..33caf5e 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "smpboot.h"
@@ -57,17 +58,30 @@ static struct {
* an ongoing cpu hotplug operation.
*/
int refcount;
+
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
} cpu_hotplug = {
.active_writer = NULL,
.lock = __MUTEX_INITIALIZER(cpu_hotplug.lock),
.refcount = 0,
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ .dep_map = {.name = "cpu_hotplug.lock" },
+#endif
};
+/* Lockdep annotations for get/put_online_cpus() and cpu_hotplug_begin/end() */
+#define cpuhp_lock_acquire_read() lock_map_acquire_read(_hotplug.dep_map)
+#define cpuhp_lock_acquire() lock_map_acquire(_hotplug.dep_map)
+#define cpuhp_lock_release() lock_map_release(_hotplug.dep_map)
+
void get_online_cpus(void)
{
might_sleep();
if (cpu_hotplug.active_writer == current)
return;
+ cpuhp_lock_acquire_read();
mutex_lock(_hotplug.lock);
cpu_hotplug.refcount++;
mutex_unlock(_hotplug.lock);
@@ -87,6 +101,7 @@ void put_online_cpus(void)
if (!--cpu_hotplug.refcount && unlikely(cpu_hotplug.active_writer))
wake_up_process(cpu_hotplug.active_writer);
mutex_unlock(_hotplug.lock);
+ cpuhp_lock_release();
}
EXPORT_SYMBOL_GPL(put_online_cpus);
@@ -117,6 +132,7 @@ void cpu_hotplug_begin(void)
{
cpu_hotplug.active_writer = current;
+ cpuhp_lock_acquire();
for (;;) {
mutex_lock(_hotplug.lock);
if (likely(!cpu_hotplug.refcount))
@@ -131,6 +147,7 @@ void cpu_hotplug_done(void)
{
cpu_hotplug.active_writer = NULL;
mutex_unlock(_hotplug.lock);
+ cpuhp_lock_release();
}
/*
--
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 00/52] CPU hotplug: Fix issues with callback registration
Hi, Many subsystems and drivers have the need to register CPU hotplug callbacks from their init routines and also perform initialization for the CPUs that are already online. But unfortunately there is no race-free way to achieve this today. For example, consider this piece of code: get_online_cpus(); for_each_online_cpu(cpu) init_cpu(cpu); register_cpu_notifier(_cpu_notifier); put_online_cpus(); This is not safe because there is a possibility of an ABBA deadlock involving the cpu_add_remove_lock and the cpu_hotplug.lock. CPU 0 CPU 1 - - Acquire cpu_hotplug.lock [via get_online_cpus()] CPU online/offline operation takes cpu_add_remove_lock [via cpu_maps_update_begin()] Try to acquire cpu_add_remove_lock [via register_cpu_notifier()] CPU online/offline operation tries to acquire cpu_hotplug.lock [via cpu_hotplug_begin()] *** DEADLOCK! *** Other combinations of callback registration also don't work correctly. Examples: register_cpu_notifier(_cpu_notifier); get_online_cpus(); for_each_online_cpu(cpu) init_cpu(cpu); put_online_cpus(); This can lead to double initialization if a hotplug operation occurs after registering the notifier and before invoking get_online_cpus(). On the other hand, the following piece of code can miss hotplug events altogether: get_online_cpus(); for_each_online_cpu(cpu) init_cpu(cpu); put_online_cpus(); ^ | Race window; Can miss hotplug events here v register_cpu_notifier(_cpu_notifier); To solve these issues and provide a race-free method to register CPU hotplug callbacks, this patchset introduces new variants of the callback registration APIs that don't hold the cpu_add_remove_lock, and exports the cpu_add_remove_lock via 2 new APIs cpu_notifier_register_begin/done() for use by various subsystems. With this in place, the following code snippet will register a hotplug callback as well as initialize already online CPUs without any race conditions. cpu_notifier_register_begin(); for_each_online_cpu(cpu) init_cpu(cpu); /* This doesn't take the cpu_add_remove_lock */ __register_cpu_notifier(_cpu_notifier); cpu_notifier_register_done(); In this patchset, patch 1 adds lockdep annotations to catch the above mentioned deadlock scenario. Patch 2 introduces the new APIs and infrastructure necessary for race-free callback registration. The remaining patches perform tree-wide conversions (to use this model). This patchset has been hosted in the below git tree. It applies cleanly on v3.14-rc1. git://github.com/srivatsabhat/linux.git cpuhp-registration-fixes-v2 Gautham R. Shenoy (1): CPU hotplug: Add lockdep annotations to get/put_online_cpus() Srivatsa S. Bhat (51): CPU hotplug: Provide lockless versions of callback registration functions Doc/cpu-hotplug: Specify race-free way to register CPU hotplug callbacks CPU hotplug, perf: Fix CPU hotplug callback registration ia64, salinfo: Fix hotplug callback registration ia64, palinfo: Fix CPU hotplug callback registration ia64, topology: Fix CPU hotplug callback registration ia64, err-inject: Fix CPU hotplug callback registration arm, hw-breakpoint: Fix CPU hotplug callback registration arm, kvm: Fix CPU hotplug callback registration s390, cacheinfo: Fix CPU hotplug callback registration s390, smp: Fix CPU hotplug callback registration sparc, sysfs: Fix CPU hotplug callback registration powerpc, sysfs: Fix CPU hotplug callback registration x86, msr: Fix CPU hotplug callback registration x86, cpuid: Fix CPU hotplug callback registration x86, vsyscall: Fix CPU hotplug callback registration x86, intel, uncore: Fix CPU hotplug callback registration x86, mce: Fix CPU hotplug callback registration x86, therm_throt.c: Fix CPU hotplug callback registration x86, therm_throt.c: Remove unused therm_cpu_lock x86, amd, ibs: Fix CPU hotplug callback registration x86, intel, cacheinfo: Fix CPU hotplug callback registration x86, intel, rapl: Fix CPU hotplug callback registration x86, amd, uncore: Fix CPU hotplug callback registration x86, hpet: Fix CPU hotplug callback registration x86, pci, amd-bus: Fix CPU hotplug callback registration x86, oprofile, nmi: Fix CPU hotplug callback registration x86,
Re: [PATCH v15 0/10] Add 32 bit VDSO time function support
On 02/13/2014 11:48 PM, Stefani Seibold wrote: > Am Donnerstag, den 13.02.2014, 22:47 -0800 schrieb H. Peter Anvin: >> Hi, >> >> I tried this patchset, but it fails to compile on i386 "make allyesconfig". >> >> -hpa >> > > I tried "make allyseconfig" on my i386, but the resulting config will > always set CONFIG_X86_64=y, so it fails with "make ARCH=i386 allyesconfig" ... will do it for you. > scripts/mod/empty.c:1:0: error: CPU you selected does not support x86-64 > instruction set > > Setting to CONFIG_X86_32 by hand will allow to compile but fails in > vclock_gettime.c, because CONFIG_PARAVIRT_CLOCK is not supported for by > a 32 bit VDSO. Right, this is the problem here. Keep in mind many shipping kernels will have CONFIG_PARAVIRT_CLOCK enabled, so it matters that a PV kernel *booting native* doesn't take an unnecessary hit. > PARAVIRT_CLOCK and getcpu is an other topic which is not addressed by > this patch set. > > I will do a patch to fix this. Thanks. -hpa -- 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 v15 0/10] Add 32 bit VDSO time function support
Am Donnerstag, den 13.02.2014, 22:47 -0800 schrieb H. Peter Anvin: > Hi, > > I tried this patchset, but it fails to compile on i386 "make allyesconfig". > > -hpa > I tried "make allyseconfig" on my i386, but the resulting config will always set CONFIG_X86_64=y, so it fails with scripts/mod/empty.c:1:0: error: CPU you selected does not support x86-64 instruction set Setting to CONFIG_X86_32 by hand will allow to compile but fails in vclock_gettime.c, because CONFIG_PARAVIRT_CLOCK is not supported for by a 32 bit VDSO. PARAVIRT_CLOCK and getcpu is an other topic which is not addressed by this patch set. I will do a patch to fix this. - Stefani -- 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 07/14] regulator: s2mps11: Copy supported regulators from initconst
On Thu, 2014-02-13 at 19:07 +, Mark Brown wrote: > On Thu, Feb 13, 2014 at 10:14:00AM +0100, Krzysztof Kozlowski wrote: > > > - for (i = 0; i < S2MPS11_REGULATOR_CNT; i++) > > + s2mps11->rdev = devm_kzalloc(>dev, > > + sizeof(*s2mps11->rdev)*rdev_num, GFP_KERNEL); > > + if (!s2mps11->rdev) > > + return -ENOMEM; > > If we're using managed allocations do we actually need to keep the rdev > table at all? We only normally use it to free. You're right, the "s2mps11->rdev" is not needed at all. > > > + rdata = devm_kzalloc(>dev, sizeof(*rdata)*rdev_num, GFP_KERNEL); > > + if (!rdata) > > + return -ENOMEM; > > + > > > + /* rdata was needed only for of_regulator_match() during probe */ > > + if (rdata) > > + devm_kfree(>dev, rdata); > > + > > If this is always going to be freed within the probe path (in the same > function indeed) why is it a managed allocaton at all? Actually no good reason, simplifies a little the return statements on error conditions. I'll use kzalloc() and kfree(). 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: [RFC PATCH V5] mm readahead: Fix readahead fail for no local memory and limit readahead pages
On Thu 13-02-14 16:37:53, Linus Torvalds wrote:
> Is this whole thread still just for the crazy and pointless
> "max_sane_readahead()"?
>
> Or is there some *real* reason we should care?
>
> Because if it really is just for max_sane_readahead(), then for the
> love of God, let us just do this
>
> unsigned long max_sane_readahead(unsigned long nr)
> {
> return min(nr, 128);
> }
>
> and bury this whole idiotic thread.
max_sane_readahead() is also used for limiting amount of readahead for
[fm]advice(2) WILLNEED and that is used e.g. by a dynamic linker to preload
shared libraries into memory. So I'm convinced this usecase *will* notice
the change - effectively we limit preloading of shared libraries to the
first 512KB in the file but libraries get accessed in a rather random manner.
Maybe limits for WILLNEED and for standard readahead should be different.
It makes sence to me and people seem to keep forgetting that
max_sane_readahead() limits also WILLNEED preloading.
Honza
> On Thu, Feb 13, 2014 at 4:14 PM, Nishanth Aravamudan
> wrote:
> >
> > I'm working on this latter bit now. I tried to mirror ia64, but it looks
> > like they have CONFIG_USER_PERCPU_NUMA_NODE_ID, which powerpc doesn't.
> > It seems like CONFIG_USER_PERCPU_NUMA_NODE_ID and
> > CONFIG_HAVE_MEMORYLESS_NODES should be tied together in Kconfig?
> >
> > I'll keep working, but would appreciate any further insight.
> >
> > -Nish
> >
--
Jan Kara
SUSE Labs, CR
--
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] printk: fix one circular lockdep warning about console_lock
On 02/12/2014 05:19 AM, Andrew Morton wrote: There are three locks involved in two sequence: a) pm suspend: console_lock (@suspend_console()) cpu_add_remove_lock (@disable_nonboot_cpus()) cpu_hotplug.lock (@_cpu_down()) But but but. suspend_console() releases console_sem again. Console_lock does not refer to console_sem but console_lock_dep_map. Its name is console_lock. Suspend_console() does not release console_lock_dep_map. So the sequence is actually down(_sem) (@suspend_console()) acquire(_lock_dep_map) (_console()) up(_sem) (@suspend_console()) cpu_add_remove_lock (@disable_nonboot_cpus()) cpu_hotplug.lock (@_cpu_down()) So console_sem *doesn't* nest outside cpu_add_remove_lock and cpu_hotplug.lock. Add console_lock in the sequence. b) Plug-out CPUx: cpu_add_remove_lock (@(cpu_down()) cpu_hotplug.lock (@_cpu_down()) console_lock (@console_cpu_notify()) => Lockdeps prints warning log. There should be not real deadlock, as flag of console_suspended can protect this. console_lock() does down(_sem) *before* testing console_suspended, so I don't understand this sentence - a more detailed description would help. After suspend_console(), console_sem is unlocked, but console_lock_dep_map has been acquired. Best Regards, Jane -- 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 09/14] regulator: s2mps11: Add support for S2MPS14 regulators
On Thu, 2014-02-13 at 19:10 +, Mark Brown wrote: > On Thu, Feb 13, 2014 at 10:14:02AM +0100, Krzysztof Kozlowski wrote: > > Add support for S2MPS14 PMIC regulators to s2mps11 driver. The S2MPS14 > > has fewer BUCK-s and LDO-s than S2MPS11. It also does not support > > controlling the BUCK ramp delay. > > How different are the other Samsung PMICs? They share the core driver > code and this makes the driver more parameterisable so perhaps it means > the others could be merged in here too. With some effort the s2mps11 and s5m8767 regulator drivers can be merged. The s5m8767 shares most of the features with s2mps11 and adds some new stuff (i.e. GPIO control over BUCK DVS, low power mode for opmode). Anyway it was easier to add support for S2MPS14 to S2MPS11 than to merge everything now. -- 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/6] fat: add fat_fallocate operation
Namjae Jeon writes:
>>> [...]
>>>
+ /* Release unwritten fallocated blocks on inode eviction. */
+ if (MSDOS_I(inode)->mmu_private < MSDOS_I(inode)->i_disksize) {
+ int err;
+ fat_truncate_blocks(inode, MSDOS_I(inode)->mmu_private);
+ /* Fallocate results in updating the i_start/iogstart
+ * for the zero byte file. So, make it return to
+ * original state during evict and commit it
+ * synchrnously to avoid any corruption on the next
+ * access to the cluster chain for the file.
+ */
+ err = fat_sync_inode(inode);
>>>
>>> Ah, good catch. We have to update i_size. I was forgetting about this.
>>> Well, sync inode unconditionally would not be good. Maybe, we better to
>>> use __fat_write_inode() with inode_needs_sync() or such.
>> Okay, I will change it.
> Hi OGAWA
>
> When I checked more, we should wait till inode is sync. Because in the
> eviction it will leave the inode/buffers being marked dirty.
> Not waiting for it get sync over here. It will leave cluster chain
> corrupted when remounting.
> It mean we cannot use __fat_write_inode with inode_needs_sync() conditionally.
Yeah, this situation bothers us. However, the inode is not marked as
dirty after I_FREEING. And in fatfs case, all related dirty buffers
should goes into blockdev inode buffers (i.e. metadata only), right?
So, I thought sync is not necessary.
Thanks.
--
OGAWA Hirofumi
--
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] x86, efi: Fix 32-bit fallout
From: Borislav Petkov
We do not enable the new efi memmap on 32-bit and thus we need to run
runtime_code_page_mkexec() unconditionally there. Fix that.
Reported-and-tested-by: Lejun Zhu
Cc: # v3.14+
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/efi.h | 2 ++
arch/x86/platform/efi/efi.c| 8 +++-
arch/x86/platform/efi/efi_32.c | 6 ++
arch/x86/platform/efi/efi_64.c | 9 +
4 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index d3c099f53ff2..7fd9830285e0 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -133,6 +133,8 @@ extern int efi_setup_page_tables(unsigned long pa_memmap,
unsigned num_pages);
extern void efi_cleanup_page_tables(unsigned long pa_memmap, unsigned
num_pages);
extern void __init old_map_region(efi_memory_desc_t *md);
extern void __init efi_dump_pagetable(void);
+extern void __init runtime_code_page_mkexec(void);
+extern void __init efi_runtime_mkexec(void);
struct efi_setup_data {
u64 fw_vendor;
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 0c8672b3f9a3..40e62ea52864 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -776,7 +776,7 @@ void __init efi_set_executable(efi_memory_desc_t *md, bool
executable)
set_memory_nx(addr, npages);
}
-static void __init runtime_code_page_mkexec(void)
+void __init runtime_code_page_mkexec(void)
{
efi_memory_desc_t *md;
void *p;
@@ -1024,8 +1024,7 @@ static void __init kexec_enter_virtual_mode(void)
efi.update_capsule = virt_efi_update_capsule;
efi.query_capsule_caps = virt_efi_query_capsule_caps;
- if (efi_enabled(EFI_OLD_MEMMAP) && (__supported_pte_mask & _PAGE_NX))
- runtime_code_page_mkexec();
+ efi_runtime_mkexec();
/* clean DUMMY object */
efi.set_variable(efi_dummy_name, _DUMMY_GUID,
@@ -1125,8 +1124,7 @@ static void __init __efi_enter_virtual_mode(void)
efi.update_capsule = virt_efi_update_capsule;
efi.query_capsule_caps = virt_efi_query_capsule_caps;
- if (efi_enabled(EFI_OLD_MEMMAP) && (__supported_pte_mask & _PAGE_NX))
- runtime_code_page_mkexec();
+ efi_runtime_mkexec();
/*
* We mapped the descriptor array into the EFI pagetable above but we're
diff --git a/arch/x86/platform/efi/efi_32.c b/arch/x86/platform/efi/efi_32.c
index 7ad87ee09525..9ee3491e31fb 100644
--- a/arch/x86/platform/efi/efi_32.c
+++ b/arch/x86/platform/efi/efi_32.c
@@ -82,3 +82,9 @@ void efi_call_phys_epilog(void)
local_irq_restore(efi_rt_eflags);
}
+
+void __init efi_runtime_mkexec(void)
+{
+ if (__supported_pte_mask & _PAGE_NX)
+ runtime_code_page_mkexec();
+}
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 0998f3a536ff..50cc39be2271 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -268,3 +268,12 @@ void __init efi_dump_pagetable(void)
ptdump_walk_pgd_level(NULL, pgd);
#endif
}
+
+void __init efi_runtime_mkexec(void)
+{
+ if (!efi_enabled(EFI_OLD_MEMMAP))
+ return;
+
+ if (__supported_pte_mask & _PAGE_NX)
+ runtime_code_page_mkexec();
+}
--
1.8.5.2.192.g7794a68
--
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,bonding: fix bond_options.c direct rwlock.h include
drivers/net/bonding/bond_options.c includes rwlock.h directly, which is a nono, and which also breaks RT kernel build. Signed-off-by: Mike Galbraith --- diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c index 11cb943222d5..c37878432717 100644 --- a/drivers/net/bonding/bond_options.c +++ b/drivers/net/bonding/bond_options.c @@ -14,7 +14,7 @@ #include #include #include -#include +#include #include #include #include -- 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: [BUG] perf report/annotate: consuming too many file descriptors
Hi Stephane,
On Thu, 13 Feb 2014 17:26:30 +0100, Stephane Eranian wrote:
> Hi,
>
> Your patch does solve the file consumption problem on my test case.
> We still open and do the ELF read 5 times.
>>> The first problem is why is dso__read_binary_type_filename()
>>> blindly returning success on many types. For my files, I got matches
>>> on DEBUGLINK, SYSTEM_DSO_PATH, GUEST_KMODULE,
>>> SYSTEM_PATH_KMODULE.
Hmm.. the dso__read_binary_type_filename() will be called for either of
user binaries or kernel modules. But for each binary, it's pointless to
check both types of symtab since it can only have one type.
So I think we should try SYMTEM_PATH_DSO, DEBUGLINK, BUILD_ID_CACHE and
a couple of DEBUGINFOs for user binaries, and only try *_KMODULE for
kernel modules. This way, we can reduce the unnecessary open and ELF
reading/parsing time.
Could you please test following patch also?
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index a9d758a3b371..303b8dc59dd8 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1251,6 +1251,46 @@ out_failure:
return -1;
}
+static bool dso__is_compatible_symtab_type(struct dso *dso, bool kmod,
+ enum dso_binary_type type)
+{
+ switch (type) {
+ case DSO_BINARY_TYPE__JAVA_JIT:
+ case DSO_BINARY_TYPE__DEBUGLINK:
+ case DSO_BINARY_TYPE__SYSTEM_PATH_DSO:
+ case DSO_BINARY_TYPE__FEDORA_DEBUGINFO:
+ case DSO_BINARY_TYPE__UBUNTU_DEBUGINFO:
+ case DSO_BINARY_TYPE__BUILDID_DEBUGINFO:
+ case DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO:
+ return !kmod && dso->kernel == DSO_TYPE_USER;
+
+ case DSO_BINARY_TYPE__KALLSYMS:
+ case DSO_BINARY_TYPE__VMLINUX:
+ case DSO_BINARY_TYPE__KCORE:
+ return dso->kernel == DSO_TYPE_KERNEL;
+
+ case DSO_BINARY_TYPE__GUEST_KALLSYMS:
+ case DSO_BINARY_TYPE__GUEST_VMLINUX:
+ case DSO_BINARY_TYPE__GUEST_KCORE:
+ return dso->kernel == DSO_TYPE_GUEST_KERNEL;
+
+ case DSO_BINARY_TYPE__GUEST_KMODULE:
+ case DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE:
+ /*
+* kernel modules know their symtab type - it's set when
+* creating a module dso in machine__new_module().
+*/
+ return kmod && dso->symtab_type == type;
+
+ case DSO_BINARY_TYPE__BUILD_ID_CACHE:
+ return true;
+
+ case DSO_BINARY_TYPE__NOT_FOUND:
+ default:
+ return false;
+ }
+}
+
int dso__load(struct dso *dso, struct map *map, symbol_filter_t filter)
{
char *name;
@@ -1261,6 +1301,7 @@ int dso__load(struct dso *dso, struct map *map,
symbol_filter_t filter)
int ss_pos = 0;
struct symsrc ss_[2];
struct symsrc *syms_ss = NULL, *runtime_ss = NULL;
+ bool kmod;
dso__set_loaded(dso, map->type);
@@ -1301,7 +1342,11 @@ int dso__load(struct dso *dso, struct map *map,
symbol_filter_t filter)
if (!name)
return -1;
- /* Iterate over candidate debug images.
+ kmod = dso->symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE ||
+ dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE;
+
+ /*
+* Iterate over candidate debug images.
* Keep track of "interesting" ones (those which have a symtab, dynsym,
* and/or opd section) for processing.
*/
@@ -1311,6 +1356,9 @@ int dso__load(struct dso *dso, struct map *map,
symbol_filter_t filter)
enum dso_binary_type symtab_type = binary_type_symtab[i];
+ if (!dso__is_compatible_symtab_type(dso, kmod, symtab_type))
+ continue;
+
if (dso__read_binary_type_filename(dso, symtab_type,
root_dir, name, PATH_MAX))
continue;
@@ -1351,15 +1399,10 @@ int dso__load(struct dso *dso, struct map *map,
symbol_filter_t filter)
if (!runtime_ss && syms_ss)
runtime_ss = syms_ss;
- if (syms_ss) {
- int km;
-
- km = dso->symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE ||
-dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE;
- ret = dso__load_sym(dso, map, syms_ss, runtime_ss, filter, km);
- } else {
+ if (syms_ss)
+ ret = dso__load_sym(dso, map, syms_ss, runtime_ss, filter,
kmod);
+ else
ret = -1;
- }
if (ret > 0) {
int nr_plt;
--
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: [Regression 3.14-rc2] drm/i915: Brightness adjustment is broken in 945GM
On Thu, 13 Feb 2014, Luis Ortega wrote: > On Thu, Feb 13, 2014 at 05:24:23PM +0100, Luis Ortega wrote: >> > I dare say either your bisect went sour or you don't have 945GM. Please >> > verify your steps. >> >> Well, what can I say? I was careful when testing and the last kernel I >> compiled >> shows the problem. I can replay the bisection if needed but if I have to >> start >> all over again it's gonna take some time. I'm compiling in the netbook and >> took >> me day and a half to finish the process. >> >> In all honesty, along the way I met commit messages that I thought were more >> probable to introduce this regression. (backlight related) >> >> Also, here's the output of lspci: >> 00:00.0 Host bridge: Intel Corporation Mobile 945GSE Express Memory >> Controller Hub (rev 03) >> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GSE Express >> Integrated Graphics Controller (rev 03) >> 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, >> 943/940GML Express Integrated Graphics Controller (rev 03) >> >> > Please provide dmesg with drm.debug=0xe with 3.14-rc2. >> >> Care to explain a bit more before I recompile 3.14-rc2? Do I need to >> enable some particular debug option? How do I proceed for drm.debug=0xe? >> >> >> Luis >> > On Thu, Feb 13, 2014 at 05:04:23PM +0200, Jani Nikula wrote: >> > On Thu, 13 Feb 2014, Luis Ortega wrote: >> > > Hi, testing 3.14-rc2 I noticed I could not adjust the brightness of the >> > > screen any longer. This problem is already present in 3.14-rc1. 3.13 >> > > works fine. >> > > >> > > My hardware is a netbook with intel atom and a 945GM graphics card. >> > > >> > > I bisected the problem down to the next commit: >> > >> > I dare say either your bisect went sour or you don't have 945GM. Please >> > verify your steps. >> > >> > Please provide dmesg with drm.debug=0xe with 3.14-rc2. >> > >> > BR, >> > Jani. >> > >> > > >> > > bc0bb9fd1c7810407ab810d204bbaecb255fddde is the first bad commit >> > > commit bc0bb9fd1c7810407ab810d204bbaecb255fddde >> > > Author: Jani Nikula >> > > Date: Thu Nov 14 12:14:29 2013 +0200 >> > > >> > > drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE >> > > >> > > The quirk was added as what I'd say was a stopgap measure in >> > > >> > > commit e85843bec6c2ea7c10ec61238396891cc2b753a9 >> > > Author: Kamal Mostafa >> > > Date: Fri Jul 19 15:02:01 2013 -0700 >> > > >> > > drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight >> > > >> > > without really digging into what was going on. >> > > >> > > Also, as mentioned in the related bug [1], having the quirk regressed >> > > some of the machines it was supposed to fix to begin with, and there >> > > were patches posted to disable the quirk on such machines [2]! >> > > >> > > The fact is, we do need the BLM_PCH_PWM_ENABLE bit set to have >> > > backlight. With the quirk, we've relied on BIOS to have set it, and >> > > our >> > > save/restore code to retain it. With the full backlight setup at >> > > enable, >> > > we have no place for things that rely on previous state. >> > > >> > > With the per platform hooks, we've also made a change in the PCH >> > > platform enable order: setting the backlight duty cycle between CPU >> > > and >> > > PCH PWM enable. Some experimenting and >> > > >> > > commit 770c12312ad617172b1a65b911d3e6564fc5aca8 >> > > Author: Takashi Iwai >> > > Date: Sat Aug 11 08:56:42 2012 +0200 >> > > >> > > drm/i915: Fix blank panel at reopening lid >> > > >> > > indicate that we can't set the backlight before enabling CPU PWM; the >> > > value just won't stick. But AFAICT we should do it before enabling >> > > the >> > > PCH PWM. >> > > >> > > Finally, any fallout we should fix properly, preferrably without >> > > quirks, >> > > and absolutely without quirks that rely on existing state. With the >> > > per >> > > platform hooks have much more flexibility to adjust the sequence as >> > > required by platforms. >> > > >> > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=47941 >> > > [2] >> > > http://lkml.kernel.org/r/1378229848-29113-1-git-send-email-ka...@canonical.com >> > > >> > > Signed-off-by: Jani Nikula >> > > Reviewed-by: Imre Deak >> > > Signed-off-by: Daniel Vetter >> > > >> > > >> > > Additionally, when I had narrowed the problem to around 11 commits all >> > > the >> > > resulting kernel I compiled made the screen blink and shake from left to >> > > right >> > > non-stop. In the -rc kernels this doesn't happen. Thought it was worth >> > > mentioning. >> > >> > >> > -- >> > Jani Nikula, Intel Open Source Technology Center > >> Please provide dmesg with drm.debug=0xe with 3.14-rc2. > > I've booted with the kernel args drm.debug=0xe log_buf_len=16M. > I've attached the following files for your inspection: > >
Re: [lm-sensors] [RFC PATCH] hwmon: (max6650) Convert to be a platform driver
On Thu, Feb 13, 2014 at 12:40 PM, Lee Jones wrote: >> http://comments.gmane.org/gmane.linux.kernel/1645251 >> >> Step 2 did not happen. I did not get any review for my change. I >> literally submitted that within a couple of hours after the request. >> >> Could you please tell me what was wrong with that change, and why I >> did not get any respect not to "xargs rm -rf" my work in that area? I >> believe I was ignored instead of improving the change, and someone >> else tried to address the same thing. There was no argument in that >> thread. It was a technical change. I personally do not feel happy >> about it. > > Let's start again. > > Rebase your work on top of the HWMON tree on kernel.org and resubmit > the entire set. If rebasing takes you more than 20 mins, you're > probably doing it wrong. I tried, but I could not manage it within 20 minutes, so I guess I am doing something wrong. Can you please provide some pointers how not to do it wrong? Perhaps, I am not aware of some tricks. -- 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/9] slab: move up code to get kmem_cache_node in free_block()
node isn't changed, so we don't need to retreive this structure
everytime we move the object. Maybe compiler do this optimization,
but making it explicitly is better.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index 6d17cad..53d1a36 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3361,6 +3361,7 @@ static void free_block(struct kmem_cache *cachep, void
**objpp, int nr_objects,
int i;
struct kmem_cache_node *n;
+ n = cachep->node[node];
for (i = 0; i < nr_objects; i++) {
void *objp;
struct page *page;
@@ -3368,7 +3369,6 @@ static void free_block(struct kmem_cache *cachep, void
**objpp, int nr_objects,
objp = clear_obj_pfmemalloc(objpp[i]);
page = virt_to_head_page(objp);
- n = cachep->node[node];
list_del(>lru);
check_spinlock_acquired_node(cachep, node);
slab_put_obj(cachep, page, objp, node);
--
1.7.9.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 0/9] clean-up and remove lockdep annotation in SLAB
This patchset does some clean-up and tries to remove lockdep annotation. Patches 1~3 are just for really really minor improvement. Patches 4~9 are for clean-up and removing lockdep annotation. There are two cases that lockdep annotation is needed in SLAB. 1) holding two node locks 2) holding two array cache(alien cache) locks I looked at the code and found that we can avoid these cases without any negative effect. 1) occurs if freeing object makes new free slab and we decide to destroy it. Although we don't need to hold the lock during destroying a slab, current code do that. Destroying a slab without holding the lock would help the reduction of the lock contention. To do it, I change the implementation that new free slab is destroyed after releasing the lock. 2) occurs on similar situation. When we free object from non-local node, we put this object to alien cache with holding the alien cache lock. If alien cache is full, we try to flush alien cache to proper node cache, and, in this time, new free slab could be made. Destroying it would be started and we will free metadata object which comes from another node. In this case, we need another node's alien cache lock to free object. This forces us to hold two array cache locks and then we need lockdep annotation although they are always different locks and deadlock cannot be possible. To prevent this situation, I use same way as 1). In this way, we can avoid 1) and 2) cases, and then, can remove lockdep annotation. As short stat noted, this makes SLAB code much simpler. This patchset is based on slab/next branch on Pekka's git tree. git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git Thanks. Joonsoo Kim (9): slab: add unlikely macro to help compiler slab: makes clear_obj_pfmemalloc() just return store masked value slab: move up code to get kmem_cache_node in free_block() slab: defer slab_destroy in free_block() slab: factor out initialization of arracy cache slab: introduce alien_cache slab: use the lock on alien_cache, instead of the lock on array_cache slab: destroy a slab without holding any alien cache lock slab: remove a useless lockdep annotation mm/slab.c | 384 ++--- mm/slab.h |2 +- 2 files changed, 138 insertions(+), 248 deletions(-) -- 1.7.9.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 5/9] slab: factor out initialization of arracy cache
Factor out initialization of array cache to use it in following patch.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index 551d503..90bfd79 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -741,13 +741,8 @@ static void start_cpu_timer(int cpu)
}
}
-static struct array_cache *alloc_arraycache(int node, int entries,
- int batchcount, gfp_t gfp)
+static void init_arraycache(struct array_cache *ac, int limit, int batch)
{
- int memsize = sizeof(void *) * entries + sizeof(struct array_cache);
- struct array_cache *nc = NULL;
-
- nc = kmalloc_node(memsize, gfp, node);
/*
* The array_cache structures contain pointers to free object.
* However, when such objects are allocated or transferred to another
@@ -755,15 +750,25 @@ static struct array_cache *alloc_arraycache(int node, int
entries,
* valid references during a kmemleak scan. Therefore, kmemleak must
* not scan such objects.
*/
- kmemleak_no_scan(nc);
- if (nc) {
- nc->avail = 0;
- nc->limit = entries;
- nc->batchcount = batchcount;
- nc->touched = 0;
- spin_lock_init(>lock);
+ kmemleak_no_scan(ac);
+ if (ac) {
+ ac->avail = 0;
+ ac->limit = limit;
+ ac->batchcount = batch;
+ ac->touched = 0;
+ spin_lock_init(>lock);
}
- return nc;
+}
+
+static struct array_cache *alloc_arraycache(int node, int entries,
+ int batchcount, gfp_t gfp)
+{
+ int memsize = sizeof(void *) * entries + sizeof(struct array_cache);
+ struct array_cache *ac = NULL;
+
+ ac = kmalloc_node(memsize, gfp, node);
+ init_arraycache(ac, entries, batchcount);
+ return ac;
}
static inline bool is_slab_pfmemalloc(struct page *page)
--
1.7.9.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 6/9] slab: introduce alien_cache
Currently, we use array_cache for alien_cache. Although they are mostly
similar, there is one difference, that is, need for spinlock.
We don't need spinlock for array_cache itself, but to use array_cache for
alien_cache, array_cache structure should have spinlock. This is needless
overhead, so removing it would be better. This patch prepare it by
introducing alien_cache and using it. In the following patch,
we remove spinlock in array_cache.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index 90bfd79..c048ac5 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -203,6 +203,11 @@ struct array_cache {
*/
};
+struct alien_cache {
+ spinlock_t lock;
+ struct array_cache ac;
+};
+
#define SLAB_OBJ_PFMEMALLOC1
static inline bool is_obj_pfmemalloc(void *objp)
{
@@ -458,7 +463,7 @@ static void slab_set_lock_classes(struct kmem_cache *cachep,
struct lock_class_key *l3_key, struct lock_class_key *alc_key,
int q)
{
- struct array_cache **alc;
+ struct alien_cache **alc;
struct kmem_cache_node *n;
int r;
@@ -479,7 +484,7 @@ static void slab_set_lock_classes(struct kmem_cache *cachep,
return;
for_each_node(r) {
if (alc[r])
- lockdep_set_class([r]->lock, alc_key);
+ lockdep_set_class(&(alc[r]->ac.lock), alc_key);
}
}
@@ -915,12 +920,13 @@ static int transfer_objects(struct array_cache *to,
#define drain_alien_cache(cachep, alien) do { } while (0)
#define reap_alien(cachep, n) do { } while (0)
-static inline struct array_cache **alloc_alien_cache(int node, int limit,
gfp_t gfp)
+static inline struct alien_cache **alloc_alien_cache(int node,
+ int limit, gfp_t gfp)
{
- return (struct array_cache **)BAD_ALIEN_MAGIC;
+ return (struct alien_cache **)BAD_ALIEN_MAGIC;
}
-static inline void free_alien_cache(struct array_cache **ac_ptr)
+static inline void free_alien_cache(struct alien_cache **ac_ptr)
{
}
@@ -946,40 +952,52 @@ static inline void *cache_alloc_node(struct
kmem_cache *cachep,
static void *cache_alloc_node(struct kmem_cache *, gfp_t, int);
static void *alternate_node_alloc(struct kmem_cache *, gfp_t);
-static struct array_cache **alloc_alien_cache(int node, int limit, gfp_t gfp)
+static struct alien_cache *__alloc_alien_cache(int node, int entries,
+ int batch, gfp_t gfp)
+{
+ int memsize = sizeof(void *) * entries + sizeof(struct alien_cache);
+ struct alien_cache *alc = NULL;
+
+ alc = kmalloc_node(memsize, gfp, node);
+ init_arraycache(>ac, entries, batch);
+ return alc;
+}
+
+static struct alien_cache **alloc_alien_cache(int node, int limit, gfp_t gfp)
{
- struct array_cache **ac_ptr;
+ struct alien_cache **alc_ptr;
int memsize = sizeof(void *) * nr_node_ids;
int i;
if (limit > 1)
limit = 12;
- ac_ptr = kzalloc_node(memsize, gfp, node);
- if (ac_ptr) {
- for_each_node(i) {
- if (i == node || !node_online(i))
- continue;
- ac_ptr[i] = alloc_arraycache(node, limit, 0xbaadf00d,
gfp);
- if (!ac_ptr[i]) {
- for (i--; i >= 0; i--)
- kfree(ac_ptr[i]);
- kfree(ac_ptr);
- return NULL;
- }
+ alc_ptr = kzalloc_node(memsize, gfp, node);
+ if (!alc_ptr)
+ return NULL;
+
+ for_each_node(i) {
+ if (i == node || !node_online(i))
+ continue;
+ alc_ptr[i] = __alloc_alien_cache(node, limit, 0xbaadf00d, gfp);
+ if (!alc_ptr[i]) {
+ for (i--; i >= 0; i--)
+ kfree(alc_ptr[i]);
+ kfree(alc_ptr);
+ return NULL;
}
}
- return ac_ptr;
+ return alc_ptr;
}
-static void free_alien_cache(struct array_cache **ac_ptr)
+static void free_alien_cache(struct alien_cache **alc_ptr)
{
int i;
- if (!ac_ptr)
+ if (!alc_ptr)
return;
for_each_node(i)
- kfree(ac_ptr[i]);
- kfree(ac_ptr);
+ kfree(alc_ptr[i]);
+ kfree(alc_ptr);
}
static void __drain_alien_cache(struct kmem_cache *cachep,
@@ -1013,25 +1031,31 @@ static void reap_alien(struct kmem_cache *cachep,
struct kmem_cache_node *n)
int node = __this_cpu_read(slab_reap_node);
if (n->alien) {
- struct array_cache *ac = n->alien[node];
-
- if (ac && ac->avail && spin_trylock_irq(>lock)) {
- __drain_alien_cache(cachep, ac, node);
-
[PATCH 7/9] slab: use the lock on alien_cache, instead of the lock on array_cache
Now, we have separate alien_cache structure, so it'd be better to hold
the lock on alien_cache while manipulating alien_cache. After that,
we don't need the lock on array_cache, so remove it.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index c048ac5..ec1df4c 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -191,7 +191,6 @@ struct array_cache {
unsigned int limit;
unsigned int batchcount;
unsigned int touched;
- spinlock_t lock;
void *entry[]; /*
* Must have this definition in here for the proper
* alignment of array_cache. Also simplifies accessing
@@ -484,7 +483,7 @@ static void slab_set_lock_classes(struct kmem_cache *cachep,
return;
for_each_node(r) {
if (alc[r])
- lockdep_set_class(&(alc[r]->ac.lock), alc_key);
+ lockdep_set_class(&(alc[r]->lock), alc_key);
}
}
@@ -761,7 +760,6 @@ static void init_arraycache(struct array_cache *ac, int
limit, int batch)
ac->limit = limit;
ac->batchcount = batch;
ac->touched = 0;
- spin_lock_init(>lock);
}
}
@@ -960,6 +958,7 @@ static struct alien_cache *__alloc_alien_cache(int node,
int entries,
alc = kmalloc_node(memsize, gfp, node);
init_arraycache(>ac, entries, batch);
+ spin_lock_init(>lock);
return alc;
}
@@ -1036,9 +1035,9 @@ static void reap_alien(struct kmem_cache *cachep, struct
kmem_cache_node *n)
if (alc) {
ac = >ac;
- if (ac->avail && spin_trylock_irq(>lock)) {
+ if (ac->avail && spin_trylock_irq(>lock)) {
__drain_alien_cache(cachep, ac, node);
- spin_unlock_irq(>lock);
+ spin_unlock_irq(>lock);
}
}
}
@@ -1056,9 +1055,9 @@ static void drain_alien_cache(struct kmem_cache *cachep,
alc = alien[i];
if (alc) {
ac = >ac;
- spin_lock_irqsave(>lock, flags);
+ spin_lock_irqsave(>lock, flags);
__drain_alien_cache(cachep, ac, i);
- spin_unlock_irqrestore(>lock, flags);
+ spin_unlock_irqrestore(>lock, flags);
}
}
}
@@ -1086,13 +1085,13 @@ static inline int cache_free_alien(struct kmem_cache
*cachep, void *objp)
if (n->alien && n->alien[nodeid]) {
alien = n->alien[nodeid];
ac = >ac;
- spin_lock(>lock);
+ spin_lock(>lock);
if (unlikely(ac->avail == ac->limit)) {
STATS_INC_ACOVERFLOW(cachep);
__drain_alien_cache(cachep, ac, nodeid);
}
ac_put_obj(cachep, ac, objp);
- spin_unlock(>lock);
+ spin_unlock(>lock);
} else {
spin_lock(&(cachep->node[nodeid])->list_lock);
free_block(cachep, , 1, nodeid, );
@@ -1561,10 +1560,6 @@ void __init kmem_cache_init(void)
memcpy(ptr, cpu_cache_get(kmem_cache),
sizeof(struct arraycache_init));
- /*
-* Do not assume that spinlocks can be initialized via memcpy:
-*/
- spin_lock_init(>lock);
kmem_cache->array[smp_processor_id()] = ptr;
@@ -1574,10 +1569,6 @@ void __init kmem_cache_init(void)
!= _generic.cache);
memcpy(ptr, cpu_cache_get(kmalloc_caches[INDEX_AC]),
sizeof(struct arraycache_init));
- /*
-* Do not assume that spinlocks can be initialized via memcpy:
-*/
- spin_lock_init(>lock);
kmalloc_caches[INDEX_AC]->array[smp_processor_id()] = ptr;
}
--
1.7.9.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 8/9] slab: destroy a slab without holding any alien cache lock
I haven't heard that this alien cache lock is contended, but to reduce
chance of contention would be better generally. And with this change,
we can simplify complex lockdep annotation in slab code.
In the following patch, it will be implemented.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index ec1df4c..9c9d4d4 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1000,9 +1000,9 @@ static void free_alien_cache(struct alien_cache **alc_ptr)
}
static void __drain_alien_cache(struct kmem_cache *cachep,
- struct array_cache *ac, int node)
+ struct array_cache *ac, int node,
+ struct list_head *list)
{
- LIST_HEAD(list);
struct kmem_cache_node *n = cachep->node[node];
if (ac->avail) {
@@ -1015,10 +1015,9 @@ static void __drain_alien_cache(struct kmem_cache
*cachep,
if (n->shared)
transfer_objects(n->shared, ac, ac->limit);
- free_block(cachep, ac->entry, ac->avail, node, );
+ free_block(cachep, ac->entry, ac->avail, node, list);
ac->avail = 0;
spin_unlock(>list_lock);
- slabs_destroy(cachep, );
}
}
@@ -1036,8 +1035,11 @@ static void reap_alien(struct kmem_cache *cachep, struct
kmem_cache_node *n)
if (alc) {
ac = >ac;
if (ac->avail && spin_trylock_irq(>lock)) {
- __drain_alien_cache(cachep, ac, node);
+ LIST_HEAD(list);
+
+ __drain_alien_cache(cachep, ac, node, );
spin_unlock_irq(>lock);
+ slabs_destroy(cachep, );
}
}
}
@@ -1054,10 +1056,13 @@ static void drain_alien_cache(struct kmem_cache *cachep,
for_each_online_node(i) {
alc = alien[i];
if (alc) {
+ LIST_HEAD(list);
+
ac = >ac;
spin_lock_irqsave(>lock, flags);
- __drain_alien_cache(cachep, ac, i);
+ __drain_alien_cache(cachep, ac, i, );
spin_unlock_irqrestore(>lock, flags);
+ slabs_destroy(cachep, );
}
}
}
@@ -1088,10 +1093,11 @@ static inline int cache_free_alien(struct kmem_cache
*cachep, void *objp)
spin_lock(>lock);
if (unlikely(ac->avail == ac->limit)) {
STATS_INC_ACOVERFLOW(cachep);
- __drain_alien_cache(cachep, ac, nodeid);
+ __drain_alien_cache(cachep, ac, nodeid, );
}
ac_put_obj(cachep, ac, objp);
spin_unlock(>lock);
+ slabs_destroy(cachep, );
} else {
spin_lock(&(cachep->node[nodeid])->list_lock);
free_block(cachep, , 1, nodeid, );
--
1.7.9.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 4/9] slab: defer slab_destroy in free_block()
In free_block(), if freeing object makes new free slab and number of
free_objects exceeds free_limit, we start to destroy this new free slab
with holding the kmem_cache node lock. Holding the lock is useless and,
generally, holding a lock as least as possible is good thing. I never
measure performance effect of this, but we'd be better not to hold the lock
as much as possible.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index 53d1a36..551d503 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -242,7 +242,8 @@ static struct kmem_cache_node __initdata
init_kmem_cache_node[NUM_INIT_LISTS];
static int drain_freelist(struct kmem_cache *cache,
struct kmem_cache_node *n, int tofree);
static void free_block(struct kmem_cache *cachep, void **objpp, int len,
- int node);
+ int node, struct list_head *list);
+static void slabs_destroy(struct kmem_cache *cachep, struct list_head *list);
static int enable_cpucache(struct kmem_cache *cachep, gfp_t gfp);
static void cache_reap(struct work_struct *unused);
@@ -979,6 +980,7 @@ static void free_alien_cache(struct array_cache **ac_ptr)
static void __drain_alien_cache(struct kmem_cache *cachep,
struct array_cache *ac, int node)
{
+ LIST_HEAD(list);
struct kmem_cache_node *n = cachep->node[node];
if (ac->avail) {
@@ -991,9 +993,10 @@ static void __drain_alien_cache(struct kmem_cache *cachep,
if (n->shared)
transfer_objects(n->shared, ac, ac->limit);
- free_block(cachep, ac->entry, ac->avail, node);
+ free_block(cachep, ac->entry, ac->avail, node, );
ac->avail = 0;
spin_unlock(>list_lock);
+ slabs_destroy(cachep, );
}
}
@@ -1037,6 +1040,7 @@ static inline int cache_free_alien(struct kmem_cache
*cachep, void *objp)
struct kmem_cache_node *n;
struct array_cache *alien = NULL;
int node;
+ LIST_HEAD(list);
node = numa_mem_id();
@@ -1060,8 +1064,9 @@ static inline int cache_free_alien(struct kmem_cache
*cachep, void *objp)
spin_unlock(>lock);
} else {
spin_lock(&(cachep->node[nodeid])->list_lock);
- free_block(cachep, , 1, nodeid);
+ free_block(cachep, , 1, nodeid, );
spin_unlock(&(cachep->node[nodeid])->list_lock);
+ slabs_destroy(cachep, );
}
return 1;
}
@@ -1130,6 +1135,7 @@ static void cpuup_canceled(long cpu)
struct array_cache *nc;
struct array_cache *shared;
struct array_cache **alien;
+ LIST_HEAD(list);
/* cpu is dead; no one can alloc from it. */
nc = cachep->array[cpu];
@@ -1144,7 +1150,7 @@ static void cpuup_canceled(long cpu)
/* Free limit for this kmem_cache_node */
n->free_limit -= cachep->batchcount;
if (nc)
- free_block(cachep, nc->entry, nc->avail, node);
+ free_block(cachep, nc->entry, nc->avail, node, );
if (!cpumask_empty(mask)) {
spin_unlock_irq(>list_lock);
@@ -1154,7 +1160,7 @@ static void cpuup_canceled(long cpu)
shared = n->shared;
if (shared) {
free_block(cachep, shared->entry,
- shared->avail, node);
+ shared->avail, node, );
n->shared = NULL;
}
@@ -1162,6 +1168,7 @@ static void cpuup_canceled(long cpu)
n->alien = NULL;
spin_unlock_irq(>list_lock);
+ slabs_destroy(cachep, );
kfree(shared);
if (alien) {
@@ -1999,6 +2006,15 @@ static void slab_destroy(struct kmem_cache *cachep,
struct page *page)
kmem_cache_free(cachep->freelist_cache, freelist);
}
+static void slabs_destroy(struct kmem_cache *cachep, struct list_head *list)
+{
+ struct page *page, *n;
+ list_for_each_entry_safe(page, n, list, lru) {
+ list_del(>lru);
+ slab_destroy(cachep, page);
+ }
+}
+
/**
* calculate_slab_order - calculate size (page order) of slabs
* @cachep: pointer to the cache that is being created
@@ -2399,12 +2415,14 @@ static void do_drain(void *arg)
struct kmem_cache *cachep = arg;
struct array_cache *ac;
int node = numa_mem_id();
+ LIST_HEAD(list);
check_irq_off();
ac = cpu_cache_get(cachep);
spin_lock(>node[node]->list_lock);
- free_block(cachep, ac->entry, ac->avail, node);
+ free_block(cachep, ac->entry, ac->avail, node, );
spin_unlock(>node[node]->list_lock);
+ slabs_destroy(cachep, );
ac->avail = 0;
}
@@ -3355,8 +3373,8
[PATCH 2/9] slab: makes clear_obj_pfmemalloc() just return store masked value
clear_obj_pfmemalloc() takes the pointer to the object pointer as argument
to store masked value back into this address.
But this is useless, since we don't use this stored value anymore.
All we need is just masked value. So makes clear_obj_pfmemalloc()
just return masked value.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index 5906f8f..6d17cad 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -215,9 +215,9 @@ static inline void set_obj_pfmemalloc(void **objp)
return;
}
-static inline void clear_obj_pfmemalloc(void **objp)
+static inline void *clear_obj_pfmemalloc(void *objp)
{
- *objp = (void *)((unsigned long)*objp & ~SLAB_OBJ_PFMEMALLOC);
+ return (void *)((unsigned long)objp & ~SLAB_OBJ_PFMEMALLOC);
}
/*
@@ -810,7 +810,7 @@ static void *__ac_get_obj(struct kmem_cache *cachep, struct
array_cache *ac,
struct kmem_cache_node *n;
if (gfp_pfmemalloc_allowed(flags)) {
- clear_obj_pfmemalloc();
+ objp = clear_obj_pfmemalloc(objp);
return objp;
}
@@ -833,7 +833,7 @@ static void *__ac_get_obj(struct kmem_cache *cachep, struct
array_cache *ac,
if (!list_empty(>slabs_free) && force_refill) {
struct page *page = virt_to_head_page(objp);
ClearPageSlabPfmemalloc(page);
- clear_obj_pfmemalloc();
+ objp = clear_obj_pfmemalloc(objp);
recheck_pfmemalloc_active(cachep, ac);
return objp;
}
@@ -3365,8 +3365,7 @@ static void free_block(struct kmem_cache *cachep, void
**objpp, int nr_objects,
void *objp;
struct page *page;
- clear_obj_pfmemalloc([i]);
- objp = objpp[i];
+ objp = clear_obj_pfmemalloc(objpp[i]);
page = virt_to_head_page(objp);
n = cachep->node[node];
--
1.7.9.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 9/9] slab: remove a useless lockdep annotation
Now, there is no code to hold two lock simultaneously, since
we don't call slab_destroy() with holding any lock. So, lockdep
annotation is useless now. Remove it.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index 9c9d4d4..f723a72 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -437,143 +437,6 @@ static struct kmem_cache kmem_cache_boot = {
.name = "kmem_cache",
};
-#define BAD_ALIEN_MAGIC 0x01020304ul
-
-#ifdef CONFIG_LOCKDEP
-
-/*
- * Slab sometimes uses the kmalloc slabs to store the slab headers
- * for other slabs "off slab".
- * The locking for this is tricky in that it nests within the locks
- * of all other slabs in a few places; to deal with this special
- * locking we put on-slab caches into a separate lock-class.
- *
- * We set lock class for alien array caches which are up during init.
- * The lock annotation will be lost if all cpus of a node goes down and
- * then comes back up during hotplug
- */
-static struct lock_class_key on_slab_l3_key;
-static struct lock_class_key on_slab_alc_key;
-
-static struct lock_class_key debugobj_l3_key;
-static struct lock_class_key debugobj_alc_key;
-
-static void slab_set_lock_classes(struct kmem_cache *cachep,
- struct lock_class_key *l3_key, struct lock_class_key *alc_key,
- int q)
-{
- struct alien_cache **alc;
- struct kmem_cache_node *n;
- int r;
-
- n = cachep->node[q];
- if (!n)
- return;
-
- lockdep_set_class(>list_lock, l3_key);
- alc = n->alien;
- /*
-* FIXME: This check for BAD_ALIEN_MAGIC
-* should go away when common slab code is taught to
-* work even without alien caches.
-* Currently, non NUMA code returns BAD_ALIEN_MAGIC
-* for alloc_alien_cache,
-*/
- if (!alc || (unsigned long)alc == BAD_ALIEN_MAGIC)
- return;
- for_each_node(r) {
- if (alc[r])
- lockdep_set_class(&(alc[r]->lock), alc_key);
- }
-}
-
-static void slab_set_debugobj_lock_classes_node(struct kmem_cache *cachep, int
node)
-{
- slab_set_lock_classes(cachep, _l3_key, _alc_key,
node);
-}
-
-static void slab_set_debugobj_lock_classes(struct kmem_cache *cachep)
-{
- int node;
-
- for_each_online_node(node)
- slab_set_debugobj_lock_classes_node(cachep, node);
-}
-
-static void init_node_lock_keys(int q)
-{
- int i;
-
- if (slab_state < UP)
- return;
-
- for (i = 1; i <= KMALLOC_SHIFT_HIGH; i++) {
- struct kmem_cache_node *n;
- struct kmem_cache *cache = kmalloc_caches[i];
-
- if (!cache)
- continue;
-
- n = cache->node[q];
- if (!n || OFF_SLAB(cache))
- continue;
-
- slab_set_lock_classes(cache, _slab_l3_key,
- _slab_alc_key, q);
- }
-}
-
-static void on_slab_lock_classes_node(struct kmem_cache *cachep, int q)
-{
- if (!cachep->node[q])
- return;
-
- slab_set_lock_classes(cachep, _slab_l3_key,
- _slab_alc_key, q);
-}
-
-static inline void on_slab_lock_classes(struct kmem_cache *cachep)
-{
- int node;
-
- VM_BUG_ON(OFF_SLAB(cachep));
- for_each_node(node)
- on_slab_lock_classes_node(cachep, node);
-}
-
-static inline void init_lock_keys(void)
-{
- int node;
-
- for_each_node(node)
- init_node_lock_keys(node);
-}
-#else
-static void init_node_lock_keys(int q)
-{
-}
-
-static inline void init_lock_keys(void)
-{
-}
-
-static inline void on_slab_lock_classes(struct kmem_cache *cachep)
-{
-}
-
-static inline void on_slab_lock_classes_node(struct kmem_cache *cachep, int
node)
-{
-}
-
-static void slab_set_debugobj_lock_classes_node(struct kmem_cache *cachep, int
node)
-{
-}
-
-static void slab_set_debugobj_lock_classes(struct kmem_cache *cachep)
-{
-}
-#endif
-
static DEFINE_PER_CPU(struct delayed_work, slab_reap_work);
static inline struct array_cache *cpu_cache_get(struct kmem_cache *cachep)
@@ -921,7 +784,7 @@ static int transfer_objects(struct array_cache *to,
static inline struct alien_cache **alloc_alien_cache(int node,
int limit, gfp_t gfp)
{
- return (struct alien_cache **)BAD_ALIEN_MAGIC;
+ return NULL;
}
static inline void free_alien_cache(struct alien_cache **ac_ptr)
@@ -1296,13 +1159,7 @@ static int cpuup_prepare(long cpu)
spin_unlock_irq(>list_lock);
kfree(shared);
free_alien_cache(alien);
- if (cachep->flags & SLAB_DEBUG_OBJECTS)
- slab_set_debugobj_lock_classes_node(cachep, node);
- else if (!OFF_SLAB(cachep) &&
-!(cachep->flags & SLAB_DESTROY_BY_RCU))
- on_slab_lock_classes_node(cachep, node);
}
-
[PATCH 1/9] slab: add unlikely macro to help compiler
slab_should_failslab() is called on every allocation, so to optimize it
is reasonable. We normally don't allocate from kmem_cache. It is just
used when new kmem_cache is created, so it's very rare case. Therefore,
add unlikely macro to help compiler optimization.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index 8347d80..5906f8f 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3009,7 +3009,7 @@ static void *cache_alloc_debugcheck_after(struct
kmem_cache *cachep,
static bool slab_should_failslab(struct kmem_cache *cachep, gfp_t flags)
{
- if (cachep == kmem_cache)
+ if (unlikely(cachep == kmem_cache))
return false;
return should_failslab(cachep->object_size, flags, cachep->flags);
--
1.7.9.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 v2 3/5] mm/compaction: change the timing to check to drop the spinlock
It is odd to drop the spinlock when we scan (SWAP_CLUSTER_MAX - 1) th pfn
page. This may results in below situation while isolating migratepage.
1. try isolate 0x0 ~ 0x200 pfn pages.
2. When low_pfn is 0x1ff, ((low_pfn+1) % SWAP_CLUSTER_MAX) == 0, so drop
the spinlock.
3. Then, to complete isolating, retry to aquire the lock.
I think that it is better to use SWAP_CLUSTER_MAX th pfn for checking
the criteria about dropping the lock. This has no harm 0x0 pfn, because,
at this time, locked variable would be false.
Acked-by: Vlastimil Babka
Signed-off-by: Joonsoo Kim
diff --git a/mm/compaction.c b/mm/compaction.c
index 0d821a2..b1ba297 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -481,7 +481,7 @@ isolate_migratepages_range(struct zone *zone, struct
compact_control *cc,
cond_resched();
for (; low_pfn < end_pfn; low_pfn++) {
/* give a chance to irqs before checking need_resched() */
- if (locked && !((low_pfn+1) % SWAP_CLUSTER_MAX)) {
+ if (locked && !(low_pfn % SWAP_CLUSTER_MAX)) {
if (should_release_lock(>lru_lock)) {
spin_unlock_irqrestore(>lru_lock, flags);
locked = false;
--
1.7.9.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 v2 0/5] compaction related commits
changes for v2 o include more experiment data in cover letter o deal with vlastimil's comments mostly about commit description on 4/5 This patchset is related to the compaction. patch 1 fixes contrary implementation of the purpose of compaction. patch 2~4 are for optimization. patch 5 is just for clean-up. I tested this patchset with stress-highalloc benchmark on Mel's mmtest and cannot find any regression in terms of success rate. And I find much reduced(9%) elapsed time. Below is the average result of 10 runs on my 4GB quad core system. compaction-base+ is based on 3.13.0 with Vlastimil's recent fixes. compaction-fix+ has this patch series on top of compaction-base+. Thanks. stress-highalloc 3.13.0 3.13.0 compaction-base+compaction-fix+ Success 1 14.10 15.00 Success 2 20.20 20.00 Success 3 68.30 73.40 3.13.0 3.13.0 compaction-base+compaction-fix+ User3486.02 3437.13 System 757.92 741.15 Elapsed 1638.52 1488.32 3.13.0 3.13.0 compaction-base+compaction-fix+ Minor Faults172591561 167116621 Major Faults 984 859 Swap Ins 743 653 Swap Outs 36573535 Direct pages scanned 129742 127344 Kswapd pages scanned 1852277 1817825 Kswapd pages reclaimed 1838000 1804212 Direct pages reclaimed129719 127327 Kswapd efficiency98% 98% Kswapd velocity 1130.0661221.296 Direct efficiency99% 99% Direct velocity 79.367 85.585 Percentage direct scans 6% 6% Zone normal velocity 231.829 246.097 Zone dma32 velocity 972.5891055.158 Zone dma velocity 5.015 5.626 Page writes by reclaim 62876534 Page writes file26302999 Page writes anon36573535 Page reclaim immediate 21872080 Sector Reads 2917808 2877336 Sector Writes 1147789111206722 Page rescued immediate 0 0 Slabs scanned2214118 2168524 Direct inode steals121819788 Kswapd inode steals 144830 132109 Kswapd skipped wait0 0 THP fault alloc0 0 THP collapse alloc 0 0 THP splits 0 0 THP fault fallback 0 0 THP collapse fail 0 0 Compaction stalls738 714 Compaction success 194 207 Compaction failures 543 507 Page migrate success 1806083 1464014 Page migrate failure 0 0 Compaction pages isolated3873329 3162974 Compaction migrate scanned 7459486259874420 Compaction free scanned 12554 110868637 Compaction cost 24691998 Joonsoo Kim (5): mm/compaction: disallow high-order page for migration target mm/compaction: do not call suitable_migration_target() on every page mm/compaction: change the timing to check to drop the spinlock mm/compaction: check pageblock suitability once per pageblock mm/compaction: clean-up code on success of ballon isolation mm/compaction.c | 75 --- 1 file changed, 38 insertions(+), 37 deletions(-) -- 1.7.9.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
[PATCH v2 1/5] mm/compaction: disallow high-order page for migration target
Purpose of compaction is to get a high order page. Currently, if we find
high-order page while searching migration target page, we break it to
order-0 pages and use them as migration target. It is contrary to purpose
of compaction, so disallow high-order page to be used for
migration target.
Additionally, clean-up logic in suitable_migration_target() to simplify
the code. There is no functional changes from this clean-up.
Acked-by: Vlastimil Babka
Signed-off-by: Joonsoo Kim
diff --git a/mm/compaction.c b/mm/compaction.c
index 3a91a2e..bbe1260 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -217,21 +217,12 @@ static inline bool compact_trylock_irqsave(spinlock_t
*lock,
/* Returns true if the page is within a block suitable for migration to */
static bool suitable_migration_target(struct page *page)
{
- int migratetype = get_pageblock_migratetype(page);
-
- /* Don't interfere with memory hot-remove or the min_free_kbytes blocks
*/
- if (migratetype == MIGRATE_RESERVE)
- return false;
-
- if (is_migrate_isolate(migratetype))
- return false;
-
- /* If the page is a large free page, then allow migration */
+ /* If the page is a large free page, then disallow migration */
if (PageBuddy(page) && page_order(page) >= pageblock_order)
- return true;
+ return false;
/* If the block is MIGRATE_MOVABLE or MIGRATE_CMA, allow migration */
- if (migrate_async_suitable(migratetype))
+ if (migrate_async_suitable(get_pageblock_migratetype(page)))
return true;
/* Otherwise skip the block */
--
1.7.9.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 v2 2/5] mm/compaction: do not call suitable_migration_target() on every page
suitable_migration_target() checks that pageblock is suitable for
migration target. In isolate_freepages_block(), it is called on every
page and this is inefficient. So make it called once per pageblock.
suitable_migration_target() also checks if page is highorder or not,
but it's criteria for highorder is pageblock order. So calling it once
within pageblock range has no problem.
Signed-off-by: Joonsoo Kim
diff --git a/mm/compaction.c b/mm/compaction.c
index bbe1260..0d821a2 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -245,6 +245,7 @@ static unsigned long isolate_freepages_block(struct
compact_control *cc,
unsigned long nr_strict_required = end_pfn - blockpfn;
unsigned long flags;
bool locked = false;
+ bool checked_pageblock = false;
cursor = pfn_to_page(blockpfn);
@@ -275,8 +276,16 @@ static unsigned long isolate_freepages_block(struct
compact_control *cc,
break;
/* Recheck this is a suitable migration target under lock */
- if (!strict && !suitable_migration_target(page))
- break;
+ if (!strict && !checked_pageblock) {
+ /*
+* We need to check suitability of pageblock only once
+* and this isolate_freepages_block() is called with
+* pageblock range, so just check once is sufficient.
+*/
+ checked_pageblock = true;
+ if (!suitable_migration_target(page))
+ break;
+ }
/* Recheck this is a buddy page under lock */
if (!PageBuddy(page))
--
1.7.9.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 v2 5/5] mm/compaction: clean-up code on success of ballon isolation
It is just for clean-up to reduce code size and improve readability.
There is no functional change.
Acked-by: Vlastimil Babka
Signed-off-by: Joonsoo Kim
diff --git a/mm/compaction.c b/mm/compaction.c
index 56536d3..a1a9270 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -553,11 +553,7 @@ isolate_migratepages_range(struct zone *zone, struct
compact_control *cc,
if (unlikely(balloon_page_movable(page))) {
if (locked && balloon_page_isolate(page)) {
/* Successfully isolated */
- cc->finished_update_migrate = true;
- list_add(>lru, migratelist);
- cc->nr_migratepages++;
- nr_isolated++;
- goto check_compact_cluster;
+ goto isolate_success;
}
}
continue;
@@ -609,13 +605,14 @@ isolate_migratepages_range(struct zone *zone, struct
compact_control *cc,
VM_BUG_ON(PageTransCompound(page));
/* Successfully isolated */
- cc->finished_update_migrate = true;
del_page_from_lru_list(page, lruvec, page_lru(page));
+
+isolate_success:
+ cc->finished_update_migrate = true;
list_add(>lru, migratelist);
cc->nr_migratepages++;
nr_isolated++;
-check_compact_cluster:
/* Avoid isolating too much */
if (cc->nr_migratepages == COMPACT_CLUSTER_MAX) {
++low_pfn;
--
1.7.9.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 v2 4/5] mm/compaction: check pageblock suitability once per pageblock
isolation_suitable() and migrate_async_suitable() is used to be sure
that this pageblock range is fine to be migragted. It isn't needed to
call it on every page. Current code do well if not suitable, but, don't
do well when suitable.
1) It re-checks isolation_suitable() on each page of a pageblock that was
already estabilished as suitable.
2) It re-checks migrate_async_suitable() on each page of a pageblock that
was not entered through the next_pageblock: label, because
last_pageblock_nr is not otherwise updated.
This patch fixes situation by 1) calling isolation_suitable() only once
per pageblock and 2) always updating last_pageblock_nr to the pageblock
that was just checked.
Additionally, move PageBuddy() check after pageblock unit check,
since pageblock check is the first thing we should do and makes things
more simple.
[vba...@suse.cz: rephrase commit description]
Acked-by: Vlastimil Babka
Signed-off-by: Joonsoo Kim
diff --git a/mm/compaction.c b/mm/compaction.c
index b1ba297..56536d3 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -520,26 +520,31 @@ isolate_migratepages_range(struct zone *zone, struct
compact_control *cc,
/* If isolation recently failed, do not retry */
pageblock_nr = low_pfn >> pageblock_order;
- if (!isolation_suitable(cc, page))
- goto next_pageblock;
+ if (last_pageblock_nr != pageblock_nr) {
+ int mt;
+
+ last_pageblock_nr = pageblock_nr;
+ if (!isolation_suitable(cc, page))
+ goto next_pageblock;
+
+ /*
+* For async migration, also only scan in MOVABLE
+* blocks. Async migration is optimistic to see if
+* the minimum amount of work satisfies the allocation
+*/
+ mt = get_pageblock_migratetype(page);
+ if (!cc->sync && !migrate_async_suitable(mt)) {
+ cc->finished_update_migrate = true;
+ skipped_async_unsuitable = true;
+ goto next_pageblock;
+ }
+ }
/* Skip if free */
if (PageBuddy(page))
continue;
/*
-* For async migration, also only scan in MOVABLE blocks. Async
-* migration is optimistic to see if the minimum amount of work
-* satisfies the allocation
-*/
- if (!cc->sync && last_pageblock_nr != pageblock_nr &&
- !migrate_async_suitable(get_pageblock_migratetype(page))) {
- cc->finished_update_migrate = true;
- skipped_async_unsuitable = true;
- goto next_pageblock;
- }
-
- /*
* Check may be lockless but that's ok as we recheck later.
* It's possible to migrate LRU pages and balloon pages
* Skip any other type of page
@@ -621,7 +626,6 @@ check_compact_cluster:
next_pageblock:
low_pfn = ALIGN(low_pfn + 1, pageblock_nr_pages) - 1;
- last_pageblock_nr = pageblock_nr;
}
acct_isolated(zone, locked, cc);
--
1.7.9.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 v15 0/10] Add 32 bit VDSO time function support
Hi, I tried this patchset, but it fails to compile on i386 "make allyesconfig". -hpa -- 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 13/51] powerpc, sysfs: Fix CPU hotplug callback registration
On Thursday 06 February 2014 03:36 AM, Srivatsa S. Bhat wrote:
> Subsystems that want to register CPU hotplug callbacks, as well as perform
> initialization for the CPUs that are already online, often do it as shown
> below:
>
> get_online_cpus();
>
> for_each_online_cpu(cpu)
> init_cpu(cpu);
>
> register_cpu_notifier(_cpu_notifier);
>
> put_online_cpus();
>
> This is wrong, since it is prone to ABBA deadlocks involving the
> cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
> with CPU hotplug operations).
>
> Instead, the correct and race-free way of performing the callback
> registration is:
>
> cpu_maps_update_begin();
>
> for_each_online_cpu(cpu)
> init_cpu(cpu);
>
> /* Note the use of the double underscored version of the API */
> __register_cpu_notifier(_cpu_notifier);
>
> cpu_maps_update_done();
>
>
> Fix the sysfs code in powerpc by using this latter form of callback
> registration.
Acked-by: Madhavan Srinivasan
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Madhavan Srinivasan
> Cc: Olof Johansson
> Cc: Wang Dongsheng
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Srivatsa S. Bhat
> ---
>
> arch/powerpc/kernel/sysfs.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index 97e1dc9..c29ad44 100644
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -975,7 +975,8 @@ static int __init topology_init(void)
> int cpu;
>
> register_nodes();
> - register_cpu_notifier(_cpu_nb);
> +
> + cpu_maps_update_begin();
>
> for_each_possible_cpu(cpu) {
> struct cpu *c = _cpu(cpu_devices, cpu);
> @@ -999,6 +1000,11 @@ static int __init topology_init(void)
> if (cpu_online(cpu))
> register_cpu_online(cpu);
> }
> +
> + __register_cpu_notifier(_cpu_nb);
> +
> + cpu_maps_update_done();
> +
> #ifdef CONFIG_PPC64
> sysfs_create_dscr_default();
> #endif /* CONFIG_PPC64 */
>
--
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: Re: [PATCH] Fix Default to 'y' for SR9800 Device Driver, settingto 'n'
Dear David : Thanks all the same. 2014-02-14 liujunliang_ljl 发件人： David Miller 发送时间： 2014-02-14 07:42:24 收件人： sergei.shtylyov 抄送： liujunliang_ljl; thierry.reding; horms; joe; romieu; gregkh; netdev; linux-usb; linux-kernel; sunhecheng 主题： Re: [PATCH] Fix Default to 'y' for SR9800 Device Driver, settingto 'n' From: Sergei Shtylyov Date: Fri, 14 Feb 2014 03:38:17 +0300 > Hello. > > On 02/14/2014 02:32 AM, David Miller wrote: > >>> From: Liu Junliang > >>> Signed-off-by: Liu Junliang > >> I think it's more canonical to specify no default at all. > >That's what he did, no? Indeed, my bad, patch applied, thanks! .
[PATCH V2 2/2] mm/vmscan: not check compaction_ready on promoted zones
We abort direct reclaim if find the zone is ready for compaction.
Sometimes the zone is just a promoted highmem zone to force scan
pinning highmem, which is not the intended zone the caller want to
alloc page from. In this situation, setting aborted_reclaim to
indicate the caller turn back to retry allocation is waste of time
and could cause a loop in __alloc_pages_slowpath().
This patch do not check compaction_ready() on promoted zones to avoid
the above situation, only set aborted_reclaim if the caller intended
zone is ready to compaction.
Acked-by: Rik van Riel
Signed-off-by: Weijie Yang
---
mm/vmscan.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index da0a87c..9ec6519 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2299,6 +2299,7 @@ static bool shrink_zones(struct zonelist *zonelist,
struct scan_control *sc)
unsigned long nr_soft_scanned;
bool aborted_reclaim = false;
gfp_t orig_mask = sc->gfp_mask;
+ enum zone_type requested_highidx = gfp_zone(sc->gfp_mask);
/*
* If the number of buffer_heads in the machine exceeds the maximum
@@ -2332,7 +2333,8 @@ static bool shrink_zones(struct zonelist *zonelist,
struct scan_control *sc)
* noticeable problem, like transparent huge
* page allocations.
*/
- if (compaction_ready(zone, sc)) {
+ if ((zonelist_zone_idx(z) <= requested_highidx)
+ && compaction_ready(zone, sc)) {
aborted_reclaim = true;
continue;
}
--
1.7.10.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 1/2] mm/vmscan: restore sc->gfp_mask after promoting it to __GFP_HIGHMEM
We promote sc->gfp_mask to __GFP_HIGHMEM to forcibly scan highmem if there are too many buffer_heads pinning highmem. see: cc715d99e5 This patch restores sc->gfp_mask to its caller original value after finishing the scan job, to avoid the impact on other invocations from its upper caller, such as vmpressure_prio(), shrink_slab(). Signed-off-by: Weijie Yang --- Changes since v1: - use orig_mask to record the caller's orininal mask and restore it after finishing scan, according to Riel's suggestion. V1: https://lkml.org/lkml/2014/2/12/764 mm/vmscan.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/mm/vmscan.c b/mm/vmscan.c index a9c74b4..da0a87c 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2298,6 +2298,7 @@ static bool shrink_zones(struct zonelist *zonelist, struct scan_control *sc) unsigned long nr_soft_reclaimed; unsigned long nr_soft_scanned; bool aborted_reclaim = false; + gfp_t orig_mask = sc->gfp_mask; /* * If the number of buffer_heads in the machine exceeds the maximum @@ -2354,6 +2355,12 @@ static bool shrink_zones(struct zonelist *zonelist, struct scan_control *sc) shrink_zone(zone, sc); } + /* +* restore to original mask to avoid the impact on its caller +* if we promote it to __GFP_HIGHMEM. +*/ + sc->gfp_mask = orig_mask; + return aborted_reclaim; } -- 1.7.10.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] thinkpad_acpi: Fix inconsistent mute LED after resume
At Thu, 13 Feb 2014 19:02:46 +0100,
rauchwo...@gmx.net wrote:
>
> Hi,
>
> this patch doesn't work. The sound is now muted after the resume (light is
> on).
> But the userspace knows nothing about it. (kmix shows the volume as umuted)
OK, scratch the last patch. I thought the mute LED is also a part of
thinkpad_acpi's leds_class, but it's not. So, my initial patch is a
correct fix in the end.
Matthew, could you take it please?
thanks,
Takashi
>
> Peter
>
>
> On Thu, 13 Feb 2014 09:35:30 +0100
> Takashi Iwai wrote:
>
> > At Wed, 12 Feb 2014 20:37:36 +,
> > Matthew Garrett wrote:
> > >
> > > On Wed, 2014-02-12 at 16:32 +0100, Takashi Iwai wrote:
> > > > The mute LED states have to be restored after resume.
> > >
> > > Oh, never mind, we're not doing this through the LED class, are we?
> >
> > Good point. It seems that leds_class has pm_ops but it's enabled only
> > when a flag is set.
> >
> > I added the original bug reporter to Cc. (Don't know the name,
> > Bugzilla shows only the email address.)
> > Could you check the patch below works instead of the previous fix?
> >
> >
> > Takashi
> >
> > ---
> > diff --git a/drivers/platform/x86/thinkpad_acpi.c
> > b/drivers/platform/x86/thinkpad_acpi.c
> > index defb6afc1409..16edf75d9c00 100644
> > --- a/drivers/platform/x86/thinkpad_acpi.c
> > +++ b/drivers/platform/x86/thinkpad_acpi.c
> > @@ -4796,6 +4796,7 @@ static struct tpacpi_led_classdev
> > tpacpi_led_thinklight = {
> > .name = "tpacpi::thinklight",
> > .brightness_set = _sysfs_set,
> > .brightness_get = _sysfs_get,
> > + .flags = LED_CORE_SUSPENDRESUME,
> > }
> > };
> >
>
--
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 09/10] regulator: Add LM3631 driver
LM3631 regulator driver has 5 regulators.
One boost output and four LDOs are used for the display module.
Boost voltage is configurable but always on.
Supported operations for LDOs are enabled/disabled and voltage change.
Cc: Mark Brown
Signed-off-by: Milo Kim
---
drivers/regulator/Kconfig|8 +
drivers/regulator/Makefile |1 +
drivers/regulator/lm3631-regulator.c | 285 ++
3 files changed, 294 insertions(+)
create mode 100644 drivers/regulator/lm3631-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 6a79328..9809d7b 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -221,6 +221,14 @@ config REGULATOR_ISL6271A
help
This driver supports ISL6271A voltage regulator chip.
+config REGULATOR_LM3631
+ tristate "TI LM3631 voltage regulators"
+ depends on MFD_TI_LMU
+ help
+ This driver supports LM3631 voltage regulators for the LCD bias.
+ One boost output voltage is configurable and always on.
+ Four LDOs are used for the display module.
+
config REGULATOR_LP3971
tristate "National Semiconductors LP3971 PMIC regulator driver"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 979f9dd..b20070d 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
obj-$(CONFIG_REGULATOR_FAN53555) += fan53555.o
obj-$(CONFIG_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
+obj-$(CONFIG_REGULATOR_LM3631) += lm3631-regulator.o
obj-$(CONFIG_REGULATOR_LP3971) += lp3971.o
obj-$(CONFIG_REGULATOR_LP3972) += lp3972.o
obj-$(CONFIG_REGULATOR_LP872X) += lp872x.o
diff --git a/drivers/regulator/lm3631-regulator.c
b/drivers/regulator/lm3631-regulator.c
new file mode 100644
index 000..930bad4
--- /dev/null
+++ b/drivers/regulator/lm3631-regulator.c
@@ -0,0 +1,285 @@
+/*
+ * TI LM3631 Regulator Driver
+ *
+ * Copyright 2014 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ENABLE_TIME_USEC 1000
+
+enum lm3631_regulator_id {
+ LM3631_BOOST, /* Boost output */
+ LM3631_LDO_CONT,/* Display panel controller */
+ LM3631_LDO_OREF,/* Gamma reference */
+ LM3631_LDO_POS, /* Positive display bias output */
+ LM3631_LDO_NEG, /* Negative display bias output */
+};
+
+struct lm3631_regulator {
+ struct ti_lmu *lmu;
+ struct regulator_desc *desc;
+ struct regulator_dev *regulator;
+};
+
+static const int lm3631_boost_vtbl[] = {
+ 450, 455, 460, 465, 470, 475, 480, 485,
+ 490, 495, 500, 505, 510, 515, 520, 525,
+ 530, 535, 540, 545, 550, 555, 560, 565,
+ 570, 575, 580, 585, 590, 595, 600, 605,
+ 610, 615, 620, 625, 630, 635,
+};
+
+static const int lm3631_ldo_cont_vtbl[] = {
+ 180, 230, 280, 330,
+};
+
+static const int lm3631_ldo_target_vtbl[] = {
+ 400, 405, 410, 415, 420, 425, 430, 435,
+ 440, 445, 450, 455, 460, 465, 470, 475,
+ 480, 485, 490, 495, 500, 505, 510, 515,
+ 520, 525, 530, 535, 540, 545, 550, 555,
+ 560, 565, 570, 575, 580, 585, 590, 595,
+ 600,
+};
+
+const int ldo_cont_enable_time[] = {
+ 0, 2000, 5000, 1, 2, 5, 10, 20,
+};
+
+static int lm3631_regulator_enable_time(struct regulator_dev *rdev)
+{
+ struct lm3631_regulator *lm3631_regulator = rdev_get_drvdata(rdev);
+ enum lm3631_regulator_id id = rdev_get_id(rdev);
+ u8 val, addr, mask;
+
+ switch (id) {
+ case LM3631_LDO_CONT:
+ addr = LM3631_REG_ENTIME_VCONT;
+ mask = LM3631_ENTIME_CONT_MASK;
+ break;
+ case LM3631_LDO_OREF:
+ addr = LM3631_REG_ENTIME_VOREF;
+ mask = LM3631_ENTIME_MASK;
+ break;
+ case LM3631_LDO_POS:
+ addr = LM3631_REG_ENTIME_VPOS;
+ mask = LM3631_ENTIME_MASK;
+ break;
+ case LM3631_LDO_NEG:
+ addr = LM3631_REG_ENTIME_VNEG;
+ mask = LM3631_ENTIME_MASK;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if
[PATCH 10/10] Documentation: Add device tree bindings for TI LMU devices
Bindings for TI LMU, backlight, LM3631 regulator and LM3633 LED are added.
Cc: devicet...@vger.kernel.org
Cc: Bryan Wu
Cc: Jingoo Han
Cc: Lee Jones
Cc: Mark Brown
Cc: Samuel Ortiz
Signed-off-by: Milo Kim
---
.../devicetree/bindings/leds/leds-lm3633.txt | 39 +
Documentation/devicetree/bindings/mfd/ti-lmu.txt | 182
.../bindings/regulator/lm3631-regulator.txt| 49 ++
.../bindings/video/backlight/ti-lmu-backlight.txt | 127 ++
4 files changed, 397 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3633.txt
create mode 100644 Documentation/devicetree/bindings/mfd/ti-lmu.txt
create mode 100644
Documentation/devicetree/bindings/regulator/lm3631-regulator.txt
create mode 100644
Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3633.txt
b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
new file mode 100644
index 000..4adeb62
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
@@ -0,0 +1,39 @@
+TI LMU LM3633 LED device tree bindings
+
+Required properties:
+ - compatible: "ti,lm3633-leds"
+ - lvled1-used, lvled2-used, lvled3-used, lvled4-used, lvled5-used,
lvled6-used
+: LED string configuration. Each child node should include this information
+ about which LED string is used.
+
+Optional properties:
+ - chan-name: LED channel name
+ - max-current-milliamp: Max current setting. Unit is mA.
+
+Example:
+
+lm3633@36 {
+ compatible = "ti,lm3633";
+ reg = <0x36>;
+
+ ti,enable-gpio = < 6 GPIO_ACTIVE_HIGH>;
+
+ leds {
+ compatible = "ti,lm3633-leds";
+
+ chan2 {
+ chan-name = "status";
+ lvled2-used;
+ max-current-milliamp = /bits/ 8 <6>;
+ };
+
+ chan456 {
+ chan-name = "rgb";
+ lvled4-used;
+ lvled5-used;
+ lvled6-used;
+
+ max-current-milliamp = /bits/ 8 <5>;
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
new file mode 100644
index 000..2b3ecca
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
@@ -0,0 +1,182 @@
+TI LMU(Lighting Management Unit) device tree bindings
+
+TI LMU driver supports lighting devices belows.
+
+ NameDevice tree properties
+ --
+ LM3532 Backlight
+ LM3631 Backlight and regulator
+ LM3633 Backlight and LED
+ LM3695 Backlight
+ LM3697 Backlight
+
+Those have shared device tree properties.
+
+Required properties:
+ - compatible: "ti,lm3532", "ti,lm3631", "ti,lm3633", "ti,lm3695", "ti,lm3697"
+ - reg: I2C slave address.
+0x38 is LM3532
+0x29 is LM3631
+0x36 is LM3633, LM3697
+0x63 is LM3695
+ - ti,enable-gpio: GPIO number of hardware enable pin
+
+For the TI LMU backlight properties, please refer to:
+Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt
+
+For the LM3631 regulator properties, please refer to:
+Documentation/devicetree/bindings/regulator/lm3631-regulator.txt
+
+For the LM3633 LED properties, please refer to:
+Documentation/devicetree/bindings/leds/leds-lm3633.txt
+
+Examples:
+
+lm3532@38 {
+ compatible = "ti,lm3532";
+ reg = <0x38>;
+
+ /* GPIO134 for HWEN pin */
+ ti,enable-gpio = < 6 GPIO_ACTIVE_HIGH>;
+
+ backlight {
+ compatible = "ti,lmu-backlight", "ti,lm3532-backlight";
+
+ lcd {
+ hvled1-used;
+ hvled2-used;
+ hvled3-used;
+
+ max-current-milliamp = /bits/ 8 <20>;
+ ramp-up = <1>;
+ ramp-down = <1>;
+ };
+ };
+};
+
+lm3631@29 {
+ compatible = "ti,lm3631";
+ reg = <0x29>;
+
+ ti,enable-gpio = < 6 GPIO_ACTIVE_HIGH>;
+
+ /* Only Vpos and Vneg are used with LCD boost */
+ regulators {
+ compatible = "ti,lm3631-regulator";
+
+ vboost {
+ regulator-name = "lcd_boost";
+ regulator-min-microvolt = <450>;
+ regulator-max-microvolt = <635>;
+ regulator-always-on;
+ };
+
+ vpos {
+ regulator-name = "lcd_vpos";
+ regulator-min-microvolt = <400>;
+ regulator-max-microvolt = <600>;
+ regulator-boot-on;
+ };
+
+ vneg {
+ regulator-name = "lcd_vneg";
+ regulator-min-microvolt = <400>;
+
[PATCH 05/10] backlight: ti-lmu-backlight: Add LM3633 driver
LM3633 has 3 backlight strings and 11 bit dimming is supported.
PWM brightness control is also supported.
Common backlight driver is controlled by TI LMU backlight driver.
Only LM3633 specific code is implemented here.
Cc: Jingoo Han
Cc: Bryan Wu
Cc: Lee Jones
Signed-off-by: Milo Kim
---
drivers/video/backlight/Kconfig |9 ++
drivers/video/backlight/Makefile|1 +
drivers/video/backlight/lm3633_bl.c | 244 +++
3 files changed, 254 insertions(+)
create mode 100644 drivers/video/backlight/lm3633_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index a43a015..aa012a3 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -402,6 +402,15 @@ config BACKLIGHT_LM3631
Up to 2 backlight strings and 11 bit dimming is supported.
PWM brightness control is also supported.
+config BACKLIGHT_LM3633
+ tristate "Backlight driver for TI LM3633"
+ depends on BACKLIGHT_CLASS_DEVICE && MFD_TI_LMU
+ select TI_LMU_BACKLIGHT
+ help
+ Say Y to enable the backlight driver for TI LM3633.
+ Up to 3 backlight strings and 11 bit dimming is supported.
+ PWM brightness control is also supported.
+
config TI_LMU_BACKLIGHT
tristate "Backlight driver for TI LMU"
depends on BACKLIGHT_LM3532 || BACKLIGHT_LM3631 || BACKLIGHT_LM3633 ||
BACKLIGHT_LM3695 || BACKLIGHT_LM3697
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 2a17f8b..842a256 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_BACKLIGHT_LM3630A) += lm3630a_bl.o
obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
obj-$(CONFIG_BACKLIGHT_LM3532) += lm3532_bl.o
obj-$(CONFIG_BACKLIGHT_LM3631) += lm3631_bl.o
+obj-$(CONFIG_BACKLIGHT_LM3633) += lm3633_bl.o
obj-$(CONFIG_TI_LMU_BACKLIGHT) += ti-lmu-backlight.o
obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
diff --git a/drivers/video/backlight/lm3633_bl.c
b/drivers/video/backlight/lm3633_bl.c
new file mode 100644
index 000..c12fd42
--- /dev/null
+++ b/drivers/video/backlight/lm3633_bl.c
@@ -0,0 +1,244 @@
+/*
+ * TI LM3633 Backlight Driver
+ *
+ * Copyright 2014 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * LM3633 backlight driver consists of two parts
+ *
+ * 1) LM3633 chip specific part: this file
+ * Define device specific operations
+ * Register LMU backlight driver
+ *
+ * 2) LMU backlight common driver: ti-lmu-backlight
+ * General backlight subsystem control
+ *
+ * 3) LMU effect driver
+ * Backlight slope time configuration
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ti-lmu-backlight.h"
+
+#define LM3633_BOOST_OVP_40V 0x6
+#define LM3633_BL_MAX_STRINGS 3
+#define LM3633_BL_MAX_BRIGHTNESS 2047
+
+static int lm3633_bl_init(struct ti_lmu_bl_chip *chip)
+{
+ /* Configure ramp selection for each bank */
+ return ti_lmu_update_bits(chip->lmu, LM3633_REG_BL_RAMP_CONF,
+ LM3633_BL_RAMP_MASK, LM3633_BL_RAMP_EACH);
+}
+
+static int lm3633_bl_enable(struct ti_lmu_bl *lmu_bl, int enable)
+{
+ return ti_lmu_update_bits(lmu_bl->chip->lmu, LM3633_REG_ENABLE,
+ BIT(lmu_bl->bank_id),
+ enable << lmu_bl->bank_id);
+}
+
+static int lm3633_bl_set_brightness(struct ti_lmu_bl *lmu_bl, int brightness)
+{
+ int ret;
+ u8 data;
+ u8 reg_lsb[] = { LM3633_REG_BRT_HVLED_A_LSB,
+LM3633_REG_BRT_HVLED_B_LSB, };
+ u8 reg_msb[] = { LM3633_REG_BRT_HVLED_A_MSB,
+LM3633_REG_BRT_HVLED_B_MSB, };
+
+ if (lmu_bl->mode == BL_PWM_BASED) {
+ /*
+* PWM can start from any non-zero code and dim down to zero.
+* So, brightness register should be updated even in PWM mode.
+*/
+ if (brightness > 0)
+ brightness = LM3633_BL_MAX_BRIGHTNESS;
+ else
+ brightness = 0;
+ }
+
+ data = brightness & LM3633_BRT_HVLED_LSB_MASK;
+ ret = ti_lmu_update_bits(lmu_bl->chip->lmu, reg_lsb[lmu_bl->bank_id],
+LM3633_BRT_HVLED_LSB_MASK, data);
+ if (ret)
+ return ret;
+
+ data = (brightness >> LM3633_BRT_HVLED_MSB_SHIFT) & 0xFF;
+ return ti_lmu_write_byte(lmu_bl->chip->lmu, reg_msb[lmu_bl->bank_id],
+data);
+}
+
+static
[PATCH 07/10] backlight: ti-lmu-backlight: Add LM3697 driver
LM3697 has 3 backlight strings and 11 bit dimming is supported.
PWM brightness control is also supported.
Common backlight driver is controlled by TI LMU backlight driver.
Only LM3697 specific code is implemented here.
Cc: Jingoo Han
Cc: Bryan Wu
Cc: Lee Jones
Signed-off-by: Milo Kim
---
drivers/video/backlight/Kconfig |9 ++
drivers/video/backlight/Makefile|1 +
drivers/video/backlight/lm3697_bl.c | 224 +++
3 files changed, 234 insertions(+)
create mode 100644 drivers/video/backlight/lm3697_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index b169c8d..3c39b30 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -419,6 +419,15 @@ config BACKLIGHT_LM3695
Say Y to enable the backlight driver for TI LM3695.
Up to 2 backlight strings and 11 bit dimming is supported.
+config BACKLIGHT_LM3697
+ tristate "Backlight driver for TI LM3697"
+ depends on BACKLIGHT_CLASS_DEVICE && MFD_TI_LMU
+ select TI_LMU_BACKLIGHT
+ help
+ Say Y to enable the backlight driver for TI LM3697.
+ Up to 3 backlight strings and 11 bit dimming is supported.
+ PWM brightness control is also supported.
+
config TI_LMU_BACKLIGHT
tristate "Backlight driver for TI LMU"
depends on BACKLIGHT_LM3532 || BACKLIGHT_LM3631 || BACKLIGHT_LM3633 ||
BACKLIGHT_LM3695 || BACKLIGHT_LM3697
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 5427162..16e6ad7 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_BACKLIGHT_LM3532)+= lm3532_bl.o
obj-$(CONFIG_BACKLIGHT_LM3631) += lm3631_bl.o
obj-$(CONFIG_BACKLIGHT_LM3633) += lm3633_bl.o
obj-$(CONFIG_BACKLIGHT_LM3695) += lm3695_bl.o
+obj-$(CONFIG_BACKLIGHT_LM3697) += lm3697_bl.o
obj-$(CONFIG_TI_LMU_BACKLIGHT) += ti-lmu-backlight.o
obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
diff --git a/drivers/video/backlight/lm3697_bl.c
b/drivers/video/backlight/lm3697_bl.c
new file mode 100644
index 000..18b866a
--- /dev/null
+++ b/drivers/video/backlight/lm3697_bl.c
@@ -0,0 +1,224 @@
+/*
+ * TI LM3697 Backlight Driver
+ *
+ * Copyright 2014 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * LM3697 backlight driver consists of three parts
+ *
+ * 1) LM3697 chip specific part: this file
+ * Define device specific operations
+ * Register LMU backlight driver
+ *
+ * 2) LMU backlight common driver: ti-lmu-backlight
+ * General backlight subsystem control
+ *
+ * 3) LMU effect driver
+ * Backlight ramp time configuration
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ti-lmu-backlight.h"
+
+#define LM3697_BL_MAX_STRINGS 3
+#define LM3697_MAX_BRIGHTNESS 2047
+
+static int lm3697_bl_init(struct ti_lmu_bl_chip *chip)
+{
+ /* Configure ramp selection for each bank */
+ return ti_lmu_update_bits(chip->lmu, LM3697_REG_RAMP_CONF,
+ LM3697_RAMP_MASK, LM3697_RAMP_EACH);
+}
+
+static int lm3697_bl_enable(struct ti_lmu_bl *lmu_bl, int enable)
+{
+ return ti_lmu_update_bits(lmu_bl->chip->lmu, LM3697_REG_ENABLE,
+ BIT(lmu_bl->bank_id),
+ enable << lmu_bl->bank_id);
+}
+
+static int lm3697_bl_set_brightness(struct ti_lmu_bl *lmu_bl, int brightness)
+{
+ int ret;
+ u8 data;
+ u8 reg_lsb[] = { LM3697_REG_BRT_A_LSB, LM3697_REG_BRT_B_LSB, };
+ u8 reg_msb[] = { LM3697_REG_BRT_A_MSB, LM3697_REG_BRT_B_MSB, };
+
+ data = brightness & LM3697_BRT_LSB_MASK;
+ ret = ti_lmu_update_bits(lmu_bl->chip->lmu, reg_lsb[lmu_bl->bank_id],
+LM3697_BRT_LSB_MASK, data);
+ if (ret)
+ return ret;
+
+ data = (brightness >> LM3697_BRT_MSB_SHIFT) & 0xFF;
+ return ti_lmu_write_byte(lmu_bl->chip->lmu, reg_msb[lmu_bl->bank_id],
+data);
+}
+
+static int lm3697_bl_set_ctrl_mode(struct ti_lmu_bl *lmu_bl)
+{
+ int bank_id = lmu_bl->bank_id;
+
+ if (lmu_bl->mode == BL_PWM_BASED)
+ return ti_lmu_update_bits(lmu_bl->chip->lmu,
+ LM3697_REG_PWM_CFG,
+ BIT(bank_id), 1 << bank_id);
+
+ return 0;
+}
+
+static int lm3697_bl_string_configure(struct ti_lmu_bl *lmu_bl)
+{
+ struct ti_lmu *lmu = lmu_bl->chip->lmu;
+ int bank_id = lmu_bl->bank_id;
+ int is_detected = 0;
+
[PATCH 04/10] backlight: ti-lmu-backlight: Add LM3631 driver
LM3631 has 2 backlight strings and 11 bit dimming is supported.
PWM brightness control is also supported.
Common backlight driver is controlled by TI LMU backlight driver.
Only LM3631 specific code is implemented here.
Cc: Jingoo Han
Cc: Bryan Wu
Cc: Lee Jones
Signed-off-by: Milo Kim
---
drivers/video/backlight/Kconfig |9 ++
drivers/video/backlight/Makefile|1 +
drivers/video/backlight/lm3631_bl.c | 186 +++
3 files changed, 196 insertions(+)
create mode 100644 drivers/video/backlight/lm3631_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index d841057..a43a015 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -393,6 +393,15 @@ config BACKLIGHT_LM3532
Up to 3 backlight strings and 8 bit dimming is supported.
PWM brightness control is also supported.
+config BACKLIGHT_LM3631
+ tristate "Backlight driver for TI LM3631"
+ depends on BACKLIGHT_CLASS_DEVICE && MFD_TI_LMU
+ select TI_LMU_BACKLIGHT
+ help
+ Say Y to enable the backlight driver for TI LM3631.
+ Up to 2 backlight strings and 11 bit dimming is supported.
+ PWM brightness control is also supported.
+
config TI_LMU_BACKLIGHT
tristate "Backlight driver for TI LMU"
depends on BACKLIGHT_LM3532 || BACKLIGHT_LM3631 || BACKLIGHT_LM3633 ||
BACKLIGHT_LM3695 || BACKLIGHT_LM3697
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 51354d1..2a17f8b 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_BACKLIGHT_LM3533)+= lm3533_bl.o
obj-$(CONFIG_BACKLIGHT_LM3630A)+= lm3630a_bl.o
obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
obj-$(CONFIG_BACKLIGHT_LM3532) += lm3532_bl.o
+obj-$(CONFIG_BACKLIGHT_LM3631) += lm3631_bl.o
obj-$(CONFIG_TI_LMU_BACKLIGHT) += ti-lmu-backlight.o
obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
diff --git a/drivers/video/backlight/lm3631_bl.c
b/drivers/video/backlight/lm3631_bl.c
new file mode 100644
index 000..45693c0
--- /dev/null
+++ b/drivers/video/backlight/lm3631_bl.c
@@ -0,0 +1,186 @@
+/*
+ * TI LM3631 Backlight Driver
+ *
+ * Copyright 2014 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * LM3631 backlight driver consists of three parts
+ *
+ * 1) LM3631 chip specific part: this file
+ * Define device specific operations
+ * Register LMU backlight driver
+ *
+ * 2) LMU backlight common driver: ti-lmu-backlight
+ * General backlight subsystem control
+ *
+ * 3) LMU effect driver
+ * Backlight slope time configuration
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ti-lmu-backlight.h"
+
+#define LM3631_FULL_STRINGS(LMU_HVLED1 | LMU_HVLED2)
+#define LM3631_DEFAULT_MODELM3631_MODE_COMB1
+#define LM3631_MAX_BRIGHTNESS 2047
+
+static int lm3631_bl_init(struct ti_lmu_bl_chip *chip)
+{
+ int ret;
+
+ /* Set OVP to 25V by default */
+ ret = ti_lmu_update_bits(chip->lmu, LM3631_REG_BL_BOOST,
+LM3631_BOOST_OVP_MASK, LM3631_BOOST_OVP_25V);
+ if (ret)
+ return ret;
+
+ /* Set the brightness mode to 'comb1' by default */
+ return ti_lmu_update_bits(chip->lmu, LM3631_REG_BRT_MODE,
+ LM3631_MODE_MASK, LM3631_DEFAULT_MODE);
+}
+
+static int lm3631_bl_enable(struct ti_lmu_bl *lmu_bl, int enable)
+{
+ return ti_lmu_update_bits(lmu_bl->chip->lmu, LM3631_REG_DEVCTRL,
+ LM3631_BL_EN_MASK,
+ enable << LM3631_BL_EN_SHIFT);
+}
+
+static int lm3631_bl_set_brightness(struct ti_lmu_bl *lmu_bl, int brightness)
+{
+ u8 data;
+ int ret;
+
+ if (lmu_bl->mode == BL_PWM_BASED)
+ return 0;
+
+ data = brightness & LM3631_BRT_LSB_MASK;
+ ret = ti_lmu_update_bits(lmu_bl->chip->lmu, LM3631_REG_BRT_LSB,
+LM3631_BRT_LSB_MASK, data);
+ if (ret)
+ return ret;
+
+ data = (brightness >> LM3631_BRT_MSB_SHIFT) & 0xFF;
+ return ti_lmu_write_byte(lmu_bl->chip->lmu, LM3631_REG_BRT_MSB,
+data);
+}
+
+static int lm3631_bl_string_configure(struct ti_lmu_bl *lmu_bl)
+{
+ u8 val;
+
+ if (lmu_bl->bl_pdata->bl_string == LM3631_FULL_STRINGS)
+ val = LM3631_BL_TWO_STRINGS;
+ else
+ val = LM3631_BL_ONE_STRING;
+
+ return
[PATCH 08/10] leds: Add LM3633 driver
LM3633 LED driver supports generic LED functions and pattern generation.
Pattern is generated by using LMU effect driver APIs.
Sysfs documentation is added.
Cc: Bryan Wu
Signed-off-by: Milo Kim
---
Documentation/leds/leds-lm3633.txt | 38 +++
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile |1 +
drivers/leds/leds-lm3633.c | 661
4 files changed, 710 insertions(+)
create mode 100644 Documentation/leds/leds-lm3633.txt
create mode 100644 drivers/leds/leds-lm3633.c
diff --git a/Documentation/leds/leds-lm3633.txt
b/Documentation/leds/leds-lm3633.txt
new file mode 100644
index 000..a5a59c3
--- /dev/null
+++ b/Documentation/leds/leds-lm3633.txt
@@ -0,0 +1,38 @@
+LM3633 LED Driver
+=
+
+LM3633 LED driver supports not only LED functions but also programmable
pattern.
+A pattern is generated via the sysfs.
+
+LED Pattern Generator
+
+(3)
+ (a) ---> ___
+ / \
+ (2) / \ (4)
+ (b) > _/ \_ ...
+ (1) (5)
+
+ |<- period -> |
+
+ Time dimension
+(1) delay : 0 ~ 10 sec
+(2) rise : 0 ~ 16 sec
+(3) high : 0 ~ 10 sec
+(4) fall : 0 ~ 16 sec
+(5) low : 0 ~ 16 sec
+
+ Level dimension - channel current
+(a) low : 0 ~ 255
+(b) high : 0 ~ 255
+
+Example)
+Time : No delay, rise 500ms, high 1000ms, fall 400ms, low 2000ms
+Level : Brightness 0 and 255
+
+echo 0 500 1000 400 2000 > /sys/class/leds//pattern_times
+echo 0 255 > /sys/class/leds//pattern_levels
+echo 1 > /sys/class/leds//run_pattern
+
+To stop running pattern,
+echo 0 > /sys/class/leds//run_pattern
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 72156c1..ed659be 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -63,6 +63,16 @@ config LEDS_LM3533
hardware-accelerated blinking with maximum on and off periods of 9.8
and 77 seconds respectively.
+config LEDS_LM3633
+ tristate "LED support for the TI LM3633 LMU"
+ depends on LEDS_CLASS
+ depends on MFD_TI_LMU
+ help
+ This option enables support for the LEDs on the LM3633.
+ LM3633 has 6 low voltage indicator LEDs.
+ All low voltage current sinks can have a programmable pattern
+ modulated onto LED output strings.
+
config LEDS_LM3642
tristate "LED support for LM3642 Chip"
depends on LEDS_CLASS && I2C
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 3cd76db..96f55fe 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_LEDS_BD2802) += leds-bd2802.o
obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
obj-$(CONFIG_LEDS_LM3530) += leds-lm3530.o
obj-$(CONFIG_LEDS_LM3533) += leds-lm3533.o
+obj-$(CONFIG_LEDS_LM3633) += leds-lm3633.o
obj-$(CONFIG_LEDS_LM3642) += leds-lm3642.o
obj-$(CONFIG_LEDS_MIKROTIK_RB532) += leds-rb532.o
obj-$(CONFIG_LEDS_S3C24XX) += leds-s3c24xx.o
diff --git a/drivers/leds/leds-lm3633.c b/drivers/leds/leds-lm3633.c
new file mode 100644
index 000..13a43bf
--- /dev/null
+++ b/drivers/leds/leds-lm3633.c
@@ -0,0 +1,661 @@
+/*
+ * TI LM3633 LED driver
+ *
+ * Copyright 2014 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * LM3633 LED driver has features below.
+ *
+ * - Generic LED subsystem control
+ * - LED string configuration
+ * - Pattern programming via the sysfs
+ * - Platform data configuration from the device tree nodes
+ *
+ * Pattern generated by using LMU effect driver APIs.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LM3633_LED_MAX_BRIGHTNESS 255
+#define LM3633_DEFAULT_LED_NAME"indicator"
+
+enum lm3633_led_bank_id {
+ LM3633_LED_BANK_C,
+ LM3633_LED_BANK_D,
+ LM3633_LED_BANK_E,
+ LM3633_LED_BANK_F,
+ LM3633_LED_BANK_G,
+ LM3633_LED_BANK_H,
+ LM3633_MAX_LEDS,
+};
+
+struct lm3633_pattern_time {
+ unsigned int delay;
+ unsigned int rise;
+ unsigned int high;
+ unsigned int fall;
+ unsigned int low;
+};
+
+struct lm3633_pattern_level {
+ u8 low;
+ u8 high;
+};
+
+/* One LED chip can have multiple LED strings (max: 6) */
+struct ti_lmu_led_chip {
+ struct device *dev;
+ struct ti_lmu *lmu;
+ struct mutex lock;
+ int num_leds;
+};
+
+/* LED string structure */
+struct ti_lmu_led {
+ enum lm3633_led_bank_id bank_id;
+
+ struct led_classdev cdev;
+
[PATCH 06/10] backlight: ti-lmu-backlight: Add LM3695 driver
LM3695 has 2 backlight strings and 11 bit dimming is supported.
Common backlight driver is controlled by TI LMU backlight driver.
Only LM3695 specific code is implemented here.
Cc: Jingoo Han
Cc: Bryan Wu
Cc: Lee Jones
Signed-off-by: Milo Kim
---
drivers/video/backlight/Kconfig |8 ++
drivers/video/backlight/Makefile|1 +
drivers/video/backlight/lm3695_bl.c | 143 +++
3 files changed, 152 insertions(+)
create mode 100644 drivers/video/backlight/lm3695_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index aa012a3..b169c8d 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -411,6 +411,14 @@ config BACKLIGHT_LM3633
Up to 3 backlight strings and 11 bit dimming is supported.
PWM brightness control is also supported.
+config BACKLIGHT_LM3695
+ tristate "Backlight driver for TI LM3695"
+ depends on BACKLIGHT_CLASS_DEVICE && MFD_TI_LMU
+ select TI_LMU_BACKLIGHT
+ help
+ Say Y to enable the backlight driver for TI LM3695.
+ Up to 2 backlight strings and 11 bit dimming is supported.
+
config TI_LMU_BACKLIGHT
tristate "Backlight driver for TI LMU"
depends on BACKLIGHT_LM3532 || BACKLIGHT_LM3631 || BACKLIGHT_LM3633 ||
BACKLIGHT_LM3695 || BACKLIGHT_LM3697
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 842a256..5427162 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_BACKLIGHT_LM3639)+= lm3639_bl.o
obj-$(CONFIG_BACKLIGHT_LM3532) += lm3532_bl.o
obj-$(CONFIG_BACKLIGHT_LM3631) += lm3631_bl.o
obj-$(CONFIG_BACKLIGHT_LM3633) += lm3633_bl.o
+obj-$(CONFIG_BACKLIGHT_LM3695) += lm3695_bl.o
obj-$(CONFIG_TI_LMU_BACKLIGHT) += ti-lmu-backlight.o
obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
diff --git a/drivers/video/backlight/lm3695_bl.c
b/drivers/video/backlight/lm3695_bl.c
new file mode 100644
index 000..959e72a
--- /dev/null
+++ b/drivers/video/backlight/lm3695_bl.c
@@ -0,0 +1,143 @@
+/*
+ * TI LM3695 Backlight Driver
+ *
+ * Copyright 2014 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * LM3695 backlight driver consists of two parts
+ *
+ * 1) LM3695 chip specific part: this file
+ * Define device specific operations
+ * Register LMU backlight driver
+ *
+ * 2) LMU backlight common driver: ti-lmu-backlight
+ * General backlight subsystem control
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ti-lmu-backlight.h"
+
+#define LM3695_FULL_STRINGS(LMU_HVLED1 | LMU_HVLED2)
+#define LM3695_MAX_BRIGHTNESS 2047
+
+static int lm3695_bl_enable(struct ti_lmu_bl *lmu_bl, int enable)
+{
+ int ret;
+
+ ret = ti_lmu_update_bits(lmu_bl->chip->lmu, LM3695_REG_GP,
+LM3695_BL_EN_MASK, enable);
+ if (ret)
+ return ret;
+
+ /* Wait time for brightness register wake up */
+ usleep_range(600, 700);
+
+ return 0;
+}
+
+static int lm3695_bl_set_brightness(struct ti_lmu_bl *lmu_bl, int brightness)
+{
+ u8 data;
+ int ret;
+
+ data = brightness & LM3695_BRT_LSB_MASK;
+ ret = ti_lmu_update_bits(lmu_bl->chip->lmu, LM3695_REG_BRT_LSB,
+LM3695_BRT_LSB_MASK, data);
+ if (ret)
+ return ret;
+
+ data = (brightness >> LM3695_BRT_MSB_SHIFT) & 0xFF;
+ return ti_lmu_write_byte(lmu_bl->chip->lmu, LM3695_REG_BRT_MSB,
+data);
+}
+
+static int lm3695_bl_init(struct ti_lmu_bl_chip *chip)
+{
+ return ti_lmu_update_bits(chip->lmu, LM3695_REG_GP,
+ LM3695_BRT_RW_MASK, LM3695_BRT_SET_RW);
+}
+
+static int lm3695_bl_configure(struct ti_lmu_bl *lmu_bl)
+{
+ u8 val;
+
+ if (lmu_bl->bl_pdata->bl_string == LM3695_FULL_STRINGS)
+ val = LM3695_BL_TWO_STRINGS;
+ else
+ val = LM3695_BL_ONE_STRING;
+
+ return ti_lmu_update_bits(lmu_bl->chip->lmu, LM3695_REG_GP,
+ LM3695_BL_STRING_MASK, val);
+}
+
+static const struct ti_lmu_bl_ops lm3695_lmu_ops = {
+ .init = lm3695_bl_init,
+ .configure = lm3695_bl_configure,
+ .update_brightness = lm3695_bl_set_brightness,
+ .bl_enable = lm3695_bl_enable,
+ .max_brightness= LM3695_MAX_BRIGHTNESS,
+};
+
+static int lm3695_bl_probe(struct platform_device *pdev)
+{
+ struct ti_lmu *lmu = dev_get_drvdata(pdev->dev.parent);
+
[PATCH 01/10] mfd: Add TI LMU driver
TI LMU (Lighting Management Unit) driver supports lighting devices such like
LM3532, LM3631, LM3633, LM3695 and LM3697.
LMU devices has common features as below.
- I2C interface for accessing device registers
- Hardware enable pin control
- Backlight brightness control
- Light effect driver for backlight and LED patterns
It contains backlight, light effect, LED and regulator driver.
Backlight
-
It's handled by TI LMU backlight common driver and chip dependent driver.
Please refer to separate patches for ti-lmu-backlight.
Light effect
LMU effect driver is used for setting any light effects.
Each device has specific time value and register map.
Backlight and LED driver can use consitent APIs for light effects.
There are two lists for effect management. LMU effect list and pending list.
Light effect list is added when ti-lmu-effect driver is loaded by referencing
platform resource data.
However, it can be a problem because some LMU device requests the effect
in advance of loading ti-lmu-effect driver.
For example, LM3532 backlight driver requests light ramp effects before
ti-lmu-effect is loaded.
Then, requested effect can not be handled because it doesn't exist in the
list.
To solve this situation, pending request list is used.
If requested effect is not in the list, just insert it into the pending list.
And then pending request is handled as soon as the effect is added.
LED indicator
-
LM3633 has 6 indicator LEDs. Programmable pattern is supported.
Regulator
-
LM3631 has 5 regulators for the display bias.
Cc: Samuel Ortiz
Cc: Lee Jones
Signed-off-by: Milo Kim
---
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile|1 +
drivers/mfd/ti-lmu-effect.c | 328 +
drivers/mfd/ti-lmu.c| 464 +++
include/linux/mfd/ti-lmu-effect.h | 109
include/linux/mfd/ti-lmu-register.h | 269
include/linux/mfd/ti-lmu.h | 150 +++
7 files changed, 1333 insertions(+)
create mode 100644 drivers/mfd/ti-lmu-effect.c
create mode 100644 drivers/mfd/ti-lmu.c
create mode 100644 include/linux/mfd/ti-lmu-effect.h
create mode 100644 include/linux/mfd/ti-lmu-register.h
create mode 100644 include/linux/mfd/ti-lmu.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d4be491..e7e1e6b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -784,6 +784,18 @@ config MFD_PALMAS
If you say yes here you get support for the Palmas
series of PMIC chips from Texas Instruments.
+config MFD_TI_LMU
+ tristate "TI Lighting Management Unit driver"
+ depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ Say yes here to enable support for TI LMU chips.
+
+ TI LMU MFD supports LM3532, LM3631, LM3633, LM3695 and LM3697.
+ It consists of backlight, light effect, LED and regulator driver.
+ It provides consistent device controls for lighting functions.
+
config MFD_TI_SSP
tristate "TI Sequencer Serial Port support"
depends on ARCH_DAVINCI_TNETV107X
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 93c7cad..02dc65a 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o
obj-$(CONFIG_MFD_DAVINCI_VOICECODEC) += davinci_voicecodec.o
obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
+obj-$(CONFIG_MFD_TI_LMU) += ti-lmu.o ti-lmu-effect.o
obj-$(CONFIG_MFD_TI_SSP) += ti-ssp.o
obj-$(CONFIG_MFD_TI_AM335X_TSCADC) += ti_am335x_tscadc.o
diff --git a/drivers/mfd/ti-lmu-effect.c b/drivers/mfd/ti-lmu-effect.c
new file mode 100644
index 000..a4a3d26
--- /dev/null
+++ b/drivers/mfd/ti-lmu-effect.c
@@ -0,0 +1,328 @@
+/*
+ * TI LMU Effect Driver
+ *
+ * Copyright 2014 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * LMU effect driver is used for setting any light effects.
+ * Each device has specific time value and register map.
+ * Light effect can be controlled with consistent APIs.
+ *
+ * Examples:
+ * Backlight ramp time control - LM3532, LM3631, LM3633 and LM3697
+ * LED pattern display - LM3633
+ *
+ * Flow:
+ * 1) LMU backlight and LED drivers request to the light effect driver
+ * by using ti_lmu_effect_request().
+ * 2) Call ti_lmu_effect_set_* APIs in each callback function.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define LMU_EFFECT_MAX_TIME_PERIOD 9700
+
+struct ti_lmu_effect_req {
+ struct list_head list;
+ const char *name;
+ ti_lmu_effect_cb_t *cbfunc;
+ int req_id;
+ void *data;
+};
+
+struct
[PATCH 02/10] backlight: Add TI LMU backlight common driver
TI LMU backlight driver provides common driver features.
Chip specific configuration is handled by each backlight driver such like
LM3532, LM3631, LM3633, LM3695 and LM3697.
It supports common features as below.
- Consistent device control flow
- Control bank assignment from the platform data
- Backlight subsystem control
- PWM brightness control
- Shared device tree node
Cc: Jingoo Han
Cc: Bryan Wu
Cc: Lee Jones
Signed-off-by: Milo Kim
---
drivers/video/backlight/Kconfig|7 +
drivers/video/backlight/Makefile |1 +
drivers/video/backlight/ti-lmu-backlight.c | 369
drivers/video/backlight/ti-lmu-backlight.h | 78 ++
4 files changed, 455 insertions(+)
create mode 100644 drivers/video/backlight/ti-lmu-backlight.c
create mode 100644 drivers/video/backlight/ti-lmu-backlight.h
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 5a3eb2e..3641698 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -384,6 +384,13 @@ config BACKLIGHT_LM3639
help
This supports TI LM3639 Backlight + 1.5A Flash LED Driver
+config TI_LMU_BACKLIGHT
+ tristate "Backlight driver for TI LMU"
+ depends on BACKLIGHT_LM3532 || BACKLIGHT_LM3631 || BACKLIGHT_LM3633 ||
BACKLIGHT_LM3695 || BACKLIGHT_LM3697
+ help
+ TI LMU backlight driver provides common driver features.
+ Chip specific configuration is handled by each backlight driver.
+
config BACKLIGHT_LP855X
tristate "Backlight driver for TI LP855X"
depends on BACKLIGHT_CLASS_DEVICE && I2C
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index bb82002..f80e046 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_BACKLIGHT_HP700) += jornada720_bl.o
obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
obj-$(CONFIG_BACKLIGHT_LM3630A)+= lm3630a_bl.o
obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
+obj-$(CONFIG_TI_LMU_BACKLIGHT) += ti-lmu-backlight.o
obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
obj-$(CONFIG_BACKLIGHT_LP8788) += lp8788_bl.o
diff --git a/drivers/video/backlight/ti-lmu-backlight.c
b/drivers/video/backlight/ti-lmu-backlight.c
new file mode 100644
index 000..5ceb5e8
--- /dev/null
+++ b/drivers/video/backlight/ti-lmu-backlight.c
@@ -0,0 +1,369 @@
+/*
+ * TI LMU Backlight Common Driver
+ *
+ * Copyright 2014 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * LMU backlight driver supports common features as below.
+ *
+ * - Consistent device control flow by using ti_lmu_bl_ops
+ * - Control bank assignment from the platform data
+ * - Backlight subsystem control
+ * - PWM brightness control
+ * - Shared device tree node
+ *
+ * Sequence of LMU backlight control
+ *
+ * (Chip dependent backlight driver)(TI LMU Backlight Common)
+ *
+ * Operation configuration
+ * ti_lmu_backlight_init_device() --->
+ * Initialization <---ops->init()
+ *
+ * ti_lmu_backlight_register() --->
+ * Backlight configuration <---ops->configure()
+ *
+ * Runtime brightness control
+ * Enable register control <---ops->bl_enable()
+ * Brightness register control <---ops->update_brightness()
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ti-lmu-backlight.h"
+
+#define DEFAULT_BL_NAME"lcd-backlight"
+
+static int ti_lmu_backlight_enable(struct ti_lmu_bl *lmu_bl, int enable)
+{
+ const struct ti_lmu_bl_ops *ops = lmu_bl->chip->ops;
+
+ if (ops->bl_enable)
+ return ops->bl_enable(lmu_bl, enable);
+
+ return 0;
+}
+
+static void ti_lmu_backlight_pwm_ctrl(struct ti_lmu_bl *lmu_bl, int br,
+ int max_br)
+{
+ struct pwm_device *pwm;
+ unsigned int duty, period;
+
+ /* Request a PWM device with the consumer name */
+ if (!lmu_bl->pwm) {
+ pwm = devm_pwm_get(lmu_bl->chip->dev, lmu_bl->pwm_name);
+ if (IS_ERR(pwm)) {
+ dev_err(lmu_bl->chip->dev,
+ "Can not get PWM device: %s\n",
+ lmu_bl->pwm_name);
+ return;
+ }
+ lmu_bl->pwm = pwm;
+ }
+
+ period = lmu_bl->bl_pdata->pwm_period;
+ duty = br * period / max_br;
+
+ pwm_config(lmu_bl->pwm, duty, period);
+ if
[PATCH 03/10] backlight: ti-lmu-backlight: Add LM3532 driver
LM3532 has 3 backlight strings and 8 bit dimming is supported.
PWM brightness control is also supported.
Common backlight driver is controlled by TI LMU backlight driver.
Only LM3532 specific code is implemented here.
Cc: Jingoo Han
Cc: Bryan Wu
Cc: Lee Jones
Signed-off-by: Milo Kim
---
drivers/video/backlight/Kconfig |9 ++
drivers/video/backlight/Makefile|1 +
drivers/video/backlight/lm3532_bl.c | 240 +++
3 files changed, 250 insertions(+)
create mode 100644 drivers/video/backlight/lm3532_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 3641698..d841057 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -384,6 +384,15 @@ config BACKLIGHT_LM3639
help
This supports TI LM3639 Backlight + 1.5A Flash LED Driver
+config BACKLIGHT_LM3532
+ tristate "Backlight driver for TI LM3532"
+ depends on BACKLIGHT_CLASS_DEVICE && MFD_TI_LMU
+ select TI_LMU_BACKLIGHT
+ help
+ Say Y to enable the backlight driver for TI LM3532.
+ Up to 3 backlight strings and 8 bit dimming is supported.
+ PWM brightness control is also supported.
+
config TI_LMU_BACKLIGHT
tristate "Backlight driver for TI LMU"
depends on BACKLIGHT_LM3532 || BACKLIGHT_LM3631 || BACKLIGHT_LM3633 ||
BACKLIGHT_LM3695 || BACKLIGHT_LM3697
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index f80e046..51354d1 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_BACKLIGHT_HP700) += jornada720_bl.o
obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
obj-$(CONFIG_BACKLIGHT_LM3630A)+= lm3630a_bl.o
obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
+obj-$(CONFIG_BACKLIGHT_LM3532) += lm3532_bl.o
obj-$(CONFIG_TI_LMU_BACKLIGHT) += ti-lmu-backlight.o
obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
diff --git a/drivers/video/backlight/lm3532_bl.c
b/drivers/video/backlight/lm3532_bl.c
new file mode 100644
index 000..c4cf636
--- /dev/null
+++ b/drivers/video/backlight/lm3532_bl.c
@@ -0,0 +1,240 @@
+/*
+ * TI LM3532 Backlight Driver
+ *
+ * Copyright 2014 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * LM3532 backlight driver consists of three parts
+ *
+ * 1) LM3532 chip specific part: this file
+ * Define device specific operations
+ * Register LMU backlight driver
+ *
+ * 2) LMU backlight common driver: ti-lmu-backlight
+ * General backlight subsystem control
+ *
+ * 3) LMU effect driver
+ * Backlight ramp time configuration
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ti-lmu-backlight.h"
+
+#define LM3532_PWM10
+#define LM3532_PWM21
+#define LM3532_BL_MAX_STRINGS 3
+#define LM3532_MAX_ZONE_CFG3
+#define LM3532_MAX_BRIGHTNESS 255
+
+static int lm3532_bl_init(struct ti_lmu_bl_chip *chip)
+{
+ int i, ret;
+ u8 lm3532_regs[] = { LM3532_REG_ZONE_CFG_A, LM3532_REG_ZONE_CFG_B,
+LM3532_REG_ZONE_CFG_C, };
+
+ /*
+* Assign zone targets as below.
+* Zone target 0 for control A
+* Zone target 1 for control B
+* Zone target 2 for control C
+*/
+
+ for (i = 0; i < LM3532_MAX_ZONE_CFG; i++) {
+ ret = ti_lmu_update_bits(chip->lmu, lm3532_regs[i],
+LM3532_ZONE_CFG_MASK,
+i << LM3532_ZONE_CFG_SHIFT);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int lm3532_bl_enable(struct ti_lmu_bl *lmu_bl, int enable)
+{
+ return ti_lmu_update_bits(lmu_bl->chip->lmu, LM3532_REG_ENABLE,
+ BIT(lmu_bl->bank_id),
+ enable << lmu_bl->bank_id);
+}
+
+static int lm3532_bl_set_brightness(struct ti_lmu_bl *lmu_bl, int brightness)
+{
+ u8 reg[] = { LM3532_REG_BRT_A, LM3532_REG_BRT_B, LM3532_REG_BRT_C, };
+
+ return ti_lmu_write_byte(lmu_bl->chip->lmu, reg[lmu_bl->bank_id],
+brightness);
+}
+
+static int lm3532_bl_select_pwm_bank(struct ti_lmu_bl *lmu_bl, int bank_id)
+{
+ struct ti_lmu *lmu = lmu_bl->chip->lmu;
+ static int num_pwms;
+ u8 pwm_sel;
+ u8 mask[] = { LM3532_PWM_SEL_A_MASK, LM3532_PWM_SEL_B_MASK,
+ LM3532_PWM_SEL_C_MASK, };
+ u8 shift[] = { LM3532_PWM_SEL_A_SHIFT, LM3532_PWM_SEL_B_SHIFT,
+
[PATCH 00/10] Support TI Light Management Unit devices
TI LMU (Lighting Management Unit) driver supports lighting devices such like LM3532, LM3631, LM3633, LM3695 and LM3697. Enable pin Backlights PWM control Light effects Others -- -- --- - -- LM3532 Yes Yes Yes ramp up/down LM3631 Yes Yes Yes slope 5 regulators LM3633 Yes Yes Yes ramp up/down LEDs /pattern LM3695 Yes Yes No LM3697 Yes Yes Yes ramp up/down This patch-set consists of several parts below. TI LMU: HW enable pin control. I2C register access TI LMU effect : Light effect support for backlight and LED TI LMU backlight : Backlight subsystem, PWM, control bank assignment Each backlight driver : Chip dependent code LM3633 LED: LED subsystem, pattern generation LM3631 regulator : Regulator drivers for the display bias Device tree documentation is also included. Milo Kim (10): mfd: Add TI LMU driver backlight: Add TI LMU backlight common driver backlight: ti-lmu-backlight: Add LM3532 driver backlight: ti-lmu-backlight: Add LM3631 driver backlight: ti-lmu-backlight: Add LM3633 driver backlight: ti-lmu-backlight: Add LM3695 driver backlight: ti-lmu-backlight: Add LM3697 driver leds: Add LM3633 driver regulator: Add LM3631 driver Documentation: Add device tree bindings for TI LMU devices .../devicetree/bindings/leds/leds-lm3633.txt | 39 ++ Documentation/devicetree/bindings/mfd/ti-lmu.txt | 182 ++ .../bindings/regulator/lm3631-regulator.txt| 49 ++ .../bindings/video/backlight/ti-lmu-backlight.txt | 127 Documentation/leds/leds-lm3633.txt | 38 ++ drivers/leds/Kconfig | 10 + drivers/leds/Makefile |1 + drivers/leds/leds-lm3633.c | 661 drivers/mfd/Kconfig| 12 + drivers/mfd/Makefile |1 + drivers/mfd/ti-lmu-effect.c| 328 ++ drivers/mfd/ti-lmu.c | 464 ++ drivers/regulator/Kconfig |8 + drivers/regulator/Makefile |1 + drivers/regulator/lm3631-regulator.c | 285 + drivers/video/backlight/Kconfig| 51 ++ drivers/video/backlight/Makefile |6 + drivers/video/backlight/lm3532_bl.c| 240 +++ drivers/video/backlight/lm3631_bl.c| 186 ++ drivers/video/backlight/lm3633_bl.c| 244 drivers/video/backlight/lm3695_bl.c| 143 + drivers/video/backlight/lm3697_bl.c| 224 +++ drivers/video/backlight/ti-lmu-backlight.c | 369 +++ drivers/video/backlight/ti-lmu-backlight.h | 78 +++ include/linux/mfd/ti-lmu-effect.h | 109 include/linux/mfd/ti-lmu-register.h| 269 include/linux/mfd/ti-lmu.h | 150 + 27 files changed, 4275 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3633.txt create mode 100644 Documentation/devicetree/bindings/mfd/ti-lmu.txt create mode 100644 Documentation/devicetree/bindings/regulator/lm3631-regulator.txt create mode 100644 Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt create mode 100644 Documentation/leds/leds-lm3633.txt create mode 100644 drivers/leds/leds-lm3633.c create mode 100644 drivers/mfd/ti-lmu-effect.c create mode 100644 drivers/mfd/ti-lmu.c create mode 100644 drivers/regulator/lm3631-regulator.c create mode 100644 drivers/video/backlight/lm3532_bl.c create mode 100644 drivers/video/backlight/lm3631_bl.c create mode 100644 drivers/video/backlight/lm3633_bl.c create mode 100644 drivers/video/backlight/lm3695_bl.c create mode 100644 drivers/video/backlight/lm3697_bl.c create mode 100644 drivers/video/backlight/ti-lmu-backlight.c create mode 100644 drivers/video/backlight/ti-lmu-backlight.h create mode 100644 include/linux/mfd/ti-lmu-effect.h create mode 100644 include/linux/mfd/ti-lmu-register.h create mode 100644 include/linux/mfd/ti-lmu.h -- 1.7.9.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: 3.12.9-rt13: BUG: soft lockup
On 02/13/2014 03:55 PM, Thomas Gleixner wrote: On Thu, 13 Feb 2014, Fernando Lopez-Lezcano wrote: On 02/13/2014 02:25 PM, Thomas Gleixner wrote: On Wed, 12 Feb 2014, Fernando Lopez-Lezcano wrote: [771508.546449] RIP: 0010:[] [] smp_call_function_many+0x2ca/0x330 Can you decode the exact location inside of smp_call_function_many via addr2line please ? Hope this is useful (adding 0x2ce/0x330 as offsets does not make any difference, don't know if it should)... # grep smp_call_function /var/log/messages|tail -1 Feb 12 14:18:21 cmn27 kernel: [771840.224419] RIP: 0010:[] [] smp_call_function_many+0x2ce/0x330 # addr2line -e /usr/lib/debug/lib/modules/3.12.10-300.rt15.1.fc20.ccrma.x86_64+rt/vmlinux 810dc60e /usr/src/debug/kernel-3.12.fc20.ccrma/linux-3.12.10-300.rt15.1.fc20.ccrma.x86_64/kernel/rtmutex.c:1295 I can't see how the kernel decoder thinks it's smp_call_function_many but addr2line looks at rtmutex.c That doesn't make any sense at all. Version mismatch? Indeed, sorry for the mixup... here I go again, hopefully this one will make sense: # addr2line -e /usr/lib/debug/lib/modules/3.12.9-301.rt13.1.fc20.ccrma.x86_64+rt/vmlinux 810dc60e /usr/src/debug/kernel-3.12.fc20.ccrma/linux-3.12.9-301.rt13.1.fc20.ccrma.x86_64/kernel/smp.c:108 -- Fernando -- 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 RESEND] staging: android: lowmemorykiller: set TIF_MEMDIE before send kill sig
Set TIF_MEMDIE tsk_thread flag before send kill signal to the selected thread. This is to fit a usual code sequence and avoid potential race issue. Signed-off-by: Weijie Yang --- drivers/staging/android/lowmemorykiller.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c index 6f094b3..4bcf00a --- a/drivers/staging/android/lowmemorykiller.c +++ b/drivers/staging/android/lowmemorykiller.c @@ -159,8 +159,8 @@ static unsigned long lowmem_scan(struct shrinker *s, struct shrink_control *sc) selected->pid, selected->comm, selected_oom_score_adj, selected_tasksize); lowmem_deathpending_timeout = jiffies + HZ; - send_sig(SIGKILL, selected, 0); set_tsk_thread_flag(selected, TIF_MEMDIE); + send_sig(SIGKILL, selected, 0); rem += selected_tasksize; } -- 1.7.10.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 00/10] mm: thrash detection-based file cache sizing v9
Johannes Weiner wrote:
> Thanks for the report. There is already a fix for this in -mm:
> http://marc.info/?l=linux-mm-commits=139180637114625=2
>
> It was merged on the 7th, so it should show up in -next... any day
> now?
That patch solved this bproblem but breaks build instead.
ERROR: \"list_lru_init_key\" [fs/xfs/xfs.ko] undefined!
ERROR: \"list_lru_init_key\" [fs/gfs2/gfs2.ko] undefined!
make[1]: *** [__modpost] Error 1
diff --git a/mm/list_lru.c b/mm/list_lru.c
index 2a5b8fd..f1a0db1 100644
--- a/mm/list_lru.c
+++ b/mm/list_lru.c
@@ -143,7 +143,7 @@ int list_lru_init_key(struct list_lru *lru, struct
lock_class_key *key)
}
return 0;
}
-EXPORT_SYMBOL_GPL(list_lru_init);
+EXPORT_SYMBOL_GPL(list_lru_init_key);
void list_lru_destroy(struct list_lru *lru)
{
--
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 PATCH V5] mm readahead: Fix readahead fail for no local memory and limit readahead pages
On 13.02.2014 [14:41:04 -0800], David Rientjes wrote: > On Thu, 13 Feb 2014, Raghavendra K T wrote: > > > Thanks David, unfortunately even after applying that patch, I do not see > > the improvement. > > > > Interestingly numa_mem_id() seem to still return the value of a > > memoryless node. > > May be per cpu _numa_mem_ values are not set properly. Need to dig out > > > > I believe ppc will be relying on __build_all_zonelists() to set > numa_mem_id() to be the proper node, and that relies on the ordering of > the zonelist built for the memoryless node. It would be very strange if > local_memory_node() is returning a memoryless node because it is the first > zone for node_zonelist(GFP_KERNEL) (why would a memoryless node be on the > zonelist at all?). > > I think the real problem is that build_all_zonelists() is only called at > init when the boot cpu is online so it's only setting numa_mem_id() > properly for the boot cpu. Does it return a node with memory if you > toggle /proc/sys/vm/numa_zonelist_order? Do > > echo node > /proc/sys/vm/numa_zonelist_order > echo zone > /proc/sys/vm/numa_zonelist_order > echo default > /proc/sys/vm/numa_zonelist_order > > and check if it returns the proper value at either point. This will force > build_all_zonelists() and numa_mem_id() to point to the proper node since > all cpus are now online. Yep, after massaging the code to allow CONFIG_USE_PERCPU_NUMA_NODE_ID, you're right that the memory node is wrong. The cpu node is right (they are all on node 0), but that could be lucky. The memory node is right for the boot cpu. I did notice that some CPUs now think the cpu node is 1, which is wrong. > So the prerequisite for CONFIG_HAVE_MEMORYLESS_NODES is that there is an > arch-specific set_numa_mem() that makes this mapping correct like ia64 > does. If that's the case, then it's (1) completely undocumented and (2) > Nishanth's patch is incomplete because anything that adds > CONFIG_HAVE_MEMORYLESS_NODES needs to do the proper set_numa_mem() for it > to be any different than numa_node_id(). I'll work on getting the set_numa_mem() and set_numa_node() correct for powerpc. Thanks, Nish -- 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 1/2] mmc: omap_hsmmc: Add support for quirky omap3 hsmmc controller
When device is booted using devicetree, platforms impacted by Erratum
2.1.1.128 is not detected easily in the mmc driver. This erratum
indicates that the module cannot do multi-block transfers. Platforms
such as LDP which use OMAP3 ES revision prior to ES3.0 are impacted by
this.
Provide a new compatible property "ti,omap3-pre-es3-hsmmc" to allow
driver to determine if driver needs to implement quirks associated
with the specific module version (primarily because the IP revision
information is not sufficient for the same).
Signed-off-by: Nishanth Menon
---
Changes since v1:
- new compatible flag as suggested by Tony which contains
the relevant controller flag to work around the erratum
V1: https://patchwork.kernel.org/patch/3514851/
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 +
drivers/mmc/host/omap_hsmmc.c | 26 +---
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 8c8908a..ce80561 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -10,6 +10,7 @@ Required properties:
- compatible:
Should be "ti,omap2-hsmmc", for OMAP2 controllers
Should be "ti,omap3-hsmmc", for OMAP3 controllers
+ Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0
Should be "ti,omap4-hsmmc", for OMAP4 controllers
- ti,hwmods: Must be "mmc", n is controller instance starting 1
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 575f9cc..390f421 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -192,6 +192,11 @@ struct omap_hsmmc_host {
struct omap_mmc_platform_data *pdata;
};
+struct omap_mmc_of_data {
+ u32 reg_offset;
+ u8 controller_flags;
+};
+
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -1678,18 +1683,29 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
#endif
#ifdef CONFIG_OF
-static u16 omap4_reg_offset = 0x100;
+static const struct omap_mmc_of_data omap3_pre_es3_mmc_of_data = {
+ /* See 35xx errata 2.1.1.128 in SPRZ278F */
+ .controller_flags = OMAP_HSMMC_BROKEN_MULTIBLOCK_READ,
+};
+
+static const struct omap_mmc_of_data omap4_mmc_of_data = {
+ .reg_offset = 0x100,
+};
static const struct of_device_id omap_mmc_of_match[] = {
{
.compatible = "ti,omap2-hsmmc",
},
{
+ .compatible = "ti,omap3-pre-es3-hsmmc",
+ .data = _pre_es3_mmc_of_data,
+ },
+ {
.compatible = "ti,omap3-hsmmc",
},
{
.compatible = "ti,omap4-hsmmc",
- .data = _reg_offset,
+ .data = _mmc_of_data,
},
{},
};
@@ -1759,6 +1775,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
struct pinctrl *pinctrl;
+ const struct omap_mmc_of_data *data;
match = of_match_device(of_match_ptr(omap_mmc_of_match), >dev);
if (match) {
@@ -1768,8 +1785,9 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
return PTR_ERR(pdata);
if (match->data) {
- const u16 *offsetp = match->data;
- pdata->reg_offset = *offsetp;
+ data = match->data;
+ pdata->reg_offset = data->reg_offset;
+ pdata->controller_flags |= data->controller_flags;
}
}
--
1.7.9.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 V2 2/2] ARM: dts: omap3-ldp: fix mmc configuration
MMC1 is the only MMC interface available on the platform. Further,
since the platform is based on older revision of SoC which is not
capable of doing multi-block reads, mark it with compatibility for the
same and add pinmux to ensure that all relevant pins are configured
for non-MMC boot mode.
Signed-off-by: Nishanth Menon
---
Changes since V1:
- fixed commit message as suggested by Balaji.
- update to use new compatible match for the erratum.
V1: https://patchwork.kernel.org/patch/3514881/
arch/arm/boot/dts/omap3-ldp.dts | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index ddce0d8..0abe986 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -174,8 +174,20 @@
};
{
+ /* See 35xx errata 2.1.1.128 in SPRZ278F */
+ compatible = "ti,omap3-pre-es3-hsmmc";
vmmc-supply = <>;
bus-width = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+};
+
+ {
+ status="disabled";
+};
+
+ {
+ status="disabled";
};
_pmx_core {
@@ -209,6 +221,17 @@
0x174 (PIN_OUTPUT | MUX_MODE0) /*
hsusb0_stp.hsusb0_stp */
>;
};
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_clk.mmc1_clk */
+ OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_cmd.mmc1_cmd */
+ OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat0.mmc1_dat0 */
+ OMAP3_CORE1_IOPAD(0x214A, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat1.mmc1_dat1 */
+ OMAP3_CORE1_IOPAD(0x214C, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat2.mmc1_dat2 */
+ OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat3.mmc1_dat3 */
+ >;
+ };
};
_otg_hs {
--
1.7.9.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 V2 0/2] mmc: omap_hsmmc: fix for pre es3.0 OMAP3
Originally reported in: https://patchwork.kernel.org/patch/3514851/ https://patchwork.kernel.org/patch/3514881/ ES3.0+ provides MMC controller which is fixed for multi-block reads, however LDP platform Looking at the various IP revision register information: sdp2430: Revision: 1.2, Spec: 0.0, normal interrupt OMAP3430-ldp: (ES2.1): Revision: 2.6, Spec: 0.0, normal interrupt SDP3430:(ES3.0) Revision: 2.6, Spec: 0.0, normal interrupt AM3517-evm: (ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt AM3517-crane:(ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt AM37x-evm: (ES1.2) Revision: 2.6, Spec: 0.0, normal interrupt OMAP3630-beag-xm (ES1.2): Revision: 2.6, Spec: 0.0, normal interrupt am335x-evm:(ES1.0): Revision: 3.1, Spec: 0.1, normal interrupt am335x-sk: (ES2.1): Revision: 3.1, Spec: 0.1, normal interrupt am335x-beaglebone-black:(ES2.0): Revision: 3.1, Spec: 0.1, normal interrupt sdp4430: (ES2.2): Revision: 3.1, Spec: 0.1, normal interrupt OMAP4460-panda-es (ES1.1): Revision: 3.1, Spec: 0.1, normal interrupt OMAP5uevm:(ES2.0): Revision: 3.3, Spec: 0.2, normal interrupt dra7-evm (es1.1): Revision: 3.3, Spec: 0.2, normal interrupt This series has been tested on the following platforms: 1: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2ObUDfm5N 2: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2xmviGgFf 3: dra7: Boot PASS: http://slexy.org/raw/s2Ad6rxaQk 4:ldp: Boot PASS: http://slexy.org/raw/s20kEx9eHg 5: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s2gHT1EWKF 6:sdp2430: Boot PASS: http://slexy.org/raw/s20dvr8yQA (nfs) 7:sdp3430: Boot PASS: http://slexy.org/raw/s2aUEsEemS 8:sdp4430: Boot PASS: http://slexy.org/raw/s20nqL8gjz 9: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s20O0QfmZw TOTAL = 9 boards, Booted Boards = 9, No Boot boards = 0 LDP platform prior to the series reports: http://slexy.org/raw/s20qVg17T0 Series is based on v3.14-rc2 Nishanth Menon (2): mmc: omap_hsmmc: Add support for quirky omap3 hsmmc controller ARM: dts: omap3-ldp: fix mmc configuration .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 + arch/arm/boot/dts/omap3-ldp.dts| 23 + drivers/mmc/host/omap_hsmmc.c | 26 +--- 3 files changed, 46 insertions(+), 4 deletions(-) -- 1.7.9.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 -tip v3 00/11] perf-probe: Updates for handling local functions correctly and distro debuginfo
Ping? :) (2014/02/06 14:32), Masami Hiramatsu wrote: > Hi, > > Here is the 3rd version of the series for handling local > functions correctly with perf-probe. This version also > includes distro debuginfo-file support (a small > enhancement, based on existing feature). > > In this version, I used ref_reloc_sym based probe point > instead of absolute address/"_stext", because kASLR > changes the address offset randomly and the debuginfo > doesn't know that offset. Recently perftools supports > kASLR by introducing ref_reloc_sym (which is usually > "_text" or "_stext"). Since we already ensured that > the kmap->ref_reloc_sym symbol exists in the kernel, > it is safe to reuse it for the reference point of > probe points. > > Note that this series requires a bugfix patch: > perf-probe: Do not add offset to uprobe address > https://lkml.org/lkml/2014/2/5/7 > > > Issue 1) > Current perf-probe can't handle probe-points for kprobes, > since it uses symbol-based probe definition. The symbol > based definition is easy to read and robust for differnt > kernel and modules. However, when user gives a local > function name which has several different instances, > it may put probes on wrong (or unexpected) address. > On the other hand, since uprobe events are based on the > actual address, it can avoid this issue. > > E.g. > In the case to probe t_show local functions (which has > 4 different instances. > > # grep " t_show\$" /proc/kallsyms > 810d9720 t t_show > 810e2e40 t t_show > 810ece30 t t_show > 810f4ad0 t t_show > # ./perf probe -fa "t_show \$vars" > Added new events: > probe:t_show (on t_show with $vars) > probe:t_show_1 (on t_show with $vars) > probe:t_show_2 (on t_show with $vars) > probe:t_show_3 (on t_show with $vars) > > You can now use it in all perf tools, such as: > > perf record -e probe:t_show_3 -aR sleep 1 > > OK, we have 4 different t_show()s. All functions have > different arguments as below; > > # cat /sys/kernel/debug/tracing/kprobe_events > p:probe/t_show t_show m=%di:u64 v=%si:u64 > p:probe/t_show_1 t_show m=%di:u64 v=%si:u64 t=%si:u64 > p:probe/t_show_2 t_show m=%di:u64 v=%si:u64 fmt=%si:u64 > p:probe/t_show_3 t_show m=%di:u64 v=%si:u64 file=%si:u64 > > However, all of them have been put on the *same* address. > > # cat /sys/kernel/debug/kprobes/list > 810d9720 k t_show+0x0[DISABLED] > 810d9720 k t_show+0x0[DISABLED] > 810d9720 k t_show+0x0[DISABLED] > 810d9720 k t_show+0x0[DISABLED] > > oops... > > Issue 2) > With the debuginfo, issue 1 can be solved by using > _stext-based probe definition instead of local symbol-based. > However, without debuginfo, perf-probe can only use > symbol-map in the binary (or kallsyms). The map provides > symbol find methods, but it returns only the first matched > symbol. To put probes on all functions which have given > symbol, we need a symbol-list iterator for the map. > > E.g. (built perf with NO_DWARF=1) > In the case to probe t_show and identity__map_ip in perf. > > # ./perf probe -a t_show > Added new event: > probe:t_show (on t_show) > > You can now use it in all perf tools, such as: > > perf record -e probe:t_show -aR sleep 1 > > # ./perf probe -x perf -a identity__map_ip > no symbols found in /kbuild/ksrc/linux-3/tools/perf/perf, maybe install a > debug package? > Failed to load map. > Error: Failed to add events. (-22) > > oops. > > > Solutions) > To solve the issue 1, this series changes perf probe to > use _stext-based probe definition. This means that we > also need to fix the --list options to analyze actual > probe address from _stext address. (and that has been > done in this series). > > E.g. with this series; > > # ./perf probe -a "t_show \$vars" > Added new events: > probe:t_show (on t_show with $vars) > probe:t_show_1 (on t_show with $vars) > probe:t_show_2 (on t_show with $vars) > probe:t_show_3 (on t_show with $vars) > > You can now use it in all perf tools, such as: > > perf record -e probe:t_show_3 -aR sleep 1 > > # cat /sys/kernel/debug/tracing/kprobe_events > p:probe/t_show _stext+889880 m=%di:u64 v=%si:u64 > p:probe/t_show_1 _stext+928568 m=%di:u64 v=%si:u64 t=%si:u64 > p:probe/t_show_2 _stext+969512 m=%di:u64 v=%si:u64 fmt=%si:u64 > p:probe/t_show_3 _stext+1001416 m=%di:u64 v=%si:u64 file=%si:u64 > > # cat /sys/kernel/debug/kprobes/list > b50d95e0 k t_show+0x0[DISABLED] > b50e2d00 k t_show+0x0[DISABLED] > b50f4990 k t_show+0x0[DISABLED] > b50eccf0 k t_show+0x0[DISABLED] > > This time we can see the events are set in different > addresses. > > And for the issue 2, the last
Re: [PATCH 00/08] PCI: rcar: Recent driver patches from Ben Dooks and me
On Thu, Feb 13, 2014 at 9:34 PM, Ben Dooks wrote: > On 13/02/14 03:03, Magnus Damm wrote: >> >> PCI: rcar: Recent driver patches from Ben Dooks and me >> >> [PATCH 01/08] PCI: rcar: check platform_get_irq() return code >> [PATCH v2 02/08] PCI: rcar: add error interrupt handling >> [PATCH 03/08] PCI: rcar: fix bridge logic configuration accesses >> [PATCH v2 04/08] PCI: rcar: Register each instance independently >> [PATCH v2 05/08] PCI: rcar: Break out window size handling >> [PATCH v2 06/08] PCI: rcar: Add DMABOUNCE support >> [PATCH 07/08] PCI: rcar: Enable BOUNCE in case of HIGHMEM >> [PATCH 08/08] PCI: rcar: Make the Kconfig dependencies more generic >> >> These patches update the pci-rcar-gen2.c driver with patches from >> Ben Dooks and me. The first 3 are written by Ben (thanks!) and are >> included here to show what I would like to have merged and what I >> rebased my patches on. The following 4 are updated versions of >> >> [PATCH 00/04] PCI: rcar: Driver model and physical address space update >> >> The final patch is a new one that fixes up the Kconfig dependencies. > > > Thanks. Is there any chance of getting this driver device-tree > enabled too? I think so! The DT bindings proposed by you looked good for this device. The only question is how to handle the PHY hardware in a sane way. The PHY is the central problematic point so to say, since it ties these PCI USB2.0 devices together with USBHS and for some SoCs USB 3.0 as well. I'm thinking of something along these lines: 1) To use DT to describe the full hardware topology 2) Enable all or some device drivers in the kernel configuration 3) Have a sane default but use the bind interface to reassign driver-to-port configuration. What is your intended use case? Thanks, / 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: [PATCH net,v3] hyperv: Fix the carrier status setting
From: Haiyang Zhang Date: Wed, 12 Feb 2014 16:54:27 -0800 > Without this patch, the "cat /sys/class/net/ethN/operstate" shows > "unknown", and "ethtool ethN" shows "Link detected: yes", when VM > boots up with or without vNIC connected. > > This patch fixed the problem. > > Signed-off-by: Haiyang Zhang > Reviewed-by: K. Y. Srinivasan Applied and queued up for -stable, 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/
linux-next: Tree for Feb 14
Hi all,
If you see failures in building this tree due to missing declarations of
k..alloc/free, then it may be caused by commit 2bd59d48ebfb ("cgroup:
convert to kernfs"). Please send Tejun Heo a patch
adding an inclusion of linux/slab.h to the appropriate file(s).
This tree fails (more than usual) the powerpc allyesconfig build.
Changes since 20140213:
The wireless tree gained a conflict against Linus' tree.
The powerpc tree still had its build failure.
The mfd-lj tree lost its build failure but gained another so I used the
version from next-20140210.
The wireless-next tree lost its build failure.
The devicetree tree gained a conflict against the net-next tree.
The akpm-current tree gained conflicts against the cgroup tree.
The akpm tree gained a conflict against the spi tree.
Non-merge commits (relative to Linus' tree): 2548
2828 files changed, 88633 insertions(+), 46917 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" as mentioned in the FAQ on the wiki
(see below).
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 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final
link) and i386, sparc, sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
I am currently merging 208 trees (counting Linus' and 28 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.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master (4675348e78fa Merge tag 'stable/for-linus-3.14-rc2-tag'
of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip)
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1)
Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8)
Merging arm-current/fixes (b027df048500 ARM: 7957/1: add DSB after icache flush
in __flush_icache_all())
Merging m68k-current/for-linus (7247f55381d5 m68k: Wire up sched_setattr and
sched_getattr)
Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2)
Merging powerpc-merge/merge (cd15b048445d powerpc/powernv: Add iommu DMA bypass
support for IODA2)
Merging sparc/master (738b52bb9845 Merge tag 'microblaze-3.14-rc3' of
git://git.monstr.eu/linux-2.6-microblaze)
Merging net/master (219e288e8900 net: sched: Cleanup PIE comments)
Merging ipsec/master (738b52bb9845 Merge tag 'microblaze-3.14-rc3' of
git://git.monstr.eu/linux-2.6-microblaze)
Merging sound-current/for-linus (2078600b1f8f ALSA: Revert "ALSA: hda/realtek -
Avoid invalid COEFs for ALC271X")
Merging pci-current/for-linus (3ce4e860e578 PCI/MSI: Add pci_enable_msi_exact()
and pci_enable_msix_exact())
Merging wireless/master (6b6ee88774ae bcma: gpio: register all 32 GPIOs)
CONFLICT (content): Merge conflict in drivers/bcma/driver_gpio.c
Merging driver-core.current/driver-core-linus (9e1ccb4a7700 drivers/base: fix
devres handling for master device)
Merging tty.current/tty-linus (0930b0950a89 vt: Fix secure clear screen)
Merging usb.current/usb-linus (3635c7e2d59f usb: option: blacklist ZTE MF667
net interface)
Merging staging.current/staging-linus (ddf5eb564d97 staging/rtl8821ae: fix
build, depends on MAC80211)
Merging char-misc.current/char-misc-linus (3b1cc9b9622a misc: mic: fix possible
signed underflow (undefined behavior) in userspace API)
Merging input-current/for-linus (55df811f2066 Merge branch 'next' into
for-linus)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "di
[PATCH] mmc: omap_hsmmc: fix sparse/smatch warning for paranthesis
commit 6c31b21 (mmc: omap_hsmmc: remove access to SYSCONFIG register) introduced an smatch(http://smatch.sf.net) warning for the following: drivers/mmc/host/omap_hsmmc.c:608 omap_hsmmc_context_restore() warn: add some parenthesis here? drivers/mmc/host/omap_hsmmc.c:608 omap_hsmmc_context_restore() warn: maybe use && instead of & sparse reports: drivers/mmc/host/omap_hsmmc.c: warning: dubious: !x & y Fix the same. Signed-off-by: Nishanth Menon --- drivers/mmc/host/omap_hsmmc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index dbd32ad..575f9cc 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -605,7 +605,7 @@ static int omap_hsmmc_context_restore(struct omap_hsmmc_host *host) u32 hctl, capa; unsigned long timeout; - if (!OMAP_HSMMC_READ(host->base, SYSSTATUS) & RESETDONE) + if (!(OMAP_HSMMC_READ(host->base, SYSSTATUS) & RESETDONE)) return 1; if (host->con == OMAP_HSMMC_READ(host->base, CON) && -- 1.7.9.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: [BUG] perf report/annotate: consuming too many file descriptors
Hi Stephane, On Thu, 13 Feb 2014 17:26:30 +0100, Stephane Eranian wrote: > Hi, > > Your patch does solve the file consumption problem on my test case. > We still open and do the ELF read 5 times. Cool. Could you also confirm what's the problem case - whether it's stripped or static linked? > > Now, if on top of your patch, we also add the following, we save one > open(). I think you need one more patch below on top of yours since the filename__read_debuglink() always return -1. Thanks, Namhyung diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c index 3e9f336740fa..8ac4a4fe2abd 100644 --- a/tools/perf/util/symbol-elf.c +++ b/tools/perf/util/symbol-elf.c @@ -506,6 +506,8 @@ int filename__read_debuglink(const char *filename, char *debuglink, /* the start of this section is a zero-terminated string */ strncpy(debuglink, data->d_buf, size); + err = 0; + out_elf_end: elf_end(elf); out_close: -- 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] Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE
Users have reported being unable to trace non-signed modules loaded
within a kernel supporting module signature.
This is caused by tracepoint.c:tracepoint_module_coming() refusing to
take into account tracepoints sitting within force-loaded modules
(TAINT_FORCED_MODULE). The reason for this check, in the first place, is
that a force-loaded module may have a struct module incompatible with
the layout expected by the kernel, and can thus cause a kernel crash
upon forced load of that module on a kernel with CONFIG_TRACEPOINTS=y.
Tracepoints, however, specifically accept TAINT_OOT_MODULE and
TAINT_CRAP, since those modules do not lead to the "very likely system
crash" issue cited above for force-loaded modules.
With kernels having CONFIG_MODULE_SIG=y (signed modules), a non-signed
module is tainted re-using the TAINT_FORCED_MODULE taint flag.
Unfortunately, this means that Tracepoints treat that module as a
force-loaded module, and thus silently refuse to consider any tracepoint
within this module.
Since an unsigned module does not fit within the "very likely system
crash" category of tainting, add a new TAINT_UNSIGNED_MODULE taint flag
to specifically address this taint behavior, and accept those modules
within Tracepoints. We use the letter 'X' as a taint flag character for
a module being loaded that doesn't know how to sign its name (proposed
by Steven Rostedt).
Also add the missing 'O' entry to trace event show_module_flags() list
for the sake of completeness.
Signed-off-by: Mathieu Desnoyers
CC: Steven Rostedt
CC: Ingo Molnar
CC: Thomas Gleixner
CC: Rusty Russell
CC: David Howells
CC: Greg Kroah-Hartman
---
Documentation/ABI/testing/sysfs-module |1 +
Documentation/module-signing.txt |3 ++-
Documentation/oops-tracing.txt |3 +++
Documentation/sysctl/kernel.txt|2 ++
include/linux/kernel.h |1 +
include/trace/events/module.h |4 +++-
kernel/module.c|4 +++-
kernel/panic.c |2 ++
kernel/tracepoint.c|5 +++--
9 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-module
b/Documentation/ABI/testing/sysfs-module
index 47064c2..b9a29cd 100644
--- a/Documentation/ABI/testing/sysfs-module
+++ b/Documentation/ABI/testing/sysfs-module
@@ -49,3 +49,4 @@ Description: Module taint flags:
O - out-of-tree module
F - force-loaded module
C - staging driver module
+ X - unsigned module
diff --git a/Documentation/module-signing.txt b/Documentation/module-signing.txt
index 2b40e04..b6af42e 100644
--- a/Documentation/module-signing.txt
+++ b/Documentation/module-signing.txt
@@ -53,7 +53,8 @@ This has a number of options available:
If this is off (ie. "permissive"), then modules for which the key is not
available and modules that are unsigned are permitted, but the kernel will
- be marked as being tainted.
+ be marked as being tainted, and the concerned modules will be marked as
+ tainted, shown with the character 'X'.
If this is on (ie. "restrictive"), only modules that have a valid
signature that can be verified by a public key in the kernel's possession
diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt
index 13032c0..879abe2 100644
--- a/Documentation/oops-tracing.txt
+++ b/Documentation/oops-tracing.txt
@@ -265,6 +265,9 @@ characters, each representing a particular tainted value.
13: 'O' if an externally-built ("out-of-tree") module has been loaded.
+ 14: 'X' if an unsigned module has been loaded in a kernel supporting
+ module signature.
+
The primary reason for the 'Tainted: ' string is to tell kernel
debuggers if this is a clean kernel or if anything unusual has
occurred. Tainting is permanent: even if an offending module is
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index e55124e..8ebe1c0 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -792,6 +792,8 @@ can be ORed together:
1024 - A module from drivers/staging was loaded.
2048 - The system is working around a severe firmware bug.
4096 - An out-of-tree module has been loaded.
+8192 - An unsigned module has been loaded in a kernel supporting module
+ signature.
==
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 196d1ea..4710900 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -469,6 +469,7 @@ extern enum system_states {
#define TAINT_CRAP 10
#define TAINT_FIRMWARE_WORKAROUND 11
#define TAINT_OOT_MODULE 12
+#define TAINT_UNSIGNED_MODULE 13
extern const char hex_asc[];
#define hex_asc_lo(x) hex_asc[((x) & 0x0f)]
diff --git a/include/trace/events/module.h
Re: [PATCH v2 4/6] ARM: firmware: add prepare_idle() operation
On 02/13/2014 08:01 PM, Tomasz Figa wrote: Hi Alexandre, On 07.02.2014 05:35, Alexandre Courbot wrote: Some firmwares do not put the CPU into idle mode themselves, but still need to be informed that the CPU is about to enter idle mode before this happens. Add a prepare_idle() operation to the firmware_ops structure to handle such cases. Signed-off-by: Alexandre Courbot --- arch/arm/include/asm/firmware.h | 4 1 file changed, 4 insertions(+) I wonder if .do_idle() couldn't simply return an appropriate error code to let the upper layer know that it should proceed with normal CPU idle activation, while still letting the firmware know that the CPU is going to idle. In our particular case I agree it would be enough to use do_idle() to let the firmware know about the operation and have it return -ENOSYS so the kernel actually performs it. I'm afraid this might not fulfill all needs though (e.g. one can imagine a firmware where the OS needs to take action between the notification and the actual shutdown), and as Stephen pointed out that would make the name of the function ambiguous at best. I'd rather keep it the current way for clarity. -- 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 net 1/3] kref: add kref_sub_return
From: Greg KH Date: Thu, 13 Feb 2014 16:03:20 -0800 > So how about just "open coding" a kref for this structure, as it wants > something that doesn't fit into the kref model, and should be pretty > simple to do (you can ensure you get the locking right, unlike almost > all users of krefs, as Al Viro constantly points out to me...) They redid their patches meanwhile to use their own atomic_t. -- 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][PATCH 0/5] arch: atomic rework
On Wed, 2014-02-12 at 10:19 +0100, Peter Zijlstra wrote: > > I don't know the specifics of your example, but from how I understand > > it, I don't see a problem if the compiler can prove that the store will > > always happen. > > > > To be more specific, if the compiler can prove that the store will > > happen anyway, and the region of code can be assumed to always run > > atomically (e.g., there's no loop or such in there), then it is known > > that we have one atomic region of code that will always perform the > > store, so we might as well do the stuff in the region in some order. > > > > Now, if any of the memory accesses are atomic, then the whole region of > > code containing those accesses is often not atomic because other threads > > might observe intermediate results in a data-race-free way. > > > > (I know that this isn't a very precise formulation, but I hope it brings > > my line of reasoning across.) > > So given something like: > > if (x) > y = 3; > > assuming both x and y are atomic (so don't gimme crap for now knowing > the C11 atomic incantations); and you can prove x is always true; you > don't see a problem with not emitting the conditional? That depends on what your goal is. It would be correct as far as the standard is specified; this makes sense if all you want is indeed a program that does what the abstract machine might do, and produces the same output / side effects. If you're trying to preserve the branch in the code emitted / executed by the implementation, then it would not be correct. But those branches aren't specified as being part of the observable side effects. In the common case, this makes sense because it enables optimizations that are useful; this line of reasoning also allows the compiler to merge some atomic accesses in the way that Linus would like to see it. > Avoiding the conditional changes the result; see that control dependency > email from earlier. It does not regarding how the standard defines "result". > In the above example the load of X and the store to > Y are strictly ordered, due to control dependencies. Not emitting the > condition and maybe not even emitting the load completely wrecks this. I think you're trying to solve this backwards. You are looking at this with an implicit wishlist of what the compiler should do (or how you want to use the hardware), but this is not a viable specification that one can write a compiler against. We do need clear rules for what the compiler is allowed to do or not (e.g., a memory model that models multi-threaded executions). Otherwise it's all hand-waving, and we're getting nowhere. Thus, the way to approach this is to propose a feature or change to the standard, make sure that this is consistent and has no unintended side effects for other aspects of compilation or other code, and then ask the compiler to implement it. IOW, we need a patch for where this all starts: in the rules and requirements for compilation. Paul and I are at the C++ meeting currently, and we had sessions in which the concurrency study group talked about memory model issues like dependency tracking and memory_order_consume. Paul shared uses of atomics (or likewise) in the kernel, and we discussed how the memory model currently handles various cases and why, how one could express other requirements consistently, and what is actually implementable in practice. I can't speak for Paul, but I thought those discussions were productive. > Its therefore an invalid optimization to take out the conditional or > speculate the store, since it takes out the dependency. -- 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 akpm tree with the spi tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
drivers/spi/spi.c between commit 513273538a6c ("spi: Make max_tx and
max_rx the same type") from the spi tree and commit "drivers/spi/spi.c:
fix max() warning" from the akpm tree.
I fixed it up (I used the version from the akpm tree giving the patch
below) and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index a7c3691456dd..99bc9c513b70 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -644,12 +644,11 @@ static int spi_map_msg(struct spi_master *master, struct
spi_message *msg)
struct device *tx_dev, *rx_dev;
struct spi_transfer *xfer;
void *tmp;
- unsigned int max_tx, max_rx;
int ret;
if (master->flags & (SPI_MASTER_MUST_RX | SPI_MASTER_MUST_TX)) {
- max_tx = 0;
- max_rx = 0;
+ unsigned max_tx = 0;
+ unsigned max_rx = 0;
list_for_each_entry(xfer, >transfers, transfer_list) {
if ((master->flags & SPI_MASTER_MUST_TX) &&
pgpJsrfXwlQQK.pgp
Description: PGP signature
[RFC PATCH] sched: make sure sched-priority after invoke idle_balance()
Since idle_balance() will release rq-lock for a while, there is a chance that
RT/DL tasks will be enqueued and ask for the resched, the func used to be
invoked ahead of pick_next_task(), which will make sure we drop into the
bottom-half inside pick_next_task().
Now since idle_balance() was done inside pick_next_task_fair(), pick_next_task()
can no longer make sure the priority, the worst case is that we will going to
pick the pulled fair task while there is RT/DL on rq which actually should be
picked up.
This patch will prevent this happen by some rechecking after idle_balance(), it
utilize the resched-flag for the case when RT/DL task was enqueued but don't ask
for resched (will that ever happened?).
CC: Ingo Molnar
Suggested-by: Peter Zijlstra
Signed-off-by: Michael Wang
---
kernel/sched/fair.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 235cfa7..ce67514 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4776,6 +4776,16 @@ simple:
idle:
#ifdef CONFIG_SMP
+ /*
+* We came here only when there is no more tasks on rq (top-half of
+* pick_next_task()), and we are now going to pull some fair entities.
+*
+* Since prev is still the current on rq, clear it's resched-flag so
+* we would be able to know when we got a new resched-request during
+* idle_balance(), check below for more details.
+*/
+ clear_tsk_need_resched(prev);
+
idle_enter_fair(rq);
/*
* We must set idle_stamp _before_ calling idle_balance(), such that we
@@ -4784,7 +4794,18 @@ idle:
rq->idle_stamp = rq_clock(rq);
if (idle_balance(rq)) { /* drops rq->lock */
rq->idle_stamp = 0;
- goto again;
+ /*
+* Before we start to pick one of the pulled fair entities, take
+* care if some RT/DL tasks has been enqueued during the time
+* we release rq-lock inside idle_balance().
+*
+* In such cases, since clear_tsk_need_resched() was done
+* already, need_resched() will imply the request to sched-in
+* the enqueued RT/DL tasks, so don't 'goto again' to make sure
+* the priority.
+*/
+ if (rq->nr_running == rq->cfs.h_nr_running || !need_resched())
+ goto again;
}
#endif
--
1.7.9.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 v3 2/6] fat: add fat_fallocate operation
>> [...]
>>
>>> + /* Release unwritten fallocated blocks on inode eviction. */
>>> + if (MSDOS_I(inode)->mmu_private < MSDOS_I(inode)->i_disksize) {
>>> + int err;
>>> + fat_truncate_blocks(inode, MSDOS_I(inode)->mmu_private);
>>> + /* Fallocate results in updating the i_start/iogstart
>>> +* for the zero byte file. So, make it return to
>>> +* original state during evict and commit it
>>> +* synchrnously to avoid any corruption on the next
>>> +* access to the cluster chain for the file.
>>> +*/
>>> + err = fat_sync_inode(inode);
>>
>> Ah, good catch. We have to update i_size. I was forgetting about this.
>> Well, sync inode unconditionally would not be good. Maybe, we better to
>> use __fat_write_inode() with inode_needs_sync() or such.
> Okay, I will change it.
Hi OGAWA
When I checked more, we should wait till inode is sync. Because in the
eviction it will leave the inode/buffers being marked dirty.
Not waiting for it get sync over here. It will leave cluster chain
corrupted when remounting.
It mean we cannot use __fat_write_inode with inode_needs_sync() conditionally.
Thanks.
>
> Thanks.
>> --
>> OGAWA Hirofumi
>>
>
--
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 -tip RESEND 2/2] ftrace: Introduce nr_saved_cmdlines I/F
Hi Yoshihiro,
On Thu, 13 Feb 2014 10:28:58 +0900, Yoshihiro YUNOMAE wrote:
> Introduce nr_saved_cmdlines I/F for changing the number of pid-comm list.
> saved_cmdlines can store 128 command names using SAVED_CMDLINES now, but
> 'no-existing processes' names are often lost in saved_cmdlines when we
> read trace data. So, by introducing nr_saved_cmdlines I/F, the rule storing
> 128 command names is changed to the command numbers defined users.
>
> When we write a value to nr_saved_cmdlines, the number of the value will
> be stored in pid-comm list:
>
> # echo 1024 > /sys/kernel/debug/tracing/nr_saved_cmdlines
>
> Here, 1024 command names are stored. The default number is 128 and the maximum
> number is PID_MAX_DEFAULT (=32768 if CONFIG_BASE_SMALL is not set). So, if we
> want to avoid to lose command names, we need to set 32768 to
> nr_saved_cmdlines.
>
> We can read the maximum number of the list:
>
> # cat /sys/kernel/debug/tracing/nr_saved_cmdlines
> 128
[SNIP]
> @@ -3685,7 +3760,8 @@ static void *saved_cmdlines_next(struct seq_file *m,
> void *v, loff_t *pos)
>
> (*pos)++;
>
> - for (; ptr < _cmdline_to_pid[SAVED_CMDLINES]; ptr++) {
> + for (; ptr < >map_cmdline_to_pid[savedcmd->cmdline_num];
> + ptr++) {
> if (*ptr == -1 || *ptr == NO_CMDLINE_MAP)
> continue;
>
> @@ -3700,7 +3776,7 @@ static void *saved_cmdlines_start(struct seq_file *m,
> loff_t *pos)
> void *v;
> loff_t l = 0;
>
> - v = _cmdline_to_pid[0];
> + v = >map_cmdline_to_pid[0];
> while (l <= *pos) {
> v = saved_cmdlines_next(m, v, );
> if (!v)
Are you accessing the savecmd without trace_cmdline_lock?
Thanks,
Namhyung
--
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] printk: Fix discarding of records
Found another buffer overflow in this code that was introduced by e3756477aec028427fec767957c0d4b6cfb87208 trying to solve a related overflow. strace still shows a problem: syslog(0x3, 0x7fffd65375d0, 0x1000) = 4107 The first record output was in the middle of a LOG_CONT line: <4>[2.974999] 0x0500-0x052f SystemIO conflicts with Region \GPIO 1 (20130328/utaddress-251) This happens because when discarding records to be less than len, every line it subtracts should be the first line which means prev should be 0. Otherwise for example it won't include the prefix len if the last line was a LOG_CONT record, which however will be printed because there won't be a previous line. This patch makes sure enough records are discarded to be under len. CC: sta...@vger.kernel.org Signed-off-by: Debabrata Banerjee --- kernel/printk/printk.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index b1d255f..c1722d5 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -1067,7 +1067,6 @@ static int syslog_print_all(char __user *buf, int size, bool clear) struct printk_log *msg = log_from_idx(idx); len -= msg_print_text(msg, prev, true, NULL, 0); - prev = msg->flags; idx = log_next(idx); seq++; } @@ -2780,7 +2779,6 @@ bool kmsg_dump_get_buffer(struct kmsg_dumper *dumper, bool syslog, l -= msg_print_text(msg, prev, true, NULL, 0); idx = log_next(idx); seq++; - prev = msg->flags; } /* last message in next interation */ -- 1.8.3.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: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters
On Thu, Feb 13, 2014 at 12:20 PM, Daniel Borkmann wrote: > On 02/07/2014 02:20 AM, Alexei Starovoitov wrote: > ... >> >> Hi Daniel, > > > Thanks for your answer and sorry for the late reply. > > >> Thank you for taking a look. Good questions. I had the same concerns. >> Old BPF was carefully extended in specific places. >> End result may look big at first glance, but every extension has specific >> reason behind it. I tried to explain the reasoning in >> Documentation/bpf_jit.txt >> >> I'm planning to write an on-the-fly converter from old BPF to BPF64 >> when BPF64 manages to demonstrate that it is equally safe. >> It is straight forward to convert. Encoding is very similar. >> Core concepts are the same. >> Try diff include/uapi/linux/filter.h include/linux/bpf.h >> to see how much is reused. >> >> I believe that old BPF outlived itself and BPF64 should >> replace it in all current use cases plus a lot more. >> It just cannot happen at once. >> BPF64 can come in. bpf32->bpf64 converter functioning. >> JIT from bpf64->aarch64 and may be sparc64 needs to be in place. >> Then old bpf can fade away. > > > Do you see a possibility to integrate your work step by step? That is, Sure. let's see how we can do it. > to first integrate the interpreter part only; meaning, to detect "old" > BPF programs e.g. coming from SO_ATTACH_FILTER et al and run them in > compatibility mode while extended BPF is fully integrated and replaces > the old engine in net/core/filter.c. Maybe, "old" programs can be do you mean drop bfp64_jit, checker and just have bpf32->bpf64 converter and bpf64 interpreter as phase 1 ? Checking is done by old bpf32, all existing bpf32 jits, if available, can convert bpf32 to native, but interpreter will be running on bpf64 ? phase 2 to introduce bpf64_x86 jit and so on? Sounds fine. Today I didn't try to optimize bpf64 interpreter, since insn set is designed for eventual JITing and interpreter is there to support archs that don't have jit yet. I guess I have to tweak it to perform at bpf32 interpreter speeds. > transformed transparently to the new representation and then would be > good to execute in eBPF. If possible, in such a way that in the first > step JIT compilers won't need any upgrades. Once that is resolved, > JIT compilers could successively migrate, arch by arch, to compile the > new code? And last but not least the existing tools as well for handling > eBPF. I think, if possible, that would be great. Also, I unfortunately > haven't looked into your code too deeply yet due to time constraints, > but I'm wondering e.g. for accessing some skb fields we currently use > the "hack" to "overload" load instructions with negative arguments. Do > we have a sort of "meta" instruction that is extendible in eBPF to avoid > such things in future? Exactly. This 'negative offset' hack of bpf32 isn't very clean, since jits for all archs need to change when new offsets added. For bpf64 I'm proposing a customizable 'bpf_context' and variable set of bpf-callable functions, so JITs don't need to change and verifier stays the same. That's the idea behind 'bpf_callbacks' in include/linux/bpf_jit.h Some meta data makes sense to pass as input into bpf program. Like for seccomp 'bpf_context' can be 'struct seccomp_data' For networking, bpf_context can be 'skb', then bpf_s_anc_protocol becomes a normal 2-byte bpf64 load from skb->protocol field. Allowing access to other fields of skb is just a matter of defining permissions of 'struct bpf_context' in bpf_callback->get_context_access() Some other meta data and extensions are cleaner when defined as function calls from bpf, since calls are free. I think bpf_table_lookup() is a fundamental one that allows to define arbitrary tables within bpf and access them from the program. (here I need feedback the most whether to access tables via netlink from userspace or via debugfs...) It probably will be easier to read the code of bpf32-bpf64 converter to understand the differences between the two. I guess I have to start working on the converter sooner than I thought... Thanks Alexei -- 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][PATCH 0/5] arch: atomic rework
On Thu, 2014-02-13 at 18:01 -0800, Paul E. McKenney wrote: > On Thu, Feb 13, 2014 at 12:03:57PM -0800, Torvald Riegel wrote: > > On Wed, 2014-02-12 at 16:23 -0800, Paul E. McKenney wrote: > > > On Wed, Feb 12, 2014 at 12:22:53PM -0800, Linus Torvalds wrote: > > > > On Wed, Feb 12, 2014 at 10:07 AM, Paul E. McKenney > > > > wrote: > > > > > > > > > > Us Linux-kernel hackers will often need to use volatile semantics in > > > > > combination with C11 atomics in most cases. The C11 atomics do cover > > > > > some of the reasons we currently use ACCESS_ONCE(), but not all of > > > > > them -- > > > > > in particular, it allows load/store merging. > > > > > > > > I really disagree with the "will need to use volatile". > > > > > > > > We should never need to use volatile (outside of whatever MMIO we do > > > > using C) if C11 defines atomics correctly. > > > > > > > > Allowing load/store merging is *fine*. All sane CPU's do that anyway - > > > > it's called a cache - and there's no actual reason to think that > > > > "ACCESS_ONCE()" has to mean our current "volatile". > > > > > > > > Now, it's possible that the C standards simply get atomics _wrong_, so > > > > that they create visible semantics that are different from what a CPU > > > > cache already does, but that's a plain bug in the standard if so. > > > > > > > > But merging loads and stores is fine. And I *guarantee* it is fine, > > > > exactly because CPU's already do it, so claiming that the compiler > > > > couldn't do it is just insanity. > > > > > > Agreed, both CPUs and compilers can merge loads and stores. But CPUs > > > normally get their stores pushed through the store buffer in reasonable > > > time, and CPUs also use things like invalidations to ensure that a > > > store is seen in reasonable time by readers. Compilers don't always > > > have these two properties, so we do need to be more careful of load > > > and store merging by compilers. > > > > The standard's _wording_ is a little vague about forward-progress > > guarantees, but I believe the vast majority of the people involved do > > want compilers to not prevent forward progress. There is of course a > > difference whether a compiler establishes _eventual_ forward progress in > > the sense of after 10 years or forward progress in a small bounded > > interval of time, but this is a QoI issue, and good compilers won't want > > to introduce unnecessary latencies. I believe that it is fine if the > > standard merely talks about eventual forward progress. > > The compiler will need to earn my trust on this one. ;-) > > > > > Now, there are things that are *not* fine, like speculative stores > > > > that could be visible to other threads. Those are *bugs* (either in > > > > the compiler or in the standard), and anybody who claims otherwise is > > > > not worth discussing with. > > > > > > And as near as I can tell, volatile semantics are required in C11 to > > > avoid speculative stores. I might be wrong about this, and hope that > > > I am wrong. But I am currently not seeing it in the current standard. > > > (Though I expect that most compilers would avoid speculating stores, > > > especially in the near term. > > > > This really depends on how we define speculative stores. The memory > > model is absolutely clear that programs have to behave as if executed by > > the virtual machine, and that rules out speculative stores to volatiles > > and other locations. Under certain circumstances, there will be > > "speculative" stores in the sense that they will happen at different > > times as if you had a trivial implementation of the abstract machine. > > But to be allowed to do that, the compiler has to prove that such a > > transformation still fulfills the as-if rule. > > Agreed, although the as-if rule would ignore control dependencies, since > these are not yet part of the standard (as you in fact note below). > I nevertheless consider myself at least somewhat reassured that current > C11 won't speculate stores. My remaining concerns involve the compiler > proving to itself that a given branch is always taken, thus motivating > it to optimize the branch away -- though this is more properly a > control-dependency concern. > > > IOW, the abstract machine is what currently defines disallowed > > speculative stores. If you want to put *further* constraints on what > > implementations are allowed to do, I suppose it is best to talk about > > those and see how we can add rules that allow programmers to express > > those constraints. For example, control dependencies might be such a > > case. I don't have a specific suggestion -- maybe the control > > dependencies are best tackled similar to consume dependencies (even > > though we don't have a good solution for those yets). But using > > volatile accesses for that seems to be a big hammer, or even the wrong > > one. > > In current compilers, the two hammers we have are volatile and barrier(). > But yes, it would be
linux-next: manual merge of the akpm-current tree with the cgroup tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
mm/memcontrol.c between commit e61734c55c24 ("cgroup: remove
cgroup->name") from the cgroup tree and commit 05d3a02a1a0d ("memcg:
change oom_info_lock to mutex") from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc mm/memcontrol.c
index d9c6ac1532e6,de1a2aed4954..
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -1683,25 -1683,54 +1683,25 @@@ static void move_unlock_mem_cgroup(stru
*/
void mem_cgroup_print_oom_info(struct mem_cgroup *memcg, struct task_struct
*p)
{
- /*
- * protects memcg_name and makes sure that parallel ooms do not
- * interleave
- */
+ /* oom_info_lock ensures that parallel ooms do not interleave */
- static DEFINE_SPINLOCK(oom_info_lock);
+ static DEFINE_MUTEX(oom_info_lock);
- struct cgroup *task_cgrp;
- struct cgroup *mem_cgrp;
- static char memcg_name[PATH_MAX];
- int ret;
struct mem_cgroup *iter;
unsigned int i;
if (!p)
return;
- spin_lock(_info_lock);
+ mutex_lock(_info_lock);
rcu_read_lock();
- mem_cgrp = memcg->css.cgroup;
- task_cgrp = task_cgroup(p, mem_cgroup_subsys_id);
-
- ret = cgroup_path(task_cgrp, memcg_name, PATH_MAX);
- if (ret < 0) {
- /*
- * Unfortunately, we are unable to convert to a useful name
- * But we'll still print out the usage information
- */
- rcu_read_unlock();
- goto done;
- }
- rcu_read_unlock();
-
- pr_info("Task in %s killed", memcg_name);
+ pr_info("Task in ");
+ pr_cont_cgroup_path(task_cgroup(p, memory_cgrp_id));
+ pr_info(" killed as a result of limit of ");
+ pr_cont_cgroup_path(memcg->css.cgroup);
+ pr_info("\n");
- rcu_read_lock();
- ret = cgroup_path(mem_cgrp, memcg_name, PATH_MAX);
- if (ret < 0) {
- rcu_read_unlock();
- goto done;
- }
rcu_read_unlock();
- /*
- * Continues from above, so we don't need an KERN_ level
- */
- pr_cont(" as a result of limit of %s\n", memcg_name);
-done:
-
pr_info("memory: usage %llukB, limit %llukB, failcnt %llu\n",
res_counter_read_u64(>res, RES_USAGE) >> 10,
res_counter_read_u64(>res, RES_LIMIT) >> 10,
pgp1pOE08oTtJ.pgp
Description: PGP signature
[tip:x86/asmlinkage] lto: Handle LTO common symbols in module loader
Commit-ID: 80375980f1608f43b47abc2671456b23ec68c434
Gitweb: http://git.kernel.org/tip/80375980f1608f43b47abc2671456b23ec68c434
Author: Joe Mario
AuthorDate: Sat, 8 Feb 2014 09:01:09 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:24:50 -0800
lto: Handle LTO common symbols in module loader
Here is the workaround I made for having the kernel not reject modules
built with -flto. The clean solution would be to get the compiler to not
emit the symbol. Or if it has to emit the symbol, then emit it as
initialized data but put it into a comdat/linkonce section.
Minor tweaks by AK over Joe's patch.
Cc: Rusty Russell
Signed-off-by: Andi Kleen
Link:
http://lkml.kernel.org/r/1391846481-31491-5-git-send-email...@linux.intel.com
Signed-off-by: H. Peter Anvin
---
kernel/module.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/module.c b/kernel/module.c
index d24fcf2..b99e801 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1948,6 +1948,10 @@ static int simplify_symbols(struct module *mod, const
struct load_info *info)
switch (sym[i].st_shndx) {
case SHN_COMMON:
+ /* Ignore common symbols */
+ if (!strncmp(name, "__gnu_lto", 9))
+ break;
+
/* We compiled with -fno-common. These are not
supposed to happen. */
pr_debug("Common symbol: %s\n", name);
--
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 PATCH V5] mm readahead: Fix readahead fail for no local memory and limit readahead pages
Hi Linus,
On 13.02.2014 [16:37:53 -0800], Linus Torvalds wrote:
> Is this whole thread still just for the crazy and pointless
> "max_sane_readahead()"?
>
> Or is there some *real* reason we should care?
There is an open issue on powerpc with memoryless nodes (inasmuch as we
can have them, but the kernel doesn't support it properly). There is a
separate discussion going on on linuxppc-dev about what is necessary for
CONFIG_HAVE_MEMORYLESS_NODES to be supported.
> Because if it really is just for max_sane_readahead(), then for the
> love of God, let us just do this
>
> unsigned long max_sane_readahead(unsigned long nr)
> {
> return min(nr, 128);
> }
>
> and bury this whole idiotic thread.
Agreed that for the readahead case the above is probably more than
sufficient.
Apologies for hijacking the thread, my comments below were purely about
the memoryless node support, not about readahead specifically.
Thanks,
Nish
> Seriously, if your IO subsystem needs more than 512kB of read-ahead to
> get full performance, your IO subsystem is just bad, and has latencies
> that are long enough that you should just replace it. There's no real
> reason to bend over backwards for that, and the whole complexity and
> fragility of the insane "let's try to figure out how much memory this
> node has" is just not worth it. The read-ahead should be small enough
> that we should never need to care, and large enough that you get
> reasonable IO throughput. The above does that.
>
> Goddammit, there's a reason the whole "Gordian knot" parable is
> famous. We're making this all too damn complicated FOR NO GOOD REASON.
>
> Just cut the rope, people. Our aim is not to generate some kind of job
> security by making things as complicated as possible.
>
> Linus
>
> On Thu, Feb 13, 2014 at 4:14 PM, Nishanth Aravamudan
> wrote:
> >
> > I'm working on this latter bit now. I tried to mirror ia64, but it looks
> > like they have CONFIG_USER_PERCPU_NUMA_NODE_ID, which powerpc doesn't.
> > It seems like CONFIG_USER_PERCPU_NUMA_NODE_ID and
> > CONFIG_HAVE_MEMORYLESS_NODES should be tied together in Kconfig?
> >
> > I'll keep working, but would appreciate any further insight.
> >
> > -Nish
> >
>
--
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/
[tip:x86/asmlinkage] Kbuild, lto: Disable LTO for asm-offsets.c
Commit-ID: 1e64ff42ea3d8d2fc8aa71f9717b3c1cb6c2f893 Gitweb: http://git.kernel.org/tip/1e64ff42ea3d8d2fc8aa71f9717b3c1cb6c2f893 Author: Andi Kleen AuthorDate: Sat, 8 Feb 2014 09:01:15 +0100 Committer: H. Peter Anvin CommitDate: Thu, 13 Feb 2014 20:25:03 -0800 Kbuild, lto: Disable LTO for asm-offsets.c The asm-offset.c technique to fish data out of the assembler file does not work with LTO. Just disable for the asm-offset.c build. Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1391846481-31491-11-git-send-email...@linux.intel.com Signed-off-by: H. Peter Anvin --- scripts/Makefile.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index d5d859c..9f0ee22 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -198,7 +198,7 @@ $(multi-objs-y:.o=.s) : modname = $(modname-multi) $(multi-objs-y:.o=.lst) : modname = $(modname-multi) quiet_cmd_cc_s_c = CC $(quiet_modtag) $@ -cmd_cc_s_c = $(CC) $(c_flags) -fverbose-asm -S -o $@ $< +cmd_cc_s_c = $(CC) $(c_flags) $(DISABLE_LTO) -fverbose-asm -S -o $@ $< $(obj)/%.s: $(src)/%.c FORCE $(call if_changed_dep,cc_s_c) -- 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/
[tip:x86/asmlinkage] Kbuild, lto: Handle basic LTO in modpost
Commit-ID: ef178f9238b142cc1020265e176b20d27fd02ba9
Gitweb: http://git.kernel.org/tip/ef178f9238b142cc1020265e176b20d27fd02ba9
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:17 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:25:05 -0800
Kbuild, lto: Handle basic LTO in modpost
- Don't warn about LTO marker symbols. modpost runs before
the linker, so the module is not necessarily LTOed yet.
- Don't complain about .gnu.lto* sections
Signed-off-by: Andi Kleen
Link:
http://lkml.kernel.org/r/1391846481-31491-13-git-send-email...@linux.intel.com
Signed-off-by: H. Peter Anvin
---
scripts/mod/modpost.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index f91dd45..63804a1 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -623,7 +623,10 @@ static void handle_modversions(struct module *mod, struct
elf_info *info,
switch (sym->st_shndx) {
case SHN_COMMON:
- warn("\"%s\" [%s] is COMMON symbol\n", symname, mod->name);
+ if (!strncmp(symname, "__gnu_lto_", sizeof("__gnu_lto_")-1)) {
+ /* Should warn here, but modpost runs before the linker
*/
+ } else
+ warn("\"%s\" [%s] is COMMON symbol\n", symname,
mod->name);
break;
case SHN_UNDEF:
/* undefined symbol */
@@ -849,6 +852,7 @@ static const char *section_white_list[] =
".xt.lit", /* xtensa */
".arcextmap*", /* arc */
".gnu.linkonce.arcext*",/* arc : modules */
+ ".gnu.lto*",
NULL
};
--
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/
[tip:x86/asmlinkage] Kbuild, lto: Add a gcc-ld script to let run gcc as ld
Commit-ID: 8564ed2b3888176ac323eefea1722003daeba3d3 Gitweb: http://git.kernel.org/tip/8564ed2b3888176ac323eefea1722003daeba3d3 Author: Andi Kleen AuthorDate: Sat, 8 Feb 2014 09:01:14 +0100 Committer: H. Peter Anvin CommitDate: Thu, 13 Feb 2014 20:25:02 -0800 Kbuild, lto: Add a gcc-ld script to let run gcc as ld For LTO we need to run the link step with gcc, not ld. Since there are a lot of linker options passed to it, add a gcc-ld wrapper that wraps them as -Wl, Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1391846481-31491-10-git-send-email...@linux.intel.com Signed-off-by: H. Peter Anvin --- scripts/gcc-ld | 29 + 1 file changed, 29 insertions(+) diff --git a/scripts/gcc-ld b/scripts/gcc-ld new file mode 100644 index 000..cadab9a --- /dev/null +++ b/scripts/gcc-ld @@ -0,0 +1,29 @@ +#!/bin/sh +# run gcc with ld options +# used as a wrapper to execute link time optimizations +# yes virginia, this is not pretty + +ARGS="-nostdlib" + +while [ "$1" != "" ] ; do + case "$1" in + -save-temps|-m32|-m64) N="$1" ;; + -r) N="$1" ;; + -[Wg]*) N="$1" ;; + -[olv]|-[Ofd]*|-nostdlib) N="$1" ;; + --end-group|--start-group) +N="-Wl,$1" ;; + -[RTFGhIezcbyYu]*|\ +--script|--defsym|-init|-Map|--oformat|-rpath|\ +-rpath-link|--sort-section|--section-start|-Tbss|-Tdata|-Ttext|\ +--version-script|--dynamic-list|--version-exports-symbol|--wrap|-m) + A="$1" ; shift ; N="-Wl,$A,$1" ;; + -[m]*) N="$1" ;; + -*) N="-Wl,$1" ;; + *) N="$1" ;; + esac + ARGS="$ARGS $N" + shift +done + +exec $CC $ARGS -- 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/
[tip:x86/asmlinkage] Kbuild, lto: add ld-version and ld-ifversion macros
Commit-ID: ccbef1674a1579842c7dbdf554efca85d2cd245a
Gitweb: http://git.kernel.org/tip/ccbef1674a1579842c7dbdf554efca85d2cd245a
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:13 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:25:00 -0800
Kbuild, lto: add ld-version and ld-ifversion macros
To check the linker version. Used by the LTO makefile.
Signed-off-by: Andi Kleen
Link:
http://lkml.kernel.org/r/1391846481-31491-9-git-send-email...@linux.intel.com
Signed-off-by: H. Peter Anvin
---
scripts/Kbuild.include | 9 +
scripts/ld-version.sh | 8
2 files changed, 17 insertions(+)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 547e15d..93a0da2 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -155,6 +155,15 @@ ld-option = $(call try-run,\
# Important: no spaces around options
ar-option = $(call try-run, $(AR) rc$(1) "$$TMP",$(1),$(2))
+# ld-version
+# Usage: $(call ld-version)
+# Note this is mainly for HJ Lu's 3 number binutil versions
+ld-version = $(shell $(LD) --version | $(srctree)/scripts/ld-version.sh)
+
+# ld-ifversion
+# Usage: $(call ld-ifversion, -ge, 22252, y)
+ld-ifversion = $(shell [ $(call ld-version) $(1) $(2) ] && echo $(3))
+
##
###
diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
new file mode 100755
index 000..198580d
--- /dev/null
+++ b/scripts/ld-version.sh
@@ -0,0 +1,8 @@
+#!/usr/bin/awk -f
+# extract linker version number from stdin and turn into single number
+ {
+ gsub(".*)", "");
+ split($1,a, ".");
+ print a[1]*1000 + a[2]*10 + a[3]*1 + a[4]*100 + a[5];
+ exit
+ }
--
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/
[tip:x86/asmlinkage] Kbuild, lto, workaround: Don' t warn for initcall_reference in modpost
Commit-ID: 77ab21adae509c5540956729e2d03bc1a59bc82a
Gitweb: http://git.kernel.org/tip/77ab21adae509c5540956729e2d03bc1a59bc82a
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:11 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:24:56 -0800
Kbuild, lto, workaround: Don't warn for initcall_reference in modpost
This reference is discarded, but can cause warnings when it refers to
exit. Ignore for now.
This is a workaround and can be removed once we get rid of
-fno-toplevel-reorder
Signed-off-by: Andi Kleen
Link:
http://lkml.kernel.org/r/1391846481-31491-7-git-send-email...@linux.intel.com
Signed-off-by: H. Peter Anvin
---
scripts/mod/modpost.c | 4
1 file changed, 4 insertions(+)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 4061098..1f1b154 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1455,6 +1455,10 @@ static void check_section_mismatch(const char *modname,
struct elf_info *elf,
to = find_elf_symbol(elf, r->r_addend, sym);
tosym = sym_name(elf, to);
+ if (!strncmp(fromsym, "reference___initcall",
+ sizeof("reference___initcall")-1))
+ return;
+
/* check whitelist - we may ignore it */
if (secref_whitelist(mismatch,
fromsec, fromsym, tosec, tosym)) {
--
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/
[tip:x86/asmlinkage] lto: Disable LTO for sys_ni
Commit-ID: 58edae3aac9f2ccd1afb12ea08127e840a0a706c Gitweb: http://git.kernel.org/tip/58edae3aac9f2ccd1afb12ea08127e840a0a706c Author: Andi Kleen AuthorDate: Sat, 8 Feb 2014 09:01:10 +0100 Committer: H. Peter Anvin CommitDate: Thu, 13 Feb 2014 20:24:53 -0800 lto: Disable LTO for sys_ni The assembler alias code in cond_syscall does not work when compiled for LTO. Just disable LTO for that file. Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1391846481-31491-6-git-send-email...@linux.intel.com Signed-off-by: H. Peter Anvin --- kernel/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/Makefile b/kernel/Makefile index bc010ee..31c26c6 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -18,6 +18,9 @@ CFLAGS_REMOVE_cgroup-debug.o = -pg CFLAGS_REMOVE_irq_work.o = -pg endif +# cond_syscall is currently not LTO compatible +CFLAGS_sys_ni.o = $(DISABLE_LTO) + obj-y += sched/ obj-y += locking/ obj-y += power/ -- 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/
[tip:x86/asmlinkage] lto, workaround: Add workaround for initcall reordering
Commit-ID: ef1b893c29d0dba778f67ad97b554b37f9108dcc
Gitweb: http://git.kernel.org/tip/ef1b893c29d0dba778f67ad97b554b37f9108dcc
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:08 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:24:13 -0800
lto, workaround: Add workaround for initcall reordering
Work around a LTO gcc problem: when there is no reference to a variable
in a module it will be moved to the end of the program. This causes
reordering of initcalls which the kernel does not like.
Add a dummy reference function to avoid this. The function is
deleted by the linker.
This replaces a previous much slower workaround.
Thanks to Jan "Honza" Hubička for suggesting this technique.
Suggested-by: Jan Hubička
Signed-off-by: Andi Kleen
Link:
http://lkml.kernel.org/r/1391846481-31491-4-git-send-email...@linux.intel.com
Signed-off-by: H. Peter Anvin
---
include/linux/init.h | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/include/linux/init.h b/include/linux/init.h
index e168880..a3ba270 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -163,6 +163,23 @@ extern bool initcall_debug;
#ifndef __ASSEMBLY__
+#ifdef CONFIG_LTO
+/* Work around a LTO gcc problem: when there is no reference to a variable
+ * in a module it will be moved to the end of the program. This causes
+ * reordering of initcalls which the kernel does not like.
+ * Add a dummy reference function to avoid this. The function is
+ * deleted by the linker.
+ */
+#define LTO_REFERENCE_INITCALL(x) \
+ ; /* yes this is needed */ \
+ static __used __exit void *reference_##x(void) \
+ { \
+ return \
+ }
+#else
+#define LTO_REFERENCE_INITCALL(x)
+#endif
+
/* initcalls are now grouped by functionality into separate
* subsections. Ordering inside the subsections is determined
* by link order.
@@ -175,7 +192,8 @@ extern bool initcall_debug;
#define __define_initcall(fn, id) \
static initcall_t __initcall_##fn##id __used \
- __attribute__((__section__(".initcall" #id ".init"))) = fn
+ __attribute__((__section__(".initcall" #id ".init"))) = fn; \
+ LTO_REFERENCE_INITCALL(__initcall_##fn##id)
/*
* Early initcalls run before initializing SMP.
--
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/
[tip:x86/asmlinkage] Kbuild, lto: Drop .number postfixes in modpost
Commit-ID: 7d02b490e93c199a15b3c4bce1c393588c1300ca
Gitweb: http://git.kernel.org/tip/7d02b490e93c199a15b3c4bce1c393588c1300ca
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:12 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:24:58 -0800
Kbuild, lto: Drop .number postfixes in modpost
LTO turns all global symbols effectively into statics. This
has the side effect that they all have a .NUMBER postfix to make
them unique. In modpost drop this postfix because it confuses
it.
Signed-off-by: Andi Kleen
Link:
http://lkml.kernel.org/r/1391846481-31491-8-git-send-email...@linux.intel.com
Signed-off-by: H. Peter Anvin
---
scripts/mod/modpost.c | 15 ++-
scripts/mod/modpost.h | 2 +-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 1f1b154..f91dd45 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1684,6 +1684,19 @@ static void check_sec_ref(struct module *mod, const char
*modname,
}
}
+static char *remove_dot(char *s)
+{
+ char *end;
+ int n = strcspn(s, ".");
+
+ if (n > 0 && s[n] != 0) {
+ strtoul(s + n + 1, , 10);
+ if (end > s + n + 1 && (*end == '.' || *end == 0))
+ s[n] = 0;
+ }
+ return s;
+}
+
static void read_symbols(char *modname)
{
const char *symname;
@@ -1722,7 +1735,7 @@ static void read_symbols(char *modname)
}
for (sym = info.symtab_start; sym < info.symtab_stop; sym++) {
- symname = info.strtab + sym->st_name;
+ symname = remove_dot(info.strtab + sym->st_name);
handle_modversions(mod, , sym, symname);
handle_moddevtable(mod, , sym, symname);
diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h
index 51207e4..168b43d 100644
--- a/scripts/mod/modpost.h
+++ b/scripts/mod/modpost.h
@@ -127,7 +127,7 @@ struct elf_info {
Elf_Section export_gpl_sec;
Elf_Section export_unused_gpl_sec;
Elf_Section export_gpl_future_sec;
- const char *strtab;
+ char *strtab;
char *modinfo;
unsigned int modinfo_len;
--
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/
[tip:x86/asmlinkage] x86, lto: Disable LTO for the x86 VDSO
Commit-ID: 67424d5a22124fa2d115faa8f32d12506989628f Gitweb: http://git.kernel.org/tip/67424d5a22124fa2d115faa8f32d12506989628f Author: Andi Kleen AuthorDate: Sat, 8 Feb 2014 09:01:05 +0100 Committer: H. Peter Anvin CommitDate: Thu, 13 Feb 2014 20:21:57 -0800 x86, lto: Disable LTO for the x86 VDSO The VDSO does not play well with LTO, so just disable LTO for it. Also pass a 32bit linker flag for the 32bit version. [ hpa: change braces to parens to match kernel Makefile style ] Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1391846481-31491-1-git-send-email...@linux.intel.com Signed-off-by: H. Peter Anvin --- arch/x86/vdso/Makefile | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile index fd14be1..9206ac7 100644 --- a/arch/x86/vdso/Makefile +++ b/arch/x86/vdso/Makefile @@ -2,6 +2,8 @@ # Building vDSO images for x86. # +KBUILD_CFLAGS += $(DISABLE_LTO) + VDSO64-$(CONFIG_X86_64):= y VDSOX32-$(CONFIG_X86_X32_ABI) := y VDSO32-$(CONFIG_X86_32):= y @@ -35,7 +37,8 @@ export CPPFLAGS_vdso.lds += -P -C VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \ -Wl,--no-undefined \ - -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 + -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 \ + $(DISABLE_LTO) $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso.so @@ -127,7 +130,7 @@ vdso32.so-$(VDSO32-y) += sysenter vdso32-images = $(vdso32.so-y:%=vdso32-%.so) CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds) -VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-soname=linux-gate.so.1 +VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-m,elf_i386 -Wl,-soname=linux-gate.so.1 # This makes sure the $(obj) subdirectory exists even though vdso32/ # is not a kbuild sub-make subdirectory. @@ -181,7 +184,8 @@ quiet_cmd_vdso = VDSO$@ -Wl,-T,$(filter %.lds,$^) $(filter %.o,$^) && \ sh $(srctree)/$(src)/checkundef.sh '$(NM)' '$@' -VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) +VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) \ + $(LTO_CFLAGS) GCOV_PROFILE := n # -- 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/
[tip:x86/asmlinkage] lto: Make asmlinkage __visible
Commit-ID: 128ea04a9885af9629059e631ddf0cab4815b589 Gitweb: http://git.kernel.org/tip/128ea04a9885af9629059e631ddf0cab4815b589 Author: Andi Kleen AuthorDate: Sat, 8 Feb 2014 09:01:07 +0100 Committer: H. Peter Anvin CommitDate: Thu, 13 Feb 2014 20:21:59 -0800 lto: Make asmlinkage __visible Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1391846481-31491-3-git-send-email...@linux.intel.com Signed-off-by: H. Peter Anvin --- include/linux/linkage.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/linkage.h b/include/linux/linkage.h index a6a42dd..34a513a 100644 --- a/include/linux/linkage.h +++ b/include/linux/linkage.h @@ -12,9 +12,9 @@ #endif #ifdef __cplusplus -#define CPP_ASMLINKAGE extern "C" +#define CPP_ASMLINKAGE extern "C" __visible #else -#define CPP_ASMLINKAGE +#define CPP_ASMLINKAGE __visible #endif #ifndef asmlinkage -- 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-next: manual merge of the akpm-current tree with the cgroup tree
[Just adding Tejun]
On Fri, 14 Feb 2014 15:25:57 +1100 Stephen Rothwell
wrote:
>
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in
> kernel/cpuset.c between commit d66393e54e0a ("cpuset: use
> css_task_iter_start/next/end() instead of css_scan_tasks()") from the
> cgroup tree and commit a82211b06d6e ("cpusets: allocate heap only when
> required") from the akpm-current tree.
>
> I fixed it up (the former removed the need for the heap, so I effectively
> remove the latter) and can carry the fix as necessary (no action is
> required).
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
Cheers,
Stephen Rothwell
pgpUe9XiFjdLD.pgp
Description: PGP signature
Re: [PATCH 14/17] Kbuild, lto: Add Link Time Optimization support
I am about to commit the patches before this except 02/17 and 12/17 to tip:x86/asmlinkage; however, I figure we need a new 02/17 before committing the actual LTO patches to avoid build breakage. -hpa -- 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/
