[PATCH] printk: Add caller information to printk() output.

2018-11-23 Thread Tetsuo Handa
Sometimes we want to print a whole line without being disturbed by
concurrent printk() from interrupts and/or other threads, for printk()
which does not end with '\n' can be disturbed.

We tried to allow printk() callers to explicitly use their local buffer
in order to make sure that a whole line is printed by one printk() call.
But it turned out that it is not realistic to ask printk() callers to
update their function arguments only for handling rare race conditions.
Also, like Steven Rostedt mentioned at [1], buffering sometimes makes
the situation worse. Therefore, we should not enforce buffering in a way
that requires modification of printk() callers.

I need to give up (at least for now) manipulating text which will be
passed to printk(). Instead, I propose allow saving caller information
as of calling log_store() and adding it as "T$thread_id" or
"C$processor_id" upon printing each line of printk() output.


Some examples for console output:

  [0.293000] [T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @ 2.80GHz 
(family: 0x6, model: 0x3c, stepping: 0x3)
  [0.299733] [T1] Performance Events: Haswell events, core PMU driver.
  [2.813808] [T35] clocksource: Switched to clocksource tsc
  [2.893984] [C0] random: fast init done

Some examples for /dev/kmsg output:

  6,21,0,-,from=T0;NX (Execute Disable) protection: active
  6,22,0,-,from=T0;SMBIOS 2.7 present.
  6,23,0,-,from=T0;DMI: VMware, Inc. VMware Virtual Platform/440BX Desktop 
Reference Platform, BIOS 6.00 05/19/2017
  6,24,0,-,from=T0;tsc: Fast TSC calibration using PIT
  6,25,0,-,from=T0;tsc: Detected 2793.552 MHz processor
  7,26,858,-,from=T0;e820: update [mem 0x-0x0fff] usable ==> 
reserved
  7,27,864,-,from=T0;e820: remove [mem 0x000a-0x000f] usable
  6,28,882,-,from=T0;last_pfn = 0x14 max_arch_pfn = 0x4
  7,29,953,-,from=T0;MTRR default type: uncachable
  6,512,753757,-,from=T1;PCI: Using host bridge windows from ACPI; if 
necessary, use "pci=nocrs" and report a bug
  6,513,757721,-,from=T1;ACPI: Enabled 4 GPEs in block 00 to 0F
  6,514,984829,-,from=T1;ACPI: PCI Root Bridge [PCI0] (domain  [bus 00-7f])
  6,515,985728,-,from=T1;acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig 
ASPM ClockPM Segments MSI]
   SUBSYSTEM=acpi
   DEVICE=+acpi:PNP0A03:00
  6,516,987723,-,from=T1;acpi PNP0A03:00: _OSC: platform does not support [AER 
LTR]
   SUBSYSTEM=acpi
   DEVICE=+acpi:PNP0A03:00
  6,517,989723,-,from=T1;acpi PNP0A03:00: _OSC: OS now controls [PCIeHotplug 
PME PCIeCapability]
   SUBSYSTEM=acpi
   DEVICE=+acpi:PNP0A03:00
  5,1493,2893984,-,from=C0;random: fast init done


[1] https://lkml.kernel.org/r/20181123105634.4956c...@vmware.local.home

Signed-off-by: Tetsuo Handa 
---
 kernel/printk/printk.c | 33 +
 lib/Kconfig.debug  | 17 +
 2 files changed, 50 insertions(+)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 5c2079d..5ace5ba 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -356,6 +356,9 @@ struct printk_log {
u8 facility;/* syslog facility */
u8 flags:5; /* internal record flags */
u8 level:3; /* syslog level */
+#ifdef CONFIG_PRINTK_FROM
+   u32 from_id;/* thread id or processor id */
+#endif
 }
 #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
 __packed __aligned(4)
@@ -609,6 +612,12 @@ static int log_store(int facility, int level,
 
/* fill message */
msg = (struct printk_log *)(log_buf + log_next_idx);
+#ifdef CONFIG_PRINTK_FROM
+   if (in_task())
+   msg->from_id = current->pid;
+   else
+   msg->from_id = 0x8000 + raw_smp_processor_id();
+#endif
memcpy(log_text(msg), text, text_len);
msg->text_len = text_len;
if (trunc_msg_len) {
@@ -690,9 +699,17 @@ static ssize_t msg_print_ext_header(char *buf, size_t size,
 
do_div(ts_usec, 1000);
 
+#ifdef CONFIG_PRINTK_FROM
+   return scnprintf(buf, size, "%u,%llu,%llu,%c,from=%c%u;",
+(msg->facility << 3) | msg->level, seq, ts_usec,
+msg->flags & LOG_CONT ? 'c' : '-',
+msg->from_id & 0x8000 ? 'C' : 'T',
+msg->from_id & ~0x8000);
+#else
return scnprintf(buf, size, "%u,%llu,%llu,%c;",
   (msg->facility << 3) | msg->level, seq, ts_usec,
   msg->flags & LOG_CONT ? 'c' : '-');
+#endif
 }
 
 static ssize_t msg_print_ext_body(char *buf, size_t size,
@@ -1037,6 +1054,9 @@ void log_buf_vmcoreinfo_setup(void)
VMCOREINFO_OFFSET(printk_log, len);
VMCOREINFO_OFFSET(printk_log, text_len);
VMCOREINFO_OFFSET(printk_log, dict_len);
+#ifdef CONFIG_PRINTK_FROM
+   VMCOREINFO_OFFSET(printk_log, from_id);
+#endif
 }
 #endif
 
@@ -1242,6 +1262,16 @@ static size_t print_time(u64 ts, char *buf)
   (unsigned long)ts, re

[PATCH] ALSA: pcm: Fix starvation on down_write_nonblock()

2018-11-23 Thread Chanho Min
Commit 67ec1072b053 (ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream)
fixes deadlock for non-atomic PCM stream. But, This patch causes antother stuck.
If writer is RT thread and reader is a normal thread, the reader thread will
be difficult to get scheduled. It may not give chance to release read locks
and writer gets stuck for a long time or forever if they are pinned to single
cpu.

To fix this, The writer gives reader a chance to be scheduled by using the
minimum msleep() instaed of spinning. This is for concept, We may need to
change the function name and comments or suggest another approach.

Signed-off-by: Chanho Min 
---
 sound/core/pcm_native.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 66c90f4..88d4aab 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -96,7 +96,7 @@ static DECLARE_RWSEM(snd_pcm_link_rwsem);
 static inline void down_write_nonblock(struct rw_semaphore *lock)
 {
while (!down_write_trylock(lock))
-   cond_resched();
+   msleep(1);
 }
 
 #define PCM_LOCK_DEFAULT   0
-- 
2.1.4



Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-23 Thread Jens Axboe
On 11/21/18 11:16 AM, Linus Torvalds wrote:
> On Wed, Nov 21, 2018 at 9:27 AM Linus Torvalds
>  wrote:
>>
>> It would be interesting to know exactly which copy it is that matters
>> so much...  *inlining* the erms case might show that nicely in
>> profiles.
> 
> Side note: the fact that Jens' patch (which I don't like in that form)
> allegedly shrunk the resulting kernel binary would seem to indicate
> that there's a *lot* of compile-time constant-sized memcpy calls that
> we are missing, and that fall back to copy_user_generic().

Other kind of side note... This also affects memset(), which does
rep stosb if we have ERMS if any size memset. I noticed this from
sg_init_table(), which does a memset of the table. For my kind of
testing, the entry size is small. The below, too, reduces memset()
overhead by 50% here for me.

diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S
index 9bc861c71e75..bad0fdb9ddcd 100644
--- a/arch/x86/lib/memset_64.S
+++ b/arch/x86/lib/memset_64.S
@@ -60,6 +60,8 @@ EXPORT_SYMBOL(__memset)
  * rax   original destination
  */
 ENTRY(memset_erms)
+   cmpl $128,%edx
+   jb memset_orig
movq %rdi,%r9
movb %sil,%al
movq %rdx,%rcx

-- 
Jens Axboe



Re: [RFC][PATCH 02/14] fgraph: Have set_graph_notrace only affect function_graph tracer

2018-11-23 Thread Namhyung Kim
On Sat, Nov 24, 2018 at 2:37 AM Steven Rostedt  wrote:
>
> On Fri, 23 Nov 2018 09:01:18 +0900
> Namhyung Kim  wrote:
>
> > Acked-by: Namhyung Kim 
>
> Thanks Namhyung!

It'd be nice if you cc me for the whole patchset (and other tracing
patches) next time.

Thanks,
Namhyung


Re: [RFC][PATCH 11/14] function_graph: Convert ret_stack to a series of longs

2018-11-23 Thread Joel Fernandes
On Wed, Nov 21, 2018 at 08:27:19PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" 
> 
> In order to make it possible to have multiple callbacks registered with the
> function_graph tracer, the retstack needs to be converted from an array of
> ftrace_ret_stack structures to an array of longs. This will allow to store
> the list of callbacks on the stack for the return side of the functions.
> 
> [ Note, this currently breaks architectures that access the ret_stack of a
>   task to handle unwinding when 'return_to_handler' is on the stack ]
> 
> Signed-off-by: Steven Rostedt (VMware) 
> ---
>  include/linux/sched.h |   2 +-
>  kernel/trace/fgraph.c | 123 +++---
>  2 files changed, 70 insertions(+), 55 deletions(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index d6183a55e8eb..71a084a300da 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1119,7 +1119,7 @@ struct task_struct {
>   int curr_ret_depth;
>  
>   /* Stack of return addresses for return function tracing: */
> - struct ftrace_ret_stack *ret_stack;
> + unsigned long   *ret_stack;
>  
>   /* Timestamp for last schedule: */
>   unsigned long long  ftrace_timestamp;
> diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
> index 9b85638ecded..1389fe39f64c 100644
> --- a/kernel/trace/fgraph.c
> +++ b/kernel/trace/fgraph.c
> @@ -23,6 +23,17 @@
>  #define ASSIGN_OPS_HASH(opsname, val)
>  #endif
>  
> +#define FGRAPH_RET_SIZE (sizeof(struct ftrace_ret_stack))
> +#define FGRAPH_RET_INDEX (ALIGN(FGRAPH_RET_SIZE, sizeof(long)) / 
> sizeof(long))
> +#define SHADOW_STACK_SIZE (FTRACE_RETFUNC_DEPTH * FGRAPH_RET_SIZE)
> +#define SHADOW_STACK_INDEX   \
> + (ALIGN(SHADOW_STACK_SIZE, sizeof(long)) / sizeof(long))
> +#define SHADOW_STACK_MAX_INDEX (SHADOW_STACK_INDEX - FGRAPH_RET_INDEX)
> +
> +#define RET_STACK(t, index) ((struct ftrace_ret_stack 
> *)(&(t)->ret_stack[index]))
> +#define RET_STACK_INC(c) ({ c += FGRAPH_RET_INDEX; })
> +#define RET_STACK_DEC(c) ({ c -= FGRAPH_RET_INDEX; })
> +
[...]
> @@ -514,7 +531,7 @@ void ftrace_graph_init_task(struct task_struct *t)
>  
>  void ftrace_graph_exit_task(struct task_struct *t)
>  {
> - struct ftrace_ret_stack *ret_stack = t->ret_stack;
> + unsigned long *ret_stack = t->ret_stack;
>  
>   t->ret_stack = NULL;
>   /* NULL must become visible to IRQs before we free it: */
> @@ -526,12 +543,10 @@ void ftrace_graph_exit_task(struct task_struct *t)
>  /* Allocate a return stack for each task */
>  static int start_graph_tracing(void)
>  {
> - struct ftrace_ret_stack **ret_stack_list;
> + unsigned long **ret_stack_list;
>   int ret, cpu;
>  
> - ret_stack_list = kmalloc_array(FTRACE_RETSTACK_ALLOC_SIZE,
> -sizeof(struct ftrace_ret_stack *),
> -GFP_KERNEL);
> + ret_stack_list = kmalloc(SHADOW_STACK_SIZE, GFP_KERNEL);
>  

I had dumped the fgraph size related macros to understand the patch better, I
got:
[0.909528] val of FGRAPH_RET_SIZE is 40
[0.910250] val of FGRAPH_RET_INDEX is 5
[0.910866] val of FGRAPH_ARRAY_SIZE is 16
[0.911488] val of FGRAPH_ARRAY_MASK is 255
[0.912134] val of FGRAPH_MAX_INDEX is 16
[0.912751] val of FGRAPH_INDEX_SHIFT is 8
[0.913382] val of FGRAPH_FRAME_SIZE is 168
[0.914033] val of FGRAPH_FRAME_INDEX is 21
  FTRACE_RETFUNC_DEPTH is 50
[0.914686] val of SHADOW_STACK_SIZE is 8400

I had a concern about memory overhead per-task. It seems the total memory
needed per task for the stack is 8400 bytes (with my configuration with
FUNCTION_PROFILE
turned off).

Where as before it would be 32 * 40 = 1280 bytes. That looks like ~7 times
more than before.

On my system with ~4000 threads, that becomes ~32MB which seems a bit
wasteful especially if there was only one or 2 function graph callbacks
registered and most of the callback array in the stack isn't used.

Could we make the array size configurable at compile time and start it with a
small number like 4 or 6?

Also for patches 1 through 10:
Reviewed-by: Joel Fernandes (Google) 

thanks,

 - Joel



Re: test_kmod: BUG on module removal

2018-11-23 Thread Luis Chamberlain
On Sat, Oct 13, 2018 at 10:59:46AM -0700, Randy Dunlap wrote:
> 4.19-rc7, on x86_64:
> 
> modprobe test_kmod; rmmod test_kmod
> 
> [  199.033143] calling  test_kmod_init+0x0/0x1000 [test_kmod] @ 1704
> [  199.034636] misc test_kmod0: interface ready
> [  199.035468] initcall test_kmod_init+0x0/0x1000 [test_kmod] returned 0 
> after 1210 usecs
> [  206.597737] misc test_kmod0: Ending request_module() tests
> [  206.598698] misc test_kmod0: removing interface
> [  206.600052] BUG: unable to handle kernel paging request at e150a6032048
> [  206.601224] PGD 0 P4D 0 
> [  206.601642] Oops:  [#1] PREEMPT SMP PTI
> [  206.602309] CPU: 3 PID: 1707 Comm: rmmod Not tainted 4.19.0-rc7mod #2
> [  206.603479] Hardware name: TOSHIBA PORTEGE R835/Portable PC, BIOS Version 
> 4.10   01/08/2013
> [  206.604899] RIP: 0010:kfree+0x43/0x180

Thanks, I've fixed this, and sent a patch.

  Luis


[PATCH] test_kmod: fix rmmod double free

2018-11-23 Thread Luis Chamberlain
We double free the misc device string twice on rmmod, fix this.
Without this we cannot remove the module without crashing.

Cc:   # for v4.12 and up
Reported-by: Randy Dunlap 
Signed-off-by: Luis Chamberlain 
---
 lib/test_kmod.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/test_kmod.c b/lib/test_kmod.c
index e3ddd836491f..d82d022111e0 100644
--- a/lib/test_kmod.c
+++ b/lib/test_kmod.c
@@ -1214,7 +1214,6 @@ void unregister_test_dev_kmod(struct kmod_test_device 
*test_dev)
 
dev_info(test_dev->dev, "removing interface\n");
misc_deregister(&test_dev->misc_dev);
-   kfree(&test_dev->misc_dev.name);
 
mutex_unlock(&test_dev->config_mutex);
mutex_unlock(&test_dev->trigger_mutex);
-- 
2.19.1



Re: [PATCH v3] mm: Create the new vm_fault_t type

2018-11-23 Thread Souptick Joarder
On Thu, Nov 15, 2018 at 7:17 AM Mike Rapoport  wrote:
>
> On Tue, Nov 06, 2018 at 05:36:42PM +0530, Souptick Joarder wrote:
> > Page fault handlers are supposed to return VM_FAULT codes,
> > but some drivers/file systems mistakenly return error
> > numbers. Now that all drivers/file systems have been converted
> > to use the vm_fault_t return type, change the type definition
> > to no longer be compatible with 'int'. By making it an unsigned
> > int, the function prototype becomes incompatible with a function
> > which returns int. Sparse will detect any attempts to return a
> > value which is not a VM_FAULT code.
> >
> > VM_FAULT_SET_HINDEX and VM_FAULT_GET_HINDEX values are changed
> > to avoid conflict with other VM_FAULT codes.
> >
> > Signed-off-by: Souptick Joarder 
>
> For the docs part
> Reviewed-by: Mike Rapoport 
>
> > ---
> > v2: Updated the change log and corrected the document part.
> > name added to the enum that kernel-doc able to parse it.
> >
> > v3: Corrected the documentation.

If no further comment, can we get this patch in queue for 4.21 ?

> >
> >  include/linux/mm.h   | 46 --
> >  include/linux/mm_types.h | 73 
> > +++-
> >  2 files changed, 72 insertions(+), 47 deletions(-)
> >
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index fcf9cc9..511a3ce 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -1267,52 +1267,6 @@ static inline void clear_page_pfmemalloc(struct page 
> > *page)
> >  }
> >
> >  /*
> > - * Different kinds of faults, as returned by handle_mm_fault().
> > - * Used to decide whether a process gets delivered SIGBUS or
> > - * just gets major/minor fault counters bumped up.
> > - */
> > -
> > -#define VM_FAULT_OOM 0x0001
> > -#define VM_FAULT_SIGBUS  0x0002
> > -#define VM_FAULT_MAJOR   0x0004
> > -#define VM_FAULT_WRITE   0x0008  /* Special case for get_user_pages */
> > -#define VM_FAULT_HWPOISON 0x0010 /* Hit poisoned small page */
> > -#define VM_FAULT_HWPOISON_LARGE 0x0020  /* Hit poisoned large page. Index 
> > encoded in upper bits */
> > -#define VM_FAULT_SIGSEGV 0x0040
> > -
> > -#define VM_FAULT_NOPAGE  0x0100  /* ->fault installed the pte, not 
> > return page */
> > -#define VM_FAULT_LOCKED  0x0200  /* ->fault locked the returned page */
> > -#define VM_FAULT_RETRY   0x0400  /* ->fault blocked, must retry */
> > -#define VM_FAULT_FALLBACK 0x0800 /* huge page fault failed, fall back 
> > to small */
> > -#define VM_FAULT_DONE_COW   0x1000   /* ->fault has fully handled COW */
> > -#define VM_FAULT_NEEDDSYNC  0x2000   /* ->fault did not modify page tables
> > -  * and needs fsync() to complete (for
> > -  * synchronous page faults in DAX) */
> > -
> > -#define VM_FAULT_ERROR   (VM_FAULT_OOM | VM_FAULT_SIGBUS | 
> > VM_FAULT_SIGSEGV | \
> > -  VM_FAULT_HWPOISON | VM_FAULT_HWPOISON_LARGE | \
> > -  VM_FAULT_FALLBACK)
> > -
> > -#define VM_FAULT_RESULT_TRACE \
> > - { VM_FAULT_OOM, "OOM" }, \
> > - { VM_FAULT_SIGBUS,  "SIGBUS" }, \
> > - { VM_FAULT_MAJOR,   "MAJOR" }, \
> > - { VM_FAULT_WRITE,   "WRITE" }, \
> > - { VM_FAULT_HWPOISON,"HWPOISON" }, \
> > - { VM_FAULT_HWPOISON_LARGE,  "HWPOISON_LARGE" }, \
> > - { VM_FAULT_SIGSEGV, "SIGSEGV" }, \
> > - { VM_FAULT_NOPAGE,  "NOPAGE" }, \
> > - { VM_FAULT_LOCKED,  "LOCKED" }, \
> > - { VM_FAULT_RETRY,   "RETRY" }, \
> > - { VM_FAULT_FALLBACK,"FALLBACK" }, \
> > - { VM_FAULT_DONE_COW,"DONE_COW" }, \
> > - { VM_FAULT_NEEDDSYNC,   "NEEDDSYNC" }
> > -
> > -/* Encode hstate index for a hwpoisoned large page */
> > -#define VM_FAULT_SET_HINDEX(x) ((x) << 12)
> > -#define VM_FAULT_GET_HINDEX(x) (((x) >> 12) & 0xf)
> > -
> > -/*
> >   * Can be called by the pagefault handler when it gets a VM_FAULT_OOM.
> >   */
> >  extern void pagefault_out_of_memory(void);
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 5ed8f62..cb25016 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -22,7 +22,6 @@
> >  #endif
> >  #define AT_VECTOR_SIZE (2*(AT_VECTOR_SIZE_ARCH + AT_VECTOR_SIZE_BASE + 1))
> >
> > -typedef int vm_fault_t;
> >
> >  struct address_space;
> >  struct mem_cgroup;
> > @@ -609,6 +608,78 @@ static inline bool mm_tlb_flush_nested(struct 
> > mm_struct *mm)
> >
> >  struct vm_fault;
> >
> > +/**
> > + * typedef vm_fault_t - Return type for page fault handlers.
> > + *
> > + * Page fault handlers return a bitmask of %VM_FAULT values.
> > + */
> > +typedef __bitwise unsigned int vm_fault_t;
> > +
> > +/**
> > + * enum vm_fault_reason - Page fault handlers return a bitmask of
> > + * these values to tell the core VM 

Re: [tip:timers/core] time: Add SPDX license identifiers

2018-11-23 Thread Joe Perches
On Fri, 2018-11-23 at 03:19 -0800, tip-bot for Thomas Gleixner wrote:
> The SPDX
> identifier is a legally binding shorthand, which can be used instead of the
> full boiler plate text.

Is the "legally binding shorthand" actually proven anywhere?
I am not aware of any case law for this.




Re: [PATCH] printk: Make printk_emit() local function.

2018-11-23 Thread Tetsuo Handa
Well, moving "__printf(3, 4) __cold" to before
"int devkmsg_emit(int facility, int level, const char *fmt, ...) {"
seems to be working. I did not know...

>From 86fff21e5fef6d3f7970cf5c07a54a907e582b52 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Sat, 24 Nov 2018 13:05:25 +0900
Subject: [PATCH v2] printk: Make printk_emit() local function.

printk_emit() is called from only devkmsg_write() in the same file.
Save object size by making it a local function.

Signed-off-by: Tetsuo Handa 
---
 include/linux/printk.h |  5 -
 kernel/printk/printk.c | 30 ++
 2 files changed, 14 insertions(+), 21 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index cf3eccf..55aa969 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -166,11 +166,6 @@ int vprintk_emit(int facility, int level,
 asmlinkage __printf(1, 0)
 int vprintk(const char *fmt, va_list args);
 
-asmlinkage __printf(5, 6) __cold
-int printk_emit(int facility, int level,
-   const char *dict, size_t dictlen,
-   const char *fmt, ...);
-
 asmlinkage __printf(1, 2) __cold
 int printk(const char *fmt, ...);
 
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 1b2a029..5c2079d 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -752,6 +752,19 @@ struct devkmsg_user {
char buf[CONSOLE_EXT_LOG_MAX];
 };
 
+static __printf(3, 4) __cold
+int devkmsg_emit(int facility, int level, const char *fmt, ...)
+{
+   va_list args;
+   int r;
+
+   va_start(args, fmt);
+   r = vprintk_emit(facility, level, NULL, 0, fmt, args);
+   va_end(args);
+
+   return r;
+}
+
 static ssize_t devkmsg_write(struct kiocb *iocb, struct iov_iter *from)
 {
char *buf, *line;
@@ -810,7 +823,7 @@ static ssize_t devkmsg_write(struct kiocb *iocb, struct 
iov_iter *from)
}
}
 
-   printk_emit(facility, level, NULL, 0, "%s", line);
+   devkmsg_emit(facility, level, "%s", line);
kfree(buf);
return ret;
 }
@@ -1935,21 +1948,6 @@ asmlinkage int vprintk(const char *fmt, va_list args)
 }
 EXPORT_SYMBOL(vprintk);
 
-asmlinkage int printk_emit(int facility, int level,
-  const char *dict, size_t dictlen,
-  const char *fmt, ...)
-{
-   va_list args;
-   int r;
-
-   va_start(args, fmt);
-   r = vprintk_emit(facility, level, dict, dictlen, fmt, args);
-   va_end(args);
-
-   return r;
-}
-EXPORT_SYMBOL(printk_emit);
-
 int vprintk_default(const char *fmt, va_list args)
 {
int r;
-- 
1.8.3.1



Re: [PATCH V2] exportfs: do not read dentry after free

2018-11-23 Thread J. Bruce Fields
On Fri, Nov 23, 2018 at 03:56:33PM +0800, Pan Bian wrote:
> The function dentry_connected calls dput(dentry) to drop the previously
> acquired reference to dentry. In this case, dentry can be released.
> After that, IS_ROOT(dentry) checks the condition
> (dentry == dentry->d_parent), which may result in a use-after-free bug.
> This patch directly compares dentry with its parent obtained before
> dropping the reference.

Looks right to me, thanks.--b.

> 
> Fixes: a056cc8934c("exportfs: stop retrying once we race with
> rename/remove")
> 
> Signed-off-by: Pan Bian 
> 
> ---
> V2: get rid of the comment
> 
> ---
>  fs/exportfs/expfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
> index 645158d..a69aaf5 100644
> --- a/fs/exportfs/expfs.c
> +++ b/fs/exportfs/expfs.c
> @@ -77,7 +77,7 @@ static bool dentry_connected(struct dentry *dentry)
>   struct dentry *parent = dget_parent(dentry);
>  
>   dput(dentry);
> - if (IS_ROOT(dentry)) {
> + if (dentry == parent) {
>   dput(parent);
>   return false;
>   }
> -- 
> 2.7.4
> 


Re: Official Linux system wrapper library?

2018-11-23 Thread David Newall

On 24/11/18 1:53 am, Szabolcs Nagy wrote:

On 23/11/18 14:11, David Newall wrote:

On 24/11/18 12:04 am, Florian Weimer wrote:

But socketcall does not exist on all architectures.  Neither does
getpid, it's called getxpid on some architectures.
...
I think it would be a poor approach to expose application developers to
these portability issues.  We need to abstract over these differences at
a certain layer, and applications are too late.

Interesting.  I think the opposite.  I think exposing the OS's interfaces is 
exactly what a c-library should do.  It might also provide
alternative interfaces that work consistently across different platforms, but 
in addition to, not instead of the OS interface.

you don't understand the point of the c language if you think so.


I understand the point of C, thank you very much, and we're talking 
about the C library, not the language.  I don't understand the point of 
your rudeness.




Re: [alsa-devel] [RFC PATCH 1/6] ASoC: Intel: Skylake: Add CFL-S support

2018-11-23 Thread Pierre-Louis Bossart



On 11/22/18 3:56 AM, Andy Shevchenko wrote:

On Wed, Nov 21, 2018 at 11:17:41PM +0100, Takashi Iwai wrote:

On Wed, 21 Nov 2018 18:38:41 +0100, Andy Shevchenko wrote:

Compare:

/* CFL */
{ PCI_DEVICE(0x8086, 0xa348),
.driver_data = (unsigned long)&snd_soc_acpi_intel_cnl_machines},

to something like:

#define PCI_DEVICE_ID_INTEL_AUDIO_CFL   0xa348
...

{PCI_DEVICE_DATA(INTEL, AUDIO_CFL, &snd_soc_acpi_intel_cnl_machines)},

The former gives a better grep-ability, though.

I have no big preference over two, just want to mention that both have
merits and demerits.

True.
So, up to you, guys, what to choose.


I am leaning to leave the PCI stuff alone for now. If we change the PCI 
definitions I'd like to do it on the SKL and legacy sides at the same 
time, to avoid multiple definitions or redundancies.


However I like your suggestion for the macros on the other patch so will 
change the code.


Thanks for the reviews!





[RFC PATCH v3 00/14] m68k: Drop arch_gettimeoffset and adopt clocksource API

2018-11-23 Thread Finn Thain
This series removes "select ARCH_USES_GETTIMEOFFSET" from arch/m68k
and converts users of arch_gettimeoffset to the clocksource API.
Various bugs are fixed along the way.

Those platforms which do not actually implement arch_gettimeoffset
(apollo, q40, sun3, sun3x) use the "jiffies" clocksource by default.

The difficulty with these patches is the use of the timer interrupt to
update the counter for the clock source. The timer interrupt handler races
with clocksource read method, and both of those functions race with the
timer hardware.

Hence, more testing and code review would be appreciated.

Changed since v2:
 - Reinstated patch "m68k: hp300: Convert to clocksource API", and added
a new patch "m68k: hp300: Handle timer counter overflow" to address 
monotonicity issues.
 - Omitted a minor cleanup patch which may be merged independently.
 - Various other changes summarized in the relevant patches.

Changed since v1:
 - Dropped patches 1/13 and 2/13. These were a failed attempt to fix
5cfc8ee0bb51 and 4ad4c76b7afb. By adopting the clocksource API we can fix
this issue in mainline. By backporting this series we can fix it for -stable
(for m68k at least).
 - Dropped patch "m68k: hp300: Convert to clocksource API" and added
patch "m68k: hp300: Remove hp300_gettimeoffset".
 - Added a new patch to address an old m68k bug pointed out by Thomas
Gleixner. The bug can arise when a timer interrupt handler gets interrupted.
 - Added new patches to address old mvme16x and mvme147 bugs pointed out
by Thomas Gleixner. The bug could cause the clock to jump backwards.
 - Various other changes summarized in the relevant patches.


Finn Thain (14):
  m68k: Call timer_interrupt() with interrupts disabled
  m68k: mac: Fix VIA timer counter accesses
  m68k: apollo, q40, sun3, sun3x: Remove arch_gettimeoffset
implementations
  m68k: Drop ARCH_USES_GETTIMEOFFSET
  m68k: amiga: Convert to clocksource API
  m68k: atari: Convert to clocksource API
  m68k: bvme6000: Convert to clocksource API
  m68k: hp300: Convert to clocksource API
  m68k: hp300: Handle timer counter overflow
  m68k: mac: Convert to clocksource API
  m68k: mvme147: Convert to clocksource API
  m68k: mvme147: Handle timer counter overflow
  m68k: mvme16x: Convert to clocksource API
  m68k: mvme16x: Handle timer counter overflow

 arch/m68k/Kconfig |   1 -
 arch/m68k/amiga/cia.c |   9 ++
 arch/m68k/amiga/config.c  |  67 +-
 arch/m68k/apollo/config.c |   7 --
 arch/m68k/atari/ataints.c |   4 +-
 arch/m68k/atari/config.c  |   2 -
 arch/m68k/atari/time.c|  70 +++
 arch/m68k/bvme6000/config.c   |  76 ++--
 arch/m68k/hp300/config.c  |   1 -
 arch/m68k/hp300/time.c|  73 +++
 arch/m68k/hp300/time.h|   1 -
 arch/m68k/include/asm/mvme147hw.h |   2 +-
 arch/m68k/mac/config.c|   3 -
 arch/m68k/mac/via.c   | 145 --
 arch/m68k/mvme147/config.c|  73 ++-
 arch/m68k/mvme16x/config.c|  97 ++--
 arch/m68k/q40/config.c|   9 --
 arch/m68k/q40/q40ints.c   |  19 ++--
 arch/m68k/sun3/config.c   |   2 -
 arch/m68k/sun3/intersil.c |   7 --
 arch/m68k/sun3/sun3ints.c |   3 +
 arch/m68k/sun3x/config.c  |   1 -
 arch/m68k/sun3x/time.c|  21 +++--
 arch/m68k/sun3x/time.h|   1 -
 24 files changed, 449 insertions(+), 245 deletions(-)

-- 
2.18.1



[RFC PATCH v3 01/14] m68k: Call timer_interrupt() with interrupts disabled

2018-11-23 Thread Finn Thain
Some platforms execute their timer handler with the interrupt priority
level set below 6. That means the handler could be interrupted by another
driver and this could lead to re-entry of the timer core.

Avoid this by use of local_irq_save/restore for timer interrupt dispatch.
This provides mutual exclusion around the timer interrupt flag access
which is needed later in this series for the clocksource conversion.

Reported-by: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/alpine.deb.2.21.1811131407120.2...@nanos.tec.linutronix.de
Signed-off-by: Finn Thain 
---
I've only checked 680x0 MMU platforms for this issue.

Changed since v2:
 - Don't waste an iteration of the for loop in cia_handler().
 - Remove q40_timer_routine for better consistency with other platforms.
 - Minor cleanup.
---
 arch/m68k/amiga/cia.c   |  9 +
 arch/m68k/atari/ataints.c   |  4 ++--
 arch/m68k/atari/time.c  | 15 ++-
 arch/m68k/bvme6000/config.c | 20 ++--
 arch/m68k/hp300/time.c  | 10 --
 arch/m68k/mac/via.c | 17 +
 arch/m68k/mvme147/config.c  | 18 ++
 arch/m68k/mvme16x/config.c  | 21 +++--
 arch/m68k/q40/q40ints.c | 19 +++
 arch/m68k/sun3/sun3ints.c   |  3 +++
 arch/m68k/sun3x/time.c  | 16 ++--
 11 files changed, 105 insertions(+), 47 deletions(-)

diff --git a/arch/m68k/amiga/cia.c b/arch/m68k/amiga/cia.c
index 2081b8cd5591..b9aee983e6f4 100644
--- a/arch/m68k/amiga/cia.c
+++ b/arch/m68k/amiga/cia.c
@@ -88,10 +88,19 @@ static irqreturn_t cia_handler(int irq, void *dev_id)
struct ciabase *base = dev_id;
int mach_irq;
unsigned char ints;
+   unsigned long flags;
 
+   /* Interrupts get disabled while the timer irq flag is cleared and
+* the timer interrupt serviced.
+*/
mach_irq = base->cia_irq;
+   local_irq_save(flags);
ints = cia_set_irq(base, CIA_ICR_ALL);
amiga_custom.intreq = base->int_mask;
+   if (ints & 1)
+   generic_handle_irq(mach_irq);
+   local_irq_restore(flags);
+   mach_irq++, ints >>= 1;
for (; ints; mach_irq++, ints >>= 1) {
if (ints & 1)
generic_handle_irq(mach_irq);
diff --git a/arch/m68k/atari/ataints.c b/arch/m68k/atari/ataints.c
index 3d2b63bedf05..56f02ea2c248 100644
--- a/arch/m68k/atari/ataints.c
+++ b/arch/m68k/atari/ataints.c
@@ -142,7 +142,7 @@ struct mfptimerbase {
.name   = "MFP Timer D"
 };
 
-static irqreturn_t mfptimer_handler(int irq, void *dev_id)
+static irqreturn_t mfp_timer_d_handler(int irq, void *dev_id)
 {
struct mfptimerbase *base = dev_id;
int mach_irq;
@@ -344,7 +344,7 @@ void __init atari_init_IRQ(void)
st_mfp.tim_ct_cd = (st_mfp.tim_ct_cd & 0xf0) | 0x6;
 
/* request timer D dispatch handler */
-   if (request_irq(IRQ_MFP_TIMD, mfptimer_handler, IRQF_SHARED,
+   if (request_irq(IRQ_MFP_TIMD, mfp_timer_d_handler, IRQF_SHARED,
stmfp_base.name, &stmfp_base))
pr_err("Couldn't register %s interrupt\n", stmfp_base.name);
 
diff --git a/arch/m68k/atari/time.c b/arch/m68k/atari/time.c
index 9cca64286464..fafa20f75ab9 100644
--- a/arch/m68k/atari/time.c
+++ b/arch/m68k/atari/time.c
@@ -24,6 +24,18 @@
 DEFINE_SPINLOCK(rtc_lock);
 EXPORT_SYMBOL_GPL(rtc_lock);
 
+static irqreturn_t mfp_timer_c_handler(int irq, void *dev_id)
+{
+   irq_handler_t timer_routine = dev_id;
+   unsigned long flags;
+
+   local_irq_save(flags);
+   timer_routine(0, NULL);
+   local_irq_restore(flags);
+
+   return IRQ_HANDLED;
+}
+
 void __init
 atari_sched_init(irq_handler_t timer_routine)
 {
@@ -32,7 +44,8 @@ atari_sched_init(irq_handler_t timer_routine)
 /* start timer C, div = 1:100 */
 st_mfp.tim_ct_cd = (st_mfp.tim_ct_cd & 15) | 0x60;
 /* install interrupt service routine for MFP Timer C */
-if (request_irq(IRQ_MFP_TIMC, timer_routine, 0, "timer", timer_routine))
+if (request_irq(IRQ_MFP_TIMC, mfp_timer_c_handler, 0, "timer",
+timer_routine))
pr_err("Couldn't register timer interrupt\n");
 }
 
diff --git a/arch/m68k/bvme6000/config.c b/arch/m68k/bvme6000/config.c
index 143ee9fa3893..0e5efed4da86 100644
--- a/arch/m68k/bvme6000/config.c
+++ b/arch/m68k/bvme6000/config.c
@@ -44,11 +44,6 @@ extern int bvme6000_hwclk (int, struct rtc_time *);
 extern void bvme6000_reset (void);
 void bvme6000_set_vectors (void);
 
-/* Save tick handler routine pointer, will point to xtime_update() in
- * kernel/timer/timekeeping.c, called via bvme6000_process_int() */
-
-static irq_handler_t tick_handler;
-
 
 int __init bvme6000_parse_bootinfo(const struct bi_record *bi)
 {
@@ -157,12 +152,18 @@ irqreturn_t bvme6000_abort_int (int irq, void *dev_id)
 
 static irqreturn_t bvme6000_timer_int (int irq, void *dev_id)
 {
+irq_handler_t timer_routine = dev_id;
+unsigned long fl

[RFC PATCH v3 02/14] m68k: mac: Fix VIA timer counter accesses

2018-11-23 Thread Finn Thain
This resolves some bugs that affect VIA timer counter accesses.
Avoid lost interrupts caused by reading the counter low byte register.
Make allowance for the fact that the counter will be decremented to
0x before being reloaded.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Finn Thain 
---
Changed since v2:
 - Don't check for timer interrupt in mac_gettimeoffset() when the timer is
about to be reloaded.

Changed since v1:
 - Test the timer interrupt flag unconditionally.
 - Drop some extraneous clean up.
 - Don't try to recover from lost timer interrupts. Don't lose them
in the first place. That means giving up on the timer counter low byte.
The extra precision is probably not worth the extra complexity and
I couldn't make it work anyway.
---
 arch/m68k/mac/via.c | 102 +++-
 1 file changed, 53 insertions(+), 49 deletions(-)

diff --git a/arch/m68k/mac/via.c b/arch/m68k/mac/via.c
index f6df83ba2227..f1f39ecf84c2 100644
--- a/arch/m68k/mac/via.c
+++ b/arch/m68k/mac/via.c
@@ -54,16 +54,6 @@ static __u8 rbv_clear;
 
 static int gIER,gIFR,gBufA,gBufB;
 
-/*
- * Timer defs.
- */
-
-#define TICK_SIZE  1
-#define MAC_CLOCK_TICK (783300/HZ) /* ticks per HZ */
-#define MAC_CLOCK_LOW  (MAC_CLOCK_TICK&0xFF)
-#define MAC_CLOCK_HIGH (MAC_CLOCK_TICK>>8)
-
-
 /*
  * On Macs with a genuine VIA chip there is no way to mask an individual slot
  * interrupt. This limitation also seems to apply to VIA clone logic cores in
@@ -267,22 +257,6 @@ void __init via_init(void)
}
 }
 
-/*
- * Start the 100 Hz clock
- */
-
-void __init via_init_clock(irq_handler_t func)
-{
-   via1[vACR] |= 0x40;
-   via1[vT1LL] = MAC_CLOCK_LOW;
-   via1[vT1LH] = MAC_CLOCK_HIGH;
-   via1[vT1CL] = MAC_CLOCK_LOW;
-   via1[vT1CH] = MAC_CLOCK_HIGH;
-
-   if (request_irq(IRQ_MAC_TIMER_1, func, 0, "timer", func))
-   pr_err("Couldn't register %s interrupt\n", "timer");
-}
-
 /*
  * Debugging dump, used in various places to see what's going on.
  */
@@ -310,29 +284,6 @@ void via_debug_dump(void)
}
 }
 
-/*
- * This is always executed with interrupts disabled.
- *
- * TBI: get time offset between scheduling timer ticks
- */
-
-u32 mac_gettimeoffset(void)
-{
-   unsigned long ticks, offset = 0;
-
-   /* read VIA1 timer 2 current value */
-   ticks = via1[vT1CL] | (via1[vT1CH] << 8);
-   /* The probability of underflow is less than 2% */
-   if (ticks > MAC_CLOCK_TICK - MAC_CLOCK_TICK / 50)
-   /* Check for pending timer interrupt in VIA1 IFR */
-   if (via1[vIFR] & 0x40) offset = TICK_SIZE;
-
-   ticks = MAC_CLOCK_TICK - ticks;
-   ticks = ticks * 1L / MAC_CLOCK_TICK;
-
-   return (ticks + offset) * 1000;
-}
-
 /*
  * Flush the L2 cache on Macs that have it by flipping
  * the system into 24-bit mode for an instant.
@@ -618,3 +569,56 @@ int via2_scsi_drq_pending(void)
return via2[gIFR] & (1 << IRQ_IDX(IRQ_MAC_SCSIDRQ));
 }
 EXPORT_SYMBOL(via2_scsi_drq_pending);
+
+/* timer and clock source */
+
+#define VIA_CLOCK_FREQ 783360/* VIA "phase 2" clock in Hz 
*/
+#define VIA_TIMER_INTERVAL (100 / HZ)/* microseconds per jiffy */
+#define VIA_TIMER_CYCLES   (VIA_CLOCK_FREQ / HZ) /* clock cycles per jiffy */
+
+#define VIA_TC (VIA_TIMER_CYCLES - 2) /* including 0 and -1 */
+#define VIA_TC_LOW (VIA_TC & 0xFF)
+#define VIA_TC_HIGH(VIA_TC >> 8)
+
+void __init via_init_clock(irq_handler_t timer_routine)
+{
+   if (request_irq(IRQ_MAC_TIMER_1, timer_routine, 0, "timer", NULL)) {
+   pr_err("Couldn't register %s interrupt\n", "timer");
+   return;
+   }
+
+   via1[vT1LL] = VIA_TC_LOW;
+   via1[vT1LH] = VIA_TC_HIGH;
+   via1[vT1CL] = VIA_TC_LOW;
+   via1[vT1CH] = VIA_TC_HIGH;
+   via1[vACR] |= 0x40;
+}
+
+u32 mac_gettimeoffset(void)
+{
+   unsigned long flags;
+   u8 count_high;
+   u16 count, offset = 0;
+
+   /*
+* Timer counter wrap-around is detected with the timer interrupt flag
+* but reading the counter low byte (vT1CL) would reset the flag.
+* Also, accessing both counter registers is essentially a data race.
+* These problems are avoided by ignoring the low byte. Clock accuracy
+* is 256 times worse (error can reach 0.327 ms) but CPU overhead is
+* reduced by avoiding slow VIA register accesses.
+*/
+
+   local_irq_save(flags);
+   count_high = via1[vT1CH];
+   if (count_high == 0xFF)
+   count_high = 0;
+   else if (via1[vIFR] & VIA_TIMER_1_INT)
+   offset = VIA_TIMER_CYCLES;
+   local_irq_restore(flags);
+
+   count = count_high << 8;
+   count = VIA_TIMER_CYCLES - count + offset;
+
+   return ((count * VIA_TIMER_INTERVAL) / VIA_TIMER_CYCLES) * 1000;
+}
-- 
2.18.1



[RFC PATCH v3 09/14] m68k: hp300: Handle timer counter overflow

2018-11-23 Thread Finn Thain
Because hp300_read_clk() never checks the timer interrupt flag it may
fail to notice that the timer has wrapped, allowing the clock to jump
backwards. This is not a new problem.

This is resolved by checking the interrupt flag and, if need be,
taking wrap-around into account. The interrupt handler clears the flag
when it eventually executes.

Signed-off-by: Finn Thain 
---
TODO: find a spare counter for the clocksource, rather than hanging
it off the HZ timer.
---
 arch/m68k/hp300/time.c | 44 +-
 1 file changed, 26 insertions(+), 18 deletions(-)

diff --git a/arch/m68k/hp300/time.c b/arch/m68k/hp300/time.c
index 90982803a629..ce6b5fc8d4a9 100644
--- a/arch/m68k/hp300/time.c
+++ b/arch/m68k/hp300/time.c
@@ -41,9 +41,12 @@ static u32 clk_total;
 #defineCLKCR3  CLKCR1
 #defineCLKSR   CLKCR2
 #defineCLKMSB1 0x5
+#defineCLKLSB1 0x7
 #defineCLKMSB2 0x9
 #defineCLKMSB3 0xD
 
+#defineCLKSR_INT1  BIT(0)
+
 /* This is for machines which generate the exact clock. */
 
 #define HP300_TIMER_CLOCK_FREQ 25
@@ -70,24 +73,29 @@ static irqreturn_t hp300_tick(int irq, void *dev_id)
 
 static u64 hp300_read_clk(struct clocksource *cs)
 {
-  unsigned long flags;
-  unsigned char lsb, msb1, msb2;
-  u32 ticks;
-
-  local_irq_save(flags);
-  /* Read current timer 1 value */
-  msb1 = in_8(CLOCKBASE + 5);
-  lsb = in_8(CLOCKBASE + 7);
-  msb2 = in_8(CLOCKBASE + 5);
-  if (msb1 != msb2)
-/* A carry happened while we were reading.  Read it again */
-lsb = in_8(CLOCKBASE + 7);
-
-  ticks = INTVAL - ((msb2 << 8) | lsb);
-  ticks += clk_total;
-  local_irq_restore(flags);
-
-  return ticks;
+   unsigned long flags;
+   unsigned char lsb, msb, msb_new;
+   u16 offset = 0;
+   u32 ticks;
+
+   local_irq_save(flags);
+   /* Read current timer 1 value */
+   msb = in_8(CLOCKBASE + CLKMSB1);
+again:
+   if ((in_8(CLOCKBASE + CLKSR) & CLKSR_INT1) && msb > 0)
+   offset = INTVAL;
+   lsb = in_8(CLOCKBASE + CLKLSB1);
+   msb_new = in_8(CLOCKBASE + CLKMSB1);
+   if (msb_new != msb) {
+   msb = msb_new;
+   goto again;
+   }
+
+   ticks = INTVAL - ((msb << 8) | lsb);
+   ticks += offset + clk_total;
+   local_irq_restore(flags);
+
+   return ticks;
 }
 
 void __init hp300_sched_init(irq_handler_t vector)
-- 
2.18.1



[RFC PATCH v3 06/14] m68k: atari: Convert to clocksource API

2018-11-23 Thread Finn Thain
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.

Normally the MFP timer C interrupt flag would be used to check for
timer counter wrap-around. Unfortunately, that flag gets cleared by the
MFP itself (due to automatic End-of-Interrupt mode). This means that
mfp_timer_c_handler() and atari_read_clk() must race when accounting
for counter wrap-around.

That problem is avoided by effectively stopping the clock when it might
otherwise jump backwards (due to interrupt latency). Note that this may
affect clock accuracy.

After the timer interrupt is asserted, wait for the counter to be
reloaded so that atari_read_clk() will not see the intermediate state
as that would cause the clock to jump backwards.

Signed-off-by: Finn Thain 
Acked-by: Linus Walleij 
Tested-by: Michael Schmitz 
---
TODO: find a spare counter for the clocksource, rather than hanging
it off the HZ timer.

Changed since v2:
 - Wait for timer reload after timer interrupt.
 - Add comment and improve code style for better clarity.

Changed since v1:
 - Moved clk_total access to within the irq lock.
 - Renamed mfp_timer_handler and mfptimer_handler.
 - Avoid accessing the timer interrupt flag in atari_read_clk(). To
get monotonicity, keep track of the previous timer counter value.
---
 arch/m68k/atari/time.c | 53 --
 1 file changed, 36 insertions(+), 17 deletions(-)

diff --git a/arch/m68k/atari/time.c b/arch/m68k/atari/time.c
index fafa20f75ab9..ce923a523695 100644
--- a/arch/m68k/atari/time.c
+++ b/arch/m68k/atari/time.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -24,12 +25,29 @@
 DEFINE_SPINLOCK(rtc_lock);
 EXPORT_SYMBOL_GPL(rtc_lock);
 
+static u64 atari_read_clk(struct clocksource *cs);
+
+static struct clocksource atari_clk = {
+   .name   = "mfp",
+   .rating = 100,
+   .read   = atari_read_clk,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
+};
+
+static u32 clk_total;
+static u8 last_timer_count;
+
 static irqreturn_t mfp_timer_c_handler(int irq, void *dev_id)
 {
irq_handler_t timer_routine = dev_id;
unsigned long flags;
 
local_irq_save(flags);
+   do {
+   last_timer_count = st_mfp.tim_dt_c;
+   } while (last_timer_count == 1);
+   clk_total += INT_TICKS;
timer_routine(0, NULL);
local_irq_restore(flags);
 
@@ -44,32 +62,33 @@ atari_sched_init(irq_handler_t timer_routine)
 /* start timer C, div = 1:100 */
 st_mfp.tim_ct_cd = (st_mfp.tim_ct_cd & 15) | 0x60;
 /* install interrupt service routine for MFP Timer C */
-if (request_irq(IRQ_MFP_TIMC, mfp_timer_c_handler, 0, "timer",
+if (request_irq(IRQ_MFP_TIMC, mfp_timer_c_handler, IRQF_TIMER, "timer",
 timer_routine))
pr_err("Couldn't register timer interrupt\n");
+
+clocksource_register_hz(&atari_clk, INT_CLK);
 }
 
 /* ++andreas: gettimeoffset fixed to check for pending interrupt */
 
-#define TICK_SIZE 1
-
-/* This is always executed with interrupts disabled.  */
-u32 atari_gettimeoffset(void)
+static u64 atari_read_clk(struct clocksource *cs)
 {
-  u32 ticks, offset = 0;
-
-  /* read MFP timer C current value */
-  ticks = st_mfp.tim_dt_c;
-  /* The probability of underflow is less than 2% */
-  if (ticks > INT_TICKS - INT_TICKS / 50)
-/* Check for pending timer interrupt */
-if (st_mfp.int_pn_b & (1 << 5))
-  offset = TICK_SIZE;
+   unsigned long flags;
+   u8 count;
+   u32 ticks;
 
-  ticks = INT_TICKS - ticks;
-  ticks = ticks * 1L / INT_TICKS;
+   local_irq_save(flags);
+   /* Ensure that the count is monotonically decreasing, even though
+* the result may briefly stop changing after counter wrap-around.
+*/
+   count = min(st_mfp.tim_dt_c, last_timer_count);
+   last_timer_count = count;
+
+   ticks = INT_TICKS - count;
+   ticks += clk_total;
+   local_irq_restore(flags);
 
-  return (ticks + offset) * 1000;
+   return ticks;
 }
 
 
-- 
2.18.1



[RFC PATCH v3 12/14] m68k: mvme147: Handle timer counter overflow

2018-11-23 Thread Finn Thain
Reading the timer counter races with timer overflow (and the
corresponding interrupt). This is resolved by reading the overflow
register and taking this value into account. The interrupt handler
must clear the overflow register when it eventually executes.

Suggested-by: Thomas Gleixner 
Signed-off-by: Finn Thain 
---
TODO: find a spare counter for the clocksource, rather than hanging
it off the HZ timer.
---
 arch/m68k/include/asm/mvme147hw.h |  1 +
 arch/m68k/mvme147/config.c| 21 +++--
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/m68k/include/asm/mvme147hw.h 
b/arch/m68k/include/asm/mvme147hw.h
index 7c3dd513128e..257b29184af9 100644
--- a/arch/m68k/include/asm/mvme147hw.h
+++ b/arch/m68k/include/asm/mvme147hw.h
@@ -66,6 +66,7 @@ struct pcc_regs {
 #define PCC_INT_ENAB   0x08
 
 #define PCC_TIMER_INT_CLR  0x80
+#define PCC_TIMER_CLR_OVF  0x04
 
 #define PCC_LEVEL_ABORT0x07
 #define PCC_LEVEL_SERIAL   0x04
diff --git a/arch/m68k/mvme147/config.c b/arch/m68k/mvme147/config.c
index c44a254e8a8c..545a1fe0e119 100644
--- a/arch/m68k/mvme147/config.c
+++ b/arch/m68k/mvme147/config.c
@@ -118,7 +118,7 @@ static irqreturn_t mvme147_timer_int (int irq, void *dev_id)
 
local_irq_save(flags);
m147_pcc->t1_int_cntrl = PCC_TIMER_INT_CLR;
-   m147_pcc->t1_int_cntrl = PCC_INT_ENAB|PCC_LEVEL_TIMER1;
+   m147_pcc->t1_cntrl = PCC_TIMER_CLR_OVF;
clk_total += PCC_TIMER_CYCLES;
timer_routine(0, NULL);
local_irq_restore(flags);
@@ -144,21 +144,22 @@ void mvme147_sched_init (irq_handler_t timer_routine)
clocksource_register_hz(&mvme147_clk, PCC_TIMER_CLOCK_FREQ);
 }
 
-/* XXX There are race hazards in this code XXX */
 static u64 mvme147_read_clk(struct clocksource *cs)
 {
unsigned long flags;
-   volatile unsigned short *cp = (volatile unsigned short *)0xfffe1012;
-   unsigned short n;
+   u8 overflow, tmp;
+   u16 count;
u32 ticks;
 
local_irq_save(flags);
-   n = *cp;
-   while (n != *cp)
-   n = *cp;
-
-   n -= PCC_TIMER_PRELOAD;
-   ticks = clk_total + n;
+   tmp = m147_pcc->t1_cntrl >> 4;
+   count = m147_pcc->t1_count;
+   overflow = m147_pcc->t1_cntrl >> 4;
+   if (overflow != tmp)
+   count = m147_pcc->t1_count;
+   count -= PCC_TIMER_PRELOAD;
+   ticks = count + overflow * PCC_TIMER_CYCLES;
+   ticks += clk_total;
local_irq_restore(flags);
 
return ticks;
-- 
2.18.1



[RFC PATCH v3 07/14] m68k: bvme6000: Convert to clocksource API

2018-11-23 Thread Finn Thain
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.

Signed-off-by: Finn Thain 
Acked-by: Linus Walleij 
---
Changed since v2:
 - Don't check for timer interrupt in bvme6000_read_clk() when the timer is
about to be reloaded.

Changed since v1:
 - Moved clk_total access to within the irq lock.
---
 arch/m68k/bvme6000/config.c | 56 ++---
 1 file changed, 40 insertions(+), 16 deletions(-)

diff --git a/arch/m68k/bvme6000/config.c b/arch/m68k/bvme6000/config.c
index c8b99d5516d1..162796bcff6a 100644
--- a/arch/m68k/bvme6000/config.c
+++ b/arch/m68k/bvme6000/config.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -147,6 +148,21 @@ irqreturn_t bvme6000_abort_int (int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+static u64 bvme6000_read_clk(struct clocksource *cs);
+
+static struct clocksource bvme6000_clk = {
+   .name   = "rtc",
+   .rating = 250,
+   .read   = bvme6000_read_clk,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
+};
+
+static u32 clk_total;
+
+#define RTC_TIMER_CLOCK_FREQ 800
+#define RTC_TIMER_CYCLES (RTC_TIMER_CLOCK_FREQ / HZ)
+#define RTC_TIMER_COUNT  ((RTC_TIMER_CYCLES / 2) - 1)
 
 static irqreturn_t bvme6000_timer_int (int irq, void *dev_id)
 {
@@ -158,6 +174,7 @@ static irqreturn_t bvme6000_timer_int (int irq, void 
*dev_id)
 local_irq_save(flags);
 msr = rtc->msr & 0xc0;
 rtc->msr = msr | 0x20; /* Ack the interrupt */
+clk_total += RTC_TIMER_CYCLES;
 timer_routine(0, NULL);
 local_irq_restore(flags);
 
@@ -180,13 +197,13 @@ void bvme6000_sched_init (irq_handler_t timer_routine)
 
 rtc->msr = 0;  /* Ensure timer registers accessible */
 
-if (request_irq(BVME_IRQ_RTC, bvme6000_timer_int, 0, "timer",
+if (request_irq(BVME_IRQ_RTC, bvme6000_timer_int, IRQF_TIMER, "timer",
 timer_routine))
panic ("Couldn't register timer int");
 
 rtc->t1cr_omr = 0x04;  /* Mode 2, ext clk */
-rtc->t1msb = 3 >> 8;
-rtc->t1lsb = 3 & 0xff;
+rtc->t1msb = RTC_TIMER_COUNT >> 8;
+rtc->t1lsb = RTC_TIMER_COUNT & 0xff;
 rtc->irr_icr1 &= 0xef; /* Route timer 1 to INTR pin */
 rtc->msr = 0x40;   /* Access int.cntrl, etc */
 rtc->pfr_icr0 = 0x80;  /* Just timer 1 ints enabled */
@@ -198,14 +215,14 @@ void bvme6000_sched_init (irq_handler_t timer_routine)
 
 rtc->msr = msr;
 
+clocksource_register_hz(&bvme6000_clk, RTC_TIMER_CLOCK_FREQ);
+
 if (request_irq(BVME_IRQ_ABORT, bvme6000_abort_int, 0,
"abort", bvme6000_abort_int))
panic ("Couldn't register abort int");
 }
 
 
-/* This is always executed with interrupts disabled.  */
-
 /*
  * NOTE:  Don't accept any readings within 5us of rollover, as
  * the T1INT bit may be a little slow getting set.  There is also
@@ -213,14 +230,18 @@ void bvme6000_sched_init (irq_handler_t timer_routine)
  * results...
  */
 
-u32 bvme6000_gettimeoffset(void)
+static u64 bvme6000_read_clk(struct clocksource *cs)
 {
+unsigned long flags;
 volatile RtcPtr_t rtc = (RtcPtr_t)BVME_RTC_BASE;
 volatile PitRegsPtr pit = (PitRegsPtr)BVME_PIT_BASE;
-unsigned char msr = rtc->msr & 0xc0;
+unsigned char msr, msb;
 unsigned char t1int, t1op;
 u32 v = 80, ov;
 
+local_irq_save(flags);
+
+msr = rtc->msr & 0xc0;
 rtc->msr = 0;  /* Ensure timer registers accessible */
 
 do {
@@ -228,22 +249,25 @@ u32 bvme6000_gettimeoffset(void)
t1int = rtc->msr & 0x20;
t1op  = pit->pcdr & 0x04;
rtc->t1cr_omr |= 0x40;  /* Latch timer1 */
-   v = rtc->t1msb << 8;/* Read timer1 */
-   v |= rtc->t1lsb;/* Read timer1 */
+   msb = rtc->t1msb;   /* Read timer1 */
+   v = (msb << 8) | rtc->t1lsb;/* Read timer1 */
 } while (t1int != (rtc->msr & 0x20) ||
t1op != (pit->pcdr & 0x04) ||
abs(ov-v) > 80 ||
-   v > 39960);
+   v > RTC_TIMER_COUNT - (RTC_TIMER_COUNT / 100));
 
-v = 3 - v;
+v = RTC_TIMER_COUNT - v;
 if (!t1op) /* If in second half cycle.. */
-   v += 4;
-v /= 8;/* Convert ticks to microseconds */
-if (t1int)
-   v += 1; /* Int pending, + 10ms */
+   v += RTC_TIMER_CYCLES / 2;
+if (msb > 0 && t1int)
+   v += RTC_TIMER_CYCLES;
 rtc->msr = msr;
 
-return v * 1000;
+v += clk_total;
+
+local_irq_restore(flags);
+
+return v;
 }
 
 /*
-- 
2.18.1



[RFC PATCH v3 03/14] m68k: apollo, q40, sun3, sun3x: Remove arch_gettimeoffset implementations

2018-11-23 Thread Finn Thain
These dummy implementations are no better than
default_arch_gettimeoffset() so remove them.

Signed-off-by: Finn Thain 
---
 arch/m68k/apollo/config.c | 7 ---
 arch/m68k/q40/config.c| 9 -
 arch/m68k/sun3/config.c   | 2 --
 arch/m68k/sun3/intersil.c | 7 ---
 arch/m68k/sun3x/config.c  | 1 -
 arch/m68k/sun3x/time.c| 5 -
 arch/m68k/sun3x/time.h| 1 -
 7 files changed, 32 deletions(-)

diff --git a/arch/m68k/apollo/config.c b/arch/m68k/apollo/config.c
index aef8d42e078d..7d168e6dfb01 100644
--- a/arch/m68k/apollo/config.c
+++ b/arch/m68k/apollo/config.c
@@ -29,7 +29,6 @@ u_long apollo_model;
 
 extern void dn_sched_init(irq_handler_t handler);
 extern void dn_init_IRQ(void);
-extern u32 dn_gettimeoffset(void);
 extern int dn_dummy_hwclk(int, struct rtc_time *);
 extern void dn_dummy_reset(void);
 #ifdef CONFIG_HEARTBEAT
@@ -152,7 +151,6 @@ void __init config_apollo(void)
 
mach_sched_init=dn_sched_init; /* */
mach_init_IRQ=dn_init_IRQ;
-   arch_gettimeoffset   = dn_gettimeoffset;
mach_max_dma_address = 0x;
mach_hwclk   = dn_dummy_hwclk; /* */
mach_reset   = dn_dummy_reset;  /* */
@@ -205,11 +203,6 @@ void dn_sched_init(irq_handler_t timer_routine)
pr_err("Couldn't register timer interrupt\n");
 }
 
-u32 dn_gettimeoffset(void)
-{
-   return 0xdeadbeef;
-}
-
 int dn_dummy_hwclk(int op, struct rtc_time *t) {
 
 
diff --git a/arch/m68k/q40/config.c b/arch/m68k/q40/config.c
index 96810d91da2b..e63eb5f06999 100644
--- a/arch/m68k/q40/config.c
+++ b/arch/m68k/q40/config.c
@@ -40,7 +40,6 @@ extern void q40_init_IRQ(void);
 static void q40_get_model(char *model);
 extern void q40_sched_init(irq_handler_t handler);
 
-static u32 q40_gettimeoffset(void);
 static int q40_hwclk(int, struct rtc_time *);
 static unsigned int q40_get_ss(void);
 static int q40_get_rtc_pll(struct rtc_pll_info *pll);
@@ -169,7 +168,6 @@ void __init config_q40(void)
mach_sched_init = q40_sched_init;
 
mach_init_IRQ = q40_init_IRQ;
-   arch_gettimeoffset = q40_gettimeoffset;
mach_hwclk = q40_hwclk;
mach_get_ss = q40_get_ss;
mach_get_rtc_pll = q40_get_rtc_pll;
@@ -201,13 +199,6 @@ int __init q40_parse_bootinfo(const struct bi_record *rec)
return 1;
 }
 
-
-static u32 q40_gettimeoffset(void)
-{
-   return 5000 * (ql_ticks != 0) * 1000;
-}
-
-
 /*
  * Looks like op is non-zero for setting the clock, and zero for
  * reading the clock.
diff --git a/arch/m68k/sun3/config.c b/arch/m68k/sun3/config.c
index 79a2bb857906..867e68d92c71 100644
--- a/arch/m68k/sun3/config.c
+++ b/arch/m68k/sun3/config.c
@@ -37,7 +37,6 @@
 
 char sun3_reserved_pmeg[SUN3_PMEGS_NUM];
 
-extern u32 sun3_gettimeoffset(void);
 static void sun3_sched_init(irq_handler_t handler);
 extern void sun3_get_model (char* model);
 extern int sun3_hwclk(int set, struct rtc_time *t);
@@ -138,7 +137,6 @@ void __init config_sun3(void)
 mach_sched_init  =  sun3_sched_init;
 mach_init_IRQ=  sun3_init_IRQ;
 mach_reset   =  sun3_reboot;
-   arch_gettimeoffset   =  sun3_gettimeoffset;
mach_get_model   =  sun3_get_model;
mach_hwclk   =  sun3_hwclk;
mach_halt=  sun3_halt;
diff --git a/arch/m68k/sun3/intersil.c b/arch/m68k/sun3/intersil.c
index d911070af02a..8fc74864de81 100644
--- a/arch/m68k/sun3/intersil.c
+++ b/arch/m68k/sun3/intersil.c
@@ -22,13 +22,6 @@
 #define STOP_VAL (INTERSIL_STOP | INTERSIL_INT_ENABLE | INTERSIL_24H_MODE)
 #define START_VAL (INTERSIL_RUN | INTERSIL_INT_ENABLE | INTERSIL_24H_MODE)
 
-/* does this need to be implemented? */
-u32 sun3_gettimeoffset(void)
-{
-  return 1000;
-}
-
-
 /* get/set hwclock */
 
 int sun3_hwclk(int set, struct rtc_time *t)
diff --git a/arch/m68k/sun3x/config.c b/arch/m68k/sun3x/config.c
index 33d3a1c6fba0..03ce7f9facfe 100644
--- a/arch/m68k/sun3x/config.c
+++ b/arch/m68k/sun3x/config.c
@@ -49,7 +49,6 @@ void __init config_sun3x(void)
mach_sched_init  = sun3x_sched_init;
mach_init_IRQ= sun3_init_IRQ;
 
-   arch_gettimeoffset   = sun3x_gettimeoffset;
mach_reset   = sun3x_reboot;
 
mach_hwclk   = sun3x_hwclk;
diff --git a/arch/m68k/sun3x/time.c b/arch/m68k/sun3x/time.c
index 3c8a86d08508..9163294b0fb6 100644
--- a/arch/m68k/sun3x/time.c
+++ b/arch/m68k/sun3x/time.c
@@ -73,11 +73,6 @@ int sun3x_hwclk(int set, struct rtc_time *t)
 
return 0;
 }
-/* Not much we can do here */
-u32 sun3x_gettimeoffset(void)
-{
-return 0L;
-}
 
 #if 0
 static irqreturn_t sun3x_timer_tick(int irq, void *dev_id)
diff --git a/arch/m68k/sun3x/time.h b/arch/m68k/sun3x/time.h
index 496f406412ad..86ce78bb3c28 100644
--- a/arch/m68k/sun3x/time.h
+++ b/arch/m68k/sun3x/time.h
@@ -3,7 +3,6 @@
 #define SUN3X_TIME_H
 
 extern int sun3x_hwclk(int set, struct rtc_time *t);
-u32 sun3x_gettimeoffset(void);
 void sun3x_sched_init(irq_handler_t vector);
 

[RFC PATCH v3 04/14] m68k: Drop ARCH_USES_GETTIMEOFFSET

2018-11-23 Thread Finn Thain
The functions that implement arch_gettimeoffset are re-used by
new clocksource drivers in subsequent patches.

Signed-off-by: Finn Thain 
Acked-by: Linus Walleij 
---
 arch/m68k/Kconfig   | 1 -
 arch/m68k/amiga/config.c| 3 ---
 arch/m68k/atari/config.c| 2 --
 arch/m68k/bvme6000/config.c | 2 --
 arch/m68k/hp300/config.c| 1 -
 arch/m68k/hp300/time.h  | 1 -
 arch/m68k/mac/config.c  | 3 ---
 arch/m68k/mvme147/config.c  | 2 --
 arch/m68k/mvme16x/config.c  | 2 --
 9 files changed, 17 deletions(-)

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 070553791e97..cc62660a5760 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -19,7 +19,6 @@ config M68K
select GENERIC_STRNCPY_FROM_USER if MMU
select GENERIC_STRNLEN_USER if MMU
select ARCH_WANT_IPC_PARSE_VERSION
-   select ARCH_USES_GETTIMEOFFSET if MMU && !COLDFIRE
select HAVE_FUTEX_CMPXCHG if MMU && FUTEX
select HAVE_MOD_ARCH_SPECIFIC
select MODULES_USE_ELF_REL
diff --git a/arch/m68k/amiga/config.c b/arch/m68k/amiga/config.c
index 65f63a457130..d4976c1aa0cc 100644
--- a/arch/m68k/amiga/config.c
+++ b/arch/m68k/amiga/config.c
@@ -95,8 +95,6 @@ static char amiga_model_name[13] = "Amiga ";
 static void amiga_sched_init(irq_handler_t handler);
 static void amiga_get_model(char *model);
 static void amiga_get_hardware_list(struct seq_file *m);
-/* amiga specific timer functions */
-static u32 amiga_gettimeoffset(void);
 extern void amiga_mksound(unsigned int count, unsigned int ticks);
 static void amiga_reset(void);
 extern void amiga_init_sound(void);
@@ -386,7 +384,6 @@ void __init config_amiga(void)
mach_init_IRQ= amiga_init_IRQ;
mach_get_model   = amiga_get_model;
mach_get_hardware_list = amiga_get_hardware_list;
-   arch_gettimeoffset   = amiga_gettimeoffset;
 
/*
 * default MAX_DMA=0x on all machines. If we don't do so, the 
SCSI
diff --git a/arch/m68k/atari/config.c b/arch/m68k/atari/config.c
index bd96702a1ad0..89e65be2655f 100644
--- a/arch/m68k/atari/config.c
+++ b/arch/m68k/atari/config.c
@@ -78,7 +78,6 @@ static void atari_heartbeat(int on);
 
 /* atari specific timer functions (in time.c) */
 extern void atari_sched_init(irq_handler_t);
-extern u32 atari_gettimeoffset(void);
 extern int atari_mste_hwclk (int, struct rtc_time *);
 extern int atari_tt_hwclk (int, struct rtc_time *);
 
@@ -205,7 +204,6 @@ void __init config_atari(void)
mach_init_IRQ= atari_init_IRQ;
mach_get_model   = atari_get_model;
mach_get_hardware_list = atari_get_hardware_list;
-   arch_gettimeoffset   = atari_gettimeoffset;
mach_reset   = atari_reset;
mach_max_dma_address = 0xff;
 #if IS_ENABLED(CONFIG_INPUT_M68K_BEEP)
diff --git a/arch/m68k/bvme6000/config.c b/arch/m68k/bvme6000/config.c
index 0e5efed4da86..c8b99d5516d1 100644
--- a/arch/m68k/bvme6000/config.c
+++ b/arch/m68k/bvme6000/config.c
@@ -39,7 +39,6 @@
 
 static void bvme6000_get_model(char *model);
 extern void bvme6000_sched_init(irq_handler_t handler);
-extern u32 bvme6000_gettimeoffset(void);
 extern int bvme6000_hwclk (int, struct rtc_time *);
 extern void bvme6000_reset (void);
 void bvme6000_set_vectors (void);
@@ -105,7 +104,6 @@ void __init config_bvme6000(void)
 mach_max_dma_address = 0x;
 mach_sched_init  = bvme6000_sched_init;
 mach_init_IRQ= bvme6000_init_IRQ;
-arch_gettimeoffset   = bvme6000_gettimeoffset;
 mach_hwclk   = bvme6000_hwclk;
 mach_reset  = bvme6000_reset;
 mach_get_model   = bvme6000_get_model;
diff --git a/arch/m68k/hp300/config.c b/arch/m68k/hp300/config.c
index a19bcd23f80b..a161d44fd20b 100644
--- a/arch/m68k/hp300/config.c
+++ b/arch/m68k/hp300/config.c
@@ -254,7 +254,6 @@ void __init config_hp300(void)
mach_sched_init  = hp300_sched_init;
mach_init_IRQ= hp300_init_IRQ;
mach_get_model   = hp300_get_model;
-   arch_gettimeoffset   = hp300_gettimeoffset;
mach_hwclk   = hp300_hwclk;
mach_get_ss  = hp300_get_ss;
mach_reset   = hp300_reset;
diff --git a/arch/m68k/hp300/time.h b/arch/m68k/hp300/time.h
index f5583ec4033d..1d77b55cc72a 100644
--- a/arch/m68k/hp300/time.h
+++ b/arch/m68k/hp300/time.h
@@ -1,2 +1 @@
 extern void hp300_sched_init(irq_handler_t vector);
-extern u32 hp300_gettimeoffset(void);
diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index cd9317d53276..11be08f4f750 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -54,8 +54,6 @@ struct mac_booter_data mac_bi_data;
 /* The phys. video addr. - might be bogus on some machines */
 static unsigned long mac_orig_videoaddr;
 
-/* Mac specific timer functions */
-extern u32 mac_gettimeoffset(void);
 extern int mac_hwclk(int, struct rtc_time *);
 extern void iop_preinit(void);
 extern void iop_init(void);
@@ -155,7 +153,6 @@ void __init c

[RFC PATCH v3 05/14] m68k: amiga: Convert to clocksource API

2018-11-23 Thread Finn Thain
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.

Signed-off-by: Finn Thain 
Acked-by: Linus Walleij 
---
Changed since v2:
 - Don't check for timer interrupt in amiga_read_clk() when the timer is
about to be reloaded.

Changed since v1:
 - Moved clk_total access to within the irq lock.
---
 arch/m68k/amiga/config.c | 64 +++-
 1 file changed, 43 insertions(+), 21 deletions(-)

diff --git a/arch/m68k/amiga/config.c b/arch/m68k/amiga/config.c
index d4976c1aa0cc..0c2c07318f6c 100644
--- a/arch/m68k/amiga/config.c
+++ b/arch/m68k/amiga/config.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -461,7 +462,28 @@ void __init config_amiga(void)
*(unsigned char *)ZTWO_VADDR(0xde0002) |= 0x80;
 }
 
+static u64 amiga_read_clk(struct clocksource *cs);
+
+static struct clocksource amiga_clk = {
+   .name   = "ciab",
+   .rating = 250,
+   .read   = amiga_read_clk,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
+};
+
 static unsigned short jiffy_ticks;
+static u32 clk_total;
+
+static irqreturn_t ciab_timer_handler(int irq, void *dev_id)
+{
+   irq_handler_t timer_routine = dev_id;
+
+   clk_total += jiffy_ticks;
+   timer_routine(0, NULL);
+
+   return IRQ_HANDLED;
+}
 
 static void __init amiga_sched_init(irq_handler_t timer_routine)
 {
@@ -481,41 +503,41 @@ static void __init amiga_sched_init(irq_handler_t 
timer_routine)
 * Please don't change this to use ciaa, as it interferes with the
 * SCSI code. We'll have to take a look at this later
 */
-   if (request_irq(IRQ_AMIGA_CIAB_TA, timer_routine, 0, "timer", NULL))
+   if (request_irq(IRQ_AMIGA_CIAB_TA, ciab_timer_handler, IRQF_TIMER,
+   "timer", timer_routine))
pr_err("Couldn't register timer interrupt\n");
/* start timer */
ciab.cra |= 0x11;
-}
 
-#define TICK_SIZE 1
+   clocksource_register_hz(&amiga_clk, amiga_eclock);
+}
 
-/* This is always executed with interrupts disabled.  */
-static u32 amiga_gettimeoffset(void)
+static u64 amiga_read_clk(struct clocksource *cs)
 {
-   unsigned short hi, lo, hi2;
+   unsigned long flags;
+   u8 msb, lsb, tmp;
u32 ticks, offset = 0;
 
-   /* read CIA B timer A current value */
-   hi  = ciab.tahi;
-   lo  = ciab.talo;
-   hi2 = ciab.tahi;
+   local_irq_save(flags);
 
-   if (hi != hi2) {
-   lo = ciab.talo;
-   hi = hi2;
-   }
-
-   ticks = hi << 8 | lo;
+   /* read CIA B timer A current value */
+   tmp = ciab.tahi;
+   lsb = ciab.talo;
+   msb = ciab.tahi;
+   if (msb != tmp)
+   lsb = ciab.talo;
 
-   if (ticks > jiffy_ticks / 2)
+   if (msb > 0)
/* check for pending interrupt */
if (cia_set_irq(&ciab_base, 0) & CIA_ICR_TA)
-   offset = 1;
+   offset = jiffy_ticks;
+
+   ticks = jiffy_ticks - (msb << 8 | lsb);
+   ticks += offset + clk_total;
 
-   ticks = jiffy_ticks - ticks;
-   ticks = (1 * ticks) / jiffy_ticks;
+   local_irq_restore(flags);
 
-   return (ticks + offset) * 1000;
+   return ticks;
 }
 
 static void amiga_reset(void)  __noreturn;
-- 
2.18.1



[RFC PATCH v3 08/14] m68k: hp300: Convert to clocksource API

2018-11-23 Thread Finn Thain
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.

Signed-off-by: Finn Thain 
Acked-by: Linus Walleij 
---
Changed since v1:
 - Moved clk_total access to within the irq lock.
 - Use type u32 for tick counter.
---
 arch/m68k/hp300/time.c | 37 ++---
 1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/arch/m68k/hp300/time.c b/arch/m68k/hp300/time.c
index d30b03ea93a2..90982803a629 100644
--- a/arch/m68k/hp300/time.c
+++ b/arch/m68k/hp300/time.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,6 +20,18 @@
 #include 
 #include 
 
+static u64 hp300_read_clk(struct clocksource *cs);
+
+static struct clocksource hp300_clk = {
+   .name   = "timer",
+   .rating = 250,
+   .read   = hp300_read_clk,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
+};
+
+static u32 clk_total;
+
 /* Clock hardware definitions */
 
 #define CLOCKBASE  0xf05f8000
@@ -32,9 +45,10 @@
 #defineCLKMSB3 0xD
 
 /* This is for machines which generate the exact clock. */
-#define USECS_PER_JIFFY (100/HZ)
 
-#define INTVAL ((1 / 4) - 1)
+#define HP300_TIMER_CLOCK_FREQ 25
+#define HP300_TIMER_CYCLES (HP300_TIMER_CLOCK_FREQ / HZ)
+#define INTVAL (HP300_TIMER_CYCLES - 1)
 
 static irqreturn_t hp300_tick(int irq, void *dev_id)
 {
@@ -45,6 +59,7 @@ static irqreturn_t hp300_tick(int irq, void *dev_id)
local_irq_save(flags);
in_8(CLOCKBASE + CLKSR);
asm volatile ("movpw %1@(5),%0" : "=d" (tmp) : "a" (CLOCKBASE));
+   clk_total += INTVAL;
timer_routine(0, NULL);
local_irq_restore(flags);
 
@@ -53,20 +68,26 @@ static irqreturn_t hp300_tick(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
-u32 hp300_gettimeoffset(void)
+static u64 hp300_read_clk(struct clocksource *cs)
 {
-  /* Read current timer 1 value */
+  unsigned long flags;
   unsigned char lsb, msb1, msb2;
-  unsigned short ticks;
+  u32 ticks;
 
+  local_irq_save(flags);
+  /* Read current timer 1 value */
   msb1 = in_8(CLOCKBASE + 5);
   lsb = in_8(CLOCKBASE + 7);
   msb2 = in_8(CLOCKBASE + 5);
   if (msb1 != msb2)
 /* A carry happened while we were reading.  Read it again */
 lsb = in_8(CLOCKBASE + 7);
+
   ticks = INTVAL - ((msb2 << 8) | lsb);
-  return ((USECS_PER_JIFFY * ticks) / INTVAL) * 1000;
+  ticks += clk_total;
+  local_irq_restore(flags);
+
+  return ticks;
 }
 
 void __init hp300_sched_init(irq_handler_t vector)
@@ -76,9 +97,11 @@ void __init hp300_sched_init(irq_handler_t vector)
 
   asm volatile(" movpw %0,%1@(5)" : : "d" (INTVAL), "a" (CLOCKBASE));
 
-  if (request_irq(IRQ_AUTO_6, hp300_tick, 0, "timer tick", vector))
+  if (request_irq(IRQ_AUTO_6, hp300_tick, IRQF_TIMER, "timer tick", vector))
 pr_err("Couldn't register timer interrupt\n");
 
   out_8(CLOCKBASE + CLKCR2, 0x1);  /* select CR1 */
   out_8(CLOCKBASE + CLKCR1, 0x40); /* enable irq */
+
+  clocksource_register_hz(&hp300_clk, HP300_TIMER_CLOCK_FREQ);
 }
-- 
2.18.1



[RFC PATCH v3 11/14] m68k: mvme147: Convert to clocksource API

2018-11-23 Thread Finn Thain
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.

Signed-off-by: Finn Thain 
Acked-by: Linus Walleij 
---
Changed since v1:
 - Moved clk_total access to within the irq lock.
 - Use type u32 for tick counter.
---
 arch/m68k/include/asm/mvme147hw.h |  1 -
 arch/m68k/mvme147/config.c| 36 +--
 2 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/arch/m68k/include/asm/mvme147hw.h 
b/arch/m68k/include/asm/mvme147hw.h
index 9c7ff67c5ffd..7c3dd513128e 100644
--- a/arch/m68k/include/asm/mvme147hw.h
+++ b/arch/m68k/include/asm/mvme147hw.h
@@ -66,7 +66,6 @@ struct pcc_regs {
 #define PCC_INT_ENAB   0x08
 
 #define PCC_TIMER_INT_CLR  0x80
-#define PCC_TIMER_PRELOAD  63936l
 
 #define PCC_LEVEL_ABORT0x07
 #define PCC_LEVEL_SERIAL   0x04
diff --git a/arch/m68k/mvme147/config.c b/arch/m68k/mvme147/config.c
index 4ef4faa5ed8b..c44a254e8a8c 100644
--- a/arch/m68k/mvme147/config.c
+++ b/arch/m68k/mvme147/config.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -92,6 +93,21 @@ void __init config_mvme147(void)
vme_brdtype = VME_TYPE_MVME147;
 }
 
+static u64 mvme147_read_clk(struct clocksource *cs);
+
+static struct clocksource mvme147_clk = {
+   .name   = "pcc",
+   .rating = 250,
+   .read   = mvme147_read_clk,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
+};
+
+static u32 clk_total;
+
+#define PCC_TIMER_CLOCK_FREQ 16
+#define PCC_TIMER_CYCLES (PCC_TIMER_CLOCK_FREQ / HZ)
+#define PCC_TIMER_PRELOAD(0x1 - PCC_TIMER_CYCLES)
 
 /* Using pcc tick timer 1 */
 
@@ -103,6 +119,7 @@ static irqreturn_t mvme147_timer_int (int irq, void *dev_id)
local_irq_save(flags);
m147_pcc->t1_int_cntrl = PCC_TIMER_INT_CLR;
m147_pcc->t1_int_cntrl = PCC_INT_ENAB|PCC_LEVEL_TIMER1;
+   clk_total += PCC_TIMER_CYCLES;
timer_routine(0, NULL);
local_irq_restore(flags);
 
@@ -112,32 +129,39 @@ static irqreturn_t mvme147_timer_int (int irq, void 
*dev_id)
 
 void mvme147_sched_init (irq_handler_t timer_routine)
 {
-   if (request_irq(PCC_IRQ_TIMER1, mvme147_timer_int, 0, "timer 1",
-   timer_routine))
+   if (request_irq(PCC_IRQ_TIMER1, mvme147_timer_int, IRQF_TIMER,
+   "timer 1", timer_routine))
pr_err("Couldn't register timer interrupt\n");
 
/* Init the clock with a value */
-   /* our clock goes off every 6.25us */
+   /* The clock counter increments until 0x then reloads */
m147_pcc->t1_preload = PCC_TIMER_PRELOAD;
m147_pcc->t1_cntrl = 0x0;   /* clear timer */
m147_pcc->t1_cntrl = 0x3;   /* start timer */
m147_pcc->t1_int_cntrl = PCC_TIMER_INT_CLR;  /* clear pending ints */
m147_pcc->t1_int_cntrl = PCC_INT_ENAB|PCC_LEVEL_TIMER1;
+
+   clocksource_register_hz(&mvme147_clk, PCC_TIMER_CLOCK_FREQ);
 }
 
-/* This is always executed with interrupts disabled.  */
 /* XXX There are race hazards in this code XXX */
-u32 mvme147_gettimeoffset(void)
+static u64 mvme147_read_clk(struct clocksource *cs)
 {
+   unsigned long flags;
volatile unsigned short *cp = (volatile unsigned short *)0xfffe1012;
unsigned short n;
+   u32 ticks;
 
+   local_irq_save(flags);
n = *cp;
while (n != *cp)
n = *cp;
 
n -= PCC_TIMER_PRELOAD;
-   return ((unsigned long)n * 25 / 4) * 1000;
+   ticks = clk_total + n;
+   local_irq_restore(flags);
+
+   return ticks;
 }
 
 static int bcd2int (unsigned char b)
-- 
2.18.1



[RFC PATCH v3 13/14] m68k: mvme16x: Convert to clocksource API

2018-11-23 Thread Finn Thain
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.

Signed-off-by: Finn Thain 
Acked-by: Linus Walleij 
---
Changed since v1:
 - Moved clk_total access to within the irq lock.
---
 arch/m68k/mvme16x/config.c | 37 +++--
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/arch/m68k/mvme16x/config.c b/arch/m68k/mvme16x/config.c
index 3a3129e6f0bc..2c109ee2a1a5 100644
--- a/arch/m68k/mvme16x/config.c
+++ b/arch/m68k/mvme16x/config.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -343,6 +344,21 @@ static irqreturn_t mvme16x_abort_int (int irq, void 
*dev_id)
return IRQ_HANDLED;
 }
 
+static u64 mvme16x_read_clk(struct clocksource *cs);
+
+static struct clocksource mvme16x_clk = {
+   .name   = "pcc",
+   .rating = 250,
+   .read   = mvme16x_read_clk,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
+};
+
+static u32 clk_total;
+
+#define PCC_TIMER_CLOCK_FREQ 100
+#define PCC_TIMER_CYCLES (PCC_TIMER_CLOCK_FREQ / HZ)
+
 static irqreturn_t mvme16x_timer_int (int irq, void *dev_id)
 {
irq_handler_t timer_routine = dev_id;
@@ -350,6 +366,7 @@ static irqreturn_t mvme16x_timer_int (int irq, void *dev_id)
 
local_irq_save(flags);
*(volatile unsigned char *)0xfff4201b |= 8;
+   clk_total += PCC_TIMER_CYCLES;
timer_routine(0, NULL);
local_irq_restore(flags);
 
@@ -363,13 +380,15 @@ void mvme16x_sched_init (irq_handler_t timer_routine)
 
 /* Using PCCchip2 or MC2 chip tick timer 1 */
 *(volatile unsigned long *)0xfff42008 = 0;
-*(volatile unsigned long *)0xfff42004 = 1; /* 10ms */
+*(volatile unsigned long *)0xfff42004 = PCC_TIMER_CYCLES;
 *(volatile unsigned char *)0xfff42017 |= 3;
 *(volatile unsigned char *)0xfff4201b = 0x16;
-if (request_irq(MVME16x_IRQ_TIMER, mvme16x_timer_int, 0, "timer",
+if (request_irq(MVME16x_IRQ_TIMER, mvme16x_timer_int, IRQF_TIMER, "timer",
 timer_routine))
panic ("Couldn't register timer int");
 
+clocksource_register_hz(&mvme16x_clk, PCC_TIMER_CLOCK_FREQ);
+
 if (brdno == 0x0162 || brdno == 0x172)
irq = MVME162_IRQ_ABORT;
 else
@@ -379,11 +398,17 @@ void mvme16x_sched_init (irq_handler_t timer_routine)
panic ("Couldn't register abort int");
 }
 
-
-/* This is always executed with interrupts disabled.  */
-u32 mvme16x_gettimeoffset(void)
+static u64 mvme16x_read_clk(struct clocksource *cs)
 {
-return (*(volatile u32 *)0xfff42008) * 1000;
+   unsigned long flags;
+   u32 ticks;
+
+   local_irq_save(flags);
+   ticks = *(volatile u32 *)0xfff42008;
+   ticks += clk_total;
+   local_irq_restore(flags);
+
+   return ticks;
 }
 
 int bcd2int (unsigned char b)
-- 
2.18.1



[RFC PATCH v3 10/14] m68k: mac: Convert to clocksource API

2018-11-23 Thread Finn Thain
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.

Signed-off-by: Finn Thain 
Acked-by: Linus Walleij 
Tested-by: Stan Johnson 
---
Changed since v2:
 - Drop unneeded 'clk_offset' variable.

Changed since v1:
 - Moved clk_total access to within the irq lock.
 - Use type u32 for tick counter.
---
 arch/m68k/mac/via.c | 40 +---
 1 file changed, 33 insertions(+), 7 deletions(-)

diff --git a/arch/m68k/mac/via.c b/arch/m68k/mac/via.c
index f1f39ecf84c2..c226ca7eae84 100644
--- a/arch/m68k/mac/via.c
+++ b/arch/m68k/mac/via.c
@@ -23,6 +23,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -573,16 +574,38 @@ EXPORT_SYMBOL(via2_scsi_drq_pending);
 /* timer and clock source */
 
 #define VIA_CLOCK_FREQ 783360/* VIA "phase 2" clock in Hz 
*/
-#define VIA_TIMER_INTERVAL (100 / HZ)/* microseconds per jiffy */
 #define VIA_TIMER_CYCLES   (VIA_CLOCK_FREQ / HZ) /* clock cycles per jiffy */
 
 #define VIA_TC (VIA_TIMER_CYCLES - 2) /* including 0 and -1 */
 #define VIA_TC_LOW (VIA_TC & 0xFF)
 #define VIA_TC_HIGH(VIA_TC >> 8)
 
+static u64 mac_read_clk(struct clocksource *cs);
+
+static struct clocksource mac_clk = {
+   .name   = "via1",
+   .rating = 250,
+   .read   = mac_read_clk,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
+};
+
+static u32 clk_total;
+
+static irqreturn_t via_timer_handler(int irq, void *dev_id)
+{
+   irq_handler_t timer_routine = dev_id;
+
+   clk_total += VIA_TIMER_CYCLES;
+   timer_routine(0, NULL);
+
+   return IRQ_HANDLED;
+}
+
 void __init via_init_clock(irq_handler_t timer_routine)
 {
-   if (request_irq(IRQ_MAC_TIMER_1, timer_routine, 0, "timer", NULL)) {
+   if (request_irq(IRQ_MAC_TIMER_1, via_timer_handler, IRQF_TIMER, "timer",
+   timer_routine)) {
pr_err("Couldn't register %s interrupt\n", "timer");
return;
}
@@ -592,13 +615,16 @@ void __init via_init_clock(irq_handler_t timer_routine)
via1[vT1CL] = VIA_TC_LOW;
via1[vT1CH] = VIA_TC_HIGH;
via1[vACR] |= 0x40;
+
+   clocksource_register_hz(&mac_clk, VIA_CLOCK_FREQ);
 }
 
-u32 mac_gettimeoffset(void)
+static u64 mac_read_clk(struct clocksource *cs)
 {
unsigned long flags;
u8 count_high;
u16 count, offset = 0;
+   u32 ticks;
 
/*
 * Timer counter wrap-around is detected with the timer interrupt flag
@@ -615,10 +641,10 @@ u32 mac_gettimeoffset(void)
count_high = 0;
else if (via1[vIFR] & VIA_TIMER_1_INT)
offset = VIA_TIMER_CYCLES;
-   local_irq_restore(flags);
-
count = count_high << 8;
-   count = VIA_TIMER_CYCLES - count + offset;
+   ticks = VIA_TIMER_CYCLES - count;
+   ticks += offset + clk_total;
+   local_irq_restore(flags);
 
-   return ((count * VIA_TIMER_INTERVAL) / VIA_TIMER_CYCLES) * 1000;
+   return ticks;
 }
-- 
2.18.1



[RFC PATCH v3 14/14] m68k: mvme16x: Handle timer counter overflow

2018-11-23 Thread Finn Thain
Reading the timer counter races with timer overflow (and the
corresponding interrupt). This is resolved by reading the overflow
register and taking this value into account. The interrupt handler
must clear the overflow register when it eventually executes.

Suggested-by: Thomas Gleixner 
Signed-off-by: Finn Thain 
---
TODO: find a spare counter for the clocksource, rather than hanging
it off the HZ timer.
---
 arch/m68k/mvme16x/config.c | 45 +++---
 1 file changed, 32 insertions(+), 13 deletions(-)

diff --git a/arch/m68k/mvme16x/config.c b/arch/m68k/mvme16x/config.c
index 2c109ee2a1a5..9bc2da69f80c 100644
--- a/arch/m68k/mvme16x/config.c
+++ b/arch/m68k/mvme16x/config.c
@@ -115,11 +115,11 @@ static void __init mvme16x_init_IRQ (void)
m68k_setup_user_interrupt(VEC_USER, 192);
 }
 
-#define pcc2chip   ((volatile u_char *)0xfff42000)
-#define PccSCCMICR 0x1d
-#define PccSCCTICR 0x1e
-#define PccSCCRICR 0x1f
-#define PccTPIACKR 0x25
+#define PCC2CHIP   (0xfff42000)
+#define PCCSCCMICR (PCC2CHIP + 0x1d)
+#define PCCSCCTICR (PCC2CHIP + 0x1e)
+#define PCCSCCRICR (PCC2CHIP + 0x1f)
+#define PCCTPIACKR (PCC2CHIP + 0x25)
 
 #ifdef CONFIG_EARLY_PRINTK
 
@@ -227,10 +227,10 @@ void mvme16x_cons_write(struct console *co, const char 
*str, unsigned count)
base_addr[CyIER] = CyTxMpty;
 
while (1) {
-   if (pcc2chip[PccSCCTICR] & 0x20)
+   if (in_8(PCCSCCTICR) & 0x20)
{
/* We have a Tx int. Acknowledge it */
-   sink = pcc2chip[PccTPIACKR];
+   sink = in_8(PCCTPIACKR);
if ((base_addr[CyLICR] >> 2) == port) {
if (i == count) {
/* Last char of string is now output */
@@ -359,13 +359,26 @@ static u32 clk_total;
 #define PCC_TIMER_CLOCK_FREQ 100
 #define PCC_TIMER_CYCLES (PCC_TIMER_CLOCK_FREQ / HZ)
 
+#define PCCTCMP1 (PCC2CHIP + 0x04)
+#define PCCTCNT1 (PCC2CHIP + 0x08)
+#define PCCTOVR1 (PCC2CHIP + 0x17)
+#define PCCTIC1  (PCC2CHIP + 0x1b)
+
+#define PCCTOVR1_TIC_EN  0x01
+#define PCCTOVR1_COC_EN  0x02
+#define PCCTOVR1_OVR_CLR 0x04
+
+#define PCCTIC1_INT_CLR  0x08
+#define PCCTIC1_INT_EN   0x10
+
 static irqreturn_t mvme16x_timer_int (int irq, void *dev_id)
 {
irq_handler_t timer_routine = dev_id;
unsigned long flags;
 
local_irq_save(flags);
-   *(volatile unsigned char *)0xfff4201b |= 8;
+   out_8(PCCTIC1, in_8(PCCTIC1) | PCCTIC1_INT_CLR);
+   out_8(PCCTOVR1, PCCTOVR1_OVR_CLR);
clk_total += PCC_TIMER_CYCLES;
timer_routine(0, NULL);
local_irq_restore(flags);
@@ -379,10 +392,10 @@ void mvme16x_sched_init (irq_handler_t timer_routine)
 int irq;
 
 /* Using PCCchip2 or MC2 chip tick timer 1 */
-*(volatile unsigned long *)0xfff42008 = 0;
-*(volatile unsigned long *)0xfff42004 = PCC_TIMER_CYCLES;
-*(volatile unsigned char *)0xfff42017 |= 3;
-*(volatile unsigned char *)0xfff4201b = 0x16;
+out_be32(PCCTCNT1, 0);
+out_be32(PCCTCMP1, PCC_TIMER_CYCLES);
+out_8(PCCTOVR1, in_8(PCCTOVR1) | PCCTOVR1_TIC_EN | PCCTOVR1_COC_EN);
+out_8(PCCTIC1, PCCTIC1_INT_EN | 6);
 if (request_irq(MVME16x_IRQ_TIMER, mvme16x_timer_int, IRQF_TIMER, "timer",
 timer_routine))
panic ("Couldn't register timer int");
@@ -401,10 +414,16 @@ void mvme16x_sched_init (irq_handler_t timer_routine)
 static u64 mvme16x_read_clk(struct clocksource *cs)
 {
unsigned long flags;
+   u8 overflow, tmp;
u32 ticks;
 
local_irq_save(flags);
-   ticks = *(volatile u32 *)0xfff42008;
+   tmp = in_8(PCCTOVR1) >> 4;
+   ticks = in_be32(PCCTCNT1);
+   overflow = in_8(PCCTOVR1) >> 4;
+   if (overflow != tmp)
+   ticks = in_be32(PCCTCNT1);
+   ticks += overflow * PCC_TIMER_CYCLES;
ticks += clk_total;
local_irq_restore(flags);
 
-- 
2.18.1



Re: [RFC PATCH v2 07/14] m68k: atari: Convert to clocksource API

2018-11-23 Thread Finn Thain
On Sat, 24 Nov 2018, Michael Schmitz wrote:

> 
> Am 20.11.2018 um 23:02 schrieb Andreas Schwab:
> > On Nov 20 2018, Linus Walleij  wrote:
> > 
> > > Yes you already see the same as I see: this chip MK68901 has no less 
> > > than four timers. I bet the kernel is just using one of them, out of 
> > > habit.
> > 
> > Note that not all timers can be used freely.  Some of them are 
> > hardwired to generate the clock for the serial interfaces.
> 
> Timer A is used by the DMA sound driver - no workaround possible there.
> 
> Timer B is used by the framebuffer driver, but it's used only once to 
> reprogram the screen base address at driver init. This one could 
> potentially be used after framebuffer init to improve the clocksource 
> accuracy.
> 

I don't think it would make a good clocksource as MFP timers are all 8 
bits wide. It could be used as a clock event device in the course of a 
GENERIC_CLOCKEVENTS conversion (discussed elsewhere in this thread), 
though the longest timed interrupt inverval would be only 21 ms.

-- 

> Timer D is already used to generate timer interrupts used to poll the 
> ROM port network card / USB adapters. This timer is initialized early in 
> the boot process, which prevents using the MFP UART as serial console 
> (something that I hadn't properly considered before). I'll send a patch 
> for that. I'll also consider using timer B or timer C interrupts instead 
> to poll ROM port hardware.
> 
> There are no serial drivers anymore that could use the MFP UART 
> hardware, so that point is somewhat moot at present.
> 
> Cheers,
> 
>   Michael
> 
> > Andreas.
> > 
> 


Re: [PATCH v4] debugobjects: scale the static pool size

2018-11-23 Thread Qian Cai



> On Nov 22, 2018, at 4:56 PM, Thomas Gleixner  wrote:
> 
> On Tue, 20 Nov 2018, Qian Cai wrote:
> 
> Looking deeper at that.
> 
>> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
>> index 70935ed91125..140571aa483c 100644
>> --- a/lib/debugobjects.c
>> +++ b/lib/debugobjects.c
>> @@ -23,9 +23,81 @@
>> #define ODEBUG_HASH_BITS 14
>> #define ODEBUG_HASH_SIZE (1 << ODEBUG_HASH_BITS)
>> 
>> -#define ODEBUG_POOL_SIZE1024
>> +#define ODEBUG_DEFAULT_POOL 512
>> #define ODEBUG_POOL_MIN_LEVEL256
>> 
>> +/*
>> + * Some debug objects are allocated during the early boot. Enabling some 
>> options
>> + * like timers or workqueue objects may increase the size required 
>> significantly
>> + * with large number of CPUs. For example (as today, 20 Nov. 2018),
>> + *
>> + * No. CPUs x 2 (worker pool) objects:
>> + *
>> + * start_kernel
>> + *   workqueue_init_early
>> + * init_worker_pool
>> + *   init_timer_key
>> + * debug_object_init
>> + *
>> + * No. CPUs objects (CONFIG_HIGH_RES_TIMERS):
>> + *
>> + * sched_init
>> + *   hrtick_rq_init
>> + * hrtimer_init
>> + *
>> + * CONFIG_DEBUG_OBJECTS_WORK:
>> + * No. CPUs x 6 (workqueue) objects:
>> + *
>> + * workqueue_init_early
>> + *   alloc_workqueue
>> + * __alloc_workqueue_key
>> + *   alloc_and_link_pwqs
>> + * init_pwq
>> + *
>> + * Also, plus No. CPUs objects:
>> + *
>> + * perf_event_init
>> + *__init_srcu_struct
>> + *  init_srcu_struct_fields
>> + *init_srcu_struct_nodes
>> + *  __init_work
> 
> None of the things are actually used or required _BEFORE_
> debug_objects_mem_init() is invoked.
> 
> The reason why the call is at this place in start_kernel() is
> historical. It's because back in the days when debugobjects were added the
> memory allocator was enabled way later than today. So we can just move the
> debug_objects_mem_init() call right before sched_init() I think.

Well, now that kmemleak_init() seems complains that debug_objects_mem_init()
is called before it.

[0.078805] kmemleak: Cannot insert 0xc00dff93 into the object 
search tree (overlaps existing)
[0.078860] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.20.0-rc3+ #3
[0.078883] Call Trace:
[0.078904] [c1c8fcd0] [c0c96b34] dump_stack+0xe8/0x164 
(unreliable)
[0.078935] [c1c8fd20] [c0486e84] create_object+0x344/0x380
[0.078962] [c1c8fde0] [c0489544] early_alloc+0x108/0x1f8
[0.078989] [c1c8fe20] [c109738c] kmemleak_init+0x1d8/0x3d4
[0.079016] [c1c8ff00] [c1054028] start_kernel+0x5c0/0x6f8
[0.079043] [c1c8ff90] [c000ae7c] 
start_here_common+0x1c/0x520
[0.079070] kmemleak: Kernel memory leak detector disabled
[0.079091] kmemleak: Object 0xc00ffd587b68 (size 40):
[0.079112] kmemleak:   comm "swapper/0", pid 0, jiffies 4294937299
[0.079135] kmemleak:   min_count = -1
[0.079153] kmemleak:   count = 0
[0.079170] kmemleak:   flags = 0x5
[0.079188] kmemleak:   checksum = 0
[0.079206] kmemleak:   backtrace:
[0.079227]  __debug_object_init+0x688/0x700
[0.079250]  debug_object_activate+0x1e0/0x350
[0.079272]  __call_rcu+0x60/0x430
[0.079292]  put_object+0x60/0x80
[0.079311]  kmemleak_init+0x2cc/0x3d4
[0.079331]  start_kernel+0x5c0/0x6f8
[0.079351]  start_here_common+0x1c/0x520
[0.079380] kmemleak: Early log backtrace:
[0.079399]memblock_alloc_try_nid_raw+0x90/0xcc
[0.079421]sparse_init_nid+0x144/0x51c
[0.079440]sparse_init+0x1a0/0x238
[0.079459]initmem_init+0x1d8/0x25c
[0.079498]setup_arch+0x3e0/0x464
[0.079517]start_kernel+0xa4/0x6f8
[0.079536]start_here_common+0x1c/0x520



Re: [PATCH] debugobjects: call debug_objects_mem_init eariler

2018-11-23 Thread Qian Cai



> On Nov 23, 2018, at 4:46 PM, Thomas Gleixner  wrote:
> 
> On Thu, 22 Nov 2018, Waiman Long wrote:
>> On 11/22/2018 11:31 PM, Qian Cai wrote:
>>> The current value of the early boot static pool size, 1024 is not big
>>> enough for systems with large number of CPUs with timer or/and workqueue
>>> objects selected. As the results, systems have 60+ CPUs with both timer
>>> and workqueue objects enabled could trigger "ODEBUG: Out of memory.
>>> ODEBUG disabled".
>>> 
>>> However, none of the things are actually used or required beofre
> 
> before
> 
>>> debug_objects_mem_init() is invoked.
>>> 
>>> According to tglx,
>>> "the reason why the call is at this place in start_kernel() is
>>> historical. It's because back in the days when debugobjects were added
>>> the memory allocator was enabled way later than today. So we can just
>>> move the debug_objects_mem_init() call right before sched_init()."
>>> 
>>> Afterwards, when calling debug_objects_mem_init(), interrupts have
>>> already been disabled and lockdep_init() will only be called later, so
>>> no need to worry about interrupts in
>>> debug_objects_replace_static_objects().
> 
> Just out of curiosity. How many objects are allocated between early and mem
> init?

64-CPU:   68
160-CPU: 164
256-CPU: 260

INIT_WORK(&p->wq, free_work) is called per CPU:

start_kernel
   vmalloc_init
  __init_work
__debug_object_init

Once debug_objects_mem_init() is moved just before vmalloc_init(), there
is only 1 object.

ODEBUG: 1 of 1 active objects replace

> 
>>> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
>>> index 70935ed91125..cc5818ced652 100644
>>> --- a/lib/debugobjects.c
>>> +++ b/lib/debugobjects.c
>>> @@ -1132,13 +1132,6 @@ static int __init 
>>> debug_objects_replace_static_objects(void)
>>> hlist_add_head(&obj->node, &objects);
>>> }
>>> 
>>> -   /*
>>> -* When debug_objects_mem_init() is called we know that only
>>> -* one CPU is up, so disabling interrupts is enough
>>> -* protection. This avoids the lockdep hell of lock ordering.
>>> -*/
>>> -   local_irq_disable();
>> 
>> I think you should have a comment saying that debug_objects_mm_init() is
>> called early with only one CPU up and interrupt disabled. So it is safe
>> to replace static objects without any protection.
> 
> Yes please.
> 
> Thanks,
> 
>   tglx



[PATCH V2] hfs: do not free node before using

2018-11-23 Thread Pan Bian
The function hfs_bmap_free frees node via hfs_bnode_put(node). However,
it then reads node->this when dumping error message on an error path,
which may result in a use-after-free bug. This patch frees node only
when it is never used.

Fixes: a1185ffa2fc("HFS rewrite")

Signed-off-by: Pan Bian 

---
V2: correct the commit information in Fixes

---
 fs/hfs/btree.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/hfs/btree.c b/fs/hfs/btree.c
index 98b96ff..19017d2 100644
--- a/fs/hfs/btree.c
+++ b/fs/hfs/btree.c
@@ -338,13 +338,14 @@ void hfs_bmap_free(struct hfs_bnode *node)
 
nidx -= len * 8;
i = node->next;
-   hfs_bnode_put(node);
if (!i) {
/* panic */;
pr_crit("unable to free bnode %u. bmap not found!\n",
node->this);
+   hfs_bnode_put(node);
return;
}
+   hfs_bnode_put(node);
node = hfs_bnode_find(tree, i);
if (IS_ERR(node))
return;
-- 
2.7.4




Re: [RFC][PATCH] fs: set xattrs in initramfs from regular files

2018-11-23 Thread Casey Schaufler
On 11/23/2018 11:30 AM, Mimi Zohar wrote:
> On Fri, 2018-11-23 at 11:03 -0800, Casey Schaufler wrote:
>> On 11/22/2018 7:49 AM, Roberto Sassu wrote:
>>> Although rootfs (tmpfs) supports xattrs, they are not set due to the
>>> limitation of the cpio format. A new format called 'newcx' was proposed to
>>> overcome this limitation.
>>>
>>> However, it looks like that adding a new format is not simple: 15 kernel
>>> patches; user space tools must support the new format; mistakes made in the
>>> past should be avoided; it is unclear whether the kernel should switch from
>>> cpio to tar.
>>>
>>> The aim of this patch is to provide the same functionality without
>>> introducing a new format. The value of xattrs is placed in regular files
>>> having the same file name as the files xattrs are added to, plus a
>>> separator and the xattr name (.xattr-).
>>>
>>> Example:
>>>
>>> '/bin/cat.xattr-security.ima' is the name of a file containing the value of
>>> the security.ima xattr to be added to /bin/cat.
>>>
>>> At kernel initialization time, the kernel iterates over the rootfs
>>> filesystem, and if it encounters files with the '.xattr-' separator, it
>>> reads the content and adds the xattr to the file without the suffix.
>> No.
>>
>> Really, no.
>>
>> It would be incredibly easy to use this mechanism to break
>> into systems.
>>  
>>
>>> This proposal requires that LSMs and IMA allow the read and setxattr
>>> operations. This should not be a concern since: files with xattr values
>>> are not parsed by the kernel; user space processes are not yet executed.
>>>
>>> It would be possible to include all xattrs in the same file, but this
>>> increases the risk of the kernel being compromised by parsing the content.
>> The kernel mustn't do this.
> Mustn't do what?  Store the xattr as separate detached files, 
> include all the xattrs in a single or per security/LSM xattr attribute
> file(s), or either?

Any and all of the above. The proposed behavior is a kludge
around making the installation tools work correctly. Sure, it
may be easier to change the kernel than to change the utilities.
That's doesn't make it right.

>
> Mimi
>
>



Re: [RFC PATCH v2 07/14] m68k: atari: Convert to clocksource API

2018-11-23 Thread Michael Schmitz



Am 20.11.2018 um 23:02 schrieb Andreas Schwab:

On Nov 20 2018, Linus Walleij  wrote:


Yes you already see the same as I see: this chip MK68901 has
no less than four timers. I bet the kernel is just using one of them,
out of habit.


Note that not all timers can be used freely.  Some of them are hardwired
to generate the clock for the serial interfaces.


Timer A is used by the DMA sound driver - no workaround possible there.

Timer B is used by the framebuffer driver, but it's used only once to 
reprogram the screen base address at driver init. This one could 
potentially be used after framebuffer init to improve the clocksource 
accuracy.


Timer D is already used to generate timer interrupts used to poll the 
ROM port network card / USB adapters. This timer is initialized early in 
the boot process, which prevents using the MFP UART as serial console 
(something that I hadn't properly considered before). I'll send a patch 
for that. I'll also consider using timer B or timer C interrupts instead 
to poll ROM port hardware.


There are no serial drivers anymore that could use the MFP UART 
hardware, so that point is somewhat moot at present.


Cheers,

Michael


Andreas.



Re: [PATCH] hfs: do not free node before using

2018-11-23 Thread PanBian
On Fri, Nov 23, 2018 at 04:51:49PM -0800, Viacheslav Dubeyko wrote:
> On Fri, 2018-11-23 at 17:04 +0800, Pan Bian wrote:
> > The function hfs_bmap_free frees node via hfs_bnode_put(node).
> > However,
> > it then reads node->this when dumping error message on an error path,
> > which may result in a use-after-free bug. This patch frees node only
> > when it is never used.
> > 
> > Fixes: d614267329f("hfs/hfsplus: convert printks to pr_")
> > 
> > Signed-off-by: Pan Bian 
> > ---
> >  fs/hfs/btree.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/fs/hfs/btree.c b/fs/hfs/btree.c
> > index 98b96ff..19017d2 100644
> > --- a/fs/hfs/btree.c
> > +++ b/fs/hfs/btree.c
> > @@ -338,13 +338,14 @@ void hfs_bmap_free(struct hfs_bnode *node)
> >  
> >     nidx -= len * 8;
> >     i = node->next;
> > -   hfs_bnode_put(node);
> >     if (!i) {
> >     /* panic */;
> >     pr_crit("unable to free bnode %u. bmap not
> > found!\n",
> >     node->this);
> 
> 
> What's about simply to store node->this into the local variable in the
> beginning of the cycle? In this case, it is possible to use the node ID
> in the pr_crit() and to use the hfs_bnode_put(node) in the same place
> without to use it twice. What do you think?

Of course, it is a solution. But I think doing like that does not really
simplify the code, as we have to declare an extra local variable, and
assign node->this to it...

Best,
Pan

> 
> Thanks,
> Vyacheslav Dubeyko.
> 
> 
> > +   hfs_bnode_put(node);
> >     return;
> >     }
> > +   hfs_bnode_put(node);
> >     node = hfs_bnode_find(tree, i);
> >     if (IS_ERR(node))
> >     return;



Re: [PATCH] hfs: do not free node before using

2018-11-23 Thread Viacheslav Dubeyko
On Fri, 2018-11-23 at 17:04 +0800, Pan Bian wrote:
> The function hfs_bmap_free frees node via hfs_bnode_put(node).
> However,
> it then reads node->this when dumping error message on an error path,
> which may result in a use-after-free bug. This patch frees node only
> when it is never used.
> 
> Fixes: d614267329f("hfs/hfsplus: convert printks to pr_")
> 
> Signed-off-by: Pan Bian 
> ---
>  fs/hfs/btree.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/hfs/btree.c b/fs/hfs/btree.c
> index 98b96ff..19017d2 100644
> --- a/fs/hfs/btree.c
> +++ b/fs/hfs/btree.c
> @@ -338,13 +338,14 @@ void hfs_bmap_free(struct hfs_bnode *node)
>  
>   nidx -= len * 8;
>   i = node->next;
> - hfs_bnode_put(node);
>   if (!i) {
>   /* panic */;
>   pr_crit("unable to free bnode %u. bmap not
> found!\n",
>   node->this);


What's about simply to store node->this into the local variable in the
beginning of the cycle? In this case, it is possible to use the node ID
in the pr_crit() and to use the hfs_bnode_put(node) in the same place
without to use it twice. What do you think?

Thanks,
Vyacheslav Dubeyko.


> + hfs_bnode_put(node);
>   return;
>   }
> + hfs_bnode_put(node);
>   node = hfs_bnode_find(tree, i);
>   if (IS_ERR(node))
>   return;


Re: [PATCH] staging: iio: ad5933: finalized device-tree support

2018-11-23 Thread Rodrigo Siqueira
Hi Marcelo,

I believe that a proper commit message for this patch could be something
like "Add device tree support".

On 11/23, Marcelo Schmitt wrote:
> Added a of_device_id struct variable and subsequent call to
> MODULE_DEVICE_TABLE macro to complete device-tree support for this
> driver.
> 
> Signed-off-by: Marcelo Schmitt 
> ---
>  drivers/staging/iio/impedance-analyzer/ad5933.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c 
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index edb8b540bbf1..19e8b6d2865c 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -771,9 +771,18 @@ static const struct i2c_device_id ad5933_id[] = {
>  
>  MODULE_DEVICE_TABLE(i2c, ad5933_id);
>  
> +static const struct of_device_id ad5933_of_match[] = {
> + { .compatible = "analog-devices,ad5933" },
> + { .compatible = "analog-devices,ad5934" },
> + { },
> +};
> +
> +MODULE_DEVICE_TABLE(of, ad5933_of_match);
> +
>  static struct i2c_driver ad5933_driver = {
>   .driver = {
>   .name = "ad5933",
> + .of_match_table = ad5933_of_match,
>   },
>   .probe = ad5933_probe,
>   .remove = ad5933_remove,
> -- 
> 2.17.1
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Kernel USP" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to kernel-usp+unsubscr...@googlegroups.com.
> To post to this group, send email to kernel-...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/kernel-usp/20181123235159.hh43xnvvwsil4on2%40smtp.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
Rodrigo Siqueira
https://siqueira.tech
https://twitter.com/siqueirajordao
Graduate Student
Department of Computer Science
University of São Paulo


signature.asc
Description: PGP signature


Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

2018-11-23 Thread Tetsuo Handa
On 2018/11/24 0:56, Steven Rostedt wrote:
> On Fri, 23 Nov 2018 13:46:47 +0100
> Petr Mladek  wrote:
> 
>> Steven told me on Plumbers conference that even few initial
>> characters saved him a day few times.
> 
> Yes, and that has happened more than once. I would reboot and retest
> code that is crashing, and due to a triple fault, the machine would
> reboot because of some race, and the little output I get from the
> console would help tremendously.
> 
> Remember, debugging the kernel is a lot like forensics, especially when
> it's from a customer's site. You look at all the evidence that you can
> get, and sometimes it's just 10 characters in the output that gives you
> an idea of where things went wrong. I'm really not liking the buffering
> idea because of this.

Then, we should not enforce buffering in a way that requires modification of
printk() callers. That is, we should not ask printk() callers to use their
private buffer. What we can do is to enable/disable line buffering inside
printk() depending on the problem the user wants to debug.

Also, we should allow disabling "struct cont" depending on the problem (in
order to allow flushing the 10 characters in the "cont" buffer).



By the way, is the comment

  /*
   * Continuation lines are buffered, and not committed to the record buffer
   * until the line is complete, or a race forces it. The line fragments
   * though, are printed immediately to the consoles to ensure everything has
   * reached the console in case of a kernel crash.
   */

appropriate despite we don't call cont_flush() upon a kernel crash?



[PATCH v3 7/7] staging:iio:ad2s90: Move out of staging

2018-11-23 Thread Matheus Tavares
Move ad2s90 resolver driver out of staging to the main tree.

Signed-off-by: Matheus Tavares 
Signed-off-by: Victor Colombo 
---
Changes in v3:
 - none

Changes in v2:
 - Disabled git move detection, to see the whole code, as Jonathan
 suggested

 drivers/iio/resolver/Kconfig  |  10 ++
 drivers/iio/resolver/Makefile |   1 +
 drivers/iio/resolver/ad2s90.c | 131 ++
 drivers/staging/iio/resolver/Kconfig  |  10 --
 drivers/staging/iio/resolver/Makefile |   1 -
 drivers/staging/iio/resolver/ad2s90.c | 131 --
 6 files changed, 142 insertions(+), 142 deletions(-)
 create mode 100644 drivers/iio/resolver/ad2s90.c
 delete mode 100644 drivers/staging/iio/resolver/ad2s90.c

diff --git a/drivers/iio/resolver/Kconfig b/drivers/iio/resolver/Kconfig
index 2ced9f22aa70..786801be54f6 100644
--- a/drivers/iio/resolver/Kconfig
+++ b/drivers/iio/resolver/Kconfig
@@ -3,6 +3,16 @@
 #
 menu "Resolver to digital converters"
 
+config AD2S90
+   tristate "Analog Devices ad2s90 driver"
+   depends on SPI
+   help
+ Say yes here to build support for Analog Devices spi resolver
+ to digital converters, ad2s90, provides direct access via sysfs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad2s90.
+
 config AD2S1200
tristate "Analog Devices ad2s1200/ad2s1205 driver"
depends on SPI
diff --git a/drivers/iio/resolver/Makefile b/drivers/iio/resolver/Makefile
index 4e1dccae07e7..398d82d50028 100644
--- a/drivers/iio/resolver/Makefile
+++ b/drivers/iio/resolver/Makefile
@@ -2,4 +2,5 @@
 # Makefile for Resolver/Synchro drivers
 #
 
+obj-$(CONFIG_AD2S90) += ad2s90.o
 obj-$(CONFIG_AD2S1200) += ad2s1200.o
diff --git a/drivers/iio/resolver/ad2s90.c b/drivers/iio/resolver/ad2s90.c
new file mode 100644
index ..a41f5cb10da5
--- /dev/null
+++ b/drivers/iio/resolver/ad2s90.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ad2s90.c simple support for the ADI Resolver to Digital Converters: AD2S90
+ *
+ * Copyright (c) 2010-2010 Analog Devices Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/*
+ * Although chip's max frequency is 2Mhz, it needs 600ns between CS and the
+ * first falling edge of SCLK, so frequency should be at most 1 / (2 * 6e-7)
+ */
+#define AD2S90_MAX_SPI_FREQ_HZ  83
+
+struct ad2s90_state {
+   struct mutex lock; /* lock to protect rx buffer */
+   struct spi_device *sdev;
+   u8 rx[2] cacheline_aligned;
+};
+
+static int ad2s90_read_raw(struct iio_dev *indio_dev,
+  struct iio_chan_spec const *chan,
+  int *val,
+  int *val2,
+  long m)
+{
+   int ret;
+   struct ad2s90_state *st = iio_priv(indio_dev);
+
+   if (chan->type != IIO_ANGL)
+   return -EINVAL;
+
+   switch (m) {
+   case IIO_CHAN_INFO_SCALE:
+   /* 2 * Pi / 2^12 */
+   *val = 6283; /* mV */
+   *val2 = 12;
+   return IIO_VAL_FRACTIONAL_LOG2;
+   case IIO_CHAN_INFO_RAW:
+   mutex_lock(&st->lock);
+   ret = spi_read(st->sdev, st->rx, 2);
+   if (ret < 0) {
+   mutex_unlock(&st->lock);
+   return ret;
+   }
+   *val = (((u16)(st->rx[0])) << 4) | ((st->rx[1] & 0xF0) >> 4);
+
+   mutex_unlock(&st->lock);
+
+   return IIO_VAL_INT;
+   default:
+   break;
+   }
+
+   return -EINVAL;
+}
+
+static const struct iio_info ad2s90_info = {
+   .read_raw = ad2s90_read_raw,
+};
+
+static const struct iio_chan_spec ad2s90_chan = {
+   .type = IIO_ANGL,
+   .indexed = 1,
+   .channel = 0,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
+};
+
+static int ad2s90_probe(struct spi_device *spi)
+{
+   struct iio_dev *indio_dev;
+   struct ad2s90_state *st;
+
+   if (spi->max_speed_hz > AD2S90_MAX_SPI_FREQ_HZ) {
+   dev_err(&spi->dev, "SPI CLK, %d Hz exceeds %d Hz\n",
+   spi->max_speed_hz, AD2S90_MAX_SPI_FREQ_HZ);
+   return -EINVAL;
+   }
+
+   indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
+   if (!indio_dev)
+   return -ENOMEM;
+   st = iio_priv(indio_dev);
+   spi_set_drvdata(spi, indio_dev);
+
+   mutex_init(&st->lock);
+   st->sdev = spi;
+   indio_dev->dev.parent = &spi->dev;
+   indio_dev->info = &ad2s90_info;
+   indio_dev->modes = INDIO_DIRECT_MODE;
+   indio_dev->channels = &ad2s90_chan;
+   indio_dev->num_channels = 1;
+   indio_dev->name = spi_get_device_id(spi)->name;
+
+   return devm_iio_device_register(indio_dev->dev.parent, indio_dev);
+}
+
+static const struct of_device_id ad2s90_of_match[] = {

[PATCH v3 1/7] staging:iio:ad2s90: Add device tree support

2018-11-23 Thread Matheus Tavares
This patch adds device tree support to ad2s90 with standard
device tree id table.

Signed-off-by: Matheus Tavares 
---
Changes in v3:
 - Removed of_patch_ptr from of_match_table assignment

Changes in v2:
 - none

 drivers/staging/iio/resolver/ad2s90.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/staging/iio/resolver/ad2s90.c 
b/drivers/staging/iio/resolver/ad2s90.c
index 3e257ac46f7a..fdae067ed866 100644
--- a/drivers/staging/iio/resolver/ad2s90.c
+++ b/drivers/staging/iio/resolver/ad2s90.c
@@ -107,6 +107,12 @@ static int ad2s90_probe(struct spi_device *spi)
return devm_iio_device_register(indio_dev->dev.parent, indio_dev);
 }
 
+static const struct of_device_id ad2s90_of_match[] = {
+   { .compatible = "adi,ad2s90", },
+   {}
+};
+MODULE_DEVICE_TABLE(of, ad2s90_of_match);
+
 static const struct spi_device_id ad2s90_id[] = {
{ "ad2s90" },
{}
@@ -116,6 +122,7 @@ MODULE_DEVICE_TABLE(spi, ad2s90_id);
 static struct spi_driver ad2s90_driver = {
.driver = {
.name = "ad2s90",
+   .of_match_table = ad2s90_of_match,
},
.probe = ad2s90_probe,
.id_table = ad2s90_id,
-- 
2.18.0



[PATCH v3 3/7] staging:iio:ad2s90: Add max frequency check at probe

2018-11-23 Thread Matheus Tavares
From: Alexandru Ardelean 

This patch adds a max frequency check at the beginning of ad2s90_probe
function so that when it is set to a value above 0.83Mhz, dev_err is
called with an appropriate message and -EINVAL is returned.

The defined limit is 0.83Mhz instead of 2Mhz, which is the chip's max
frequency as specified in the datasheet, because, as also specified in
the datasheet, a 600ns delay is expected between the application of a
logic LO to CS and the application of SCLK. Since the delay is not
implemented in the spi code, to satisfy it, SCLK's period should be at
most 2 * 600ns, so the max frequency should be 1 / (2 * 6e-7), which
gives roughly 83Hz.

Signed-off-by: Alexandru Ardelean 
Signed-off-by: Matheus Tavares 
---
Changes in v3:
 - none

Changes in v2:
 - Correctly credit Alexandru as the patch's author

 drivers/staging/iio/resolver/ad2s90.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/staging/iio/resolver/ad2s90.c 
b/drivers/staging/iio/resolver/ad2s90.c
index abb9b9147ee6..4721e9bbb8b0 100644
--- a/drivers/staging/iio/resolver/ad2s90.c
+++ b/drivers/staging/iio/resolver/ad2s90.c
@@ -19,6 +19,12 @@
 #include 
 #include 
 
+/*
+ * Although chip's max frequency is 2Mhz, it needs 600ns between CS and the
+ * first falling edge of SCLK, so frequency should be at most 1 / (2 * 6e-7)
+ */
+#define AD2S90_MAX_SPI_FREQ_HZ  83
+
 struct ad2s90_state {
struct mutex lock;
struct spi_device *sdev;
@@ -78,6 +84,12 @@ static int ad2s90_probe(struct spi_device *spi)
struct iio_dev *indio_dev;
struct ad2s90_state *st;
 
+   if (spi->max_speed_hz > AD2S90_MAX_SPI_FREQ_HZ) {
+   dev_err(&spi->dev, "SPI CLK, %d Hz exceeds %d Hz\n",
+   spi->max_speed_hz, AD2S90_MAX_SPI_FREQ_HZ);
+   return -EINVAL;
+   }
+
indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
if (!indio_dev)
return -ENOMEM;
-- 
2.18.0



[PATCH v3 0/7] staging:iio:ad2s90: Add dt support and move out of staging

2018-11-23 Thread Matheus Tavares
This series adds device tree support to ad2s90, adds the respective dt-binding
documentation, solves all remaining codestyle problems for ad2s90 and move it
out of staging.

This patch set completes all the remaining itens listed to be done before moving
the driver out of staging, enumerated in this mail thread:
https://marc.info/?l=linux-iio&m=154028966111330&w=2.

Alexandru Ardelean (1):
  staging:iio:ad2s90: Add max frequency check at probe

Matheus Tavares (5):
  staging:iio:ad2s90: Add device tree support
  staging:iio:ad2s90: Remove spi setup that should be done via dt
  dt-bindings:iio:resolver: Add docs for ad2s90
  staging:iio:ad2s90: Replace license text w/ SPDX identifier
  staging:iio:ad2s90: Move out of staging

Victor Colombo (1):
  staging:iio:ad2s90: Add comment to device state mutex

 .../bindings/iio/resolver/ad2s90.txt  |  31 +
 drivers/iio/resolver/Kconfig  |  10 ++
 drivers/iio/resolver/Makefile |   1 +
 drivers/iio/resolver/ad2s90.c | 131 ++
 drivers/staging/iio/resolver/Kconfig  |  10 --
 drivers/staging/iio/resolver/Makefile |   1 -
 drivers/staging/iio/resolver/ad2s90.c | 127 -
 7 files changed, 173 insertions(+), 138 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/resolver/ad2s90.txt
 create mode 100644 drivers/iio/resolver/ad2s90.c
 delete mode 100644 drivers/staging/iio/resolver/ad2s90.c

-- 
2.18.0



[PATCH v3 5/7] staging:iio:ad2s90: Replace license text w/ SPDX identifier

2018-11-23 Thread Matheus Tavares
This patch removes the license boilerplate text at the top of ad2s90.c
and, instead, adds the SPDX GPL-2.0 license identifier, which solves the
checkpatch.pl warning:
"WARNING: Missing or malformed SPDX-License-Identifier tag in line 1".

Signed-off-by: Matheus Tavares 
---
Changes in v3:
 - none

Changes in v2:
 - Changed GPL-2.0-only identifier to GPL-2.0
 - Removed license boilerplate text
 - Rewritten patch message to reflect these modifications

 drivers/staging/iio/resolver/ad2s90.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/staging/iio/resolver/ad2s90.c 
b/drivers/staging/iio/resolver/ad2s90.c
index 4721e9bbb8b0..678351dabe6b 100644
--- a/drivers/staging/iio/resolver/ad2s90.c
+++ b/drivers/staging/iio/resolver/ad2s90.c
@@ -1,12 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * ad2s90.c simple support for the ADI Resolver to Digital Converters: AD2S90
  *
  * Copyright (c) 2010-2010 Analog Devices Inc.
- *
- * 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 
-- 
2.18.0



[PATCH v3 6/7] staging:iio:ad2s90: Add comment to device state mutex

2018-11-23 Thread Matheus Tavares
From: Victor Colombo 

Fix the checkpatch.pl issue:
"CHECK: struct mutex definition without comment".

Signed-off-by: Victor Colombo 
Signed-off-by: Matheus Tavares 
---
Changes in v3:
 - none

Changes in v2:
 - Patch added in v2

 drivers/staging/iio/resolver/ad2s90.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/resolver/ad2s90.c 
b/drivers/staging/iio/resolver/ad2s90.c
index 678351dabe6b..a41f5cb10da5 100644
--- a/drivers/staging/iio/resolver/ad2s90.c
+++ b/drivers/staging/iio/resolver/ad2s90.c
@@ -22,7 +22,7 @@
 #define AD2S90_MAX_SPI_FREQ_HZ  83
 
 struct ad2s90_state {
-   struct mutex lock;
+   struct mutex lock; /* lock to protect rx buffer */
struct spi_device *sdev;
u8 rx[2] cacheline_aligned;
 };
-- 
2.18.0



[PATCH v3 4/7] dt-bindings:iio:resolver: Add docs for ad2s90

2018-11-23 Thread Matheus Tavares
This patch adds the device tree binding documentation for the ad2s90
resolver-to-digital converter.

Signed-off-by: Matheus Tavares 
---
Changes in v3:
 - Added reference to spi-bus documentation after spi properties, as
 suggested by Alexandru Ardelean.

Changes in v2:
 - Rewritten 'spi-cpol and spi-cpha' item to say that the device can
 work in either mode (0,0) or (1,1) and explain how they should be
 specified in DT.

 .../bindings/iio/resolver/ad2s90.txt  | 31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/resolver/ad2s90.txt

diff --git a/Documentation/devicetree/bindings/iio/resolver/ad2s90.txt 
b/Documentation/devicetree/bindings/iio/resolver/ad2s90.txt
new file mode 100644
index ..477d41fa6467
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/resolver/ad2s90.txt
@@ -0,0 +1,31 @@
+Analog Devices AD2S90 Resolver-to-Digital Converter
+
+https://www.analog.com/en/products/ad2s90.html
+
+Required properties:
+  - compatible: should be "adi,ad2s90"
+  - reg: SPI chip select number for the device
+  - spi-max-frequency: set maximum clock frequency, must be 83
+  - spi-cpol and spi-cpha:
+Either SPI mode (0,0) or (1,1) must be used, so specify none or both of
+spi-cpha, spi-cpol.
+
+See for more details:
+Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Note about max frequency:
+Chip's max frequency, as specified in its datasheet, is 2Mhz. But a 600ns
+delay is expected between the application of a logic LO to CS and the
+application of SCLK, as also specified. And since the delay is not
+implemented in the spi code, to satisfy it, SCLK's period should be at most
+2 * 600ns, so the max frequency should be 1 / (2 * 6e-7), which gives
+roughly 83Hz.
+
+Example:
+resolver@0 {
+   compatible = "adi,ad2s90";
+   reg = <0>;
+   spi-max-frequency = <83>;
+   spi-cpol;
+   spi-cpha;
+};
-- 
2.18.0



[PATCH v3 2/7] staging:iio:ad2s90: Remove spi setup that should be done via dt

2018-11-23 Thread Matheus Tavares
The ad2s90 driver currently sets some spi settings (max_speed_hz and
mode) at ad2s90_probe. Since the maximum frequency is a required element
in DT binding for spi slave devices and because the spi mode for the
device can be either (0,0) or (1,1), these settings should be handled
via device tree, not in the driver's code. This patch removes them from
the probe function.

Note: The way in which the mentioned spi settings need to be specified
on the ad2s90's node of a device tree will be documented in the future
patch "dt-bindings:iio:resolver: Add docs for ad2s90".

Signed-off-by: Matheus Tavares 
---
Changes in v3:
 - none

Changes in v2:
 - Rewritten patch message to better explain why the code snippet in
 question should be removed.

 drivers/staging/iio/resolver/ad2s90.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/staging/iio/resolver/ad2s90.c 
b/drivers/staging/iio/resolver/ad2s90.c
index fdae067ed866..abb9b9147ee6 100644
--- a/drivers/staging/iio/resolver/ad2s90.c
+++ b/drivers/staging/iio/resolver/ad2s90.c
@@ -77,7 +77,6 @@ static int ad2s90_probe(struct spi_device *spi)
 {
struct iio_dev *indio_dev;
struct ad2s90_state *st;
-   int ret;
 
indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
if (!indio_dev)
@@ -94,16 +93,6 @@ static int ad2s90_probe(struct spi_device *spi)
indio_dev->num_channels = 1;
indio_dev->name = spi_get_device_id(spi)->name;
 
-   /* need 600ns between CS and the first falling edge of SCLK */
-   spi->max_speed_hz = 83;
-   spi->mode = SPI_MODE_3;
-   ret = spi_setup(spi);
-
-   if (ret < 0) {
-   dev_err(&spi->dev, "spi_setup failed!\n");
-   return ret;
-   }
-
return devm_iio_device_register(indio_dev->dev.parent, indio_dev);
 }
 
-- 
2.18.0



Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1

2018-11-23 Thread Aaro Koskinen
Hi,

On Fri, Nov 23, 2018 at 01:45:46PM +0200, Peter Ujfalusi wrote:
> On 23/11/2018 0.01, Aaro Koskinen wrote:
> > With that reverted, the DMA works OK (and I can also now confirm that
> > OMAP_DMA_LCH_2D works). I haven't yet checked if we actually need that
> > quirk in OMAP UDC,
> 
> The omap_udc driver is a bit of a mess, need to check it myself, but for
> now we can just set the quirk_ep_out_aligned_size and investigate later.

OK, with quirk_ep_out_aligned_size we get 770/16xx DMA working again,
but on 15xx the omap_udc DMA still doesn't work (tested today for the
first time ever, I have no idea if it has ever worked and if so, when?).

A.


Re: [RFC PATCH 1/5] mm: print more information about mapping in __dump_page

2018-11-23 Thread Andrew Morton
On Wed,  7 Nov 2018 11:18:26 +0100 Michal Hocko  wrote:

> From: Michal Hocko 
> 
> __dump_page prints the mapping pointer but that is quite unhelpful
> for many reports because the pointer itself only helps to distinguish
> anon/ksm mappings from other ones (because of lowest bits
> set). Sometimes it would be much more helpful to know what kind of
> mapping that is actually and if we know this is a file mapping then also
> try to resolve the dentry name.
> 
> ...
>
> --- a/mm/debug.c
> +++ b/mm/debug.c
>
> ...
>
> @@ -70,6 +71,18 @@ void __dump_page(struct page *page, const char *reason)
>   if (PageCompound(page))
>   pr_cont(" compound_mapcount: %d", compound_mapcount(page));
>   pr_cont("\n");
> + if (PageAnon(page))
> + pr_emerg("anon ");
> + else if (PageKsm(page))
> + pr_emerg("ksm ");
> + else if (mapping) {
> + pr_emerg("%ps ", mapping->a_ops);
> + if (mapping->host->i_dentry.first) {
> + struct dentry *dentry;
> + dentry = container_of(mapping->host->i_dentry.first, 
> struct dentry, d_u.d_alias);
> + pr_emerg("name:\"%*s\" ", dentry->d_name.len, 
> dentry->d_name.name);
> + }
> + }

There has to be a better way of printing the filename.  It is so often
needed.

The (poorly named and gleefully undocumented)
take_dentry_name_snapshot() looks promising.  However it's unclear that
__dump_page() is always called from contexts where
take_dentry_name_snapshot() and release_dentry_name_snapshot() can be
safely called.  Probably it's OK, but how to guarantee it?




[PATCH] staging: iio: ad5933: finalized device-tree support

2018-11-23 Thread Marcelo Schmitt
Added a of_device_id struct variable and subsequent call to
MODULE_DEVICE_TABLE macro to complete device-tree support for this
driver.

Signed-off-by: Marcelo Schmitt 
---
 drivers/staging/iio/impedance-analyzer/ad5933.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c 
b/drivers/staging/iio/impedance-analyzer/ad5933.c
index edb8b540bbf1..19e8b6d2865c 100644
--- a/drivers/staging/iio/impedance-analyzer/ad5933.c
+++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
@@ -771,9 +771,18 @@ static const struct i2c_device_id ad5933_id[] = {
 
 MODULE_DEVICE_TABLE(i2c, ad5933_id);
 
+static const struct of_device_id ad5933_of_match[] = {
+   { .compatible = "analog-devices,ad5933" },
+   { .compatible = "analog-devices,ad5934" },
+   { },
+};
+
+MODULE_DEVICE_TABLE(of, ad5933_of_match);
+
 static struct i2c_driver ad5933_driver = {
.driver = {
.name = "ad5933",
+   .of_match_table = ad5933_of_match,
},
.probe = ad5933_probe,
.remove = ad5933_remove,
-- 
2.17.1



Re: [PATCH v3 3/3] ALSA: hda: add support for Huawei WMI micmute LED

2018-11-23 Thread Pavel Machek
Hi!

> > > > > > > You have general-purpose LED, yet you are treating it as 
> > > > > > > "something
> > > > > > > special". That means ugly code (quoted above) and lack of 
> > > > > > > flexibility.
> > > > > > >

> > I'd prefer this to be normal LED and "mic muted" to become normal
> > trigger.
> 
> But how would you solve the existing problem?
> 
> As already mentioned, you'll need to hook the LED trigger and the
> actual mixer value change.  This is the biggest missing piece, and
> it's the very reason we have the exported symbol from the platform
> driver side.
> 
> So, if you prefer in that way, please implement that for the existing
> driver (thinkpad_acpi and dell-laptop) at first.  I'll be really happy
> to get rid of the present ugly solution!  But it's been there just
> because it's not so trivial at all.  FWIW, this must be all done
> inside the kernel; otherwise you'll hit a regression.

Ok, what about something like this?

Tested, and it did not work. I guess I hooked it up at the wrong place
in LED subsystem... or maybe thinkpad x60 is wrong machine to test on.

Anyway, it looks less ugly than current code in alsa. We should not
really be using mixer settings to turn LED on and off.

Plus, it works in similar way triggers and LEDs "usually" do, and has
all the flexibility.

Signed-off-by: Pavel Machek 

commit e7d6d170f2f45ea7a42c9ebb31869f440382e3ad

leds: ledtrig-sound: provide indication of muted microphone

Signed-off-by: Pavel Machek 

diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 9bcb64e..c5ea19e 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o
 obj-$(CONFIG_LEDS_TRIGGER_PANIC)   += ledtrig-panic.o
 obj-$(CONFIG_LEDS_TRIGGER_NETDEV)  += ledtrig-netdev.o
 obj-$(CONFIG_LEDS_TRIGGER_PATTERN) += ledtrig-pattern.o
+obj-y  += ledtrig-sound.o
diff --git a/drivers/leds/trigger/ledtrig-sound.c 
b/drivers/leds/trigger/ledtrig-sound.c
new file mode 100644
index 000..608df35
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-sound.c
@@ -0,0 +1,23 @@
+/* GPLv2+.
+ * Copyright 2018 Pavel Machek 
+ */
+
+#include 
+#include 
+#include 
+
+DEFINE_LED_TRIGGER(ledtrig_micmute);
+
+void ledtrig_mic_muted(bool muted)
+{
+   led_trigger_event(ledtrig_micmute, muted ? LED_FULL : LED_OFF);
+}
+EXPORT_SYMBOL(ledtrig_mic_muted);
+
+static int __init ledtrig_micmute_init(void)
+{
+   led_trigger_register_simple("mic-muted", &ledtrig_micmute);
+
+   return 0;
+}
+device_initcall(ledtrig_micmute_init);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index e4a9a00..c30e1cb 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -494,6 +494,14 @@ static inline void ledtrig_cpu(enum cpu_led_event evt)
 }
 #endif
 
+#ifdef CONFIG_LEDS_TRIGGERS
+extern void ledtrig_mic_muted(bool m);
+#else
+static inline void ledtrig_mic_muted(bool m) {}
+#endif
+
+
+
 #ifdef CONFIG_LEDS_BRIGHTNESS_HW_CHANGED
 extern void led_classdev_notify_brightness_hw_changed(
struct led_classdev *led_cdev, enum led_brightness brightness);
diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c
index 276150f..3ec1f61 100644
--- a/sound/pci/hda/hda_generic.c
+++ b/sound/pci/hda/hda_generic.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3929,6 +3930,7 @@ static void call_micmute_led_update(struct hda_codec 
*codec)
val = !spec->micmute_led.capture;
break;
}
+   ledtrig_mic_muted(!spec->micmute_led.capture);
 
if (val == spec->micmute_led.led_value)
return;
diff --git a/sound/pci/hda/thinkpad_helper.c b/sound/pci/hda/thinkpad_helper.c
index 568575b..f1b2265 100644
--- a/sound/pci/hda/thinkpad_helper.c
+++ b/sound/pci/hda/thinkpad_helper.c
@@ -23,6 +23,8 @@ static void update_tpacpi_mute_led(void *private_data, int 
enabled)
if (old_vmaster_hook)
old_vmaster_hook(private_data, enabled);
 
+   printk("mute led... %d\n", !enabled);
+
if (led_set_func)
led_set_func(TPACPI_LED_MUTE, !enabled);
 }


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v2 1/5] autofs - improve ioctl sbi checks

2018-11-23 Thread Andrew Morton
On Fri, 23 Nov 2018 18:41:50 +0800 Ian Kent  wrote:

> Al Viro made some suggestions to improve the implementation
> of commit 0633da48f0 "fix autofs_sbi() does not check super
> block type".
> 
> The check is unnessesary in all cases except for ioctl usage
> so placing the check in the super block accessor function
> adds a small overhead to the common case where it isn't
> needed.
> 
> So it's sufficient to do this in the ioctl code only.
> 
> Also the check in the ioctl code is needlessly complex.
>
> ...
>
> --- a/fs/autofs/dev-ioctl.c
> +++ b/fs/autofs/dev-ioctl.c
> @@ -14,6 +14,8 @@
>  
>  #include "autofs_i.h"
>  
> +extern struct file_system_type autofs_fs_type;
> +
>  /*
>   * This module implements an interface for routing autofs ioctl control
>   * commands via a miscellaneous device file.

It's naughty to declare externs in C files, for various reasons.  Is
this OK?

--- a/fs/autofs/autofs_i.h~autofs-improve-ioctl-sbi-checks-fix
+++ a/fs/autofs/autofs_i.h
@@ -42,6 +42,8 @@
 #endif
 #define pr_fmt(fmt) KBUILD_MODNAME ":pid:%d:%s: " fmt, current->pid, __func__
 
+extern struct file_system_type autofs_fs_type;
+
 /*
  * Unified info structure.  This is pointed to by both the dentry and
  * inode structures.  Each file in the filesystem has an instance of this
--- a/fs/autofs/dev-ioctl.c~autofs-improve-ioctl-sbi-checks-fix
+++ a/fs/autofs/dev-ioctl.c
@@ -14,8 +14,6 @@
 
 #include "autofs_i.h"
 
-extern struct file_system_type autofs_fs_type;
-
 /*
  * This module implements an interface for routing autofs ioctl control
  * commands via a miscellaneous device file.
_



Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1

2018-11-23 Thread Russell King - ARM Linux
On Fri, Nov 23, 2018 at 04:16:59PM +, Russell King - ARM Linux wrote:
> Hi Peter,
> 
> Here's the patch, which should now support IN as well as OUT.
> Completely untested, as mentioned before.

Now compile tested...

 drivers/usb/gadget/udc/omap_udc.c | 291 ++
 drivers/usb/gadget/udc/omap_udc.h |   3 +-
 2 files changed, 137 insertions(+), 157 deletions(-)

diff --git a/drivers/usb/gadget/udc/omap_udc.c 
b/drivers/usb/gadget/udc/omap_udc.c
index 3a16431da321..dd85476ec234 100644
--- a/drivers/usb/gadget/udc/omap_udc.c
+++ b/drivers/usb/gadget/udc/omap_udc.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -203,7 +204,7 @@ static int omap_ep_enable(struct usb_ep *_ep,
/* set endpoint to initial state */
ep->dma_channel = 0;
ep->has_dma = 0;
-   ep->lch = -1;
+   ep->dma = NULL;
use_ep(ep, UDC_EP_SEL);
omap_writew(udc->clr_halt, UDC_CTRL);
ep->ackwait = 0;
@@ -468,43 +469,6 @@ static int read_fifo(struct omap_ep *ep, struct omap_req 
*req)
 
 /*-*/
 
-static u16 dma_src_len(struct omap_ep *ep, dma_addr_t start)
-{
-   dma_addr_t  end;
-
-   /* IN-DMA needs this on fault/cancel paths, so 15xx misreports
-* the last transfer's bytecount by more than a FIFO's worth.
-*/
-   if (cpu_is_omap15xx())
-   return 0;
-
-   end = omap_get_dma_src_pos(ep->lch);
-   if (end == ep->dma_counter)
-   return 0;
-
-   end |= start & (0x << 16);
-   if (end < start)
-   end += 0x1;
-   return end - start;
-}
-
-static u16 dma_dest_len(struct omap_ep *ep, dma_addr_t start)
-{
-   dma_addr_t  end;
-
-   end = omap_get_dma_dst_pos(ep->lch);
-   if (end == ep->dma_counter)
-   return 0;
-
-   end |= start & (0x << 16);
-   if (cpu_is_omap15xx())
-   end++;
-   if (end < start)
-   end += 0x1;
-   return end - start;
-}
-
-
 /* Each USB transfer request using DMA maps to one or more DMA transfers.
  * When DMA completion isn't request completion, the UDC continues with
  * the next DMA transfer for that USB transfer.
@@ -512,34 +476,53 @@ static u16 dma_dest_len(struct omap_ep *ep, dma_addr_t 
start)
 
 static void next_in_dma(struct omap_ep *ep, struct omap_req *req)
 {
-   u16 txdma_ctrl, w;
-   unsignedlength = req->req.length - req->req.actual;
-   const int   sync_mode = cpu_is_omap15xx()
-   ? OMAP_DMA_SYNC_FRAME
-   : OMAP_DMA_SYNC_ELEMENT;
-   int dma_trigger = 0;
+   struct dma_async_tx_descriptor *tx;
+   struct dma_chan *dma = ep->dma;
+   dma_cookie_t cookie;
+   unsigned burst, length;
+   u16 txdma_ctrl, w;
+   struct dma_slave_config omap_udc_in_cfg = {
+   .direction = DMA_MEM_TO_DEV,
+   .dst_addr = UDC_DATA_DMA,
+   };
+
+   length = req->req.length - req->req.actual;
 
/* measure length in either bytes or packets */
-   if ((cpu_is_omap16xx() && length <= UDC_TXN_TSC)
-   || (cpu_is_omap15xx() && length < ep->maxpacket)) {
+   if ((cpu_is_omap16xx() && length <= UDC_TXN_TSC) ||
+   (cpu_is_omap15xx() && length < ep->maxpacket)) {
+   omap_udc_in_cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
txdma_ctrl = UDC_TXN_EOT | length;
-   omap_set_dma_transfer_params(ep->lch, OMAP_DMA_DATA_TYPE_S8,
-   length, 1, sync_mode, dma_trigger, 0);
+   burst = length;
} else {
-   length = min(length / ep->maxpacket,
-   (unsigned) UDC_TXN_TSC + 1);
+   omap_udc_in_cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+   length = min_t(unsigned, length / ep->maxpacket,
+  UDC_TXN_TSC + 1);
txdma_ctrl = length;
-   omap_set_dma_transfer_params(ep->lch, OMAP_DMA_DATA_TYPE_S16,
-   ep->ep.maxpacket >> 1, length, sync_mode,
-   dma_trigger, 0);
length *= ep->maxpacket;
+   burst = ep->ep.maxpacket >> 1;
}
-   omap_set_dma_src_params(ep->lch, OMAP_DMA_PORT_EMIFF,
-   OMAP_DMA_AMODE_POST_INC, req->req.dma + req->req.actual,
-   0, 0);
 
-   omap_start_dma(ep->lch);
-   ep->dma_counter = omap_get_dma_src_pos(ep->lch);
+   if (!cpu_is_omap15xx())
+   burst = 1;
+
+   omap_udc_in_cfg.dst_maxburst = burst;
+
+   if (WARN_ON(dmaengine_slave_config(dma, &omap_udc_in_cfg)))
+   return;
+
+   tx = dmaengine_prep_slave_single(dma, req->req.dma + req->req.actual,
+  

Re: [PATCH v2 1/2] power: supply: add input voltage limit property.

2018-11-23 Thread Pavel Machek
Hi!

> We have a problem with USBPD chargers which under certain conditions
> can result in system overheating if the voltage provided by the USBPD
> port is too high. While the preferred means to control this would be
> through devicetree or ACPI settings, this is not always possible, and
> we need to have a means to set a voltage limit.
> 
> This patch exposes a new property, similar to input current limit, to
> re-configure the maximum voltage from the external supply at runtime
> based on system-level knowledge or user input.

First, this should really be handled by dt / ACPI. If it is broken,
that's a hardware bug, and we can do DMI-based blacklists in kernel.

How are you supposed to fsck a system, for example?

> +What:
> /sys/class/power_supply//input_voltage_limit
> +Date:Nov 2018
> +Contact: linux...@vger.kernel.org
> +Description:
> + Details the incoming VBUS voltage limit currently set in the
> + supply. Normally this is configured based on the type of
> + connection made.

"Details"?

Who can write to this value and when? What is the limit? If USB
charger is plugged in, should it show 5.0V (because that's nominal on
the USB) or 5.25V (because that is the real limit)?

Who can write to this and when. And what happens on write? What
happens if I write value that charger can't provide there?

Does it set the voltage power supply should produce? Or maximal it can
choose to produce?

This really needs better documentation.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: Official Linux system wrapper library?

2018-11-23 Thread Dmitry V. Levin
On Fri, Nov 23, 2018 at 12:15:39PM -0800, Daniel Colascione wrote:
> On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer wrote:
> > > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
> > >>
> > >>> If the kernel provides a system call, libc should provide a C wrapper
> > >>> for it, even if in the opinion of the libc maintainers, that system
> > >>> call is flawed.
> > >>
> > >> It's not that simple, I think.  What about bdflush?  socketcall?
> > >> getxpid?  osf_gettimeofday?  set_robust_list?
> > >
> > > What about them? Mentioning that these system calls exist is not in
> > > itself an argument.
> >
> > But socketcall does not exist on all architectures.  Neither does
> > getpid, it's called getxpid on some architectures.
> 
> So what? On systems on which a given system call does not exist,
> attempts to link against that system call should fail, or attempts to
> make that system call should fail at runtime with ENOSYS. That's
> completely expected and unsurprising behavior, not some unavoidable
> source of catastrophic confusion.

I'm sorry but you've just said that getpid() must either be unavailable or
fail on those architectures that provide no syscall with exactly the same
semantics as getpid syscall.  Nobody is going to use a libc that doesn't
provide getpid() in a reliable way.

If you really need a 1-1 correspondence between syscalls and C wrappers,
there is syscall(3) with all associated portability issues.

If you need something else, please be more specific, i.e. be ready to give
a detailed answer about every syscall ever supported by the kernel,
on every supported architecture.

My first trivial question is, do you need C wrappers for
__NR_epoll_create, __NR_eventfd, __NR_inotify_init,
and __NR_signalfd syscalls?


-- 
ldv


signature.asc
Description: PGP signature


Please i need your help

2018-11-23 Thread Aisha Gaddafi



--
Hello Dear ,
I came across your contact during my private search
Mrs Aisha Al-Qaddafi is my name, the only daughter of late Libyan
president, I have funds the sum
of $27.5 million USD for investment, I am interested in you for
investment project assistance in your country,
i shall compensate you 30% of the total sum after the funds are
transfer into your account,
Reply me urgent for more details
Mrs Aisha Al-Qaddafi
--



Re: [PATCH] locking/atomics: build atomic headers as required

2018-11-23 Thread Andrew Morton
On Fri, 23 Nov 2018 15:33:21 + Mark Rutland  wrote:

> Andrew and Ingo report that the check-atomics.sh script is simply too
> slow to run for every kernel build, and it's impractical to make it
> faster without rewriting it in something other than shell.
> 
> Rather than committing the generated headers, let's regenerate these
> as-required for a pristine tree.
> 
> That ensures they're always up-to-date, allows them to be built in
> parallel, and avoid redundant rebuilds, which is a 2-8s saving per
> incremental build. Since the results are not committed, it's very
> obvious that they should not be modified directly. If we need to
> generate more headers in future, it's easy to extend Makefile.genheader
> to permit this.
> 
> I've verified that this works in the cases we previously had issues with
> (out-of-tree builds and where scripts have no execute permissions), and
> have tested these cases for both x86_64 and arm64.

Seems like a reasonable compromise.  I'll take a copy for testing now,
shall drop that when this appears in tip->linux-next.



[PATCH] drivers/base/memory.c: remove an unnecessary check on NR_MEM_SECTIONS

2018-11-23 Thread Wei Yang
In commit cb5e39b8038b ("drivers: base: refactor add_memory_section() to
add_memory_block()"), add_memory_block() is introduced, which is only
invoked in memory_dev_init().

When combine these two loops in memory_dev_init() and
add_memory_block(), they looks like this:

for (i = 0; i < NR_MEM_SECTIONS; i += sections_per_block)
for (j = i;
(j < i + sections_per_block) && j < NR_MEM_SECTIONS;
j++)

Since it is sure (i < NR_MEM_SECTIONS) and j sits in its own memory
block, the check of (j < NR_MEM_SECTIONS) is not necessary.

This patch just removes this check.

Signed-off-by: Wei Yang 
---
 drivers/base/memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 0e5985682642..547997a2249b 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -688,7 +688,7 @@ static int add_memory_block(int base_section_nr)
int i, ret, section_count = 0, section_nr;
 
for (i = base_section_nr;
-(i < base_section_nr + sections_per_block) && i < NR_MEM_SECTIONS;
+i < base_section_nr + sections_per_block;
 i++) {
if (!present_section_nr(i))
continue;
-- 
2.15.1



Re: [RFC][PATCH 06/14] fgraph: Move function graph specific code into fgraph.c

2018-11-23 Thread Joel Fernandes
On Fri, Nov 23, 2018 at 01:11:38PM -0500, Steven Rostedt wrote:
> On Fri, 23 Nov 2018 12:58:34 -0500
> Steven Rostedt  wrote:
> 
> > I think the better answer is to move it into trace_functions_graph.c.
> 
> I take that back. I think the better answer is to not call that
> function if the profiler is not set, nor have that option even
> available. Because it has no meaning without the profiler.

Agreed, that's better. Thanks,

 - Joel


Re: [PATCH v3 3/3] ALSA: hda: add support for Huawei WMI micmute LED

2018-11-23 Thread Pavel Machek
HI!

> > > > > > > You have general-purpose LED, yet you are treating it as 
> > > > > > > "something
> > > > > > > special". That means ugly code (quoted above) and lack of 
> > > > > > > flexibility.
> > > > > > >
> > > > > > > For example, if my notebook lacks HDD LED, I can use scrollock 
> > > > > > > LED for
> > > > > > > that instead. Or, in reverse way, maybe "mic mute" LED is not 
> > > > > > > useful
> > > > > > > for me, and I'd like to use it for notifications instead.
> > > > > >
> > > > > > I'm not against adding the LEDs device implementation for any exotic
> > > > > > usage.
> > > > > >
> > > > > > But for the audio mute LED features, you'll need really lots of 
> > > > > > other
> > > > > > works if it were implemented via leds device.  That's the hardest
> > > > > > part, and a few lines of hooks solves it easily in the kernel side.
> > > > > > That's all about it.
> > > > > >
> > > > > > If you are ready for submitting the real solutions in user-space 
> > > > > > side
> > > > > > (patching PulseAudio and whatever all existing sound daemons, and
> > > > > > creating yet another daemon for non-PA systems (another footprint,
> > > > > > lovely), and so on), we can happily delete such in-kernel hooks :)
> > > > >
> > > > > I'm not saying we should move it to the userspace.
> > > > >
> > > > > I'm saying this should be "normal" led. 
> > > > > drivers/leds/led-huawei-acpi.c,
> > > > > or something. Perhaps this acpi stuff is so similar you don't really
> > > > > need .c code.
> > > > >
> > > > > And then there should be a "mic muted" trigger. Similar to
> > > > > drivers/leds/trigger/ledtrig-disk.c.
> > > >
> > > > And who will trigger this, e.g. when the mixer is muted?
> > > 
> > > Is this settled? I'm encouraged to promote this series to our for-next 
> > > branch.
> > 
> > I'd prefer this to be normal LED and "mic muted" to become normal
> > trigger.
> 
> But how would you solve the existing problem?
> 
> As already mentioned, you'll need to hook the LED trigger and the
> actual mixer value change.  This is the biggest missing piece, and
> it's the very reason we have the exported symbol from the platform
> driver side.
> 
> So, if you prefer in that way, please implement that for the existing
> driver (thinkpad_acpi and dell-laptop) at first.  I'll be really happy
> to get rid of the present ugly solution!  But it's been there just
> because it's not so trivial at all.  FWIW, this must be all done
> inside the kernel; otherwise you'll hit a regression.

I am really have enough work to do at the moment, but let me take a look.

> If the path via leds class can't be achieved quickly, I'd prefer
> taking the current approach at first.  Once after it's done for those
> above, we can apply the same for huawei-wmi later, too.

I'd prefer not adding more mess. Don't expect full solution from me,
but ... I should have something better than what is in the tree rather
soon.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH] debugobjects: call debug_objects_mem_init eariler

2018-11-23 Thread Thomas Gleixner
On Thu, 22 Nov 2018, Waiman Long wrote:
> On 11/22/2018 11:31 PM, Qian Cai wrote:
> > The current value of the early boot static pool size, 1024 is not big
> > enough for systems with large number of CPUs with timer or/and workqueue
> > objects selected. As the results, systems have 60+ CPUs with both timer
> > and workqueue objects enabled could trigger "ODEBUG: Out of memory.
> > ODEBUG disabled".
> >
> > However, none of the things are actually used or required beofre

before

> > debug_objects_mem_init() is invoked.
> >
> > According to tglx,
> > "the reason why the call is at this place in start_kernel() is
> > historical. It's because back in the days when debugobjects were added
> > the memory allocator was enabled way later than today. So we can just
> > move the debug_objects_mem_init() call right before sched_init()."
> >
> > Afterwards, when calling debug_objects_mem_init(), interrupts have
> > already been disabled and lockdep_init() will only be called later, so
> > no need to worry about interrupts in
> > debug_objects_replace_static_objects().

Just out of curiosity. How many objects are allocated between early and mem
init?

> > diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> > index 70935ed91125..cc5818ced652 100644
> > --- a/lib/debugobjects.c
> > +++ b/lib/debugobjects.c
> > @@ -1132,13 +1132,6 @@ static int __init 
> > debug_objects_replace_static_objects(void)
> > hlist_add_head(&obj->node, &objects);
> > }
> >  
> > -   /*
> > -* When debug_objects_mem_init() is called we know that only
> > -* one CPU is up, so disabling interrupts is enough
> > -* protection. This avoids the lockdep hell of lock ordering.
> > -*/
> > -   local_irq_disable();
> 
> I think you should have a comment saying that debug_objects_mm_init() is
> called early with only one CPU up and interrupt disabled. So it is safe
> to replace static objects without any protection.

Yes please.
 
Thanks,

tglx


unclaimed/abandoned fund

2018-11-23 Thread James Brown

From Desk of James Brown
Accountant officer  Wema bank Of Nigeria

Hello My Dear ,

My name is James Brown I have decided to seek a confidential 
co-operation with you in the execution of the deal described here-under 
for our both mutual benefit and I hope you will keep it a top secret 
because of the nature of the transaction, During the course of our bank 
year auditing.


I discovered an unclaimed/abandoned fund, sum total of  { $18 Million } 
in the bank account that belongs to a Mexican businessman (Late Mr. Hock 
Miller) Who unfortunately lost his life and entire family in a plane 
crash.


Now our bank has been waiting for any of  the relatives to come-up for 
the claim but nobody has done that.


I personally has been unsuccessful in locating any of the relatives for 
several years now, I sincerely seek your consent to present you as the 
next of kin / Will Beneficiary to the deceased so that the proceeds of 
this account valued at ( $18 Million } can be paid to you, which we will 
share in these percentages ratio, 65% to me and 35% to you.


All I request is your utmost sincere co-operation; trust and maximum 
confidentiality to achieve this project successfully.


I have carefully mapped out the moralities for execution of this 
transaction under a legitimate arrangement to protect you from any 
breach of the law both in your country and here in Nigeria when the fund 
is being transferred to your bank account.


I will have to provide all the relevant document that will be requested 
from Wema bank to indicate that you are the rightful beneficiary of this 
legacy and Wema bank will release the fund to you without any further 
delay, upon your consideration and acceptance of this offer, please send 
me the following information as stated below so we can proceed and get 
this fund transferred to your designated bank account immediately.


Your Full Name:
Your Contact Address:
Your direct Mobile telephone Number:
Your Date of Birth:
Your occupation:

I await your swift response and re-assurance so we commence this 
transaction immediately email me here jamesbrowngoodn...@gmail.com


Best regards,
James Brown


Re: [PATCH 0/7] ACPI HMAT memory sysfs representation

2018-11-23 Thread Dan Williams
On Fri, Nov 23, 2018 at 11:21 AM Dave Hansen  wrote:
>
> On 11/22/18 10:42 PM, Anshuman Khandual wrote:
> > Are we willing to go in the direction for inclusion of a new system
> > call, subset of it appears on sysfs etc ? My primary concern is not
> > how the attribute information appears on the sysfs but lack of it's
> > completeness.
>
> A new system call makes total sense to me.  I have the same concern
> about the completeness of what's exposed in sysfs, I just don't see a
> _route_ to completeness with sysfs itself.  Thus, the minimalist
> approach as a first step.

Outside of platform-firmware-id to Linux-numa-node-id what other
userspace API infrastructure does the kernel need to provide? It seems
userspace enumeration of memory attributes is fully enabled once the
firmware-to-Linux identification is established.


Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation

2018-11-23 Thread Mathieu Desnoyers
- On Nov 23, 2018, at 1:35 PM, Rich Felker dal...@libc.org wrote:

> On Fri, Nov 23, 2018 at 12:52:21PM -0500, Mathieu Desnoyers wrote:
>> - On Nov 23, 2018, at 12:30 PM, Rich Felker dal...@libc.org wrote:
>> 
>> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> >> - On Nov 23, 2018, at 9:28 AM, Rich Felker dal...@libc.org wrote:
>> >> [...]
>> >> > 
>> >> > Absolutely. As long as it's in libc, implicit destruction will happen.
>> >> > Actually I think the glibc code shound unconditionally unregister the
>> >> > rseq address at exit (after blocking signals, so no application code
>> >> > can run) in case a third-party rseq library was linked and failed to
>> >> > do so before thread exit (e.g. due to mismatched ref counts) rather
>> >> > than respecting the reference count, since it knows it's the last
>> >> > user. This would make potentially-buggy code safer.
>> >> 
>> >> OK, let me go ahead with a few ideas/questions along that path.
>> > ^^^
>> >> 
>> >> Let's say our stated goal is to let the "exit" system call from the
>> >> glibc thread exit path perform rseq unregistration (without explicit
>> >> unregistration beforehand). Let's look at what we need.
>> > 
>> > This is not "along that path". The above-quoted text is not about
>> > assuming it's safe to make SYS_exit without unregistering the rseq
>> > object, but rather about glibc being able to perform the
>> > rseq-unregister syscall without caring about reference counts, since
>> > it knows no other code that might depend on rseq can run after it.
>> 
>> When saying "along that path", what I mean is: if we go in that direction,
>> then we should look into going all the way there, and rely on thread
>> exit to implicitly unregister the TLS area.
>> 
>> Do you see any reason for doing an explicit unregistration at thread
>> exit rather than simply rely on the exit system call ?
> 
> Whether this is needed is an implementation detail of glibc that
> should be permitted to vary between versions. Unless glibc wants to
> promise that it would become a public guarantee, it's not part of the
> discussion around the API/ABI. Only part of the discussion around
> implementation internals of the glibc rseq stuff.
> 
> Of course I may be biased thinking application code should not assume
> this since it's not true on musl -- for detached threads, the thread
> frees its own stack before exiting (and thus has to unregister
> set_tid_address and set_robustlist before exiting).

OK, so on glibc, the implementation could rely on exit side-effect to
implicitly unregister rseq. On musl, based on the scenario you describe,
the library should unregister rseq explicitly before stack reclaim.

Am I understanding the situation correctly ?

> 
>> >> First, we need the TLS area to be valid until the exit system call
>> >> is invoked by the thread. If glibc defines __rseq_abi as a weak symbol,
>> >> I'm not entirely sure we can guarantee the IE model if another library
>> >> gets its own global-dynamic weak symbol elected at execution time. Would
>> >> it be better to switch to a "strong" symbol for the glibc __rseq_abi
>> >> rather than weak ?
>> > 
>> > This doesn't help; still whichever comes first in link order would
>> > override. Either way __rseq_abi would be in static TLS, though,
>> > because any dynamically-loaded library is necessarily loaded after
>> > libc, which is loaded at initial exec time.
>> 
>> OK, AFAIU so you argue for leaving the __rseq_abi symbol "weak". Just making
>> sure I correctly understand your position.
> 
> I don't think it matters, and I don't think making it weak is
> meaningful or useful (weak in a shared library is largely meaningless)
> but maybe I'm missing something here.

Using a "weak" symbol in early adopter libraries is important, so they
can be loaded together into the same process without causing loader
errors due to many definitions of the same strong symbol.

Using "weak" in a C library is something I'm not sure is a characteristic
we want or need, because I doubt we would ever want to load two libc at the
same time in a given process.

The only reason I see for using "weak" for the __rseq_abi symbol in the
libc is if we want to allow early adopter applications to define
__rseq_abi as a strong symbol, which would make some sense.


> 
>> Something can be technically correct based on the current implementation,
>> but fragile with respect to future changes. We need to carefully distinguish
>> between the two when exposing ABIs.
> 
> Yes.
> 
>> >> There has been presumptions about signals being blocked when the thread
>> >> exits throughout this email thread. Out of curiosity, what code is
>> >> responsible for disabling signals in this situation ?
>> 
>> This question is still open.
> 
> I can't find it -- maybe it's not done in glibc. It is in musl, and I
> assumed glibc would also do it, because otherwise it's possible to see
> som

Re: [PATCH] x86/TSC: Use RDTSCP

2018-11-23 Thread Borislav Petkov
On Fri, Nov 23, 2018 at 01:03:25PM -0800, Guenter Roeck wrote:
> It is a cut off screen log. x86 boots change xterm configuration from
> wrap to non-wrap, and I did a cut-and-paste instead of copying the log
> to a file. Sorry for that.

No worries.

It was a head-scratcher though because look what it decodes to with the
'b':

[ 0.854209] Code: 90 90 90 90 90 90 90 a1 84 37 11 cd c3 8d b4 26 00 00 00 00 
8d 76 00 c3 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 90 55 89 e5 <0f> ae f0b 
0f 31 5d c3 8d b6 00 00 00 00 55 89 e5 57 31 ff 56 53 89
All code

   0:   90  nop
   1:   90  nop
   2:   90  nop
   3:   90  nop
   4:   90  nop
   5:   90  nop
   6:   90  nop
   7:   a1 84 37 11 cd  mov0xcd113784,%eax
   c:   c3  ret
   d:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
  14:   8d 76 00lea0x0(%esi),%esi
  17:   c3  ret
  18:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
  1f:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
  26:   90  nop
  27:   55  push   %ebp
  28:   89 e5   mov%esp,%ebp
  2a:*  0f ae 0bfxrstor (%ebx)  <-- trapping instruction
  2d:   0f 31   rdtsc
  2f:   5d  pop%ebp
  30:   c3  ret

FXRSTOR?!?!?

:-)

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


Re: [PATCH] x86/TSC: Use RDTSCP

2018-11-23 Thread Guenter Roeck

On 11/23/18 12:44 PM, Borislav Petkov wrote:

On Fri, Nov 23, 2018 at 12:03:07PM -0800, Guenter Roeck wrote:

[0.762832] EIP: read_tsc+0x4/0x10
[0.762832] Code: 00 01 00 eb 89 90 55 89 e5 5d c3 90 90 90 90 90 90 90 90 90 90 
90 55 a1 44 5a 8b c5 89 e5 5d c3 8d b6 00 00 00 00 55 89 e5 57 <0f> ae f0b


Where does that 'b' in f0b come from?



Good catch.

It is a cut off screen log. x86 boots change xterm configuration from
wrap to non-wrap, and I did a cut-and-paste instead of copying the log
to a file. Sorry for that.

Guenter


But ok, I was able to reproduce and decode myself. So if the Code:
section is correct, qemu chokes on MFENCE.

[ 0.854209] Code: 90 90 90 90 90 90 90 a1 84 37 11 cd c3 8d b4 26 00 00 00 00 8d 76 
00 c3 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 90 55 89 e5 <0f> ae f0 0f 31 5d 
c3 8d b6 00 00 00 00 55 89 e5 57 31 ff 56 53 89
All code

0:   90  nop
1:   90  nop
2:   90  nop
3:   90  nop
4:   90  nop
5:   90  nop
6:   90  nop
7:   a1 84 37 11 cd  mov0xcd113784,%eax
c:   c3  ret
d:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
   14:   8d 76 00lea0x0(%esi),%esi
   17:   c3  ret
   18:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
   1f:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
   26:   90  nop
   27:   55  push   %ebp
   28:   89 e5   mov%esp,%ebp
   2a:*  0f ae f0mfence  <-- trapping instruction
   2d:   0f 31   rdtsc
   2f:   5d  pop%ebp
   30:   c3  ret
   31:   8d b6 00 00 00 00   lea0x0(%esi),%esi
   37:   55  push   %ebp
   38:   89 e5   mov%esp,%ebp
   3a:   57  push   %edi
   3b:   31 ff   xor%edi,%edi
   3d:   56  push   %esi
   3e:   53  push   %ebx
   3f:   89  .byte 0x89

Doing this:

 asm volatile(ALTERNATIVE_2("mfence", ...

fails too which confirms that P3 can't do MFENCE.

I need to think about how to handle that old cruft.

Thx for the report.





Re: [PATCH rdma-next 3/3] RDMA/hns: Modify hns RoCE device's name

2018-11-23 Thread Jason Gunthorpe
On Fri, Nov 23, 2018 at 11:14:25PM +0800, Wei Hu (Xavier) wrote:
> This patch modifies the name of hns RoCE device's name in order
> to ensure that the name is consistent before and after reset.
> 
> Signed-off-by: Wei Hu (Xavier) 
>  drivers/infiniband/hw/hns/hns_roce_device.h | 1 +
>  drivers/infiniband/hw/hns/hns_roce_hw_v2.c  | 3 +++
>  drivers/infiniband/hw/hns/hns_roce_main.c   | 4 +++-
>  3 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h 
> b/drivers/infiniband/hw/hns/hns_roce_device.h
> index 259977b..a8cfe76 100644
> +++ b/drivers/infiniband/hw/hns/hns_roce_device.h
> @@ -954,6 +954,7 @@ struct hns_roce_dev {
>   struct pci_dev  *pci_dev;
>   struct device   *dev;
>   struct hns_roce_uar priv_uar;
> + charname[IB_DEVICE_NAME_MAX];
>   const char  *irq_names[HNS_ROCE_MAX_IRQ_NUM];
>   spinlock_t  sm_lock;
>   spinlock_t  bt_cmd_lock;
> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c 
> b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> index 1d639a0..678c7ec 100644
> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> @@ -6110,6 +6110,9 @@ static int hns_roce_hw_v2_get_cfg(struct hns_roce_dev 
> *hr_dev,
>   hr_dev->irq[i] = pci_irq_vector(handle->pdev,
>   i + handle->rinfo.base_vector);
>  
> + snprintf(hr_dev->name, IB_DEVICE_NAME_MAX, "hns%s",
> +  handle->rinfo.netdev->name);

Why is this making up its own driver name? How is this avoiding
colliding with an existing name?

This is very dangerous since we now have device renaming, the driver
could fail to load with no recovery.

Jason


Re: [PATCH] x86/TSC: Use RDTSCP

2018-11-23 Thread Borislav Petkov
On Fri, Nov 23, 2018 at 12:03:07PM -0800, Guenter Roeck wrote:
> [0.762832] EIP: read_tsc+0x4/0x10
> [0.762832] Code: 00 01 00 eb 89 90 55 89 e5 5d c3 90 90 90 90 90 90 90 90 
> 90 90 90 55 a1 44 5a 8b c5 89 e5 5d c3 8d b6 00 00 00 00 55 89 e5 57 <0f> ae 
> f0b

Where does that 'b' in f0b come from?

But ok, I was able to reproduce and decode myself. So if the Code:
section is correct, qemu chokes on MFENCE.

[ 0.854209] Code: 90 90 90 90 90 90 90 a1 84 37 11 cd c3 8d b4 26 00 00 00 00 
8d 76 00 c3 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 90 55 89 e5 <0f> ae f0 0f 
31 5d c3 8d b6 00 00 00 00 55 89 e5 57 31 ff 56 53 89
All code

   0:   90  nop
   1:   90  nop
   2:   90  nop
   3:   90  nop
   4:   90  nop
   5:   90  nop
   6:   90  nop
   7:   a1 84 37 11 cd  mov0xcd113784,%eax
   c:   c3  ret
   d:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
  14:   8d 76 00lea0x0(%esi),%esi
  17:   c3  ret
  18:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
  1f:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
  26:   90  nop
  27:   55  push   %ebp
  28:   89 e5   mov%esp,%ebp
  2a:*  0f ae f0mfence  <-- trapping instruction
  2d:   0f 31   rdtsc  
  2f:   5d  pop%ebp
  30:   c3  ret
  31:   8d b6 00 00 00 00   lea0x0(%esi),%esi
  37:   55  push   %ebp
  38:   89 e5   mov%esp,%ebp
  3a:   57  push   %edi
  3b:   31 ff   xor%edi,%edi
  3d:   56  push   %esi
  3e:   53  push   %ebx
  3f:   89  .byte 0x89

Doing this:

asm volatile(ALTERNATIVE_2("mfence", ...

fails too which confirms that P3 can't do MFENCE.

I need to think about how to handle that old cruft.

Thx for the report.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


Re: [PATCH] x86/TSC: Use RDTSCP

2018-11-23 Thread Thomas Gleixner
On Fri, 23 Nov 2018, h...@zytor.com wrote:
> On November 23, 2018 12:03:07 PM PST, Guenter Roeck  
> wrote:
> ># first bad commit: [2e94061096c5c3aa6c3fe3ec2bec176c1f9c1b07] x86/TSC:
> >Use RDTSCP
> 
> Right, because that cpu predates RDTSCP, so it needs to use a fallback.

Well, that's not the problem.

The default here is MFENCE; RDTSC; But P3 does not have MFENCE either :)

We need alternative_3 with default RDTSC

Thanks,

tglx



Re: [PATCH rdma-next 0/3] RDMA/hns: Updates for reset process of roce device in hip08

2018-11-23 Thread Jason Gunthorpe
On Fri, Nov 23, 2018 at 11:14:22PM +0800, Wei Hu (Xavier) wrote:
> Hi, Doug and Janson
> 
> This series mainly include updates for reset process of roce device
> in hip08.
> One patch adds support for reset and loading or unloading driver occur
> simultaneously to ensure work normally, one stops sending mailbox&cmq&
> doorbell when reset occured or reset is occuring, the last one modifies
> the name of hns RoCE device's name in order to ensure that the name is
> consistent before and after reset.
> 
> This series relies on the the new interfaces in hns NIC driver those
> had been accepted by David, the related commit as below:
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
> commit cb7ea80c6dfda472a068d40f4f9755d034b2dfde

Then you can't send patches to RDMA until the next cycle. Please
reasend after v4.21-rc1 is out.

We can only coordinate with Dave's tree if you are able to setup a
shared branch like Mellanox does.

Also, I don't even see cb7ea80c6dfda472a068d40f4f9755d034b2dfde in
that tree???

Jason


[PATCH 1/9] staging: rtl8188eu: cleanup remaining comparsions to true

2018-11-23 Thread Michael Straube
Cleanup remaining comparsions to true.
if (x == true) -> if (x)
if (x != true) -> if (!x)
if (!x == true) -> if (!x)

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_ap.c   |  4 +--
 drivers/staging/rtl8188eu/core/rtw_cmd.c  | 10 +++---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 26 +++---
 drivers/staging/rtl8188eu/core/rtw_recv.c | 16 -
 drivers/staging/rtl8188eu/core/rtw_sta_mgt.c  |  2 +-
 .../staging/rtl8188eu/core/rtw_wlan_util.c|  2 +-
 drivers/staging/rtl8188eu/core/rtw_xmit.c |  7 ++--
 drivers/staging/rtl8188eu/include/rtw_mlme.h  |  2 +-
 .../staging/rtl8188eu/os_dep/ioctl_linux.c| 36 +--
 9 files changed, 53 insertions(+), 52 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c 
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 1c319c2ca86d..1f232ba6651c 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -629,7 +629,7 @@ static void start_bss_network(struct adapter *padapter, u8 
*pbuf)
}
 
/* setting only at  first time */
-   if (pmlmepriv->cur_network.join_res != true) {
+   if (!pmlmepriv->cur_network.join_res) {
/* WEP Key will be set before this function, do not
 * clear CAM.
 */
@@ -756,7 +756,7 @@ int rtw_check_beacon_data(struct adapter *padapter, u8 
*pbuf,  int len)
 
DBG_88E("%s, len =%d\n", __func__, len);
 
-   if (check_fwstate(pmlmepriv, WIFI_AP_STATE) != true)
+   if (!check_fwstate(pmlmepriv, WIFI_AP_STATE))
return _FAIL;
 
if (len < 0 || len > MAX_IE_SZ)
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c 
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index f6dbcf6fe39b..e3e46f7ac834 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -240,7 +240,7 @@ u8 rtw_sitesurvey_cmd(struct adapter  *padapter, struct 
ndis_802_11_ssid *ssid,
struct cmd_priv *pcmdpriv = &padapter->cmdpriv;
struct mlme_priv*pmlmepriv = &padapter->mlmepriv;
 
-   if (check_fwstate(pmlmepriv, _FW_LINKED) == true)
+   if (check_fwstate(pmlmepriv, _FW_LINKED))
rtw_lps_ctrl_wk_cmd(padapter, LPS_CTRL_SCAN, 1);
 
ph2c = kzalloc(sizeof(*ph2c), GFP_ATOMIC);
@@ -820,7 +820,7 @@ static void dynamic_chk_wk_hdl(struct adapter *padapter, u8 
*pbuf, int sz)
pmlmepriv = &padapter->mlmepriv;
 
 #ifdef CONFIG_88EU_AP_MODE
-   if (check_fwstate(pmlmepriv, WIFI_AP_STATE) == true)
+   if (check_fwstate(pmlmepriv, WIFI_AP_STATE))
expire_timeout_chk(padapter);
 #endif
 
@@ -836,13 +836,13 @@ static void lps_ctrl_wk_hdl(struct adapter *padapter, u8 
lps_ctrl_type)
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
u8  mstatus;
 
-   if ((check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) == true) ||
-   (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true))
+   if (check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) ||
+   check_fwstate(pmlmepriv, WIFI_ADHOC_STATE))
return;
 
switch (lps_ctrl_type) {
case LPS_CTRL_SCAN:
-   if (check_fwstate(pmlmepriv, _FW_LINKED) == true) {
+   if (check_fwstate(pmlmepriv, _FW_LINKED)) {
/* connect */
LPS_Leave(padapter);
}
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index e5c8b02e6ab2..b6210d98ee2d 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -315,8 +315,8 @@ int is_same_network(struct wlan_bssid_ex *src, struct 
wlan_bssid_ex *dst)
d_cap = le16_to_cpu(le_dcap);
 
return ((src->Ssid.SsidLength == dst->Ssid.SsidLength) &&
-   ((!memcmp(src->MacAddress, dst->MacAddress, ETH_ALEN)) == true) 
&&
-   ((!memcmp(src->Ssid.Ssid, dst->Ssid.Ssid, 
src->Ssid.SsidLength)) == true) &&
+   (!memcmp(src->MacAddress, dst->MacAddress, ETH_ALEN)) &&
+   (!memcmp(src->Ssid.Ssid, dst->Ssid.Ssid, src->Ssid.SsidLength)) 
&&
((s_cap & WLAN_CAPABILITY_IBSS) ==
(d_cap & WLAN_CAPABILITY_IBSS)) &&
((s_cap & WLAN_CAPABILITY_ESS) ==
@@ -386,8 +386,8 @@ static void update_current_network(struct adapter *adapter, 
struct wlan_bssid_ex
 {
struct  mlme_priv   *pmlmepriv = &(adapter->mlmepriv);
 
-   if ((check_fwstate(pmlmepriv, _FW_LINKED) == true) &&
-   (is_same_network(&(pmlmepriv->cur_network.network), pnetwork))) {
+   if (check_fwstate(pmlmepriv, _FW_LINKED) &&
+   is_same_network(&pmlmepriv->cur_network.network, pnetwork)) {
update_network(&(pmlmepriv->cur_network.network), pnetwork, 
adapter, true);
rtw_update_protection(adapter, 
(pmlmepriv->cur_network.network.ies) + 

[PATCH 3/9] staging: rtl8188eu: use __func__ in rtw_mlme.c

2018-11-23 Thread Michael Straube
Use __func__ instead of hardcoded function names.
Reported by checkpatch.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 48 +--
 1 file changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index d5c22a028905..54f05e62da49 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -230,8 +230,9 @@ int rtw_if_up(struct adapter *padapter)
if (padapter->bDriverStopped || padapter->bSurpriseRemoved ||
!check_fwstate(&padapter->mlmepriv, _FW_LINKED)) {
RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_,
-("rtw_if_up:bDriverStopped(%d) OR 
bSurpriseRemoved(%d)",
-padapter->bDriverStopped, padapter->bSurpriseRemoved));
+("%s:bDriverStopped(%d) OR bSurpriseRemoved(%d)",
+ __func__, padapter->bDriverStopped,
+ padapter->bSurpriseRemoved));
res = false;
} else {
res =  true;
@@ -555,11 +556,13 @@ void rtw_survey_event_callback(struct adapter 
*adapter, u8 *pbuf)
 
pnetwork = (struct wlan_bssid_ex *)pbuf;
 
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, 
("rtw_survey_event_callback, ssid=%s\n",  pnetwork->Ssid.Ssid));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_,
+("%s, ssid=%s\n", __func__, pnetwork->Ssid.Ssid));
 
len = get_wlan_bssid_ex_sz(pnetwork);
if (len > (sizeof(struct wlan_bssid_ex))) {
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, 
("\nrtw_survey_event_callback: return a wrong bss ***\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_,
+("\n%s: return a wrong bss ***\n", __func__));
return;
}
spin_lock_bh(&pmlmepriv->lock);
@@ -606,7 +609,8 @@ void rtw_surveydone_event_callback(struct adapter   
*adapter, u8 *pbuf)
pmlmepriv->wps_probe_req_ie = NULL;
}
 
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, 
("rtw_surveydone_event_callback: fw_state:%x\n\n", get_fwstate(pmlmepriv)));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_,
+("%s: fw_state:%x\n\n", __func__, get_fwstate(pmlmepriv)));
 
if (check_fwstate(pmlmepriv, _FW_UNDER_SURVEY)) {
del_timer_sync(&pmlmepriv->scan_to_timer);
@@ -695,7 +699,7 @@ static void free_scanqueue(struct   mlme_priv *pmlmepriv)
struct __queue *scan_queue = &pmlmepriv->scanned_queue;
struct list_head *plist, *phead, *ptemp;
 
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_notice_, ("+free_scanqueue\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_notice_, ("+%s\n", __func__));
spin_lock_bh(&scan_queue->lock);
spin_lock_bh(&free_queue->lock);
 
@@ -808,7 +812,7 @@ void rtw_indicate_disconnect(struct adapter *padapter)
 {
struct  mlme_priv *pmlmepriv = &padapter->mlmepriv;
 
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, 
("+rtw_indicate_disconnect\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("+%s\n", __func__));
 
_clr_fwstate_(pmlmepriv, _FW_UNDER_LINKING | WIFI_UNDER_WPS);
 
@@ -1159,12 +1163,15 @@ void rtw_stassoc_event_callback(struct adapter 
*adapter, u8 *pbuf)
psta = rtw_get_stainfo(&adapter->stapriv, pstassoc->macaddr);
if (psta) {
/* the sta have been in sta_info_queue => do nothing */
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("Error: 
rtw_stassoc_event_callback: sta has been in sta_hash_queue\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_,
+("Error: %s: sta has been in sta_hash_queue\n",
+ __func__));
return; /* between drv has received this event before and  fw 
have not yet to set key to CAM_ENTRY) */
}
psta = rtw_alloc_stainfo(&adapter->stapriv, pstassoc->macaddr);
if (!psta) {
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("Can't alloc 
sta_info when rtw_stassoc_event_callback\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_,
+("Can't alloc sta_info when %s\n", __func__));
return;
}
/* to do: init sta_info variable */
@@ -1293,7 +1300,7 @@ void rtw_stadel_event_callback(struct adapter *adapter, 
u8 *pbuf)
 
 void rtw_cpwm_event_callback(struct adapter *padapter, u8 *pbuf)
 {
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("+rtw_cpwm_event_callback 
!!!\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("+%s !!!\n", __func__));
 }
 
 /*
@@ -1574,22 +1581,23 @@ int rtw_set_key(struct adapter *adapter, struct 
security_priv *psecuritypriv, in
if (psecuritypriv->dot11AuthAlgrthm == dot11AuthAlgrthm_8021X) {
psetkeyparm->

[PATCH 4/9] staging: rtl8188eu: remove rtw_android_set_block()

2018-11-23 Thread Michael Straube
The function rtw_android_set_block() just returns zero. The only user
is the function rtw_android_priv_cmd(). The variable bytes_written is
initialized to zero and not changed before the use of
rtw_android_set_block(). Remove rtw_android_set_block() and it's only
use.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/os_dep/rtw_android.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/rtw_android.c 
b/drivers/staging/rtl8188eu/os_dep/rtw_android.c
index 34080c0ce14a..2ea2af3286bc 100644
--- a/drivers/staging/rtl8188eu/os_dep/rtw_android.c
+++ b/drivers/staging/rtl8188eu/os_dep/rtw_android.c
@@ -127,12 +127,6 @@ static int android_get_p2p_addr(struct net_device *net, 
char *command,
return ETH_ALEN;
 }
 
-static int rtw_android_set_block(struct net_device *net, char *command,
-int total_len)
-{
-   return 0;
-}
-
 int rtw_android_priv_cmd(struct net_device *net, struct ifreq *ifr, int cmd)
 {
int ret = 0;
@@ -186,8 +180,6 @@ int rtw_android_priv_cmd(struct net_device *net, struct 
ifreq *ifr, int cmd)
priv_cmd.total_len);
break;
case ANDROID_WIFI_CMD_BLOCK:
-   bytes_written = rtw_android_set_block(net, command,
- priv_cmd.total_len);
break;
case ANDROID_WIFI_CMD_RXFILTER_START:
break;
-- 
2.19.2



[PATCH 8/9] staging: rtl8188eu: correct indentation

2018-11-23 Thread Michael Straube
Correct indentation to clear a checkpatch warning.
WARNING: suspect code indent for conditional statements (8, 24)

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 824e3c669a46..b048a3b633a9 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -1739,7 +1739,7 @@ int rtw_restruct_sec_ie(struct adapter *adapter, u8 
*in_ie, u8 *out_ie, uint in_
ielength = 12;
if ((ndisauthmode == Ndis802_11AuthModeWPA) ||
(ndisauthmode == Ndis802_11AuthModeWPAPSK))
-   authmode = _WPA_IE_ID_;
+   authmode = _WPA_IE_ID_;
if ((ndisauthmode == Ndis802_11AuthModeWPA2) ||
(ndisauthmode == Ndis802_11AuthModeWPA2PSK))
authmode = _WPA2_IE_ID_;
-- 
2.19.2



[PATCH 9/9] staging: rtl8188eu: cleanup lines over 80 characters

2018-11-23 Thread Michael Straube
Cleanup lines over 80 characters by replacing tabs with spaces
or adding appropriate line breaks.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index b048a3b633a9..714f7a70ed64 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -324,7 +324,7 @@ int is_same_network(struct wlan_bssid_ex *src, struct 
wlan_bssid_ex *dst)
(d_cap & WLAN_CAPABILITY_ESS)));
 }
 
-struct wlan_network*rtw_get_oldest_wlan_network(struct __queue 
*scanned_queue)
+struct wlan_network *rtw_get_oldest_wlan_network(struct __queue *scanned_queue)
 {
struct list_head *plist, *phead;
struct wlan_network *pwlan = NULL;
@@ -413,7 +413,7 @@ void rtw_update_scanned_network(struct adapter *adapter, 
struct wlan_bssid_ex *t
plist = phead->next;
 
while (phead != plist) {
-   pnetwork= container_of(plist, struct wlan_network, 
list);
+   pnetwork = container_of(plist, struct wlan_network, list);
 
if (is_same_network(&pnetwork->network, target))
break;
@@ -451,7 +451,8 @@ void rtw_update_scanned_network(struct adapter *adapter, 
struct wlan_bssid_ex *t
pnetwork = rtw_alloc_network(pmlmepriv); /*  will 
update scan_time */
 
if (!pnetwork) {
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, 
("\n\n\nsomething wrong here\n\n\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_,
+("\n\n\nsomething wrong here\n\n\n"));
goto exit;
}
 
@@ -469,9 +470,9 @@ void rtw_update_scanned_network(struct adapter *adapter, 
struct wlan_bssid_ex *t
list_add_tail(&pnetwork->list, &queue->queue);
}
} else {
-   /* we have an entry and we are going to update it. But this 
entry may
-* be already expired. In this case we do the same as we found 
a new
-* net and call the new_net handler
+   /* we have an entry and we are going to update it. But this
+* entry may be already expired. In this case we do the same
+* as we found a new net and call the new_net handler
 */
bool update_ie = true;
 
-- 
2.19.2



[PATCH 7/9] staging: rtl8188eu: remove return from void function

2018-11-23 Thread Michael Straube
Remove return from a void function to clear a checkpatch warning.
WARNING: void function return statements are not generally useful

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 513b6d89a0de..824e3c669a46 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -592,9 +592,7 @@ void rtw_survey_event_callback(struct adapter   
*adapter, u8 *pbuf)
}
 
 exit:
-
spin_unlock_bh(&pmlmepriv->lock);
-   return;
 }
 
 void rtw_surveydone_event_callback(struct adapter  *adapter, u8 *pbuf)
-- 
2.19.2



[PATCH 5/9] staging: rtl8188eu: cleanup declarations in rtw_mlme.c

2018-11-23 Thread Michael Straube
Replace tabs with spaces, remove spaces, remove blank lines
and break lines appropriatly in declarations.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 130 +++---
 1 file changed, 64 insertions(+), 66 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 54f05e62da49..9cc7d5b8293c 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -24,11 +24,11 @@ extern const u8 MCS_rate_1R[16];
 
 int rtw_init_mlme_priv(struct adapter *padapter)
 {
-   int i;
-   u8  *pbuf;
-   struct wlan_network *pnetwork;
-   struct mlme_priv*pmlmepriv = &padapter->mlmepriv;
-   int res = _SUCCESS;
+   int i;
+   u8 *pbuf;
+   struct wlan_network *pnetwork;
+   struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
+   int res = _SUCCESS;
 
/*  We don't need to memset padapter->XXX to zero, because adapter is 
allocated by vzalloc(). */
 
@@ -179,7 +179,7 @@ void _rtw_free_network_nolock(structmlme_priv 
*pmlmepriv, struct wlan_network *
 struct wlan_network *rtw_find_network(struct __queue *scanned_queue, u8 *addr)
 {
struct list_head *phead, *plist;
-   struct  wlan_network *pnetwork = NULL;
+   struct wlan_network *pnetwork = NULL;
u8 zero_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
 
if (!memcmp(zero_addr, addr, ETH_ALEN)) {
@@ -259,7 +259,7 @@ u8 *rtw_get_capability_from_ie(u8 *ie)
 
 u16 rtw_get_capability(struct wlan_bssid_ex *bss)
 {
-   __le16  val;
+   __le16 val;
 
memcpy((u8 *)&val, rtw_get_capability_from_ie(bss->ies), 2);
 
@@ -327,8 +327,8 @@ int is_same_network(struct wlan_bssid_ex *src, struct 
wlan_bssid_ex *dst)
 struct wlan_network*rtw_get_oldest_wlan_network(struct __queue 
*scanned_queue)
 {
struct list_head *plist, *phead;
-   struct  wlan_network*pwlan = NULL;
-   struct  wlan_network*oldest = NULL;
+   struct wlan_network *pwlan = NULL;
+   struct wlan_network *oldest = NULL;
 
phead = get_list_head(scanned_queue);
 
@@ -402,11 +402,11 @@ static void update_current_network(struct adapter 
*adapter, struct wlan_bssid_ex
 void rtw_update_scanned_network(struct adapter *adapter, struct wlan_bssid_ex 
*target)
 {
struct list_head *plist, *phead;
-   u32 bssid_ex_sz;
+   u32 bssid_ex_sz;
struct mlme_priv *pmlmepriv = &adapter->mlmepriv;
struct __queue *queue = &pmlmepriv->scanned_queue;
-   struct wlan_network *pnetwork = NULL;
-   struct wlan_network *oldest = NULL;
+   struct wlan_network *pnetwork = NULL;
+   struct wlan_network *oldest = NULL;
 
spin_lock_bh(&queue->lock);
phead = get_list_head(queue);
@@ -722,7 +722,7 @@ static void free_scanqueue(struct   mlme_priv *pmlmepriv)
  */
 void rtw_free_assoc_resources(struct adapter *adapter)
 {
-   struct  mlme_priv *pmlmepriv = &adapter->mlmepriv;
+   struct mlme_priv *pmlmepriv = &adapter->mlmepriv;
 
spin_lock_bh(&pmlmepriv->scanned_queue.lock);
rtw_free_assoc_resources_locked(adapter);
@@ -735,8 +735,8 @@ void rtw_free_assoc_resources(struct adapter *adapter)
 void rtw_free_assoc_resources_locked(struct adapter *adapter)
 {
struct wlan_network *pwlan = NULL;
-   struct  mlme_priv *pmlmepriv = &adapter->mlmepriv;
-   struct  sta_priv *pstapriv = &adapter->stapriv;
+   struct mlme_priv *pmlmepriv = &adapter->mlmepriv;
+   struct sta_priv *pstapriv = &adapter->stapriv;
struct wlan_network *tgt_network = &pmlmepriv->cur_network;
 
RT_TRACE(_module_rtl871x_mlme_c_, _drv_notice_, 
("+rtw_free_assoc_resources\n"));
@@ -784,7 +784,7 @@ void rtw_free_assoc_resources_locked(struct adapter 
*adapter)
  */
 void rtw_indicate_connect(struct adapter *padapter)
 {
-   struct mlme_priv*pmlmepriv = &padapter->mlmepriv;
+   struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
 
RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("+%s\n", __func__));
 
@@ -810,7 +810,7 @@ void rtw_indicate_connect(struct adapter *padapter)
  */
 void rtw_indicate_disconnect(struct adapter *padapter)
 {
-   struct  mlme_priv *pmlmepriv = &padapter->mlmepriv;
+   struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
 
RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("+%s\n", __func__));
 
@@ -965,12 +965,12 @@ static void rtw_joinbss_update_network(struct adapter 
*padapter, struct wlan_net
 void rtw_joinbss_event_prehandle(struct adapter *adapter, u8 *pbuf)
 {
struct sta_info *ptarget_sta = NULL, *pcur_sta = NULL;
-   struct  sta_priv *pstapriv = &adapter->stapriv;
+   struct sta_priv *pstapriv = &adapter->stapriv;
struct mlme_priv *pmlmepriv = &adapter->mlmepriv;
-   struct wlan_network *pnetwork   = (struct wlan_network *)pbuf;
+   struct wlan_network *pnet

[PATCH 6/9] staging: rtl8188eu: refactor if else statement

2018-11-23 Thread Michael Straube
Refactor if else statement to clear checkpatch warnings.
WARNING: else is not generally useful after a break or return
WARNING: line over 80 characters

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 9cc7d5b8293c..513b6d89a0de 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -1758,12 +1758,9 @@ int rtw_restruct_sec_ie(struct adapter *adapter, u8 
*in_ie, u8 *out_ie, uint in_
}
 
iEntry = SecIsInPMKIDList(adapter, pmlmepriv->assoc_bssid);
-   if (iEntry < 0) {
-   return ielength;
-   } else {
-   if (authmode == _WPA2_IE_ID_)
-   ielength = rtw_append_pmkid(adapter, iEntry, out_ie, 
ielength);
-   }
+   if (iEntry >= 0 && authmode == _WPA2_IE_ID_)
+   ielength = rtw_append_pmkid(adapter, iEntry, out_ie, ielength);
+
return ielength;
 }
 
-- 
2.19.2



[PATCH 2/9] staging: rtl8188eu: remove unnecessary parentheses in rtw_mlme.c

2018-11-23 Thread Michael Straube
Remove unnecessary parentheses reported by checkpatch.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 120 --
 1 file changed, 63 insertions(+), 57 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index b6210d98ee2d..d5c22a028905 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -39,9 +39,9 @@ int rtw_init_mlme_priv(struct adapter *padapter)
pmlmepriv->cur_network.network.InfrastructureMode = 
Ndis802_11AutoUnknown;
pmlmepriv->scan_mode = SCAN_ACTIVE;/*  1: active, 0: pasive. Maybe 
someday we should rename this varable to "active_mode" (Jeff) */
 
-   spin_lock_init(&(pmlmepriv->lock));
-   _rtw_init_queue(&(pmlmepriv->free_bss_pool));
-   _rtw_init_queue(&(pmlmepriv->scanned_queue));
+   spin_lock_init(&pmlmepriv->lock);
+   _rtw_init_queue(&pmlmepriv->free_bss_pool);
+   _rtw_init_queue(&pmlmepriv->scanned_queue);
 
memset(&pmlmepriv->assoc_ssid, 0, sizeof(struct ndis_802_11_ssid));
 
@@ -56,9 +56,9 @@ int rtw_init_mlme_priv(struct adapter *padapter)
pnetwork = (struct wlan_network *)pbuf;
 
for (i = 0; i < MAX_BSS_CNT; i++) {
-   INIT_LIST_HEAD(&(pnetwork->list));
+   INIT_LIST_HEAD(&pnetwork->list);
 
-   list_add_tail(&(pnetwork->list), 
&(pmlmepriv->free_bss_pool.queue));
+   list_add_tail(&pnetwork->list, &pmlmepriv->free_bss_pool.queue);
 
pnetwork++;
}
@@ -137,7 +137,7 @@ static void _rtw_free_network(struct mlme_priv *pmlmepriv, 
struct wlan_network *
unsigned long curr_time;
u32 delta_time;
u32 lifetime = SCANQUEUE_LIFETIME;
-   struct __queue *free_queue = &(pmlmepriv->free_bss_pool);
+   struct __queue *free_queue = &pmlmepriv->free_bss_pool;
 
if (!pnetwork)
return;
@@ -154,21 +154,21 @@ static void _rtw_free_network(struct mlme_priv 
*pmlmepriv, struct wlan_network *
return;
}
spin_lock_bh(&free_queue->lock);
-   list_del_init(&(pnetwork->list));
-   list_add_tail(&(pnetwork->list), &(free_queue->queue));
+   list_del_init(&pnetwork->list);
+   list_add_tail(&pnetwork->list, &free_queue->queue);
spin_unlock_bh(&free_queue->lock);
 }
 
 void _rtw_free_network_nolock(struct   mlme_priv *pmlmepriv, struct 
wlan_network *pnetwork)
 {
-   struct __queue *free_queue = &(pmlmepriv->free_bss_pool);
+   struct __queue *free_queue = &pmlmepriv->free_bss_pool;
 
if (!pnetwork)
return;
if (pnetwork->fixed)
return;
-   list_del_init(&(pnetwork->list));
-   list_add_tail(&(pnetwork->list), get_list_head(free_queue));
+   list_del_init(&pnetwork->list);
+   list_add_tail(&pnetwork->list, get_list_head(free_queue));
 }
 
 /*
@@ -354,7 +354,8 @@ void update_network(struct wlan_bssid_ex *dst, struct 
wlan_bssid_ex *src,
rtw_hal_antdiv_rssi_compared(padapter, dst, src); /* this will update 
src.Rssi, need consider again */
 
/* The rule below is 1/5 for sample value, 4/5 for history value */
-   if (check_fwstate(&padapter->mlmepriv, _FW_LINKED) && 
is_same_network(&(padapter->mlmepriv.cur_network.network), src)) {
+   if (check_fwstate(&padapter->mlmepriv, _FW_LINKED) &&
+   is_same_network(&padapter->mlmepriv.cur_network.network, src)) {
/* Take the recvpriv's value for the connected AP*/
ss_final = padapter->recvpriv.signal_strength;
sq_final = padapter->recvpriv.signal_qual;
@@ -384,11 +385,11 @@ void update_network(struct wlan_bssid_ex *dst, struct 
wlan_bssid_ex *src,
 
 static void update_current_network(struct adapter *adapter, struct 
wlan_bssid_ex *pnetwork)
 {
-   struct  mlme_priv   *pmlmepriv = &(adapter->mlmepriv);
+   struct mlme_priv *pmlmepriv = &adapter->mlmepriv;
 
if (check_fwstate(pmlmepriv, _FW_LINKED) &&
is_same_network(&pmlmepriv->cur_network.network, pnetwork)) {
-   update_network(&(pmlmepriv->cur_network.network), pnetwork, 
adapter, true);
+   update_network(&pmlmepriv->cur_network.network, pnetwork, 
adapter, true);
rtw_update_protection(adapter, 
(pmlmepriv->cur_network.network.ies) + sizeof(struct ndis_802_11_fixed_ie),
  pmlmepriv->cur_network.network.ie_length);
}
@@ -401,8 +402,8 @@ void rtw_update_scanned_network(struct adapter *adapter, 
struct wlan_bssid_ex *t
 {
struct list_head *plist, *phead;
u32 bssid_ex_sz;
-   struct mlme_priv*pmlmepriv = &(adapter->mlmepriv);
-   struct __queue *queue   = &(pmlmepriv->scanned_queue);
+   struct mlme_priv *pmlmepriv = &adapter->mlmepriv;
+   struct __queue *queue = &pmlmepriv->scanned_queue;
struc

Re: [PATCH] x86/TSC: Use RDTSCP

2018-11-23 Thread hpa
On November 23, 2018 12:03:07 PM PST, Guenter Roeck  wrote:
>Hi,
>
>On Mon, Nov 19, 2018 at 07:45:56PM +0100, Borislav Petkov wrote:
>> From: Borislav Petkov 
>> 
>> Currently, the kernel uses
>> 
>>   [LM]FENCE; RDTSC
>> 
>> in the timekeeping code, to guarantee monotonicity of time where the
>> *FENCE is selected based on vendor.
>> 
>> Replace that sequence with RDTSCP which is faster or on-par and gives
>> the same guarantees.
>> 
>> A microbenchmark on Intel shows that the change is on-par.
>> 
>> On AMD, the change is either on-par with the current LFENCE-prefixed
>> RDTSC and some are slightly better with RDTSCP.
>> 
>> The comparison is done with the LFENCE-prefixed RDTSC (and not with
>the
>> MFENCE-prefixed one, as one would normally expect) because all modern
>> AMD families make LFENCE serializing and thus avoid the heavy MFENCE
>by
>> effectively enabling X86_FEATURE_LFENCE_RDTSC.
>> 
>> Co-developed-by: Thomas Gleixner 
>> Signed-off-by: Thomas Gleixner 
>> Signed-off-by: Borislav Petkov 
>> Cc: Andy Lutomirski 
>> Cc: "H. Peter Anvin" 
>> Cc: John Stultz 
>> Cc: Thomas Lendacky 
>> Cc: x...@kernel.org
>> ---
>>  arch/x86/include/asm/msr.h | 15 +--
>>  1 file changed, 13 insertions(+), 2 deletions(-)
>> 
>> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
>> index 91e4cf189914..f00f2b61d326 100644
>> --- a/arch/x86/include/asm/msr.h
>> +++ b/arch/x86/include/asm/msr.h
>> @@ -217,6 +217,8 @@ static __always_inline unsigned long long
>rdtsc(void)
>>   */
>>  static __always_inline unsigned long long rdtsc_ordered(void)
>>  {
>> +DECLARE_ARGS(val, low, high);
>> +
>>  /*
>>   * The RDTSC instruction is not ordered relative to memory
>>   * access.  The Intel SDM and the AMD APM are both vague on this
>> @@ -227,9 +229,18 @@ static __always_inline unsigned long long
>rdtsc_ordered(void)
>>   * ordering guarantees as reading from a global memory location
>>   * that some other imaginary CPU is updating continuously with a
>>   * time stamp.
>> + *
>> + * Thus, use the preferred barrier on the respective CPU, aiming
>for
>> + * RDTSCP as the default.
>>   */
>> -barrier_nospec();
>> -return rdtsc();
>> +asm volatile(ALTERNATIVE_2("mfence; rdtsc",
>> +   "lfence; rdtsc", X86_FEATURE_LFENCE_RDTSC,
>> +   "rdtscp", X86_FEATURE_RDTSCP)
>> +: EAX_EDX_RET(val, low, high)
>> +/* RDTSCP clobbers ECX with MSR_TSC_AUX. */
>> +:: "ecx");
>> +
>> +return EAX_EDX_VAL(val, low, high);
>>  }
>>  
>
>This patch results in a crash with certain qemu emulations.
>
>[0.756869] hpet0: 3 comparators, 64-bit 100.00 MHz counter
>[0.762233] invalid opcode:  [#1] PTI
>[0.762435] CPU: 0 PID: 1 Comm: swapper Not tainted
>4.20.0-rc3-next-20181123 #2
>[0.762644] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
>Ubuntu-1.8.2-1ubuntu1 04/01/2014
>[0.762832] EIP: read_tsc+0x4/0x10
>
>To reproduce:
>
>make ARCH=i386 defconfig
>echo "CONFIG_HIGHMEM64G=y" >> .config
>make ARCH=i386 olddefconfig
>make -j30 ARCH=i386
>
>qemu-system-i386 \
>   -kernel arch/x86/boot/bzImage \
>   -M q35 -cpu pentium3 -no-reboot -m 256 \
>   -initrd rootfs.cpio \
>   --append 'earlycon=uart8250,io,0x3f8,9600n8 rdinit=/sbin/init panic=-1
>console=ttyS0 console=tty' \
>   -nographic -monitor none
>
>initrd or root file system doesn't really matter since the code never
>gets there, but it is available from here:
>   
> https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/rootfs.cpio.gz
>The qemu version does not matter either (I tried with 2.5 and 3.0).
>
>Reverting the patch fixes the problem.
>
>Guenter
>
>---
>crash log:
>
>...
>[0.756366] HPET: 3 timers in total, 0 timers will be used for
>per-cpu timer
>[0.756718] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0
>[0.756869] hpet0: 3 comparators, 64-bit 100.00 MHz counter
>[0.762233] invalid opcode:  [#1] PTI
>[0.762435] CPU: 0 PID: 1 Comm: swapper Not tainted
>4.20.0-rc3-next-20181123
>#2
>[0.762644] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
>Ubuntu-1.8.2-1ubuntu1 04/01/2014
>[0.762832] EIP: read_tsc+0x4/0x10
>[0.762832] Code: 00 

Re: [RFC PATCH 3/3] mm, fault_around: do not take a reference to a locked page

2018-11-23 Thread Hugh Dickins
On Thu, 22 Nov 2018, Michal Hocko wrote:
> 
> If you want some update to the comment in this function or to the
> changelog, I am open of course. Right now I have
> +* Check for a locked page first, as a speculative
> +* reference may adversely influence page migration.
> as suggested by William.

I ought to care, since I challenged the significance of this aspect
in the first place, but find I don't care enough - I much prefer the
patch to the comments on and in it, but have not devised any wording
that I'd prefer to see instead - sorry.

Hugh


Re: [RFC][PATCH] fs: set xattrs in initramfs from regular files

2018-11-23 Thread Rob Landley
On 11/22/18 9:49 AM, Roberto Sassu wrote:
> Although rootfs (tmpfs) supports xattrs, they are not set due to the
> limitation of the cpio format. A new format called 'newcx' was proposed to
> overcome this limitation.

I got email about that format the day before you posted this, by the way.

> However, it looks like that adding a new format is not simple: 15 kernel
> patches; user space tools must support the new format; mistakes made in the
> past should be avoided; it is unclear whether the kernel should switch from
> cpio to tar.

The kernel _can't_ switch from cpio to tar without breaking backwards
compatability, it could only add tar as a second format it supported (remember
cpio images can be sideloaded so a new rootfs can be used with an existing
initramfs, plus existing build systems generate them and would still need to if
they wanted to keep supporting older kernels), and then once you've got two
formats somebody will propose zip support, and let's just not go there please.

The changes to the userspace tools are trivial (I say that as the maintainer of
toybox, which has a cpio). The argument was about things like 64 bit timestamps
(y2038 problem), nanosecond support, sparse files, etc. And I think the argument
had largely died down?

Keep in mind the squashfs guy spent 5 years trying to get his filesystem merged
(https://lwn.net/Articles/563578/), I spent several years trying to get my perl
removal patch merged (and only work up the enthusiasm to resubmit
http://lists.busybox.net/pipermail/buildroot/2015-March/123385.html
https://patchwork.kernel.org/patch/9193529/ https://lkml.org/lkml/2017/9/13/651
about once a year because dealing with linux-kernel is just no fun for hobbyists
anymore).

> The aim of this patch is to provide the same functionality without
> introducing a new format. The value of xattrs is placed in regular files
> having the same file name as the files xattrs are added to, plus a
> separator and the xattr name (.xattr-).

I think you're solving the wrong problem, but that's just my opinion.

Rob


Re: Official Linux system wrapper library?

2018-11-23 Thread Daniel Colascione
On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer  wrote:
>
> * Daniel Colascione:
>
> > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer  wrote:
> >> * Daniel Colascione:
> >>
> >>> If the kernel provides a system call, libc should provide a C wrapper
> >>> for it, even if in the opinion of the libc maintainers, that system
> >>> call is flawed.
> >>
> >> It's not that simple, I think.  What about bdflush?  socketcall?
> >> getxpid?  osf_gettimeofday?  set_robust_list?
> >
> > What about them? Mentioning that these system calls exist is not in
> > itself an argument.
>
> But socketcall does not exist on all architectures.  Neither does
> getpid, it's called getxpid on some architectures.

So what? On systems on which a given system call does not exist,
attempts to link against that system call should fail, or attempts to
make that system call should fail at runtime with ENOSYS. That's
completely expected and unsurprising behavior, not some unavoidable
source of catastrophic confusion.

> >> There are quite a few irregularities
> >
> > So?
>
> I think it would be a poor approach to expose application developers to
> these portability issues.  We need to abstract over these differences at
> a certain layer, and applications are too late.

And glibc is too early. The purpose of the lowest-level user library
is not to provide an OS-agnostic portability layer. There are other
projects much better-suited to providing portability, including the
excellent GLib, Gnulib, and Qt. The purpose of the lowest-level user
library is to expose the interfaces of the underlying system, whatever
they are. That's a basic tenet of layered interface design.

Due to historical accident, the same library (on most Linux systems)
serves as both the lowest-level user library and an implementation of
some antiquated portability constructs from ANSI C and POSIX. That
this library provides these old portability interfaces is not a reason
for that library to neglect its responsibility as the lowest-level
system interface library. If people find that every attempt to expose
even trivial new kernel interfaces turns into an endless trek through
a swamp of specious objection (see the gettid debacle), then it
becomes perfectly reasonable to find an alternate route over firmer
ground.

Other glibc developers (e.g., Joseph Myers) have expressed support for
adding long-missing system call wrappers, like gettid, as long as the
functions are adequately documented. Would you make a sustained
objection to these additions?

> >> and some editorial discretion appears to be unavoidable.
> >
> > That's an assertion, not an argument, and I strongly disagree. *Why*
> > do you think "editorial discretion" is unavoidable?
>
> We do not want application authors to write code which uses socketcall,

That's an opinion on portability, not an argument for the necessity of
"editorial discretion". That you think an application calling
socketcall would somehow be a bad idea is not a justification for not
providing this interface. Low-level libraries must focus on mechanism,
not policy, if a system is to be flexible enough to accommodate
unanticipated needs.


Re: [PATCH v3] mm: use swp_offset as key in shmem_replace_page()

2018-11-23 Thread Hugh Dickins
On Wed, 21 Nov 2018, Andrew Morton wrote:
> On Wed, 21 Nov 2018 14:54:42 -0700 Yu Zhao  wrote:
> 
> > We changed key of swap cache tree from swp_entry_t.val to
> > swp_offset. Need to do so in shmem_replace_page() as well.
> 
> What are the user-visible effects of this change?

Sorry, I don't know; and I don't know whether it's something Yu noticed
by source inspection, or in trying to use it, perhaps in some new way:
I assume the former, but he can add more info if the latter.

shmem_replace_page() was added in 3.5, to allow Intel's GMA500 graphics
driver to use the shmem support for GEM objects, despite its hardware
addressing limitations.  (I did once try to extend it to NUMA placement,
but that turned out to be a waste, doing more harm than good.)

My guess at user-visible effects would be that the screen goes blank
or weird on GMA500 after a bout of swapping (because shmem_getpage_gfp()
failed to bring back a part of the object).  The code in shmem.c looks
robust (amusing to see my "Is this possible? I think not" comment!),
but I don't know how it plays out at the graphics driver end.

> 
> > Fixes: f6ab1f7f6b2d ("mm, swap: use offset of swap entry as key of swap 
> > cache")
> > Cc: sta...@vger.kernel.org # v4.9+
> 
> Please always provide the user-impact information when fixing bugs.  This
> becomes especially important when proposing -stable backporting.

So far as I know, nothing but GMA500 gets to use it, but perhaps other
uses have been added since.  We could ask around, but, frankly I'd prefer
just to remove the Fixes and Cc stable tags if they're causing trouble.
It's just a good simple bugfix, we thought stable would be glad of it.

> 
> Hugh said
> 
> : shmem_replace_page() has been wrong since the day I wrote it: good
> : enough to work on swap "type" 0, which is all most people ever use
> : (especially those few who need shmem_replace_page() at all), but broken
> : once there are any non-0 swp_type bits set in the higher order bits.

Yu then kindly restored my honour on that: I was misreading,
it was not broken from the start, but got broken by the commit in 4.9.

> 
> but we still don't have a description of "broken".
> 
> Thanks.

Hugh


Re: [PATCH] x86/TSC: Use RDTSCP

2018-11-23 Thread Guenter Roeck
Hi,

On Mon, Nov 19, 2018 at 07:45:56PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov 
> 
> Currently, the kernel uses
> 
>   [LM]FENCE; RDTSC
> 
> in the timekeeping code, to guarantee monotonicity of time where the
> *FENCE is selected based on vendor.
> 
> Replace that sequence with RDTSCP which is faster or on-par and gives
> the same guarantees.
> 
> A microbenchmark on Intel shows that the change is on-par.
> 
> On AMD, the change is either on-par with the current LFENCE-prefixed
> RDTSC and some are slightly better with RDTSCP.
> 
> The comparison is done with the LFENCE-prefixed RDTSC (and not with the
> MFENCE-prefixed one, as one would normally expect) because all modern
> AMD families make LFENCE serializing and thus avoid the heavy MFENCE by
> effectively enabling X86_FEATURE_LFENCE_RDTSC.
> 
> Co-developed-by: Thomas Gleixner 
> Signed-off-by: Thomas Gleixner 
> Signed-off-by: Borislav Petkov 
> Cc: Andy Lutomirski 
> Cc: "H. Peter Anvin" 
> Cc: John Stultz 
> Cc: Thomas Lendacky 
> Cc: x...@kernel.org
> ---
>  arch/x86/include/asm/msr.h | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
> index 91e4cf189914..f00f2b61d326 100644
> --- a/arch/x86/include/asm/msr.h
> +++ b/arch/x86/include/asm/msr.h
> @@ -217,6 +217,8 @@ static __always_inline unsigned long long rdtsc(void)
>   */
>  static __always_inline unsigned long long rdtsc_ordered(void)
>  {
> + DECLARE_ARGS(val, low, high);
> +
>   /*
>* The RDTSC instruction is not ordered relative to memory
>* access.  The Intel SDM and the AMD APM are both vague on this
> @@ -227,9 +229,18 @@ static __always_inline unsigned long long 
> rdtsc_ordered(void)
>* ordering guarantees as reading from a global memory location
>* that some other imaginary CPU is updating continuously with a
>* time stamp.
> +  *
> +  * Thus, use the preferred barrier on the respective CPU, aiming for
> +  * RDTSCP as the default.
>*/
> - barrier_nospec();
> - return rdtsc();
> + asm volatile(ALTERNATIVE_2("mfence; rdtsc",
> +"lfence; rdtsc", X86_FEATURE_LFENCE_RDTSC,
> +"rdtscp", X86_FEATURE_RDTSCP)
> + : EAX_EDX_RET(val, low, high)
> + /* RDTSCP clobbers ECX with MSR_TSC_AUX. */
> + :: "ecx");
> +
> + return EAX_EDX_VAL(val, low, high);
>  }
>  

This patch results in a crash with certain qemu emulations.

[0.756869] hpet0: 3 comparators, 64-bit 100.00 MHz counter
[0.762233] invalid opcode:  [#1] PTI
[0.762435] CPU: 0 PID: 1 Comm: swapper Not tainted 4.20.0-rc3-next-20181123 
#2
[0.762644] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[0.762832] EIP: read_tsc+0x4/0x10

To reproduce:

make ARCH=i386 defconfig
echo "CONFIG_HIGHMEM64G=y" >> .config
make ARCH=i386 olddefconfig
make -j30 ARCH=i386

qemu-system-i386 \
-kernel arch/x86/boot/bzImage \
-M q35 -cpu pentium3 -no-reboot -m 256 \
-initrd rootfs.cpio \
--append 'earlycon=uart8250,io,0x3f8,9600n8 rdinit=/sbin/init panic=-1 
console=ttyS0 console=tty' \
-nographic -monitor none

initrd or root file system doesn't really matter since the code never
gets there, but it is available from here:

https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/rootfs.cpio.gz
The qemu version does not matter either (I tried with 2.5 and 3.0).

Reverting the patch fixes the problem.

Guenter

---
crash log:

...
[0.756366] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[0.756718] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0
[0.756869] hpet0: 3 comparators, 64-bit 100.00 MHz counter
[0.762233] invalid opcode:  [#1] PTI
[0.762435] CPU: 0 PID: 1 Comm: swapper Not tainted 4.20.0-rc3-next-20181123
#2
[0.762644] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[0.762832] EIP: read_tsc+0x4/0x10
[0.762832] Code: 00 01 00 eb 89 90 55 89 e5 5d c3 90 90 90 90 90 90 90 90 
90 90 90 55 a1 44 5a 8b c5 89 e5 5d c3 8d b6 00 00 00 00 55 89 e5 57 <0f> ae f0b
[0.762832] EAX: c58062c0 EBX: c58062c0 ECX: 0008 EDX: c4c1f0a0
[0.762832] ESI: c58168c0 EDI: 00200086 EBP: cb495ed4 ESP: cb495ed0
[0.762832] DS: 007b ES: 007b FS:  GS: 00e0 SS: 0068 EFLAGS: 0022
[0.762832] CR0: 80050033 CR2:  CR3: 0597a000 CR4: 06f0
[0.762832] Call Trace:
[0.762832]  tk_setup_internals.constprop.10+0x3d/0x260

Re: [for-next][PATCH 08/18] parisc: function_graph: Simplify with function_graph_entry()

2018-11-23 Thread Sasha Levin

On Fri, Nov 23, 2018 at 02:26:17PM -0500, Steven Rostedt wrote:

On Fri, 23 Nov 2018 13:34:15 -0500
Sasha Levin  wrote:


Does this mean that someone (Steve) will send a backport of this to all
relevant stable trees? Right now it looks like the series will randomly
apply on a mix of trees, which can't be good.


Nope. I stated that in my 0 patch.


That's not good though, if you don't intend for them to be automagically
backported to stable trees by Greg, then they shouldn't be tagged at all
and if someone is interested then he can provide a backport.

What will happen with these is that once Greg's scripts process Linus's
tree he'll end up with this patch series inconsistently backported to
stable trees, which is not what you want here.

Sure, we can wait for the "added to the xyz stable tree" mails and
object then, but why risk breaking the trees?

--
Thanks.
Sasha


[PATCH 2/6] ARM: dts: meson: group the Cortex-A5 / Cortex-A9 peripherals

2018-11-23 Thread Martin Blumenstingl
The public Meson8b (S805) datasheet describes a memory region called "A9
Periph base" which starts at 0xC430 and ends at 0xC430. Add a
simple-bus node and move all peripherals that are part of this memory
region.
This makes the .dts a bit easier to read. No functional changes.

Signed-off-by: Martin Blumenstingl 
---
 arch/arm/boot/dts/meson.dtsi   | 24 
 arch/arm/boot/dts/meson8.dtsi  | 12 +++-
 arch/arm/boot/dts/meson8b.dtsi | 12 +++-
 3 files changed, 30 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/meson.dtsi b/arch/arm/boot/dts/meson.dtsi
index 0839da07a75c..e4645f612712 100644
--- a/arch/arm/boot/dts/meson.dtsi
+++ b/arch/arm/boot/dts/meson.dtsi
@@ -59,14 +59,6 @@
cache-level = <2>;
};
 
-   gic: interrupt-controller@c4301000 {
-   compatible = "arm,cortex-a9-gic";
-   reg = <0xc4301000 0x1000>,
- <0xc4300100 0x0100>;
-   interrupt-controller;
-   #interrupt-cells = <3>;
-   };
-
soc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -207,6 +199,22 @@
};
};
 
+   periph: bus@c430 {
+   compatible = "simple-bus";
+   reg = <0xc430 0x1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0xc430 0x1>;
+
+   gic: interrupt-controller@1000 {
+   compatible = "arm,cortex-a9-gic";
+   reg = <0x1000 0x1000>,
+ <0x100 0x100>;
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   };
+   };
+
aobus: aobus@c810 {
compatible = "simple-bus";
reg = <0xc810 0x10>;
diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 3be5fbd07997..28b9f6779993 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -129,11 +129,6 @@
no-map;
};
};
-
-   scu@c430 {
-   compatible = "arm,cortex-a9-scu";
-   reg = <0xc430 0x100>;
-   };
 }; /* end of / */
 
 &aobus {
@@ -362,6 +357,13 @@
arm,shared-override;
 };
 
+&periph {
+   scu@0 {
+   compatible = "arm,cortex-a9-scu";
+   reg = <0x0 0x100>;
+   };
+};
+
 &pwm_ab {
compatible = "amlogic,meson8-pwm", "amlogic,meson8b-pwm";
 };
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index 587a855f872b..6b097ab8637f 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -112,11 +112,6 @@
no-map;
};
};
-
-   scu@c430 {
-   compatible = "arm,cortex-a5-scu";
-   reg = <0xc430 0x100>;
-   };
 }; /* end of / */
 
 &aobus {
@@ -349,6 +344,13 @@
arm,shared-override;
 };
 
+&periph {
+   scu@0 {
+   compatible = "arm,cortex-a5-scu";
+   reg = <0x0 0x100>;
+   };
+};
+
 &pwm_ab {
compatible = "amlogic,meson8b-pwm";
 };
-- 
2.19.2



[PATCH 3/6] ARM: dts: meson8: add the ARM TWD timer

2018-11-23 Thread Martin Blumenstingl
The Meson8 and Meson8m2 SoC are using four ARM Cortex-A9 cores which
come with a "TWD" (Timer-Watchdog) based timer. This adds support for
the ARM TWD Timer on these two SoCs.

Suggested-by: Carlo Caione 
[ rebased patch from Carlo, use IRQ_TYPE_EDGE_RISING instead of
  IRQ_TYPE_LEVEL_LOW to prevent "GIC: PPI13 is secure or misconfigured"
  message during boot, use pre-processor macros to specify the IRQ,
  added the correct clock, dropped TWD watchdog node since there's no
  driver for it anymore ]
Signed-off-by: Martin Blumenstingl 
---
 arch/arm/boot/dts/meson8.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 28b9f6779993..2b0b3edbd896 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -362,6 +362,13 @@
compatible = "arm,cortex-a9-scu";
reg = <0x0 0x100>;
};
+
+   timer@600 {
+   compatible = "arm,cortex-a9-twd-timer";
+   reg = <0x600 0x20>;
+   interrupts = ;
+   clocks = <&clkc CLKID_PERIPH>;
+   };
 };
 
 &pwm_ab {
-- 
2.19.2



[PATCH 0/6] 32-bit Meson: add the ARM TWD and Global Timers

2018-11-23 Thread Martin Blumenstingl
The 32-bit Meson SoCs use Cortex-A9 or Cortex-A5 cores. These come
with the ARM TWD ("Timer Watchdog") which contains a timer and a
watchdog as well as the ARM Global Timer.

This enables the corresponding configs for the 32-bit Meson target.
Additionally this adds and enables the ARM TWD timer. The Global
Timer is added but currently disabled because it's clock input is
the PERIPH clock which is derived from the CPU clock. Thus the rate
of the PERIPH clock will change when changing the CPU frequency.
Unfortunately the Global Timer driver doesn't handle clocks with
changing rates yet (unlike the TWD timer), thus we keep it disabled
for now.

The whole series is inspired by an almost 3 year old patch from
Carlo: [0]


Dependencies:
- I build this on top of my other series "ARM: dts: meson: add the
  timer interrupts and clocks" from [1]
- CLKID_PERIPH requires updated clock driver headers. Neil provided
  a tag which includes the updated headers: [2]
- There is no runtime dependency on the PERIPH clock as we don't
  have CPU frequency scaling support enabled yet. In case the TWD
  timer driver can't find the clock it falls back to auto-detecting
  the clock rate at boot time. This is safe as long as we don't have
  .dts patches in place which allow changing the CPU clock rate. Once
  we enable CPU frequency scaling support for the PERIPH clock becomes
  mandatory so the TWD timer driver knows about changes to the PERIPH
  clock (which is derived from the CPU clock).


[0] https://patchwork.kernel.org/patch/7797581/
[1] https://patchwork.kernel.org/cover/10687005/
[2] http://lists.infradead.org/pipermail/linux-amlogic/2018-November/009136.html


Martin Blumenstingl (6):
  ARM: meson: select HAVE_ARM_TWD and ARM_GLOBAL_TIMER
  ARM: dts: meson: group the Cortex-A5 / Cortex-A9 peripherals
  ARM: dts: meson8: add the ARM TWD timer
  ARM: dts: meson8: add the Cortex-A9 global timer
  ARM: dts: meson8b: add the ARM TWD timer
  ARM: dts: meson8b: add the Cortex-A5 global timer

 arch/arm/boot/dts/meson.dtsi   | 24 
 arch/arm/boot/dts/meson8.dtsi  | 32 +++-
 arch/arm/boot/dts/meson8b.dtsi | 32 +++-
 arch/arm/mach-meson/Kconfig|  2 ++
 4 files changed, 72 insertions(+), 18 deletions(-)

-- 
2.19.2



[PATCH 4/6] ARM: dts: meson8: add the Cortex-A9 global timer

2018-11-23 Thread Martin Blumenstingl
The Meson8 and Meson8m2 SoCs are using four Cortex-A9 cores. These come
with an ARM global timer.
This adds the Cortex-A9 global timer but keeps it disabled for now. The
timer is clocked by the "PERIPH" clock whose rate can change during
runtime (when changing the frequency of the CPU clock). Unfortunately
the arm_global_timer driver does not handle changes to the clock rate
yet.

Signed-off-by: Martin Blumenstingl 
---
 arch/arm/boot/dts/meson8.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 2b0b3edbd896..2575a5835567 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -363,6 +363,19 @@
reg = <0x0 0x100>;
};
 
+   timer@200 {
+   compatible = "arm,cortex-a9-global-timer";
+   reg = <0x200 0x20>;
+   interrupts = ;
+   clocks = <&clkc CLKID_PERIPH>;
+
+   /*
+* the arm_global_timer driver currently does not handle clock
+* rate changes. Keep it disabled for now.
+*/
+   status = "disabled";
+   };
+
timer@600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0x600 0x20>;
-- 
2.19.2



[PATCH 1/6] ARM: meson: select HAVE_ARM_TWD and ARM_GLOBAL_TIMER

2018-11-23 Thread Martin Blumenstingl
The 32-bit Meson SoCs use multiple Cortex-A9 (Meson8 and Meson8m2) or
Cortex-A5 (Meson8b) CPU cores. These come with the "ARM global timer"
and "Timer-Watchdog" (aka TWD, which provides both a per-cpu local timer
and watchdog).

Selecting ARM_GLOBAL_TIMER and HAVE_ARM_TWD allows us to add the timers
to the SoC.dtsi files.

Signed-off-by: Martin Blumenstingl 
---
 arch/arm/mach-meson/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index d51cfda953d4..b16831697183 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -4,12 +4,14 @@ menuconfig ARCH_MESON
select GPIOLIB
select GENERIC_IRQ_CHIP
select ARM_GIC
+   select ARM_GLOBAL_TIMER
select CACHE_L2X0
select PINCTRL
select PINCTRL_MESON
select COMMON_CLK
select COMMON_CLK_AMLOGIC
select HAVE_ARM_SCU if SMP
+   select HAVE_ARM_TWD if SMP
 
 if ARCH_MESON
 
-- 
2.19.2



[PATCH 5/6] ARM: dts: meson8b: add the ARM TWD timer

2018-11-23 Thread Martin Blumenstingl
The Meson8B SoC is using four ARM Cortex-A5 cores which come with a
"TWD" (Timer-Watchdog) based timer. This adds support for the ARM TWD
Timer on this SoC.

Suggested-by: Carlo Caione 
[ rebased patch from Carlo, use IRQ_TYPE_EDGE_RISING instead of
  IRQ_TYPE_LEVEL_LOW to prevent "GIC: PPI13 is secure or misconfigured"
  message during boot, use pre-processor macros to specify the IRQ,
  added the correct clock, dropped TWD watchdog node since there's no
  driver for it anymore ]
Signed-off-by: Martin Blumenstingl 
---
 arch/arm/boot/dts/meson8b.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index 6b097ab8637f..a3a5649e32fa 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -349,6 +349,13 @@
compatible = "arm,cortex-a5-scu";
reg = <0x0 0x100>;
};
+
+   timer@600 {
+   compatible = "arm,cortex-a5-twd-timer";
+   reg = <0x600 0x20>;
+   interrupts = ;
+   clocks = <&clkc CLKID_PERIPH>;
+   };
 };
 
 &pwm_ab {
-- 
2.19.2



[PATCH 6/6] ARM: dts: meson8b: add the Cortex-A5 global timer

2018-11-23 Thread Martin Blumenstingl
The Meson8b SoC is using four Cortex-A5 cores. These come with an ARM
global timer.
This adds the Cortex-A5 global timer but keeps it disabled for now. The
timer is clocked by the "PERIPH" clock whose rate can change during
runtime (when changing the frequency of the CPU clock). Unfortunately
the arm_global_timer driver does not handle changes to the clock rate
yet.

Signed-off-by: Martin Blumenstingl 
---
 arch/arm/boot/dts/meson8b.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index a3a5649e32fa..a38d187d3d6e 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -350,6 +350,19 @@
reg = <0x0 0x100>;
};
 
+   timer@200 {
+   compatible = "arm,cortex-a5-global-timer";
+   reg = <0x200 0x20>;
+   interrupts = ;
+   clocks = <&clkc CLKID_PERIPH>;
+
+   /*
+* the arm_global_timer driver currently does not handle clock
+* rate changes. Keep it disabled for now.
+*/
+   status = "disabled";
+   };
+
timer@600 {
compatible = "arm,cortex-a5-twd-timer";
reg = <0x600 0x20>;
-- 
2.19.2



Re: [PATCH v2 0/4] Meson8b: add the CPU clock post-dividers

2018-11-23 Thread Martin Blumenstingl
On Fri, Nov 23, 2018 at 3:40 PM Neil Armstrong  wrote:
>
> On 22/11/2018 22:40, Martin Blumenstingl wrote:
> > This is the successor to my previous series "meson8b: add the CPU_DIV16
> > clock for the ARM TWD" from [0]. I decided to not send this as v2 of
> > the original series because the PERIPH clock is not the CPU_DIV16 clock.
> > It's not clear whether a CPU_DIV16 clock exists.
> >
> > With this series we get all the CPU_CLK post-dividers as listed in the
> > public S805 datasheet [1] on pages 31 and 32:
> > - ABP
> > - PERIPH (used as input for the ARM global timer and ARM TWD timer)
> > - AXI
> > - L2 DRAM
> >
> > Each of these clocks has a register called "..._CLK_DIS" which is
> > documented as a "just in case" bit:
> > "Set to 1 to manually disable the [...] clock when changing the mux
> > selection. Typically this bit is set to 0 since the clock muxes can
> > switch without glitches."
> > Since we're not supposed to touch that register we're using the new
> > read-only gate clk_ops to ensure that nothing accidentally modifies
> > these bits.
> >
> > The result of this is that we can use the PERIPH clock which clocks
> > the ARM TWD timer. I will send a separate series to add the TWD timer.
> >
> >
> > changes since v1 at [2]:
> > - added new patch 2 "clk: meson: clk-regmap: add read-only gate ops"
> > - switched from CLK_IS_CRITICAL to the new clk_regmap_gate_ro_ops
> >   so we're consistent with all other read-only clocks
> > - collected Jerome's Acked-by tags (thanks!)
> >
> >
> > [0] http://lists.infradead.org/pipermail/linux-amlogic/2018-July/007890.html
> > [1] 
> > https://dn.odroid.com/S805/Datasheet/S805_Datasheet%20V0.8%2020150126.pdf
> > [2] https://patchwork.kernel.org/cover/10687023/
> >
> >
> > Martin Blumenstingl (4):
> >   dt-bindings: clock: meson8b: export the CPU post dividers
> >   clk: meson: clk-regmap: add read-only gate ops
> >   clk: meson: meson8b: rename cpu_div2/cpu_div3 to
> > cpu_in_div2/cpu_in_div3
> >   clk: meson: meson8b: add the CPU clock post divider clocks
> >
> >  drivers/clk/meson/clk-regmap.c   |   5 +
> >  drivers/clk/meson/clk-regmap.h   |   1 +
> >  drivers/clk/meson/meson8b.c  | 264 ++-
> >  drivers/clk/meson/meson8b.h  |  17 +-
> >  include/dt-bindings/clock/meson8b-clkc.h |   4 +
> >  5 files changed, 278 insertions(+), 13 deletions(-)
>
>
> Applied, with the bindings on next/headers
awesome, thank you Neil!
you even gave Kevin a tag with only the headers included - good for me
since I can sent the corresponding .dts patches now.


Regards
Martin


Re: [PATCH v2 0/2] clocksource/meson6_timer: implement ARM delay timer

2018-11-23 Thread Martin Blumenstingl
On Fri, Nov 23, 2018 at 7:15 AM Daniel Lezcano
 wrote:
>
> On 22/11/2018 23:12, Martin Blumenstingl wrote:
> > Hi Daniel,
> >
> > On Sun, Nov 18, 2018 at 2:27 AM Daniel Lezcano
> >  wrote:
> >>
> >> On 15/11/2018 23:46, Martin Blumenstingl wrote:
> >>> While trying to add support for the ARM TWD Timer and the ARM Global
> >>> Timer on Meson8, Meson8b and Meson8m2 (ARM Cortex-A5 and Cortex-A9 SoCs)
> >>> I did a review of the existing driver.
> >>> Unfortunately I found it hard to review because the pre-processor
> >>> #defines did not match the names from the public S805 datasheet. Thus
> >>> patch #1 adjusts these. No functional changes here, this is just
> >>> preparation work for patch #2.
> >>>
> >>> Using the ARM Global Timer (drivers/clocksource/arm_global_timer.c)
> >>> would have given us a timer-based delay implementation (so udelay() and
> >>> friends would use the timer instead of using a loop-based delay
> >>> implementation). Unfortunately we can't use the ARM Global Timer yet
> >>> because it's input clock is derived from the CPU clock (which can change
> >>> once we enable CPU frequency scaling on these SoCs, for which I will be
> >>> sending patches in the near future).
> >>> Amlogic's 3.10 kernel uses Timer E as delay timer which (with the
> >>> current configuration) has a resolution of 1us. So patch #2 uses
> >>> register_current_timer_delay() to register Timer E as ARM delay timer
> >>> (which will be especially useful as we have to use udelay() when
> >>> changing the CPU clocks during DVFS).
> >>>
> >>>
> >>> Changes since v1 at [0]:
> >>> - convert the enums for the input clock (meson6_timera_input_clock and
> >>>   meson6_timere_input_clock) to simple #defines as these are register
> >>>   values and not something driver-internal. All other register values
> >>>   are #defines so it makes sense that these are #defines as well.
> >>>
> >>>
> >>> [0] https://patchwork.kernel.org/cover/10658591/
> >>>
> >>>
> >>> Martin Blumenstingl (2):
> >>>   clocksource: meson6_timer: use register names from the datasheet
> >>>   clocksource: meson6_timer: implement ARM delay timer
> >>>
> >>>  drivers/clocksource/meson6_timer.c | 128 +++--
> >>>  1 file changed, 85 insertions(+), 43 deletions(-)
> >>
> >> Both applied, thanks!
> > thank you for taking my patches
> >
> > I have one question more: can you please push these patches to a
> > repository/branch which is included in -next?
> > I'm asking because I'd like to send patches that enable CPU frequency
> > scaling on Meson8, Meson8b and Meson8m2. The code to change the CPU
> > clock calls udelay(), which (in this special case) needs a delay timer
> > to work properly (we can't use jiffies as we're using udelay() *while*
> > changing the CPU clock).
>
> branch pushed [1], should appear in linux-next very soon.
awesome, thank you!


Regards
Martin


Re: [RFC][PATCH] fs: set xattrs in initramfs from regular files

2018-11-23 Thread Mimi Zohar
On Fri, 2018-11-23 at 11:03 -0800, Casey Schaufler wrote:
> On 11/22/2018 7:49 AM, Roberto Sassu wrote:
> > Although rootfs (tmpfs) supports xattrs, they are not set due to the
> > limitation of the cpio format. A new format called 'newcx' was proposed to
> > overcome this limitation.
> >
> > However, it looks like that adding a new format is not simple: 15 kernel
> > patches; user space tools must support the new format; mistakes made in the
> > past should be avoided; it is unclear whether the kernel should switch from
> > cpio to tar.
> >
> > The aim of this patch is to provide the same functionality without
> > introducing a new format. The value of xattrs is placed in regular files
> > having the same file name as the files xattrs are added to, plus a
> > separator and the xattr name (.xattr-).
> >
> > Example:
> >
> > '/bin/cat.xattr-security.ima' is the name of a file containing the value of
> > the security.ima xattr to be added to /bin/cat.
> >
> > At kernel initialization time, the kernel iterates over the rootfs
> > filesystem, and if it encounters files with the '.xattr-' separator, it
> > reads the content and adds the xattr to the file without the suffix.
> 
> No.
> 
> Really, no.
> 
> It would be incredibly easy to use this mechanism to break
> into systems.
>  
> 
> > This proposal requires that LSMs and IMA allow the read and setxattr
> > operations. This should not be a concern since: files with xattr values
> > are not parsed by the kernel; user space processes are not yet executed.
> >
> > It would be possible to include all xattrs in the same file, but this
> > increases the risk of the kernel being compromised by parsing the content.
> 
> The kernel mustn't do this.

Mustn't do what?  Store the xattr as separate detached files, 
include all the xattrs in a single or per security/LSM xattr attribute
file(s), or either?

Mimi



Re: [GIT PULL] Ceph fix for 4.20-rc4

2018-11-23 Thread pr-tracker-bot
The pull request you sent on Fri, 23 Nov 2018 19:49:19 +0100:

> https://github.com/ceph/ceph-client.git tags/ceph-for-4.20-rc4

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7c98a42618271210c60b79128b220107d35938d9

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [for-next][PATCH 08/18] parisc: function_graph: Simplify with function_graph_entry()

2018-11-23 Thread Steven Rostedt
On Fri, 23 Nov 2018 13:34:15 -0500
Sasha Levin  wrote:

> Does this mean that someone (Steve) will send a backport of this to all
> relevant stable trees? Right now it looks like the series will randomly
> apply on a mix of trees, which can't be good.

Nope. I stated that in my 0 patch.

-- Steve


Re: [RFC][PATCH 09/14] function_graph: Move ftrace_graph_get_addr() to fgraph.c

2018-11-23 Thread Steven Rostedt
On Thu, 22 Nov 2018 19:13:38 -0800
Joel Fernandes  wrote:

> On Wed, Nov 21, 2018 at 08:27:17PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)" 
> > 
> > Move the function function_graph_get_addr() to fgraph.c, as the management
> > of the curr_ret_stack is going to change, and all the accesses to ret_stack
> > needs to be done in fgraph.c.  
> 
> s/ftrace_graph_get_addr/ftrace_graph_ret_addr/
> 

Good catch. I wrote the change logs a bit after writing the patch. I
had "get" on my mind.

-- Steve


Re: [PATCH 0/7] ACPI HMAT memory sysfs representation

2018-11-23 Thread Dave Hansen
On 11/22/18 10:42 PM, Anshuman Khandual wrote:
> Are we willing to go in the direction for inclusion of a new system
> call, subset of it appears on sysfs etc ? My primary concern is not
> how the attribute information appears on the sysfs but lack of it's
> completeness.

A new system call makes total sense to me.  I have the same concern
about the completeness of what's exposed in sysfs, I just don't see a
_route_ to completeness with sysfs itself.  Thus, the minimalist
approach as a first step.



Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-23 Thread Andy Lutomirski



> On Nov 23, 2018, at 11:44 AM, Linus Torvalds  
> wrote:
> 
>> On Fri, Nov 23, 2018 at 10:39 AM Andy Lutomirski  wrote:
>> 
>> What is memcpy_to_io even supposed to do?  I’m guessing it’s defined as 
>> something like “copy this data to IO space using at most long-sized writes, 
>> all aligned, and writing each byte exactly once, in order.”  That sounds... 
>> dubiously useful.
> 
> We've got hundreds of users of it, so it's fairly common..
> 

I’m wondering if the “at most long-sizes” restriction matters, especially given 
that we’re apparently accessing some of the same bytes more than once. I would 
believe that trying to encourage 16-byte writes (with AVX, ugh) or 64-byte 
writes (with MOVDIR64B) would be safe and could meaningfully speed up some 
workloads.

>> I could see a function that writes to aligned memory in specified-sized 
>> chunks.
> 
> We have that. It's called "__iowrite{32,64}_copy()". It has very few users.
> 
>  Linus


  1   2   3   4   5   >