[PATCH v2] thp: reduce usage of huge zero page's atomic counter
On 08/30/2016 11:59 PM, Sergey Senozhatsky wrote:
> Hello,
>
> for !CONFIG_TRANSPARENT_HUGEPAGE configs mm_put_huge_zero_page() is
> BUILD_BUG(),
> which gives the following build error (mmots v4.8-rc4-mmots-2016-08-29-16-56)
My bad, I mistakenly understand BUILD_BUG and now that
mm_put_huge_zero_page will not be eliminated during compile time, it's
not appropriate to use BUILD_BUG here.
Thanks for the note, I have changed the BUILD_BUG to "return;".
In the meantime, I have also added performance change and runtime change
data to the changelog.
From: Aaron Lu
Date: Fri, 17 Jun 2016 17:13:08 +0800
Subject: [PATCH v2] thp: reduce usage of huge zero page's atomic counter
The global zero page is used to satisfy an anonymous read fault. If
THP(Transparent HugePage) is enabled then the global huge zero page is used.
The global huge zero page uses an atomic counter for reference counting
and is allocated/freed dynamically according to its counter value.
CPU time spent on that counter will greatly increase if there are
a lot of processes doing anonymous read faults. This patch proposes a
way to reduce the access to the global counter so that the CPU load
can be reduced accordingly.
To do this, a new flag of the mm_struct is introduced: MMF_USED_HUGE_ZERO_PAGE.
With this flag, the process only need to touch the global counter in
two cases:
1 The first time it uses the global huge zero page;
2 The time when mm_user of its mm_struct reaches zero.
Note that right now, the huge zero page is eligible to be freed as soon
as its last use goes away. With this patch, the page will not be
eligible to be freed until the exit of the last process from which it
was ever used.
And with the use of mm_user, the kthread is not eligible to use huge
zero page either. Since no kthread is using huge zero page today, there
is no difference after applying this patch. But if that is not desired,
I can change it to when mm_count reaches zero.
Case used for test on Haswell EP:
usemem -n 72 --readonly -j 0x20 100G
Which spawns 72 processes and each will mmap 100G anonymous space and
then do read only access to that space sequentially with a step of 2MB.
CPU cycles from perf report for base commit:
54.03% usemem [kernel.kallsyms] [k] get_huge_zero_page
CPU cycles from perf report for this commit:
0.11% usemem [kernel.kallsyms] [k] mm_get_huge_zero_page
Performance(throughput) of the workload for base commit: 1784430792
Performance(throughput) of the workload for this commit: 4726928591
164% increase.
Runtime of the workload for base commit: 707592 us
Runtime of the workload for this commit: 303970 us
50% drop.
Signed-off-by: Aaron Lu
---
fs/dax.c| 2 +-
include/linux/huge_mm.h | 8
include/linux/sched.h | 1 +
kernel/fork.c | 1 +
mm/huge_memory.c| 36 +---
mm/swap.c | 4 +---
mm/swap_state.c | 4 +---
7 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 993dc6fe0416..226c0d5eedac 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1034,7 +1034,7 @@ int dax_pmd_fault(struct vm_area_struct *vma, unsigned
long address,
if (!write && !buffer_mapped(&bh)) {
spinlock_t *ptl;
pmd_t entry;
- struct page *zero_page = get_huge_zero_page();
+ struct page *zero_page = mm_get_huge_zero_page(vma->vm_mm);
if (unlikely(!zero_page)) {
dax_pmd_dbg(&bh, address, "no zero page");
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 6f14de45b5ce..9e6ab7eeaf17 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -152,8 +152,8 @@ static inline bool is_huge_zero_pmd(pmd_t pmd)
return is_huge_zero_page(pmd_page(pmd));
}
-struct page *get_huge_zero_page(void);
-void put_huge_zero_page(void);
+struct page *mm_get_huge_zero_page(struct mm_struct *mm);
+void mm_put_huge_zero_page(struct mm_struct *mm);
#define mk_huge_pmd(page, prot) pmd_mkhuge(mk_pmd(page, prot))
@@ -213,9 +213,9 @@ static inline bool is_huge_zero_page(struct page *page)
return false;
}
-static inline void put_huge_zero_page(void)
+static inline void mm_put_huge_zero_page(struct mm_struct *mm)
{
- BUILD_BUG();
+ return;
}
static inline struct page *follow_devmap_pmd(struct vm_area_struct *vma,
diff --git a/include/linux/sched.h b/include/linux/sched.h
index d7e1e783cf01..02246a70b63c 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -523,6 +523,7 @@ static inline int get_dumpable(struct mm_struct *mm)
#define MMF_RECALC_UPROBES 20 /* MMF_HAS_UPROBES can be wrong */
#define MMF_OOM_REAPED 21 /* mm has been already reaped */
#define MMF_OOM_NOT_REAPABLE 22 /* mm couldn't be reaped */
+#define MMF_HUGE_ZERO_PAGE 23 /* mm has ever used the global huge
zero page */
#define MMF_INIT_MASK
Re: [PATCH 0/4] Bluetooth: hci_uart: various fixes
Hi Boris, >>> We recently faced some problems when using an BT uart chip interfaced >>> through the H5 proto (rtk_h5). Here are the logs of the 2 different >>> issues we had when closing the line discipline (actually, restoring >>> the previous one) [1][2]. I know the kernel is Tainted in those logs, >>> but after some investigations I found a few potential issues that might >>> explain what we're seeing. >> >> while I can look through these patches, but I wonder when we are finally >> getting a full and proper RTK support that doesn't use these hackish >> hciattach code I have seen. >> >> I mean the only thing userspace should be doing is attaching the line >> discipline and then everything else should run inside the kernel. Attaching >> the line discipline is the same as plugging in an USB dongle. Detaching it >> is the same as unplugging the dongle. That is how we should treat it. So for >> the lifetime of a system it should never detach. All the power control etc. >> should be done inside the kernel. Same as how we have done it for Broadcom >> and Intel devices. > > Well, I'm completely new to the bluetooth stack, and while the > 'hciattach/in-kernel driver' interaction does seem weird to me, I > definitely can't tell whether it's good or bad. if it is the hciattach_rtk.c that uses kernel struct sk_buff in userspace, then it is hackish like no tomorrow. I am still surprised that this works for anybody. > I just sent those patches because I was facing kernel panics. > > Still, I don't get your argument about allowing a user to attach the > line discipline, but preventing him from detaching it. The races exist, > so even if you decide that the line discipline cannot be detached, how > do you plan to handle module unloading (maybe you don't want to allow > that either)? The point is that btattach (which we like to use now) is suppose to be plug/unplug action. You should be able to keep the line discipline attached over hciconfig hci0 up/down interaction. Meaning the kernel can do its proper work without having to resort to detach the line discipline to bring the device down or in low power mode. > One last comment. Even after applying those fixes I'm still facing > panics [1], so there are probably other racy portions in the code. I am not fully surprised. It would be great if you have time to add full RTK support to the kernel side that just uses btattach in userspace to open the TTY and attach the line discipline. And then drive vendor setup + firmware loading from the kernel. Regards Marcel
Re: [PATCH] ftrace: Access ret_stack->subtime only in the function profiler
On Tue, Aug 30, 2016 at 10:34:41AM +0900, Namhyung Kim wrote:
> Hi Steve,
>
> On Mon, Aug 29, 2016 at 04:07:00PM -0400, Steven Rostedt wrote:
> > On Mon, 29 Aug 2016 12:05:18 +0900
> > Namhyung Kim wrote:
> >
> > > The subtime is used only for function profiler with function graph
> > > tracer enabled. Move the definition of subtime under
> > > CONFIG_FUNCTION_PROFILER to reduce the memory usage. Also move the
> > > initialization of subtime into the graph entry callback.
> >
> > Hmm, I think documentation needs to be updated. Although it was never
> > implemented, I believe I added the subtime to not only work with the
> > profiler, but also with the normal tracing (to have the time of the
> > internal functions subtracted from the upper level functions). But it
> > appears that part was never implemented.
> >
> > I'm fine with the patch, or actually implementing what graph-time
> > states in Documentation/ftrace.txt. If we take this patch, that comment
> > needs to be made to only mention the profiler (and the option should
> > only be shown when the profiler is enabled).
>
> Ah, missed the documentation part. To implement it in the normal
> tracing, I think we need to add 'subtime' field to struct
> ftrace_graph_ret which will increase disk size. Are you ok with this?
On second thought, I think I can do it by just adding value of subtime
to ftrace_graph_ret.calltime when graph-time is off. Then the
calltime would not be the timestamp at function entry, but it seems
not guaranteed due to the sleep-time anyway. Now I wonder why it
doesn't have 'duration' in the ftrace_graph_ret instead of having
calltime and rettime.
Thanks,
Namhyung
>
> >
> > >
> > > Cc: Josh Poimboeuf
> > > Signed-off-by: Namhyung Kim
> > > ---
> > > include/linux/ftrace.h | 2 ++
> > > kernel/trace/ftrace.c| 6 ++
> > > kernel/trace/trace_functions_graph.c | 1 -
> > > 3 files changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> > > index 6f93ac46e7f0..b3d34d3e0e7e 100644
> > > --- a/include/linux/ftrace.h
> > > +++ b/include/linux/ftrace.h
> > > @@ -794,7 +794,9 @@ struct ftrace_ret_stack {
> > > unsigned long ret;
> > > unsigned long func;
> > > unsigned long long calltime;
> > > +#ifdef CONFIG_FUNCTION_PROFILER
> > > unsigned long long subtime;
> > > +#endif
> > > #ifdef HAVE_FUNCTION_GRAPH_FP_TEST
> > > unsigned long fp;
> > > #endif
> > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > > index 84752c8e28b5..2050a7652a86 100644
> > > --- a/kernel/trace/ftrace.c
> > > +++ b/kernel/trace/ftrace.c
> > > @@ -872,7 +872,13 @@ function_profile_call(unsigned long ip, unsigned
> > > long parent_ip,
> > > #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> > > static int profile_graph_entry(struct ftrace_graph_ent *trace)
> > > {
> > > + int index = trace->depth;
> > > +
> > > function_profile_call(trace->func, 0, NULL, NULL);
> > > +
> > > + if (index >= 0 && index < FTRACE_RETFUNC_DEPTH)
> > > + current->ret_stack[index].subtime = 0;
> > > +
> > > return 1;
> > > }
> > >
> > > diff --git a/kernel/trace/trace_functions_graph.c
> > > b/kernel/trace/trace_functions_graph.c
> > > index 0cbe38a844fa..9c7ffa4df5a8 100644
> > > --- a/kernel/trace/trace_functions_graph.c
> > > +++ b/kernel/trace/trace_functions_graph.c
> > > @@ -170,7 +170,6 @@ ftrace_push_return_trace(unsigned long ret, unsigned
> > > long func, int *depth,
> > > current->ret_stack[index].ret = ret;
> > > current->ret_stack[index].func = func;
> > > current->ret_stack[index].calltime = calltime;
> > > - current->ret_stack[index].subtime = 0;
> > > #ifdef HAVE_FUNCTION_GRAPH_FP_TEST
> > > current->ret_stack[index].fp = frame_pointer;
> > > #endif
> >
Re: [PATCH] ftrace: Access ret_stack->subtime only in the function profiler
On Wed, 31 Aug 2016 11:11:38 +0900 Namhyung Kim wrote: > On Tue, Aug 30, 2016 at 10:34:41AM +0900, Namhyung Kim wrote: > > Hi Steve, > > > > On Mon, Aug 29, 2016 at 04:07:00PM -0400, Steven Rostedt wrote: > > > On Mon, 29 Aug 2016 12:05:18 +0900 > > > Namhyung Kim wrote: > > > > > > > The subtime is used only for function profiler with function graph > > > > tracer enabled. Move the definition of subtime under > > > > CONFIG_FUNCTION_PROFILER to reduce the memory usage. Also move the > > > > initialization of subtime into the graph entry callback. > > > > > > Hmm, I think documentation needs to be updated. Although it was never > > > implemented, I believe I added the subtime to not only work with the > > > profiler, but also with the normal tracing (to have the time of the > > > internal functions subtracted from the upper level functions). But it > > > appears that part was never implemented. > > > > > > I'm fine with the patch, or actually implementing what graph-time > > > states in Documentation/ftrace.txt. If we take this patch, that comment > > > needs to be made to only mention the profiler (and the option should > > > only be shown when the profiler is enabled). > > > > Ah, missed the documentation part. To implement it in the normal > > tracing, I think we need to add 'subtime' field to struct > > ftrace_graph_ret which will increase disk size. Are you ok with this? > > On second thought, I think I can do it by just adding value of subtime > to ftrace_graph_ret.calltime when graph-time is off. Then the > calltime would not be the timestamp at function entry, but it seems > not guaranteed due to the sleep-time anyway. Now I wonder why it > doesn't have 'duration' in the ftrace_graph_ret instead of having > calltime and rettime. > As it hasn't worked, like forever, I'm thinking of nuking it. Nobody seemed to have noticed. I haven't needed to use it, and apparently nobody else has either. Why support a feature that nobody uses? I have used it for profiling, but not normal function graph tracing. You can see the function times inside and do the logic post processing. Best bet is to just update the documentation to what the current code does. -- Steve
[PATCH v3] arm64: KVM: Optimize __guest_enter/exit() to save a few instructions
We are doing an unnecessary stack push/pop operation when restoring the guest registers x0-x18 in __guest_enter(). This patch saves the two instructions by using x18 as a base register. No need to store the vcpu context pointer in stack because it is redundant, the same information is available in tpidr_el2. The function __guest_exit() calling convention is slightly modified, caller only pushes the regs x0-x1 to stack instead of regs x0-x3. Signed-off-by: Shanker Donthineni Reviewed-by: Christoffer Dall --- Tested this patch using the Qualcomm QDF24XXX platform. Changes since v2: Removed macros save_x0_to_x3/restore_x0_to_x3. Modified el1_sync() to use regs x0 and x1. Edited commit text. Changes since v1: Incorporated Cristoffer suggestions. __guest_exit prototype is changed to 'void __guest_exit(u64 reason, struct kvm_vcpu *vcpu)'. arch/arm64/kvm/hyp/entry.S | 101 - arch/arm64/kvm/hyp/hyp-entry.S | 37 ++- 2 files changed, 63 insertions(+), 75 deletions(-) diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S index ce9e5e5..3967c231 100644 --- a/arch/arm64/kvm/hyp/entry.S +++ b/arch/arm64/kvm/hyp/entry.S @@ -55,79 +55,78 @@ */ ENTRY(__guest_enter) // x0: vcpu - // x1: host/guest context - // x2-x18: clobbered by macros + // x1: host context + // x2-x17: clobbered by macros + // x18: guest context // Store the host regs save_callee_saved_regs x1 - // Preserve vcpu & host_ctxt for use at exit time - stp x0, x1, [sp, #-16]! + // Store the host_ctxt for use at exit time + str x1, [sp, #-16]! - add x1, x0, #VCPU_CONTEXT + add x18, x0, #VCPU_CONTEXT - // Prepare x0-x1 for later restore by pushing them onto the stack - ldp x2, x3, [x1, #CPU_XREG_OFFSET(0)] - stp x2, x3, [sp, #-16]! + // Restore guest regs x0-x17 + ldp x0, x1, [x18, #CPU_XREG_OFFSET(0)] + ldp x2, x3, [x18, #CPU_XREG_OFFSET(2)] + ldp x4, x5, [x18, #CPU_XREG_OFFSET(4)] + ldp x6, x7, [x18, #CPU_XREG_OFFSET(6)] + ldp x8, x9, [x18, #CPU_XREG_OFFSET(8)] + ldp x10, x11, [x18, #CPU_XREG_OFFSET(10)] + ldp x12, x13, [x18, #CPU_XREG_OFFSET(12)] + ldp x14, x15, [x18, #CPU_XREG_OFFSET(14)] + ldp x16, x17, [x18, #CPU_XREG_OFFSET(16)] - // x2-x18 - ldp x2, x3, [x1, #CPU_XREG_OFFSET(2)] - ldp x4, x5, [x1, #CPU_XREG_OFFSET(4)] - ldp x6, x7, [x1, #CPU_XREG_OFFSET(6)] - ldp x8, x9, [x1, #CPU_XREG_OFFSET(8)] - ldp x10, x11, [x1, #CPU_XREG_OFFSET(10)] - ldp x12, x13, [x1, #CPU_XREG_OFFSET(12)] - ldp x14, x15, [x1, #CPU_XREG_OFFSET(14)] - ldp x16, x17, [x1, #CPU_XREG_OFFSET(16)] - ldr x18, [x1, #CPU_XREG_OFFSET(18)] - - // x19-x29, lr - restore_callee_saved_regs x1 - - // Last bits of the 64bit state - ldp x0, x1, [sp], #16 + // Restore guest regs x19-x29, lr + restore_callee_saved_regs x18 + + // Restore guest reg x18 + ldr x18, [x18, #CPU_XREG_OFFSET(18)] // Do not touch any register after this! eret ENDPROC(__guest_enter) ENTRY(__guest_exit) - // x0: vcpu - // x1: return code - // x2-x3: free - // x4-x29,lr: vcpu regs - // vcpu x0-x3 on the stack - - add x2, x0, #VCPU_CONTEXT - - stp x4, x5, [x2, #CPU_XREG_OFFSET(4)] - stp x6, x7, [x2, #CPU_XREG_OFFSET(6)] - stp x8, x9, [x2, #CPU_XREG_OFFSET(8)] - stp x10, x11, [x2, #CPU_XREG_OFFSET(10)] - stp x12, x13, [x2, #CPU_XREG_OFFSET(12)] - stp x14, x15, [x2, #CPU_XREG_OFFSET(14)] - stp x16, x17, [x2, #CPU_XREG_OFFSET(16)] - str x18, [x2, #CPU_XREG_OFFSET(18)] - - ldp x6, x7, [sp], #16 // x2, x3 - ldp x4, x5, [sp], #16 // x0, x1 - - stp x4, x5, [x2, #CPU_XREG_OFFSET(0)] - stp x6, x7, [x2, #CPU_XREG_OFFSET(2)] + // x0: return code + // x1: vcpu + // x2-x29,lr: vcpu regs + // vcpu x0-x1 on the stack + + add x1, x1, #VCPU_CONTEXT + + // Store the guest regs x2 and x3 + stp x2, x3, [x1, #CPU_XREG_OFFSET(2)] + + // Retrieve the guest regs x0-x1 from the stack + ldp x2, x3, [sp], #16 // x0, x1 + + // Store the guest regs x0-x1 and x4-x18 + stp x2, x3, [x1, #CPU_XREG_OFFSET(0)] + stp x4, x5, [x1, #CPU_XREG_OFFSET(4)] + stp x6, x7, [x1, #CPU_XREG_OFFSET(6)] + stp x8, x9, [x1, #CPU_XREG_OFFSET(8)] + stp x10, x11, [x1, #CPU_XREG_OFFSET(10)] + stp x12, x13, [x1, #CPU_XREG_OFFSET(12)] + stp x14, x15, [x1, #CPU_XREG_OFFSET(14)] + stp x16, x17, [x1, #CPU_XREG_OFFSET(16
Re: [PATCH] megaraid_sas: Fix the search of first memory bar
> "Christophe" == Christophe JAILLET writes: Christophe> The 2nd parameter of 'find_first_bit' is the number of bits Christophe> to search. In this case, we are passing 'sizeof(unsigned Christophe> long)' which is likely to be 4. Christophe> It is likely that the number of bits in a long was expected Christophe> here, so use BITS_PER_LONG instead. Applied to 4.9/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v7 05/14] arm64/numa: avoid inconsistent information to be printed
On 2016/8/31 1:51, Will Deacon wrote:
> On Sat, Aug 27, 2016 at 04:54:56PM +0800, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2016/8/26 20:47, Will Deacon wrote:
>>> On Wed, Aug 24, 2016 at 03:44:44PM +0800, Zhen Lei wrote:
numa_init(of_numa_init) may returned error because of numa configuration
error. So "No NUMA configuration found" is inaccurate. In fact, specific
configuration error information should be immediately printed by the
testing branch.
Signed-off-by: Zhen Lei
---
arch/arm64/mm/numa.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 5bb15ea..d97c6e2 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -335,8 +335,10 @@ static int __init numa_init(int (*init_func)(void))
if (ret < 0)
return ret;
- if (nodes_empty(numa_nodes_parsed))
+ if (nodes_empty(numa_nodes_parsed)) {
+ pr_info("No NUMA configuration found\n");
return -EINVAL;
>>>
>>> Hmm, but dummy_numa_init calls node_set(nid, numa_nodes_parsed) for a
>>> completely artificial setup, created by adding all memblocks to node 0,
>>> so this new message will be suppressed even though things really did go
>>> wrong.
>> It will be printed by the former: numa_init(of_numa_init)
>
> Does that print an error for every possible failure case? What about the
> acpi path?
I think acpi path should print error by itself. The reason maybe:
1. In numa_init and its sub function, all error paths printed error
immediately, except arm64_acpi_numa_init.
2. Suppose numa_init returns error, we do not print the returned error code, so
the user don't known what problem cause acpi numa failed.
>
>>> In that case, don't we want to print *something* (like we do today in
>>> dummy_numa_init) but maybe not "No NUMA configuration found"? What
>>> exactly do you find inaccurate about the current message?
>> For example:
>> [0.00] NUMA: No distance-matrix property in distance-map
>> [0.00] No NUMA configuration found
>>
>> So if of_numa_init or arm64_acpi_numa_init returned error, because of
>> some numa configuration error had been found, it's no good to print "No
>> NUMA ...".
>
> Sure, I'm all for changing the message. I just think removing it is
> probably unhelpful. Something like:
>
> "NUMA: Failed to initialise from firmware"
I think adding this into arm64_acpi_numa_init will be better, maybe we should
print 'ret' further:
int __init arm64_acpi_numa_init(void)
{
int ret;
ret = acpi_numa_init();
if (ret) {
+ pr_info("Failed to initialise from firmware\n");
return ret;
}
>
> might do the trick?
>
> Will
>
> .
>
Re: [PATCH v10 1/2] printk: Make printk() completely async
On (08/30/16 11:29), Petr Mladek wrote:
> > you didn't miss anything, I think I wasn't too descriptive and that caused
> > some confusion. this patch is not a replacement of wake_up_process() patch
> > posted earlier in the loop, but an addition to it. not only every WARN/BUG
> > issued from wake_up_process() will do no good, but every lock we take is
> > potentially dangerous as well. In the simplest case because of $LOCK-debug.c
> > files in kernel/locking (spin_lock in our case); in the worst case --
> > because of WARNs issued by log_store() and friends (there may be custom
> > modifications) or by violations of spinlock atomicity requirements.
> >
> > For example,
> >
> > vprintk_emit()
> > local_irq_save()
> > raw_spin_lock()
> > text_len = vscnprintf(text, sizeof(textbuf), fmt, args)
> > {
> > vsnprintf()
> > {
> > if (WARN_ON_ONCE(size > INT_MAX))
> > return 0;
> > }
> > }
> > ...
> >
> > this is a rather unlikely event, sure, there must be some sort of
> > memory corruption or something else, but the thing is -- if it will
> > happen, printk() will not be willing to help.
> >
> > wake_up_process() change, posted earlier, is using a deferred version of
> > WARN macro, but we definitely can (and we better do) switch to lockless
> > alternative printk() in both cases and don't bother with new macros.
> > replacing all of the existing ones with 'safe' deferred versions is
> > a difficult task, but keeping track of a newly introduced ones is even
> > harder (if possible at all).
>
> I see. It makes some sense. I would like to be on the safe side. I am
> just afraid that adding yet another per-CPU buffer is too complex.
> It adds quite some complexity to the code. And it even more scatters
> the messages so that it will be harder to get them from the
> crash dump or flush them to the console when the system goes down.
>
> It took few years to get in the solution for NMIs even when
> it fixed real life deadlocks for many people and customers.
> I am afraid that it is not realistic to get in similar complex
> code to fix rather theoretical problems.
well, I still can try it in my spare time. we can't fix printk() without
ever touching it, can we? so far we basically only acknowledge the
existing printk() problems. we can do better than that, I think.
> Sigh, I waited few days with this comment. I do not want to sound
> like a broken record.
no worries
-ss
drm/atmel-hlcdc: connector type & fbdev mode settings
According to Atmel's guideline... http://www.at91.com/linux4sam/bin/view/Linux4SAM/UsingAtmelDRMDriver the "fbdev emulation mode" could be set from kernel command line (LVDS-1:...) however, driver register it as DRM_MODE_CONNECTOR_Unknown connector. Actually we using sama5d3x with LVDS cable so that below patch would be correct. But I don't know the other case such as HDMI, composite... Do we need to consider using DT or auto-detection?? Signed-off-by: HyungJin Jung --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c index 6119b50..da97efe --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c @@ -208,7 +208,7 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device *dev, &atmel_hlcdc_panel_connector_helper_funcs); ret = drm_connector_init(dev, &output->connector, &atmel_hlcdc_panel_connector_funcs, -DRM_MODE_CONNECTOR_Unknown); +DRM_MODE_CONNECTOR_LVDS); if (ret) goto err_encoder_cleanup; -- 1.9.1 BR, Davy
Re: [PATCH] ftrace: Access ret_stack->subtime only in the function profiler
On Tue, Aug 30, 2016 at 10:16:47PM -0400, Steven Rostedt wrote: > On Wed, 31 Aug 2016 11:11:38 +0900 > Namhyung Kim wrote: > > > On Tue, Aug 30, 2016 at 10:34:41AM +0900, Namhyung Kim wrote: > > > Hi Steve, > > > > > > On Mon, Aug 29, 2016 at 04:07:00PM -0400, Steven Rostedt wrote: > > > > On Mon, 29 Aug 2016 12:05:18 +0900 > > > > Namhyung Kim wrote: > > > > > > > > > The subtime is used only for function profiler with function graph > > > > > tracer enabled. Move the definition of subtime under > > > > > CONFIG_FUNCTION_PROFILER to reduce the memory usage. Also move the > > > > > initialization of subtime into the graph entry callback. > > > > > > > > Hmm, I think documentation needs to be updated. Although it was never > > > > implemented, I believe I added the subtime to not only work with the > > > > profiler, but also with the normal tracing (to have the time of the > > > > internal functions subtracted from the upper level functions). But it > > > > appears that part was never implemented. > > > > > > > > I'm fine with the patch, or actually implementing what graph-time > > > > states in Documentation/ftrace.txt. If we take this patch, that comment > > > > needs to be made to only mention the profiler (and the option should > > > > only be shown when the profiler is enabled). > > > > > > Ah, missed the documentation part. To implement it in the normal > > > tracing, I think we need to add 'subtime' field to struct > > > ftrace_graph_ret which will increase disk size. Are you ok with this? > > > > On second thought, I think I can do it by just adding value of subtime > > to ftrace_graph_ret.calltime when graph-time is off. Then the > > calltime would not be the timestamp at function entry, but it seems > > not guaranteed due to the sleep-time anyway. Now I wonder why it > > doesn't have 'duration' in the ftrace_graph_ret instead of having > > calltime and rettime. > > > > As it hasn't worked, like forever, I'm thinking of nuking it. Nobody > seemed to have noticed. I haven't needed to use it, and apparently > nobody else has either. Why support a feature that nobody uses? > > I have used it for profiling, but not normal function graph tracing. > You can see the function times inside and do the logic post processing. > > Best bet is to just update the documentation to what the current code > does. Ok, will send v2. Thanks, Namhyung
Re: [RESEND][PATCH] proc: Fix timerslack_ns CAP_SYS_NICE check when adjusting self
On Mon, Aug 29, 2016 at 11:28:47AM -0700, John Stultz wrote: > On Mon, Aug 22, 2016 at 4:01 PM, John Stultz wrote: > > In changing from checking ptrace_may_access(p, PTRACE_MODE_ATTACH_FSCREDS) > > to capable(CAP_SYS_NICE), I missed that ptrace_my_access succeeds > > when p == current, but the CAP_SYS_NICE doesn't. > > > > Thus while the previous commit was intended to loosen the needed > > privledges to modify a processes timerslack, it needlessly restricted > > a task modifying its own timerslack via the proc//timerslack_ns > > (which is permitted also via the PR_SET_TIMERSLACK method). > > > > This patch corrects this by checking if p == current before checking > > the CAP_SYS_NICE value. > > > > This patch applies on top of my two previous patches currently in -mm > > Ping? Any feedback or comments on this one? (sorry - no objection from me on this patch, thanks)
Re: [PATCH 1/4] kernel: add a helper to get an owning user namespace for a namespace
On Fri, Aug 26, 2016 at 04:08:08PM -0700, Andrei Vagin wrote:
> From: Andrey Vagin
>
> Return -EPERM if an owning user namespace is outside of a process
> current user namespace.
>
> v2: In a first version ns_get_owner returned ENOENT for init_user_ns.
> This special cases was removed from this version. There is nothing
> outside of init_user_ns, so we can return EPERM.
>
> Signed-off-by: Andrei Vagin
> ---
> fs/namespace.c | 6 ++
> include/linux/proc_ns.h| 1 +
> include/linux/user_namespace.h | 7 +++
> ipc/namespace.c| 6 ++
> kernel/cgroup.c| 6 ++
> kernel/pid_namespace.c | 6 ++
> kernel/user_namespace.c| 24
> kernel/utsname.c | 6 ++
> net/core/net_namespace.c | 6 ++
> 9 files changed, 68 insertions(+)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 491b8f3..f985817 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -3368,10 +3368,16 @@ static int mntns_install(struct nsproxy *nsproxy,
> struct ns_common *ns)
> return 0;
> }
>
> +static struct user_namespace *mntns_get_owner(struct ns_common *ns)
> +{
> + return to_mnt_ns(ns)->user_ns;
Hi - sorry to be pedantic here, but *_get_owner makes me think
it will grab a reference too. A bit unfortunate, maybe it doesn't
matter, but would mntns_owner(), netns_owner(), etc be better?
[PATCH v3] f2fs: fix to set superblock dirty correctly
tests/generic/251 of fstest suit complains us with below message: [ cut here ] invalid opcode: [#1] PREEMPT SMP CPU: 2 PID: 7698 Comm: fstrim Tainted: G O4.7.0+ #21 task: e9f4e000 task.stack: e7262000 EIP: 0060:[] EFLAGS: 00010202 CPU: 2 EIP is at write_checkpoint+0xfde/0x1020 [f2fs] EAX: f33eb300 EBX: eecac310 ECX: 0001 EDX: 0001 ESI: eecac000 EDI: eecac5f0 EBP: e7263dec ESP: e7263d18 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 80050033 CR2: b76ab01c CR3: 2eb89de0 CR4: 000406f0 Stack: 0001 a220fb7b e9f4e000 0002 419ff2d3 b3a05151 0002 e9f4e5d8 e9f4e000 419ff2d3 b3a05151 eecac310 c10b8154 b3a05151 419ff2d3 c10b78bd e9f4e000 e9f4e000 e9f4e5d8 0001 e9f4e000 ec409000 eecac2cc eecac288 Call Trace: [] ? __lock_acquire+0x3c4/0x760 [] ? mark_held_locks+0x5d/0x80 [] f2fs_trim_fs+0x1c2/0x2e0 [f2fs] [] f2fs_ioctl+0x6b6/0x10b0 [f2fs] [] ? __this_cpu_preempt_check+0xf/0x20 [] ? trace_hardirqs_off_caller+0x91/0x120 [] ? __exchange_data_block+0xd30/0xd30 [f2fs] [] do_vfs_ioctl+0x81/0x7f0 [] ? kmem_cache_free+0x245/0x2e0 [] ? get_unused_fd_flags+0x40/0x40 [] ? putname+0x4c/0x50 [] ? do_sys_open+0x16e/0x1d0 [] ? do_fast_syscall_32+0x30/0x1c0 [] ? __this_cpu_preempt_check+0xf/0x20 [] SyS_ioctl+0x58/0x80 [] do_fast_syscall_32+0xa1/0x1c0 [] sysenter_past_esp+0x45/0x74 EIP: [] write_checkpoint+0xfde/0x1020 [f2fs] SS:ESP 0068:e7263d18 ---[ end trace 4de95d7e6b3aa7c6 ]--- The reason is: with below call stack, we will encounter BUG_ON during doing fstrim. Thread AThread B - write_checkpoint - do_checkpoint - f2fs_write_inode - update_inode_page - update_inode - set_page_dirty - f2fs_set_node_page_dirty - inc_page_count - percpu_counter_inc - set_sbi_flag(SBI_IS_DIRTY) - clear_sbi_flag(SBI_IS_DIRTY) Thread CThread D - f2fs_write_node_page - set_node_addr - __set_nat_cache_dirty - nm_i->dirty_nat_cnt++ - do_vfs_ioctl - f2fs_ioctl - f2fs_trim_fs - write_checkpoint - f2fs_bug_on(nm_i->dirty_nat_cnt) Fix it by setting superblock dirty correctly in do_checkpoint and f2fs_write_node_page. Signed-off-by: Chao Yu --- fs/f2fs/checkpoint.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c index 727e97e..b80dd37 100644 --- a/fs/f2fs/checkpoint.c +++ b/fs/f2fs/checkpoint.c @@ -1154,6 +1154,16 @@ static int do_checkpoint(struct f2fs_sb_info *sbi, struct cp_control *cpc) clear_sbi_flag(sbi, SBI_IS_DIRTY); clear_sbi_flag(sbi, SBI_NEED_CP); + /* +* redirty superblock if metadata like node page or inode cache is +* updated during writing checkpoint. +*/ + if (get_pages(sbi, F2FS_DIRTY_NODES) || + get_pages(sbi, F2FS_DIRTY_IMETA)) + set_sbi_flag(sbi, SBI_IS_DIRTY); + + f2fs_bug_on(sbi, get_pages(sbi, F2FS_DIRTY_DENTS)); + return 0; } -- 2.8.2.311.gee88674
Re: [PATCH v7 14/14] Documentation: remove the constraint on the distances of node pairs
On 2016/8/31 1:55, Will Deacon wrote: > On Sat, Aug 27, 2016 at 06:44:39PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2016/8/26 23:35, Will Deacon wrote: >>> On Wed, Aug 24, 2016 at 03:44:53PM +0800, Zhen Lei wrote: Update documentation. This limit is unneccessary. Signed-off-by: Zhen Lei Acked-by: Rob Herring --- Documentation/devicetree/bindings/numa.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/numa.txt b/Documentation/devicetree/bindings/numa.txt index 21b3505..c0ea4a7 100644 --- a/Documentation/devicetree/bindings/numa.txt +++ b/Documentation/devicetree/bindings/numa.txt @@ -48,7 +48,6 @@ distance (memory latency) between all numa nodes. Note: 1. Each entry represents distance from first node to second node. - The distances are equal in either direction. >>> >>> Hmm, so what happens now if firmware provides a description where both >>> distances (in either direction) are supplied, but are different? >> I have not known any hardware that the distances of two direction are >> different yet > > Then let's not add support for this just yet. When we have systems that > actually need it, we'll be in a much better position to assess the > suitability of any patches. At the moment, the whole thing is pretty > questionable and it adds needless complication to the code. How about I changed to: To simplify the configuration, the distance of the opposite direction is the same to it by default. > > Will > > . >
[PATCH v2] ftrace: Access ret_stack->subtime only in the function profiler
The subtime is used only for function profiler with function graph
tracer enabled. Move the definition of subtime under
CONFIG_FUNCTION_PROFILER to reduce the memory usage. Also move the
initialization of subtime into the graph entry callback.
Cc: Josh Poimboeuf
Signed-off-by: Namhyung Kim
---
Documentation/trace/ftrace.txt | 10 +-
include/linux/ftrace.h | 2 ++
kernel/trace/ftrace.c| 6 ++
kernel/trace/trace_functions_graph.c | 1 -
4 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index a6b3705e62a6..185c39fea2a0 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -858,11 +858,11 @@ x494] <- /root/a.out[+0x4a8] <- /lib/libc-2.7.so[+0x1e1a6]
When enabled, it will account time the task has been
scheduled out as part of the function call.
- graph-time - When running function graph tracer, to include the
- time to call nested functions. When this is not set,
- the time reported for the function will only include
- the time the function itself executed for, not the time
- for functions that it called.
+ graph-time - When running function profiler with function graph tracer,
+ to include the time to call nested functions. When this is
+ not set, the time reported for the function will only
+ include the time the function itself executed for, not the
+ time for functions that it called.
record-cmd - When any event or tracer is enabled, a hook is enabled
in the sched_switch trace point to fill comm cache
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 6f93ac46e7f0..b3d34d3e0e7e 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -794,7 +794,9 @@ struct ftrace_ret_stack {
unsigned long ret;
unsigned long func;
unsigned long long calltime;
+#ifdef CONFIG_FUNCTION_PROFILER
unsigned long long subtime;
+#endif
#ifdef HAVE_FUNCTION_GRAPH_FP_TEST
unsigned long fp;
#endif
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 84752c8e28b5..2050a7652a86 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -872,7 +872,13 @@ function_profile_call(unsigned long ip, unsigned long
parent_ip,
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
static int profile_graph_entry(struct ftrace_graph_ent *trace)
{
+ int index = trace->depth;
+
function_profile_call(trace->func, 0, NULL, NULL);
+
+ if (index >= 0 && index < FTRACE_RETFUNC_DEPTH)
+ current->ret_stack[index].subtime = 0;
+
return 1;
}
diff --git a/kernel/trace/trace_functions_graph.c
b/kernel/trace/trace_functions_graph.c
index 0cbe38a844fa..9c7ffa4df5a8 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -170,7 +170,6 @@ ftrace_push_return_trace(unsigned long ret, unsigned long
func, int *depth,
current->ret_stack[index].ret = ret;
current->ret_stack[index].func = func;
current->ret_stack[index].calltime = calltime;
- current->ret_stack[index].subtime = 0;
#ifdef HAVE_FUNCTION_GRAPH_FP_TEST
current->ret_stack[index].fp = frame_pointer;
#endif
--
2.9.3
Re: [PATCH 1/4] kernel: add a helper to get an owning user namespace for a namespace
On Fri, Aug 26, 2016 at 04:08:08PM -0700, Andrei Vagin wrote:
> +struct ns_common *ns_get_owner(struct ns_common *ns)
> +{
> + struct user_namespace *my_user_ns = current_user_ns();
> + struct user_namespace *owner, *p;
> +
> + /* See if the owner is in the current user namespace */
> + owner = p = ns->ops->get_owner(ns);
> + for (;;) {
> + if (!p)
> + return ERR_PTR(-EPERM);
> + if (p == my_user_ns)
> + break;
> + p = p->parent;
> + }
> +
> + return &get_user_ns(owner)->ns;
get_user_ns() bumps the owner's refcount. I don't see where
this is being dropped, especially when ns_ioctl() uses it in
the next patch.
[PATCH] pwm/atmel-hlcdc: Add BACKLIGHT_PWM to config dependency
atmel-hlcdc-pwm working with pwm-backlight so that add dependency to avoid user falut. Signed-off-by: HyungJin Jung --- drivers/pwm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 80a566a..b32b2c1 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -54,6 +54,7 @@ config PWM_ATMEL_HLCDC_PWM tristate "Atmel HLCDC PWM support" depends on MFD_ATMEL_HLCDC depends on HAVE_CLK + depends on BACKLIGHT_PWM help Generic PWM framework driver for the PWM output of the HLCDC (Atmel High-end LCD Controller). This PWM output is mainly used -- 1.9.1
[PATCH net] rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash possibly
From: Gao Feng
The original codes depend on that the function parameters are evaluated from
left to right. But the parameter's evaluation order is not defined in C
standard actually.
When flow_keys_have_l4(&keys) is invoked before ___skb_get_hash(skb, &keys,
hashrnd) with some compilers or environment, the keys passed to
flow_keys_have_l4 is not initialized.
Signed-off-by: Gao Feng
---
net/core/flow_dissector.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 61ad43f..52742a0 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -680,11 +680,13 @@ EXPORT_SYMBOL_GPL(__skb_get_hash_symmetric);
void __skb_get_hash(struct sk_buff *skb)
{
struct flow_keys keys;
+ u32 hash;
__flow_hash_secret_init();
- __skb_set_sw_hash(skb, ___skb_get_hash(skb, &keys, hashrnd),
- flow_keys_have_l4(&keys));
+ hash = ___skb_get_hash(skb, &keys, hashrnd);
+
+ __skb_set_sw_hash(skb, hash, flow_keys_have_l4(&keys));
}
EXPORT_SYMBOL(__skb_get_hash);
--
1.9.1
Re: [PATCH v5 00/11] Add HW throttle for Tegra soctherm
On 08/19/2016 03:15 PM, Zhang Rui wrote: > On 四, 2016-05-26 at 17:42 +0800, Wei Ni wrote: >> Hi, >> Does there have any comments on this series? >> Let me know if someone has suggestions. >> > I have no objections to this patch set. > As 10 patches out of 11, in this patch series, contain changes out of > thermal scope, if you prefer this patch set go through thermal tree, I > still need ACKs for the changes out of thermal scope. Rui, thanks for your comments. Thierry & Matt could you ACK this series ? Thanks. Wei. > > thanks, > rui > >> Thanks. >> Wei. >> >> On 05/11/2016 06:20 PM, Wei Ni wrote: >>> >>> This series add following functions for Tegra soctherm: >>> 1. add HW throttle function. >>> 2. enable soctherm node for Tegra124, Tegra132, Tegra210, and >>> set "critical", "hot" trips for them. >>> >>> Main changes from v4: >>> 1. drop the "nvidia" prefix from the node name, per Rob's comments. >>> >>> Main changes from v3: >>> 1. change some properties'name and descriptions, per Rob's >>> comments. >>> 2. change the corresponding driver codes. >>> >>> Main changes from v2: >>> 1. improve the of-binding, per Eduardo's comments, and >>> change the corresponding driver codes. >>> 2. move two setting critical trip patches in this series, >>> 3. fix some bugs in dts changes. >>> >>> Main changes from v1: >>> 1. use readl/writel instead of __raw_readl/__raw_writel. >>> 2. rebase on the linux-next. >>> >>> The v1 series is in: >>> https://lkml.org/lkml/2016/3/31/230 >>> >>> The v2 series is in: >>> https://lkml.org/lkml/2016/4/26/1577 >>> >>> The v3 series is in: >>> https://lkml.org/lkml/2016/5/3/274 >>> >>> The v4 series is in: >>> https://lkml.org/lkml/2016/5/9/45 >>> >>> Wei Ni (11): >>> of: Add bindings of hw throttle for Tegra soctherm >>> thermal: tegra: add hw-throttle function >>> thermal: tegra: add hw-throttle for Tegra132 >>> arm: tegra: set critical trips for Tegra124 >>> arm: tegra: set hot trips for Tegra124 >>> arm64: tegra: use tegra132-soctherm for Tegra132 >>> arm64: tegra: set critical trips for Tegra132 >>> arm64: tegra: set hot trips for Tegra132 >>> arm64: tegra: add soctherm node for Tegra210 >>> arm64: tegra: set critical trips for Tegra210 >>> arm64: tegra: set hot trips for Tegra210 >>> >>> .../bindings/thermal/nvidia,tegra124-soctherm.txt | 121 ++- >>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 18 +- >>> arch/arm/boot/dts/tegra124.dtsi| 83 +- >>> arch/arm64/boot/dts/nvidia/tegra132.dtsi | 119 ++- >>> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 127 >>> drivers/thermal/tegra/soctherm.c | 842 >>> - >>> drivers/thermal/tegra/soctherm.h | 10 + >>> drivers/thermal/tegra/tegra124-soctherm.c | 18 + >>> drivers/thermal/tegra/tegra132-soctherm.c | 18 + >>> drivers/thermal/tegra/tegra210-soctherm.c | 18 + >>> include/dt-bindings/thermal/tegra124-soctherm.h| 5 + >>> 11 files changed, 1344 insertions(+), 35 deletions(-) >>>
Re: [PATCH v2 4/4] clk: rockchip: remove CLK_IGNORE_UNUSED flag for aclk_emmc_grf on rk3399
On 2016年08月31日 09:37, Shawn Lin wrote:
aclk_emmc_grf is used for accessing corecfg_* of emmc stuff within
GRF block. We don't need to add CLK_IGNORE_UNUSED for it now as the
emmc driver will enable/disable it explicitly when needed.
Signed-off-by: Shawn Lin
This patchset test result:
localhost driver # cat /sys/kernel/debug/clk/clk_summary | grep emmc
gpll_aclk_emmc_src 11
59400 0 0
aclk_emmc35
19800 0 0
aclk_emmcgrf 12
19800 0 0
aclk_emmc_noc 11
19800 0 0
aclk_emmccore 00
19800 0 0
clk_emmc12
14850 0 0
emmc_cardclock 00
14850 0 0
cpll_aclk_emmc_src 00
8 0 0
After unbind driver.
localhost driver # cat /sys/kernel/debug/clk/clk_summary | grep emmc
gpll_aclk_emmc_src 11
59400 0 0
aclk_emmc12
19800 0 0
aclk_emmcgrf 00
19800 0 0
aclk_emmc_noc 11
19800 0 0
aclk_emmccore 00
19800 0 0
clk_emmc00
14850 0 0
cpll_aclk_emmc_src 00
8 0 0
And aclk_emmcgrf(Bit 10, when high, enable clock) had gate.
localhost driver # mem r 0xff760380
0x0415
It works sane, so
Tested-by: Ziyuan Xu
---
Changes in v2: None
drivers/clk/rockchip/clk-rk3399.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3399.c
b/drivers/clk/rockchip/clk-rk3399.c
index ede6c47..908f684 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -934,7 +934,7 @@ static struct rockchip_clk_branch rk3399_clk_branches[]
__initdata = {
RK3399_CLKGATE_CON(32), 8, GFLAGS),
GATE(ACLK_EMMC_NOC, "aclk_emmc_noc", "aclk_emmc", CLK_IGNORE_UNUSED,
RK3399_CLKGATE_CON(32), 9, GFLAGS),
- GATE(ACLK_EMMC_GRF, "aclk_emmcgrf", "aclk_emmc", CLK_IGNORE_UNUSED,
+ GATE(ACLK_EMMC_GRF, "aclk_emmcgrf", "aclk_emmc", 0,
RK3399_CLKGATE_CON(32), 10, GFLAGS),
/* perilp0 */
Re: [PATCH V3 2/2] usb: phy: phy-brcm-usb: Add Broadcom STB USB Phy driver
Hi Al, [auto build test ERROR on phy/next] [also build test ERROR on next-20160825] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Al-Cooper/soc-brcmstb-Add-Product-ID-and-Family-ID-helper-functions/20160830-224057 base: https://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git next config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): >> ERROR: "brcm_usb_common_init" [drivers/phy/phy-brcm-usb.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH v3] time: alarmtimer: Add the trcepoints for alarmtimer
Hi Steven, On 30 August 2016 at 23:42, Steven Rostedt wrote: > On Tue, 30 Aug 2016 19:50:20 +0800 > Baolin Wang wrote: > >> Hi, >> >> On 22 August 2016 at 12:23, Baolin Wang wrote: >> > For system debugging, we usually want to know who sets one alarm timer, the >> > time of the timer, when the timer started and fired and so on. Thus adding >> > tracepoints can help us trace the alarmtimer information. >> > >> > For example, when we debug the system supend/resume, if the system is >> > always >> > resumed by RTC alarm, we can find out which process set the alarm timer to >> > resume system by below trace log: >> > >> > .. >> > Binder:2976_6-3473 [005] d..2 1076.587732: alarmtimer_start: >> > process:Binder:2976_6 >> > alarmtimer type:ALARM_BOOTTIME expires:123415400 time: 1970-1-1 0:20:35 >> > >> > Binder:2976_7-3480 [002] d..2 1076.592707: alarmtimer_cancel: >> > process:Binder:2976_7 >> > alarmtimer type:ALARM_BOOTTIME expires:13254630600 time: 2012-1-2 >> > 0:11:0 >> > >> > Binder:2976_7-3480 [002] d..2 1076.592731: alarmtimer_start: >> > process:Binder:2976_7 >> > alarmtimer type:ALARM_BOOTTIME expires:13253780400 time: 2012-1-1 >> > 0:34:0 >> > >> > system_server-2976 [003] d..2 1076.605587: alarmtimer_cancel: >> > process:system_server >> > alarmtimer type:ALARM_BOOTTIME expires:123415400 time: 1970-1-1 0:20:35 >> > >> > system_server-2976 [003] d..2 1076.605608: alarmtimer_start: >> > process:system_server >> > alarmtimer type:ALARM_BOOTTIME expires:123415500 time: 1970-1-1 0:20:35 >> > >> > system_server-3000 [002] ...1 1087.737565: alarmtimer_suspend: >> > alarmtimer type:ALARM_BOOTTIME >> > expires time: 2012-1-1 0:34:0 >> > .. >> > >> > From the trace log, we can find out the 'Binder:2976_7' process set one >> > alarm >> > timer which resumes the system. >> >> Do you have any comments about this patch? Thanks. > > Looks fine to me. > > Acked-by: Steven Rostedt > > Now you need to get the time maintainers to accept it. Thanks. -- Baolin.wang Best Regards
Re: [PATCH v2 2/4] mmc: sdhci-of-arasan: Control clock for accessing syscon
Hi Shawn,
On 2016年08月31日 09:37, Shawn Lin wrote:
In the eariler commit 65820199272d ("Documentation: mmc:
sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs"), we
introduced syscon to control corecfg_* stuff provided by
arasan. But given that we may need to ungate the clock for
accessing corecfg_*, it not so perfect as it depends on
whether specific clock driver disables it if not referenced.
Meanwhile, if we don't need arasan contoller to work anymore,
there is no reason to still enable it. So let's control this
clock when needed.
Signed-off-by: Shawn Lin
---
Without this series of patches, we can't gate aclk_emmcgrf even though
driver enter suspend/remove. It meaningful to save power consumption.
It looks nice to me, and also I have tested on rk3399 board, so
Tested-by: Ziyuan Xu
Changes in v2:
- assign NULL to clk_syscon if it's not deferral error.
drivers/mmc/host/sdhci-of-arasan.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 0b3a9cf..3169f81 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -78,6 +78,7 @@ struct sdhci_arasan_soc_ctl_map {
* struct sdhci_arasan_data
* @host: Pointer to the main SDHCI host structure.
* @clk_ahb: Pointer to the AHB clock
+ * @clk_syscon:Pointer to the optional clock for accessing
syscon
* @phy: Pointer to the generic phy
* @is_phy_on:True if the PHY is on; false if not.
* @sdcardclk_hw: Struct for the clock we might provide to a PHY.
@@ -88,6 +89,7 @@ struct sdhci_arasan_soc_ctl_map {
struct sdhci_arasan_data {
struct sdhci_host *host;
struct clk *clk_ahb;
+ struct clk *clk_syscon;
struct phy *phy;
boolis_phy_on;
@@ -290,6 +292,7 @@ static int sdhci_arasan_suspend(struct device *dev)
clk_disable(pltfm_host->clk);
clk_disable(sdhci_arasan->clk_ahb);
+ clk_disable(sdhci_arasan->clk_syscon);
return 0;
}
@@ -309,6 +312,12 @@ static int sdhci_arasan_resume(struct device *dev)
struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
int ret;
+ ret = clk_enable(sdhci_arasan->clk_syscon);
+ if (ret) {
+ dev_err(dev, "Cannot enable syscon clock.\n");
+ return ret;
+ }
+
ret = clk_enable(sdhci_arasan->clk_ahb);
if (ret) {
dev_err(dev, "Cannot enable AHB clock.\n");
@@ -528,26 +537,41 @@ static int sdhci_arasan_probe(struct platform_device
*pdev)
ret);
goto err_pltfm_free;
}
+
+ sdhci_arasan->clk_syscon = devm_clk_get(&pdev->dev,
+ "clk_syscon");
+ if (IS_ERR(sdhci_arasan->clk_syscon)) {
+ ret = PTR_ERR(sdhci_arasan->clk_syscon);
+ if (ret == -EPROBE_DEFER)
+ goto err_pltfm_free;
+ else
+ sdhci_arasan->clk_syscon = NULL;
+ }
+
+ if (clk_prepare_enable(sdhci_arasan->clk_syscon)) {
+ dev_err(&pdev->dev, "Unable to enable syscon clock.\n");
+ goto err_pltfm_free;
+ }
}
sdhci_arasan->clk_ahb = devm_clk_get(&pdev->dev, "clk_ahb");
if (IS_ERR(sdhci_arasan->clk_ahb)) {
dev_err(&pdev->dev, "clk_ahb clock not found.\n");
ret = PTR_ERR(sdhci_arasan->clk_ahb);
- goto err_pltfm_free;
+ goto clk_dis_syscon;
}
clk_xin = devm_clk_get(&pdev->dev, "clk_xin");
if (IS_ERR(clk_xin)) {
dev_err(&pdev->dev, "clk_xin clock not found.\n");
ret = PTR_ERR(clk_xin);
- goto err_pltfm_free;
+ goto clk_dis_syscon;
}
ret = clk_prepare_enable(sdhci_arasan->clk_ahb);
if (ret) {
dev_err(&pdev->dev, "Unable to enable AHB clock.\n");
- goto err_pltfm_free;
+ goto clk_dis_syscon;
}
ret = clk_prepare_enable(clk_xin);
@@ -607,6 +631,8 @@ clk_disable_all:
clk_disable_unprepare(clk_xin);
clk_dis_ahb:
clk_disable_unprepare(sdhci_arasan->clk_ahb);
+clk_dis_syscon:
+ clk_disable_unprepare(sdhci_arasan->clk_syscon);
err_pltfm_free:
sdhci_pltfm_free(pdev);
return ret;
@@ -631,6 +657,7 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
ret = sdhci_pltfm_unregister(pdev);
clk_disable_unprepare(clk_ahb);
+ clk_disable_unprepare(sdhci_arasan->clk_syscon);
return ret;
}
Re: [GIT PULL] bcm2835-dt-next-2016-08-29
Le 29/08/2016 à 12:38, Eric Anholt a écrit : > The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: > > Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) > > are available in the git repository at: > > https://github.com/anholt/linux bcm2835-dt-next-2016-08-29 > > for you to fetch changes up to c8336249c1eeca288919e3286f7dd03ae1d8ceae: > > ARM: dts: bcm2835: Add Raspberry Pi Zero (2016-08-24 13:33:19 -0700) > > > This pull request brings in support for Raspberry Pi Zero. Merged thanks Eric! -- Florian signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 3/4] arm64: dts: rockchip: add clk_syscon for sdhci on rk3399
Hi Shawn, On 2016年08月31日 09:37, Shawn Lin wrote: We are intent on letting the sdhci variant driver handle this optional clock on rk3399 platform now. Signed-off-by: Shawn Lin --- Thanks for your patch, we can gate aclk_emmcgrf now as soon as sdhci driver suspend. Reviewed-by: Ziyuan Xu Tested-by: Ziyuan Xu Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index bc86e8c..d26c6ad 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -233,8 +233,9 @@ arasan,soc-ctl-syscon = <&grf>; assigned-clocks = <&cru SCLK_EMMC>; assigned-clock-rates = <2>; - clocks = <&cru SCLK_EMMC>, <&cru ACLK_EMMC>; - clock-names = "clk_xin", "clk_ahb"; + clocks = <&cru SCLK_EMMC>, <&cru ACLK_EMMC>, +<&cru ACLK_EMMC_GRF>; + clock-names = "clk_xin", "clk_ahb", "clk_syscon"; clock-output-names = "emmc_cardclock"; #clock-cells = <0>; phys = <&emmc_phy>;
Re: [PATCH v9 1/2] ASoC: sun4i-codec: Distinguish sun4i from sun7i
On Tue, Aug 30, 2016 at 1:44 PM, Danny Milosavljevic
wrote:
> This distinguishes sun4i from sun7i. It is necessary because they use
> different registers for the audio mixer.
> ---
> sound/soc/sunxi/sun4i-codec.c | 44
> +--
> 1 file changed, 34 insertions(+), 10 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 0e19c50..30f4ea2 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -96,8 +96,9 @@
> /* Other various ADC registers */
> #define SUN4I_CODEC_DAC_TXCNT (0x30)
> #define SUN4I_CODEC_ADC_RXCNT (0x34)
> -#define SUN4I_CODEC_AC_SYS_VERI(0x38)
> -#define SUN4I_CODEC_AC_MIC_PHONE_CAL (0x3c)
> +
> +#define SUN7I_CODEC_AC_DAC_CAL (0x38)
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
>
> struct sun4i_codec {
> struct device *dev;
> @@ -509,10 +510,17 @@ static const struct snd_kcontrol_new
> sun4i_codec_pa_mute =
>
> static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
>
> -static const struct snd_kcontrol_new sun4i_codec_widgets[] = {
> - SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
> - SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
> - sun4i_codec_pa_volume_scale),
> +#define SUN4I_COMMON_CODEC_CONTROLS \
> + SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,\
> + SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,\
> + sun4i_codec_pa_volume_scale)
This is slightly worrying. It will get messy as you add more widgets.
> +
> +static const struct snd_kcontrol_new sun4i_codec_controls[] = {
> + SUN4I_COMMON_CODEC_CONTROLS,
> +};
> +
> +static const struct snd_kcontrol_new sun7i_codec_controls[] = {
> + SUN4I_COMMON_CODEC_CONTROLS,
> };
>
> static const struct snd_kcontrol_new sun4i_codec_left_mixer_controls[] = {
> @@ -629,8 +637,18 @@ static const struct snd_soc_dapm_route
> sun4i_codec_codec_dapm_routes[] = {
>
> static struct snd_soc_codec_driver sun4i_codec_codec = {
> .component_driver = {
> - .controls = sun4i_codec_widgets,
> - .num_controls = ARRAY_SIZE(sun4i_codec_widgets),
> + .controls = sun4i_codec_controls,
> + .num_controls = ARRAY_SIZE(sun4i_codec_controls),
> + .dapm_widgets = sun4i_codec_codec_dapm_widgets,
> + .num_dapm_widgets =
> ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
> + .dapm_routes= sun4i_codec_codec_dapm_routes,
> + .num_dapm_routes=
> ARRAY_SIZE(sun4i_codec_codec_dapm_routes),
> + },
> +};
> +static struct snd_soc_codec_driver sun7i_codec_codec = {
> + .component_driver = {
> + .controls = sun7i_codec_controls,
> + .num_controls = ARRAY_SIZE(sun7i_codec_controls),
> .dapm_widgets = sun4i_codec_codec_dapm_widgets,
> .num_dapm_widgets =
> ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
> .dapm_routes= sun4i_codec_codec_dapm_routes,
> @@ -682,7 +700,7 @@ static const struct regmap_config
> sun4i_codec_regmap_config = {
> .reg_bits = 32,
> .reg_stride = 4,
> .val_bits = 32,
> - .max_register = SUN4I_CODEC_AC_MIC_PHONE_CAL,
> + .max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
> };
On sun4i the registers only go as far as SUN4I_CODEC_ADC_RXCNT.
Could you add a separate regmap_config as well?
>
> static const struct of_device_id sun4i_codec_of_match[] = {
> @@ -760,6 +778,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
> {
> struct snd_soc_card *card;
> struct sun4i_codec *scodec;
> + struct snd_soc_codec_driver *codec;
> struct resource *res;
> void __iomem *base;
> int ret;
> @@ -822,7 +841,12 @@ static int sun4i_codec_probe(struct platform_device
> *pdev)
> scodec->capture_dma_data.maxburst = 4;
> scodec->capture_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
>
> - ret = snd_soc_register_codec(&pdev->dev, &sun4i_codec_codec,
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "allwinner,sun7i-a20-codec"))
> + codec = &sun7i_codec_codec;
> + else
> + codec = &sun4i_codec_codec;
> + ret = snd_soc_register_codec(&pdev->dev, codec,
This will get reworked into something like in
https://github.com/wens/linux/commit/54a58e3087fb67572ca416256bc000e08b163480
I haven't gotten around to posting this series yet though.
ChenYu
> &sun4i_codec_dai, 1);
> if (ret) {
> dev_err(&pdev->dev, "Failed to r
[PATCH 1/2] mm: Move definition of 'zone_names' array into mmzone.h
zone_names[] is used to identify any zone given it's index which
can be used in many other places. So moving the definition into
include/linux/mmzone.h for broader access.
Signed-off-by: Anshuman Khandual
---
include/linux/mmzone.h | 17 +
mm/page_alloc.c| 17 -
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index d572b78..01ca3f4 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -341,6 +341,23 @@ enum zone_type {
};
+static char * const zone_names[__MAX_NR_ZONES] = {
+#ifdef CONFIG_ZONE_DMA
+"DMA",
+#endif
+#ifdef CONFIG_ZONE_DMA32
+"DMA32",
+#endif
+"Normal",
+#ifdef CONFIG_HIGHMEM
+"HighMem",
+#endif
+"Movable",
+#ifdef CONFIG_ZONE_DEVICE
+"Device",
+#endif
+};
+
#ifndef __GENERATING_BOUNDS_H
struct zone {
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3fbe73a..8e2261c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -207,23 +207,6 @@ int sysctl_lowmem_reserve_ratio[MAX_NR_ZONES-1] = {
EXPORT_SYMBOL(totalram_pages);
-static char * const zone_names[MAX_NR_ZONES] = {
-#ifdef CONFIG_ZONE_DMA
-"DMA",
-#endif
-#ifdef CONFIG_ZONE_DMA32
-"DMA32",
-#endif
-"Normal",
-#ifdef CONFIG_HIGHMEM
-"HighMem",
-#endif
-"Movable",
-#ifdef CONFIG_ZONE_DEVICE
-"Device",
-#endif
-};
-
char * const migratetype_names[MIGRATE_TYPES] = {
"Unmovable",
"Movable",
--
1.9.3
Re: [PATCH] pstore/ramoops: fixup driver removal
(Resending with all recipients, sorry)
On Sat, Aug 20, 2016 at 1:52 AM, Sebastian Andrzej Siewior
wrote:
> A basic rmmod ramoops segfaults. Let's see why.
>
> Since commit 34f0ec82e0a9 ("pstore: Correct the max_dump_cnt clearing of
> ramoops") sets ->max_dump_cnt to zero before looping over ->przs but we
> didn't use it before that either.
>
> And since commit ee1d267423a1 ("pstore: add pstore unregister") we free
> that memory on rmmod.
>
> But even then, we looped until a NULL pointer or ERR. I don't see where
> it is ensured that the last member is NULL. Let's try this instead:
> simply error recovery and free. Clean up in error case where ressouces
> were allocated. And then, in the free path, rely on ->max_dump_cnt in
> the free path.
>
> Cc: Anton Vorontsov
> Cc: Colin Cross
> Cc: Kees Cook
> Cc: Tony Luck
> Signed-off-by: Sebastian Andrzej Siewior
Fwiw,
Acked-by: Namhyung Kim
Thanks,
Namhyung
> ---
>
> Not sure if I miss something obvious or not.
>
> fs/pstore/ram.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 7a034d62cf8c..2340262a7e97 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -377,13 +377,14 @@ static void ramoops_free_przs(struct ramoops_context
> *cxt)
> {
> int i;
>
> - cxt->max_dump_cnt = 0;
> if (!cxt->przs)
> return;
>
> - for (i = 0; !IS_ERR_OR_NULL(cxt->przs[i]); i++)
> + for (i = 0; i < cxt->max_dump_cnt; i++)
> persistent_ram_free(cxt->przs[i]);
> +
> kfree(cxt->przs);
> + cxt->max_dump_cnt = 0;
> }
>
> static int ramoops_init_przs(struct device *dev, struct ramoops_context *cxt,
> @@ -408,7 +409,7 @@ static int ramoops_init_przs(struct device *dev, struct
> ramoops_context *cxt,
> GFP_KERNEL);
> if (!cxt->przs) {
> dev_err(dev, "failed to initialize a prz array for dumps\n");
> - goto fail_prz;
> + goto fail_mem;
> }
>
> for (i = 0; i < cxt->max_dump_cnt; i++) {
> @@ -419,6 +420,11 @@ static int ramoops_init_przs(struct device *dev, struct
> ramoops_context *cxt,
> err = PTR_ERR(cxt->przs[i]);
> dev_err(dev, "failed to request mem region
> (0x%zx@0x%llx): %d\n",
> cxt->record_size, (unsigned long long)*paddr,
> err);
> +
> + while (i > 0) {
> + i--;
> + persistent_ram_free(cxt->przs[i]);
> + }
> goto fail_prz;
> }
> *paddr += cxt->record_size;
> @@ -426,7 +432,9 @@ static int ramoops_init_przs(struct device *dev, struct
> ramoops_context *cxt,
>
> return 0;
> fail_prz:
> - ramoops_free_przs(cxt);
> + kfree(cxt->przs);
> +fail_mem:
> + cxt->max_dump_cnt = 0;
> return err;
> }
>
> @@ -659,7 +667,6 @@ static int ramoops_remove(struct platform_device *pdev)
> struct ramoops_context *cxt = &oops_cxt;
>
> pstore_unregister(&cxt->pstore);
> - cxt->max_dump_cnt = 0;
>
> kfree(cxt->pstore.buf);
> cxt->pstore.bufsize = 0;
> --
> 2.9.3
>
Re: [PATCH] sparc64 mm: Fix more TSB sizing issues
On 08/30/2016 03:51 PM, kbuild test robot wrote: > Hi Mike, > > [auto build test ERROR on sparc/master] > [also build test ERROR on v4.8-rc4 next-20160825] > [cannot apply to sparc-next/master] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for > convenience) to record what (public, well-known) commit your patch series was > built on] > [Check https://git-scm.com/docs/git-format-patch for more information] Ugh! I'll send a V2 patch with the non-hugepage/non-thp build error fixed. I'd really like to fix this without adding another #ifdef to the routine. -- Mike Kravetz > > url: > https://github.com/0day-ci/linux/commits/Mike-Kravetz/sparc64-mm-Fix-more-TSB-sizing-issues/20160831-054025 > base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git master > config: sparc64-allnoconfig (attached as .config) > compiler: sparc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609 > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=sparc64 > > All errors (new ones prefixed by >>): > >arch/sparc/mm/tsb.c: In function 'init_new_context': >>> arch/sparc/mm/tsb.c:504:4: error: 'saved_thp_pte_count' undeclared (first >>> use in this function) >saved_thp_pte_count * (HPAGE_SIZE / PAGE_SIZE)); >^ >arch/sparc/mm/tsb.c:504:4: note: each undeclared identifier is reported > only once for each function it appears in >>> arch/sparc/mm/tsb.c:504:27: error: 'HPAGE_SIZE' undeclared (first use in >>> this function) >saved_thp_pte_count * (HPAGE_SIZE / PAGE_SIZE)); > ^ > > vim +/saved_thp_pte_count +504 arch/sparc/mm/tsb.c > >498mm->context.tsb_block[i].tsb = NULL; >499 >500/* If this is fork, inherit the parent's TSB size. We > would >501 * grow it to that size on the first page fault anyways. >502 */ >503tsb_grow(mm, MM_TSB_BASE, get_mm_rss(mm) - > > 504 saved_thp_pte_count * (HPAGE_SIZE / > PAGE_SIZE)); >505 >506#if defined(CONFIG_HUGETLB_PAGE) || > defined(CONFIG_TRANSPARENT_HUGEPAGE) >507if (unlikely(saved_hugetlb_pte_count + > saved_thp_pte_count)) > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation >
[PATCH 2/2] mm: Add sysfs interface to dump each node's zonelist information
Each individual node in the system has a ZONELIST_FALLBACK zonelist
and a ZONELIST_NOFALLBACK zonelist. These zonelists decide fallback
order of zones during memory allocations. Sometimes it helps to dump
these zonelists to see the priority order of various zones in them.
This change just adds a sysfs interface for doing the same.
Example zonelist information from a KVM guest.
[NODE (0)]
ZONELIST_FALLBACK
(0) (node 0) (zone DMA c140c000)
(1) (node 1) (zone DMA c001)
(2) (node 2) (zone DMA c002)
(3) (node 3) (zone DMA c003)
ZONELIST_NOFALLBACK
(0) (node 0) (zone DMA c140c000)
[NODE (1)]
ZONELIST_FALLBACK
(0) (node 1) (zone DMA c001)
(1) (node 2) (zone DMA c002)
(2) (node 3) (zone DMA c003)
(3) (node 0) (zone DMA c140c000)
ZONELIST_NOFALLBACK
(0) (node 1) (zone DMA c001)
[NODE (2)]
ZONELIST_FALLBACK
(0) (node 2) (zone DMA c002)
(1) (node 3) (zone DMA c003)
(2) (node 0) (zone DMA c140c000)
(3) (node 1) (zone DMA c001)
ZONELIST_NOFALLBACK
(0) (node 2) (zone DMA c002)
[NODE (3)]
ZONELIST_FALLBACK
(0) (node 3) (zone DMA c003)
(1) (node 0) (zone DMA c140c000)
(2) (node 1) (zone DMA c001)
(3) (node 2) (zone DMA c002)
ZONELIST_NOFALLBACK
(0) (node 3) (zone DMA c003)
Signed-off-by: Anshuman Khandual
---
drivers/base/memory.c | 46 ++
1 file changed, 46 insertions(+)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index dc75de9..8c9330a 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -442,7 +442,52 @@ print_block_size(struct device *dev, struct
device_attribute *attr,
return sprintf(buf, "%lx\n", get_memory_block_size());
}
+static ssize_t dump_zonelist(char *buf, struct zonelist *zonelist)
+{
+ unsigned int i;
+ ssize_t count = 0;
+
+ for (i = 0; zonelist->_zonerefs[i].zone; i++) {
+ count += sprintf(buf + count,
+ "\t\t(%d) (node %d) (%-10s %lx)\n", i,
+ zonelist->_zonerefs[i].zone->zone_pgdat->node_id,
+ zone_names[zonelist->_zonerefs[i].zone_idx],
+ (unsigned long) zonelist->_zonerefs[i].zone);
+ }
+ return count;
+}
+
+static ssize_t dump_zonelists(char *buf)
+{
+ struct zonelist *zonelist;
+ unsigned int node;
+ ssize_t count = 0;
+
+ for_each_online_node(node) {
+ zonelist = &(NODE_DATA(node)->
+ node_zonelists[ZONELIST_FALLBACK]);
+ count += sprintf(buf + count, "[NODE (%d)]\n", node);
+ count += sprintf(buf + count, "\tZONELIST_FALLBACK\n");
+ count += dump_zonelist(buf + count, zonelist);
+
+ zonelist = &(NODE_DATA(node)->
+ node_zonelists[ZONELIST_NOFALLBACK]);
+ count += sprintf(buf + count, "\tZONELIST_NOFALLBACK\n");
+ count += dump_zonelist(buf + count, zonelist);
+ }
+ return count;
+}
+
+static ssize_t
+print_system_zone_details(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ return dump_zonelists(buf);
+}
+
+
static DEVICE_ATTR(block_size_bytes, 0444, print_block_size, NULL);
+static DEVICE_ATTR(system_zone_details, 0444, print_system_zone_details, NULL);
/*
* Memory auto online policy.
@@ -783,6 +828,7 @@ static struct attribute *memory_root_attrs[] = {
#endif
&dev_attr_block_size_bytes.attr,
+ &dev_attr_system_zone_details.attr,
&dev_attr_auto_online_blocks.attr,
NULL
};
--
1.9.3
Re: [RFC v2 09/10] landlock: Handle cgroups (performance)
On Tue, Aug 30, 2016 at 6:36 PM, Alexei Starovoitov wrote: > On Tue, Aug 30, 2016 at 02:45:14PM -0700, Andy Lutomirski wrote: >> >> One might argue that landlock shouldn't be tied to seccomp (in theory, >> attached progs could be given access to syscall_get_xyz()), but I > > proposed lsm is way more powerful than syscall_get_xyz. > no need to dumb it down. I think you're misunderstanding me. Mickaël's code allows one to make the LSM hook filters depend on the syscall using SECCOMP_RET_LANDLOCK. I'm suggesting that a similar effect could be achieved by allowing the eBPF LSM hook to call syscall_get_xyz() if it wants to. > >> think that the seccomp attachment mechanism is the right way to >> install unprivileged filters. It handles the no_new_privs stuff, it >> allows TSYNC, it's totally independent of systemwide policy, etc. >> >> Trying to use cgroups or similar for this is going to be much nastier. >> Some tighter sandboxes (Sandstorm, etc) aren't even going to dream of >> putting cgroupfs in their containers, so requiring cgroups or similar >> would be a mess for that type of application. > > I don't see why it is a 'mess'. cgroups are already used by majority > of the systems, so I don't see why requiring a cgroup is such a big deal. Requiring cgroup to be configured in isn't a big deal. Requiring > But let's say we don't do them. How implementation is going to look like > for task based hierarchy? Note that we need an array of bpf_prog pointers. > One for each lsm hook. Where this array is going to be stored? > We cannot put in task_struct, since it's too large. Cannot put it > into 'struct seccomp' directly either, unless it will become a pointer. > Is that the proposal? It would go in struct seccomp_filter or in something pointed to from there. > So now we will be wasting extra 1kbyte of memory per task. Not great. > We'd want to optimize it by sharing this such struct seccomp with prog array > across threads of the same task? Or dynimically allocating it when > landlock is in use? May sound nice, but how to account for that kernel > memory? I guess also solvable by charging memlock. > With cgroup based approach we don't need to worry about all that. > The considerations are essentially identical either way. With cgroups, if you want to share the memory between multiple separate sandboxes (Firejail instances, Sandstorm grains, Chromium instances, xdg-apps, etc), you'd need to get them to all coordinate to share a cgroup. With a seccomp-like interface, you'd need to get them to coordinate to share an installed layer (using my FD idea or similar). There would *not* be any duplication of this memory just because a sandboxed process called fork(). --Andy -- Andy Lutomirski AMA Capital Management, LLC
[PATCH v4 1/2] serial: 8250_dw: make dw8250_set_termios as default set_termios callback
Make dw8250_set_termios() handle all cases of dw8250_data->clk properly,
then we can safely use dw8250_set_termios() as the default set_termios
callback instead of serial8250_do_set_termios(), so do it.
Signed-off-by: Kefeng Wang
---
drivers/tty/serial/8250/8250_dw.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw.c
index 5c0c123..adecece 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -235,7 +235,7 @@ static void dw8250_set_termios(struct uart_port *p, struct
ktermios *termios,
unsigned int rate;
int ret;
- if (IS_ERR(d->clk) || !old)
+ if (IS_ERR_OR_NULL(d->clk) || !old)
goto out;
clk_disable_unprepare(d->clk);
@@ -308,13 +308,11 @@ static void dw8250_quirks(struct uart_port *p, struct
dw8250_data *data)
p->serial_in = dw8250_serial_in32;
data->uart_16550_compatible = true;
}
- p->set_termios = dw8250_set_termios;
}
/* Platforms with iDMA */
if (platform_get_resource_byname(to_platform_device(p->dev),
IORESOURCE_MEM, "lpss_priv")) {
- p->set_termios = dw8250_set_termios;
data->dma.rx_param = p->dev->parent;
data->dma.tx_param = p->dev->parent;
data->dma.fn = dw8250_idma_filter;
@@ -391,6 +389,7 @@ static int dw8250_probe(struct platform_device *pdev)
p->iotype = UPIO_MEM;
p->serial_in= dw8250_serial_in;
p->serial_out = dw8250_serial_out;
+ p->set_termios = dw8250_set_termios;
p->membase = devm_ioremap(&pdev->dev, regs->start, resource_size(regs));
if (!p->membase)
--
1.7.12.4
[PATCH] serial: 8250_dw: Use an unified new dev variable in probe
Use an unified new dev variable instead of &pdev->dev and p->dev
in probe function.
Signed-off-by: Kefeng Wang
---
drivers/tty/serial/8250/8250_dw.c | 45 ---
1 file changed, 23 insertions(+), 22 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw.c
index 3478c2c..225d797 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -363,18 +363,19 @@ static int dw8250_probe(struct platform_device *pdev)
struct resource *regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
int irq = platform_get_irq(pdev, 0);
struct uart_port *p = &uart.port;
+ struct device *dev = &pdev->dev;
struct dw8250_data *data;
int err;
u32 val;
if (!regs) {
- dev_err(&pdev->dev, "no registers defined\n");
+ dev_err(dev, "no registers defined\n");
return -EINVAL;
}
if (irq < 0) {
if (irq != -EPROBE_DEFER)
- dev_err(&pdev->dev, "cannot get irq\n");
+ dev_err(dev, "cannot get irq\n");
return irq;
}
@@ -385,17 +386,17 @@ static int dw8250_probe(struct platform_device *pdev)
p->pm = dw8250_do_pm;
p->type = PORT_8250;
p->flags= UPF_SHARE_IRQ | UPF_FIXED_PORT;
- p->dev = &pdev->dev;
+ p->dev = dev;
p->iotype = UPIO_MEM;
p->serial_in= dw8250_serial_in;
p->serial_out = dw8250_serial_out;
p->set_termios = dw8250_set_termios;
- p->membase = devm_ioremap(&pdev->dev, regs->start, resource_size(regs));
+ p->membase = devm_ioremap(dev, regs->start, resource_size(regs));
if (!p->membase)
return -ENOMEM;
- data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
@@ -403,57 +404,57 @@ static int dw8250_probe(struct platform_device *pdev)
data->usr_reg = DW_UART_USR;
p->private_data = data;
- data->uart_16550_compatible = device_property_read_bool(p->dev,
+ data->uart_16550_compatible = device_property_read_bool(dev,
"snps,uart-16550-compatible");
- err = device_property_read_u32(p->dev, "reg-shift", &val);
+ err = device_property_read_u32(dev, "reg-shift", &val);
if (!err)
p->regshift = val;
- err = device_property_read_u32(p->dev, "reg-io-width", &val);
+ err = device_property_read_u32(dev, "reg-io-width", &val);
if (!err && val == 4) {
p->iotype = UPIO_MEM32;
p->serial_in = dw8250_serial_in32;
p->serial_out = dw8250_serial_out32;
}
- if (device_property_read_bool(p->dev, "dcd-override")) {
+ if (device_property_read_bool(dev, "dcd-override")) {
/* Always report DCD as active */
data->msr_mask_on |= UART_MSR_DCD;
data->msr_mask_off |= UART_MSR_DDCD;
}
- if (device_property_read_bool(p->dev, "dsr-override")) {
+ if (device_property_read_bool(dev, "dsr-override")) {
/* Always report DSR as active */
data->msr_mask_on |= UART_MSR_DSR;
data->msr_mask_off |= UART_MSR_DDSR;
}
- if (device_property_read_bool(p->dev, "cts-override")) {
+ if (device_property_read_bool(dev, "cts-override")) {
/* Always report CTS as active */
data->msr_mask_on |= UART_MSR_CTS;
data->msr_mask_off |= UART_MSR_DCTS;
}
- if (device_property_read_bool(p->dev, "ri-override")) {
+ if (device_property_read_bool(dev, "ri-override")) {
/* Always report Ring indicator as inactive */
data->msr_mask_off |= UART_MSR_RI;
data->msr_mask_off |= UART_MSR_TERI;
}
/* Always ask for fixed clock rate from a property. */
- device_property_read_u32(p->dev, "clock-frequency", &p->uartclk);
+ device_property_read_u32(dev, "clock-frequency", &p->uartclk);
/* If there is separate baudclk, get the rate from it. */
- data->clk = devm_clk_get(&pdev->dev, "baudclk");
+ data->clk = devm_clk_get(dev, "baudclk");
if (IS_ERR(data->clk) && PTR_ERR(data->clk) != -EPROBE_DEFER)
- data->clk = devm_clk_get(&pdev->dev, NULL);
+ data->clk = devm_clk_get(dev, NULL);
if (IS_ERR(data->clk) && PTR_ERR(data->clk) == -EPROBE_DEFER)
return -EPROBE_DEFER;
if (!IS_ERR_OR_NULL(data->clk)) {
err = clk_prepare_enable(data->clk);
if (err)
- dev_warn(&pdev->dev, "could not enable optional
baudclk: %d
[PATCH 3/3] autofs: fix "fix dev ioctl number range check"
From: Tomohiro Kusumi 102a340f had a typo that made the count macro negative (-13). The acutal check used by ioctl is ((cmd - cmd_first) > COUNT), so it needs to be positive (13). * 102a340f is a commit in linux-next which hasn't been merged to mainline upstream. Signed-off-by: Tomohiro Kusumi Signed-off-by: Ian Kent --- fs/autofs4/autofs_i.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h index 4404a22..a1fba42 100644 --- a/fs/autofs4/autofs_i.h +++ b/fs/autofs4/autofs_i.h @@ -21,7 +21,7 @@ #define AUTOFS_DEV_IOCTL_IOC_FIRST (AUTOFS_DEV_IOCTL_VERSION) #define AUTOFS_DEV_IOCTL_IOC_COUNT \ - (AUTOFS_DEV_IOCTL_VERSION_CMD - AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD) + (AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD - AUTOFS_DEV_IOCTL_VERSION_CMD) #include #include
[PATCH v4 2/2] serial: 8250_dw: add ACPI support for uart on Hisilicon Hip05 SoC
Add ACPI identifier for UART on Hisilicon Hip05 SoC, be careful that
it is not 16550 compatible, and "reg-io-width" and "reg-shift" need
be set properly by _DSD method in DSDT.
Signed-off-by: Kefeng Wang
---
drivers/tty/serial/8250/8250_dw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw.c
index adecece..3478c2c 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -623,6 +623,7 @@ static const struct acpi_device_id dw8250_acpi_match[] = {
{ "APMC0D08", 0},
{ "AMD0020", 0 },
{ "AMDI0020", 0 },
+ { "HISI0031", 0 },
{ },
};
MODULE_DEVICE_TABLE(acpi, dw8250_acpi_match);
--
1.7.12.4
[PATCH 2/3] autofs: refactor ioctl fn vector in iookup_dev_ioctl()
From: Tomohiro Kusumi
cmd part of this struct is the same as an index of itself within
_ioctls[]. In fact this cmd is unused, so we can drop this part.
Signed-off-by: Tomohiro Kusumi
Signed-off-by: Ian Kent
---
fs/autofs4/dev-ioctl.c | 49
1 file changed, 16 insertions(+), 33 deletions(-)
diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
index e89d6bb..fc09eb7 100644
--- a/fs/autofs4/dev-ioctl.c
+++ b/fs/autofs4/dev-ioctl.c
@@ -597,42 +597,25 @@ out:
static ioctl_fn lookup_dev_ioctl(unsigned int cmd)
{
- static struct {
- int cmd;
- ioctl_fn fn;
- } _ioctls[] = {
- {cmd_idx(AUTOFS_DEV_IOCTL_VERSION_CMD),
-autofs_dev_ioctl_version},
- {cmd_idx(AUTOFS_DEV_IOCTL_PROTOVER_CMD),
-autofs_dev_ioctl_protover},
- {cmd_idx(AUTOFS_DEV_IOCTL_PROTOSUBVER_CMD),
-autofs_dev_ioctl_protosubver},
- {cmd_idx(AUTOFS_DEV_IOCTL_OPENMOUNT_CMD),
-autofs_dev_ioctl_openmount},
- {cmd_idx(AUTOFS_DEV_IOCTL_CLOSEMOUNT_CMD),
-autofs_dev_ioctl_closemount},
- {cmd_idx(AUTOFS_DEV_IOCTL_READY_CMD),
-autofs_dev_ioctl_ready},
- {cmd_idx(AUTOFS_DEV_IOCTL_FAIL_CMD),
-autofs_dev_ioctl_fail},
- {cmd_idx(AUTOFS_DEV_IOCTL_SETPIPEFD_CMD),
-autofs_dev_ioctl_setpipefd},
- {cmd_idx(AUTOFS_DEV_IOCTL_CATATONIC_CMD),
-autofs_dev_ioctl_catatonic},
- {cmd_idx(AUTOFS_DEV_IOCTL_TIMEOUT_CMD),
-autofs_dev_ioctl_timeout},
- {cmd_idx(AUTOFS_DEV_IOCTL_REQUESTER_CMD),
-autofs_dev_ioctl_requester},
- {cmd_idx(AUTOFS_DEV_IOCTL_EXPIRE_CMD),
-autofs_dev_ioctl_expire},
- {cmd_idx(AUTOFS_DEV_IOCTL_ASKUMOUNT_CMD),
-autofs_dev_ioctl_askumount},
- {cmd_idx(AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD),
-autofs_dev_ioctl_ismountpoint}
+ static ioctl_fn _ioctls[] = {
+ autofs_dev_ioctl_version,
+ autofs_dev_ioctl_protover,
+ autofs_dev_ioctl_protosubver,
+ autofs_dev_ioctl_openmount,
+ autofs_dev_ioctl_closemount,
+ autofs_dev_ioctl_ready,
+ autofs_dev_ioctl_fail,
+ autofs_dev_ioctl_setpipefd,
+ autofs_dev_ioctl_catatonic,
+ autofs_dev_ioctl_timeout,
+ autofs_dev_ioctl_requester,
+ autofs_dev_ioctl_expire,
+ autofs_dev_ioctl_askumount,
+ autofs_dev_ioctl_ismountpoint,
};
unsigned int idx = cmd_idx(cmd);
- return (idx >= ARRAY_SIZE(_ioctls)) ? NULL : _ioctls[idx].fn;
+ return (idx >= ARRAY_SIZE(_ioctls)) ? NULL : _ioctls[idx];
}
/* ioctl dispatcher */
[PATCH 1/3] autofs: remove possibly misleading /* #define DEBUG */
From: Tomohiro Kusumi Having this in autofs_i.h gives illusion that uncommenting this enables pr_debug(), but it doesn't enable all the pr_debug() in autofs because inclusion order matters. XFS has the same DEBUG macro in its core header fs/xfs/xfs.h, however XFS seems to have a rule to include this prior to other XFS headers as well as kernel headers. This is not the case with autofs, and DEBUG could be enabled via Makefile, so autofs should just get rid of this comment to make the code less confusing. It's a comment, so there is literally no functional difference. Signed-off-by: Tomohiro Kusumi Signed-off-by: Ian Kent --- fs/autofs4/autofs_i.h |2 -- 1 file changed, 2 deletions(-) diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h index dd71bd4..4404a22 100644 --- a/fs/autofs4/autofs_i.h +++ b/fs/autofs4/autofs_i.h @@ -34,8 +34,6 @@ #include #include -/* #define DEBUG */ - #ifdef pr_fmt #undef pr_fmt #endif
[PATCH v4 0/2] serial: 8250_dw: Add ACPI support for uart on Hisilicon Hip05 SoC
Handle all cases of dw8250_data->clk properly in dw8250_set_termios(), then make it as the default set_termios callback for 8250 dw uart. After that, add ACPI support for uart on Hisilicon Hip05 SoC, be careful that it is not 16500 compatible, and with Heikki's patchset[1], we safely only add ACPI identifier, due to the ACPI quirks in dw8250_quirks() only for "APMC0D08". Change since v3: - The new dev var patch is sent separately. - Address the comment from Andy, and repost patches based on Heikki Krogerus's patchset[1] "[PATCHv2 0/3] serial: dw8250: ACPI tuning" Change since v2: - Add a new patch to use new var dev in probe - Use built-in device properties to set device parameters for existing device probed by acpi, suggested by Andy Shevchenko Change since v1: - Use acpi_match_device() instead of acpi_dev_found(), limit the check to the device being probed and not a global search for whole DSDT (pointed by graeme.greg...@linaro.org) [1] http://www.spinics.net/lists/linux-acpi/msg68519.html Kefeng Wang (2): serial: 8250_dw: make dw8250_set_termios as default set_termios callback serial: 8250_dw: add ACPI support for uart on Hisilicon Hip05 SoC drivers/tty/serial/8250/8250_dw.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 1.7.12.4
Re: [PATCHV5 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only
On 30 August 2016 at 22:30, Steven Rostedt wrote:
> On Tue, 30 Aug 2016 16:07:28 +0800
> Chunyan Zhang wrote:
>
>> Currently Function traces can be only exported to ring buffer, this
>> patch added trace_export concept which can process traces and export
>> them to a registered destination as an addition to the current only
>> output of Ftrace - i.e. ring buffer.
>>
>> In this way, if we want Function traces to be sent to other destination
>> rather than ring buffer only, we just need to register a new
>> trace_export and implement its own .commit() callback or just use
>> 'trace_generic_commit()' which this patch also added and hooks up its
>> own .write() function for writing traces to the storage.
>>
>> With this patch, only Function trace (trace type is TRACE_FN)
>> is supported.
>>
>> Signed-off-by: Chunyan Zhang
>> ---
>> include/linux/trace.h | 35
>> kernel/trace/trace.c | 155
>> +-
>> kernel/trace/trace.h | 1 +
>> 3 files changed, 190 insertions(+), 1 deletion(-)
>> create mode 100644 include/linux/trace.h
>>
>> diff --git a/include/linux/trace.h b/include/linux/trace.h
>> new file mode 100644
>> index 000..30ded92
>> --- /dev/null
>> +++ b/include/linux/trace.h
>> @@ -0,0 +1,35 @@
>> +#ifndef _LINUX_TRACE_H
>> +#define _LINUX_TRACE_H
>> +
>> +#include
>> +struct trace_array;
>> +
>> +#ifdef CONFIG_TRACING
>> +/*
>> + * The trace export - an export of Ftrace. The trace_export can process
>> + * traces and export them to a registered destination as an addition to
>> + * the current only output of Ftrace - i.e. ring buffer.
>> + *
>> + * If you want traces to be sent to some other place rather than
>> + * ring buffer only, just need to register a new trace_export and
>> + * implement its own .commit() callback or just directly use
>> + * 'trace_generic_commit()' and hooks up its own .write() function
>> + * for writing traces to the storage.
>> + *
>> + * next - pointer to the next trace_export
>> + * commit- commit the traces to the destination
>> + * write - copy traces which have been delt with ->commit() to
>> + * the destination
>> + */
>> +struct trace_export {
>> + struct trace_export __rcu *next;
>> + void (*commit)(struct trace_array *, struct ring_buffer_event *);
>> + void (*write)(const char *, unsigned int);
>> +};
>> +
>> +int register_ftrace_export(struct trace_export *export);
>> +int unregister_ftrace_export(struct trace_export *export);
>> +
>> +#endif /* CONFIG_TRACING */
>> +
>> +#endif /* _LINUX_TRACE_H */
>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>> index dade4c9..3163fa6 100644
>> --- a/kernel/trace/trace.c
>> +++ b/kernel/trace/trace.c
>> @@ -40,6 +40,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #include "trace.h"
>> @@ -2128,6 +2129,155 @@ void trace_buffer_unlock_commit_regs(struct
>> trace_array *tr,
>> ftrace_trace_userstack(buffer, flags, pc);
>> }
>>
>> +static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled);
>> +
>> +static void ftrace_exports_enable(void)
>> +{
>> + static_branch_enable(&ftrace_exports_enabled);
>> +}
>> +
>> +static void ftrace_exports_disable(void)
>> +{
>> + static_branch_disable(&ftrace_exports_enabled);
>> +}
>> +
>> +static size_t trace_size[] = {
>> + [TRACE_FN] = sizeof(struct ftrace_entry),
>> + [TRACE_CTX] = sizeof(struct ctx_switch_entry),
>> + [TRACE_WAKE]= sizeof(struct ctx_switch_entry),
>> + [TRACE_STACK] = sizeof(struct stack_entry),
>> + [TRACE_PRINT] = sizeof(struct print_entry),
>> + [TRACE_BPRINT] = sizeof(struct bprint_entry),
>> + [TRACE_MMIO_RW] = sizeof(struct trace_mmiotrace_rw),
>> + [TRACE_MMIO_MAP]= sizeof(struct trace_mmiotrace_map),
>> + [TRACE_BRANCH] = sizeof(struct trace_branch),
>> + [TRACE_GRAPH_RET] = sizeof(struct ftrace_graph_ret_entry),
>> + [TRACE_GRAPH_ENT] = sizeof(struct ftrace_graph_ent_entry),
>> + [TRACE_USER_STACK] = sizeof(struct userstack_entry),
>> + [TRACE_BPUTS] = sizeof(struct bputs_entry),
>> +};
>> +
>> +static void
>> +trace_generic_commit(struct trace_array *tr,
>> +struct ring_buffer_event *event)
>> +{
>> + struct trace_entry *entry;
>> + struct trace_export *export = tr->export;
>
> Why not just pass in the export directly?
>
>> + unsigned int size = 0;
>> +
>> + entry = ring_buffer_event_data(event);
>> +
>> + size = trace_size[entry->type];
>
> BTW, it would make much more sense if you just did:
>
> size = ring_buffer_event_length(event);
>
> and get rid of that silly array, as that is prone to bugs if you add a
> new type.
>
>> + if (!size)
>> + return;
>> +
>> + if (export && export->write)
>> + export->write((char *)entry, size);
>> +}
>> +
Re: [RFC][PATCH] Fix a race between rwsem and the scheduler
On 30/08/16 22:58, Oleg Nesterov wrote:
> On 08/30, Balbir Singh wrote:
>>
>> The origin of the issue I've seen seems to be related to
>> rwsem spin lock stealing. Basically I see the system deadlock'd in the
>> following state
>>
>> I have a system with multiple threads and
>>
>> Most of the threads are stuck doing
>>
>> [67272.593915] --- interrupt: e81 at _raw_spin_lock_irqsave+0xa4/0x130
>> [67272.593915] LR = _raw_spin_lock_irqsave+0x9c/0x130
>> [67272.700996] [c00012857ae0] [c012453c] rwsem_wake+0xcc/0x110
>> [67272.749283] [c00012857b20] [c01215d8] up_write+0x78/0x90
>> [67272.788965] [c00012857b50] [c028153c]
>> unlink_anon_vmas+0x15c/0x2c0
>> [67272.798782] [c00012857bc0] [c026f5c0] free_pgtables+0xf0/0x1c0
>> [67272.842528] [c00012857c10] [c027c9a0] exit_mmap+0x100/0x1a0
>> [67272.872947] [c00012857cd0] [c00b4a98] mmput+0xa8/0x1b0
>> [67272.898432] [c00012857d00] [c00bc50c] do_exit+0x33c/0xc30
>> [67272.944721] [c00012857dc0] [c00bcee4] do_group_exit+0x64/0x100
>> [67272.969014] [c00012857e00] [c00bcfac] SyS_exit_group+0x2c/0x30
>> [67272.978971] [c00012857e30] [c0009204] system_call+0x38/0xb4
>> [67272.999016] Instruction dump:
>>
>> They are spinning on the sem->wait_lock, the holder of sem->wait_lock has
>> irq's disabled and is doing
>>
>> [c0037930fb30] c00f724c try_to_wake_up+0x6c/0x570
>> [c0037930fbb0] c0124328 __rwsem_do_wake+0x1f8/0x260
>> [c0037930fc00] c01244b4 rwsem_wake+0x84/0x110
>> [c0037930fc40] c0121598 up_write+0x78/0x90
>> [c0037930fc70] c0281a54 anon_vma_fork+0x184/0x1d0
>> [c0037930fcc0] c00b68e0 copy_process.isra.5+0x14c0/0x1870
>> [c0037930fda0] c00b6e68 _do_fork+0xa8/0x4b0
>> [c0037930fe30] c0009460 ppc_clone+0x8/0xc
>>
>> The offset of try_to_wake_up is actually misleading, it is actually stuck
>> doing the following in try_to_wake_up
>>
>> while (p->on_cpu)
>> cpu_relax();
>>
>> Analysis
>>
>> The issue is triggered, due to the following race
>>
>> CPU1 CPU2
>>
>> while () {
>> if (cond)
>> break;
>> do {
>> schedule();
>> set_current_state(TASK_UN..)
>> } while (!cond);
>> rwsem_wake()
>>spin_lock_irqsave(wait_lock)
>> raw_spin_lock_irqsave(wait_lock) wake_up_process()
>> } try_to_wake_up()
>> set_current_state(TASK_RUNNING); ..
>> list_del(&waiter.list);
>>
>> CPU2 wakes up CPU1, but before it can get the wait_lock and set
>> current state to TASK_RUNNING the following occurs
>>
>> CPU3
>> (stole the rwsem before waiter can be woken up from queue)
>> up_write()
>> rwsem_wake()
>> raw_spin_lock_irqsave(wait_lock)
>> if (!list_empty)
>> wake_up_process()
>> try_to_wake_up()
>> raw_spin_lock_irqsave(p->pi_lock)
>> ..
>> if (p->on_rq && ttwu_wakeup())
>> ..
>> while (p->on_cpu)
>> cpu_relax()
>> ..
>>
>> CPU3 tries to wake up the task on CPU1 again since it finds
>> it on the wait_queue, CPU1 is spinning on wait_lock, but immediately
>> after CPU2, CPU3 got it.
>>
>> CPU3 checks the state of p on CPU1, it is TASK_UNINTERRUPTIBLE and
>> the task is spinning on the wait_lock. Interestingly since p->on_rq
>> is checked under pi_lock, I've noticed that try_to_wake_up() finds
>> p->on_rq to be 0. This was the most confusing bit of the analysis,
>> but p->on_rq is changed under runqueue lock, rq_lock, the p->on_rq
>> check is not reliable without this fix IMHO. The race is visible
>> (based on the analysis) only when ttwu_queue() does a remote wakeup
>> via ttwu_queue_remote. In which case the p->on_rq change is not
>> done uder the pi_lock.
>>
>> The result is that after a while the entire system locks up on
>> the raw_spin_irqlock_save(wait_lock) and the holder spins infintely
>>
>> Reproduction of the issue
>>
>> The issue can be reproduced after a long run on my system with 80
>> threads and having to tweak available memory to very low and running
>> memory stress-ng mmapfork test. It usually takes a long time to
>> reproduce. I am trying to work on a test case that can reproduce
>> the issue faster, but thats work in progress. I am still testing the
>> changes on my still in a loop and the tests seem OK thus far.
>>
>> Big thanks to Benjamin and Nick for helping debug this as well.
>> Ben helped catch the missing barrier, Nick caught every missing
>> bit in my theory
>>
>> Cc: Peter Zijlstra
>> Cc: Nicholas Piggin
>> Cc: Benjamin Herrenschmidt
>>
>> Signed-off-by: Balbir Singh
>> ---
>> kernel/sched/core.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 2a906f2..582c684 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -2016,6 +2016,17 @@ try_to_wake_up(str
Re: [PATCH net-next 4/6] perf, bpf: add perf events core support for BPF_PROG_TYPE_PERF_EVENT programs
On Mon, Aug 29, 2016 at 02:17:18PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 26, 2016 at 07:31:22PM -0700, Alexei Starovoitov wrote:
> > +static int perf_event_set_bpf_handler(struct perf_event *event, u32
> > prog_fd)
> > +{
> > + struct bpf_prog *prog;
> > +
> > + if (event->overflow_handler_context)
> > + /* hw breakpoint or kernel counter */
> > + return -EINVAL;
> > +
> > + if (event->prog)
> > + return -EEXIST;
> > +
> > + prog = bpf_prog_get_type(prog_fd, BPF_PROG_TYPE_PERF_EVENT);
> > + if (IS_ERR(prog))
> > + return PTR_ERR(prog);
> > +
> > + event->prog = prog;
> > + event->orig_overflow_handler = READ_ONCE(event->overflow_handler);
> > + WRITE_ONCE(event->overflow_handler, bpf_overflow_handler);
> > + return 0;
> > +}
> > +
> > +static void perf_event_free_bpf_handler(struct perf_event *event)
> > +{
> > + struct bpf_prog *prog = event->prog;
> > +
> > + if (!prog)
> > + return;
>
> Does it make sense to do something like:
>
> WARN_ON_ONCE(event->overflow_handler != bpf_overflow_handler);
Yes that's an implicit assumption here, but checking for that
would be overkill. event->overflow_handler and event->prog are set
back to back in two places and reset here once together.
Such warn_on will only make people reading this code in the future
think that this bit is too complex to analyze by hand.
> > +
> > + WRITE_ONCE(event->overflow_handler, event->orig_overflow_handler);
> > + event->prog = NULL;
> > + bpf_prog_put(prog);
> > +}
>
>
> > static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
> > {
> > bool is_kprobe, is_tracepoint;
> > struct bpf_prog *prog;
> >
> > + if (event->attr.type == PERF_TYPE_HARDWARE ||
> > + event->attr.type == PERF_TYPE_SOFTWARE)
> > + return perf_event_set_bpf_handler(event, prog_fd);
> > +
> > if (event->attr.type != PERF_TYPE_TRACEPOINT)
> > return -EINVAL;
> >
> > @@ -7647,6 +7711,8 @@ static void perf_event_free_bpf_prog(struct
> > perf_event *event)
> > {
> > struct bpf_prog *prog;
> >
> > + perf_event_free_bpf_handler(event);
> > +
> > if (!event->tp_event)
> > return;
> >
>
> Does it at all make sense to merge the tp_event->prog thing into this
> new event->prog?
'struct trace_event_call *tp_event' is global while tp_event->perf_events
are per cpu, so I don't see how we can do that without breaking user space
logic. Right now users do single perf_event_open of kprobe and attach prog
that is executed on all cpus where kprobe is firing. Additional per-cpu
filtering is done from within bpf prog.
> > #ifdef CONFIG_HAVE_HW_BREAKPOINT
> > @@ -8957,6 +9029,14 @@ perf_event_alloc(struct perf_event_attr *attr, int
> > cpu,
> > if (!overflow_handler && parent_event) {
> > overflow_handler = parent_event->overflow_handler;
> > context = parent_event->overflow_handler_context;
> > + if (overflow_handler == bpf_overflow_handler) {
> > + event->prog = bpf_prog_inc(parent_event->prog);
> > + event->orig_overflow_handler =
> > parent_event->orig_overflow_handler;
> > + if (IS_ERR(event->prog)) {
> > + event->prog = NULL;
> > + overflow_handler = NULL;
> > + }
> > + }
> > }
>
> Should we not fail the entire perf_event_alloc() call in that IS_ERR()
> case?
Yes. Good point. Will do.
Re: [RFC][PATCH] Fix a race between rwsem and the scheduler
On 30/08/16 22:19, Peter Zijlstra wrote:
> On Tue, Aug 30, 2016 at 06:49:37PM +1000, Balbir Singh wrote:
>>
>>
>> The origin of the issue I've seen seems to be related to
>> rwsem spin lock stealing. Basically I see the system deadlock'd in the
>> following state
>
> As Nick says (good to see you're back Nick!), this is unrelated to
> rwsems.
>
> This is true for pretty much every blocking wait loop out there, they
> all do:
>
> for (;;) {
> current->state = UNINTERRUPTIBLE;
> smp_mb();
> if (cond)
> break;
> schedule();
> }
> current->state = RUNNING;
>
> Which, if the wakeup is spurious, is just the pattern you need.
Yes True! My bad Alexey had seen the same basic pattern, I should have been
clearer
in my commit log. Should I resend the patch?
>
>> +++ b/kernel/sched/core.c
>> @@ -2016,6 +2016,17 @@ try_to_wake_up(struct task_struct *p, unsigned int
>> state, int wake_flags)
>> success = 1; /* we're going to change ->state */
>> cpu = task_cpu(p);
>>
>> +/*
>> + * Ensure we see on_rq and p_state consistently
>> + *
>> + * For example in __rwsem_down_write_failed(), we have
>> + *[S] ->on_rq = 1 [L] ->state
>> + *MB RMB
>
> There isn't an MB there. The best I can do is UNLOCK+LOCK, which, thanks
> to PPC, is _not_ MB. It is however sufficient for this case.
>
The MB comes from the __switch_to() in schedule(). Ben mentioned it in a
different thread.
>> + *[S] ->state = TASK_UNINTERRUPTIBLE[L] ->on_rq
>> + * In the absence of the RMB p->on_rq can be observed to be 0
>> + * and we end up spinning indefinitely in while (p->on_cpu)
>> + */
>
>
> /*
>* Ensure we load p->on_rq _after_ p->state, otherwise it would
>* be possible to, falsely, observe p->on_rq == 0 and get stuck
>* in smp_cond_load_acquire() below.
>*
>* sched_ttwu_pending() try_to_wake_up()
>* [S] p->on_rq = 1; [L] P->state
>* UNLOCK rq->lock
>*
>* schedule() RMB
>* LOCK rq->lock
>* UNLOCK rq->lock
>*
>* [task p]
>* [S] p->state = UNINTERRUPTIBLE [L] p->on_rq
>*
>* Pairs with the UNLOCK+LOCK on rq->lock from the
>* last wakeup of our task and the schedule that got our task
>* current.
>*/
>
>> +smp_rmb();
>> if (p->on_rq && ttwu_remote(p, wake_flags))
>> goto stat;
>>
>
>
> Now, this has been present for a fair while, I suspect ever since we
> reworked the wakeup path to not use rq->lock twice. Curious you only now
> hit it.
>
Yes, I just hit it a a week or two back and I needed to collect data to
explain why p->on_rq got to 0. Hitting it requires extreme stress -- for me
I needed a system with large threads and less memory running stress-ng.
Reproducing the problem takes an unpredictable amount of time.
Balbir Singh.
Re: [Documentation] State of CPU controller in cgroup v2
On Mon, Aug 29, 2016 at 3:20 PM, Tejun Heo wrote: >> > These base-system operations are special regardless of cgroup and we >> > already have sometimes crude ways to affect their behaviors where >> > necessary through sysctl knobs, priorities on specific kernel threads >> > and so on. cgroup doesn't change the situation all that much. What >> > gets left in the root cgroup usually are the base-system operations >> > which are outside the scope of cgroup resource control in the first >> > place and cgroup resource graph can treat the root as an opaque anchor >> > point. >> >> This seems to explain why the controllers need to be able to handle >> things being charged to the root cgroup (or to an unidentifiable >> cgroup, anyway). That isn't quite the same thing as allowing, from an >> ABI point of view, the root cgroup to contain processes and cgroups >> but not allowing other cgroups to do the same thing. Consider: > > The points are 1. we need the root to be a special container anyway But you don't need to let userspace see that. > 2. allowing it to be special and contain system-wide consumptions > doesn't make the resource graph inconsistent once all non-system-wide > consumptions are put in non-root cgroups, and 3. this is the most > natural way to handle the situation both from implementation and > interface standpoints as it makes non-cgroup configuration a natural > degenerate case of cgroup configuration. > >> suppose that systemd (or some competing cgroup manager) is designed to >> run in the root cgroup namespace. It presumably expects *itself* to >> be in the root cgroup. Now try to run it using cgroups v2 in a >> non-root namespace. I don't see how it can possibly work if it the >> hierarchy constraints don't permit it to create sub-cgroups while it's >> still in the root. In fact, this seems impossible to fix even with >> user code changes. The manager would need to simultaneously create a >> new child cgroup to contain itself and assign itself to that child >> cgroup, because the intermediate state is illegal. > > Please re-read the constraint. It doesn't prevent any organizational > operations before resource control is enabled. > >> I really, really think that cgroup v2 should supply the same >> *interface* inside and outside of a non-root namespace. If this is > > It *does*. That's what I tried to explain, that it's exactly > isomorhpic once you discount the system-wide consumptions. > I don't think I agree. Suppose I wrote an init program or a cgroup manager. I can expect that init program to be started in the root cgroup. The program can be lazy and write +io to /cgroup/cgroup.subtree_control and then create some new cgroup /cgroup/a and it will work (I just tried it). Now I run that program in a namespace. It will not work because it'll get -EBUSY when it tries to write to cgroup.subtree_control. (I just tried this, too, only using cd instead of a namespace.) So it's *not* isomorphic. It *also* won't work (I think) if subtree control is enabled on the root, but I don't think this is a problem in practice because subtree control won't be enabled on the namespace root by a sensible cgroup manager. --Andy
Re: [PATCH] cpufreq: Drop unnecessary check from cpufreq_policy_alloc()
On 31-08-16, 03:11, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Since cpufreq_policy_alloc() doesn't use its dev variable for
> anything useful, drop that variable from there along with the
> NULL check against it.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/cpufreq/cpufreq.c |4
> 1 file changed, 4 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -1073,13 +1073,9 @@ static void handle_update(struct work_st
>
> static struct cpufreq_policy *cpufreq_policy_alloc(unsigned int cpu)
> {
> - struct device *dev = get_cpu_device(cpu);
> struct cpufreq_policy *policy;
> int ret;
>
> - if (WARN_ON(!dev))
> - return NULL;
> -
> policy = kzalloc(sizeof(*policy), GFP_KERNEL);
> if (!policy)
> return NULL;
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH] printk/nmi: avoid direct printk()-s from __printk_nmi_flush()
On (08/30/16 13:19), Petr Mladek wrote:
[..]
> > yes, x86 has a per-cpu nmi_state to handle the case when NMI is
> > loosing its NMI context. But other arch-s, as far as I can see,
> > don't do that. Does it mean that we are safe only on x86?
>
> My understanding is that the kernel would crash on the other
> architectures if a double iret was called. By other words,
> they would have bigger problems than the nmi_enter()/nmi_exit()
> calls. So, we should be on the safe side.
>
> > this printk_func_saved thing is still will be needed, I think,
> > for alt_printk.
> >
> > Example:
> >
> > process abc
> > printk()
> > alt_printk_enter()
> > this_cpu_write(printk_func, vprintk_alt);
> > -> NMI
> > : printk_nmi_enter()
> > : this_cpu_write(printk_func, vprintk_nmi);
> > : printk_nmi_exit()
> > : this_cpu_write(printk_func, vprintk_default);
> > return NMI
> >
> > printk() nested printk -> vprintk_default(), set by
> > nmi_exit()
> > alt_printk_exit()
> > ...
>
> I see. But then we will need to be more careful because printk_func
> and printk_func_saved will be manipulated in different contexts:
> normal, irq, nmi. A solution might be using an atomic counter
> and selecting the right vprintk_func according to the value.
yes, I thought about something like this.
... or we can use the one and only 'nmi_seq' buffer and share it between
NMI and alt_printk, adding a special prefix to every message
if (in_nmi())
sprintf("NMI:%s", message)
else
sprintf("%s", message)
so, yes, it can get hairy, but at least it will be grep-able, still
better than nothing.
> Well, I am still afraid that yet another alt_printk is not
> the way to go.
well, it might be and it might be not.
-ss
Re: [PART2 PATCH v7 12/12] svm: Implements update_pi_irte hook to setup posted interrupt
2016-08-23 13:52-0500, Suravee Suthikulpanit: > From: Suravee Suthikulpanit > > This patch implements update_pi_irte function hook to allow SVM > communicate to IOMMU driver regarding how to set up IRTE for handling > posted interrupt. > > In case AVIC is enabled, during vcpu_load/unload, SVM needs to update > IOMMU IRTE with appropriate host physical APIC ID. Also, when > vcpu_blocking/unblocking, SVM needs to update the is-running bit in > the IOMMU IRTE. Both are achieved via calling amd_iommu_update_ga(). > > However, if GA mode is not enabled for the pass-through device, > IOMMU driver will simply just return when calling amd_iommu_update_ga. > > Signed-off-by: Suravee Suthikulpanit > --- I forgot nitpicks in the office before going on a vacation, ;) Reviewed-by: Radim Krčmář
Re: [PATCH RESEND] drm: bridge/dw-hdmi: Fix colorspace and scan information registers values
Hi, On 08/29/2016 03:00 PM, Jose Abreu wrote: Colorspace and scan information values were being written in wrong offsets. This patch corrects this and writes the values at the offsets specified in the databook. queued to drm-misc after cleaning up some checkpatch errors. Thanks, Archit Signed-off-by: Jose Abreu Acked-by: Russell King Cc: Carlos Palminha Cc: Archit Taneja Cc: David Airlie Cc: Russell King Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org --- drivers/gpu/drm/bridge/dw-hdmi.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c index 77ab473..cdf39aa 100644 --- a/drivers/gpu/drm/bridge/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/dw-hdmi.c @@ -940,10 +940,11 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode *mode) */ /* -* AVI data byte 1 differences: Colorspace in bits 4,5 rather than 5,6, -* active aspect present in bit 6 rather than 4. +* AVI data byte 1 differences: Colorspace in bits 0,1 rather than 5,6, +* scan info in bits 4,5 rather than 0,1 and active aspect present in +* bit 6 rather than 4. */ - val = (frame.colorspace & 3) << 4 | (frame.scan_mode & 0x3); + val = (frame.scan_mode & 3) << 4 | (frame.colorspace & 3); if (frame.active_aspect & 15) val |= HDMI_FC_AVICONF0_ACTIVE_FMT_INFO_PRESENT; if (frame.top_bar || frame.bottom_bar) -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH V3 3/3] dmaengine: qcom_hidma: add error reporting for tx_status
On Tue, Aug 30, 2016 at 01:51:02PM -0400, Sinan Kaya wrote: > On 8/30/2016 1:37 PM, Sinan Kaya wrote: > > On 8/30/2016 1:04 PM, Vinod Koul wrote: > >> On Tue, Aug 23, 2016 at 12:48:11AM -0400, Sinan Kaya wrote: > >> > >>> spin_lock_init(&lldev->lock); > >>> - tasklet_init(&lldev->rst_task, hidma_ll_abort, (unsigned long)lldev); > >> > >> ?? > >> > >> This is not described in changlog? If you are not using in anywhere else, > >> then rst_task variable should be removed too.. > >> > > > > Sure, I can add more description. I thought I did mention that we are no > > longer > > resetting the hardware in ISR. > > > > I can certainly mention that rst_task variable is removed and can get rid > > of it. > > It is no longer in use. > > > > It looks like I mentioned this in the cover letter only not in the commit > message. > I'll pull the description into the commit message too. Sounds good to me, thanks -- ~Vinod
Re: [PATCH net] rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash possibly
On Wed, 2016-08-31 at 10:56 +0800, f...@ikuai8.com wrote:
> From: Gao Feng
>
> The original codes depend on that the function parameters are evaluated from
> left to right. But the parameter's evaluation order is not defined in C
> standard actually.
>
> When flow_keys_have_l4(&keys) is invoked before ___skb_get_hash(skb, &keys,
> hashrnd) with some compilers or environment, the keys passed to
> flow_keys_have_l4 is not initialized.
>
> Signed-off-by: Gao Feng
> ---
Good catch, please add
Fixes: 6db61d79c1e1 ("flow_dissector: Ignore flow dissector return value from
___skb_get_hash")
Acked-by: Eric Dumazet
Re: [PATCH] kasan: avoid overflowing quarantine size on low memory systems
On Monday, August 1, 2016 at 10:59:29 AM UTC-4, Alexander Potapenko wrote:
> If the total amount of memory assigned to quarantine is less than the
> amount of memory assigned to per-cpu quarantines, |new_quarantine_size|
> may overflow. Instead, set it to zero.
>
> Reported-by: Dmitry Vyukov
> Fixes: 55834c59098d ("mm: kasan: initial memory quarantine
> implementation")
> Signed-off-by: Alexander Potapenko
> ---
> mm/kasan/quarantine.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> index 65793f1..416d3b0 100644
> --- a/mm/kasan/quarantine.c
> +++ b/mm/kasan/quarantine.c
> @@ -196,7 +196,7 @@ void quarantine_put(struct kasan_free_meta *info, struct
> kmem_cache *cache)
>
> void quarantine_reduce(void)
> {
> - size_t new_quarantine_size;
> + size_t new_quarantine_size, percpu_quarantines;
> unsigned long flags;
> struct qlist_head to_free = QLIST_INIT;
> size_t size_to_free = 0;
> @@ -214,7 +214,15 @@ void quarantine_reduce(void)
>*/
> new_quarantine_size = (READ_ONCE(totalram_pages) << PAGE_SHIFT) /
> QUARANTINE_FRACTION;
> - new_quarantine_size -= QUARANTINE_PERCPU_SIZE * num_online_cpus();
> + percpu_quarantines = QUARANTINE_PERCPU_SIZE * num_online_cpus();
> + if (new_quarantine_size < percpu_quarantines) {
> + WARN_ONCE(1,
> + "Too little memory, disabling global KASAN
> quarantine.\n",
> + );
> + new_quarantine_size = 0;
> + } else {
> + new_quarantine_size -= percpu_quarantines;
> + }
> WRITE_ONCE(quarantine_size, new_quarantine_size);
>
> last = global_quarantine.head;
> --
> 2.8.0.rc3.226.g39d4020
On Monday, August 1, 2016 at 10:59:29 AM UTC-4, Alexander Potapenko wrote:
> If the total amount of memory assigned to quarantine is less than the
> amount of memory assigned to per-cpu quarantines, |new_quarantine_size|
> may overflow. Instead, set it to zero.
>
> Reported-by: Dmitry Vyukov
> Fixes: 55834c59098d ("mm: kasan: initial memory quarantine
> implementation")
> Signed-off-by: Alexander Potapenko
> ---
> mm/kasan/quarantine.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> index 65793f1..416d3b0 100644
> --- a/mm/kasan/quarantine.c
> +++ b/mm/kasan/quarantine.c
> @@ -196,7 +196,7 @@ void quarantine_put(struct kasan_free_meta *info, struct
> kmem_cache *cache)
>
> void quarantine_reduce(void)
> {
> - size_t new_quarantine_size;
> + size_t new_quarantine_size, percpu_quarantines;
> unsigned long flags;
> struct qlist_head to_free = QLIST_INIT;
> size_t size_to_free = 0;
> @@ -214,7 +214,15 @@ void quarantine_reduce(void)
>*/
> new_quarantine_size = (READ_ONCE(totalram_pages) << PAGE_SHIFT) /
> QUARANTINE_FRACTION;
> - new_quarantine_size -= QUARANTINE_PERCPU_SIZE * num_online_cpus();
> + percpu_quarantines = QUARANTINE_PERCPU_SIZE * num_online_cpus();
> + if (new_quarantine_size < percpu_quarantines) {
> + WARN_ONCE(1,
> + "Too little memory, disabling global KASAN
> quarantine.\n",
> + );
> + new_quarantine_size = 0;
> + } else {
> + new_quarantine_size -= percpu_quarantines;
> + }
> WRITE_ONCE(quarantine_size, new_quarantine_size);
>
> last = global_quarantine.head;
> --
> 2.8.0.rc3.226.g39d4020
Re: [PATCH net] rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash possibly
On Wed, Aug 31, 2016 at 12:14 PM, Eric Dumazet wrote:
> On Wed, 2016-08-31 at 10:56 +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> The original codes depend on that the function parameters are evaluated from
>> left to right. But the parameter's evaluation order is not defined in C
>> standard actually.
>>
>> When flow_keys_have_l4(&keys) is invoked before ___skb_get_hash(skb, &keys,
>> hashrnd) with some compilers or environment, the keys passed to
>> flow_keys_have_l4 is not initialized.
>>
>> Signed-off-by: Gao Feng
>> ---
>
> Good catch, please add
>
> Fixes: 6db61d79c1e1 ("flow_dissector: Ignore flow dissector return value from
> ___skb_get_hash")
> Acked-by: Eric Dumazet
>
>
Add it into the description and resend the patch again?
Best Regards
Feng
[PATCH v3 1/2] regulator: pwm: Add support for a fixed delay after duty cycle changes
From: Matthias Kaehlcke
A change of the duty cycle doesn't necessarily cause an immediate switch
to the target voltage. On many PWM regulators there is a fixed "settle
time" (irrespective of the jump size) that we need to wait after an
upward jump. This change introduces the device tree property
"settle-time-up-us" which allows us to specify a fixed delay after a
voltage increase.
We don't add an option of a fixed delay on the way down for now because
the way down is probably modelled best with a ramp rate, not a fixed
delay.
Signed-off-by: Matthias Kaehlcke
Signed-off-by: Douglas Anderson
---
Changes in v3:
- Took out fixed delay for falling transitions
- Updated description
.../devicetree/bindings/regulator/pwm-regulator.txt | 6 ++
drivers/regulator/pwm-regulator.c | 19 +++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
index 3aeba9f86ed8..9dc15d18e787 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -34,6 +34,12 @@ Only required for Voltage Table Mode:
First cell is voltage in microvolts (uV)
Second cell is duty-cycle in percent (%)
+Optional properties:
+
+- settle-time-up-us: Time to settle down after a voltage increase
+ (unit: us). For regulators with a ramp delay
+ the two values are added.
+
Optional properties for Continuous mode:
- pwm-dutycycle-unit: Integer value encoding the duty cycle unit. If not
defined, <100> is assumed, meaning that
diff --git a/drivers/regulator/pwm-regulator.c
b/drivers/regulator/pwm-regulator.c
index c24524242da2..94f1ca3b793d 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -48,6 +48,8 @@ struct pwm_regulator_data {
/* Enable GPIO */
struct gpio_desc *enb_gpio;
+
+ u32 settle_time_up_us;
};
struct pwm_voltages {
@@ -195,6 +197,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev
*rdev,
unsigned int max_uV_duty = drvdata->continuous.max_uV_dutycycle;
unsigned int duty_unit = drvdata->continuous.dutycycle_unit;
unsigned int ramp_delay = rdev->constraints->ramp_delay;
+ unsigned int delay = 0;
int min_uV = rdev->constraints->min_uV;
int max_uV = rdev->constraints->max_uV;
int diff_uV = max_uV - min_uV;
@@ -233,12 +236,17 @@ static int pwm_regulator_set_voltage(struct regulator_dev
*rdev,
return ret;
}
- if ((ramp_delay == 0) || !pwm_regulator_is_enabled(rdev))
+ if (req_min_uV > old_uV)
+ delay = drvdata->settle_time_up_us;
+
+ if (ramp_delay != 0)
+ /* Adjust ramp delay to uS and add to settle time. */
+ delay += DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
+
+ if ((delay == 0) || !pwm_regulator_is_enabled(rdev))
return 0;
- /* Ramp delay is in uV/uS. Adjust to uS and delay */
- ramp_delay = DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
- usleep_range(ramp_delay, ramp_delay + DIV_ROUND_UP(ramp_delay, 10));
+ usleep_range(delay, delay + DIV_ROUND_UP(delay, 10));
return 0;
}
@@ -368,6 +376,9 @@ static int pwm_regulator_probe(struct platform_device *pdev)
if (!init_data)
return -ENOMEM;
+ of_property_read_u32(np, "settle-time-up-us",
+ &drvdata->settle_time_up_us);
+
config.of_node = np;
config.dev = &pdev->dev;
config.driver_data = drvdata;
--
2.8.0.rc3.226.g39d4020
[PATCH v3 2/2] regulator: pwm: Prevent falling too fast
On some boards it's possible that transitioning the PWM regulator
downwards too fast will trigger the over voltage protection (OVP) on the
regulator. This is because until the voltage actually falls there is a
time when the requested voltage is much lower than the actual voltage.
We'll fix this OVP problem by allowing users to specify the maximum
voltage that we can safely fall. Apparently this maximum safe voltage
should be specified as a percentage of the current voltage. The PWM
regulator will then break things into separate steps with a delay in
between.
In order to figure out what the delay should be we need to figure out
how slowly the voltage rail might fall in the worst (slowest) case.
We'll assume this worst case is present and delay so we know for sure
that we've finished each step.
In this patch we actually block returning from the set_voltage() call
until we've finished delaying. A future patch atop this one might
choose to return more immediately and let the voltages fall in the
background. That would possibly to allow us to cancel a slow downward
decay if there was a request to go back up.
Signed-off-by: Douglas Anderson
---
Changes in v3:
- Prevent falling too fast new for v3.
.../bindings/regulator/pwm-regulator.txt | 7 ++
drivers/regulator/pwm-regulator.c | 79 +++---
2 files changed, 78 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
index 9dc15d18e787..99fa09c42aac 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -39,6 +39,13 @@ Optional properties:
- settle-time-up-us: Time to settle down after a voltage increase
(unit: us). For regulators with a ramp delay
the two values are added.
+- safe-fall-percent: If specified, it's not safe to transition the regulator
+ down faster than this amount and bigger jumps need to
+ be broken into more than one step.
+- slowest-decay-rate: Describes how slowly the regulator voltage will
+ decay down in the worst case (lightest expected load).
+ Specified in uV / us (like main regulator ramp rate).
+ This is required when safe-fall-percent is specified.
Optional properties for Continuous mode:
- pwm-dutycycle-unit: Integer value encoding the duty cycle unit. If not
diff --git a/drivers/regulator/pwm-regulator.c
b/drivers/regulator/pwm-regulator.c
index 94f1ca3b793d..47675632c0c6 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -50,6 +50,8 @@ struct pwm_regulator_data {
struct gpio_desc *enb_gpio;
u32 settle_time_up_us;
+ u32 slowest_decay_rate;
+ u32 safe_fall_percent;
};
struct pwm_voltages {
@@ -188,9 +190,8 @@ static int pwm_regulator_get_voltage(struct regulator_dev
*rdev)
return voltage + min_uV;
}
-static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
-int req_min_uV, int req_max_uV,
-unsigned int *selector)
+static int _pwm_regulator_set_voltage(struct regulator_dev *rdev,
+ int old_uV, int req_uV)
{
struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
unsigned int min_uV_duty = drvdata->continuous.min_uV_dutycycle;
@@ -202,7 +203,6 @@ static int pwm_regulator_set_voltage(struct regulator_dev
*rdev,
int max_uV = rdev->constraints->max_uV;
int diff_uV = max_uV - min_uV;
struct pwm_state pstate;
- int old_uV = pwm_regulator_get_voltage(rdev);
unsigned int diff_duty;
unsigned int dutycycle;
int ret;
@@ -219,8 +219,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev
*rdev,
else
diff_duty = max_uV_duty - min_uV_duty;
- dutycycle = DIV_ROUND_CLOSEST_ULL((u64)(req_min_uV - min_uV) *
- diff_duty,
+ dutycycle = DIV_ROUND_CLOSEST_ULL((u64)(req_uV - min_uV) * diff_duty,
diff_uV);
if (max_uV_duty < min_uV_duty)
@@ -236,12 +235,12 @@ static int pwm_regulator_set_voltage(struct regulator_dev
*rdev,
return ret;
}
- if (req_min_uV > old_uV)
+ if (req_uV > old_uV)
delay = drvdata->settle_time_up_us;
if (ramp_delay != 0)
/* Adjust ramp delay to uS and add to settle time. */
- delay += DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
+ delay += DIV_ROUND_UP(abs(req_uV - old_uV), ramp_delay);
if ((delay == 0) || !pwm_regulator_is_enabled(rdev))
return 0;
@@ -251,6 +250,47 @
Re: [PATCH 0/3] Small fixes and cleanup
> "Finn" == Finn Thain writes: Finn> Miscellaneous small patches for an interrupt latency issue, a Finn> compiler warning and a documentation cleanup. Applied patches 1 and 2 to 4.9/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v2] scsi: move function declarations to scsi_priv.h
> "Baoyou" == Baoyou Xie writes: Baoyou> We get 2 warnings about global functions without a declaration Baoyou> in the scsi driver when building with W=1: Baoyou> drivers/scsi/scsi_lib.c:467:6: warning: no previous prototype Baoyou> for 'scsi_requeue_run_queue' [-Wmissing-prototypes] Baoyou> drivers/scsi/scsi_lib.c:2609:6: warning: no previous prototype Baoyou> for 'scsi_evt_thread' [-Wmissing-prototypes] Baoyou> in fact, both functions are declared in drivers/scsi/scsi_scan.c Baoyou> but need to move them into scsi_priv.h. Applied to 4.9/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 0/7 v5] K3DMA fixes for HiKey HDMI audio
On Mon, Aug 29, 2016 at 10:30:46AM -0700, John Stultz wrote: > Just sending these the k3dma fixes and cyclic mode patches > needed to support audio on HiKey, hopefully one last time. :) > > Again, no code changes here, but I did re-order the Kconfig > chnage to be last to avoid a bisection build issue on i386 > w/ COMPILE_TEST that the kbuild test bot found. Applied all, thanks -- ~Vinod
Re: [PATCH V3 2/2] rtc/rtc-cmos: Initialize software counters before irq is registered
Hi, Pratyush,
I'm not sure who is the maintainer to review and take the patches,
In MATAINERS file, x86 hpet is orphaned. rtc-cmos may go to rtc
maitianer Alessandro Zummo
Ccing Andrew maybe he can also take the patches for orphaned component.
On 08/30/16 at 03:24pm, Pratyush Anand wrote:
> Hi Dave,
>
> On 30/08/2016:04:22:30 PM, Dave Young wrote:
> > Hi, Pratyush
> >
> > On 08/16/16 at 08:55am, Pratyush Anand wrote:
> > > We have observed on few x86 machines with rtc-cmos device that
> > > hpet_rtc_interrupt() is called just after irq registration and before
> > > cmos_do_probe() could call hpet_rtc_timer_init().
> > >
> > > So, neither hpet_default_delta nor hpet_t1_cmp is initialized by the time
> > > interrupt is raised in the given situation, and this results in NMI
> > > watchdog LOCKUP.
> > >
> > > It has only been observed sporadically on kdump secondary kernels.
> > >
> > > See the call trace:
> > > ---<-snip->---
> > >27.913194] Kernel panic - not syncing: Watchdog detected hard LOCKUP on
> > > cpu 0
> > > [ 27.915371] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> > > 3.10.0-342.el7.x86_64 #1
> > > [ 27.917503] Hardware name: HP ProLiant DL160 Gen8, BIOS J03 02/10/2014
> > > [ 27.919455] 8186a728 59c82488 880034e05af0
> > > 81637bd4
> > > [ 27.921870] 880034e05b70 8163144a 0010
> > > 880034e05b80
> > > [ 27.924257] 880034e05b20 59c82488
> > >
> > > [ 27.926599] Call Trace:
> > > [ 27.927352][] dump_stack+0x19/0x1b
> > > [ 27.929080] [] panic+0xd8/0x1e7
> > > [ 27.930588] [] ? restart_watchdog_hrtimer+0x50/0x50
> > > [ 27.932502] [] watchdog_overflow_callback+0xc2/0xd0
> > > [ 27.934427] [] __perf_event_overflow+0xa1/0x250
> > > [ 27.936232] [] perf_event_overflow+0x14/0x20
> > > [ 27.937957] [] intel_pmu_handle_irq+0x1e8/0x470
> > > [ 27.939799] [] perf_event_nmi_handler+0x2b/0x50
> > > [ 27.941649] [] nmi_handle.isra.0+0x69/0xb0
> > > [ 27.943348] [] do_nmi+0x169/0x340
> > > [ 27.944802] [] end_repeat_nmi+0x1e/0x2e
> > > [ 27.946424] [] ? hpet_rtc_interrupt+0x85/0x380
> > > [ 27.948197] [] ? hpet_rtc_interrupt+0x85/0x380
> > > [ 27.949992] [] ? hpet_rtc_interrupt+0x85/0x380
> > > [ 27.951816] <>[] ?
> > > run_timer_softirq+0x43/0x340
> > > [ 27.954114] [] handle_irq_event_percpu+0x3e/0x1e0
> > > [ 27.955962] [] handle_irq_event+0x3d/0x60
> > > [ 27.957635] [] handle_edge_irq+0x77/0x130
> > > [ 27.959332] [] handle_irq+0xbf/0x150
> > > [ 27.960949] [] do_IRQ+0x4f/0xf0
> > > [ 27.962434] [] common_interrupt+0x6d/0x6d
> > > [ 27.964101][] ?
> > > _raw_spin_unlock_irqrestore+0x1b/0x40
> > > [ 27.966308] [] __setup_irq+0x2a7/0x570
> > > [ 28.067859] [] ? hpet_cpuhp_notify+0x140/0x140
> > > [ 28.069709] [] request_threaded_irq+0xcc/0x170
> > > [ 28.071585] [] cmos_do_probe+0x1e6/0x450
> > > [ 28.073240] [] ? cmos_do_probe+0x450/0x450
> > > [ 28.074911] [] cmos_pnp_probe+0xbb/0xc0
> > > [ 28.076533] [] pnp_device_probe+0x65/0xd0
> > > [ 28.078198] [] driver_probe_device+0x87/0x390
> > > [ 28.079971] [] __driver_attach+0x93/0xa0
> > > [ 28.081660] [] ? __device_attach+0x40/0x40
> > > [ 28.083662] [] bus_for_each_dev+0x73/0xc0
> > > [ 28.085370] [] driver_attach+0x1e/0x20
> > > [ 28.086974] [] bus_add_driver+0x200/0x2d0
> > > [ 28.088634] [] ? rtc_sysfs_init+0xe/0xe
> > > [ 28.090349] [] driver_register+0x64/0xf0
> > > [ 28.091989] [] pnp_register_driver+0x20/0x30
> > > [ 28.093707] [] cmos_init+0x11/0x71
> > > ---<-snip->---
> > >
> > > The previous patch split hpet_rtc_timer_init into
> > > hpet_rtc_timer_counter_init() and hpet_rtc_timer_enable().
> > >
> > > Therefore, this patch moved hpet_rtc_timer_counter_init() before IRQ
> > > registration, so that we can gracefully handle such spurious interrupts.
> > >
> > > We were able to reproduce the problem in maximum 15 trials of kdump
> > > secondary kernel boot on an hp-dl160gen8 machine without this patch.
> > > However, more than 35 trials went fine after applying this patch.
> > >
> > > Signed-off-by: Pratyush Anand
> > > [dzic...@redhat.com: edited the patch's summary]
> > > Signed-off-by: Don Zickus
> > > ---
> > > drivers/rtc/rtc-cmos.c | 13 -
> > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> > > index 43745cac0141..089d987f2638 100644
> > > --- a/drivers/rtc/rtc-cmos.c
> > > +++ b/drivers/rtc/rtc-cmos.c
> > > @@ -129,6 +129,16 @@ static inline int hpet_rtc_dropped_irq(void)
> > > return 0;
> > > }
> > >
> > > +static inline int hpet_rtc_timer_counter_init(void)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > > +static inline int hpet_rtc_timer_enable(void)
> > > +{
> > > + return 0;
> > > +}
> > > +
> >
> > Can these dummy functions go to /usr/include/linux/hpet.h alont with
> > the #ifdef e
Re: [PATCH 1/4] spinlock: Document memory barrier rules
On 08/29/2016 03:44 PM, Peter Zijlstra wrote:
If you add a barrier, the Changelog had better be clear. And I'm still
not entirely sure I get what exactly this barrier should do, nor why it
defaults to a full smp_mb. If what I suspect it should do, only PPC and
ARM64 need the barrier.
The barrier must ensure that taking the spinlock (as observed by another
cpu with spin_unlock_wait()) and a following read are ordered.
start condition: sma->complex_mode = false;
CPU 1:
spin_lock(&sem->lock); /* sem_nsems instances */
smp_mb__after_spin_lock();
if (!smp_load_acquire(&sma->complex_mode)) {
/* fast path successful! */
return sops->sem_num;
}
/* slow path, not relevant */
CPU 2: (holding sma->sem_perm.lock)
smp_store_mb(sma->complex_mode, true);
for (i = 0; i < sma->sem_nsems; i++) {
spin_unlock_wait(&sma->sem_base[i].lock);
}
It must not happen that both CPUs proceed:
Either CPU1 proceeds, then CPU2 must spin in spin_unlock_wait()
or CPU2 proceeds, then CPU1 must enter the slow path.
What about this?
/*
* spin_lock() provides ACQUIRE semantics regarding reading the lock.
* There are no guarantees that the store of the lock is visible before
* any read or write operation within the protected area is performed.
* If the store of the lock must happen first, this function is required.
*/
#define spin_lock_store_acquire()
I would update the patch series.
--
Manfred
[PATCH v2 3/3] scsi/ncr5380: Improve interrupt latency during PIO tranfers
Large PIO transfers are broken up into chunks to try to avoid disabling
local IRQs for long periods. But IRQs are still disabled for too long
and this causes SCC FIFO overruns during serial port transfers.
This patch reduces the PIO chunk size to reduce interrupt latency to
something on the order of milliseconds, at the expense of additional CPU
overhead from extra iterations of the NCR5380_main() loop.
That CPU overhead is a problem for slow machines (e.g. mac_scsi on 25 MHz
68030) but these machines generally use PDMA not PIO. This patch doesn't
make the overhead any worse on my Mac LC III (because it only gets about
510 accesses per ms).
This patch decreases disk performance by a fraction of one percent for
dmx3191d on my 333 MHz PowerPC 750. Other affected hardware (such as
g_NCR5380 on x86) was not tested but 5380 ISA cards generally use PDMA
and not PIO.
Signed-off-by: Finn Thain
---
Changed since v1:
- PIO transfer chunk size is now hard-coded for simplicity.
---
drivers/scsi/NCR5380.c |8
drivers/scsi/NCR5380.h |2 ++
2 files changed, 6 insertions(+), 4 deletions(-)
Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c 2016-08-31 14:44:51.0 +1000
+++ linux/drivers/scsi/NCR5380.c2016-08-31 14:44:52.0 +1000
@@ -1849,11 +1849,11 @@ static void NCR5380_information_transfer
/* XXX - need to source or sink
data here, as appropriate */
}
} else {
- /* Break up transfer into 3 ms chunks,
-* presuming 6 accesses per handshake.
+ /* Transfer a small chunk so that the
+* irq mode lock is not held too long.
*/
- transfersize = min((unsigned
long)cmd->SCp.this_residual,
-
hostdata->accesses_per_ms / 2);
+ transfersize =
min(cmd->SCp.this_residual,
+
NCR5380_PIO_CHUNK_SIZE);
len = transfersize;
NCR5380_transfer_pio(instance, &phase,
&len,
(unsigned char
**)&cmd->SCp.ptr);
Index: linux/drivers/scsi/NCR5380.h
===
--- linux.orig/drivers/scsi/NCR5380.h 2016-08-31 14:44:51.0 +1000
+++ linux/drivers/scsi/NCR5380.h2016-08-31 14:44:52.0 +1000
@@ -250,6 +250,8 @@ struct NCR5380_cmd {
#define NCR5380_CMD_SIZE (sizeof(struct NCR5380_cmd))
+#define NCR5380_PIO_CHUNK_SIZE 256
+
static inline struct scsi_cmnd *NCR5380_to_scmd(struct NCR5380_cmd *ncmd_ptr)
{
return ((struct scsi_cmnd *)ncmd_ptr) - 1;
Re: trace: use-after-free in hist_unreg_all
On Tuesday, June 28, 2016 at 8:59:10 AM UTC-4, dvyukov wrote: > Hello, > > While running tools/testing/selftests test suite with KASAN I hit the > following use-after-free report: > > > > == > BUG: KASAN: use-after-free in hist_unreg_all+0x1a1/0x1d0 at addr > 880031632cc0 > Read of size 8 by task ftracetest/7413 > = > BUG kmalloc-128 (Not tainted): kasan: bad access detected > - > > Disabling lock debugging due to kernel taint > INFO: Allocated in 0x age=18446712312426182376 cpu=0 pid=0 > [< inline >] kmalloc include/linux/slab.h:478 > [< inline >] kzalloc include/linux/slab.h:622 > [< none >] event_hist_trigger_func+0xfcd/0x2430 > kernel/trace/trace_events_hist.c:1552 > [< none >] ___slab_alloc+0x564/0x5e0 mm/slub.c:2446 > [< none >] __slab_alloc+0x68/0xc0 mm/slub.c:2475 > [< inline >] slab_alloc_node mm/slub.c:2538 > [< inline >] slab_alloc mm/slub.c:2580 > [< none >] kmem_cache_alloc_trace+0x263/0x3d0 mm/slub.c:2597 > [< inline >] kmalloc include/linux/slab.h:478 > [< inline >] kzalloc include/linux/slab.h:622 > [< none >] event_hist_trigger_func+0xfcd/0x2430 > kernel/trace/trace_events_hist.c:1552 > [< inline >] trigger_process_regex > kernel/trace/trace_events_trigger.c:234 > [< inline >] event_trigger_regex_write > kernel/trace/trace_events_trigger.c:271 > [< none >] event_trigger_write+0x244/0x3c0 > kernel/trace/trace_events_trigger.c:300 > [< none >] __vfs_write+0x10b/0x620 fs/read_write.c:510 > [< none >] vfs_write+0x170/0x4a0 fs/read_write.c:560 > [< inline >] SYSC_write fs/read_write.c:607 > [< none >] SyS_write+0xd4/0x1a0 fs/read_write.c:599 > [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 > arch/x86/entry/entry_64.S:207 > > INFO: Freed in 0xfffcb4bb age=18446712239411738348 cpu=0 pid=0 > [< none >] trigger_data_free+0x75/0x90 > kernel/trace/trace_events_trigger.c:37 > [< none >] __slab_free+0x1e8/0x300 mm/slub.c:2657 > [< inline >] slab_free mm/slub.c:2810 > [< none >] kfree+0x2fc/0x370 mm/slub.c:3662 > [< none >] trigger_data_free+0x75/0x90 > kernel/trace/trace_events_trigger.c:37 > [< none >] event_hist_trigger_free+0xb5/0x120 > kernel/trace/trace_events_hist.c:1256 > [< none >] hist_unreg_all+0x156/0x1d0 > kernel/trace/trace_events_hist.c:1511 > [< inline >] event_trigger_regex_open > kernel/trace/trace_events_trigger.c:205 > [< none >] event_trigger_open+0x1ee/0x2a0 > kernel/trace/trace_events_trigger.c:306 > [< none >] do_dentry_open+0x698/0xca0 fs/open.c:736 > [< none >] vfs_open+0x10f/0x210 fs/open.c:849 > [< inline >] do_last fs/namei.c:3360 > [< none >] path_openat+0x12f9/0x2a80 fs/namei.c:3483 > [< none >] do_filp_open+0x18c/0x250 fs/namei.c:3518 > [< none >] do_sys_open+0x1fc/0x420 fs/open.c:1016 > [< inline >] SYSC_open fs/open.c:1034 > [< none >] SyS_open+0x2d/0x40 fs/open.c:1029 > [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 > arch/x86/entry/entry_64.S:207 > INFO: Slab 0xeac58c80 objects=17 used=15 fp=0x880031632398 > flags=0xfffe004080 > INFO: Object 0x880031632c78 @offset=3192 fp=0x > > Redzone 880031632c70: d0 6f 81 81 ff ff ff ff > .o.. > Object 880031632c78: bb bb bb bb bb bb bb bb 00 00 00 00 00 00 00 > 00 > Object 880031632c88: 00 00 00 00 00 00 00 00 c0 17 18 88 ff ff ff > ff > Object 880031632c98: 00 17 18 88 ff ff ff ff 00 00 00 00 00 00 00 > 00 > Object 880031632ca8: 00 00 00 00 00 00 00 00 98 23 63 31 00 88 ff > ff .#c1 > Object 880031632cb8: 00 00 00 00 00 00 00 00 40 e0 96 3e 00 88 ff > ff @..> > Object 880031632cc8: 00 02 00 00 00 00 ad de 00 00 00 00 00 00 00 > 00 > Object 880031632cd8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > Object 880031632ce8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > Redzone 880031632cf8: 00 00 00 00 00 00 00 00 > > Padding 880031632e30: aa b6 fc ff 00 00 00 00 > > CPU: 0 PID: 7413 Comm: ftracetest Tainted: GB 4.7.0-rc4+ #6 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > 880b58e0 88005ed1f8e8 82cc83cf 00c58c80 > fbfff1016b1c 880031632000 880031632c78 88003e807480 > eac58c80 8160e820 88005ed1f918 817b3ec0 > > Call Trace: > [] __asan_report_load8_noabort+0x3e/0x40 > mm/kasan/report
Re: [PATCH net-next 0/8] rxrpc: Preparation for removal of use of skbs from AFS
From: David Howells Date: Tue, 30 Aug 2016 16:41:37 +0100 > Here's a set of patches that prepare the way for the removal of the use of > sk_buffs from fs/afs (they'll be entirely retained within net/rxrpc): > > (1) Fix a potential NULL-pointer deref in rxrpc_abort_calls(). > > (2) Condense all the terminal call state machine states to a single one > plus supplementary info. > > (3) Add a trace point for rxrpc call usage debugging. > > (4) Cleanups and missing headers. > > (5) Provide a way for AFS to ask about a call's peer address without > having an sk_buff to query. > > (6) Use call->peer directly rather than going via call->conn (which might > be NULL). > > (7) Pass struct socket * to various rxrpc kernel interface functions so > they can use that directly rather than getting it from the rxrpc_call > struct. ... > Tagged thusly: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > rxrpc-rewrite-20160830-1 Pulled, thanks David.
Re: [v2] locking/percpu-rwsem: Optimize readers and reduce global impact
Peter,
On Tue, Aug 09, 2016 at 11:51:12AM +0200, Peter Zijlstra wrote:
> Currently the percpu-rwsem switches to (global) atomic ops while a
> writer is waiting; which could be quite a while and slows down
> releasing the readers.
>
> This patch cures this problem by ordering the reader-state vs
> reader-count (see the comments in __percpu_down_read() and
> percpu_down_write()). This changes a global atomic op into a full
> memory barrier, which doesn't have the global cacheline contention.
>
> This also enables using the percpu-rwsem with rcu_sync disabled in order
> to bias the implementation differently, reducing the writer latency by
> adding some cost to readers.
>
> Cc: Paul McKenney
> Reviewed-by: Oleg Nesterov
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> include/linux/percpu-rwsem.h | 84 +--
> kernel/locking/percpu-rwsem.c | 228
> --
> 2 files changed, 206 insertions(+), 106 deletions(-)
>
> --- a/include/linux/percpu-rwsem.h
> +++ b/include/linux/percpu-rwsem.h
> @@ -10,30 +10,96 @@
>
> struct percpu_rw_semaphore {
> struct rcu_sync rss;
> - unsigned int __percpu *fast_read_ctr;
> + unsigned int __percpu *read_count;
> struct rw_semaphore rw_sem;
> - atomic_tslow_read_ctr;
> - wait_queue_head_t write_waitq;
> + wait_queue_head_t writer;
> + int readers_block;
> };
>
> -extern void percpu_down_read(struct percpu_rw_semaphore *);
> -extern int percpu_down_read_trylock(struct percpu_rw_semaphore *);
> -extern void percpu_up_read(struct percpu_rw_semaphore *);
> +extern int __percpu_down_read(struct percpu_rw_semaphore *, int);
> +extern void __percpu_up_read(struct percpu_rw_semaphore *);
> +
> +static inline void percpu_down_read(struct percpu_rw_semaphore *sem)
> +{
> + might_sleep();
> +
> + rwsem_acquire_read(&sem->rw_sem.dep_map, 0, 0, _RET_IP_);
> +
> + preempt_disable();
> + /*
> + * We are in an RCU-sched read-side critical section, so the writer
> + * cannot both change sem->state from readers_fast and start checking
> + * counters while we are here. So if we see !sem->state, we know that
> + * the writer won't be checking until we're past the preempt_enable()
> + * and that one the synchronize_sched() is done, the writer will see
> + * anything we did within this RCU-sched read-size critical section.
> + */
> + __this_cpu_inc(*sem->read_count);
> + if (unlikely(!rcu_sync_is_idle(&sem->rss)))
The call to rcu_sync_is_idle() causes the following build error when building
x86_64:allmodconfig.
ERROR: "rcu_sync_lockdep_assert" [kernel/locking/locktorture.ko] undefined!
ERROR: "rcu_sync_lockdep_assert" [fs/ext4/ext4.ko] undefined!
I think this was also reported by the 0-day build bot.
The simple fix would of course be to export rcu_sync_lockdep_assert. Before I
apply that change to the Android code (where the patch has been aplied and
the problem is seen) - do you by any chance have a better solution in mind ?
Thanks,
Guenter
Re: constification and cocci / kernel build test robot ?
On Tue, 30 Aug 2016, Kees Cook wrote:
> On Tue, Aug 30, 2016 at 3:23 PM, Julia Lawall wrote:
> >
> >
> > On Tue, 30 Aug 2016, Kees Cook wrote:
> >
> >> On Sun, Aug 28, 2016 at 9:13 AM, Julia Lawall wrote:
> >> > [Adding Kees, in case it's of interest]
> >> >
> >> > Below is the list of types of top-level initialized structures and the
> >> > number that are const. For quicker reading, here are some that are
> >> > sometimes const (numerator), but not always (denominator):
> >> >
> >> > file_operations: 2221/2233
> >> > attribute_group: 447/919
> >> > irq_chip: 1/518
> >> > net_device_ops: 488/498
> >> > regmap_config: 407/447
> >> > dev_pm_ops: 398/415
> >> > clk_ops: 314/386
> >> > resource: 6/385
> >> > seq_operations: 327/328
> >> > snd_pcm_ops: 9/288
> >> >
> >> > and here are the most used ones that are never const at all:
> >> >
> >> > platform_driver: 2943
> >> > platform_device: 2226
> >> > clk_branch: 1131
> >> > i2c_driver: 786
> >> > pci_driver: 781
> >> > omap_hwmod_ocp_if: 670
> >> > omap_hwmod: 582
> >> > notifier_block: 556
> >> > clk: 473
> >> > clk_rcg2: 384
> >> >
> >> > [...]
> >>
> >> The structures that should get the greatest level of attention are
> >> those that contain function pointers. The "constify" gcc plugin from
> >> PaX/Grsecurity does this, but it uses a big hammer: it moves all of
> >> them const even if they receive assignment. To handle this, there is
> >> the concept of an open/close method to gain temporary access to the
> >> structure. For example:
> >>
> >> drivers/cdrom/cdrom.c:
> >>
> >> int register_cdrom(...) {
> >> ...
> >> if (!cdo->generic_packet) {
> >> pax_open_kernel();
> >> const_cast(cdo->generic_packet) =
> >> cdrom_dummy_generic_packet;
> >> pax_close_kernel();
> >
> > Thanks for the clarification. The above has to be added to the code
> > manually, or the plugin does it?
>
> Currently, the plugin just warns, and a successful build depends on
> manually adding the open/close logic. For simple cases, the plugin
> could be taught to do this automatically, but some situations are more
> complex.
I guess it would be desirable to avoid this if at all possible. But maybe
it would end up in some library functions, because some drivers would call
them from an init context.
julia
Re: [PATCH] mmc: sdhci-msm: Add pm_runtime and system PM support
Thanks Ulf for the review. On 29 August 2016 at 19:50, Ulf Hansson wrote: > On 16 June 2016 at 14:35, Pramod Gurav wrote: >> + platform_set_drvdata(pdev, msm_host); >> + >> + pm_runtime_set_active(&pdev->dev); >> + pm_runtime_enable(&pdev->dev); > > I think you need to move these a bit earlier, before calling sdhci_add_host(). > > Maybe it's just easier if you look at the sdhci-of-at91.c driver, > which behaves nicely around runtime PM deployment. You can probably > use the very similar code, except the ->runtime_suspend|resume() > callbacks. > > And don't forget to deploy runtime PM support in the ->remove() > callback as well, again sdhci-of-at91 is a good reference. > Will take a look at the said driver and do necessary changes and repost. Thanks again. Regards, Pramod
Re: [PATCH v3] time: alarmtimer: Add the trcepoints for alarmtimer
On 31 August 2016 at 02:58, John Stultz wrote: > On Tue, Aug 30, 2016 at 4:50 AM, Baolin Wang wrote: >> Hi, >> >> On 22 August 2016 at 12:23, Baolin Wang wrote: >>> For system debugging, we usually want to know who sets one alarm timer, the >>> time of the timer, when the timer started and fired and so on. Thus adding >>> tracepoints can help us trace the alarmtimer information. >>> >>> For example, when we debug the system supend/resume, if the system is always >>> resumed by RTC alarm, we can find out which process set the alarm timer to >>> resume system by below trace log: >>> >>> .. >>> Binder:2976_6-3473 [005] d..2 1076.587732: alarmtimer_start: >>> process:Binder:2976_6 >>> alarmtimer type:ALARM_BOOTTIME expires:123415400 time: 1970-1-1 0:20:35 >>> >>> Binder:2976_7-3480 [002] d..2 1076.592707: alarmtimer_cancel: >>> process:Binder:2976_7 >>> alarmtimer type:ALARM_BOOTTIME expires:13254630600 time: 2012-1-2 >>> 0:11:0 >>> >>> Binder:2976_7-3480 [002] d..2 1076.592731: alarmtimer_start: >>> process:Binder:2976_7 >>> alarmtimer type:ALARM_BOOTTIME expires:13253780400 time: 2012-1-1 >>> 0:34:0 >>> >>> system_server-2976 [003] d..2 1076.605587: alarmtimer_cancel: >>> process:system_server >>> alarmtimer type:ALARM_BOOTTIME expires:123415400 time: 1970-1-1 0:20:35 >>> >>> system_server-2976 [003] d..2 1076.605608: alarmtimer_start: >>> process:system_server >>> alarmtimer type:ALARM_BOOTTIME expires:123415500 time: 1970-1-1 0:20:35 >>> >>> system_server-3000 [002] ...1 1087.737565: alarmtimer_suspend: alarmtimer >>> type:ALARM_BOOTTIME >>> expires time: 2012-1-1 0:34:0 >>> .. >>> >>> From the trace log, we can find out the 'Binder:2976_7' process set one >>> alarm >>> timer which resumes the system. >> >> Do you have any comments about this patch? Thanks. > > No objection from me. I'll queue it for testing. Thanks, John. > > thanks > -john -- Baolin.wang Best Regards
RE: [PATCH v1 4/5] ARM: dts: ls1043a: add qDMA node
On Mon 29 August 2016 03:34:47, : Alexander Stein wrote:
> On Thursday 18 August 2016 14:38:47, Yuan Yao wrote:
> > From: Yuan Yao
> >
> > Add the QDMA node for ls1043a platform to support QDMA driver.
> >
> > Signed-off-by: Yuan Yao
> > ---
> > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi index
> > e8e4c3e..e463074
> > 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > @@ -467,6 +467,16 @@
> > <&clockgen 4 0>;
> > };
> >
> > + qdma: qdma@839 {
> > + compatible = "fsl,ls1021a-qdma", "fsl,ls1043a-qdma";
>
> This doesn't match the order of your binding in Patch 2/5:
> > +- compatible :
> > + - "fsl,ls1021a-qdma",
> > + Or "fsl,ls1043a-qdma" followed by "fsl,ls1021a-qdma",
>
> It should be the other way around.
Thanks for your review.
It should be compatible = "fsl,ls1043a-qspi", "fsl,ls1021a-qspi";
I will update it in the next version.
Thanks.
Re: [PATCH v3 2/3] tracing: Add trace_irqsoff tracepoints
Hi Daniel/Steven,
On 30 August 2016 at 20:32, Daniel Wagner wrote:
> On 08/30/2016 04:20 PM, Daniel Wagner wrote:
>> Just setting the size of the type is not enough. The hist_field_*
>> getter function want to know the offset too:
>
> With this hack here it should work. The COMM generic field is handled via
> the tracing_map_ops. We could do it also there but than we need to
> a condition in the trace_map_ops if it is COMM or CPU.
> This shortcut here avoids it:
> diff --git a/kernel/trace/trace_events_hist.c
> b/kernel/trace/trace_events_hist.c
> index f3a960e..77073b7 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -556,6 +567,11 @@ static int create_key_field(struct hist_trigger_data
> *hist_data,
> key_size = MAX_FILTER_STR_VAL;
> else
> key_size = field->size;
> +
> + // strcmp(field_name, "cpu") would also work to figure
> + // out if this is a one of the generic fields.
> + if (field->filter_type == FILTER_CPU)
> + flags |= HIST_FIELD_FL_CPU;
> }
>
> hist_data->fields[key_idx] = create_hist_field(field, flags);
I applied Daniel's fix and it seems to work. Can we use the following instead
on top of your patch? Like how the other keys are compared against
respective fields?
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 46203b7..963a121 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -537,6 +537,12 @@ static int create_key_field(struct
hist_trigger_data *hist_data,
} else {
char *field_name = strsep(&field_str, ".");
+/* Cannot keep these 2 lines in side the if() below
+ * as field_str would be NULL for the key 'cpu'
+ */
+if (strcmp(field_name, "cpu") == 0)
+flags |= HIST_FIELD_FL_CPU;
+
if (field_str) {
if (strcmp(field_str, "hex") == 0)
flags |= HIST_FIELD_FL_HEX;
@@ -568,11 +574,6 @@ static int create_key_field(struct
hist_trigger_data *hist_data,
else
key_size = field->size;
- // strcmp(field_name, "cpu") would also work to figure
- // out if this is a one of the generic fields.
- if (field->filter_type == FILTER_CPU)
- flags |= HIST_FIELD_FL_CPU;
-
}
hist_data->fields[key_idx] = create_hist_field(field, flags);
- Binoy
[PATCH v4] ARM: dts: exynos: Enable HDMI for Arndale Octa board
* GPIO for HDMI hot plug detect
GPX3_7 is used. The HPD awareness is done when the GPIO is active high.
* Enable HDMI block in Exynos5420
HDMI VDD and PLL consume 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator
requires 1.8V LDO7 (PVDD_ANAIP_1V8).
* Support HDMI display data channel
I2C #2 is assigned for the HDMI DDC. It enables the EDID access.
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Rob Herring
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 39a3b81..d2ad48e 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -70,6 +70,15 @@
status = "disabled";
};
+&hdmi {
+ hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+ vdd_osc-supply = <&ldo7_reg>;
+ vdd_pll-supply = <&ldo6_reg>;
+ vdd-supply = <&ldo6_reg>;
+ ddc = <&i2c_2>;
+ status = "okay";
+};
+
&hsi2c_4 {
status = "okay";
@@ -347,6 +356,10 @@
};
};
+&i2c_2 {
+ status = "okay";
+};
+
&mmc_0 {
status = "okay";
broken-cd;
--
2.9.3
Re: [PATCH 07/34] mm, vmscan: make kswapd reclaim in terms of nodes
> > The trigger is memblock_reserve() for the complete node memory. And
> > this is exactly what FA_DUMP does. Here again the node has memory but
> > its all reserved so there is no free memory in the node.
> >
> > Did you mean populated_zone() when you said zone_populated or have I
> > mistaken? populated_zone() does return 1 since it checks for
> > zone->present_pages.
> >
>
> Yes, I meant populated_zone(). Using present pages may have hidden
> a long-lived corner case as it was unexpected that an entire node
> would be reserved. The old code happened to survive *probably* because
> pgdat_reclaimable would look false and kswapd checks for pgdat being
> balanced would happen to do the right thing in this case.
>
> Can you check if something like this works?
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index d572b78b65e1..cf64a5456cf6 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -830,7 +830,7 @@ unsigned long __init node_memmap_size_bytes(int, unsigned
> long, unsigned long);
>
> static inline int populated_zone(struct zone *zone)
> {
> - return (!!zone->present_pages);
> + return (!!zone->managed_pages);
> }
>
> extern int movable_zone;
>
This indeed fixes the problem.
Please add my
Tested-by: Srikar Dronamraju
[RESEND PATCH 0/4] Support the rk3399 gmac pd function
This patch add to handle the gmac pd issue, and support the rk3399 gmac for devicetree. Caesar Wang (2): arm64: dts: rockchip: support gmac for rk3399 arm64: dts: rockchip: enable the gmac for rk3399 evb board David Wu (1): net: stmmac: dwmac-rk: add pd_gmac support for rk3399 Roger Chen (1): net: stmmac: dwmac-rk: fixes the gmac resume after PD on/off arch/arm64/boot/dts/rockchip/rk3399-evb.dts| 31 + arch/arm64/boot/dts/rockchip/rk3399.dtsi | 90 ++ drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 28 +--- 3 files changed, 140 insertions(+), 9 deletions(-) -- 1.9.1
[RESEND PATCH 2/4] net: stmmac: dwmac-rk: add pd_gmac support for rk3399
From: David Wu
Add the gmac power domain support for rk3399, in order to save more
power consumption.
Signed-off-by: David Wu
Signed-off-by: Caesar Wang
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 289e7a6..406573d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "stmmac_platform.h"
@@ -659,11 +660,19 @@ static int rk_gmac_powerup(struct rk_priv_data *bsp_priv)
if (ret)
return ret;
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
+
return 0;
}
static void rk_gmac_powerdown(struct rk_priv_data *gmac)
{
+ struct device *dev = &gmac->pdev->dev;
+
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
+
phy_power_on(gmac, false);
gmac_clk_enable(gmac, false);
}
--
1.9.1
[RESEND PATCH 1/4] net: stmmac: dwmac-rk: fixes the gmac resume after PD on/off
From: Roger Chen
GMAC Power Domain(PD) will be disabled during suspend.
That will causes GRF registers reset.
So corresponding GRF registers for GMAC must be setup again.
Signed-off-by: Roger Chen
Signed-off-by: Caesar Wang
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 9210591..289e7a6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -629,6 +629,16 @@ static struct rk_priv_data *rk_gmac_setup(struct
platform_device *pdev,
"rockchip,grf");
bsp_priv->pdev = pdev;
+ gmac_clk_init(bsp_priv);
+
+ return bsp_priv;
+}
+
+static int rk_gmac_powerup(struct rk_priv_data *bsp_priv)
+{
+ int ret;
+ struct device *dev = &bsp_priv->pdev->dev;
+
/*rmii or rgmii*/
if (bsp_priv->phy_iface == PHY_INTERFACE_MODE_RGMII) {
dev_info(dev, "init for RGMII\n");
@@ -641,15 +651,6 @@ static struct rk_priv_data *rk_gmac_setup(struct
platform_device *pdev,
dev_err(dev, "NO interface defined!\n");
}
- gmac_clk_init(bsp_priv);
-
- return bsp_priv;
-}
-
-static int rk_gmac_powerup(struct rk_priv_data *bsp_priv)
-{
- int ret;
-
ret = phy_power_on(bsp_priv, true);
if (ret)
return ret;
--
1.9.1
[PATCH v4 1/3] gpu: drm: exynos_hdmi: Move DDC logic into single function
Paring DT properties and getting the I2C adapter in one function.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 46
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2275efe..1440dfd 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1760,16 +1760,34 @@ static const struct component_ops hdmi_component_ops = {
.unbind = hdmi_unbind,
};
-static struct device_node *hdmi_legacy_ddc_dt_binding(struct device *dev)
+static int hdmi_get_ddc_adapter(struct hdmi_context *hdata)
{
const char *compatible_str = "samsung,exynos4210-hdmiddc";
struct device_node *np;
+ struct i2c_adapter *adpt;
np = of_find_compatible_node(NULL, NULL, compatible_str);
if (np)
- return of_get_next_parent(np);
+ np = of_get_next_parent(np);
+ else
+ np = of_parse_phandle(hdata->dev->of_node, "ddc", 0);
+
+ if (!np) {
+ DRM_ERROR("Failed to find ddc node in device tree\n");
+ return -ENODEV;
+ }
+
+ adpt = of_find_i2c_adapter_by_node(np);
+ of_node_put(np);
- return NULL;
+ if (!adpt) {
+ DRM_INFO("Failed to get ddc i2c adapter by node\n");
+ return -EPROBE_DEFER;
+ }
+
+ hdata->ddc_adpt = adpt;
+
+ return 0;
}
static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
@@ -1781,7 +1799,7 @@ static struct device_node
*hdmi_legacy_phy_dt_binding(struct device *dev)
static int hdmi_probe(struct platform_device *pdev)
{
- struct device_node *ddc_node, *phy_node;
+ struct device_node *phy_node;
struct device *dev = &pdev->dev;
struct hdmi_context *hdata;
struct resource *res;
@@ -1811,23 +1829,9 @@ static int hdmi_probe(struct platform_device *pdev)
return ret;
}
- ddc_node = hdmi_legacy_ddc_dt_binding(dev);
- if (ddc_node)
- goto out_get_ddc_adpt;
-
- ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
- if (!ddc_node) {
- DRM_ERROR("Failed to find ddc node in device tree\n");
- return -ENODEV;
- }
- of_node_put(dev->of_node);
-
-out_get_ddc_adpt:
- hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
- if (!hdata->ddc_adpt) {
- DRM_ERROR("Failed to get ddc i2c adapter by node\n");
- return -EPROBE_DEFER;
- }
+ ret = hdmi_get_ddc_adapter(hdata);
+ if (ret)
+ return ret;
phy_node = hdmi_legacy_phy_dt_binding(dev);
if (phy_node)
--
2.9.3
[PATCH v4 0/3] gpu: drm: exynos_hdmi: Code refactoring on hdmi ddc and phy
v4: Only DRM patchset is sent, DTS patch was sent separately. Milo Kim (3): gpu: drm: exynos_hdmi: Move DDC logic into single function gpu: drm: exynos_hdmi: Move PHY logic into single function gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator bulk consumer drivers/gpu/drm/exynos/exynos_hdmi.c | 112 ++- 1 file changed, 59 insertions(+), 53 deletions(-) -- 2.9.3
[RESEND PATCH 4/4] arm64: dts: rockchip: enable the gmac for rk3399 evb board
We add the required and optional properties for evb board.
See the [0] to get the detail information.
[0]:
Documentation/devicetree/bindings/net/rockchip-dwmac.txt
Signed-off-by: Roger Chen
Signed-off-by: Caesar Wang
---
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 31 +
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
index d47b4e9..ed6f2e8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -94,12 +94,43 @@
regulator-always-on;
regulator-boot-on;
};
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+
+ vcc_phy: vcc-phy-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_phy";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
};
&emmc_phy {
status = "okay";
};
+&gmac {
+ phy-supply = <&vcc_phy>;
+ phy-mode = "rgmii";
+ clock_in_out = "input";
+ snps,reset-gpio = <&gpio3 15 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 1 5>;
+ assigned-clocks = <&cru SCLK_RMII_SRC>;
+ assigned-clock-parents = <&clkin_gmac>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ tx_delay = <0x28>;
+ rx_delay = <0x11>;
+ status = "okay";
+};
+
&pwm0 {
status = "okay";
};
--
1.9.1
[PATCH v4 3/3] gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator bulk consumer
The helper, devm_regulator_bulk_get() initializes the consumer as NULL,
so this code can be ignored.
Reviewed-by: Andrzej Hajda
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 42b0b98..e8fb6ef 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1669,10 +1669,9 @@ static int hdmi_resources_init(struct hdmi_context
*hdata)
if (ret)
return ret;
- for (i = 0; i < ARRAY_SIZE(supply); ++i) {
+ for (i = 0; i < ARRAY_SIZE(supply); ++i)
hdata->regul_bulk[i].supply = supply[i];
- hdata->regul_bulk[i].consumer = NULL;
- }
+
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(supply),
hdata->regul_bulk);
if (ret) {
if (ret != -EPROBE_DEFER)
--
2.9.3
[RESEND PATCH 3/4] arm64: dts: rockchip: support gmac for rk3399
This patch adds needed gamc information for rk3399,
also support the gmac pd.
Signed-off-by: Roger Chen
Signed-off-by: Caesar Wang
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 90
1 file changed, 90 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 32aebc8..abf27a4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -200,6 +200,26 @@
};
};
+ gmac: eth@fe30 {
+ compatible = "rockchip,rk3399-gmac";
+ reg = <0x0 0xfe30 0x0 0x1>;
+ interrupts = ;
+ interrupt-names = "macirq";
+ clocks = <&cru SCLK_MAC>, <&cru SCLK_MAC_RX>,
+<&cru SCLK_MAC_TX>, <&cru SCLK_MACREF>,
+<&cru SCLK_MACREF_OUT>, <&cru ACLK_GMAC>,
+<&cru PCLK_GMAC>;
+ clock-names = "stmmaceth", "mac_clk_rx",
+ "mac_clk_tx", "clk_mac_ref",
+ "clk_mac_refout", "aclk_mac",
+ "pclk_mac";
+ power-domains = <&power RK3399_PD_GMAC>;
+ resets = <&cru SRST_A_GMAC>;
+ reset-names = "stmmaceth";
+ rockchip,grf = <&grf>;
+ status = "disabled";
+ };
+
sdio0: dwmmc@fe31 {
compatible = "rockchip,rk3399-dw-mshc",
"rockchip,rk3288-dw-mshc";
@@ -611,6 +631,11 @@
status = "disabled";
};
+ qos_gmac: qos@ffa5c000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa5c000 0x0 0x20>;
+ };
+
qos_hdcp: qos@ffa9 {
compatible = "syscon";
reg = <0x0 0xffa9 0x0 0x20>;
@@ -704,6 +729,11 @@
#size-cells = <0>;
/* These power domains are grouped by VD_CENTER */
+ pd_gmac@RK3399_PD_GMAC {
+ reg = ;
+ clocks = <&cru ACLK_GMAC>;
+ pm_qos = <&qos_gmac>;
+ };
pd_iep@RK3399_PD_IEP {
reg = ;
clocks = <&cru ACLK_IEP>,
@@ -1183,6 +1213,66 @@
drive-strength = <13>;
};
+ gmac {
+ rgmii_pins: rgmii-pins {
+ rockchip,pins =
+ /* mac_txclk */
+ <3 17 RK_FUNC_1 &pcfg_pull_none_13ma>,
+ /* mac_rxclk */
+ <3 14 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_mdio */
+ <3 13 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_txen */
+ <3 12 RK_FUNC_1 &pcfg_pull_none_13ma>,
+ /* mac_clk */
+ <3 11 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_rxdv */
+ <3 9 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_mdc */
+ <3 8 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_rxd1 */
+ <3 7 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_rxd0 */
+ <3 6 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_txd1 */
+ <3 5 RK_FUNC_1 &pcfg_pull_none_13ma>,
+ /* mac_txd0 */
+ <3 4 RK_FUNC_1 &pcfg_pull_none_13ma>,
+ /* mac_rxd3 */
+ <3 3 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_rxd2 */
+ <3 2 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_txd3 */
+ <3 1 RK_FUNC_1 &pcfg_pull_none_13ma>,
+ /* mac_txd2 */
+ <3 0 RK_FUNC_1 &pcfg_pull_none_13ma>;
+ };
+
+ rmii_pins: rmii-pins {
+ rockchip,pins =
+ /* mac_mdio */
+ <3 13 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_txen */
+ <3 12 RK_FUNC_1 &pcfg_pull_none_13ma>,
+
[PATCH v4 2/3] gpu: drm: exynos_hdmi: Move PHY logic into single function
Paring DT properties and getting PHY IO (memory mapped or I2C) in one
function.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 63 +++-
1 file changed, 33 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 1440dfd..42b0b98 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1790,16 +1790,44 @@ static int hdmi_get_ddc_adapter(struct hdmi_context
*hdata)
return 0;
}
-static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
+static int hdmi_get_phy_io(struct hdmi_context *hdata)
{
const char *compatible_str = "samsung,exynos4212-hdmiphy";
+ struct device_node *np;
+ int ret = 0;
+
+ np = of_find_compatible_node(NULL, NULL, compatible_str);
+ if (!np) {
+ np = of_parse_phandle(hdata->dev->of_node, "phy", 0);
+ if (!np) {
+ DRM_ERROR("Failed to find hdmiphy node in device
tree\n");
+ return -ENODEV;
+ }
+ }
+
+ if (hdata->drv_data->is_apb_phy) {
+ hdata->regs_hdmiphy = of_iomap(np, 0);
+ if (!hdata->regs_hdmiphy) {
+ DRM_ERROR("failed to ioremap hdmi phy\n");
+ ret = -ENOMEM;
+ goto out;
+ }
+ } else {
+ hdata->hdmiphy_port = of_find_i2c_device_by_node(np);
+ if (!hdata->hdmiphy_port) {
+ DRM_INFO("Failed to get hdmi phy i2c client\n");
+ ret = -EPROBE_DEFER;
+ goto out;
+ }
+ }
- return of_find_compatible_node(NULL, NULL, compatible_str);
+out:
+ of_node_put(np);
+ return ret;
}
static int hdmi_probe(struct platform_device *pdev)
{
- struct device_node *phy_node;
struct device *dev = &pdev->dev;
struct hdmi_context *hdata;
struct resource *res;
@@ -1833,34 +1861,9 @@ static int hdmi_probe(struct platform_device *pdev)
if (ret)
return ret;
- phy_node = hdmi_legacy_phy_dt_binding(dev);
- if (phy_node)
- goto out_get_phy_port;
-
- phy_node = of_parse_phandle(dev->of_node, "phy", 0);
- if (!phy_node) {
- DRM_ERROR("Failed to find hdmiphy node in device tree\n");
- ret = -ENODEV;
+ ret = hdmi_get_phy_io(hdata);
+ if (ret)
goto err_ddc;
- }
- of_node_put(dev->of_node);
-
-out_get_phy_port:
- if (hdata->drv_data->is_apb_phy) {
- hdata->regs_hdmiphy = of_iomap(phy_node, 0);
- if (!hdata->regs_hdmiphy) {
- DRM_ERROR("failed to ioremap hdmi phy\n");
- ret = -ENOMEM;
- goto err_ddc;
- }
- } else {
- hdata->hdmiphy_port = of_find_i2c_device_by_node(phy_node);
- if (!hdata->hdmiphy_port) {
- DRM_ERROR("Failed to get hdmi phy i2c client\n");
- ret = -EPROBE_DEFER;
- goto err_ddc;
- }
- }
INIT_DELAYED_WORK(&hdata->hotplug_work, hdmi_hotplug_work_func);
--
2.9.3
Re: [PATCH v3 1/5] ARM: dts: exynos: Enable HDMI for Arndale Octa board
Hi Krzysztof, On 08/25/2016 04:05 AM, Krzysztof Kozlowski wrote: First of all - it looks like these DTS patches do not depend on DRM part, do they? I just sent the v4 patch for DTS. DRM patch-set was sent separately. Thanks for your advise. Best regards, Milo
Re: [PATCH v9 2/2] Add mixer controls: Line-In, FM-In, Mic 2, Capture Source, Differential Line-In.
Hi,
On Tue, Aug 30, 2016 at 1:44 PM, Danny Milosavljevic
wrote:
> Note: Mic1 Capture Volume is in a different register on A20 than on A10.
> Note: Mic2 Capture Volume is in a different register on A20 than on A10.
The subject would be better saying "Add support for Line-In, FM-In, Mic 2
and Capture Source paths". You are not just adding mixer controls, but
DAPM widgets and routes as well.
A general description and any quirks of the hardware would be nice,
such as the capture source has a mux and not a mixer, in addition to
what you mentioned.
> ---
> sound/soc/sunxi/sun4i-codec.c | 256
> ++
> 1 file changed, 236 insertions(+), 20 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 30f4ea2..f510e6d 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -59,9 +59,20 @@
> #define SUN4I_CODEC_DAC_ACTL_DACAENR (31)
> #define SUN4I_CODEC_DAC_ACTL_DACAENL (30)
> #define SUN4I_CODEC_DAC_ACTL_MIXEN (29)
> +#define SUN4I_CODEC_DAC_ACTL_LNG (26)
> +#define SUN4I_CODEC_DAC_ACTL_FMG (23)
> +#define SUN4I_CODEC_DAC_ACTL_MICG (20)
> +#define SUN4I_CODEC_DAC_ACTL_LLNS (19)
> +#define SUN4I_CODEC_DAC_ACTL_RLNS (18)
> +#define SUN4I_CODEC_DAC_ACTL_LFMS (17)
> +#define SUN4I_CODEC_DAC_ACTL_RFMS (16)
> #define SUN4I_CODEC_DAC_ACTL_LDACLMIXS (15)
> #define SUN4I_CODEC_DAC_ACTL_RDACRMIXS (14)
> #define SUN4I_CODEC_DAC_ACTL_LDACRMIXS (13)
> +#define SUN4I_CODEC_DAC_ACTL_MIC1LS(12)
> +#define SUN4I_CODEC_DAC_ACTL_MIC1RS(11)
> +#define SUN4I_CODEC_DAC_ACTL_MIC2LS(10)
> +#define SUN4I_CODEC_DAC_ACTL_MIC2RS(9)
> #define SUN4I_CODEC_DAC_ACTL_DACPAS(8)
> #define SUN4I_CODEC_DAC_ACTL_MIXPAS(7)
> #define SUN4I_CODEC_DAC_ACTL_PA_MUTE (6)
> @@ -87,8 +98,12 @@
> #define SUN4I_CODEC_ADC_ACTL_PREG1EN (29)
> #define SUN4I_CODEC_ADC_ACTL_PREG2EN (28)
> #define SUN4I_CODEC_ADC_ACTL_VMICEN(27)
> -#define SUN4I_CODEC_ADC_ACTL_VADCG (20)
> +#define SUN4I_CODEC_ADC_ACTL_PREG1 (25)
> +#define SUN4I_CODEC_ADC_ACTL_PREG2 (23)
> +#define SUN4I_CODEC_ADC_ACTL_ADCG (20)
> #define SUN4I_CODEC_ADC_ACTL_ADCIS (17)
> +#define SUN4I_CODEC_ADC_ACTL_LNRDF (16)
> +#define SUN4I_CODEC_ADC_ACTL_LNPREG(13)
> #define SUN4I_CODEC_ADC_ACTL_PA_EN (4)
> #define SUN4I_CODEC_ADC_ACTL_DDE (3)
> #define SUN4I_CODEC_ADC_DEBUG (0x2c)
> @@ -100,6 +115,9 @@
> #define SUN7I_CODEC_AC_DAC_CAL (0x38)
> #define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
>
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG1 (29)
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG2 (26)
> +
> struct sun4i_codec {
> struct device *dev;
> struct regmap *regmap;
> @@ -509,23 +527,142 @@ static const struct snd_kcontrol_new
> sun4i_codec_pa_mute =
> SUN4I_CODEC_DAC_ACTL_PA_MUTE, 1, 0);
>
> static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
> +static DECLARE_TLV_DB_SCALE(sun4i_codec_linein_loopback_gain_scale,
X_playback_gain_scale, matching the control names later.
> + -150,
> + 150,
> + 0);
> +static DECLARE_TLV_DB_SCALE(sun4i_codec_linein_preamp_gain_scale,
> + -1200,
> + 300,
> + 0);
> +static DECLARE_TLV_DB_SCALE(sun4i_codec_fmin_loopback_gain_scale,
> + -450,
> + 150,
> + 0);
> +static DECLARE_TLV_DB_SCALE(sun4i_codec_micin_loopback_gain_scale,
> + -450,
> + 150,
> + 0);
Please merge the above 2. Also can they be const? Same for all the
other TLV structures.
> +static DECLARE_TLV_DB_RANGE(sun4i_codec_micin_preamp_gain_scale,
> + 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
> + 1, 7, TLV_DB_SCALE_ITEM(3500, 300, 0));
> +static DECLARE_TLV_DB_SCALE(sun4i_codec_adc_gain_scale, -450, 150, 0);
> +static DECLARE_TLV_DB_RANGE(sun7i_codec_micin_preamp_gain_scale,
> + 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
> + 1, 7, TLV_DB_SCALE_ITEM(2400, 300, 0)
> +);
> +
> +static const char * const sun4i_codec_capture_source[] = {
> + "Line",
> + "FM",
> + "Mic1",
> + "Mic2",
>
[PATCH v2 net] rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash possibly
From: Gao Feng
The original codes depend on that the function parameters are evaluated from
left to right. But the parameter's evaluation order is not defined in C
standard actually.
When flow_keys_have_l4(&keys) is invoked before ___skb_get_hash(skb, &keys,
hashrnd) with some compilers or environment, the keys passed to
flow_keys_have_l4 is not initialized.
Fixes: 6db61d79c1e1 ("flow_dissector: Ignore flow dissector return value from
___skb_get_hash")
Acked-by: Eric Dumazet
Signed-off-by: Gao Feng
---
v2: Add fixed commit description according to Eric's advice
v1: Inital patch
net/core/flow_dissector.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 61ad43f..52742a0 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -680,11 +680,13 @@ EXPORT_SYMBOL_GPL(__skb_get_hash_symmetric);
void __skb_get_hash(struct sk_buff *skb)
{
struct flow_keys keys;
+ u32 hash;
__flow_hash_secret_init();
- __skb_set_sw_hash(skb, ___skb_get_hash(skb, &keys, hashrnd),
- flow_keys_have_l4(&keys));
+ hash = ___skb_get_hash(skb, &keys, hashrnd);
+
+ __skb_set_sw_hash(skb, hash, flow_keys_have_l4(&keys));
}
EXPORT_SYMBOL(__skb_get_hash);
--
1.9.1
Re: [PATCH, net-next] qede: hide 32-bit compile warning
From: Arnd Bergmann
Date: Fri, 26 Aug 2016 17:37:53 +0200
> The addition of the per-queue statistics introduced a harmless warning
> on all 32-bit architectures:
>
> drivers/net/ethernet/qlogic/qede/qede_ethtool.c: In function
> 'qede_get_ethtool_stats':
> drivers/net/ethernet/qlogic/qede/qede_ethtool.c:244:31: error: cast from
> pointer to integer of different size [-Werror=pointer-to-int-cast]
> buf[cnt++] = QEDE_TQSTATS_DATA(edev,
>^
> drivers/net/ethernet/qlogic/qede/qede_ethtool.c:244:22: error: cast to
> pointer from integer of different size [-Werror=int-to-pointer-cast]
> buf[cnt++] = QEDE_TQSTATS_DATA(edev,
> ^
> This changes the cast to 'void *' to shut up the warning, which
> avoids the assumptions on the size of the pointer type.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 68db9ec2df07 ("qede: Add support for per-queue stats.")
Applied, thanks.
RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration
Hi Michael, I know you are very busy. If you have time, could you help to take a look at this patch set? Thanks! Liang > -Original Message- > From: Li, Liang Z > Sent: Thursday, August 18, 2016 9:06 AM > To: Michael S. Tsirkin > Cc: virtualizat...@lists.linux-foundation.org; linux...@kvack.org; virtio- > d...@lists.oasis-open.org; k...@vger.kernel.org; qemu-de...@nongnu.org; > quint...@redhat.com; dgilb...@redhat.com; Hansen, Dave; linux- > ker...@vger.kernel.org > Subject: RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast > (de)inflating > & fast live migration > > Hi Michael, > > Could you help to review this version when you have time? > > Thanks! > Liang > > > -Original Message- > > From: Li, Liang Z > > Sent: Monday, August 08, 2016 2:35 PM > > To: linux-kernel@vger.kernel.org > > Cc: virtualizat...@lists.linux-foundation.org; linux...@kvack.org; > > virtio- d...@lists.oasis-open.org; k...@vger.kernel.org; > > qemu-de...@nongnu.org; quint...@redhat.com; dgilb...@redhat.com; > > Hansen, Dave; Li, Liang Z > > Subject: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast > > (de)inflating & fast live migration > > > > This patch set contains two parts of changes to the virtio-balloon. > > > > One is the change for speeding up the inflating & deflating process, > > the main idea of this optimization is to use bitmap to send the page > > information to host instead of the PFNs, to reduce the overhead of > > virtio data transmission, address translation and madvise(). This can > > help to improve the performance by about 85%. > > > > Another change is for speeding up live migration. By skipping process > > guest's free pages in the first round of data copy, to reduce needless > > data processing, this can help to save quite a lot of CPU cycles and > > network bandwidth. We put guest's free page information in bitmap and > > send it to host with the virt queue of virtio-balloon. For an idle 8GB > > guest, this can help to shorten the total live migration time from > > 2Sec to about 500ms in the 10Gbps network environment. > > > > Dave Hansen suggested a new scheme to encode the data structure, > > because of additional complexity, it's not implemented in v3. > > > > Changes from v2 to v3: > > * Change the name of 'free page' to 'unused page'. > > * Use the scatter & gather bitmap instead of a 1MB page bitmap. > > * Fix overwriting the page bitmap after kicking. > > * Some of MST's comments for v2. > > > > Changes from v1 to v2: > > * Abandon the patch for dropping page cache. > > * Put some structures to uapi head file. > > * Use a new way to determine the page bitmap size. > > * Use a unified way to send the free page information with the bitmap > > * Address the issues referred in MST's comments > > > > > > Liang Li (7): > > virtio-balloon: rework deflate to add page to a list > > virtio-balloon: define new feature bit and page bitmap head > > mm: add a function to get the max pfn > > virtio-balloon: speed up inflate/deflate process > > mm: add the related functions to get unused page > > virtio-balloon: define feature bit and head for misc virt queue > > virtio-balloon: tell host vm's unused page info > > > > drivers/virtio/virtio_balloon.c | 390 > > > > include/linux/mm.h | 3 + > > include/uapi/linux/virtio_balloon.h | 41 > > mm/page_alloc.c | 94 + > > 4 files changed, 485 insertions(+), 43 deletions(-) > > > > -- > > 1.8.3.1
Re: [PATCH 0/9] staging: octeon: multi rx group (queue) support
Hi, On Tue, Aug 30, 2016 at 06:12:17PM -0700, Ed Swierk wrote: > On Tue, Aug 30, 2016 at 11:47 AM, Aaro Koskinen wrote: > > This series implements multiple RX group support that should improve > > the networking performance on multi-core OCTEONs. Basically we register > > IRQ and NAPI for each group, and ask the HW to select the group for > > the incoming packets based on hash. > > > > Tested on EdgeRouter Lite with a simple forwarding test using two flows > > and 16 RX groups distributed between two cores - the routing throughput > > is roughly doubled. > > I applied the series to my 4.4.19 tree, which involved backporting a > bunch of other patches from master, most of them trivial. > > When I test it on a Cavium Octeon 2 (CN6880) board, I get an immediate > crash (bus error) in the netif_receive_skb() call from cvm_oct_poll(). > Replacing the rx_group argument to cvm_oct_poll() with int group, and > dereferencing rx_group->group in the caller (cvm_oct_napi_poll()) > instead makes the crash disappear. Apparently there's some race in > dereferencing rx_group from within cvm_oct_poll(). Oops, looks like I tested without CONFIG_NET_POLL_CONTROLLER enabled and that seems to be broken. Sorry. > With this workaround in place, I can send and receive on XAUI > interfaces, but don't see any performance improvement. I'm guessing I > need to set receive_group_order > 0. But any value between 1 and 4 > seems to break rx altogether. When I ping another host I see both > request and response on the wire, and the interface counters increase, > but the response doesn't make it back to ping. Can you see multiple ethernet IRQs in /proc/interrupts and their counters increasing? With receive_group_order=4 you should see 16 IRQs. > Is some other configuration needed to make use of multiple rx groups? Once RX interrupts are working you need to divide them to multiple cores using /proc/irq//smp_affinity, or use irqbalance or such. A.
Re: [PATCH] generic: Add the exception case checking routine for ppi interrupt
Hi Marc & Mark: 在 2016/8/30 19:21, Mark Rutland 写道: > On Tue, Aug 30, 2016 at 12:07:36PM +0100, Marc Zyngier wrote: >> +Mark >> On 30/08/16 11:35, majun (F) wrote: >>> 在 2016/8/30 16:50, Marc Zyngier 写道: On 30/08/16 05:17, MaJun wrote: > From: Ma Jun > > During system booting, if the interrupt which has no action registered > is triggered, it would cause system panic when try to access the > action member. And why would that interrupt be enabled? If you enable a PPI before registering a handler, you're doing something wrong. >>> >>> Actually,the problem described above happened during the capture >>> kernel booting. >>> >>> In my system, sometimes there is a pending physical timer >>> interrupt(30) when the first kernel panic and the status is kept >>> until the capture kernel booting. >> >> And that's perfectly fine. The interrupt can be pending forever, as it >> shouldn't get enabled. >> >>> So, this interrupt will be handled during capture kernel booting. >> >> Why? Who enables it? >> >>> Becasue we use virt timer interrupt but not physical timer interrupt >>> in capture kernel, the interrupt 30 has no action handler. >> >> Again: who enables this interrupt? Whichever driver enables it should be >> fixed. > > I'm also at a loss. > > In this case, arch_timer_uses_ppi must be VIRT_PPI. So in > arch_timer_register(), we'll only request_percpu_irq the virt PPI. > arch_timer_has_nonsecure_ppi() will be false, given arch_timer_uses_ppi > is VIRT_PPI, so in arch_timer_starting_cpu() we'll only > enable_percpu_irq() the virt PPI. > > We don't fiddle with arch_timer_uses_ppi after calling > arch_timer_register(). So I can't see how we could enable another IRQ in > this case. > > Looking at the driver in virt/kvm/arm/arch_timer.c, we only enable what > we've succesfully requested, so it doesnt' seem like there's an issue > there. > >>From a quick look at teh GIC driver, it looks like we reset PPIs > correctly, so it doesn't look like we have a "latent enable". > I just checked the status of irq 30 during capture kernel booting. The irq 30 status is: mask, pending after arch_timer_starting_cpu() called. Because irq 30 triggered only 1 time during capture kernel booting, I think this problem maybe happened in the case like: 1:irq 30 triggered, but not acked by cpu yet. 2:local_irq_disable() called 3:system reboot -->capture kernel booting 4:local_irq_enable() 5:irq 30 acked by CPU. Is this case possible? Thanks MaJun > Thanks, > Mark. > > . >
Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller
On Wed, 2016-08-24 at 15:37 +0200, Mirza Krak wrote:
> From: Mirza Krak
>
> Document the devicetree bindings for the Generic Memory Interface
> (GMI)
> bus driver found on Tegra SOCs.
>
> Signed-off-by: Mirza Krak
> ---
> Changes in v2:
> - Updated examples and some information based on comments from Jon
> Hunter.
>
> .../devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 132
> +
> 1 file changed, 132 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra20-
> gmi.txt b/Documentation/devicetree/bindings/bus/nvidia,tegra20-
> gmi.txt
> new file mode 100644
> index 000..8c1e15f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
> @@ -0,0 +1,132 @@
> +Device tree bindings for NVIDIA Tegra Generic Memory Interface bus
> +
> +The Generic Memory Interface bus enables memory transfers between
> internal and
> +external memory. Can be used to attach various high speed devices
> such as
> +synchronous/asynchronous NOR, FPGA, UARTS and more.
> +
> +The actual devices are instantiated from the child nodes of a GMI
> node.
> +
> +Required properties:
> + - compatible : Should contain one of the following:
> +For Tegra20 must contain "nvidia,tegra20-gmi".
> +For Tegra30 must contain "nvidia,tegra30-gmi".
> + - reg: Should contain GMI controller registers location and length.
> + - clocks: Must contain an entry for each entry in clock-names.
> + - clock-names: Must include the following entries: "gmi"
> + - resets : Must contain an entry for each entry in reset-names.
> + - reset-names : Must include the following entries: "gmi"
> + - #address-cells: The number of cells used to represent physical
> base
> + addresses in the GMI address space. Should be 1.
> + - #size-cells: The number of cells used to represent the size of an
> address
> + range in the GMI address space. Should be 1.
> + - ranges: Must be set up to reflect the memory layout with three
> integer values
> + for each chip-select line in use (only one entry is supported,
> see below
> + comments):
> +
> +
> +Note that the GMI controller does not have any internal chip-select
> address
> +decoding, because of that chip-selects either need to be managed via
> software
> +or by employing external chip-select decoding logic.
> +
> +If external chip-select logic is used to support multiple devices it
> is assumed
> +that the devices use the same timing and so are probably the same
> type. It also
> +assumes that they can fit in the 256MB address range. In this case
> only one
> +child device is supported which represents the active chip-select
> line, see
> +examples for more insight.
> +
> +Required child cs node properties:
> + - reg: First entry should contain the active chip-select number
> +
> +Optional child cs node properties:
> +
> + - nvidia,snor-data-width-32bit: Use 32bit data-bus, default is
> 16bit.
> + - nvidia,snor-mux-mode: Enable address/data MUX mode.
> + - nvidia,snor-rdy-active-before-data: Assert RDY signal one cycle
> before data.
> + If omitted it will be asserted with data.
> + - nvidia,snor-rdy-inv: RDY signal is active high
> + - nvidia,snor-adv-inv: ADV signal is active high
> + - nvidia,snor-oe-inv: WE/OE signal is active high
> + - nvidia,snor-cs-inv: CS signal is active high
> +
> + Note that there is some special handling for the timing values.
> + From Tegra TRM:
> + Programming 0 means 1 clock cycle: actual cycle = programmed cycle
> + 1
> +
> + - nvidia,snor-muxed-width: Number of cycles MUX address/data
> asserted on the
> + bus. Valid values are 0-15, default is 1
> + - nvidia,snor-hold-width: Number of cycles CE stays asserted after
> the
> + de-assertion of WR_N (in case of SLAVE/MASTER Request) or OE_N
> + (in case of MASTER Request). Valid values are 0-15, default is 1
> + - nvidia,snor-adv-width: Number of cycles during which ADV stays
> asserted.
> + Valid values are 0-15, default is 1.
> + - nvidia,snor-ce-width: Number of cycles before CE is asserted.
> + Valid values are 0-15, default is 4
> + - nvidia,snor-we-width: Number of cycles during which WE stays
> asserted.
> + Valid values are 0-15, default is 1
> + - nvidia,snor-oe-width: Number of cycles during which OE stays
> asserted.
> + Valid values are 0-255, default is 1
> + - nvidia,snor-wait-width: Number of cycles before READY is
> asserted.
> + Valid values are 0-255, default is 3
> +
> +Example with two SJA1000 CAN controllers connected to the GMI bus.
> We wrap the
> +controllers with a simple-bus node since they are all connected to
> the same
> +chip-select (CS4), in this example external address decoding is
> provided:
> +
> +gmi@7009 {
It's actually 70009000.
> + compatible = "nvidia,tegra20-gmi";
> + reg = <0x70009000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + clocks = <&tegra_car TEGRA20
Re: [PATCH] ravb: avoid unused function warnings
From: Arnd Bergmann
Date: Fri, 26 Aug 2016 17:30:29 +0200
> When CONFIG_PM_SLEEP is disabled, we get a couple of harmless warnings:
>
> drivers/net/ethernet/renesas/ravb_main.c:2117:12: error: 'ravb_resume'
> defined but not used [-Werror=unused-function]
> drivers/net/ethernet/renesas/ravb_main.c:2104:12: error: 'ravb_suspend'
> defined but not used [-Werror=unused-function]
>
> The simplest solution here is to replace the #ifdef with __maybe_unused
> annotations, which lets the compiler do the right thing by itself.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 0184165b2f42 ("ravb: add sleep PM suspend/resume support")
Applied, thanks.
Re: [PATCH v2] kernel/fork: fix CLONE_CHILD_CLEARTID regression in nscd
On Wed 24-08-16 17:37:16, Michal Hocko wrote:
> On Wed 24-08-16 17:32:00, Oleg Nesterov wrote:
> > On 08/24, Michal Hocko wrote:
> > >
> > > Sounds better?
> > > diff --git a/kernel/fork.c b/kernel/fork.c
> > > index b89f0eb99f0a..ddde5849df81 100644
> > > --- a/kernel/fork.c
> > > +++ b/kernel/fork.c
> > > @@ -914,7 +914,8 @@ void mm_release(struct task_struct *tsk, struct
> > > mm_struct *mm)
> > >
> > > /*
> > >* Signal userspace if we're not exiting with a core dump
> > > - * or a killed vfork parent which shouldn't touch this mm.
> > > + * because we want to leave the value intact for debugging
> > > + * purposes.
> > >*/
> > > if (tsk->clear_child_tid) {
> > > if (!(tsk->signal->flags & SIGNAL_GROUP_COREDUMP) &&
> >
> > Yes, thanks Michal!
> >
> > Acked-by: Oleg Nesterov
>
> OK, thanks.
ping
> ---
> From 39cad7842660e0261c27f75702d49458a1f3cea1 Mon Sep 17 00:00:00 2001
> From: Michal Hocko
> Date: Mon, 30 May 2016 20:20:32 +0200
> Subject: [PATCH] kernel/fork: fix CLONE_CHILD_CLEARTID regression in nscd
>
> fec1d0115240 ("[PATCH] Disable CLONE_CHILD_CLEARTID for abnormal exit")
> has caused a subtle regression in nscd which uses CLONE_CHILD_CLEARTID
> to clear the nscd_certainly_running flag in the shared databases, so
> that the clients are notified when nscd is restarted. Now, when nscd
> uses a non-persistent database, clients that have it mapped keep
> thinking the database is being updated by nscd, when in fact nscd has
> created a new (anonymous) one (for non-persistent databases it uses an
> unlinked file as backend).
>
> The original proposal for the CLONE_CHILD_CLEARTID change claimed
> (https://lkml.org/lkml/2006/10/25/233):
> "
> The NPTL library uses the CLONE_CHILD_CLEARTID flag on clone() syscalls
> on behalf of pthread_create() library calls. This feature is used to
> request that the kernel clear the thread-id in user space (at an address
> provided in the syscall) when the thread disassociates itself from the
> address space, which is done in mm_release().
>
> Unfortunately, when a multi-threaded process incurs a core dump (such as
> from a SIGSEGV), the core-dumping thread sends SIGKILL signals to all of
> the other threads, which then proceed to clear their user-space tids
> before synchronizing in exit_mm() with the start of core dumping. This
> misrepresents the state of process's address space at the time of the
> SIGSEGV and makes it more difficult for someone to debug NPTL and glibc
> problems (misleading him/her to conclude that the threads had gone away
> before the fault).
>
> The fix below is to simply avoid the CLONE_CHILD_CLEARTID action if a
> core dump has been initiated.
> "
>
> The resulting patch from Roland (https://lkml.org/lkml/2006/10/26/269)
> seems to have a larger scope than the original patch asked for. It seems
> that limitting the scope of the check to core dumping should work for
> SIGSEGV issue describe above.
>
> [Changelog partly based on Andreas' description]
> Fixes: fec1d0115240 ("[PATCH] Disable CLONE_CHILD_CLEARTID for abnormal exit")
> Tested-by: William Preston
> Cc: Roland McGrath
> Cc: Andreas Schwab
> Acked-by: Oleg Nesterov
> Signed-off-by: Michal Hocko
> ---
> kernel/fork.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 52e725d4a866..ddde5849df81 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -913,14 +913,12 @@ void mm_release(struct task_struct *tsk, struct
> mm_struct *mm)
> deactivate_mm(tsk, mm);
>
> /*
> - * If we're exiting normally, clear a user-space tid field if
> - * requested. We leave this alone when dying by signal, to leave
> - * the value intact in a core dump, and to save the unnecessary
> - * trouble, say, a killed vfork parent shouldn't touch this mm.
> - * Userland only wants this done for a sys_exit.
> + * Signal userspace if we're not exiting with a core dump
> + * because we want to leave the value intact for debugging
> + * purposes.
>*/
> if (tsk->clear_child_tid) {
> - if (!(tsk->flags & PF_SIGNALED) &&
> + if (!(tsk->signal->flags & SIGNAL_GROUP_COREDUMP) &&
> atomic_read(&mm->mm_users) > 1) {
> /*
>* We don't check the error code - if userspace has
> --
> 2.8.1
>
> --
> Michal Hocko
> SUSE Labs
--
Michal Hocko
SUSE Labs
Re: [PATCH V3 2/2] rtc/rtc-cmos: Initialize software counters before irq is registered
On 31/08/2016 at 12:56:17 +0800, Dave Young wrote : > Hi, Pratyush, > > I'm not sure who is the maintainer to review and take the patches, > In MATAINERS file, x86 hpet is orphaned. rtc-cmos may go to rtc > maitianer Alessandro Zummo > > Ccing Andrew maybe he can also take the patches for orphaned component. > Well, my point was that I can take them but I'd like to get some review from the x86 maintainers as this is x86 specific and I don't know much about the hpet. > On 08/30/16 at 03:24pm, Pratyush Anand wrote: > > Hi Dave, > > > > On 30/08/2016:04:22:30 PM, Dave Young wrote: > > > Hi, Pratyush > > > > > > On 08/16/16 at 08:55am, Pratyush Anand wrote: > > > > We have observed on few x86 machines with rtc-cmos device that > > > > hpet_rtc_interrupt() is called just after irq registration and before > > > > cmos_do_probe() could call hpet_rtc_timer_init(). > > > > > > > > So, neither hpet_default_delta nor hpet_t1_cmp is initialized by the > > > > time > > > > interrupt is raised in the given situation, and this results in NMI > > > > watchdog LOCKUP. > > > > > > > > It has only been observed sporadically on kdump secondary kernels. > > > > > > > > See the call trace: > > > > ---<-snip->--- > > > >27.913194] Kernel panic - not syncing: Watchdog detected hard LOCKUP > > > > on > > > > cpu 0 > > > > [ 27.915371] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > > > > 3.10.0-342.el7.x86_64 #1 > > > > [ 27.917503] Hardware name: HP ProLiant DL160 Gen8, BIOS J03 > > > > 02/10/2014 > > > > [ 27.919455] 8186a728 59c82488 880034e05af0 > > > > 81637bd4 > > > > [ 27.921870] 880034e05b70 8163144a 0010 > > > > 880034e05b80 > > > > [ 27.924257] 880034e05b20 59c82488 > > > > > > > > [ 27.926599] Call Trace: > > > > [ 27.927352][] dump_stack+0x19/0x1b > > > > [ 27.929080] [] panic+0xd8/0x1e7 > > > > [ 27.930588] [] ? > > > > restart_watchdog_hrtimer+0x50/0x50 > > > > [ 27.932502] [] > > > > watchdog_overflow_callback+0xc2/0xd0 > > > > [ 27.934427] [] __perf_event_overflow+0xa1/0x250 > > > > [ 27.936232] [] perf_event_overflow+0x14/0x20 > > > > [ 27.937957] [] intel_pmu_handle_irq+0x1e8/0x470 > > > > [ 27.939799] [] perf_event_nmi_handler+0x2b/0x50 > > > > [ 27.941649] [] nmi_handle.isra.0+0x69/0xb0 > > > > [ 27.943348] [] do_nmi+0x169/0x340 > > > > [ 27.944802] [] end_repeat_nmi+0x1e/0x2e > > > > [ 27.946424] [] ? hpet_rtc_interrupt+0x85/0x380 > > > > [ 27.948197] [] ? hpet_rtc_interrupt+0x85/0x380 > > > > [ 27.949992] [] ? hpet_rtc_interrupt+0x85/0x380 > > > > [ 27.951816] <>[] ? > > > > run_timer_softirq+0x43/0x340 > > > > [ 27.954114] [] handle_irq_event_percpu+0x3e/0x1e0 > > > > [ 27.955962] [] handle_irq_event+0x3d/0x60 > > > > [ 27.957635] [] handle_edge_irq+0x77/0x130 > > > > [ 27.959332] [] handle_irq+0xbf/0x150 > > > > [ 27.960949] [] do_IRQ+0x4f/0xf0 > > > > [ 27.962434] [] common_interrupt+0x6d/0x6d > > > > [ 27.964101][] ? > > > > _raw_spin_unlock_irqrestore+0x1b/0x40 > > > > [ 27.966308] [] __setup_irq+0x2a7/0x570 > > > > [ 28.067859] [] ? hpet_cpuhp_notify+0x140/0x140 > > > > [ 28.069709] [] request_threaded_irq+0xcc/0x170 > > > > [ 28.071585] [] cmos_do_probe+0x1e6/0x450 > > > > [ 28.073240] [] ? cmos_do_probe+0x450/0x450 > > > > [ 28.074911] [] cmos_pnp_probe+0xbb/0xc0 > > > > [ 28.076533] [] pnp_device_probe+0x65/0xd0 > > > > [ 28.078198] [] driver_probe_device+0x87/0x390 > > > > [ 28.079971] [] __driver_attach+0x93/0xa0 > > > > [ 28.081660] [] ? __device_attach+0x40/0x40 > > > > [ 28.083662] [] bus_for_each_dev+0x73/0xc0 > > > > [ 28.085370] [] driver_attach+0x1e/0x20 > > > > [ 28.086974] [] bus_add_driver+0x200/0x2d0 > > > > [ 28.088634] [] ? rtc_sysfs_init+0xe/0xe > > > > [ 28.090349] [] driver_register+0x64/0xf0 > > > > [ 28.091989] [] pnp_register_driver+0x20/0x30 > > > > [ 28.093707] [] cmos_init+0x11/0x71 > > > > ---<-snip->--- > > > > > > > > The previous patch split hpet_rtc_timer_init into > > > > hpet_rtc_timer_counter_init() and hpet_rtc_timer_enable(). > > > > > > > > Therefore, this patch moved hpet_rtc_timer_counter_init() before IRQ > > > > registration, so that we can gracefully handle such spurious interrupts. > > > > > > > > We were able to reproduce the problem in maximum 15 trials of kdump > > > > secondary kernel boot on an hp-dl160gen8 machine without this patch. > > > > However, more than 35 trials went fine after applying this patch. > > > > > > > > Signed-off-by: Pratyush Anand > > > > [dzic...@redhat.com: edited the patch's summary] > > > > Signed-off-by: Don Zickus > > > > --- > > > > drivers/rtc/rtc-cmos.c | 13 - > > > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c > > > > index 43745cac0141..089d987f2638 100644 > > > > ---
Re: [PATCH v4] ARM: dts: exynos: Enable HDMI for Arndale Octa board
On 08/31/2016 08:08 AM, Milo Kim wrote:
> * GPIO for HDMI hot plug detect
> GPX3_7 is used. The HPD awareness is done when the GPIO is active high.
>
> * Enable HDMI block in Exynos5420
> HDMI VDD and PLL consume 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator
> requires 1.8V LDO7 (PVDD_ANAIP_1V8).
>
> * Support HDMI display data channel
> I2C #2 is assigned for the HDMI DDC. It enables the EDID access.
>
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: Rob Herring
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Milo Kim
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> arch/arm/boot/dts/exynos5420-arndale-octa.dts | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> index 39a3b81..d2ad48e 100644
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -70,6 +70,15 @@
> status = "disabled";
> };
>
> +&hdmi {
> + hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
> + vdd_osc-supply = <&ldo7_reg>;
> + vdd_pll-supply = <&ldo6_reg>;
> + vdd-supply = <&ldo6_reg>;
> + ddc = <&i2c_2>;
> + status = "okay";
> +};
> +
> &hsi2c_4 {
> status = "okay";
>
> @@ -347,6 +356,10 @@
> };
> };
>
> +&i2c_2 {
> + status = "okay";
> +};
> +
> &mmc_0 {
> status = "okay";
> broken-cd;
Re: [PATCH 1/2] mmc: dw_mmc: split out preparation of desc for IDMAC32 and IDMAC64
Hi Shawn,
On 08/19/2016 06:40 PM, Shawn Lin wrote:
> We intend to add more check for descriptors when
> preparing desc. Let's spilt out the separate body
> to make the dw_mci_translate_sglist not so lengthy.
Sorry for reviewing late.
>
> Signed-off-by: Shawn Lin
> ---
>
> drivers/mmc/host/dw_mmc.c | 148
> +-
> 1 file changed, 81 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 32380d5..0a5a49f 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -467,103 +467,117 @@ static void dw_mci_dmac_complete_dma(void *arg)
> }
> }
>
> -static void dw_mci_translate_sglist(struct dw_mci *host, struct mmc_data
> *data,
> - unsigned int sg_len)
> +static inline void dw_mci_prepare_desc64(struct dw_mci *host,
> + struct mmc_data *data,
> + unsigned int sg_len)
> {
> unsigned int desc_len;
> + struct idmac_desc_64addr *desc_first, *desc_last, *desc;
> int i;
>
> - if (host->dma_64bit_address == 1) {
> - struct idmac_desc_64addr *desc_first, *desc_last, *desc;
> -
> - desc_first = desc_last = desc = host->sg_cpu;
> + desc_first = desc_last = desc = host->sg_cpu;
>
> - for (i = 0; i < sg_len; i++) {
> - unsigned int length = sg_dma_len(&data->sg[i]);
> + for (i = 0; i < sg_len; i++) {
> + unsigned int length = sg_dma_len(&data->sg[i]);
>
> - u64 mem_addr = sg_dma_address(&data->sg[i]);
> + u64 mem_addr = sg_dma_address(&data->sg[i]);
>
> - for ( ; length ; desc++) {
> - desc_len = (length <= DW_MCI_DESC_DATA_LENGTH) ?
> -length : DW_MCI_DESC_DATA_LENGTH;
> + for ( ; length ; desc++) {
> + desc_len = (length <= DW_MCI_DESC_DATA_LENGTH) ?
> +length : DW_MCI_DESC_DATA_LENGTH;
>
> - length -= desc_len;
> + length -= desc_len;
>
> - /*
> - * Set the OWN bit and disable interrupts
> - * for this descriptor
> - */
> - desc->des0 = IDMAC_DES0_OWN | IDMAC_DES0_DIC |
> - IDMAC_DES0_CH;
> + /*
> + * Set the OWN bit and disable interrupts
> + * for this descriptor
> + */
> + desc->des0 = IDMAC_DES0_OWN | IDMAC_DES0_DIC |
> + IDMAC_DES0_CH;
>
> - /* Buffer length */
> - IDMAC_64ADDR_SET_BUFFER1_SIZE(desc, desc_len);
> + /* Buffer length */
> + IDMAC_64ADDR_SET_BUFFER1_SIZE(desc, desc_len);
>
> - /* Physical address to DMA to/from */
> - desc->des4 = mem_addr & 0x;
> - desc->des5 = mem_addr >> 32;
> + /* Physical address to DMA to/from */
> + desc->des4 = mem_addr & 0x;
> + desc->des5 = mem_addr >> 32;
>
> - /* Update physical address for the next desc */
> - mem_addr += desc_len;
> + /* Update physical address for the next desc */
> + mem_addr += desc_len;
>
> - /* Save pointer to the last descriptor */
> - desc_last = desc;
> - }
> + /* Save pointer to the last descriptor */
> + desc_last = desc;
> }
> + }
>
> - /* Set first descriptor */
> - desc_first->des0 |= IDMAC_DES0_FD;
> + /* Set first descriptor */
> + desc_first->des0 |= IDMAC_DES0_FD;
>
> - /* Set last descriptor */
> - desc_last->des0 &= ~(IDMAC_DES0_CH | IDMAC_DES0_DIC);
> - desc_last->des0 |= IDMAC_DES0_LD;
> + /* Set last descriptor */
> + desc_last->des0 &= ~(IDMAC_DES0_CH | IDMAC_DES0_DIC);
> + desc_last->des0 |= IDMAC_DES0_LD;
> +}
>
> - } else {
> - struct idmac_desc *desc_first, *desc_last, *desc;
>
> - desc_first = desc_last = desc = host->sg_cpu;
> +static inline void dw_mci_prepare_desc32(struct dw_mci *host,
> + struct mmc_data *data,
> + unsigned int sg_len)
> +{
> + unsigned int desc_len;
> + struct idmac_desc *desc_first, *desc_last, *desc;
> + int i;
>
Re: [PATCH v4 1/3] gpu: drm: exynos_hdmi: Move DDC logic into single function
On 08/31/2016 08:14 AM, Milo Kim wrote: > Paring DT properties and getting the I2C adapter in one function. > > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: dri-de...@lists.freedesktop.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Milo Kim > Reviewed-by: Andrzej Hajda -- Regards Andrzej
Re: [PATCH 2/2] mmc: dw_mmc: avoid race condition of cpu and IDMAC
Hi Shawn,
On 08/19/2016 06:40 PM, Shawn Lin wrote:
> We could see an obvious race condition by test that
> the former write operation by IDMAC aiming to clear
> OWN bit reach right after the later configuration of
> the same desc, which makes the IDMAC be in SUSPEND
> state as the OWN bit was cleared by the asynchronous
> write operation of IDMAC. The bug can be very easy
> reproduced on RK3288 or similar when we reduce the
> running rate of system buses and keep the CPU running
> faster. So as two separate masters, IDMAC and cpu
> write the same descriptor stored on the same address,
> and this should be protected by adding check of OWN
> bit before preparing new descriptors.
>
> Signed-off-by: Shawn Lin
> ---
>
> drivers/mmc/host/dw_mmc.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 0a5a49f..e640f83 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -473,6 +473,7 @@ static inline void dw_mci_prepare_desc64(struct dw_mci
> *host,
> {
> unsigned int desc_len;
> struct idmac_desc_64addr *desc_first, *desc_last, *desc;
> + unsigned long timeout = jiffies + msecs_to_jiffies(100);
> int i;
>
> desc_first = desc_last = desc = host->sg_cpu;
> @@ -489,6 +490,20 @@ static inline void dw_mci_prepare_desc64(struct dw_mci
> *host,
> length -= desc_len;
>
> /*
> + * Wait for the former clear OWN bit operation
> + * of IDMAC to make sure that this descriptor
> + * isn't still owned by IDMAC as IDMAC's write
> + * ops and CPU's read ops are asynchronous.
> + */
> + while (readl(&desc->des0) & IDMAC_DES0_OWN) {
> + if (time_after(jiffies, timeout)) {
> + dev_err(host->dev, "DESC is still owned
> by IDMAC.\n");
> + break;
Doesn't it need the error handling? Just display the message?
Best Regards,
Jaehoon Chung
> + }
> + udelay(10);
> + }
> +
> + /*
>* Set the OWN bit and disable interrupts
>* for this descriptor
>*/
> @@ -525,6 +540,7 @@ static inline void dw_mci_prepare_desc32(struct dw_mci
> *host,
> {
> unsigned int desc_len;
> struct idmac_desc *desc_first, *desc_last, *desc;
> + unsigned long timeout = jiffies + msecs_to_jiffies(100);
> int i;
>
> desc_first = desc_last = desc = host->sg_cpu;
> @@ -541,6 +557,20 @@ static inline void dw_mci_prepare_desc32(struct dw_mci
> *host,
> length -= desc_len;
>
> /*
> + * Wait for the former clear OWN bit operation
> + * of IDMAC to make sure that this descriptor
> + * isn't still owned by IDMAC as IDMAC's write
> + * ops and CPU's read ops are asynchronous.
> + */
> + while (readl(&desc->des0) & IDMAC_DES0_OWN) {
> + if (time_after(jiffies, timeout)) {
> + dev_err(host->dev, "DESC is still owned
> by IDMAC.\n");
> + break;
> + }
> + udelay(10);
> + }
> +
> + /*
>* Set the OWN bit and disable interrupts
>* for this descriptor
>*/
>
Re: [PATCH V6 1/5] perf tools: making coresight PMU listable
On Mon, Aug 29, 2016 at 09:56:02AM -0600, Mathieu Poirier wrote: > On 28 August 2016 at 08:16, Jiri Olsa wrote: > > On Thu, Aug 25, 2016 at 02:20:41PM -0600, Mathieu Poirier wrote: > > > > SNIP > > > >> ARM/CORGI MACHINE SUPPORT > >> M: Richard Purdie > >> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config > >> index 24803c58049a..72edf83d76b7 100644 > >> --- a/tools/perf/Makefile.config > >> +++ b/tools/perf/Makefile.config > >> @@ -746,10 +746,13 @@ ifdef LIBBABELTRACE > >> endif > >> > >> ifndef NO_AUXTRACE > >> - ifeq ($(feature-get_cpuid), 0) > >> -msg := $(warning Your gcc lacks the __get_cpuid() builtin, disables > >> support for auxtrace/Intel PT, please install a newer gcc); > >> -NO_AUXTRACE := 1 > >> - else > >> + ifeq ($(ARCH),x86) > >> +ifeq ($(feature-get_cpuid), 0) > >> + msg := $(warning Your gcc lacks the __get_cpuid() builtin, disables > >> support for auxtrace/Intel PT, please install a newer gcc); > >> + NO_AUXTRACE := 1 > >> +endif > >> + endif > >> + ifndef NO_AUXTRACE > > > > hum, how's this hunk connected to the issue described in changelog? > > Patch 1/6 and 2/6 are needed by [3, 4, 5, 6]/6 of this set. > Originally they were part of a separate patchset I but decided to > include them here for completeness. Let me know if you'd like to see > them split again. ook, jirka
Re: [PATCH 0/4 v3] Add a new board TOPEET iTOP for exynos 4412
On 08/28/2016 01:21 PM, Randy Li wrote: > The added the audio codec seems work now, but the audio sounds > still a little different to the original. But I didn't hear the sound > in the Android, I don't know whether it is qualified. > > Also it lacks of full pinctrl for the sleep state. > > Changelog: > - v3: >- fixing the rtc clock, using clock source from PMIC >- enable the tmu >- enable the fimc for elite board >- suuport the audio codec at elite board >- fixing minor bugs in the last commit > - v2: >- removing rtc node > the clock source driver is not done yet. >- adding exynos-bus >- fixing the MFC The way you send emails is really messed up. 1. The v3 in "PATCH v3" should be present in all patches. Use -v3 for format-patch. 2. Don't reply-in-to old thread. All your new patches are now under old ones. They have same subject so this is highly confusing. I don't have a clue which is a new one. Best regards, Krzysztof
Re: [PATCH] arm64: dts: rockchip: Explicitly set pclk_pmu_src on rk3399
Hi Elaine,
Am Dienstag, 30. August 2016, 08:59:31 schrieb Elaine Zhang:
> On 08/30/2016 02:18 AM, Brian Norris wrote:
> > On Mon, Aug 29, 2016 at 11:11:24AM -0700, Doug Anderson wrote:
> >> On rk3399 we explicitly set ppll in the device tree to 67600. The
> >> ppll has one major child, pclk_pmu_src, that is the parent of lots of
> >> other clocks. Right now nobody is setting that clock rate and we're
> >> relying on the divider to just happen to be something sane. Let's be
> >> explicit in our request so we're not relying on the firmware.
> >>
> >> With the current firmware I tested with this patch has no expected
> >> impact but it's probably good to do anyway.
> >>
> >> Signed-off-by: Douglas Anderson
> >> ---
> >>
> >> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> >> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index
> >> 62d450935a57..ffb3faa8c176 100644
> >> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> >> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> >> @@ -908,8 +908,8 @@
> >>
> >>reg = <0x0 0xff75 0x0 0x1000>;
> >>#clock-cells = <1>;
> >>#reset-cells = <1>;
> >>
> >> - assigned-clocks = <&pmucru PLL_PPLL>;
> >> - assigned-clock-rates = <67600>;
> >> + assigned-clocks = <&pmucru PLL_PPLL>, <&pmucru PCLK_SRC_PMU>;
> >> + assigned-clock-rates = <67600>, <11267>;
> >
> > I think this makes sense and is a good idea. One alternative would be to
> > have the various children actually set a rate that they expect, but
> > several of them don't have a separate driver at all, and that would be
> > of dubious value anyway I think.
>
> I agree with you. This clk default div is set in the uboot or coreboot.
> And if is need to set in kernel ,I hope the freq is 50M(<48285714>).
> This freq can meet the performance,and the power consumption is not too
> much.
can you maybe also provide a tag like the one Brian did below. Your sentence
above indicates that you reviewed and approve, but it's helpful to also state
that explicitly :-)
> > Reviewed-by: Brian Norris
Thanks
Heiko
> >
> >>};
> >>
> >>cru: clock-controller@ff76 {
> >>
> >> --
> >> 2.8.0.rc3.226.g39d4020
Re: [PATCH] ALSA: hda - Enable subwoofer on Dell Inspiron 7559
On Tue, 30 Aug 2016 08:25:18 +0200,
Kai Heng Feng wrote:
>
> On Tue, Aug 30, 2016 at 1:33 PM, Takashi Iwai wrote:
> > On Tue, 30 Aug 2016 07:27:41 +0200,
> > Kai-Heng Feng wrote:
> >>
> >> The subwoofer on Inspiron 7559 does not work originally.
> >> Applying a pin fixup can make it work.
> >>
> >> Signed-off-by: Kai-Heng Feng
> >> ---
> >> sound/pci/hda/patch_realtek.c | 11 +++
> >> 1 file changed, 11 insertions(+)
> >>
> >> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> >> index 7100f05..2a3dd18 100644
> >> --- a/sound/pci/hda/patch_realtek.c
> >> +++ b/sound/pci/hda/patch_realtek.c
> >> @@ -4855,6 +4855,7 @@ enum {
> >> ALC221_FIXUP_HP_FRONT_MIC,
> >> ALC292_FIXUP_TPT460,
> >> ALC298_FIXUP_SPK_VOLUME,
> >> + ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER,
> >> };
> >>
> >> static const struct hda_fixup alc269_fixups[] = {
> >> @@ -5516,6 +5517,15 @@ static const struct hda_fixup alc269_fixups[] = {
> >> .chained = true,
> >> .chain_id = ALC298_FIXUP_DELL1_MIC_NO_PRESENCE,
> >> },
> >> + [ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER] = {
> >> + .type = HDA_FIXUP_PINS,
> >> + .v.pins = (const struct hda_pintbl[]) {
> >> + { 0x1b, 0x90170151 },
> >
> > What's the original value of this pin?
> >
> >
> > Takashi
>
> The original value of 0x1b is 0x41f0.
OK, so it was disabled. Maybe better to mention it in the patch
description.
Takashi
Did you get my message?
Hello, This is the second time i am sending you this mail. I, Friedrich Mayrhofer and my wife has Donate $ 1,000,000.00 USD to You, Email Me personally for more details. Regards. Friedrich Mayrhofer
Re: hwrng: pasemi_rng.c: Migrate to managed API
Hi Darren, >> I wanted to use devm_ioremap_resource but could not find DT entry >> required for this driver in any of the .dts files. So did not change >> that. I could not find any dts/dtsi for this platform. So I assume >> that the dtb is not present in the kernel, dtb is supplied by the >> bootloader. I may be wrong in this. Can anyone confirm this? > > On mine (Amigaone X1000) that is correct, we boot linux with a vmlinux file, > and the bootloader (CFE) passes a fixed dtb. I think it is possible to dump > the tree from inside CFE, if it would help I can invetigate? I don't know if it is possible to get dts from dtb even if you manage to extract devicetree blob from your system. Labbe, Do you know anyway to get dts from dtb? Is this step really required to remove 0x100 value for this patch given that the value was present here for years? If extracting dtb and converting dtb to dts is easy and not time consuming, I am in favour of finding a way to remove hard coded value.
Re: [PATCH 1/4] ARM: dts: Add TOPEET itop core board SCP package version
On 08/28/2016 01:21 PM, Randy Li wrote:
> The TOPEET itop is a samsung exnynos 4412 core board, which have
> two package versions. This patch add the support for SCP version.
>
> Currently supported are USB3503A HSIC, USB OTG, eMMC, rtc and
> PMIC. The future features are in the based board. Also MFC and
> watchdog have been enabled.
>
> Signed-off-by: Randy Li
> ---
> arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 489
>
> 1 file changed, 489 insertions(+)
> create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
>
> diff --git a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
> b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
> new file mode 100644
> index 000..ce5076c
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
> @@ -0,0 +1,489 @@
> +/*
> + * TOPEET's Exynos4412 based itop board device tree source
> + *
> + * Copyright (c) 2016 SUMOMO Computer Association
> + * https://www.sumomo.mobi
> + * Randy Li
> + *
> + * Device tree source file for TOPEET iTop Exynos 4412 SCP package core
> + * board which is based on Samsung's Exynos4412 SoC.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include "exynos4412.dtsi"
> +#include "exynos4412-ppmu-common.dtsi"
> +#include "exynos-mfc-reserved-memory.dtsi"
> +#include
> +#include
First system-wide includes, then local ones.
> +
> +/ {
> + memory {
> + reg = <0x4000 0x4000>;
> + };
> +
> + firmware@0203F000 {
> + compatible = "samsung,secure-firmware";
> + reg = <0x0203F000 0x1000>;
> + };
> +
> + fixed-rate-clocks {
> + xxti {
> + compatible = "samsung,clock-xxti";
> + clock-frequency = <0>;
> + };
> +
> + xusbxti {
> + compatible = "samsung,clock-xusbxti";
> + clock-frequency = <2400>;
> + };
> +
> + /* Clock from S5M8767A AP32K */
> + ap32k: xrtcxti {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <32768000>;
1. 32 MHz? Usually it is 32 kHz... Did you test these DTS?
2. Please use existing S5M8767 driver.
> + };
> + };
> +
> + thermal-zones {
> + cpu_thermal: cpu-thermal {
> + cooling-maps {
> + map0 {
> + /* Corresponds to 800MHz at freq_table */
> + cooling-device = <&cpu0 7 7>;
> + };
> + map1 {
> + /* Corresponds to 200MHz at freq_table */
> + cooling-device = <&cpu0 13 13>;
> +};
> +};
> + };
> + };
> +
> + usb-hub {
> + compatible = "smsc,usb3503a";
Floating USB hub? Isn't it connected to SoC through I2C?
> + reset-gpios = <&gpm2 4 GPIO_ACTIVE_LOW>;
> + connect-gpios = <&gpm3 3 GPIO_ACTIVE_HIGH>;
> + intn-gpios = <&gpx2 3 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&hsic_reset>;
> + };
> +};
> +
> +&bus_dmc {
> + devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> + vdd-supply = <&buck1_reg>;
> + status = "okay";
> +};
> +
> +&bus_acp {
> +devfreq = <&bus_dmc>;
> +status = "okay";
> +};
> +
> +&bus_c2c {
> +devfreq = <&bus_dmc>;
> +status = "okay";
> +};
> +
> +&bus_leftbus {
> +devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
> +vdd-supply = <&buck3_reg>;
> +status = "okay";
> +};
> +
> +&bus_rightbus {
> +devfreq = <&bus_leftbus>;
> +status = "okay";
> +};
> +
> +&bus_fsys {
> +devfreq = <&bus_leftbus>;
> +status = "okay";
> +};
> +
> +&bus_peri {
> +devfreq = <&bus_leftbus>;
> +status = "okay";
> +};
> +
> +&bus_mfc {
> +devfreq = <&bus_leftbus>;
> +status = "okay";
> +};
> +
> +&cpu0 {
> + cpu0-supply = <&buck2_reg>;
> +};
> +
> +&i2c_1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + samsung,i2c-sda-delay = <100>;
> + samsung,i2c-max-bus-freq = <40>;
> + pinctrl-0 = <&i2c1_bus>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + s5m8767: s5m8767_pmic@66 {
> + compatible = "samsung,s5m8767-pmic";
> + reg = <0x66>;
> +
> + s5m8767,pmic-buck-default-dvs-idx = <3>;
> +
> + s5m8767,pmic-buck-dvs-gpios = <&gpb 5 GPIO_ACTIVE_HIGH>,
> + <&gp
