Re: [PATCH 2/3] sched,fair: Fix local starvation
2016-05-21 22:04 GMT+08:00 Mike Galbraith :
> On Tue, 2016-05-10 at 19:43 +0200, Peter Zijlstra wrote:
>
> (Evolution authors must either not do patch review, or use some other
> mailer. Squint hard, this crud really is your patch;)
>
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>>
>> @@ -1762,7 +1770,11 @@ void sched_ttwu_pending(void)
>> >> while (llist) {
>> >> > p = llist_entry(llist, struct task_struct, wake_entry);
>> >> > llist = llist_next(llist);
>> ->> > ttwu_do_activate(rq, p, 0, cookie);
>> +>> > /*
>> +>> > * See ttwu_queue(); we only call ttwu_queue_remote() when
>> +>> > * its a x-cpu wakeup.
>> +>> > */
>> +>> > ttwu_do_activate(rq, p, WF_MIGRATED, cookie);
>
> Wakees that were not migrated/normalized eat an unwanted min_vruntime,
Why there were wakees queued by twu_queue_remote() not migrated?
Regards,
Wanpeng Li
Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer
Hi Paul, On Sat, May 21, 2016 at 10:24:22PM -0700, Paul E. McKenney wrote: > On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote: > > Greetings, > > > > 0day kernel testing robot got the below dmesg and the first bad commit is > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > > > commit 8704baab9bc848b58c129fed6b591bb84ec02f41 > > Author: Paul E. McKenney > > AuthorDate: Thu Dec 31 18:33:22 2015 -0800 > > Commit: Paul E. McKenney > > CommitDate: Thu Mar 31 13:37:38 2016 -0700 > > > > rcutorture: Add RCU grace-period performance tests > > > > This commit adds a new rcuperf module that carries out simple > > performance > > tests of RCU grace periods. > > > > Signed-off-by: Paul E. McKenney > > ??? > > This commit adds a default-n performance-test module. I don't believe I think the robot was using a !SMP && CONFIG_TORTURE_TEST=y && CONFIG_RCU_PERF_TEST=y configuration ;-) > that this would result in boot failures. False bisection? > The code triggering the warning is: WARN_ON(rcu_gp_is_normal() && gp_exp); , so rcu_gp_is_normal() is true because we are using TINY RCU, moreover the default value of gp_exp for *rcuperf* is also true (whereas the one for rcutorture is false). That's why the warnning was triggered. It happened in the boot progress because rcu_perf_writer threads were created and ran via module init function rcu_perf_init(). Maybe we'd better change the defaut value of gp_exp for rcuperf? Regards, Boqun > Thanx, Paul > > > +---++++ > > | | 291783b8ad | > > 8704baab9b | ce82e4a05f | > > +---++++ > > | boot_successes| 57 | 0 > > | 0 | > > | boot_failures | 6 | 22 > > | 13 | > > | BUG:unable_to_handle_kernel | 6 | 22 > > || > > | Oops | 6 | 22 > > || > > | EIP_is_at_get_perf_callchain | 6 | > > || > > | Kernel_panic-not_syncing:Fatal_exception | 5 | 22 > > || > > | backtrace:acpi_get_cpuid | 6 | 22 > > | 13 | > > | backtrace:early_init_pdc | 6 | 22 > > | 13 | > > | backtrace:acpi_early_processor_set_pdc| 6 | 22 > > | 13 | > > | backtrace:acpi_init | 6 | 22 > > | 13 | > > | backtrace:kernel_init_freeable| 6 | 22 > > | 13 | > > | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 1 | > > || > > | backtrace:vfs_fstatat | 2 | > > || > > | backtrace:SyS_fstatat64 | 2 | > > || > > | backtrace:SYSC_socketcall | 2 | > > || > > | backtrace:SyS_socketcall | 2 | 0 > > | 6 | > > | WARNING:at_kernel/rcu/rcuperf.c:#rcu_perf_writer | 0 | 22 > > | 13 | > > | BUG:spinlock_bad_magic_on_CPU | 0 | 22 > > || > > | BUG:spinlock_lockup_suspected_on_CPU | 0 | 22 > > || > > | EIP_is_at__wake_up_common | 0 | 22 > > || > > | backtrace:rcu_perf_writer | 0 | 22 > > | 13 | > > | backtrace:sock_setsockopt | 0 | 0 > > | 6 | > > | backtrace:rht_deferred_worker | 0 | 0 > > | 3 | > > +---++++ > > > > [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted > > 4.6.0-rc1-5-g8704baa #3 > > [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted > > 4.6.0-rc1-5-g8704baa #3 > > [1.062485] > > [1.062485] cf03bc70 cf03bc70 cf03bc50 cf03bc50 c15192fc > > c15192fc cf03bc5c cf03bc5c c157a45b c157a45b c1ed4940 c1ed4940 cf03bcac > > cf03bcac > > > > [1.064620] c157aa41 > > [1.064620] c157aa41 c1bba04c c1bba04c cf03bc74 cf03bc74 c1ed4958 > > c1ed4958 0202 0202 c100
[GIT] Sparc
Some 32-bit kgdb cleanups from Sam Ravnborg, and a hugepage TLB flush overhead fix on 64-bit from Nitin Gupta. Please pull, thanks a lot! The following changes since commit 33656a1f2ee5346c742d63ddd0e0970c95a56b70: Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs (2016-05-02 09:59:57 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc for you to fetch changes up to 24e49ee3d76b70853a96520e46b8837e5eae65b2: sparc64: Reduce TLB flushes during hugepte changes (2016-05-20 18:44:27 -0700) David S. Miller (1): Merge branch 'sparc32-cosmetic-changes' Nitin Gupta (1): sparc64: Reduce TLB flushes during hugepte changes Sam Ravnborg (7): sparc32: drop hardcoding trap_level in kgdb_trap sparc32: drop local prototype in kgdb_32 sparc32: use proper prototype for trapbase sparc32: fix build with STRICT_MM_TYPECHECKS sparc32: drop superfluous cast in calls to __nocache_pa() openprom: fix warning aeroflex/greth: fix warning about unused variable arch/sparc/include/asm/head_32.h | 8 arch/sparc/include/asm/kgdb.h | 2 +- arch/sparc/include/asm/page_32.h | 2 -- arch/sparc/include/asm/pgalloc_32.h | 4 ++-- arch/sparc/include/asm/pgtable_32.h | 2 +- arch/sparc/include/asm/pgtable_64.h | 43 --- arch/sparc/include/asm/tlbflush_64.h | 3 ++- arch/sparc/kernel/entry.S | 10 -- arch/sparc/kernel/kernel.h| 1 + arch/sparc/kernel/kgdb_32.c | 11 +-- arch/sparc/kernel/setup_32.c | 4 +--- arch/sparc/mm/hugetlbpage.c | 33 - arch/sparc/mm/init_64.c | 12 arch/sparc/mm/io-unit.c | 4 ++-- arch/sparc/mm/srmmu.c | 19 --- arch/sparc/mm/tlb.c | 25 ++--- arch/sparc/mm/tsb.c | 32 +--- drivers/net/ethernet/aeroflex/greth.c | 2 +- drivers/sbus/char/openprom.c | 40 19 files changed, 147 insertions(+), 110 deletions(-)
Re: [PATCHv9 2/2] selftest/x86: add mremap vdso test
2016-05-21 23:27 GMT+03:00 Ingo Molnar : > > * Andy Lutomirski wrote: > >> On Thu, May 19, 2016 at 11:48 PM, Ingo Molnar wrote: >> > >> > * Dmitry Safonov wrote: >> > >> >> Should print on success: >> >> [root@localhost ~]# ./test_mremap_vdso_32 >> >> AT_SYSINFO_EHDR is 0xf773f000 >> >> [NOTE]Moving vDSO: [f773f000, f774] -> [a00, a001000] >> >> [OK] >> >> Or segfault if landing was bad (before patches): >> >> [root@localhost ~]# ./test_mremap_vdso_32 >> >> AT_SYSINFO_EHDR is 0xf774f000 >> >> [NOTE]Moving vDSO: [f774f000, f775] -> [a00, a001000] >> >> Segmentation fault (core dumped) >> > >> > So I still think that generating potential segfaults is not a proper way >> > to test a >> > new feature. How are we supposed to tell the feature still works? I >> > realize that >> > glibc is a problem here - but that doesn't really change the QA equation: >> > we are >> > adding new kernel code to help essentially a single application out of >> > tens of >> > thousands of applications. >> > >> > At minimum we should have a robust testcase ... >> >> I think it's robust enough. It will print "[OK]" and exit with 0 on >> success and it will crash on failure. The latter should cause make >> run_tests to fail reliably. > > Indeed, you are right - I somehow mis-read it as potentially segfaulting on > fixed > kernels as well... > > Will look at applying this after the merge window. Great! Thanks, Ingo - maybe I should have wrote test's patch description better. Thanks again, Andy.
[PATCH] clk: fixed-rate: add clk_hw_unregister_fixed_rate()
This will be used to migrate to the clk_hw APIs.
Signed-off-by: Masahiro Yamada
---
drivers/clk/clk-fixed-rate.c | 11 +++
include/linux/clk-provider.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index 8e4453e..2edb393 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -145,6 +145,17 @@ void clk_unregister_fixed_rate(struct clk *clk)
}
EXPORT_SYMBOL_GPL(clk_unregister_fixed_rate);
+void clk_hw_unregister_fixed_rate(struct clk_hw *hw)
+{
+ struct clk_fixed_rate *fixed;
+
+ fixed = to_clk_fixed_rate(hw);
+
+ clk_hw_unregister(hw);
+ kfree(fixed);
+}
+EXPORT_SYMBOL_GPL(clk_hw_unregister_fixed_rate);
+
#ifdef CONFIG_OF
/**
* of_fixed_clk_setup() - Setup function for simple fixed rate clock
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 0c72204..94e00fe 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -293,6 +293,7 @@ void clk_unregister_fixed_rate(struct clk *clk);
struct clk_hw *clk_hw_register_fixed_rate_with_accuracy(struct device *dev,
const char *name, const char *parent_name, unsigned long flags,
unsigned long fixed_rate, unsigned long fixed_accuracy);
+void clk_hw_unregister_fixed_rate(struct clk_hw *hw);
void of_fixed_clk_setup(struct device_node *np);
--
1.9.1
Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer
On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > commit 8704baab9bc848b58c129fed6b591bb84ec02f41 > Author: Paul E. McKenney > AuthorDate: Thu Dec 31 18:33:22 2015 -0800 > Commit: Paul E. McKenney > CommitDate: Thu Mar 31 13:37:38 2016 -0700 > > rcutorture: Add RCU grace-period performance tests > > This commit adds a new rcuperf module that carries out simple performance > tests of RCU grace periods. > > Signed-off-by: Paul E. McKenney ??? This commit adds a default-n performance-test module. I don't believe that this would result in boot failures. False bisection? Thanx, Paul > +---++++ > | | 291783b8ad | > 8704baab9b | ce82e4a05f | > +---++++ > | boot_successes| 57 | 0 > | 0 | > | boot_failures | 6 | 22 > | 13 | > | BUG:unable_to_handle_kernel | 6 | 22 > || > | Oops | 6 | 22 > || > | EIP_is_at_get_perf_callchain | 6 | > || > | Kernel_panic-not_syncing:Fatal_exception | 5 | 22 > || > | backtrace:acpi_get_cpuid | 6 | 22 > | 13 | > | backtrace:early_init_pdc | 6 | 22 > | 13 | > | backtrace:acpi_early_processor_set_pdc| 6 | 22 > | 13 | > | backtrace:acpi_init | 6 | 22 > | 13 | > | backtrace:kernel_init_freeable| 6 | 22 > | 13 | > | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 1 | > || > | backtrace:vfs_fstatat | 2 | > || > | backtrace:SyS_fstatat64 | 2 | > || > | backtrace:SYSC_socketcall | 2 | > || > | backtrace:SyS_socketcall | 2 | 0 > | 6 | > | WARNING:at_kernel/rcu/rcuperf.c:#rcu_perf_writer | 0 | 22 > | 13 | > | BUG:spinlock_bad_magic_on_CPU | 0 | 22 > || > | BUG:spinlock_lockup_suspected_on_CPU | 0 | 22 > || > | EIP_is_at__wake_up_common | 0 | 22 > || > | backtrace:rcu_perf_writer | 0 | 22 > | 13 | > | backtrace:sock_setsockopt | 0 | 0 > | 6 | > | backtrace:rht_deferred_worker | 0 | 0 > | 3 | > +---++++ > > [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted > 4.6.0-rc1-5-g8704baa #3 > [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted > 4.6.0-rc1-5-g8704baa #3 > [1.062485] > [1.062485] cf03bc70 cf03bc70 cf03bc50 cf03bc50 c15192fc > c15192fc cf03bc5c cf03bc5c c157a45b c157a45b c1ed4940 c1ed4940 cf03bcac > cf03bcac > > [1.064620] c157aa41 > [1.064620] c157aa41 c1bba04c c1bba04c cf03bc74 cf03bc74 c1ed4958 > c1ed4958 0202 0202 c100312d c100312d cf03bc80 cf03bc80 c10ab3fb > c10ab3fb > > [1.066740] cf03bc90 > [1.066740] cf03bc90 0203 0203 cf0a8634 cf0a8634 0382 > 0382 cf03bcc4 cf03bcc4 c11a701a c11a701a 0010 0010 eb0e29d5 > eb0e29d5 > > [1.068833] Call Trace: > [1.068833] Call Trace: > [1.072825] [] dump_stack+0x16/0x1a > [1.072825] [] dump_stack+0x16/0x1a > [1.073958] [] ubsan_epilogue+0xb/0x40 > [1.073958] [] ubsan_epilogue+0xb/0x40 > [1.075151] [] __ubsan_handle_out_of_bounds+0x61/0x80 > [1.075151] [] __ubsan_handle_out_of_bounds+0x61/0x80 > [1.080046] [] ? allocate_fake_cpuc+0x7d/0x90 > [1.080046] [] ? allocate_fake_cpuc+0x7d/0x90 > [1.081379] [] ? trace_hardirqs_on+0xb/0x10 > [1.081379] [] ? trace_hardirqs_on+0xb/0x10 > [1.086052] [] ? slob_free+0x15a/0xa00 > [1.086052] [] ? slob_f
[PATCH v3] Drivers: hv: vmbus: fix the race when querying & updating the percpu list
There is a rare race when we remove an entry from the global list
hv_context.percpu_list[cpu] in hv_process_channel_removal() ->
percpu_channel_deq() -> list_del(): at this time, if vmbus_on_event() ->
process_chn_event() -> pcpu_relid2channel() is trying to query the list,
we can get the kernel fault.
Similarly, we also have the issue in the code path: vmbus_process_offer() ->
percpu_channel_enq().
We can resolve the issue by disabling the tasklet when updating the list.
The patch also moves vmbus_release_relid() to a later place where
the channel has been removed from the per-cpu and the global lists.
Reported-by: Rolf Neugebauer
Cc: Vitaly Kuznetsov
Signed-off-by: Dexuan Cui
---
v2: added tasklet_schedule() after tasklet_enable(). Thanks, Vitaly!
v3: I shouldn't have moved percpu_channel_deq()
from hv_process_channel_removal() to vmbus_close_internal(): the
channel couldn't be removed from the per-cpu list, if the channel state
was not CHANNEL_OPENED_STATE. v3 fixed this.
v3 also added 2 wrapper functions for the disable/enable stuff.
v3 also moved vmbus_release_relid() to a later safe place.
You can also get v3 by
https://github.com/dcui/linux/commit/2f314fb9352020f70b094bf31539afd3a18a5545
drivers/hv/channel.c | 6 ++
drivers/hv/channel_mgmt.c | 32
include/linux/hyperv.h| 3 +++
3 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 56dd261..ef8e9b5 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -512,7 +512,6 @@ static void reset_channel_cb(void *arg)
static int vmbus_close_internal(struct vmbus_channel *channel)
{
struct vmbus_channel_close_channel *msg;
- struct tasklet_struct *tasklet;
int ret;
/*
@@ -524,8 +523,7 @@ static int vmbus_close_internal(struct vmbus_channel
*channel)
* To resolve the race, we can serialize them by disabling the
* tasklet when the latter is running here.
*/
- tasklet = hv_context.event_dpc[channel->target_cpu];
- tasklet_disable(tasklet);
+ hv_event_tasklet_disable(channel);
/*
* In case a device driver's probe() fails (e.g.,
@@ -591,7 +589,7 @@ static int vmbus_close_internal(struct vmbus_channel
*channel)
get_order(channel->ringbuffer_pagecount * PAGE_SIZE));
out:
- tasklet_enable(tasklet);
+ hv_event_tasklet_enable(channel);
return ret;
}
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 38b682ba..3bcf141 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -21,6 +21,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include
+#include
#include
#include
#include
@@ -303,16 +304,32 @@ static void vmbus_release_relid(u32 relid)
vmbus_post_msg(&msg, sizeof(struct vmbus_channel_relid_released));
}
+void hv_event_tasklet_disable(struct vmbus_channel *channel)
+{
+ struct tasklet_struct *tasklet;
+ tasklet = hv_context.event_dpc[channel->target_cpu];
+ tasklet_disable(tasklet);
+}
+
+void hv_event_tasklet_enable(struct vmbus_channel *channel)
+{
+ struct tasklet_struct *tasklet;
+ tasklet = hv_context.event_dpc[channel->target_cpu];
+ tasklet_enable(tasklet);
+
+ /* In case there is any pending event */
+ tasklet_schedule(tasklet);
+}
+
void hv_process_channel_removal(struct vmbus_channel *channel, u32 relid)
{
unsigned long flags;
struct vmbus_channel *primary_channel;
- vmbus_release_relid(relid);
-
BUG_ON(!channel->rescind);
BUG_ON(!mutex_is_locked(&vmbus_connection.channel_mutex));
+ hv_event_tasklet_disable(channel);
if (channel->target_cpu != get_cpu()) {
put_cpu();
smp_call_function_single(channel->target_cpu,
@@ -321,6 +338,7 @@ void hv_process_channel_removal(struct vmbus_channel
*channel, u32 relid)
percpu_channel_deq(channel);
put_cpu();
}
+ hv_event_tasklet_enable(channel);
if (channel->primary_channel == NULL) {
list_del(&channel->listentry);
@@ -341,6 +359,8 @@ void hv_process_channel_removal(struct vmbus_channel
*channel, u32 relid)
cpumask_clear_cpu(channel->target_cpu,
&primary_channel->alloced_cpus_in_node);
+ vmbus_release_relid(relid);
+
free_channel(channel);
}
@@ -409,6 +429,7 @@ static void vmbus_process_offer(struct vmbus_channel
*newchannel)
init_vp_index(newchannel, dev_type);
+ hv_event_tasklet_disable(channel);
if (newchannel->target_cpu != get_cpu()) {
put_cpu();
smp_call_function_single(newchannel->target_cpu,
@@ -418,6 +439,7 @@ static void vmbus_process_offer(struct vmbus_channel
*newchannel)
percpu_channel_enq(newchannel);
put_cpu();
}
+
[rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 8704baab9bc848b58c129fed6b591bb84ec02f41 Author: Paul E. McKenney AuthorDate: Thu Dec 31 18:33:22 2015 -0800 Commit: Paul E. McKenney CommitDate: Thu Mar 31 13:37:38 2016 -0700 rcutorture: Add RCU grace-period performance tests This commit adds a new rcuperf module that carries out simple performance tests of RCU grace periods. Signed-off-by: Paul E. McKenney +---++++ | | 291783b8ad | 8704baab9b | ce82e4a05f | +---++++ | boot_successes| 57 | 0 | 0 | | boot_failures | 6 | 22 | 13 | | BUG:unable_to_handle_kernel | 6 | 22 || | Oops | 6 | 22 || | EIP_is_at_get_perf_callchain | 6 | || | Kernel_panic-not_syncing:Fatal_exception | 5 | 22 || | backtrace:acpi_get_cpuid | 6 | 22 | 13 | | backtrace:early_init_pdc | 6 | 22 | 13 | | backtrace:acpi_early_processor_set_pdc| 6 | 22 | 13 | | backtrace:acpi_init | 6 | 22 | 13 | | backtrace:kernel_init_freeable| 6 | 22 | 13 | | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 1 | || | backtrace:vfs_fstatat | 2 | || | backtrace:SyS_fstatat64 | 2 | || | backtrace:SYSC_socketcall | 2 | || | backtrace:SyS_socketcall | 2 | 0 | 6 | | WARNING:at_kernel/rcu/rcuperf.c:#rcu_perf_writer | 0 | 22 | 13 | | BUG:spinlock_bad_magic_on_CPU | 0 | 22 || | BUG:spinlock_lockup_suspected_on_CPU | 0 | 22 || | EIP_is_at__wake_up_common | 0 | 22 || | backtrace:rcu_perf_writer | 0 | 22 | 13 | | backtrace:sock_setsockopt | 0 | 0 | 6 | | backtrace:rht_deferred_worker | 0 | 0 | 3 | +---++++ [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted 4.6.0-rc1-5-g8704baa #3 [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted 4.6.0-rc1-5-g8704baa #3 [1.062485] [1.062485] cf03bc70 cf03bc70 cf03bc50 cf03bc50 c15192fc c15192fc cf03bc5c cf03bc5c c157a45b c157a45b c1ed4940 c1ed4940 cf03bcac cf03bcac [1.064620] c157aa41 [1.064620] c157aa41 c1bba04c c1bba04c cf03bc74 cf03bc74 c1ed4958 c1ed4958 0202 0202 c100312d c100312d cf03bc80 cf03bc80 c10ab3fb c10ab3fb [1.066740] cf03bc90 [1.066740] cf03bc90 0203 0203 cf0a8634 cf0a8634 0382 0382 cf03bcc4 cf03bcc4 c11a701a c11a701a 0010 0010 eb0e29d5 eb0e29d5 [1.068833] Call Trace: [1.068833] Call Trace: [1.072825] [] dump_stack+0x16/0x1a [1.072825] [] dump_stack+0x16/0x1a [1.073958] [] ubsan_epilogue+0xb/0x40 [1.073958] [] ubsan_epilogue+0xb/0x40 [1.075151] [] __ubsan_handle_out_of_bounds+0x61/0x80 [1.075151] [] __ubsan_handle_out_of_bounds+0x61/0x80 [1.080046] [] ? allocate_fake_cpuc+0x7d/0x90 [1.080046] [] ? allocate_fake_cpuc+0x7d/0x90 [1.081379] [] ? trace_hardirqs_on+0xb/0x10 [1.081379] [] ? trace_hardirqs_on+0xb/0x10 [1.086052] [] ? slob_free+0x15a/0xa00 [1.086052] [] ? slob_free+0x15a/0xa00 [1.087383] [] acpi_ds_create_operand+0x20b/0x294 [1.087383] [] acpi_ds_create_operand+0x20b/0x294 [1.088807] [] ? __kmem_cache_free+0x3d/0x60 [1.088807] [] ? __kmem_cache_free+0x3d/0x60 [1.095377] [] acpi_ds_create_operands+0xf7/0x139 [1.095377] [] acpi_ds_create_operands+0xf7/0x139 [1.096857] [] ? acpi_os_release_object+0x8/0xc [1.096857] [] ? acpi_os_release_object+0x8/0xc [1.098240] [] ? acpi_ut_delete_generic_sta
Re: [PATCH 1/4] x86: Save return value from kernel_thread
On Sat, May 21, 2016 at 9:44 PM, Andy Lutomirski wrote: > On Sat, May 21, 2016 at 9:04 AM, Brian Gerst wrote: >> Kernel threads should always return zero on success after calling >> do_execve(). The >> two existing cases in the kernel (kernel_init() and >> call_usermodehelper_exec_async()) >> correctly do this. Save a few bytes by storing EAX/RAX instead of an >> immediate zero. >> Also fix the 64-bit case which should save the full 64-bits. > > Does this have any additional motivation beyond cleanup and fixing an > inconsequential bug? I.e. does the rest of your series need this? > > --Andy It's just a minor cleanup, not necessary. -- Brian Gerst
Re: [PATCH 1/4] x86: Save return value from kernel_thread
On Sat, May 21, 2016 at 9:04 AM, Brian Gerst wrote: > Kernel threads should always return zero on success after calling > do_execve(). The > two existing cases in the kernel (kernel_init() and > call_usermodehelper_exec_async()) > correctly do this. Save a few bytes by storing EAX/RAX instead of an > immediate zero. > Also fix the 64-bit case which should save the full 64-bits. Does this have any additional motivation beyond cleanup and fixing an inconsequential bug? I.e. does the rest of your series need this? --Andy
[GIT PULL] f2fs for 4.7-rc1
Hi Linus,
In this round, as Ted pointed out, fscrypto allows one more key prefix given by
filesystem to resolve backward compatibility issue. Other than that, we could
fix several error handling flow by introducing fault injection facility. We've
also achieved performance improvement in some workloads as well as a bunch of
bug fixes.
Could you consider pulling the below patches?
Thanks,
The following changes since commit 806fdcce017dc98c4dbf8ed001750a0d7d2bb0af:
Merge branch 'x86-urgent-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2016-04-14 19:53:46
-0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
tags/for-f2fs-4.7
for you to fetch changes up to 0f3311a8c266b9f4fae4e5cdfcd9a86970e2b9bd:
f2fs: fix to update dirty page count correctly (2016-05-20 14:55:41 -0700)
Enhancement
- fs-specific prefix for fscrypto
- fault injection facility
- expose validity bitmaps for user to be aware of fragmentation
- fallocate/rm/preallocation speed up
- use percpu counters
Bug fixes
- some inline_dentry/inline_data bugs
- error handling for atomic/volatile/orphan inodes
- recover broken superblock
Chao Yu (22):
f2fs: fix to convert inline directory correctly
MAINTAINERS: update my email address
f2fs: be aware of invalid filename length
f2fs: move node pages only in victim section during GC
f2fs: fix to clear private data in page
f2fs: fix to clear page private flag
f2fs: factor out fsync inode entry operations
f2fs: remove unneeded readahead in find_fsync_dnodes
f2fs: remove unneeded memset when updating xattr
f2fs: reuse get_extent_info
f2fs: shrink size of struct seg_entry
f2fs: fix incorrect mapping in ->bmap
f2fs: avoid panic when truncating to max filesize
f2fs: fix inode cache leak
f2fs: use mnt_{want,drop}_write_file in ioctl
f2fs: make atomic/volatile operation exclusive
f2fs: support in batch multi blocks preallocation
f2fs: support in batch fzero in dnode page
f2fs: fix deadlock when flush inline data
f2fs: fix i_current_depth during inline dentry conversion
f2fs: fix incorrect error path handling in f2fs_move_rehashed_dirents
f2fs: fix to update dirty page count correctly
Jaegeuk Kim (46):
f2fs: give RO message when recovering superblock
f2fs: recover superblock at RW remounts
f2fs: give -EINVAL for norecovery and rw mount
f2fs: treat as a normal umount when remounting ro
f2fs: show current mount status
f2fs: use PGP_LOCK to check its truncation
f2fs: add BUG_ON to avoid unnecessary flow
f2fs: fix dropping inmemory pages in a wrong time
f2fs: unset atomic/volatile flag in f2fs_release_file
f2fs: remove redundant condition check
f2fs: give -E2BIG for no space in xattr
f2fs: don't invalidate atomic page if successful
f2fs: flush dirty pages before starting atomic writes
f2fs: avoid needless lock for node pages when fsyncing a file
f2fs: avoid writing 0'th page in volatile writes
f2fs: split sync_node_pages with fsync_node_pages
f2fs: report unwritten status in fsync_node_pages
f2fs: set fsync mark only for the last dnode
f2fs: issue cache flush on direct IO
f2fs: introduce macros for proc entries
f2fs: add proc entry to show valid block bitmap
f2fs: introduce f2fs_kmalloc to wrap kmalloc
f2fs: use f2fs_grab_cache_page instead of grab_cache_page
f2fs: add mount option to select fault injection ratio
f2fs: inject kmalloc failure
f2fs: inject page allocation failures
f2fs: inject ENOSPC failures
f2fs: revisit error handling flows
f2fs: fix leak of orphan inode objects
f2fs: retry to truncate blocks in -ENOMEM case
f2fs: don't worry about inode leak in evict_inode
f2fs: remove an obsolete variable
fscrypto/f2fs: allow fs-specific key prefix for fs encryption
f2fs: fallocate data blocks in single locked node page
f2fs: read node blocks ahead when truncating blocks
f2fs: do not preallocate block unaligned to 4KB
f2fs: show # of orphan inodes
f2fs: avoid f2fs_bug_on during recovery
f2fs: manipulate dirty file inodes when DATA_FLUSH is set
f2fs: use bio count instead of F2FS_WRITEBACK page count
f2fs: use percpu_counter for page counters
f2fs: use percpu_counter for # of dirty pages in inode
f2fs: use percpu_counter for alloc_valid_block_count
f2fs: use percpu_counter for total_valid_inode_count
f2fs: avoid ENOSPC fault in the recovery process
f2fs: flush pending bios right away when error occurs
Sheng Yong (2):
f2fs: correct return value type of f2fs_fill_super
f2fs: add fault
Re: [PATCH] dell-smm-hwmon: Detect fan with index=2
On Sunday 22 May 2016 02:21:46 Guenter Roeck wrote:
> On 05/21/2016 07:52 AM, Pali Rohár wrote:
> > Some Dell machines (e.g. Dell Precision M3800) have two fans, first
> > with index=0 and second with index=2. So export also attributes
> > for third fan device with index=2.
> >
> > Reported-by: Tolga Cakir
> > Signed-off-by: Pali Rohár
> > ---
> >
> > drivers/hwmon/dell-smm-hwmon.c | 20 +++-
> > 1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > ---
> >
> > Hi Tolga! Can you test this patch if sensors see fan device
> > correctly?
>
> I assume this means I should wait for test results before applying
> the patch ?
Yes, testing should be done.
Do you have some pending/testing/next tree/branch for such patches?
> Thanks,
> Guenter
>
> > diff --git a/drivers/hwmon/dell-smm-hwmon.c
> > b/drivers/hwmon/dell-smm-hwmon.c index 577445f..7a2764a 100644
> > --- a/drivers/hwmon/dell-smm-hwmon.c
> > +++ b/drivers/hwmon/dell-smm-hwmon.c
> > @@ -78,6 +78,7 @@ static uint i8k_fan_max = I8K_FAN_HIGH;
> >
> > #define I8K_HWMON_HAVE_TEMP4 (1 << 3)
> > #define I8K_HWMON_HAVE_FAN1 (1 << 4)
> > #define I8K_HWMON_HAVE_FAN2 (1 << 5)
> >
> > +#define I8K_HWMON_HAVE_FAN3(1 << 6)
> >
> > MODULE_AUTHOR("Massimo Dal Zotto (d...@debian.org)");
> > MODULE_AUTHOR("Pali Rohár ");
> >
> > @@ -246,7 +247,7 @@ static int _i8k_get_fan_type(int fan)
> >
> > static int i8k_get_fan_type(int fan)
> > {
> >
> > /* I8K_SMM_GET_FAN_TYPE SMM call is expensive, so cache values
> > */
> >
> > - static int types[2] = { INT_MIN, INT_MIN };
> > + static int types[3] = { INT_MIN, INT_MIN, INT_MIN };
> >
> > if (types[fan] == INT_MIN)
> >
> > types[fan] = _i8k_get_fan_type(fan);
> >
> > @@ -707,6 +708,12 @@ static SENSOR_DEVICE_ATTR(fan2_label, S_IRUGO,
> > i8k_hwmon_show_fan_label, NULL,
> >
> > 1);
> >
> > static SENSOR_DEVICE_ATTR(pwm2, S_IRUGO | S_IWUSR,
> > i8k_hwmon_show_pwm,
> >
> > i8k_hwmon_set_pwm, 1);
> >
> > +static SENSOR_DEVICE_ATTR(fan3_input, S_IRUGO, i8k_hwmon_show_fan,
> > NULL, + 2);
> > +static SENSOR_DEVICE_ATTR(fan3_label, S_IRUGO,
> > i8k_hwmon_show_fan_label, NULL, + 2);
> > +static SENSOR_DEVICE_ATTR(pwm3, S_IRUGO | S_IWUSR,
> > i8k_hwmon_show_pwm, + i8k_hwmon_set_pwm, 2);
> >
> > static struct attribute *i8k_attrs[] = {
> >
> > &sensor_dev_attr_temp1_input.dev_attr.attr, /* 0 */
> >
> > @@ -723,6 +730,9 @@ static struct attribute *i8k_attrs[] = {
> >
> > &sensor_dev_attr_fan2_input.dev_attr.attr, /* 11 */
> > &sensor_dev_attr_fan2_label.dev_attr.attr, /* 12 */
> > &sensor_dev_attr_pwm2.dev_attr.attr,/* 13 */
> >
> > + &sensor_dev_attr_fan3_input.dev_attr.attr, /* 14 */
> > + &sensor_dev_attr_fan3_label.dev_attr.attr, /* 15 */
> > + &sensor_dev_attr_pwm3.dev_attr.attr,/* 16 */
> >
> > NULL
> >
> > };
> >
> > @@ -747,6 +757,9 @@ static umode_t i8k_is_visible(struct kobject
> > *kobj, struct attribute *attr,
> >
> > if (index >= 11 && index <= 13 &&
> >
> > !(i8k_hwmon_flags & I8K_HWMON_HAVE_FAN2))
> >
> > return 0;
> >
> > + if (index >= 14 && index <= 16 &&
> > + !(i8k_hwmon_flags & I8K_HWMON_HAVE_FAN3))
> > + return 0;
> >
> > return attr->mode;
> >
> > }
> >
> > @@ -788,6 +801,11 @@ static int __init i8k_init_hwmon(void)
> >
> > if (err >= 0)
> >
> > i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN2;
> >
> > + /* Third fan attributes, if fan status is OK */
> > + err = i8k_get_fan_status(2);
> > + if (err >= 0)
> > + i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN3;
> > +
> >
> > i8k_hwmon_dev = hwmon_device_register_with_groups(NULL,
> > "dell_smm",
> >
> > NULL, i8k_groups);
> >
> > if (IS_ERR(i8k_hwmon_dev)) {
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection
On Sunday 22 May 2016 02:19:48 Guenter Roeck wrote:
> On 05/21/2016 07:46 AM, Pali Rohár wrote:
> > On more Dell machines (e.g. Dell Precision M3800)
> > I8K_SMM_GET_FAN_TYPE call is too expensive (CPU is too long in SMM
> > mode) and cause kernel to hang. This patch cache type for each fan
> > (as it should not change) and change the way how fan presense is
> > detected. It revert and use function fan_status() as was before
> > commit f989e55452c7 ("i8k: Add support for fan labels").
> >
> > Moreover, kernel hangs for 2 - 3 seconds only sometimes and only on
> > some Dell machines. When kernel hangs fan speed is at max. So it
> > was hard to debug and bisect where is root of this problem. It
> > looks like this is bug in Dell BIOS which implement fan type SMM
> > code... and there is no way how to fix it in kernel.
> >
> > Signed-off-by: Pali Rohár
> > Reviewed-by: Jean Delvare
> > Reported-and-tested-by: Tolga Cakir
> > Fixes: f989e55452c7 ("i8k: Add support for fan labels")
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=112021
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=100121
> > Cc: sta...@vger.kernel.org # v4.0+, will need backport
>
> Should this patch be applied, or do you wait for more testing ?
I would like to hear some confirmation from people with affected machine.
> Guenter
>
> > ---
> >
> > drivers/hwmon/dell-smm-hwmon.c | 21 -
> > 1 file changed, 16 insertions(+), 5 deletions(-)
> >
> > ---
> >
> > Hi!
> >
> > Jan C Peters, Thorsten Leemhuis, David Santamaría Rogado, Peter
> > Saunderson and others, can you test this patch if it fixes your
> > freeze problem at boottime and when using "sensors" program?
> >
> > I need to know if this patch fixes problem on Dell Studio XPS 8000
> > and Dell Studio XPS 8100 machines, so we can revert git commits:
> >
> > 6220f4ebd7b4 ("hwmon: (dell-smm) Blacklist Dell Studio XPS 8000")
> > a4b45b25f18d ("hwmon: (dell-smm) Blacklist Dell Studio XPS 8100")
> >
> > diff --git a/drivers/hwmon/dell-smm-hwmon.c
> > b/drivers/hwmon/dell-smm-hwmon.c index c43318d..577445f 100644
> > --- a/drivers/hwmon/dell-smm-hwmon.c
> > +++ b/drivers/hwmon/dell-smm-hwmon.c
> > @@ -235,7 +235,7 @@ static int i8k_get_fan_speed(int fan)
> >
> > /*
> >
> >* Read the fan type.
> >*/
> >
> > -static int i8k_get_fan_type(int fan)
> > +static int _i8k_get_fan_type(int fan)
> >
> > {
> >
> > struct smm_regs regs = { .eax = I8K_SMM_GET_FAN_TYPE, };
> >
> > @@ -243,6 +243,17 @@ static int i8k_get_fan_type(int fan)
> >
> > return i8k_smm(®s) ? : regs.eax & 0xff;
> >
> > }
> >
> > +static int i8k_get_fan_type(int fan)
> > +{
> > + /* I8K_SMM_GET_FAN_TYPE SMM call is expensive, so cache values */
> > + static int types[2] = { INT_MIN, INT_MIN };
> > +
> > + if (types[fan] == INT_MIN)
> > + types[fan] = _i8k_get_fan_type(fan);
> > +
> > + return types[fan];
> > +}
> > +
> >
> > /*
> >
> >* Read the fan nominal rpm for specific fan speed.
> >*/
> >
> > @@ -767,13 +778,13 @@ static int __init i8k_init_hwmon(void)
> >
> > if (err >= 0)
> >
> > i8k_hwmon_flags |= I8K_HWMON_HAVE_TEMP4;
> >
> > - /* First fan attributes, if fan type is OK */
> > - err = i8k_get_fan_type(0);
> > + /* First fan attributes, if fan status is OK */
> > + err = i8k_get_fan_status(0);
> >
> > if (err >= 0)
> >
> > i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN1;
> >
> > - /* Second fan attributes, if fan type is OK */
> > - err = i8k_get_fan_type(1);
> > + /* Second fan attributes, if fan status is OK */
> > + err = i8k_get_fan_status(1);
> >
> > if (err >= 0)
> >
> > i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN2;
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] dell-smm-hwmon: Detect fan with index=2
On 05/21/2016 07:52 AM, Pali Rohár wrote:
Some Dell machines (e.g. Dell Precision M3800) have two fans, first with
index=0 and second with index=2. So export also attributes for third fan
device with index=2.
Reported-by: Tolga Cakir
Signed-off-by: Pali Rohár
---
drivers/hwmon/dell-smm-hwmon.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
---
Hi Tolga! Can you test this patch if sensors see fan device correctly?
I assume this means I should wait for test results before applying the patch ?
Thanks,
Guenter
diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
index 577445f..7a2764a 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -78,6 +78,7 @@ static uint i8k_fan_max = I8K_FAN_HIGH;
#define I8K_HWMON_HAVE_TEMP4 (1 << 3)
#define I8K_HWMON_HAVE_FAN1 (1 << 4)
#define I8K_HWMON_HAVE_FAN2 (1 << 5)
+#define I8K_HWMON_HAVE_FAN3(1 << 6)
MODULE_AUTHOR("Massimo Dal Zotto (d...@debian.org)");
MODULE_AUTHOR("Pali Rohár ");
@@ -246,7 +247,7 @@ static int _i8k_get_fan_type(int fan)
static int i8k_get_fan_type(int fan)
{
/* I8K_SMM_GET_FAN_TYPE SMM call is expensive, so cache values */
- static int types[2] = { INT_MIN, INT_MIN };
+ static int types[3] = { INT_MIN, INT_MIN, INT_MIN };
if (types[fan] == INT_MIN)
types[fan] = _i8k_get_fan_type(fan);
@@ -707,6 +708,12 @@ static SENSOR_DEVICE_ATTR(fan2_label, S_IRUGO,
i8k_hwmon_show_fan_label, NULL,
1);
static SENSOR_DEVICE_ATTR(pwm2, S_IRUGO | S_IWUSR, i8k_hwmon_show_pwm,
i8k_hwmon_set_pwm, 1);
+static SENSOR_DEVICE_ATTR(fan3_input, S_IRUGO, i8k_hwmon_show_fan, NULL,
+ 2);
+static SENSOR_DEVICE_ATTR(fan3_label, S_IRUGO, i8k_hwmon_show_fan_label, NULL,
+ 2);
+static SENSOR_DEVICE_ATTR(pwm3, S_IRUGO | S_IWUSR, i8k_hwmon_show_pwm,
+ i8k_hwmon_set_pwm, 2);
static struct attribute *i8k_attrs[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr, /* 0 */
@@ -723,6 +730,9 @@ static struct attribute *i8k_attrs[] = {
&sensor_dev_attr_fan2_input.dev_attr.attr, /* 11 */
&sensor_dev_attr_fan2_label.dev_attr.attr, /* 12 */
&sensor_dev_attr_pwm2.dev_attr.attr,/* 13 */
+ &sensor_dev_attr_fan3_input.dev_attr.attr, /* 14 */
+ &sensor_dev_attr_fan3_label.dev_attr.attr, /* 15 */
+ &sensor_dev_attr_pwm3.dev_attr.attr,/* 16 */
NULL
};
@@ -747,6 +757,9 @@ static umode_t i8k_is_visible(struct kobject *kobj, struct
attribute *attr,
if (index >= 11 && index <= 13 &&
!(i8k_hwmon_flags & I8K_HWMON_HAVE_FAN2))
return 0;
+ if (index >= 14 && index <= 16 &&
+ !(i8k_hwmon_flags & I8K_HWMON_HAVE_FAN3))
+ return 0;
return attr->mode;
}
@@ -788,6 +801,11 @@ static int __init i8k_init_hwmon(void)
if (err >= 0)
i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN2;
+ /* Third fan attributes, if fan status is OK */
+ err = i8k_get_fan_status(2);
+ if (err >= 0)
+ i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN3;
+
i8k_hwmon_dev = hwmon_device_register_with_groups(NULL, "dell_smm",
NULL, i8k_groups);
if (IS_ERR(i8k_hwmon_dev)) {
Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection
On 05/21/2016 07:46 AM, Pali Rohár wrote:
On more Dell machines (e.g. Dell Precision M3800) I8K_SMM_GET_FAN_TYPE call
is too expensive (CPU is too long in SMM mode) and cause kernel to hang.
This patch cache type for each fan (as it should not change) and change the
way how fan presense is detected. It revert and use function fan_status()
as was before commit f989e55452c7 ("i8k: Add support for fan labels").
Moreover, kernel hangs for 2 - 3 seconds only sometimes and only on some
Dell machines. When kernel hangs fan speed is at max. So it was hard to
debug and bisect where is root of this problem. It looks like this is bug
in Dell BIOS which implement fan type SMM code... and there is no way how
to fix it in kernel.
Signed-off-by: Pali Rohár
Reviewed-by: Jean Delvare
Reported-and-tested-by: Tolga Cakir
Fixes: f989e55452c7 ("i8k: Add support for fan labels")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=112021
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100121
Cc: sta...@vger.kernel.org # v4.0+, will need backport
Should this patch be applied, or do you wait for more testing ?
Guenter
---
drivers/hwmon/dell-smm-hwmon.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
---
Hi!
Jan C Peters, Thorsten Leemhuis, David Santamaría Rogado, Peter Saunderson
and others, can you test this patch if it fixes your freeze problem at
boottime and when using "sensors" program?
I need to know if this patch fixes problem on Dell Studio XPS 8000 and
Dell Studio XPS 8100 machines, so we can revert git commits:
6220f4ebd7b4 ("hwmon: (dell-smm) Blacklist Dell Studio XPS 8000")
a4b45b25f18d ("hwmon: (dell-smm) Blacklist Dell Studio XPS 8100")
diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
index c43318d..577445f 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -235,7 +235,7 @@ static int i8k_get_fan_speed(int fan)
/*
* Read the fan type.
*/
-static int i8k_get_fan_type(int fan)
+static int _i8k_get_fan_type(int fan)
{
struct smm_regs regs = { .eax = I8K_SMM_GET_FAN_TYPE, };
@@ -243,6 +243,17 @@ static int i8k_get_fan_type(int fan)
return i8k_smm(®s) ? : regs.eax & 0xff;
}
+static int i8k_get_fan_type(int fan)
+{
+ /* I8K_SMM_GET_FAN_TYPE SMM call is expensive, so cache values */
+ static int types[2] = { INT_MIN, INT_MIN };
+
+ if (types[fan] == INT_MIN)
+ types[fan] = _i8k_get_fan_type(fan);
+
+ return types[fan];
+}
+
/*
* Read the fan nominal rpm for specific fan speed.
*/
@@ -767,13 +778,13 @@ static int __init i8k_init_hwmon(void)
if (err >= 0)
i8k_hwmon_flags |= I8K_HWMON_HAVE_TEMP4;
- /* First fan attributes, if fan type is OK */
- err = i8k_get_fan_type(0);
+ /* First fan attributes, if fan status is OK */
+ err = i8k_get_fan_status(0);
if (err >= 0)
i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN1;
- /* Second fan attributes, if fan type is OK */
- err = i8k_get_fan_type(1);
+ /* Second fan attributes, if fan status is OK */
+ err = i8k_get_fan_status(1);
if (err >= 0)
i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN2;
Re: [PATCH] drm/gma500: use vma_pages().
On Sat, May 21, 2016 at 3:21 PM, Muhammad Falak R Wani wrote: > Replace explicit computation of vma page count by a call to > vma_pages() > > Signed-off-by: Muhammad Falak R Wani Thanks, queued for gma500-next > --- > drivers/gpu/drm/gma500/framebuffer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/gma500/framebuffer.c > b/drivers/gpu/drm/gma500/framebuffer.c > index 7440bf9..5486e7e 100644 > --- a/drivers/gpu/drm/gma500/framebuffer.c > +++ b/drivers/gpu/drm/gma500/framebuffer.c > @@ -125,7 +125,7 @@ static int psbfb_vm_fault(struct vm_area_struct *vma, > struct vm_fault *vmf) > unsigned long phys_addr = (unsigned long)dev_priv->stolen_base + > psbfb->gtt->offset; > > - page_num = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; > + page_num = vma_pages(vma); > address = (unsigned long)vmf->virtual_address - (vmf->pgoff << > PAGE_SHIFT); > > vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > -- > 1.9.1 >
[rcu:dev.2016.05.18a 28/28] kernel/rcu/tree_plugin.h:1168:2: error: implicit declaration of function 'for_each_leaf_node_cpu_bit'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2016.05.18a head: a396e98dae720a48c49795892d23ca17c87319b0 commit: a396e98dae720a48c49795892d23ca17c87319b0 [28/28] rcu: Correctly handle sparse possible CPUs config: x86_64-randconfig-n0-05220622 (attached as .config) compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430 reproduce: git checkout a396e98dae720a48c49795892d23ca17c87319b0 # save the attached .config to linux build tree make ARCH=x86_64 Note: the rcu/dev.2016.05.18a HEAD a396e98dae720a48c49795892d23ca17c87319b0 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): In file included from kernel/rcu/tree.c:4209:0: kernel/rcu/tree_plugin.h: In function 'rcu_boost_kthread_setaffinity': >> kernel/rcu/tree_plugin.h:1168:2: error: implicit declaration of function >> 'for_each_leaf_node_cpu_bit' [-Werror=implicit-function-declaration] for_each_leaf_node_cpu_bit(rnp, cpu, bit) ^~ >> kernel/rcu/tree_plugin.h:1169:3: error: expected ';' before 'if' if ((mask & bit) && cpu != outgoingcpu) ^~ kernel/rcu/tree_plugin.h:1159:16: warning: unused variable 'mask' [-Wunused-variable] unsigned long mask = rcu_rnp_online_cpus(rnp); ^~~~ cc1: some warnings being treated as errors vim +/for_each_leaf_node_cpu_bit +1168 kernel/rcu/tree_plugin.h 1162 int cpu; 1163 1164 if (!t) 1165 return; 1166 if (!zalloc_cpumask_var(&cm, GFP_KERNEL)) 1167 return; > 1168 for_each_leaf_node_cpu_bit(rnp, cpu, bit) > 1169 if ((mask & bit) && cpu != outgoingcpu) 1170 cpumask_set_cpu(cpu, cm); 1171 if (cpumask_weight(cm) == 0) 1172 cpumask_setall(cm); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
[PATCH v2 1/1] rtc: ds1685: correct check of day of month
The day of month is checked in ds1685_rtc_read_alarm
and ds1685_rtc_set_alarm.
Multiple errors exist in the day of month check.
Operator ! has a higher priority than &&.
(!(mday >= 1) && (mday <= 31)) is false for mday == 32.
When verifying the day of month the binary and the BCD mode
have to be considered.
v2:
consider ds1685_rtc_read_alarm
consider rtc->bcd_mode as indicated by Alexandre Belloni
Signed-off-by: Heinrich Schuchardt
---
drivers/rtc/rtc-ds1685.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-ds1685.c b/drivers/rtc/rtc-ds1685.c
index b3ce3c6..92e2f27 100644
--- a/drivers/rtc/rtc-ds1685.c
+++ b/drivers/rtc/rtc-ds1685.c
@@ -103,6 +103,26 @@ ds1685_rtc_bin2bcd(struct ds1685_priv *rtc, u8 val, u8
bin_mask, u8 bcd_mask)
}
/**
+ * s1685_rtc_check_mday - check validity of the day of month.
+ * @rtc: pointer to the ds1685 rtc structure.
+ * @mday: day of month.
+ *
+ * Returns -EDOM if the day of month is not within 1..31 range.
+ */
+static inline int
+ds1685_rtc_check_mday(struct ds1685_priv *rtc, u8 mday)
+{
+ if (rtc->bcd_mode) {
+ if (mday < 0x01 || mday > 0x31 || (mday & 0x0f) > 0x09)
+ return -EDOM;
+ } else {
+ if (mday < 1 || mday > 31)
+ return -EDOM;
+ }
+ return 0;
+}
+
+/**
* ds1685_rtc_switch_to_bank0 - switch the rtc to bank 0.
* @rtc: pointer to the ds1685 rtc structure.
*/
@@ -377,6 +397,7 @@ ds1685_rtc_read_alarm(struct device *dev, struct rtc_wkalrm
*alrm)
struct platform_device *pdev = to_platform_device(dev);
struct ds1685_priv *rtc = platform_get_drvdata(pdev);
u8 seconds, minutes, hours, mday, ctrlb, ctrlc;
+ int ret;
/* Fetch the alarm info from the RTC alarm registers. */
ds1685_rtc_begin_data_access(rtc);
@@ -388,9 +409,10 @@ ds1685_rtc_read_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
ctrlc = rtc->read(rtc, RTC_CTRL_C);
ds1685_rtc_end_data_access(rtc);
- /* Check month date. */
- if (!(mday >= 1) && (mday <= 31))
- return -EDOM;
+ /* Check the month date for validity. */
+ ret = ds1685_rtc_check_mday(rtc, mday);
+ if (ret)
+ return ret;
/*
* Check the three alarm bytes.
@@ -445,6 +467,7 @@ ds1685_rtc_set_alarm(struct device *dev, struct rtc_wkalrm
*alrm)
struct platform_device *pdev = to_platform_device(dev);
struct ds1685_priv *rtc = platform_get_drvdata(pdev);
u8 ctrlb, seconds, minutes, hours, mday;
+ int ret;
/* Fetch the alarm info and convert to BCD. */
seconds = ds1685_rtc_bin2bcd(rtc, alrm->time.tm_sec,
@@ -461,8 +484,9 @@ ds1685_rtc_set_alarm(struct device *dev, struct rtc_wkalrm
*alrm)
RTC_MDAY_BCD_MASK);
/* Check the month date for validity. */
- if (!(mday >= 1) && (mday <= 31))
- return -EDOM;
+ ret = ds1685_rtc_check_mday(rtc, mday);
+ if (ret)
+ return ret;
/*
* Check the three alarm bytes.
--
2.1.4
[PATCH] libnvdimm, dax: fix deletion
The ndctl unit tests discovered that the dax enabling omitted updates to
nd_detach_and_reset(). This routine clears device the configuration
when the namespace is detached. Without this clearing userspace may
assume that the device is in the process of being configured by another
agent in the system.
Signed-off-by: Dan Williams
---
drivers/nvdimm/claim.c| 23 +--
drivers/nvdimm/nd-core.h |1 +
drivers/nvdimm/pfn_devs.c | 19 ---
3 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/nvdimm/claim.c b/drivers/nvdimm/claim.c
index 5f53db59a058..8b2e3c4fb0ad 100644
--- a/drivers/nvdimm/claim.c
+++ b/drivers/nvdimm/claim.c
@@ -93,6 +93,25 @@ static bool is_idle(struct device *dev, struct
nd_namespace_common *ndns)
return true;
}
+struct nd_pfn *to_nd_pfn_safe(struct device *dev)
+{
+ /*
+* pfn device attributes are re-used by dax device instances, so we
+* need to be careful to correct device-to-nd_pfn conversion.
+*/
+ if (is_nd_pfn(dev))
+ return to_nd_pfn(dev);
+
+ if (is_nd_dax(dev)) {
+ struct nd_dax *nd_dax = to_nd_dax(dev);
+
+ return &nd_dax->nd_pfn;
+ }
+
+ WARN_ON(1);
+ return NULL;
+}
+
static void nd_detach_and_reset(struct device *dev,
struct nd_namespace_common **_ndns)
{
@@ -106,8 +125,8 @@ static void nd_detach_and_reset(struct device *dev,
nd_btt->lbasize = 0;
kfree(nd_btt->uuid);
nd_btt->uuid = NULL;
- } else if (is_nd_pfn(dev)) {
- struct nd_pfn *nd_pfn = to_nd_pfn(dev);
+ } else if (is_nd_pfn(dev) || is_nd_dax(dev)) {
+ struct nd_pfn *nd_pfn = to_nd_pfn_safe(dev);
kfree(nd_pfn->uuid);
nd_pfn->uuid = NULL;
diff --git a/drivers/nvdimm/nd-core.h b/drivers/nvdimm/nd-core.h
index 4136c1a82539..6c42eda025f9 100644
--- a/drivers/nvdimm/nd-core.h
+++ b/drivers/nvdimm/nd-core.h
@@ -94,4 +94,5 @@ bool __nd_attach_ndns(struct device *dev, struct
nd_namespace_common *attach,
ssize_t nd_namespace_store(struct device *dev,
struct nd_namespace_common **_ndns, const char *buf,
size_t len);
+struct nd_pfn *to_nd_pfn_safe(struct device *dev);
#endif /* __ND_CORE_H__ */
diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index 04f71d6d304d..436191c47077 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -54,25 +54,6 @@ struct nd_pfn *to_nd_pfn(struct device *dev)
}
EXPORT_SYMBOL(to_nd_pfn);
-static struct nd_pfn *to_nd_pfn_safe(struct device *dev)
-{
- /*
-* pfn device attributes are re-used by dax device instances, so we
-* need to be careful to correct device-to-nd_pfn conversion.
-*/
- if (is_nd_pfn(dev))
- return to_nd_pfn(dev);
-
- if (is_nd_dax(dev)) {
- struct nd_dax *nd_dax = to_nd_dax(dev);
-
- return &nd_dax->nd_pfn;
- }
-
- WARN_ON(1);
- return NULL;
-}
-
static ssize_t mode_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
Re: [PATCHv9 2/2] selftest/x86: add mremap vdso test
* Andy Lutomirski wrote: > On Thu, May 19, 2016 at 11:48 PM, Ingo Molnar wrote: > > > > * Dmitry Safonov wrote: > > > >> Should print on success: > >> [root@localhost ~]# ./test_mremap_vdso_32 > >> AT_SYSINFO_EHDR is 0xf773f000 > >> [NOTE]Moving vDSO: [f773f000, f774] -> [a00, a001000] > >> [OK] > >> Or segfault if landing was bad (before patches): > >> [root@localhost ~]# ./test_mremap_vdso_32 > >> AT_SYSINFO_EHDR is 0xf774f000 > >> [NOTE]Moving vDSO: [f774f000, f775] -> [a00, a001000] > >> Segmentation fault (core dumped) > > > > So I still think that generating potential segfaults is not a proper way to > > test a > > new feature. How are we supposed to tell the feature still works? I realize > > that > > glibc is a problem here - but that doesn't really change the QA equation: > > we are > > adding new kernel code to help essentially a single application out of tens > > of > > thousands of applications. > > > > At minimum we should have a robust testcase ... > > I think it's robust enough. It will print "[OK]" and exit with 0 on > success and it will crash on failure. The latter should cause make > run_tests to fail reliably. Indeed, you are right - I somehow mis-read it as potentially segfaulting on fixed kernels as well... Will look at applying this after the merge window. Thanks, Ingo
[PATCH] seqlock: fix raw_read_seqcount_latch()
lockless_dereference() is supposed to take pointer not integer.
Signed-off-by: Alexey Dobriyan
---
include/linux/seqlock.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -277,7 +277,7 @@ static inline void raw_write_seqcount_barrier(seqcount_t *s)
static inline int raw_read_seqcount_latch(seqcount_t *s)
{
- return lockless_dereference(s->sequence);
+ return lockless_dereference(s)->sequence;
}
/**
@@ -331,7 +331,7 @@ static inline int raw_read_seqcount_latch(seqcount_t *s)
* unsigned seq, idx;
*
* do {
- * seq = lockless_dereference(latch->seq);
+ * seq = lockless_dereference(latch)->seq;
*
* idx = seq & 0x01;
* entry = data_query(latch->data[idx], ...);
Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs
Hi Peter, Ingo, On Thu, May 19, 2016 at 04:04:19PM -0700, Steve Muckle wrote: > On Thu, May 19, 2016 at 11:06:14PM +0200, Rafael J. Wysocki wrote: > > > In the case of a remote update the hook has to run (or not) after it is > > > known whether preemption will occur so we don't do needless work or > > > IPIs. If the policy CPUs aren't known in the scheduler then the early > > > hook will always need to be called along with an indication that it is > > > the early hook being called. If it turns out to be a remote update it > > > could then be deferred to the later hook, which would only be called > > > when a remote update has been deferred and preemption has not occurred. > > > > > > This means two hook inovcations for a remote non-preempting wakeup > > > though instead of one. Perhaps this is a good middle ground on code > > > churn vs. optimization though. > > > > I would think so. > > Ok, I will pursue this approach. I'd like to get your opinion here before proceeding further... To catch you up and summarize, I'm trying to implement support for calling the scheduler cpufreq callback during remote wakeups. Currently the scheduler cpufreq callback is only called when the target CPU is the current CPU. If a remote wakeup does not result in preemption, the CPU frequency may currently not be adjusted appropriately for up to a tick, when we are guaranteed to call the hook again. Invoking schedutil promptly for the target CPU in this situation means sending an IPI if the current CPU is not in the target CPU's frequency domain. This is because often a cpufreq driver must run on a CPU within the frequency domain it is bound to. But the catch is that we should not do this and incur the overhead of an IPI if preemption will occur, as in that case the scheduler (and schedutil) will run soon on the target CPU anyway, potentially as a result of the scheduler sending its own IPI. I figured this unnecessary overhead would be unacceptable and so have been working on an approach to avoid it. Unfortunately the current hooks happen before the preemption decision is made. My current implementation sets a flag if schedutil sees a remote wakeup and then bails. There's a test to call the hook again at the end of check_preempt_curr() if the flag is set. The flag is cleared by resched_curr() as that means preemption will happen on the target CPU. The flag currently lives at the end of the rq struct. I could move it into the update_util_data hook structure or elsewhere, but that would mean accessing another per-cpu item in hot scheduler paths. Thoughts? Note the current implementation described above differs a bit from the last posting in this thread, per discussion with Rafael. thanks, Steve
Re: [GIT PULL] RTC for 4.7
On 21/05/2016 at 11:18:15 -0700, Linus Torvalds wrote : > On Sat, May 21, 2016 at 8:15 AM, Alexandre Belloni > wrote: > > > > Here is the pull-request for the RTC subsystem for 4.7. > > Grr. I noticed this too late, but this has all been rebased very recently. > > Don't f*cking do this! Why do I have to tell people every single merge window? > Yeah, sorry about that. I realized I forgot to rework a few commit messages (Fixes: tags and author names due to patchwork messing with them) before applying so I did it before sending the pull request. I'll abstain next time. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Re: [PATCH] max44000: Remove scale from proximity
On 20/05/16 15:44, Crestez Dan Leonard wrote:
> This is not implemented and doesn't really make sense because IIO
> proximity is unit-less.
>
> Remove IIO_CHAN_INFO_SCALE from info_mask because so that the _scale
> sysfs entry won't appear. This fixes userspace tools like generic_buffer
> which abort when reads returns an error.
>
Applied to the fixes-togreg-post-rc1 branch of iio.git.
Thanks,
Jonathan
> Signed-off-by: Crestez Dan Leonard
> ---
> drivers/iio/light/max44000.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/iio/light/max44000.c b/drivers/iio/light/max44000.c
> index e01e58a..f17cb2e 100644
> --- a/drivers/iio/light/max44000.c
> +++ b/drivers/iio/light/max44000.c
> @@ -147,7 +147,6 @@ static const struct iio_chan_spec max44000_channels[] = {
> {
> .type = IIO_PROXIMITY,
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> - .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
> .scan_index = MAX44000_SCAN_INDEX_PRX,
> .scan_type = {
> .sign = 'u',
>
Re: [PATCH] iio: light: jsa1212: remove unneeded i2c check functionality test
On 19/05/16 21:19, Matt Ranostay wrote: > Reviewed-by: Matt Ranostay Applied to the togreg branch of iio.git. Thanks, Jonathan > > On Thu, May 19, 2016 at 11:37 AM, sathyanarayanan kuppuswamy > wrote: >> Looks Good. >> >> Reviewed-by:Kuppuswamy Sathyanarayanan >> >> >> >> On 05/15/2016 11:37 AM, Alison Schofield wrote: >>> >>> This driver does not call i2c_smbus_read|write_byte_data(), >>> so remove the corresponding functionality test. It uses regmap >>> to handle byte transfers transparently. >>> >>> Signed-off-by: Alison Schofield >>> --- >>> Found & fixed by inspection based on same defect recently fixed >>> in light/tpl0102 driver. >>> >>> >>> drivers/iio/light/jsa1212.c | 3 --- >>> 1 file changed, 3 deletions(-) >>> >>> diff --git a/drivers/iio/light/jsa1212.c b/drivers/iio/light/jsa1212.c >>> index 99a6281..e8a8931 100644 >>> --- a/drivers/iio/light/jsa1212.c >>> +++ b/drivers/iio/light/jsa1212.c >>> @@ -325,9 +325,6 @@ static int jsa1212_probe(struct i2c_client *client, >>> struct regmap *regmap; >>> int ret; >>> - if (!i2c_check_functionality(client->adapter, >>> I2C_FUNC_SMBUS_BYTE_DATA)) >>> - return -EOPNOTSUPP; >>> - >>> indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data)); >>> if (!indio_dev) >>> return -ENOMEM; >> >> >> -- >> Sathyanarayanan Kuppuswamy >> Android kernel developer >>
Re: [PATCH v2 03/12] of: add J-Core interrupt controller bindings
On Sat, May 21, 2016 at 08:07:54PM +0200, Geert Uytterhoeven wrote: > On Sat, May 21, 2016 at 12:34 AM, Rich Felker wrote: > > On Fri, May 20, 2016 at 10:04:26AM +0200, Geert Uytterhoeven wrote: > >> On Fri, May 20, 2016 at 4:53 AM, Rich Felker wrote: > >> > +Additional properties required for aic1: > >> > + > >> > +- reg : Memory region for configuration. > >> > + > >> > +- cpu-offset : For SMP, the offset to the per-cpu memory region for > >> > + configuration, to be scaled by the cpu number. > >> > >> Does cpu-offset apply to aic1 only? > > > > The current kernel driver doesn't have any reason to _need_ cpu-offset > > for aic2, but since there are registers there that a driver (even a > > non-Linux one) may want to use, I think it makes sense that it should > > be present in the bindings. > > Hence the "for aic1" should be dropped? Yes, I've fixed that locally. Moved reg to required and cpu-offset to optional but needed for smp. Rich
Re: [PATCH v5] iio: max5487: Add support for Maxim digital potentiometers
On 19/05/16 06:55, Cristina Moraru wrote:
> Add implementation for Maxim MAX5487, MAX5488, MAX5489
> digital potentiometers.
>
> Datasheet:
> http://datasheets.maximintegrated.com/en/ds/MAX5487-MAX5489.pdf
>
> Signed-off-by: Cristina Moraru
> CC: Daniel Baluta
Applied to the togreg branch of iio.git - initially pushed out as
testing. As ever with stuff in testing I can still modify the
commit if anyone has anything to add (acks etc welcome of course!)
Jonathan
> ---
> Changes since v4:
> Add year for copyright
> Changes since v3:
> Fix size issue in max5487_write_cmd
> Fix typo
> Changes since v2:
> Change switch statement in max5487_write_raw
> to if statement for consistency
> Add blank line before return statement
> Eliminate regmap support and use spi_write
> Use iio_device_register instead of devm_ version
> Changes since v1:
> Fix spacing
> Eliminate max5487_cfg struct
> Add kohms as driver data
>
> drivers/iio/potentiometer/Kconfig | 11 +++
> drivers/iio/potentiometer/Makefile | 1 +
> drivers/iio/potentiometer/max5487.c | 161
>
> 3 files changed, 173 insertions(+)
> create mode 100644 drivers/iio/potentiometer/max5487.c
>
> diff --git a/drivers/iio/potentiometer/Kconfig
> b/drivers/iio/potentiometer/Kconfig
> index 6acb238..0941c8d4 100644
> --- a/drivers/iio/potentiometer/Kconfig
> +++ b/drivers/iio/potentiometer/Kconfig
> @@ -15,6 +15,17 @@ config DS1803
> To compile this driver as a module, choose M here: the
> module will be called ds1803.
>
> +config MAX5487
> +tristate "Maxim MAX5487/MAX5488/MAX5489 Digital Potentiometer driver"
> +depends on SPI
> +help
> + Say yes here to build support for the Maxim
> + MAX5487, MAX5488, MAX5489 digital potentiometer
> + chips.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called max5487.
> +
> config MCP4131
> tristate "Microchip MCP413X/414X/415X/416X/423X/424X/425X/426X Digital
> Potentiometer driver"
> depends on SPI
> diff --git a/drivers/iio/potentiometer/Makefile
> b/drivers/iio/potentiometer/Makefile
> index 6007faa..8adb58f 100644
> --- a/drivers/iio/potentiometer/Makefile
> +++ b/drivers/iio/potentiometer/Makefile
> @@ -4,6 +4,7 @@
>
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_DS1803) += ds1803.o
> +obj-$(CONFIG_MAX5487) += max5487.o
> obj-$(CONFIG_MCP4131) += mcp4131.o
> obj-$(CONFIG_MCP4531) += mcp4531.o
> obj-$(CONFIG_TPL0102) += tpl0102.o
> diff --git a/drivers/iio/potentiometer/max5487.c
> b/drivers/iio/potentiometer/max5487.c
> new file mode 100644
> index 000..6c50939
> --- /dev/null
> +++ b/drivers/iio/potentiometer/max5487.c
> @@ -0,0 +1,161 @@
> +/*
> + * max5487.c - Support for MAX5487, MAX5488, MAX5489 digital potentiometers
> + *
> + * Copyright (C) 2016 Cristina-Gabriela Moraru
> + *
> + * 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
> +
> +#define MAX5487_WRITE_WIPER_A(0x01 << 8)
> +#define MAX5487_WRITE_WIPER_B(0x02 << 8)
> +
> +/* copy both wiper regs to NV regs */
> +#define MAX5487_COPY_AB_TO_NV(0x23 << 8)
> +/* copy both NV regs to wiper regs */
> +#define MAX5487_COPY_NV_TO_AB(0x33 << 8)
> +
> +#define MAX5487_MAX_POS 255
> +
> +struct max5487_data {
> + struct spi_device *spi;
> + int kohms;
> +};
> +
> +#define MAX5487_CHANNEL(ch, addr) { \
> + .type = IIO_RESISTANCE, \
> + .indexed = 1, \
> + .output = 1,\
> + .channel = ch, \
> + .address = addr,\
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> +}
> +
> +static const struct iio_chan_spec max5487_channels[] = {
> + MAX5487_CHANNEL(0, MAX5487_WRITE_WIPER_A),
> + MAX5487_CHANNEL(1, MAX5487_WRITE_WIPER_B),
> +};
> +
> +static int max5487_write_cmd(struct spi_device *spi, u16 cmd)
> +{
> + return spi_write(spi, (const void *) &cmd, sizeof(u16));
> +}
> +
> +static int max5487_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct max5487_data *data = iio_priv(indio_dev);
> +
> + if (mask != IIO_CHAN_INFO_SCALE)
> + return -EINVAL;
> +
> + *val = 1000 * data->kohms;
> + *val2 = MAX5487_MAX_POS;
> +
> +
Re: [PATCH] iio: Export I2C module alias information
On 17/05/16 17:25, Javier Martinez Canillas wrote:
> The I2C drivers have an i2c_device_id array but that information isn't
> exported to the modules using the MODULE_DEVICE_TABLE() macro. So the
> modules autoloading won't work if the I2C device is registered using
> OF or legacy board files due missing alias information in the modules.
>
> The issue was found using Kieran Bingham's coccinelle semantic patch:
> https://lkml.org/lkml/2016/5/10/520
>
> Signed-off-by: Javier Martinez Canillas
Applied to the togreg branch of iio.git - initially pushed out as
testing for the autobuilders to play with it.
thanks
Jonathan
>
> ---
>
> drivers/iio/humidity/am2315.c | 1 +
> drivers/iio/humidity/htu21.c | 1 +
> drivers/iio/pressure/hp206c.c | 1 +
> drivers/iio/pressure/ms5637.c | 1 +
> drivers/iio/temperature/tsys02d.c | 1 +
> 5 files changed, 5 insertions(+)
>
> diff --git a/drivers/iio/humidity/am2315.c b/drivers/iio/humidity/am2315.c
> index 3be6d209a159..8de39bd349f9 100644
> --- a/drivers/iio/humidity/am2315.c
> +++ b/drivers/iio/humidity/am2315.c
> @@ -278,6 +278,7 @@ static const struct i2c_device_id am2315_i2c_id[] = {
> {"am2315", 0},
> {}
> };
> +MODULE_DEVICE_TABLE(i2c, am2315_i2c_id);
>
> static const struct acpi_device_id am2315_acpi_id[] = {
> {"AOS2315", 0},
> diff --git a/drivers/iio/humidity/htu21.c b/drivers/iio/humidity/htu21.c
> index 11cbc38b450f..0fbbd8c40894 100644
> --- a/drivers/iio/humidity/htu21.c
> +++ b/drivers/iio/humidity/htu21.c
> @@ -236,6 +236,7 @@ static const struct i2c_device_id htu21_id[] = {
> {"ms8607-humidity", MS8607},
> {}
> };
> +MODULE_DEVICE_TABLE(i2c, htu21_id);
>
> static struct i2c_driver htu21_driver = {
> .probe = htu21_probe,
> diff --git a/drivers/iio/pressure/hp206c.c b/drivers/iio/pressure/hp206c.c
> index 90f2b6e4a920..12f769e86355 100644
> --- a/drivers/iio/pressure/hp206c.c
> +++ b/drivers/iio/pressure/hp206c.c
> @@ -401,6 +401,7 @@ static const struct i2c_device_id hp206c_id[] = {
> {"hp206c"},
> {}
> };
> +MODULE_DEVICE_TABLE(i2c, hp206c_id);
>
> #ifdef CONFIG_ACPI
> static const struct acpi_device_id hp206c_acpi_match[] = {
> diff --git a/drivers/iio/pressure/ms5637.c b/drivers/iio/pressure/ms5637.c
> index e68052c118e6..8fb6f7ab97e4 100644
> --- a/drivers/iio/pressure/ms5637.c
> +++ b/drivers/iio/pressure/ms5637.c
> @@ -173,6 +173,7 @@ static const struct i2c_device_id ms5637_id[] = {
> {"ms8607-temppressure", 1},
> {}
> };
> +MODULE_DEVICE_TABLE(i2c, ms5637_id);
>
> static struct i2c_driver ms5637_driver = {
> .probe = ms5637_probe,
> diff --git a/drivers/iio/temperature/tsys02d.c
> b/drivers/iio/temperature/tsys02d.c
> index ab6fe8f6f2d1..c0a19a000387 100644
> --- a/drivers/iio/temperature/tsys02d.c
> +++ b/drivers/iio/temperature/tsys02d.c
> @@ -174,6 +174,7 @@ static const struct i2c_device_id tsys02d_id[] = {
> {"tsys02d", 0},
> {}
> };
> +MODULE_DEVICE_TABLE(i2c, tsys02d_id);
>
> static struct i2c_driver tsys02d_driver = {
> .probe = tsys02d_probe,
>
Re: [PATCH 2/3] sched,fair: Fix local starvation
On Sat, 2016-05-21 at 16:04 +0200, Mike Galbraith wrote:
> Wakees that were not migrated/normalized eat an unwanted min_vruntime,
> and likely take a size XXL latency hit. Big box running master bled
> profusely under heavy load until I turned TTWU_QUEUE off.
The below made big box a happy camper again.
sched/fair: Move se->vruntime normalization state into struct sched_entity
Make ->vruntime normalization state explicit.
Signed-off-by: Mike Galbraith
---
include/linux/sched.h |1 +
kernel/sched/core.c |1 +
kernel/sched/fair.c | 42 ++
3 files changed, 16 insertions(+), 28 deletions(-)
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1348,6 +1348,7 @@ struct sched_entity {
struct rb_node run_node;
struct list_headgroup_node;
unsigned inton_rq;
+ boolnormalized;
u64 exec_start;
u64 sum_exec_runtime;
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2259,6 +2259,7 @@ static void __sched_fork(unsigned long c
p->se.prev_sum_exec_runtime = 0;
p->se.nr_migrations = 0;
p->se.vruntime = 0;
+ p->se.normalized= true;
INIT_LIST_HEAD(&p->se.group_node);
#ifdef CONFIG_FAIR_GROUP_SCHED
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3305,14 +3305,13 @@ static inline void check_schedstat_requi
static void
enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags)
{
- bool renorm = !(flags & ENQUEUE_WAKEUP) || (flags & ENQUEUE_MIGRATED);
bool curr = cfs_rq->curr == se;
/*
* If we're the current task, we must renormalise before calling
* update_curr().
*/
- if (renorm && curr)
+ if (se->normalized && curr)
se->vruntime += cfs_rq->min_vruntime;
update_curr(cfs_rq);
@@ -3323,9 +3322,11 @@ enqueue_entity(struct cfs_rq *cfs_rq, st
* placed in the past could significantly boost this task to the
* fairness detriment of existing tasks.
*/
- if (renorm && !curr)
+ if (se->normalized && !curr)
se->vruntime += cfs_rq->min_vruntime;
+ se->normalized = false;
+
enqueue_entity_load_avg(cfs_rq, se);
account_entity_enqueue(cfs_rq, se);
update_cfs_shares(cfs_rq);
@@ -3422,8 +3423,10 @@ dequeue_entity(struct cfs_rq *cfs_rq, st
* update can refer to the ->curr item and we need to reflect this
* movement in our normalized position.
*/
- if (!(flags & DEQUEUE_SLEEP))
+ if (!(flags & DEQUEUE_SLEEP)) {
se->vruntime -= cfs_rq->min_vruntime;
+ se->normalized = true;
+ }
/* return excess runtime on last dequeue */
return_cfs_rq_runtime(cfs_rq);
@@ -5681,6 +5684,7 @@ static void migrate_task_rq_fair(struct
#endif
se->vruntime -= min_vruntime;
+ se->normalized = true;
}
/*
@@ -8591,6 +8595,7 @@ static void task_fork_fair(struct task_s
}
se->vruntime -= cfs_rq->min_vruntime;
+ se->normalized = true;
raw_spin_unlock_irqrestore(&rq->lock, flags);
}
@@ -8619,29 +8624,7 @@ prio_changed_fair(struct rq *rq, struct
static inline bool vruntime_normalized(struct task_struct *p)
{
- struct sched_entity *se = &p->se;
-
- /*
-* In both the TASK_ON_RQ_QUEUED and TASK_ON_RQ_MIGRATING cases,
-* the dequeue_entity(.flags=0) will already have normalized the
-* vruntime.
-*/
- if (p->on_rq)
- return true;
-
- /*
-* When !on_rq, vruntime of the task has usually NOT been normalized.
-* But there are some cases where it has already been normalized:
-*
-* - A forked child which is waiting for being woken up by
-* wake_up_new_task().
-* - A task which has been woken up by try_to_wake_up() and
-* waiting for actually being woken up by sched_ttwu_pending().
-*/
- if (!se->sum_exec_runtime || p->state == TASK_WAKING)
- return true;
-
- return false;
+ return p->se.normalized;
}
static void detach_task_cfs_rq(struct task_struct *p)
@@ -8656,6 +8639,7 @@ static void detach_task_cfs_rq(struct ta
*/
place_entity(cfs_rq, se, 0);
se->vruntime -= cfs_rq->min_vruntime;
+ se->normalized = true;
}
/* Catch up with the cfs_rq and remove our load when we leave */
@@ -8678,8 +8662,10 @@ static void attach_task_cfs_rq(struct ta
/* Synchronize task with its cfs_rq */
attach_entity_load_avg(cfs_rq, se);
- if (!vruntime_normalized(p))
+ if (vruntime_normalized(p)) {
se->vruntime += cfs_rq->min_vruntime;
+
[PATCH 0/2] f_fs: better handle excess data on read
Between this set and Du, Changbin’s patch, we now have implementation for the following three possibilities to choose from: 1. Buffer excess data (this whole patch set). 2. Fail the transfer (Du, Changbin’s patch). 3. Drop excess data (the first patch from this set). As per earlier comments, I think 3. is the correct, i.e. the second patch should not be ocmmited because: * it complicates the code, * doesn’t handle AIO anyway, * introduces weird behaviours when partial read happens just before endpoint is disabled (we may end up silently dropping excess data anyway), * goes beyond what UDC does and * breaks one read -> one request model which has been true so far. Michal Nazarewicz (2): usb: gadget: f_fs: printk error when excess data is dropped on read usb: gadget: f_fs: buffer data from ‘oversized’ OUT requests drivers/usb/gadget/function/f_fs.c | 179 ++--- 1 file changed, 145 insertions(+), 34 deletions(-) -- Best regards ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ «If at first you don’t succeed, give up skydiving»
[PATCH 2/2] usb: gadget: f_fs: buffer data from ‘oversized’ OUT requests
f_fs rounds up read(2) requests to a multiple of a max packet size
which means that host may provide more data than user has space for.
So far, the excess data has been silently ignored.
This introduces a buffer for a tail of such requests so that they are
returned on next read instead of being ignored.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_fs.c | 130 +++--
1 file changed, 109 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index e26a6b4..08a1ac2 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -130,6 +130,12 @@ struct ffs_epfile {
struct dentry *dentry;
+ /*
+* Buffer for holding data from partial reads which may happen since
+* we’re rounding user read requests to a multiple of a max packet size.
+*/
+ struct ffs_buffer *read_buffer; /* P: epfile->mutex */
+
charname[5];
unsigned char in; /* P: ffs->eps_lock */
@@ -138,6 +144,12 @@ struct ffs_epfile {
unsigned char _pad;
};
+struct ffs_buffer {
+ size_t length;
+ char *data;
+ char storage[];
+};
+
/* ffs_io_data structure ***/
struct ffs_io_data {
@@ -667,6 +679,11 @@ static ssize_t ffs_copy_to_iter(void *data, int data_len,
struct iov_iter *iter)
* Was the buffer aligned in the first place, no such problem would
* happen.
*
+* Data may be dropped only in AIO reads. Synchronous reads are handled
+* by splitting a request into multiple parts. This splitting may still
+* be a problem though so it’s likely best to align the buffer
+* regardless of it being AIO or not..
+*
* This only affects OUT endpoints, i.e. reading data with a read(2),
* aio_read(2) etc. system calls. Writing data to an IN endpoint is not
* affected.
@@ -717,6 +734,56 @@ static void ffs_epfile_async_io_complete(struct usb_ep
*_ep,
schedule_work(&io_data->work);
}
+/* Assumes epfile->mutex is held. */
+static ssize_t __ffs_epfile_read_buffered(struct ffs_epfile *epfile,
+ struct iov_iter *iter)
+{
+ struct ffs_buffer *buf = epfile->read_buffer;
+ ssize_t ret;
+ if (!buf)
+ return 0;
+
+ ret = copy_to_iter(buf->data, buf->length, iter);
+ if (buf->length == ret) {
+ kfree(buf);
+ epfile->read_buffer = NULL;
+ } else if (unlikely(iov_iter_count(iter))) {
+ ret = -EFAULT;
+ } else {
+ buf->length -= ret;
+ buf->data += ret;
+ }
+ return ret;
+}
+
+/* Assumes epfile->mutex is held. */
+static ssize_t __ffs_epfile_read_data(struct ffs_epfile *epfile,
+ void *data, int data_len,
+ struct iov_iter *iter)
+{
+ struct ffs_buffer *buf;
+
+ ssize_t ret = copy_to_iter(data, data_len, iter);
+ if (likely(data_len == ret))
+ return ret;
+
+ if (unlikely(iov_iter_count(iter)))
+ return -EFAULT;
+
+ /* See ffs_copy_to_iter for more context. */
+ pr_warn("functionfs read size %d > requested size %zd, splitting
request into multiple reads.",
+ data_len, ret);
+
+ data_len -= ret;
+ buf = kmalloc(sizeof(*buf) + data_len, GFP_KERNEL);
+ buf->length = data_len;
+ buf->data = buf->storage;
+ memcpy(buf->storage, data + ret, data_len);
+ epfile->read_buffer = buf;
+
+ return ret;
+}
+
static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data)
{
struct ffs_epfile *epfile = file->private_data;
@@ -746,21 +813,40 @@ static ssize_t ffs_epfile_io(struct file *file, struct
ffs_io_data *io_data)
if (halt && epfile->isoc)
return -EINVAL;
+ /* We will be using request and read_buffer */
+ ret = ffs_mutex_lock(&epfile->mutex, file->f_flags & O_NONBLOCK);
+ if (unlikely(ret))
+ goto error;
+
/* Allocate & copy */
if (!halt) {
+ struct usb_gadget *gadget;
+
+ /*
+* Do we have buffered data from previous partial read? Check
+* that for synchronous case only because we do not have
+* facility to ‘wake up’ a pending asynchronous read and push
+* buffered data to it which we would need to make things behave
+* consistently.
+*/
+ if (!io_data->aio && io_data->read) {
+ ret = __ffs_epfile_read_buffered(epfile,
&io_data->data);
+ if (ret)
+
[PATCH 1/2] usb: gadget: f_fs: printk error when excess data is dropped on read
Add a pr_err when host sent more data then the size of the buffer user
space gave us. This may happen on UDCs which require OUT requests to
be aligned to max packet size. The patch includes a description of the
situation.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_fs.c | 61 --
1 file changed, 46 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 2c314c1..e26a6b4 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -640,6 +640,44 @@ static void ffs_epfile_io_complete(struct usb_ep *_ep,
struct usb_request *req)
}
}
+static ssize_t ffs_copy_to_iter(void *data, int data_len, struct iov_iter
*iter)
+{
+ ssize_t ret = copy_to_iter(data, data_len, iter);
+ if (likely(ret == data_len))
+ return ret;
+
+ if (unlikely(iov_iter_count(iter)))
+ return -EFAULT;
+
+ /*
+* Dear user space developer!
+*
+* TL;DR: To stop getting below error message in your kernel log, change
+* user space code using functionfs to align read buffers to a max
+* packet size.
+*
+* Some UDCs (e.g. dwc3) require request sizes to be a multiple of a max
+* packet size. When unaligned buffer is passed to functionfs, it
+* internally uses a larger, aligned buffer so that such UDCs are happy.
+*
+* Unfortunately, this means that host may send more data than was
+* requested in read(2) system call. f_fs doesn’t know what to do with
+* that excess data so it simply drops it.
+*
+* Was the buffer aligned in the first place, no such problem would
+* happen.
+*
+* This only affects OUT endpoints, i.e. reading data with a read(2),
+* aio_read(2) etc. system calls. Writing data to an IN endpoint is not
+* affected.
+*/
+ pr_err("functionfs read size %d > requested size %zd, dropping excess
data. "
+ "Align read buffer size to max packet size to avoid the
problem.\n",
+ data_len, ret);
+
+ return ret;
+}
+
static void ffs_user_copy_worker(struct work_struct *work)
{
struct ffs_io_data *io_data = container_of(work, struct ffs_io_data,
@@ -649,9 +687,7 @@ static void ffs_user_copy_worker(struct work_struct *work)
if (io_data->read && ret > 0) {
use_mm(io_data->mm);
- ret = copy_to_iter(io_data->buf, ret, &io_data->data);
- if (ret != io_data->req->actual &&
iov_iter_count(&io_data->data))
- ret = -EFAULT;
+ ret = ffs_copy_to_iter(io_data->buf, ret, &io_data->data);
unuse_mm(io_data->mm);
}
@@ -804,18 +840,13 @@ static ssize_t ffs_epfile_io(struct file *file, struct
ffs_io_data *io_data)
interrupted = ep->status < 0;
}
- /*
-* XXX We may end up silently droping data here. Since data_len
-* (i.e. req->length) may be bigger than len (after being
-* rounded up to maxpacketsize), we may end up with more data
-* then user space has space for.
-*/
- ret = interrupted ? -EINTR : ep->status;
- if (io_data->read && ret > 0) {
- ret = copy_to_iter(data, ret, &io_data->data);
- if (!ret)
- ret = -EFAULT;
- }
+ if (interrupted)
+ ret = -EINTR;
+ else if (io_data->read && ep->status > 0)
+ ret = ffs_copy_to_iter(data, ep->status,
+ &io_data->data);
+ else
+ ret = ep->status;
goto error_mutex;
} else if (!(req = usb_ep_alloc_request(ep->ep, GFP_KERNEL))) {
ret = -ENOMEM;
--
2.8.0.rc3.226.g39d4020
RE: [PATCH] ftrace: As disabling interrupts is costly and write_lock variant of tasklist_lock is not held from interrupt context it is not necessary to disable interrupts.
On Thu, 19 May 2016 13:49:16 + "N, Soumya P" wrote: > Hi Steve, > > Thanks for the explanation. > I will take care of your comments and send v2 of the same patch. > >>No need, I just pulled in your patch and made the updates to the change log >>and subject myself. I'm starting my tests on it now. > Thanks Steve.
Re: [PATCH v8 2/4] power: reset: add reboot mode driver
On Sun, Apr 24, 2016 at 11:55 PM, Andy Yan wrote:
[..]
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
[..]
> +config SYSCON_REBOOT_MODE
> + bool "Generic SYSCON regmap reboot mode driver"
> + depends on OF
As this isn't really useful without syscon (but still compiles), I
would suggest adding:
depends on SYSCON || COMPILE_TEST
> + select REBOOT_MODE
> + help
> + Say y here will enable reboot mode driver. This will
> + get reboot mode arguments and store it in SYSCON mapped
> + register, then the bootloader can read it to take different
> + action according to the mode.
> +
> endif
>
[..]
> diff --git a/drivers/power/reset/reboot-mode.c
> b/drivers/power/reset/reboot-mode.c
[..]
> +
> +#define PREFIX "mode-"
> +
> +struct mode_info {
> + const char *mode;
> + unsigned int magic;
If you're using of_property_read_u32() to populate this directly you
should have this as u32.
> + struct list_head list;
> +};
> +
> +static int get_reboot_mode_magic(struct reboot_mode_driver *reboot,
> +const char *cmd)
Magic comes from an unsigned property and is passed as unsigned to the
regmap api. Please make it unsigned int throughout the implementation.
> +{
> + const char *normal = "normal";
> + int magic = 0;
> + struct mode_info *info;
> +
> + if (!cmd)
> + cmd = normal;
> +
> + list_for_each_entry(info, &reboot->head, list) {
> + if (!strcmp(info->mode, cmd)) {
> + magic = info->magic;
> + break;
> + }
> + }
> +
[..]
> +int reboot_mode_register(struct reboot_mode_driver *reboot)
> +{
> + struct mode_info *info;
> + struct property *prop;
> + struct device_node *np = reboot->dev->of_node;
> + size_t len = strlen(PREFIX);
> + int ret;
> +
> + INIT_LIST_HEAD(&reboot->head);
> +
> + for_each_property_of_node(np, prop) {
> + if (len > strlen(prop->name) || strncmp(prop->name, PREFIX,
> len))
There's no reason to iterate over the string twice here, strncmp will
exit with -1 if you hit a '\0' before strlen(PREFIX). So you can drop
the first check without any difference in functionality.
What passes this checkout though is if the property equals PREFIX, but
this is probably better to handle as an error, rather than skip over.
So do that below
> + continue;
> +
> + info = devm_kzalloc(reboot->dev, sizeof(*info), GFP_KERNEL);
> + if (!info) {
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + info->mode = kstrdup_const(prop->name + len, GFP_KERNEL);
You need something like this here:
if (!info->mode) {
ret = -ENOMEM;
goto error;
} else if (info->mode[0] == '\0')
dev_err("mode too short");
ret = -EINVAL;
goto error;
}
If you do the kernel a favor and submit a patch to
drivers/base/devres.c adding devm_kstrdup_const() you don't have to do
the goto dance at all.
> + if (of_property_read_u32(np, prop->name, &info->magic)) {
> + dev_err(reboot->dev, "reboot mode %s without magic
> number\n",
> + info->mode);
> + devm_kfree(reboot->dev, info);
> + continue;
> + }
> + list_add_tail(&info->list, &reboot->head);
> + }
> +
> + reboot->reboot_notifier.notifier_call = reboot_mode_notify;
> + ret = register_reboot_notifier(&reboot->reboot_notifier);
> + if (ret)
> + dev_err(reboot->dev, "can't register reboot notifier\n");
You're returning an error but haven't freed your info->modes.
> +
> + return ret;
> +
> +error:
> + list_for_each_entry(info, &reboot->head, list)
> + kfree_const(info->mode);
> +
> + return ret;
> +}
Regards,
Bjorn
Re: [GIT PULL] RTC for 4.7
On Sat, May 21, 2016 at 8:15 AM, Alexandre Belloni wrote: > > Here is the pull-request for the RTC subsystem for 4.7. Grr. I noticed this too late, but this has all been rebased very recently. Don't f*cking do this! Why do I have to tell people every single merge window? Linus
Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver
On Wed, May 18, 2016 at 12:07:02AM +0800, jeffrey.lin wrote:
> Hi Dmitry:
> > >static int raydium_i2c_read_message(struct i2c_client *client,
> > > u32 addr, void *data, size_t len)
> > >{
> > > __be32 be_addr;
> > > size_t xfer_len;
> > > int error;
> > > while (len) {
> > > xfer_len = min_t(size_t, len, RM_MAX_READ_SIZE);
> > >
> > > be_addr = cpu_to_be32(addr);
> > >
> > > error = raydium_i2c_send(client, RM_CMD_BANK_SWITCH,
> > >&be_addr, sizeof(be_addr));
> > > if (!error)
> > > error = raydium_i2c_read(client, addr & 0xff,
> > >data, xfer_len);
> > Change as:
> > if (!error)
> > error = raydium_i2c_read(client, (be_addr >> 24) & 0xff,
> > data, xfer_len);
>
> >I think it is the same on LE, and I suspect it will not work correctly
> >on BE... You want to have the 8 least significant bits of the bank to be
> >used as the address, right?
> This function work correctly with the kernel 3.18 of chromebook in my
> hand. Raydium touch direct access mode can recieve the BE address
That is because it is a little-endian device.
>
> after bank switch command 0xaa. For example, if we'll read 10 bytes
> data begin on 0x12345678. We need send the command sequences as 0xaa->
> 0x12->0x34->0x56-> 0x78 and then recive 10 bytes from 0x78.
>
Right. So the thing is - on any architecture, be it little- or
big-endian, expression "value & 0xff" will extract the 8 least
significant bits from the value, while "(value >> 24) & 0xff" will
extract the most significant bits (assuming that the value is 32 bits). So with
your example if you do
cpu_to_be32() on LE architecture it will actually reshuffle the bytes so
that former LSB will become MSB and then you will extract that MSB and
use it. On BE arches cpu_to_be32() is a noop, so addr and be_addr will
have the same value, and your expression will produce 0x12 and not 0x78
as you expect. On the other hand, doing "addr & 0xff" will produce 0x78
regardless of endianness.
> > static int raydium_i2c_fw_write_page(struct i2c_client *client,
> > u16 page_idx, const void *data, size_t len)
> > {
> > u8 buf[RM_BL_WRT_LEN];
> > u8 pkg_idx = 1;
> > u8 div_cnt;
> > size_t xfer_len;
> > int error;
> > int i;
> >
> > div_cnt = len % RM_BL_WRT_PKG_SIZE ?
> > len / RM_BL_WRT_PKG_SIZE + 1:len / RM_BL_WRT_PKG_SIZE;
> >
> >Drop this. BTW, if you ever need it we have DIV_ROUND_UP macro.
>
> >
> > for (i = 0; i < div_cnt; i++) {
> >
> > while (len) {
> >
> > xfer_len = min_t(size_t, len, RM_BL_WRT_PKG_SIZE);
> > buf[BL_HEADER] = RM_CMD_BOOT_PAGE_WRT;
> > /*FIXME,Touch MCU need zero index as start page*/
> > buf[BL_PAGE_STR] = page_idx ? 0xff : 0;
> > buf[BL_PKG_IDX] = pkg_idx++;
> >
> > memcpy(&buf[BL_DATA_STR], data, xfer_len);
> >
> > /* we need to pad to full page size */
> > if (len < RM_BL_WRT_PKG_SIZE)
> > memset(&buf[BL_DATA_STR] + len, 0xff,
> > RM_BL_WRT_PKG_SIZE - len);
> >
> > if (len == 0)
> > memset(buf + BL_DATA_STR, 0xff, RM_BL_WRT_PKG_SIZE);
> > else if (len < RM_BL_WRT_PKG_SIZE)
> > memset(buf + BL_DATA_STR + xfer_len, 0xff,
> > RM_BL_WRT_PKG_SIZE - xfer_len);
> >
> > error = raydium_i2c_write_object(client, buf, RM_BL_WRT_LEN,
> > RAYDIUM_WAIT_READY);
> > if (error) {
> > dev_err(&client->dev,
> > "page write command failed for page %d, chunk
> > %d: %d\n",
> > page_idx, pkg_idx, error);
> > return error;
> > }
> > data += RM_BL_WRT_PKG_SIZE;
> > len -= RM_BL_WRT_PKG_SIZE;
> > }
> >
> > return error;
> > }
> Modify as below.
>
> static int raydium_i2c_fw_write_page(struct i2c_client *client,
>u16 page_idx, const void *data, size_t len)
> {
> u8 buf[RM_BL_WRT_LEN];
> u8 pkg_idx = 1;
> size_t xfer_len;
> int error;
>
> while (len) {
> xfer_len = min_t(size_t, len, RM_BL_WRT_PKG_SIZE);
> buf[BL_HEADER] = RM_CMD_BOOT_PAGE_WRT;
> /*FIXME,Touch MCU need zero index as start page*/
> buf[BL_PAGE_STR] = page_idx ? 0xff : 0;
> buf[BL_PKG_IDX] = pkg_idx++;
>
> memcpy(&buf[BL_DATA_STR], data, xfer_len);
>
> if (len < RM_BL_WRT_PKG_SIZE) {
> buf[BL_PKG_IDX] = 4;
Why 4???
> memset(buf + BL_DATA_STR + xfer_len, 0xf
[PATCH 1/2] iommu/amd: Remove entry from the list before freeing it
From: Jan Vesely
Signed-off-by: Jan Vesely
---
drivers/iommu/amd_iommu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 634f636..17c76f2 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3288,8 +3288,10 @@ static void amd_iommu_put_dm_regions(struct device *dev,
{
struct iommu_dm_region *entry, *next;
- list_for_each_entry_safe(entry, next, head, list)
+ list_for_each_entry_safe(entry, next, head, list) {
+ list_del(&entry->list);
kfree(entry);
+ }
}
static const struct iommu_ops amd_iommu_ops = {
--
2.5.5
[PATCH 2/2] iommu/amd: Destroy api_lock mutex when freeing domain
From: Jan Vesely Signed-off-by: Jan Vesely --- drivers/iommu/amd_iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index 17c76f2..4ff5e40 100644 --- a/drivers/iommu/amd_iommu.c +++ b/drivers/iommu/amd_iommu.c @@ -3016,6 +3016,7 @@ static void protection_domain_free(struct protection_domain *domain) del_domain_from_list(domain); + mutex_destroy(&domain->api_lock); if (domain->id) domain_id_free(domain->id); -- 2.5.5
Re: [PATCH v2 03/12] of: add J-Core interrupt controller bindings
On Sat, May 21, 2016 at 12:34 AM, Rich Felker wrote:
> On Fri, May 20, 2016 at 10:04:26AM +0200, Geert Uytterhoeven wrote:
>> On Fri, May 20, 2016 at 4:53 AM, Rich Felker wrote:
>> > +Additional properties required for aic1:
>> > +
>> > +- reg : Memory region for configuration.
>> > +
>> > +- cpu-offset : For SMP, the offset to the per-cpu memory region for
>> > + configuration, to be scaled by the cpu number.
>>
>> Does cpu-offset apply to aic1 only?
>
> The current kernel driver doesn't have any reason to _need_ cpu-offset
> for aic2, but since there are registers there that a driver (even a
> non-Linux one) may want to use, I think it makes sense that it should
> be present in the bindings.
Hence the "for aic1" should be dropped?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data
Sasha Levin writes:
> On 05/18/2016 12:05 PM, Greg Kroah-Hartman wrote:
>> On Wed, May 18, 2016 at 11:18:16AM -0400, Sasha Levin wrote:
>>> On 05/18/2016 11:01 AM, Nicolai Stange wrote:
Thanks a million for reporting!
1.) Do you have lockdep enabled?
>>>
>>> Yup, nothing there.
>>>
2.) Does this happen before or after userspace init has been spawned,
i.e. does the lockup happen at debugfs file creation time or
possibly at usage time?
>>>
>>> So I looked closer, and it seems to happen after starting syzkaller, which
>>> as far as I know tries to open many different debugfs files.
>>>
>>> Is there debug code I can add it that'll help us figure out what's up?
>>
>> Trying to figure out _which_ debugfs file is causing this would be
>> great, if at all possible. strace?
>
> What seems to be failing is syzkaller's attempt to mmap the coverage
> debugfs file. So this isn't actually a kernel deadlock but syzkaller
> misbehaves when that scenario happens.
>
> Either way, it only fails to mmap with that commit that I've pointed
> out.
That info is really helpful here: the proxy file_operations introduced by
this commit doesn't have a ->mmap() defined, i.e. it is NULL from the
VFS layer's point of view.
The simple reason is that at the time I submitted this series, my
Coccinelle script didn't find any debugfs user with a ->mmap()
defined. Thus either that script was broken or things have changed in
the meanwhile.
I'll look into this tomorrow.
Thank you very much for the effort you put into this!
>
> th->cover_fd = open("/sys/kernel/debug/kcov", O_RDWR);
> if (th->cover_fd == -1)
> fail("open of /sys/kernel/debug/kcov failed");
> if (ioctl(th->cover_fd, KCOV_INIT_TRACE, kCoverSize))
> fail("cover enable write failed");
> th->cover_data = (uintptr_t*)mmap(NULL, kCoverSize *
> sizeof(th->cover_data[0]), PROT_READ | PROT_WRITE, MAP_SHARED, th->cover_fd,
> 0);
> if ((void*)th->cover_data == MAP_FAILED)
> fail("cover mmap failed");
>
> And it's the mmap() that fails with -ENODEV.
Re: [GIT PULL] Driver core update for 4.7-rc1
On Sat, May 21, 2016 at 10:16 AM, William Breathitt Gray wrote: > > Would you like me to submit a patchset after your commit to introduce > the ISA_BUS/ISA_BUS_API Kconfig options, as well as adjust the relevant > drivers' Kconfig options to depend on the ISA_BUS_API? Yes please. Linus
Re: [GIT PULL] Driver core update for 4.7-rc1
On Sat, May 21, 2016 at 09:59:09AM -0700, Linus Torvalds wrote:
>Author: Linus Torvalds
>Date: Sat May 21 09:13:41 2016 -0700
>
>x86 isa: add back X86_32 dependency on CONFIG_ISA
>
>Commit b3c1be1b789c ("base: isa: Remove X86_32 dependency") made ISA
>support available on x86-64 too. That's not right - while there are
>some LPC-style devices that might be useful still and be based on
>ISA-like IP blocks, that is *not* an excuse to try to enable any random
>legacy drivers.
>
>Such drivers should be individually enabled and made to perhaps depend
>on ISA_DMA_API instead (which we have continued to support on x86-64).
>Or we could add another "ISA_XYZ_API" that we support that doesn't
>enable random old drivers that aren't even 64-bit clean nor do we have
>any test coverage for.
>
>Turning off ISA will now also turn off some drivers that have been
>marked as depending on it as part of this series, and that used to work
>on modern platforms.
>
>See for example commits ad7afc38eab3..cc736607c86d, which may also need
>to be reverted.
>
>Cc: William Breathitt Gray
>Cc: Linus Walleij
>Cc: Guenter Roeck
>Cc: Greg Kroah-Hartman
>Signed-off-by: Linus Torvalds
>
>diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>index 48ac29034e1e..0a7b885964ba 100644
>--- a/arch/x86/Kconfig
>+++ b/arch/x86/Kconfig
>@@ -2447,6 +2447,8 @@ config ISA_DMA_API
> Enables ISA-style DMA support for devices requiring such controllers.
> If unsure, say Y.
>
>+if X86_32
>+
> config ISA
> bool "ISA support"
> ---help---
>@@ -2456,8 +2458,6 @@ config ISA
> (MCA) or VESA. ISA is an older system, now being displaced by PCI;
> newer boards don't support it. If you have ISA, say Y, otherwise N.
>
>-if X86_32
>-
> config EISA
> bool "EISA support"
> depends on ISA
Acked-by: William Breathitt Gray
That makes sense to me. The drivers which switched to use the ISA bus
driver would simply need their respective Kconfig option adjusted to
depend on a "ISA_BUS_API" option, rather than ISA, to allow them to
compile on X86_64.
Would you like me to submit a patchset after your commit to introduce
the ISA_BUS/ISA_BUS_API Kconfig options, as well as adjust the relevant
drivers' Kconfig options to depend on the ISA_BUS_API?
William Breathitt Gray
Re: sem_lock() vs qspinlocks
On Sat, 21 May 2016, Peter Zijlstra wrote: On Fri, May 20, 2016 at 05:48:39PM -0700, Davidlohr Bueso wrote: On Fri, 20 May 2016, Linus Torvalds wrote: >Oh, I definitely agree on the stable part, and yes, the "splt things >up" model should come later if people agree that it's a good thing. The backporting part is quite nice, yes, but ultimately I think I prefer Linus' suggestion making things explicit, as opposed to consulting the spinlock implying barriers. I also hate to have an smp_mb() (particularly for spin_is_locked) given that we are not optimizing for the common case (regular mutual excl). I'm confused; we _are_ optimizing for the common case. spin_is_locked() is very unlikely to be used. And arguably should be used less in favour of lockdep_assert_held(). Indeed we are. But by 'common case' I was really thinking about spin_is_locked() vs spin_wait_unlock(). The former being the more common of the two, and the one which mostly will _not_ be used for lock correctness purposes, hence it doesn't need that new smp_mb. Hence allowing users to explicitly set the ordering needs (ie spin_lock_synchronize()) seems like the better long term alternative. otoh, with your approach all such bugs are automatically fixed :) Thanks, Davidlohr
Re: [PATCH v2 1/6] power: Introduce Broadcom kona reset driver
Le 11/05/2016 14:36, Chris Brand a écrit : > This driver supports reset on both BCM21664 and BCM23550. > Code is being moved from arch/arm/mach-bcm/board_bcm21664.c > > Signed-off-by: Chris Brand Sebastian, Dmitry, I know we are in the merge window, let me know if you would want me to take this patch and the 5 others in the next arm-soc pull request, or if you prefer to take this one in your own tree. Thanks! -- Florian
Re: [GIT PULL] Driver core update for 4.7-rc1
On Sat, May 21, 2016 at 9:31 AM, Linus Torvalds
wrote:
>
> We're not suddenly enabling ISA on x86-64 after having successfully
> gotten rid of that insane crap long long ago.
>
> If you have *specific* dribvers that are actually relevant for some
> reason, make those ones available based on other options. For example,
> we've had the ISA_DMA_API config option to say "we support a subset of
> ISA, even when we don't actually want to ever see actual plug-in ISA
> cards".
I am planning on committing something like the attached.
Note that anything that added "depends on ISA" because of the other
patches will now be disabled on x86-64, even if that driver wasn't
disabled before.
Added Linus Walleij and Guenther Roech to the cc because of the
drivers that I'm aware that did this.
To repeat: I'm not at all interested in enabling random old drivers on
x86-64. Any driver enablement needs to be done on a one-by-one basis,
after having actually gotten TESTING, and after having had people make
sure that we don't get tons of new warnings like we did with the
"let's just enable ISA randomly" approach.
I'm ok with enabling some "ISA_BUS_API" support (like we have
ISA_DMA_API) that allows people to enable drivers one-by-one as they
are converted to a convenience function. The patch series seems to
have had that kind of approach initially.
I'd suggest doing that ISA_BUS_API config option as a *general* thing
(not arch-specific), and make it start out like
config ISA_BUS_API
def_bool ISA
which means that everybody gets it, and if ISA was enabled, it will be
enabled automatically. Then, architectures that do *not* enable ISA
itself (like x86-64), could choose to have a config option like
config ISA_BUS
bool "support ISA-style drivers on modern systems" if (x86 && EXPERT)
default y
select ISA_BUS_API
or something, which means that ISA_BUS_API would then get enabled (but
not ISA itself).
That's similar to what we do today with ISA_DMA_API, except we made
the mistake of making all the different architectures define the
ISA_DMA_API option.
It's the wholesale "enable random crap" that I will not accept. Not
even if there is then "hide the crap again when it causes warnings".
Even a driver that doesn't warn isn't necessarily useful, and I don't
want people to suddenly start seeing a lot of options for random ISA
drivers that simply aren't relevant, and never will be. Not even if
they compile cleanly.
Linus
Author: Linus Torvalds
Date: Sat May 21 09:13:41 2016 -0700
x86 isa: add back X86_32 dependency on CONFIG_ISA
Commit b3c1be1b789c ("base: isa: Remove X86_32 dependency") made ISA
support available on x86-64 too. That's not right - while there are
some LPC-style devices that might be useful still and be based on
ISA-like IP blocks, that is *not* an excuse to try to enable any random
legacy drivers.
Such drivers should be individually enabled and made to perhaps depend
on ISA_DMA_API instead (which we have continued to support on x86-64).
Or we could add another "ISA_XYZ_API" that we support that doesn't
enable random old drivers that aren't even 64-bit clean nor do we have
any test coverage for.
Turning off ISA will now also turn off some drivers that have been
marked as depending on it as part of this series, and that used to work
on modern platforms.
See for example commits ad7afc38eab3..cc736607c86d, which may also need
to be reverted.
Cc: William Breathitt Gray
Cc: Linus Walleij
Cc: Guenter Roeck
Cc: Greg Kroah-Hartman
Signed-off-by: Linus Torvalds
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 48ac29034e1e..0a7b885964ba 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2447,6 +2447,8 @@ config ISA_DMA_API
Enables ISA-style DMA support for devices requiring such controllers.
If unsure, say Y.
+if X86_32
+
config ISA
bool "ISA support"
---help---
@@ -2456,8 +2458,6 @@ config ISA
(MCA) or VESA. ISA is an older system, now being displaced by PCI;
newer boards don't support it. If you have ISA, say Y, otherwise N.
-if X86_32
-
config EISA
bool "EISA support"
depends on ISA
Re: [PATCH] spi: spidev: fix possible arithmetic overflow for multi-transfer message
On Mon, Mar 23, 2015 at 10:50 AM, Ian Abbott wrote:
> `spidev_message()` sums the lengths of the individual SPI transfers to
> determine the overall SPI message length. It restricts the total
> length, returning an error if too long, but it does not check for
> arithmetic overflow. For example, if the SPI message consisted of two
> transfers and the first has a length of 10 and the second has a length
> of (__u32)(-1), the total length would be seen as 9, even though the
> second transfer is actually very long. If the second transfer specifies
> a null `rx_buf` and a non-null `tx_buf`, the `copy_from_user()` could
> overrun the spidev's pre-allocated tx buffer before it reaches an
> invalid user memory address. Fix it by checking that neither the total
> nor the individual transfer lengths exceed the maximum allowed value.
>
> Thanks to Dan Carpenter for reporting the potential integer overflow.
>
> Signed-off-by: Ian Abbott
> Cc: # 4.0+
> ---
> This could be backported to kernels prior to 4.0, but the total and
> individual lengths would need to be checked against `bufsiz` instead of
> `INT_MAX`.
> ---
> drivers/spi/spidev.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
> index bb6b3ab..23ad978 100644
> --- a/drivers/spi/spidev.c
> +++ b/drivers/spi/spidev.c
> @@ -249,9 +249,10 @@ static int spidev_message(struct spidev_data *spidev,
> total += k_tmp->len;
> /* Since the function returns the total length of transfers
> * on success, restrict the total to positive int values to
> -* avoid the return value looking like an error.
> +* avoid the return value looking like an error. Also check
> +* each transfer length to avoid arithmetic overflow.
> */
> - if (total > INT_MAX) {
> + if (total > INT_MAX || k_tmp->len > INT_MAX) {
What if total is INT_MAX - 2 and k_tmp->len is 3? What about total is
INT_MAX and k_tmp->len is INT_MAX as well? I think the proper check
should be:
if (total < k_tmp->len || total > INT_MAX) {
...
}
> status = -EMSGSIZE;
> goto done;
> }
Thanks.
--
Dmitry
Re: PROBLEM: Resume form hibernate broken by setting NX on gap
On Fri, May 20, 2016 at 6:57 PM, Logan Gunthorpe wrote: > On 20/05/16 04:16 PM, Kees Cook wrote: >> >> On Fri, May 20, 2016 at 2:59 PM, Kees Cook wrote: >>> >>> On Fri, May 20, 2016 at 2:46 PM, Rafael J. Wysocki >>> wrote: On Fri, May 20, 2016 at 3:56 PM, Stephen Smalley wrote: > > On 05/20/2016 07:34 AM, Rafael J. Wysocki wrote: >> >> On Fri, May 20, 2016 at 9:15 AM, Ingo Molnar wrote: >>> >>> >>> * Logan Gunthorpe wrote: >>> Hi, I have been working on a bug that causes my laptop to freeze during resume from hibernation. I did a bisect to find the offending commit: [ab76f7b4ab] x86/mm: Set NX on gap between __ex_table and rodata There is more information in the bugzilla report [1] that I've been working on but I will summarize things below. I've experienced intermittent but reproducible freezes when resuming from hibernation since about kernel version 3.19. The freeze was significantly more reproducible when a few applications were loaded before hibernation and would largely not happen if hibernated immediately after booting to a desktop. I did some tracing work to find that the kernel gets as far as the resume_image call in swsusp_arch_resume and I could not find any response from the image kernel when I hit the bug. I also did testing that seemed to rule out this being caused by a problematic driver. I did a successful bisect between 3.18 and 3.19 which found a bug in commit f5b2831d6 that was then later fixed by commit 55696b1f66 in 4.4. Then, I did a second bisect with a ported version of the fix to the first bug and found commit ab76f7b4ab in 4.3 to also break hibernation with what appears to be the exact same symptoms. Reverting that commit in recent kernels up to and including 4.6 fixes the issue and restores reliable hibernation. However, it's not at all clear to me why that commit would cause this issue or how to fix the issue without reverting. >>> >>> >>> I've attached that commit below and also Cc:-ed a few more people who >>> might have >>> an idea about why this regressed. Worst-case we'll have to revert it. >> >> >> Without looking deep into mm, my theory would be that after this patch >> the final jump from the boot kernel to the image kernel's trampoline >> code during resume may crash the kernel if the trampoline page turns >> out to be NX in the boot kernel (it has to be executable in both the >> boot and the image kernels). > > > So, pardon my ignorance, but where is this trampoline page placed in > kernel memory? On 32-bit its location has to be the same in both the boot and the image kernels and that's within kernel text in both cases, so that shouldn't be a problem. On 64-bit its location depends on the image kernel and specifically on the location of the restore_registers routine in it. The (virtual) address of that routine is stored in the restore_jump_address variable, so the page containing it (the trampoline page) can be found with the help of that. swsusp_arch_resume() sets up a temporary kernel mapping to finalize the image restoration and that page must not be NX in that mapping for things to work. >>> >>> >>> It looks like nothing in the swsusp_arch_resume() -> get_safe_page() >>> -> get_image_page() path sets the page executable... >>> >>> Untested, but I wonder if this work work in swsusp_arch_resume() >>> before the memcpy? >> >> >> I can't type today, it seems. It should read "... if this would work ..." >> >> If you can test this and it works for you, I'll send a proper patch... :P >> >> -Kees >> > > Hi Kees, > > Thanks. I tried the patch but it only resulted in a kernel warning and > freeze. I've attached a photo showing as much of the messages as I could > get. > > Logan Ah, dang, ok, thanks for trying it. I'll let Rafael try to figure this one out. -Kees -- Kees Cook Chrome OS & Brillo Security
Re: [RFT PATCH] iio: magn: Add support for BMM150 magnetometer
On 18/05/16 15:01, Daniel Baluta wrote: > On Wed, May 4, 2016 at 1:26 PM, Jonathan Cameron wrote: >> On 27/04/16 15:55, Lucas De Marchi wrote: >>> On Tue, Apr 26, 2016 at 9:39 AM, Daniel Baluta >>> wrote: BMM150 is register compatible with magnetometer part of BMC156. Datasheet is at: http://www.mouser.com/ds/2/783/BST-BMM150-DS001-01-786480.pdf Signed-off-by: Daniel Baluta --- Lucas let me know if it works for you. I don't have yet the BMM150 evaluation board. It should be available in few weeks. I'll just leave this patch here in case anyone steps in to test it. >>> >>> It will take a while for my test board to arrive here, so expect delay >>> on testing this. >> I'm dropping this from my list of outstanding patches for now. >> It'll resurface when you guys restart the thread. > > Got the shuttle board and basic tests with generic_buffer seem to work fine. > > Jonathan can you pick this up if no other comments? Done. It might be worth a follow up to list the supported parts in the Kconfig description. Given they aren't listed already, I'm not going to add this one on it's own and it would make little sense to add them all in this patch. > > thanks, > Daniel. >
Re: [GIT PULL] Driver core update for 4.7-rc1
On Sat, May 21, 2016 at 9:20 AM, William Breathitt Gray wrote: > > I'll submit patches to resolve these warnings and errors. No. I will disable that ISA config option. We're not randomly making old drivers available on modern platforms. Really. We're not suddenly enabling ISA on x86-64 after having successfully gotten rid of that insane crap long long ago. If you have *specific* dribvers that are actually relevant for some reason, make those ones available based on other options. For example, we've had the ISA_DMA_API config option to say "we support a subset of ISA, even when we don't actually want to ever see actual plug-in ISA cards". Your patch already resulted in having to add several cases of - depends on ISA + depends on X86 && ISA because you tried to randomly widen what "ISA" meant. No. No no no. No more "let's randomly change what ISA is". Do this enabling one driver at a time, or not at all. I'm not at all interested in seeing some kind of generic "we will support random shit on modern platfoms" crap. 99% of all drivers that depend on ISA have no maintainership, and will never get any maintainership. Linus
Re: [PATCH 2/2] iio: generic_buffer: Add --device-num option
On 20/05/16 16:45, Crestez Dan Leonard wrote:
> This makes it possible to distinguish between iio devices with the same
> name.
>
> Signed-off-by: Crestez Dan Leonard
happy with this and will pickup once the first patch is sorted.
Jonathan
> ---
> tools/iio/generic_buffer.c | 53
> ++
> 1 file changed, 40 insertions(+), 13 deletions(-)
>
> diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
> index e7bf477..f805ef9 100644
> --- a/tools/iio/generic_buffer.c
> +++ b/tools/iio/generic_buffer.c
> @@ -251,7 +251,9 @@ void print_usage(void)
> " -e Disable wait for event (new data)\n"
> " -g Use trigger-less mode\n"
> " -l Set buffer length to n samples\n"
> - " -n Set device name (mandatory)\n"
> + " --device-name -n \n"
> + " --device-num -N \n"
> + "Set device by name or number"
> " -t Set trigger name\n"
> " -w Set delay between reads in us (event-less
> mode)\n");
> }
> @@ -319,6 +321,12 @@ void register_cleanup(void)
> }
> }
>
> +static const struct option longopts[] = {
> + { "device-name",1, 0, 'n' },
> + { "device-num", 1, 0, 'N' },
> + { },
> +};
> +
> int main(int argc, char **argv)
> {
> unsigned long num_loops = 2;
> @@ -333,7 +341,7 @@ int main(int argc, char **argv)
>
> char *data;
> ssize_t read_size;
> - int dev_num, trig_num;
> + int dev_num = -1, trig_num;
> char *buffer_access;
> int scan_size;
> int noevents = 0;
> @@ -344,7 +352,7 @@ int main(int argc, char **argv)
>
> register_cleanup();
>
> - while ((c = getopt(argc, argv, "ac:egl:n:t:w:")) != -1) {
> + while ((c = getopt_long(argc, argv, "ac:egl:n:N:t:w:", longopts, NULL))
> != -1) {
> switch (c) {
> case 'a':
> autochannels = AUTOCHANNELS_ENABLED;
> @@ -372,6 +380,12 @@ int main(int argc, char **argv)
> case 'n':
> device_name = optarg;
> break;
> + case 'N':
> + errno = 0;
> + dev_num = strtoul(optarg, &dummy, 10);
> + if (errno)
> + return -errno;
> + break;
> case 't':
> trigger_name = optarg;
> break;
> @@ -387,24 +401,37 @@ int main(int argc, char **argv)
> }
> }
>
> - if (!device_name) {
> - fprintf(stderr, "Device name not set\n");
> + /* Find the device requested */
> + if (dev_num < 0 && !device_name) {
> + fprintf(stderr, "Device not set\n");
> print_usage();
> return -1;
> + } else if (dev_num >= 0 && device_name) {
> + fprintf(stderr, "Only one of --device-num or --device-name
> needs to be set\n");
> + print_usage();
> + return -1;
> + } else if (dev_num < 0) {
> + dev_num = find_type_by_name(device_name, "iio:device");
> + if (dev_num < 0) {
> + fprintf(stderr, "Failed to find the %s\n", device_name);
> + return dev_num;
> + }
> }
> -
> - /* Find the device requested */
> - dev_num = find_type_by_name(device_name, "iio:device");
> - if (dev_num < 0) {
> - fprintf(stderr, "Failed to find the %s\n", device_name);
> - return dev_num;
> - }
> -
> printf("iio device number being used is %d\n", dev_num);
>
> ret = asprintf(&dev_dir_name, "%siio:device%d", iio_dir, dev_num);
> if (ret < 0)
> return -ENOMEM;
> + if (!device_name) {
> + device_name = malloc(IIO_MAX_NAME_LENGTH);
> + if (!device_name)
> + return -ENOMEM;
> + ret = read_sysfs_string("name", dev_dir_name, device_name);
> + if (ret < 0) {
> + fprintf(stderr, "Failed to read name of device %d\n",
> dev_num);
> + return ret;
> + }
> + }
>
> if (!notrigger) {
> if (!trigger_name) {
>
Re: [PATCH 1/2] iio: generic_buffer: Cleanup when receiving signals
On 20/05/16 16:55, Peter Meerwald-Stadler wrote:
>
>> This also drops all the code freeing string buffers at the end of main.
>> Memory is freed when the process exits anyway so there's no point in
>> cluttering the code with all those gotos.
>
> well, it helps to see that all memory has been released when looking for
> leaks :)
> e.g. valgrind becomes much less useful when the program exits with tons of
> memory still allocated
Beyond that we are looking at code here that will get cut and paste into other
peoples applications - they might not pick up that it doesn't clean up properly
after itself.
I'd much prefer to keep these explicit frees in place.
Jonathan
>
> functions and global variables could be static
>
>> ---
>> tools/iio/generic_buffer.c | 162
>> -
>> 1 file changed, 88 insertions(+), 74 deletions(-)
>>
>> diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
>> index 2429c78..e7bf477 100644
>> --- a/tools/iio/generic_buffer.c
>> +++ b/tools/iio/generic_buffer.c
>> @@ -32,6 +32,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include "iio_utils.h"
>>
>> /**
>> @@ -254,6 +256,69 @@ void print_usage(void)
>> " -w Set delay between reads in us (event-less
>> mode)\n");
>> }
>>
>> +enum autochan autochannels = AUTOCHANNELS_DISABLED;
>> +char *dev_dir_name = NULL;
>> +char *buf_dir_name = NULL;
>> +bool current_trigger_set = false;
>> +
>> +void cleanup(void)
>> +{
>> +int ret;
>> +
>> +fprintf(stderr, "Cleanup\n");
>> +
>> +/* Disable trigger */
>> +if (dev_dir_name && current_trigger_set) {
>> +/* Disconnect the trigger - just write a dummy name. */
>> +ret = write_sysfs_string("trigger/current_trigger",
>> + dev_dir_name, "NULL");
>> +if (ret < 0)
>> +fprintf(stderr, "Failed to disable trigger: %s\n",
>> +strerror(-ret));
>> +}
>> +
>> +/* Disable buffer */
>> +if (buf_dir_name) {
>> +ret = write_sysfs_int("enable", buf_dir_name, 0);
>> +if (ret < 0)
>> +fprintf(stderr, "Failed to disable buffer: %s\n",
>> +strerror(-ret));
>> +}
>> +
>> +/* Disable channels if auto-enabled */
>> +if (dev_dir_name && autochannels == AUTOCHANNELS_ACTIVE) {
>> +ret = enable_disable_all_channels(dev_dir_name, 0);
>> +if (ret)
>> +fprintf(stderr, "Failed to disable all channels\n");
>> +}
>> +}
>> +
>> +void sig_handler(int signum)
>> +{
>> +fprintf(stderr, "Caught signal %d\n", signum);
>> +exit(-signum);
>> +}
>> +
>> +void register_cleanup(void)
>> +{
>> +struct sigaction sa = { .sa_handler = sig_handler };
>> +const int signums[] = { SIGINT, SIGTERM, SIGABRT };
>> +int ret, i;
>> +
>> +ret = atexit(cleanup);
>> +if (ret) {
>> +perror("Failed to register atexit");
>> +exit(-1);
>> +}
>> +for (i = 0; i < ARRAY_SIZE(signums); ++i) {
>> +ret = sigaction(signums[i], &sa, NULL);
>> +if (ret) {
>> +perror("Failed to register signal handler");
>> +exit(-1);
>> +}
>> +}
>> +}
>> +
>> int main(int argc, char **argv)
>> {
>> unsigned long num_loops = 2;
>> @@ -265,9 +330,7 @@ int main(int argc, char **argv)
>>
>> int num_channels;
>> char *trigger_name = NULL, *device_name = NULL;
>> -char *dev_dir_name, *buf_dir_name;
>>
>> -int datardytrigger = 1;
>> char *data;
>> ssize_t read_size;
>> int dev_num, trig_num;
>> @@ -275,11 +338,12 @@ int main(int argc, char **argv)
>> int scan_size;
>> int noevents = 0;
>> int notrigger = 0;
>> -enum autochan autochannels = AUTOCHANNELS_DISABLED;
>> char *dummy;
>>
>> struct iio_channel_info *channels;
>>
>> +register_cleanup();
>> +
>> while ((c = getopt(argc, argv, "ac:egl:n:t:w:")) != -1) {
>> switch (c) {
>> case 'a':
>> @@ -310,7 +374,6 @@ int main(int argc, char **argv)
>> break;
>> case 't':
>> trigger_name = optarg;
>> -datardytrigger = 0;
>> break;
>> case 'w':
>> errno = 0;
>> @@ -352,10 +415,8 @@ int main(int argc, char **argv)
>> */
>> ret = asprintf(&trigger_name,
>> "%s-dev%d", device_name, dev_num);
>> -if (ret < 0) {
>> -ret = -ENOMEM;
>> -goto error_free_dev_dir_name;
>> -}
>> +if (ret < 0)
>> +return -ENOMEM;
>> }
>>
>> /* Look for this "-devN" trigge
Re: [PATCH] iio: humidity: hdc100x: add HDC1000 and HDC1008 product names
On 20/05/16 18:34, Matt Ranostay wrote:
> On Fri, May 20, 2016 at 10:05 AM, Alison Schofield
> wrote:
>> hdc100x supports Texas Instruments HDC1000 and HDC1008 relative
>> humidity and temperature sensors. Add these product names to
>> Kconfig and to the drivers device id structure to enable finding
>> the product by name and using it to add a device.
>>
>> Signed-off-by: Alison Schofield
>> Cc: Daniel Baluta
>> ---
>> drivers/iio/humidity/Kconfig | 8
>> drivers/iio/humidity/hdc100x.c | 2 ++
>> 2 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/iio/humidity/Kconfig b/drivers/iio/humidity/Kconfig
>> index 738a86d..f155386 100644
>> --- a/drivers/iio/humidity/Kconfig
>> +++ b/drivers/iio/humidity/Kconfig
>> @@ -26,11 +26,11 @@ config HDC100X
>> tristate "TI HDC100x relative humidity and temperature sensor"
>> depends on I2C
>> help
>> -Say yes here to build support for the TI HDC100x series of
>> -relative humidity and temperature sensors.
>> + Say yes here to build support for the Texas Instruments
>> + HDC1000 and HDC1008 relative humidity and temperature sensors.
>>
>> -To compile this driver as a module, choose M here: the module
>> -will be called hdc100x.
>> + To compile this driver as a module, choose M here: the module
>> + will be called hdc100x.
>>
>> config HTU21
>> tristate "Measurement Specialties HTU21 humidity & temperature
>> sensor"
>> diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
>> index fa47676..0deb874 100644
>> --- a/drivers/iio/humidity/hdc100x.c
>> +++ b/drivers/iio/humidity/hdc100x.c
>> @@ -302,6 +302,8 @@ static int hdc100x_probe(struct i2c_client *client,
>>
>> static const struct i2c_device_id hdc100x_id[] = {
>> { "hdc100x", 0 },
>> + { "hdc1000", 0 },
>> + { "hdc1008", 0 },
>
> Personally I think adding more device ids that don't add any per chip
> configuration is just adding clutter.
> There is a reason I used "hdc100x" when I wrote the driver :)
Hmm. I should have picked up on this in the first place. It's much preferred to
go with complete part names. Avoids any possible issues with devicetrees / ACPI
bindings where it's kind of assumed a whole part name will be used.
I'd prefer to have them explicitly listed. We will have to keep the wild card
form as well as by now there will be boards using that out there.
If it was just internal to the kernel I'd agree with the clutter argument, but
it isn't so let us be as explicit in the naming as possible.
Jonathan
>
>
>> { }
>> };
>> MODULE_DEVICE_TABLE(i2c, hdc100x_id);
>> --
>> 2.1.4
>>
Re: [PATCH] iio: humidity: hdc100x: correct humidity integration time mask
On 20/05/16 18:44, Matt Ranostay wrote:
> Reviewed-by: Matt Ranostay
>
> On Fri, May 20, 2016 at 10:06 AM, Alison Schofield
> wrote:
>> Apply the correct mask to enable all available humidity integration
>> times. Currently, the driver defaults to 6500 and all is okay with that.
>> However, if 3850 is selected we get a stuck bit and can't change back
>> to 6500 or select 2500. (Verified with HDC1008)
>>
>> Signed-off-by: Alison Schofield
>> Cc: Daniel Baluta
Applied to the fixes-togreg-post-rc1 branch of iio.git
Thanks,
Jonathan
>> ---
>> drivers/iio/humidity/hdc100x.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
>> index fa47676..59aa1cb 100644
>> --- a/drivers/iio/humidity/hdc100x.c
>> +++ b/drivers/iio/humidity/hdc100x.c
>> @@ -55,7 +55,7 @@ static const struct {
>> },
>> { /* IIO_HUMIDITYRELATIVE channel */
>> .shift = 8,
>> - .mask = 2,
>> + .mask = 3,
>
> Yikes that is embarrassing on my part! I guess our validation was only
> in the high resolution mode... good catch!
>
>> },
>> };
>>
>> --
>> 2.1.4
>>
Re: [GIT PULL] Driver core update for 4.7-rc1
On Fri, May 20, 2016 at 10:04:38PM -0700, Greg KH wrote: >On Fri, May 20, 2016 at 09:51:18PM -0700, Linus Torvalds wrote: >> On Fri, May 20, 2016 at 8:23 PM, Greg KH wrote: >> > >> > William Breathitt Gray (13): >> > base: isa: Remove X86_32 dependency >> > isa: Decouple X86_32 dependency from the ISA Kconfig option >> >> So I'm going to revert these unless I get >> >> (a) a good reason for them >> >> (b) patches to get rid of the incessant warnings these cause. > >What warnings? I haven't seen any reports of warnings, what .config >causes them? > >> Most of the ISA drivers are not 64-bit safe. They give compiler >> warnings, and they will definitely simply not work. So just blindly >> enabling that shit is not the answer. >> >> We've never needed this before, why do we need it now? > >I'll let William answer that, it seems he has some crazy isa hardware >for x86_64 platforms... > >thanks, > >greg k-h I'll submit patches to resolve these warnings and errors. The primary reason for decoupling the x86_32 dependency from the X86 ISA Kconfig option is to allow the ISA bus driver to be used to interface with PC/104 devices. Although you are correct that the ISA bus for general consumers is essentially legacy from the pre-64-bit era, the PC/104 bus (a derivative of the ISA bus) is ubiquitous in the embedded systems industry; new PC/104 devices are developed and produced every day. Despite the form factor difference, PC/104 devices appear to software as ISA devices: you can interact with them like you would any other ISA device, using I/O port-mapped reads and writes. This makes the existing ISA bus driver an apt solution to interface with PC/104 devices (to software, there is no difference between PC/104 and ISA). The issue arises with the X86_32 dependency on the X86 ISA Kconfig option: this dependency is not necessary because there is no hard 32-bit dependency on the ISA bus itself; in fact, the ISA bus driver (drivers/base/isa.c) is portable across all X86 platforms. Worse, the X86_32 dependency puts an artifical limitation on PC/104 devices. Many embedded systems vendors produce PC/104 compatible motherboards running 64-bit X86 processors; this isn't the exception, it's the norm. To use the ISA bus driver with the X86_32 dependency means preventing support for PC/104 devices on virtually any modern PC/104 compatible embedded system motherboard. There are real PC/104 devices out there, from real companies and people, intended to run on real motherboards with 64-bit X86 processors. I'm in the process of developing drivers for a few new PC/104 devices. For reference, there are currently four PC/104 drivers already merged: the Apex Embedded Systems STX104 DAC driver, the ACCES 104-DIO-48E series GPIO driver, the ACCES 104-IDI-48 series GPIO driver, and the ACCES 104-IDIO-16 series GPIO driver. Although not necessarily PC/104 devices, the WinSystems EBC-C384 watchdog timer driver and WinSystems WS16C48 GPIO driver communicate via an ISA bus interface and are also expected to run on motherboards with 64-bit X86 processors. One alternative to decoupling the X86_32 dependency from the ISA Kconfig option would be to copy the drivers/base/isa.c code to a new drivers/base/pc104.c file, which will serve as the PC/104 bus driver; new PC/104 drivers intended to run on any X86 platform can use this new bus driver. However, it doesn't seem right to maintain an identical set of code simply to sidestep a Kconfig dependency issue. Removing the X86_32 dependency from the X86 ISA Kconfig option results in warnings and errors for two reasons: 1. The relevant code is meant to be 32-bit X86 specific. - In this case, an explicit X86_32 should be added to the Kconfig option for the relevant code. 2. The relevant code is meant to work on both 32-bit and 64-bit X86 platforms, but a 32-bit specific piece of code was overlooked. - In this case, the code should be fixed to be portable across X86 platforms as intended. Regardless, in both scenarios, adding an explicit X86_32 dependency to the relevant Kconfig options resolves the warnings and errors by limiting the compilation to X86_32 as they have been before; thus the status quo is maintained. However, a major benefit is gained: the ISA bus driver may now be used to support these new PC/104 devices expected to run with 64-bit X86 processors. Regarding the excerpt of warnings already posted: the Kconfig for the IDE chipsets has an X86 dependency which should explicitly be X86_32, while the 3C515 and NI65 drivers' Kconfig dependencies should also be adjusted since neither use the X86 ISA bus driver. As I said before, it is my intention to submit patches to resolve the warnings and errors which have appeared; they are currently there simply because I mistakenly overlooked them when I performed my initial testing. I've logged the warnings and errors after compiling from an allmodconfig, with and without the t
[PATCH] kcov: add AFL-style tracing
From: Quentin Casasnovas
AFL uses a fixed-size buffer (typically 64 KiB) where each byte is
a counter representing how many times an A -> B branch was taken.
Of course, since the buffer is fixed size, it's a little imprecise
in that e.g. two different branches could map to the same counter,
but in practice it works well.
See afl:docs/technical_details.txt for more information.
Here is a small test program that demonstrates the new capability:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
#define KCOV_INIT_AFL _IOR('c', 2, unsigned long)
#define KCOV_ENABLE _IO('c', 100)
#define KCOV_DISABLE_IO('c', 101)
int main(int argc, char *argv[])
{
int fd = open("/sys/kernel/debug/kcov", O_RDWR);
if (fd == -1)
error(1, errno, "open()");
unsigned long size = 1 << 10;
if (ioctl(fd, KCOV_INIT_AFL, size) != 0)
error(1, errno, "ioctl(KCOV_INIT_AFL)");
void *mem = mmap(NULL, size * sizeof(long), PROT_READ |
PROT_WRITE, MAP_SHARED, fd, 0);
if (mem == MAP_FAILED)
error(1, errno, "mmap()");
/* Start kernel instrumentation */
if (ioctl(fd, KCOV_ENABLE, 0) != 0)
error(1, errno, "ioctl(KCOV_ENABLE)");
printf("Hello world!\n");
/* End kernel instrumentation*/
if (ioctl(fd, KCOV_DISABLE, 0) != 0)
error(1, errno, "ioctl(KCOV_DISABLE)");
/* Hex dump of memory area */
unsigned char *mem2 = mem;
for (unsigned int i = 0; i < size; ++i) {
printf("%02x ", mem2[i]);
if (i % 32 == 31)
printf("\n");
}
close(fd);
return 0;
}
This patch is a collaboration between Quentin Casasnovas and Vegard Nossum.
Cc: Dmitry Vyukov
Cc: Michal Zalewski
Cc: Kees Cook
Signed-off-by: Quentin Casasnovas
Signed-off-by: Vegard Nossum
---
include/linux/kcov.h | 6 ++
include/uapi/linux/kcov.h | 1 +
kernel/kcov.c | 44
3 files changed, 51 insertions(+)
diff --git a/include/linux/kcov.h b/include/linux/kcov.h
index 2883ac9..cb8eb3e 100644
--- a/include/linux/kcov.h
+++ b/include/linux/kcov.h
@@ -18,6 +18,12 @@ enum kcov_mode {
* Covered PCs are collected in a per-task buffer.
*/
KCOV_MODE_TRACE = 1,
+ /*
+* AFL-style collection.
+* Covered branches are hashed and collected in a fixed size buffer
+* (see AFL documentation for more information).
+*/
+ KCOV_MODE_AFL = 2,
};
#else
diff --git a/include/uapi/linux/kcov.h b/include/uapi/linux/kcov.h
index 574e22e..0dc1cf9 100644
--- a/include/uapi/linux/kcov.h
+++ b/include/uapi/linux/kcov.h
@@ -4,6 +4,7 @@
#include
#define KCOV_INIT_TRACE_IOR('c', 1, unsigned long)
+#define KCOV_INIT_AFL _IOR('c', 2, unsigned long)
#define KCOV_ENABLE_IO('c', 100)
#define KCOV_DISABLE _IO('c', 101)
diff --git a/kernel/kcov.c b/kernel/kcov.c
index a02f2dd..e6eb785 100644
--- a/kernel/kcov.c
+++ b/kernel/kcov.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -34,6 +35,19 @@ struct kcov {
enum kcov_mode mode;
/* Size of arena (in long's for KCOV_MODE_TRACE). */
unsignedsize;
+
+ union {
+ /* For KCOV_MODE_AFL */
+ struct {
+ /* (number of bytes) - 1, where number of
+* bytes must be a power of 2. */
+ unsigned intmask;
+
+ /* Previous PC (for KCOV_MODE_AFL). */
+ unsigned intprev_location;
+ };
+ };
+
/* Coverage buffer shared with user space. */
void*area;
/* Task for which we collect coverage, or NULL. */
@@ -76,6 +90,19 @@ void notrace __sanitizer_cov_trace_pc(void)
area[pos] = _RET_IP_;
WRITE_ONCE(area[0], pos);
}
+ } else if (mode == KCOV_MODE_AFL) {
+ struct kcov *kcov;
+ unsigned char *area;
+ unsigned long location = _RET_IP_;
+
+ /* See above */
+ barrier();
+
+ kcov = t->kcov;
+ area = kcov->area;
+
+ ++
[PATCH 1/4] x86: Save return value from kernel_thread
Kernel threads should always return zero on success after calling do_execve(). The two existing cases in the kernel (kernel_init() and call_usermodehelper_exec_async()) correctly do this. Save a few bytes by storing EAX/RAX instead of an immediate zero. Also fix the 64-bit case which should save the full 64-bits. Signed-off-by: Brian Gerst --- arch/x86/entry/entry_32.S | 2 +- arch/x86/entry/entry_64.S | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index 983e5d3..ee6fea0 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -221,7 +221,7 @@ ENTRY(ret_from_kernel_thread) popl%eax movlPT_EBP(%esp), %eax call*PT_EBX(%esp) - movl$0, PT_EAX(%esp) + movl%eax, PT_EAX(%esp) /* * Kernel threads return to userspace as if returning from a syscall. diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 9ee0da1..ab9f8c8 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -387,7 +387,7 @@ ENTRY(ret_from_fork) */ movqRBP(%rsp), %rdi call*RBX(%rsp) - movl$0, RAX(%rsp) + movq%rax, RAX(%rsp) /* * Fall through as though we're exiting a syscall. This makes a -- 2.5.5
[PATCH 3/4] x86: Rewrite switch_to() code
Move the low-level context switch code to an out-of-line asm stub instead of
using complex inline asm. This allows constructing a new stack frame for the
child process to make it seamlessly flow to ret_from_fork without an extra
test and branch in __switch_to(). It also improves code generation for
__schedule() by using the C calling convention instead of clobbering all
registers.
Signed-off-by: Brian Gerst
---
arch/x86/entry/entry_32.S | 38 ++
arch/x86/entry/entry_64.S | 42 +++-
arch/x86/include/asm/processor.h | 3 -
arch/x86/include/asm/switch_to.h | 137 ++---
arch/x86/include/asm/thread_info.h | 2 -
arch/x86/kernel/asm-offsets.c | 6 ++
arch/x86/kernel/asm-offsets_32.c | 5 ++
arch/x86/kernel/asm-offsets_64.c | 5 ++
arch/x86/kernel/process_32.c | 8 ++-
arch/x86/kernel/process_64.c | 7 +-
arch/x86/kernel/smpboot.c | 1 -
11 files changed, 124 insertions(+), 130 deletions(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index ee6fea0..05e5340 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -204,6 +204,44 @@
POP_GS_EX
.endm
+/*
+ * %eax: prev task
+ * %edx: next task
+ */
+ENTRY(__switch_to_asm)
+ /*
+* Save callee-saved registers
+* This must match the order in struct fork_frame
+* Frame pointer must be last for get_wchan
+*/
+ pushl %ebx
+ pushl %edi
+ pushl %esi
+ pushl %ebp
+
+ /* switch stack */
+ movl%esp, TASK_threadsp(%eax)
+ movlTASK_threadsp(%edx), %esp
+
+#ifdef CONFIG_CC_STACKPROTECTOR
+ movlTASK_stack_canary(%edx), %ebx
+ movl%ebx, PER_CPU_VAR(stack_canary)+stack_canary_offset
+#endif
+
+ /* restore callee-saved registers */
+ popl%ebp
+ popl%esi
+ popl%edi
+ popl%ebx
+
+ jmp __switch_to
+END(__switch_to_asm)
+
+/*
+ * A newly forked process directly context switches into this address.
+ *
+ * eax: prev task we switched from
+ */
ENTRY(ret_from_fork)
pushl %eax
callschedule_tail
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index ab9f8c8..0542ad1 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -365,13 +365,49 @@ END(ptregs_\func)
#include
/*
+ * %rdi: prev task
+ * %rsi: next task
+ */
+ENTRY(__switch_to_asm)
+ /*
+* Save callee-saved registers
+* This must match the order in struct fork_frame
+* Frame pointer must be last for get_wchan
+*/
+ pushq %rbx
+ pushq %r12
+ pushq %r13
+ pushq %r14
+ pushq %r15
+ pushq %rbp
+
+ /* switch stack */
+ movq%rsp, TASK_threadsp(%rdi)
+ movqTASK_threadsp(%rsi), %rsp
+
+#ifdef CONFIG_CC_STACKPROTECTOR
+ movqTASK_stack_canary(%rsi), %rbx
+ movq%rbx, PER_CPU_VAR(irq_stack_union)+stack_canary_offset
+#endif
+
+ /* restore callee-saved registers */
+ popq%rbp
+ popq%r15
+ popq%r14
+ popq%r13
+ popq%r12
+ popq%rbx
+
+ jmp __switch_to
+END(__switch_to_asm)
+
+/*
* A newly forked process directly context switches into this address.
*
- * rdi: prev task we switched from
+ * rax: prev task we switched from
*/
ENTRY(ret_from_fork)
- LOCK ; btr $TIF_FORK, TI_flags(%r8)
-
+ movq%rax, %rdi
callschedule_tail /* rdi: 'prev' task parameter */
testb $3, CS(%rsp)/* from kernel_thread? */
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 62c6cc3..d3c2598 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -384,9 +384,6 @@ struct thread_struct {
unsigned short fsindex;
unsigned short gsindex;
#endif
-#ifdef CONFIG_X86_32
- unsigned long ip;
-#endif
#ifdef CONFIG_X86_64
unsigned long fsbase;
unsigned long gsbase;
diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index 8f321a1..b6c9e0c 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -2,130 +2,35 @@
#define _ASM_X86_SWITCH_TO_H
struct task_struct; /* one of the stranger aspects of C forward declarations */
+
+struct task_struct *__switch_to_asm(struct task_struct *prev,
+ struct task_struct *next);
+
__visible struct task_struct *__switch_to(struct task_struct *prev,
- struct task_struct *next);
+ struct task_struct *next);
struct tss_struct;
void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
struct tss_struct *tss);
[PATCH 2/4] x86-32, kgdb: Don't use thread.ip in sleeping_thread_to_gdb_regs()
Match 64-bit and set gdb_regs[GDB_PC] to zero. thread.ip is always the same point in the scheduler (except for newly forked processes), and will be removed in a future patch. Signed-off-by: Brian Gerst --- arch/x86/kernel/kgdb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c index 04cde52..fe649a5 100644 --- a/arch/x86/kernel/kgdb.c +++ b/arch/x86/kernel/kgdb.c @@ -172,7 +172,6 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct *p) gdb_regs[GDB_ES]= __KERNEL_DS; gdb_regs[GDB_PS]= 0; gdb_regs[GDB_CS]= __KERNEL_CS; - gdb_regs[GDB_PC]= p->thread.ip; gdb_regs[GDB_SS]= __KERNEL_DS; gdb_regs[GDB_FS]= 0x; gdb_regs[GDB_GS]= 0x; @@ -180,7 +179,6 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct *p) gdb_regs32[GDB_PS] = *(unsigned long *)(p->thread.sp + 8); gdb_regs32[GDB_CS] = __KERNEL_CS; gdb_regs32[GDB_SS] = __KERNEL_DS; - gdb_regs[GDB_PC]= 0; gdb_regs[GDB_R8]= 0; gdb_regs[GDB_R9]= 0; gdb_regs[GDB_R10] = 0; @@ -190,6 +188,7 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct *p) gdb_regs[GDB_R14] = 0; gdb_regs[GDB_R15] = 0; #endif + gdb_regs[GDB_PC]= 0; gdb_regs[GDB_SP]= p->thread.sp; } -- 2.5.5
[PATCH 0/4] x86: Rewrite switch_to()
This patch set simplifies the switch_to() code, by moving the stack switch code out of line into an asm stub before calling __switch_to(). This ends up being more readable, and using the C calling convention instead of clobbering all registers improves code generation. It also allows newly forked processes to construct a special stack frame to seamlessly flow to ret_from_fork, instead of using a test and branch, or an unbalanced call/ret. [PATCH 1/4] x86: Save return value from kernel_thread [PATCH 2/4] x86-32, kgdb: Don't use thread.ip in [PATCH 3/4] x86: Rewrite switch_to() code [PATCH 4/4] x86: Pass kernel thread parameters in fork_frame arch/x86/entry/entry_32.S | 68 +- arch/x86/entry/entry_64.S | 72 +-- arch/x86/include/asm/processor.h | 3 - arch/x86/include/asm/switch_to.h | 137 ++--- arch/x86/include/asm/thread_info.h | 2 - arch/x86/kernel/asm-offsets.c | 6 ++ arch/x86/kernel/asm-offsets_32.c | 5 ++ arch/x86/kernel/asm-offsets_64.c | 5 ++ arch/x86/kernel/kgdb.c | 3 +- arch/x86/kernel/process_32.c | 19 ++--- arch/x86/kernel/process_64.c | 17 +++-- arch/x86/kernel/smpboot.c | 1 - 12 files changed, 153 insertions(+), 185 deletions(-)
[PATCH 4/4] x86: Pass kernel thread parameters in fork_frame
Instead of setting up a fake pt_regs context, put the kernel thread
function pointer and arg into the unused callee-restored registers
of struct fork_frame.
Signed-off-by: Brian Gerst
---
arch/x86/entry/entry_32.S| 28 +++-
arch/x86/entry/entry_64.S| 30 +++---
arch/x86/kernel/process_32.c | 15 ---
arch/x86/kernel/process_64.c | 10 +++---
4 files changed, 29 insertions(+), 54 deletions(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 05e5340..424e8d3 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -241,35 +241,29 @@ END(__switch_to_asm)
* A newly forked process directly context switches into this address.
*
* eax: prev task we switched from
+ * ebx: kernel thread func
+ * edi: kernel thread arg
*/
ENTRY(ret_from_fork)
pushl %eax
callschedule_tail
popl%eax
+ testl %ebx, %ebx
+ jnz 1f
+
+2:
/* When we fork, we trace the syscall return in the child, too. */
movl%esp, %eax
callsyscall_return_slowpath
jmp restore_all
-END(ret_from_fork)
-ENTRY(ret_from_kernel_thread)
- pushl %eax
- callschedule_tail
- popl%eax
- movlPT_EBP(%esp), %eax
- call*PT_EBX(%esp)
+ /* kernel thread */
+1: movl%edi, %eax
+ call*%ebx
movl%eax, PT_EAX(%esp)
-
- /*
-* Kernel threads return to userspace as if returning from a syscall.
-* We should check whether anything actually uses this path and, if so,
-* consider switching it over to ret_from_fork.
-*/
- movl%esp, %eax
- callsyscall_return_slowpath
- jmp restore_all
-ENDPROC(ret_from_kernel_thread)
+ jmp 2b
+END(ret_from_fork)
/*
* Return to user mode is not as complex as all this looks,
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 0542ad1..cc8a0ba 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -405,37 +405,29 @@ END(__switch_to_asm)
* A newly forked process directly context switches into this address.
*
* rax: prev task we switched from
+ * rbx: kernel thread func
+ * r12: kernel thread arg
*/
ENTRY(ret_from_fork)
movq%rax, %rdi
callschedule_tail /* rdi: 'prev' task parameter */
- testb $3, CS(%rsp)/* from kernel_thread? */
+ testq %rbx, %rbx /* from kernel_thread? */
jnz 1f
- /*
-* We came from kernel_thread. This code path is quite twisted, and
-* someone should clean it up.
-*
-* copy_thread_tls stashes the function pointer in RBX and the
-* parameter to be passed in RBP. The called function is permitted
-* to call do_execve and thereby jump to user mode.
-*/
- movqRBP(%rsp), %rdi
- call*RBX(%rsp)
- movq%rax, RAX(%rsp)
-
- /*
-* Fall through as though we're exiting a syscall. This makes a
-* twisted sort of sense if we just called do_execve.
-*/
-
-1:
+2:
movq%rsp, %rdi
callsyscall_return_slowpath /* returns with IRQs disabled */
TRACE_IRQS_ON /* user mode is traced as IRQS on */
SWAPGS
jmp restore_regs_and_iret
+
+1:
+ /* kernel thread */
+ movq%r12, %rdi
+ call*%rbx
+ movq%rax, RAX(%rsp)
+ jmp 2b
END(ret_from_fork)
/*
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 0ba6fdf..bba563f 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -138,6 +138,7 @@ int copy_thread_tls(unsigned long clone_flags, unsigned
long sp,
int err;
frame->bp = 0;
+ frame->ret_addr = (unsigned long) ret_from_fork;
p->thread.sp = (unsigned long) frame;
p->thread.sp0 = (unsigned long) (childregs+1);
memset(p->thread.ptrace_bps, 0, sizeof(p->thread.ptrace_bps));
@@ -145,25 +146,17 @@ int copy_thread_tls(unsigned long clone_flags, unsigned
long sp,
if (unlikely(p->flags & PF_KTHREAD)) {
/* kernel thread */
memset(childregs, 0, sizeof(struct pt_regs));
- frame->ret_addr = (unsigned long) ret_from_kernel_thread;
- task_user_gs(p) = __KERNEL_STACK_CANARY;
- childregs->ds = __USER_DS;
- childregs->es = __USER_DS;
- childregs->fs = __KERNEL_PERCPU;
- childregs->bx = sp; /* function */
- childregs->bp = arg;
- childregs->orig_ax = -1;
- childregs->cs = __KERNEL_CS | get_kernel_rpl();
- childregs->flags = X86_EFLAGS_IF | X86_EFLAGS_FIXED;
+ frame->bx = sp; /* function */
+ frame->di
Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE
On 05/18/2016 12:58 PM, Jason Low wrote: > On Wed, 2016-05-18 at 14:29 -0400, Waiman Long wrote: >> On 05/18/2016 01:21 PM, Jason Low wrote: >>> On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote: On Tue, 17 May 2016, Waiman Long wrote: > Without using WRITE_ONCE(), the compiler can potentially break a > write into multiple smaller ones (store tearing). So a read from the > same data by another task concurrently may return a partial result. > This can result in a kernel crash if the data is a memory address > that is being dereferenced. > > This patch changes all write to rwsem->owner to use WRITE_ONCE() > to make sure that store tearing will not happen. READ_ONCE() may > not be needed for rwsem->owner as long as the value is only used for > comparison and not dereferencing. >>> It might be okay to leave out READ_ONCE() for reading rwsem->owner, but >>> couldn't we include it to at least document that we're performing a >>> "special" lockless read? >>> >> >> Using READ_ONCE() does have a bit of cost as it limits compiler >> optimization. If we changes all access to rwsem->owner to READ_ONCE() >> and WRITE_ONCE(), we may as well change its type to volatile and be done >> with. > > Right, although there are still places like the init function where > WRITE_ONCE isn't necessary. Which doesn't cost anything either. >> I am not against doing that, but it feels a bit over-reach for me. >> On the other hand, we may define a do-nothing macro that designates the >> owner as a special variable for documentation purpose, but don't need >> protection at that particular call site. > > It should be fine to use the standard READ_ONCE here, even if it's just > for documentation, as it's probably not going to cost anything in > practice. It would be better to avoid adding any special macros for this > which may just add more complexity. See, I don't understand this line of reasoning at all. I read this as "it's ok to be non-optimal here where were spinning CPU time but not ok to be non-optimal generally elsewhere where it's way less important like at init time". And by the way, it's not just "here" but _everywhere_. What about reading ->on_cpu locklessly? Sure it's a bool, but doesn't the "we need to document lockless access" argument equally apply here? Regards, Peter Hurley
Re: [PATCH v2 09/12] clocksource: add J-Core PIT/RTC driver
On 05/20/2016 10:15 PM, Rich Felker wrote: > On Fri, May 20, 2016 at 04:01:56PM +0200, Daniel Lezcano wrote: >>> + return ((u64)sechi << 32 | seclo) * 10 + nsec; >> >> s/10/NSEC_PER_SEC/ ... >>> + hwirq = irq_get_irq_data(pit_irq)->hwirq; >>> + enable_val = (1<<26) | ((hwirq&0x3c)<<18) | (hwirq<<12); >> >> Can you explain? (and replace litterals by macros). "Hiding numbers that are used just once into defines to put them out of sight does not really help readability." - Pavel Machek http://lkml.iu.edu/hypermail/linux/kernel/1407.1/00299.html Rob
[GIT PULL] RTC for 4.7
Hi Linus, Here is the pull-request for the RTC subsystem for 4.7. Note that you may have to refresh my key to verify the tag signature as I'm now using a subkey to sign tags and emails. The following changes since commit 2dcd0af568b0cf583645c8a317dd12e344b1c72a: Linux 4.6 (2016-05-15 15:43:13 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-4.7 for you to fetch changes up to b9ba1eb0336877b9b83556fd30d2becda110fd8c: rtc: tps6586x: rename so module can be autoloaded (2016-05-21 17:07:17 +0200) RTC for 4.7 Subsystem wide cleanups: - Use IS_ENABLED() instead of checking for built-in or module - remove useless DRV_VERSION - remove CLK_IS_ROOT - remove UIE signaling Drivers: - ds1302: rewritten to be a proper SPI device driver - m41t80: huge cleanup, alarm, wakelarm ans oscialltor failure detection support - rv3029: switch to regmap to handle rv3049, alarm support, fixes - zynqmp: enable switching to battery power, fixes - small fixes for at91sam9, da9053, ds1307, ds1685, ds3232, r2025, sa1100, snvs, stmp3xxx, tps6586x Akinobu Mita (2): rtc: ds1302: fix error check in set_time rtc: ds1302: fix write value for day of week register Alexandre Belloni (1): rtc: remove useless DRV_VERSION Anurag Kumar Vulisha (3): rtc: zynqmp: Enable RTC switching to battery power when VCC_PSAUX is N/A rtc: zynqmp: Write Calibration value before setting time rtc: zynqmp: Update seconds time programming logic Arnd Bergmann (1): rtc: rv3029: hide unused i2c device table Colin Ian King (1): rtc: at91sam9: remove duplicate assignment of variable mr Geert Uytterhoeven (1): rtc: sa1100: DT spelling s/interrupt-name/interrupt-names/ Javier Martinez Canillas (1): rtc: Use IS_ENABLED() instead of checking for built-in or module Josh Poimboeuf (1): rtc: ds1685: actually spin forever in poweroff path Mylène Josserand (15): rtc: m41t80: update sysfs entries export rtc: m41t80: remove proc macro rtc: m41t80: replace i2c functions for smbus ones rtc: m41t80: add the use of 'BIT' macro rtc: m41t80: remove warnings and replace obsolete function rtc: m41t80: add alarm functionality rtc: m41t80: add wakealarm functionality rtc: m41t80: handle oscillator failure bit rtc: rv3029: remove 'i2c' in functions names rtc: rv3029: convert to use regmap rtc: rv3029: Add support of RV3049 rtc: rv3029: Remove some checks and warnings rtc: rv3029: fix alarm support rtc: rv3029: fix set_time function rtc: rv3029: add alarm IRQ Nicolas Boullis (2): rtc: ds1307: fix ds1307_native_smbus_read_block_data function rtc: ds1307: ensure that any pending alarm is cleared before a new alarm is enabled Nicolas Chauvet (1): rtc: tps6586x: rename so module can be autoloaded Qianyu Gong (1): rtc: ds3232: fix call trace when rtc->ops_lock is used as NULL Sergey Yanovich (1): rtc: ds1302: rewrite using SPI Stefan Agner (1): rtc: snvs: return error in case enable_irq_wake fails Stephen Boyd (3): rtc: pcf8563: Remove CLK_IS_ROOT rtc: hym8563: Remove CLK_IS_ROOT rtc: ds1307: Remove CLK_IS_ROOT Steve Twiss (1): rtc: da9053: fix access ordering error during RTC interrupt at system power on Sudip Mukherjee (1): rtc: stmp3xxx: print message on error Thomas Koeller (1): rtc: rs5c372: r2025: fix check for 'oscillator halted' condition Wolfram Sang (2): rtc: mxc: remove UIE signaling rtc: mc13xxx: remove UIE signaling .../devicetree/bindings/rtc/maxim-ds1302.txt | 46 ++ .../devicetree/bindings/rtc/sa1100-rtc.txt | 2 +- drivers/rtc/Kconfig| 52 +- drivers/rtc/rtc-at91sam9.c | 2 +- drivers/rtc/rtc-cmos.c | 2 +- drivers/rtc/rtc-da9052.c | 13 +- drivers/rtc/rtc-ds1216.c | 3 - drivers/rtc/rtc-ds1286.c | 3 - drivers/rtc/rtc-ds1302.c | 348 ++-- drivers/rtc/rtc-ds1307.c | 23 +- drivers/rtc/rtc-ds1343.c | 2 - drivers/rtc/rtc-ds1511.c | 3 - drivers/rtc/rtc-ds1553.c | 3 - drivers/rtc/rtc-ds1672.c | 5 - drivers/rtc/rtc-ds1685.c | 4 +- drivers/rtc/rtc-ds1742.c | 3 - drivers/rtc/rtc-ds3232.c | 9 +- drivers/rtc/rtc-ep93xx.c | 3 - drivers/rtc/rtc-gemini.c | 1 - drivers/rtc/rtc-hym8563.c
[PATCH] dell-smm-hwmon: In debug mode log duration of SMM calls
This allow us to debug how long take each SMM call and how long is system
freezed in SMM handler.
Signed-off-by: Pali Rohár
---
drivers/hwmon/dell-smm-hwmon.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
index 7a2764a..8a66a42 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -137,6 +137,14 @@ static int i8k_smm(struct smm_regs *regs)
int eax = regs->eax;
cpumask_var_t old_mask;
+#ifdef DEBUG
+ int ebx = regs->ebx;
+ unsigned long duration;
+ ktime_t calltime, delta, rettime;
+
+ calltime = ktime_get();
+#endif
+
/* SMM requires CPU 0 */
if (!alloc_cpumask_var(&old_mask, GFP_KERNEL))
return -ENOMEM;
@@ -208,6 +216,15 @@ static int i8k_smm(struct smm_regs *regs)
out:
set_cpus_allowed_ptr(current, old_mask);
free_cpumask_var(old_mask);
+
+#ifdef DEBUG
+ rettime = ktime_get();
+ delta = ktime_sub(rettime, calltime);
+ duration = ktime_to_ns(delta) >> 10;
+ pr_debug("smm(0x%.4x 0x%.4x) = 0x%.4x (took %7lu usecs)\n", eax, ebx,
+ (rc ? 0x : regs->eax & 0x), duration);
+#endif
+
return rc;
}
--
1.7.9.5
[PATCH] dell-smm-hwmon: Detect fan with index=2
Some Dell machines (e.g. Dell Precision M3800) have two fans, first with
index=0 and second with index=2. So export also attributes for third fan
device with index=2.
Reported-by: Tolga Cakir
Signed-off-by: Pali Rohár
---
drivers/hwmon/dell-smm-hwmon.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
---
Hi Tolga! Can you test this patch if sensors see fan device correctly?
diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
index 577445f..7a2764a 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -78,6 +78,7 @@ static uint i8k_fan_max = I8K_FAN_HIGH;
#define I8K_HWMON_HAVE_TEMP4 (1 << 3)
#define I8K_HWMON_HAVE_FAN1(1 << 4)
#define I8K_HWMON_HAVE_FAN2(1 << 5)
+#define I8K_HWMON_HAVE_FAN3(1 << 6)
MODULE_AUTHOR("Massimo Dal Zotto (d...@debian.org)");
MODULE_AUTHOR("Pali Rohár ");
@@ -246,7 +247,7 @@ static int _i8k_get_fan_type(int fan)
static int i8k_get_fan_type(int fan)
{
/* I8K_SMM_GET_FAN_TYPE SMM call is expensive, so cache values */
- static int types[2] = { INT_MIN, INT_MIN };
+ static int types[3] = { INT_MIN, INT_MIN, INT_MIN };
if (types[fan] == INT_MIN)
types[fan] = _i8k_get_fan_type(fan);
@@ -707,6 +708,12 @@ static SENSOR_DEVICE_ATTR(fan2_label, S_IRUGO,
i8k_hwmon_show_fan_label, NULL,
1);
static SENSOR_DEVICE_ATTR(pwm2, S_IRUGO | S_IWUSR, i8k_hwmon_show_pwm,
i8k_hwmon_set_pwm, 1);
+static SENSOR_DEVICE_ATTR(fan3_input, S_IRUGO, i8k_hwmon_show_fan, NULL,
+ 2);
+static SENSOR_DEVICE_ATTR(fan3_label, S_IRUGO, i8k_hwmon_show_fan_label, NULL,
+ 2);
+static SENSOR_DEVICE_ATTR(pwm3, S_IRUGO | S_IWUSR, i8k_hwmon_show_pwm,
+ i8k_hwmon_set_pwm, 2);
static struct attribute *i8k_attrs[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr, /* 0 */
@@ -723,6 +730,9 @@ static struct attribute *i8k_attrs[] = {
&sensor_dev_attr_fan2_input.dev_attr.attr, /* 11 */
&sensor_dev_attr_fan2_label.dev_attr.attr, /* 12 */
&sensor_dev_attr_pwm2.dev_attr.attr,/* 13 */
+ &sensor_dev_attr_fan3_input.dev_attr.attr, /* 14 */
+ &sensor_dev_attr_fan3_label.dev_attr.attr, /* 15 */
+ &sensor_dev_attr_pwm3.dev_attr.attr,/* 16 */
NULL
};
@@ -747,6 +757,9 @@ static umode_t i8k_is_visible(struct kobject *kobj, struct
attribute *attr,
if (index >= 11 && index <= 13 &&
!(i8k_hwmon_flags & I8K_HWMON_HAVE_FAN2))
return 0;
+ if (index >= 14 && index <= 16 &&
+ !(i8k_hwmon_flags & I8K_HWMON_HAVE_FAN3))
+ return 0;
return attr->mode;
}
@@ -788,6 +801,11 @@ static int __init i8k_init_hwmon(void)
if (err >= 0)
i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN2;
+ /* Third fan attributes, if fan status is OK */
+ err = i8k_get_fan_status(2);
+ if (err >= 0)
+ i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN3;
+
i8k_hwmon_dev = hwmon_device_register_with_groups(NULL, "dell_smm",
NULL, i8k_groups);
if (IS_ERR(i8k_hwmon_dev)) {
--
1.7.9.5
[PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection
On more Dell machines (e.g. Dell Precision M3800) I8K_SMM_GET_FAN_TYPE call
is too expensive (CPU is too long in SMM mode) and cause kernel to hang.
This patch cache type for each fan (as it should not change) and change the
way how fan presense is detected. It revert and use function fan_status()
as was before commit f989e55452c7 ("i8k: Add support for fan labels").
Moreover, kernel hangs for 2 - 3 seconds only sometimes and only on some
Dell machines. When kernel hangs fan speed is at max. So it was hard to
debug and bisect where is root of this problem. It looks like this is bug
in Dell BIOS which implement fan type SMM code... and there is no way how
to fix it in kernel.
Signed-off-by: Pali Rohár
Reviewed-by: Jean Delvare
Reported-and-tested-by: Tolga Cakir
Fixes: f989e55452c7 ("i8k: Add support for fan labels")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=112021
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100121
Cc: sta...@vger.kernel.org # v4.0+, will need backport
---
drivers/hwmon/dell-smm-hwmon.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
---
Hi!
Jan C Peters, Thorsten Leemhuis, David Santamaría Rogado, Peter Saunderson
and others, can you test this patch if it fixes your freeze problem at
boottime and when using "sensors" program?
I need to know if this patch fixes problem on Dell Studio XPS 8000 and
Dell Studio XPS 8100 machines, so we can revert git commits:
6220f4ebd7b4 ("hwmon: (dell-smm) Blacklist Dell Studio XPS 8000")
a4b45b25f18d ("hwmon: (dell-smm) Blacklist Dell Studio XPS 8100")
diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
index c43318d..577445f 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -235,7 +235,7 @@ static int i8k_get_fan_speed(int fan)
/*
* Read the fan type.
*/
-static int i8k_get_fan_type(int fan)
+static int _i8k_get_fan_type(int fan)
{
struct smm_regs regs = { .eax = I8K_SMM_GET_FAN_TYPE, };
@@ -243,6 +243,17 @@ static int i8k_get_fan_type(int fan)
return i8k_smm(®s) ? : regs.eax & 0xff;
}
+static int i8k_get_fan_type(int fan)
+{
+ /* I8K_SMM_GET_FAN_TYPE SMM call is expensive, so cache values */
+ static int types[2] = { INT_MIN, INT_MIN };
+
+ if (types[fan] == INT_MIN)
+ types[fan] = _i8k_get_fan_type(fan);
+
+ return types[fan];
+}
+
/*
* Read the fan nominal rpm for specific fan speed.
*/
@@ -767,13 +778,13 @@ static int __init i8k_init_hwmon(void)
if (err >= 0)
i8k_hwmon_flags |= I8K_HWMON_HAVE_TEMP4;
- /* First fan attributes, if fan type is OK */
- err = i8k_get_fan_type(0);
+ /* First fan attributes, if fan status is OK */
+ err = i8k_get_fan_status(0);
if (err >= 0)
i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN1;
- /* Second fan attributes, if fan type is OK */
- err = i8k_get_fan_type(1);
+ /* Second fan attributes, if fan status is OK */
+ err = i8k_get_fan_status(1);
if (err >= 0)
i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN2;
--
1.7.9.5
Re: [PATCH] usb: host: ehci-msm: Conditionally call ehci suspend/resume
On Fri, 20 May 2016, Andy Gross wrote:
> This patch fixes a suspend/resume issue where the driver is blindly
> calling ehci_suspend/resume functions when the ehci hasn't been setup.
> This results in a crash during suspend/resume operations.
>
> Signed-off-by: Andy Gross
> ---
> drivers/usb/host/ehci-msm.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
> index 3e226ef..9996a60 100644
> --- a/drivers/usb/host/ehci-msm.c
> +++ b/drivers/usb/host/ehci-msm.c
> @@ -179,22 +179,32 @@ static int ehci_msm_remove(struct platform_device *pdev)
> static int ehci_msm_pm_suspend(struct device *dev)
> {
> struct usb_hcd *hcd = dev_get_drvdata(dev);
> + struct ehci_hcd *ehci = hcd_to_ehci(hcd);
> bool do_wakeup = device_may_wakeup(dev);
>
> dev_dbg(dev, "ehci-msm PM suspend\n");
>
> - return ehci_suspend(hcd, do_wakeup);
> + /* Only call ehci_suspend if ehci_setup has been done */
> + if (ehci->sbrn)
> + return ehci_suspend(hcd, do_wakeup);
> +
> + return 0;
> }
>
> static int ehci_msm_pm_resume(struct device *dev)
> {
> struct usb_hcd *hcd = dev_get_drvdata(dev);
> + struct ehci_hcd *ehci = hcd_to_ehci(hcd);
>
> dev_dbg(dev, "ehci-msm PM resume\n");
> - ehci_resume(hcd, false);
> +
> + /* Only call ehci_resume if ehci_setup has been done */
> + if (ehci->sbrn)
> + ehci_resume(hcd, false);
>
> return 0;
> }
> +
> #else
> #define ehci_msm_pm_suspend NULL
> #define ehci_msm_pm_resume NULL
Acked-by: Alan Stern
[GIT PULL] Btrfs
Hi Linus, My for-linus-4.7 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.7 Has our merge window series of cleanups and fixes. These target a wide range of issues, but do include some important fixes for qgroups, O_DIRECT, and fsync handling. Jeff Mahoney moved around a few definitions to make them easier for userland to consume. Also whiteout support is included now that issues with overlayfs have been cleared up. I have one more fix pending for page faults during btrfs_copy_from_user, but I wanted to get this bulk out the door first. David Sterba (28) commits (+343/-247): btrfs: introduce raid-type to error-code table, for minimum device constraint (+16/-1) btrfs: switch to common message helpers in open_ctree, adjust messages (+50/-52) btrfs: reuse existing variable in scrub_stripe, reduce stack usage (+9/-10) btrfs: send: use vmalloc only as fallback for clone_sources_tmp (+8/-5) btrfs: pass number of devices to btrfs_check_raid_min_devices (+20/-15) btrfs: use dynamic allocation for root item in create_subvol (+37/-28) btrfs: use existing device constraints table btrfs_raid_array (+9/-14) btrfs: clone: use vmalloc only as fallback for nodesize bufer (+8/-5) btrfs: send: use temporary variable to store allocation size (+8/-6) btrfs: make find_workspace warn if there are no workspaces (+14/-0) btrfs: rename and document compression workspace members (+19/-16) btrfs: send: use vmalloc only as fallback for clone_roots (+7/-4) btrfs: add read-only check to sysfs handler of features (+3/-0) btrfs: send: use vmalloc only as fallback for read_buf (+7/-4) btrfs: send: use vmalloc only as fallback for send_buf (+7/-4) btrfs: ioctl: reorder exclusive op check in RM_DEV (+11/-12) btrfs: ioctl: reorder exclusive op check in RM_DEV (+11/-12) btrfs: add write protection to SET_FEATURES ioctl (+13/-3) btrfs: kill unused writepage_io_hook callback (+16/-24) btrfs: rename btrfs_find_device_by_user_input (+13/-10) btrfs: build fixup for qgroup_account_snapshot (+5/-0) btrfs: sysfs: protect reading label by lock (+7/-1) btrfs: make find_workspace always succeed (+12/-8) btrfs: preallocate compression workspaces (+16/-0) btrfs: add check to sysfs handler of label (+3/-0) btrfs: rename __check_raid_min_devices (+2/-2) btrfs: GFP_NOFS does not GFP_HIGHMEM (+4/-4) btrfs: rename flags for vol args v2 (+8/-7) Anand Jain (20) commits (+449/-381): btrfs: fix lock dep warning, move scratch dev out of device_list_mutex and uuid_mutex (+12/-5) btrfs: fix lock dep warning move scratch super outside of chunk_mutex (+5/-4) btrfs: make use of btrfs_scratch_superblocks() in btrfs_rm_device() (+13/-64) btrfs: enhance btrfs_find_device_by_user_input() to check device path (+3/-4) btrfs: cleanup assigning next active device with a check (+48/-22) btrfs: create helper function __check_raid_min_devices() (+32/-19) btrfs: create helper btrfs_find_device_by_user_input() (+23/-23) btrfs: clean up and optimize __check_raid_min_device() (+19/-24) btrfs: create a helper function to read the disk super (+52/-35) btrfs: rename btrfs_std_error to btrfs_handle_fs_error (+31/-31) btrfs: pass the right error code to the btrfs_std_error (+2/-2) btrfs: make use of btrfs_find_device_by_user_input() (+37/-63) btrfs: move error handling code together in ctree.h (+40/-38) btrfs: refactor btrfs_dev_replace_start for reuse (+41/-23) btrfs: s_bdev is not null after missing replace (+6/-3) btrfs: remove unused function btrfs_assert() (+0/-1) btrfs: introduce device delete by devid (+73/-5) btrfs: optimize check for stale device (+2/-1) btrfs: remove save_error_info() (+6/-10) btrfs: use fs_info directly (+4/-4) Filipe Manana (13) commits (+404/-180): Btrfs: fix race between fsync and direct IO writes for prealloc extents (+37/-6) Btrfs: fix empty symlink after creating symlink and fsync parent dir (+1/-1) Btrfs: add semaphore to synchronize direct IO writes with fsync (+77/-118) Btrfs: fix inode leak on failure to setup whiteout inode in rename (+6/-6) Btrfs: fix for incorrect directory entries after fsync log replay (+8/-5) Btrfs: fix race between block group relocation and nocow writes (+81/-1) Btrfs: fix number of transaction units for renames with whiteout (+8/-1) Btrfs: don't wait for unrelated IO to finish before relocation (+38/-19) Btrfs: pin logs earlier when doing a rename exchange operation (+4/-4) Btrfs: don't do unnecessary delalloc flushes when relocating (+79/-7) Btrfs: unpin logs if rename exchange operation fails (+36/-2) Btrfs: unpin log if rename operation fails (+27/-1) Btrfs: pin log earlier when renaming (+2/-9) Jeff Mahoney (8) commits (+1161/-1090): btrfs: uapi/linux/btrfs.h migration, move struct btrfs_ioctl_defrag_range_args (+37/-32
Re: [PATCH 2/3] sched,fair: Fix local starvation
On Tue, 2016-05-10 at 19:43 +0200, Peter Zijlstra wrote:
(Evolution authors must either not do patch review, or use some other
mailer. Squint hard, this crud really is your patch;)
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
>
> @@ -1762,7 +1770,11 @@ void sched_ttwu_pending(void)
> >> while (llist) {
> >> > p = llist_entry(llist, struct task_struct, wake_entry);
> >> > llist = llist_next(llist);
> ->> > ttwu_do_activate(rq, p, 0, cookie);
> +>> > /*
> +>> > * See ttwu_queue(); we only call ttwu_queue_remote() when
> +>> > * its a x-cpu wakeup.
> +>> > */
> +>> > ttwu_do_activate(rq, p, WF_MIGRATED, cookie);
Wakees that were not migrated/normalized eat an unwanted min_vruntime,
and likely take a size XXL latency hit. Big box running master bled
profusely under heavy load until I turned TTWU_QUEUE off.
-Mike
Re: sem_lock() vs qspinlocks
On 05/21/2016 09:37 AM, Peter Zijlstra wrote:
On Fri, May 20, 2016 at 05:48:39PM -0700, Davidlohr Bueso wrote:
As opposed to spin_is_locked(), spin_unlock_wait() is perhaps more tempting
to use for locking correctness. For example, taking a look at
nf_conntrack_all_lock(),
it too likes to get smart with spin_unlock_wait() -- also for finer graining
purposes.
While not identical to sems, it goes like:
nf_conntrack_all_lock():nf_conntrack_lock():
spin_lock(B); spin_lock(A);
if (bar) { // false
bar = 1; ...
}
[loop ctrl-barrier]
spin_unlock_wait(A);
foo(); foo();
If the spin_unlock_wait() doesn't yet see the store that makes A visibly locked,
we could end up with both threads in foo(), no?. (Although I'm unsure about that
ctrl barrier and archs could fall into it. The point was to see in-tree examples
of creative thinking with locking).
I'm tempted to put that trailing smp_rmb() in spin_unlock_wait() too;
because I suspect the netfilter code is broken without it.
And it seems intuitive to assume that if we return from unlock_wait() we
can indeed observe the critical section we waited on.
Then !spin_is_locked() and spin_unlock_wait() would be different with
regards to memory barriers.
Would that really help?
My old plan was to document the rules, and define a generic
smp_acquire__after_spin_is_unlocked.
https://lkml.org/lkml/2015/3/1/153
Noone supported it, so it ended up as
ipc_smp_acquire__after_spin_is_unlocked().
Should we move it to linux/spinlock.h?
Who needs it?
- ipc/sem.c (but please start from the version from linux-next as
reference, it is far less convoluted compared to the current code)
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/ipc/sem.c
- nf_conntrack
- task_rq_lock() perhaps needs smp_acquire__after_ctrl_dep
(I didn't figure out yet what happened to the proposed patch)
https://lkml.org/lkml/2015/2/17/129
--
Manfred
[PATCH] drivers: dma-coherent: use vma_pages().
Replace explicit computation of vma page count by a call to
vma_pages()
Signed-off-by: Muhammad Falak R Wani
---
drivers/base/dma-coherent.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index bdf28f7..db122a0 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -261,7 +261,7 @@ int dma_mmap_from_coherent(struct device *dev, struct
vm_area_struct *vma,
(mem->virt_base + (mem->size << PAGE_SHIFT))) {
unsigned long off = vma->vm_pgoff;
int start = (vaddr - mem->virt_base) >> PAGE_SHIFT;
- int user_count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+ int user_count = vma_pages(vma);
int count = size >> PAGE_SHIFT;
*ret = -ENXIO;
--
1.9.1
[PATCH] dma-buf: use vma_pages().
Replace explicit computation of vma page count by a call to vma_pages() Signed-off-by: Muhammad Falak R Wani --- drivers/dma-buf/dma-buf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 4a2c07e..b0317ec 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -90,7 +90,7 @@ static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma) dmabuf = file->private_data; /* check for overflowing the buffer's size */ - if (vma->vm_pgoff + ((vma->vm_end - vma->vm_start) >> PAGE_SHIFT) > + if (vma->vm_pgoff + vma_pages(vma) > dmabuf->size >> PAGE_SHIFT) return -EINVAL; @@ -723,11 +723,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma, return -EINVAL; /* check for offset overflow */ - if (pgoff + ((vma->vm_end - vma->vm_start) >> PAGE_SHIFT) < pgoff) + if (pgoff + vma_pages(vma) < pgoff) return -EOVERFLOW; /* check for overflowing the buffer's size */ - if (pgoff + ((vma->vm_end - vma->vm_start) >> PAGE_SHIFT) > + if (pgoff + vma_pages(vma) > dmabuf->size >> PAGE_SHIFT) return -EINVAL; -- 1.9.1
[PATCH] dma-mapping: use vma_pages().
Replace explicit computation of vma page count by a call to
vma_pages()
Signed-off-by: Muhammad Falak R Wani
---
drivers/base/dma-mapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index d799662..1d82f7e 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -247,7 +247,7 @@ int dma_common_mmap(struct device *dev, struct
vm_area_struct *vma,
{
int ret = -ENXIO;
#if defined(CONFIG_MMU) && !defined(CONFIG_ARCH_NO_COHERENT_DMA_MMAP)
- unsigned long user_count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+ unsigned long user_count = vma_pages(vma);
unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
unsigned long off = vma->vm_pgoff;
--
1.9.1
[PATCH] drm/gma500: use vma_pages().
Replace explicit computation of vma page count by a call to vma_pages() Signed-off-by: Muhammad Falak R Wani --- drivers/gpu/drm/gma500/framebuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/framebuffer.c b/drivers/gpu/drm/gma500/framebuffer.c index 7440bf9..5486e7e 100644 --- a/drivers/gpu/drm/gma500/framebuffer.c +++ b/drivers/gpu/drm/gma500/framebuffer.c @@ -125,7 +125,7 @@ static int psbfb_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf) unsigned long phys_addr = (unsigned long)dev_priv->stolen_base + psbfb->gtt->offset; - page_num = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; + page_num = vma_pages(vma); address = (unsigned long)vmf->virtual_address - (vmf->pgoff << PAGE_SHIFT); vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); -- 1.9.1
[PATCH] HSI: cmt_speech: use vma_pages().
Replace explicit computation of vma page count by a call to vma_pages() Signed-off-by: Muhammad Falak R Wani --- drivers/hsi/clients/cmt_speech.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hsi/clients/cmt_speech.c b/drivers/hsi/clients/cmt_speech.c index 95638df..b16cfa4 100644 --- a/drivers/hsi/clients/cmt_speech.c +++ b/drivers/hsi/clients/cmt_speech.c @@ -1275,7 +1275,7 @@ static int cs_char_mmap(struct file *file, struct vm_area_struct *vma) if (vma->vm_end < vma->vm_start) return -EINVAL; - if (((vma->vm_end - vma->vm_start) >> PAGE_SHIFT) != 1) + if (vma_pages(vma) != 1) return -EINVAL; vma->vm_flags |= VM_IO | VM_DONTDUMP | VM_DONTEXPAND; -- 1.9.1
[PATCH] Staging: Android: Fix bracket alignment style issue in sync.c
This patch changes 3 bracket alignment errors found by checkpatch.
Signed-off-by: Craig Inches
---
drivers/staging/android/sync.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3a8f210..4a64bdd 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -430,7 +430,7 @@ static unsigned int sync_file_poll(struct file *file,
poll_table *wait)
}
static long sync_file_ioctl_merge(struct sync_file *sync_file,
- unsigned long arg)
+ unsigned long arg)
{
int fd = get_unused_fd_flags(O_CLOEXEC);
int err;
@@ -500,7 +500,7 @@ static int sync_fill_fence_info(struct fence *fence, void
*data, int size)
}
static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
- unsigned long arg)
+ unsigned long arg)
{
struct sync_file_info *info;
__u32 size;
@@ -552,7 +552,7 @@ out:
}
static long sync_file_ioctl(struct file *file, unsigned int cmd,
-unsigned long arg)
+ unsigned long arg)
{
struct sync_file *sync_file = file->private_data;
--
2.7.3
[PATCH] misc: mic: scif: use vma_pages().
Replace explicit computation of vma page count by a call to
vma_pages()
Signed-off-by: Muhammad Falak R Wani
---
drivers/misc/mic/scif/scif_mmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/mic/scif/scif_mmap.c
b/drivers/misc/mic/scif/scif_mmap.c
index 49cb8f7..9282116 100644
--- a/drivers/misc/mic/scif/scif_mmap.c
+++ b/drivers/misc/mic/scif/scif_mmap.c
@@ -552,7 +552,7 @@ static void scif_munmap(struct vm_area_struct *vma)
{
struct scif_endpt *ep;
struct vma_pvt *vmapvt = vma->vm_private_data;
- int nr_pages = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+ int nr_pages = vma_pages(vma);
s64 offset;
struct scif_rma_req req;
struct scif_window *window = NULL;
@@ -614,7 +614,7 @@ int scif_mmap(struct vm_area_struct *vma, scif_epd_t epd)
struct scif_window *window = NULL;
struct scif_endpt *ep = (struct scif_endpt *)epd;
s64 start_offset = vma->vm_pgoff << PAGE_SHIFT;
- int nr_pages = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+ int nr_pages = vma_pages(vma);
int err;
struct vma_pvt *vmapvt;
--
1.9.1
[PATCH] xen/privcmd: use vma_pages().
Replace explicit computation of vma page count by a call to
vma_pages()
Signed-off-by: Muhammad Falak R Wani
---
drivers/xen/privcmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index df2e6f7..702040f 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -582,7 +582,7 @@ static long privcmd_ioctl(struct file *file,
static void privcmd_close(struct vm_area_struct *vma)
{
struct page **pages = vma->vm_private_data;
- int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+ int numpgs = vma_pages(vma);
int numgfns = (vma->vm_end - vma->vm_start) >> XEN_PAGE_SHIFT;
int rc;
--
1.9.1
[PATCH] xen/gntdev: use vma_pages().
Replace explicit computation of vma page count by a call to
vma_pages()
Signed-off-by: Muhammad Falak R Wani
---
drivers/xen/gntdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 6793957..bb95212 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -982,7 +982,7 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
{
struct gntdev_priv *priv = flip->private_data;
int index = vma->vm_pgoff;
- int count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+ int count = vma_pages(vma);
struct grant_map *map;
int i, err = -EINVAL;
--
1.9.1
[PATCH] xen/gntalloc: use vma_pages().
Replace explicit computation of vma page count by a call to
vma_pages()
Signed-off-by: Muhammad Falak R Wani
---
drivers/xen/gntalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index 4547a91..7a47c4c 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -504,7 +504,7 @@ static int gntalloc_mmap(struct file *filp, struct
vm_area_struct *vma)
struct gntalloc_file_private_data *priv = filp->private_data;
struct gntalloc_vma_private_data *vm_priv;
struct gntalloc_gref *gref;
- int count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+ int count = vma_pages(vma);
int rv, i;
if (!(vma->vm_flags & VM_SHARED)) {
--
1.9.1
Re: Mount namespace "dominant peer group"?
Hello Ram,
On 05/20/2016 06:15 PM, Ram Pai wrote:
> On Fri, May 20, 2016 at 04:24:18PM -0500, Michael Kerrisk (man-pages) wrote:
>> Hello Miklos,
>>
>> I'm working on some better documentation of mount namespaces,
>> and there's a detail that puzzles me, and I hope you might be
>> able to help, since you added the detail...
>>
>> In Documentation/filesystems/proc.txt there is this text in the
>> description of /proc/PID/mountinfo:
>>
>> [[
>> Parsers should ignore all unrecognised optional fields. Currently the
>> possible optional fields are:
>>
>> shared:X mount is shared in peer group X
>> master:X mount is slave to peer group X
>> propagate_from:X mount is slave and receives propagation from peer group X
>> (*)
>> unbindable mount is unbindable
>>
>> (*) X is the closest dominant peer group under the process's root. If
>> X is the immediate master of the mount, or if there's no dominant peer
>> group under the same root, then only the "master:X" field is present
>> and not the "propagate_from:X" field.
>> ]]
>>
>> What is a dominant peer group, as distinct from the immediate master?
>>
>> I can see in fs/proc_namespaces.c that there is this distinction made:
>>
>> [[
>> /* Tagged fields ("foo:X" or "bar") */
>> if (IS_MNT_SHARED(r))
>> seq_printf(m, " shared:%i", r->mnt_group_id);
>> if (IS_MNT_SLAVE(r)) {
>> int master = r->mnt_master->mnt_group_id;
>> int dom = get_dominating_id(r, &p->root);
>> seq_printf(m, " master:%i", master);
>> if (dom && dom != master)
>> seq_printf(m, " propagate_from:%i", dom);
>> }
>> ]]
>>
>> But I can't relate that to some user-space semantics. I suppose another
>> way of asking my question is: how could I create a slave that is
>> propagating from a peer group other than it's immediate master?
>
> It can happen if you have unmounted or privatised all your master mounts from
> the peer group.
>
> Eg:
>
> mount /dev/xyz /1#creates a new mount
> mount --make-private /1 #just make sure that it does not receive or send
> and propogation
> mount --make-shared /1#now make it shared.
> mount --bind /1 /2 #create a peer /1 and /2 are peers
> create a new fs-namespace. this new fs-namespace which will have /1' and /2'.
> /1 /2 /1' /2' are now all part of the same peergroup.
> mount --make-slave /2 # this will make /2 a slave of the peer group that
> contains /1 /1' and /2'
> umount /1 # we now have /2 which receives propagation from a peer group
> which does not have a representative in its fs-namespace.
Thanks for the note. However, doing the above, I still do not
see any mount being marked with 'propagate_from'. Perhaps I
misunderstood your instructions above. Here's what I did:
sh1# mount --make-private / # Make share everything is private...
sh1# mount /dev/sdb6 /1
sh1# mount --make-private /1
sh1# mount --make-shared /1
sh1# mount --bind /1 /2
sh1# cat /proc/self/mountinfo | grep '/[12] ' | sed 's/ - .*//'
81 61 8:22 / /1 rw,relatime shared:1
82 61 8:22 / /2 rw,relatime shared:1
Then, at a second terminal, create a new mount NS:
sh2# unshare -m --propagation unchanged sh
sh2# cat /proc/self/mountinfo | grep '/[12] ' | sed 's/ - .*//'
169 132 8:22 / /1 rw,relatime shared:1
170 132 8:22 / /2 rw,relatime shared:1
Returning to the first terminal:
sh1# mount --make-slave /2
sh1# umount /1
sh1# cat /proc/self/mountinfo | grep '/[12] ' | sed 's/ - .*//'
82 61 8:22 / /2 rw,relatime master:1
That is, we see /2 in the initial mount namespace is a slave
but there is no 'propagate_from' tag. Did I miss something?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH] perf, tools, report: Add srcline_from/to branch sort keys
On Fri, May 20, 2016 at 01:15:08PM -0700, Andi Kleen wrote: > From: Andi Kleen > > Add srcline_from and srcline_to branch sort keys that allow > to show the source lines of a branch. That makes it much easier > to track down where particular branches happen in the program, > for example to examine branch mispredictions, or to associate > it with cycle counts: > > % perf record -b -e cycles:p ./tcall > % perf report --sort srcline_from,srcline_to,mispredict > ... > 15.10% tcall.c:18 tcall.c:10 > N > 14.83% tcall.c:11 tcall.c:5 > N > 14.12% tcall.c:7 tcall.c:12 > N > 14.04% tcall.c:12 tcall.c:5 > N > 12.42% tcall.c:17 tcall.c:18 > N > 12.39% tcall.c:7 tcall.c:13 > N > 12.27% tcall.c:13 tcall.c:17 > N > ... > > % perf report --sort srcline_from,srcline_to,cycles > ... > 17.12% tcall.c:18 tcall.c:11 > 1 > 17.01% tcall.c:12 tcall.c:6 > 1 > 16.98% tcall.c:11 tcall.c:6 > 1 > 15.91% tcall.c:17 tcall.c:18 > 1 > 6.38% tcall.c:7 tcall.c:17 > 7 > 4.80% tcall.c:7 tcall.c:12 > 8 > 4.21% tcall.c:7 tcall.c:17 > 8 > 2.67% tcall.c:7 tcall.c:12 > 7 > 2.62% tcall.c:7 tcall.c:12 > 10 > 2.10% tcall.c:7 tcall.c:17 > 9 > 1.58% tcall.c:7 tcall.c:12 > 6 > 1.44% tcall.c:7 tcall.c:12 > 5 > 1.38% tcall.c:7 tcall.c:12 > 9 > 1.06% tcall.c:7 tcall.c:17 > 13 > 1.05% tcall.c:7 tcall.c:12 > 4 > 1.01% tcall.c:7 tcall.c:17 > 6 > > Open issues: > - Some kernel symbols get misresolved. Acked-by: Jiri Olsa thanks, jirka
Re: [PATCHv3] support for AD5820 camera auto-focus coil
Hi,
On 21.05.2016 13:56, Pavel Machek wrote:
This adds support for AD5820 autofocus coil, found for example in
Nokia N900 smartphone.
Signed-off-by: Pavel Machek
---
v2: simple cleanups, fix error paths, simplify probe
v3: more cleanups, remove printk, add include
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 993dc50..77313a1 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -279,6 +279,13 @@ config VIDEO_ML86V7667
To compile this driver as a module, choose M here: the
module will be called ml86v7667.
+config VIDEO_AD5820
+ tristate "AD5820 lens voice coil support"
+ depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ ---help---
+ This is a driver for the AD5820 camera lens voice coil.
+ It is used for example in Nokia N900 (RX-51).
+
config VIDEO_SAA7110
tristate "Philips SAA7110 video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 94f2c99..34434ae 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -19,6 +20,7 @@ obj-$(CONFIG_VIDEO_SAA717X) += saa717x.o
obj-$(CONFIG_VIDEO_SAA7127) += saa7127.o
obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
+obj-$(CONFIG_VIDEO_AD5820) += ad5820.o
obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
diff --git a/drivers/media/i2c/ad5820.c b/drivers/media/i2c/ad5820.c
new file mode 100644
index 000..7725829
--- /dev/null
+++ b/drivers/media/i2c/ad5820.c
@@ -0,0 +1,416 @@
+/*
+ * drivers/media/i2c/ad5820.c
+ *
+ * AD5820 DAC driver for camera voice coil focus.
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Copyright (C) 2007 Texas Instruments
+ * Copyright (C) 2016 Pavel Machek
+ *
+ * Contact: Tuukka Toivonen
+ * Sakari Ailus
+ *
+ * Based on af_d88.c by Texas Instruments.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
At least on my machine checkpatch.pl complains about FSF address.
+#include
+#include
+#include
+#include
+#include
+#include
Doesn't seem to get used.
+#include
+#include
+#include
+
+#include
+#include
+
+#define CODE_TO_RAMP_US(s) ((s) == 0 ? 0 : (1 << ((s) - 1)) * 50)
+#define RAMP_US_TO_CODE(c) fls(((c) + ((c)>>1)) / 50)
+
+/**
+ * @brief I2C write using i2c_transfer().
+ * @param coil - the driver data structure
+ * @param data - register value to be written
+ * @returns nonnegative on success, negative if failed
+ */
+static int ad5820_write(struct ad5820_device *coil, u16 data)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&coil->subdev);
+ struct i2c_msg msg;
+ int r;
+
+ if (!client->adapter)
+ return -ENODEV;
+
+ data = cpu_to_be16(data);
+ msg.addr = client->addr;
+ msg.flags = 0;
+ msg.len = 2;
+ msg.buf = (u8 *)&data;
+
+ r = i2c_transfer(client->adapter, &msg, 1);
+ if (r < 0) {
+ dev_err(&client->dev, "write failed, error %d\n", r);
+ return r;
+ }
+
+ return 0;
+}
+
+/*
+ * Calculate status word and write it to the device based on current
+ * values of V4L2 controls. It is assumed that the stored V4L2 control
+ * values are properly limited and rounded.
+ */
+static int ad5820_update_hw(struct ad5820_device *coil)
+{
+ u16 status;
+
+ status = RAMP_US_TO_CODE(coil->focus_ramp_time);
+ status |= coil->focus_ramp_mode
+ ? AD5820_RAMP_MODE_64_16 : AD5820_RAMP_MODE_LINEAR;
+ status |= coil->focus_absolute << AD5820_DAC_SHIFT;
+
+ if (coil->standby)
+ status |= AD5820_POWER_DOWN;
+
+ return ad5820_write(coil, status);
+}
+
+/*
+ * Power handling
+ */
+static int ad5820_power_off(struct ad5820_device *coil, int standby)
+{
+ int ret = 0;
+
+ /*
+* Go to standby first as real power off my be denied by the hardware
+* (single power line control for both coil and sensor).
+*/
+ if (standby) {
+ coil->standby = 1;
+ ret = ad5820_update_hw(coil);
+ }
+
+ ret |= regulator_disable(coil->vana);
+
+ return ret;
+}
+
+static int ad5820_power_on(struct ad5820_device *coil, int restore)
+
Re: [PATCH 2/2] perf stat: Add missing aggregation headers for --metric-only CSV
On Fri, May 20, 2016 at 12:50:15PM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> When in CSV mode --metric-only outputs an header, unlike the other
> modes. Previously it did not properly print headers for the
> aggregation columns, so the headers were actually shifted against
> the real values.
>
> Fix this here by outputting the correct headers for CSV.
>
> Signed-off-by: Andi Kleen
> ---
> tools/perf/builtin-stat.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index 790eeea335cc..5d295da0e41c 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -1311,6 +1311,14 @@ static int aggr_header_lens[] = {
> [AGGR_GLOBAL] = 0,
> };
>
> +static const char *aggr_header_csv[] = {
> + [AGGR_CORE] = "core,cpus,",
> + [AGGR_SOCKET] = "socket,cpus",
> + [AGGR_NONE] = "cpu,",
> + [AGGR_THREAD] = "comm-pid,",
> + [AGGR_GLOBAL] = ""
> +};
please indent properly, otherwise
Acked-by: Jiri Olsa
thanks,
jirka
Re: [PATCH 1/2] perf stat: Print topology/time headers with --metric-only
On Fri, May 20, 2016 at 12:50:14PM -0700, Andi Kleen wrote: > From: Andi Kleen > > When --metric-only is enabled there were no headers for the topology > in interval mode. Also when headers were printed they were > on a separate line. > > Before: > > $ perf stat --metric-only -A -I 1000 -a > 1.001038376 frontend cycles idle insn per cycle stalled > cycles per insn branch-misses of all branches > 1.001038376 CPU0 123.54% 0.235.29 > 7.61% > 1.001038376 CPU1 137.78% 0.245.13 > 10.07% > 1.001038376 CPU2 64.48% 0.225.50 > 6.84% > > After: > > $ perf stat --metric-only -A -I 1000 -a > 1.00114 CPU0 82.46% 0.322.60 > 7.64% > 1.00114 CPU1 126.63% 0.02 42.83 > 0.15% > 1.00114 CPU2 193.54% 0.322.59 > 6.92% > > v2: Move all headers on a single line changelog is wrong [jolsa@ibm-x3650m4-01 perf]$ sudo ./perf stat --metric-only -A -I 1000 -a # time CPU frontend cycles idle backend cycles idle insn per cycle stalled cycles per insn branch-misses of all branches 1.003232468 CPU0 69.13% 56.43%0.31 2.200.01% 1.003232468 CPU1 69.13% 56.23%0.31 2.200.00% 1.003232468 CPU2 69.11% 56.27%0.32 2.190.00% otherwise Acked-by: Jiri Olsa thanks, jirka
[PATCHv3] support for AD5820 camera auto-focus coil
This adds support for AD5820 autofocus coil, found for example in
Nokia N900 smartphone.
Signed-off-by: Pavel Machek
---
v2: simple cleanups, fix error paths, simplify probe
v3: more cleanups, remove printk, add include
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 993dc50..77313a1 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -279,6 +279,13 @@ config VIDEO_ML86V7667
To compile this driver as a module, choose M here: the
module will be called ml86v7667.
+config VIDEO_AD5820
+ tristate "AD5820 lens voice coil support"
+ depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ ---help---
+ This is a driver for the AD5820 camera lens voice coil.
+ It is used for example in Nokia N900 (RX-51).
+
config VIDEO_SAA7110
tristate "Philips SAA7110 video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 94f2c99..34434ae 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -19,6 +20,7 @@ obj-$(CONFIG_VIDEO_SAA717X) += saa717x.o
obj-$(CONFIG_VIDEO_SAA7127) += saa7127.o
obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
+obj-$(CONFIG_VIDEO_AD5820) += ad5820.o
obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
diff --git a/drivers/media/i2c/ad5820.c b/drivers/media/i2c/ad5820.c
new file mode 100644
index 000..7725829
--- /dev/null
+++ b/drivers/media/i2c/ad5820.c
@@ -0,0 +1,416 @@
+/*
+ * drivers/media/i2c/ad5820.c
+ *
+ * AD5820 DAC driver for camera voice coil focus.
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Copyright (C) 2007 Texas Instruments
+ * Copyright (C) 2016 Pavel Machek
+ *
+ * Contact: Tuukka Toivonen
+ * Sakari Ailus
+ *
+ * Based on af_d88.c by Texas Instruments.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define CODE_TO_RAMP_US(s) ((s) == 0 ? 0 : (1 << ((s) - 1)) * 50)
+#define RAMP_US_TO_CODE(c) fls(((c) + ((c)>>1)) / 50)
+
+/**
+ * @brief I2C write using i2c_transfer().
+ * @param coil - the driver data structure
+ * @param data - register value to be written
+ * @returns nonnegative on success, negative if failed
+ */
+static int ad5820_write(struct ad5820_device *coil, u16 data)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&coil->subdev);
+ struct i2c_msg msg;
+ int r;
+
+ if (!client->adapter)
+ return -ENODEV;
+
+ data = cpu_to_be16(data);
+ msg.addr = client->addr;
+ msg.flags = 0;
+ msg.len = 2;
+ msg.buf = (u8 *)&data;
+
+ r = i2c_transfer(client->adapter, &msg, 1);
+ if (r < 0) {
+ dev_err(&client->dev, "write failed, error %d\n", r);
+ return r;
+ }
+
+ return 0;
+}
+
+/*
+ * Calculate status word and write it to the device based on current
+ * values of V4L2 controls. It is assumed that the stored V4L2 control
+ * values are properly limited and rounded.
+ */
+static int ad5820_update_hw(struct ad5820_device *coil)
+{
+ u16 status;
+
+ status = RAMP_US_TO_CODE(coil->focus_ramp_time);
+ status |= coil->focus_ramp_mode
+ ? AD5820_RAMP_MODE_64_16 : AD5820_RAMP_MODE_LINEAR;
+ status |= coil->focus_absolute << AD5820_DAC_SHIFT;
+
+ if (coil->standby)
+ status |= AD5820_POWER_DOWN;
+
+ return ad5820_write(coil, status);
+}
+
+/*
+ * Power handling
+ */
+static int ad5820_power_off(struct ad5820_device *coil, int standby)
+{
+ int ret = 0;
+
+ /*
+* Go to standby first as real power off my be denied by the hardware
+* (single power line control for both coil and sensor).
+*/
+ if (standby) {
+ coil->standby = 1;
+ ret = ad5820_update_hw(coil);
+ }
+
+ ret |= regulator_disable(coil->vana);
+
+ return ret;
+}
+
+static int ad5820_power_on(struct ad5820_device *coil, int restore)
+{
+ int ret;
+
+ printk("ad5820_power_on: 1\n");
+ ret = regulator_enable(coil->vana);
+ if (ret < 0)
+ return ret;
[PATCH v2 1/2] ip6_gre: Fix MTU setting for ip6gretap
When creat an ip6gretap interface with an unreachable route,
the MTU is about 14 bytes larger than what was needed.
If the remote address is reachable:
ping6 2001:0:130::1 -c 2
PING 2001:0:130::1(2001:0:130::1) 56 data bytes
64 bytes from 2001:0:130::1: icmp_seq=1 ttl=64 time=1.46 ms
64 bytes from 2001:0:130::1: icmp_seq=2 ttl=64 time=81.1 ms
--- 2001:0:130::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.465/41.316/81.167/39.851 ms
ip link add ip6gretap1 type ip6gretap\
local 2001:0:130::2 remote 2001:0:130::1
ip link show ip6gretap1
11: ip6gretap1@NONE: mtu 1434 ...
link/ether c2:f3:f8:c1:2c:bf brd ff:ff:ff:ff:ff:ff
The MTU value 1434 is right. But if we delete the direct route:
ip -6 route del 2001:0:130::/64
ping6 2001:0:130::1 -c 2
connect: Network is unreachable
ip link add ip6gretap1 type ip6gretap\
local 2001:0:130::2 remote 2001:0:130::1
ip link show ip6gretap1
12: ip6gretap1@NONE: mtu 1448 ...
link/ether 7e:e1:d2:c4:06:5e brd ff:ff:ff:ff:ff:ff
Now, the MTU value 1448 is larger than what was needed.
The reason is that if there is a reachable route, when
run following code in ip6gre_tnl_link_config:
if (p->flags & IP6_TNL_F_CAP_XMIT) {
int strict = (ipv6_addr_type(&p->raddr) &
(IPV6_ADDR_MULTICAST|IPV6_ADDR_LINKLOCAL));
struct rt6_info *rt = rt6_lookup(t->net,
&p->raddr, &p->laddr,
p->link, strict);
if (!rt)
return;
if (rt->dst.dev) {
dev->hard_header_len = rt->dst.dev->hard_header_len +
t_hlen;
if (set_mtu) {
dev->mtu = rt->dst.dev->mtu - t_hlen;
if (!(t->parms.flags &
IP6_TNL_F_IGN_ENCAP_LIMIT))
dev->mtu -= 8;
if (dev->type == ARPHRD_ETHER)
dev->mtu -= ETH_HLEN;
if (dev->mtu < IPV6_MIN_MTU)
dev->mtu = IPV6_MIN_MTU;
}
}
ip6_rt_put(rt);
}
Because rt is not NULL here, so dev->mtu will subtract the ethernet
header length later. But when rt is NULL, it just simply return, so
dev->mtu doesn't update correctly in this situation.
This patch first verify the dev->type is ARPHRD_ETHER for ip6gretap
interface, and then decrease the mtu as early as possible.
Signed-off-by: Haishuang Yan
---
Changes in v2:
- Make the commit message more clearer.
---
net/ipv6/ip6_gre.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 4541fa5..8ea5a4d 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1029,6 +1029,8 @@ static int ip6gre_tunnel_init_common(struct net_device
*dev)
dev->hard_header_len = LL_MAX_HEADER + t_hlen;
dev->mtu = ETH_DATA_LEN - t_hlen;
+ if (dev->type == ARPHRD_ETHER)
+ dev->mtu -= ETH_HLEN;
if (!(tunnel->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT))
dev->mtu -= 8;
--
1.8.3.1
[PATCH v2 2/2] ip6_gre: Set flowi6_proto as IPPROTO_GRE in xmit path.
In gre6 xmit path, we are sending a GRE packet, so set fl6 proto to IPPROTO_GRE properly. Signed-off-by: Haishuang Yan --- Changes in v2: - Initialize the flow protocol in ip6gre_tnl_link_config --- net/ipv6/ip6_gre.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c index 8ea5a4d..e706621 100644 --- a/net/ipv6/ip6_gre.c +++ b/net/ipv6/ip6_gre.c @@ -712,6 +712,7 @@ static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu) fl6->daddr = p->raddr; fl6->flowi6_oif = p->link; fl6->flowlabel = 0; + fl6->flowi6_proto = IPPROTO_GRE; if (!(p->flags&IP6_TNL_F_USE_ORIG_TCLASS)) fl6->flowlabel |= IPV6_TCLASS_MASK & p->flowinfo; -- 1.8.3.1
Re: [PATCH 1/1] ASoC: pxa: Fix module autoload for platform drivers
Andrea Adami writes: > These platform drivers are lacking MODULE_ALIAS so module autoloading > doesn't work. Tested on corgi and poodle with kernel 4.4. > > Signed-off-by: Andrea Adami Yes, why not. Acked-by: Robert Jarzmik Cheers. -- Robert
[GIT PULL] Mailbox changes for v4.7
Hi Linus,
The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9:
Linux 4.6-rc4 (2016-04-17 19:13:32 -0700)
are available in the git repository at:
git://git.linaro.org/landing-teams/working/fujitsu/integration.git
mailbox-for-next
for you to fetch changes up to c430cf376fee0b03d9c9293615f9737649de1b12:
mailbox: Fix devm_ioremap_resource error detection code (2016-05-08
22:44:46 +0530)
- OMAP
Remove non-DT support from mailbox driver
Move PM from client calls to native driver suspend/resume
Trivial cleanups to make checkpatch happy
- STI
Check return from devm_ioremap_resource as ERR_PTR, not NULL
Amitoj Kaur Chawla (1):
mailbox: Fix devm_ioremap_resource error detection code
Suman Anna (8):
mailbox/omap: drop legacy platform device support
mailbox/omap: use variable name for sizeof() operator
mailbox/omap: remove FSF mailing address paragraph
mailbox/omap: add blank lines after declarations
mailbox/omap: store mailbox interrupt type in omap_mbox_device
mailbox/omap: add support for suspend/resume
mailbox/omap: check for any unread messages during suspend
mailbox/omap: kill omap_mbox_{save/restore}_ctx() functions
drivers/mailbox/mailbox-sti.c | 4 +-
drivers/mailbox/omap-mailbox.c | 220 +
include/linux/omap-mailbox.h | 2 -
include/linux/platform_data/mailbox-omap.h | 58
4 files changed, 104 insertions(+), 180 deletions(-)
delete mode 100644 include/linux/platform_data/mailbox-omap.h
[PATCH] ACPI / Thermal / video: fix max_level incorrect value
On Sat, May 21, 2016 at 11:29:33AM +0800, Aaron Lu wrote:
> My bad, I see the problem here: the acpi_video_device_lcd_query_levels
> called in acpi_video_run_bcl_for_osi didn't do the proper conversion.
> The acpi_handle is a "void *" so there is no warnings...
I think I have found the problem, please give the patch a test, thanks.
From: Aaron Lu
Date: Sat, 21 May 2016 15:30:46 +0800
Subject: [PATCH] ACPI / Thermal / video: fix max_level incorrect value
commit 059500940def("ACPI/video: export acpi_video_get_levels")
mistakenly dropped the correct value of max_level and that caused the
set_level function following failed and the acpi_video backlight interface
didn't get created. Fix this by passing back the correct max_level value.
While at it, also fix the param used in acpi_video_device_lcd_query_levels
where acpi_handle is expected but acpi_video_device is passed.
Reported-by: Valdis Kletnieks
Signed-off-by: Aaron Lu
---
drivers/acpi/acpi_video.c | 9 ++---
drivers/thermal/int340x_thermal/int3406_thermal.c | 2 +-
include/acpi/video.h | 6 --
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 3d5b8a099351..c1d138e128cb 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -754,7 +754,8 @@ static int acpi_video_bqc_quirk(struct acpi_video_device
*device,
}
int acpi_video_get_levels(struct acpi_device *device,
- struct acpi_video_device_brightness **dev_br)
+ struct acpi_video_device_brightness **dev_br,
+ int *pmax_level)
{
union acpi_object *obj = NULL;
int i, max_level = 0, count = 0, level_ac_battery = 0;
@@ -841,6 +842,8 @@ int acpi_video_get_levels(struct acpi_device *device,
br->count = count;
*dev_br = br;
+ if (pmax_level)
+ *pmax_level = max_level;
out:
kfree(obj);
@@ -869,7 +872,7 @@ acpi_video_init_brightness(struct acpi_video_device *device)
struct acpi_video_device_brightness *br = NULL;
int result = -EINVAL;
- result = acpi_video_get_levels(device->dev, &br);
+ result = acpi_video_get_levels(device->dev, &br, &max_level);
if (result)
return result;
device->brightness = br;
@@ -1737,7 +1740,7 @@ static void acpi_video_run_bcl_for_osi(struct
acpi_video_bus *video)
mutex_lock(&video->device_list_lock);
list_for_each_entry(dev, &video->video_device_list, entry) {
- if (!acpi_video_device_lcd_query_levels(dev, &levels))
+ if (!acpi_video_device_lcd_query_levels(dev->dev->handle,
&levels))
kfree(levels);
}
mutex_unlock(&video->device_list_lock);
diff --git a/drivers/thermal/int340x_thermal/int3406_thermal.c
b/drivers/thermal/int340x_thermal/int3406_thermal.c
index 13d431cbd29e..a578cd257db4 100644
--- a/drivers/thermal/int340x_thermal/int3406_thermal.c
+++ b/drivers/thermal/int340x_thermal/int3406_thermal.c
@@ -177,7 +177,7 @@ static int int3406_thermal_probe(struct platform_device
*pdev)
return -ENODEV;
d->raw_bd = bd;
- ret = acpi_video_get_levels(ACPI_COMPANION(&pdev->dev), &d->br);
+ ret = acpi_video_get_levels(ACPI_COMPANION(&pdev->dev), &d->br, NULL);
if (ret)
return ret;
diff --git a/include/acpi/video.h b/include/acpi/video.h
index 70a41f742037..5731ccb42585 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -51,7 +51,8 @@ extern void acpi_video_set_dmi_backlight_type(enum
acpi_backlight_type type);
*/
extern bool acpi_video_handles_brightness_key_presses(void);
extern int acpi_video_get_levels(struct acpi_device *device,
-struct acpi_video_device_brightness **dev_br);
+struct acpi_video_device_brightness **dev_br,
+int *pmax_level);
#else
static inline int acpi_video_register(void) { return 0; }
static inline void acpi_video_unregister(void) { return; }
@@ -72,7 +73,8 @@ static inline bool
acpi_video_handles_brightness_key_presses(void)
return false;
}
static inline int acpi_video_get_levels(struct acpi_device *device,
- struct acpi_video_device_brightness **dev_br)
+ struct acpi_video_device_brightness **dev_br,
+ int *pmax_level)
{
return -ENODEV;
}
--
2.5.5
Re: Builtin microcode does nothing..
On Sat, May 21, 2016 at 04:59:15AM +0200, Gabriel C wrote:
> Should this check not be the other way around ?
Actually, I've changed it to this:
/* try built-in microcode first */
if (load_builtin_intel_microcode(&cd))
/*
* clear start as we might've gotten an initrd too supplied by
* the boot loader, by mistake or simply forgotten there. That's
* fine, we ignore it since we've found builtin microcode.
*/
start = 0;
else {
#ifdef CONFIG_BLK_DEV_INITRD
static __initdata char ucode_name[] =
"kernel/x86/microcode/GenuineIntel.bin";
char *p = IS_ENABLED(CONFIG_X86_32) ? (char
*)__pa_nodebug(ucode_name)
: ucode_name;
cd = find_cpio_data(p, (void *)start, size, NULL);
if (!cd.data)
#endif
return UCODE_ERROR;
}
so we're trying the built-in microcode first.
Why, you ask?
Well, I'm following the intention here - the user has gone the length
and has explicitly configured builtin microcode into the kernel and
therefore we're looking for it first.
If we don't find it, we fall back to initrd. This way, even if you have
an initrd forgotten in the bootloader, we ignore it.
I'll ping you once I'm done testing here.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
Re: Builtin microcode does nothing..
On Sat, May 21, 2016 at 02:20:56AM +0200, Gabriel C wrote: > I got to test an kernel without CONFIG_BLK_DEV_INITRD and this way > does work. Good, this confirms what I've been debugging here too. Thanks. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Re: [REGRESSION] Headphones no longer working on MacPro6,1 with 4.4
On Sat, 21 May 2016 08:41:28 +0200,
Takashi Iwai wrote:
>
> On Sat, 21 May 2016 00:27:22 +0200,
> Laura Abbott wrote:
> >
> > On 03/15/2016 12:49 PM, Takashi Iwai wrote:
> > > On Tue, 15 Mar 2016 20:38:41 +0100,
> > > Takashi Iwai wrote:
> > >>
> > >> On Tue, 15 Mar 2016 20:23:09 +0100,
> > >> Laura Abbott wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> We received a bug report
> > >>> https://bugzilla.redhat.com/show_bug.cgi?id=1316119
> > >>> that the headphone jack on a MacPro6,1 stopped working on an upgrade
> > >>> from 4.3
> > >>> to 4.4.
> > >>>
> > >>> The bugzilla has the alsainfo, diffing shows that the Amp-Out vals are
> > >>> different. I tried a revert of 9f660a1c4 (" ALSA: hda/realtek - Fix
> > >>> silent
> > >>> headphone output on MacPro 4,1 (v2)") but that didn't help.
> > >>>
> > >>> Any ideas before asking for a bisect? Does this hardware version need
> > >>> to have
> > >>> the vref fixup as well?
> > >>
> > >> The obvious difference is the power state of each node. The recent
> > >> kernel has the finer power saving mode, and this might be the cause --
> > >> Mac has some secret that requires some node to be powered up.
> > >>
> > >> Try to power on each node via hda-verb. For example, to power up the
> > >> node 0x05, run like:
> > >> hda-verb /dev/snd/hwC0D0 0x05 SET_POWER 0x01
> > >
> > > Oops, a typo: the last argument must be 0x00, corresponding to D0:
> > > hda-verb /dev/snd/hwC0D0 0x05 SET_POWER 0x00
> > >
> > >
> >
> > Bringing this back again, the command that makes it work is
> >
> > hda-verb /dev/snd/hwC0D0 0x10 SET_POWER 0x00
>
> OK, then please give alsa-info.sh output (run with --no-upload option)
> at both working and non-working cases.
>
> > And this is still needed as of 4.5.4
>
> Of course, nothing has changed. I didn't hear from you since my
> previous question...
Wait, some relevant changes have been merged in 4.6.
Please check 4.6 at first to be sure. Then give alsa-info.sh
outputs.
Takashi
Re: sem_lock() vs qspinlocks
On Sat, May 21, 2016 at 12:01:00AM -0400, Waiman Long wrote: > On 05/20/2016 08:59 PM, Davidlohr Bueso wrote: > >On Fri, 20 May 2016, Peter Zijlstra wrote: > > > >>On Fri, May 20, 2016 at 04:47:43PM -0400, Waiman Long wrote: > >> > Similarly, and I know you hate it, but afaict, then semantically > queued_spin_is_contended() ought to be: > > - return atomic_read(&lock->val) & ~_Q_LOCKED_MASK; > + return atomic_read(&lock->val); > > >> > >>>Looking for contended lock, you need to consider the lock waiters > >>>also. So > >>>looking at the whole word is right. > >> > >>No, you _only_ need to look at the lock waiters. > > > >Is there anyway to do this in a single atomic_read? My thought is that > >otherwise > >we could further expand the race window Its inherently racy, arrival of a contender is subject to timing. No point in trying to fix what can't be fixed. > The existing code is doing that, but I would argue that including the > locked, but uncontended case isn't a bad idea. It _IS_ a bad idea, you get unconditional lock-breaks. Its the same as: #define spin_is_contended(l)(true) Because the only reason you're using spin_is_conteded() is if you're holding it.
Re: sem_lock() vs qspinlocks
On Fri, May 20, 2016 at 05:48:39PM -0700, Davidlohr Bueso wrote:
> On Fri, 20 May 2016, Linus Torvalds wrote:
>
>
> >Oh, I definitely agree on the stable part, and yes, the "splt things
> >up" model should come later if people agree that it's a good thing.
>
> The backporting part is quite nice, yes, but ultimately I think I prefer
> Linus' suggestion making things explicit, as opposed to consulting the
> spinlock
> implying barriers. I also hate to have an smp_mb() (particularly for
> spin_is_locked)
> given that we are not optimizing for the common case (regular mutual excl).
I'm confused; we _are_ optimizing for the common case. spin_is_locked()
is very unlikely to be used. And arguably should be used less in favour
of lockdep_assert_held().
> As opposed to spin_is_locked(), spin_unlock_wait() is perhaps more tempting
> to use for locking correctness. For example, taking a look at
> nf_conntrack_all_lock(),
> it too likes to get smart with spin_unlock_wait() -- also for finer graining
> purposes.
> While not identical to sems, it goes like:
>
> nf_conntrack_all_lock(): nf_conntrack_lock():
> spin_lock(B); spin_lock(A);
>
> if (bar) { // false
> bar = 1; ...
> }
> [loop ctrl-barrier]
> spin_unlock_wait(A);
> foo();foo();
>
> If the spin_unlock_wait() doesn't yet see the store that makes A visibly
> locked,
> we could end up with both threads in foo(), no?. (Although I'm unsure about
> that
> ctrl barrier and archs could fall into it. The point was to see in-tree
> examples
> of creative thinking with locking).
I'm tempted to put that trailing smp_rmb() in spin_unlock_wait() too;
because I suspect the netfilter code is broken without it.
And it seems intuitive to assume that if we return from unlock_wait() we
can indeed observe the critical section we waited on.
Something a little like so; but then for _all_ implementations.
---
include/asm-generic/qspinlock.h | 6 ++
include/linux/compiler.h| 13 -
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/include/asm-generic/qspinlock.h b/include/asm-generic/qspinlock.h
index 6bd05700d8c9..2f2eddd3e1f9 100644
--- a/include/asm-generic/qspinlock.h
+++ b/include/asm-generic/qspinlock.h
@@ -135,6 +135,12 @@ static inline void queued_spin_unlock_wait(struct
qspinlock *lock)
smp_mb();
while (atomic_read(&lock->val) & _Q_LOCKED_MASK)
cpu_relax();
+
+ /*
+* Match the RELEASE of the spin_unlock() we just observed. Thereby
+* ensuring we observe the whole critical section that ended.
+*/
+ smp_acquire__after_ctrl_dep();
}
#ifndef virt_spin_lock
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 793c0829e3a3..3c4bc8160947 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -304,21 +304,24 @@ static __always_inline void __write_once_size(volatile
void *p, void *res, int s
__u.__val; \
})
+/*
+ * A control dependency provides a LOAD->STORE order, the additional RMB
+ * provides LOAD->LOAD order, together they provide LOAD->{LOAD,STORE} order,
+ * aka. ACQUIRE.
+ */
+#define smp_acquire__after_ctrl_dep() smp_rmb()
+
/**
* smp_cond_acquire() - Spin wait for cond with ACQUIRE ordering
* @cond: boolean expression to wait for
*
* Equivalent to using smp_load_acquire() on the condition variable but employs
* the control dependency of the wait to reduce the barrier on many platforms.
- *
- * The control dependency provides a LOAD->STORE order, the additional RMB
- * provides LOAD->LOAD order, together they provide LOAD->{LOAD,STORE} order,
- * aka. ACQUIRE.
*/
#define smp_cond_acquire(cond) do {\
while (!(cond)) \
cpu_relax();\
- smp_rmb(); /* ctrl + rmb := acquire */ \
+ smp_acquire__after_ctrl_dep(); \
} while (0)
#endif /* __KERNEL__ */
