Re: [PATCH] staging: rtl8723au: Fixes unnecessary return warning
On Sat, 2016-01-30 at 12:23 +0530, Bhakti Priya wrote: > I will be happy to extend checkpatch.pl. As suggested by you, I am > trying to detect such blank lines in a line removal patch by checking > if the line above the deleted line was a blank line and the line > following the deleted line had a closing brace. > Can you please guide me and let me know if I am headed in the right > direction. You have to track all the + and - lines that precede the deleted line. Good luck.
Re: [slab] a1fd55538c: WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2601 trace_hardirqs_on_caller()
On Thu, 28 Jan 2016 18:47:49 +0100, Jesper Dangaard Brouer said: > I cannot reproduce below problem... have enabled all kind of debugging > and also lockdep. > > Can I get a version of the .config file used? I'm not the 0day bot, but my laptop hits the same issue at boot. .config follows.. # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.5.0-rc1 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=28 CONFIG_ARCH_MMAP_RND_BITS_MAX=32 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_64_SMP=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set CONFIG_KERNEL_XZ=y # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # # CONFIG_TICK_CPU_ACCOUNTING is not set # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set CONFIG_IRQ_TIME_ACCOUNTING=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_PREEMPT_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_EXPEDITE_BOOT is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=21 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_NMI_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_CGROUPS=y # CONFIG_MEMCG is not set CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y CONFIG_RT_GROUP_SCHED=y # CONFIG_CGROUP_PIDS is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_HUGETLB is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_PERF=y CONFIG_CGROUP_DEBUG=y # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y # CONFIG_USER_NS is not set CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set CONFIG_RD_XZ=y # CONFIG_RD_LZO is no
Re: [PATCH 09/12] sparc: move exports to definitions
From: Al Viro Date: Fri, 29 Jan 2016 19:18:31 + > From: Al Viro > > Signed-off-by: Al Viro Acked-by: David S. Miller
Re: [PATCH 11/12] [sparc] unify 32bit and 64bit string.h
From: Al Viro Date: Fri, 29 Jan 2016 19:18:33 + > From: Al Viro > > Signed-off-by: Al Viro Acked-by: David S. Miller
Re: [PATCH 12/12] sparc32: debride memcpy.S a bit
From: Al Viro Date: Fri, 29 Jan 2016 19:18:34 + > From: Al Viro > > unreachable code, unused macros... > > Signed-off-by: Al Viro Acked-by: David S. Miller
Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences
On Fri, Jan 29, 2016 at 10:01 PM, Dan Williams wrote: > On Fri, Jan 29, 2016 at 9:28 PM, Matthew Wilcox wrote: >> On Fri, Jan 29, 2016 at 11:28:15AM -0700, Ross Zwisler wrote: >>> I guess I need to go off and understand if we can have DAX mappings on such >>> a >>> device. If we can, we may have a problem - we can get the block_device from >>> get_block() in I/O path and the various fault paths, but we don't have >>> access >>> to get_block() when flushing via dax_writeback_mapping_range(). We avoid >>> needing it the normal case by storing the sector results from get_block() in >>> the radix tree. >> >> I think we're doing it wrong by storing the sector in the radix tree; we'd >> really need to store both the sector and the bdev which is too much data. >> >> If we store the PFN of the underlying page instead, we don't have this >> problem. Instead, we have a different problem; of the device going >> away under us. I'm trying to find the code which tears down PTEs when >> the device goes away, and I'm not seeing it. What do we do about user >> mappings of the device? >> > > I deferred the dax tear down code until next cycle as Al rightly > pointed out some needed re-works: > > https://lists.01.org/pipermail/linux-nvdimm/2016-January/003995.html If you store sectors in the radix and the device gets removed you still have to unmap user mappings of PFNs. So why is the device remove harder with the PFN vs bdev+sector radix entry? Either way you need a list of PFNs and their corresponding PTE's, right? And are we just talking graceful removal? Any plans for device failures?
Re: [PATCH v2 3/3] input: touchscreen: ad7879: add device tree support
I haven't checked the entire context, but it look suspicious to have the
kfree in the remove function and not in the probe function.
Unrlatedly, do the probe and remove functions really needed to be
exported?
julia
On Sat, 30 Jan 2016, kbuild test robot wrote:
>
> Hi Stefan,
>
> [auto build test WARNING on input/next]
> [also build test WARNING on v4.5-rc1 next-20160129]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improving the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Stefan-Agner/input-touchscreen-ad7879-move-header-to-platform_data-directory/20160130-075110
> base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
> :: branch date: 2 hours ago
> :: commit date: 2 hours ago
>
> >> drivers/input/touchscreen/ad7879.c:676:1-6: WARNING: invalid free of devm_
> >> allocated data
>
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 0e522b6d5ce3104accf736302f6de5386b9af789
> vim +676 drivers/input/touchscreen/ad7879.c
>
> b4be468c Michael Hennerich 2009-03-09 660
> ec51b7f5 Michael Hennerich 2010-01-19 661 err_remove_gpio:
> 4397c98a Mike Frysinger2010-06-30 662ad7879_gpio_remove(ts);
> b4be468c Michael Hennerich 2009-03-09 663 err_remove_attr:
> 4397c98a Mike Frysinger2010-06-30 664sysfs_remove_group(&dev->kobj,
> &ad7879_attr_group);
> 4397c98a Mike Frysinger2010-06-30 665 err_out:
> 4397c98a Mike Frysinger2010-06-30 666return ERR_PTR(err);
> b4be468c Michael Hennerich 2009-03-09 667 }
> 4397c98a Mike Frysinger2010-06-30 668 EXPORT_SYMBOL(ad7879_probe);
> b4be468c Michael Hennerich 2009-03-09 669
> 4397c98a Mike Frysinger2010-06-30 670 void ad7879_remove(struct ad7879
> *ts)
> b4be468c Michael Hennerich 2009-03-09 671 {
> 4397c98a Mike Frysinger2010-06-30 672ad7879_gpio_remove(ts);
> 4397c98a Mike Frysinger2010-06-30 673
> sysfs_remove_group(&ts->dev->kobj, &ad7879_attr_group);
> 4397c98a Mike Frysinger2010-06-30 674free_irq(ts->irq, ts);
> b4be468c Michael Hennerich 2009-03-09 675
> input_unregister_device(ts->input);
> b4be468c Michael Hennerich 2009-03-09 @676kfree(ts);
> b4be468c Michael Hennerich 2009-03-09 677 }
> 4397c98a Mike Frysinger2010-06-30 678 EXPORT_SYMBOL(ad7879_remove);
> b4be468c Michael Hennerich 2009-03-09 679
> b4be468c Michael Hennerich 2009-03-09 680 MODULE_AUTHOR("Michael Hennerich
> ");
> b4be468c Michael Hennerich 2009-03-09 681 MODULE_DESCRIPTION("AD7879(-1)
> touchscreen Driver");
> b4be468c Michael Hennerich 2009-03-09 682 MODULE_LICENSE("GPL");
>
> :: The code at line 676 was first introduced by commit
> :: b4be468cc1e65110d9144751bf7079dad6f142b7 Input: add AD7879 Touchscreen
> driver
>
> :: TO: Michael Hennerich
> :: CC: Dmitry Torokhov
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
Re: [PATCH] staging: rtl8723au: Fixes unnecessary return warning
Hi, Thank you for your reply. I've just sent version 2 of the patch with the blank lines removed. I will be happy to extend checkpatch.pl. As suggested by you, I am trying to detect such blank lines in a line removal patch by checking if the line above the deleted line was a blank line and the line following the deleted line had a closing brace. Can you please guide me and let me know if I am headed in the right direction. Thanks, Bhaktipriya On Sat, Jan 30, 2016 at 8:48 AM, Joe Perches wrote: > On Sat, 2016-01-30 at 14:09 +1100, Julian Calaby wrote: >> Hi Joe, > > Hello Julian. > >> On Sat, Jan 30, 2016 at 12:28 PM, Joe Perches >> wrote: >> > On Sat, 2016-01-30 at 10:17 +1100, Julian Calaby wrote: >> > > On Sat, Jan 30, 2016 at 5:00 AM, Jes Sorensen > > > t.com> wrote: >> > > > Bhaktipriya Shridhar writes: >> > > > > This patch fixes checkpatch.pl warning in rtw_mlme_ext.c >> > > > > file. >> > > > > WARNING: void function return statements are not generally >> > > > > useful >> > [] >> > > > > diff --git a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c >> > > > > b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c >> > [] >> > > > > @@ -2657,7 +2657,6 @@ static void issue_probersp(struct >> > > > > rtw_adapter *padapter, unsigned char *da) >> > > > > >> > > > > dump_mgntframe23a(padapter, pmgntframe); >> > > > > >> > > > > - return; >> > > > > } >> > > > >> > > > If you insist on pushing this rather unncessary change, please >> > > > do it >> > > > properly, and remove the blank line before the return statement >> > > > as well. >> > > >> > > As Jes said, you need to remove the blank lines before the >> > > returns >> > > too. checkpatch should have picked this up, you did run the patch >> > > through checkpatch before you sent it, right? >> > >> > checkpatch doesn't pick this up. >> > >> > If you'd like to make it do so, you're welcome to try >> > but it's likely a bit more complicated than it appears. >> >> I meant the extra blank lines, not the useless return statements. > > I understood what you meant. > > It's relatively difficult to determine that a line removal > patch causes a blank line to appear before a closing brace. > > You're welcome to extend checkpatch to find these things, > but there are likely many additional patch types that need > to be considered. Remember patches can add, modify and > delete lines. > > cheers, Joe
[PATCH] mfd: core: add macro for adding mfd cells
Most of MFD drivers add the mfd sub devices cells as follows:
static const struct mfd_cell as3722_devs[] = {
{
.name = "as3722-pinctrl",
},
{
.name = "as3722-regulator",
},
{
.name = "as3722-rtc",
.num_resources = ARRAY_SIZE(as3722_rtc_resource),
.resources = as3722_rtc_resource,
},
{
.name = "as3722-adc",
.num_resources = ARRAY_SIZE(as3722_adc_resource),
.resources = as3722_adc_resource,
},
};
Add defines for adding mfd cells so that it can be done in single line
as follows:
static const struct mfd_cell as3722_devs[] = {
DEFINE_MFD_CELL_NAME("as3722-pinctrl"),
DEFINE_MFD_CELL_NAME("as3722-regulator"),
DEFINE_MFD_CELL_NAME_RESOURCE("as3722-rtc", as3722_rtc_resource),
DEFINE_MFD_CELL_NAME_RESOURCE("as3722-adc", as3722_adc_resource),
};
Signed-off-by: Laxman Dewangan
---
I am sending this patch based on review comment recived on max77620 mfd patch
to use/add macro whereever possible.
Once this is reviewed and agreed, I will post series of mfd patches to use this
macro.
include/linux/mfd/core.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index bc6f7e0..508e586 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -14,6 +14,7 @@
#ifndef MFD_CORE_H
#define MFD_CORE_H
+#include
#include
struct irq_domain;
@@ -81,6 +82,20 @@ struct mfd_cell {
int num_parent_supplies;
};
+/* Defne mfd cells with name and resource */
+#define DEFINE_MFD_CELL_NAME_RESOURCE(_name, _res) \
+ { \
+ .name = (_name),\
+ .num_resources = ARRAY_SIZE((res)), \
+ .resources = (_res),\
+ }
+
+/* Defne mfd cells with name */
+#define DEFINE_MFD_CELL_NAME(_name)\
+ { \
+ .name = (_name),\
+ }
+
/*
* Convenience functions for clients using shared cells. Refcounting
* happens automatically, with the cell's enable/disable callbacks
--
2.1.4
Re: PCI device driver broken between 4.2 and 4.3
On Fri, Jan 29, 2016 at 8:31 AM, Bjorn Helgaas wrote: > > 991de2e59090 is related to IRQs, so I'd start by printing dev->irq in your > driver before and after you call pci_enable_device(). Add some printks in > pcibios_alloc_irq() and pcibios_enable_device() just to confirm that we got > there and when, e.g., add lines like this: looks like that commit removed pcibios_enable_irq for parent bridge. pci_enable_device==>pci_enable_bridge==>pci_enable_device==>pcibios_enable_device ==>pcibios_enable_irq without msi enabled. so pci=routeirq may workaround the problem. Thanks Yinghai
[PATCH 4/9] staging: lowmemorykiller: Make default lowmemorykiller debug message useful
From: Colin Cross
lowmemorykiller debug messages are inscrutable and mostly useful
for debugging the lowmemorykiller, not explaining why a process
was killed. Make the messages more useful by prefixing them
with "lowmemorykiller: " and explaining in more readable terms
what was killed, who it was killed for, and why it was killed.
The messages now look like:
[ 76.997631] lowmemorykiller: Killing 'droid.gallery3d' (2172), adj 1000,
[ 76.997635]to free 27436kB on behalf of 'kswapd0' (29) because
[ 76.997638]cache 122624kB is below limit 122880kB for oom_score_adj 1000
[ 76.997641]Free memory is -53356kB above reserved
A negative number for free memory above reserved means some of the
reserved memory has been used and is being regenerated by kswapd,
which is likely what called the shrinkers.
Cc: Android Kernel Team
Cc: Greg KH
Signed-off-by: Colin Cross
[jstultz: Minor checkpatch tweaks]
Signed-off-by: John Stultz
---
drivers/staging/android/lowmemorykiller.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index 806643d..98abec7 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -83,6 +83,7 @@ static unsigned long lowmem_scan(struct shrinker *s, struct
shrink_control *sc)
int tasksize;
int i;
short min_score_adj = OOM_SCORE_ADJ_MAX + 1;
+ int minfree = 0;
int selected_tasksize = 0;
short selected_oom_score_adj;
int array_size = ARRAY_SIZE(lowmem_adj);
@@ -96,8 +97,8 @@ static unsigned long lowmem_scan(struct shrinker *s, struct
shrink_control *sc)
if (lowmem_minfree_size < array_size)
array_size = lowmem_minfree_size;
for (i = 0; i < array_size; i++) {
- if (other_free < lowmem_minfree[i] &&
- other_file < lowmem_minfree[i]) {
+ minfree = lowmem_minfree[i];
+ if (other_free < minfree && other_file < minfree) {
min_score_adj = lowmem_adj[i];
break;
}
@@ -152,8 +153,8 @@ static unsigned long lowmem_scan(struct shrinker *s, struct
shrink_control *sc)
selected = p;
selected_tasksize = tasksize;
selected_oom_score_adj = oom_score_adj;
- lowmem_print(2, "select %d (%s), adj %hd, size %d, to kill\n",
-p->pid, p->comm, oom_score_adj, tasksize);
+ lowmem_print(2, "select '%s' (%d), adj %hd, size %d, to kill\n",
+p->comm, p->pid, oom_score_adj, tasksize);
}
if (selected) {
task_lock(selected);
@@ -166,9 +167,18 @@ static unsigned long lowmem_scan(struct shrinker *s,
struct shrink_control *sc)
if (selected->mm)
mark_oom_victim(selected);
task_unlock(selected);
- lowmem_print(1, "send sigkill to %d (%s), adj %hd, size %d\n",
-selected->pid, selected->comm,
-selected_oom_score_adj, selected_tasksize);
+ lowmem_print(1, "Killing '%s' (%d), adj %hd,\n"
+" to free %ldkB on behalf of '%s' (%d)
because\n"
+" cache %ldkB is below limit %ldkB for
oom_score_adj %hd\n"
+" Free memory is %ldkB above reserved\n",
+selected->comm, selected->pid,
+selected_oom_score_adj,
+selected_tasksize * (long)(PAGE_SIZE / 1024),
+current->comm, current->pid,
+other_file * (long)(PAGE_SIZE / 1024),
+minfree * (long)(PAGE_SIZE / 1024),
+min_score_adj,
+other_free * (long)(PAGE_SIZE / 1024));
lowmem_deathpending_timeout = jiffies + HZ;
rem += selected_tasksize;
}
--
1.9.1
[PATCH 3/9] staging: lowmemorykiller: Fix task_struct leak
From: San Mehat As it turns out, the CONFIG_PROFILING interfaces leak a task struct if the notifier chain returns NOTIFY_OK.. doh. This patch reworks lowmemkiller to use the new generic task free notifier chain. Cc: Android Kernel Team Cc: Greg KH Signed-off-by: San Mehat [jstultz: Commit subject tweak] Signed-off-by: John Stultz --- drivers/staging/android/lowmemorykiller.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c index 8b5a4a8..806643d 100644 --- a/drivers/staging/android/lowmemorykiller.c +++ b/drivers/staging/android/lowmemorykiller.c @@ -40,7 +40,6 @@ #include #include #include -#include #include static u32 lowmem_debug_level = 1; -- 1.9.1
[PATCH 5/9] staging: lowmemorykiller: Trace kill events.
From: Martijn Coenen
Allows for capturing lmk kill events and
their rationale.
Cc: Android Kernel Team
Cc: Greg KH
Signed-off-by: Martijn Coenen
[jstultz: Checkpatch fixups]
Signed-off-by: John Stultz
---
drivers/staging/android/lowmemorykiller.c | 14 +++--
drivers/staging/android/trace/lowmemorykiller.h | 40 +
2 files changed, 51 insertions(+), 3 deletions(-)
create mode 100644 drivers/staging/android/trace/lowmemorykiller.h
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index 98abec7..bda0e8a 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -42,6 +42,9 @@
#include
#include
+#define CREATE_TRACE_POINTS
+#include "trace/lowmemorykiller.h"
+
static u32 lowmem_debug_level = 1;
static short lowmem_adj[6] = {
0,
@@ -157,6 +160,8 @@ static unsigned long lowmem_scan(struct shrinker *s, struct
shrink_control *sc)
p->comm, p->pid, oom_score_adj, tasksize);
}
if (selected) {
+ long cache_size, cache_limit, free;
+
task_lock(selected);
send_sig(SIGKILL, selected, 0);
/*
@@ -167,6 +172,10 @@ static unsigned long lowmem_scan(struct shrinker *s,
struct shrink_control *sc)
if (selected->mm)
mark_oom_victim(selected);
task_unlock(selected);
+ cache_size = other_file * (long)(PAGE_SIZE / 1024);
+ cache_limit = minfree * (long)(PAGE_SIZE / 1024);
+ free = other_free * (long)(PAGE_SIZE / 1024);
+ trace_lowmemory_kill(selected, cache_size, cache_limit, free);
lowmem_print(1, "Killing '%s' (%d), adj %hd,\n"
" to free %ldkB on behalf of '%s' (%d)
because\n"
" cache %ldkB is below limit %ldkB for
oom_score_adj %hd\n"
@@ -175,10 +184,9 @@ static unsigned long lowmem_scan(struct shrinker *s,
struct shrink_control *sc)
selected_oom_score_adj,
selected_tasksize * (long)(PAGE_SIZE / 1024),
current->comm, current->pid,
-other_file * (long)(PAGE_SIZE / 1024),
-minfree * (long)(PAGE_SIZE / 1024),
+cache_size, cache_limit,
min_score_adj,
-other_free * (long)(PAGE_SIZE / 1024));
+free);
lowmem_deathpending_timeout = jiffies + HZ;
rem += selected_tasksize;
}
diff --git a/drivers/staging/android/trace/lowmemorykiller.h
b/drivers/staging/android/trace/lowmemorykiller.h
new file mode 100644
index 000..7d01bd4
--- /dev/null
+++ b/drivers/staging/android/trace/lowmemorykiller.h
@@ -0,0 +1,40 @@
+#undef TRACE_SYSTEM
+#define TRACE_INCLUDE_PATH ../../drivers/staging/android/trace
+#define TRACE_SYSTEM lowmemorykiller
+
+#if !defined(_TRACE_LOWMEMORYKILLER_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_LOWMEMORYKILLER_H
+
+#include
+
+TRACE_EVENT(lowmemory_kill,
+ TP_PROTO(struct task_struct *killed_task, long cache_size,
+long cache_limit, long free),
+
+ TP_ARGS(killed_task, cache_size, cache_limit, free),
+
+ TP_STRUCT__entry(
+ __array(char, comm, TASK_COMM_LEN)
+ __field(pid_t, pid)
+ __field(long, pagecache_size)
+ __field(long, pagecache_limit)
+ __field(long, free)
+ ),
+
+ TP_fast_assign(
+ memcpy(__entry->comm, killed_task->comm, TASK_COMM_LEN);
+ __entry->pid = killed_task->pid;
+ __entry->pagecache_size = cache_size;
+ __entry->pagecache_limit = cache_limit;
+ __entry->free = free;
+ ),
+
+ TP_printk("%s (%d), page cache %ldkB (limit %ldkB), free %ldKb",
+ __entry->comm, __entry->pid, __entry->pagecache_size,
+ __entry->pagecache_limit, __entry->free)
+);
+
+#endif /* !defined(_TRACE_LOWMEMORYKILLER_H) ||
defined(TRACE_HEADER_MULTI_READ) */
+
+/* This part must be outside protection */
+#include
--
1.9.1
[PATCH 6/9] staging: ion: Set minimum carveout heap allocation order to PAGE_SHIFT
From: Rajmal Menariya
In carveout heap, change minimum allocation order from 12 to
PAGE_SHIFT. After this change each bit in bitmap (genalloc -
General purpose special memory pool) represents one page size
memory.
Cc: sprd-ind-kernel-gr...@googlegroups.com
Cc: sanjeev.ya...@spreadtrum.com
Cc: Colin Cross
Cc: Android Kernel Team
Cc: Greg KH
Cc: Laura Abbott
Cc: Sumit Semwal
Signed-off-by: Rajmal Menariya
[jstultz: Reworked commit message]
Signed-off-by: John Stultz
---
drivers/staging/android/ion/ion_carveout_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c
b/drivers/staging/android/ion/ion_carveout_heap.c
index 9156d82..e702ce6 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -167,7 +167,7 @@ struct ion_heap *ion_carveout_heap_create(struct
ion_platform_heap *heap_data)
if (!carveout_heap)
return ERR_PTR(-ENOMEM);
- carveout_heap->pool = gen_pool_create(12, -1);
+ carveout_heap->pool = gen_pool_create(PAGE_SHIFT, -1);
if (!carveout_heap->pool) {
kfree(carveout_heap);
return ERR_PTR(-ENOMEM);
--
1.9.1
[PATCH 7/9] staging: ion: Handle the memory mapping correctly on x86
From: Vinil Cheeramvelil
This patch modifies the ion page pool code to address
limitation in x86 PAT. When one physical page is mapped
to multiple virtual pages, the same cache policy
should be used. Add set_memory_wc/uc call to avoid aliases.
If not, all mappings will be cached(write back).
Cc: Android Kernel Team
Cc: Greg KH
Cc: Laura Abbott
Cc: Sumit Semwal
Signed-off-by: Zhebin Jin
Signed-off-by: Vinil Cheeramvelil
Signed-off-by: John Stultz
---
drivers/staging/android/ion/Kconfig | 8 +++
drivers/staging/android/ion/ion_page_pool.c | 8 +++
drivers/staging/android/ion/ion_priv.h| 33 +++
drivers/staging/android/ion/ion_system_heap.c | 6 +++--
4 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index 19c1572..a15ff29 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -40,3 +40,11 @@ config ION_HISI
Choose this option if you wish to use ion on Hisilicon Platform.
source "drivers/staging/android/ion/hisilicon/Kconfig"
+
+config ION_POOL_CACHE_POLICY
+ bool "Ion set page pool cache policy"
+ depends on ION
+ default y if X86
+ help
+ Choose this option if need to explicity set cache policy of the
+ pages in the page pool.
diff --git a/drivers/staging/android/ion/ion_page_pool.c
b/drivers/staging/android/ion/ion_page_pool.c
index fd7e23e..59ee2f8 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -30,6 +30,8 @@ static void *ion_page_pool_alloc_pages(struct ion_page_pool
*pool)
if (!page)
return NULL;
+ ion_page_pool_alloc_set_cache_policy(pool, page);
+
ion_pages_sync_for_device(NULL, page, PAGE_SIZE << pool->order,
DMA_BIDIRECTIONAL);
return page;
@@ -38,6 +40,7 @@ static void *ion_page_pool_alloc_pages(struct ion_page_pool
*pool)
static void ion_page_pool_free_pages(struct ion_page_pool *pool,
struct page *page)
{
+ ion_page_pool_free_set_cache_policy(pool, page);
__free_pages(page, pool->order);
}
@@ -103,6 +106,11 @@ void ion_page_pool_free(struct ion_page_pool *pool, struct
page *page)
ion_page_pool_free_pages(pool, page);
}
+void ion_page_pool_free_immediate(struct ion_page_pool *pool, struct page
*page)
+{
+ ion_page_pool_free_pages(pool, page);
+}
+
static int ion_page_pool_total(struct ion_page_pool *pool, bool high)
{
int count = pool->low_count;
diff --git a/drivers/staging/android/ion/ion_priv.h
b/drivers/staging/android/ion/ion_priv.h
index 0239883..9a25ba6 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -26,6 +26,9 @@
#include
#include
#include
+#ifdef CONFIG_ION_POOL_CACHE_POLICY
+#include
+#endif
#include "ion.h"
@@ -381,6 +384,36 @@ struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask,
unsigned int order);
void ion_page_pool_destroy(struct ion_page_pool *);
struct page *ion_page_pool_alloc(struct ion_page_pool *);
void ion_page_pool_free(struct ion_page_pool *, struct page *);
+void ion_page_pool_free_immediate(struct ion_page_pool *, struct page *);
+
+#ifdef CONFIG_ION_POOL_CACHE_POLICY
+static inline void ion_page_pool_alloc_set_cache_policy
+ (struct ion_page_pool *pool,
+ struct page *page){
+ void *va = page_address(page);
+
+ if (va)
+ set_memory_wc((unsigned long)va, 1 << pool->order);
+}
+
+static inline void ion_page_pool_free_set_cache_policy
+ (struct ion_page_pool *pool,
+ struct page *page){
+ void *va = page_address(page);
+
+ if (va)
+ set_memory_wb((unsigned long)va, 1 << pool->order);
+}
+#else
+static inline void ion_page_pool_alloc_set_cache_policy
+ (struct ion_page_pool *pool,
+ struct page *page){ }
+
+static inline void ion_page_pool_free_set_cache_policy
+ (struct ion_page_pool *pool,
+ struct page *page){ }
+#endif
+
/** ion_page_pool_shrink - shrinks the size of the memory cached in the pool
* @pool: the pool
diff --git a/drivers/staging/android/ion/ion_system_heap.c
b/drivers/staging/android/ion/ion_system_heap.c
index d4c3e55..fa62cc4 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -85,8 +85,10 @@ static void free_buffer_page(struct ion_system_heap *heap,
if (!cached && !(buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE)) {
struct ion_page_pool *pool = heap->pools[order_to_index(order)];
-
-
[PATCH 2/9] staging: ashmem: Add missing include
From: Rom Lemarchand Include into ashmem.h to ensure referenced types are defined Cc: Android Kernel Team Cc: Greg KH Signed-off-by: Rom Lemarchand [jstultz: Minor commit message tweaks] Signed-off-by: John Stultz --- drivers/staging/android/uapi/ashmem.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/android/uapi/ashmem.h b/drivers/staging/android/uapi/ashmem.h index ba4743c..13df42d 100644 --- a/drivers/staging/android/uapi/ashmem.h +++ b/drivers/staging/android/uapi/ashmem.h @@ -13,6 +13,7 @@ #define _UAPI_LINUX_ASHMEM_H #include +#include #define ASHMEM_NAME_LEN256 -- 1.9.1
[PATCH 9/9] staging: ion: Fix page pool cache policy
From: Amit Pundir
Fix redundant "buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE"
checks in if(!cached ...) condition block.
The previous patch, "ion: Handle the memory mapping correctly on
x86", is broken on android-3.18+ kernels. It conflicts with
upstream commit commit 53a91c68fa7b ("staging: ion: Add private
buffer flag to skip page pooling on free"), and breaks the
ION_PRIV_FLAG_SHRINKER_FREE private flag check logic.
Cc: Android Kernel Team
Cc: Greg KH
Cc: Laura Abbott
Cc: Sumit Semwal
Reported-by: chenfeng
Signed-off-by: Amit Pundir
Signed-off-by: John Stultz
---
drivers/staging/android/ion/ion_system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_system_heap.c
b/drivers/staging/android/ion/ion_system_heap.c
index fa62cc4..57d115d 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -83,7 +83,7 @@ static void free_buffer_page(struct ion_system_heap *heap,
unsigned int order = compound_order(page);
bool cached = ion_buffer_cached(buffer);
- if (!cached && !(buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE)) {
+ if (!cached) {
struct ion_page_pool *pool = heap->pools[order_to_index(order)];
if (buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE)
ion_page_pool_free_immediate(pool, page);
--
1.9.1
[PATCH 1/9] staging: ashmem: Avoid deadlock with mmap/shrink
From: Laura Abbott
Both ashmem_mmap and ashmem_shrink take the ashmem_lock. It may
be possible for ashmem_mmap to invoke ashmem_shrink:
-000|mutex_lock(lock = 0x0)
-001|ashmem_shrink(?, sc = 0x0) <--- try to take ashmem_mutex again
-002|shrink_slab(shrink = 0xDA5F1CC0, nr_pages_scanned = 0, lru_pages
-002|=
-002|124)
-003|try_to_free_pages(zonelist = 0x0, ?, ?, ?)
-004|__alloc_pages_nodemask(gfp_mask = 21200, order = 1, zonelist =
-004|0xC11D0940,
-005|new_slab(s = 0xE4841E80, ?, node = -1)
-006|__slab_alloc.isra.43.constprop.50(s = 0xE4841E80, gfpflags =
-006|2148925462, ad
-007|kmem_cache_alloc(s = 0xE4841E80, gfpflags = 208)
-008|shmem_alloc_inode(?)
-009|alloc_inode(sb = 0xE480E800)
-010|new_inode_pseudo(?)
-011|new_inode(?)
-012|shmem_get_inode(sb = 0xE480E800, dir = 0x0, ?, dev = 0, flags =
-012|187)
-013|shmem_file_setup(?, ?, flags = 187)
-014|ashmem_mmap(?, vma = 0xC5D64210) < Acquire ashmem_mutex
-015|mmap_region(file = 0xDF8E2C00, addr = 1772974080, len = 233472,
-015|flags = 57,
-016|sys_mmap_pgoff(addr = 0, len = 230400, prot = 3, flags = 1, fd =
-016|157, pgoff
-017|ret_fast_syscall(asm)
-->|exception
-018|NUR:0x40097508(asm)
---|end of frame
Avoid this deadlock by using mutex_trylock in ashmem_shrink; if the mutex
is already held, do not attempt to shrink.
Cc: Greg KH
Cc: Android Kernel Team
Reported-by: Matt Wagantall
Reported-by: Syed Rameez Mustafa
Reported-by: Osvaldo Banuelos
Reported-by: Subbaraman Narayanamurthy
Signed-off-by: Laura Abbott
[jstultz: Minor commit message tweaks]
Signed-off-by: John Stultz
---
drivers/staging/android/ashmem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 5bb1283..8ae1308 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -441,7 +441,9 @@ ashmem_shrink_scan(struct shrinker *shrink, struct
shrink_control *sc)
if (!(sc->gfp_mask & __GFP_FS))
return SHRINK_STOP;
- mutex_lock(&ashmem_mutex);
+ if (!mutex_trylock(&ashmem_mutex))
+ return -1;
+
list_for_each_entry_safe(range, next, &ashmem_lru_list, lru) {
loff_t start = range->pgstart * PAGE_SIZE;
loff_t end = (range->pgend + 1) * PAGE_SIZE;
--
1.9.1
[PATCH 8/9] staging: ion: Add X86 dependency for ION_POOL_CACHE_POLICY
From: Daniel Rosenberg ION_POOL_CACHE_POLICY uses x86 specific commands. Only allow it to be used for x86. Cc: Android Kernel Team Cc: Greg KH Cc: Laura Abbott Cc: Sumit Semwal Signed-off-by: Daniel Rosenberg Signed-off-by: John Stultz --- drivers/staging/android/ion/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/android/ion/Kconfig b/drivers/staging/android/ion/Kconfig index a15ff29..e2ee3c3 100644 --- a/drivers/staging/android/ion/Kconfig +++ b/drivers/staging/android/ion/Kconfig @@ -43,7 +43,7 @@ source "drivers/staging/android/ion/hisilicon/Kconfig" config ION_POOL_CACHE_POLICY bool "Ion set page pool cache policy" - depends on ION + depends on ION && X86 default y if X86 help Choose this option if need to explicity set cache policy of the -- 1.9.1
[PATCH 0/9] staging: Updates from the Android tree
In reviewing the experimental/android-4.4 tree from AOSP, I realized there were a handful of patches to code in the staging/android directory. So I wanted to send these along for review, so if there were no objections they could be queued for 4.6. Let me know if there is any comments or feedback thanks -john Cc: Android Kernel Team Cc: Greg KH Cc: Laura Abbott Cc: Sumit Semwal Amit Pundir (1): staging: ion: Fix page pool cache policy Colin Cross (1): staging: lowmemorykiller: Make default lowmemorykiller debug message useful Daniel Rosenberg (1): staging: ion: Add X86 dependency for ION_POOL_CACHE_POLICY Laura Abbott (1): staging: ashmem: Avoid deadlock with mmap/shrink Martijn Coenen (1): staging: lowmemorykiller: Trace kill events. Rajmal Menariya (1): staging: ion: Set minimum carveout heap allocation order to PAGE_SHIFT Rom Lemarchand (1): staging: ashmem: Add missing include San Mehat (1): staging: lowmemorykiller: Fix task_struct leak Vinil Cheeramvelil (1): staging: ion: Handle the memory mapping correctly on x86 drivers/staging/android/ashmem.c| 4 ++- drivers/staging/android/ion/Kconfig | 8 + drivers/staging/android/ion/ion_carveout_heap.c | 2 +- drivers/staging/android/ion/ion_page_pool.c | 8 + drivers/staging/android/ion/ion_priv.h | 33 drivers/staging/android/ion/ion_system_heap.c | 8 +++-- drivers/staging/android/lowmemorykiller.c | 33 +++- drivers/staging/android/trace/lowmemorykiller.h | 40 + drivers/staging/android/uapi/ashmem.h | 1 + 9 files changed, 124 insertions(+), 13 deletions(-) create mode 100644 drivers/staging/android/trace/lowmemorykiller.h -- 1.9.1
Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences
On Fri, Jan 29, 2016 at 9:28 PM, Matthew Wilcox wrote: > On Fri, Jan 29, 2016 at 11:28:15AM -0700, Ross Zwisler wrote: >> I guess I need to go off and understand if we can have DAX mappings on such a >> device. If we can, we may have a problem - we can get the block_device from >> get_block() in I/O path and the various fault paths, but we don't have access >> to get_block() when flushing via dax_writeback_mapping_range(). We avoid >> needing it the normal case by storing the sector results from get_block() in >> the radix tree. > > I think we're doing it wrong by storing the sector in the radix tree; we'd > really need to store both the sector and the bdev which is too much data. > > If we store the PFN of the underlying page instead, we don't have this > problem. Instead, we have a different problem; of the device going > away under us. I'm trying to find the code which tears down PTEs when > the device goes away, and I'm not seeing it. What do we do about user > mappings of the device? > I deferred the dax tear down code until next cycle as Al rightly pointed out some needed re-works: https://lists.01.org/pipermail/linux-nvdimm/2016-January/003995.html
[PATCH v2] staging: rtl8723au: Fixes unnecessary return warning
This patch fixes checkpatch.pl warning in rtw_mlme_ext.c file.
WARNING: void function return statements are not generally useful
Signed-off-by: Bhaktipriya Shridhar
---
Changes in v2:
- Removed the unnecessary blank lines.
drivers/staging/rtl8723au/core/rtw_mlme_ext.c | 20
1 file changed, 20 deletions(-)
diff --git a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
index d28f29a..7cd0052 100644
--- a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
@@ -2656,8 +2656,6 @@ static void issue_probersp(struct rtw_adapter *padapter,
unsigned char *da)
pattrib->last_txcmdsz = pattrib->pktlen;
dump_mgntframe23a(padapter, pmgntframe);
-
- return;
}
static int _issue_probereq(struct rtw_adapter *padapter,
@@ -2957,8 +2955,6 @@ static void issue_auth(struct rtw_adapter *padapter,
struct sta_info *psta,
rtw_wep_encrypt23a(padapter, pmgntframe);
DBG_8723A("%s\n", __func__);
dump_mgntframe23a(padapter, pmgntframe);
-
- return;
}
#ifdef CONFIG_8723AU_AP_MODE
@@ -3338,8 +3334,6 @@ exit:
}
} else
kfree(pmlmepriv->assoc_req);
-
- return;
}
/* when wait_ack is true, this function should be called at process context */
@@ -4102,8 +4096,6 @@ static void rtw_site_survey(struct rtw_adapter *padapter)
pmlmeext->chan_scan_time = SURVEY_TO;
pmlmeext->sitesurvey_res.state = SCAN_DISABLE;
}
-
- return;
}
/* collect bss info from Beacon and Probe request/response frames. */
@@ -4759,8 +4751,6 @@ void report_survey_event23a(struct rtw_adapter *padapter,
rtw_enqueue_cmd23a(pcmdpriv, pcmd_obj);
pmlmeext->sitesurvey_res.bss_cnt++;
-
- return;
}
void report_surveydone_event23a(struct rtw_adapter *padapter)
@@ -4802,8 +4792,6 @@ void report_surveydone_event23a(struct rtw_adapter
*padapter)
DBG_8723A("survey done event(%x)\n", psurveydone_evt->bss_cnt);
rtw_enqueue_cmd23a(pcmdpriv, pcmd_obj);
-
- return;
}
void report_join_res23a(struct rtw_adapter *padapter, int res)
@@ -4850,8 +4838,6 @@ void report_join_res23a(struct rtw_adapter *padapter, int
res)
rtw_joinbss_event_prehandle23a(padapter, (u8 *)&pjoinbss_evt->network);
rtw_enqueue_cmd23a(pcmdpriv, pcmd_obj);
-
- return;
}
void report_del_sta_event23a(struct rtw_adapter *padapter,
@@ -4906,8 +4892,6 @@ void report_del_sta_event23a(struct rtw_adapter *padapter,
DBG_8723A("report_del_sta_event23a: delete STA, mac_id =%d\n", mac_id);
rtw_enqueue_cmd23a(pcmdpriv, pcmd_obj);
-
- return;
}
void report_add_sta_event23a(struct rtw_adapter *padapter,
@@ -4951,8 +4935,6 @@ void report_add_sta_event23a(struct rtw_adapter *padapter,
DBG_8723A("report_add_sta_event23a: add STA\n");
rtw_enqueue_cmd23a(pcmdpriv, pcmd_obj);
-
- return;
}
/
@@ -5394,8 +5376,6 @@ static void link_timer_hdl(unsigned long data)
issue_assocreq(padapter);
set_link_timer(pmlmeext, REASSOC_TO);
}
-
- return;
}
static void addba_timer_hdl(unsigned long data)
--
2.1.4
Re: [PATCH V2 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
On Fri, 2016-01-29 at 19:36 -0800, K. Y. Srinivasan wrote: > tree: https://na01.safelinks.protection.outlook.com/?url=https%3a%2 > f%2fgit.kernel.org%2fpub%2fscm%2flinux%2fkernel%2fgit%2ftorvalds%2fli > nux.git&data=01%7c01%7ckys%40microsoft.com%7ce2e0622715844b79ad7108d3 > 2796ec3c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ubr4GbBaNS%2ftO > z%2buJBk0CL9N0UNG9x2TidLgy6Yovg4%3d master > head: 03c21cb775a313f1ff19be59c5d02df3e3526471 > commit: dac582417bc449b1f7f572d3f1dd9d23eec15cc9 storvsc: Properly > support Fibre Channel devices > date: 3 weeks ago > config: x86_64-randconfig-s3-01281016 (attached as .config) > reproduce: > git checkout dac582417bc449b1f7f572d3f1dd9d23eec15cc9 > # save the attached .config to linux build tree > make ARCH=x86_64 > > All errors (new ones prefixed by >>): > >drivers/built-in.o: In function `storvsc_remove': > > > storvsc_drv.c:(.text+0x213af7): undefined reference to > > > `fc_remove_host' >drivers/built-in.o: In function `storvsc_drv_init': > > > storvsc_drv.c:(.init.text+0xcbcc): undefined reference to > > > `fc_attach_transport' > > > storvsc_drv.c:(.init.text+0xcc06): undefined reference to > > > `fc_release_transport' >drivers/built-in.o: In function `storvsc_drv_exit': > > > storvsc_drv.c:(.exit.text+0x123c): undefined reference to > > > `fc_release_transport' > > With this commit, the storvsc driver depends on FC atttributes. Make > this > dependency explicit. > > Signed-off-by: K. Y. Srinivasan > Reported-by: Fengguang Wu > --- > V2: Fixed the dependency based on suggestion by James Bottomley > > > drivers/scsi/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig > index 64eed87..ce0d07b 100644 > --- a/drivers/scsi/Kconfig > +++ b/drivers/scsi/Kconfig > @@ -594,6 +594,7 @@ config XEN_SCSI_FRONTEND > config HYPERV_STORAGE > tristate "Microsoft Hyper-V virtual storage driver" > depends on SCSI && HYPERV > + depends on SCSI_FC_ATTRS || SCSI_FC_ATTRS !=m No ... if you want to depend on the FC_ATTRS then a simple depend works. If you want to be able to build without them or with them, then that line must read depends on m || SCSI_FC_ATTRS != m James
Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences
On Fri, Jan 29, 2016 at 11:28:15AM -0700, Ross Zwisler wrote: > I guess I need to go off and understand if we can have DAX mappings on such a > device. If we can, we may have a problem - we can get the block_device from > get_block() in I/O path and the various fault paths, but we don't have access > to get_block() when flushing via dax_writeback_mapping_range(). We avoid > needing it the normal case by storing the sector results from get_block() in > the radix tree. I think we're doing it wrong by storing the sector in the radix tree; we'd really need to store both the sector and the bdev which is too much data. If we store the PFN of the underlying page instead, we don't have this problem. Instead, we have a different problem; of the device going away under us. I'm trying to find the code which tears down PTEs when the device goes away, and I'm not seeing it. What do we do about user mappings of the device?
Re: [PATCH 1/4] sched,time: remove non-power-of-two divides from __acct_update_integrals
Hi Rik, [auto build test ERROR on tip/sched/core] [also build test ERROR on v4.5-rc1 next-20160129] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/riel-redhat-com/sched-time-remove-non-power-of-two-divides-from-__acct_update_integrals/20160130-114019 config: i386-defconfig (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): kernel/built-in.o: In function `xacct_add_tsk': >> (.text+0x906b0): undefined reference to `__udivdi3' kernel/built-in.o: In function `xacct_add_tsk': (.text+0x906e3): undefined reference to `__udivdi3' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH net 5/6] net: mvneta: The mvneta_percpu_elect function should be atomic
From: Gregory CLEMENT
Date: Fri, 29 Jan 2016 17:26:06 +0100
> @@ -370,6 +370,8 @@ struct mvneta_port {
> struct net_device *dev;
> struct notifier_block cpu_notifier;
> int rxq_def;
> + /* protect */
> + spinlock_t lock;
>
> /* Core clock */
> struct clk *clk;
Protect what? This comment needs a lot of improvement.
Everyone knows a spinlock "protects" things, so if you aren't going
to actually describe what this lock protects, and in what contexts
the lock is used, you might as well not say anything at all.
Re: pull-request: wireless-drivers 2016-01-29
From: Kalle Valo Date: Fri, 29 Jan 2016 10:47:19 +0200 > few fixes for 4.5. Nothing really standing out, see the tag for > more info. Please let me know if you have any problems. Pulled, thanks Kalle.
Re: [PATCH] kernel/Makefile: remove the useless CFLAGS_REMOVE_cgroup-debug.o
On 2016/1/30 11:54, Li Bin wrote: > The file cgroup-debug.c had been removed from commit fe6934354f8e > (cgroups: move the cgroup debug subsys into cgroup.c to access internal > state). > Remain the CFLAGS_REMOVE_cgroup-debug.o = $(CC_FLAGS_FTRACE) > useless in kernel/Makefile. > > Signed-off-by: Li Bin Acked-by: Zefan Li > --- > kernel/Makefile |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/kernel/Makefile b/kernel/Makefile > index 53abf00..baa55e5 100644 > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -14,8 +14,7 @@ obj-y = fork.o exec_domain.o panic.o \ > obj-$(CONFIG_MULTIUSER) += groups.o > > ifdef CONFIG_FUNCTION_TRACER > -# Do not trace debug files and internal ftrace files > -CFLAGS_REMOVE_cgroup-debug.o = $(CC_FLAGS_FTRACE) > +# Do not trace internal ftrace files > CFLAGS_REMOVE_irq_work.o = $(CC_FLAGS_FTRACE) > endif > >
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64
Hi, Yury
On 1:09 2016/1/30, Yury Norov wrote:
On Fri, Jan 29, 2016 at 05:59:33PM +0800, Zhangjian (Bamvor) wrote:
Hi,
On 1:22 2016/1/15, Yury Norov wrote:
This is still RFC because we have no glibc yet, that correspnds new ABI
introduced here. And so we cannot run tests. LP64 and AARCH32 tests show
no regression though.
Hi,
Glad to see this version. I hope I could test it. Where could I find the
corresponding glibc? I could not find it in
http://github.com/norov/glibc.git. Or is there a plan to do it?
Besides compat wrappers discussed in these series, is there any other
blockers for upstream? I would suppose everyone is intestested in the
result of LTP...
Regards
Bamvor
Hi, Bamvor,
Just to order all commits, I created new ILP32 branch at [1], that
based on 4.4 kernel + [2] + [3]. There's no new glibc suitable for
rfc5. But I started with it, and I hope there will be progress soon.
Cool:)
You cannot run LTP as there are some syscalls that are called during
dynamic loading that fail, but you can try to build your test statically
agaginst current glibc, and there's a big chance it will work.
I have a set of 'hello-worlds' working that way.
Currrently, I got 300+ in ltplite with you glibc[1]. I will try static link
later.
If you have some specific test that you cannot run, you can send it to
me, and I will take a look on it.
Sure, I am reading the test results. Hope we could fix these failure
together.
Regards
Bamvor
[1] https://github.com/norov/glibc/tree/thunderx-ilp32-32time_toff_t
Yury
[1] https://github.com/norov/linux/tree/rfc5
[2] http://permalink.gmane.org/gmane.linux.kernel/2116021
[3] http://comments.gmane.org/gmane.linux.kernel/2134747
v3: https://lkml.org/lkml/2014/9/3/704
v4: https://lkml.org/lkml/2015/4/13/691
v5: https://lkml.org/lkml/2015/9/29/911
v6:
- time_t, __kenel_off_t and other types turned to be 32-bit
for compatibility reasons (after v5 discussion);
- related changes applied to ILP32 syscall table and handlers;
- ILP32 VDSO code excluded. It's not mandatory, and caused questions
during review process. We definitely make sure we will follow up
with a VDSO later on because it is needed for performance reasons;
- fixed build issues with different combinations of AARCH32 / ILP32
enabling in config;
- ILP32 TLS bug fixed;
- entry32-common.S introduced to hold wrappers needed for both ILP32
and AARCH32_EL0;
- documentation updated according to latest changes;
- rebased to the current head;
- coding style re-checked;
- ILP32 syscall table turned around.
rfc3:
- all structures and system calls are just like AARCH32 ones now. with 2
exceptions: syscalls that take 64-bit parameter in 2 32-bit regosters
are replaced with LP64 version; struct rt_sigframe is constructed both
from LP64 and AARCH32 fields to be consistent with AARCH64 register set;
- documentation rewritten accordingly;
- common code for all 3 ABIs is moved to separated files for easy use,
new headers and objects are introduced, incl: is_compat.h, thread_bits.h,
signal_common.h, signal32_common.h.
- ILP32 VDSO code restored, Nathans comments are addressed;
- patch "arm64: ilp32: force IPC_64 in msgctl, shmctl, semctl" removed, as
Arnd suggested general solution for IPC_64 problem.
rfc4:
- sys_ilp32.c syscall list is fixed according to comments;
- binfmt_elf32.c and binfmt_ilp32.c are introduced to host the code handling
corresponding formats;
- statfs64, fstsatfs64 and mmap wrappers are removed;
- rebased on v4.4-rc8 + http://www.spinics.net/lists/kernel/msg2151759.html
rfc5:
- addressed rfc4 comments;
- turned s390 compat wrappers to be generic and applied it to arm64/ilp32.
Heiko Carsten and Martin Schwidefsky added to CC as s390 maintainers.
Andrew Pinski (6):
arm64: ensure the kernel is compiled for LP64
arm64: rename COMPAT to AARCH32_EL0 in Kconfig
arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0
instead
arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
it
arm64:ilp32: add ARM64_ILP32 to Kconfig
Bamvor Jian Zhang (1):
arm64: compat: change config dependences to aarch32
Philipp Tomsich (1):
arm64:ilp32: add vdso-ilp32 and use for signal return
Yury Norov (13):
arm64: ilp32: add documentation on the ILP32 ABI for ARM64
thread: move thread bits accessors to separated file
arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
arm64: introduce binfmt_elf32.c
arm64: ilp32: introduce binfmt_ilp32.c
arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
arm64: signal: wrap struct ucontext, fp and lr with struct sigframe
arm64: signal: share lp64 signal routines to ilp32
arm64: signal32: move ilp32 and aarch32 common code to separat
[PATCH] kernel/Makefile: remove the useless CFLAGS_REMOVE_cgroup-debug.o
The file cgroup-debug.c had been removed from commit fe6934354f8e (cgroups: move the cgroup debug subsys into cgroup.c to access internal state). Remain the CFLAGS_REMOVE_cgroup-debug.o = $(CC_FLAGS_FTRACE) useless in kernel/Makefile. Signed-off-by: Li Bin --- kernel/Makefile |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/kernel/Makefile b/kernel/Makefile index 53abf00..baa55e5 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -14,8 +14,7 @@ obj-y = fork.o exec_domain.o panic.o \ obj-$(CONFIG_MULTIUSER) += groups.o ifdef CONFIG_FUNCTION_TRACER -# Do not trace debug files and internal ftrace files -CFLAGS_REMOVE_cgroup-debug.o = $(CC_FLAGS_FTRACE) +# Do not trace internal ftrace files CFLAGS_REMOVE_irq_work.o = $(CC_FLAGS_FTRACE) endif -- 1.7.1
Re: [PATCH 1/2] sched,time: remove pointless divides from __acct_update_integrals
On 01/29/2016 10:36 PM, Frederic Weisbecker wrote: > On Sat, Jan 30, 2016 at 12:10:18AM +0100, Peter Zijlstra wrote: >> On Fri, Jan 29, 2016 at 05:22:59PM -0500, r...@redhat.com wrote: >>> From: Rik van Riel >>> >>> When running a microbenchmark calling an invalid syscall number >>> in a loop, on a nohz_full CPU, we spend a full 9% of our CPU >>> time in __acct_update_integrals. >>> >>> This function converts cputime_t to jiffies, to a timeval, only to >>> convert the timeval back to microseconds before discarding it. >>> >>> This patch leaves __acct_update_integrals functionally equivalent, >>> but speeds things up by about 11%, with 10 million calls to an >>> invalid syscall number dropping from 3.7 to 3.3 seconds. >> >> WTH is this taskstat crap anyway? Who uses it and can't we kill it? > > I have no idea what it's used for, it seems to be related to taskstats > over netlink. I'm not even sure if it's actually used. There don't seem > to be a runtime offcase and I bet distros enable it. So that stuff does > some work every millisecond on millions of machines while it probably > has very few users. > > SGI introduced it in 2006 and it seems that their last contribution there is > in 2008. The rest is kernel maintainance and fixes. > > If there are still users of it, then at least we should disable it on runtime > by > default. With all the non-power-of-2 divides removed, __acct_update_integrals disappears from the profile, even running many times per millisecond. At that point, native_sched_clock takes over the top of the profile, and the only way I can think of getting rid of that one is making sure it is not called twice for every syscall, irq, and kvm guest entry/exit. -- All rights reversed
Re: [PATCH net] net: dsa: mv88e6xxx: fix port VLAN maps
From: Vivien Didelot
Date: Thu, 28 Jan 2016 16:54:37 -0500
> Currently the port based VLAN maps should be configured to allow every
> port to egress frames on all other ports, except themselves.
>
> The debugfs interface shows that they are misconfigured. For instance, a
> 7-port switch has the following content in the related register 0x06:
>
>GLOBAL GLOBAL2 SERDES 0123456
> ...
> 6: 1fa41f0f 4 7f 7e 7d 7c 7b 7a 79
> ...
>
> This means that port 3 is allowed to talk to port 2-6, but cannot talk
> to ports 0 and 1. With this fix, port 3 can correctly talk to all ports
> except 3 itself:
>
>GLOBAL GLOBAL2 SERDES 0123456
> ...
> 6: 1fa41f0f 4 7e 7d 7b 77 6f 5f 3f
> ...
>
> Fixes: ede8098d0fef ("net: dsa: mv88e6xxx: bridges do not need an FID")
> Reported-by: Kevin Smith
> Signed-off-by: Vivien Didelot
Applied.
Re: [PATCHv2] net: moxart: use correct accessors for DMA memory
From: Arnd Bergmann Date: Thu, 28 Jan 2016 17:54:33 +0100 > The moxart ethernet driver confuses coherent DMA buffers with > MMIO registers. > > moxart_ether.c: In function 'moxart_mac_setup_desc_ring': > moxart_ether.c:146:428: error: passing argument 1 of '__fswab32' makes > integer from pointer without a cast [-Werror=int-conversion] > moxart_ether.c:74:39: warning: incorrect type in argument 3 (different > address spaces) > moxart_ether.c:74:39:expected void *cpu_addr > moxart_ether.c:74:39:got void [noderef] *tx_desc_base > > This leaves the basic logic alone and uses normal pointers for > the virtual address of the descriptor. As we cannot use readl/writel > to access them, we also introduce our own moxart_desc_read > moxart_desc_write helpers that perform the same endianess swap > as the original code, but without the address space conversion. > > The barriers are made explicit here where needed: Even in the worst-case > scenario, we just have to use a rmb() after checking ownership so > we don't read any input data before we are sure it is value, and we > use wmb() before transferring ownership back to the device. > > Signed-off-by: Arnd Bergmann Applied, thanks.
Re: [PATCHv2] ipv4: ipconfig: avoid unused ic_proto_used symbol
From: Arnd Bergmann Date: Thu, 28 Jan 2016 17:39:24 +0100 > When CONFIG_PROC_FS, CONFIG_IP_PNP_BOOTP, CONFIG_IP_PNP_DHCP and > CONFIG_IP_PNP_RARP are all disabled, we get a warning about the > ic_proto_used variable being unused: > > net/ipv4/ipconfig.c:146:12: error: 'ic_proto_used' defined but not used > [-Werror=unused-variable] > > This avoids the warning, by making the definition conditional on > whether a dynamic IP configuration protocol is configured. If not, > we know that the value is always zero, so we can optimize away the > variable and all code that depends on it. > > Signed-off-by: Arnd Bergmann Applied.
[PATCH 3/4] time,acct: drop irq save & restore from __acct_update_integrals
From: Rik van Riel
It looks like all the call paths that lead to __acct_update_integrals
already have irqs disabled, and __acct_update_integrals does not need
to disable irqs itself.
This is very convenient since about half the CPU time left in this
function was spent in local_irq_save alone.
Performance of a microbenchmark that calls an invalid syscall
ten million times in a row on a nohz_full CPU improves 21% vs.
4.5-rc1 with both the removal of divisions from __acct_update_integrals
and this patch, with runtime dropping from 3.7 to 2.9 seconds.
With these patches applied, the highest remaining cpu user in
the trace is native_sched_clock, which is addressed in the next
patch.
Suggested-by: Peter Zijlstra
Signed-off-by: Rik van Riel
---
kernel/tsacct.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/kernel/tsacct.c b/kernel/tsacct.c
index 8908f8b1d26e..b2663d699a72 100644
--- a/kernel/tsacct.c
+++ b/kernel/tsacct.c
@@ -124,26 +124,22 @@ static void __acct_update_integrals(struct task_struct
*tsk,
cputime_t utime, cputime_t stime)
{
cputime_t time, dtime;
- unsigned long flags;
u64 delta;
if (unlikely(!tsk->mm))
return;
- local_irq_save(flags);
time = stime + utime;
dtime = time - tsk->acct_timexpd;
delta = cputime_to_nsecs(dtime);
if (delta < TICK_NSEC)
- goto out;
+ return;
tsk->acct_timexpd = time;
/* The final unit will be Mbyte-usecs, see xacct_add_tsk */
tsk->acct_rss_mem1 += delta * get_mm_rss(tsk->mm) / 1024;
tsk->acct_vm_mem1 += delta * tsk->mm->total_vm / 1024;
-out:
- local_irq_restore(flags);
}
/**
--
2.5.0
Re: [PATCH net v2 0/4] net: add and use rx_nohandler stat counter
From: Jarod Wilson Date: Thu, 28 Jan 2016 10:49:44 -0500 > The network core tries to keep track of dropped packets, but some packets > you wouldn't really call dropped, so much as intentionally ignored, under > certain circumstances. One such case is that of bonding and team device > slaves that are currently inactive. Their respective rx_handler functions > return RX_HANDLER_EXACT (the only places in the kernel that return that), > which ends up tracking into the network core's __netif_receive_skb_core() > function's drop path, with no pt_prev set. On a noisy network, this can > result in a very rapidly incrementing rx_dropped counter, not only on the > inactive slave(s), but also on the master device, such as the following: ... Both my inbox and patchwork only show patch 2, 3, and 4. Where is #1? Thanks.
[PATCH 4/4] sched,time: only call account_{user,sys,guest,idle}_time once a jiffy
From: Rik van Riel
After removing __acct_update_integrals from the profile,
native_sched_clock remains as the top CPU user. This can be
reduced by only calling account_{user,sys,guest,idle}_time
once per jiffy for long running tasks on nohz_full CPUs.
This will reduce timing accuracy on nohz_full CPUs to jiffy
based sampling, just like on normal CPUs. It results in
totally removing native_sched_clock from the profile, and
significantly speeding up the syscall entry and exit path,
as well as irq entry and exit, and kvm guest entry & exit.
This code relies on another CPU advancing jiffies when the
system is busy. On a nohz_full system, this is done by a
housekeeping CPU.
A microbenchmark calling an invalid syscall number 10 million
times in a row speeds up an additional 30% over the numbers
with just the previous patches, for a total speedup of about
40% over 4.4 and 4.5-rc1.
Run times for the microbenchmark:
4.4 3.8 seconds
4.5-rc1 3.7 seconds
4.5-rc1 + first patch 3.3 seconds
4.5-rc1 + first 3 patches 3.1 seconds
4.5-rc1 + all patches 2.3 seconds
Signed-off-by: Rik van Riel
---
include/linux/sched.h | 1 +
kernel/sched/cputime.c | 35 +--
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a10494a94cc3..019c3af98503 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1532,6 +1532,7 @@ struct task_struct {
struct prev_cputime prev_cputime;
#ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
seqcount_t vtime_seqcount;
+ unsigned long vtime_jiffies;
unsigned long long vtime_snap;
enum {
/* Task is sleeping or running in a CPU with VTIME inactive */
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index b2ab2ffb1adc..923c110319b1 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -668,6 +668,15 @@ void thread_group_cputime_adjusted(struct task_struct *p,
cputime_t *ut, cputime
#endif /* !CONFIG_VIRT_CPU_ACCOUNTING_NATIVE */
#ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
+static bool vtime_jiffies_changed(struct task_struct *tsk, unsigned long now)
+{
+ if (tsk->vtime_jiffies == jiffies)
+ return false;
+
+ tsk->vtime_jiffies = jiffies;
+ return true;
+}
+
static unsigned long long vtime_delta(struct task_struct *tsk)
{
unsigned long long clock;
@@ -699,6 +708,9 @@ static void __vtime_account_system(struct task_struct *tsk)
void vtime_account_system(struct task_struct *tsk)
{
+ if (!vtime_jiffies_changed(tsk, jiffies))
+ return;
+
write_seqcount_begin(&tsk->vtime_seqcount);
__vtime_account_system(tsk);
write_seqcount_end(&tsk->vtime_seqcount);
@@ -707,7 +719,8 @@ void vtime_account_system(struct task_struct *tsk)
void vtime_gen_account_irq_exit(struct task_struct *tsk)
{
write_seqcount_begin(&tsk->vtime_seqcount);
- __vtime_account_system(tsk);
+ if (vtime_jiffies_changed(tsk, jiffies))
+ __vtime_account_system(tsk);
if (context_tracking_in_user())
tsk->vtime_snap_whence = VTIME_USER;
write_seqcount_end(&tsk->vtime_seqcount);
@@ -718,16 +731,19 @@ void vtime_account_user(struct task_struct *tsk)
cputime_t delta_cpu;
write_seqcount_begin(&tsk->vtime_seqcount);
- delta_cpu = get_vtime_delta(tsk);
tsk->vtime_snap_whence = VTIME_SYS;
- account_user_time(tsk, delta_cpu, cputime_to_scaled(delta_cpu));
+ if (vtime_jiffies_changed(tsk, jiffies)) {
+ delta_cpu = get_vtime_delta(tsk);
+ account_user_time(tsk, delta_cpu, cputime_to_scaled(delta_cpu));
+ }
write_seqcount_end(&tsk->vtime_seqcount);
}
void vtime_user_enter(struct task_struct *tsk)
{
write_seqcount_begin(&tsk->vtime_seqcount);
- __vtime_account_system(tsk);
+ if (vtime_jiffies_changed(tsk, jiffies))
+ __vtime_account_system(tsk);
tsk->vtime_snap_whence = VTIME_USER;
write_seqcount_end(&tsk->vtime_seqcount);
}
@@ -742,7 +758,8 @@ void vtime_guest_enter(struct task_struct *tsk)
* that can thus safely catch up with a tickless delta.
*/
write_seqcount_begin(&tsk->vtime_seqcount);
- __vtime_account_system(tsk);
+ if (vtime_jiffies_changed(tsk, jiffies))
+ __vtime_account_system(tsk);
current->flags |= PF_VCPU;
write_seqcount_end(&tsk->vtime_seqcount);
}
@@ -759,8 +776,12 @@ EXPORT_SYMBOL_GPL(vtime_guest_exit);
void vtime_account_idle(struct task_struct *tsk)
{
- cputime_t delta_cpu = get_vtime_delta(tsk);
+ cputime_t delta_cpu;
+
+ if (!vtime_jiffies_changed(tsk, jiffies))
+ return;
+ delta_cpu = get_vtime_delta(tsk);
account_idle_time(delta_cpu);
}
@@ -773,6 +794,7 @@ void arch_vtime_t
Re: [PATCH 1/2] sched,time: remove pointless divides from __acct_update_integrals
On Sat, Jan 30, 2016 at 12:10:18AM +0100, Peter Zijlstra wrote: > On Fri, Jan 29, 2016 at 05:22:59PM -0500, r...@redhat.com wrote: > > From: Rik van Riel > > > > When running a microbenchmark calling an invalid syscall number > > in a loop, on a nohz_full CPU, we spend a full 9% of our CPU > > time in __acct_update_integrals. > > > > This function converts cputime_t to jiffies, to a timeval, only to > > convert the timeval back to microseconds before discarding it. > > > > This patch leaves __acct_update_integrals functionally equivalent, > > but speeds things up by about 11%, with 10 million calls to an > > invalid syscall number dropping from 3.7 to 3.3 seconds. > > WTH is this taskstat crap anyway? Who uses it and can't we kill it? I have no idea what it's used for, it seems to be related to taskstats over netlink. I'm not even sure if it's actually used. There don't seem to be a runtime offcase and I bet distros enable it. So that stuff does some work every millisecond on millions of machines while it probably has very few users. SGI introduced it in 2006 and it seems that their last contribution there is in 2008. The rest is kernel maintainance and fixes. If there are still users of it, then at least we should disable it on runtime by default.
[PATCH 2/4] acct,time: change indentation in __acct_update_integrals
From: Rik van Riel
Change the indentation in __acct_update_integrals to make the function
a little easier to read.
Suggested-by: Peter Zijlstra
Signed-off-by: Rik van Riel
---
kernel/tsacct.c | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/kernel/tsacct.c b/kernel/tsacct.c
index 41667b23dbd0..8908f8b1d26e 100644
--- a/kernel/tsacct.c
+++ b/kernel/tsacct.c
@@ -123,26 +123,27 @@ void xacct_add_tsk(struct taskstats *stats, struct
task_struct *p)
static void __acct_update_integrals(struct task_struct *tsk,
cputime_t utime, cputime_t stime)
{
- if (likely(tsk->mm)) {
- cputime_t time, dtime;
- unsigned long flags;
- u64 delta;
-
- local_irq_save(flags);
- time = stime + utime;
- dtime = time - tsk->acct_timexpd;
- delta = cputime_to_nsecs(dtime);
-
- if (delta < TICK_NSEC)
- goto out;
-
- tsk->acct_timexpd = time;
- /* The final unit will be Mbyte-usecs, see xacct_add_tsk */
- tsk->acct_rss_mem1 += delta * get_mm_rss(tsk->mm) / 1024;
- tsk->acct_vm_mem1 += delta * tsk->mm->total_vm / 1024;
- out:
- local_irq_restore(flags);
- }
+ cputime_t time, dtime;
+ unsigned long flags;
+ u64 delta;
+
+ if (unlikely(!tsk->mm))
+ return;
+
+ local_irq_save(flags);
+ time = stime + utime;
+ dtime = time - tsk->acct_timexpd;
+ delta = cputime_to_nsecs(dtime);
+
+ if (delta < TICK_NSEC)
+ goto out;
+
+ tsk->acct_timexpd = time;
+ /* The final unit will be Mbyte-usecs, see xacct_add_tsk */
+ tsk->acct_rss_mem1 += delta * get_mm_rss(tsk->mm) / 1024;
+ tsk->acct_vm_mem1 += delta * tsk->mm->total_vm / 1024;
+out:
+ local_irq_restore(flags);
}
/**
--
2.5.0
[PATCH 1/4] sched,time: remove non-power-of-two divides from __acct_update_integrals
From: Rik van Riel
When running a microbenchmark calling an invalid syscall number
in a loop, on a nohz_full CPU, we spend a full 9% of our CPU
time in __acct_update_integrals.
This function converts cputime_t to jiffies, to a timeval, only to
convert the timeval back to microseconds before discarding it.
This patch leaves __acct_update_integrals functionally equivalent,
but speeds things up by about 12%, with 10 million calls to an
invalid syscall number dropping from 3.7 to 3.25 seconds.
Signed-off-by: Rik van Riel
---
kernel/tsacct.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/kernel/tsacct.c b/kernel/tsacct.c
index 975cb49e32bf..41667b23dbd0 100644
--- a/kernel/tsacct.c
+++ b/kernel/tsacct.c
@@ -93,9 +93,9 @@ void xacct_add_tsk(struct taskstats *stats, struct
task_struct *p)
{
struct mm_struct *mm;
- /* convert pages-usec to Mbyte-usec */
- stats->coremem = p->acct_rss_mem1 * PAGE_SIZE / MB;
- stats->virtmem = p->acct_vm_mem1 * PAGE_SIZE / MB;
+ /* convert pages-nsec/KB to Mbyte-usec, see __acct_update_integrals */
+ stats->coremem = p->acct_rss_mem1 * PAGE_SIZE / (1000 * KB);
+ stats->virtmem = p->acct_vm_mem1 * PAGE_SIZE / (1000 * KB);
mm = get_task_mm(p);
if (mm) {
/* adjust to KB unit */
@@ -125,22 +125,21 @@ static void __acct_update_integrals(struct task_struct
*tsk,
{
if (likely(tsk->mm)) {
cputime_t time, dtime;
- struct timeval value;
unsigned long flags;
u64 delta;
local_irq_save(flags);
time = stime + utime;
dtime = time - tsk->acct_timexpd;
- jiffies_to_timeval(cputime_to_jiffies(dtime), &value);
- delta = value.tv_sec;
- delta = delta * USEC_PER_SEC + value.tv_usec;
+ delta = cputime_to_nsecs(dtime);
- if (delta == 0)
+ if (delta < TICK_NSEC)
goto out;
+
tsk->acct_timexpd = time;
- tsk->acct_rss_mem1 += delta * get_mm_rss(tsk->mm);
- tsk->acct_vm_mem1 += delta * tsk->mm->total_vm;
+ /* The final unit will be Mbyte-usecs, see xacct_add_tsk */
+ tsk->acct_rss_mem1 += delta * get_mm_rss(tsk->mm) / 1024;
+ tsk->acct_vm_mem1 += delta * tsk->mm->total_vm / 1024;
out:
local_irq_restore(flags);
}
--
2.5.0
[PATCH 0/2] sched,time: reduce nohz_full syscall overhead 40%
unning with nohz_full introduces a fair amount of overhead. Specifically, various things that are usually done from the timer interrupt are now done at syscall, irq, and guest entry and exit times. However, some of the code that is called every single time has only ever worked at jiffy resolution. The code in __acct_update_integrals was also doing some unnecessary calculations. Getting rid of the unnecessary calculations, without changing any of the functionality in __acct_update_integrals gets us about an 11% win. Not calling the time statistics updating code more than once per jiffy, like is done on housekeeping CPUs and on all the CPUs of a non-nohz_full system, shaves off a further 30%. I tested this series with a microbenchmark calling an invalid syscall number ten million times in a row, on a nohz_full cpu. Run times for the microbenchmark: 4.4 3.8 seconds 4.5-rc1 3.7 seconds 4.5-rc1 + first patch 3.3 seconds 4.5-rc1 + first 3 patches 3.1 seconds 4.5-rc1 + all patches 2.3 seconds
Re: [PATCH] staging: rtl8723au: Fixes unnecessary return warning
On Sat, 2016-01-30 at 14:09 +1100, Julian Calaby wrote: > Hi Joe, Hello Julian. > On Sat, Jan 30, 2016 at 12:28 PM, Joe Perches > wrote: > > On Sat, 2016-01-30 at 10:17 +1100, Julian Calaby wrote: > > > On Sat, Jan 30, 2016 at 5:00 AM, Jes Sorensen > > t.com> wrote: > > > > Bhaktipriya Shridhar writes: > > > > > This patch fixes checkpatch.pl warning in rtw_mlme_ext.c > > > > > file. > > > > > WARNING: void function return statements are not generally > > > > > useful > > [] > > > > > diff --git a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c > > > > > b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c > > [] > > > > > @@ -2657,7 +2657,6 @@ static void issue_probersp(struct > > > > > rtw_adapter *padapter, unsigned char *da) > > > > > > > > > > Â Â dump_mgntframe23a(padapter, pmgntframe); > > > > > > > > > > -Â return; > > > > > Â } > > > > > > > > If you insist on pushing this rather unncessary change, please > > > > do it > > > > properly, and remove the blank line before the return statement > > > > as well. > > > > > > As Jes said, you need to remove the blank lines before the > > > returns > > > too. checkpatch should have picked this up, you did run the patch > > > through checkpatch before you sent it, right? > > > > checkpatch doesn't pick this up. > > > > If you'd like to make it do so, you're welcome to try > > but it's likely a bit more complicated than it appears. > > I meant the extra blank lines, not the useless return statements. I understood what you meant. It's relatively difficult to determine that a line removal patch causes a blank line to appear before a closing brace. You're welcome to extend checkpatch to find these things, but there are likely many additional patch types that need to be considered. Â Remember patches can add, modify and delete lines. cheers, Joe
Re: [PATCH] staging: rtl8723au: Fixes unnecessary return warning
Hi Joe, On Sat, Jan 30, 2016 at 12:28 PM, Joe Perches wrote: > On Sat, 2016-01-30 at 10:17 +1100, Julian Calaby wrote: >> On Sat, Jan 30, 2016 at 5:00 AM, Jes Sorensen >> wrote: >> > Bhaktipriya Shridhar writes: >> > > This patch fixes checkpatch.pl warning in rtw_mlme_ext.c file. >> > > WARNING: void function return statements are not generally useful > [] >> > > diff --git a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c >> > > b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c > [] >> > > @@ -2657,7 +2657,6 @@ static void issue_probersp(struct rtw_adapter >> > > *padapter, unsigned char *da) >> > > >> > > dump_mgntframe23a(padapter, pmgntframe); >> > > >> > > - return; >> > > } >> > >> > If you insist on pushing this rather unncessary change, please do it >> > properly, and remove the blank line before the return statement as well. >> >> As Jes said, you need to remove the blank lines before the returns >> too. checkpatch should have picked this up, you did run the patch >> through checkpatch before you sent it, right? > > checkpatch doesn't pick this up. > > If you'd like to make it do so, you're welcome to try > but it's likely a bit more complicated than it appears. I meant the extra blank lines, not the useless return statements. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/
[PATCH 2/2] powerpc/perf/hv-24x7: Display change in counter values
>From a1aa992fb25fb8e98a5c5724376ae8cc91463de3 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Mon, 25 Jan 2016 23:05:36 -0500
Subject: [PATCH 2/2] powerpc/perf/hv-24x7: Display change in counter values
For 24x7 counters, perf displays the raw value of the 24x7 counter, which
is a monotonically increasing value.
perf stat -C 0 -e \
'hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/' \
sleep 1
Performance counter stats for 'CPU(s) 0':
9,105,403,170 hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/
0.000425751 seconds time elapsed
In the typical usage of 'perf stat' this counter value is not as useful
as the _change_ in the counter value over the duration of the application.
Have h_24x7_event_init() set the event's prev_count to the raw value of
the 24x7 counter at the time of initialization. When the application
terminates, hv_24x7_event_read() will compute the change in value and
report to the perf tool. Similarly, for the transaction interface, clear
the event count to 0 at the beginning of the transaction.
perf stat -C 0 -e \
'hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/' \
sleep 1
Performance counter stats for 'CPU(s) 0':
245,758 hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/
1.006366383 seconds time elapsed
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/perf/hv-24x7.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index b7a9a03..77b958f 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1222,11 +1222,12 @@ static int h_24x7_event_init(struct perf_event *event)
return -EACCES;
}
- /* see if the event complains */
+ /* Get the initial value of the counter for this event */
if (single_24x7_request(event, &ct)) {
pr_devel("test hcall failed\n");
return -EIO;
}
+ (void)local64_xchg(&event->hw.prev_count, ct);
return 0;
}
@@ -1289,6 +1290,16 @@ static void h_24x7_event_read(struct perf_event *event)
h24x7hw = &get_cpu_var(hv_24x7_hw);
h24x7hw->events[i] = event;
put_cpu_var(h24x7hw);
+ /*
+* Clear the event count so we can compute the _change_
+* in the 24x7 raw counter value at the end of the txn.
+*
+* Note that we could alternatively read the 24x7 value
+* now and save its value in event->hw.prev_count. But
+* that would require issuing a hcall, which would then
+* defeat the purpose of using the txn interface.
+*/
+ local64_set(&event->count, 0);
}
put_cpu_var(hv_24x7_reqb);
--
2.5.3
[PATCH 1/2] powerpc/perf/hv-24x7: Fix usage with chip events
>From 9b5848ce1834a4d82fc251022035d36d9e26b500 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Sat, 23 Jan 2016 03:58:12 -0500
Subject: [PATCH 1/2] powerpc/perf/hv-24x7: Fix usage with chip events.
24x7 counters can belong to different domains (core, chip, virtual CPU
etc). For events in the 'chip' domain, sysfs entry currently looks like:
$ cd /sys/bus/event_source/devices/hv_24x7/events
$ cat PM_XLINK_CYCLES__PHYS_CHIP
domain=0x1,offset=0x230,core=?,lpar=0x0
where the required parameter, 'core=?' is specified with perf as:
perf stat -C 0 -e hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,core=1/ \
/bin/true
This is inconsistent in that 'core' is a required parameter for a chip
event. Instead, have the the sysfs entry display 'chip=?' for chip
events:
$ cd /sys/bus/event_source/devices/hv_24x7/events
$ cat PM_XLINK_CYCLES__PHYS_CHIP
domain=0x1,offset=0x230,chip=?,lpar=0x0
We also need to add a 'chip' entry in the sysfs format directory:
$ ls /sys/bus/event_source/devices/hv_24x7/format
chip core domain lpar offset vcpu
(new)
so the perf tool can automatically check usage and format the chip
parameter correctly:
$ perf stat -C 0 -v -e hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP/ \
/bin/true
Required parameter 'chip' not specified
invalid or unsupported event: 'hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP/'
$ perf stat -C 0 -v -e hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,chip=1/ \
/bin/true
hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,chip=1/: 0 6628908 6628908
Performance counter stats for 'CPU(s) 0':
0 hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,chip=1/
0.006606970 seconds time elapsed
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/perf/hv-24x7.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 9f9dfda..b7a9a03 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -101,6 +101,7 @@ static bool catalog_entry_domain_is_valid(unsigned domain)
EVENT_DEFINE_RANGE_FORMAT(domain, config, 0, 3);
/* u16 */
EVENT_DEFINE_RANGE_FORMAT(core, config, 16, 31);
+EVENT_DEFINE_RANGE_FORMAT(chip, config, 16, 31);
EVENT_DEFINE_RANGE_FORMAT(vcpu, config, 16, 31);
/* u32, see "data_offset" */
EVENT_DEFINE_RANGE_FORMAT(offset, config, 32, 63);
@@ -115,6 +116,7 @@ static struct attribute *format_attrs[] = {
&format_attr_domain.attr,
&format_attr_offset.attr,
&format_attr_core.attr,
+ &format_attr_chip.attr,
&format_attr_vcpu.attr,
&format_attr_lpar.attr,
NULL,
@@ -289,10 +291,16 @@ static char *event_fmt(struct hv_24x7_event_data *event,
unsigned domain)
const char *sindex;
const char *lpar;
- if (is_physical_domain(domain)) {
+ switch (domain) {
+ case HV_PERF_DOMAIN_PHYS_CHIP:
+ lpar = "0x0";
+ sindex = "chip";
+ break;
+ case HV_PERF_DOMAIN_PHYS_CORE:
lpar = "0x0";
sindex = "core";
- } else {
+ break;
+ default:
lpar = "?";
sindex = "vcpu";
}
@@ -1089,10 +1097,16 @@ static int add_event_to_24x7_request(struct perf_event
*event,
return -EINVAL;
}
- if (is_physical_domain(event_get_domain(event)))
+ switch (event_get_domain(event)) {
+ case HV_PERF_DOMAIN_PHYS_CHIP:
+ idx = event_get_chip(event);
+ break;
+ case HV_PERF_DOMAIN_PHYS_CORE:
idx = event_get_core(event);
- else
+ break;
+ default:
idx = event_get_vcpu(event);
+ }
i = request_buffer->num_requests++;
req = &request_buffer->requests[i];
--
2.5.3
Re: [PATCH 03/15] mips: use of_platform_default_populate() to populate default bus
On 2016/1/30 0:00, Joshua Henderson wrote:
> On 01/26/2016 09:27 PM, Kefeng Wang wrote:
>> Use helper of_platform_default_populate() in linux/of_platform
>> when possible, instead of calling of_platform_populate() with
>> the default match table.
>>
>> Cc: Ralf Baechle
>> Signed-off-by: Kefeng Wang
>> ---
>> arch/mips/ath79/setup.c | 2 +-
>> arch/mips/jz4740/setup.c | 2 +-
>> arch/mips/mti-sead3/sead3-setup.c | 2 +-
>> arch/mips/pic32/pic32mzda/init.c | 3 +--
>> arch/mips/pistachio/init.c| 2 +-
>> arch/mips/xilfpga/init.c | 2 +-
>> 6 files changed, 6 insertions(+), 7 deletions(-)
>>
>
> [...]
>
>> diff --git a/arch/mips/pic32/pic32mzda/init.c
>> b/arch/mips/pic32/pic32mzda/init.c
>> index 775ff90..77ecf32 100644
>> --- a/arch/mips/pic32/pic32mzda/init.c
>> +++ b/arch/mips/pic32/pic32mzda/init.c
>> @@ -147,8 +147,7 @@ static int __init plat_of_setup(void)
>> panic("Device tree not present");
>>
>> pic32_of_prepare_platform_data(pic32_auxdata_lookup);
>> -if (of_platform_populate(NULL, of_default_bus_match_table,
>> - pic32_auxdata_lookup, NULL))
>> +if (of_platform_default_populate(NULL, pic32_auxdata_lookup, NULL))
>> panic("Failed to populate DT");
>>
>> return 0;
>
> I'll one-up just compile-testing for this.
Hi Joshua, Many thanks.
>
> Tested-by: Joshua Henderson
>
> [...]
>
>
> .
>
Re: [PATCH] arm64: Allow vmalloc regions to be set with set_memory_*
On 2016/1/29 19:02, Mark Rutland wrote: > On Fri, Jan 29, 2016 at 09:21:40AM +0800, Xishi Qiu wrote: >> On 2016/1/28 22:27, Mark Rutland wrote: >>> On Thu, Jan 28, 2016 at 07:47:09PM +0800, Xishi Qiu wrote: Hi Mark, Is it safe in the following path? alloc the whole linear map section >>> >>> I don't understand what you mean by this, you will need to elaborate. >>> The terms "alloc" and "section" can mean a number of different things in >>> this context. >>> cpu A write something on it cpu B write something on it cpu C set read only flag and call flush_tlb_kernel_range() >>> >>> If you want to modify a portion of the linear map, this will not work. >>> Modfiying the linear map in this manner is not safe. >>> >>> If you want an alias of the linear map which was mapped using pages, and >>> you wanted to change that alias, that could work. >>> >> >> Hi Mark, >> >> I mean I change the whole section(maybe 1G?) in linear map. > > If you mean something that was mapped with a section (i.e. a block entry > in some level of page table), then no. The linear map is not open to > this kind of change, as portions of the region may be in use elsewhere > within Linux. > >> In our software, kernel create mapping(linear map) on special memory, >> and >> it is separated from buddy system, the service manage the special memory >> itself. > > This is not what the linear map is for. What exactly is this "special > memory"? > > Is it some persistent memory? > > Is it normal memory that you wish to use for some communication with > other agents and/or DMA? > > Is it normal memory that you simply have a special use-case for? > >> And the service alloc/free the memory based on the physical address, so if >> the service want to change the prot dynamically, vmalloc doesn't work, and >> fixmap is a little complex. > > Without further explanation of your use-case, this doesn't make sense to > me. I don't understand why the physical address matters -- that implies > you have other agents accessing this memory. If that's the case, I don't > see what changing the permissions buys you. > > Regardless, it sounds like either we're missing some infrastructure, or > you are mis-using existing APIs. > >> I think if I create the spacial memory in 4kb, then the service could >> use set_memory_ro() directly, right? > > Perhaps. If it's a vmalloc'd area, then yes (once Ard's patch to allow > that is in). I have more general concerns with your approach, in that I > still do not understand the problem you are trying to solve. > Hi Mark, Thanks for your reply. Maybe I didn't express it clearly, sorry for it. The abstract process is the following: 1. do not create a large block, use 4kb for all of the memory(regardless of performance). setup_arch->paging_init()->map_mem()->__map_memblock()->create_mapping() 2. alloc a page and get the the linear mapping address. 3. modify judgment condition of the function set_memory_ro(), so it could handle the linear mapping range. 4. use set_memory_ro() to change the prot flag of the page which we get in step 2. Is it safe? Thanks, Xishi Qiu > Thanks, > Mark. > > . >
Re: [PATCH v2] locktorture: Fix NULL pointer when torture_type is invalid
Hi Paul,
On 2016/1/28 12:25, Kefeng Wang wrote:
> Insmod locktorture with torture_type=mutex will lead to crash,
>
> Unable to handle kernel NULL pointer dereference at virtual address 0008
> pgd = ffc0f6c1
> [0008] *pgd=00013b221003, *pud=00013b221003,
> *pmd=a
> Internal error: Oops: 9406 [#1] PREEMPT SMP
> Modules linked in: locktorture(+) torture
> CPU: 2 PID: 1462 Comm: insmod Not tainted 4.4.0+ #19
> Hardware name: linux,dummy-virt (DT)
> task: ffc0fb2b3700 ti: ffc0fa938000 task.ti: ffc0fa938000
> PC is at __torture_print_stats+0x18/0x180 [locktorture]
> LR is at lock_torture_stats_print+0x68/0x110 [locktorture]
> pc : [] lr : [] pstate: 6145
> sp : ffc0fa93bb20
> [snip...]
> Call trace:
> [] __torture_print_stats+0x18/0x180 [locktorture]
> [] lock_torture_stats_print+0x68/0x110 [locktorture]
> [] lock_torture_cleanup+0xc4/0x278 [locktorture]
> [] lock_torture_init+0x144/0x5b0 [locktorture]
> [] do_one_initcall+0x94/0x1a0
> [] do_init_module+0x60/0x1c8
> [] load_module+0x1880/0x1c9c
> [] SyS_finit_module+0x7c/0x88
> [] el0_svc_naked+0x24/0x28
>
> Fix it by check statp in __torture_print_stats(), if it is NULL, just
> create a lock-torture-statistics message with zero statistic argument.
It is keep to get the statistics printout at the end if with bad argument,
what's your opinion about this version？
Thanks,
Kefeng
>
> Cc: Josh Triplett
> Cc: Paul E. McKenney
> Signed-off-by: Kefeng Wang
> ---
> kernel/locking/locktorture.c | 24 ++--
> 1 file changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
> index 8ef1919..7f0cf9c 100644
> --- a/kernel/locking/locktorture.c
> +++ b/kernel/locking/locktorture.c
> @@ -647,19 +647,23 @@ static void __torture_print_stats(char *page,
> bool fail = 0;
> int i, n_stress;
> long max = 0;
> - long min = statp[0].n_lock_acquired;
> + long min = 0;
> long long sum = 0;
>
> - n_stress = write ? cxt.nrealwriters_stress : cxt.nrealreaders_stress;
> - for (i = 0; i < n_stress; i++) {
> - if (statp[i].n_lock_fail)
> - fail = true;
> - sum += statp[i].n_lock_acquired;
> - if (max < statp[i].n_lock_fail)
> - max = statp[i].n_lock_fail;
> - if (min > statp[i].n_lock_fail)
> - min = statp[i].n_lock_fail;
> + if (statp) {
> + min = statp[0].n_lock_acquired;
> + n_stress = write ? cxt.nrealwriters_stress :
> cxt.nrealreaders_stress;
> + for (i = 0; i < n_stress; i++) {
> + if (statp[i].n_lock_fail)
> + fail = true;
> + sum += statp[i].n_lock_acquired;
> + if (max < statp[i].n_lock_fail)
> + max = statp[i].n_lock_fail;
> + if (min > statp[i].n_lock_fail)
> + min = statp[i].n_lock_fail;
> + }
> }
> +
> page += sprintf(page,
> "%s: Total: %lld Max/Min: %ld/%ld %s Fail: %d %s\n",
> write ? "Writes" : "Reads ",
>
Re: [PATCH 01/31] Add hard/soft lockup debugger entry points
On 1/29/16, Ingo Molnar wrote: > > * Jeffrey Merkey wrote: > >> On 1/28/16, Thomas Gleixner wrote: >> > On Thu, 28 Jan 2016, Jeffrey Merkey wrote: >> >> On 1/28/16, Thomas Gleixner wrote: >> >> > I'm probably missing something obvious here. >> >> >> >> It's a pain in the butt to grep around through assembly language in a >> >> function in watchdog.c that has everything declared static with no >> >> symbols. >> >> It's a lot easier just to insert an INT3 in the section of code that >> >> has the >> >> mouse caught in the trap (inside a function that triggers the hard >> >> lockup) -- >> >> after all -- that's what the instruction is for. >> > >> > AFAICT, debuggers can set breakpoints on arbitrary code lines without >> > grepping >> > through assembly language. If you don't have the debug information >> > available, >> > then using a debugger is pointless anyway. >> > >> > This is beyond silly. If we follow your argumentation we need another >> > gazillion of conditional breakpoints in the kernel. Definitely not. >> > >> > Thanks, >> > >> >tglx >> >> If you don't get it Thomas, I don't know what else to say. [...] > > He provided specific technical arguments: > >> > AFAICT, debuggers can set breakpoints on arbitrary code lines without >> > grepping >> > through assembly language. > > Thomas's argument is that live kernel debuggers are already able to insert > breakpoints just fine, without us having to artificially uglify the source > code > like your patch series does. > I agree that this patch series is less than ideal. > ... but instead of addressing his technical point (which is perfectly > valid), you > replied with a condescending tone. You are quickly establishing yourself as > a > contributor who is difficult to work with. > Well, Ingo, I guess we both have articles smeared all over the internet about how we are hard to deal with. You have a few, I have a few. Other people have them to. People who make a difference ruffle feathers. It's the nature of change. The only person that likes change is a wet baby. > As to Thomas's point: on typical distro kernels we at minimum have the > kallsyms > data, but also the System.map in general on packaged kernels. Having > function > symbols is more than enough to start a disassembly from, and the breakpoint > can be > set from there. > Well, I can certainly do all that, all I was suggesting was let linux find the bugs for you and pop into a debugger if one is active. > If you intentionally and completely throw away all symbol data then > debuggability > decreases drastically. That's nothing new - don't do that. Note that > disassembly > from a live debugger is generally _still_ possible: as function entries are > > usually pretty easy to recognize signatures - and generally there's enough > padding > for cache alignment reasons for even a 'blind' disassembly starting say 1KB > before > the intended breakpoint to actually show correct disassembly. > > So I don't see any technical reason to apply your patch-set in that form. > I would agree that something more elegant is needed. >> [...] Right now the only debugger that provides disassembly on a single >> running >> live Linux system is the one I use unless you want to use a serial >> connection >> with kgdb. [...] > > Given that at least in the x86 space most systems have a real or an emulated > > serial line (the latter via management interfaces), this isn't a big > limitation in > practice. > A live debugger on actual hardware is a far cry from a simulated UML/KVM/QEMU style environment. It's just not the same thing. And I use kgdb with a virtual serial connection, but GDB has got to be one of the most user hostile interfaces on the planet. It's plain hard to use with long commands and piss poor command recall. >> [...] All you are convincing me of is that you don't use a debugger or sit >> >> around looking at dissassembly all day long on live linux systems looking >> for >> bugs or you would understand why this is so helpful. So I totally >> understand >> why you don't get this. > > Just for the record, I don't see the point of the many artificial and ugly > breakpoints either that your series adds, so I'm NAK-ing this intrusive > form, > until better justification is given: How about I go off and refine this idea and submit something later. > > NAKed-by: Ingo Molnar > >> Think of it like git. Before git was around, everything was done with >> manual >> patches. Now we have git, and everything can be automated. Same thing >> here. >> Why do I want to grep around looking for a bug when I can have linux find >> it for >> me. > > Non sequitur: uglifying kernel source code (which has a very real cost for > only > marginal benefit - making it a net negative) has very little to do with the > > utility of Git (which has small cost for a big benefit, which makes it a net > > positive). There are thousands of BUG(), WARN(), BUG_ON() macros uglifying the code already.BFD. Jeff
[PATCH] ARM: dts: cros-ec-keyboard: Add LOCK key to keyboard matrix
From: James Chao The LOCK key is at KSO9/KSI3 for Chromebook Flip and other devices that use the Chrome OS EC keyboard matrix. Signed-off-by: James Chao Signed-off-by: Daniel Kurtz Signed-off-by: YH Huang --- arch/arm/boot/dts/cros-ec-keyboard.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/cros-ec-keyboard.dtsi b/arch/arm/boot/dts/cros-ec-keyboard.dtsi index 4e42f30c..c045105 100644 --- a/arch/arm/boot/dts/cros-ec-keyboard.dtsi +++ b/arch/arm/boot/dts/cros-ec-keyboard.dtsi @@ -55,6 +55,7 @@ MATRIX_KEY(0x03, 0x04, KEY_F5) MATRIX_KEY(0x03, 0x06, KEY_6) MATRIX_KEY(0x03, 0x08, KEY_MINUS) + MATRIX_KEY(0x03, 0x09, KEY_F13) MATRIX_KEY(0x03, 0x0b, KEY_BACKSLASH) MATRIX_KEY(0x03, 0x0c, KEY_MUHENKAN) -- 2.7.0.rc3.207.g0ac5344
RE: [PATCH] cputime: Fix timeval-->cputime conversion
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Friday, January 29, 2016 4:46 PM
> To: Zengtao (B)
> Cc: Thomas Gleixner; LKML; Frederic Weisbecker
> Subject: Re: [PATCH] cputime: Fix timeval-->cputime conversion
>
> On Friday 29 January 2016 03:12:37 Zengtao wrote:
> > > -Original Message-
> > > From: Arnd Bergmann [mailto:a...@arndb.de]
> > > Sent: Thursday, January 28, 2016 7:52 PM
> > > To: Thomas Gleixner
> > > Cc: Zengtao (B); LKML; Frederic Weisbecker
> > > Subject: Re: [PATCH] cputime: Fix timeval-->cputime conversion
> > >
> > > On Thursday 28 January 2016 09:22:04 Thomas Gleixner wrote:
> > > > Cc'ing Arnd
> > > >
> > > > On Thu, 28 Jan 2016, zengtao wrote:
> > > >
> > > > > The structure:
> > > > > struct timeval {
> > > > > __kernel_time_t tv_sec; /* seconds */
> > > > > __kernel_suseconds_ttv_usec;/* microseconds
> */
> > > > > };
> > > > > both __kernel_time_t and __kernel_suseconds_t are short than u64
> > > > > when it is 32bit platform, so force u64 conversion here.
> > > > >
> > > > > Signed-off-by: zengtao
> > > >
> > > > Reviewed-by: Thomas Gleixner
> > >
> > > This seems to miss timespec_to_cputime(), which has the same problem,
> > > so only setitimer() is fixed, but not nanosleep() or timer_settime().
> > Yes, I have checked the code just now, the timespec_to_cputime() has the
> > same problem.I found the origin issue through setitimer().And I think the
> > timespec_to_cputime() only affects timer_settime(),by which means it
> affects
> > nanosleep?
>
> Reading that code again, I think it does not affect sys_nanosleep, but
> it does affect sys_clock_nanosleep(CLOCK_PROCESS_CPUTIME_ID, ...)
> along with timer_create/timer_settime with CLOCK_PROCESS_CPUTIME_ID.
>
Got it, I will fix the timespec_to_cputime and resend the patch later.
> Arnd
Re: [PATCH v5] mtd: spi-nor: add hisilicon spi-nor flash controller driver
Hi Ezequiel, Thank you very much for your comments. I read them carefully. All of your suggestions are very good and helpful. I will correct in next version. Regards, Jiancheng . On 2016/1/29 22:45, Ezequiel Garcia wrote: > Hi Jiancheng, > > Driver looks mostly good. Few comments below. > > On 29 Jan 04:03 PM, Jiancheng Xue wrote: >> add hisilicon spi-nor flash controller driver >> >
Re: [PATCH] regulator: max77802: Fix DT binding document reference
W dniu 30.01.2016 o 01:09, Javier Martinez Canillas pisze: > The DT binding doc references the max77802 clocks header file which makes > no sense since of course it doesn't contain data related to the regulators. > > It's a copy and paste error, so add a reference to the correct header file. > > Signed-off-by: Javier Martinez Canillas > > --- > > Documentation/devicetree/bindings/regulator/max77802.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
[PATCH 1/1] pid: Fix spelling in comments
Accidentally discovered when I study this module.
Signed-off-by: Zhen Lei
---
kernel/pid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/pid.c b/kernel/pid.c
index f4ad91b..7efa5c9 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -588,7 +588,7 @@ void __init pidhash_init(void)
void __init pidmap_init(void)
{
- /* Veryify no one has done anything silly */
+ /* Verify no one has done anything silly */
BUILD_BUG_ON(PID_MAX_LIMIT >= PIDNS_HASH_ADDING);
/* bump default and minimum pid_max based on number of cpus */
--
2.5.0
[PATCH V2 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
tree: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit.kernel.org%2fpub%2fscm%2flinux%2fkernel%2fgit%2ftorvalds%2flinux.git&data=01%7c01%7ckys%40microsoft.com%7ce2e0622715844b79ad7108d32796ec3c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ubr4GbBaNS%2ftOz%2buJBk0CL9N0UNG9x2TidLgy6Yovg4%3d master head: 03c21cb775a313f1ff19be59c5d02df3e3526471 commit: dac582417bc449b1f7f572d3f1dd9d23eec15cc9 storvsc: Properly support Fibre Channel devices date: 3 weeks ago config: x86_64-randconfig-s3-01281016 (attached as .config) reproduce: git checkout dac582417bc449b1f7f572d3f1dd9d23eec15cc9 # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/built-in.o: In function `storvsc_remove': >> storvsc_drv.c:(.text+0x213af7): undefined reference to `fc_remove_host' drivers/built-in.o: In function `storvsc_drv_init': >> storvsc_drv.c:(.init.text+0xcbcc): undefined reference to >> `fc_attach_transport' >> storvsc_drv.c:(.init.text+0xcc06): undefined reference to >> `fc_release_transport' drivers/built-in.o: In function `storvsc_drv_exit': >> storvsc_drv.c:(.exit.text+0x123c): undefined reference to >> `fc_release_transport' With this commit, the storvsc driver depends on FC atttributes. Make this dependency explicit. Signed-off-by: K. Y. Srinivasan Reported-by: Fengguang Wu --- V2: Fixed the dependency based on suggestion by James Bottomley drivers/scsi/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 64eed87..ce0d07b 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -594,6 +594,7 @@ config XEN_SCSI_FRONTEND config HYPERV_STORAGE tristate "Microsoft Hyper-V virtual storage driver" depends on SCSI && HYPERV + depends on SCSI_FC_ATTRS || SCSI_FC_ATTRS !=m default HYPERV help Select this option to enable the Hyper-V virtual storage driver. -- 1.7.4.1
Re: [PATCH] ipv6: release idev lock before calling ipv6_ifa_notify()
From: Gregory Herrero
Date: Thu, 28 Jan 2016 09:34:52 +0100
> @@ -2302,8 +2302,11 @@ static void manage_tempaddrs(struct inet6_dev *idev,
> ift->flags &= ~IFA_F_DEPRECATED;
>
> spin_unlock(&ift->lock);
> - if (!(flags&IFA_F_TENTATIVE))
> + if (!(flags & IFA_F_TENTATIVE)) {
> + read_unlock_bh(&idev->lock);
> ipv6_ifa_notify(0, ift);
> + read_lock_bh(&idev->lock);
> + }
> }
>
> if ((create || list_empty(&idev->tempaddr_list)) &&
You can't do this, the idev->lock has to be held to keep the list we
are iterating over from changing.
Re: [PATCH 2/4] dmi: Add a DMI firmware node and handling
Dang, I've been doing too much Python. I've fixed this, but I guess I'll
wait for more comments.
-corey
On 01/29/2016 05:59 PM, kbuild test robot wrote:
Hi Corey,
[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on v4.5-rc1 next-20160129]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/minyard-acm-org/dmi-Rework-to-get-IPMI-autoloading-from-DMI-tables/20160130-074830
config: i386-tinyconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from arch/x86/kernel/setup.c:46:0:
include/linux/dmi.h: In function 'is_dmi_fwnode':
include/linux/dmi.h:164:1: error: expected ';' before '}' token
}
^
vim +164 include/linux/dmi.h
158 static inline const struct dmi_system_id *
159 dmi_first_match(const struct dmi_system_id *list) { return
NULL; }
160
161 static inline bool is_dmi_fwnode(struct fwnode_handle *fwnode)
162 {
163 return false
> 164 }
165
166 static inline struct dmi_fwnode *to_dmi_device(struct fwnode_handle
*fwnode)
167 {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH] staging: rtl8723au: Fixes unnecessary return warning
On Sat, 2016-01-30 at 10:17 +1100, Julian Calaby wrote: > On Sat, Jan 30, 2016 at 5:00 AM, Jes Sorensen wrote: > > Bhaktipriya Shridhar writes: > > > This patch fixes checkpatch.pl warning in rtw_mlme_ext.c file. > > > WARNING: void function return statements are not generally useful [] > > > diff --git a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c > > > b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c [] > > > @@ -2657,7 +2657,6 @@ static void issue_probersp(struct rtw_adapter > > > *padapter, unsigned char *da) > > > > > > Â Â dump_mgntframe23a(padapter, pmgntframe); > > > > > > -Â return; > > > Â } > > > > If you insist on pushing this rather unncessary change, please do it > > properly, and remove the blank line before the return statement as well. > > As Jes said, you need to remove the blank lines before the returns > too. checkpatch should have picked this up, you did run the patch > through checkpatch before you sent it, right? checkpatch doesn't pick this up. If you'd like to make it do so, you're welcome to try but it's likely a bit more complicated than it appears.
Re: [PATCH] clk: st: avoid uninitialized variable use
On 01/25, Arnd Bergmann wrote: > My previous patch fixed some warnings about printing a couple > of variables that are always uninitialized in quadfs_pll_fs660c32_set_rate(), > but I now got a warning that only shows up in some configurations (i.e. > without gcc -Os) about the params.ndiv being used uninitialized in the > error case: > > drivers/clk/st/clkgen-fsyn.c: In function 'quadfs_pll_fs660c32_set_rate': > drivers/clk/st/clkgen-fsyn.c:584:75: warning: 'params.ndiv' may be used > uninitialized in this function [-Wmaybe-uninitialized] > drivers/clk/st/clkgen-fsyn.c:574:16: note: 'params.ndiv' was declared here > > This changes the error handling so we bail for invalid arguments rather > than continuing with uninitialized data. > > Signed-off-by: Arnd Bergmann > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH RFC] locking/mutexes: don't spin on owner when wait list is not NULL.
On 2016/1/29 17:53, Peter Zijlstra wrote: > On Sun, Jan 24, 2016 at 04:03:50PM +0800, Ding Tianhong wrote: > >> looks good to me, I will try this solution and report the result, thanks >> everyone. > > Did you get a change to run with this? > > . > I backport this patch to 3.10 lts kernel, and didn't change any logic, Till now, the patch works fine to me, and no need to change anything, So I think this patch is no problem, could you formal release this patch to the latest kernel? :) Thanks. Ding
[PATCH] recordmcount: arm: Implement make_nop
In similar spirit to x86 and arm64 support, add a make_nop_arm()
to replace calls to mcount with a "nop" in sections that aren't
traced.
Cc: Russell King
Cc: Rabin Vincent
Signed-off-by: Stephen Boyd
---
scripts/recordmcount.c | 49 +
scripts/recordmcount.h | 3 ++-
2 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index e167592793a7..0b16d14c54fb 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -206,6 +206,52 @@ static int make_nop_x86(void *map, size_t const offset)
return 0;
}
+/*
+ * Indicates if ARM is using __gnu_mcount_nc or mcount style and if
+ * we should replace it with a pop or a nop respectively.
+ */
+static int uses_altmcount;
+
+static unsigned char ideal_nop4_arm_arm[4] = { 0x00, 0x40, 0xbd, 0xe8 };
+static unsigned char ideal_nop4_arm_thumb[4] = { 0x5d, 0xf8, 0x04, 0xeb };
+static unsigned char ideal_nop4_arm_arm_be[4] = { 0xe8, 0xbd, 0x40, 0x00 };
+static unsigned char ideal_nop4_arm_thumb_be[4] = { 0xf8, 0x5d, 0xeb, 0x04 };
+static unsigned char ideal_nop4_arm_old[4] = { 0x00, 0x00, 0xa0, 0xe1 };
+static unsigned char ideal_nop4_arm_old_be[4] = { 0xe1, 0xa0, 0x00, 0x00 };
+
+static unsigned char bl_gnu_mcount_nc_arm[4] = { 0xfe, 0xff, 0xff, 0xeb };
+static unsigned char bl_gnu_mcount_nc_thumb[4] = { 0xff, 0xf7, 0xfe, 0xff };
+static unsigned char bl_gnu_mcount_nc_arm_be[4] = { 0xeb, 0xff, 0xff, 0xfe };
+static unsigned char bl_gnu_mcount_nc_thumb_be[4] = { 0xf7, 0xff, 0xff, 0xfe };
+
+static int make_nop_arm(void *map, size_t const offset)
+{
+ uint32_t *ptr;
+
+ ptr = map + offset;
+ if (memcmp(ptr, bl_gnu_mcount_nc_arm, 4) == 0) {
+ if (uses_altmcount)
+ ideal_nop = ideal_nop4_arm_arm;
+ else
+ ideal_nop = ideal_nop4_arm_old;
+ } else if (memcmp(ptr, bl_gnu_mcount_nc_arm_be, 4) == 0) {
+ if (uses_altmcount)
+ ideal_nop = ideal_nop4_arm_arm_be;
+ else
+ ideal_nop = ideal_nop4_arm_old_be;
+ } else if (memcmp(ptr, bl_gnu_mcount_nc_thumb, 4) == 0)
+ ideal_nop = ideal_nop4_arm_thumb;
+ else if (memcmp(ptr, bl_gnu_mcount_nc_thumb_be, 4) == 0)
+ ideal_nop = ideal_nop4_arm_thumb_be;
+ else
+ return -1;
+
+ /* Convert to nop */
+ ulseek(fd_map, offset, SEEK_SET);
+ uwrite(fd_map, ideal_nop, 4);
+ return 0;
+}
+
static unsigned char ideal_nop4_arm64[4] = {0x1f, 0x20, 0x03, 0xd5};
static int make_nop_arm64(void *map, size_t const offset)
{
@@ -454,6 +500,9 @@ do_file(char const *const fname)
break;
case EM_ARM: reltype = R_ARM_ABS32;
altmcount = "__gnu_mcount_nc";
+make_nop = make_nop_arm;
+rel_type_nop = R_ARM_NONE;
+ideal_nop = ideal_nop4_arm_arm;
break;
case EM_AARCH64:
reltype = R_AARCH64_ABS64;
diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
index b9897e2be404..890f5211745f 100644
--- a/scripts/recordmcount.h
+++ b/scripts/recordmcount.h
@@ -266,7 +266,8 @@ static unsigned get_mcountsym(Elf_Sym const *const sym0,
if (symname[0] == '.')
++symname; /* ppc64 hack */
if (strcmp(mcount, symname) == 0 ||
- (altmcount && strcmp(altmcount, symname) == 0) ||
+ (altmcount && strcmp(altmcount, symname) == 0 &&
+(uses_altmcount = 1)) ||
(strcmp(fentry, symname) == 0))
mcountsym = Elf_r_sym(relp);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled
On 01/29, Stefan Agner wrote: > If a clock gets enabled early during boot time, it can lead to a PLL > startup. The wait_lock function makes sure that the PLL is really > stareted up before it gets used. However, the function sleeps which > leads to scheduling and an error: > bad: scheduling from the idle thread! > ... Can you please share the full splat? I have no clue what's going on. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH] clk: axi-clkgen: Remove sometimes impossible check
The size of unsigned long on 64-bit architectures is equal to the size of u64, so this check is impossible there. This throws off static checkers: drivers/clk/clk-axi-clkgen.c:331 axi_clkgen_recalc_rate() warn: impossible condition '(tmp > (~0)) => (0-u64max > u64max)' Let's change this code to use min_t() instead so that we get the same effect on architectures where sizeof(unsigned long) doesn't equal sizeof(u64). Cc: Lars-Peter Clausen Signed-off-by: Stephen Boyd --- drivers/clk/clk-axi-clkgen.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/clk/clk-axi-clkgen.c b/drivers/clk/clk-axi-clkgen.c index 9a0744c9947c..3294db3b4e4e 100644 --- a/drivers/clk/clk-axi-clkgen.c +++ b/drivers/clk/clk-axi-clkgen.c @@ -328,10 +328,7 @@ static unsigned long axi_clkgen_recalc_rate(struct clk_hw *clk_hw, tmp = (unsigned long long)(parent_rate / d) * m; do_div(tmp, dout); - if (tmp > ULONG_MAX) - return ULONG_MAX; - - return tmp; + return min_t(unsigned long long, tmp, ULONG_MAX); } static int axi_clkgen_enable(struct clk_hw *clk_hw) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2] irqchip: gicv3-its: Fix memory leak in its_free_tables()
On 01/29/2016 02:30 AM, Thomas Gleixner wrote:
On Thu, 28 Jan 2016, Shanker Donthineni wrote:
@@ -807,9 +810,10 @@ static void its_free_tables(struct its_node *its)
int i;
for (i = 0; i < GITS_BASER_NR_REGS; i++) {
- if (its->tables[i]) {
- free_page((unsigned long)its->tables[i]);
- its->tables[i] = NULL;
+ if (its->tables[i].base) {
+ free_pages((unsigned long)its->tables[i].base,
+ get_order(its->tables[i].size));
+ its->tables[i].base = NULL;
}
}
}
@@ -880,6 +884,7 @@ retry_alloc_baser:
if (alloc_pages > GITS_BASER_PAGES_MAX) {
alloc_pages = GITS_BASER_PAGES_MAX;
order = get_order(GITS_BASER_PAGES_MAX * psz);
+ alloc_size = (1 << order) * PAGE_SIZE;
Why don't you record the order instead of converting back and forth ?
I can use page order information to fix memory leak and I will post v3
patch with your suggestion.
We have another coding BUG which is related to not refreshing alloc_size
whenever order changes.
Because we are not updating alloc_size variable here, later part of the
code logic uses incorrect
alloc_size value in two places as shown below.
Code snippet-1:
if (!shr) {
cache = GITS_BASER_nC;
__flush_dcache_area(base, alloc_size);
}
Code snippet-2:
pr_info("ITS: allocated %d %s @%lx (psz %dK, shr %d)\n",
(int)(alloc_size / entry_size),
its_base_type_string[type],
(unsigned long)virt_to_phys(base),
psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT);
How do you suggest I fix the second problem? Should I create another
patch or include in v3 patch?
Thanks,
tglx
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 2/2] clk: axi-clkgen: Add multi-parent support
On 11/30, Lars-Peter Clausen wrote:
> The clock generator has two clock inputs that can be used as the reference
> clock. Add support for switching between them at runtime.
>
> Signed-off-by: Lars-Peter Clausen
> ---
Applied to clk-next
> .../devicetree/bindings/clock/axi-clkgen.txt | 5 ++-
> drivers/clk/clk-axi-clkgen.c | 40
> ++
> 2 files changed, 38 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/clk/clk-axi-clkgen.c b/drivers/clk/clk-axi-clkgen.c
> index 8dedc60..9a0744c 100644
> --- a/drivers/clk/clk-axi-clkgen.c
> +++ b/drivers/clk/clk-axi-clkgen.c
> @@ -349,12 +350,33 @@ static void axi_clkgen_disable(struct clk_hw *clk_hw)
> @@ -370,10 +392,11 @@ static int axi_clkgen_probe(struct platform_device
> *pdev)
> const struct of_device_id *id;
> struct axi_clkgen *axi_clkgen;
> struct clk_init_data init;
> - const char *parent_name;
> + const char *parent_names[2];
> const char *clk_name;
> struct resource *mem;
> struct clk *clk;
> + unsigned int i;
>
> if (!pdev->dev.of_node)
> return -ENODEV;
> @@ -391,19 +414,24 @@ static int axi_clkgen_probe(struct platform_device
> *pdev)
> if (IS_ERR(axi_clkgen->base))
> return PTR_ERR(axi_clkgen->base);
>
> - parent_name = of_clk_get_parent_name(pdev->dev.of_node, 0);
> - if (!parent_name)
> + init.num_parents = of_clk_get_parent_count(pdev->dev.of_node);
> + if (init.num_parents < 1 || init.num_parents > 2)
> return -EINVAL;
>
> + for (i = 0; i < init.num_parents; i++) {
> + parent_names[i] = of_clk_get_parent_name(pdev->dev.of_node, i);
> + if (!parent_names[i])
> + return -EINVAL;
> + }
This can be of_clk_parent_fill(). Feel free to send a cleanup. I
would have asked for one, but you've been waiting two months.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
On 1/28/2016 6:43 PM, Olof Johansson wrote: > On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit > wrote: >> Hi Olof, >> >> On 1/28/2016 3:39 PM, Olof Johansson wrote: >>> >>> Hi Suravee, >>> >>> On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit >>> wrote: From: Suravee Suthikulpanit This patch series contains several updates for the AMD Seattle SOC DTS files. It also adds new board files for newer Overdrive and Linaro 96boards (Husky) platforms. >>> >>> >>> My Overdrive comes with DT provided by firmware, so there's no need to >>> have a in-kernel-tree DT source. >> >> >> You are correct that the FW comes with DT, and in typical case, you wouldn't >> need this. >> >>> Are you aware of other reasons to have it here? I just foresee >>> divergence and conflicts between the two. It was quite obvious before >>> this update when the FW-provided DT was a lot more complete than what >>> we had in the kernel tree. >> >> >> However, there are still new/updated drivers being developed, and sometimes >> requires new/changes in DT binding. So, the DT that comes with the FW can >> get out of date, and will lack the support for new drivers. > > Note that it's expected that the driver will cope with the old DT > contents, i.e. it needs to go with defaults that made sense before the > binding was updated. > > It, however, doesn't have to enable new features. In other words, > booting with an old DT needs to continue working. You can't require a > user to update DT to avoid getting driver breakage. > > (The opposite is not enforced: Booting with a DT that is newer than > the kernel isn't guaranteed to always work). > >> Certain version of the FW allows overriding the DT that comes with the FW. >> So, we are providing the in-kernel DT to allow developers to provide the >> updated device tree for newer kernels. This patch series is bringing the >> in-kernel DT closer to what the latest FW is providing to avoid potential >> conflicts. > > I do appreciate keeping the kernel one up to date with what firmware > provides if it's truly needed, but I'd even more prefer that it > wasn't. After all, it's how the ACPI-based booting works (no > overriding table provided with the kernel), so it's a model you should > already be somewhat familiar with. :) > > I'm not doing a hard NAK on this, but I would like to get a bit more > understanding of why it's considered needed. > > > -Olof I would strongly encourage the inclusion of the dts file in the kernel source tree, even if the dtb is delivered with the firmware for several reasons. The dts provides a reference for other developers who are supporting new boards that are similar. The dts might be reviewed. We hope to have tools that will validate the dts against the documented bindings. (Yes, this effort has stalled, but I am optimistic that it is not dead.) If someone has the board (any board, not just this one) that the kernel does not boot on, then it might not be possible to retrieve the dtb from the board (which can then be de-compiled to a dts) for the purpose of debugging or properly configuring the kernel. (The boot loader may provide the ability to get the dtb or it might not.) -Frank
Re: [PATCH 2/2] clk: palmas: fix a possible NULL dereference
On 11/25, LABBE Corentin wrote: > of_match_device could return NULL, and so cause a NULL pointer > dereference later. > Even if the probability of this case is very low, fixing it made > static analyzers happy. > > Solving this with of_device_get_match_data made also code simplier. > > Reported-by: coverity (CID 1324137) > Signed-off-by: LABBE Corentin > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 1/2] clk: palmas: constify the palmas_clks_of_match_data structure
On 11/25, LABBE Corentin wrote: > The palmas_clks_of_match_data structures are never modified. > This patch constify them. > > Signed-off-by: LABBE Corentin > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [RFC PATCH 00/19] cpufreq locking cleanups and documentation
On 01/11/2016 09:35 AM, Juri Lelli wrote: Hi all, In the context of the ongoing discussion about introducing a simple platform energy model to guide scheduling decisions (Energy Aware Scheduling [1]) concerns have been expressed by Peter about the component in charge of driving clock frequency selection (Steve recently posted an update of such component [2]): https://lkml.org/lkml/2015/8/15/141. The problem is that, with this new approach, cpufreq core functions need to be accessed from scheduler hot-paths and the overhead associated with the current locking scheme might result to be unsustainable. Peter's proposed approach of using RCU logic to reduce locking overhead seems reasonable, but things may not be so straightforward as originally thought. The very first thing I actually realized when I started looking into this is that it was hard for me to understand which locking mechanism was protecting which data structure. As mostly a way to build a better understanding of the current cpufreq locking scheme and also as preparatory work for implementing RCU logic, I came up with this set of patches. In fact, at this stage, I would like each patch to be considered as a question I'm asking rather than a proposed change, thus the RFC tag for the series; with the intent of documenting current locking scheme and modifying it a bit in order to make RCU logic implementation easier. Actually, as you'll soon notice, I didn't really start from scratch. Mike shared with me some patches he has been developing while looking at the same problem. I've given Mike attribution for the patches that I took unchanged from him, with thanks for sharing his findings with me. High level description of patches: o [01-04] cleanup and move code around to make things (hopefully) cleaner o [05-14] insert lockdep assertions and fix uncovered erroneous situations o [15-18] remove overkill usage of locking mechanism o 19 adds documentation for the cleaned up locking scheme With Viresh' tests [3] on both arm TC2 and arm64 Juno boards I'm not seeing anything bad happening. However, coverage is really small (as is my personal confidence of not breaking things for other confs :-)). This set is based on top of linux-pm/linux-next as of today and it is also available from here: git://linux-arm.org/linux-jl.git upstream/cpufreq_cleanups Comments, concerns and rants are the primary goal of this posting; I'm thus looking forward to them. Best, - Juri [1] https://lkml.org/lkml/2015/7/7/754 [2] https://lkml.org/lkml/2015/12/9/35 [3] https://git.linaro.org/people/viresh.kumar/cpufreq-tests.git Juri Lelli (16): cpufreq: kill for_each_policy cpufreq: bring data structures close to their locks cpufreq: assert locking when accessing cpufreq_policy_list cpufreq: always access cpufreq_policy_list while holding cpufreq_driver_lock cpufreq: assert locking when accessing cpufreq_governor_list cpufreq: fix warning for cpufreq_init_policy unlocked access to cpufreq_governor_list cpufreq: fix warning for show_scaling_available_governors unlocked access to cpufreq_governor_list cpufreq: assert policy->rwsem is held in cpufreq_set_policy cpufreq: assert policy->rwsem is held in __cpufreq_governor cpufreq: fix locking of policy->rwsem in cpufreq_init_policy cpufreq: fix locking of policy->rwsem in cpufreq_offline_prepare cpufreq: fix locking of policy->rwsem in cpufreq_offline_finish cpufreq: remove useless usage of cpufreq_governor_mutex in __cpufreq_governor cpufreq: hold policy->rwsem across CPUFREQ_GOV_POLICY_EXIT cpufreq: stop checking for cpufreq_driver being present in cpufreq_cpu_get cpufreq: documentation: document locking scheme Michael Turquette (3): cpufreq: do not expose cpufreq_governor_lock cpufreq: merge governor lock and mutex cpufreq: remove transition_lock Documentation/cpu-freq/core.txt| 44 + drivers/cpufreq/cpufreq.c | 132 +++-- drivers/cpufreq/cpufreq_governor.h | 2 - include/linux/cpufreq.h| 5 -- 4 files changed, 125 insertions(+), 58 deletions(-) Juri, I haven't looked at the cpufreq-tests, but I doubt they do hotplug testing where they remove all the CPUs of a policy (to trigger a policy exit). Can you please add that to your testing? I wouldn't be surprised if some of your clean ups would cause a dead lock. This clean up series is definitely appreciated, but I think the patch series might still be missing some patches that are needed to make things work without deadlocking. I'll try to do a deeper analysis/review/testing, but kinda hard pressed on time here. Thanks, Saravana -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 1/3] f2fs: wait on page's writeback in writepages path
Likewise f2fs_write_cache_pages, let's do for node and meta pages too. Especially, for node blocks, we should do this before marking its fsync and dentry flags. Signed-off-by: Jaegeuk Kim --- fs/f2fs/checkpoint.c | 4 +++- fs/f2fs/node.c | 5 +++-- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c index 112e19f..96d606d 100644 --- a/fs/f2fs/checkpoint.c +++ b/fs/f2fs/checkpoint.c @@ -232,7 +232,6 @@ static int f2fs_write_meta_page(struct page *page, if (unlikely(f2fs_cp_error(sbi))) goto redirty_out; - f2fs_wait_on_page_writeback(page, META, true); write_meta_page(sbi, page); dec_page_count(sbi, F2FS_DIRTY_META); unlock_page(page); @@ -315,6 +314,9 @@ continue_unlock: goto continue_unlock; } + f2fs_wait_on_page_writeback(page, META, true); + + BUG_ON(PageWriteback(page)); if (!clear_page_dirty_for_io(page)) goto continue_unlock; diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index eae8977..511c0e7 100644 --- a/fs/f2fs/node.c +++ b/fs/f2fs/node.c @@ -1297,6 +1297,9 @@ continue_unlock: continue; } + f2fs_wait_on_page_writeback(page, NODE, true); + + BUG_ON(PageWriteback(page)); if (!clear_page_dirty_for_io(page)) goto continue_unlock; @@ -1402,8 +1405,6 @@ static int f2fs_write_node_page(struct page *page, if (unlikely(f2fs_cp_error(sbi))) goto redirty_out; - f2fs_wait_on_page_writeback(page, NODE, true); - /* get old block addr of this node page */ nid = nid_of_node(page); f2fs_bug_on(sbi, page->index != nid); -- 2.6.3
[PATCH 2/3] f2fs: flush bios to handle cp_error in put_super
Sometimes, if cp_error is set, there remains under-writeback pages, resulting in
kernel hang in put_super.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/super.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 9962021..aa2d3d9 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -582,6 +582,13 @@ static void f2fs_put_super(struct super_block *sb)
f2fs_leave_shrinker(sbi);
mutex_unlock(&sbi->umount_mutex);
+ /* our cp_error case, we can wait for any writeback page */
+ if (get_pages(sbi, F2FS_WRITEBACK)) {
+ f2fs_submit_merged_bio(sbi, DATA, WRITE);
+ f2fs_submit_merged_bio(sbi, NODE, WRITE);
+ f2fs_submit_merged_bio(sbi, META, WRITE);
+ }
+
iput(sbi->node_inode);
iput(sbi->meta_inode);
--
2.6.3
[PATCH 3/3] f2fs: fix conflict on page->private usage
This patch fixes confilct on page->private value between f2fs_trace_pid and
atomic page.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/segment.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index ee44d34..cd7111b 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -183,7 +183,7 @@ struct segment_allocation {
* this value is set in page as a private data which indicate that
* the page is atomically written, and it is in inmem_pages list.
*/
-#define ATOMIC_WRITTEN_PAGE0x
+#define ATOMIC_WRITTEN_PAGE((unsigned long)-1)
#define IS_ATOMIC_WRITTEN_PAGE(page) \
(page_private(page) == (unsigned long)ATOMIC_WRITTEN_PAGE)
--
2.6.3
Re: [PATCH] clk: optimize the divider walk in clk_divider_bestdiv()
On 01/05, Masahiro Yamada wrote: > Because _next_div() returns a valid divider, there is no need to > consult _is_valid_div() for the validity of the divider in every > iteration. > > Signed-off-by: Masahiro Yamada > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 14/38] clk: vt8500: fix sign of possible PLL values
On 10/02, Andrzej Hajda wrote: > With unsigned values underflow in loops can occur resulting in > theoretically infinite loops. > > The problem has been detected using proposed semantic patch > scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1]. > > [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576 > > Signed-off-by: Andrzej Hajda > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 1/2] clk: add clk_unregister_fixed_factor()
On 01/06, Masahiro Yamada wrote: > Allow to unregister fixed factor clock. > > Signed-off-by: Masahiro Yamada > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 2/2] clk: add clk_unregister_fixed_rate()
On 01/06, Masahiro Yamada wrote: > Allow to unregister fixed rate clock. > > Signed-off-by: Masahiro Yamada > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 2/4] dmi: Add a DMI firmware node and handling
Hi Corey, [auto build test WARNING on char-misc/char-misc-testing] [also build test WARNING on v4.5-rc1 next-20160129] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/minyard-acm-org/dmi-Rework-to-get-IPMI-autoloading-from-DMI-tables/20160130-074830 config: i386-randconfig-s0-201604 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): >> WARNING: vmlinux.o(.text.unlikely+0xe634): Section mismatch in reference >> from the function dmi_zalloc() to the function .init.text:extend_brk() The function dmi_zalloc() references the function __init extend_brk(). This is often because dmi_zalloc lacks a __init annotation or the annotation of extend_brk is wrong. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH RESEND v2 4/4] ARM: dts: enable audio clock support for Cygnus
Hi Florian,
With Stephen merging the first 3 patches into the clk tree, could you
please take this DT patch now?
Thanks,
Ray
On 1/26/2016 5:18 PM, Ray Jui wrote:
From: Simran Rai
Add audio clock to the existing Broadcom Cygnus clock DT
Signed-off-by: Simran Rai
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/boot/dts/bcm-cygnus-clock.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
b/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
index 32bcd45..80b6ba4 100644
--- a/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
@@ -121,4 +121,13 @@ clocks {
clocks = <&osc>;
clock-output-names = "keypad", "adc/touch", "pwm";
};
+
+ audiopll: audiopll {
+ #clock-cells = <1>;
+ compatible = "brcm,cygnus-audiopll";
+ reg = <0x180aeb00 0x68>;
+ clocks = <&osc>;
+ clock-output-names = "audiopll", "ch0_audio",
+ "ch1_audio", "ch2_audio";
+ };
};
CONFIG_UBSAN_ALIGNMENT breaks x86-64 kernel with lockdep enabled
Hi, option CONFIG_UBSAN_ALIGNMENT breaks x86-64 kernel with lockdep enabled, i. e kernel with CONFIG_UBSAN_ALIGNMENT fails to load without even any error message. The problem is that ubsan callbacks use spinlocks and might be called before lockdep is initialized. Particularly this line in the reserve_ebda_region function causes problem: lowmem = *(unsigned short *)__va(BIOS_LOWMEM_KILOBYTES); If i put lockdep_init() before reserve_ebda_region call in x86_64_start_reservations kernel loads well. Since CONFIG_UBSAN_ALIGNMENT isn't useful for x86 anyway it might be better to disable this option for x86 arch?
Re: [PATCH v2] clk:gcc-msm8916: add missing mss_q6_bimc_axi clock
On 01/04, Srinivas Kandagatla wrote: > This clock is required for loading the qdsp firmware. > > Signed-off-by: Srinivas Kandagatla > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v8 3/3] x86, mce: Add __mcsafe_copy()
On Wed, Jan 13, 2016 at 8:39 PM, Borislav Petkov wrote:
> On Wed, Jan 13, 2016 at 03:22:58PM -0800, Tony Luck wrote:
>> Are there some examples of synthetic CPUID bits?
>
> X86_FEATURE_ALWAYS is one. The others got renamed into X86_BUG_* ones,
> the remaining mechanism is the same, though.
So something like this [gmail will line wrap, but should still be legible]
Then Dan will be able to use:
if (cpu_has(c, X86_FEATURE_MCRECOVERY))
to decide whether to use the (slightly slower, but recovery capable)
__mcsafe_copy()
or just pick the fastest memcpy() instead.
-Tony
diff --git a/arch/x86/include/asm/cpufeature.h
b/arch/x86/include/asm/cpufeature.h
index 7ad8c9464297..621e05103633 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -106,6 +106,7 @@
#define X86_FEATURE_APERFMPERF ( 3*32+28) /* APERFMPERF */
#define X86_FEATURE_EAGER_FPU ( 3*32+29) /* "eagerfpu" Non lazy FPU restore */
#define X86_FEATURE_NONSTOP_TSC_S3 ( 3*32+30) /* TSC doesn't stop in
S3 state */
+#define X86_FEATURE_MCRECOVERY ( 3*32+31) /* cpu has recoverable
machine checks */
/* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
#define X86_FEATURE_XMM3 ( 4*32+ 0) /* "pni" SSE-3 */
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index a006f4cd792b..b8980d767240 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1694,6 +1694,14 @@ void mcheck_cpu_init(struct cpuinfo_x86 *c)
return;
}
+ /*
+* MCG_CAP.MCG_SER_P is necessary but not sufficient to know
+* whether this processor will actually generate recoverable
+* machine checks. Check to see if this is an E7 model Xeon.
+*/
+ if (mca_cfg.ser && !strncmp(c->x86_model_id, "Intel(R) Xeon(R)
CPU E7-", 24))
+ set_cpu_cap(c, X86_FEATURE_MCRECOVERY);
+
if (mce_gen_pool_init()) {
mca_cfg.disabled = true;
pr_emerg("Couldn't allocate MCE records pool!\n");
Re: [PATCH v3 1/4] clk: s2mps11: merge two for loops in one
On 01/20, Andi Shyti wrote: > the driver already loops once, there is no reason to loop again > for a different purpose. Merge the second loop into the first. > > Signed-off-by: Andi Shyti > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v3 4/4] clk: s2mps11: remove redundant code
On 01/20, Andi Shyti wrote: > The definition of s2mps11_name is meant to resolve the name of a > given clock. Remove it because the clocks have the same name we > can get it directly from the s2mps11_clks_init structure. > > While in the probe function the s2mps11_clks is used only to > iterate through the s2mps11_clks. The naming itself brings > confusion and the readability does not improve much. > > Signed-off-by: Andi Shyti > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v3 3/4] clk: s2mps11: remove redundant static variables declaration
On 01/20, Andi Shyti wrote: > The clk_table and clk_data are declared static. The clk_table > contains the three clock data stractures belonging to the s2mps11 > driver. In the probe function it gets stored into clk_data. > > Remove clk_table and refer directly to clk_data. > > clk_data, itself, is also declared static. Declare locally it > and allocate it inside the probe function, as it is not used > anywhere else. > > Signed-off-by: Andi Shyti > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v3 2/4] clk: s2mps11: allocate only one structure for clock init
On 01/20, Andi Shyti wrote: > The driver allocates three structures, s2mpsxx_clk_init, for > three different clock types (s2mps11, s2mps13 and s2mps14). They > are quite similar but they differ only by the name. Only one of > these structures is used, while the others lie unused in the > memory. > > The clock's name, though, is not such a meaningful information > and by assigning the same name to the initial data we can avoid > over allocation. The common name chosen will be s2mps11, > coherently with the device driver name, instead of the clock > device. > > Therefore, remove the structures associated to s2mps13 and > s2mps14 and use only the one referred to s2mps11 for all kind of > clocks. > > Signed-off-by: Andi Shyti > Suggested-by: Krzysztof Kozlowski > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v2] block: use DAX for partition table reads
Avoid populating pagecache when the block device is in DAX mode.
Otherwise these page cache entries collide with the fsync/msync
implementation and break data durability guarantees.
Cc: Jan Kara
Cc: Jeff Moyer
Cc: Christoph Hellwig
Cc: Dave Chinner
Cc: Andrew Morton
Reported-by: Ross Zwisler
Tested-by: Ross Zwisler
Reviewed-by: Matthew Wilcox
Signed-off-by: Dan Williams
---
Changes in v2:
1/ Switch from __page_cache_alloc to alloc_pages (Jens)
2/ Move read_dax_sector() declaration to include/linux/dax.h (Willy)
3/ Collect Reviewed-by and Tested-by tags from Willy and Ross.
block/partition-generic.c | 18 +++---
fs/dax.c | 20
include/linux/dax.h | 11 +++
3 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/block/partition-generic.c b/block/partition-generic.c
index 746935a5973c..fefd01b496a0 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include "partitions/check.h"
@@ -550,13 +551,24 @@ int invalidate_partitions(struct gendisk *disk, struct
block_device *bdev)
return 0;
}
-unsigned char *read_dev_sector(struct block_device *bdev, sector_t n, Sector
*p)
+static struct page *read_pagecache_sector(struct block_device *bdev, sector_t
n)
{
struct address_space *mapping = bdev->bd_inode->i_mapping;
+
+ return read_mapping_page(mapping, (pgoff_t)(n >> (PAGE_CACHE_SHIFT-9)),
+ NULL);
+}
+
+unsigned char *read_dev_sector(struct block_device *bdev, sector_t n, Sector
*p)
+{
struct page *page;
- page = read_mapping_page(mapping, (pgoff_t)(n >> (PAGE_CACHE_SHIFT-9)),
-NULL);
+ /* don't populate page cache for dax capable devices */
+ if (IS_DAX(bdev->bd_inode))
+ page = read_dax_sector(bdev, n);
+ else
+ page = read_pagecache_sector(bdev, n);
+
if (!IS_ERR(page)) {
if (PageError(page))
goto fail;
diff --git a/fs/dax.c b/fs/dax.c
index 4fd6b0c5c6b5..e0e9358baf35 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -58,6 +58,26 @@ static void dax_unmap_atomic(struct block_device *bdev,
blk_queue_exit(bdev->bd_queue);
}
+struct page *read_dax_sector(struct block_device *bdev, sector_t n)
+{
+ struct page *page = alloc_pages(GFP_KERNEL, 0);
+ struct blk_dax_ctl dax = {
+ .size = PAGE_SIZE,
+ .sector = n & ~int) PAGE_SIZE) / 512) - 1),
+ };
+ long rc;
+
+ if (!page)
+ return ERR_PTR(-ENOMEM);
+
+ rc = dax_map_atomic(bdev, &dax);
+ if (rc < 0)
+ return ERR_PTR(rc);
+ memcpy_from_pmem(page_address(page), dax.addr, PAGE_SIZE);
+ dax_unmap_atomic(bdev, &dax);
+ return page;
+}
+
/*
* dax_clear_blocks() is called from within transaction context from XFS,
* and hence this means the stack from this point must follow GFP_NOFS
diff --git a/include/linux/dax.h b/include/linux/dax.h
index 8204c3dc3800..818e45078929 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -14,6 +14,17 @@ int dax_fault(struct vm_area_struct *, struct vm_fault *,
get_block_t,
dax_iodone_t);
int __dax_fault(struct vm_area_struct *, struct vm_fault *, get_block_t,
dax_iodone_t);
+
+#ifdef CONFIG_FS_DAX
+struct page *read_dax_sector(struct block_device *bdev, sector_t n);
+#else
+static inline struct page *read_dax_sector(struct block_device *bdev,
+ sector_t n)
+{
+ return ERR_PTR(-ENXIO);
+}
+#endif
+
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
int dax_pmd_fault(struct vm_area_struct *, unsigned long addr, pmd_t *,
unsigned int flags, get_block_t, dax_iodone_t);
Re: [PATCH RESEND v2 2/4] clk: iproc: Add support for Cygnus audio clocks
On 01/26, Ray Jui wrote: > From: Simran Rai > > This patch adds support for Broadcom Cygnus audio PLL and leaf > clocks > > Signed-off-by: Simran Rai > Reviewed-by: Scott Branden > Signed-off-by: Ray Jui > --- Applied to clk-iproc -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH RESEND v2 3/4] clk: iproc: Remove __init from header
On 01/26, Ray Jui wrote: > Remove __init macro from all function prototypes in clk-iproc.h > > Signed-off-by: Ray Jui > --- Applied to clk-iproc -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor
On 01/12/2016 02:20 AM, Viresh Kumar wrote:
On 11-01-16, 17:35, Juri Lelli wrote:
__cpufreq_governor works on policy, so policy->rwsem has to be held.
Add assertion for such condition.
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Signed-off-by: Juri Lelli
---
drivers/cpufreq/cpufreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index f1f9fbc..e7fc5c9 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1950,6 +1950,9 @@ static int __cpufreq_governor(struct cpufreq_policy
*policy,
/* Don't start any governor operations if we are entering suspend */
if (cpufreq_suspended)
return 0;
+
+ lockdep_assert_held(&policy->rwsem);
+
We had an ABBA problem with the EXIT governor callback and so this
rwsem is dropped just before that from set_policy()..
commit 955ef4833574 ("cpufreq: Drop rwsem lock around
CPUFREQ_GOV_POLICY_EXIT")
AFAIR, the ABBA issue was between the sysfs lock and the policy lock.
The fix for that issue should not be dropping the lock around
POLICY_EXIT. The proper fix is to have the governor "export" the
attributes it wants to add/remove and have the cpufreq framework do the
adding/removing of the attributes from sysfs for the governor.
Thanks,
Saravana
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH RESEND v2 1/4] Documentation: dt-bindings: Add DT bindings for Cygnus audio clock
On 01/26, Ray Jui wrote: > From: Simran Rai > > This patch adds audio clock device tree binding documentation to an > existing Cygnus clock DT bindings document. > > Signed-off-by: Simran Rai > Reviewed-by: Ray Jui > Reviewed-by: Lori Hikichi > Reviewed-by: Scott Branden > --- Applied to clk-iproc -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] clk: rockchip: fix wrong mmc phase shift for rk3228
On 01/26, Shawn Lin wrote:
> mmc sample shift is 0 for rk3228 refer to user manaul.
> So it's broken if we enable mmc tuning for rk3228.
>
> Fixes: 307a2e9ac ("clk: rockchip: add clock controller for rk3228")
> Cc: Xing Zheng
> Cc: Jeffy Chen
> Signed-off-by: Shawn Lin
> ---
Acked-by: Stephen Boyd
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v2] clk: Move vendor's Kconfig into CCF menu section
On 01/28, James Liao wrote: > Move all vendor's Kconfig into CCF menu section to prevent > new drivers putting their Kconfig files in a wrong place. > > Some Kconigs need to modify at the same time to avoid build > warnings. > > Signed-off-by: James Liao > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH] tpm: fix rollback when adding char dev fails
Fixed rollback and gave better names to the functions (more
self-documenting, less confusing).
Fixes: d972b0523f ("tpm: fix call order in tpm-chip.c")
Signed-off-by: Jarkko Sakkinen
cc: sta...@vger.kernel.org
---
drivers/char/tpm/tpm-chip.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index 45cc39a..1a9dcee 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -140,7 +140,7 @@ struct tpm_chip *tpmm_chip_alloc(struct device *dev,
}
EXPORT_SYMBOL_GPL(tpmm_chip_alloc);
-static int tpm_dev_add_device(struct tpm_chip *chip)
+static int tpm_add_char_device(struct tpm_chip *chip)
{
int rc;
@@ -151,7 +151,6 @@ static int tpm_dev_add_device(struct tpm_chip *chip)
chip->devname, MAJOR(chip->dev.devt),
MINOR(chip->dev.devt), rc);
- device_unregister(&chip->dev);
return rc;
}
@@ -162,13 +161,14 @@ static int tpm_dev_add_device(struct tpm_chip *chip)
chip->devname, MAJOR(chip->dev.devt),
MINOR(chip->dev.devt), rc);
+ cdev_del(&chip->cdev);
return rc;
}
return rc;
}
-static void tpm_dev_del_device(struct tpm_chip *chip)
+static void tpm_del_char_device(struct tpm_chip *chip)
{
cdev_del(&chip->cdev);
device_unregister(&chip->dev);
@@ -222,7 +222,7 @@ int tpm_chip_register(struct tpm_chip *chip)
tpm_add_ppi(chip);
- rc = tpm_dev_add_device(chip);
+ rc = tpm_add_char_device(chip);
if (rc)
goto out_err;
@@ -274,6 +274,6 @@ void tpm_chip_unregister(struct tpm_chip *chip)
sysfs_remove_link(&chip->pdev->kobj, "ppi");
tpm1_chip_unregister(chip);
- tpm_dev_del_device(chip);
+ tpm_del_char_device(chip);
}
EXPORT_SYMBOL_GPL(tpm_chip_unregister);
--
2.7.0
Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences
On Fri, Jan 29, 2016 at 3:34 PM, Ross Zwisler wrote: > On Fri, Jan 29, 2016 at 11:28:15AM -0700, Ross Zwisler wrote: >> On Thu, Jan 28, 2016 at 01:38:58PM -0800, Christoph Hellwig wrote: >> > On Thu, Jan 28, 2016 at 12:35:04PM -0700, Ross Zwisler wrote: >> > > There are a number of places in dax.c that look up the struct >> > > block_device >> > > associated with an inode. Previously this was done by just using >> > > inode->i_sb->s_bdev. This is correct for inodes that exist within the >> > > filesystems supported by DAX (ext2, ext4 & XFS), but when running DAX >> > > against raw block devices this value is NULL. This causes NULL pointer >> > > dereferences when these block_device pointers are used. >> > >> > It's also wrong for an XFS file system with a RT device.. >> > >> > > +#define DAX_BDEV(inode) (S_ISBLK(inode->i_mode) ? I_BDEV(inode) \ >> > > + : inode->i_sb->s_bdev) >> > >> > .. but this isn't going to fix it. You must use a bdev returned by >> > get_blocks or a similar file system method. >> >> I guess I need to go off and understand if we can have DAX mappings on such a >> device. If we can, we may have a problem - we can get the block_device from >> get_block() in I/O path and the various fault paths, but we don't have access >> to get_block() when flushing via dax_writeback_mapping_range(). We avoid >> needing it the normal case by storing the sector results from get_block() in >> the radix tree. >> >> /me is off to play with RT devices... > > Well, RT devices are completely broken as far as I can see. I've reported the > breakage to the XFS list. Anything I do that triggers a RT block allocation > in XFS causes a lockdep splat + a kernel BUG - I've tried regular pwrite(), > xfs_rtcp and mmap() + write to address. Not a new bug either - happens just > the same with v4.4. Happens with both PMEM and BRD, and has no relationship > to whether I'm using DAX or not. > > Does it work for this patch to go in as-is since it fixes an immediate OOPS > with raw block devices + DAX, and when RT devices are alive again I'll figure > out how to make them work too? Can we step back and be clear about which lookups should be coming from get_blocks(). Which ones are critical vs ones we just opportunistically lookup for a debug print. Right now xfs and ext4 are basically disagreeing on whether get_blocks() reliably sets ->bh_bdev, and checking for a raw block-device inode in dax_clear_blocks() does not make sense. So this all seems a bit confused.
[PATCH] ARM: dts: vf610: Add alias for ethernet controller
Add alias for FEC ethernet on Vybrid to allow bootloaders (like U-Boot)
patch-in the MAC address using this alias.
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vfxxx.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index eb42172..f23eb82 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -16,6 +16,8 @@
aliases {
can0 = &can0;
can1 = &can1;
+ ethernet0 = &fec0;
+ ethernet1 = &fec1;
serial0 = &uart0;
serial1 = &uart1;
serial2 = &uart2;
--
2.7.0
Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
On 1/28/2016 8:43 PM, Olof Johansson wrote: On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit wrote: Hi Olof, On 1/28/2016 3:39 PM, Olof Johansson wrote: Hi Suravee, On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit wrote: From: Suravee Suthikulpanit This patch series contains several updates for the AMD Seattle SOC DTS files. It also adds new board files for newer Overdrive and Linaro 96boards (Husky) platforms. My Overdrive comes with DT provided by firmware, so there's no need to have a in-kernel-tree DT source. You are correct that the FW comes with DT, and in typical case, you wouldn't need this. Are you aware of other reasons to have it here? I just foresee divergence and conflicts between the two. It was quite obvious before this update when the FW-provided DT was a lot more complete than what we had in the kernel tree. However, there are still new/updated drivers being developed, and sometimes requires new/changes in DT binding. So, the DT that comes with the FW can get out of date, and will lack the support for new drivers. Note that it's expected that the driver will cope with the old DT contents, i.e. it needs to go with defaults that made sense before the binding was updated. It, however, doesn't have to enable new features. In other words, booting with an old DT needs to continue working. You can't require a user to update DT to avoid getting driver breakage. (The opposite is not enforced: Booting with a DT that is newer than the kernel isn't guaranteed to always work). Ok. I understand your point that driver will not break the existing DT. :) Certain version of the FW allows overriding the DT that comes with the FW. So, we are providing the in-kernel DT to allow developers to provide the updated device tree for newer kernels. This patch series is bringing the in-kernel DT closer to what the latest FW is providing to avoid potential conflicts. I do appreciate keeping the kernel one up to date with what firmware provides if it's truly needed, but I'd even more prefer that it wasn't. After all, it's how the ACPI-based booting works (no overriding table provided with the kernel), so it's a model you should already be somewhat familiar with. :) Agree. This is true in the x86 world where things are mostly stable. However, in the ARM64 cases, there are still newer supports being added. Often that I have been asked by folks to provide a base DT that they can extend (e.g. to add support for platform device pass-through, PCI pass-through, SBSA GWDT, etc). Eventually, this in-kernel DT would not be needed as the more stable DT would have already been in the later version of the FW. But in the meantime, it seems useful to have this in one accessible place. Thanks, Suravee I'm not doing a hard NAK on this, but I would like to get a bit more understanding of why it's considered needed. -Olof
Re: livepatch: Implement separate coming and going module notifiers
On Fri, 29 Jan 2016 17:58:29 -0500
Jessica Yu wrote:
> diff --git a/kernel/module.c b/kernel/module.c
> index 8358f46..eccd289 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -979,8 +979,12 @@ SYSCALL_DEFINE2(delete_module, const char __user *,
> name_user,
> /* Final destruction now no one is using it. */
> if (mod->exit != NULL)
> mod->exit();
> blocking_notifier_call_chain(&module_notify_list,
>MODULE_STATE_GOING, mod);
> + klp_module_disable(mod);
> + ftrace_release_mod(mod);
> +
> async_synchronize_full();
>
> /* Store the name of the last unloaded module for diagnostic purposes */
> @@ -3371,6 +3375,13 @@ static int complete_formation(struct module *mod,
> struct load_info *info)
> mod->state = MODULE_STATE_COMING;
> mutex_unlock(&module_mutex);
>
> + ftrace_module_enable(mod);
> + err = klp_module_enable(mod); // write all relocations before calling
> coming notifiers
> + if (err) {
> + ftrace_release_mod(mod);
This isn't needed. If complete_formation() fails with an error, then
its caller (load_module) will do the clean up and call
ftrace_release_mod().
-- Steve
> + goto out;
> + }
> +
> blocking_notifier_call_chain(&module_notify_list,
>MODULE_STATE_COMING, mod);
> return 0;
>
Re: [PATCH 2/4] dmi: Add a DMI firmware node and handling
Hi Corey,
[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on v4.5-rc1 next-20160129]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/minyard-acm-org/dmi-Rework-to-get-IPMI-autoloading-from-DMI-tables/20160130-074830
config: i386-tinyconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from arch/x86/kernel/setup.c:46:0:
include/linux/dmi.h: In function 'is_dmi_fwnode':
>> include/linux/dmi.h:164:1: error: expected ';' before '}' token
}
^
vim +164 include/linux/dmi.h
158 static inline const struct dmi_system_id *
159 dmi_first_match(const struct dmi_system_id *list) { return
NULL; }
160
161 static inline bool is_dmi_fwnode(struct fwnode_handle *fwnode)
162 {
163 return false
> 164 }
165
166 static inline struct dmi_fwnode *to_dmi_device(struct fwnode_handle
*fwnode)
167 {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v5 04/14] clk: clk-pic32: Add PIC32 clock driver
On 01/13, Joshua Henderson wrote:
> diff --git a/drivers/clk/clk-pic32.c b/drivers/clk/clk-pic32.c
> new file mode 100644
> index 000..9dc5f78
> --- /dev/null
> +++ b/drivers/clk/clk-pic32.c
> @@ -0,0 +1,1801 @@
> +/*
> + * Purna Chandra Mandal,
> + * Copyright (C) 2015 Microchip Technology Inc. All rights reserved.
> + *
> + * This program is free software; you can distribute it and/or modify it
> + * under the terms of the GNU General Public License (Version 2) as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> + * for more details.
> + */
> +#include
> +#include
Is this used?
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Please move asm includes after all linux includes.
Include for abs usage?
> +
> +#include
Is this header required? I'd like to be able to build this file
without using a MIPS compiler. For example, if we could move that
pic32_syskey_unlock() prototype somewhere else besides
asm/mach-pic32 then this should compile fine on non-MIPS kernels?
> +
> +/* OSCCON Reg fields */
> +#define OSC_CUR_MASK 0x07
> +#define OSC_CUR_SHIFT12
> +#define OSC_NEW_MASK 0x07
> +#define OSC_NEW_SHIFT8
> +#define OSC_SWEN 0x01
> +#define OSC_CLK_FAILED 0x04
> +
> +/* SPLLCON Reg fields */
> +#define PLL_RANGE_MASK 0x07
> +#define PLL_RANGE_SHIFT 0
> +#define PLL_ICLK_MASK0x01
> +#define PLL_ICLK_SHIFT 7
> +#define PLL_IDIV_MASK0x07
> +#define PLL_IDIV_SHIFT 8
> +#define PLL_ODIV_MASK0x07
> +#define PLL_ODIV_SHIFT 24
> +#define PLL_MULT_MASK0x7F
> +#define PLL_MULT_SHIFT 16
> +#define PLL_MULT_MAX 128
> +#define PLL_ODIV_MIN 1
> +#define PLL_ODIV_MAX 5
> +
> +/* Peripheral Bus Clock Reg Fields */
> +#define PB_DIV_MASK 0x7f
> +#define PB_DIV_SHIFT 0
> +#define PB_DIV_READY BIT(11)
> +#define PB_DIV_ENABLED BIT(15)
> +#define PB_DIV_MAX 128
> +#define PB_DIV_MIN 0
> +
> +/* Reference Oscillator Control Reg fields */
> +#define REFO_SEL_MASK0x0f
> +#define REFO_SEL_SHIFT 0
> +#define REFO_ACTIVE BIT(8)
> +#define REFO_DIVSW_ENBIT(9)
> +#define REFO_OE BIT(12)
> +#define REFO_ON BIT(15)
> +#define REFO_DIV_SHIFT 16
> +#define REFO_DIV_MASK0x7fff
> +
> +/* Reference Oscillator Trim Register Fields */
> +#define REFO_TRIM_REG0x10 /* Register offset w.r.t.
> REFO_CON_REG */
> +#define REFO_TRIM_MASK 0x1ff
> +#define REFO_TRIM_SHIFT 23
> +#define REFO_TRIM_MAX511
> +
> +/* FRC postscaler */
> +#define OSC_FRCDIV_MASK 0x07
> +#define OSC_FRCDIV_SHIFT 24
> +
> +/* FRC tuning */
> +#define OSC_FRCTUN_MASK 0x3F
> +#define OSC_FRCTUN_SHIFT 0
> +
> +/* SLEW Control Register fields */
> +#define SLEW_BUSY0x01
> +#define SLEW_DOWNEN 0x02
> +#define SLEW_UPEN0x04
> +#define SLEW_DIV 0x07
> +#define SLEW_DIV_SHIFT 8
> +#define SLEW_SYSDIV 0x0f
> +#define SLEW_SYSDIV_SHIFT20
> +
> +/* Common clock flags */
> +#define CLK_ENABLED_ALWAYS CLK_IGNORE_UNUSED
> +#define CLK_DIV_FIXEDBIT(20)
> +
> +/* Sys Mux clock flags */
> +#define SYS_MUX_POSTDIV 0x1
> +#define SYS_MUX_SLEW 0x2
> +
> +#define LOCK_TIMEOUT_NS (100 * NSEC_PER_MSEC)
> +
> +/* System PLL clk */
> +struct pic32_spll {
> + struct clk_hw hw;
> + void __iomem *regs;
> + void __iomem *status_reg;
> + u32 pll_locked;
Maybe this could be called lock_mask?
> + u8 idiv; /* pll-iclk divider, treating fixed */
> +};
> +
> +/* System Clk */
> +struct pic32_sclk {
> + struct clk_hw hw;
> + void __iomem *regs;
> + void __iomem *slwreg;
> + unsigned long flags;
> + u32 *parent_idx;
#ifdef CONFIG_DEBUGFS?
> + struct debugfs_regset32 regset;
> +};
> +
> +/* Reference Oscillator */
> +struct pic32_refosc {
> + struct clk_hw hw;
> + void __iomem *regs;
> + u32 *parent_idx;
> + struct debugfs_regset32 regset;
> +};
> +
> +/* Peripheral Bus Clock */
> +struct pic32_pbclk {
> + struct clk_hw hw;
> + void __iomem *regs;
> + u32 flags;
This should probably be unsigned long.
> + struct debugfs_regset32 regset;
> +};
> +
> +/* External SOSC(fixed gated) clock */
> +struct pic32_sosc {
> + struct clk_hw hw;
> + void __iomem *regs;
> +
[PATCH v2 1/3] input: touchscreen: ad7879: move header to platform_data directory
The header file is used by the SPI and I2C variant of the driver.
Therefore, move it to a more generic place under platform_data.
Signed-off-by: Stefan Agner
---
Changes since v1:
- Move to include/linux/platform_data/
arch/blackfin/mach-bf527/boards/ezbrd.c| 2 +-
arch/blackfin/mach-bf527/boards/ezkit.c| 2 +-
arch/blackfin/mach-bf527/boards/tll6527m.c | 2 +-
arch/blackfin/mach-bf537/boards/stamp.c| 2 +-
arch/blackfin/mach-bf538/boards/ezkit.c| 2 +-
drivers/input/touchscreen/ad7879.c | 10
include/linux/platform_data/ad7879.h | 41 ++
include/linux/spi/ad7879.h | 41 --
8 files changed, 51 insertions(+), 51 deletions(-)
create mode 100644 include/linux/platform_data/ad7879.h
delete mode 100644 include/linux/spi/ad7879.h
diff --git a/arch/blackfin/mach-bf527/boards/ezbrd.c
b/arch/blackfin/mach-bf527/boards/ezbrd.c
index a3a5723..80bcfd1 100644
--- a/arch/blackfin/mach-bf527/boards/ezbrd.c
+++ b/arch/blackfin/mach-bf527/boards/ezbrd.c
@@ -279,7 +279,7 @@ static const struct ad7877_platform_data
bfin_ad7877_ts_info = {
#endif
#if IS_ENABLED(CONFIG_TOUCHSCREEN_AD7879)
-#include
+#include
static const struct ad7879_platform_data bfin_ad7879_ts_info = {
.model = 7879, /* Model = AD7879 */
.x_plate_ohms = 620, /* 620 Ohm from the touch datasheet */
diff --git a/arch/blackfin/mach-bf527/boards/ezkit.c
b/arch/blackfin/mach-bf527/boards/ezkit.c
index d4219e8..571edfd 100644
--- a/arch/blackfin/mach-bf527/boards/ezkit.c
+++ b/arch/blackfin/mach-bf527/boards/ezkit.c
@@ -477,7 +477,7 @@ static const struct ad7877_platform_data
bfin_ad7877_ts_info = {
#endif
#if IS_ENABLED(CONFIG_TOUCHSCREEN_AD7879)
-#include
+#include
static const struct ad7879_platform_data bfin_ad7879_ts_info = {
.model = 7879, /* Model = AD7879 */
.x_plate_ohms = 620, /* 620 Ohm from the touch datasheet */
diff --git a/arch/blackfin/mach-bf527/boards/tll6527m.c
b/arch/blackfin/mach-bf527/boards/tll6527m.c
index a0f5856..c1acce4 100644
--- a/arch/blackfin/mach-bf527/boards/tll6527m.c
+++ b/arch/blackfin/mach-bf527/boards/tll6527m.c
@@ -29,7 +29,7 @@
#include
#if IS_ENABLED(CONFIG_TOUCHSCREEN_AD7879)
-#include
+#include
#define LCD_BACKLIGHT_GPIO 0x40
/* TLL6527M uses TLL7UIQ35 / ADI LCD EZ Extender. AD7879 AUX GPIO is used for
* LCD Backlight Enable
diff --git a/arch/blackfin/mach-bf537/boards/stamp.c
b/arch/blackfin/mach-bf537/boards/stamp.c
index c181543..eaec7b4 100644
--- a/arch/blackfin/mach-bf537/boards/stamp.c
+++ b/arch/blackfin/mach-bf537/boards/stamp.c
@@ -776,7 +776,7 @@ static const struct ad7877_platform_data
bfin_ad7877_ts_info = {
#endif
#if IS_ENABLED(CONFIG_TOUCHSCREEN_AD7879)
-#include
+#include
static const struct ad7879_platform_data bfin_ad7879_ts_info = {
.model = 7879, /* Model = AD7879 */
.x_plate_ohms = 620, /* 620 Ohm from the touch datasheet */
diff --git a/arch/blackfin/mach-bf538/boards/ezkit.c
b/arch/blackfin/mach-bf538/boards/ezkit.c
index ae2fcbb..4a03c44 100644
--- a/arch/blackfin/mach-bf538/boards/ezkit.c
+++ b/arch/blackfin/mach-bf538/boards/ezkit.c
@@ -521,7 +521,7 @@ static struct bfin5xx_spi_chip spi_flash_chip_info = {
#endif /* CONFIG_SPI_BFIN5XX */
#if IS_ENABLED(CONFIG_TOUCHSCREEN_AD7879)
-#include
+#include
static const struct ad7879_platform_data bfin_ad7879_ts_info = {
.model = 7879, /* Model = AD7879 */
.x_plate_ohms = 620, /* 620 Ohm from the touch datasheet */
diff --git a/drivers/input/touchscreen/ad7879.c
b/drivers/input/touchscreen/ad7879.c
index 16b5cc2..93b8ea2 100644
--- a/drivers/input/touchscreen/ad7879.c
+++ b/drivers/input/touchscreen/ad7879.c
@@ -31,7 +31,7 @@
#include
#include
-#include
+#include
#include
#include "ad7879.h"
@@ -170,10 +170,10 @@ static int ad7879_report(struct ad7879 *ts)
* filter. The combination of these two techniques provides a robust
* solution, discarding the spurious noise in the signal and keeping
* only the data of interest. The size of both filters is
-* programmable. (dev.platform_data, see linux/spi/ad7879.h) Other
-* user-programmable conversion controls include variable acquisition
-* time, and first conversion delay. Up to 16 averages can be taken
-* per conversion.
+* programmable. (dev.platform_data, see linux/platform_data/ad7879.h)
+* Other user-programmable conversion controls include variable
+* acquisition time, and first conversion delay. Up to 16 averages can
+* be taken per conversion.
*/
if (likely(x && z1)) {
diff --git a/include/linux/platform_data/ad7879.h
b/include/linux/platform_data/ad7879.h
new file mode 100644
index 000..69e2e1fd
--- /dev/null
+++ b/include/linux/platf
