Re: objtool warnings for kernel/trace/trace_selftest_dynamic.o
Hi, On Tue, Dec 18 2018, Andi Kleen wrote: >> OK, I have read through it and with the caveats that I don't quite >> understand what the failure is, that also believe attribute noclone >> should not affect frame pointer generation, and that I don't quite get >> how LTO comes into play, my comments are the following: > >> >> I am the developer who introduced attribute noclone to GCC and also the >> one who advises against using it :-) ...at least without also using the >> noinline attribute, the combination means " > > The function in question uses noinline too. > >> I want only one or zero >> copies of this function in the compiled assembly" which you might need >> if you do fancy stuff in inline assembly, for example. > > For this case we only want one non inlined copy because it is used as a > test case for a function tracer. > > LTO comes into play because it originally relied on being in a separate > file, so it would not be inlined, but with LTO that doesn't work. > >> >> I believe that when people use noclone on its own, in 99 out 100 cases >> they actually want something else. Usually there is something that > > AFAIK there is no noclone without noinline in the kernel tree. > > >> references the function from code (such as assembly) or a tool that the >> compiler does know about and then they should use the "used" attribute. > > Neither in the ftrace case, nor in the KVM case (another user which > has fancy inline assembly that cannot be duplicated) that's the case. > It's just about having exactly one out of line instance. > > So based on that I think noclone is fine. Of course there > is still the open question why exactly the frame pointer disappears. I agree, I originally thought the problem was something else. Thanks for the clarification, Martin
[PATCH 3/3] mm: show number of vmalloc pages in /proc/meminfo
Vmalloc() is getting more and more used these days (kernel stacks,
bpf and percpu allocator are new top users), and the total %
of memory consumed by vmalloc() can be pretty significant
and changes dynamically.
/proc/meminfo is the best place to display this information:
its top goal is to show top consumers of the memory.
Since the VmallocUsed field in /proc/meminfo is not in use
for quite a long time (it has been defined to 0 by the
commit a5ad88ce8c7f ("mm: get rid of 'vmalloc_info' from
/proc/meminfo")), let's reuse it for showing the actual
physical memory consumption of vmalloc().
Signed-off-by: Roman Gushchin
Acked-by: Johannes Weiner
---
fs/proc/meminfo.c | 2 +-
include/linux/vmalloc.h | 2 ++
mm/vmalloc.c| 10 ++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index 568d90e17c17..465ea0153b2a 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -120,7 +120,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
show_val_kb(m, "Committed_AS: ", committed);
seq_printf(m, "VmallocTotal: %8lu kB\n",
(unsigned long)VMALLOC_TOTAL >> 10);
- show_val_kb(m, "VmallocUsed:", 0ul);
+ show_val_kb(m, "VmallocUsed:", vmalloc_nr_pages());
show_val_kb(m, "VmallocChunk: ", 0ul);
show_val_kb(m, "Percpu: ", pcpu_nr_pages());
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 398e9c95cd61..0b497408272b 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -63,10 +63,12 @@ extern void vm_unmap_aliases(void);
#ifdef CONFIG_MMU
extern void __init vmalloc_init(void);
+extern unsigned long vmalloc_nr_pages(void);
#else
static inline void vmalloc_init(void)
{
}
+static inline unsigned long vmalloc_nr_pages(void) { return 0; }
#endif
extern void *vmalloc(unsigned long size);
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 042175d7d95f..efca916940e9 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -340,6 +340,13 @@ static unsigned long cached_align;
static unsigned long vmap_area_pcpu_hole;
+static atomic_long_t nr_vmalloc_pages;
+
+unsigned long vmalloc_nr_pages(void)
+{
+ return atomic_long_read(_vmalloc_pages);
+}
+
static struct vmap_area *__find_vmap_area(unsigned long addr)
{
struct rb_node *n = vmap_area_root.rb_node;
@@ -1549,6 +1556,7 @@ static void __vunmap(const void *addr, int
deallocate_pages)
BUG_ON(!page);
__free_pages(page, 0);
}
+ atomic_long_sub(area->nr_pages, _vmalloc_pages);
kvfree(area->pages);
}
@@ -1717,12 +1725,14 @@ static void *__vmalloc_area_node(struct vm_struct
*area, gfp_t gfp_mask,
if (unlikely(!page)) {
/* Successfully allocated i pages, free them in
__vunmap() */
area->nr_pages = i;
+ atomic_long_add(area->nr_pages, _vmalloc_pages);
goto fail;
}
area->pages[i] = page;
if (gfpflags_allow_blocking(gfp_mask|highmem_mask))
cond_resched();
}
+ atomic_long_add(area->nr_pages, _vmalloc_pages);
if (map_vm_area(area, prot, pages))
goto fail;
--
2.19.2
[PATCH 2/3] mm: separate memory allocation and actual work in alloc_vmap_area()
alloc_vmap_area() is allocating memory for the vmap_area, and
performing the actual lookup of the vm area and vmap_area
initialization.
This prevents us from using a pre-allocated memory for the map_area
structure, which can be used in some cases to minimize the number
of required memory allocations.
Let's keep the memory allocation part in alloc_vmap_area() and
separate everything else into init_vmap_area().
Signed-off-by: Roman Gushchin
Acked-by: Johannes Weiner
Reviewed-by: Matthew Wilcox
---
mm/vmalloc.c | 50 +-
1 file changed, 33 insertions(+), 17 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 7660e3ef4133..042175d7d95f 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -395,16 +395,10 @@ static void purge_vmap_area_lazy(void);
static BLOCKING_NOTIFIER_HEAD(vmap_notify_list);
-/*
- * Allocate a region of KVA of the specified size and alignment, within the
- * vstart and vend.
- */
-static struct vmap_area *alloc_vmap_area(unsigned long size,
- unsigned long align,
- unsigned long vstart, unsigned long vend,
- int node, gfp_t gfp_mask)
+static int init_vmap_area(struct vmap_area *va, unsigned long size,
+ unsigned long align, unsigned long vstart,
+ unsigned long vend, int node, gfp_t gfp_mask)
{
- struct vmap_area *va;
struct rb_node *n;
unsigned long addr;
int purged = 0;
@@ -416,11 +410,6 @@ static struct vmap_area *alloc_vmap_area(unsigned long
size,
might_sleep();
- va = kmalloc_node(sizeof(struct vmap_area),
- gfp_mask & GFP_RECLAIM_MASK, node);
- if (unlikely(!va))
- return ERR_PTR(-ENOMEM);
-
/*
* Only scan the relevant parts containing pointers to other objects
* to avoid false negatives.
@@ -512,7 +501,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
BUG_ON(va->va_start < vstart);
BUG_ON(va->va_end > vend);
- return va;
+ return 0;
overflow:
spin_unlock(_area_lock);
@@ -534,8 +523,35 @@ static struct vmap_area *alloc_vmap_area(unsigned long
size,
if (!(gfp_mask & __GFP_NOWARN) && printk_ratelimit())
pr_warn("vmap allocation for size %lu failed: use
vmalloc= to increase size\n",
size);
- kfree(va);
- return ERR_PTR(-EBUSY);
+
+ return -EBUSY;
+}
+
+/*
+ * Allocate a region of KVA of the specified size and alignment, within the
+ * vstart and vend.
+ */
+static struct vmap_area *alloc_vmap_area(unsigned long size,
+unsigned long align,
+unsigned long vstart,
+unsigned long vend,
+int node, gfp_t gfp_mask)
+{
+ struct vmap_area *va;
+ int ret;
+
+ va = kmalloc_node(sizeof(struct vmap_area),
+ gfp_mask & GFP_RECLAIM_MASK, node);
+ if (unlikely(!va))
+ return ERR_PTR(-ENOMEM);
+
+ ret = init_vmap_area(va, size, align, vstart, vend, node, gfp_mask);
+ if (ret) {
+ kfree(va);
+ return ERR_PTR(ret);
+ }
+
+ return va;
}
int register_vmap_purge_notifier(struct notifier_block *nb)
--
2.19.2
[PATCH 1/3] mm: refactor __vunmap() to avoid duplicated call to find_vm_area()
__vunmap() calls find_vm_area() twice without an obvious reason:
first directly to get the area pointer, second indirectly by calling
remove_vm_area(), which is again searching for the area.
To remove this redundancy, let's split remove_vm_area() into
__remove_vm_area(struct vmap_area *), which performs the actual area
removal, and remove_vm_area(const void *addr) wrapper, which can
be used everywhere, where it has been used before.
On my test setup, I've got up to 12% speed up on vfree()'ing 100
of 4-pages vmalloc blocks.
Signed-off-by: Roman Gushchin
Acked-by: Johannes Weiner
Reviewed-by: Matthew Wilcox
---
mm/vmalloc.c | 47 +++
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 871e41c55e23..7660e3ef4133 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1462,6 +1462,24 @@ struct vm_struct *find_vm_area(const void *addr)
return NULL;
}
+static struct vm_struct *__remove_vm_area(struct vmap_area *va)
+{
+ struct vm_struct *vm = va->vm;
+
+ might_sleep();
+
+ spin_lock(_area_lock);
+ va->vm = NULL;
+ va->flags &= ~VM_VM_AREA;
+ va->flags |= VM_LAZY_FREE;
+ spin_unlock(_area_lock);
+
+ kasan_free_shadow(vm);
+ free_unmap_vmap_area(va);
+
+ return vm;
+}
+
/**
* remove_vm_area - find and remove a continuous kernel virtual area
* @addr: base address
@@ -1472,31 +1490,20 @@ struct vm_struct *find_vm_area(const void *addr)
*/
struct vm_struct *remove_vm_area(const void *addr)
{
+ struct vm_struct *vm = NULL;
struct vmap_area *va;
- might_sleep();
-
va = find_vmap_area((unsigned long)addr);
- if (va && va->flags & VM_VM_AREA) {
- struct vm_struct *vm = va->vm;
-
- spin_lock(_area_lock);
- va->vm = NULL;
- va->flags &= ~VM_VM_AREA;
- va->flags |= VM_LAZY_FREE;
- spin_unlock(_area_lock);
-
- kasan_free_shadow(vm);
- free_unmap_vmap_area(va);
+ if (va && va->flags & VM_VM_AREA)
+ vm = __remove_vm_area(va);
- return vm;
- }
- return NULL;
+ return vm;
}
static void __vunmap(const void *addr, int deallocate_pages)
{
struct vm_struct *area;
+ struct vmap_area *va;
if (!addr)
return;
@@ -1505,17 +1512,18 @@ static void __vunmap(const void *addr, int
deallocate_pages)
addr))
return;
- area = find_vmap_area((unsigned long)addr)->vm;
- if (unlikely(!area)) {
+ va = find_vmap_area((unsigned long)addr);
+ if (unlikely(!va || !va->vm)) {
WARN(1, KERN_ERR "Trying to vfree() nonexistent vm area (%p)\n",
addr);
return;
}
+ area = va->vm;
debug_check_no_locks_freed(area->addr, get_vm_area_size(area));
debug_check_no_obj_freed(area->addr, get_vm_area_size(area));
- remove_vm_area(addr);
+ __remove_vm_area(va);
if (deallocate_pages) {
int i;
@@ -1530,7 +1538,6 @@ static void __vunmap(const void *addr, int
deallocate_pages)
}
kfree(area);
- return;
}
static inline void __vfree_deferred(const void *addr)
--
2.19.2
[PATCH 0/3] vmalloc enhancements
The patchset contains few changes to the vmalloc code, which are leading to some performance gains and code simplification. Also, it exports a number of pages, used by vmalloc(), in /proc/meminfo. Patch (1) removes some redundancy on __vunmap(). Patch (2) separates memory allocation and data initialization in alloc_vmap_area() Patch (3) adds vmalloc counter to /proc/meminfo. RFC->v1: - removed bogus empty lines (suggested by Matthew Wilcox) - made nr_vmalloc_pages static (suggested by Matthew Wilcox) - dropped patch 3 from RFC patchset, will post later with some other changes - dropped RFC Roman Gushchin (3): mm: refactor __vunmap() to avoid duplicated call to find_vm_area() mm: separate memory allocation and actual work in alloc_vmap_area() mm: show number of vmalloc pages in /proc/meminfo fs/proc/meminfo.c | 2 +- include/linux/vmalloc.h | 2 + mm/vmalloc.c| 107 ++-- 3 files changed, 73 insertions(+), 38 deletions(-) -- 2.19.2
Re: [PATCH 1/2] ARC: show_regs: avoid page allocator
On 12/19/18 9:04 AM, Eugeniy Paltsev wrote: > Just curious: isn't that enough to use GFP_NOWAIT instead > of GFP_KERNEL when we allocate page in show_regs()? > > As I can see x86 use print_vma_addr() in their show_signal_msg() > function which allocate page with __get_free_page(GFP_NOWAIT); I'm not sure if lockdep will be happy with it still. At any rate, as explained in changelog, this still has merit, since the buffer is only needed for nested d_path calls, which are better served with a smaller on-stack buffer. For cases such as kernel crash, we want lesser code/traces in fault path to sift thru ! -Vineet
Re: [PATCH 7/7] drm: Complete remove drm_mode_object dependency
On 12/19, Daniel Vetter wrote:
> On Tue, Dec 18, 2018 at 11:38:36AM -0200, Shayenne Moura wrote:
> > This patch finalizes the KMS cleanup task dependency from drm_display_mode
> > It removes the use of drm_mode_object from drm_display_mode struct
> > and it removes the use of base.id and base.type.
> >
> > Signed-off-by: Shayenne Moura
>
> I didn't yet compile-test all the drivers, but aside from that this looks
> all good.
>
Thank you for your reviews! :)
Shayenne
> Reviewed-by: Daniel Vetter
> > ---
> > include/drm/drm_modes.h | 21 +++--
> > 1 file changed, 3 insertions(+), 18 deletions(-)
> >
> > diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> > index baded6514456..9ecc1e835565 100644
> > --- a/include/drm/drm_modes.h
> > +++ b/include/drm/drm_modes.h
> > @@ -136,8 +136,7 @@ enum drm_mode_status {
> > .hdisplay = (hd), .hsync_start = (hss), .hsync_end = (hse), \
> > .htotal = (ht), .hskew = (hsk), .vdisplay = (vd), \
> > .vsync_start = (vss), .vsync_end = (vse), .vtotal = (vt), \
> > - .vscan = (vs), .flags = (f), \
> > - .base.type = DRM_MODE_OBJECT_MODE
> > + .vscan = (vs), .flags = (f)
> >
> > #define CRTC_INTERLACE_HALVE_V (1 << 0) /* halve V values for interlacing
> > */
> > #define CRTC_STEREO_DOUBLE (1 << 1) /* adjust timings for stereo modes
> > */
> > @@ -213,20 +212,6 @@ struct drm_display_mode {
> > */
> > struct list_head head;
> >
> > - /**
> > -* @base:
> > -*
> > -* A display mode is a normal modeset object, possibly including
> > public
> > -* userspace id.
> > -*
> > -* FIXME:
> > -*
> > -* This can probably be removed since the entire concept of
> > userspace
> > -* managing modes explicitly has never landed in upstream kernel
> > mode
> > -* setting support.
> > -*/
> > - struct drm_mode_object base;
> > -
> > /**
> > * @name:
> > *
> > @@ -429,14 +414,14 @@ struct drm_display_mode {
> > /**
> > * DRM_MODE_FMT - printf string for drm_display_mode
> > */
> > -#define DRM_MODE_FMT"%d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
> > +#define DRM_MODE_FMT"\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
> >
> > /**
> > * DRM_MODE_ARG - printf arguments for drm_display_mode
> > * @m: display mode
> > */
> > #define DRM_MODE_ARG(m) \
> > - (m)->base.id, (m)->name, (m)->vrefresh, (m)->clock, \
> > + (m)->name, (m)->vrefresh, (m)->clock, \
> > (m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
> > (m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
> > (m)->type, (m)->flags
> > --
> > 2.17.1
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Re: [PATCH net 4/4] vhost: log dirty page correctly
Hi Jason, I love your patch! Perhaps something to improve: [auto build test WARNING on net/master] url: https://github.com/0day-ci/linux/commits/Jason-Wang/Fix-various-issue-of-vhost/20181210-223236 config: x86_64-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): include/linux/slab.h:332:43: warning: dubious: x & !y include/linux/slab.h:332:43: warning: dubious: x & !y include/linux/slab.h:332:43: warning: dubious: x & !y drivers/vhost/vhost.c:704:17: warning: incorrect type in return expression (different address spaces) drivers/vhost/vhost.c:704:17:expected void [noderef] * drivers/vhost/vhost.c:704:17:got void * drivers/vhost/vhost.c:704:17: warning: incorrect type in return expression (different address spaces) drivers/vhost/vhost.c:704:17:expected void [noderef] * drivers/vhost/vhost.c:704:17:got void * include/linux/slab.h:332:43: warning: dubious: x & !y drivers/vhost/vhost.c:704:17: warning: incorrect type in return expression (different address spaces) drivers/vhost/vhost.c:704:17:expected void [noderef] * drivers/vhost/vhost.c:704:17:got void * >> drivers/vhost/vhost.c:1771:35: warning: cast removes address space '' >> of expression drivers/vhost/vhost.c:1776:42: warning: cast removes address space '' of expression drivers/vhost/vhost.c:1788:48: warning: cast removes address space '' of expression drivers/vhost/vhost.c:1819:13: warning: incorrect type in argument 2 (different address spaces) drivers/vhost/vhost.c:1819:13:expected void *addr drivers/vhost/vhost.c:1819:13:got restricted __virtio16 [noderef] * drivers/vhost/vhost.c:704:17: warning: incorrect type in return expression (different address spaces) drivers/vhost/vhost.c:704:17:expected void [noderef] * drivers/vhost/vhost.c:704:17:got void * drivers/vhost/vhost.c:851:42: warning: incorrect type in argument 2 (different address spaces) drivers/vhost/vhost.c:851:42:expected void [noderef] *addr drivers/vhost/vhost.c:851:42:got void *addr drivers/vhost/vhost.c:1837:13: warning: incorrect type in argument 2 (different address spaces) drivers/vhost/vhost.c:1837:13:expected void *addr drivers/vhost/vhost.c:1837:13:got restricted __virtio16 [noderef] [usertype] * drivers/vhost/vhost.c:704:17: warning: incorrect type in return expression (different address spaces) drivers/vhost/vhost.c:704:17:expected void [noderef] * drivers/vhost/vhost.c:704:17:got void * drivers/vhost/vhost.c:851:42: warning: incorrect type in argument 2 (different address spaces) drivers/vhost/vhost.c:851:42:expected void [noderef] *addr drivers/vhost/vhost.c:851:42:got void *addr drivers/vhost/vhost.c:1874:13: warning: incorrect type in argument 2 (different address spaces) drivers/vhost/vhost.c:1874:13:expected void *addr drivers/vhost/vhost.c:1874:13:got restricted __virtio16 [noderef] * drivers/vhost/vhost.c:704:17: warning: incorrect type in return expression (different address spaces) drivers/vhost/vhost.c:704:17:expected void [noderef] * drivers/vhost/vhost.c:704:17:got void * drivers/vhost/vhost.c:851:42: warning: incorrect type in argument 2 (different address spaces) drivers/vhost/vhost.c:851:42:expected void [noderef] *addr drivers/vhost/vhost.c:851:42:got void *addr drivers/vhost/vhost.c:2073:21: warning: incorrect type in argument 2 (different address spaces) drivers/vhost/vhost.c:2073:21:expected void *addr drivers/vhost/vhost.c:2073:21:got restricted __virtio16 [noderef] * drivers/vhost/vhost.c:704:17: warning: incorrect type in return expression (different address spaces) drivers/vhost/vhost.c:704:17:expected void [noderef] * drivers/vhost/vhost.c:704:17:got void * drivers/vhost/vhost.c:851:42: warning: incorrect type in argument 2 (different address spaces) drivers/vhost/vhost.c:851:42:expected void [noderef] *addr drivers/vhost/vhost.c:851:42:got void *addr drivers/vhost/vhost.c:2100:13: warning: incorrect type in argument 2 (different address spaces) drivers/vhost/vhost.c:2100:13:expected void *addr drivers/vhost/vhost.c:2100:13:got restricted __virtio16 [noderef] * drivers/vhost/vhost.c:704:17: warning: incorrect type in return expression (different address spaces) drivers/vhost/vhost.c:704:17:expected void [noderef] * drivers/vhost/vhost.c:704:17:got void * drivers/vhost/vhost.c:851:42: warning: incorrect type in argument 2 (different address spaces) drivers/vhost/vhost.c:851:42:expected void [noderef] *addr drivers/vhost/vhost.c:851:42:got void *addr drivers/vhost/vhost.c:2231:21: warning: incorrect type in argument 2
Re: objtool warnings for kernel/trace/trace_selftest_dynamic.o
Hi,
On Tue, Dec 18 2018, Josh Poimboeuf wrote:
> On Tue, Dec 18, 2018 at 01:15:40PM +0100, Martin Jambor wrote:
>> I'm afraid I cannot give an opinion what you should do in this case
>> without understanding the problem better. If you can isolate the case
>> where noclone behaves weirdly into a self-contained testcase, I'd be
>> happy to have a look at it.
>
> I whittled it down to a small test case. It turns out the problem is
> caused by the "__optimize__("no-tracer")" atribute, which is used by our
> __noclone macro:
Wonderful, thanks a lot.
>
> # if __has_attribute(__optimize__)
> # define __noclone __attribute__((__noclone__,
> __optimize__("no-tracer")))
> # else
> # define __noclone __attribute__((__noclone__))
> # endif
>
>
> Here's the test case. Notice it skips the frame pointer setup before
> the call to __sanitizer_cov_trace_pc():
>
>
> $ cat test.c
> __attribute__((__optimize__("no-tracer"))) int test(void)
> {
> return 0;
> }
> $ gcc -O2 -fno-omit-frame-pointer -fsanitize-coverage=trace-pc -c -o test.o
> test.c
Well, it might not be intuitive but the __optimize__ attribute resets to
-O2 optimization defaults and thus drops -fno-omit-frame-pointer on the
floor, so no wonder there is no frame pointer. This applies to other
optimization options you pass on the command line, for example if you
still compile kernel with -fno-strict-aliasing, you get GCC assuming
strict aliasing in functions marked with your __noclone.
> Apparently we are using "no-tracer" because of:
>
>
> commit 95272c29378ee7dc15f43fa2758cb28a5913a06d
> Author: Paolo Bonzini
> Date: Thu Mar 31 09:38:51 2016 +0200
>
> compiler-gcc: disable -ftracer for __noclone functions
>
> -ftracer can duplicate asm blocks causing compilation to fail in
> noclone functions. For example, KVM declares a global variable
> in an asm like
>
> asm("2: ... \n
> .pushsection data \n
> .global vmx_return \n
> vmx_return: .long 2b");
>
> and -ftracer causes a double declaration.
There is no way for a user to reliably prevent a duplication of an
inline assembly statement. The correct fix is to move such statements
to an assembly files. You have disabled tracer which duplicated it in
your case but other passes might do that too in the future.
The correct fix is to put such assembler snippets into separate assembly
files or, if you for for some reason insist on inline assembly, to use
'%=' inline assembler template format string (it is expanded to a number
that is unique in a compilation unit).
Martin
Re: [PATCH 4/7] drm: i915: Delete base.id prints
On 12/19, Daniel Vetter wrote: > On Tue, Dec 18, 2018 at 11:38:21AM -0200, Shayenne Moura wrote: > > This patch removes base.id prints from drm_display_mode > > > > objects in i915 files. It removes dependency from drm_mode_object. > > > > Signed-off-by: Shayenne Moura > > Again I think better to switch to DRM_MODE_FMT/ARG. > -Daniel > This one has a different print style. Is it okay to change to DRM_MODE_FMT? Best, Shayenne > > --- > > drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > > b/drivers/gpu/drm/i915/i915_debugfs.c > > index 7f455bca528e..61dd7bb3fa85 100644 > > --- a/drivers/gpu/drm/i915/i915_debugfs.c > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > > @@ -2948,8 +2948,8 @@ static void intel_seq_print_mode(struct seq_file *m, > > int tabs, > > for (i = 0; i < tabs; i++) > > seq_putc(m, '\t'); > > > > - seq_printf(m, "id %d:\"%s\" freq %d clock %d hdisp %d hss %d hse %d > > htot %d vdisp %d vss %d vse %d vtot %d type 0x%x flags 0x%x\n", > > - mode->base.id, mode->name, > > + seq_printf(m, "name:\"%s\" freq %d clock %d hdisp %d hss %d hse %d htot > > %d vdisp %d vss %d vse %d vtot %d type 0x%x flags 0x%x\n", > > + mode->name, > >mode->vrefresh, mode->clock, > >mode->hdisplay, mode->hsync_start, > >mode->hsync_end, mode->htotal, > > -- > > 2.17.1 > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
Re: [PATCH 4/4] ARM: mxs: cfa10036: Fixup OLED display reset polarity
On Tue, Dec 04, 2018 at 03:03:40PM +, Vokáč Michal wrote:
> There was a bug in reset signal generation in ssd1307fb OLED driver.
> The display needs an active-low reset signal but the driver produced
> the correct sequence only if the GPIO used for reset was specified as
> GPIO_ACTIVE_HIGH.
>
> Now as the OLED driver is fixed it is also necessarry to implement
> a fixup for all current users of the old DT ABI. There is only one
> in-tree user and that is the Crystalfontz CFA-10036 board. In case
> this board is booting and GPIO_ACTIVE_HIGH is used for reset we
> override it to GPIO_ACTIVE_LOW.
>
> Signed-off-by: Michal Vokáč
> ---
> arch/arm/mach-mxs/mach-mxs.c | 45
>
> 1 file changed, 45 insertions(+)
>
> diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
> index 1c6062d..23c260c 100644
> --- a/arch/arm/mach-mxs/mach-mxs.c
> +++ b/arch/arm/mach-mxs/mach-mxs.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -268,9 +269,53 @@ static void __init apx4devkit_init(void)
> apx4devkit_phy_fixup);
> }
>
> +#define OLED_RESET_GPIO_LEN 3
> +#define OLED_RESET_GPIO_SIZE (OLED_RESET_GPIO_LEN * sizeof(u32))
> +
> +static void __init crystalfontz_oled_reset_fixup(void)
> +{
> + struct property *newgpio;
> + struct device_node *np;
> + u32 *gpiospec;
> + int i, ret;
> +
> + np = of_find_compatible_node(NULL, NULL, "solomon,ssd1306fb-i2c");
> + if (!np)
> + return;
> +
> + newgpio = kzalloc(sizeof(*newgpio) + OLED_RESET_GPIO_SIZE, GFP_KERNEL);
> + if (!newgpio)
> + return;
> +
> + newgpio->value = newgpio + 1;
> + newgpio->length = OLED_RESET_GPIO_SIZE;
> + newgpio->name = kstrdup("reset-gpios", GFP_KERNEL);
> + if (!newgpio->name) {
> + kfree(newgpio);
> + return;
> + }
> +
> + gpiospec = newgpio->value;
> + for (i = 0; i < OLED_RESET_GPIO_LEN; i++) {
> + ret = of_property_read_u32_index(np, "reset-gpios", i,
> + [i]);
Don't we have a helper to read the whole array?
Otherwise, for the series:
Reviewed-by: Rob Herring
> + if (ret) {
> + kfree(newgpio);
> + return;
> + }
> + }
> +
> + if (!(gpiospec[2] & OF_GPIO_ACTIVE_LOW)) {
> + gpiospec[2] |= OF_GPIO_ACTIVE_LOW;
> + cpu_to_be32_array(gpiospec, gpiospec, OLED_RESET_GPIO_LEN);
> + of_update_property(np, newgpio);
> + }
> +}
> +
> static void __init crystalfontz_init(void)
> {
> update_fec_mac_prop(OUI_CRYSTALFONTZ);
> + crystalfontz_oled_reset_fixup();
> }
>
> static void __init duckbill_init(void)
> --
> 2.1.4
>
[PATCH v3] irqchip/mmp: only touch the PJ4 & FIQ bits on enable/disable
On an OLPC XO 1.75 machine, the "security processor" handles the GPIO 71
and 72 interrupts. Don't reset the "route to SP" bit (4).
I'm just assuming the bit 4 is the "route to SP" bit -- it fixes the
SP-based keyboard for me and defines
ICU_INT_ROUTE_SP_IRQ to be 1 << 4. When asked for a data sheet, Marvell
was not helpful.
Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
---
Changes since v2:
- Correct subsystem maintainers on Cc (irqchip)
Changes since v1:
- Adjusted wording & ack from Pavel
drivers/irqchip/irq-mmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c
index 25f32e1d7764..1ed38f9f1d0a 100644
--- a/drivers/irqchip/irq-mmp.c
+++ b/drivers/irqchip/irq-mmp.c
@@ -190,7 +190,7 @@ static const struct mmp_intc_conf mmp_conf = {
static const struct mmp_intc_conf mmp2_conf = {
.conf_enable= 0x20,
.conf_disable = 0x0,
- .conf_mask = 0x7f,
+ .conf_mask = 0x60,
};
static void __exception_irq_entry mmp_handle_irq(struct pt_regs *regs)
--
2.19.2
Re: [RFC PATCH 1/2] mm: swap: check if swap backing device is congested or not
On 12/18/18 9:56 PM, Yang Shi wrote: > > > On 12/18/18 4:16 PM, Tim Chen wrote: >> On 12/18/18 3:43 PM, Yang Shi wrote: >>> >>> On 12/18/18 11:29 AM, Tim Chen wrote: On 12/17/18 10:52 PM, Yang Shi wrote: > diff --git a/mm/swap_state.c b/mm/swap_state.c > index fd2f21e..7cc3c29 100644 > --- a/mm/swap_state.c > +++ b/mm/swap_state.c > @@ -538,11 +538,15 @@ struct page *swap_cluster_readahead(swp_entry_t > entry, gfp_t gfp_mask, > bool do_poll = true, page_allocated; > struct vm_area_struct *vma = vmf->vma; > unsigned long addr = vmf->address; > + struct inode *inode = si->swap_file->f_mapping->host; > mask = swapin_nr_pages(offset) - 1; > if (!mask) > goto skip; > Shmem will also be using this function and I don't think the inode_read_congested logic is relevant for that case. >>> IMHO, shmem is also relevant. As long as it is trying to readahead from >>> swap, it should check if the underlying device is busy or not regardless of >>> shmem or anon page. >>> >> I don't think your dereference inode = si->swap_file->f_mapping->host >> is always safe. You should do it only when (si->flags & SWP_FS) is true. > > Do you mean it is not safe for swap partition? The f_mapping may not be instantiated. It is only done for SWP_FS. Tim
Re: RT-Kernel boot stalls because of change in fs/dcache.c
On 19.12.18 14:46, Frieder Schrempf wrote: > Hi Sebastian, > > On 19.12.18 12:36, Sebastian Andrzej Siewior wrote: >> On 2018-12-19 07:50:17 [+], Schrempf Frieder wrote: >>> + linux-rt-users >>> >>> On 17.12.18 11:42, Frieder Schrempf wrote: Hi, I have tried to boot a 4.14-Kernel with the RT-patches and PREEMPT_RT_FULL on an i.MX6UL board. Unfortunately the boot stalls at some point and never finishes. I did some bisecting and found out, that reverting this change: [1], makes the board boot correctly. Can anyone help to come up with a proper fix for this? >> >> can you check if the hashtable is initialized twice? > > I'm not sure how to check, but I guess you are on the right track. I can > leave the init loop for dentry_hashtable in place and remove the one for > in_lookup_hashtable in vfs_caches_init_early() and this also makes the > board boot. > > Could it be, that the initializing for dentry_hashtable and > in_lookup_hashtable somehow interfere? So the source of the issue turned out to be completely unrelated to this. Although it seems like enabling PREEMPT_RT_FULL triggered the problem in my case. The lockup of the kernel was caused by the SNVS RTC driver. Pulling in this patch: [1], solved the problem. As this patch fixes a real bug I sent a request for it to be backported to the stable releases. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cd7f3a249dbed2858e6c2f30e5be7f1f7a709ee2 [1]: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/commit/?h=v4.14-rt=56684d21f7f8341f7a5ed1433714112f49294590 >> >> Sebastian >>
Re: [PATCH 4.19 00/44] 4.19.11-stable review
On Tue, Dec 18, 2018 at 05:39:12PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.19.11 release. > There are 44 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Dec 20 16:39:02 UTC 2018. > Anything received after that time might be too late. > Build results: total: 155 pass: 155 fail: 0 Qemu test results: total: 338 pass: 338 fail: 0 Details are available at https://kerneltests.org/builders/. Guenter
Re: [PATCH 01/10] i2c: add suspended flag and accessors for i2c adapters
On Wed, Dec 19, 2018 at 05:48:17PM +0100, Wolfram Sang wrote:
> +static inline void i2c_mark_adapter_suspended(struct i2c_adapter *adap)
> +{
> + i2c_lock_bus(adap, I2C_LOCK_ROOT_ADAPTER);
> + set_bit(I2C_ALF_IS_SUSPENDED, >locked_flags);
> + i2c_unlock_bus(adap, I2C_LOCK_ROOT_ADAPTER);
> +}
This looks like a duplication of the is_suspended flag in struct dev_pm_info.
Any reason why you can't use that? If so, it would be good to document the
reason in the commit message.
If the point is to constrain refusal of transfers in suspended state to
certain drivers, those drivers could opt in to that functionality by
setting a flag, and the i2c core could then gate refusal based on
that flag and the is_suspended flag in struct dev_pm_info.
Also, why is it necessary to take a lock to perform an atomic bitop?
(Sorry if that's a dumb question, seems non-obvious to me.)
Thanks,
Lukas
Re: [PATCH] kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled
On Wed, Dec 19, 2018 at 05:58:53PM +0100, Jiri Kosina wrote: > On Wed, 19 Dec 2018, Josh Poimboeuf wrote: > > > This option only makes sense for source-based patch generation, so isn't > > it a bit premature to make this change without proper source-based patch > > tooling? > > The reality is though that before the full-fledged patch tooling exists, > people are actually already writing livepatches by hand, so this option is > useful for them. Fair enough. Though, upstream, almost everybody seems to use kpatch-build, for which this patch doesn't help. And people will continue to do so until we have decent source-based tooling. Will the klp-convert patches be revived soon? -- Josh
[PATCH 1/3] dt-bindings: ASoC: xlnx,audio-formatter: Document audio formatter bindings
Added documentation for audio formatter IP core DT bindings.
Signed-off-by: Maruthi Srinivas Bayyavarapu
---
.../bindings/sound/xlnx,audio-formatter.txt| 29 ++
1 file changed, 29 insertions(+)
create mode 100644
Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt
diff --git a/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt
b/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt
new file mode 100644
index 000..cbc93c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt
@@ -0,0 +1,29 @@
+Device-Tree bindings for Xilinx PL audio formatter
+
+The IP core supports DMA, data formatting(AES<->PCM conversion)
+of audio samples.
+
+Required properties:
+ - compatible: "xlnx,audio-formatter-1.0"
+ - interrupt-names: Names specified to list of interrupts in same
+ order mentioned under "interrupts".
+ List of supported interrupt names are:
+ "irq_mm2s" : interrupt from MM2S block
+ "irq_s2mm" : interrupt from S2MM block
+ - interrupts-parent: Phandle for interrupt controller.
+ - interrupts: List of Interrupt numbers.
+ - reg: Base address and size of the IP core instance.
+ - clock-names: List of input clocks.
+ Required elements: "s_axi_lite_aclk", "aud_mclk"
+ - clocks: Input clock specifier. Refer to common clock bindings.
+
+Example:
+ audio_ss_0_audio_formatter_0: audio_formatter@8001 {
+ compatible = "xlnx,audio-formatter-1.0";
+ interrupt-names = "irq_mm2s", "irq_s2mm";
+ interrupt-parent = <>;
+ interrupts = <0 104 4>, <0 105 4>;
+ reg = <0x0 0x8001 0x0 0x1000>;
+ clock-names = "s_axi_lite_aclk", "aud_mclk";
+ clocks = < 71>, <_wiz_1 0>;
+ };
--
2.7.4
[PATCH 2/3] ASoC: xlnx: add pcm formatter platform driver
The audio formatter PL IP supports DMA of two streams -
mm2s and s2mm for playback and capture respectively. Apart from
DMA, IP also does conversions like PCM to AES and viceversa.
This patch adds DMA component driver for the IP.
Signed-off-by: Maruthi Srinivas Bayyavarapu
---
sound/soc/xilinx/xlnx_formatter_pcm.c | 561 ++
1 file changed, 561 insertions(+)
create mode 100644 sound/soc/xilinx/xlnx_formatter_pcm.c
diff --git a/sound/soc/xilinx/xlnx_formatter_pcm.c
b/sound/soc/xilinx/xlnx_formatter_pcm.c
new file mode 100644
index 000..a6da5ad
--- /dev/null
+++ b/sound/soc/xilinx/xlnx_formatter_pcm.c
@@ -0,0 +1,561 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Xilinx ASoC audio formatter support
+//
+// Copyright (C) 2018 Xilinx, Inc.
+//
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define DRV_NAME "xlnx_formatter_pcm"
+
+#define XLNX_S2MM_OFFSET 0
+#define XLNX_MM2S_OFFSET 0x100
+
+#define XLNX_AUD_CORE_CONFIG 0x4
+#define XLNX_AUD_CTRL 0x10
+#define XLNX_AUD_STS 0x14
+
+#define AUD_CTRL_RESET_MASKBIT(1)
+#define AUD_CFG_MM2S_MASK BIT(15)
+#define AUD_CFG_S2MM_MASK BIT(31)
+
+#define XLNX_AUD_FS_MULTIPLIER 0x18
+#define XLNX_AUD_PERIOD_CONFIG 0x1C
+#define XLNX_AUD_BUFF_ADDR_LSB 0x20
+#define XLNX_AUD_BUFF_ADDR_MSB 0x24
+#define XLNX_AUD_XFER_COUNT0x28
+#define XLNX_AUD_CH_STS_START 0x2C
+#define XLNX_BYTES_PER_CH 0x44
+
+#define AUD_STS_IOC_IRQ_MASK BIT(31)
+#define AUD_STS_CH_STS_MASKBIT(29)
+#define AUD_CTRL_IOC_IRQ_MASK BIT(13)
+#define AUD_CTRL_TOUT_IRQ_MASK BIT(14)
+#define AUD_CTRL_DMA_EN_MASK BIT(0)
+
+#define CFG_MM2S_CH_MASK GENMASK(11, 8)
+#define CFG_MM2S_CH_SHIFT 8
+#define CFG_MM2S_XFER_MASK GENMASK(14, 13)
+#define CFG_MM2S_XFER_SHIFT13
+#define CFG_MM2S_PKG_MASK BIT(12)
+
+#define CFG_S2MM_CH_MASK GENMASK(27, 24)
+#define CFG_S2MM_CH_SHIFT 24
+#define CFG_S2MM_XFER_MASK GENMASK(30, 29)
+#define CFG_S2MM_XFER_SHIFT29
+#define CFG_S2MM_PKG_MASK BIT(28)
+
+#define AUD_CTRL_DATA_WIDTH_SHIFT 16
+#define AUD_CTRL_ACTIVE_CH_SHIFT 19
+#define PERIOD_CFG_PERIODS_SHIFT 16
+
+#define PERIODS_MIN2
+#define PERIODS_MAX6
+#define PERIOD_BYTES_MIN 192
+#define PERIOD_BYTES_MAX (50 * 1024)
+
+enum bit_depth {
+ BIT_DEPTH_8,
+ BIT_DEPTH_16,
+ BIT_DEPTH_20,
+ BIT_DEPTH_24,
+ BIT_DEPTH_32,
+};
+
+struct xlnx_pcm_drv_data {
+ void __iomem *mmio;
+ bool s2mm_presence;
+ bool mm2s_presence;
+ unsigned int s2mm_irq;
+ unsigned int mm2s_irq;
+ struct snd_pcm_substream *play_stream;
+ struct snd_pcm_substream *capture_stream;
+ struct clk *axi_clk;
+};
+
+/*
+ * struct xlnx_pcm_stream_param - stream configuration
+ * @mmio: base address offset
+ * @interleaved: audio channels arrangement in buffer
+ * @xfer_mode: data formatting mode during transfer
+ * @ch_limit: Maximum channels supported
+ * @buffer_size: stream ring buffer size
+ */
+struct xlnx_pcm_stream_param {
+ void __iomem *mmio;
+ bool interleaved;
+ u32 xfer_mode;
+ u32 ch_limit;
+ u64 buffer_size;
+};
+
+static const struct snd_pcm_hardware xlnx_pcm_hardware = {
+ .info = SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER |
+ SNDRV_PCM_INFO_BATCH | SNDRV_PCM_INFO_PAUSE |
+ SNDRV_PCM_INFO_RESUME,
+ .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE |
+ SNDRV_PCM_FMTBIT_S24_LE,
+ .channels_min = 2,
+ .channels_max = 2,
+ .rates = SNDRV_PCM_RATE_8000_192000,
+ .rate_min = 8000,
+ .rate_max = 192000,
+ .buffer_bytes_max = PERIODS_MAX * PERIOD_BYTES_MAX,
+ .period_bytes_min = PERIOD_BYTES_MIN,
+ .period_bytes_max = PERIOD_BYTES_MAX,
+ .periods_min = PERIODS_MIN,
+ .periods_max = PERIODS_MAX,
+};
+
+static int xlnx_formatter_pcm_reset(void __iomem *mmio_base)
+{
+ u32 val, retries = 0;
+
+ val = readl(mmio_base + XLNX_AUD_CTRL);
+ val |= AUD_CTRL_RESET_MASK;
+ writel(val, mmio_base + XLNX_AUD_CTRL);
+
+ val = readl(mmio_base + XLNX_AUD_CTRL);
+ /* Poll for maximum timeout of approximately 100ms (1 * 100)*/
+ while ((val & AUD_CTRL_RESET_MASK) && (retries < 100)) {
+ mdelay(1);
+ retries++;
+ val = readl(mmio_base + XLNX_AUD_CTRL);
+ }
+ if (val & AUD_CTRL_RESET_MASK)
+ return -ENODEV;
+
+ return 0;
+}
+
+static void xlnx_formatter_disable_irqs(void __iomem *mmio_base, int stream)
+{
+ u32 val;
+
+ val = readl(mmio_base + XLNX_AUD_CTRL);
+ val &= ~AUD_CTRL_IOC_IRQ_MASK;
+ if (stream == SNDRV_PCM_STREAM_CAPTURE)
+ val &= ~AUD_CTRL_TOUT_IRQ_MASK;
+
+ writel(val, mmio_base + XLNX_AUD_CTRL);
+}
+
+static
[PATCH 3/3] ASoC: xlnx: enable audio formatter driver build
Enable audio formatter driver build. Signed-off-by: Maruthi Srinivas Bayyavarapu --- sound/soc/xilinx/Kconfig | 7 +++ sound/soc/xilinx/Makefile | 2 ++ 2 files changed, 9 insertions(+) diff --git a/sound/soc/xilinx/Kconfig b/sound/soc/xilinx/Kconfig index 723a583..ac48d6a 100644 --- a/sound/soc/xilinx/Kconfig +++ b/sound/soc/xilinx/Kconfig @@ -6,3 +6,10 @@ config SND_SOC_XILINX_I2S mode, IP receives audio in AES format, extracts PCM and sends PCM data. In receiver mode, IP receives PCM audio and encapsulates PCM in AES format and sends AES data. + +config SND_SOC_XILINX_AUDIO_FORMATTER +tristate "Audio support for the the Xilinx audio formatter" +help + Select this option to enable Xilinx audio formatter + support. This provides DMA platform device support for + audio functionality. diff --git a/sound/soc/xilinx/Makefile b/sound/soc/xilinx/Makefile index 6c1209b..432693b 100644 --- a/sound/soc/xilinx/Makefile +++ b/sound/soc/xilinx/Makefile @@ -1,2 +1,4 @@ snd-soc-xlnx-i2s-objs := xlnx_i2s.o obj-$(CONFIG_SND_SOC_XILINX_I2S) += snd-soc-xlnx-i2s.o +snd-soc-xlnx-formatter-pcm-objs := xlnx_formatter_pcm.o +obj-$(CONFIG_SND_SOC_XILINX_AUDIO_FORMATTER) += snd-soc-xlnx-formatter-pcm.o -- 2.7.4
Re: [PATCH] dt-bindings: marvell,mmp2: fix a typo in bindings doc
On Mon, Dec 03, 2018 at 12:47:48PM +0100, Lubomir Rintel wrote: > A trivial one, but it's annoying that copy & paste of the link > doesn't work. > > Signed-off-by: Lubomir Rintel > --- > Documentation/devicetree/bindings/clock/marvell,mmp2.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/clock/marvell,mmp2.txt > b/Documentation/devicetree/bindings/clock/marvell,mmp2.txt > index af376a01f2b7..b0447d9896bc 100644 > --- a/Documentation/devicetree/bindings/clock/marvell,mmp2.txt > +++ b/Documentation/devicetree/bindings/clock/marvell,mmp2.txt > @@ -18,4 +18,4 @@ Required Properties: > Each clock is assigned an identifier and client nodes use this identifier > to specify the clock which they consume. > > -All these identifier could be found in . > +All these identifier could be found in . Really, should be: identifiers can be > -- > 2.19.1 >
[PATCH 0/3] add Xilinx audio formatter driver
Audio formatter IP supports two streaming interfaces - MM2S for playback and S2MM for capture. The driver enables DMA functionality for both the interfaces. Patchset includes devicetree bindings documentation, driver and build enablement. Maruthi Srinivas Bayyavarapu (3): dt-bindings: ASoC: xlnx,audio-formatter: Document audio formatter bindings ASoC: xlnx: add pcm formatter platform driver ASoC: xlnx: enable audio formatter driver build .../bindings/sound/xlnx,audio-formatter.txt| 29 ++ sound/soc/xilinx/Kconfig | 7 + sound/soc/xilinx/Makefile | 2 + sound/soc/xilinx/xlnx_formatter_pcm.c | 561 + 4 files changed, 599 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt create mode 100644 sound/soc/xilinx/xlnx_formatter_pcm.c -- 2.7.4
Re: [PATCH 05/16] remoteproc/pru: Add pru-specific debugfs support
* Mark Brown [181219 17:07]: > On Wed, Dec 19, 2018 at 04:48:52PM +0100, David Lechner wrote: > > On 12/19/18 4:43 PM, Roger Quadros wrote: > > > > Did I do something wrong or we just need to enhance regmap_debugfs.c? > > > Do you assign the name field in pru_regmap_config and > > pru_debug_regmap_config? > > Yeah, you'll at least need to override the name since the default is to > use the name of the device and that'll result in two duplicates. Also combining IO regions often has a serious issue that the separate IO regions may not be in the same device (or same interconnect target module). This means that flushing a posted write with a read-back for an IO region will only flush it for a single device and not the other(s). And this leads into hard to find bugs :) Regards, Tony
Re: [PATCH] dt-bindings: mrvl,intc: fix a trivial typo
On Mon, Dec 03, 2018 at 12:47:10PM +0100, Lubomir Rintel wrote: > s/whold/whole/. > > Signed-off-by: Lubomir Rintel > --- > .../devicetree/bindings/interrupt-controller/mrvl,intc.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks.
[GIT PULL] dlm updates for 4.21
Hi Linus, Please pull dlm updates from tag: git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm.git dlm-4.21 This set is entirely trivial fixes, mainly around correct cleanup on error paths and improved error checks. One patch adds scheduling in a potentially long recovery loop. Thanks, Dave Bob Peterson (1): dlm: Don't swamp the CPU with callbacks queued during recovery David Teigland (2): dlm: fix missing idr_destroy for recover_idr dlm: fix invalid cluster name warning Denis V. Lunev (1): dlm: fix possible call to kfree() for non-initialized pointer Thomas Meyer (1): dlm: NULL check before some freeing functions is not needed Tycho Andersen (3): dlm: fix invalid free dlm: don't allow zero length names dlm: don't leak kernel pointer to userspace Vasily Averin (4): dlm: fixed memory leaks after failed ls_remove_names allocation dlm: possible memory leak on error path in create_lkb() dlm: lost put_lkb on error path in receive_convert() and receive_unlock() dlm: memory leaks on error path in dlm_user_request() Wen Yang (1): dlm: NULL check before kmem_cache_destroy is not needed fs/dlm/ast.c | 10 ++ fs/dlm/lock.c | 17 ++--- fs/dlm/lockspace.c | 9 - fs/dlm/member.c| 7 --- fs/dlm/memory.c| 9 +++-- fs/dlm/user.c | 5 +++-- 6 files changed, 34 insertions(+), 23 deletions(-)
Re: [PATCH 7/9] dt-bindings: input: touchscreen: goodix: Add GT5663 compatible
On Mon, Dec 03, 2018 at 03:45:45PM +0530, Jagan Teki wrote:
> GT5663 is capacitive touch controller with customized smart wakeup gestures,
> the existing goodix driver will work by phandle vcc-supply regulator.
>
> So, document compatible and example node for the same.
>
> Signed-off-by: Jagan Teki
> ---
> .../bindings/input/touchscreen/goodix.txt | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> index 604766e347ce..1898d3dde8e1 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> @@ -3,6 +3,7 @@ Device tree bindings for Goodix GT9xx series touchscreen
> controller
> Required properties:
>
> - compatible: Should be "goodix,gt1151"
> + or "goodix,gt5663"
>or "goodix,gt911"
>or "goodix,gt9110"
>or "goodix,gt912"
> @@ -42,3 +43,15 @@ Example:
>
> /* ... */
> };
> +
> + touchscreen@5d {
> + compatible = "goodix,gt5663";
Just a new compatible doesn't warrant a new example.
> + reg = <0x5d>;
> + vcc-supply = <_ldo_io0>;
> + interrupt-parent = <>;
> + interrupts = <7 4 IRQ_TYPE_EDGE_FALLING>;
> + irq-gpios = < 7 4 GPIO_ACTIVE_HIGH>;/* CTP-INT: PH4
> */
> + reset-gpios = < 7 8 GPIO_ACTIVE_HIGH>; /* CTP-RST: PH8
> */
> + touchscreen-inverted-x;
> + touchscreen-inverted-y;
> + };
> --
> 2.18.0.321.gffc6fa0e3
>
[PATCH v2] regulator: palmas: fix a missing check of return value
If palmas_smps_read() fails, we should not use the read data in "reg"
which may contain random value. The fix inserts a check for the return
value of palmas_smps_read(): If it fails, we return the error code
upstream and stop using "reg".
Signed-off-by: Kangjie Lu
---
drivers/regulator/palmas-regulator.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index bb5ab7d78895..c2cc392a27d4 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -443,13 +443,16 @@ static int palmas_ldo_write(struct palmas *palmas,
unsigned int reg,
static int palmas_set_mode_smps(struct regulator_dev *dev, unsigned int mode)
{
int id = rdev_get_id(dev);
+ int ret;
struct palmas_pmic *pmic = rdev_get_drvdata(dev);
struct palmas_pmic_driver_data *ddata = pmic->palmas->pmic_ddata;
struct palmas_regs_info *rinfo = >palmas_regs_info[id];
unsigned int reg;
bool rail_enable = true;
- palmas_smps_read(pmic->palmas, rinfo->ctrl_addr, );
+ ret = palmas_smps_read(pmic->palmas, rinfo->ctrl_addr, );
+ if (ret)
+ return ret;
reg &= ~PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
--
2.17.2 (Apple Git-113)
Re: [PATCH v3 0/5] alpha: system call table generation support
On Wed, Dec 19, 2018 at 4:59 PM Matt Turner wrote: > On Fri, Dec 14, 2018 at 10:18 AM Firoz Khan wrote: > > On Tue, 13 Nov 2018 at 15:02, Firoz Khan wrote: > > > > Could someone review this patch series and queue it for 4.21 > > through alpha tree would be great. > > Thank you! I'll take a look. Hi Matt, I see that you merged the changes a while ago into git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha#for-linus This all seems fine, but they never showed up in linux-next, which his what had both Firoz and me confused. Is that intentional, or should it be added there? Added Stephen to Cc here in case you want it added. Arnd
Re: [PATCH 05/16] remoteproc/pru: Add pru-specific debugfs support
On Wed, Dec 19, 2018 at 04:48:52PM +0100, David Lechner wrote: > On 12/19/18 4:43 PM, Roger Quadros wrote: > > Did I do something wrong or we just need to enhance regmap_debugfs.c? > Do you assign the name field in pru_regmap_config and > pru_debug_regmap_config? Yeah, you'll at least need to override the name since the default is to use the name of the device and that'll result in two duplicates. signature.asc Description: PGP signature
[PATCH net v4] net: mvpp2: fix the phylink mode validation
The mvpp2_phylink_validate() sets all modes that are supported by a
given PPv2 port. An mistake made the 1baseT_Full mode being
advertised in some cases when a port wasn't configured to perform at
10G. This patch fixes this.
Fixes: d97c9f4ab000 ("net: mvpp2: 1000baseX support")
Reported-by: Russell King
Signed-off-by: Antoine Tenart
---
Since v3:
- Rebase on top of net/master.
Since v2, v1:
- N/A.
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 88aa488054a8..f1dab0b55769 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4406,6 +4406,7 @@ static void mvpp2_phylink_validate(struct net_device *dev,
case PHY_INTERFACE_MODE_XAUI:
case PHY_INTERFACE_MODE_NA:
if (port->gop_id == 0) {
+ phylink_set(mask, 1baseT_Full);
phylink_set(mask, 1baseCR_Full);
phylink_set(mask, 1baseSR_Full);
phylink_set(mask, 1baseLR_Full);
@@ -4423,7 +4424,6 @@ static void mvpp2_phylink_validate(struct net_device *dev,
phylink_set(mask, 10baseT_Full);
phylink_set(mask, 100baseT_Half);
phylink_set(mask, 100baseT_Full);
- phylink_set(mask, 1baseT_Full);
/* Fall-through */
case PHY_INTERFACE_MODE_1000BASEX:
case PHY_INTERFACE_MODE_2500BASEX:
--
2.19.2
Re: [PATCH 1/2] ARC: show_regs: avoid page allocator
Hi Vineet,
Just curious: isn't that enough to use GFP_NOWAIT instead
of GFP_KERNEL when we allocate page in show_regs()?
As I can see x86 use print_vma_addr() in their show_signal_msg()
function which allocate page with __get_free_page(GFP_NOWAIT);
On Tue, 2018-12-18 at 10:53 -0800, Vineet Gupta wrote:
> Use on-stack smaller buffers instead of dynamic pages.
>
> The motivation for this change was to address lockdep splat when
> signal handling code calls show_regs (with preemption disabled) and
> ARC show_regs calls into sleepable page allocator.
>
> > potentially unexpected fatal signal 11.
> > BUG: sleeping function called from invalid context at
> > ../mm/page_alloc.c:4317
> > in_atomic(): 1, irqs_disabled(): 0, pid: 57, name: segv
> > no locks held by segv/57.
> > Preemption disabled at:
> > [<8182f17e>] get_signal+0x4a6/0x7c4
> > CPU: 0 PID: 57 Comm: segv Not tainted 4.17.0+ #23
> >
> > Stack Trace:
> > arc_unwind_core.constprop.1+0xd0/0xf4
> > __might_sleep+0x1f6/0x234
> > __get_free_pages+0x174/0xca0
> > show_regs+0x22/0x330
> > get_signal+0x4ac/0x7c4 # print_fatal_signals() -> preempt_disable()
> > do_signal+0x30/0x224
> > resume_user_mode_begin+0x90/0xd8
>
> Despite this, lockdep still barfs (see next change), but this patch
> still has merit as in we use smaller/localized buffers now and there's
> less instructoh trace to sift thru when debugging pesky issues.
>
> Signed-off-by: Vineet Gupta
> ---
> arch/arc/kernel/troubleshoot.c | 22 +-
> 1 file changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arc/kernel/troubleshoot.c b/arch/arc/kernel/troubleshoot.c
> index e8d9fb452346..2885bec71fb8 100644
> --- a/arch/arc/kernel/troubleshoot.c
> +++ b/arch/arc/kernel/troubleshoot.c
> @@ -58,11 +58,12 @@ static void show_callee_regs(struct callee_regs *cregs)
> print_reg_file(&(cregs->r13), 13);
> }
>
> -static void print_task_path_n_nm(struct task_struct *tsk, char *buf)
> +static void print_task_path_n_nm(struct task_struct *tsk)
> {
> char *path_nm = NULL;
> struct mm_struct *mm;
> struct file *exe_file;
> + char buf[256];
>
> mm = get_task_mm(tsk);
> if (!mm)
> @@ -80,10 +81,9 @@ static void print_task_path_n_nm(struct task_struct *tsk,
> char *buf)
> pr_info("Path: %s\n", !IS_ERR(path_nm) ? path_nm : "?");
> }
>
> -static void show_faulting_vma(unsigned long address, char *buf)
> +static void show_faulting_vma(unsigned long address)
> {
> struct vm_area_struct *vma;
> - char *nm = buf;
> struct mm_struct *active_mm = current->active_mm;
>
> /* can't use print_vma_addr() yet as it doesn't check for
> @@ -96,8 +96,11 @@ static void show_faulting_vma(unsigned long address, char
> *buf)
>* if the container VMA is not found
>*/
> if (vma && (vma->vm_start <= address)) {
> + char buf[256];
> + char *nm = "?";
> +
> if (vma->vm_file) {
> - nm = file_path(vma->vm_file, buf, PAGE_SIZE - 1);
> + nm = file_path(vma->vm_file, buf, 256-1);
> if (IS_ERR(nm))
> nm = "?";
> }
> @@ -173,13 +176,8 @@ void show_regs(struct pt_regs *regs)
> {
> struct task_struct *tsk = current;
> struct callee_regs *cregs;
> - char *buf;
> -
> - buf = (char *)__get_free_page(GFP_KERNEL);
> - if (!buf)
> - return;
>
> - print_task_path_n_nm(tsk, buf);
> + print_task_path_n_nm(tsk);
> show_regs_print_info(KERN_INFO);
>
> show_ecr_verbose(regs);
> @@ -189,7 +187,7 @@ void show_regs(struct pt_regs *regs)
> (void *)regs->blink, (void *)regs->ret);
>
> if (user_mode(regs))
> - show_faulting_vma(regs->ret, buf); /* faulting code, not data */
> + show_faulting_vma(regs->ret); /* faulting code, not data */
>
> pr_info("[STAT32]: 0x%08lx", regs->status32);
>
> @@ -221,8 +219,6 @@ void show_regs(struct pt_regs *regs)
> cregs = (struct callee_regs *)current->thread.callee_reg;
> if (cregs)
> show_callee_regs(cregs);
> -
> - free_page((unsigned long)buf);
> }
>
> void show_kernel_fault_diag(const char *str, struct pt_regs *regs,
--
Eugeniy Paltsev
Re: [PATCH v7 11/25] arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking
Hi Ard,
On 14/12/2018 16:40, Julien Thierry wrote:
>
>
> On 14/12/2018 15:49, Ard Biesheuvel wrote:
>> On Fri, 14 Dec 2018 at 16:23, Julien Thierry wrote:
>>>
>>> Hi,
>>>
>>> On 13/12/2018 15:03, Julien Thierry wrote:
Argh, not as simple as I had expected.
Turns out include/linux/efi.h does not include asm/efi.h (including it
at the beginning of the file breaks the build because asm/efi.h misses
the efi type definitions.
So a thing like:
#ifndef efi_get_irqflags
#define efi_get_irqflags(flags) local_save_flags(flags)
#endif
in include/linux/efi.h cannot be overridden.
Either I would need to introduce the definitions arm, arm64 and x86 (I
don't think there are other arch supporting EFI right now) or I'll need
to come up with another solution.
>>>
>>
>> It might be a bit nasty, but can we put the #ifndef above in
>> runtime-wrappers.c directly? The only reference in linux/efi.h is a
>> macro, so that shouldn't matter afaict.
>>
>
> Sadly, in arch/x86/platform/uv/bios_uv.c, uv_bios_call() has a reference
> to the macro efi_call_virt_pointer() which wouldn't be able to see the
> definition in runtime-wrappers.c
>
> Otherwise, we could've moved efi_call_virt_pointer() and
> __efi_call_virt_pointer in runtime-wrappers.c and things would not have
> been as nasty.
>
> But no, I don't think we can do that without breaking some x86 build :( .
>
Since the above does not work, would the solution with the
HAVE_GENERIC_EFI_FLAGS below be acceptable to you? Or would you rather I
defined helpers in for all arm/arm64/x86?
Or neither and I shall find another way?
Thanks,
Julien
>>
>>> Would the following patch be acceptable for the EFI generic side?
>>>
>>> If it is, I'll add it to the next iteration of this series.
>>>
>>> Thanks,
>>>
>>> Julien
>>>
>>> -->
>>>
>>> From 7acaa8e17142263addafb18ae10bd5d2d49cfb39 Mon Sep 17 00:00:00 2001
>>> From: Julien Thierry
>>> Date: Fri, 14 Dec 2018 14:20:13 +
>>> Subject: [RFC] efi: Let architectures decide the flags that should be
>>> saved/restored
>>>
>>> Currently, irqflags are saved before calling runtime services and
>>> checked for mismatch on return.
>>>
>>> Add a config option to let architectures define a set of flags to be
>>> checked and (if needed) restored when coming back from runtime services.
>>> This allows to use check flags that are not necesarly related to
>>> irqflags.
>>>
>>> Signed-off-by: Julien Thierry
>>> ---
>>> arch/Kconfig| 8
>>> drivers/firmware/efi/runtime-wrappers.c | 4 ++--
>>> include/linux/efi.h | 12 ++--
>>> 3 files changed, 20 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/Kconfig b/arch/Kconfig
>>> index e1e540f..cbec325 100644
>>> --- a/arch/Kconfig
>>> +++ b/arch/Kconfig
>>> @@ -695,6 +695,14 @@ config HAVE_ARCH_HASH
>>> file which provides platform-specific implementations of some
>>> functions in or fs/namei.c.
>>>
>>> +config HAVE_GENERIC_EFI_FLAGS
>>> + bool
>>> + default n
>>> + help
>>> + Architecture defines a set of flags that EFI runtime services
>>> + should take care to restore when returning to the OS.
>>> + If this is not set, the set of flags defaults to the arch
>>> irqflags.
>>> +
>>> config ISA_BUS_API
>>> def_bool ISA
>>>
>>> diff --git a/drivers/firmware/efi/runtime-wrappers.c
>>> b/drivers/firmware/efi/runtime-wrappers.c
>>> index 8903b9c..6dafa04 100644
>>> --- a/drivers/firmware/efi/runtime-wrappers.c
>>> +++ b/drivers/firmware/efi/runtime-wrappers.c
>>> @@ -93,7 +93,7 @@ void efi_call_virt_check_flags(unsigned long flags, const
>>> char *call)
>>> {
>>> unsigned long cur_flags, mismatch;
>>>
>>> - local_save_flags(cur_flags);
>>> + efi_save_flags(cur_flags);
>>>
>>> mismatch = flags ^ cur_flags;
>>> if (!WARN_ON_ONCE(mismatch & ARCH_EFI_IRQ_FLAGS_MASK))
>>> @@ -102,7 +102,7 @@ void efi_call_virt_check_flags(unsigned long flags,
>>> const char *call)
>>> add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_NOW_UNRELIABLE);
>>> pr_err_ratelimited(FW_BUG "IRQ flags corrupted (0x%08lx=>0x%08lx)
>>> by EFI %s\n",
>>>flags, cur_flags, call);
>>> - local_irq_restore(flags);
>>> + efi_restore_flags(flags);
>>> }
>>>
>>> /*
>>> diff --git a/include/linux/efi.h b/include/linux/efi.h
>>> index 100ce4a..41c110a 100644
>>> --- a/include/linux/efi.h
>>> +++ b/include/linux/efi.h
>>> @@ -1594,6 +1594,14 @@ enum efi_secureboot_mode {
>>>
>>> void efi_retrieve_tpm2_eventlog(efi_system_table_t *sys_table);
>>>
>>> +#ifdef CONFIG_HAVE_GENERIC_EFI_FLAGS
>>> +#define efi_save_flags(state_flags)arch_efi_save_flags(state_flags)
>>> +#define efi_restore_flags(state_flags) arch_efi_restore_flags(state_flags)
>>> +#else
>>> +#define efi_save_flags(state_flags)
Re: ensure dma_alloc_coherent always returns zeroed memory
FYI, I've picked this up for dma-mapping for-next now.
Re: [PATCH] kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled
On Wed, 19 Dec 2018, Josh Poimboeuf wrote: > This option only makes sense for source-based patch generation, so isn't > it a bit premature to make this change without proper source-based patch > tooling? The reality is though that before the full-fledged patch tooling exists, people are actually already writing livepatches by hand, so this option is useful for them. > Also the commit message needs an analysis of the performance impacts. Agreed. Especially as it's expected (*) to be completely in the noise particularly for the kernel, it'd be good to have that documented in the changelog. (*) actually measured already for some subset of the IPA optimizations Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH v2 2/2] kgdb/treewide: constify struct kgdb_arch arch_kgdb_ops
On Thu, Dec 06, 2018 at 08:07:40PM +, Christophe Leroy wrote:
> checkpatch.pl reports the following:
>
> WARNING: struct kgdb_arch should normally be const
> #28: FILE: arch/mips/kernel/kgdb.c:397:
> +struct kgdb_arch arch_kgdb_ops = {
>
> This report makes sense, as all other ops struct, this
> one should also be const. This patch does the change.
>
> Cc: Vineet Gupta
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Yoshinori Sato
> Cc: Richard Kuo
> Cc: Michal Simek
> Cc: Ralf Baechle
> Cc: Paul Burton
> Cc: James Hogan
> Cc: Ley Foon Tan
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Rich Felker
> Cc: "David S. Miller"
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: x...@kernel.org
> Acked-by: Daniel Thompson
> Acked-by: Paul Burton
> Signed-off-by: Christophe Leroy
I've not heard any objections from the arch/ maintainers so...
Applied! Thanks.
> -
> ---
> v2: Added CCs to all maintainers/supporters identified by get_maintainer.pl
> and Acks from Daniel and Paul.
>
> arch/arc/kernel/kgdb.c| 2 +-
> arch/arm/kernel/kgdb.c| 2 +-
> arch/arm64/kernel/kgdb.c | 2 +-
> arch/h8300/kernel/kgdb.c | 2 +-
> arch/hexagon/kernel/kgdb.c| 2 +-
> arch/microblaze/kernel/kgdb.c | 2 +-
> arch/mips/kernel/kgdb.c | 2 +-
> arch/nios2/kernel/kgdb.c | 2 +-
> arch/powerpc/kernel/kgdb.c| 2 +-
> arch/sh/kernel/kgdb.c | 2 +-
> arch/sparc/kernel/kgdb_32.c | 2 +-
> arch/sparc/kernel/kgdb_64.c | 2 +-
> arch/x86/kernel/kgdb.c| 2 +-
> include/linux/kgdb.h | 2 +-
> 14 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
> index 9a3c34af2ae8..bfd04b442e36 100644
> --- a/arch/arc/kernel/kgdb.c
> +++ b/arch/arc/kernel/kgdb.c
> @@ -204,7 +204,7 @@ void kgdb_roundup_cpus(unsigned long flags)
> local_irq_disable();
> }
>
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> /* breakpoint instruction: TRAP_S 0x3 */
> #ifdef CONFIG_CPU_BIG_ENDIAN
> .gdb_bpt_instr = {0x78, 0x7e},
> diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
> index caa0dbe3dc61..21a6d5958955 100644
> --- a/arch/arm/kernel/kgdb.c
> +++ b/arch/arm/kernel/kgdb.c
> @@ -274,7 +274,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> * and we handle the normal undef case within the do_undefinstr
> * handler.
> */
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> #ifndef __ARMEB__
> .gdb_bpt_instr = {0xfe, 0xde, 0xff, 0xe7}
> #else /* ! __ARMEB__ */
> diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> index a20de58061a8..fe1d1f935b90 100644
> --- a/arch/arm64/kernel/kgdb.c
> +++ b/arch/arm64/kernel/kgdb.c
> @@ -357,7 +357,7 @@ void kgdb_arch_exit(void)
> unregister_die_notifier(_notifier);
> }
>
> -struct kgdb_arch arch_kgdb_ops;
> +const struct kgdb_arch arch_kgdb_ops;
>
> int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> {
> diff --git a/arch/h8300/kernel/kgdb.c b/arch/h8300/kernel/kgdb.c
> index 1a1d30cb0609..602e478afbd5 100644
> --- a/arch/h8300/kernel/kgdb.c
> +++ b/arch/h8300/kernel/kgdb.c
> @@ -129,7 +129,7 @@ void kgdb_arch_exit(void)
> /* Nothing to do */
> }
>
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> /* Breakpoint instruction: trapa #2 */
> .gdb_bpt_instr = { 0x57, 0x20 },
> };
> diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
> index 16c24b22d0b2..f1924d483e78 100644
> --- a/arch/hexagon/kernel/kgdb.c
> +++ b/arch/hexagon/kernel/kgdb.c
> @@ -83,7 +83,7 @@ struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = {
> { "syscall_nr", GDB_SIZEOF_REG, offsetof(struct pt_regs, syscall_nr)},
> };
>
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> /* trap0(#0xDB) 0x0cdb0054 */
> .gdb_bpt_instr = {0x54, 0x00, 0xdb, 0x0c},
> };
> diff --git a/arch/microblaze/kernel/kgdb.c b/arch/microblaze/kernel/kgdb.c
> index 6366f69d118e..130cd0f064ce 100644
> --- a/arch/microblaze/kernel/kgdb.c
> +++ b/arch/microblaze/kernel/kgdb.c
> @@ -143,7 +143,7 @@ void kgdb_arch_exit(void)
> /*
> * Global data
> */
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> #ifdef __MICROBLAZEEL__
> .gdb_bpt_instr = {0x18, 0x00, 0x0c, 0xba}, /* brki r16, 0x18 */
> #else
> diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
> index 31eff1bec577..edfdc2ec2d16 100644
> --- a/arch/mips/kernel/kgdb.c
> +++ b/arch/mips/kernel/kgdb.c
> @@ -394,7 +394,7 @@ int kgdb_arch_handle_exception(int vector, int signo, int
> err_code,
> return -1;
> }
>
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> #ifdef CONFIG_CPU_BIG_ENDIAN
> .gdb_bpt_instr = { spec_op <<
Re: [PATCH v2 1/2] mips/kgdb: prepare arch_kgdb_ops for constness
On Thu, Dec 06, 2018 at 08:07:38PM +, Christophe Leroy wrote:
> MIPS is the only architecture modifying arch_kgdb_ops during init.
> This patch makes the init static, so that it can be changed to
> const in following patch, as recommended by checkpatch.pl
>
> Suggested-by: Paul Burton
> Acked-by: Daniel Thompson
> Acked-by: Paul Burton
> Signed-off-by: Christophe Leroy
Applied! Thanks.
> -
> ---
> v2: Added acks from Daniel and Paul.
>
> arch/mips/kernel/kgdb.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
> index eb6c0d582626..31eff1bec577 100644
> --- a/arch/mips/kernel/kgdb.c
> +++ b/arch/mips/kernel/kgdb.c
> @@ -394,18 +394,16 @@ int kgdb_arch_handle_exception(int vector, int signo,
> int err_code,
> return -1;
> }
>
> -struct kgdb_arch arch_kgdb_ops;
> +struct kgdb_arch arch_kgdb_ops = {
> +#ifdef CONFIG_CPU_BIG_ENDIAN
> + .gdb_bpt_instr = { spec_op << 2, 0x00, 0x00, break_op },
> +#else
> + .gdb_bpt_instr = { break_op, 0x00, 0x00, spec_op << 2 },
> +#endif
> +};
>
> int kgdb_arch_init(void)
> {
> - union mips_instruction insn = {
> - .r_format = {
> - .opcode = spec_op,
> - .func = break_op,
> - }
> - };
> - memcpy(arch_kgdb_ops.gdb_bpt_instr, insn.byte, BREAK_INSTR_SIZE);
> -
> register_die_notifier(_notifier);
>
> return 0;
> --
> 2.13.3
>
Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions
On Wed, Dec 19, 2018 at 12:35:40PM +0100, Jan Kara wrote: > On Wed 19-12-18 21:28:25, Dave Chinner wrote: > > On Tue, Dec 18, 2018 at 08:03:29PM -0700, Jason Gunthorpe wrote: > > > On Wed, Dec 19, 2018 at 10:42:54AM +1100, Dave Chinner wrote: > > > > > > > Essentially, what we are talking about is how to handle broken > > > > hardware. I say we should just brun it with napalm and thermite > > > > (i.e. taint the kernel with "unsupportable hardware") and force > > > > wait_for_stable_page() to trigger when there are GUP mappings if > > > > the underlying storage doesn't already require it. > > > > > > If you want to ban O_DIRECT/etc from writing to file backed pages, > > > then just do it. > > > > O_DIRECT IO *isn't the problem*. > > That is not true. O_DIRECT IO is a problem. In some aspects it is > easier than the problem with RDMA but currently O_DIRECT IO can > crash your machine or corrupt data the same way RDMA can. Just the > race window is much smaller. So we have to fix the generic GUP > infrastructure to make O_DIRECT IO work. I agree that fixing RDMA > will likely require even more work like revokable leases or what > not. This is what I've understood, talking to all the experts. Dave? Why do you think O_DIRECT is actually OK? I agree the duration issue with RDMA is different, but don't forget, O_DIRECT goes out to the network too and has potentially very long timeouts as well. If O_DIRECT works fine then lets use the same approach in RDMA?? Jason
Re: [REPOST PATCH v6 3/4] kgdb: Don't round up a CPU that failed rounding up before
On Tue, Dec 04, 2018 at 07:38:27PM -0800, Douglas Anderson wrote:
> If we're using the default implementation of kgdb_roundup_cpus() that
> uses smp_call_function_single_async() we can end up hanging
> kgdb_roundup_cpus() if we try to round up a CPU that failed to round
> up before.
>
> Specifically smp_call_function_single_async() will try to wait on the
> csd lock for the CPU that we're trying to round up. If the previous
> round up never finished then that lock could still be held and we'll
> just sit there hanging.
>
> There's not a lot of use trying to round up a CPU that failed to round
> up before. Let's keep a flag that indicates whether the CPU started
> but didn't finish to round up before. If we see that flag set then
> we'll skip the next round up.
>
> In general we have a few goals here:
> - We never want to end up calling smp_call_function_single_async()
> when the csd is still locked. This is accomplished because
> flush_smp_call_function_queue() unlocks the csd _before_ invoking
> the callback. That means that when kgdb_nmicallback() runs we know
> for sure the the csd is no longer locked. Thus when we set
> "rounding_up = false" we know for sure that the csd is unlocked.
> - If there are no timeouts rounding up we should never skip a round
> up.
>
> NOTE #1: In general trying to continue running after failing to round
> up CPUs doesn't appear to be supported in the debugger. When I
> simulate this I find that kdb reports "Catastrophic error detected"
> when I try to continue. I can overrule and continue anyway, but it
> should be noted that we may be entering the land of dragons here.
> Possibly the "Catastrophic error detected" was added _because_ of the
> future failure to round up, but even so this is an area of the code
> that hasn't been strongly tested.
>
> NOTE #2: I did a bit of testing before and after this change. I
> introduced a 10 second hang in the kernel while holding a spinlock
> that I could invoke on a certain CPU with 'taskset -c 3 cat /sys/...".
>
> Before this change if I did:
> - Invoke hang
> - Enter debugger
> - g (which warns about Catastrophic error, g again to go anyway)
> - g
> - Enter debugger
>
> ...I'd hang the rest of the 10 seconds without getting a debugger
> prompt. After this change I end up in the debugger the 2nd time after
> only 1 second with the standard warning about 'Timed out waiting for
> secondary CPUs.'
>
> I'll also note that once the CPU finished waiting I could actually
> debug it (aka "btc" worked)
>
> I won't promise that everything works perfectly if the errant CPU
> comes back at just the wrong time (like as we're entering or exiting
> the debugger) but it certainly seems like an improvement.
>
> NOTE #3: setting 'kgdb_info[cpu].rounding_up = false' is in
> kgdb_nmicallback() instead of kgdb_call_nmi_hook() because some
> implementations override kgdb_call_nmi_hook(). It shouldn't hurt to
> have it in kgdb_nmicallback() in any case.
>
> NOTE #4: this logic is really only needed because there is no API call
> like "smp_try_call_function_single_async()" or "smp_csd_is_locked()".
> If such an API existed then we'd use it instead, but it seemed a bit
> much to add an API like this just for kgdb.
>
> Signed-off-by: Douglas Anderson
> Acked-by: Daniel Thompson
Applied! Thanks.
> ---
>
> Changes in v6:
> - Moved smp_call_function_single_async() error check to patch 3.
>
> Changes in v5: None
> Changes in v4:
> - Removed smp_mb() calls.
>
> Changes in v3:
> - Don't round up a CPU that failed rounding up before new for v3.
>
> Changes in v2: None
>
> kernel/debug/debug_core.c | 20 +++-
> kernel/debug/debug_core.h | 1 +
> 2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
> index 10db2833a423..1fb8b239e567 100644
> --- a/kernel/debug/debug_core.c
> +++ b/kernel/debug/debug_core.c
> @@ -247,6 +247,7 @@ void __weak kgdb_roundup_cpus(void)
> call_single_data_t *csd;
> int this_cpu = raw_smp_processor_id();
> int cpu;
> + int ret;
>
> for_each_online_cpu(cpu) {
> /* No need to roundup ourselves */
> @@ -254,8 +255,23 @@ void __weak kgdb_roundup_cpus(void)
> continue;
>
> csd = _cpu(kgdb_roundup_csd, cpu);
> +
> + /*
> + * If it didn't round up last time, don't try again
> + * since smp_call_function_single_async() will block.
> + *
> + * If rounding_up is false then we know that the
> + * previous call must have at least started and that
> + * means smp_call_function_single_async() won't block.
> + */
> + if (kgdb_info[cpu].rounding_up)
> + continue;
> + kgdb_info[cpu].rounding_up = true;
> +
> csd->func = kgdb_call_nmi_hook;
> - smp_call_function_single_async(cpu,
Re: [REPOST PATCH v6 4/4] kdb: Don't back trace on a cpu that didn't round up
On Tue, Dec 04, 2018 at 07:38:28PM -0800, Douglas Anderson wrote:
> If you have a CPU that fails to round up and then run 'btc' you'll end
> up crashing in kdb becaue we dereferenced NULL. Let's add a check.
> It's wise to also set the task to NULL when leaving the debugger so
> that if we fail to round up on a later entry into the debugger we
> won't backtrace a stale task.
>
> Signed-off-by: Douglas Anderson
> Acked-by: Daniel Thompson
Applied! Thanks.
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Also clear out .debuggerinfo.
> - Also clear out .debuggerinfo and .task for the master.
> - Remove clearing out in kdb_stub for offline CPUs; it's now redundant.
>
> Changes in v3:
> - Don't back trace on a cpu that didn't round up new for v3.
>
> Changes in v2: None
>
> kernel/debug/debug_core.c | 4
> kernel/debug/kdb/kdb_bt.c | 11 ++-
> kernel/debug/kdb/kdb_debugger.c | 7 ---
> 3 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
> index 1fb8b239e567..5cc608de6883 100644
> --- a/kernel/debug/debug_core.c
> +++ b/kernel/debug/debug_core.c
> @@ -592,6 +592,8 @@ static int kgdb_cpu_enter(struct kgdb_state *ks, struct
> pt_regs *regs,
> arch_kgdb_ops.correct_hw_break();
> if (trace_on)
> tracing_on();
> + kgdb_info[cpu].debuggerinfo = NULL;
> + kgdb_info[cpu].task = NULL;
> kgdb_info[cpu].exception_state &=
> ~(DCPU_WANT_MASTER | DCPU_IS_SLAVE);
> kgdb_info[cpu].enter_kgdb--;
> @@ -724,6 +726,8 @@ static int kgdb_cpu_enter(struct kgdb_state *ks, struct
> pt_regs *regs,
> if (trace_on)
> tracing_on();
>
> + kgdb_info[cpu].debuggerinfo = NULL;
> + kgdb_info[cpu].task = NULL;
> kgdb_info[cpu].exception_state &=
> ~(DCPU_WANT_MASTER | DCPU_IS_SLAVE);
> kgdb_info[cpu].enter_kgdb--;
> diff --git a/kernel/debug/kdb/kdb_bt.c b/kernel/debug/kdb/kdb_bt.c
> index 7921ae4fca8d..7e2379aa0a1e 100644
> --- a/kernel/debug/kdb/kdb_bt.c
> +++ b/kernel/debug/kdb/kdb_bt.c
> @@ -186,7 +186,16 @@ kdb_bt(int argc, const char **argv)
> kdb_printf("btc: cpu status: ");
> kdb_parse("cpu\n");
> for_each_online_cpu(cpu) {
> - sprintf(buf, "btt 0x%px\n", KDB_TSK(cpu));
> + void *kdb_tsk = KDB_TSK(cpu);
> +
> + /* If a CPU failed to round up we could be here */
> + if (!kdb_tsk) {
> + kdb_printf("WARNING: no task for cpu %ld\n",
> +cpu);
> + continue;
> + }
> +
> + sprintf(buf, "btt 0x%px\n", kdb_tsk);
> kdb_parse(buf);
> touch_nmi_watchdog();
> }
> diff --git a/kernel/debug/kdb/kdb_debugger.c b/kernel/debug/kdb/kdb_debugger.c
> index 15e1a7af5dd0..53a0df6e4d92 100644
> --- a/kernel/debug/kdb/kdb_debugger.c
> +++ b/kernel/debug/kdb/kdb_debugger.c
> @@ -118,13 +118,6 @@ int kdb_stub(struct kgdb_state *ks)
> kdb_bp_remove();
> KDB_STATE_CLEAR(DOING_SS);
> KDB_STATE_SET(PAGER);
> - /* zero out any offline cpu data */
> - for_each_present_cpu(i) {
> - if (!cpu_online(i)) {
> - kgdb_info[i].debuggerinfo = NULL;
> - kgdb_info[i].task = NULL;
> - }
> - }
> if (ks->err_code == DIE_OOPS || reason == KDB_REASON_OOPS) {
> ks->pass_exception = 1;
> KDB_FLAG_SET(CATASTROPHIC);
> --
> 2.20.0.rc1.387.gf8505762e3-goog
>
Re: [REPOST PATCH v6 2/4] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
On Tue, Dec 04, 2018 at 07:38:26PM -0800, Douglas Anderson wrote:
> When I had lockdep turned on and dropped into kgdb I got a nice splat
> on my system. Specifically it hit:
> DEBUG_LOCKS_WARN_ON(current->hardirq_context)
>
> Specifically it looked like this:
> sysrq: SysRq : DEBUG
> [ cut here ]
> DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> WARNING: CPU: 0 PID: 0 at .../kernel/locking/lockdep.c:2875
> lockdep_hardirqs_on+0xf0/0x160
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0 #27
> pstate: 604003c9 (nZCv DAIF +PAN -UAO)
> pc : lockdep_hardirqs_on+0xf0/0x160
> ...
> Call trace:
>lockdep_hardirqs_on+0xf0/0x160
>trace_hardirqs_on+0x188/0x1ac
>kgdb_roundup_cpus+0x14/0x3c
>kgdb_cpu_enter+0x53c/0x5cc
>kgdb_handle_exception+0x180/0x1d4
>kgdb_compiled_brk_fn+0x30/0x3c
>brk_handler+0x134/0x178
>do_debug_exception+0xfc/0x178
>el1_dbg+0x18/0x78
>kgdb_breakpoint+0x34/0x58
>sysrq_handle_dbg+0x54/0x5c
>__handle_sysrq+0x114/0x21c
>handle_sysrq+0x30/0x3c
>qcom_geni_serial_isr+0x2dc/0x30c
> ...
> ...
> irq event stamp: ...45
> hardirqs last enabled at (...44): [...] __do_softirq+0xd8/0x4e4
> hardirqs last disabled at (...45): [...] el1_irq+0x74/0x130
> softirqs last enabled at (...42): [...] _local_bh_enable+0x2c/0x34
> softirqs last disabled at (...43): [...] irq_exit+0xa8/0x100
> ---[ end trace adf21f830c46e638 ]---
>
> Looking closely at it, it seems like a really bad idea to be calling
> local_irq_enable() in kgdb_roundup_cpus(). If nothing else that seems
> like it could violate spinlock semantics and cause a deadlock.
>
> Instead, let's use a private csd alongside
> smp_call_function_single_async() to round up the other CPUs. Using
> smp_call_function_single_async() doesn't require interrupts to be
> enabled so we can remove the offending bit of code.
>
> In order to avoid duplicating this across all the architectures that
> use the default kgdb_roundup_cpus(), we'll add a "weak" implementation
> to debug_core.c.
>
> Looking at all the people who previously had copies of this code,
> there were a few variants. I've attempted to keep the variants
> working like they used to. Specifically:
> * For arch/arc we passed NULL to kgdb_nmicallback() instead of
> get_irq_regs().
> * For arch/mips there was a bit of extra code around
> kgdb_nmicallback()
>
> NOTE: In this patch we will still get into trouble if we try to round
> up a CPU that failed to round up before. We'll try to round it up
> again and potentially hang when we try to grab the csd lock. That's
> not new behavior but we'll still try to do better in a future patch.
>
> Suggested-by: Daniel Thompson
> Signed-off-by: Douglas Anderson
> Cc: Vineet Gupta
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Richard Kuo
> Cc: Ralf Baechle
> Cc: Paul Burton
> Cc: James Hogan
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: "David S. Miller"
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Acked-by: Will Deacon
I've not heard any objections from the arch/ maintainers so...
Applied! Thanks.
> -
> ---
>
> Changes in v6:
> - Moved smp_call_function_single_async() error check to patch 3.
>
> Changes in v5:
> - Add a comment about get_irq_regs().
> - get_cpu() => raw_smp_processor_id() in kgdb_roundup_cpus().
> - for_each_cpu() => for_each_online_cpu()
> - Error check smp_call_function_single_async()
>
> Changes in v4: None
> Changes in v3:
> - No separate init call.
> - Don't round up the CPU that is doing the rounding up.
> - Add "#ifdef CONFIG_SMP" to match the rest of the file.
> - Updated desc saying we don't solve the "failed to roundup" case.
> - Document the ignored parameter.
>
> Changes in v2:
> - Removing irq flags separated from fixing lockdep splat.
> - Don't use smp_call_function (Daniel).
>
> arch/arc/kernel/kgdb.c | 10 ++
> arch/arm/kernel/kgdb.c | 12 ---
> arch/arm64/kernel/kgdb.c | 12 ---
> arch/hexagon/kernel/kgdb.c | 27 -
> arch/mips/kernel/kgdb.c| 9 +
> arch/powerpc/kernel/kgdb.c | 4 ++--
> arch/sh/kernel/kgdb.c | 12 ---
> include/linux/kgdb.h | 15 --
> kernel/debug/debug_core.c | 41 ++
> 9 files changed, 59 insertions(+), 83 deletions(-)
>
> diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
> index 0932851028e0..68d9fe4b5aa7 100644
> --- a/arch/arc/kernel/kgdb.c
> +++ b/arch/arc/kernel/kgdb.c
> @@ -192,18 +192,12 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned
> long ip)
> instruction_pointer(regs) = ip;
> }
>
> -static void kgdb_call_nmi_hook(void *ignored)
> +void kgdb_call_nmi_hook(void *ignored)
> {
> + /* Default implementation passes get_irq_regs() but we don't */
>
[PATCH] perf/x86/intel: Delay memory deallocation until x86_pmu_dead_cpu()
From: Peter Zijlstra
intel_pmu_cpu_prepare() allocated memory for ->shared_regs among other
members of struct cpu_hw_events. This memory is released in
intel_pmu_cpu_dying() which is wrong. The counterpart of the
intel_pmu_cpu_prepare() callback is x86_pmu_dead_cpu().
Otherwise if the CPU fails on the UP path between CPUHP_PERF_X86_PREPARE
and CPUHP_AP_PERF_X86_STARTING then it won't release the memory but
allocate new memory on the next attempt to online the CPU (leaking the
old memory).
Also, if the CPU down path fails between CPUHP_AP_PERF_X86_STARTING and
CPUHP_PERF_X86_PREPARE then the CPU will go back online but never
allocate the memory that was released in x86_pmu_dying_cpu().
Make the memory allocation/free symmetrical in regard to the CPU hotplug
notifier by moving the deallocation to intel_pmu_cpu_dead().
This started in commit
a7e3ed1e47011 ("perf: Add support for supplementary event registers").
Cc: sta...@vger.kernel.org
Reported-by: He Zhe
Fixes: a7e3ed1e47011 ("perf: Add support for supplementary event registers").
Signed-off-by: Peter Zijlstra (Intel)
[bigeasy: patch description]
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/events/intel/core.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index ecc3e34ca955f..90b6718ff861d 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3558,6 +3558,14 @@ static void free_excl_cntrs(int cpu)
}
static void intel_pmu_cpu_dying(int cpu)
+{
+ fini_debug_store_on_cpu(cpu);
+
+ if (x86_pmu.counter_freezing)
+ disable_counter_freeze();
+}
+
+static void intel_pmu_cpu_dead(int cpu)
{
struct cpu_hw_events *cpuc = _cpu(cpu_hw_events, cpu);
struct intel_shared_regs *pc;
@@ -3570,11 +3578,6 @@ static void intel_pmu_cpu_dying(int cpu)
}
free_excl_cntrs(cpu);
-
- fini_debug_store_on_cpu(cpu);
-
- if (x86_pmu.counter_freezing)
- disable_counter_freeze();
}
static void intel_pmu_sched_task(struct perf_event_context *ctx,
@@ -3663,6 +3666,7 @@ static __initconst const struct x86_pmu core_pmu = {
.cpu_prepare= intel_pmu_cpu_prepare,
.cpu_starting = intel_pmu_cpu_starting,
.cpu_dying = intel_pmu_cpu_dying,
+ .cpu_dead = intel_pmu_cpu_dead,
};
static struct attribute *intel_pmu_attrs[];
@@ -3703,6 +3707,8 @@ static __initconst const struct x86_pmu intel_pmu = {
.cpu_prepare= intel_pmu_cpu_prepare,
.cpu_starting = intel_pmu_cpu_starting,
.cpu_dying = intel_pmu_cpu_dying,
+ .cpu_dead = intel_pmu_cpu_dead,
+
.guest_get_msrs = intel_guest_get_msrs,
.sched_task = intel_pmu_sched_task,
};
--
2.20.1
Re: [REPOST PATCH v6 1/4] kgdb: Remove irq flags from roundup
On Tue, Dec 04, 2018 at 07:38:25PM -0800, Douglas Anderson wrote:
> The function kgdb_roundup_cpus() was passed a parameter that was
> documented as:
>
> > the flags that will be used when restoring the interrupts. There is
> > local_irq_save() call before kgdb_roundup_cpus().
>
> Nobody used those flags. Anyone who wanted to temporarily turn on
> interrupts just did local_irq_enable() and local_irq_disable() without
> looking at them. So we can definitely remove the flags.
>
> Signed-off-by: Douglas Anderson
> Cc: Vineet Gupta
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Richard Kuo
> Cc: Ralf Baechle
> Cc: Paul Burton
> Cc: James Hogan
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: "David S. Miller"
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Acked-by: Will Deacon
I've not heard any objections from the arch/ maintainers so...
Applied! Thanks.
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Removing irq flags separated from fixing lockdep splat.
>
> arch/arc/kernel/kgdb.c | 2 +-
> arch/arm/kernel/kgdb.c | 2 +-
> arch/arm64/kernel/kgdb.c | 2 +-
> arch/hexagon/kernel/kgdb.c | 9 ++---
> arch/mips/kernel/kgdb.c| 2 +-
> arch/powerpc/kernel/kgdb.c | 2 +-
> arch/sh/kernel/kgdb.c | 2 +-
> arch/sparc/kernel/smp_64.c | 2 +-
> arch/x86/kernel/kgdb.c | 9 ++---
> include/linux/kgdb.h | 9 ++---
> kernel/debug/debug_core.c | 2 +-
> 11 files changed, 14 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
> index 9a3c34af2ae8..0932851028e0 100644
> --- a/arch/arc/kernel/kgdb.c
> +++ b/arch/arc/kernel/kgdb.c
> @@ -197,7 +197,7 @@ static void kgdb_call_nmi_hook(void *ignored)
> kgdb_nmicallback(raw_smp_processor_id(), NULL);
> }
>
> -void kgdb_roundup_cpus(unsigned long flags)
> +void kgdb_roundup_cpus(void)
> {
> local_irq_enable();
> smp_call_function(kgdb_call_nmi_hook, NULL, 0);
> diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
> index caa0dbe3dc61..f21077b077be 100644
> --- a/arch/arm/kernel/kgdb.c
> +++ b/arch/arm/kernel/kgdb.c
> @@ -175,7 +175,7 @@ static void kgdb_call_nmi_hook(void *ignored)
> kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
> }
>
> -void kgdb_roundup_cpus(unsigned long flags)
> +void kgdb_roundup_cpus(void)
> {
> local_irq_enable();
> smp_call_function(kgdb_call_nmi_hook, NULL, 0);
> diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> index a20de58061a8..12c339ff6e75 100644
> --- a/arch/arm64/kernel/kgdb.c
> +++ b/arch/arm64/kernel/kgdb.c
> @@ -289,7 +289,7 @@ static void kgdb_call_nmi_hook(void *ignored)
> kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
> }
>
> -void kgdb_roundup_cpus(unsigned long flags)
> +void kgdb_roundup_cpus(void)
> {
> local_irq_enable();
> smp_call_function(kgdb_call_nmi_hook, NULL, 0);
> diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
> index 16c24b22d0b2..012e0e230ac2 100644
> --- a/arch/hexagon/kernel/kgdb.c
> +++ b/arch/hexagon/kernel/kgdb.c
> @@ -119,17 +119,12 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned
> long pc)
>
> /**
> * kgdb_roundup_cpus - Get other CPUs into a holding pattern
> - * @flags: Current IRQ state
> *
> * On SMP systems, we need to get the attention of the other CPUs
> * and get them be in a known state. This should do what is needed
> * to get the other CPUs to call kgdb_wait(). Note that on some arches,
> * the NMI approach is not used for rounding up all the CPUs. For example,
> - * in case of MIPS, smp_call_function() is used to roundup CPUs. In
> - * this case, we have to make sure that interrupts are enabled before
> - * calling smp_call_function(). The argument to this function is
> - * the flags that will be used when restoring the interrupts. There is
> - * local_irq_save() call before kgdb_roundup_cpus().
> + * in case of MIPS, smp_call_function() is used to roundup CPUs.
> *
> * On non-SMP systems, this is not called.
> */
> @@ -139,7 +134,7 @@ static void hexagon_kgdb_nmi_hook(void *ignored)
> kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
> }
>
> -void kgdb_roundup_cpus(unsigned long flags)
> +void kgdb_roundup_cpus(void)
> {
> local_irq_enable();
> smp_call_function(hexagon_kgdb_nmi_hook, NULL, 0);
> diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
> index eb6c0d582626..2b05effc17b4 100644
> --- a/arch/mips/kernel/kgdb.c
> +++ b/arch/mips/kernel/kgdb.c
> @@ -219,7 +219,7 @@ static void kgdb_call_nmi_hook(void *ignored)
> set_fs(old_fs);
> }
>
> -void kgdb_roundup_cpus(unsigned long flags)
> +void kgdb_roundup_cpus(void)
> {
> local_irq_enable();
>
Re: [PATCH] kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled
On Wed, Dec 19, 2018 at 03:17:44PM +0100, Miroslav Benes wrote: > GCC 9 introduces a new option, -flive-patching. It disables certain > optimizations which could make a compilation unsafe for later live > patching of the running kernel. > > The option is used only if CONFIG_LIVEPATCH is enabled and $(CC) > supports it. > > Signed-off-by: Miroslav Benes > --- > Makefile | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Makefile b/Makefile > index a0650bf79606..53f5ab810efe 100644 > --- a/Makefile > +++ b/Makefile > @@ -778,6 +778,10 @@ KBUILD_CFLAGS_KERNEL += $(call > cc-option,-ffunction-sections,) > KBUILD_CFLAGS_KERNEL += $(call cc-option,-fdata-sections,) > endif > > +ifdef CONFIG_LIVEPATCH > +KBUILD_CFLAGS += $(call cc-option, -flive-patching=inline-clone) > +endif > + > # arch Makefile may override CC so keep this after arch Makefile is included > NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include) This option only makes sense for source-based patch generation, so isn't it a bit premature to make this change without proper source-based patch tooling? Also the commit message needs an analysis of the performance impacts. -- Josh
Re: [PATCH] tools/power/x86/intel_pstate_tracer: Fix non root execution for post processing a trace file.
On Mon, 2018-12-17 at 23:34 -0800, Doug Smythies wrote: > This script is supposed to be allowed to run with regular user > privileges > if a previously captured trace is being post processed. > > Commit fbe313884d7ddd73ce457473cbdf3763f5b1d3da > tools/power/x86/intel_pstate_tracer: Free the trace buffer memory > introduced a bug that breaks that option. > > Commit 35459105deb26430653a7299a86bc66fb4dd5773 > tools/power/x86/intel_pstate_tracer: Add optional setting of trace > buffer memory allocation > moved the code but kept the bug. > > This patch fixes the issue. > > Signed-off-by: Doug Smythies Acked-by: Srinivas Pandruvada > --- > tools/power/x86/intel_pstate_tracer/intel_pstate_tracer.py | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git > a/tools/power/x86/intel_pstate_tracer/intel_pstate_tracer.py > b/tools/power/x86/intel_pstate_tracer/intel_pstate_tracer.py > index 84e2b64..2fa3c57 100755 > --- a/tools/power/x86/intel_pstate_tracer/intel_pstate_tracer.py > +++ b/tools/power/x86/intel_pstate_tracer/intel_pstate_tracer.py > @@ -585,9 +585,9 @@ current_max_cpu = 0 > > read_trace_data(filename) > > -clear_trace_file() > -# Free the memory > if interval: > +clear_trace_file() > +# Free the memory > free_trace_buffer() > > if graph_data_present == False:
Re: [PATCH v2 3/3] sched/fair: fix unnecessary increase of balance interval
On Wed, 19 Dec 2018 at 16:54, Valentin Schneider wrote: > > On 19/12/2018 13:29, Vincent Guittot wrote: > [...] > >> My point is that AFAICT the LBF_ALL_PINNED flag would cover all the cases > >> we care about, although the one you're mentioning is the only one I can > >> think of. In that case LBF_ALL_PINNED would never be cleared, so when we do > >> the active balance we'd know it's because all other tasks were pinned so > >> we should probably increase the interval (see last snippet I sent). > > > > There are probably several other UC than the one mentioned below as > > tasks can be discarded for several reasons. > > So instead of changing for all UC by default, i would prefer only > > change for those for which we know it's safe > > I get your point. Thing is, I've stared at the code for a while and > couldn't find any other usecase where checking LBF_ALL_PINNED wouldn't > suffice. The point is that LBF_ALL_PINNED flag is not set otherwise we would have jump to out_*_pinned But conditions are similar > > It would be nice convince ourselves it is indeed enough (or not, but then > we should be sure of it rather than base ourselves on assumptions), because > then we can have just a simple condition rather than something that > introduces active balance categories. this can be part of the larger rework that Peter asked few days ago
Re: [RFC v3 1/3] PM/runtime: Add a new interface to get accounted time
On Wed, 19 Dec 2018 at 17:36, Ulf Hansson wrote:
>
> On Wed, 19 Dec 2018 at 14:26, Vincent Guittot
> wrote:
> >
> > On Wed, 19 Dec 2018 at 11:43, Ulf Hansson wrote:
> > >
> > > On Wed, 19 Dec 2018 at 11:34, Vincent Guittot
> > > wrote:
> > > >
> > > > On Wed, 19 Dec 2018 at 11:21, Ulf Hansson
> > > > wrote:
> > > > >
> >
> > > > > > > >
> > > > > > > > diff --git a/drivers/base/power/runtime.c
> > > > > > > > b/drivers/base/power/runtime.c
> > > > > > > > index 7062469..6461469 100644
> > > > > > > > --- a/drivers/base/power/runtime.c
> > > > > > > > +++ b/drivers/base/power/runtime.c
> > > > > > > > @@ -88,6 +88,32 @@ static void __update_runtime_status(struct
> > > > > > > > device *dev, enum rpm_status status)
> > > > > > > > dev->power.runtime_status = status;
> > > > > > > > }
> > > > > > > >
> > > > > > > > +u64 pm_runtime_accounted_time_get(struct device *dev, enum
> > > > > > > > rpm_status status, bool update)
> > > > > > > > +{
> > > > > > > > + u64 now = ktime_to_ns(ktime_get());
> > > > > > >
> > > > > > > I think you should stay on jiffies here - and then switch to
> > > > > > > ktime in patch 3.
> > > > > > >
> > > > > > > > + u64 delta = 0, time = 0;
> > > > > > > > + unsigned long flags;
> > > > > > > > +
> > > > > > > > + spin_lock_irqsave(>power.lock, flags);
> > > > > > > > +
> > > > > > > > + if (dev->power.disable_depth > 0)
> > > > > > > > + goto unlock;
> > > > > > > > +
> > > > > > > > + /* Add ongoing state if requested */
> > > > > > > > + if (update && dev->power.runtime_status == status)
> > > > > > > > + delta = now - dev->power.accounting_timestamp;
> > > > > > > > +
> > > > > > >
> > > > > > > Hmm. Do we really need to update the accounting timestamp? I would
> > > > > > > rather avoid it if possible.
> > > > > >
> > > > > > i915/drm uses this to track ongoing suspended state. In fact they
> > > > > > are
> > > > > > mainly interested by this part
> > > > >
> > > > > Again, sorry I don't follow.
> > > >
> > > > In fact we don't update dev->power.accounting_timestamp but only use
> > > > it to get how much time has elapsed in the current state.
> > > >
> > > > >
> > > > > My suggested changes below, would do exactly that; track the ongoing
> > > > > suspended state.
> > > > >
> > > > > The user can call the function several times while the device remains
> > > > > RPM_SUSPENDED, and if needed the user could then compute the delta
> > > > > in-between the calls, for whatever reason that may be needed.
> > > >
> > > > So I'm not sure to catch your question:
> > > > Is your problem linked to status != RPM_SUSPENDED or the update
> > > > parameter that compute delta ?
> > >
> > > My intent was to keep things simple.
> > >
> > > 1. Only expose last suspended time, which means tracking the ongoing
> > > suspended state. In other words, you can also remove "enum rpm_status
> > > status" as the in-parameter to pm_runtime_accounted_time_get().
> >
> > Ok for this point if Rafael doesn't see any benefit of keeping the
> > generic interface
> >
> > > 2. Don't allow the user of pm_runtime_accounted_time_get() to update
> > > the current timestamp, in "dev->power.accounting_timestamp".
> >
> > But pm_runtime_accounted_time_get doesn't update
> > dev->power.accounting_timestamp, it only reads it to know when when
> > the last state transition happened
>
> I understand, sorry for not being clear enough.
>
> My point is, you must not update dev->power.suspended_time, without
> also setting a new value for dev->power.accounting_timestamp.
> Otherwise, the next time the core calls
> update_pm_runtime_accounting(), it will end up adding a wrong delta to
> dev->power.suspended_time.
I fully agree on that and that's why dev->power.accounting_timestamp
is not and has never been modified
>
> BTW, it seems like you have based this on top of some patch converting
> from jiffies to ktime, as I can't fine dev->power.suspended_time, but
> instead I have dev->power.suspended_jiffies.
>
> On Wed, 19 Dec 2018 at 14:26, Vincent Guittot
> wrote:
> >
> > On Wed, 19 Dec 2018 at 11:43, Ulf Hansson wrote:
> > >
> > > On Wed, 19 Dec 2018 at 11:34, Vincent Guittot
> > > wrote:
> > > >
> > > > On Wed, 19 Dec 2018 at 11:21, Ulf Hansson
> > > > wrote:
> > > > >
> >
> > > > > > > >
> > > > > > > > diff --git a/drivers/base/power/runtime.c
> > > > > > > > b/drivers/base/power/runtime.c
> > > > > > > > index 7062469..6461469 100644
> > > > > > > > --- a/drivers/base/power/runtime.c
> > > > > > > > +++ b/drivers/base/power/runtime.c
> > > > > > > > @@ -88,6 +88,32 @@ static void __update_runtime_status(struct
> > > > > > > > device *dev, enum rpm_status status)
> > > > > > > > dev->power.runtime_status = status;
> > > > > > > > }
> > > > > > > >
> > > > > > > > +u64 pm_runtime_accounted_time_get(struct device *dev, enum
> > > > > > > > rpm_status status, bool update)
> > > > > > > > +{
> > > > > > > > + u64
[PATCH] ACPI/APEI: Clear GHES block_status before panic()
From: Lenny Szubowicz
In __ghes_panic() clear the block status in the APEI generic
error status block for that generic hardware error source before
calling panic() to prevent a second panic() in the crash kernel
for exactly the same fatal error.
Otherwise ghes_probe(), running in the crash kernel, would see
an unhandled error in the APEI generic error status block and
panic again, thereby precluding any crash dump.
Signed-off-by: Lenny Szubowicz
Signed-off-by: David Arcari
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Tony Luck
Cc: Borislav Petkov
Cc: "Eric W. Biederman"
Cc: Alexandru Gagniuc
Cc: linux-kernel@vger.kernel.org
---
drivers/acpi/apei/ghes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 02c6fd9..f008ba7 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -691,6 +691,8 @@ static void __ghes_panic(struct ghes *ghes)
{
__ghes_print_estatus(KERN_EMERG, ghes->generic, ghes->estatus);
+ ghes_clear_estatus(ghes);
+
/* reboot to log the error! */
if (!panic_timeout)
panic_timeout = ghes_panic_timeout;
--
1.8.3.1
[PATCH 00/10] i2c: move handling of suspended adapters to the core
Finally, here is the implementation Hans and I agreed on. Plus, all potential users I could spot already converted. Renesas R-Car driver was added on top. This series was tested on a Renesas Lager board (R-Car H2). I had to hack some error cases into the code to verify the workings. Thanks for all the tests so far. Of course, more testing never hurts ;) Please comment, review, test... a branch can be found here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/i2c/core-pm-helpers Thanks, Wolfram Changes since RFC: * don't use bitfields anymore but an unsigned long flags variable which is only meant for flags to be changed when the adapter lock is held * split the genereic accessor into _mark_suspended() and _mark_resumed() * added kerneldoc and noted that using these helpers is optional * documented -ESHUTDOWN as the error code when trying to transfer using an already suspended adapter * added acks from last series. Changes were minor enough to keep them. Please let me know if you disagree. Wolfram Sang (10): i2c: add suspended flag and accessors for i2c adapters i2c: reject new transfers when adapters are suspended i2c: synquacer: remove unused is_suspended flag i2c: brcmstb: use core helper to mark adapter suspended i2c: zx2967: use core helper to mark adapter suspended i2c: sprd: don't use pdev as variable name for struct device * i2c: sprd: use core helper to mark adapter suspended i2c: exynos5: use core helper to mark adapter suspended i2c: s3c2410: use core helper to mark adapter suspended i2c: rcar: add suspend/resume support Documentation/i2c/fault-codes | 4 drivers/i2c/busses/i2c-brcmstb.c | 13 ++--- drivers/i2c/busses/i2c-exynos5.c | 11 ++- drivers/i2c/busses/i2c-rcar.c | 25 + drivers/i2c/busses/i2c-s3c2410.c | 8 ++-- drivers/i2c/busses/i2c-sprd.c | 34 -- drivers/i2c/busses/i2c-synquacer.c | 5 - drivers/i2c/busses/i2c-zx2967.c| 8 ++-- drivers/i2c/i2c-core-base.c| 3 +++ include/linux/i2c.h| 34 ++ 10 files changed, 86 insertions(+), 59 deletions(-) -- 2.11.0
[PATCH 04/10] i2c: brcmstb: use core helper to mark adapter suspended
Rejecting transfers should be handled by the core.
Signed-off-by: Wolfram Sang
Reviewed-by: Kamal Dasu
---
drivers/i2c/busses/i2c-brcmstb.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-brcmstb.c b/drivers/i2c/busses/i2c-brcmstb.c
index 826d32049996..f4d862234980 100644
--- a/drivers/i2c/busses/i2c-brcmstb.c
+++ b/drivers/i2c/busses/i2c-brcmstb.c
@@ -170,7 +170,6 @@ struct brcmstb_i2c_dev {
struct bsc_regs *bsc_regmap;
struct i2c_adapter adapter;
struct completion done;
- bool is_suspended;
u32 clk_freq_hz;
int data_regsz;
};
@@ -467,9 +466,6 @@ static int brcmstb_i2c_xfer(struct i2c_adapter *adapter,
int xfersz = brcmstb_i2c_get_xfersz(dev);
u32 cond, cond_per_msg;
- if (dev->is_suspended)
- return -EBUSY;
-
/* Loop through all messages */
for (i = 0; i < num; i++) {
pmsg = [i];
@@ -689,10 +685,7 @@ static int brcmstb_i2c_suspend(struct device *dev)
{
struct brcmstb_i2c_dev *i2c_dev = dev_get_drvdata(dev);
- i2c_lock_bus(_dev->adapter, I2C_LOCK_ROOT_ADAPTER);
- i2c_dev->is_suspended = true;
- i2c_unlock_bus(_dev->adapter, I2C_LOCK_ROOT_ADAPTER);
-
+ i2c_mark_adapter_suspended(_dev->adapter);
return 0;
}
@@ -700,10 +693,8 @@ static int brcmstb_i2c_resume(struct device *dev)
{
struct brcmstb_i2c_dev *i2c_dev = dev_get_drvdata(dev);
- i2c_lock_bus(_dev->adapter, I2C_LOCK_ROOT_ADAPTER);
brcmstb_i2c_set_bsc_reg_defaults(i2c_dev);
- i2c_dev->is_suspended = false;
- i2c_unlock_bus(_dev->adapter, I2C_LOCK_ROOT_ADAPTER);
+ i2c_mark_adapter_resumed(_dev->adapter);
return 0;
}
--
2.11.0
[PATCH 02/10] i2c: reject new transfers when adapters are suspended
Using the new 'is_suspended' flag, we now reject new transfers if the adapter is already marked suspended. Signed-off-by: Wolfram Sang --- Documentation/i2c/fault-codes | 4 drivers/i2c/i2c-core-base.c | 2 ++ 2 files changed, 6 insertions(+) diff --git a/Documentation/i2c/fault-codes b/Documentation/i2c/fault-codes index 47c25abb7d52..0cee0fc545b4 100644 --- a/Documentation/i2c/fault-codes +++ b/Documentation/i2c/fault-codes @@ -112,6 +112,10 @@ EPROTO case is when the length of an SMBus block data response (from the SMBus slave) is outside the range 1-32 bytes. +ESHUTDOWN + Returned when a transfer was requested using an adapter + which is already suspended. + ETIMEDOUT This is returned by drivers when an operation took too much time, and was aborted before it completed. diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 2c465455b2f6..926ca0a7477f 100644 --- a/drivers/i2c/i2c-core-base.c +++ b/drivers/i2c/i2c-core-base.c @@ -1866,6 +1866,8 @@ int __i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) if (WARN_ON(!msgs || num < 1)) return -EINVAL; + if (WARN_ON(test_bit(I2C_ALF_IS_SUSPENDED, >locked_flags))) + return -ESHUTDOWN; if (adap->quirks && i2c_check_for_quirks(adap, msgs, num)) return -EOPNOTSUPP; -- 2.11.0
[PATCH 05/10] i2c: zx2967: use core helper to mark adapter suspended
Rejecting transfers should be handled by the core. Also, this will
ensure proper locking which was forgotten in this open coded version
and make sure resume mark is set after enabling clocks (not before).
Signed-off-by: Wolfram Sang
Acked-by: Shawn Guo
---
drivers/i2c/busses/i2c-zx2967.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-zx2967.c b/drivers/i2c/busses/i2c-zx2967.c
index b8f9e020d80e..7b98d97da3c6 100644
--- a/drivers/i2c/busses/i2c-zx2967.c
+++ b/drivers/i2c/busses/i2c-zx2967.c
@@ -66,7 +66,6 @@ struct zx2967_i2c {
int msg_rd;
u8 *cur_trans;
u8 access_cnt;
- boolis_suspended;
int error;
};
@@ -313,9 +312,6 @@ static int zx2967_i2c_xfer(struct i2c_adapter *adap,
int ret;
int i;
- if (i2c->is_suspended)
- return -EBUSY;
-
zx2967_set_addr(i2c, msgs->addr);
for (i = 0; i < num; i++) {
@@ -470,7 +466,7 @@ static int __maybe_unused zx2967_i2c_suspend(struct device
*dev)
{
struct zx2967_i2c *i2c = dev_get_drvdata(dev);
- i2c->is_suspended = true;
+ i2c_mark_adapter_suspended(>adap);
clk_disable_unprepare(i2c->clk);
return 0;
@@ -480,8 +476,8 @@ static int __maybe_unused zx2967_i2c_resume(struct device
*dev)
{
struct zx2967_i2c *i2c = dev_get_drvdata(dev);
- i2c->is_suspended = false;
clk_prepare_enable(i2c->clk);
+ i2c_mark_adapter_resumed(>adap);
return 0;
}
--
2.11.0
[PATCH 07/10] i2c: sprd: use core helper to mark adapter suspended
Rejecting transfers should be handled by the core.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-sprd.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-sprd.c b/drivers/i2c/busses/i2c-sprd.c
index e266d8a713d9..961123529678 100644
--- a/drivers/i2c/busses/i2c-sprd.c
+++ b/drivers/i2c/busses/i2c-sprd.c
@@ -86,7 +86,6 @@ struct sprd_i2c {
u32 count;
int irq;
int err;
- bool is_suspended;
};
static void sprd_i2c_set_count(struct sprd_i2c *i2c_dev, u32 count)
@@ -284,9 +283,6 @@ static int sprd_i2c_master_xfer(struct i2c_adapter
*i2c_adap,
struct sprd_i2c *i2c_dev = i2c_adap->algo_data;
int im, ret;
- if (i2c_dev->is_suspended)
- return -EBUSY;
-
ret = pm_runtime_get_sync(i2c_dev->dev);
if (ret < 0)
return ret;
@@ -590,10 +586,7 @@ static int __maybe_unused sprd_i2c_suspend_noirq(struct
device *dev)
{
struct sprd_i2c *i2c_dev = dev_get_drvdata(dev);
- i2c_lock_bus(_dev->adap, I2C_LOCK_ROOT_ADAPTER);
- i2c_dev->is_suspended = true;
- i2c_unlock_bus(_dev->adap, I2C_LOCK_ROOT_ADAPTER);
-
+ i2c_mark_adapter_suspended(_dev->adap);
return pm_runtime_force_suspend(dev);
}
@@ -601,10 +594,7 @@ static int __maybe_unused sprd_i2c_resume_noirq(struct
device *dev)
{
struct sprd_i2c *i2c_dev = dev_get_drvdata(dev);
- i2c_lock_bus(_dev->adap, I2C_LOCK_ROOT_ADAPTER);
- i2c_dev->is_suspended = false;
- i2c_unlock_bus(_dev->adap, I2C_LOCK_ROOT_ADAPTER);
-
+ i2c_mark_adapter_resumed(_dev->adap);
return pm_runtime_force_resume(dev);
}
--
2.11.0
[PATCH 06/10] i2c: sprd: don't use pdev as variable name for struct device *
The pointer to a device is usually named 'dev'. These 'pdev' here look
much like copy errors. Fix them to avoid confusion.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-sprd.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/busses/i2c-sprd.c b/drivers/i2c/busses/i2c-sprd.c
index a94e724f51dc..e266d8a713d9 100644
--- a/drivers/i2c/busses/i2c-sprd.c
+++ b/drivers/i2c/busses/i2c-sprd.c
@@ -586,40 +586,40 @@ static int sprd_i2c_remove(struct platform_device *pdev)
return 0;
}
-static int __maybe_unused sprd_i2c_suspend_noirq(struct device *pdev)
+static int __maybe_unused sprd_i2c_suspend_noirq(struct device *dev)
{
- struct sprd_i2c *i2c_dev = dev_get_drvdata(pdev);
+ struct sprd_i2c *i2c_dev = dev_get_drvdata(dev);
i2c_lock_bus(_dev->adap, I2C_LOCK_ROOT_ADAPTER);
i2c_dev->is_suspended = true;
i2c_unlock_bus(_dev->adap, I2C_LOCK_ROOT_ADAPTER);
- return pm_runtime_force_suspend(pdev);
+ return pm_runtime_force_suspend(dev);
}
-static int __maybe_unused sprd_i2c_resume_noirq(struct device *pdev)
+static int __maybe_unused sprd_i2c_resume_noirq(struct device *dev)
{
- struct sprd_i2c *i2c_dev = dev_get_drvdata(pdev);
+ struct sprd_i2c *i2c_dev = dev_get_drvdata(dev);
i2c_lock_bus(_dev->adap, I2C_LOCK_ROOT_ADAPTER);
i2c_dev->is_suspended = false;
i2c_unlock_bus(_dev->adap, I2C_LOCK_ROOT_ADAPTER);
- return pm_runtime_force_resume(pdev);
+ return pm_runtime_force_resume(dev);
}
-static int __maybe_unused sprd_i2c_runtime_suspend(struct device *pdev)
+static int __maybe_unused sprd_i2c_runtime_suspend(struct device *dev)
{
- struct sprd_i2c *i2c_dev = dev_get_drvdata(pdev);
+ struct sprd_i2c *i2c_dev = dev_get_drvdata(dev);
clk_disable_unprepare(i2c_dev->clk);
return 0;
}
-static int __maybe_unused sprd_i2c_runtime_resume(struct device *pdev)
+static int __maybe_unused sprd_i2c_runtime_resume(struct device *dev)
{
- struct sprd_i2c *i2c_dev = dev_get_drvdata(pdev);
+ struct sprd_i2c *i2c_dev = dev_get_drvdata(dev);
int ret;
ret = clk_prepare_enable(i2c_dev->clk);
--
2.11.0
[GIT PULL] Please pull NFS client bugfixes
Hi Linus, The following 3 patches fix a regression in the NFS/RPC TPC re- connection code which can cause the RPC transmission to hang. The issue was discovered by Dave Wysochanski last week. With this pull, we still have one more regression to fix. MIPS is seeing data corruption due to the fact that the iovec_iter code does not appear to call flush_dcache_page() after copying data into the bvec pages. We need guidance from Al as to how he wants this fixed. Cheers Trond The following changes since commit 7566ec393f4161572ba6f11ad5171fd5d59b0fbd: Linux 4.20-rc7 (2018-12-16 15:46:55 -0800) are available in the Git repository at: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.20-6 for you to fetch changes up to abc13275771fac77e2d7b129c289522dacb644b6: SUNRPC: Remove xprt_connect_status() (2018-12-18 11:04:10 -0500) NFS client bugfixes for Linux 4.20 Bugfixes: - Fix TCP socket disconnection races by ensuring we always call xprt_disconnect_done() after releasing the socket. - Fix a race when clearing both XPRT_CONNECTING and XPRT_LOCKED - Remove xprt_connect_status() so it does not mask errors that should be handled by call_connect_status() Trond Myklebust (3): SUNRPC: Fix disconnection races SUNRPC: Fix a race with XPRT_CONNECTING SUNRPC: Remove xprt_connect_status() net/sunrpc/clnt.c | 1 + net/sunrpc/xprt.c | 35 --- net/sunrpc/xprtsock.c | 10 -- 3 files changed, 9 insertions(+), 37 deletions(-) -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.mykleb...@hammerspace.com
[PATCH 09/10] i2c: s3c2410: use core helper to mark adapter suspended
Rejecting transfers should be handled by the core. Also, this will
ensure proper locking which was forgotten in this open coded version.
Signed-off-by: Wolfram Sang
Tested-by: Marek Szyprowski
---
drivers/i2c/busses/i2c-s3c2410.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 2f2e28d60ef5..53bc021f4a5a 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -104,7 +104,6 @@ enum s3c24xx_i2c_state {
struct s3c24xx_i2c {
wait_queue_head_t wait;
kernel_ulong_t quirks;
- unsigned intsuspended:1;
struct i2c_msg *msg;
unsigned intmsg_num;
@@ -703,9 +702,6 @@ static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c,
unsigned long timeout;
int ret;
- if (i2c->suspended)
- return -EIO;
-
ret = s3c24xx_i2c_set_master(i2c);
if (ret != 0) {
dev_err(i2c->dev, "cannot get bus (error %d)\n", ret);
@@ -1246,7 +1242,7 @@ static int s3c24xx_i2c_suspend_noirq(struct device *dev)
{
struct s3c24xx_i2c *i2c = dev_get_drvdata(dev);
- i2c->suspended = 1;
+ i2c_mark_adapter_suspended(>adap);
if (!IS_ERR(i2c->sysreg))
regmap_read(i2c->sysreg, EXYNOS5_SYS_I2C_CFG,
>sys_i2c_cfg);
@@ -1267,7 +1263,7 @@ static int s3c24xx_i2c_resume_noirq(struct device *dev)
return ret;
s3c24xx_i2c_init(i2c);
clk_disable(i2c->clk);
- i2c->suspended = 0;
+ i2c_mark_adapter_resumed(>adap);
return 0;
}
--
2.11.0
[PATCH 01/10] i2c: add suspended flag and accessors for i2c adapters
A few drivers open code handling of suspended adapters. It could be
handled by the core, though, to ensure generic handling. This patch adds
the flag and accessor functions. The usage of these helpers is optional,
though. See the kerneldoc in this patch.
Signed-off-by: Wolfram Sang
---
drivers/i2c/i2c-core-base.c | 1 +
include/linux/i2c.h | 34 ++
2 files changed, 35 insertions(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 28460f6a60cc..2c465455b2f6 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1232,6 +1232,7 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
if (!adap->lock_ops)
adap->lock_ops = _adapter_lock_ops;
+ adap->locked_flags = 0;
rt_mutex_init(>bus_lock);
rt_mutex_init(>mux_lock);
mutex_init(>userspace_clients_lock);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 65b4eaed1d96..b7401c55dc83 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -680,6 +680,8 @@ struct i2c_adapter {
int timeout;/* in jiffies */
int retries;
struct device dev; /* the adapter device */
+ unsigned long locked_flags; /* owned by the I2C core */
+#define I2C_ALF_IS_SUSPENDED 0
int nr;
char name[48];
@@ -762,6 +764,38 @@ i2c_unlock_bus(struct i2c_adapter *adapter, unsigned int
flags)
adapter->lock_ops->unlock_bus(adapter, flags);
}
+/**
+ * i2c_mark_adapter_suspended - Report suspended state of the adapter to the
core
+ * @adap: Adapter to mark as suspended
+ *
+ * When using this helper to mark an adapter as suspended, the core will reject
+ * further transfers to this adapter. The usage of this helper is optional but
+ * recommended for devices having distinct handlers for systems suspend and
+ * runtime suspend. More complex devices are free to implement custom solutions
+ * to reject transfers when suspended.
+ */
+static inline void i2c_mark_adapter_suspended(struct i2c_adapter *adap)
+{
+ i2c_lock_bus(adap, I2C_LOCK_ROOT_ADAPTER);
+ set_bit(I2C_ALF_IS_SUSPENDED, >locked_flags);
+ i2c_unlock_bus(adap, I2C_LOCK_ROOT_ADAPTER);
+}
+
+/**
+ * i2c_mark_adapter_resumed - Report resumed state of the adapter to the core
+ * @adap: Adapter to mark as resumed
+ *
+ * When using this helper to mark an adapter as resumed, the core will allow
+ * further transfers to this adapter. See also further notes to
+ * @i2c_mark_adapter_suspended().
+ */
+static inline void i2c_mark_adapter_resumed(struct i2c_adapter *adap)
+{
+ i2c_lock_bus(adap, I2C_LOCK_ROOT_ADAPTER);
+ clear_bit(I2C_ALF_IS_SUSPENDED, >locked_flags);
+ i2c_unlock_bus(adap, I2C_LOCK_ROOT_ADAPTER);
+}
+
/*flags for the client struct: */
#define I2C_CLIENT_PEC 0x04/* Use Packet Error Checking */
#define I2C_CLIENT_TEN 0x10/* we have a ten bit chip address */
--
2.11.0
Re: [PATCH net v3 0/2] net: mvpp2: phylink validate fixes
Hi David,
On Wed, Dec 19, 2018 at 08:34:18AM -0800, David Miller wrote:
> From: Antoine Tenart
> Date: Wed, 19 Dec 2018 09:26:09 +0100
> >
> > The patch 2/2 ("net: mvpp2: fix the phylink mode validation") is still
> > relevant, in addition to the patch you applied. It was added in v3, and
> > is an (unrelated) addition to the first patch.
>
> Sorry about that!
>
> Please resubmit patch #2 separately and I'll apply it.
No worries! I'll re-send it as a separate patch.
Thanks!
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[PATCH 10/10] i2c: rcar: add suspend/resume support
Because the adapter will be set up before every transaction anyhow, we
just need to mark it as suspended to the I2C core.
Signed-off-by: Hiromitsu Yamasaki
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-rcar.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 254e6219e538..1d6390eed861 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -1017,10 +1017,35 @@ static int rcar_i2c_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int rcar_i2c_suspend(struct device *dev)
+{
+ struct rcar_i2c_priv *priv = dev_get_drvdata(dev);
+
+ i2c_mark_adapter_suspended(>adap);
+ return 0;
+}
+
+static int rcar_i2c_resume(struct device *dev)
+{
+ struct rcar_i2c_priv *priv = dev_get_drvdata(dev);
+
+ i2c_mark_adapter_resumed(>adap);
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(rcar_i2c_pm_ops, rcar_i2c_suspend, rcar_i2c_resume);
+
+#define DEV_PM_OPS (_i2c_pm_ops)
+#else
+#define DEV_PM_OPS NULL
+#endif /* CONFIG_PM_SLEEP */
+
static struct platform_driver rcar_i2c_driver = {
.driver = {
.name = "i2c-rcar",
.of_match_table = rcar_i2c_dt_ids,
+ .pm = DEV_PM_OPS,
},
.probe = rcar_i2c_probe,
.remove = rcar_i2c_remove,
--
2.11.0
[PATCH 08/10] i2c: exynos5: use core helper to mark adapter suspended
Rejecting transfers should be handled by the core. Also, this will
ensure proper locking which was forgotten in this open coded version.
Signed-off-by: Wolfram Sang
Tested-by: Marek Szyprowski
---
drivers/i2c/busses/i2c-exynos5.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index c1ce2299a76e..41de4ee409b6 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -183,7 +183,6 @@ enum i2c_type_exynos {
struct exynos5_i2c {
struct i2c_adapter adap;
- unsigned intsuspended:1;
struct i2c_msg *msg;
struct completion msg_complete;
@@ -715,11 +714,6 @@ static int exynos5_i2c_xfer(struct i2c_adapter *adap,
struct exynos5_i2c *i2c = adap->algo_data;
int i, ret;
- if (i2c->suspended) {
- dev_err(i2c->dev, "HS-I2C is not initialized.\n");
- return -EIO;
- }
-
ret = clk_enable(i2c->clk);
if (ret)
return ret;
@@ -847,8 +841,7 @@ static int exynos5_i2c_suspend_noirq(struct device *dev)
{
struct exynos5_i2c *i2c = dev_get_drvdata(dev);
- i2c->suspended = 1;
-
+ i2c_mark_adapter_suspended(>adap);
clk_unprepare(i2c->clk);
return 0;
@@ -871,7 +864,7 @@ static int exynos5_i2c_resume_noirq(struct device *dev)
exynos5_i2c_init(i2c);
clk_disable(i2c->clk);
- i2c->suspended = 0;
+ i2c_mark_adapter_resumed(>adap);
return 0;
}
--
2.11.0
[PATCH 03/10] i2c: synquacer: remove unused is_suspended flag
This flag was defined and checked but never set a value. Remove it.
Signed-off-by: Wolfram Sang
Acked-by: Ard Biesheuvel
---
drivers/i2c/busses/i2c-synquacer.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-synquacer.c
b/drivers/i2c/busses/i2c-synquacer.c
index 2184b7c3580e..d18b0941b71a 100644
--- a/drivers/i2c/busses/i2c-synquacer.c
+++ b/drivers/i2c/busses/i2c-synquacer.c
@@ -144,8 +144,6 @@ struct synquacer_i2c {
u32 timeout_ms;
enum i2c_state state;
struct i2c_adapter adapter;
-
- boolis_suspended;
};
static inline int is_lastmsg(struct synquacer_i2c *i2c)
@@ -316,9 +314,6 @@ static int synquacer_i2c_doxfer(struct synquacer_i2c *i2c,
unsigned long timeout;
int ret;
- if (i2c->is_suspended)
- return -EBUSY;
-
synquacer_i2c_hw_init(i2c);
bsr = readb(i2c->base + SYNQUACER_I2C_REG_BSR);
if (bsr & SYNQUACER_I2C_BSR_BB) {
--
2.11.0
Re: [PATCH v2 03/12] PCI: aardvark: Add PHY support
Hi Marek, Marek Behún wrote on Wed, 19 Dec 2018 16:28:35 +0100: > Hi, > > One thing for which I would like to be able to disable comphy is that > each consumes about 100mW of power. On Turris Mox we configure the > comphys to SGMII1, PCIe and USB3 modes. If there is no USB device > plugged, the USB3 phy can be disabled, and save 100mW of power. If the > PCIe extension module is not present, the PCIe can too be disabled, and > if there is no switch nor SFP module present, so can SGMII1. Indeed not all PHY types implement ->power_off() (see in ATF code). Better ask Marvell directly for that. > > The other reason is this: if the SGMII phy is set to 1G mode, and then > powered on second time in 2.5G mode, will it work? I would like to This should work, yes. > patch mvneta driver to power on/off the comphy, if the device node is > present in device tree. But then the system can request such a change > (SGMII to 2500BASE-X or back). > > Marek > > On Tue, 18 Dec 2018 14:41:30 +0100 > Miquel Raynal wrote: > > > Hi Marek, > > > > Marek Behun wrote on Tue, 18 Dec 2018 14:09:20 > > +0100: > > > > > > [2] > > > > https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/marvell/comphy/phy-comphy-3700.c > > > > > > > > > > Yes, I used mainline atf (it did not work out of the box with 18.09 > > > atf-marvell of course). But there is no _power_off function for > > > SGMII, nor a digital_reset function like in cp110 implementation. > > > > Indeed, but why would you need one? Just use the helpers from the core > > and if there is no implementation, nothing should happen and the > > helper should exit without error. Just call > > phy_set_mode()/phy_power_on() an you should be good. > > > > > > Thanks, > > Miquèl > For the record, I found out what was wrong in my code, toggling the reset lines do not produce random effects anymore. Thanks, Miquèl
Re: [PATCH] kdb: use bool for binary state indicators
On Fri, Jul 20, 2018 at 11:50:16AM +0100, Daniel Thompson wrote:
> On Fri, Jul 20, 2018 at 11:23:37AM +0200, Nicholas Mc Guire wrote:
> > defcmd_in_progress is the state trace for command group processing
> > - within a command group or not - usable is an indicator if a command
> > set is valid (allocated/non-empty) - so use a bool for those binary
> > indication here.
> >
> > Signed-off-by: Nicholas Mc Guire
>
> Reviewed-by: Daniel Thompson
Applied! Thanks.
>
> > ---
> >
> > Found during code review.
> > Not a functional issue - just type correctness.
> >
> > Patch was compile tested with: x86_64_defconfig + CONFIG_KGDB=y,
> > CONFIG_KGDB_KDB=y
> > (some sparse/smatch warnings not related to the proposed change though)
> >
> > Patch is against 4.18-rc5 (localversion-next is next-20180720)
> >
> > kernel/debug/kdb/kdb_main.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
> > index bb4fe4e..fda515a 100644
> > --- a/kernel/debug/kdb/kdb_main.c
> > +++ b/kernel/debug/kdb/kdb_main.c
> > @@ -658,7 +658,7 @@ static void kdb_cmderror(int diag)
> > */
> > struct defcmd_set {
> > int count;
> > - int usable;
> > + bool usable;
> > char *name;
> > char *usage;
> > char *help;
> > @@ -666,7 +666,7 @@ struct defcmd_set {
> > };
> > static struct defcmd_set *defcmd_set;
> > static int defcmd_set_count;
> > -static int defcmd_in_progress;
> > +static bool defcmd_in_progress;
> >
> > /* Forward references */
> > static int kdb_exec_defcmd(int argc, const char **argv);
> > @@ -676,9 +676,9 @@ static int kdb_defcmd2(const char *cmdstr, const char
> > *argv0)
> > struct defcmd_set *s = defcmd_set + defcmd_set_count - 1;
> > char **save_command = s->command;
> > if (strcmp(argv0, "endefcmd") == 0) {
> > - defcmd_in_progress = 0;
> > + defcmd_in_progress = false;
> > if (!s->count)
> > - s->usable = 0;
> > + s->usable = false;
> > if (s->usable)
> > /* macros are always safe because when executed each
> > * internal command re-enters kdb_parse() and is
> > @@ -695,7 +695,7 @@ static int kdb_defcmd2(const char *cmdstr, const char
> > *argv0)
> > if (!s->command) {
> > kdb_printf("Could not allocate new kdb_defcmd table for %s\n",
> >cmdstr);
> > - s->usable = 0;
> > + s->usable = false;
> > return KDB_NOTIMP;
> > }
> > memcpy(s->command, save_command, s->count * sizeof(*(s->command)));
> > @@ -737,7 +737,7 @@ static int kdb_defcmd(int argc, const char **argv)
> >defcmd_set_count * sizeof(*defcmd_set));
> > s = defcmd_set + defcmd_set_count;
> > memset(s, 0, sizeof(*s));
> > - s->usable = 1;
> > + s->usable = true;
> > s->name = kdb_strdup(argv[1], GFP_KDB);
> > if (!s->name)
> > goto fail_name;
> > @@ -756,7 +756,7 @@ static int kdb_defcmd(int argc, const char **argv)
> > s->help[strlen(s->help)-1] = '\0';
> > }
> > ++defcmd_set_count;
> > - defcmd_in_progress = 1;
> > + defcmd_in_progress = true;
> > kfree(save_defcmd_set);
> > return 0;
> > fail_help:
> > --
> > 2.1.4
> >
Re: [PATCH] arc: remove redundant kernel-space generic-y
On 12/19/18 7:16 AM, Masahiro Yamada wrote: > Could you pick this up to your arc tree? Done, will push it in a day or so ! Thx, -Vineet
Re: [PATCH kernel v6 20/20] vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriver
[cc +kvm, +lkml] Ditto list cc comment from 18/20, and doubly so on this with updates to the vfio uapi. Also comment below... On Wed, 19 Dec 2018 19:52:32 +1100 Alexey Kardashevskiy wrote: > POWER9 Witherspoon machines come with 4 or 6 V100 GPUs which are not > pluggable PCIe devices but still have PCIe links which are used > for config space and MMIO. In addition to that the GPUs have 6 NVLinks > which are connected to other GPUs and the POWER9 CPU. POWER9 chips > have a special unit on a die called an NPU which is an NVLink2 host bus > adapter with p2p connections to 2 to 3 GPUs, 3 or 2 NVLinks to each. > These systems also support ATS (address translation services) which is > a part of the NVLink2 protocol. Such GPUs also share on-board RAM > (16GB or 32GB) to the system via the same NVLink2 so a CPU has > cache-coherent access to a GPU RAM. > > This exports GPU RAM to the userspace as a new VFIO device region. This > preregisters the new memory as device memory as it might be used for DMA. > This inserts pfns from the fault handler as the GPU memory is not onlined > until the vendor driver is loaded and trained the NVLinks so doing this > earlier causes low level errors which we fence in the firmware so > it does not hurt the host system but still better be avoided; for the same > reason this does not map GPU RAM into the host kernel (usual thing for > emulated access otherwise). > > This exports an ATSD (Address Translation Shootdown) register of NPU which > allows TLB invalidations inside GPU for an operating system. The register > conveniently occupies a single 64k page. It is also presented to > the userspace as a new VFIO device region. One NPU has 8 ATSD registers, > each of them can be used for TLB invalidation in a GPU linked to this NPU. > This allocates one ATSD register per an NVLink bridge allowing passing > up to 6 registers. Due to the host firmware bug (just recently fixed), > only 1 ATSD register per NPU was actually advertised to the host system > so this passes that alone register via the first NVLink bridge device in > the group which is still enough as QEMU collects them all back and > presents to the guest via vPHB to mimic the emulated NPU PHB on the host. > > In order to provide the userspace with the information about GPU-to-NVLink > connections, this exports an additional capability called "tgt" > (which is an abbreviated host system bus address). The "tgt" property > tells the GPU its own system address and allows the guest driver to > conglomerate the routing information so each GPU knows how to get directly > to the other GPUs. > > For ATS to work, the nest MMU (an NVIDIA block in a P9 CPU) needs to > know LPID (a logical partition ID or a KVM guest hardware ID in other > words) and PID (a memory context ID of a userspace process, not to be > confused with a linux pid). This assigns a GPU to LPID in the NPU and > this is why this adds a listener for KVM on an IOMMU group. A PID comes > via NVLink from a GPU and NPU uses a PID wildcard to pass it through. > > This requires coherent memory and ATSD to be available on the host as > the GPU vendor only supports configurations with both features enabled > and other configurations are known not to work. Because of this and > because of the ways the features are advertised to the host system > (which is a device tree with very platform specific properties), > this requires enabled POWERNV platform. > > The V100 GPUs do not advertise any of these capabilities via the config > space and there are more than just one device ID so this relies on > the platform to tell whether these GPUs have special abilities such as > NVLinks. > > Signed-off-by: Alexey Kardashevskiy > --- > Changes: > v6: > * reworked capabilities - tgt for nvlink and gpu and link-speed > for nvlink only > > v5: > * do not memremap GPU RAM for emulation, map it only when it is needed > * allocate 1 ATSD register per NVLink bridge, if none left, then expose > the region with a zero size > * separate caps per device type > * addressed AW review comments > > v4: > * added nvlink-speed to the NPU bridge capability as this turned out to > be not a constant value > * instead of looking at the exact device ID (which also changes from system > to system), now this (indirectly) looks at the device tree to know > if GPU and NPU support NVLink > > v3: > * reworded the commit log about tgt > * added tracepoints (do we want them enabled for entire vfio-pci?) > * added code comments > * added write|mmap flags to the new regions > * auto enabled VFIO_PCI_NVLINK2 config option > * added 'tgt' capability to a GPU so QEMU can recreate ibm,npu and ibm,gpu > references; there are required by the NVIDIA driver > * keep notifier registered only for short time > --- > drivers/vfio/pci/Makefile | 1 + > drivers/vfio/pci/trace.h| 102 ++ > drivers/vfio/pci/vfio_pci_private.h | 14 + > include/uapi/linux/vfio.h | 38 +++ >
Re: [PATCH kernel v6 18/20] vfio_pci: Allow mapping extra regions
[cc +kvm, +lkml]
Sorry, just noticed these are only visible on ppc lists or for those
directly cc'd. vfio's official development list is the kvm list. I'll
let spapr specific changes get away without copying this list, but
changes like this really need to be visible to everyone. Thanks,
Alex
On Wed, 19 Dec 2018 19:52:30 +1100
Alexey Kardashevskiy wrote:
> So far we only allowed mapping of MMIO BARs to the userspace. However
> there are GPUs with on-board coherent RAM accessible via side
> channels which we also want to map to the userspace. The first client
> for this is NVIDIA V100 GPU with NVLink2 direct links to a POWER9
> NPU-enabled CPU; such GPUs have 16GB RAM which is coherently mapped
> to the system address space, we are going to export these as an extra
> PCI region.
>
> We already support extra PCI regions and this adds support for mapping
> them to the userspace.
>
> Signed-off-by: Alexey Kardashevskiy
> Reviewed-by: David Gibson
> Acked-by: Alex Williamson
> ---
> Changes:
> v2:
> * reverted one of mistakenly removed error checks
> ---
> drivers/vfio/pci/vfio_pci_private.h | 3 +++
> drivers/vfio/pci/vfio_pci.c | 9 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/vfio/pci/vfio_pci_private.h
> b/drivers/vfio/pci/vfio_pci_private.h
> index cde3b5d..86aab05 100644
> --- a/drivers/vfio/pci/vfio_pci_private.h
> +++ b/drivers/vfio/pci/vfio_pci_private.h
> @@ -59,6 +59,9 @@ struct vfio_pci_regops {
> size_t count, loff_t *ppos, bool iswrite);
> void(*release)(struct vfio_pci_device *vdev,
> struct vfio_pci_region *region);
> + int (*mmap)(struct vfio_pci_device *vdev,
> + struct vfio_pci_region *region,
> + struct vm_area_struct *vma);
> };
>
> struct vfio_pci_region {
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index fef5002..4a6f7c0 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -1130,6 +1130,15 @@ static int vfio_pci_mmap(void *device_data, struct
> vm_area_struct *vma)
> return -EINVAL;
> if ((vma->vm_flags & VM_SHARED) == 0)
> return -EINVAL;
> + if (index >= VFIO_PCI_NUM_REGIONS) {
> + int regnum = index - VFIO_PCI_NUM_REGIONS;
> + struct vfio_pci_region *region = vdev->region + regnum;
> +
> + if (region && region->ops && region->ops->mmap &&
> + (region->flags & VFIO_REGION_INFO_FLAG_MMAP))
> + return region->ops->mmap(vdev, region, vma);
> + return -EINVAL;
> + }
> if (index >= VFIO_PCI_ROM_REGION_INDEX)
> return -EINVAL;
> if (!vdev->bar_mmap_supported[index])
Re: [PATCH kernel v6 19/20] vfio_pci: Allow regions to add own capabilities
[cc +kvm, +lkml]
Ditto list cc comment from 18/20
On Wed, 19 Dec 2018 19:52:31 +1100
Alexey Kardashevskiy wrote:
> VFIO regions already support region capabilities with a limited set of
> fields. However the subdriver might have to report to the userspace
> additional bits.
>
> This adds an add_capability() hook to vfio_pci_regops.
>
> Signed-off-by: Alexey Kardashevskiy
> Acked-by: Alex Williamson
> ---
> Changes:
> v3:
> * removed confusing rationale for the patch, the next patch makes
> use of it anyway
> ---
> drivers/vfio/pci/vfio_pci_private.h | 3 +++
> drivers/vfio/pci/vfio_pci.c | 6 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/vfio/pci/vfio_pci_private.h
> b/drivers/vfio/pci/vfio_pci_private.h
> index 86aab05..93c1738 100644
> --- a/drivers/vfio/pci/vfio_pci_private.h
> +++ b/drivers/vfio/pci/vfio_pci_private.h
> @@ -62,6 +62,9 @@ struct vfio_pci_regops {
> int (*mmap)(struct vfio_pci_device *vdev,
> struct vfio_pci_region *region,
> struct vm_area_struct *vma);
> + int (*add_capability)(struct vfio_pci_device *vdev,
> + struct vfio_pci_region *region,
> + struct vfio_info_cap *caps);
> };
>
> struct vfio_pci_region {
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 4a6f7c0..6cb70cf 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -763,6 +763,12 @@ static long vfio_pci_ioctl(void *device_data,
> if (ret)
> return ret;
>
> + if (vdev->region[i].ops->add_capability) {
> + ret = vdev->region[i].ops->add_capability(vdev,
> + >region[i], );
> + if (ret)
> + return ret;
> + }
> }
> }
>
[PATCH v2] macvlan: use per-cpu queues for broadcast and multicast packets
Currently macvlan has single per-port queue for broadcast and multicast.
This disrupts order of packets when flows from different cpus are mixed.
This patch replaces this queue with single set of per-cpu queues.
Pointer to macvlan port is passed in skb control block.
Signed-off-by: Konstantin Khlebnikov
Reported-by: Vadim Fedorenko
Tested-by: Vadim Fedorenko
---
drivers/net/macvlan.c | 65 +
1 file changed, 38 insertions(+), 27 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 0da3d36b283b..d6e74bd01571 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -46,8 +46,6 @@ struct macvlan_port {
struct net_device *dev;
struct hlist_head vlan_hash[MACVLAN_HASH_SIZE];
struct list_headvlans;
- struct sk_buff_head bc_queue;
- struct work_struct bc_work;
u32 flags;
int count;
struct hlist_head vlan_source_hash[MACVLAN_HASH_SIZE];
@@ -55,6 +53,11 @@ struct macvlan_port {
unsigned char perm_addr[ETH_ALEN];
};
+struct macvlan_bc_work {
+ struct sk_buff_head bc_queue;
+ struct work_struct bc_work;
+};
+
struct macvlan_source_entry {
struct hlist_node hlist;
struct macvlan_dev *vlan;
@@ -63,6 +66,7 @@ struct macvlan_source_entry {
};
struct macvlan_skb_cb {
+ const struct macvlan_port *port;
const struct macvlan_dev *src;
};
@@ -295,20 +299,23 @@ static void macvlan_broadcast(struct sk_buff *skb,
}
}
+static DEFINE_PER_CPU(struct macvlan_bc_work, macvlan_bc_work);
+
static void macvlan_process_broadcast(struct work_struct *w)
{
- struct macvlan_port *port = container_of(w, struct macvlan_port,
+ struct macvlan_bc_work *work = container_of(w, struct macvlan_bc_work,
bc_work);
struct sk_buff *skb;
struct sk_buff_head list;
__skb_queue_head_init();
- spin_lock_bh(>bc_queue.lock);
- skb_queue_splice_tail_init(>bc_queue, );
- spin_unlock_bh(>bc_queue.lock);
+ spin_lock_bh(>bc_queue.lock);
+ skb_queue_splice_tail_init(>bc_queue, );
+ spin_unlock_bh(>bc_queue.lock);
while ((skb = __skb_dequeue())) {
+ const struct macvlan_port *port = MACVLAN_SKB_CB(skb)->port;
const struct macvlan_dev *src = MACVLAN_SKB_CB(skb)->src;
rcu_read_lock();
@@ -345,6 +352,7 @@ static void macvlan_broadcast_enqueue(struct macvlan_port
*port,
const struct macvlan_dev *src,
struct sk_buff *skb)
{
+ struct macvlan_bc_work *work;
struct sk_buff *nskb;
int err = -ENOMEM;
@@ -352,24 +360,30 @@ static void macvlan_broadcast_enqueue(struct macvlan_port
*port,
if (!nskb)
goto err;
+ MACVLAN_SKB_CB(nskb)->port = port;
MACVLAN_SKB_CB(nskb)->src = src;
- spin_lock(>bc_queue.lock);
- if (skb_queue_len(>bc_queue) < MACVLAN_BC_QUEUE_LEN) {
+ work = get_cpu_ptr(_bc_work);
+
+ spin_lock(>bc_queue.lock);
+ if (skb_queue_len(>bc_queue) < MACVLAN_BC_QUEUE_LEN) {
if (src)
dev_hold(src->dev);
- __skb_queue_tail(>bc_queue, nskb);
+ __skb_queue_tail(>bc_queue, nskb);
err = 0;
}
- spin_unlock(>bc_queue.lock);
+ spin_unlock(>bc_queue.lock);
if (err)
goto free_nskb;
- schedule_work(>bc_work);
+ schedule_work_on(smp_processor_id(), >bc_work);
+ put_cpu_ptr(work);
+
return;
free_nskb:
+ put_cpu_ptr(work);
kfree_skb(nskb);
err:
atomic_long_inc(>dev->rx_dropped);
@@ -1171,9 +1185,6 @@ static int macvlan_port_create(struct net_device *dev)
for (i = 0; i < MACVLAN_HASH_SIZE; i++)
INIT_HLIST_HEAD(>vlan_source_hash[i]);
- skb_queue_head_init(>bc_queue);
- INIT_WORK(>bc_work, macvlan_process_broadcast);
-
err = netdev_rx_handler_register(dev, macvlan_handle_frame, port);
if (err)
kfree(port);
@@ -1185,24 +1196,16 @@ static int macvlan_port_create(struct net_device *dev)
static void macvlan_port_destroy(struct net_device *dev)
{
struct macvlan_port *port = macvlan_port_get_rtnl(dev);
- struct sk_buff *skb;
+ int cpu;
dev->priv_flags &= ~IFF_MACVLAN_PORT;
netdev_rx_handler_unregister(dev);
/* After this point, no packet can schedule bc_work anymore,
-* but we need to cancel it and purge left skbs if any.
+* but we need to flush work.
*/
- cancel_work_sync(>bc_work);
-
- while ((skb = __skb_dequeue(>bc_queue))) {
- const struct macvlan_dev *src =
Re: [PATCH 0/7] drm: KMS cleanup remove drm_mode_object dependency
On 12/19, Jani Nikula wrote: > On Tue, 18 Dec 2018, Shayenne Moura wrote: > > This patch serie removes drm_mode_object dependency from > > drm_display_mode struct. This is part of KMS cleanup. > > For future reference: > > Please use git-send-email or fix the mail threading otherwise. Patches > 1-7 should be in reply to the cover letter. > Sorry about that, > Please justify the changes in the commit messages. Your current commit > messages focus on *what* is being done, which is fairly obvious from the > changes themselves. Please try to describe *why* this is being > done. That's more important for posterity. (In this case, it's basically > explained in the FIXME comment being removed in patch 7, as well as > Documentation/gpu/todo.rst.) > > BR, > Jani. > Okay, thank you! But I should write on every patch why I am doing or just on the cover letter? Bests, Shayenne > > > > > Shayenne Moura (7): > > drm: msm: Delete base.id prints > > drm: Remove use of drm_mode_object > > drm: omapdrm: Delete base.id prints > > drm: i915: Delete base.id prints > > drm: sti: Delete base.id prints > > drm: meson: Delete base.id prints > > drm: Complete remove drm_mode_object dependency > > > > drivers/gpu/drm/drm_crtc_helper.c | 5 ++--- > > drivers/gpu/drm/drm_modes.c | 9 - > > drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- > > drivers/gpu/drm/meson/meson_dw_hdmi.c | 9 - > > drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 4 ++-- > > drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c | 4 ++-- > > drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c | 4 ++-- > > drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 4 ++-- > > drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 4 ++-- > > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 4 ++-- > > drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 4 ++-- > > drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 ++-- > > drivers/gpu/drm/msm/edp/edp_bridge.c | 4 ++-- > > drivers/gpu/drm/omapdrm/omap_connector.c | 4 ++-- > > drivers/gpu/drm/omapdrm/omap_crtc.c | 4 ++-- > > drivers/gpu/drm/sti/sti_crtc.c| 4 ++-- > > include/drm/drm_modes.h | 10 -- > > 17 files changed, 36 insertions(+), 49 deletions(-) > > -- > Jani Nikula, Intel Open Source Graphics Center
Re: pull-request: wireless-drivers 2018-12-19
From: Kalle Valo Date: Wed, 19 Dec 2018 16:34:02 +0200 > this a pull request to net tree for 4.20, more info below. > > Really sorry for sending a late request like this but I have been busy > with other stuff and this just got delayed. These are pretty > important fixes so I hope there's still time to get them to 4.20. But if > there's not time, please let me know and I'll pull these to > wireless-drivers-next. > > All of these, expect the ath10k fix, have been in linux-next, and even > the ath10k fix was in the pending branch so it has been tested by the > kbuild bot. > > I'll send the -next pull request tomorrow. Please let me know if there > are any problems. No problem, pulled, thanks!
Re: ftrace global trace_pipe_raw
On Wed, 19 Dec 2018 12:32:41 +0100
Claudio wrote:
> >>
> >> I would imagine the core functionality is already available, since
> >> trace_pipe
> >> in the tracing directory already shows all events regardless of CPU, and so
> >> it would be a matter of doing the same for trace_pipe_raw.
> >
> > The difference between trace_pipe and trace_pipe_raw is that trace_pipe
> > is post processed, and reads the per CPU buffers and interleaves them
> > one event at a time. The trace_pipe_raw just sends you the raw
> > unprocessed data directly from the buffers, which are grouped per CPU.
>
> I think that what I am looking for, to improve the performance of our system,
> is a post processed stream of binary entry data, already merged from all CPUs
> and sorted per timestamp, in the same way that it is done for textual output
> in __find_next_entry:
>
>for_each_tracing_cpu(cpu) {
>
> if (ring_buffer_empty_cpu(buffer, cpu))
> continue;
>
> ent = peek_next_entry(iter, cpu, , _events);
>
> /*
>
> * Pick the entry with the smallest timestamp:
>
> */
> if (ent && (!next || ts < next_ts)) {
> next = ent;
> next_cpu = cpu;
> next_ts = ts;
> next_lost = lost_events;
> next_size = iter->ent_size;
> }
> }
>
> We first tried to use the textual output directly, but this lead to
> unacceptable overheads in parsing the text.
>
> Please correct me if I do not understand, however it seems to me that it
> would be possible do the same kind of post processing including generating
> a sorted stream of entries, just avoiding the text output formatting,
> and outputting the binary data of the entry directly, which would be way
> more efficient to consume directly from user space correlators.
>
> But maybe this is not a general enough requirement to be acceptable for
> implementing directly into the kernel?
>
> We have the requirement of using the OS tracing events, including
> scheduling events, to react from software immediately
> (vs doing after-the-fact analysis).
Have you looked at using the perf event interface? I believe it uses a
single buffer for all events. At least for tracing a single process.
-- Steve
Re: [RFC v3 1/3] PM/runtime: Add a new interface to get accounted time
On Wed, 19 Dec 2018 at 14:26, Vincent Guittot
wrote:
>
> On Wed, 19 Dec 2018 at 11:43, Ulf Hansson wrote:
> >
> > On Wed, 19 Dec 2018 at 11:34, Vincent Guittot
> > wrote:
> > >
> > > On Wed, 19 Dec 2018 at 11:21, Ulf Hansson wrote:
> > > >
>
> > > > > > >
> > > > > > > diff --git a/drivers/base/power/runtime.c
> > > > > > > b/drivers/base/power/runtime.c
> > > > > > > index 7062469..6461469 100644
> > > > > > > --- a/drivers/base/power/runtime.c
> > > > > > > +++ b/drivers/base/power/runtime.c
> > > > > > > @@ -88,6 +88,32 @@ static void __update_runtime_status(struct
> > > > > > > device *dev, enum rpm_status status)
> > > > > > > dev->power.runtime_status = status;
> > > > > > > }
> > > > > > >
> > > > > > > +u64 pm_runtime_accounted_time_get(struct device *dev, enum
> > > > > > > rpm_status status, bool update)
> > > > > > > +{
> > > > > > > + u64 now = ktime_to_ns(ktime_get());
> > > > > >
> > > > > > I think you should stay on jiffies here - and then switch to ktime
> > > > > > in patch 3.
> > > > > >
> > > > > > > + u64 delta = 0, time = 0;
> > > > > > > + unsigned long flags;
> > > > > > > +
> > > > > > > + spin_lock_irqsave(>power.lock, flags);
> > > > > > > +
> > > > > > > + if (dev->power.disable_depth > 0)
> > > > > > > + goto unlock;
> > > > > > > +
> > > > > > > + /* Add ongoing state if requested */
> > > > > > > + if (update && dev->power.runtime_status == status)
> > > > > > > + delta = now - dev->power.accounting_timestamp;
> > > > > > > +
> > > > > >
> > > > > > Hmm. Do we really need to update the accounting timestamp? I would
> > > > > > rather avoid it if possible.
> > > > >
> > > > > i915/drm uses this to track ongoing suspended state. In fact they are
> > > > > mainly interested by this part
> > > >
> > > > Again, sorry I don't follow.
> > >
> > > In fact we don't update dev->power.accounting_timestamp but only use
> > > it to get how much time has elapsed in the current state.
> > >
> > > >
> > > > My suggested changes below, would do exactly that; track the ongoing
> > > > suspended state.
> > > >
> > > > The user can call the function several times while the device remains
> > > > RPM_SUSPENDED, and if needed the user could then compute the delta
> > > > in-between the calls, for whatever reason that may be needed.
> > >
> > > So I'm not sure to catch your question:
> > > Is your problem linked to status != RPM_SUSPENDED or the update
> > > parameter that compute delta ?
> >
> > My intent was to keep things simple.
> >
> > 1. Only expose last suspended time, which means tracking the ongoing
> > suspended state. In other words, you can also remove "enum rpm_status
> > status" as the in-parameter to pm_runtime_accounted_time_get().
>
> Ok for this point if Rafael doesn't see any benefit of keeping the
> generic interface
>
> > 2. Don't allow the user of pm_runtime_accounted_time_get() to update
> > the current timestamp, in "dev->power.accounting_timestamp".
>
> But pm_runtime_accounted_time_get doesn't update
> dev->power.accounting_timestamp, it only reads it to know when when
> the last state transition happened
I understand, sorry for not being clear enough.
My point is, you must not update dev->power.suspended_time, without
also setting a new value for dev->power.accounting_timestamp.
Otherwise, the next time the core calls
update_pm_runtime_accounting(), it will end up adding a wrong delta to
dev->power.suspended_time.
BTW, it seems like you have based this on top of some patch converting
from jiffies to ktime, as I can't fine dev->power.suspended_time, but
instead I have dev->power.suspended_jiffies.
On Wed, 19 Dec 2018 at 14:26, Vincent Guittot
wrote:
>
> On Wed, 19 Dec 2018 at 11:43, Ulf Hansson wrote:
> >
> > On Wed, 19 Dec 2018 at 11:34, Vincent Guittot
> > wrote:
> > >
> > > On Wed, 19 Dec 2018 at 11:21, Ulf Hansson wrote:
> > > >
>
> > > > > > >
> > > > > > > diff --git a/drivers/base/power/runtime.c
> > > > > > > b/drivers/base/power/runtime.c
> > > > > > > index 7062469..6461469 100644
> > > > > > > --- a/drivers/base/power/runtime.c
> > > > > > > +++ b/drivers/base/power/runtime.c
> > > > > > > @@ -88,6 +88,32 @@ static void __update_runtime_status(struct
> > > > > > > device *dev, enum rpm_status status)
> > > > > > > dev->power.runtime_status = status;
> > > > > > > }
> > > > > > >
> > > > > > > +u64 pm_runtime_accounted_time_get(struct device *dev, enum
> > > > > > > rpm_status status, bool update)
> > > > > > > +{
> > > > > > > + u64 now = ktime_to_ns(ktime_get());
> > > > > >
> > > > > > I think you should stay on jiffies here - and then switch to ktime
> > > > > > in patch 3.
> > > > > >
> > > > > > > + u64 delta = 0, time = 0;
> > > > > > > + unsigned long flags;
> > > > > > > +
> > > > > > > + spin_lock_irqsave(>power.lock, flags);
> > > > > > > +
> > > > > > > + if (dev->power.disable_depth > 0)
> > > > > > > +
Re: [PATCH net v3 0/2] net: mvpp2: phylink validate fixes
From: Antoine Tenart
Date: Wed, 19 Dec 2018 09:26:09 +0100
> Hi David,
>
> On Tue, Dec 18, 2018 at 04:42:52PM -0800, David Miller wrote:
>> From: Antoine Tenart
>> Date: Mon, 17 Dec 2018 15:56:04 +0100
>>
>> > This small series introduces 2 fixes for the phylink validate function
>> > of the Marvell PPv2 Ethernet driver.
>> >
>> > Since v2:
>> > - Added an additional patch (2/2) as suggested by Russell.
>> > - Rebased on top of net/master.
>> >
>> > Since v1:
>> > - Rebased on top of net/master.
>>
>> Because, in the end, I applied:
>>
>> 006791772084 ("net: mvpp2: 10G modes aren't supported on all ports")
>>
>> I am assuming this series is not relevant.
>
> The patch 2/2 ("net: mvpp2: fix the phylink mode validation") is still
> relevant, in addition to the patch you applied. It was added in v3, and
> is an (unrelated) addition to the first patch.
Sorry about that!
Please resubmit patch #2 separately and I'll apply it.
Thank you!
Re: [RFC/RFT 01/10] i2c: add 'is_suspended' flag for i2c adapters
On Wed, Dec 19, 2018 at 10:39:05AM +0100, Geert Uytterhoeven wrote: > Hi Wolfram, > > On Wed, Dec 19, 2018 at 12:34 AM Wolfram Sang wrote: > > > > + unsigned int is_suspended:1;/* owned by the I2C core */ > > > > > > When more stuff is added to this bit field (which always happens at > > > some point) updates to all members of the bit field will have to use > > > the same root-adapter-locking, or we will suffer from RMW-races. So > > > this feels like an invitation for future disaster. Maybe a comment > > > about that to remind our future selves? Or perhaps the bit field > > > should be avoided altogether? > > > > Changed to bool. Thanks! > > Does that help, given bool is smaller than the CPUs word size? > Is it Alpha that cannot do atomic operations on bytes? Yup, I overestimated bools :( I guess good old unsigned long locked_flags; #define _IS_SUSPENDED 0 set_bit(), clear_bit(), and test_bit() is it then. signature.asc Description: PGP signature
[PATCH] staging: wilc1000: fix missing read_write setting when reading data
From: Colin Ian King
Currently the cmd.read_write setting is not initialized so it contains
garbage from the stack. Fix this by setting it to 0 to indicate a
read is required.
Detected by CoverityScan, CID#1357925 ("Uninitialized scalar variable")
Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver")
Signed-off-by: Colin Ian King
---
drivers/staging/wilc1000/wilc_sdio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/wilc1000/wilc_sdio.c
b/drivers/staging/wilc1000/wilc_sdio.c
index 27fdfbdda5c0..e2f739fef21c 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -861,6 +861,7 @@ static int sdio_read_int(struct wilc *wilc, u32 *int_status)
if (!sdio_priv->irq_gpio) {
int i;
+ cmd.read_write = 0;
cmd.function = 1;
cmd.address = 0x04;
cmd.data = 0;
--
2.19.1
Re: [PATCH v3 3/6] irqchip: sifive-plic: More flexible plic_irq_toggle()
On Tue, Dec 18, 2018 at 02:20:10PM +0530, Anup Patel wrote: > Actually these functions should not be inline because plic_toggle() uses > raw_spin_lock() and plic_irq_toggle() uses for-loop. So? It still inlines the all of two instances into each caller for slightly different but related work. Not sure it is 100% worth it, but probably more than the one to move the calculations to init time..
Re: [PATCH v5 5/6] net: maclorawan: Implement maclorawan class module
> > Am 18.12.18 um 15:27 schrieb Jian-Hong Pan: > > >> Sun, Dec 16, 2018 at 11:18:59AM CET, starni...@g.ncu.edu.tw wrote: > > >>> LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa > > devices. > > >>> > > >>> This patch implements part of Class A end-devices SoftMAC defined in > > >>> LoRaWAN(TM) Specification Ver. 1.0.2: > > >>> 1. End-device receive slot timing > > >>> 2. Only single channel and single data rate for now > > >>> 3. Unconfirmed data up/down message types > > >>> > > >>> On the other side, it defines the basic interface and operation > > >>> functions for compatible LoRa device drivers. > > >>> > > >>> Signed-off-by: Jian-Hong Pan > > [...] > > >>> net/maclorawan/Kconfig | 14 + > > >>> net/maclorawan/Makefile | 2 + > > >>> net/maclorawan/mac.c| 555 > > > > >>> net/maclorawan/main.c | 606 > > > > >>> 4 files changed, 1177 insertions(+) > > >>> create mode 100644 net/maclorawan/Kconfig > > >>> create mode 100644 net/maclorawan/Makefile > > >>> create mode 100644 net/maclorawan/mac.c > > >>> create mode 100644 net/maclorawan/main.c > > >> > > >> I don't get it. In patch "Add LoRaWAN API declaration for LoRa devices" > > >> you add headers for "API" and here you implement functions. That is just > > >> weird. Does it mean you can have other implementations? > > > > > > LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa PHY. > > > This part is soft-MAC as Andreas mentioned > > > http://lists.infradead.org/pipermail/linux-lpwan/2018- > > December/10.html > > > > > >> Also, you don't really have any user of this API in the set. Please > > >> introduce at least 1 driver, preferably more (I see that Andreas has > > >> multiple ones in his patchset). You cannot push kernel infrastructure > > >> without kernel user. > > > > > > The soft-MAC is suitable for the LoRa chips' device drivers, like > > > sx1276/77/78/79, RFM95/96/97/98W ... > > > Still waiting for Andreas' sx1276 version 2 patch and more discussion. > > > > sx1276 regmap conversion was pushed to my staging tree together with > > Ben's sx1301 final conversion last night, lightly tested. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux- > > lora.git/log/?h=lora-next > > > > TBD: rename to sx127x, implement regmap fields, only auto-detect reset > > when no OF node available (all low priority atm, patches welcome) > > > > (and for sx1301 I still need to update my DT overlays with the new clk) > > > > > For example, how to make PF_LORA and PF_LORAWAN like Ethernet, > > PF_INET > > > and PF_INET6 don't need separate devices either, both use eth0. > > > https://lkml.org/lkml/2018/8/3/266 > > > > Jiri, I am expecting the maclorawan driver to lower packets from > > ETH_P_LORAWAN to ETH_P_LORA in a generic way, so that any of the LoRa > > device drivers can benefit of it, with maclorawan using the LoRa netlink > > commands that the individual drivers implement. > > Not sure what if anything is missing for that in the current revision? > > Still dealing with the lower-level infrastructure and my test setup ... > > progressing slowly. > > > > I'll probably need to queue the remaining generic LoRaWAN part 1/6 in my > > tree to resolve this circular dependency between Jian-Hong and me, so > > that only the soft-MAC implementation remains a separate patch series. > > The hard-MAC implementations will be on my plate mostly, as both SX1276 > > and SX1301 need the soft-MAC. > > On the SX1301 side of things, the ability to send messages as a LoRaWAN > node device is a niche use case, the majority if not all people will use the > concentrator card as the pass through gateway to the node. > > In this mode of operation the parameters for transmission such as; frequency, > spreading factor / data rate, power, are given by a remote server and passed > in from the userspace application which received it. > Eventually in the kernel these need to be checked locally to ensure regulatory > compliance. > To that end I have experimented with framing, as CAN does, so that this > metadata can be provided on a write from userspace to the SX1301 driver. > > Sounds like we need different protocols for framing within the protocol > family. > Raw in the case of nodes and framed with metadata in the case of concentrator > cards, thoughts? Yes, I have thought the roles of node and gateway. They may have different skb passing paths. As you mentioned, many things of the gateway is controlled by the remote server. So, I only implement the path for nodes right now. Maybe, we can have a role flag: node, gateway which can be assigned by some way. Then, the skb can be decode, checked and passed according to the role flag. And module also checks the integrity (MIC, length ...) and filter out the bad skb before sends to next stop. > I will send my experiment RFC to the lpwan mailing list. Or you can send the RFC first. Then we can have the
[PATCH 1/2] dt: bindings: lp5024: Introduce the lp5024 and lp5018 RGB driver
Introduce the bindings for the Texas Instruments LP5024 and the LP5018
RGB LED device driver. The LP5024/18 can control RGB LEDs individually
or as part of a control bank group. These devices have the ability
to adjust the mixing control for the RGB LEDs to obtain different colors
independent of the overall brightness of the LED grouping.
Datasheet:
http://www.ti.com/lit/ds/symlink/lp5024.pdf
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/leds/leds-lp5024.txt | 63 +++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp5024.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-lp5024.txt
b/Documentation/devicetree/bindings/leds/leds-lp5024.txt
new file mode 100644
index ..9567aa6f7813
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lp5024.txt
@@ -0,0 +1,63 @@
+* Texas Instruments - LP5024/18 RGB LED driver
+
+The LM3692x is an ultra-compact, highly efficient,
+white-LED driver designed for LCD display backlighting.
+
+The main difference between the LP5024 and L5018 is the number of
+RGB LEDs they support. The LP5024 supports twenty four strings while the
+LP5018 supports eighteen strings.
+
+Required properties:
+ - compatible:
+ "ti,lp5018"
+ "ti,lp5024"
+ - reg : I2C slave address
+ - #address-cells : 1
+ - #size-cells : 0
+
+Optional properties:
+ - enable-gpios : gpio pin to enable/disable the device.
+ - vled-supply : LED supply
+
+Required child properties:
+ - reg : Is the child node iteration.
+ - led-sources : LP5024 - 0 - 7
+ LP5018 - 0 - 5
+ Declares the LED string or strings that the child node
+ will control. If ti,control-bank is set then this
+ property will contain multiple LED IDs.
+
+Optional child properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+ - linux,default-trigger :
+ see Documentation/devicetree/bindings/leds/common.txt
+ - ti,control-bank : Indicates that the LED strings declared in the
+ led-sources property are grouped within a control
+ bank for brightness and mixing control.
+
+Example:
+
+led-controller@28 {
+ compatible = "ti,lp5024";
+ reg = <0x28>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ enable-gpios = < 28 GPIO_ACTIVE_HIGH>;
+ vled-supply = <>;
+
+ led@0 {
+ reg = <0>;
+ led-sources = <1>;
+ };
+
+ led@1 {
+ reg = <1>;
+ led-sources = <0 6>;
+ ti,control-bank;
+ };
+
+}
+
+For more product information please see the link below:
+http://www.ti.com/lit/ds/symlink/lp5024.pdf
--
2.20.0.rc2.7.g965798d1f2
[PATCH 0/2] LP5024/18 LED introduction
Hello I am introducing the newest of the TI RGB parts the LP5024 and the LP5018. Now I understand that there is a patchset in the works that changes the way the LED labeling is created but I wanted to post these patches for comments and let the maintainers decide whether to pull this in prior to that patchset being committed. Dan Dan Murphy (2): dt: bindings: lp5024: Introduce the lp5024 and lp5018 RGB driver leds: lp5024: Add the LP5024/18 RGB LED driver .../devicetree/bindings/leds/leds-lp5024.txt | 63 ++ drivers/leds/Kconfig | 7 + drivers/leds/Makefile | 1 + drivers/leds/leds-lp5024.c| 610 ++ 4 files changed, 681 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-lp5024.txt create mode 100644 drivers/leds/leds-lp5024.c -- 2.20.0.rc2.7.g965798d1f2
[PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
Introduce the LP5024 and LP5018 RGB LED driver.
The difference in these 2 parts are only in the number of
LED outputs where the LP5024 can control 24 LEDs the LP5018
can only control 18.
The device has the ability to group LED output into control banks
so that multiple LED banks can be controlled with the same mixing and
brightness. Inversely the LEDs can also be controlled independently.
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 7 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lp5024.c | 610 +
3 files changed, 618 insertions(+)
create mode 100644 drivers/leds/leds-lp5024.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index a72f97fca57b..d306bedb00b7 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -326,6 +326,13 @@ config LEDS_LP3952
To compile this driver as a module, choose M here: the
module will be called leds-lp3952.
+config LEDS_LP5024
+ tristate "LED Support for TI LP5024/18 LED driver chip"
+ depends on LEDS_CLASS && REGMAP_I2C
+ help
+ If you say yes here you get support for the Texas Instruments
+ LP5024 and LP5018 LED driver.
+
config LEDS_LP55XX_COMMON
tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501"
depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 4c1b0054f379..60b4e4ddd3ee 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_LEDS_GPIO_REGISTER) += leds-gpio-register.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
obj-$(CONFIG_LEDS_LP3944) += leds-lp3944.o
obj-$(CONFIG_LEDS_LP3952) += leds-lp3952.o
+obj-$(CONFIG_LEDS_LP5024) += leds-lp5024.o
obj-$(CONFIG_LEDS_LP55XX_COMMON) += leds-lp55xx-common.o
obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o
obj-$(CONFIG_LEDS_LP5523) += leds-lp5523.o
diff --git a/drivers/leds/leds-lp5024.c b/drivers/leds/leds-lp5024.c
new file mode 100644
index ..90e8dca15609
--- /dev/null
+++ b/drivers/leds/leds-lp5024.c
@@ -0,0 +1,610 @@
+// SPDX-License-Identifier: GPL-2.0
+/* TI LP50XX LED chip family driver
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LP5024_DEV_CFG00x00
+#define LP5024_DEV_CFG10x01
+#define LP5024_LED_CFG00x02
+#define LP5024_BNK_BRT 0x03
+#define LP5024_BNKA_CLR0x04
+#define LP5024_BNKB_CLR0x05
+#define LP5024_BNKC_CLR0x06
+#define LP5024_LED0_BRT0x07
+#define LP5024_LED1_BRT0x08
+#define LP5024_LED2_BRT0x09
+#define LP5024_LED3_BRT0x0a
+#define LP5024_LED4_BRT0x0b
+#define LP5024_LED5_BRT0x0c
+#define LP5024_LED6_BRT0x0d
+#define LP5024_LED7_BRT0x0e
+
+#define LP5024_OUT0_CLR0x0f
+#define LP5024_OUT1_CLR0x10
+#define LP5024_OUT2_CLR0x11
+#define LP5024_OUT3_CLR0x12
+#define LP5024_OUT4_CLR0x13
+#define LP5024_OUT5_CLR0x14
+#define LP5024_OUT6_CLR0x15
+#define LP5024_OUT7_CLR0x16
+#define LP5024_OUT8_CLR0x17
+#define LP5024_OUT9_CLR0x18
+#define LP5024_OUT10_CLR 0x19
+#define LP5024_OUT11_CLR 0x1a
+#define LP5024_OUT12_CLR 0x1b
+#define LP5024_OUT13_CLR 0x1c
+#define LP5024_OUT14_CLR 0x1d
+#define LP5024_OUT15_CLR 0x1e
+#define LP5024_OUT16_CLR 0x1f
+#define LP5024_OUT17_CLR 0x20
+#define LP5024_OUT18_CLR 0x21
+#define LP5024_OUT19_CLR 0x22
+#define LP5024_OUT20_CLR 0x23
+#define LP5024_OUT21_CLR 0x24
+#define LP5024_OUT22_CLR 0x25
+#define LP5024_OUT23_CLR 0x26
+
+#define LP5024_RESET 0x27
+#define LP5024_SW_RESET0xff
+
+#define LP5024_CHIP_EN BIT(6)
+
+#define LP5024_CONTROL_A 0
+#define LP5024_CONTROL_B 1
+#define LP5024_CONTROL_C 2
+#define LP5024_MAX_CONTROL_BANKS 3
+
+#define LP5018_MAX_LED_STRINGS 6
+#define LP5024_MAX_LED_STRINGS 8
+
+enum lp5024_model {
+ LP5018,
+ LP5024,
+};
+
+struct lp5024_led {
+ u32 led_strings[LP5024_MAX_LED_STRINGS];
+ char label[LED_MAX_NAME_SIZE];
+ struct led_classdev led_dev;
+ struct lp5024 *priv;
+ int led_number;
+ u8 ctrl_bank_enabled;
+};
+
+/**
+ * struct lp5024 -
+ * @enable_gpio: Hardware enable gpio
+ * @regulator: LED supply regulator pointer
+ * @client: Pointer to the I2C client
+ * @regmap: Devices register map
+
Re: [PATCH 3/3] ARM: dts: s5pv210: Add node for exynos-rotator
On Wed, 19 Dec 2018 at 17:04, Paweł Chmiel wrote: > > This commit adds node for Exynos Rorator device, > so it can be used on all s5pv210 based devices. > > Signed-off-by: Paweł Chmiel > --- > arch/arm/boot/dts/s5pv210.dtsi | 9 + > 1 file changed, 9 insertions(+) Patch looks good but it is too close to merge window so I won't be able to send it further. I'll pick it up for next cycle, after this merge window. Best regards, Krzysztof
[PATCH] KVM: x86: nSVM: fix switch to guest mmu
Recent optimizations in MMU code broke nested SVM with NPT in L1
completely: when we do nested_svm_{,un}init_mmu_context() we want
to switch from TDP MMU to shadow MMU, both init_kvm_tdp_mmu() and
kvm_init_shadow_mmu() check if re-configuration is needed by looking
at cache source data. The data, however, doesn't change - it's only
the type of the MMU which changes. We end up not re-initializing
guest MMU as shadow and everything goes off the rails.
The issue could have been fixed by putting MMU type into extended MMU
role but this is not really needed. We can just split root and guest MMUs
the exact same way we did for nVMX, their types never change in the
lifetime of a vCPU.
There is still room for improvement: currently, we reset all MMU roots
when switching from L1 to L2 and back and this is not needed.
Fixes: 7dcd57552008 ("x86/kvm/mmu: check if tdp/shadow MMU reconfiguration is
needed")
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/kvm/svm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index b78c691adea2..38821b0b78da 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2923,6 +2923,8 @@ static void nested_svm_inject_npf_exit(struct kvm_vcpu
*vcpu,
static void nested_svm_init_mmu_context(struct kvm_vcpu *vcpu)
{
WARN_ON(mmu_is_nested(vcpu));
+
+ vcpu->arch.mmu = >arch.guest_mmu;
kvm_init_shadow_mmu(vcpu);
vcpu->arch.mmu->set_cr3 = nested_svm_set_tdp_cr3;
vcpu->arch.mmu->get_cr3 = nested_svm_get_tdp_cr3;
@@ -2935,6 +2937,7 @@ static void nested_svm_init_mmu_context(struct kvm_vcpu
*vcpu)
static void nested_svm_uninit_mmu_context(struct kvm_vcpu *vcpu)
{
+ vcpu->arch.mmu = >arch.root_mmu;
vcpu->arch.walk_mmu = >arch.root_mmu;
}
@@ -3444,7 +3447,6 @@ static void enter_svm_guest_mode(struct vcpu_svm *svm,
u64 vmcb_gpa,
svm->vcpu.arch.hflags &= ~HF_HIF_MASK;
if (nested_vmcb->control.nested_ctl & SVM_NESTED_CTL_NP_ENABLE) {
- kvm_mmu_unload(>vcpu);
svm->nested.nested_cr3 = nested_vmcb->control.nested_cr3;
nested_svm_init_mmu_context(>vcpu);
}
--
2.19.2
Re: [PATCH] ASoC: xlnx: change license header format style
On Wed, Dec 19, 2018 at 07:17:04AM -0800, Christoph Hellwig wrote: > On Wed, Dec 19, 2018 at 03:10:40PM +0530, Maruthi Srinivas Bayyavarapu wrote: > > Changed License header from C to C++ style comment block. > Why this completely pointless uglification that goes counter to > the common style all over the kernel? I asked for it, when you end up with a C++ comment immediately adjacent to a C comment block it doesn't exactly look clean and intentional either. signature.asc Description: PGP signature
Re: [PATCH 2/3] dt-bindings: gpu: samsung-rotator: Document s5pv210 support
On Wed, 19 Dec 2018 at 17:04, Paweł Chmiel wrote: > > This commit documents new compatible for s5pv210 soc, > which will be also supported by this driver. > > Signed-off-by: Paweł Chmiel > --- > Documentation/devicetree/bindings/gpu/samsung-rotator.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt > b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt > index 82cd1ed0be93..78658dec6941 100644 > --- a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt > +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt > @@ -5,6 +5,7 @@ Required properties: > (a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210 > (b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412 > (c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250 > + (d) "samsung,s5pv210-rotator" for Rotator IP in S5PV210 How about putting it at beginning as the oldest chipset? This would require reordering the list so maybe let's remove the a/b/c list enumerations? They are kind of useless. Best regards, Krzysztof
Re: /proc/modules not showing any output
On Wed, Dec 19, 2018 at 9:28 PM Aruna Hewapathirane wrote: > > >> >> I think, on my test machine, by default, there are many modules which >> get added during boot up, which with vanilla kernel is not happening. >> Thanks for your input. >> >> Regards, >> >> ~Praveen. >> > > What does lsmod show you in the vanilla kernel ? If you want the same modules > to load in the vanilla > kernel folow steps given below: > > 1 -boot into the older 4.4.162-78-defaultkernel > 2 - change into the vanilla kernel source 4.20.0-rc6 builddirectory > 3 - $ lsmod > lsmod.txt > 4 - $ make LSMOD="lsmod.txt" localmodconfig > > Boot into your newly compiled vanilla kernel and run lsmod and smile :-) > > Hope this helps - Aruna > Thanks Aruna. This helps.
[PATCH] ARC: adjust memblock_reserve of kernel memory
In setup_arch_memory we reserve the memory area wherein the kernel is located. Current implementation may reserve more memory than it actually required in case of CONFIG_LINUX_LINK_BASE is not equal to CONFIG_LINUX_RAM_BASE. This happens because we calculate start of the reserved region relatively to the CONFIG_LINUX_RAM_BASE and end of the region relatively to the CONFIG_LINUX_RAM_BASE. For example in case of HSDK board we wasted 256MiB of physical memory: --->8-- Memory: 770416K/1048576K available (5496K kernel code, 240K rwdata, 1064K rodata, 2200K init, 275K bss, 278160K reserved, 0K cma-reserved) --->8-- Fix that. Cc: sta...@vger.kernel.org Signed-off-by: Eugeniy Paltsev --- arch/arc/mm/init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c index f8fe5668b30f..a56e6a8ed259 100644 --- a/arch/arc/mm/init.c +++ b/arch/arc/mm/init.c @@ -137,7 +137,8 @@ void __init setup_arch_memory(void) */ memblock_add_node(low_mem_start, low_mem_sz, 0); - memblock_reserve(low_mem_start, __pa(_end) - low_mem_start); + memblock_reserve(CONFIG_LINUX_LINK_BASE, +__pa(_end) - CONFIG_LINUX_LINK_BASE); #ifdef CONFIG_BLK_DEV_INITRD if (initrd_start) -- 2.14.5
Re: [PATCH] drm/xen-front: Make shmem backed display buffer coherent
Den 19.12.2018 09.18, skrev Oleksandr Andrushchenko:
On 12/18/18 9:20 PM, Noralf Trønnes wrote:
Den 27.11.2018 11.32, skrev Oleksandr Andrushchenko:
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content of the buffer which may
lead to screen artifacts. Make sure that the frontend's
memory is coherent and the backend always sees correct display
buffer content.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display
frontend")
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 62
+++--
1 file changed, 48 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 47ff019d3aef..c592735e49d2 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -33,8 +33,11 @@ struct xen_gem_object {
/* set for buffers allocated by the backend */
bool be_alloc;
- /* this is for imported PRIME buffer */
- struct sg_table *sgt_imported;
+ /*
+ * this is for imported PRIME buffer or the one allocated via
+ * drm_gem_get_pages.
+ */
+ struct sg_table *sgt;
};
static inline struct xen_gem_object *
@@ -77,10 +80,21 @@ static struct xen_gem_object
*gem_create_obj(struct drm_device *dev,
return xen_obj;
}
+struct sg_table *xen_drm_front_gem_get_sg_table(struct
drm_gem_object *gem_obj)
+{
+ struct xen_gem_object *xen_obj = to_xen_gem_obj(gem_obj);
+
+ if (!xen_obj->pages)
+ return ERR_PTR(-ENOMEM);
+
+ return drm_prime_pages_to_sg(xen_obj->pages, xen_obj->num_pages);
+}
+
static struct xen_gem_object *gem_create(struct drm_device *dev,
size_t size)
{
struct xen_drm_front_drm_info *drm_info = dev->dev_private;
struct xen_gem_object *xen_obj;
+ struct address_space *mapping;
int ret;
size = round_up(size, PAGE_SIZE);
@@ -113,10 +127,14 @@ static struct xen_gem_object
*gem_create(struct drm_device *dev, size_t size)
xen_obj->be_alloc = true;
return xen_obj;
}
+
/*
* need to allocate backing pages now, so we can share those
* with the backend
*/
Let's see if I understand what you're doing:
Here you say that the pages should be DMA accessible for devices that
can
only see 4GB.
Yes, your understanding is correct. As we are a para-virtualized
device we
do not have strict requirements for 32-bit DMA. But, via dma-buf export,
the buffer we create can be used by real HW, e.g. one can pass-through
real HW devices into a guest domain and they can import our buffer (yes,
they can be IOMMU backed and other conditions may apply).
So, this is why we are limiting to DMA32 here, just to allow more
possible
use-cases
+ mapping = xen_obj->base.filp->f_mapping;
+ mapping_set_gfp_mask(mapping, GFP_USER | __GFP_DMA32);
+
xen_obj->num_pages = DIV_ROUND_UP(size, PAGE_SIZE);
xen_obj->pages = drm_gem_get_pages(_obj->base);
if (IS_ERR_OR_NULL(xen_obj->pages)) {
@@ -125,8 +143,27 @@ static struct xen_gem_object *gem_create(struct
drm_device *dev, size_t size)
goto fail;
}
+ xen_obj->sgt = xen_drm_front_gem_get_sg_table(_obj->base);
+ if (IS_ERR_OR_NULL(xen_obj->sgt)){
+ ret = PTR_ERR(xen_obj->sgt);
+ xen_obj->sgt = NULL;
+ goto fail_put_pages;
+ }
+
+ if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
+ DMA_BIDIRECTIONAL)) {
Are you using the DMA streaming API as a way to flush the caches?
Yes
Does this mean that GFP_USER isn't making the buffer coherent?
No, it didn't help. I had a question [1] if there are any other better
way
to achieve the same, but didn't have any response yet. So, I implemented
it via DMA API which helped.
As Gerd says asking on the arm list is probably the best way of finding a
future proof solution and understanding what's going on.
But if you don't get any help there and you end up with the present
solution I suggest you add a comment that this is for flushing the caches
on arm. With the current code one can be led to believe that the driver
uses the dma address somewhere.
What about x86, does the problem exist there?
I wonder if you can call dma_unmap_sg() right away since the flushing has
already happened. That would contain this flushing "hack" inside the
gem_create function.
I also suggest calling drm_prime_pages_to_sg() directly to increase
readability, since the check in xen_drm_front_gem_get_sg_table() isn't
necessary for this use case.
Noralf.
Noralf.
+ ret = -EFAULT;
+ goto fail_free_sgt;
+ }
+
return xen_obj;
+fail_free_sgt:
+ sg_free_table(xen_obj->sgt);
+ xen_obj->sgt = NULL;
+fail_put_pages:
+ drm_gem_put_pages(_obj->base, xen_obj->pages,
Re: [WRONG] KVM: arm/arm64: vgic: fix off-by-one bug in vgic_get_irq()
Hi Gustavo,
On 19/12/2018 15:11, Gustavo A. R. Silva wrote:
> Hi Marc,
>
> This is wrong: commit 6022fcc0e87a0eb5e9a72b15ed70dd29ebcb7343
>
> The above is not my original patch and it should not be tagged for stable,
> as it introduces the same kind of bug I intended to fix:
>
> array_index_nospec() can now return kvm->arch.vgic.nr_spis +
> VGIC_NR_PRIVATE_IRQS
> and this is not what you want. So, in this case the following line of code
> is just fine as it is:
>
> intid = array_index_nospec(intid, kvm->arch.vgic.nr_spis +
> VGIC_NR_PRIVATE_IRQS);
>
>
> As the commit log says, my patch fixes:
>
> commit 41b87599c74300027f305d7b34368ec558978ff2
>
> not both:
>
> commit 41b87599c74300027f305d7b34368ec558978ff2
>
> and
>
> commit bea2ef803ade3359026d5d357348842bca9edcf1
>
> If you want to apply the fix on top of
> bea2ef803ade3359026d5d357348842bca9edcf1
> then you should apply this instead:
>
> diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
> index bb1a83345741..e607547c7bb0 100644
> --- a/virt/kvm/arm/vgic/vgic.c
> +++ b/virt/kvm/arm/vgic/vgic.c
> @@ -103,7 +103,7 @@ struct vgic_irq *vgic_get_irq(struct kvm *kvm, struct
> kvm_vcpu *vcpu,
> {
> /* SGIs and PPIs */
> if (intid <= VGIC_MAX_PRIVATE) {
> - intid = array_index_nospec(intid, VGIC_MAX_PRIVATE);
> + intid = array_index_nospec(intid, VGIC_MAX_PRIVATE + 1);
> return >arch.vgic_cpu.private_irqs[intid];
> }
>
>
> The commit log should remain the same.
I indeed completely fscked up the conflict resolution, clearly not
engaging my brain. I'll fix that quickly.
Thanks for the heads up.
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH 08/14] mm, compaction: Use the page allocator bulk-free helper for lists of pages
On Tue, Dec 18, 2018 at 10:55:31AM +0100, Vlastimil Babka wrote:
> On 12/15/18 12:03 AM, Mel Gorman wrote:
> > release_pages() is a simpler version of free_unref_page_list() but it
> > tracks the highest PFN for caching the restart point of the compaction
> > free scanner. This patch optionally tracks the highest PFN in the core
> > helper and converts compaction to use it.
> >
> > Signed-off-by: Mel Gorman
>
> Acked-by: Vlastimil Babka
>
> Nit below:
>
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -2961,18 +2961,26 @@ void free_unref_page(struct page *page)
> > /*
> > * Free a list of 0-order pages
> > */
> > -void free_unref_page_list(struct list_head *list)
> > +void __free_page_list(struct list_head *list, bool dropref,
> > + unsigned long *highest_pfn)
> > {
> > struct page *page, *next;
> > unsigned long flags, pfn;
> > int batch_count = 0;
> >
> > + if (highest_pfn)
> > + *highest_pfn = 0;
> > +
> > /* Prepare pages for freeing */
> > list_for_each_entry_safe(page, next, list, lru) {
> > + if (dropref)
> > + WARN_ON_ONCE(!put_page_testzero(page));
>
> That will warn just once, but then page will remain with elevated count
> and free_unref_page_prepare() will warn either immediately or later
> depending on DEBUG_VM, for each page.
> Also IIRC it's legal for basically anyone to do get_page_unless_zero()
> and later put_page(), and this would now cause warning. Maybe just test
> for put_page_testzero() result without warning, and continue? Hm but
> then we should still do a list_del() and that becomes racy after
> dropping our ref...
>
While there are cases where such a pattern is legal, this function
simply does not expect it and the callers do not violate the rule. If it
ever gets a new user that makes mistakes, they'll get the warning. Sure,
the page leaks but it'll be in a state where it's unsafe to do anything
else with it.
--
Mel Gorman
SUSE Labs
[GIT PULL] mtd: Changes for 4.21
Hello Linus,
Here is the MTD PR for 4.21 coming a bit earlier than usual (hope this
is not a problem).
Regards,
Boris
The following changes since commit 2595646791c319cadfdbf271563aac97d0843dc7:
Linux 4.20-rc5 (2018-12-02 15:07:55 -0800)
are available in the Git repository at:
git://git.infradead.org/linux-mtd.git tags/mtd/for-4.21
for you to fetch changes up to f366d3854ec0fec0f9949dac46431598614a956b:
Merge tag 'spi-nor/for-4.21' of git://git.infradead.org/linux-mtd into
mtd/next (2018-12-18 20:00:52 +0100)
SPI NOR Changes
Core changes:
- Parse the 4BAIT SFDP section
- Add a bunch of SPI NOR entries to the flash_info table
- Add the concept of SFDP fixups and use it to fix a bug on MX25L25635F
- A bunch of minor cleanups/comestic changes
NAND changes:
NAND core changes:
- kernel-doc miscellaneous fixes.
- Third batch of fixes/cleanup to the raw NAND core impacting various
controller drivers (ams-delta, marvell, fsmc, denali, tegra, vf610):
* Stopping to pass mtd_info objects to internal functions
* Reorganizing code to avoid forward declarations
* Dropping useless test in nand_legacy_set_defaults()
* Moving nand_exec_op() to internal.h
* Adding nand_[de]select_target() helpers
* Passing the CS line to be selected in struct nand_operation
* Making ->select_chip() optional when ->exec_op() is implemented
* Deprecating the ->select_chip() hook
* Moving the ->exec_op() method to nand_controller_ops
* Moving ->setup_data_interface() to nand_controller_ops
* Deprecating the dummy_controller field
* Fixing JEDEC detection
* Providing a helper for polling GPIO R/B pin
Raw NAND chip drivers changes:
- Macronix:
* Flagging 1.8V AC chips with a broken GET_FEATURES(TIMINGS)
Raw NAND controllers drivers changes:
- Ams-delta:
* Fixing the error path
* SPDX tag added
* May be compiled with COMPILE_TEST=y
* Conversion to ->exec_op() interface
* Dropping .IOADDR_R/W use
* Use GPIO API for data I/O
- Denali:
* Removing denali_reset_banks()
* Removing ->dev_ready() hook
* Including instead of
* Changes to comply with the above fixes/cleanup done in the core.
- FSMC:
* Adding an SPDX tag to replace the license text
* Making conversion from chip to fsmc consistent
* Fixing unchecked return value in fsmc_read_page_hwecc
* Changes to comply with the above fixes/cleanup done in the core.
- Marvell:
* Preventing timeouts on a loaded machine (fix)
* Changes to comply with the above fixes/cleanup done in the core.
- OMAP2:
* Pass the parent of pdev to dma_request_chan() (fix)
- R852:
* Use generic DMA API
- sh_flctl:
* Converting to SPDX identifiers
- Sunxi:
* Write pageprog related opcodes to the right register: WCMD_SET (fix)
- Tegra:
* Stop implementing ->select_chip()
- VF610:
* Adding an SPDX tag to replace the license text
* Changes to comply with the above fixes/cleanup done in the core.
- Various trivial/spelling/coding style fixes.
SPI-NAND drivers changes:
- Removing the depreacated mt29f_spinand driver from staging.
- Adding support for:
* Toshiba TC58CVG2S0H
* GigaDevice GD5FxGQ4xA
* Winbond W25N01GV
JFFS2 changes:
- Fix a lockdep issue
MTD changes:
- Rework the physmap driver to merge gpio-addr-flash and physmap_of
in it
- Add a new compatible for RedBoot partitions
- Make sub-partitions RW if the parent partition was RO because of a
mis-alignment
- Add pinctrl support to the
- Addition of /* fall-through */ comments where appropriate
- Various minor fixes and cleanups
Other changes:
- Update my email address
Alexander Sverdlin (1):
mtd: spi-nor: Add support for mx25u12835f
Boris Brezillon (61):
mtd: maps: physmap: Add SPDX header
mtd: maps: physmap: Rename ->map and ->mtd into ->maps and ->mtds
mtd: maps: physmap: Use platform_get_resource() to retrieve iomem
resources
mtd: maps: physmap: Use dev_notice() and a %pR specifier
mtd: maps: physmap: Use devm_ioremap_resource()
mtd: maps: physmap: Remove the MAX_RESOURCES limitation
mtd: maps: physmap: Check mtd_device_{parse_register, unregister}() ret
code
mtd: maps: physmap: Return -ENOMEM directly when info allocation fails
mtd: maps: physmap: Fix coding style issues reported by checkpatch
mtd: maps: Prepare merging of physmap and physmap_of
mtd: maps: Merge physmap_of.c into physmap-core.c
mtd: maps: Rename physmap_of_{versatile, gemini} into physmap-{versatile,
gemini}
mtd: maps: Merge gpio-addr-flash.c into physmap-core.c
staging: Remove the mt29f_spinand driver
mtd: maps: Get rid of the latch-addr-flash driver
mtd: rawnand: Stop passing mtd_info objects to internal functions
mtd:
[PATCH 3/3] ARM: dts: s5pv210: Add node for exynos-rotator
This commit adds node for Exynos Rorator device,
so it can be used on all s5pv210 based devices.
Signed-off-by: Paweł Chmiel
---
arch/arm/boot/dts/s5pv210.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/s5pv210.dtsi b/arch/arm/boot/dts/s5pv210.dtsi
index 75f454a210d6..a5463003c7f6 100644
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -542,6 +542,15 @@
#dma-requests = <1>;
};
+ rotator: rotator@fa30 {
+ compatible = "samsung,s5pv210-rotator";
+ reg = <0xfa30 0x1000>;
+ interrupt-parent = <>;
+ interrupts = <4>;
+ clocks = < CLK_ROTATOR>;
+ clock-names = "rotator";
+ };
+
i2c1: i2c@fab0 {
compatible = "samsung,s3c2440-i2c";
reg = <0xfab0 0x1000>;
--
2.17.1
[PATCH 2/3] dt-bindings: gpu: samsung-rotator: Document s5pv210 support
This commit documents new compatible for s5pv210 soc, which will be also supported by this driver. Signed-off-by: Paweł Chmiel --- Documentation/devicetree/bindings/gpu/samsung-rotator.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt index 82cd1ed0be93..78658dec6941 100644 --- a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt @@ -5,6 +5,7 @@ Required properties: (a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210 (b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412 (c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250 + (d) "samsung,s5pv210-rotator" for Rotator IP in S5PV210 - reg : Physical base address of the IP registers and length of memory mapped region. -- 2.17.1
[PATCH 0/3] drm/exynos: rotator: Add support for s5pv210
This patchset adds support for s5pv210 soc, into Samsung DRM Rotator driver. Currently only NV12 and XRGB formats are supported. It was tested by using simple tool from https://www.spinics.net/lists/linux-samsung-soc/msg60498.html Paweł Chmiel (3): drm/exynos: rotator: Add support for s5pv210 dt-bindings: gpu: samsung-rotator: Document s5pv210 support ARM: dts: s5pv210: Add node for exynos-rotator .../bindings/gpu/samsung-rotator.txt | 1 + arch/arm/boot/dts/s5pv210.dtsi| 9 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 23 +++ 3 files changed, 33 insertions(+) -- 2.17.1
[PATCH 1/3] drm/exynos: rotator: Add support for s5pv210
This commit adds support for s5pv210.
Currently only NV12 and XRGB formats are supported.
It was tested by using tool from
https://www.spinics.net/lists/linux-samsung-soc/msg60498.html
Signed-off-by: Paweł Chmiel
---
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 23 +
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index a820a68429b9..a822d340ccf6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -357,6 +357,11 @@ static int rotator_runtime_resume(struct device *dev)
}
#endif
+static const struct drm_exynos_ipp_limit rotator_s5pv210_rbg888_limits[] = {
+ { IPP_SIZE_LIMIT(BUFFER, .h = { 8, SZ_16K }, .v = { 8, SZ_16K }) },
+ { IPP_SIZE_LIMIT(AREA, .h.align = 2, .v.align = 2) },
+};
+
static const struct drm_exynos_ipp_limit rotator_4210_rbg888_limits[] = {
{ IPP_SIZE_LIMIT(BUFFER, .h = { 8, SZ_16K }, .v = { 8, SZ_16K }) },
{ IPP_SIZE_LIMIT(AREA, .h.align = 4, .v.align = 4) },
@@ -372,6 +377,11 @@ static const struct drm_exynos_ipp_limit
rotator_5250_rbg888_limits[] = {
{ IPP_SIZE_LIMIT(AREA, .h.align = 2, .v.align = 2) },
};
+static const struct drm_exynos_ipp_limit rotator_s5pv210_yuv_limits[] = {
+ { IPP_SIZE_LIMIT(BUFFER, .h = { 32, SZ_64K }, .v = { 32, SZ_64K }) },
+ { IPP_SIZE_LIMIT(AREA, .h.align = 8, .v.align = 8) },
+};
+
static const struct drm_exynos_ipp_limit rotator_4210_yuv_limits[] = {
{ IPP_SIZE_LIMIT(BUFFER, .h = { 32, SZ_64K }, .v = { 32, SZ_64K }) },
{ IPP_SIZE_LIMIT(AREA, .h.align = 8, .v.align = 8) },
@@ -382,6 +392,11 @@ static const struct drm_exynos_ipp_limit
rotator_4412_yuv_limits[] = {
{ IPP_SIZE_LIMIT(AREA, .h.align = 8, .v.align = 8) },
};
+static const struct exynos_drm_ipp_formats rotator_s5pv210_formats[] = {
+ { IPP_SRCDST_FORMAT(XRGB, rotator_s5pv210_rbg888_limits) },
+ { IPP_SRCDST_FORMAT(NV12, rotator_s5pv210_yuv_limits) },
+};
+
static const struct exynos_drm_ipp_formats rotator_4210_formats[] = {
{ IPP_SRCDST_FORMAT(XRGB, rotator_4210_rbg888_limits) },
{ IPP_SRCDST_FORMAT(NV12, rotator_4210_yuv_limits) },
@@ -397,6 +412,11 @@ static const struct exynos_drm_ipp_formats
rotator_5250_formats[] = {
{ IPP_SRCDST_FORMAT(NV12, rotator_4412_yuv_limits) },
};
+static const struct rot_variant rotator_s5pv210_data = {
+ .formats = rotator_s5pv210_formats,
+ .num_formats = ARRAY_SIZE(rotator_s5pv210_formats),
+};
+
static const struct rot_variant rotator_4210_data = {
.formats = rotator_4210_formats,
.num_formats = ARRAY_SIZE(rotator_4210_formats),
@@ -414,6 +434,9 @@ static const struct rot_variant rotator_5250_data = {
static const struct of_device_id exynos_rotator_match[] = {
{
+ .compatible = "samsung,s5pv210-rotator",
+ .data = _s5pv210_data,
+ }, {
.compatible = "samsung,exynos4210-rotator",
.data = _4210_data,
}, {
--
2.17.1
Re: [PATCH v3 4/6] usb: gadget: add mechanism to specify an explicit status stage
On Wed, 19 Dec 2018, Paul Elder wrote:
> A usb gadget function driver may or may not want to delay the status
> stage of a control OUT request. An instance it might want to is to
-^
Typo: missing "where"
> asynchronously validate the data of a class-specific request.
>
> A function driver that wants an explicit status stage should set the
> newly added explicit_status flag of the usb_request corresponding to the
> data stage. Later on the function driver can explicitly complete the
> status stage by enqueueing a usb_request for ACK, or calling
> usb_ep_set_halt() for STALL.
>
> To support both explicit and implicit status stages, a UDC driver must
> call the newly added usb_gadget_control_complete function right after
> calling usb_gadget_giveback_request. The status of the request that was
> just given back must be fed into usb_gadget_control_complete. To support
> the explicit status stage, it might then check what stage the
> usb_request was queued in, and send an ACK.
I don't really understand that last sentence. Perhaps what you mean is
that depending on the direction of the control transfer, the driver
should either ACK the host's 0-length data packet (control-IN) or send
a 0-length DATA1 packet (control-OUT)?
> Signed-off-by: Paul Elder
> v1 Reviewed-by: Laurent Pinchart
> ---
> Changes from v2:
>
> Add status parameter to usb_gadget_control_complete, so that a
> usb_request is not queued if the status of the just given back request
> is nonzero.
>
> Changes from v1:
>
> Complete change of API. Now we use a flag that should be set in the
> usb_request that is queued for the data stage to signal to the UDC that
> we want to delay the status stage (as opposed to setting a flag in the
> UDC itself, that persists across all requests). We now also provide a
> function for UDC drivers to very easily allow implicit status stages, to
> mitigate the need to convert all function drivers to this new API at
> once, and to make it easier for UDC drivers to convert.
>
> drivers/usb/gadget/udc/core.c | 34 ++
> include/linux/usb/gadget.h| 10 ++
> 2 files changed, 44 insertions(+)
>
> diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
> index af88b48c1cea..0a0ccd2b7639 100644
> --- a/drivers/usb/gadget/udc/core.c
> +++ b/drivers/usb/gadget/udc/core.c
> @@ -894,6 +894,40 @@ EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
>
> /* -
> */
>
> +/**
> + * usb_gadget_control_complete - complete the status stage of a control
> + * request, or delay it
> + * Context: in_interrupt()
> + *
> + * @gadget: gadget whose control request's status stage should be completed
> + * @explicit_status: true to delay status stage, false to complete here
> + * @status: completion code of previously completed request
> + *
> + * This is called by device controller drivers after returning the completed
> + * request back to the gadget layer, to either complete or delay the status
> + * stage.
> + */
> +void usb_gadget_control_complete(struct usb_gadget *gadget,
> + unsigned int explicit_status, int status)
> +{
> + struct usb_request *req;
> +
> + if (explicit_status || status)
> + return;
> +
> + /* Send an implicit status-stage request for ep0 */
> + req = usb_ep_alloc_request(gadget->ep0, GFP_ATOMIC);
> + if (req) {
> + req->length = 0;
> + req->explicit_status = 0;
Oops! I should have spotted this in the previous version, sorry. The
implicit status-stage request should have its ->explicit_status set, so
that we don't try to submit another status request when this one
completes.
Also, would it look better if the type of explicit_status was bool
instead of unsigned int (both here and in the structure)?
Either way, once this change is made:
Acked-by: Alan Stern
> + req->complete = usb_ep_free_request;
> + usb_ep_queue(gadget->ep0, req, GFP_ATOMIC);
> + }
> +}
> +EXPORT_SYMBOL_GPL(usb_gadget_control_complete);
> +
> +/* -
> */
> +
> /**
> * gadget_find_ep_by_name - returns ep whose name is the same as sting passed
> * in second parameter or NULL if searched endpoint not found
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index e5cd84a0f84a..1e3a23637468 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -73,6 +73,7 @@ struct usb_ep;
> * Note that for writes (IN transfers) some data bytes may still
> * reside in a device-side FIFO when the request is reported as
> * complete.
> + * @explicit_status: If true, delays the status stage
> *
> * These are allocated/freed through the endpoint they're used with. The
> * hardware's driver can add extra per-request data to the memory it
Re: [PATCH 2/5] dt-bindings: media: sun6i: Add vcc-csi supply property
On Mon, Dec 03, 2018 at 06:11:35PM +0800, Chen-Yu Tsai wrote: > On Mon, Dec 3, 2018 at 6:08 PM Jagan Teki wrote: > > > > Most of the Allwinner A64 CSI controllers are supply with > > VCC-PE pin. which need to supply for some of the boards to > > trigger the power. > > > > So, document the supply property as vcc-csi so-that the required > > board can eable it via device tree. > > > > Used vcc-csi instead of vcc-pe to have better naming convention > > wrt other controller pin supplies. > > This is not related to the CSI controller. It belongs in the pin > controller, but that has its own set of problems like possible > circular dependencies. That might be a better choice, but I think most platforms put the supply in the module node. But that wouldn't work well if the module is not used and you want to use the pins for GPIO or some other function. Maybe we don't hit that property because most I/O supplies are always on. Rob
Re: [PATCH v3 0/5] alpha: system call table generation support
On Fri, Dec 14, 2018 at 10:18 AM Firoz Khan wrote: > > Hi Folks, > > On Tue, 13 Nov 2018 at 15:02, Firoz Khan wrote: > > > > The purpose of this patch series is, we can easily > > add/modify/delete system call table support by cha- > > nging entry in syscall.tbl file instead of manually > > changing many files. The other goal is to unify the > > system call table generation support implementation > > across all the architectures. > > > > The system call tables are in different format in > > all architecture. It will be difficult to manually > > add, modify or delete the system calls in the resp- > > ective files manually. To make it easy by keeping a > > script and which'll generate uapi header file and > > syscall table file. > > > > syscall.tbl contains the list of available system > > calls along with system call number and correspond- > > ing entry point. Add a new system call in this arch- > > itecture will be possible by adding new entry in the > > syscall.tbl file. > > > > Adding a new table entry consisting of: > > - System call number. > > - ABI. > > - System call name. > > - Entry point name. > > > > ARM, s390 and x86 architecuture does exist the sim- > > ilar support. I leverage their implementation to > > come up with a generic solution. > > > > I have done the same support for work for ia64, m68k, > > microblaze, mips, parisc, powerpc, sh, sparc and xtensa. > > Below mentioned git repository contains more details > > about the workflow. > > > > https://github.com/frzkhn/system_call_table_generator/ > > > > Finally, this is the ground work to solve the Y2038 > > issue. We need to add two dozen of system calls to > > solve Y2038 issue. So this patch series will help to > > add new system calls easily by adding new entry in > > the syscall.tbl. > > > > changes since v2: > > - changed from generic-y to generated-y in Kbuild. > > - made changes in syscall.tbl for removing entry - > >alpha_ni_syscall. > > > > changes since v1: > > - optimized/updated the syscall table generation > >scripts. > > - fixed all mixed indentation issues in syscall.tbl. > > - added "comments" in syscall.tbl. > > - enclosed __NR_sycalls macro with __KERNEL__. > > - added missing new line. > > > > Firoz Khan (5): > > alpha: move __IGNORE* entries to non uapi header > > alpha: remove CONFIG_OSF4_COMPAT flag from syscall table > > alpha: add __NR_syscalls along with NR_SYSCALLS > > alpha: add system call table generation support > > alpha: generate uapi header and syscall table header files > > Could someone review this patch series and queue it for 4.21 > through alpha tree would be great. Thank you! I'll take a look.
Re: [PATCH 5/5] arm64: dts: allwinner: a64-amarula-relic: Add OV5640 camera node
On Thu, Dec 06, 2018 at 04:43:33PM +0530, Jagan Teki wrote:
> On Mon, Dec 3, 2018 at 3:55 PM Chen-Yu Tsai wrote:
> >
> > On Mon, Dec 3, 2018 at 6:08 PM Jagan Teki
> > wrote:
> > >
> > > Amarula A64-Relic board by default bound with OV5640 camera,
> > > so add support for it with below pin information.
> > >
> > > - PE13, PE12 via i2c-gpio bitbanging
> > > - CLK_CSI_MCLK as external clock
> > > - PE1 as external clock pin muxing
> > > - DLDO3 as vcc-csi supply
> > > - DLDO3 as AVDD supply
> > > - ALDO1 as DOVDD supply
> > > - ELDO3 as DVDD supply
> > > - PE14 gpio for reset pin
> > > - PE15 gpio for powerdown pin
> > >
> > > Signed-off-by: Jagan Teki
> > > ---
> > > .../allwinner/sun50i-a64-amarula-relic.dts| 54 +++
> > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 ++
> > > 2 files changed, 59 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > > b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > > index 6cb2b7f0c817..9ac6d773188b 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > > @@ -22,6 +22,41 @@
> > > stdout-path = "serial0:115200n8";
> > > };
> > >
> > > + i2c-csi {
> > > + compatible = "i2c-gpio";
> > > + sda-gpios = < 4 13
> > > (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
> > > + scl-gpios = < 4 12
> > > (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
> >
> > FYI our hardware doesn't do open drain.
>
> True, but the kernel is enforcing it seems, from the change from [1].
> does that mean Linux use open drain even though hardware doens't have?
> or did I miss anything?
It's forced because you can't do I2C without open drain. Things like the
slave doing clock stretching won't work.
Rob
[PATCH 5/8] scsi: hisi_sas: Add debugfs for port registers
From: Luo Jiaxing
This patch create debugfs file for port register and add file operations.
Signed-off-by: Luo Jiaxing
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_sas_main.c | 43 ++
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 55 ++
2 files changed, 98 insertions(+)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index fd85934..fbd9b4a 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -2604,9 +2604,38 @@ static int hisi_sas_debugfs_global_open(struct inode
*inode, struct file *filp)
.owner = THIS_MODULE,
};
+static int hisi_sas_debugfs_port_show(struct seq_file *s, void *p)
+{
+ struct hisi_sas_phy *phy = s->private;
+ struct hisi_hba *hisi_hba = phy->hisi_hba;
+ const struct hisi_sas_hw *hw = hisi_hba->hw;
+ const struct hisi_sas_debugfs_reg *reg_port = hw->debugfs_reg_port;
+ u32 *databuf = hisi_hba->debugfs_port_reg[phy->sas_phy.id];
+
+ hisi_sas_debugfs_print_reg(databuf, reg_port, s);
+
+ return 0;
+}
+
+static int hisi_sas_debugfs_port_open(struct inode *inode, struct file *filp)
+{
+ return single_open(filp, hisi_sas_debugfs_port_show, inode->i_private);
+}
+
+static const struct file_operations hisi_sas_debugfs_port_fops = {
+ .open = hisi_sas_debugfs_port_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .owner = THIS_MODULE,
+};
+
static void hisi_sas_debugfs_create_files(struct hisi_hba *hisi_hba)
{
struct dentry *dump_dentry;
+ struct dentry *dentry;
+ char name[256];
+ int p;
/* Create dump dir inside device dir */
dump_dentry = debugfs_create_dir("dump", hisi_hba->debugfs_dir);
@@ -2618,6 +2647,20 @@ static void hisi_sas_debugfs_create_files(struct
hisi_hba *hisi_hba)
if (!debugfs_create_file("global", 0400, dump_dentry, hisi_hba,
_sas_debugfs_global_fops))
goto fail;
+
+ /* Create port dir and files */
+ dentry = debugfs_create_dir("port", dump_dentry);
+ if (!dentry)
+ goto fail;
+
+ for (p = 0; p < hisi_hba->n_phy; p++) {
+ snprintf(name, 256, "%d", p);
+ if (!debugfs_create_file(name, 0400, dentry,
+_hba->phy[p],
+_sas_debugfs_port_fops))
+ goto fail;
+ }
+
return;
fail:
debugfs_remove_recursive(hisi_hba->debugfs_dir);
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index ca3d13b..cda1e40 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
@@ -186,6 +186,7 @@
#define CHL_INT0_MSK (PORT_BASE + 0x1c0)
#define CHL_INT1_MSK (PORT_BASE + 0x1c4)
#define CHL_INT2_MSK (PORT_BASE + 0x1c8)
+#define SAS_EC_INT_COAL_TIME (PORT_BASE + 0x1cc)
#define CHL_INT_COAL_EN(PORT_BASE + 0x1d0)
#define SAS_RX_TRAIN_TIMER (PORT_BASE + 0x2a4)
#define PHY_CTRL_RDY_MSK (PORT_BASE + 0x2b0)
@@ -205,6 +206,7 @@
#define ERR_CNT_DWS_LOST (PORT_BASE + 0x380)
#define ERR_CNT_RESET_PROB (PORT_BASE + 0x384)
#define ERR_CNT_INVLD_DW (PORT_BASE + 0x390)
+#define ERR_CNT_CODE_ERR (PORT_BASE + 0x394)
#define ERR_CNT_DISP_ERR (PORT_BASE + 0x398)
#define DEFAULT_ITCT_HW2048 /* reset value, not reprogrammed */
@@ -2339,7 +2341,60 @@ static ssize_t intr_coal_count_v3_hw_store(struct device
*dev,
NULL
};
+static const struct hisi_sas_debugfs_reg_lu debugfs_port_reg_lu[] = {
+ HISI_SAS_DEBUGFS_REG(PHY_CFG),
+ HISI_SAS_DEBUGFS_REG(HARD_PHY_LINKRATE),
+ HISI_SAS_DEBUGFS_REG(PROG_PHY_LINK_RATE),
+ HISI_SAS_DEBUGFS_REG(PHY_CTRL),
+ HISI_SAS_DEBUGFS_REG(SL_CFG),
+ HISI_SAS_DEBUGFS_REG(AIP_LIMIT),
+ HISI_SAS_DEBUGFS_REG(SL_CONTROL),
+ HISI_SAS_DEBUGFS_REG(RX_PRIMS_STATUS),
+ HISI_SAS_DEBUGFS_REG(TX_ID_DWORD0),
+ HISI_SAS_DEBUGFS_REG(TX_ID_DWORD1),
+ HISI_SAS_DEBUGFS_REG(TX_ID_DWORD2),
+ HISI_SAS_DEBUGFS_REG(TX_ID_DWORD3),
+ HISI_SAS_DEBUGFS_REG(TX_ID_DWORD4),
+ HISI_SAS_DEBUGFS_REG(TX_ID_DWORD5),
+ HISI_SAS_DEBUGFS_REG(TX_ID_DWORD6),
+ HISI_SAS_DEBUGFS_REG(TXID_AUTO),
+ HISI_SAS_DEBUGFS_REG(RX_IDAF_DWORD0),
+ HISI_SAS_DEBUGFS_REG(RXOP_CHECK_CFG_H),
+ HISI_SAS_DEBUGFS_REG(STP_LINK_TIMER),
+ HISI_SAS_DEBUGFS_REG(STP_LINK_TIMEOUT_STATE),
+ HISI_SAS_DEBUGFS_REG(CON_CFG_DRIVER),
+ HISI_SAS_DEBUGFS_REG(SAS_SSP_CON_TIMER_CFG),
+ HISI_SAS_DEBUGFS_REG(SAS_SMP_CON_TIMER_CFG),
+ HISI_SAS_DEBUGFS_REG(SAS_STP_CON_TIMER_CFG),
+
[PATCH RFC lora-next 1/4] net: lora: sx125x sx1301: correct style warnings
Checkpatch highlights some style issues which need to be addressed.
Signed-off-by: Ben Whitten
---
drivers/net/lora/sx125x.c | 20 +--
drivers/net/lora/sx1301.c | 52 ++-
drivers/net/lora/sx1301.h | 7 +++---
3 files changed, 45 insertions(+), 34 deletions(-)
diff --git a/drivers/net/lora/sx125x.c b/drivers/net/lora/sx125x.c
index b7ca782b9386..1a941f663c52 100644
--- a/drivers/net/lora/sx125x.c
+++ b/drivers/net/lora/sx125x.c
@@ -49,7 +49,7 @@ struct sx125x_priv {
struct device *dev;
struct regmap *regmap;
- struct regmap_field
*regmap_fields[ARRAY_SIZE(sx125x_regmap_fields)];
+ struct regmap_field *regmap_fields[ARRAY_SIZE(sx125x_regmap_fields)];
};
#define to_clkout(_hw) container_of(_hw, struct sx125x_priv, clkout_hw)
@@ -67,13 +67,13 @@ static struct regmap_config __maybe_unused
sx125x_regmap_config = {
};
static int sx125x_field_write(struct sx125x_priv *priv,
- enum sx125x_fields field_id, u8 val)
+ enum sx125x_fields field_id, u8 val)
{
return regmap_field_write(priv->regmap_fields[field_id], val);
}
static int sx125x_field_read(struct sx125x_priv *priv,
- enum sx125x_fields field_id, unsigned int *val)
+enum sx125x_fields field_id, unsigned int *val)
{
return regmap_field_read(priv->regmap_fields[field_id], val);
}
@@ -149,8 +149,12 @@ static int sx125x_register_clock_provider(struct
sx125x_priv *priv)
init.num_parents = 1;
priv->clkout_hw.init =
- of_property_read_string_index(dev->of_node, "clock-output-names", 0,
- );
+ ret = of_property_read_string_index(dev->of_node, "clock-output-names",
+ 0, );
+ if (ret) {
+ dev_err(dev, "unable to find output name\n");
+ return ret;
+ }
priv->clkout = devm_clk_register(dev, >clkout_hw);
if (IS_ERR(priv->clkout)) {
@@ -158,7 +162,7 @@ static int sx125x_register_clock_provider(struct
sx125x_priv *priv)
return PTR_ERR(priv->clkout);
}
ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_simple_get,
- >clkout_hw);
+>clkout_hw);
return ret;
}
@@ -180,8 +184,8 @@ static int __maybe_unused sx125x_regmap_probe(struct device
*dev, struct regmap
const struct reg_field *reg_fields = sx125x_regmap_fields;
priv->regmap_fields[i] = devm_regmap_field_alloc(dev,
- priv->regmap,
- reg_fields[i]);
+priv->regmap,
+reg_fields[i]);
if (IS_ERR(priv->regmap_fields[i])) {
ret = PTR_ERR(priv->regmap_fields[i]);
dev_err(dev, "Cannot allocate regmap field: %d\n", ret);
diff --git a/drivers/net/lora/sx1301.c b/drivers/net/lora/sx1301.c
index 23cbddc364e5..e75df93b96d8 100644
--- a/drivers/net/lora/sx1301.c
+++ b/drivers/net/lora/sx1301.c
@@ -1,6 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * Semtech SX1301 LoRa concentrator
+/* Semtech SX1301 LoRa concentrator
*
* Copyright (c) 2018 Andreas Färber
* Copyright (c) 2018 Ben Whitten
@@ -55,12 +54,13 @@ static struct regmap_config sx1301_regmap_config = {
};
static int sx1301_field_write(struct sx1301_priv *priv,
- enum sx1301_fields field_id, u8 val)
+ enum sx1301_fields field_id, u8 val)
{
return regmap_field_write(priv->regmap_fields[field_id], val);
}
-static int sx1301_agc_ram_read(struct sx1301_priv *priv, u8 addr, unsigned int
*val)
+static int sx1301_agc_ram_read(struct sx1301_priv *priv, u8 addr,
+ unsigned int *val)
{
int ret;
@@ -79,7 +79,8 @@ static int sx1301_agc_ram_read(struct sx1301_priv *priv, u8
addr, unsigned int *
return 0;
}
-static int sx1301_arb_ram_read(struct sx1301_priv *priv, u8 addr, unsigned int
*val)
+static int sx1301_arb_ram_read(struct sx1301_priv *priv, u8 addr,
+ unsigned int *val)
{
int ret;
@@ -98,7 +99,8 @@ static int sx1301_arb_ram_read(struct sx1301_priv *priv, u8
addr, unsigned int *
return 0;
}
-static int sx1301_load_firmware(struct sx1301_priv *priv, int mcu, const
struct firmware *fw)
+static int sx1301_load_firmware(struct sx1301_priv *priv, int mcu,
+ const struct firmware *fw)
{
u8 *buf;
enum sx1301_fields rst, select_mux;
@@ -165,7 +167,8 @@ static int sx1301_load_firmware(struct sx1301_priv *priv,
int mcu, const struct
}
if (memcmp(fw->data, buf, fw->size)) {
-
[PATCH 3/8] scsi: hisi_sas: Take debugfs snapshot for all regs
From: Luo Jiaxing
This patch take snapshot for global regs, port regs, CQ, DQ, IOST, ITCT.
Then, Add code for snapshot trig and generate dump directory.
Signed-off-by: Luo Jiaxing
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_sas.h | 15 +++-
drivers/scsi/hisi_sas/hisi_sas_main.c | 125 +
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 9 ++-
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 37 +-
4 files changed, 180 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/hisi_sas/hisi_sas.h b/drivers/scsi/hisi_sas/hisi_sas.h
index eca7e47..3b5fd6d 100644
--- a/drivers/scsi/hisi_sas/hisi_sas.h
+++ b/drivers/scsi/hisi_sas/hisi_sas.h
@@ -223,6 +223,12 @@ struct hisi_sas_slot {
struct hisi_sas_debugfs_reg {
int count;
+ int base_off;
+ union {
+ u32 (*read_global_reg)(struct hisi_hba *hisi_hba, u32 off);
+ u32 (*read_port_reg)(struct hisi_hba *hisi_hba, int port,
+u32 off);
+ };
};
struct hisi_sas_hw {
@@ -264,8 +270,10 @@ struct hisi_sas_hw {
u32 (*get_phys_state)(struct hisi_hba *hisi_hba);
int (*write_gpio)(struct hisi_hba *hisi_hba, u8 reg_type,
u8 reg_index, u8 reg_count, u8 *write_data);
- void (*wait_cmds_complete_timeout)(struct hisi_hba *hisi_hba,
- int delay_ms, int timeout_ms);
+ int (*wait_cmds_complete_timeout)(struct hisi_hba *hisi_hba,
+ int delay_ms, int timeout_ms);
+ void (*snapshot_prepare)(struct hisi_hba *hisi_hba);
+ void (*snapshot_restore)(struct hisi_hba *hisi_hba);
int max_command_entries;
int complete_hdr_size;
struct scsi_host_template *sht;
@@ -337,6 +345,7 @@ struct hisi_hba {
const struct hisi_sas_hw *hw; /* Low level hw interface */
unsigned long sata_dev_bitmap[BITS_TO_LONGS(HISI_SAS_MAX_DEVICES)];
struct work_struct rst_work;
+ struct work_struct debugfs_work;
u32 phy_state;
u32 intr_coal_ticks;/* Time of interrupt coalesce in us */
u32 intr_coal_count;/* Interrupt count to coalesce */
@@ -350,6 +359,7 @@ struct hisi_hba {
struct hisi_sas_itct *debugfs_itct;
struct dentry *debugfs_dir;
+ struct dentry *debugfs_dump_dentry;
};
/* Generic HW DMA host memory structures */
@@ -517,4 +527,5 @@ extern bool hisi_sas_notify_phy_event(struct hisi_sas_phy
*phy,
extern void hisi_sas_controller_reset_done(struct hisi_hba *hisi_hba);
extern void hisi_sas_debugfs_init(struct hisi_hba *hisi_hba);
extern void hisi_sas_debugfs_exit(struct hisi_hba *hisi_hba);
+extern void hisi_sas_debugfs_work_handler(struct work_struct *work);
#endif
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 0b0dbaab..742f71a 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -1429,6 +1429,10 @@ static int hisi_sas_controller_reset(struct hisi_hba
*hisi_hba)
struct Scsi_Host *shost = hisi_hba->shost;
int rc;
+ if (hisi_sas_debugfs_enable && hisi_hba->debugfs_itct &&
+ !hisi_hba->debugfs_dump_dentry)
+ queue_work(hisi_hba->wq, _hba->debugfs_work);
+
if (!hisi_hba->hw->soft_reset)
return -1;
@@ -1923,6 +1927,7 @@ static int hisi_sas_query_task(struct sas_task *task)
slot->task = NULL;
}
dev_err(dev, "internal task abort: timeout and not
done.\n");
+
res = -EIO;
goto exit;
} else
@@ -2459,6 +2464,126 @@ int hisi_sas_probe(struct platform_device *pdev,
struct dentry *hisi_sas_debugfs_dir;
+static void hisi_sas_debugfs_snapshot_cq_reg(struct hisi_hba *hisi_hba)
+{
+ int queue_entry_size = hisi_hba->hw->complete_hdr_size;
+ int i;
+
+ for (i = 0; i < hisi_hba->queue_count; i++)
+ memcpy(hisi_hba->debugfs_complete_hdr[i],
+ hisi_hba->complete_hdr[i],
+ HISI_SAS_QUEUE_SLOTS * queue_entry_size);
+}
+
+static void hisi_sas_debugfs_snapshot_dq_reg(struct hisi_hba *hisi_hba)
+{
+ int queue_entry_size = hisi_hba->hw->complete_hdr_size;
+ int i;
+
+ for (i = 0; i < hisi_hba->queue_count; i++)
+ memcpy(hisi_hba->debugfs_cmd_hdr[i],
+ hisi_hba->cmd_hdr[i],
+ HISI_SAS_QUEUE_SLOTS * queue_entry_size);
+}
+
+static void hisi_sas_debugfs_snapshot_port_reg(struct hisi_hba *hisi_hba)
+{
+ const struct hisi_sas_debugfs_reg *port =
+ hisi_hba->hw->debugfs_reg_port;
+ int i, phy_cnt;
+ u32 offset;
+ u32 *databuf;
+
+ for (phy_cnt = 0; phy_cnt < hisi_hba->n_phy; phy_cnt++) {
+ databuf = (u32
