Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption
On Tue, May 16, 2017 at 10:49 PM, Dmitry Vyukov wrote: > On Mon, May 15, 2017 at 11:23 PM, Joonsoo Kim wrote: >>> > >>> > Hello, all. >>> > >>> > This is an attempt to recude memory consumption of KASAN. Please see >>> > following description to get the more information. >>> > >>> > 1. What is per-page shadow memory >>> >>> Hi Joonsoo, >> >> Hello, Dmitry. >> >>> >>> First I need to say that this is great work. I wanted KASAN to consume >> >> Thanks! >> >>> 1/8-th of _kernel_ memory rather than total physical memory for a long >>> time. >>> >>> However, this implementation does not work inline instrumentation. And >>> the inline instrumentation is the main mode for KASAN. Outline >>> instrumentation is merely a rudiment to support gcc 4.9, and it needs >>> to be removed as soon as we stop caring about gcc 4.9 (do we at all? >>> is it the current compiler in any distro? Ubuntu 12 has 4.8, Ubuntu 14 >>> already has 5.4. And if you build gcc yourself or get a fresher >>> compiler from somewhere else, you hopefully get something better than >>> 4.9). >> >> Hmm... I don't think that outline instrumentation is something to be >> removed. In embedded world, there is a fixed partition table and >> enlarging the kernel binary would cause the problem. Changing that >> table is possible but is really uncomfortable thing for debugging >> something. So, I think that outline instrumentation has it's own merit. > > Fair. Let's consider both as important. > >> Anyway, I have missed inline instrumentation completely. >> >> I will attach the fix in the bottom. It doesn't look beautiful >> since it breaks layer design (some check will be done at report >> function). However, I think that it's a good trade-off. > > > I can confirm that inline works with that patch. > > I can also confirm that it reduces memory usage. I've booted qemu with > 2G ram and run some fixed workload. Before: > 31853 dvyukov 20 0 3043200 765464 21312 S 366.0 4.7 2:39.53 > qemu-system-x86 > 7528 dvyukov 20 0 3043200 732444 21676 S 333.3 4.5 2:23.19 > qemu-system-x86 > After: > 6192 dvyukov 20 0 3043200 394244 20636 S 17.9 2.4 2:32.95 > qemu-system-x86 > 6265 dvyukov 20 0 3043200 388860 21416 S 399.3 2.4 3:02.88 > qemu-system-x86 > 9005 dvyukov 20 0 3043200 383564 21220 S 397.1 2.3 2:35.33 > qemu-system-x86 > > However, I see some very significant slowdowns with inline > instrumentation. I did 3 tests: > 1. Boot speed, I measured time for a particular message to appear on > console. Before: > [2.504652] random: crng init done > [2.435861] random: crng init done > [2.537135] random: crng init done > After: > [7.263402] random: crng init done > [7.263402] random: crng init done > [7.174395] random: crng init done > > That's ~3x slowdown. > > 2. I've run bench_readv benchmark: > https://raw.githubusercontent.com/google/sanitizers/master/address-sanitizer/kernel_buildbot/slave/bench_readv.c > as: > while true; do time ./bench_readv bench_readv 30 1; done > > Before: > sys 0m7.299s > sys 0m7.218s > sys 0m6.973s > sys 0m6.892s > sys 0m7.035s > sys 0m6.982s > sys 0m6.921s > sys 0m6.940s > sys 0m6.905s > sys 0m7.006s > > After: > sys 0m8.141s > sys 0m8.077s > sys 0m8.067s > sys 0m8.116s > sys 0m8.128s > sys 0m8.115s > sys 0m8.108s > sys 0m8.326s > sys 0m8.529s > sys 0m8.164s > sys 0m8.380s > > This is ~19% slowdown. > > 3. I've run bench_pipes benchmark: > https://raw.githubusercontent.com/google/sanitizers/master/address-sanitizer/kernel_buildbot/slave/bench_pipes.c > as: > while true; do time ./bench_pipes 10 1 1; done > > Before: > sys 0m5.393s > sys 0m6.178s > sys 0m5.909s > sys 0m6.024s > sys 0m5.874s > sys 0m5.737s > sys 0m5.826s > sys 0m5.664s > sys 0m5.758s > sys 0m5.421s > sys 0m5.444s > sys 0m5.479s > sys 0m5.461s > sys 0m5.417s > > After: > sys 0m8.718s > sys 0m8.281s > sys 0m8.268s > sys 0m8.334s > sys 0m8.246s > sys 0m8.267s > sys 0m8.265s > sys 0m8.437s > sys 0m8.228s > sys 0m8.312s > sys 0m8.556s > sys 0m8.680s > > This is ~52% slowdown. > > > This does not look acceptable to me. I would ready to pay for this, > say, 10% of performance. But it seems that this can have up to 2-4x > slowdown for some workloads. > > > Your use-case is embed devices where you care a lot about both code > size and memory consumption, right? > > I see 2 possible ways forward: > 1. Enable this new mode only for outline, but keep current scheme for > inline. Then outline will be "small but slow" type of configuration. > 2. Somehow fix slowness (at least in inline mode). > > >> Mapping zero page to non-kernel memory could cause true-negative >> problem since we cannot flush the TLB in all cpus. We will read zero >> shadow value value in this case even if actual shadow value is not >> zero. This is one of the reason that black page is introduced in this >> patchset. > > What does make your current patch work then? > Say we map a new shadow page, update the page shadow to say that there > is mappe
[PATCH] tools/include: Sync kernel ABI headers with tooling headers
Sync (copy) the following v4.12 kernel headers to the tooling headers:
arch/x86/include/asm/disabled-features.h:
arch/x86/include/uapi/asm/kvm.h:
arch/powerpc/include/uapi/asm/kvm.h:
arch/s390/include/uapi/asm/kvm.h:
arch/arm/include/uapi/asm/kvm.h:
arch/arm64/include/uapi/asm/kvm.h:
- 'struct kvm_sync_regs' got changed in an ABI-incompatible way,
fortunately none of the (in-kernel) tooling relied on it
- new KVM_DEV calls added
arch/x86/include/asm/required-features.h:
- 5-level paging hardware ABI detail added
arch/x86/include/asm/cpufeatures.h:
- new CPU feature added
arch/x86/include/uapi/asm/vmx.h:
- new VMX exit conditions
None of the changes requires fixes in the tooling source code.
This addresses the following warnings:
Warning: include/uapi/linux/stat.h differs from kernel
Warning: arch/x86/include/asm/disabled-features.h differs from kernel
Warning: arch/x86/include/asm/required-features.h differs from kernel
Warning: arch/x86/include/asm/cpufeatures.h differs from kernel
Warning: arch/x86/include/uapi/asm/kvm.h differs from kernel
Warning: arch/x86/include/uapi/asm/vmx.h differs from kernel
Warning: arch/powerpc/include/uapi/asm/kvm.h differs from kernel
Warning: arch/s390/include/uapi/asm/kvm.h differs from kernel
Warning: arch/arm/include/uapi/asm/kvm.h differs from kernel
Warning: arch/arm64/include/uapi/asm/kvm.h differs from kernel
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar
---
tools/arch/arm/include/uapi/asm/kvm.h | 10 +-
tools/arch/arm64/include/uapi/asm/kvm.h| 10 +-
tools/arch/powerpc/include/uapi/asm/kvm.h | 3 +++
tools/arch/s390/include/uapi/asm/kvm.h | 26 --
tools/arch/x86/include/asm/cpufeatures.h | 2 ++
tools/arch/x86/include/asm/disabled-features.h | 8 +++-
tools/arch/x86/include/asm/required-features.h | 8 +++-
tools/arch/x86/include/uapi/asm/kvm.h | 3 +++
tools/arch/x86/include/uapi/asm/vmx.h | 25 ++---
tools/include/uapi/linux/stat.h| 8 ++--
10 files changed, 84 insertions(+), 19 deletions(-)
diff --git a/tools/arch/arm/include/uapi/asm/kvm.h
b/tools/arch/arm/include/uapi/asm/kvm.h
index 6ebd3e6a1fd1..5e3c673fa3f4 100644
--- a/tools/arch/arm/include/uapi/asm/kvm.h
+++ b/tools/arch/arm/include/uapi/asm/kvm.h
@@ -27,6 +27,8 @@
#define __KVM_HAVE_IRQ_LINE
#define __KVM_HAVE_READONLY_MEM
+#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
+
#define KVM_REG_SIZE(id) \
(1U << (((id) & KVM_REG_SIZE_MASK) >> KVM_REG_SIZE_SHIFT))
@@ -114,6 +116,8 @@ struct kvm_debug_exit_arch {
};
struct kvm_sync_regs {
+ /* Used with KVM_CAP_ARM_USER_IRQ */
+ __u64 device_irq_level;
};
struct kvm_arch_memory_slot {
@@ -192,13 +196,17 @@ struct kvm_arch_memory_slot {
#define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
#define KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS 6
#define KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO 7
+#define KVM_DEV_ARM_VGIC_GRP_ITS_REGS 8
#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT 10
#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK \
(0x3fULL << KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT)
#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK 0x3ff
#define VGIC_LEVEL_INFO_LINE_LEVEL 0
-#define KVM_DEV_ARM_VGIC_CTRL_INIT0
+#define KVM_DEV_ARM_VGIC_CTRL_INIT 0
+#define KVM_DEV_ARM_ITS_SAVE_TABLES 1
+#define KVM_DEV_ARM_ITS_RESTORE_TABLES 2
+#define KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES 3
/* KVM_IRQ_LINE irq field index values */
#define KVM_ARM_IRQ_TYPE_SHIFT 24
diff --git a/tools/arch/arm64/include/uapi/asm/kvm.h
b/tools/arch/arm64/include/uapi/asm/kvm.h
index c2860358ae3e..70eea2ecc663 100644
--- a/tools/arch/arm64/include/uapi/asm/kvm.h
+++ b/tools/arch/arm64/include/uapi/asm/kvm.h
@@ -39,6 +39,8 @@
#define __KVM_HAVE_IRQ_LINE
#define __KVM_HAVE_READONLY_MEM
+#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
+
#define KVM_REG_SIZE(id) \
(1U << (((id) & KVM_REG_SIZE_MASK) >> KVM_REG_SIZE_SHIFT))
@@ -143,6 +145,8 @@ struct kvm_debug_exit_arch {
#define KVM_GUESTDBG_USE_HW(1 << 17)
struct kvm_sync_regs {
+ /* Used with KVM_CAP_ARM_USER_IRQ */
+ __u64 device_irq_level;
};
struct kvm_arch_memory_slot {
@@ -212,13 +216,17 @@ struct kvm_arch_memory_slot {
#define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
#define KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS 6
#define KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO 7
+#define KVM_DEV_ARM_VGIC_GRP_ITS_REGS 8
#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT 10
#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK \
(0x3fULL << KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT)
#define KVM_DEV_ARM_VGIC_LINE_LE
Re: [PATCH 4.4 000/103] 4.4.70-stable review
On Wed, May 24, 2017 at 08:50:39AM +0200, Greg Kroah-Hartman wrote: > On Tue, May 23, 2017 at 09:01:05PM -0700, Guenter Roeck wrote: > > On 05/23/2017 01:08 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.4.70 release. > > > There are 103 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Thu May 25 20:08:25 UTC 2017. > > > Anything received after that time might be too late. > > > > > > > Early feedback: All x86_64 images are crashing. Let me know if you need me > > to bisect. > > > > Guenter > > > > --- > > > > ... > > EXT4-fs (sda): re-mounted. Opts: errors=remount-ro,data=ordered > > BUG: unable to handle kernel paging request at 2280 > > IP: [] process_echoes+0x15/0x70 > > PGD da68067 PUD d991067 PMD 0 > > Oops: [#1] PREEMPT SMP > > Modules linked in: > > CPU: 0 PID: 400 Comm: bootlogd Not tainted 4.4.70-rc1-yocto-standard+ #1 > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS > > rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014 > > task: 88000d159bc0 ti: 88000d23 task.ti: 88000d23 > > RIP: 0010:[] [] > > process_echoes+0x15/0x70 > > RSP: 0018:88000d233d50 EFLAGS: 0202 > > RAX: 88000dd950d8 RBX: RCX: 0007 > > RDX: 88000dd4a400 RSI: 88000d91b700 RDI: 88000dd95000 > > RBP: 88000d233d68 R08: 7000 R09: 88000eeb91c8 > > R10: 7fffc9dc3f70 R11: 0246 R12: 0007 > > R13: 00603574 R14: 0007 R15: 88000d91b700 > > FS: 7f973601b700() GS:88000fc0() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 2280 CR3: 0d953000 CR4: 003406f0 > > Stack: > > 88000dd95000 0007 00603574 88000d233df0 > > 814515b7 00410022 88000d91b700 88000dd950d8 > > 88000dd4a400 88000d91b700 88000d159bc0 > > Call Trace: > > [] n_tty_write+0x97/0x4e0 > > [] ? __wake_up_sync+0x20/0x20 > > [] tty_write+0x1a6/0x2d0 > > [] ? n_tty_open+0xe0/0xe0 > > [] __vfs_write+0x28/0xe0 > > [] ? preempt_count_add+0x85/0xd0 > > [] ? __fd_install+0x5e/0x110 > > [] ? __alloc_fd+0xc9/0x180 > > [] ? rw_verify_area+0x4f/0xe0 > > [] vfs_write+0x9a/0x170 > > [] SyS_write+0x46/0xb0 > > [] entry_SYSCALL_64_fastpath+0x12/0x66 > > Code: 8b 40 48 48 85 c0 74 07 55 48 89 e5 ff d0 5d c3 66 0f 1f 44 00 00 0f > > 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 9f 80 02 00 00 <48> 8b 83 80 > > 22 00 00 48 39 43 28 74 3a 4c 8d ab b0 22 00 00 49 > > RIP [] process_echoes+0x15/0x70 > > RSP > > CR2: 2280 > > ---[ end trace cec672c0d4b54e81 ]--- > > Kernel panic - not syncing: Fatal exception > > Kernel Offset: disabled > > ---[ end Kernel panic - not syncing: Fatal exception > > Yes, bisection would be great, if you can do it. I would blame the only > tty patch in the release, > tty-prevent-ldisc-drivers-from-re-using-stale-tty-fields.patch, but that > would be odd. > > Oops, nope, that would be it, the merge happened badly, I applied a > chunk in the wrong place, ugh. Let me go fix that patch up now... And that was because this patch was already merged in an older release, my fault. I've dropped it now, and pushed out an update, this should fix the problem. thanks, greg k-h
Re: [GIT PULL 0/7] perf/urgent callchain fixes
* Namhyung Kim wrote: > Hi Ingo, > > Please consider pulling the perf tooling changes below. Build tested > on Ubuntu, Fedora and Archlinux. I found a problem during `perf test` > but it seems unrelated to this series. Will take a look it later. > > Thanks, > Namhyung > > > The following changes since commit 88b0193d9418c00340e45e0a913a0813bc6c8c96: > > perf/callchain: Force USER_DS when invoking perf_callchain_user() > (2017-05-10 07:54:00 +0200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf > tags/perf-urgent-for-mingo-4.12-20170524 > > for you to fetch changes up to 37d4e1b6ba56773cef96122dff4436c2c534c381: > > perf tools: Fix to put caller above callee in children mode (2017-05-24 > 08:51:11 +0900) > > > perf/urgent fixes > > Fixes: > > - Fix segfault on `perf report -g srcline` if a callchain address >cannot find a map for some reason. The srcline sorting mode needs >a DSO to resolve line numbers and it's accessed via a map. But it >should check if map is available for the address first. (Milian Wolff) > > - Fix off-by-one for srcline output. It passed (unwound) address to >resolve srcline for callchains. But it's a return address of the >function which points to a next instruction. This leads to >off-by-one for srcline info. So pass the "address - 1" instead to >get the correct srcline. This also considers "signal frame" as >well which has the exact address, so pass the address directly in >this case. (Milian Wolff) > > - Fix missing inlined function. Current code missed to display >inlined functions at the end. This was found when comparing the >output of addr2line and perf script. (Milian Wolff) > > > User Visible: > > - `perf script` also gained `--inline` option to show inlined >functions with callchains. This helped to find a bug in the >current inline code. (Namhyung Kim) > > - Fix missed callchain ordering with `-g callee/caller` when libbfd >is not available. (Milian Wolff) > > - Reorder output entries in `perf report --children` so that it can >put parent entries above their children. It worked like this but >missed when callchain display order was changed with `-g caller`. >Now default is `-g caller` if children mode enabled. (Namhyung Kim) > > > > > Milian Wolff (5): > perf report: don't crash on invalid maps in `-g srcline` mode > perf report: fix memory leak in addr2line when called by addr2inlines > perf report: fix off-by-one for non-activation frames > perf report: always honor callchain order for inlined nodes > perf report: do not drop last inlined frame > > Namhyung Kim (2): > perf script: Add --inline option > perf tools: Fix to put caller above callee in children mode > > tools/perf/Documentation/perf-script.txt | 4 +++ > tools/perf/builtin-script.c | 2 ++ > tools/perf/ui/hist.c | 2 ++ > tools/perf/util/callchain.c | 13 ++--- > tools/perf/util/evsel_fprintf.c | 33 + > tools/perf/util/srcline.c| 49 > +--- > tools/perf/util/unwind-libdw.c | 6 +++- > tools/perf/util/unwind-libunwind-local.c | 11 +++ > 8 files changed, 92 insertions(+), 28 deletions(-) Thanks, I've applied the fixes from email with some minor tweaks to the changelogs. I also noticed that we now have a lot of warnings about out of sync headers: Warning: include/uapi/linux/stat.h differs from kernel Warning: arch/x86/include/asm/disabled-features.h differs from kernel Warning: arch/x86/include/asm/required-features.h differs from kernel Warning: arch/x86/include/asm/cpufeatures.h differs from kernel Warning: arch/x86/include/uapi/asm/kvm.h differs from kernel Warning: arch/x86/include/uapi/asm/vmx.h differs from kernel Warning: arch/powerpc/include/uapi/asm/kvm.h differs from kernel Warning: arch/s390/include/uapi/asm/kvm.h differs from kernel Warning: arch/arm/include/uapi/asm/kvm.h differs from kernel Warning: arch/arm64/include/uapi/asm/kvm.h differs from kernel ... will post a separate patch for that. Thanks, Ingo
Re: [lkp-robot] [sched/core] 1c3c5eab17: BUG:using_smp_processor_id()in_preemptible
On Wed, May 24, 2017 at 01:25:45PM +0800, kernel test robot wrote:
> [ 15.697784] BUG: using smp_processor_id() in preemptible [] code:
> swapper/0/1
> [ 15.698793] caller is debug_smp_processor_id+0x1c/0x1e
> [ 15.699461] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.12.0-rc2-00108-g1c3c5ea #1
> [ 15.700431] Call Trace:
> [ 15.700530] dump_stack+0x110/0x192
> [ 15.700530] check_preemption_disabled+0x10c/0x128
> [ 15.700530] ? set_debug_rodata+0x25/0x25
> [ 15.700530] debug_smp_processor_id+0x1c/0x1e
> [ 15.700530] sched_clock_init_late+0x27/0x87
> [ 15.700530] ? sched_init+0x4c6/0x4c6
> [ 15.700530] do_one_initcall+0xa3/0x1a7
> [ 15.700530] ? set_debug_rodata+0x25/0x25
> [ 15.700530] kernel_init_freeable+0x25e/0x304
> [ 15.700530] ? rest_init+0x29a/0x29a
> [ 15.700530] kernel_init+0x14/0x147
> [ 15.700530] ? rest_init+0x29a/0x29a
> [ 15.700530] ret_from_fork+0x31/0x40
> [ 15.707460] sched_clock: Marking stable (15707446101, 0)->(16254936915,
> -547490814)
This should fix I think...
---
Subject: sched/clock: Fix early boot preempt warning
The more strict early boot preemption warnings found that
__set_sched_clock_stable() was incorrectly assuming we'd still be
running on a single CPU.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/sched/clock.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index 1a0d389d2f2b..ca0f8fc945c6 100644
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -133,12 +133,19 @@ static void __scd_stamp(struct sched_clock_data *scd)
static void __set_sched_clock_stable(void)
{
- struct sched_clock_data *scd = this_scd();
+ struct sched_clock_data *scd;
/*
+* Since we're still unstable and the tick is already running, we have
+* to disable IRQs in order to get a consistent scd->tick* reading.
+*/
+ local_irq_disable();
+ scd = this_scd();
+ /*
* Attempt to make the (initial) unstable->stable transition continuous.
*/
__sched_clock_offset = (scd->tick_gtod + __gtod_offset) -
(scd->tick_raw);
+ local_irq_enable();
printk(KERN_INFO "sched_clock: Marking stable (%lld, %lld)->(%lld,
%lld)\n",
scd->tick_gtod, __gtod_offset,
Re: [PATCH 4.4 000/103] 4.4.70-stable review
On Tue, May 23, 2017 at 09:01:05PM -0700, Guenter Roeck wrote: > On 05/23/2017 01:08 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.70 release. > > There are 103 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu May 25 20:08:25 UTC 2017. > > Anything received after that time might be too late. > > > > Early feedback: All x86_64 images are crashing. Let me know if you need me to > bisect. > > Guenter > > --- > > ... > EXT4-fs (sda): re-mounted. Opts: errors=remount-ro,data=ordered > BUG: unable to handle kernel paging request at 2280 > IP: [] process_echoes+0x15/0x70 > PGD da68067 PUD d991067 PMD 0 > Oops: [#1] PREEMPT SMP > Modules linked in: > CPU: 0 PID: 400 Comm: bootlogd Not tainted 4.4.70-rc1-yocto-standard+ #1 > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS > rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014 > task: 88000d159bc0 ti: 88000d23 task.ti: 88000d23 > RIP: 0010:[] [] process_echoes+0x15/0x70 > RSP: 0018:88000d233d50 EFLAGS: 0202 > RAX: 88000dd950d8 RBX: RCX: 0007 > RDX: 88000dd4a400 RSI: 88000d91b700 RDI: 88000dd95000 > RBP: 88000d233d68 R08: 7000 R09: 88000eeb91c8 > R10: 7fffc9dc3f70 R11: 0246 R12: 0007 > R13: 00603574 R14: 0007 R15: 88000d91b700 > FS: 7f973601b700() GS:88000fc0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 2280 CR3: 0d953000 CR4: 003406f0 > Stack: > 88000dd95000 0007 00603574 88000d233df0 > 814515b7 00410022 88000d91b700 88000dd950d8 > 88000dd4a400 88000d91b700 88000d159bc0 > Call Trace: > [] n_tty_write+0x97/0x4e0 > [] ? __wake_up_sync+0x20/0x20 > [] tty_write+0x1a6/0x2d0 > [] ? n_tty_open+0xe0/0xe0 > [] __vfs_write+0x28/0xe0 > [] ? preempt_count_add+0x85/0xd0 > [] ? __fd_install+0x5e/0x110 > [] ? __alloc_fd+0xc9/0x180 > [] ? rw_verify_area+0x4f/0xe0 > [] vfs_write+0x9a/0x170 > [] SyS_write+0x46/0xb0 > [] entry_SYSCALL_64_fastpath+0x12/0x66 > Code: 8b 40 48 48 85 c0 74 07 55 48 89 e5 ff d0 5d c3 66 0f 1f 44 00 00 0f 1f > 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 9f 80 02 00 00 <48> 8b 83 80 22 00 > 00 48 39 43 28 74 3a 4c 8d ab b0 22 00 00 49 > RIP [] process_echoes+0x15/0x70 > RSP > CR2: 2280 > ---[ end trace cec672c0d4b54e81 ]--- > Kernel panic - not syncing: Fatal exception > Kernel Offset: disabled > ---[ end Kernel panic - not syncing: Fatal exception Yes, bisection would be great, if you can do it. I would blame the only tty patch in the release, tty-prevent-ldisc-drivers-from-re-using-stale-tty-fields.patch, but that would be odd. Oops, nope, that would be it, the merge happened badly, I applied a chunk in the wrong place, ugh. Let me go fix that patch up now... greg k-h
[PATCH 1/2] watchdog: uniphier: add UniPhier watchdog driver
Add a watchdog driver for Socionext UniPhier series SoC.
Note that the timeout value for this device must be a power
of 2 because of the specification.
Signed-off-by: Keiji Hayashibara
---
.../devicetree/bindings/watchdog/uniphier-wdt.txt | 20 ++
Documentation/watchdog/watchdog-parameters.txt | 6 +
drivers/watchdog/Kconfig | 11 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/uniphier_wdt.c| 273 +
5 files changed, 311 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt
create mode 100644 drivers/watchdog/uniphier_wdt.c
diff --git a/Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt
b/Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt
new file mode 100644
index 000..a59d1ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt
@@ -0,0 +1,20 @@
+UniPhier watchdog timer controller
+
+This UniPhier watchdog timer controller must be under sysctrl compatible node.
+
+Required properties:
+- compatible: should be "socionext,uniphier-wdt"
+
+Example:
+
+ sysctrl@6184 {
+ compatible = "socionext,uniphier-ld11-sysctrl",
+"simple-mfd", "syscon";
+ reg = <0x6184 0x4000>;
+
+ sys_wdt: watchdog {
+ compatible = "socionext,uniphier-wdt";
+ }
+
+ other nodes ...
+ };
diff --git a/Documentation/watchdog/watchdog-parameters.txt
b/Documentation/watchdog/watchdog-parameters.txt
index 4f7d86d..6f9d7b4 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -369,6 +369,12 @@ timeout: Watchdog timeout in seconds. (0
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* WDT timer setting register */
+#define WDTTIMSET 0x3004
+#define WDTTIMSET_PERIOD_MASK(0xf << 0)
+#define WDTTIMSET_PERIOD_1_SEC (0x3 << 0)
+#define WDTTIMSET_PERIOD_2_SEC (0x4 << 0)
+#define WDTTIMSET_PERIOD_4_SEC (0x5 << 0)
+#define WDTTIMSET_PERIOD_8_SEC (0x6 << 0)
+#define WDTTIMSET_PERIOD_16_SEC (0x7 << 0)
+#define WDTTIMSET_PERIOD_32_SEC (0x8 << 0)
+#define WDTTIMSET_PERIOD_64_SEC (0x9 << 0)
+#define WDTTIMSET_PERIOD_128_SEC (0xa << 0)
+
+/* WDT reset selection register */
+#define WDTRSTSEL 0x3008
+#define WDTRSTSEL_RSTSEL_MASK(0x3 << 0)
+#define WDTRSTSEL_RSTSEL_BOTH(0x0 << 0)
+#define WDTRSTSEL_RSTSEL_IRQ_ONLY(0x2 << 0)
+
+/* WDT control register */
+#define WDTCTRL0x300c
+#define WDTCTRL_STATUS BIT(8)
+#define WDTCTRL_CLEARBIT(1)
+#define WDTCTRL_ENABLE BIT(0)
+
+#define SEC_TO_WDTTIMSET_PRD(sec) \
+ (ilog2(sec) + WDTTIMSET_PERIOD_1_SEC)
+
+#define WDTST_TIMEOUT 1000 /* usec */
+
+#define WDT_DEFAULT_TIMEOUT64 /* Default is 64 seconds */
+#define WDT_PERIOD_MIN 1
+#define WDT_PERIOD_MAX 128
+
+static unsigned int timeout = WDT_DEFAULT_TIMEOUT;
+static bool nowayout = WATCHDOG_NOWAYOUT;
+
+struct uniphier_wdt_dev {
+ struct watchdog_device wdt_dev;
+ struct regmap *regmap;
+};
+
+/*
+ * UniPhier Watchdog operations
+ */
+static int uniphier_watchdog_ping(struct watchdog_device *w)
+{
+ struct uniphier_wdt_dev *wdev = watchdog_get_drvdata(w);
+
+ /* Clear counter */
+ return regmap_write(wdev->regmap, WDTCTRL,
+ WDTCTRL_CLEAR | WDTCTRL_ENABLE);
+}
+
+static int __uniphier_watchdog_start(struct regmap *regmap, unsigned int sec)
+{
+ int ret;
+
+ /* Setup period */
+ ret = regmap_write(regmap, WDTTIMSET,
+ SEC_TO_WDTTIMSET_PRD(sec));
+ if (ret)
+ return ret;
+
+ /* Enable and clear watchdog */
+ return regmap_write(regmap, WDTCTRL, WDTCTRL_ENABLE | WDTCTRL_CLEAR);
+}
+
+static int __uniphier_watchdog_stop(struct regmap *regmap)
+{
+ /* Disable and stop watchdog */
+ return regmap_write_bits(regmap, WDTCTRL, WDTCTRL_ENABLE, 0);
+}
+
+static int __uniphier_watchdog_restart(struct regmap *regmap, unsigned int sec)
+{
+ unsigned int val;
+ int ret;
+
+ ret = __uniphier_watchdog_stop(regmap);
+ if (ret)
+ return ret;
+
+ ret = regmap_read_poll_timeout(regmap, WDTCTRL, val,
+ !(val & WDTCTRL_STATUS),
+ 0, WDTST_TIMEOUT);
+ if (ret)
+ return ret;
+
+ return __uniphier_watchdog_start(regmap, sec);
+}
+
+static int uniphier_watchdog_start(struct watchdog_device *w)
+{
+ struct uniphier_wdt_dev *wdev = watchdog_get_drvdata(w);
+ unsign
[PATCH 2/2] arm64: dts: uniphier: add watchdog node for LD11 and LD20
Add nodes of watchdog timer for UniPhier LD11 and LD20 SoC.
The watchdog timer is included in sysctrl.
Signed-off-by: Keiji Hayashibara
---
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 4
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 4
2 files changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index da881f5..a3205dc 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -393,6 +393,10 @@
compatible = "socionext,uniphier-ld11-reset";
#reset-cells = <1>;
};
+
+ sys_wdt: watchdog {
+ compatible = "socionext,uniphier-wdt";
+ };
};
};
};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index a6b3a70..cd08a61 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -417,6 +417,10 @@
compatible = "socionext,uniphier-ld20-reset";
#reset-cells = <1>;
};
+
+ sys_wdt: watchdog {
+ compatible = "socionext,uniphier-wdt";
+ };
};
};
};
--
2.7.4
[PATCH 0/2] add UniPhier watchdog support
This series adds support for watchdog timer implemented on UniPhier LD11 and LD20 SoCs. This driver supports watchdog and system reset for SoCs. Keiji Hayashibara (2): watchdog: uniphier: add UniPhier watchdog driver arm64: dts: uniphier: add watchdog node for LD11 and LD20 .../devicetree/bindings/watchdog/uniphier-wdt.txt | 20 ++ Documentation/watchdog/watchdog-parameters.txt | 6 + arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 4 + arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 4 + drivers/watchdog/Kconfig | 11 + drivers/watchdog/Makefile | 1 + drivers/watchdog/uniphier_wdt.c| 273 + 7 files changed, 319 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt create mode 100644 drivers/watchdog/uniphier_wdt.c -- 2.7.4
Re: [PATCH] mm: Define KB, MB, GB, TB in core VM
On 05/23/2017 04:49 PM, Anshuman Khandual wrote: > On 05/23/2017 02:08 PM, Vlastimil Babka wrote: >> On 05/23/2017 09:02 AM, Christoph Hellwig wrote: >>> On Mon, May 22, 2017 at 02:11:49PM -0700, Andrew Morton wrote: On Mon, 22 May 2017 16:47:42 +0530 Anshuman Khandual wrote: > There are many places where we define size either left shifting integers > or multiplying 1024s without any generic definition to fall back on. But > there are couples of (powerpc and lz4) attempts to define these standard > memory sizes. Lets move these definitions to core VM to make sure that > all new usage come from these definitions eventually standardizing it > across all places. Grep further - there are many more definitions and some may now generate warnings. Newly including mm.h for these things seems a bit heavyweight. I can't immediately think of a more appropriate place. Maybe printk.h or kernel.h. >>> IFF we do these kernel.h is the right place. And please also add the >>> MiB & co variants for the binary versions right next to the decimal >>> ones. >> Those defined in the patch are binary, not decimal. Do we even need >> decimal ones? >> > > I can define KiB, MiB, with the same values as binary. > Did not get about the decimal ones, we need different names > for them holding values which are multiple of 1024 ? Now it seems little bit complicated than I initially thought. There are three different kind of definitions scattered across the tree. (1) Constant defines like these which can be unified across with little effort. +#define KB (1UL << 10) +#define MB (1UL << 20) +#define GB (1UL << 30) +#define TB (1UL << 40) (2) Function type defines like these which need to be renamed first because of the static defines already added above. #define KB(x) ((x) * 1024) #define MB(x) (KB(x) * 1024) Does these sound good as a rename ? +#define KBN(x) ((x) * KB) +#define MBN(x) ((x) * MB) +#define GBN(x) ((x) * GB) +#define TBN(x) ((x) * TB) And these need to be replaced across the tree. (3) Then there are many defines for MB, KB, GB which have nothing to do with memory size and they need to be changed as well to something else more appropriately to something they actually do. #define MB CRB * Defined inside arch/powerpc/xmon/ppc-opc.c #define GB(p,n,s) gf2k_get_bits(data, p, n, s) * Defined inside drivers/input/joystick/gf2k.c #define GB(pos,num) sw_get_bits(buf, pos, num, sw->bits) * Defined inside drivers/input/joystick/sidewinder.c So the question is are we willing to do all these changes across the tree to achieve common definitions of KB, MB, GB, TB in the kernel ? Is it worth ?
Re: [PATCH 4/7] perf script: Add --inline option
* Namhyung Kim wrote: > The --inline option is to show inlined functions in callchains. > > For example, > > $ perf script > a.out 5644 11611.467597: 309961 cycles:u: > 790 main (/home/namhyung/tmp/perf/a.out) >20511 __libc_start_main (/usr/lib/libc-2.25.so) > 8ba _start (/home/namhyung/tmp/perf/a.out) > ... > > $ perf script --inline > a.out 5644 11611.467597: 309961 cycles:u: > 790 main (/home/namhyung/tmp/perf/a.out) > > std::__detail::_Adaptor 16807ul, 0ul, 2147483647ul>, double>::operator() > > std::uniform_real_distribution::operator() long, 16807ul, 0ul, 2147483647ul> > > > std::uniform_real_distribution::operator() long, 16807ul, 0ul, 2147483647ul> > > main >20511 __libc_start_main (/usr/lib/libc-2.25.so) > 8ba _start (/home/namhyung/tmp/perf/a.out) > ... Shouldn't this be the default behavior, to make call chains more readable? Thanks, Ingo
Re: CHIPPro NAND issue with 4.12 rc1
On Tue, May 23, 2017 at 10:05:14PM -0600, Angus Ainslie wrote: > On 2017-05-23 13:52, Maxime Ripard wrote: > > > > Ok, good. > > > > If you unrevert those patches, and add clk_ignore_unused to the kernel > > command line, is it still broken? > > > > Maxime > > > If I use the clk_ignore_unused flag with the patches below then the kernel > can boot and mount the nand. > > diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.c > b/drivers/clk/sunxi-ng/ccu-sun5i.c > index 5c476f9..700944c 100644 > --- a/drivers/clk/sunxi-ng/ccu-sun5i.c > +++ b/drivers/clk/sunxi-ng/ccu-sun5i.c > @@ -251,7 +251,7 @@ static SUNXI_CCU_GATE(ahb_mmc1_clk, "ahb-mmc1", > "ahb", > static SUNXI_CCU_GATE(ahb_mmc2_clk,"ahb-mmc2", "ahb", > 0x060, BIT(10), 0); > static SUNXI_CCU_GATE(ahb_nand_clk,"ahb-nand", "ahb", > - 0x060, BIT(13), 0); > + 0x060, BIT(13), CLK_IS_CRITICAL); > static SUNXI_CCU_GATE(ahb_sdram_clk, "ahb-sdram","ahb", > 0x060, BIT(14), CLK_IS_CRITICAL); > static SUNXI_CCU_GATE(ahb_emac_clk,"ahb-emac", "ahb", That doesn't really make much sense, clk_ignore_unused and CLK_IS_CRITICAL are roughly doing the same thing Could you paste the whole kernel logs? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
[PATCH] KVM: x86: dynamically allocate large struct in em_fxrstor
Fixes the warning:
arch/x86/kvm/emulate.c:4018:12: warning: stack frame size of 1080 bytes in
function
'em_fxrstor' [-Wframe-larger-than=]
static int em_fxrstor(struct x86_emulate_ctxt *ctxt)
^
Found with CONFIG_FRAME_WARN set to 1024.
Signed-off-by: Nick Desaulniers
---
arch/x86/kvm/emulate.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 0816ab2e8adc..1d7c9ceeff56 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -4017,30 +4017,38 @@ static int fxrstor_fixup(struct x86_emulate_ctxt *ctxt,
static int em_fxrstor(struct x86_emulate_ctxt *ctxt)
{
- struct fxregs_state fx_state;
+ struct fxregs_state *fx_state;
int rc;
rc = check_fxsr(ctxt);
if (rc != X86EMUL_CONTINUE)
return rc;
- rc = segmented_read_std(ctxt, ctxt->memop.addr.mem, &fx_state, 512);
+ fx_state = kmalloc(sizeof(*fx_state), GFP_KERNEL);
+ if (!fx_state)
+ return -ENOMEM;
+
+ rc = segmented_read_std(ctxt, ctxt->memop.addr.mem, fx_state, 512);
if (rc != X86EMUL_CONTINUE)
- return rc;
+ goto out;
- if (fx_state.mxcsr >> 16)
- return emulate_gp(ctxt, 0);
+ if (fx_state->mxcsr >> 16) {
+ rc = emulate_gp(ctxt, 0);
+ goto out;
+ }
ctxt->ops->get_fpu(ctxt);
if (ctxt->mode < X86EMUL_MODE_PROT64)
- rc = fxrstor_fixup(ctxt, &fx_state);
+ rc = fxrstor_fixup(ctxt, fx_state);
if (rc == X86EMUL_CONTINUE)
- rc = asm_safe("fxrstor %[fx]", : [fx] "m"(fx_state));
+ rc = asm_safe("fxrstor %[fx]", : [fx] "m"(*fx_state));
ctxt->ops->put_fpu(ctxt);
+out:
+ kfree(fx_state);
return rc;
}
--
2.11.0
Re: [GIT PULL] x86/mm changes for v4.12
* Kirill A. Shutemov wrote:
> On Mon, May 01, 2017 at 02:00:53PM +0200, Ingo Molnar wrote:
> > - Continued Intel 5-level paging enablement: in particular the conversion
> >of x86 GUP to the generic GUP code. (Kirill A. Shutemov)
> >
> ...
> >
> > I'd like to draw special attention to this late MM commit:
> >
> > 71389703839e: mm, zone_device: Replace {get, put}_zone_device_page() with
> > a single reference to fix pmem crash
> >
> > ... which is a late fix, and which I believe is the right thing to do - but
> > please
> > double check.
>
> I've just noticied that the x86 GUP conversion haven't made it's way to
> v4.12: the fix got applied (71389703839e), but the final commit that does
> convertion keeped reverted -- 6dd29b3df975.
>
> I guess it's too late for v4.12...
>
> Ingo could you re-apply 2947ba054a4d ("x86/mm/gup: Switch GUP to the
> generic get_user_page_fast() implementation") to be queued to v4.13?
There were some late problems and I wanted x86/mm to be regression-free - we
don't
have all the 5-level paging patches applied yet so the exact cut we made at
v4.12
does not matter much - v4.13 is going to be the real deal.
Could you please make the re-application part of the remaining 5-level paging
patches?
Thanks,
Ingo
[PATCH 1/7] perf report: don't crash on invalid maps in `-g srcline` mode
From: Milian Wolff
I just hit a segfault when doing `perf report -g srcline`.
Valgrind pointed me at this code as the culprit:
==8359== Invalid read of size 8
==8359==at 0x3096D9: map__rip_2objdump (map.c:430)
==8359==by 0x2FC1A3: match_chain_srcline (callchain.c:645)
==8359==by 0x2FC1A3: match_chain (callchain.c:700)
==8359==by 0x2FC1A3: append_chain (callchain.c:895)
==8359==by 0x2FC1A3: append_chain_children (callchain.c:846)
==8359==by 0x2FF719: callchain_append (callchain.c:944)
==8359==by 0x2FF719: hist_entry__append_callchain (callchain.c:1058)
==8359==by 0x32FA06: iter_add_single_cumulative_entry (hist.c:908)
==8359==by 0x33195C: hist_entry_iter__add (hist.c:1050)
==8359==by 0x258F65: process_sample_event (builtin-report.c:204)
==8359==by 0x30D60C: perf_session__deliver_event (session.c:1310)
==8359==by 0x30D60C: ordered_events__deliver_event (session.c:119)
==8359==by 0x310D12: __ordered_events__flush (ordered-events.c:210)
==8359==by 0x310D12: ordered_events__flush.part.3 (ordered-events.c:277)
==8359==by 0x30DD3C: perf_session__process_user_event (session.c:1349)
==8359==by 0x30DD3C: perf_session__process_event (session.c:1475)
==8359==by 0x30FC3C: __perf_session__process_events (session.c:1867)
==8359==by 0x30FC3C: perf_session__process_events (session.c:1921)
==8359==by 0x25A985: __cmd_report (builtin-report.c:575)
==8359==by 0x25A985: cmd_report (builtin-report.c:1054)
==8359==by 0x2B9A80: run_builtin (perf.c:296)
==8359== Address 0x70 is not stack'd, malloc'd or (recently) free'd
This patch fixes the issue.
Cc: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Peter Zijlstra
Cc: Yao Jin
Signed-off-by: Milian Wolff
[namhy...@kernel.org: remove dependency from another change]
Signed-off-by: Namhyung Kim
---
tools/perf/util/callchain.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 81fc29ac798f..b4204b43ed58 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -621,14 +621,19 @@ enum match_result {
static enum match_result match_chain_srcline(struct callchain_cursor_node
*node,
struct callchain_list *cnode)
{
- char *left = get_srcline(cnode->ms.map->dso,
+ char *left = NULL;
+ char *right = NULL;
+ enum match_result ret = MATCH_EQ;
+ int cmp;
+
+ if (cnode->ms.map)
+ left = get_srcline(cnode->ms.map->dso,
map__rip_2objdump(cnode->ms.map, cnode->ip),
cnode->ms.sym, true, false);
- char *right = get_srcline(node->map->dso,
+ if (node->map)
+ right = get_srcline(node->map->dso,
map__rip_2objdump(node->map, node->ip),
node->sym, true, false);
- enum match_result ret = MATCH_EQ;
- int cmp;
if (left && right)
cmp = strcmp(left, right);
--
2.13.0
[PATCH 6/7] perf report: do not drop last inlined frame
From: Milian Wolff
The very last inlined frame, i.e. the one furthest away from the
non-inlined frame, was silently dropped. This is apparent when
comparing the output of `perf script` and `addr2line`:
~~
$ perf script --inline
...
a.out 26722 80836.309329: 72425 cycles:
21561 __hypot_finite (/usr/lib/libm-2.25.so)
ace3 hypot (/usr/lib/libm-2.25.so)
a4a main (a.out)
std::abs
std::_Norm_helper::_S_do_it
std::norm
main
20510 __libc_start_main (/usr/lib/libc-2.25.so)
bd9 _start (a.out)
$ addr2line -a -f -i -e /tmp/a.out a4a | c++filt
0x0a4a
std::__complex_abs(doublecomplex )
/usr/include/c++/6.3.1/complex:589
double std::abs(std::complex const&)
/usr/include/c++/6.3.1/complex:597
double std::_Norm_helper::_S_do_it(std::complex const&)
/usr/include/c++/6.3.1/complex:654
double std::norm(std::complex const&)
/usr/include/c++/6.3.1/complex:664
main
/tmp/inlining.cpp:14
~
Note how `std::__complex_abs` is missing from the `perf script`
output. This is similarly showing up in `perf report`. The patch
here fixes this issue, and the output becomes:
~
a.out 26722 80836.309329: 72425 cycles:
21561 __hypot_finite (/usr/lib/libm-2.25.so)
ace3 hypot (/usr/lib/libm-2.25.so)
a4a main (a.out)
std::__complex_abs
std::abs
std::_Norm_helper::_S_do_it
std::norm
main
20510 __libc_start_main (/usr/lib/libc-2.25.so)
bd9 _start (a.out)
~
Cc: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Peter Zijlstra
Cc: Yao Jin
Signed-off-by: Milian Wolff
Signed-off-by: Namhyung Kim
---
tools/perf/util/srcline.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index 6af0364cad06..ebc88a74e67b 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -203,6 +203,16 @@ static void addr2line_cleanup(struct a2l_data *a2l)
#define MAX_INLINE_NEST 1024
+static int inline_list__append_dso_a2l(struct dso *dso,
+ struct inline_node *node)
+{
+ struct a2l_data *a2l = dso->a2l;
+ char *funcname = a2l->funcname ? strdup(a2l->funcname) : NULL;
+ char *filename = a2l->filename ? strdup(a2l->filename) : NULL;
+
+ return inline_list__append(filename, funcname, a2l->line, node, dso);
+}
+
static int addr2line(const char *dso_name, u64 addr,
char **file, unsigned int *line, struct dso *dso,
bool unwind_inlines, struct inline_node *node)
@@ -231,15 +241,15 @@ static int addr2line(const char *dso_name, u64 addr,
if (unwind_inlines) {
int cnt = 0;
+ if (node && inline_list__append_dso_a2l(dso, node))
+ return 0;
+
while (bfd_find_inliner_info(a2l->abfd, &a2l->filename,
&a2l->funcname, &a2l->line) &&
cnt++ < MAX_INLINE_NEST) {
if (node != NULL) {
- if (inline_list__append(strdup(a2l->filename),
- strdup(a2l->funcname),
- a2l->line, node,
- dso) != 0)
+ if (inline_list__append_dso_a2l(dso, node))
return 0;
// found at least one inline frame
ret = 1;
--
2.13.0
[PATCH 7/7] perf tools: Fix to put caller above callee in children mode
The __hpp__sort_acc() sorts entries using callchain depth in order to put callers above in children mode. But it assumed the callchain order was callee-first. Now default (for children) is caller-first so the order of entries is reverted. For example, consider following case. $ perf report --no-children ..l # Overhead Command Shared ObjectSymbol # ... ... .. # 99.44% a.outa.out[.] main | ---main __libc_start_main _start Then children mode should show 'start' above '__libc_start_main' since it's the caller (parent) of the __libc_start_main. But it's reversed: # Children Self Command Shared ObjectSymbol # ... ... . # 99.61% 0.00% a.outlibc-2.25.so [.] __libc_start_main 99.61% 0.00% a.outa.out[.] _start 99.54%99.44% a.outa.out[.] main This patch fixes it. # Children Self Command Shared ObjectSymbol # ... ... . # 99.61% 0.00% a.outa.out[.] _start 99.61% 0.00% a.outlibc-2.25.so [.] __libc_start_main 99.54%99.44% a.outa.out[.] main Cc: Frederic Weisbecker Cc: Milian Wolff Acked-by: Jiri Olsa Signed-off-by: Namhyung Kim --- tools/perf/ui/hist.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c index 59addd52d9cd..ddb2c6fbdf91 100644 --- a/tools/perf/ui/hist.c +++ b/tools/perf/ui/hist.c @@ -210,6 +210,8 @@ static int __hpp__sort_acc(struct hist_entry *a, struct hist_entry *b, return 0; ret = b->callchain->max_depth - a->callchain->max_depth; + if (callchain_param.order == ORDER_CALLER) + ret = -ret; } return ret; } -- 2.13.0
[PATCH 4/7] perf script: Add --inline option
The --inline option is to show inlined functions in callchains.
For example,
$ perf script
a.out 5644 11611.467597: 309961 cycles:u:
790 main (/home/namhyung/tmp/perf/a.out)
20511 __libc_start_main (/usr/lib/libc-2.25.so)
8ba _start (/home/namhyung/tmp/perf/a.out)
...
$ perf script --inline
a.out 5644 11611.467597: 309961 cycles:u:
790 main (/home/namhyung/tmp/perf/a.out)
std::__detail::_Adaptor, double>::operator()
std::uniform_real_distribution::operator() >
std::uniform_real_distribution::operator() >
main
20511 __libc_start_main (/usr/lib/libc-2.25.so)
8ba _start (/home/namhyung/tmp/perf/a.out)
...
Cc: Jin Yao
Reviewed-and-tested-by: Milian Wolff
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-script.txt | 4
tools/perf/builtin-script.c | 2 ++
tools/perf/util/evsel_fprintf.c | 33
3 files changed, 39 insertions(+)
diff --git a/tools/perf/Documentation/perf-script.txt
b/tools/perf/Documentation/perf-script.txt
index cb0eda3925e6..3517e204a2b3 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -311,6 +311,10 @@ include::itrace.txt[]
Set the maximum number of program blocks to print with brstackasm for
each sample.
+--inline::
+ If a callgraph address belongs to an inlined function, the inline stack
+ will be printed. Each entry has function name and file/line.
+
SEE ALSO
linkperf:perf-record[1], linkperf:perf-script-perl[1],
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index d05aec491cff..4761b0d7fcb5 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -2494,6 +2494,8 @@ int cmd_script(int argc, const char **argv)
"Enable kernel symbol demangling"),
OPT_STRING(0, "time", &script.time_str, "str",
"Time span of interest (start,stop)"),
+ OPT_BOOLEAN(0, "inline", &symbol_conf.inline_name,
+ "Show inline function"),
OPT_END()
};
const char * const script_subcommands[] = { "record", "report", NULL };
diff --git a/tools/perf/util/evsel_fprintf.c b/tools/perf/util/evsel_fprintf.c
index e415aee6a245..583f3a602506 100644
--- a/tools/perf/util/evsel_fprintf.c
+++ b/tools/perf/util/evsel_fprintf.c
@@ -7,6 +7,7 @@
#include "map.h"
#include "strlist.h"
#include "symbol.h"
+#include "srcline.h"
static int comma_fprintf(FILE *fp, bool *first, const char *fmt, ...)
{
@@ -168,6 +169,38 @@ int sample__fprintf_callchain(struct perf_sample *sample,
int left_alignment,
if (!print_oneline)
printed += fprintf(fp, "\n");
+ if (symbol_conf.inline_name && node->map) {
+ struct inline_node *inode;
+
+ addr = map__rip_2objdump(node->map, node->ip),
+ inode = dso__parse_addr_inlines(node->map->dso,
addr);
+
+ if (inode) {
+ struct inline_list *ilist;
+
+ list_for_each_entry(ilist, &inode->val,
list) {
+ if (print_arrow)
+ printed += fprintf(fp,
" <-");
+
+ /* IP is same, just skip it */
+ if (print_ip)
+ printed += fprintf(fp,
"%c%16s",
+ s,
"");
+ if (print_sym)
+ printed += fprintf(fp,
" %s",
+
ilist->funcname);
+ if (print_srcline)
+ printed += fprintf(fp,
"\n %s:%d",
+
ilist->filename,
+
ilist->line_nr);
+ if (!print_oneline)
+ printed += fprintf(fp,
"\n");
+ }
+
+ inline_node__delete(inode);
+ }
+ }
+
if (symbol_conf.bt_stop_list &&
node->sym &&
[PATCH 3/7] perf report: fix off-by-one for non-activation frames
From: Milian Wolff
As the documentation for dwfl_frame_pc says, frames that
are no activation frames need to have their program counter
decremented by one to properly find the function of the caller.
This fixes many cases where perf report currently attributes
the cost to the next line. I.e. I have code like this:
~~~
#include
#include
using namespace std;
int main()
{
this_thread::sleep_for(chrono::milliseconds(1000));
this_thread::sleep_for(chrono::milliseconds(100));
this_thread::sleep_for(chrono::milliseconds(10));
return 0;
}
~~~
Now compile and record it:
~~~
g++ -std=c++11 -g -O2 test.cpp
echo 1 | sudo tee /proc/sys/kernel/sched_schedstats
perf record \
--event sched:sched_stat_sleep \
--event sched:sched_process_exit \
--event sched:sched_switch --call-graph=dwarf \
--output perf.data.raw \
./a.out
echo 0 | sudo tee /proc/sys/kernel/sched_schedstats
perf inject --sched-stat --input perf.data.raw --output perf.data
~~~
Before this patch, the report clearly shows the off-by-one issue.
Most notably, the last sleep invocation is incorrectly attributed
to the "return 0;" line:
~~~
Overhead Source:Line
...
100.00% core.c:0
|
---__schedule core.c:0
schedule
do_nanosleep hrtimer.c:0
hrtimer_nanosleep
sys_nanosleep
entry_SYSCALL_64_fastpath .tmp_entry_64.o:0
__nanosleep_nocancel .:0
std::this_thread::sleep_for >
thread:323
|
|--90.08%--main test.cpp:9
| __libc_start_main
| _start
|
|--9.01%--main test.cpp:10
| __libc_start_main
| _start
|
--0.91%--main test.cpp:13
__libc_start_main
_start
~~~
With this patch here applied, the issue is fixed. The report becomes
much more usable:
~~~
Overhead Source:Line
...
100.00% core.c:0
|
---__schedule core.c:0
schedule
do_nanosleep hrtimer.c:0
hrtimer_nanosleep
sys_nanosleep
entry_SYSCALL_64_fastpath .tmp_entry_64.o:0
__nanosleep_nocancel .:0
std::this_thread::sleep_for >
thread:323
|
|--90.08%--main test.cpp:8
| __libc_start_main
| _start
|
|--9.01%--main test.cpp:9
| __libc_start_main
| _start
|
--0.91%--main test.cpp:10
__libc_start_main
_start
~~~
Similarly it works for signal frames:
~~~
__noinline void bar(void)
{
volatile long cnt = 0;
for (cnt = 0; cnt < 1; cnt++);
}
__noinline void foo(void)
{
bar();
}
void sig_handler(int sig)
{
foo();
}
int main(void)
{
signal(SIGUSR1, sig_handler);
raise(SIGUSR1);
foo();
return 0;
}
Before, the report wrongly points to `signal.c:29` after raise():
$ perf report --stdio --no-children -g srcline -s srcline
...
100.00% signal.c:11
|
---bar signal.c:11
|
|--50.49%--main signal.c:29
| __libc_start_main
| _start
|
--49.51%--0x33a8f
raise .:0
main signal.c:29
__libc_start_main
_start
With this patch in, the issue is fixed and we instead get:
100.00% signal signal[.] bar
|
---bar signal.c:11
|
|--50.49%--main signal.c:29
| __libc_start_main
| _start
|
--49.51%--0x33a8f
raise .:0
main signal.c:27
__libc_start_main
_start
Note how this patch fixes this issue for both unwinding methods, i.e.
both dwfl and libunwind. The former case is straight-forward thanks
to dwfl_frame_pc. For libunwind, we replace the functionality via
unw_is_signal_frame for any but the very first frame.
Cc: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Peter Zijlstra
Cc: Yao Jin
Signed-off-by: Milian Wolff
Signed-off-by: Namhyung Kim
---
tools/perf/util/unwind-libdw.c | 6 +-
tools/perf/util/unwind-libunwind-local.c | 11 +++
2 files changed, 16 insertions(+), 1 deletion(-)
diff -
[PATCH 2/7] perf report: fix memory leak in addr2line when called by addr2inlines
From: Milian Wolff
When a filename was found in addr2line it was duplicated via strdup
but never freed. Now we pass NULL and handle this gracefully in
addr2line.
Detected by Valgrind:
==16331== 1,680 bytes in 21 blocks are definitely lost in loss record 148 of 220
==16331==at 0x4C2AF1F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16331==by 0x672FA69: strdup (in /usr/lib/libc-2.25.so)
==16331==by 0x52769F: addr2line (srcline.c:256)
==16331==by 0x52769F: addr2inlines (srcline.c:294)
==16331==by 0x52769F: dso__parse_addr_inlines (srcline.c:502)
==16331==by 0x574D7A: inline__fprintf (hist.c:41)
==16331==by 0x574D7A: ipchain__fprintf_graph (hist.c:147)
==16331==by 0x57518A: __callchain__fprintf_graph (hist.c:212)
==16331==by 0x5753CF: callchain__fprintf_graph.constprop.6 (hist.c:337)
==16331==by 0x57738E: hist_entry__fprintf (hist.c:628)
==16331==by 0x57738E: hists__fprintf (hist.c:882)
==16331==by 0x44A20F: perf_evlist__tty_browse_hists (builtin-report.c:399)
==16331==by 0x44A20F: report__browse_hists (builtin-report.c:491)
==16331==by 0x44A20F: __cmd_report (builtin-report.c:624)
==16331==by 0x44A20F: cmd_report (builtin-report.c:1054)
==16331==by 0x4A49CE: run_builtin (perf.c:296)
==16331==by 0x4A4CC0: handle_internal_command (perf.c:348)
==16331==by 0x434371: run_argv (perf.c:392)
==16331==by 0x434371: main (perf.c:530)
Cc: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Peter Zijlstra
Cc: Yao Jin
Signed-off-by: Milian Wolff
Signed-off-by: Namhyung Kim
---
tools/perf/util/srcline.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index df051a52393c..5e376d64d59e 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -230,7 +230,10 @@ static int addr2line(const char *dso_name, u64 addr,
bfd_map_over_sections(a2l->abfd, find_address_in_section, a2l);
- if (a2l->found && unwind_inlines) {
+ if (!a2l->found)
+ return 0;
+
+ if (unwind_inlines) {
int cnt = 0;
while (bfd_find_inliner_info(a2l->abfd, &a2l->filename,
@@ -243,6 +246,8 @@ static int addr2line(const char *dso_name, u64 addr,
a2l->line, node,
dso) != 0)
return 0;
+ // found at least one inline frame
+ ret = 1;
}
}
@@ -252,14 +257,14 @@ static int addr2line(const char *dso_name, u64 addr,
}
}
- if (a2l->found && a2l->filename) {
- *file = strdup(a2l->filename);
- *line = a2l->line;
-
- if (*file)
- ret = 1;
+ if (file) {
+ *file = a2l->filename ? strdup(a2l->filename) : NULL;
+ ret = *file ? 1 : 0;
}
+ if (line)
+ *line = a2l->line;
+
return ret;
}
@@ -278,8 +283,6 @@ void dso__free_a2l(struct dso *dso)
static struct inline_node *addr2inlines(const char *dso_name, u64 addr,
struct dso *dso)
{
- char *file = NULL;
- unsigned int line = 0;
struct inline_node *node;
node = zalloc(sizeof(*node));
@@ -291,7 +294,7 @@ static struct inline_node *addr2inlines(const char
*dso_name, u64 addr,
INIT_LIST_HEAD(&node->val);
node->addr = addr;
- if (!addr2line(dso_name, addr, &file, &line, dso, TRUE, node))
+ if (!addr2line(dso_name, addr, NULL, NULL, dso, TRUE, node))
goto out_free_inline_node;
if (list_empty(&node->val))
--
2.13.0
[GIT PULL 0/7] perf/urgent callchain fixes
Hi Ingo, Please consider pulling the perf tooling changes below. Build tested on Ubuntu, Fedora and Archlinux. I found a problem during `perf test` but it seems unrelated to this series. Will take a look it later. Thanks, Namhyung The following changes since commit 88b0193d9418c00340e45e0a913a0813bc6c8c96: perf/callchain: Force USER_DS when invoking perf_callchain_user() (2017-05-10 07:54:00 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf tags/perf-urgent-for-mingo-4.12-20170524 for you to fetch changes up to 37d4e1b6ba56773cef96122dff4436c2c534c381: perf tools: Fix to put caller above callee in children mode (2017-05-24 08:51:11 +0900) perf/urgent fixes Fixes: - Fix segfault on `perf report -g srcline` if a callchain address cannot find a map for some reason. The srcline sorting mode needs a DSO to resolve line numbers and it's accessed via a map. But it should check if map is available for the address first. (Milian Wolff) - Fix off-by-one for srcline output. It passed (unwound) address to resolve srcline for callchains. But it's a return address of the function which points to a next instruction. This leads to off-by-one for srcline info. So pass the "address - 1" instead to get the correct srcline. This also considers "signal frame" as well which has the exact address, so pass the address directly in this case. (Milian Wolff) - Fix missing inlined function. Current code missed to display inlined functions at the end. This was found when comparing the output of addr2line and perf script. (Milian Wolff) User Visible: - `perf script` also gained `--inline` option to show inlined functions with callchains. This helped to find a bug in the current inline code. (Namhyung Kim) - Fix missed callchain ordering with `-g callee/caller` when libbfd is not available. (Milian Wolff) - Reorder output entries in `perf report --children` so that it can put parent entries above their children. It worked like this but missed when callchain display order was changed with `-g caller`. Now default is `-g caller` if children mode enabled. (Namhyung Kim) Milian Wolff (5): perf report: don't crash on invalid maps in `-g srcline` mode perf report: fix memory leak in addr2line when called by addr2inlines perf report: fix off-by-one for non-activation frames perf report: always honor callchain order for inlined nodes perf report: do not drop last inlined frame Namhyung Kim (2): perf script: Add --inline option perf tools: Fix to put caller above callee in children mode tools/perf/Documentation/perf-script.txt | 4 +++ tools/perf/builtin-script.c | 2 ++ tools/perf/ui/hist.c | 2 ++ tools/perf/util/callchain.c | 13 ++--- tools/perf/util/evsel_fprintf.c | 33 + tools/perf/util/srcline.c| 49 +--- tools/perf/util/unwind-libdw.c | 6 +++- tools/perf/util/unwind-libunwind-local.c | 11 +++ 8 files changed, 92 insertions(+), 28 deletions(-)
[PATCH 5/7] perf report: always honor callchain order for inlined nodes
From: Milian Wolff
So far, the inlined nodes where only reversed when we built perf
against libbfd. If that was not available, the addr2line fallback
code path was missing the inline_list__reverse call.
Now we always add the nodes in the correct order within
inline_list__append. This removes the need to reverse the list
and also ensures that all callers construct the list in the right
order.
Cc: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Peter Zijlstra
Cc: Yao Jin
Signed-off-by: Milian Wolff
Signed-off-by: Namhyung Kim
---
tools/perf/util/srcline.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index 5e376d64d59e..6af0364cad06 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -56,7 +56,10 @@ static int inline_list__append(char *filename, char
*funcname, int line_nr,
}
}
- list_add_tail(&ilist->list, &node->val);
+ if (callchain_param.order == ORDER_CALLEE)
+ list_add_tail(&ilist->list, &node->val);
+ else
+ list_add(&ilist->list, &node->val);
return 0;
}
@@ -200,14 +203,6 @@ static void addr2line_cleanup(struct a2l_data *a2l)
#define MAX_INLINE_NEST 1024
-static void inline_list__reverse(struct inline_node *node)
-{
- struct inline_list *ilist, *n;
-
- list_for_each_entry_safe_reverse(ilist, n, &node->val, list)
- list_move_tail(&ilist->list, &node->val);
-}
-
static int addr2line(const char *dso_name, u64 addr,
char **file, unsigned int *line, struct dso *dso,
bool unwind_inlines, struct inline_node *node)
@@ -250,11 +245,6 @@ static int addr2line(const char *dso_name, u64 addr,
ret = 1;
}
}
-
- if ((node != NULL) &&
- (callchain_param.order != ORDER_CALLEE)) {
- inline_list__reverse(node);
- }
}
if (file) {
--
2.13.0
Re: [Ocfs2-devel] [PATCH v2] ocfs2: fix a static checker warning
On 05/23/2017 01:17 PM, Gang He wrote:
This patch will fix a static code checker warning, which looks
like below,
fs/ocfs2/inode.c:179 ocfs2_iget()
warn: passing zero to 'ERR_PTR'
this warning was caused by the
commit d56a8f32e4c6 ("ocfs2: check/fix inode block for online file check").
after apply this patch, the error return value will not be NULL(zero).
Signed-off-by: Gang He
Looks good to me.
Reviewed-by: Eric Ren
---
fs/ocfs2/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c
index 382401d..1a1e007 100644
--- a/fs/ocfs2/inode.c
+++ b/fs/ocfs2/inode.c
@@ -136,7 +136,7 @@ struct inode *ocfs2_ilookup(struct super_block *sb, u64
blkno)
struct inode *ocfs2_iget(struct ocfs2_super *osb, u64 blkno, unsigned flags,
int sysfile_type)
{
- int rc = 0;
+ int rc = -ESTALE;
struct inode *inode = NULL;
struct super_block *sb = osb->sb;
struct ocfs2_find_inode_args args;
Re: [WARNING] x86/mm: Found insecure W+X mapping at address ..
On Tue, 23 May 2017, Steven Rostedt wrote: > On Tue, 23 May 2017 22:48:19 +0200 (CEST) > Thomas Gleixner wrote: > > > > It's not KPROBES, it's the new fangled ftrace trampoline code. I > > added a few printks. All the leaked W+X mappings are allocated via > > this callchain: > > The trampoline code isn't new. But it has new users because of the > introduction to synchronize_rcu_tasks(), and there was a bug I fixed in > -rc2 that moved it down because the test was run before > synchronize_rcu_tasks() was functional. > > Is this still a bug in rc2? Yes. Otherwise we wouldn't talking about. Thanks, tglx
Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption
On Mon, May 22, 2017 at 05:00:29PM +0300, Andrey Ryabinin wrote: > > > On 05/19/2017 04:53 AM, Joonsoo Kim wrote: > > On Wed, May 17, 2017 at 03:17:13PM +0300, Andrey Ryabinin wrote: > >> On 05/16/2017 04:16 AM, js1...@gmail.com wrote: > >>> From: Joonsoo Kim > >>> > >>> Hello, all. > >>> > >>> This is an attempt to recude memory consumption of KASAN. Please see > >>> following description to get the more information. > >>> > >>> 1. What is per-page shadow memory > >>> > >>> This patch introduces infrastructure to support per-page shadow memory. > >>> Per-page shadow memory is the same with original shadow memory except > >>> the granualarity. It's one byte shows the shadow value for the page. > >>> The purpose of introducing this new shadow memory is to save memory > >>> consumption. > >>> > >>> 2. Problem of current approach > >>> > >>> Until now, KASAN needs shadow memory for all the range of the memory > >>> so the amount of statically allocated memory is so large. It causes > >>> the problem that KASAN cannot run on the system with hard memory > >>> constraint. Even if KASAN can run, large memory consumption due to > >>> KASAN changes behaviour of the workload so we cannot validate > >>> the moment that we want to check. > >>> > >>> 3. How does this patch fix the problem > >>> > >>> This patch tries to fix the problem by reducing memory consumption for > >>> the shadow memory. There are two observations. > >>> > >> > >> > >> I think that the best way to deal with your problem is to increase shadow > >> scale size. > >> > >> You'll need to add tunable to gcc to control shadow size. I expect that > >> gcc has some > >> places where 8-shadow scale size is hardcoded, but it should be fixable. > >> > >> The kernel also have some small amount of code written with > >> KASAN_SHADOW_SCALE_SIZE == 8 in mind, > >> which should be easy to fix. > >> > >> Note that bigger shadow scale size requires bigger alignment of allocated > >> memory and variables. > >> However, according to comments in gcc/asan.c gcc already aligns stack and > >> global variables and at > >> 32-bytes boundary. > >> So we could bump shadow scale up to 32 without increasing current stack > >> consumption. > >> > >> On a small machine (1Gb) 1/32 of shadow is just 32Mb which is comparable > >> to yours 30Mb, but I expect it to be > >> much faster. More importantly, this will require only small amount of > >> simple changes in code, which will be > >> a *lot* more easier to maintain. > > > > I agree that it is also a good option to reduce memory consumption. > > Nevertheless, there are two reasons that justifies this patchset. > > > > 1) With this patchset, memory consumption isn't increased in > > proportional to total memory size. Please consider my 4Gb system > > example on the below. With increasing shadow scale size to 32, memory > > would be consumed by 128M. However, this patchset consumed 50MB. This > > difference can be larger if we run KASAN with bigger machine. > > > > Well, yes, but I assume that bigger machine implies that we can use more > memory without > causing a significant change in system's behavior. In common case, yes. But, I guess that there is a system that statically uses most of memory and just a few memory is left for others. For example, consider 64GB system and some program (DB?) runs with using 60GB. Only 4GB left. If KASAN uses 2GB, just 2GB is left and it would cause the problem. So, I'd like to insist that this merit 1) should be considered as valuable. > > > 2) These two optimization can be applied simulatenously. It is just an > > orthogonal feature. If shadow scale size is increased to 32, memory > > consumption will be decreased in case of my patchset, too. > > > > Therefore, I think that this patchset is useful in any case. > > These are valid points, but IMO it's not enough to justify this patchset. > Too much of hacky and fragile code. > > If our goal is to make KASAN to eat less memory, the first step definitely > would be a 1/32 shadow. > Simply because it's the best way to achieve that goal. > And only if it's not enough we could think about something else, like > decreasing/turning off quarantine > and/or smaller redzones. Please refer the reply to Dmitry. I think that we need an option that everything else than something compulsory is the same with non-KASAN build as much as possible. 1/32 scale would change object layout so it will not work for this option. Thanks.
[PATCH v3] ARM: dts: mvebu: add support for Linksys WRT3200ACM (Rango)
The Linksys WRT3200ACM (Rango) is the lates Armada-385 based router in the Linksys WRT AC Series which got released in October 2016. Key differences to the earlier Armada-385 based devices in the series is a bigger flash chip, next generation wireless modules (Marvell 88W8964) in the mini pcie slots as well as a Marvell SD8887. Finally the CPU is clocked at 1866 GHz by default. The file armada-385-linksys-rango.dts is loosly based off of a DTS authored by Imre Kaloz. As Rango is part of the armada-385-linksys family of boards use the armada-385-linksys.dtsi as basis. As for functional differences to Imre Kaloz dts, the wlan LEDs aren't connected to the expander chip pca9635 but directly to GPIOs. Then mpp47 controls the USB2.0 port and not the USB3.0 port, so use the correct GPIO mpp44 for it. Finally use non-removable instead of broken-cd with the sdhci node to avoid polling. Other changes can be categorized as just cleanup / reorganization due to using the armada-385-linksys.dtsi. URL: https://github.com/openwrt/openwrt/blob/0abc3fa5a996daf7dafdc7794ccfe3fa7e955c5a/target/linux/mvebu/files/arch/arm/boot/dts/armada-385-linksys-rango.dts Signed-off-by: Ralph Sennhauser Signed-off-by: Imre Kaloz --- Hi everyone, this patch was part of a series adding support for this device, the preparatory patches all got merged already except for "clk: mvebu: add support for 1866MHz variants" which isn't strictly required for the board to run and was sent to linux-clk for inclusion. Thanks Ralph --- Changes since v1: - Update commit message - Add collected tags (Imre) Changes sice v2: - Really use non-removable for the sdhci node --- Original notes: The sdhci node is taken as is, the current node lets one use the wireless part of the attached sd8887. There is an issue with the initalization of the bluetooth firmware though. Haven't had the time to investigate that in depth so far but shouldn't hold up the Rango addition. The non-removable property might be more appropriate than broken-cd though. Checkpatch complains about the line length of the URL, though not much room there. Checkpatch also complains about the vendor prefix linksys not being documented, however this follows the examples given by the other boards. --- arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/armada-385-linksys-rango.dts | 203 + 2 files changed, 204 insertions(+) create mode 100644 arch/arm/boot/dts/armada-385-linksys-rango.dts diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 9c5e1d9..6be2974 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -999,6 +999,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \ armada-385-db-ap.dtb \ armada-385-linksys-caiman.dtb \ armada-385-linksys-cobra.dtb \ + armada-385-linksys-rango.dtb \ armada-385-linksys-shelby.dtb \ armada-385-synology-ds116.dtb \ armada-385-turris-omnia.dtb \ diff --git a/arch/arm/boot/dts/armada-385-linksys-rango.dts b/arch/arm/boot/dts/armada-385-linksys-rango.dts new file mode 100644 index 000..da8a0f3 --- /dev/null +++ b/arch/arm/boot/dts/armada-385-linksys-rango.dts @@ -0,0 +1,203 @@ +/* + * Device Tree file for the Linksys WRT3200ACM (Rango) + * + * Copyright (C) 2016 Imre Kaloz + * + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without + * any warranty of any kind, whether express or implied. + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */
Re: [PATCH v2] ARM: dts: mvebu: add support for Linksys WRT3200ACM (Rango)
On Wed, 24 May 2017 03:37:53 +0200
Andrew Lunn wrote:
> Hi Ralph
>
> > Changes since v1:
> >
> > - Use non-removable with the sdhci node
>
> ..
>
> > +
> > +&sdhci {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&sdhci_pins>;
> > + no-1-8-v;
> > + broken-cd;
> > + wp-inverted;
> > + bus-width = <8>;
> > + status = "okay";
> > +};
>
> ???
>
> Andrew
Arg, forgot to squash the --fixup for this one
Ralph
RE: [PATCH 1/2] net: phy: Update get_phy_c45_ids for Cortina PHYs
> -Original Message- > From: Florian Fainelli [mailto:f.faine...@gmail.com] > Sent: Tuesday, May 23, 2017 9:12 PM > To: Andrew Lunn ; Bogdan Purcareata > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 1/2] net: phy: Update get_phy_c45_ids for Cortina PHYs > > On 05/23/2017 09:55 AM, Andrew Lunn wrote: > >> The patches mentioned in the commit message add _some_ support for > >> the Cortina PHYs - mainly checking for devices at additional > >> locations. Once they are found, the phy IDs must be read from custom > >> locations. > > > > As a general principle, we don't add hacks in generic code to handle > > broken devices. We add generic mechanisms to work around the > > brokenness. > > > > In this case, by using ethernet-phy-id in the device tree, we are > > saying, this PHYs probing is totally borked, but we know it is there, > > at this address. Just load the driver. > > > > Please try to make ethernet-phy-id work. > > What Andrew is suggesting is to leverage the code in > drivers/of/of_mdio.c which does the following: > >is_c45 = of_device_is_compatible(child, > "ethernet-phy-ieee802.3-c45"); > > if (!is_c45 && !of_get_phy_id(child, &phy_id)) > phy = phy_device_create(mdio, addr, phy_id, 0, NULL); > else > phy = get_phy_device(mdio, addr, is_c45); > if (IS_ERR(phy)) > return; > > If you know the PHY ID, and you did put it in the PHY node's compatible > string (in the format that of_get_phy_id() expects it to, and you also > did not add "ethernet-phy-ieee802.3-c45") then the PHY library will > directly create the PHY device, with the designated ID, at the specific > address. > > While this works for clause 22 PHYs, I don't know if it also does for > clause 45 PHYs, but as Andrew is suggesting, I would be more inclined > into making this scheme work for all types (22 or 45) PHYs, rather than > hacking the core code that tries to identify devices in packages. > > Can you give it a spin? Sure. My first thought was to latch onto the codepath that had some mention of Cortina PHYs. I will check of_get_phy_id() and see if it does the job. Thank you! Bogdan
Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption
On Mon, May 22, 2017 at 08:02:36AM +0200, Dmitry Vyukov wrote: > On Fri, May 19, 2017 at 3:53 AM, Joonsoo Kim wrote: > > On Wed, May 17, 2017 at 03:17:13PM +0300, Andrey Ryabinin wrote: > >> On 05/16/2017 04:16 AM, js1...@gmail.com wrote: > >> > From: Joonsoo Kim > >> > > >> > Hello, all. > >> > > >> > This is an attempt to recude memory consumption of KASAN. Please see > >> > following description to get the more information. > >> > > >> > 1. What is per-page shadow memory > >> > > >> > This patch introduces infrastructure to support per-page shadow memory. > >> > Per-page shadow memory is the same with original shadow memory except > >> > the granualarity. It's one byte shows the shadow value for the page. > >> > The purpose of introducing this new shadow memory is to save memory > >> > consumption. > >> > > >> > 2. Problem of current approach > >> > > >> > Until now, KASAN needs shadow memory for all the range of the memory > >> > so the amount of statically allocated memory is so large. It causes > >> > the problem that KASAN cannot run on the system with hard memory > >> > constraint. Even if KASAN can run, large memory consumption due to > >> > KASAN changes behaviour of the workload so we cannot validate > >> > the moment that we want to check. > >> > > >> > 3. How does this patch fix the problem > >> > > >> > This patch tries to fix the problem by reducing memory consumption for > >> > the shadow memory. There are two observations. > >> > > >> > >> > >> I think that the best way to deal with your problem is to increase shadow > >> scale size. > >> > >> You'll need to add tunable to gcc to control shadow size. I expect that > >> gcc has some > >> places where 8-shadow scale size is hardcoded, but it should be fixable. > >> > >> The kernel also have some small amount of code written with > >> KASAN_SHADOW_SCALE_SIZE == 8 in mind, > >> which should be easy to fix. > >> > >> Note that bigger shadow scale size requires bigger alignment of allocated > >> memory and variables. > >> However, according to comments in gcc/asan.c gcc already aligns stack and > >> global variables and at > >> 32-bytes boundary. > >> So we could bump shadow scale up to 32 without increasing current stack > >> consumption. > >> > >> On a small machine (1Gb) 1/32 of shadow is just 32Mb which is comparable > >> to yours 30Mb, but I expect it to be > >> much faster. More importantly, this will require only small amount of > >> simple changes in code, which will be > >> a *lot* more easier to maintain. > > > Interesting option. We never considered increasing scale in user space > due to performance implications. But the algorithm always supported up > to 128x scale. Definitely worth considering as an option. Could you explain me how does increasing scale reduce performance? I tried to guess the reason but failed. > > > > I agree that it is also a good option to reduce memory consumption. > > Nevertheless, there are two reasons that justifies this patchset. > > > > 1) With this patchset, memory consumption isn't increased in > > proportional to total memory size. Please consider my 4Gb system > > example on the below. With increasing shadow scale size to 32, memory > > would be consumed by 128M. However, this patchset consumed 50MB. This > > difference can be larger if we run KASAN with bigger machine. > > > > 2) These two optimization can be applied simulatenously. It is just an > > orthogonal feature. If shadow scale size is increased to 32, memory > > consumption will be decreased in case of my patchset, too. > > > > Therefore, I think that this patchset is useful in any case. > > It is definitely useful all else being equal. But it does considerably > increase code size and complexity, which is an important aspect. > > Also note that there is also fixed size quarantine (1/32 of RAM) and > redzones. Reducing shadow overhead beyond some threshold has > diminishing returns, because overall overhead will be just dominated > by quarantine/redzones. My usecase doesn't use quarantine yet since it uses old version kernel and quarantine isn't back-ported. But, this 1/32 of RAM for quarantine also could affect the system and I think that we need a switch to disable it. In our case, making the feature work is more important than detecting more bugs. Redzone is also a good target to make selectable since error pattern could be changed with different object layout. I sometimes saw that error disappears if KASAN is enabled. I'm not sure what causes it, but, in some case, it would be helpful that everything else than something compulsory is the same with non-KASAN build. > What's your target devices and constraints? We run KASAN on phones > today without any issues. My target devices are a smart TV or embedded system on a car. Usually, these devices have specific use scenario and memory is managed more tightly than a phone. I have heard that some system with 1GB memory cannot run if 128MB is used for KASAN. I'm not sure th
[PATCH v2 1/1] printk: add __printf attributes to internal functions
When compiling with -Wsuggest-attribute=format, gcc complains that some
functions in kernel/printk/printk_safe.c transmit their argument to
printf-like functions without having a printf attribute. Silence these
warnings by adding relevant __printf attributes.
Signed-off-by: Nicolas Iooss
Acked-by: Petr Mladek
---
v2: add __printf attribute to the definition of vprintk_nmi() which is
used when CONFIG_PRINTK_NMI is not defined.
kernel/printk/printk_safe.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
index 033e50a7d706..f96d1ecd85ac 100644
--- a/kernel/printk/printk_safe.c
+++ b/kernel/printk/printk_safe.c
@@ -80,8 +80,8 @@ static void queue_flush_work(struct printk_safe_seq_buf *s)
* happen, printk_safe_log_store() will notice the buffer->len mismatch
* and repeat the write.
*/
-static int printk_safe_log_store(struct printk_safe_seq_buf *s,
-const char *fmt, va_list args)
+static __printf(2, 0) int printk_safe_log_store(struct printk_safe_seq_buf *s,
+ const char *fmt, va_list args)
{
int add;
size_t len;
@@ -299,7 +299,7 @@ void printk_safe_flush_on_panic(void)
* one writer running. But the buffer might get flushed from another
* CPU, so we need to be careful.
*/
-static int vprintk_nmi(const char *fmt, va_list args)
+static __printf(1, 0) int vprintk_nmi(const char *fmt, va_list args)
{
struct printk_safe_seq_buf *s = this_cpu_ptr(&nmi_print_seq);
@@ -318,7 +318,7 @@ void printk_nmi_exit(void)
#else
-static int vprintk_nmi(const char *fmt, va_list args)
+static __printf(1, 0) int vprintk_nmi(const char *fmt, va_list args)
{
return 0;
}
@@ -330,7 +330,7 @@ static int vprintk_nmi(const char *fmt, va_list args)
* into itself. It uses a per-CPU buffer to store the message, just like
* NMI.
*/
-static int vprintk_safe(const char *fmt, va_list args)
+static __printf(1, 0) int vprintk_safe(const char *fmt, va_list args)
{
struct printk_safe_seq_buf *s = this_cpu_ptr(&safe_print_seq);
--
2.13.0
[PATCH] mm/zsmalloc: fix -Wunneeded-internal-declaration warning
is_first_page() is only called from the macro VM_BUG_ON_PAGE() which is
only compiled in as a runtime check when CONFIG_DEBUG_VM is set,
otherwise is checked at compile time and not actually compiled in.
Fixes the following warning, found with Clang:
mm/zsmalloc.c:472:12: warning: function 'is_first_page' is not needed and
will not be emitted [-Wunneeded-internal-declaration]
static int is_first_page(struct page *page)
^
Signed-off-by: Nick Desaulniers
---
mm/zsmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index d41edd28298b..15959d35fc26 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -469,7 +469,7 @@ static bool is_zspage_isolated(struct zspage *zspage)
return zspage->isolated;
}
-static int is_first_page(struct page *page)
+static __maybe_unused int is_first_page(struct page *page)
{
return PagePrivate(page);
}
--
2.11.0
Re: [PATCH 2/2] spi: use gpio_desc instead of numeric gpio
On 24/05/17 08:43, Chris Packham wrote:
> Hi Andy,
>
> On 24/05/17 06:28, Andy Shevchenko wrote:
>> On Tue, May 23, 2017 at 7:03 AM, Chris Packham
>> wrote:
>>> By using a gpio_desc and gpiod_set_value() instead of a numeric gpio and
>>> gpio_set_value() the gpio flags are taken into account. This is useful
>>> when using a gpio chip-select to supplement a controllers native
>>> chip-select.
>>
>> I think would be better to move everything in SPI core to GPIO descriptors.
>
> I did consider it but it's a big change and I don't have access a lot of
> gear to test on (maybe 2 or 3 SoCs with a SPI host controller and the
> same SPI-NOR chips).
>
> I can give it a try. Perhaps converting the spi core structures over and
> leaving the slaves using numeric gpios. Then later converting the slaves.
>
OK so I've had a look at this. The changes to change struct spi_master
to use gpio_desc in drivers/spi/spi-gpio.c are pretty straight forward
(in-line patch below, apologies for MUA wrapping).
There are a few SPI host drivers that deal with cs_gpios directly.
spi-mt65xx.c and spi-davinci.c would be trivial to update. spi-ep93xx.c
and spi-imx.c are harder because they handle non-dt platforms.
Changing struct spi_device to use gpio_desc would be wider reaching but
probably automatable s/gpio_set_value/gpiod_set_value/.
I'm a little too nervous about messing up spi-ep93xx.c and spi-ep93xx.c
to push ahead with changing all of SPI core. I'd be happy to help out
someone with access to platforms using those.
-- 8< --
index b39c0f9956dd..80a96d3daa45 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include
@@ -531,8 +532,8 @@ int spi_add_device(struct spi_device *spi)
goto done;
}
- if (master->cs_gpios)
- spi->cs_gpio = master->cs_gpios[spi->chip_select];
+ if (master->cs_gpios[spi->chip_select])
+ spi->cs_gpio =
desc_to_gpio(master->cs_gpios[spi->chip_select]);
/* Drivers may modify this initial i/o setup, but will
* normally rely on the device being setup. Devices
@@ -1878,7 +1879,8 @@ EXPORT_SYMBOL_GPL(spi_alloc_master);
#ifdef CONFIG_OF
static int of_spi_register_master(struct spi_master *master)
{
- int nb, i, *cs;
+ int nb, i;
+ struct gpio_desc **cs;
struct device_node *np = master->dev.of_node;
if (!np)
@@ -1894,7 +1896,7 @@ static int of_spi_register_master(struct
spi_master *master)
return nb;
cs = devm_kzalloc(&master->dev,
- sizeof(int) * master->num_chipselect,
+ sizeof(*master->cs_gpios) *
master->num_chipselect,
GFP_KERNEL);
master->cs_gpios = cs;
@@ -1902,10 +1904,16 @@ static int of_spi_register_master(struct
spi_master *master)
return -ENOMEM;
for (i = 0; i < master->num_chipselect; i++)
- cs[i] = -ENOENT;
+ cs[i] = NULL;
- for (i = 0; i < nb; i++)
- cs[i] = of_get_named_gpio(np, "cs-gpios", i);
+ for (i = 0; i < nb; i++) {
+ struct gpio_desc *gpio;
+
+ gpio = devm_gpiod_get_index(&master->dev, "cs", i,
+ GPIOD_OUT_HIGH);
+ if (!IS_ERR(gpio))
+ cs[i] = gpio;
+ }
return 0;
}
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 935bd2854ff1..46960ca62d5b 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -556,7 +556,7 @@ struct spi_master {
struct spi_message *message);
/* gpio chip select */
- int *cs_gpios;
+ struct gpio_desc**cs_gpios;
/* statistics */
struct spi_statistics statistics;
-- >8 --
>>
>>>
>>> Signed-off-by: Chris Packham
>>> ---
>>>
>>> Notes:
>>> My specific use-case is I have a board that uses the spi-orion driver
>>> but
>>> only has one CS pin available. In order to access two spi slave
>>> devices the
>>> board has a 1-of-2 decoder/demultiplexer which is driven via a gpio.
>>>
>>> The problem is that for one of the 2 slave devices the gpio level
>>> required
>>> is opposite to the chip-select so I can't simply specify
>>> "spi-cs-high".
>>> With this change I can flag the gpio as active low and the gpio
>>> subsystem
>>> takes care of the additional inversion required.
>>>
>>>drivers/spi/spi.c | 5 -
>>>1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
>>> index 6f87fec409b5..b39c0f9956dd 100644
>>> --- a/drivers/spi/spi.c
>>> +++ b/drivers/spi/spi.c
>>> @@ -725,7 +725,10 @@ static void spi_set_cs(struct spi_device *spi, bool
>>> enable)
>>> enable = !enable;
Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE
于 2017年5月24日 GMT+08:00 下午1:34:58, Chen-Yu Tsai 写到:
>On Wed, May 24, 2017 at 1:28 PM, Icenowy Zheng wrote:
>>
>>
>> 于 2017年5月24日 GMT+08:00 下午1:24:29, Chen-Yu Tsai 写到:
>>>On Thu, May 18, 2017 at 12:43 AM, Icenowy Zheng
>>>wrote:
As we have already the support for the TV encoder on Allwinner H3,
>>>add
the display engine pipeline device tree nodes to its DTSI file.
The H5 pipeline has some differences and will be enabled later.
The currently-unused mixer0 and tcon0 are also needed, for the
completement of the pipeline.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-h3.dtsi | 189
>>>
1 file changed, 189 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>b/arch/arm/boot/dts/sun8i-h3.dtsi
index b36f9f423c39..20172ef92415 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -41,6 +41,8 @@
*/
#include "sunxi-h3-h5.dtsi"
+#include
+#include
/ {
cpus {
@@ -72,6 +74,193 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-h3-display-engine";
+ allwinner,pipelines = <&mixer0>,
+ <&mixer1>;
+ status = "disabled";
+ };
+
+ soc {
+ display_clocks: clock@100 {
+ compatible =
>"allwinner,sun8i-a83t-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_BUS_DE>,
+<&ccu CLK_DE>;
+ clock-names = "bus",
+ "mod";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ assigned-clocks = <&ccu CLK_DE>;
+ assigned-clock-parents = <&ccu CLK_PLL_DE>;
+ assigned-clock-rates = <43200>;
+ };
+
+ mixer0: mixer@110 {
+ compatible =
>"allwinner,sun8i-h3-de2-mixer0";
+ reg = <0x0110 0x10>;
+ clocks = <&display_clocks CLK_BUS_MIXER0>,
+<&display_clocks CLK_MIXER0>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_MIXER0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer0_out_tcon0:
>endpoint@0
>>>{
+ reg = <0>;
+ remote-endpoint =
>>><&tcon0_in_mixer0>;
+ };
+
+ mixer0_out_tcon1:
>endpoint@1
>>>{
+ reg = <1>;
+ remote-endpoint =
>>><&tcon1_in_mixer0>;
+ };
+ };
+ };
+ };
+
+ mixer1: mixer@120 {
+ compatible =
>"allwinner,sun8i-h3-de2-mixer1";
+ reg = <0x0120 0x10>;
+ clocks = <&display_clocks CLK_BUS_MIXER1>,
+<&display_clocks CLK_MIXER1>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_WB>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer1_out_tcon1:
>endpoint@0
>>>{
+ reg = <0>;
>>>
>>>I would prefer if you could stick to the numbering scheme w
Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE
On Wed, May 24, 2017 at 1:28 PM, Icenowy Zheng wrote:
>
>
> 于 2017年5月24日 GMT+08:00 下午1:24:29, Chen-Yu Tsai 写到:
>>On Thu, May 18, 2017 at 12:43 AM, Icenowy Zheng
>>wrote:
>>> As we have already the support for the TV encoder on Allwinner H3,
>>add
>>> the display engine pipeline device tree nodes to its DTSI file.
>>>
>>> The H5 pipeline has some differences and will be enabled later.
>>>
>>> The currently-unused mixer0 and tcon0 are also needed, for the
>>> completement of the pipeline.
>>>
>>> Signed-off-by: Icenowy Zheng
>>> ---
>>> arch/arm/boot/dts/sun8i-h3.dtsi | 189
>>
>>> 1 file changed, 189 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index b36f9f423c39..20172ef92415 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -41,6 +41,8 @@
>>> */
>>>
>>> #include "sunxi-h3-h5.dtsi"
>>> +#include
>>> +#include
>>>
>>> / {
>>> cpus {
>>> @@ -72,6 +74,193 @@
>>> };
>>> };
>>>
>>> + de: display-engine {
>>> + compatible = "allwinner,sun8i-h3-display-engine";
>>> + allwinner,pipelines = <&mixer0>,
>>> + <&mixer1>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + soc {
>>> + display_clocks: clock@100 {
>>> + compatible = "allwinner,sun8i-a83t-de2-clk";
>>> + reg = <0x0100 0x10>;
>>> + clocks = <&ccu CLK_BUS_DE>,
>>> +<&ccu CLK_DE>;
>>> + clock-names = "bus",
>>> + "mod";
>>> + resets = <&ccu RST_BUS_DE>;
>>> + #clock-cells = <1>;
>>> + #reset-cells = <1>;
>>> + assigned-clocks = <&ccu CLK_DE>;
>>> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
>>> + assigned-clock-rates = <43200>;
>>> + };
>>> +
>>> + mixer0: mixer@110 {
>>> + compatible = "allwinner,sun8i-h3-de2-mixer0";
>>> + reg = <0x0110 0x10>;
>>> + clocks = <&display_clocks CLK_BUS_MIXER0>,
>>> +<&display_clocks CLK_MIXER0>;
>>> + clock-names = "bus",
>>> + "mod";
>>> + resets = <&display_clocks RST_MIXER0>;
>>> + status = "disabled";
>>> +
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + mixer0_out: port@1 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <1>;
>>> +
>>> + mixer0_out_tcon0: endpoint@0
>>{
>>> + reg = <0>;
>>> + remote-endpoint =
>><&tcon0_in_mixer0>;
>>> + };
>>> +
>>> + mixer0_out_tcon1: endpoint@1
>>{
>>> + reg = <1>;
>>> + remote-endpoint =
>><&tcon1_in_mixer0>;
>>> + };
>>> + };
>>> + };
>>> + };
>>> +
>>> + mixer1: mixer@120 {
>>> + compatible = "allwinner,sun8i-h3-de2-mixer1";
>>> + reg = <0x0120 0x10>;
>>> + clocks = <&display_clocks CLK_BUS_MIXER1>,
>>> +<&display_clocks CLK_MIXER1>;
>>> + clock-names = "bus",
>>> + "mod";
>>> + resets = <&display_clocks RST_WB>;
>>> +
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + mixer1_out: port@1 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <1>;
>>> +
>>> + mixer1_out_tcon1: endpoint@0
>>{
>>> + reg = <0>;
>>
>>I would prefer if you could stick to the numbering scheme we're using
>>for
>>Display Engine 1.0, as in endpoint 0 links to component 0 of whatever
>>type.
>
> If we keep this we will need a ugly id property in mixer node,
> otherwise we ca
[PATCH 6/6] sched: cpufreq: Optimize cpufreq_update_this_cpu() a bit
smp_processor_id() can result in a function call if CONFIG_DEBUG_PREEMPT
is enabled. It would be much straight forward to use this_rq() macro
instead.
Signed-off-by: Viresh Kumar
---
kernel/sched/sched.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index bcdf6a136c59..4220ec76d643 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1995,7 +1995,7 @@ static inline void cpufreq_update_util(struct rq *rq,
unsigned int flags)
static inline void cpufreq_update_this_cpu(struct rq *rq, unsigned int flags)
{
- if (cpu_of(rq) == smp_processor_id())
+ if (rq == this_rq())
cpufreq_update_util(rq, flags);
}
#else
--
2.13.0.70.g636092d9
[PATCH 5/6] sched: fair: Drop always true parameter of update_cfs_rq_load_avg()
update_freq is always true and there is no need to pass it to
update_cfs_rq_load_avg(). Remove it.
Signed-off-by: Viresh Kumar
---
kernel/sched/fair.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e519f6c03fe9..89d61d09d083 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -806,7 +806,7 @@ void post_init_entity_util_avg(struct sched_entity *se)
/*
* For !fair tasks do:
*
- update_cfs_rq_load_avg(now, cfs_rq, false);
+ update_cfs_rq_load_avg(now, cfs_rq);
attach_entity_load_avg(cfs_rq, se);
switched_from_fair(rq, p);
*
@@ -3259,7 +3259,6 @@ static inline void set_tg_cfs_propagate(struct cfs_rq
*cfs_rq) {}
* update_cfs_rq_load_avg - update the cfs_rq's load/util averages
* @now: current time, as per cfs_rq_clock_task()
* @cfs_rq: cfs_rq to update
- * @update_freq: should we call cfs_rq_util_change() or will the call do so
*
* The cfs_rq avg is the direct sum of all its entities (blocked and runnable)
* avg. The immediate corollary is that all (fair) tasks must be attached, see
@@ -3273,7 +3272,7 @@ static inline void set_tg_cfs_propagate(struct cfs_rq
*cfs_rq) {}
* call update_tg_load_avg() when this function returns true.
*/
static inline int
-update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq, bool update_freq)
+update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
{
struct sched_avg *sa = &cfs_rq->avg;
int decayed, removed_load = 0, removed_util = 0;
@@ -3301,7 +3300,7 @@ update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq,
bool update_freq)
cfs_rq->load_last_update_time_copy = sa->last_update_time;
#endif
- if (update_freq && (decayed || removed_util))
+ if (decayed || removed_util)
cfs_rq_util_change(cfs_rq);
return decayed || removed_load;
@@ -3329,7 +3328,7 @@ static inline void update_load_avg(struct sched_entity
*se, int flags)
if (se->avg.last_update_time && !(flags & SKIP_AGE_LOAD))
__update_load_avg_se(now, cpu, cfs_rq, se);
- decayed = update_cfs_rq_load_avg(now, cfs_rq, true);
+ decayed = update_cfs_rq_load_avg(now, cfs_rq);
decayed |= propagate_entity_load_avg(se);
if (decayed && (flags & UPDATE_TG))
@@ -3473,7 +3472,7 @@ static int idle_balance(struct rq *this_rq, struct
rq_flags *rf);
#else /* CONFIG_SMP */
static inline int
-update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq, bool update_freq)
+update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
{
return 0;
}
@@ -6995,7 +6994,7 @@ static void update_blocked_averages(int cpu)
if (throttled_hierarchy(cfs_rq))
continue;
- if (update_cfs_rq_load_avg(cfs_rq_clock_task(cfs_rq), cfs_rq,
true))
+ if (update_cfs_rq_load_avg(cfs_rq_clock_task(cfs_rq), cfs_rq))
update_tg_load_avg(cfs_rq, 0);
/* Propagate pending load changes to the parent, if any: */
@@ -7068,7 +7067,7 @@ static inline void update_blocked_averages(int cpu)
rq_lock_irqsave(rq, &rf);
update_rq_clock(rq);
- update_cfs_rq_load_avg(cfs_rq_clock_task(cfs_rq), cfs_rq, true);
+ update_cfs_rq_load_avg(cfs_rq_clock_task(cfs_rq), cfs_rq);
rq_unlock_irqrestore(rq, &rf);
}
--
2.13.0.70.g636092d9
[PATCH 3/6] sched: fair: Pass rq to weighted_cpuload()
weighted_cpuload() uses the cpu number passed to it get pointer to the
runqueue. Almost all callers of weighted_cpuload() already have the rq
pointer with them and can send that directly to weighted_cpuload(). In
some cases the callers actually get the CPU number by doing cpu_of(rq).
It would be simpler to pass rq to weighted_cpuload().
Signed-off-by: Viresh Kumar
---
kernel/sched/fair.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index a0a97497c400..fe03efd3880a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1378,7 +1378,7 @@ bool should_numa_migrate_memory(struct task_struct *p,
struct page * page,
group_faults_cpu(ng, src_nid) * group_faults(p, dst_nid) * 4;
}
-static unsigned long weighted_cpuload(const int cpu);
+static unsigned long weighted_cpuload(struct rq *rq);
static unsigned long source_load(int cpu, int type);
static unsigned long target_load(int cpu, int type);
static unsigned long capacity_of(int cpu);
@@ -1410,7 +1410,7 @@ static void update_numa_stats(struct numa_stats *ns, int
nid)
struct rq *rq = cpu_rq(cpu);
ns->nr_running += rq->nr_running;
- ns->load += weighted_cpuload(cpu);
+ ns->load += weighted_cpuload(rq);
ns->compute_capacity += capacity_of(cpu);
cpus++;
@@ -5064,9 +5064,9 @@ static void cpu_load_update(struct rq *this_rq, unsigned
long this_load,
}
/* Used instead of source_load when we know the type == 0 */
-static unsigned long weighted_cpuload(const int cpu)
+static unsigned long weighted_cpuload(struct rq *rq)
{
- return cfs_rq_runnable_load_avg(&cpu_rq(cpu)->cfs);
+ return cfs_rq_runnable_load_avg(&rq->cfs);
}
#ifdef CONFIG_NO_HZ_COMMON
@@ -5111,7 +5111,7 @@ static void cpu_load_update_idle(struct rq *this_rq)
/*
* bail if there's load or we're actually up-to-date.
*/
- if (weighted_cpuload(cpu_of(this_rq)))
+ if (weighted_cpuload(this_rq))
return;
cpu_load_update_nohz(this_rq, READ_ONCE(jiffies), 0);
@@ -5132,7 +5132,7 @@ void cpu_load_update_nohz_start(void)
* concurrently we'll exit nohz. And cpu_load write can race with
* cpu_load_update_idle() but both updater would be writing the same.
*/
- this_rq->cpu_load[0] = weighted_cpuload(cpu_of(this_rq));
+ this_rq->cpu_load[0] = weighted_cpuload(this_rq);
}
/*
@@ -5148,7 +5148,7 @@ void cpu_load_update_nohz_stop(void)
if (curr_jiffies == this_rq->last_load_update_tick)
return;
- load = weighted_cpuload(cpu_of(this_rq));
+ load = weighted_cpuload(this_rq);
rq_lock(this_rq, &rf);
update_rq_clock(this_rq);
cpu_load_update_nohz(this_rq, curr_jiffies, load);
@@ -5174,7 +5174,7 @@ static void cpu_load_update_periodic(struct rq *this_rq,
unsigned long load)
*/
void cpu_load_update_active(struct rq *this_rq)
{
- unsigned long load = weighted_cpuload(cpu_of(this_rq));
+ unsigned long load = weighted_cpuload(this_rq);
if (tick_nohz_tick_stopped())
cpu_load_update_nohz(this_rq, READ_ONCE(jiffies), load);
@@ -5192,7 +5192,7 @@ void cpu_load_update_active(struct rq *this_rq)
static unsigned long source_load(int cpu, int type)
{
struct rq *rq = cpu_rq(cpu);
- unsigned long total = weighted_cpuload(cpu);
+ unsigned long total = weighted_cpuload(rq);
if (type == 0 || !sched_feat(LB_BIAS))
return total;
@@ -5207,7 +5207,7 @@ static unsigned long source_load(int cpu, int type)
static unsigned long target_load(int cpu, int type)
{
struct rq *rq = cpu_rq(cpu);
- unsigned long total = weighted_cpuload(cpu);
+ unsigned long total = weighted_cpuload(rq);
if (type == 0 || !sched_feat(LB_BIAS))
return total;
@@ -5229,7 +5229,7 @@ static unsigned long cpu_avg_load_per_task(int cpu)
{
struct rq *rq = cpu_rq(cpu);
unsigned long nr_running = READ_ONCE(rq->cfs.h_nr_running);
- unsigned long load_avg = weighted_cpuload(cpu);
+ unsigned long load_avg = weighted_cpuload(rq);
if (nr_running)
return load_avg / nr_running;
@@ -5651,7 +5651,7 @@ find_idlest_cpu(struct sched_group *group, struct
task_struct *p, int this_cpu)
shallowest_idle_cpu = i;
}
} else if (shallowest_idle_cpu == -1) {
- load = weighted_cpuload(i);
+ load = weighted_cpuload(cpu_rq(i));
if (load < min_load || (load == min_load && i ==
this_cpu)) {
min_load = load;
least_loaded_cpu = i;
@@ -7439,7 +7439,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
[PATCH 4/6] sched: fair: Avoid checking cfs_rq->nr_running twice
Rearrange pick_next_task_fair() a bit to avoid checking
cfs_rq->nr_running twice for the case where FAIR_GROUP_SCHED is enabled
and the previous task doesn't belong to the fair class.
Signed-off-by: Viresh Kumar
---
kernel/sched/fair.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fe03efd3880a..e519f6c03fe9 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6267,10 +6267,10 @@ pick_next_task_fair(struct rq *rq, struct task_struct
*prev, struct rq_flags *rf
int new_tasks;
again:
-#ifdef CONFIG_FAIR_GROUP_SCHED
if (!cfs_rq->nr_running)
goto idle;
+#ifdef CONFIG_FAIR_GROUP_SCHED
if (prev->sched_class != &fair_sched_class)
goto simple;
@@ -6300,11 +6300,17 @@ pick_next_task_fair(struct rq *rq, struct task_struct
*prev, struct rq_flags *rf
/*
* This call to check_cfs_rq_runtime() will do the
* throttle and dequeue its entity in the parent(s).
-* Therefore the 'simple' nr_running test will indeed
+* Therefore the nr_running test will indeed
* be correct.
*/
- if (unlikely(check_cfs_rq_runtime(cfs_rq)))
+ if (unlikely(check_cfs_rq_runtime(cfs_rq))) {
+ cfs_rq = &rq->cfs;
+
+ if (!cfs_rq->nr_running)
+ goto idle;
+
goto simple;
+ }
}
se = pick_next_entity(cfs_rq, curr);
@@ -6344,12 +6350,8 @@ pick_next_task_fair(struct rq *rq, struct task_struct
*prev, struct rq_flags *rf
return p;
simple:
- cfs_rq = &rq->cfs;
#endif
- if (!cfs_rq->nr_running)
- goto idle;
-
put_prev_task(rq, prev);
do {
--
2.13.0.70.g636092d9
[PATCH 2/6] sched: Reuse put_prev_task()
Reuse put_prev_task() instead of copying its implementation. Signed-off-by: Viresh Kumar --- kernel/sched/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index a8366cfebd31..8ddebb068585 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5683,7 +5683,7 @@ static void migrate_tasks(struct rq *dead_rq, struct rq_flags *rf) */ next = pick_next_task(rq, &fake_task, rf); BUG_ON(!next); - next->sched_class->put_prev_task(rq, next); + put_prev_task(rq, next); /* * Rules for changing task_struct::cpus_allowed are holding -- 2.13.0.70.g636092d9
[PATCH 0/6] sched: Minor fixes and cleanups
Hi, The first patch fixes a potential regression we may observe on the UP systems and the others are doing minor optimizations in the scheduler core. They are all tested on ARM 32 (exynos) and 64 (hikey) bit platforms. -- viresh Viresh Kumar (6): sched: fair: Call cpufreq update util handlers less frequently on UP sched: Reuse put_prev_task() sched: fair: Pass rq to weighted_cpuload() sched: fair: Avoid checking cfs_rq->nr_running twice sched: fair: Drop always true parameter of update_cfs_rq_load_avg() sched: cpufreq: Optimize cpufreq_update_this_cpu() a bit kernel/sched/core.c | 2 +- kernel/sched/fair.c | 107 ++- kernel/sched/sched.h | 2 +- 3 files changed, 56 insertions(+), 55 deletions(-) -- 2.13.0.70.g636092d9
[PATCH 1/6] sched: fair: Call cpufreq update util handlers less frequently on UP
For SMP systems, update_load_avg() calls the cpufreq update util
handlers only for the top level cfs_rq (i.e. rq->cfs).
But that is not the case for UP systems. update_load_avg() calls util
handler for any cfs_rq for which it is called. This would result in way
too many calls from the scheduler to the cpufreq governors when
CONFIG_FAIR_GROUP_SCHED is enabled.
Reduce the frequency of these calls by copying the behavior from the SMP
case, i.e. Only call util handlers for the top level cfs_rq.
Fixes: 536bd00cdbb7 ("sched/fair: Fix !CONFIG_SMP kernel cpufreq governor
breakage")
Signed-off-by: Viresh Kumar
---
I wasn't sure if we would like to mark Stable for this or not.
Cc: 4.6+ # 4.6+
---
kernel/sched/fair.c | 48
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 47a0c552c77b..a0a97497c400 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2728,6 +2728,29 @@ static inline void update_cfs_shares(struct sched_entity
*se)
}
#endif /* CONFIG_FAIR_GROUP_SCHED */
+static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq)
+{
+ if (&this_rq()->cfs == cfs_rq) {
+ /*
+* There are a few boundary cases this might miss but it should
+* get called often enough that that should (hopefully) not be
+* a real problem -- added to that it only calls on the local
+* CPU, so if we enqueue remotely we'll miss an update, but
+* the next tick/schedule should update.
+*
+* It will not get called when we go idle, because the idle
+* thread is a different class (!fair), nor will the utilization
+* number include things like RT tasks.
+*
+* As is, the util number is not freq-invariant (we'd have to
+* implement arch_scale_freq_capacity() for that).
+*
+* See cpu_util().
+*/
+ cpufreq_update_util(rq_of(cfs_rq), 0);
+ }
+}
+
#ifdef CONFIG_SMP
/*
* Approximate:
@@ -3215,29 +3238,6 @@ static inline void set_tg_cfs_propagate(struct cfs_rq
*cfs_rq) {}
#endif /* CONFIG_FAIR_GROUP_SCHED */
-static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq)
-{
- if (&this_rq()->cfs == cfs_rq) {
- /*
-* There are a few boundary cases this might miss but it should
-* get called often enough that that should (hopefully) not be
-* a real problem -- added to that it only calls on the local
-* CPU, so if we enqueue remotely we'll miss an update, but
-* the next tick/schedule should update.
-*
-* It will not get called when we go idle, because the idle
-* thread is a different class (!fair), nor will the utilization
-* number include things like RT tasks.
-*
-* As is, the util number is not freq-invariant (we'd have to
-* implement arch_scale_freq_capacity() for that).
-*
-* See cpu_util().
-*/
- cpufreq_update_util(rq_of(cfs_rq), 0);
- }
-}
-
/*
* Unsigned subtract and clamp on underflow.
*
@@ -3483,7 +3483,7 @@ update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq,
bool update_freq)
static inline void update_load_avg(struct sched_entity *se, int not_used1)
{
- cpufreq_update_util(rq_of(cfs_rq_of(se)), 0);
+ cfs_rq_util_change(cfs_rq_of(se));
}
static inline void
--
2.13.0.70.g636092d9
Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE
于 2017年5月24日 GMT+08:00 下午1:24:29, Chen-Yu Tsai 写到:
>On Thu, May 18, 2017 at 12:43 AM, Icenowy Zheng
>wrote:
>> As we have already the support for the TV encoder on Allwinner H3,
>add
>> the display engine pipeline device tree nodes to its DTSI file.
>>
>> The H5 pipeline has some differences and will be enabled later.
>>
>> The currently-unused mixer0 and tcon0 are also needed, for the
>> completement of the pipeline.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> arch/arm/boot/dts/sun8i-h3.dtsi | 189
>
>> 1 file changed, 189 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index b36f9f423c39..20172ef92415 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -41,6 +41,8 @@
>> */
>>
>> #include "sunxi-h3-h5.dtsi"
>> +#include
>> +#include
>>
>> / {
>> cpus {
>> @@ -72,6 +74,193 @@
>> };
>> };
>>
>> + de: display-engine {
>> + compatible = "allwinner,sun8i-h3-display-engine";
>> + allwinner,pipelines = <&mixer0>,
>> + <&mixer1>;
>> + status = "disabled";
>> + };
>> +
>> + soc {
>> + display_clocks: clock@100 {
>> + compatible = "allwinner,sun8i-a83t-de2-clk";
>> + reg = <0x0100 0x10>;
>> + clocks = <&ccu CLK_BUS_DE>,
>> +<&ccu CLK_DE>;
>> + clock-names = "bus",
>> + "mod";
>> + resets = <&ccu RST_BUS_DE>;
>> + #clock-cells = <1>;
>> + #reset-cells = <1>;
>> + assigned-clocks = <&ccu CLK_DE>;
>> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
>> + assigned-clock-rates = <43200>;
>> + };
>> +
>> + mixer0: mixer@110 {
>> + compatible = "allwinner,sun8i-h3-de2-mixer0";
>> + reg = <0x0110 0x10>;
>> + clocks = <&display_clocks CLK_BUS_MIXER0>,
>> +<&display_clocks CLK_MIXER0>;
>> + clock-names = "bus",
>> + "mod";
>> + resets = <&display_clocks RST_MIXER0>;
>> + status = "disabled";
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + mixer0_out: port@1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + mixer0_out_tcon0: endpoint@0
>{
>> + reg = <0>;
>> + remote-endpoint =
><&tcon0_in_mixer0>;
>> + };
>> +
>> + mixer0_out_tcon1: endpoint@1
>{
>> + reg = <1>;
>> + remote-endpoint =
><&tcon1_in_mixer0>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + mixer1: mixer@120 {
>> + compatible = "allwinner,sun8i-h3-de2-mixer1";
>> + reg = <0x0120 0x10>;
>> + clocks = <&display_clocks CLK_BUS_MIXER1>,
>> +<&display_clocks CLK_MIXER1>;
>> + clock-names = "bus",
>> + "mod";
>> + resets = <&display_clocks RST_WB>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + mixer1_out: port@1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + mixer1_out_tcon1: endpoint@0
>{
>> + reg = <0>;
>
>I would prefer if you could stick to the numbering scheme we're using
>for
>Display Engine 1.0, as in endpoint 0 links to component 0 of whatever
>type.
If we keep this we will need a ugly id property in mixer node,
otherwise we cannot know which TCON to be bind.
>
>We're probably going to stick to that for the R40's incredibly
>complicated
>pipeline. I don't want to have any outliers unless absolutely
>necessa
[lkp-robot] [sched/core] 1c3c5eab17: BUG:using_smp_processor_id()in_preemptible
FYI, we noticed the following commit:
commit: 1c3c5eab171590f86edd8d31389d61dd1efe3037 ("sched/core: Enable
might_sleep() and smp_processor_id() checks early")
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git sched/core
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | 69a78ff226
| 1c3c5eab17 |
+--+++
| boot_successes | 6
| 0 |
| boot_failures| 2
| 8 |
| invoked_oom-killer:gfp_mask=0x | 2
||
| Mem-Info | 2
||
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 2
||
| BUG:using_smp_processor_id()in_preemptible | 0
| 8 |
+--+++
[ 15.697784] BUG: using smp_processor_id() in preemptible [] code:
swapper/0/1
[ 15.698793] caller is debug_smp_processor_id+0x1c/0x1e
[ 15.699461] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.12.0-rc2-00108-g1c3c5ea #1
[ 15.700431] Call Trace:
[ 15.700530] dump_stack+0x110/0x192
[ 15.700530] check_preemption_disabled+0x10c/0x128
[ 15.700530] ? set_debug_rodata+0x25/0x25
[ 15.700530] debug_smp_processor_id+0x1c/0x1e
[ 15.700530] sched_clock_init_late+0x27/0x87
[ 15.700530] ? sched_init+0x4c6/0x4c6
[ 15.700530] do_one_initcall+0xa3/0x1a7
[ 15.700530] ? set_debug_rodata+0x25/0x25
[ 15.700530] kernel_init_freeable+0x25e/0x304
[ 15.700530] ? rest_init+0x29a/0x29a
[ 15.700530] kernel_init+0x14/0x147
[ 15.700530] ? rest_init+0x29a/0x29a
[ 15.700530] ret_from_fork+0x31/0x40
[ 15.707460] sched_clock: Marking stable (15707446101, 0)->(16254936915,
-547490814)
[ 15.709183] Loading compiled-in X.509 certificates
[ 15.711197] Key type encrypted registered
[ 15.791159] Unregister pv shared memory for cpu 0
[ 15.794097] CPU 0 is now offline
[ 15.801534] Freeing unused kernel memory: 1232K
[ 15.802178] Write protecting the kernel read-only data: 12288k
[ 15.804954] Freeing unused kernel memory: 832K
[ 15.824888] Freeing unused kernel memory: 1236K
[ 15.836054] random: init: uninitialized urandom read (12 bytes read)
[ 15.947972] random: mountall: uninitialized urandom read (12 bytes read)
[ 15.953829] random: trinity: uninitialized urandom read (4 bytes read)
[ 15.994557] init: Failed to create pty - disabling logging for job
[ 15.995553] init: Temporary process spawn error: No such file or directory
[ 16.016425] init: Failed to create pty - disabling logging for job
[ 16.017422] init: Temporary process spawn error: No such file or directory
[ 16.065743] init: Failed to create pty - disabling logging for job
[ 16.066743] init: Temporary process spawn error: No such file or directory
[ 16.072872] init: Failed to create pty - disabling logging for job
[ 16.073847] init: Temporary process spawn error: No such file or directory
[ 16.166147] init: Failed to create pty - disabling logging for job
[ 16.167149] init: Temporary process spawn error: No such file or directory
[ 16.176152] init: Failed to create pty - disabling logging for job
[ 16.177131] init: Temporary process spawn error: No such file or directory
[ 16.186596] init: Failed to create pty - disabling logging for job
[ 16.187565] init: Temporary process spawn error: No such file or directory
[ 16.198251] udevd[215]: starting version 175
[ 16.211652] init: Failed to create pty - disabling logging for job
[ 16.212630] init: Temporary process spawn error: No such file or directory
[ 16.222026] init: Failed to create pty - disabling logging for job
[ 16.223003] init: Temporary process spawn error: No such file or directory
[ 16.239918] init: Failed to create pty - disabling logging for job
[ 16.241031] init: Temporary process spawn error: No such file or directory
[ 16.285515] init: Failed to create pty - disabling logging for job
[ 16.286509] init: Temporary process spawn error: No such file or directory
[ 16.292670] init: Failed to create pty - disabling logging for job
[ 16.293641] init: Temporary process spawn error: No such file or directory
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.12.0-r
Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE
On Thu, May 18, 2017 at 12:43 AM, Icenowy Zheng wrote:
> As we have already the support for the TV encoder on Allwinner H3, add
> the display engine pipeline device tree nodes to its DTSI file.
>
> The H5 pipeline has some differences and will be enabled later.
>
> The currently-unused mixer0 and tcon0 are also needed, for the
> completement of the pipeline.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/boot/dts/sun8i-h3.dtsi | 189
>
> 1 file changed, 189 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index b36f9f423c39..20172ef92415 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -41,6 +41,8 @@
> */
>
> #include "sunxi-h3-h5.dtsi"
> +#include
> +#include
>
> / {
> cpus {
> @@ -72,6 +74,193 @@
> };
> };
>
> + de: display-engine {
> + compatible = "allwinner,sun8i-h3-display-engine";
> + allwinner,pipelines = <&mixer0>,
> + <&mixer1>;
> + status = "disabled";
> + };
> +
> + soc {
> + display_clocks: clock@100 {
> + compatible = "allwinner,sun8i-a83t-de2-clk";
> + reg = <0x0100 0x10>;
> + clocks = <&ccu CLK_BUS_DE>,
> +<&ccu CLK_DE>;
> + clock-names = "bus",
> + "mod";
> + resets = <&ccu RST_BUS_DE>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + assigned-clocks = <&ccu CLK_DE>;
> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
> + assigned-clock-rates = <43200>;
> + };
> +
> + mixer0: mixer@110 {
> + compatible = "allwinner,sun8i-h3-de2-mixer0";
> + reg = <0x0110 0x10>;
> + clocks = <&display_clocks CLK_BUS_MIXER0>,
> +<&display_clocks CLK_MIXER0>;
> + clock-names = "bus",
> + "mod";
> + resets = <&display_clocks RST_MIXER0>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mixer0_out: port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + mixer0_out_tcon0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint =
> <&tcon0_in_mixer0>;
> + };
> +
> + mixer0_out_tcon1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint =
> <&tcon1_in_mixer0>;
> + };
> + };
> + };
> + };
> +
> + mixer1: mixer@120 {
> + compatible = "allwinner,sun8i-h3-de2-mixer1";
> + reg = <0x0120 0x10>;
> + clocks = <&display_clocks CLK_BUS_MIXER1>,
> +<&display_clocks CLK_MIXER1>;
> + clock-names = "bus",
> + "mod";
> + resets = <&display_clocks RST_WB>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mixer1_out: port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + mixer1_out_tcon1: endpoint@0 {
> + reg = <0>;
I would prefer if you could stick to the numbering scheme we're using for
Display Engine 1.0, as in endpoint 0 links to component 0 of whatever type.
We're probably going to stick to that for the R40's incredibly complicated
pipeline. I don't want to have any outliers unless absolutely necessary.
ChenYu
> + remote-endpoint =
> <&tcon1_in_mixer1>;
> + };
> +
> + mixer1_out_tcon0: endpoint@1 {
> + reg = <
Re: [PATCH 0/3] add fallback reason strings to DAX PMD path
Hi Ross, On Tue, 23 May 2017 15:25:57 -0600 Ross Zwisler wrote: > One of the primary motivations for adding tracepoints to the DAX PMD path > was to allow the user to diagnose whether their system was actually using > PMDs, and if not to help them understand why. For me at least this has > worked okay in some situations, but many times I find myself adding more > debugging to diagnose fallback reasons that aren't immediately obvious, or > situations where the current tracepoints are simply insufficient because > they don't give you enough information. > > This series adds short fallback reason strings to the tracepoints in the > PMD path with the intention of giving the user better information about why > their system is falling back to PTEs. > > So, for example, the recent case on my system was that I forgot to move my > namespace from "raw" mode to "memory" mode, which resulted in this output: > > big-1046 [000] 103.930950: dax_pmd_fault: dev 259:0 ino 0xc shared > WRITE|ALLOW_RETRY|KILLABLE|USER address 0x10505000 vm_start 0x1020 > vm_end 0x1070 pgoff 0x305 max_pgoff 0x1400 > > big-1046 [000] 103.931220: dax_pmd_insert_mapping_fallback: dev > 259:0 ino 0xc shared write address 0x10505000 length 0x20 pfn 0x24a200 > DEV radix_entry 0x0 > > big-1046 [000] 103.931222: dax_pmd_fault_done: dev 259:0 ino 0xc > shared WRITE|ALLOW_RETRY|KILLABLE|USER address 0x10505000 vm_start > 0x1020 vm_end 0x1070 pgoff 0x305 max_pgoff 0x1400 FALLBACK > > The issue is that the PFN_MAP flag isn't set because we're lacking struct > page for our PMEM namespace. It's not immediately obvious why this > fallback happened, and actually you can't even diagnose it because we mask > off the pfn_t flags before printing the PFN. :( > > This new output: > > big-1011 [000] 36.164708: dax_pmd_fault: dev 259:0 ino 0xc shared > WRITE|ALLOW_RETRY|KILLABLE|USER address 0x10505000 vm_start 0x1020 > vm_end 0x1070 pgoff 0x305 max_pgoff 0x1400 > > big-1011 [000] 36.165521: dax_pmd_insert_mapping_fallback: dev > 259:0 ino 0xc shared write address 0x10505000 length 0x20 pfn > 0x20249200 DEV radix_entry 0x0 pfn_t not devmap > > big-1011 [000] 36.165524: dax_pmd_fault_done: dev 259:0 ino 0xc > shared WRITE|ALLOW_RETRY|KILLABLE|USER address 0x10505000 vm_start > 0x1020 vm_end 0x1070 pgoff 0x305 max_pgoff 0x1400 FALLBACK > > adds the "pfn_t not devmap" string to the second line, telling the user > exactly what's going on. I also stopped masking off the pfn_t flags so the > output was more complete. I think this idea is good. How about adding a suffix to be easy for grep? For example the suffix, DAX_FAULT_. And, to simplify the code, how about moving the string of fault reason to include/trace/events/fs_dax.h, like as include/trace/events/kvm.h? Regards, Masayoshi Mizuma > > My only concern is that somehow adding strings like this to tracepoint > output, brief and useful though they may be, is somehow breaking what > tracepoints are supposed to be doing. If anyone feels strongly about this > I guess I can just keep these changes locally and try to keep enhancing the > existing output without adding strings. > > Ross Zwisler (3): > dax: add fallback reason to dax_iomap_pmd_fault() > dax: add fallback reason to dax_pmd_insert_mapping() > dax: add fallback reason to dax_pmd_load_hole() > > fs/dax.c | 76 > +++ > include/trace/events/fs_dax.h | 50 +--- > 2 files changed, 86 insertions(+), 40 deletions(-) > > -- > 2.9.4 > > ___ > Linux-nvdimm mailing list > linux-nvd...@lists.01.org > https://lists.01.org/mailman/listinfo/linux-nvdimm
[PATCH] powerpc: dts: use #include "..." to include local DT
Most of DT files in PowerPC use #include "..." to make pre-processor
include DT in the same directory, but we have 3 exceptional files
that use #include <...> for that.
Fix them to remove -I$(srctree)/arch/$(SRCARCH)/boot/dts path from
dtc_cpp_flags.
Signed-off-by: Masahiro Yamada
---
arch/powerpc/boot/dts/ac14xx.dts | 2 +-
arch/powerpc/boot/dts/mpc5121ads.dts | 2 +-
arch/powerpc/boot/dts/pdm360ng.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/ac14xx.dts b/arch/powerpc/boot/dts/ac14xx.dts
index 27fcabc2f857..83bcfd865167 100644
--- a/arch/powerpc/boot/dts/ac14xx.dts
+++ b/arch/powerpc/boot/dts/ac14xx.dts
@@ -10,7 +10,7 @@
*/
-#include
+#include "mpc5121.dtsi"
/ {
model = "ac14xx";
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts
b/arch/powerpc/boot/dts/mpc5121ads.dts
index 75888ce2c792..73c30621429b 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -9,7 +9,7 @@
* option) any later version.
*/
-#include
+#include "mpc5121.dtsi"
/ {
model = "mpc5121ads";
diff --git a/arch/powerpc/boot/dts/pdm360ng.dts
b/arch/powerpc/boot/dts/pdm360ng.dts
index 0cec7244abe7..445b88114009 100644
--- a/arch/powerpc/boot/dts/pdm360ng.dts
+++ b/arch/powerpc/boot/dts/pdm360ng.dts
@@ -13,7 +13,7 @@
* option) any later version.
*/
-#include
+#include "mpc5121.dtsi"
/ {
model = "pdm360ng";
--
2.7.4
[PATCH] ARM: dts: versatile: use #include "..." to include local DT
Most of DT files in ARM use #include "..." to make pre-processor
include DT in the same directory, but this is one of the exceptional
files that use #include <...> for that.
Fix it to remove -I$(srctree)/arch/$(SRCARCH)/boot/dts path from
dtc_cpp_flags.
ARM: dts: versatile: use #include "..." to include DT in the same directory
Most of DT files in ARM use #include "..." to make pre-processor
include DT in the same directory, but we have 3 exceptional files
that use #include <...> for that.
They must be fixed to remove -I$(srctree)/arch/$(SRCARCH)/boot/dts
path from dtc_cpp_flags.
Signed-off-by: Masahiro Yamada
---
Arnd, Olof,
I could not find a sub-arch maintainer for versatile.
If nobody picks up this, could you take care of this?
arch/arm/boot/dts/versatile-pb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/versatile-pb.dts
b/arch/arm/boot/dts/versatile-pb.dts
index 33a8eb28374e..06e2331f666d 100644
--- a/arch/arm/boot/dts/versatile-pb.dts
+++ b/arch/arm/boot/dts/versatile-pb.dts
@@ -1,4 +1,4 @@
-#include
+#include "versatile-ab.dts"
/ {
model = "ARM Versatile PB";
--
2.7.4
Re: [PATCH 2/5] ARM: dts: use #include "..." to include DT in the same directory
Hi Shawn, 2017-05-15 22:10 GMT+09:00 Shawn Guo : > Hi Masahiro, > > On Mon, May 15, 2017 at 08:14:45PM +0900, Masahiro Yamada wrote: >> Most of DT files in ARM use #include "..." to make pre-processor >> include DT in the same directory, but we have 3 exceptional files >> that use #include <...> for that. >> >> They must be fixed to remove -I$(srctree)/arch/$(SRCARCH)/boot/dts >> path from dtc_cpp_flags. >> >> Signed-off-by: Masahiro Yamada >> --- >> >> arch/arm/boot/dts/imx6q-zii-rdu2.dts | 4 ++-- >> arch/arm/boot/dts/imx6qp-zii-rdu2.dts | 4 ++-- > > I see this patch depends on nothing and can be applied immediately. But > versatile-pb.dts is not really in my charge. In case you want to get > this series merged by arm-soc folks, here is my ACK: > > Acked-by: Shawn Guo > > Or you need to split versatile-pb.dts out, and then I can take it. > > Shawn I split it out. Please pick up the imx6 one. Thanks! -- Best Regards Masahiro Yamada
[PATCH] ARM: dts: imx6: use #include "..." to include local DT
Most of DT files in ARM use #include "..." to make pre-processor
include DT in the same directory, but we have some exceptional files
that use #include <...> for that.
Fix them to remove -I$(srctree)/arch/$(SRCARCH)/boot/dts path from
dtc_cpp_flags.
Signed-off-by: Masahiro Yamada
---
arch/arm/boot/dts/imx6q-zii-rdu2.dts | 4 ++--
arch/arm/boot/dts/imx6qp-zii-rdu2.dts | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-zii-rdu2.dts
b/arch/arm/boot/dts/imx6q-zii-rdu2.dts
index b2d346640fd7..6be8a1eea895 100644
--- a/arch/arm/boot/dts/imx6q-zii-rdu2.dts
+++ b/arch/arm/boot/dts/imx6q-zii-rdu2.dts
@@ -41,8 +41,8 @@
/dts-v1/;
-#include
-#include
+#include "imx6q.dtsi"
+#include "imx6qdl-zii-rdu2.dtsi"
/ {
model = "ZII RDU2 Board";
diff --git a/arch/arm/boot/dts/imx6qp-zii-rdu2.dts
b/arch/arm/boot/dts/imx6qp-zii-rdu2.dts
index 882b3bd97e07..547a76677ab3 100644
--- a/arch/arm/boot/dts/imx6qp-zii-rdu2.dts
+++ b/arch/arm/boot/dts/imx6qp-zii-rdu2.dts
@@ -41,8 +41,8 @@
/dts-v1/;
-#include
-#include
+#include "imx6qp.dtsi"
+#include "imx6qdl-zii-rdu2.dtsi"
/ {
model = "ZII RDU2+ Board";
--
2.7.4
[PATCH] serial: 8250_of: Add reset support
This adds the hooks for an optional reset controller in the 8250 device
tree node.
Signed-off-by: Joel Stanley
---
Documentation/devicetree/bindings/serial/8250.txt | 1 +
drivers/tty/serial/8250/8250_of.c | 16
2 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.txt
b/Documentation/devicetree/bindings/serial/8250.txt
index 10276a46ecef..63e32393f82b 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -45,6 +45,7 @@ Optional properties:
property.
- tx-threshold: Specify the TX FIFO low water indication for parts with
programmable TX FIFO thresholds.
+- resets : phandle + reset specifier pairs
Note:
* fsl,ns16550:
diff --git a/drivers/tty/serial/8250/8250_of.c
b/drivers/tty/serial/8250/8250_of.c
index 1cbadafc6889..f34dd23376f4 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -19,11 +19,13 @@
#include
#include
#include
+#include
#include "8250.h"
struct of_serial_info {
struct clk *clk;
+ struct reset_control *rst;
int type;
int line;
};
@@ -132,6 +134,18 @@ static int of_platform_serial_setup(struct platform_device
*ofdev,
}
}
+ info->rst = devm_reset_control_get_optional(&ofdev->dev, NULL);
+ if (IS_ERR(info->rst)) {
+ ret = PTR_ERR(info->rst);
+ if (ret == -EPROBE_DEFER)
+ goto out;
+ info->rst = NULL;
+ } else {
+ ret = reset_control_deassert(info->rst);
+ if (ret)
+ goto out;
+ }
+
port->type = type;
port->uartclk = clk;
port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
@@ -231,6 +245,8 @@ static int of_platform_serial_remove(struct platform_device
*ofdev)
if (info->clk)
clk_disable_unprepare(info->clk);
+ if (info->rst)
+ reset_control_assert(info->rst);
kfree(info);
return 0;
}
--
2.11.0
Re: [DT Question] "simple-mfd" DT binding
Hi Lee, 2017-05-23 16:05 GMT+09:00 Lee Jones : > On Tue, 23 May 2017, Masahiro Yamada wrote: > >> Hi Lee, Linus, >> >> Thanks for your comments! >> >> 2017-05-22 17:43 GMT+09:00 Linus Walleij : >> > On Mon, May 22, 2017 at 3:29 AM, Masahiro Yamada >> > wrote: >> > >> >> Because "simple-bus" indicates that child nodes are >> >> simply memory mapped, but the node "register-bit-led" >> >> can not be memory-mapped. >> >> So, "simple-mfd" can not be replaced "simple-bus" here. >> > >> > Yeah... just like Lee points out, you are spot on, this is exactly >> > the reason why we created "simple-mfd" in the first place >> > IIRC. >> >> OK, Linux treats simple-bus and simple-mfd in the same way >> as far as I see drivers/of/platform.c > > Correct. As I said, the functionality of the two are the same. The > difference is their meaning. Initially we were using "simple-mfd" to > achieve our aim (see below), but there was push-back due to the > differences in what the two properties were trying to achieve. Ergo, > we introduced a second property. > >> Perhaps, can we document the difference between simple-bus and >> simple-mfd clearly? >> For example, "Unlike simple-bus, it is legitimate that simple-mfd has >> subnodes without reg property" >> >> >> I think this is typical when "simple-mfd" is used together with "syscon". >> The child devices will use regmap of the parent node. >> I'd like to be sure this is valid usage. > > "simple-mfd" simply means "register all of my child nodes using the > platform API without any further intervention". It's goal is to > prevent the MFD subsystem from being stuffed full of drivers where > their only purpose is to call of_platform_populate(). All other rules > and policy which must be followed are generic DT ones. To that end, I > do not believe making further statements is necessary. I see. Thanks for your kind explanation! -- Best Regards Masahiro Yamada
[PATCH 27/27] Drivers: ccree: cc_crypto_ctx.h - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/cc_crypto_ctx.h | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h
b/drivers/staging/ccree/cc_crypto_ctx.h
index 216d24791d5d..dcec9a649a84 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -219,7 +219,8 @@ struct drv_ctx_hash {
};
/* drv_ctx_hmac should have the same structure as drv_ctx_hash except
- k0, k0_size fields */
+ * k0, k0_size fields
+ */
struct drv_ctx_hmac {
enum drv_crypto_alg alg; /* DRV_CRYPTO_ALG_HMAC */
enum drv_hash_mode mode;
@@ -240,9 +241,10 @@ struct drv_ctx_cipher {
u32 key_size; /* numeric value in bytes */
u32 data_unit_size; /* required for XTS */
/* block_state is the AES engine block state.
- * It is used by the host to pass IV or counter at initialization.
- * It is used by SeP for intermediate block chaining state and for
- * returning MAC algorithms results. */
+* It is used by the host to pass IV or counter at initialization.
+* It is used by SeP for intermediate block chaining state and for
+* returning MAC algorithms results.
+ */
u8 block_state[CC_AES_BLOCK_SIZE];
u8 key[CC_AES_KEY_SIZE_MAX];
u8 xex_key[CC_AES_KEY_SIZE_MAX];
@@ -279,9 +281,10 @@ struct drv_ctx_aead {
/* Get the address of a @member within a given @ctx address
- @ctx: The context address
- @type: Type of context structure
- @member: Associated context field */
+ * @ctx: The context address
+ * @type: Type of context structure
+ * @member: Associated context field
+ */
#define GET_CTX_FIELD_ADDR(ctx, type, member) (ctx + offsetof(type, member))
#endif /* _CC_CRYPTO_CTX_H_ */
--
2.12.2
[PATCH 26/27] Drivers: ccree: cc_hw_queue_defs.h - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/cc_hw_queue_defs.h | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h
b/drivers/staging/ccree/cc_hw_queue_defs.h
index 71381760566d..bb64fddc371d 100644
--- a/drivers/staging/ccree/cc_hw_queue_defs.h
+++ b/drivers/staging/ccree/cc_hw_queue_defs.h
@@ -23,8 +23,8 @@
#include "dx_crys_kernel.h"
/**
-* DEFINITIONS
-**/
+ * DEFINITIONS
+
**/
/* Dma AXI Secure bit */
#defineAXI_SECURE 0
@@ -36,8 +36,8 @@
#define _HW_DESC_MONITOR_KICK 0x7FFFC00
/**
-* TYPE DEFINITIONS
-**/
+ * TYPE DEFINITIONS
+
**/
struct cc_hw_desc {
u32 word[HW_DESC_SIZE_WORDS];
@@ -400,7 +400,7 @@ enum cc_hw_des_key_size {
*
* \param pDesc pointer HW descriptor struct
* \param numRounds number of rounds for Multi2
-*/
+ */
#define HW_DESC_SET_MULTI2_NUM_ROUNDS(pDesc, numRounds)
\
do {
\
CC_REG_FLD_SET(CRY_KERNEL, DSCRPTR_QUEUE_WORD2, VALUE,
(pDesc)->word[2], (u32)(numRounds)); \
@@ -411,7 +411,7 @@ enum cc_hw_des_key_size {
*
* \param pDesc pointer HW descriptor struct
* \param flowMode Any one of the modes defined in [CC7x-DESC]
-*/
+ */
#define HW_DESC_SET_FLOW_MODE(pDesc, flowMode)
\
do {
\
@@ -423,7 +423,7 @@ enum cc_hw_des_key_size {
*
* \param pDesc pointer HW descriptor struct
* \param cipherMode Any one of the modes defined in [CC7x-DESC]
-*/
+ */
#define HW_DESC_SET_CIPHER_MODE(pDesc, cipherMode)
\
do {
\
CC_REG_FLD_SET(CRY_KERNEL, DSCRPTR_QUEUE_WORD4, CIPHER_MODE,
(pDesc)->word[4], (cipherMode)); \
@@ -434,7 +434,7 @@ enum cc_hw_des_key_size {
*
* \param pDesc pointer HW descriptor struct
* \param cipherConfig Any one of the modes defined in [CC7x-DESC]
-*/
+ */
#define HW_DESC_SET_CIPHER_CONFIG0(pDesc, cipherConfig)
\
do {
\
CC_REG_FLD_SET(CRY_KERNEL, DSCRPTR_QUEUE_WORD4, CIPHER_CONF0,
(pDesc)->word[4], (cipherConfig));\
@@ -445,7 +445,7 @@ enum cc_hw_des_key_size {
*
* \param pDesc pointer HW descriptor struct
* \param cipherConfig Any one of the modes defined in [CC7x-DESC]
-*/
+ */
#define HW_DESC_SET_CIPHER_CONFIG1(pDesc, cipherConfig)
\
do {
\
CC_REG_FLD_SET(CRY_KERNEL, DSCRPTR_QUEUE_WORD4, CIPHER_CONF1,
(pDesc)->word[4], (cipherConfig));\
@@ -456,7 +456,7 @@ enum cc_hw_des_key_size {
*
* \param pDesc pointer HW descriptor struct
* \param hwKey The hw key number as in enun HwCryptoKey
-*/
+ */
#define HW_DESC_SET_HW_CRYPTO_KEY(pDesc, hwKey)
\
do {
\
CC_REG_FLD_SET(CRY_KERNEL, DSCRPTR_QUEUE_WORD4, CIPHER_DO,
(pDesc)->word[4], (hwKey) & HW_KEY_MASK_CIPHER_DO); \
@@ -468,7 +468,7 @@ enum cc_hw_des_key_size {
*
* \param pDesc pointer HW descriptor struct
* \param swapConfig Any one of the modes defined in [CC7x-DESC]
-*/
+ */
#define HW_DESC_SET_BYTES_SWAP(pDesc, swapConfig)
\
do {
\
CC_REG_FLD_SET(CRY_KERNEL, DSCRPTR_QUEUE_WORD4, BYTES_
[PATCH 25/27] Drivers: ccree: cc_regs.h - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/cc_regs.h | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/ccree/cc_regs.h b/drivers/staging/ccree/cc_regs.h
index 8b89f0603f16..f4b3b5a23ae2 100644
--- a/drivers/staging/ccree/cc_regs.h
+++ b/drivers/staging/ccree/cc_regs.h
@@ -55,8 +55,9 @@ do {
\
BITFIELD_GET(reg_val, CC_ ## reg_name ## _ ## fld_name ## _BIT_SHIFT, \
CC_ ## reg_name ## _ ## fld_name ## _BIT_SIZE))
-/* yael TBD !!! -*
-* all HW includes should start with CC_ and not DX_ !! */
+/* yael TBD !!!
+ * all HW includes should start with CC_ and not DX_ !!
+ */
/*! Bit fields set */
@@ -86,10 +87,10 @@ do {
\
} while (0)
/* Usage example:
- u32 reg_shadow = READ_REGISTER(CC_REG_ADDR(CRY_KERNEL,AES_CONTROL));
- CC_REG_FLD_SET(CRY_KERNEL,AES_CONTROL,NK_KEY0,reg_shadow, 3);
- CC_REG_FLD_SET(CRY_KERNEL,AES_CONTROL,NK_KEY1,reg_shadow, 1);
- WRITE_REGISTER(CC_REG_ADDR(CRY_KERNEL,AES_CONTROL), reg_shadow);
+ * u32 reg_shadow = READ_REGISTER(CC_REG_ADDR(CRY_KERNEL,AES_CONTROL));
+ * CC_REG_FLD_SET(CRY_KERNEL,AES_CONTROL,NK_KEY0,reg_shadow, 3);
+ * CC_REG_FLD_SET(CRY_KERNEL,AES_CONTROL,NK_KEY1,reg_shadow, 1);
+ * WRITE_REGISTER(CC_REG_ADDR(CRY_KERNEL,AES_CONTROL), reg_shadow);
*/
#endif /*_CC_REGS_H_*/
--
2.12.2
[PATCH 24/27] Drivers: ccree: hash_defs.h - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/hash_defs.h | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/ccree/hash_defs.h
b/drivers/staging/ccree/hash_defs.h
index 613897038f6d..3f2b2d1521c2 100644
--- a/drivers/staging/ccree/hash_defs.h
+++ b/drivers/staging/ccree/hash_defs.h
@@ -59,13 +59,14 @@ enum HashCipherDoPadding {
typedef struct SepHashPrivateContext {
/* The current length is placed at the end of the context buffer
because the hash
- context is used for all HMAC operations as well. HMAC context
includes a 64 bytes
- K0 field. The size of struct drv_ctx_hash reserved field is 88/184
bytes depend if t
- he SHA512 is supported ( in this case teh context size is 256 bytes).
- The size of struct drv_ctx_hash reseved field is 20 or 52 depend if
the SHA512 is supported.
- This means that this structure size (without the reserved field can
be up to 20 bytes ,
- in case sha512 is not suppported it is 20 bytes
(SEP_HASH_LENGTH_WORDS define to 2 ) and in the other
- case it is 28 (SEP_HASH_LENGTH_WORDS define to 4) */
+* context is used for all HMAC operations as well. HMAC context
includes a 64 bytes
+* K0 field. The size of struct drv_ctx_hash reserved field is
88/184 bytes depend if t
+* he SHA512 is supported ( in this case teh context size is 256
bytes).
+* The size of struct drv_ctx_hash reseved field is 20 or 52 depend if
the SHA512 is supported.
+* This means that this structure size (without the reserved field can
be up to 20 bytes ,
+* in case sha512 is not suppported it is 20 bytes
(SEP_HASH_LENGTH_WORDS define to 2 ) and in the other
+* case it is 28 (SEP_HASH_LENGTH_WORDS define to 4)
+*/
u32 reserved[(sizeof(struct drv_ctx_hash)/sizeof(u32)) -
SEP_HASH_LENGTH_WORDS - 3];
u32 CurrentDigestedLength[SEP_HASH_LENGTH_WORDS];
u32 KeyType;
--
2.12.2
[PATCH 23/27] Drivers: ccree: ssi_aead.c - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/ssi_aead.c | 45 ++--
1 file changed, 29 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 26afa8794668..ecf9ff2ae336 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -250,7 +250,8 @@ static void ssi_aead_complete(struct device *dev, void
*ssi_req, void __iomem *c
"(auth-size=%d, cipher=%d).\n",
ctx->authsize, ctx->cipher_mode);
/* In case of payload authentication failure, MUST NOT
- revealed the decrypted message --> zero its memory.
*/
+* revealed the decrypted message --> zero its memory.
+*/
ssi_buffer_mgr_zero_sgl(areq->dst, areq_ctx->cryptlen);
err = -EBADMSG;
}
@@ -279,7 +280,8 @@ static int xcbc_setkey(struct cc_hw_desc *desc, struct
ssi_aead_ctx *ctx)
/* Load the AES key */
HW_DESC_INIT(&desc[0]);
/* We are using for the source/user key the same buffer as for the
output keys,
- because after this key loading it is not needed anymore */
+* because after this key loading it is not needed anymore
+*/
HW_DESC_SET_DIN_TYPE(&desc[0], DMA_DLLI,
ctx->auth_state.xcbc.xcbc_keys_dma_addr, ctx->auth_keylen, NS_BIT);
HW_DESC_SET_CIPHER_MODE(&desc[0], DRV_CIPHER_ECB);
HW_DESC_SET_CIPHER_CONFIG0(&desc[0], DRV_CRYPTO_DIRECTION_ENCRYPT);
@@ -420,8 +422,9 @@ static int validate_keys_sizes(struct ssi_aead_ctx *ctx)
return 0; /* All tests of keys sizes passed */
}
-/*This function prepers the user key so it can pass to the hmac processing
- (copy to intenral buffer or hash in case of key longer than block */
+/* This function prepers the user key so it can pass to the hmac processing
+ * (copy to intenral buffer or hash in case of key longer than block
+ */
static int
ssi_get_plain_hmac_key(struct crypto_aead *tfm, const u8 *key, unsigned int
keylen)
{
@@ -600,7 +603,8 @@ ssi_aead_setkey(struct crypto_aead *tfm, const u8 *key,
unsigned int keylen)
(AES_MIN_KEY_SIZE + CTR_RFC3686_NONCE_SIZE))
goto badkey;
/* Copy nonce from last 4 bytes in CTR key to
- * first 4 bytes in CTR IV */
+* first 4 bytes in CTR IV
+*/
memcpy(ctx->ctr_nonce, key + ctx->auth_keylen +
ctx->enc_keylen -
CTR_RFC3686_NONCE_SIZE, CTR_RFC3686_NONCE_SIZE);
/* Set CTR key size */
@@ -829,7 +833,8 @@ ssi_aead_process_authenc_data_desc(
{
/* DOUBLE-PASS flow (as default)
* assoc. + iv + data -compact in one table
-* if assoclen is ZERO only IV perform */
+* if assoclen is ZERO only IV perform
+*/
ssi_sram_addr_t mlli_addr = areq_ctx->assoc.sram_addr;
u32 mlli_nents = areq_ctx->assoc.mlli_nents;
@@ -1287,7 +1292,8 @@ static inline void ssi_aead_hmac_authenc(
/**
* Double-pass flow
* Fallback for unsupported single-pass modes,
-* i.e. using assoc. data of non-word-multiple */
+* i.e. using assoc. data of non-word-multiple
+*/
if (direct == DRV_CRYPTO_DIRECTION_ENCRYPT) {
/* encrypt first.. */
ssi_aead_process_cipher(req, desc, seq_size, data_flow_mode);
@@ -1305,7 +1311,8 @@ static inline void ssi_aead_hmac_authenc(
/* decrypt after.. */
ssi_aead_process_cipher(req, desc, seq_size, data_flow_mode);
/* read the digest result with setting the completion bit
- must be after the cipher operation */
+* must be after the cipher operation
+*/
ssi_aead_process_digest_result_desc(req, desc, seq_size);
}
}
@@ -1338,7 +1345,8 @@ ssi_aead_xcbc_authenc(
/**
* Double-pass flow
* Fallback for unsupported single-pass modes,
-* i.e. using assoc. data of non-word-multiple */
+* i.e. using assoc. data of non-word-multiple
+*/
if (direct == DRV_CRYPTO_DIRECTION_ENCRYPT) {
/* encrypt first.. */
ssi_aead_process_cipher(req, desc, seq_size, data_flow_mode);
@@ -1353,7 +1361,8 @@ ssi_aead_xcbc_authenc(
/* decrypt after..*/
ssi_aead_process_cipher(req, desc, seq_size, data_flow_mode);
/* read the digest result with setting the completion bit
- must be after the cipher operation */
+
[PATCH 22/27] Drivers: ccree: ssi_aead.h - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/ssi_aead.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.h b/drivers/staging/ccree/ssi_aead.h
index 654a181729d7..00a3680cb8ab 100644
--- a/drivers/staging/ccree/ssi_aead.h
+++ b/drivers/staging/ccree/ssi_aead.h
@@ -15,7 +15,7 @@
*/
/* \file ssi_aead.h
- ARM CryptoCell AEAD Crypto API
+ * ARM CryptoCell AEAD Crypto API
*/
#ifndef __SSI_AEAD_H__
@@ -62,8 +62,9 @@ enum aead_ccm_header_size {
struct aead_req_ctx {
/* Allocate cache line although only 4 bytes are needed to
- * assure next field falls @ cache line
- * Used for both: digest HW compare and CCM/GCM MAC value */
+* assure next field falls @ cache line
+* Used for both: digest HW compare and CCM/GCM MAC value
+*/
u8 mac_buf[MAX_MAC_SIZE] cacheline_aligned;
u8 ctr_iv[AES_BLOCK_SIZE] cacheline_aligned;
--
2.12.2
[PATCH 21/27] Drivers: ccree: ssi_buffer_mgr.c - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/ssi_buffer_mgr.c | 87 +++---
1 file changed, 49 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 77e490968db9..db6333ae5612 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -330,7 +330,8 @@ static int ssi_buffer_mgr_generate_mlli(
/* set last bit in the current table */
if (sg_data->mlli_nents[i] != NULL) {
/*Calculate the current MLLI table length for the
- length field in the descriptor*/
+*length field in the descriptor
+*/
*(sg_data->mlli_nents[i]) +=
(total_nents - prev_total_nents);
prev_total_nents = total_nents;
@@ -463,7 +464,8 @@ static int ssi_buffer_mgr_map_scatterlist(
}
if (!is_chained) {
/* In case of mmu the number of mapped nents might
- be changed from the original sgl nents */
+* be changed from the original sgl nents
+*/
*mapped_nents = dma_map_sg(dev, sg, *nents, direction);
if (unlikely(*mapped_nents == 0)){
*nents = 0;
@@ -472,7 +474,8 @@ static int ssi_buffer_mgr_map_scatterlist(
}
} else {
/*In this case the driver maps entry by entry so it
- must have the same nents before and after map */
+* must have the same nents before and after map
+*/
*mapped_nents = ssi_buffer_mgr_dma_map_sg(dev,
sg,
*nents,
@@ -764,7 +767,8 @@ void ssi_buffer_mgr_unmap_aead_request(
}
/*In case a pool was set, a table was
- allocated and should be released */
+*allocated and should be released
+*/
if (areq_ctx->mlli_params.curr_pool != NULL) {
SSI_LOG_DEBUG("free MLLI buffer: dma=0x%08llX virt=%pK\n",
(unsigned long long)areq_ctx->mlli_params.mlli_dma_addr,
@@ -801,7 +805,8 @@ void ssi_buffer_mgr_unmap_aead_request(
size_to_skip += crypto_aead_ivsize(tfm);
}
/* copy mac to a temporary location to deal with possible
- data memory overriding that caused by cache coherence
problem. */
+* data memory overriding that caused by cache coherence
problem.
+*/
ssi_buffer_mgr_copy_scatterlist_portion(
areq_ctx->backup_mac, req->src,
size_to_skip+ req->cryptlen - areq_ctx->req_authsize,
@@ -965,7 +970,8 @@ static inline int ssi_buffer_mgr_aead_chain_assoc(
areq_ctx->assoc.nents = mapped_nents;
/* in CCM case we have additional entry for
- * ccm header configurations */
+* ccm header configurations
+*/
if (areq_ctx->ccm_hdr_size != ccm_header_size_null) {
if (unlikely((mapped_nents + 1) >
LLI_MAX_NUM_OF_ASSOC_DATA_ENTRIES)) {
@@ -1068,13 +1074,15 @@ static inline int ssi_buffer_mgr_prepare_aead_data_mlli(
if (unlikely(areq_ctx->is_icv_fragmented == true)) {
/* Backup happens only when ICV is fragmented, ICV
- verification is made by CPU compare in order to
simplify
- MAC verification upon request completion */
+* verification is made by CPU compare in order to
simplify
+* MAC verification upon request completion
+*/
if (direct == DRV_CRYPTO_DIRECTION_DECRYPT) {
#if !DX_HAS_ACP
/* In ACP platform we already copying ICV
- for any INPLACE-DECRYPT operation, hence
- we must neglect this code. */
+* for any INPLACE-DECRYPT operation, hence
+* we must neglect this code.
+*/
u32 size_to_skip = req->assoclen;
if (areq_ctx->is_gcm4543) {
size_to_skip += crypto_aead_ivsize(tfm);
@@ -1120,8 +1128,9 @@ static inline int ssi_buffer_mgr_prepare_aead_data_mlli(
if (unlikely(areq_ctx->is_icv_fragmented == true)) {
[PATCH 20/27] Drivers: ccree: ssi_buffer_mgr.h - align block comments
Fixed block comment alignment, Style fix only Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/ccree/ssi_buffer_mgr.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_buffer_mgr.h b/drivers/staging/ccree/ssi_buffer_mgr.h index 4acbb4b6afc9..98355dd789e5 100644 --- a/drivers/staging/ccree/ssi_buffer_mgr.h +++ b/drivers/staging/ccree/ssi_buffer_mgr.h @@ -15,7 +15,7 @@ */ /* \file buffer_mgr.h - Buffer Manager + * Buffer Manager */ #ifndef __SSI_BUFFER_MGR_H__ -- 2.12.2
[PATCH 18/27] Drivers: ccree: ssi_config.h - align block comments
Fixed block comment alignment, Style fix only Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/ccree/ssi_config.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/ccree/ssi_config.h b/drivers/staging/ccree/ssi_config.h index 431b518d893a..9feb692fff0d 100644 --- a/drivers/staging/ccree/ssi_config.h +++ b/drivers/staging/ccree/ssi_config.h @@ -15,7 +15,7 @@ */ /* \file ssi_config.h - Definitions for ARM CryptoCell Linux Crypto Driver + * Definitions for ARM CryptoCell Linux Crypto Driver */ #ifndef __SSI_CONFIG_H__ @@ -49,7 +49,8 @@ #define SSI_CACHE_PARAMS (0x000) /* CC attached to NONE-ACP such as HPP/ACE/AMBA4. * The customer is responsible to enable/disable this feature -* according to his platform type. */ +* according to his platform type. +*/ #define DX_HAS_ACP 0 #else #define SSI_CACHE_PARAMS (0xEEE) -- 2.12.2
[PATCH 19/27] Drivers: ccree: ssi_cipher.h - align block comments
Fixed block comment alignment, Style fix only Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/ccree/ssi_cipher.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_cipher.h b/drivers/staging/ccree/ssi_cipher.h index 7d58b56fc2c7..22d7b431edb9 100644 --- a/drivers/staging/ccree/ssi_cipher.h +++ b/drivers/staging/ccree/ssi_cipher.h @@ -15,7 +15,7 @@ */ /* \file ssi_cipher.h - ARM CryptoCell Cipher Crypto API + * ARM CryptoCell Cipher Crypto API */ #ifndef __SSI_CIPHER_H__ -- 2.12.2
[PATCH 17/27] Drivers: ccree: ssi_driver.h - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/ssi_driver.h | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/ccree/ssi_driver.h
b/drivers/staging/ccree/ssi_driver.h
index 45fc23fe169f..e034b0987137 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -15,7 +15,7 @@
*/
/* \file ssi_driver.h
- ARM CryptoCell Linux Crypto Driver
+ * ARM CryptoCell Linux Crypto Driver
*/
#ifndef __SSI_DRIVER_H__
@@ -86,7 +86,8 @@
#define NS_BIT 1
#define AXI_ID 0
/* AXI_ID is not actually the AXI ID of the transaction but the value of AXI_ID
- field in the HW descriptor. The DMA engine +8 that value. */
+ * field in the HW descriptor. The DMA engine +8 that value.
+ */
/* Logging macros */
#define SSI_LOG(level, format, ...) \
@@ -108,9 +109,11 @@
struct ssi_crypto_req {
void (*user_cb)(struct device *dev, void *req, void __iomem *cc_base);
void *user_arg;
- dma_addr_t ivgen_dma_addr[SSI_MAX_IVGEN_DMA_ADDRESSES]; /* For the
first 'ivgen_dma_addr_len' addresses of this array,
-generated IV would be placed in it by
send_request().
-Same generated IV for all addresses! */
+ dma_addr_t ivgen_dma_addr[SSI_MAX_IVGEN_DMA_ADDRESSES];
+ /* For the first 'ivgen_dma_addr_len' addresses of this array,
+* generated IV would be placed in it by send_request().
+* Same generated IV for all addresses!
+*/
unsigned int ivgen_dma_addr_len; /* Amount of 'ivgen_dma_addr' elements
to be filled. */
unsigned int ivgen_size; /* The generated IV size required, 8/16 B
allowed. */
struct completion seq_compl; /* request completion */
@@ -136,7 +139,8 @@ struct ssi_drvdata {
u32 irq_mask;
u32 fw_ver;
/* Calibration time of start/stop
- * monitor descriptors */
+* monitor descriptors
+*/
u32 monitor_null_cycles;
struct platform_device *plat_dev;
ssi_sram_addr_t mlli_sram_addr;
--
2.12.2
[PATCH 16/27] Drivers: ccree: ssi_fips.c - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/ssi_fips.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/ccree/ssi_fips.c b/drivers/staging/ccree/ssi_fips.c
index 25ee23a1cecf..60a2452f7b0b 100644
--- a/drivers/staging/ccree/ssi_fips.c
+++ b/drivers/staging/ccree/ssi_fips.c
@@ -16,8 +16,8 @@
/**
-This file defines the driver FIPS APIs
*
-***/
+ * This file defines the driver FIPS APIs *
+ **/
#include
#include "ssi_fips.h"
@@ -27,9 +27,9 @@ extern int ssi_fips_ext_get_state(ssi_fips_state_t *p_state);
extern int ssi_fips_ext_get_error(ssi_fips_error_t *p_err);
/*
-This function returns the REE FIPS state.
-It should be called by kernel module.
-*/
+ * This function returns the REE FIPS state.
+ * It should be called by kernel module.
+ */
int ssi_fips_get_state(ssi_fips_state_t *p_state)
{
int rc = 0;
@@ -46,9 +46,9 @@ int ssi_fips_get_state(ssi_fips_state_t *p_state)
EXPORT_SYMBOL(ssi_fips_get_state);
/*
-This function returns the REE FIPS error.
-It should be called by kernel module.
-*/
+ * This function returns the REE FIPS error.
+ * It should be called by kernel module.
+ */
int ssi_fips_get_error(ssi_fips_error_t *p_err)
{
int rc = 0;
--
2.12.2
[PATCH 15/27] Drivers: ccree: ssi_fips.h - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/ssi_fips.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ccree/ssi_fips.h b/drivers/staging/ccree/ssi_fips.h
index 607c64b8c458..e108d89ef98c 100644
--- a/drivers/staging/ccree/ssi_fips.h
+++ b/drivers/staging/ccree/ssi_fips.h
@@ -18,9 +18,9 @@
#define __SSI_FIPS_H__
/*!
-@file
-@brief This file contains FIPS related defintions and APIs.
-*/
+ * @file
+ * @brief This file contains FIPS related defintions and APIs.
+ */
typedef enum ssi_fips_state {
CC_FIPS_STATE_NOT_SUPPORTED = 0,
--
2.12.2
[PATCH 14/27] Drivers: ccree: ssi_fips_data.h - align block comments
Fixed block comment alignment, Style fix only Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/ccree/ssi_fips_data.h | 93 +-- 1 file changed, 46 insertions(+), 47 deletions(-) diff --git a/drivers/staging/ccree/ssi_fips_data.h b/drivers/staging/ccree/ssi_fips_data.h index a4b78f1b4d48..a2aaa925ba38 100644 --- a/drivers/staging/ccree/ssi_fips_data.h +++ b/drivers/staging/ccree/ssi_fips_data.h @@ -15,53 +15,52 @@ */ /* -The test vectors were taken from: - -* AES -NIST Special Publication 800-38A 2001 Edition -Recommendation for Block Cipher Modes of Operation -http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf -Appendix F: Example Vectors for Modes of Operation of the AES - -* AES CTS -Advanced Encryption Standard (AES) Encryption for Kerberos 5 -February 2005 -https://tools.ietf.org/html/rfc3962#appendix-B -B. Sample Test Vectors - -* AES XTS -http://csrc.nist.gov/groups/STM/cavp/#08 -http://csrc.nist.gov/groups/STM/cavp/documents/aes/XTSTestVectors.zip - -* AES CMAC -http://csrc.nist.gov/groups/STM/cavp/index.html#07 -http://csrc.nist.gov/groups/STM/cavp/documents/mac/cmactestvectors.zip - -* AES-CCM -http://csrc.nist.gov/groups/STM/cavp/#07 -http://csrc.nist.gov/groups/STM/cavp/documents/mac/ccmtestvectors.zip - -* AES-GCM -http://csrc.nist.gov/groups/STM/cavp/documents/mac/gcmtestvectors.zip - -* Triple-DES -NIST Special Publication 800-67 January 2012 -Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher -http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf -APPENDIX B: EXAMPLE OF TDEA FORWARD AND INVERSE CIPHER OPERATIONS -and -http://csrc.nist.gov/groups/STM/cavp/#01 -http://csrc.nist.gov/groups/STM/cavp/documents/des/tdesmct_intermediate.zip - -* HASH -http://csrc.nist.gov/groups/STM/cavp/#03 -http://csrc.nist.gov/groups/STM/cavp/documents/shs/shabytetestvectors.zip - -* HMAC -http://csrc.nist.gov/groups/STM/cavp/#07 -http://csrc.nist.gov/groups/STM/cavp/documents/mac/hmactestvectors.zip - -*/ + * The test vectors were taken from: + * + * * AES + * NIST Special Publication 800-38A 2001 Edition + * Recommendation for Block Cipher Modes of Operation + * http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf + * Appendix F: Example Vectors for Modes of Operation of the AES + * + * * AES CTS + * Advanced Encryption Standard (AES) Encryption for Kerberos 5 + * February 2005 + * https://tools.ietf.org/html/rfc3962#appendix-B + * B. Sample Test Vectors + * + * * AES XTS + * http://csrc.nist.gov/groups/STM/cavp/#08 + * http://csrc.nist.gov/groups/STM/cavp/documents/aes/XTSTestVectors.zip + * + * * AES CMAC + * http://csrc.nist.gov/groups/STM/cavp/index.html#07 + * http://csrc.nist.gov/groups/STM/cavp/documents/mac/cmactestvectors.zip + * + * * AES-CCM + * http://csrc.nist.gov/groups/STM/cavp/#07 + * http://csrc.nist.gov/groups/STM/cavp/documents/mac/ccmtestvectors.zip + * + * * AES-GCM + * http://csrc.nist.gov/groups/STM/cavp/documents/mac/gcmtestvectors.zip + * + * * Triple-DES + * NIST Special Publication 800-67 January 2012 + * Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher + * http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf + * APPENDIX B: EXAMPLE OF TDEA FORWARD AND INVERSE CIPHER OPERATIONS + * and + * http://csrc.nist.gov/groups/STM/cavp/#01 + * http://csrc.nist.gov/groups/STM/cavp/documents/des/tdesmct_intermediate.zip + * + * * HASH + * http://csrc.nist.gov/groups/STM/cavp/#03 + * http://csrc.nist.gov/groups/STM/cavp/documents/shs/shabytetestvectors.zip + * + * * HMAC + * http://csrc.nist.gov/groups/STM/cavp/#07 + * http://csrc.nist.gov/groups/STM/cavp/documents/mac/hmactestvectors.zip + */ /* NIST AES */ #define AES_128_BIT_KEY_SIZE16 -- 2.12.2
[PATCH 13/27] Drivers: ccree: ssi_fips_ext.c - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/ssi_fips_ext.c | 46 ++--
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/ccree/ssi_fips_ext.c
b/drivers/staging/ccree/ssi_fips_ext.c
index 291a880f567c..0f53a4bc43de 100644
--- a/drivers/staging/ccree/ssi_fips_ext.c
+++ b/drivers/staging/ccree/ssi_fips_ext.c
@@ -15,9 +15,9 @@
*/
/**
-This file defines the driver FIPS functions that should be
-implemented by the driver user. Current implementation is sample code only.
-***/
+ * This file defines the driver FIPS functions that should be
+ * implemented by the driver user. Current implementation is sample code only.
+ ***/
#include
#include "ssi_fips_local.h"
@@ -32,11 +32,11 @@ static ssi_fips_state_t fips_state =
CC_FIPS_STATE_NOT_SUPPORTED;
static ssi_fips_error_t fips_error = CC_REE_FIPS_ERROR_OK;
/*
-This function returns the FIPS REE state.
-The function should be implemented by the driver user, depends on where
.
-the state value is stored.
-The reference code uses global variable.
-*/
+ * This function returns the FIPS REE state.
+ * The function should be implemented by the driver user, depends on where
+ * the state value is stored.
+ * The reference code uses global variable.
+ */
int ssi_fips_ext_get_state(ssi_fips_state_t *p_state)
{
int rc = 0;
@@ -51,11 +51,11 @@ int ssi_fips_ext_get_state(ssi_fips_state_t *p_state)
}
/*
-This function returns the FIPS REE error.
-The function should be implemented by the driver user, depends on where
.
-the error value is stored.
-The reference code uses global variable.
-*/
+ * This function returns the FIPS REE error.
+ * The function should be implemented by the driver user, depends on where
+ * the error value is stored.
+ * The reference code uses global variable.
+ */
int ssi_fips_ext_get_error(ssi_fips_error_t *p_err)
{
int rc = 0;
@@ -70,11 +70,11 @@ int ssi_fips_ext_get_error(ssi_fips_error_t *p_err)
}
/*
-This function sets the FIPS REE state.
-The function should be implemented by the driver user, depends on where
.
-the state value is stored.
-The reference code uses global variable.
-*/
+ * This function sets the FIPS REE state.
+ * The function should be implemented by the driver user, depends on where
+ * the state value is stored.
+ * The reference code uses global variable.
+ */
int ssi_fips_ext_set_state(ssi_fips_state_t state)
{
fips_state = state;
@@ -82,11 +82,11 @@ int ssi_fips_ext_set_state(ssi_fips_state_t state)
}
/*
-This function sets the FIPS REE error.
-The function should be implemented by the driver user, depends on where
.
-the error value is stored.
-The reference code uses global variable.
-*/
+ * This function sets the FIPS REE error.
+ * The function should be implemented by the driver user, depends on where
+ * the error value is stored.
+ * The reference code uses global variable.
+ */
int ssi_fips_ext_set_error(ssi_fips_error_t err)
{
fips_error = err;
--
2.12.2
[PATCH 12/27] Drivers: ccree: ssi_fips_ll.c - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/ssi_fips_ll.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/ccree/ssi_fips_ll.c
b/drivers/staging/ccree/ssi_fips_ll.c
index 7c7c922f0788..cb487d747ee8 100644
--- a/drivers/staging/ccree/ssi_fips_ll.c
+++ b/drivers/staging/ccree/ssi_fips_ll.c
@@ -15,9 +15,9 @@
*/
/**
-This file defines the driver FIPS Low Level implmentaion functions,
-that executes the KAT.
-***/
+ * This file defines the driver FIPS Low Level implmentaion functions,
+ * that executes the KAT.
+ ***/
#include
#include "ssi_driver.h"
@@ -816,7 +816,8 @@ ssi_hmac_fips_run_test(struct ssi_drvdata *drvdata,
dma_addr_t digest_bytes_len_dma_addr)
{
/* The implemented flow is not the same as the one implemented in
ssi_hash.c (setkey + digest flows).
- In this flow, there is no need to store and reload some of the
intermidiate results. */
+* In this flow, there is no need to store and reload some of the
intermidiate results.
+*/
/* max number of descriptors used for the flow */
#define FIPS_HMAC_MAX_SEQ_LEN 12
@@ -948,9 +949,9 @@ ssi_hmac_fips_run_test(struct ssi_drvdata *drvdata,
idx++;
/* at this point:
- tmp_digest = H(o_key_pad)
- k0 = H(i_key_pad || m)
- */
+* tmp_digest = H(o_key_pad)
+* k0 = H(i_key_pad || m)
+*/
/* Loading hash opad xor key state */
HW_DESC_INIT(&desc[idx]);
@@ -1413,8 +1414,10 @@ ssi_gcm_fips_run_test(struct ssi_drvdata *drvdata,
idx++;
/* Configure Hash Engine to work with GHASH.
- Since it was not possible to extend HASH submodes to add GHASH,
- The following command is necessary in order to select GHASH
(according to HW designers)*/
+* Since it was not possible to extend HASH submodes to add GHASH,
+* The following command is necessary in order to
+* select GHASH (according to HW designers)
+*/
HW_DESC_INIT(&desc[idx]);
HW_DESC_SET_DIN_NO_DMA(&desc[idx], 0, 0xf0);
HW_DESC_SET_DOUT_NO_DMA(&desc[idx], 0, 0, 1);
--
2.12.2
[PATCH 10/27] Drivers: ccree: ssi_hash.c - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/ssi_hash.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index 162d17dee2cd..11b5eae1c55e 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -97,7 +97,8 @@ struct hash_key_req_ctx {
struct ssi_hash_ctx {
struct ssi_drvdata *drvdata;
/* holds the origin digest; the digest after "setkey" if HMAC,*
- the initial digest if HASH. */
+* the initial digest if HASH.
+*/
u8 digest_buff[SSI_MAX_HASH_DIGEST_SIZE] cacheline_aligned;
u8 opad_tmp_keys_buff[SSI_MAX_HASH_OPAD_TMP_KEYS_SIZE]
cacheline_aligned;
dma_addr_t opad_tmp_keys_dma_addr cacheline_aligned;
@@ -250,7 +251,8 @@ static int ssi_hash_map_request(struct device *dev,
}
} else { /*hash*/
/* Copy the initial digests if hash flow. The SRAM contains the
- initial digests in the expected order for all SHA* */
+* initial digests in the expected order for all SHA*
+*/
HW_DESC_INIT(&desc);
HW_DESC_SET_DIN_SRAM(&desc, larval_digest_addr,
ctx->inter_digestsize);
HW_DESC_SET_DOUT_DLLI(&desc, state->digest_buff_dma_addr,
ctx->inter_digestsize, NS_BIT, 0);
@@ -1027,7 +1029,8 @@ static int ssi_hash_setkey(void *hash,
ctx->drvdata, ctx->hash_mode);
/* The keylen value distinguishes HASH in case keylen is ZERO bytes,
- any NON-ZERO value utilizes HMAC flow */
+* any NON-ZERO value utilizes HMAC flow
+*/
ctx->key_params.keylen = keylen;
ctx->key_params.key_dma_addr = 0;
ctx->is_hmac = true;
--
2.12.2
[PATCH 11/27] Drivers: ccree: ssi_fips_local.c - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/ssi_fips_local.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/ccree/ssi_fips_local.c
b/drivers/staging/ccree/ssi_fips_local.c
index 316507d88b4e..8076c771f750 100644
--- a/drivers/staging/ccree/ssi_fips_local.c
+++ b/drivers/staging/ccree/ssi_fips_local.c
@@ -15,8 +15,8 @@
*/
/**
-This file defines the driver FIPS internal function, used by the driver itself.
-***/
+ * This file defines the driver FIPS internal function, used by the driver
itself.
+ ***/
#include
#include
#include
@@ -80,10 +80,10 @@ static enum ssi_fips_error ssi_fips_get_tee_error(struct
ssi_drvdata *drvdata)
/*
- This function should push the FIPS REE library status towards the TEE library.
- By writing the error state to HOST_GPR0 register. The function is called from
.
- driver entry point so no need to protect by mutex.
-*/
+ * This function should push the FIPS REE library status towards the TEE
library.
+ * By writing the error state to HOST_GPR0 register. The function is called
from
+ * driver entry point so no need to protect by mutex.
+ */
static void ssi_fips_update_tee_upon_ree_status(struct ssi_drvdata *drvdata,
ssi_fips_error_t err)
{
void __iomem *cc_base = drvdata->cc_base;
@@ -232,7 +232,8 @@ ssi_fips_error_t cc_fips_run_power_up_tests(struct
ssi_drvdata *drvdata)
/* The function checks if FIPS supported and FIPS error exists.*
-* It should be used in every driver API.*/
+ * It should be used in every driver API.
+ */
int ssi_fips_check_fips_error(void)
{
ssi_fips_state_t fips_state;
@@ -250,14 +251,16 @@ int ssi_fips_check_fips_error(void)
/* The function sets the REE FIPS state.*
-* It should be used while driver is being loaded .*/
+ * It should be used while driver is being loaded.
+ */
int ssi_fips_set_state(ssi_fips_state_t state)
{
return ssi_fips_ext_set_state(state);
}
/* The function sets the REE FIPS error, and pushes the error to TEE library. *
-* It should be used when any of the KAT tests fails .*/
+ * It should be used when any of the KAT tests fails.
+ */
int ssi_fips_set_error(struct ssi_drvdata *p_drvdata, ssi_fips_error_t err)
{
int rc = 0;
--
2.12.2
[PATCH 09/27] Drivers: ccree: ssi_hash.h - align block comments
Fixed block comment alignment, Style fix only Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/ccree/ssi_hash.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_hash.h b/drivers/staging/ccree/ssi_hash.h index b821d0c854b5..7c946614a1f9 100644 --- a/drivers/staging/ccree/ssi_hash.h +++ b/drivers/staging/ccree/ssi_hash.h @@ -15,7 +15,7 @@ */ /* \file ssi_hash.h - ARM CryptoCell Hash Crypto API + * ARM CryptoCell Hash Crypto API */ #ifndef __SSI_HASH_H__ -- 2.12.2
[PATCH 08/27] Drivers: ccree: ssi_ivgen.c - align block comments
Fixed block comment alignment, Style fix only Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/ccree/ssi_ivgen.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/ccree/ssi_ivgen.c b/drivers/staging/ccree/ssi_ivgen.c index 1bb6f8919101..db4b831e82a3 100644 --- a/drivers/staging/ccree/ssi_ivgen.c +++ b/drivers/staging/ccree/ssi_ivgen.c @@ -26,7 +26,8 @@ /* The max. size of pool *MUST* be <= SRAM total size */ #define SSI_IVPOOL_SIZE 1024 /* The first 32B fraction of pool are dedicated to the - next encryption "key" & "IV" for pool regeneration */ + * next encryption "key" & "IV" for pool regeneration + */ #define SSI_IVPOOL_META_SIZE (CC_AES_IV_SIZE + AES_KEYSIZE_128) #define SSI_IVPOOL_GEN_SEQ_LEN 4 @@ -278,7 +279,8 @@ int ssi_ivgen_getiv( } /* Bypass operation is proceeded by crypto sequence, hence must - * assure bypass-write-transaction by a memory barrier */ +* assure bypass-write-transaction by a memory barrier +*/ HW_DESC_INIT(&iv_seq[idx]); HW_DESC_SET_DIN_NO_DMA(&iv_seq[idx], 0, 0xf0); HW_DESC_SET_DOUT_NO_DMA(&iv_seq[idx], 0, 0, 1); -- 2.12.2
[PATCH 07/27] Drivers: ccree: ssi_pm.h - align block comments
Fixed block comment alignment, Style fix only Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/ccree/ssi_pm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_pm.h b/drivers/staging/ccree/ssi_pm.h index f1fe1777c04a..8b0d8be95199 100644 --- a/drivers/staging/ccree/ssi_pm.h +++ b/drivers/staging/ccree/ssi_pm.h @@ -15,7 +15,7 @@ */ /* \file ssi_pm.h -*/ + */ #ifndef __SSI_POWER_MGR_H__ #define __SSI_POWER_MGR_H__ -- 2.12.2
[PATCH 06/27] Drivers: ccree: ssi_pm_ext.c - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/ssi_pm_ext.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/ccree/ssi_pm_ext.c
b/drivers/staging/ccree/ssi_pm_ext.c
index 5889d9f97479..453151cdd6b2 100644
--- a/drivers/staging/ccree/ssi_pm_ext.c
+++ b/drivers/staging/ccree/ssi_pm_ext.c
@@ -26,10 +26,10 @@
#include "ssi_pm_ext.h"
/*
-This function should suspend the HW (if possiable), It should be implemented by
-the driver user.
-The reference code clears the internal SRAM to imitate lose of state.
-*/
+ * This function should suspend the HW (if possiable), It should be
implemented by
+ * the driver user.
+ * The reference code clears the internal SRAM to imitate lose of state.
+ */
void ssi_pm_ext_hw_suspend(struct device *dev)
{
struct ssi_drvdata *drvdata =
@@ -50,9 +50,9 @@ void ssi_pm_ext_hw_suspend(struct device *dev)
}
/*
-This function should resume the HW (if possiable).It should be implemented by
-the driver user.
-*/
+ * This function should resume the HW (if possiable).It should be implemented
by
+ * the driver user.
+ */
void ssi_pm_ext_hw_resume(struct device *dev)
{
return;
--
2.12.2
[PATCH 04/27] Drivers: ccree: ssi_request_mgr.c - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/ssi_request_mgr.c | 37 -
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/ccree/ssi_request_mgr.c
b/drivers/staging/ccree/ssi_request_mgr.c
index 48c2450d65c6..1bc6811d63c5 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -300,8 +300,9 @@ static inline int request_mgr_queues_status_check(
unsigned long poll_queue;
/* SW queue is checked only once as it will not
- be chaned during the poll becasue the spinlock_bh
- is held by the thread */
+* be chaned during the poll becasue the spinlock_bh
+* is held by the thread
+*/
if (unlikely(((req_mgr_h->req_queue_head + 1) &
(MAX_REQUEST_QUEUE_SIZE - 1)) ==
req_mgr_h->req_queue_tail)) {
@@ -384,8 +385,9 @@ int send_request(
spin_lock_bh(&req_mgr_h->hw_lock);
/* Check if there is enough place in the SW/HW queues
- in case iv gen add the max size and in case of no dout add 1
- for the internal completion descriptor */
+* in case iv gen add the max size and in case of no dout add 1
+* for the internal completion descriptor
+*/
rc = request_mgr_queues_status_check(req_mgr_h,
cc_base,
max_required_seq_len);
@@ -397,7 +399,8 @@ int send_request(
if (rc != -EAGAIN) {
/* Any error other than HW queue full
- (SW queue is full) */
+* (SW queue is full)
+*/
#if defined (CONFIG_PM_RUNTIME) || defined (CONFIG_PM_SLEEP)
ssi_power_mgr_runtime_put_suspend(&drvdata->plat_dev->dev);
#endif
@@ -409,7 +412,8 @@ int send_request(
} while (1);
/* Additional completion descriptor is needed incase caller did not
- enabled any DLLI/MLLI DOUT bit in the given sequence */
+* enabled any DLLI/MLLI DOUT bit in the given sequence
+*/
if (!is_dout) {
init_completion(&ssi_req->seq_compl);
ssi_req->user_cb = request_mgr_complete;
@@ -481,7 +485,8 @@ int send_request(
if (!is_dout) {
/* Wait upon sequence completion.
- * Return "0" -Operation done successfully. */
+* Return "0" -Operation done successfully.
+*/
return wait_for_completion_interruptible(&ssi_req->seq_compl);
} else {
/* Operation still in process */
@@ -633,7 +638,8 @@ static void comp_handler(unsigned long devarg)
/* ISR-to-Tasklet latency */
if (request_mgr_handle->axi_completed) {
/* Only if actually reflects ISR-to-completion-handling
latency, i.e.,
- not duplicate as a result of interrupt after
AXIM_MON_ERR clear, before end of loop */
+* not duplicate as a result of interrupt after
AXIM_MON_ERR clear, before end of loop
+*/
END_CYCLE_COUNT_AT(drvdata->isr_exit_cycles,
STAT_OP_TYPE_GENERIC, STAT_PHASE_1);
}
@@ -641,7 +647,8 @@ static void comp_handler(unsigned long devarg)
do {
proc_completions(drvdata);
/* At this point (after proc_completions()),
request_mgr_handle->axi_completed is always 0.
- The following assignment was changed to =
(previously was +=) to conform KW restrictions. */
+* The following assignment was changed to =
(previously was +=) to conform KW restrictions.
+*/
request_mgr_handle->axi_completed =
CC_REG_FLD_GET(CRY_KERNEL, AXIM_MON_COMP, VALUE,
CC_HAL_READ_REGISTER(AXIM_MON_BASE_OFFSET));
} while (request_mgr_handle->axi_completed > 0);
@@ -663,9 +670,9 @@ static void comp_handler(unsigned long devarg)
}
/*
-resume the queue configuration - no need to take the lock as this happens
inside
-the spin lock protection
-*/
+ * resume the queue configuration - no need to take the lock as this happens
inside
+ * the spin lock protection
+ */
#if defined (CONFIG_PM_RUNTIME) || defined (CONFIG_PM_SLEEP)
int ssi_request_mgr_runtime_resume_queue(struct ssi_drvdata *drvdata)
{
@@ -679,9 +686,9 @@ int ssi_request_mgr_runtime_resume_queue(struct ssi_drvdata
*drvdata)
}
/*
-suspend the queue configuration. Since it is used for the runtime suspend
-only verify t
[PATCH 05/27] Drivers: ccree: ssi_pm_ext.h - align block comments
Fixed block comment alignment, Style fix only Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/ccree/ssi_pm_ext.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_pm_ext.h b/drivers/staging/ccree/ssi_pm_ext.h index 9049e6ffa8d3..dbe658b530bf 100644 --- a/drivers/staging/ccree/ssi_pm_ext.h +++ b/drivers/staging/ccree/ssi_pm_ext.h @@ -15,7 +15,7 @@ */ /* \file ssi_pm_ext.h -*/ + */ #ifndef __PM_EXT_H__ #define __PM_EXT_H__ -- 2.12.2
[PATCH 03/27] Drivers: ccree: ssi_request_mgr.h - align block comments
Fixed block comment alignment, Style fix only Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/ccree/ssi_request_mgr.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_request_mgr.h b/drivers/staging/ccree/ssi_request_mgr.h index ea685bb7fa2b..c4036ab715f1 100644 --- a/drivers/staging/ccree/ssi_request_mgr.h +++ b/drivers/staging/ccree/ssi_request_mgr.h @@ -15,7 +15,7 @@ */ /* \file request_mgr.h - Request Manager + * Request Manager */ #ifndef __REQUEST_MGR_H__ -- 2.12.2
[PATCH 00/27] Drivers: ccree - align block comments
Fixed block comments across whole ccree driver Derek Robson (27): Drivers: ccree: ssi_sysfs.h - align block comments Drivers: ccree: ssi_sysfs.c - align block comments Drivers: ccree: ssi_request_mgr.h - align block comments Drivers: ccree: ssi_request_mgr.c - align block comments Drivers: ccree: ssi_pm_ext.h - align block comments Drivers: ccree: ssi_pm_ext.c - align block comments Drivers: ccree: ssi_pm.h - align block comments Drivers: ccree: ssi_ivgen.c - align block comments Drivers: ccree: ssi_hash.h - align block comments Drivers: ccree: ssi_hash.c - align block comments Drivers: ccree: ssi_fips_local.c - align block comments Drivers: ccree: ssi_fips_ll.c - align block comments Drivers: ccree: ssi_fips_ext.c - align block comments Drivers: ccree: ssi_fips_data.h - align block comments Drivers: ccree: ssi_fips.h - align block comments Drivers: ccree: ssi_fips.c - align block comments Drivers: ccree: ssi_driver.h - align block comments Drivers: ccree: ssi_config.h - align block comments Drivers: ccree: ssi_cipher.h - align block comments Drivers: ccree: ssi_buffer_mgr.h - align block comments Drivers: ccree: ssi_buffer_mgr.c - align block comments Drivers: ccree: ssi_aead.h - align block comments Drivers: ccree: ssi_aead.c - align block comments Drivers: ccree: hash_defs.h - align block comments Drivers: ccree: cc_regs.h - align block comments Drivers: ccree: cc_hw_queue_defs.h - align block comments Drivers: ccree: cc_crypto_ctx.h - align block comments drivers/staging/ccree/cc_crypto_ctx.h| 17 +++--- drivers/staging/ccree/cc_hw_queue_defs.h | 32 +-- drivers/staging/ccree/cc_regs.h | 13 ++--- drivers/staging/ccree/hash_defs.h| 15 +++--- drivers/staging/ccree/ssi_aead.c | 45 ++-- drivers/staging/ccree/ssi_aead.h | 7 +-- drivers/staging/ccree/ssi_buffer_mgr.c | 87 +- drivers/staging/ccree/ssi_buffer_mgr.h | 2 +- drivers/staging/ccree/ssi_cipher.h | 2 +- drivers/staging/ccree/ssi_config.h | 5 +- drivers/staging/ccree/ssi_driver.h | 16 +++--- drivers/staging/ccree/ssi_fips.c | 16 +++--- drivers/staging/ccree/ssi_fips.h | 6 +-- drivers/staging/ccree/ssi_fips_data.h| 93 drivers/staging/ccree/ssi_fips_ext.c | 46 drivers/staging/ccree/ssi_fips_ll.c | 21 drivers/staging/ccree/ssi_fips_local.c | 21 drivers/staging/ccree/ssi_hash.c | 9 ++-- drivers/staging/ccree/ssi_hash.h | 2 +- drivers/staging/ccree/ssi_ivgen.c| 6 ++- drivers/staging/ccree/ssi_pm.h | 2 +- drivers/staging/ccree/ssi_pm_ext.c | 14 ++--- drivers/staging/ccree/ssi_pm_ext.h | 2 +- drivers/staging/ccree/ssi_request_mgr.c | 37 +++-- drivers/staging/ccree/ssi_request_mgr.h | 2 +- drivers/staging/ccree/ssi_sysfs.c| 3 +- drivers/staging/ccree/ssi_sysfs.h| 2 +- 27 files changed, 288 insertions(+), 235 deletions(-) -- 2.12.2
[PATCH 02/27] Drivers: ccree: ssi_sysfs.c - align block comments
Fixed block comment alignment, Style fix only
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/ssi_sysfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/ccree/ssi_sysfs.c
b/drivers/staging/ccree/ssi_sysfs.c
index 89021c009872..69e1ae491098 100644
--- a/drivers/staging/ccree/ssi_sysfs.c
+++ b/drivers/staging/ccree/ssi_sysfs.c
@@ -355,7 +355,8 @@ static struct ssi_drvdata *sys_get_drvdata(void)
{
/* TODO: supporting multiple SeP devices would require avoiding
* global "top_dir" and finding associated "top_dir" by traversing
-* up the tree to the kobject which matches one of the top_dir's */
+* up the tree to the kobject which matches one of the top_dir's
+*/
return sys_top_dir.drvdata;
}
--
2.12.2
Re: mm, we use rcu access task_struct in mm_match_cgroup(), but not use rcu free in free_task_struct()
On 2017/5/24 9:40, Xishi Qiu wrote: > Hi, I find we use rcu access task_struct in mm_match_cgroup(), but not use > rcu free in free_task_struct(), is it right? > > Here is the backtrace. > > PID: 2133 TASK: 881fe3353300 CPU: 2 COMMAND: "CPU 15/KVM" > #0 [881fe276b528] machine_kexec at 8105280b > #1 [881fe276b588] crash_kexec at 810f5072 > #2 [881fe276b658] panic at 8163e23b > #3 [881fe276b6d8] oops_end at 8164d61b > #4 [881fe276b700] die at 8101872b > #5 [881fe276b730] do_general_protection at 8164cefe > #6 [881fe276b760] general_protection at 8164c7a8 > [exception RIP: mem_cgroup_from_task+22] > RIP: 811db536 RSP: 881fe276b810 RFLAGS: 00010286 > RAX: 6b6b6b6b6b6b6b6b RBX: ea007f90 RCX: 0002 > RDX: 0007fa607d67 RSI: 0007fa607d67 RDI: 880fe36d72c0 > RBP: 881fe276b880 R8: 0007fa607600 R9: a801fd67b300 > R10: 57fdec98cc59ecc0 R11: 880fe2e8dbd0 R12: c9001cb74000 > R13: 881fdb8cfda0 R14: 881fe2581570 R15: 0007fa607d67 > ORIG_RAX: CS: 0010 SS: > #7 [881fe276b810] page_referenced at 811a6b8a > #8 [881fe276b888] shrink_page_list at 81180994 > #9 [881fe276b9c0] shrink_inactive_list at 8118166a > #10 [881fe276ba88] shrink_lruvec at 81182135 > #11 [881fe276bb88] shrink_zone at 81182596 > #12 [881fe276bbe0] do_try_to_free_pages at 81182a90 > #13 [881fe276bc58] try_to_free_mem_cgroup_pages at 81182fea > #14 [881fe276bcf0] mem_cgroup_reclaim at 811dd8de > #15 [881fe276bd30] __mem_cgroup_try_charge at 811ddd9c > #16 [881fe276bdf0] __mem_cgroup_try_charge_swapin at 811df62b > #17 [881fe276be28] mem_cgroup_try_charge_swapin at 811e0537 > #18 [881fe276be38] handle_mm_fault at 8119abdd > #19 [881fe276bec8] __do_page_fault at 816502d6 > #20 [881fe276bf28] do_page_fault at 81650603 > #21 [881fe276bf50] page_fault at 8164c808 > RIP: 7fdaba456500 RSP: 7fdaaba6c978 RFLAGS: 00010246 > RAX: RBX: RCX: fbd0 > RDX: RSI: ae80 RDI: 002c > RBP: 7fdaaba6c9f0 R8: 00840c70 R9: 00be > R10: 7fff R11: 0246 R12: 03622010 > R13: ae80 R14: 008274e0 R15: 03622010 > ORIG_RAX: CS: 0033 SS: 002b > > > . >
[PATCH 01/27] Drivers: ccree: ssi_sysfs.h - align block comments
Fixed block comment alignment, Style fix only Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/ccree/ssi_sysfs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_sysfs.h b/drivers/staging/ccree/ssi_sysfs.h index cd456c5dccc4..4893e014adf7 100644 --- a/drivers/staging/ccree/ssi_sysfs.h +++ b/drivers/staging/ccree/ssi_sysfs.h @@ -15,7 +15,7 @@ */ /* \file ssi_sysfs.h - ARM CryptoCell sysfs APIs + * ARM CryptoCell sysfs APIs */ #ifndef __SSI_SYSFS_H__ -- 2.12.2
Re: [PATCH v1] dmaengine: DW DMAC: Handle return value of clk_prepare_enable
On Mon, May 22, 2017 at 04:01:48PM +0530, Arvind Yadav wrote: > clk_prepare_enable() can fail here and we must check its return value. Applied, thanks -- ~Vinod
Re: CHIPPro NAND issue with 4.12 rc1
On 2017-05-23 13:52, Maxime Ripard wrote:
Ok, good.
If you unrevert those patches, and add clk_ignore_unused to the kernel
command line, is it still broken?
Maxime
If I use the clk_ignore_unused flag with the patches below then the
kernel can boot and mount the nand.
diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.c
b/drivers/clk/sunxi-ng/ccu-sun5i.c
index 5c476f9..700944c 100644
--- a/drivers/clk/sunxi-ng/ccu-sun5i.c
+++ b/drivers/clk/sunxi-ng/ccu-sun5i.c
@@ -251,7 +251,7 @@ static SUNXI_CCU_GATE(ahb_mmc1_clk, "ahb-mmc1",
"ahb",
static SUNXI_CCU_GATE(ahb_mmc2_clk,"ahb-mmc2", "ahb",
0x060, BIT(10), 0);
static SUNXI_CCU_GATE(ahb_nand_clk,"ahb-nand", "ahb",
- 0x060, BIT(13), 0);
+ 0x060, BIT(13), CLK_IS_CRITICAL);
static SUNXI_CCU_GATE(ahb_sdram_clk, "ahb-sdram","ahb",
0x060, BIT(14), CLK_IS_CRITICAL);
static SUNXI_CCU_GATE(ahb_emac_clk,"ahb-emac", "ahb",
diff --git a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
index c55b11a..fa37cce 100644
--- a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
+++ b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
@@ -146,6 +149,32 @@
reg = <0>;
allwinner,rb = <0>;
nand-ecc-mode = "hw";
+nand-on-flash-bbt;
+
+spl@0 {
+ label = "SPL";
+ reg = /bits/ 64 <0x0 0x40>;
+};
+
+spl-backup@40 {
+ label = "SPL.backup";
+ reg = /bits/ 64 <0x40 0x40>;
+};
+
+u-boot@80 {
+ label = "U-Boot";
+ reg = /bits/ 64 <0x80 0x40>;
+};
+
+env@c0 {
+ label = "env";
+ reg = /bits/ 64 <0xc0 0x40>;
+};
+
+rootfs@100 {
+ label = "rootfs";
+ reg = /bits/ 64 <0x100 0x1f00>;
+};
};
};
Re: [PATCH V4 00/17] thermal: cpu_cooling: improve interaction with cpufreq core
Viresh, On Wed, May 24, 2017 at 09:23:52AM +0530, Viresh Kumar wrote: > On 23-05-17, 19:41, Eduardo Valentin wrote: > > Hey, > > > > On Tue, Apr 25, 2017 at 03:57:07PM +0530, Viresh Kumar wrote: > > > Hi Guys, > > > > > > The cpu_cooling driver is designed to use CPU frequency scaling to avoid > > > high thermal states for a platform. But it wasn't glued really well with > > > cpufreq core. For example clipped-cpus is copied from the policy > > > structure and its much better to use the policy->cpus (or related_cpus) > > > fields directly as they may have got updated. Not that things were > > > broken before this series, but they can be optimized a bit more. > > > > > > This series tries to improve interactions between cpufreq core and > > > cpu_cooling driver and does some fixes/cleanups to the cpu_cooling > > > driver. > > > > > > I have tested it on ARM 32 (exynos) and 64 bit (hikey) boards (haven't > > > tested the power specific bits). > > > > > > Lukasz from ARM has been very generous in testing and finding out few > > > bugs in the earlier versions and getting those fixed. He has > > > successfully tested the new version on his ARM big LITTLE Juno board. > > > > > > Pushed here as well: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git > > > thermal/cooling > > > > > > V3->V4: > > > > > > Took this version into my -linus branch for the next merge window. > > Including the patch to remove the checkpatch warning. But please send > > an extra patch to fix the style pointed on patch 8. > > Thanks Eduardo. > > But I am not sure what's left there to be fixed :( > > There were two warnings with patch 8, s/kmalloc/kmalloc_array and line > over 80 columns and both were fixed by the patch I sent separately. You are right, you are done here. This was probably a bug in my script showing old checkpatch results on patch 8, somehow. Sorry for the noise. > > -- > viresh signature.asc Description: Digital signature
Re: [PATCH 4.4 000/103] 4.4.70-stable review
On 05/23/2017 01:08 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.70 release. There are 103 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu May 25 20:08:25 UTC 2017. Anything received after that time might be too late. Early feedback: All x86_64 images are crashing. Let me know if you need me to bisect. Guenter --- ... EXT4-fs (sda): re-mounted. Opts: errors=remount-ro,data=ordered BUG: unable to handle kernel paging request at 2280 IP: [] process_echoes+0x15/0x70 PGD da68067 PUD d991067 PMD 0 Oops: [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 400 Comm: bootlogd Not tainted 4.4.70-rc1-yocto-standard+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014 task: 88000d159bc0 ti: 88000d23 task.ti: 88000d23 RIP: 0010:[] [] process_echoes+0x15/0x70 RSP: 0018:88000d233d50 EFLAGS: 0202 RAX: 88000dd950d8 RBX: RCX: 0007 RDX: 88000dd4a400 RSI: 88000d91b700 RDI: 88000dd95000 RBP: 88000d233d68 R08: 7000 R09: 88000eeb91c8 R10: 7fffc9dc3f70 R11: 0246 R12: 0007 R13: 00603574 R14: 0007 R15: 88000d91b700 FS: 7f973601b700() GS:88000fc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2280 CR3: 0d953000 CR4: 003406f0 Stack: 88000dd95000 0007 00603574 88000d233df0 814515b7 00410022 88000d91b700 88000dd950d8 88000dd4a400 88000d91b700 88000d159bc0 Call Trace: [] n_tty_write+0x97/0x4e0 [] ? __wake_up_sync+0x20/0x20 [] tty_write+0x1a6/0x2d0 [] ? n_tty_open+0xe0/0xe0 [] __vfs_write+0x28/0xe0 [] ? preempt_count_add+0x85/0xd0 [] ? __fd_install+0x5e/0x110 [] ? __alloc_fd+0xc9/0x180 [] ? rw_verify_area+0x4f/0xe0 [] vfs_write+0x9a/0x170 [] SyS_write+0x46/0xb0 [] entry_SYSCALL_64_fastpath+0x12/0x66 Code: 8b 40 48 48 85 c0 74 07 55 48 89 e5 ff d0 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 9f 80 02 00 00 <48> 8b 83 80 22 00 00 48 39 43 28 74 3a 4c 8d ab b0 22 00 00 49 RIP [] process_echoes+0x15/0x70 RSP CR2: 2280 ---[ end trace cec672c0d4b54e81 ]--- Kernel panic - not syncing: Fatal exception Kernel Offset: disabled ---[ end Kernel panic - not syncing: Fatal exception
Re: [PATCH 4.9 000/164] 4.9.30-stable review
On 05/23/2017 01:06 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.30 release. There are 164 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu May 25 20:08:20 UTC 2017. Anything received after that time might be too late. Early feedback: Building arm:axm55xx_defconfig ... failed -- Error log: /opt/buildbot/slave/stable-queue-4.9/build/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c: In function 'vgic_v2_populate_lr': /opt/buildbot/slave/stable-queue-4.9/build/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:176:3: error: implicit declaration of function 'irq_is_pending' [-Werror=implicit-function-declaration] if (irq->active && irq_is_pending(irq)) ^ /opt/buildbot/slave/stable-queue-4.9/build/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-v3.c: In function 'vgic_v3_populate_lr': /opt/buildbot/slave/stable-queue-4.9/build/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-v3.c:159:3: error: implicit declaration of function 'irq_is_pending' Building arm64:allmodconfig ... failed -- Error log: arch/arm64/Makefile:23: ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum arch/arm64/Makefile:36: LSE atomics not supported by binutils /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c: In function ‘vgic_v2_populate_lr’: /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:176:22: error: implicit declaration of function ‘irq_is_pending’ [-Werror=implicit-function-declaration] if (irq->active && irq_is_pending(irq)) ^ cc1: some warnings being treated as errors make[2]: *** [arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.o] Error 1 make[2]: *** Waiting for unfinished jobs /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v3.c: In function ‘vgic_v3_populate_lr’: /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v3.c:159:22: error: implicit declaration of function ‘irq_is_pending’ Guenter
Re: [PATCH V4 00/17] thermal: cpu_cooling: improve interaction with cpufreq core
On 23-05-17, 19:41, Eduardo Valentin wrote: > Hey, > > On Tue, Apr 25, 2017 at 03:57:07PM +0530, Viresh Kumar wrote: > > Hi Guys, > > > > The cpu_cooling driver is designed to use CPU frequency scaling to avoid > > high thermal states for a platform. But it wasn't glued really well with > > cpufreq core. For example clipped-cpus is copied from the policy > > structure and its much better to use the policy->cpus (or related_cpus) > > fields directly as they may have got updated. Not that things were > > broken before this series, but they can be optimized a bit more. > > > > This series tries to improve interactions between cpufreq core and > > cpu_cooling driver and does some fixes/cleanups to the cpu_cooling > > driver. > > > > I have tested it on ARM 32 (exynos) and 64 bit (hikey) boards (haven't > > tested the power specific bits). > > > > Lukasz from ARM has been very generous in testing and finding out few > > bugs in the earlier versions and getting those fixed. He has > > successfully tested the new version on his ARM big LITTLE Juno board. > > > > Pushed here as well: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git thermal/cooling > > > > V3->V4: > > > Took this version into my -linus branch for the next merge window. > Including the patch to remove the checkpatch warning. But please send > an extra patch to fix the style pointed on patch 8. Thanks Eduardo. But I am not sure what's left there to be fixed :( There were two warnings with patch 8, s/kmalloc/kmalloc_array and line over 80 columns and both were fixed by the patch I sent separately. -- viresh
Re: [PATCH] thermal: cpu_cooling: Replace kmalloc with kmalloc_array
On 23-05-17, 19:27, Eduardo Valentin wrote:
> Hello,
>
> On Tue, May 23, 2017 at 12:33:06PM +0530, Viresh Kumar wrote:
> > Checkpatch reports following:
> >
> > WARNING: Prefer kmalloc_array over kmalloc with multiply
> > + cpufreq_cdev->freq_table = kmalloc(sizeof(*cpufreq_cdev->freq_table) *
> > i,
> >
> > Fix that.
>
> That is how the patch would apply. Enter to continue
>
> WARNING: line over 80 characters
> #159: FILE: drivers/thermal/cpu_cooling.c:783:
> + cpufreq_cdev->freq_table = kmalloc(sizeof(*cpufreq_cdev->freq_table) *
> i,
>
> WARNING: Prefer kmalloc_array over kmalloc with multiply
> #159: FILE: drivers/thermal/cpu_cooling.c:783:
> + cpufreq_cdev->freq_table = kmalloc(sizeof(*cpufreq_cdev->freq_table) *
> i,
> + GFP_KERNEL);
>
> WARNING: line over 80 characters
> #190: FILE: include/linux/cpufreq.h:859:
> +static inline int cpufreq_table_count_valid_entries(const struct
> cpufreq_policy *policy)
I am not sure what you meant here. Above doesn't looks something that
this patch can generate. This was fixing the problem that you reported
above.
> >
> > Signed-off-by: Viresh Kumar
> > ---
> > drivers/thermal/cpu_cooling.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> > index 1305020790b2..908a8014cf76 100644
> > --- a/drivers/thermal/cpu_cooling.c
> > +++ b/drivers/thermal/cpu_cooling.c
> > @@ -724,8 +724,9 @@ __cpufreq_cooling_register(struct device_node *np,
> > /* max_level is an index, not a counter */
> > cpufreq_cdev->max_level = i - 1;
> >
> > - cpufreq_cdev->freq_table = kmalloc(sizeof(*cpufreq_cdev->freq_table) *
> > i,
> > - GFP_KERNEL);
> > + cpufreq_cdev->freq_table = kmalloc_array(i,
> > + sizeof(*cpufreq_cdev->freq_table),
> > + GFP_KERNEL);
> > if (!cpufreq_cdev->freq_table) {
--
viresh
Re: [RESEND PATCH] vhost/scsi: Don't reinvent the wheel but use existing llist API
On Fri, 2017-05-12 at 09:42 +0900, Byungchul Park wrote: > Although llist provides proper APIs, they are not used. Make them used. > > Signed-off-by: Byungchul Park > Acked-by: Nicholas Bellinger > --- > drivers/vhost/scsi.c | 11 +++ > 1 file changed, 3 insertions(+), 8 deletions(-) > Applied to target-pending/for-next. Thanks Byungchul.
Re: [PATCH] target: remove dead code
On Thu, 2017-05-11 at 13:39 -0700, Tyrel Datwyler wrote: > On 05/09/2017 02:46 PM, Gustavo A. R. Silva wrote: > > Local variable _ret_ is assigned to a constant value and it is never > > updated again. Remove this variable and the dead code it guards. > > > > Addresses-Coverity-ID: 140761 > > Signed-off-by: Gustavo A. R. Silva > > --- > > Reviewed-by: Tyrel Datwyler > Applied to target-pending/for-next. Thanks Gustavo + Tyrel.
Re: linux-next: build failure after merge of the spi tree
Hi Mark
since commit 8d4a6cad7adb ("spi: imx: dynamic burst length adjust for PIO mode
")
has been reverted, then
commit 1ce1c618e6b5 ("spi: imx: only allow dynamic burst in PIO mode")
need to be reverted as well.
I can submit another version of patch set, with all founded issues be addressed
after that.
Thanks,
Jiada
On 05/23/2017 06:08 PM, Stephen Rothwell wrote:
Hi Mark,
After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/spi/spi-imx.c: In function 'spi_imx_can_dma':
drivers/spi/spi-imx.c:241:9: error: 'struct spi_imx_data' has no member named
'dynamic_burst'
spi_imx->dynamic_burst = 0;
^
Caused by commit
09b3ed2d5916 ("spi: imx: Revert "spi: imx: dynamic burst length adjust for PIO
mode"")
interacting with commit
1ce1c618e6b5 ("spi: imx: only allow dynamic burst in PIO mode")
from a separate topic branch and not fixing it up in the merge. Although
that second commit could never have built anyway on its own :-(
I have used the spi tree from next-20170523 for today.
Re: [PATCH 1/1] xilinx ps uart: Adding a kernel parameter for the number of xilinx ps uarts
On Mon, May 22, 2017 at 07:26:36PM +0100, Alan Cox wrote: > > We have in soc vendor tree similar patch but the reason is different. > > > > tty: serial: Added a CONFIG_SERIAL_XILINX_NR_UARTS option. > > > > This patch Adds CONFIG_SERIAL_XILINX_NR_UARTS option to allow > > the user to provide the Max number of uart ports information. > > If multiple cards (or) PL UARTS are present, the default limit > > of 2 ports should be increased. > > > > I haven't checked all drivers but in our case we have added this as > > quick fix for scenarios where you use serial aliases where alias is > > pointed to serial2 or more. > > In cdns_uart_init() cdns_uart_uart_driver is passed which contains .nr > > which is required to be passed. > > > > What's the best driver to look at dynamic allocation? > > So there are quite a few that dynamically allocate the objects as they > are enumerated (eg max3100), but have a maximum set that is just pointers > (so for the max number of ports cheaper than the dynamic code) > > The other question is why is it a CONFIG_ option. I'm assuming these > platforms are all ARM and in that case you could just pass the value in > the device tree, or hard code a safe maximum number of pointers to a > value which is the worst case and then install them as they are > enumerated. > > There are lots of options better than breaking the "one kernel many > platforms" model. > > Alan I guess I'm confused how this isn't a better solution than what we have now, or how it breaks the "one kernel many platforms model". I agree that it is not the best solution, certainly this driver should be re-written to use the device tree and dynamic allocation, but that is not the patch being offered at this time. This is a very minor module buried deep in the drivers tree. I guess I don't understand how allowing users to choose how many UARTS they might want to implement breaks the "one kernel" model. The users of this module and those like it do not use a pre-compiled kernel and customize their kernels extensively. Is there some documentation online I could read that explains this "one kernel many platforms" model? Specifically how it pertains to FPGAs? I am but a humble embedded developer trying to make the kernel more useful to myself (and hopefully others), and I think I might have a limited worldview that restricts my ability to see the full picture and I would like to learn.
Re: [PATCH v2 0/2] module: Add module name to modinfo
+++ Kees Cook [25/04/17 21:43 -0700]: On Tue, Apr 25, 2017 at 7:32 PM, Jessica Yu wrote: +++ Kees Cook [21/04/17 15:35 -0700]: The mod structure is accessed for the "name" field prior to validating sanity in check_modstruct_version(). This becomes very obvious once struct layout randomization is happening, so instead add the module name to modinfo and use that until the mod struct has been sanity-checked. -Kees v2: - adjusted for more odd name load failure cases; jeyu Hi Kees! These patches look fine to me, would you mind if I held on to them until after the upcoming merge window? (Since we're at -rc8, and I'd still like for them to sit in -next for a while) Sure thing; I'm in no rush. :) These have been applied to modules-next, thanks! Jessica Thanks! -Kees
linux-next: Tree for May 24
Hi all, Changes since 20170523: The spi tree gained a build failure so I used the version from next-20170523. Non-merge commits (relative to Linus' tree): 2264 2585 files changed, 85073 insertions(+), 52432 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 260 trees (counting Linus' and 40 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (56fff1bb0f31 Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux) Merging fixes/master (97da3854c526 Linux 4.11-rc3) Merging kbuild-current/fixes (05d8cba4a1e8 kbuild: skip install/check of headers right under uapi directories) Merging arc-current/for-curr (2ea659a9ef48 Linux 4.12-rc1) Merging arm-current/fixes (2ea659a9ef48 Linux 4.12-rc1) Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card definitions) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (e41e53cd4fe3 powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash) Merging sparc/master (8b4822de59d5 Merge tag 'md/4.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/md) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (12e8b570e732 mlx5: fix bug reading rss_hash_type from CQE) Merging ipsec/master (a486cd23661c xfrm: fix state migration copy replay sequence numbers) Merging netfilter/master (6d18c732b95c bridge: start hello_timer when enabling KERNEL_STP in br_stp_start) Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed connections) Merging wireless-drivers/master (6d18c732b95c bridge: start hello_timer when enabling KERNEL_STP in br_stp_start) Merging mac80211/master (1b57b6210f4e cfg80211: make cfg80211_sched_scan_results() work from atomic context) Merging sound-current/for-linus (a79e7df97592 ALSA: hda - Update the list of quirk models) Merging pci-current/for-linus (4d071c323898 PCI/PM: Add needs_resume flag to avoid suspend complete optimization) Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2) Merging tty.current/tty-linus (da4c279942b0 serial: enable serdev support) Merging usb.current/usb-linus (08332893e37a Linux 4.12-rc2) Merging usb-gadget-fixes/fixes (a351e9b9fc24 Linux 4.11) Merging usb-serial-fixes/usb-linus (08332893e37a Linux 4.12-rc2) Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: check before accessing ci_role in ci_role_show) Merging phy/fixes (a380b78b799b phy: qualcomm: phy-qcom-qmp: fix application of sizeof to pointer) Merging staging.current/staging-linus (5a4733df7ef2 Merge tag 'iio-fixes-for-4.12a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (08332893e37a Linux 4.12-rc2) Merging input-current/for-linus (089b50d95948 Input: atmel_mxt_ts - add T100 as a readable object) Merging crypto-current/master (f3ad587070d6 crypto: gcm - wait for crypto op not signal safe) Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source and destination) Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6) Merging kselftest-fixes/fixes (2ea659a9ef48 Linux 4.12-rc1) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e
[PATCH] reset: ti_syscon: Rename TI_SYSCON_RESET to RESET_TI_SYSCON
Rename the current Kconfig name used for the TI SYSCON Reset driver from TI_SYSCON_RESET to RESET_TI_SYSCON to match the convention used for all the reset drivers present at the base reset folder. Signed-off-by: Suman Anna --- drivers/reset/Kconfig | 2 +- drivers/reset/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index d21c07ccc94e..42d5631c6da0 100644 --- a/drivers/reset/Kconfig +++ b/drivers/reset/Kconfig @@ -80,7 +80,7 @@ config RESET_SUNXI help This enables the reset driver for Allwinner SoCs. -config TI_SYSCON_RESET +config RESET_TI_SYSCON tristate "TI SYSCON Reset Driver" depends on HAS_IOMEM select MFD_SYSCON diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index 02a74db94339..26270e0f8342 100644 --- a/drivers/reset/Makefile +++ b/drivers/reset/Makefile @@ -13,7 +13,7 @@ obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o obj-$(CONFIG_RESET_STM32) += reset-stm32.o obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o -obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o +obj-$(CONFIG_RESET_TI_SYSCON) += reset-ti-syscon.o obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o obj-$(CONFIG_RESET_ZX2967) += reset-zx2967.o obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o -- 2.12.0
Re: [PATCH 2/3] Documentation: add sprd clock bindings
Hi Stephen,
On 19 May 2017 at 10:12, Stephen Boyd wrote:
> On 05/18, Chunyan Zhang wrote:
>> On 18 May 2017 at 03:43, Arnd Bergmann wrote:
>> > On Mon, May 15, 2017 at 10:35 AM, Chunyan Zhang
>> > wrote:
>> >> diff --git
>> >> a/Documentation/devicetree/bindings/clock/sprd/sprd,adjustable-pll-clock.txt
>> >>
>> >> b/Documentation/devicetree/bindings/clock/sprd/sprd,adjustable-pll-clock.txt
>> >> new file mode 100644
>> >> index 000..476e315
>> >> --- /dev/null
>> >> +++
>> >> b/Documentation/devicetree/bindings/clock/sprd/sprd,adjustable-pll-clock.txt
>> >> @@ -0,0 +1,17 @@
>> >> +Spreadtrum adjustable pll clock driver
>> >> +
>> >> +Required properties:
>> >> +
>> >> +- compatible : must be one of:
>> >> + "sprd,sc9836-adjustable-pll-clock"
>> >> + "sprd,sc9860-adjustable-pll-clock"
>> >> +
>> >> +Example:
>> >> + clk_mpll0: clk@40400024 {
>> >> + compatible = "sprd,sc9860-adjustable-pll-clock";
>> >> + #clock-cells = <0>;
>> >> + reg = <0 0x40400024 0 0x4>,
>> >> + <0 0x40400028 0 0x4>;
>> >> + clocks = <&clk_mpll_gates 2>;
>> >> + clock-output-names = "clk_mpll0";
>> >> + };
>> >
>> > The properties listed in the example must all be either
>> > defined as "required" or "optional" properties and have a
>> > description.
>>
>> Since these common properties are documented in the common clock binding [1]
>>
>> [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>>
>> I will add explanation in this file like I do in other bindings
>> introduced in this patch, and will address 'reg' which probably is not
>> similar to the common usage.
>>
>> >
>> > The reg property here is a bit odd, as it lists two consecutive
>> > 4-byte areas, and both are suspiciously close to a round
>> > address (0x4040), so I would guess that they are
>> > in fact part of a clock controller with several registers.
>>
>> They are PLL clock configuration registers.
>>
>> Different PLL has different configurations which listed in pll_cfg.h,
>> and probably has different number of registers for storing
>> configurations, and on some Spreadtrum's SoCs PLL clock configuration
>> registers aren't consecutive, but all PLLs on all Spreadtrum's SoCs
>> (at least so far) are using the same driver.
>>
>> >
>> > If so, please define a node for the entire clock controller,
>> > the DT description should reflect the design of the hardware
>> > rather than the design of your device driver.
>>
>> I also realized our implementation might not be easy to be understood,
>> but I haven't thought out a better solution considering the hardware
>> limitation I explained above.
>
> This binding is going down the wrong path. Please look at how
> drivers such as sunxi-ng have done the binding in comparison to
> original sunxi design. We don't put this level of detail into DT,
> instead we put the details into the driver code and have clock
> controller nodes in DT. A quick glance shows that this binding is
> making a node per-clk, which is not going to be accepted.
I have had a look at sunxi-ng design, I will try to rewrite the driver
included in this patch-set, also DT and bindings.
Thanks for your comments,
Chunyan
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
Re: [PATCH V4 00/17] thermal: cpu_cooling: improve interaction with cpufreq core
Hey, On Tue, Apr 25, 2017 at 03:57:07PM +0530, Viresh Kumar wrote: > Hi Guys, > > The cpu_cooling driver is designed to use CPU frequency scaling to avoid > high thermal states for a platform. But it wasn't glued really well with > cpufreq core. For example clipped-cpus is copied from the policy > structure and its much better to use the policy->cpus (or related_cpus) > fields directly as they may have got updated. Not that things were > broken before this series, but they can be optimized a bit more. > > This series tries to improve interactions between cpufreq core and > cpu_cooling driver and does some fixes/cleanups to the cpu_cooling > driver. > > I have tested it on ARM 32 (exynos) and 64 bit (hikey) boards (haven't > tested the power specific bits). > > Lukasz from ARM has been very generous in testing and finding out few > bugs in the earlier versions and getting those fixed. He has > successfully tested the new version on his ARM big LITTLE Juno board. > > Pushed here as well: > > git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git thermal/cooling > > V3->V4: Took this version into my -linus branch for the next merge window. Including the patch to remove the checkpatch warning. But please send an extra patch to fix the style pointed on patch 8. signature.asc Description: Digital signature
Re: [PATCH v2] usb: typec: Add a sysfs node to manage port type
On 05/23/2017 06:28 PM, Badhri Jagan Sridharan wrote:
User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.
Signed-off-by: Badhri Jagan Sridharan
---
Changelog since v1:
- introduced a new variable port_type in struct typec_port to track
the current port type instead of changing type member in
typec_capability to address Heikki Krogerus comments.
- changed the output format and strings that would be displayed as
suggested by Heikki Krogerus.
> Documentation/ABI/testing/sysfs-class-typec | 13 ++
drivers/usb/typec/typec.c | 66 +
include/linux/usb/typec.h | 4 ++
3 files changed, 83 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-typec
b/Documentation/ABI/testing/sysfs-class-typec
index d4a3d23eb09c..1f224c2e391f 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -73,6 +73,19 @@ Description:
Valid values: source, sink, none (to remove preference)
+What: /sys/class/typec//port_type
+Date: May 2017
+Description:
+ Indicates the type of the port. This attribute can be used for
+ requesting a change in the port type. Port type change is
+ supported as a synchronous operation, so write(2) to the
+ attribute will not return until the operation has finished.
+
+ Valid values:
+ - source
+ - sink
+ - dual
+
What: /sys/class/typec//supported_accessory_modes
Date: April 2017
Contact: Heikki Krogerus
diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..5063d6e0f8c7 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -69,6 +69,7 @@ struct typec_port {
enum typec_role pwr_role;
enum typec_role vconn_role;
enum typec_pwr_opmode pwr_opmode;
+ enum typec_port_typeport_type;
I am missing where this variable is initialized (when the port is registered ?).
const struct typec_capability *cap;
};
@@ -789,6 +790,12 @@ static const char * const typec_data_roles[] = {
[TYPEC_HOST]= "host",
};
+static const char * const typec_port_types[] = {
+ [TYPEC_PORT_DFP] = "source",
+ [TYPEC_PORT_UFP] = "sink",
+ [TYPEC_PORT_DRP] = "dual",
+};
+
static ssize_t
preferred_role_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t size)
@@ -856,6 +863,12 @@ static ssize_t data_role_store(struct device *dev,
return -EOPNOTSUPP;
}
+ if (port->port_type != TYPEC_PORT_DRP) {
+ dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+ return -EIO;
?? This is already there, or am I missing something ?
+ }
+
ret = sysfs_match_string(typec_data_roles, buf);
if (ret < 0)
return ret;
@@ -897,6 +910,12 @@ static ssize_t power_role_store(struct device *dev,
return -EOPNOTSUPP;
}
+ if (port->port_type != TYPEC_PORT_DRP) {
+ dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+ return -EIO;
Unrelated change; should be in a separate patch. Also, it should
probably return -EOPNOTSUPP.
+ }
+
if (port->pwr_opmode != TYPEC_PWR_MODE_PD) {
dev_dbg(dev, "partner unable to swap power role\n");
return -EIO;
@@ -926,6 +945,52 @@ static ssize_t power_role_show(struct device *dev,
}
static DEVICE_ATTR_RW(power_role);
+static ssize_t
+port_type_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ struct typec_port *port = to_typec_port(dev);
+ int ret, type;
+
I think 'type' should be 'enum typec_port_type'.
+ if (!port->cap->port_type_set || port->cap->type != TYPEC_PORT_DRP) {
+ dev_dbg(dev, "changing port type not supported\n");
+ return -EOPNOTSUPP;
+ }
+
+ ret = sysfs_match_string(typec_port_types, buf);
+ if (ret < 0)
+ return ret;
+
If the new type matches the current type, you could return immediately here.
+ type = ret;
+
+ ret = port->cap->port_type_set(port->cap, type);
+ if (ret)
+ return ret;
+
+ port->port_type = type;
We have no locking here, meaning a second request could be processed in
parallel.
There is no guarantee that the resulting value in port->port_type matches
the actual port type
Re: [PATCH] lpfc: nvmet_fc: fix format string
Arnd, > The lpfc_nvmeio_data() tracing helper always takes a format string and > three additional arguments. The latest caller has a format string with > only two integer arguments, causing this harmless warning: James? -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] qla2xxx: don't disable a not previously enabled PCI device
Johannes,
> When pci_enable_device() or pci_enable_device_mem() fail in
> qla2x00_probe_one() we bail out but do a call to
> pci_disable_device(). This causes the dev_WARN_ON() in
> pci_disable_device() to trigger, as the device wasn't enabled
> previously.
>
> So instead of taking the 'probe_out' error path we can directly return
> *iff* one of the pci_enable_device() calls fails.
>
> Additionally rename the 'probe_out' goto label's name to the more
> descriptive 'disable_device'.
>
> Signed-off-by: Johannes Thumshirn
> Fixes: e315cd28b9ef ("[SCSI] qla2xxx: Code changes for qla data structure
> refactoring")
Himanshu/Quinn: Please review!
--
Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 05/12] arm64: dts: Add I2C nodes for Hi3660
Hi, Jarkko Would you mind give some suggestion? On 2017年05月23日 20:48, Rob Herring wrote: + compatible = "snps,designware-i2c"; These should have an SoC specific compatible. We directly use drivers/i2c/busses/i2c-designware-platdrv.c, do we still an soc specific compatible? It's fine if the driver uses the snps compatible, but the dts should still have an SoC specific one. Checked arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi, and other examples, compatible = "snps,designware-i2c" is used. That was a mistake in the other platforms. We shouldn't continue repeating it. Rob Rob suggest add something like "hisilicon,hi3660-dw-i2c" as well. "The problem is dw-i2c does not give any clue as to what the configuration or version of the IP is. Is that fully discoverable with version/capability registers? If not then you need a specific compatible. Generally when we have not required them, it ends up being a problem later on." While Documentation/devicetree/bindings/i2c/i2c-designware.txt compatible : should be "snps,designware-i2c" Besides, on Hikey960, [3.822353] dw_readl(dev, DW_IC_COMP_VERSION)=0x3132302a [3.827763] dw_readl(dev, DW_IC_COMP_TYPE)=0x44570140 Are these two registers enough to distinguish version etc? Thanks
