[PATCH] cpupower: fix potential memory leak

2016-02-13 Thread Arjun Sreedharan
Signed-off-by: Arjun Sreedharan 
---
 tools/power/cpupower/bench/parse.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/power/cpupower/bench/parse.c 
b/tools/power/cpupower/bench/parse.c
index f503fb5..058a351 100644
--- a/tools/power/cpupower/bench/parse.c
+++ b/tools/power/cpupower/bench/parse.c
@@ -65,7 +65,7 @@ FILE *prepare_output(const char *dirname)
 {
FILE *output = NULL;
int len;
-   char *filename;
+   char *filename, *filename_tmp;
struct utsname sysdata;
DIR *dir;
 
@@ -80,17 +80,19 @@ FILE *prepare_output(const char *dirname)
}
 
len = strlen(dirname) + 30;
-   filename = malloc(sizeof(char) * len);
+   filename = malloc(sizeof(*filename) * len);
 
if (uname() == 0) {
len += strlen(sysdata.nodename) + strlen(sysdata.release);
-   filename = realloc(filename, sizeof(char) * len);
+   filename_tmp = realloc(filename, sizeof(*filename) * len);
 
-   if (filename == NULL) {
+   if (filename_tmp == NULL) {
+   free(filename);
perror("realloc");
return NULL;
}
 
+   filename = filename_tmp;
snprintf(filename, len - 1, "%s/benchmark_%s_%s_%li.log",
dirname, sysdata.nodename, sysdata.release, time(NULL));
} else {
-- 
2.4.5



[lkp] [x86] d5422bd64e: kasan: WARNING: KASAN doesn't support memory hot-add

2016-02-13 Thread kernel test robot
FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit d5422bd64ebb5b03bcf148f5b58c29a9ad7e990f ("x86: also use 
debug_pagealloc_enabled() for free_init_pages")


[9.917676] kasan: WARNING: KASAN doesn't support memory hot-add
[9.918444] kasan: Memory hot-add will be disabled


Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.5.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=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_KASAN_SHADOW_OFFSET=0xdc00
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_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
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=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
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_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
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 is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_CGROUPS=y
# CONFIG_MEMCG is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CGROUP_SCHED is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_CGROUP_PERF is not set
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
# CONFIG_SYSFS_SYSCALL is not set
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
# CONFIG_PCSPKR_PLATFORM is 

Re: [PATCH] [media] zl10353: use div_u64 instead of do_div

2016-02-13 Thread Ard Biesheuvel
On 13 February 2016 at 22:57, Nicolas Pitre  wrote:
> On Sat, 13 Feb 2016, Ard Biesheuvel wrote:
>
>> On 12 February 2016 at 22:01, Arnd Bergmann  wrote:
>> > However, I did stumble over an older patch I did now, which I could
>> > not remember what it was good for. It does fix the problem, and
>> > it seems to be a better solution.
>> >
>> > Arnd
>> >
>> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
>> > index b5acbb404854..b5ff9881bef8 100644
>> > --- a/include/linux/compiler.h
>> > +++ b/include/linux/compiler.h
>> > @@ -148,7 +148,7 @@ void ftrace_likely_update(struct ftrace_branch_data 
>> > *f, int val, int expect);
>> >   */
>> >  #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
>> >  #define __trace_if(cond) \
>> > -   if (__builtin_constant_p((cond)) ? !!(cond) :   \
>> > +   if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
>> > ({  \
>> > int __r;\
>> > static struct ftrace_branch_data\
>> >
>>
>> I remember seeing this patch, but I don't remember the exact context.
>> But when you think about it, !!cond can be a build time constant even
>> if cond is not, as long as you can prove statically that cond != 0. So
>
> You're right.  I just tested it and to my surprise gcc is smart enough
> to figure that case out.
>
>> I think this change is obviously correct, and an improvement since it
>> will remove the profiling overhead of branches that are not true
>> branches in the first place.
>
> Indeed.
>

... and perhaps we should not evaluate cond twice either?


Re: [PATCH] ARM: imx_v6_v7_defconfig: enable useful configurations for Vybrid

2016-02-13 Thread Shawn Guo
On Wed, Feb 10, 2016 at 06:08:18PM -0800, Stefan Agner wrote:
> Enable configuration options useful for Vybrid:
> - NFC NAND driver
> - USB dual-role controller support
> - FTM PWM driver
> - DSPI SPI driver
> - Colibri VF50 Touchscreen support.
> 
> Beside that, enable useful configurations such as IIO hwmon support
> (used in i.MX 23/28, patch pending for Vybrid), PWM LED support and
> CPU idle support.
> 
> Regenerated config using savedefconfig (which removes some configs
> which are now enabled by default).
> 
> Signed-off-by: Stefan Agner 

Applied, thanks.


Re: [PATCH 1/2] ARM: dts: vf610twr: assign Ethernet clock explicitly

2016-02-13 Thread Shawn Guo
On Wed, Feb 10, 2016 at 04:02:25PM -0800, Stefan Agner wrote:
> Assign Ethernet clock parents explicitly. The VF610 Tower Board
> uses the external Ethernet clock input which is connected to
> a 50MHz clock.
> 
> The Vybrid SoC has two ethernet interfaces (fec0 and fec1) which
> use the same clock source (VF610_CLK_ENET). Therefore this parent
> configuration affects multiple consumer devices and need to be
> specified in the clock provider node.
> 
> Signed-off-by: Stefan Agner 

Applied both, thanks.


Re: [PATCH] ARM: dts: ls1043a: Add quirk for Erratum A009116

2016-02-13 Thread Shawn Guo
On Wed, Feb 10, 2016 at 10:39:47AM +0530, Rajesh Bhagat wrote:
> Add "snps,quirk-frame-length-adjustment" property to USB3 node for erratum 
> A009116.
> This property provides value of GFLADJ_30MHZ for post silicon frame length 
> adjustment.

The commit log should be generally wrapped around column 70.  I fixed
it up and applied patch.

Shawn

> 
> Signed-off-by: Rajesh Bhagat 
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> index 42a6154..be72bf5 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> @@ -407,6 +407,7 @@
>   reg = <0x0 0x2f0 0x0 0x1>;
>   interrupts = <0 60 0x4>;
>   dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
>   };
>  
>   usb1: usb3@300 {
> @@ -414,6 +415,7 @@
>   reg = <0x0 0x300 0x0 0x1>;
>   interrupts = <0 61 0x4>;
>   dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
>   };
>  
>   usb2: usb3@310 {
> @@ -421,6 +423,7 @@
>   reg = <0x0 0x310 0x0 0x1>;
>   interrupts = <0 63 0x4>;
>   dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
>   };
>  
>   sata: sata@320 {
> -- 
> 2.6.2.198.g614a2ac
> 
> 


Re: [PATCH] ARM: dts: ls2080a: Add quirk for Erratum A009116

2016-02-13 Thread Shawn Guo
On Tue, Feb 09, 2016 at 05:08:07PM -0600, Lijun Pan wrote:
> Add "snps,quirk-frame-length-adjustment" property to
> USB3 node for erratum A009116. This property provides
> value of GFLADJ_30MHZ for post silicon frame length
> adjustment.
> 
> Signed-off-by: Lijun Pan 

Applied, thanks.


[lkp] [f2fs] 974b5afbf1: +187.0% fsmark.time.voluntary_context_switches

2016-02-13 Thread kernel test robot
FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs dev-test
commit 974b5afbf16ecd3e01cefd5d52e3090b6d967693 ("f2fs: use writepages->lock 
for WB_SYNC_ALL")


=
compiler/disk/filesize/fs/iterations/kconfig/nr_directories/nr_files_per_directory/nr_threads/rootfs/sync_method/tbox_group/test_size/testcase:
  
gcc-4.9/1HDD/16MB/f2fs/1x/x86_64-rhel/16d/256fpd/32t/debian-x86_64-2015-02-07.cgz/fsyncBeforeClose/nhm4/60G/fsmark

commit: 
  ac247fd0403387a3f264b86b41cdc71543e66400
  974b5afbf16ecd3e01cefd5d52e3090b6d967693

ac247fd0403387a3 974b5afbf16ecd3e01cefd5d52 
 -- 
 %stddev %change %stddev
 \  |\  
 40098 ±  2% +25.7%  50389 ±  3%  
fsmark.time.involuntary_context_switches
 19.30 ±  2% +18.1%  22.80 ±  1%  
fsmark.time.percent_of_cpu_this_job_got
 97.36 ±  1% +18.1% 115.00 ±  1%  fsmark.time.system_time
804635 ±  1%+187.0%2309592 ±  5%  
fsmark.time.voluntary_context_switches
  1904 ±  1% -18.8%   1546 ±  3%  uptime.idle
 38568 ±  2% +19.0%  45897 ±  3%  softirqs.RCU
 45610 ±  1% +26.9%  57875 ±  1%  softirqs.SCHED
 78751 ±  1% +39.3% 109673 ±  0%  softirqs.TIMER
 65587 ±  0% +76.5% 115770 ±  0%  vmstat.memory.free
  4605 ±  1%+159.8%  11962 ±  3%  vmstat.system.cs
564.10 ±  1% +75.7% 991.10 ±  0%  vmstat.system.in
 65578 ±  0% +76.3% 115584 ±  0%  meminfo.MemFree
 69193 ±  0% +46.4% 101331 ±  2%  meminfo.SReclaimable
 79277 ±  0% +53.9% 121991 ±  0%  meminfo.SUnreclaim
148470 ±  0% +50.4% 223322 ±  1%  meminfo.Slab
  1066 ±  2% +45.8%   1554 ±  1%  time.file_system_inputs
 40098 ±  2% +25.7%  50389 ±  3%  time.involuntary_context_switches
 19.30 ±  2% +18.1%  22.80 ±  1%  time.percent_of_cpu_this_job_got
 97.36 ±  1% +18.1% 115.00 ±  1%  time.system_time
804635 ±  1%+187.0%2309592 ±  5%  time.voluntary_context_switches
  4.80 ±  3%+240.9%  16.37 ±  3%  turbostat.%Busy
150.30 ±  3%+259.0% 539.60 ±  3%  turbostat.Avg_MHz
 10.10 ±  2% +69.4%  17.11 ±  2%  turbostat.CPU%c1
 24.51 ±  2% +12.3%  27.54 ±  2%  turbostat.CPU%c3
 60.59 ±  0% -35.7%  38.99 ±  2%  turbostat.CPU%c6
 56.00 ±  1% +12.9%  63.20 ±  1%  turbostat.CoreTmp
 1.042e+08 ±  3% -32.6%   70243667 ±  5%  cpuidle.C1E-NHM.time
  5.49e+08 ±  2% +23.1%   6.76e+08 ±  2%  cpuidle.C3-NHM.time
155243 ±  2% +22.3% 189817 ±  3%  cpuidle.C3-NHM.usage
 3.052e+09 ±  0% -17.6%  2.515e+09 ±  1%  cpuidle.C6-NHM.time
132307 ±  2% +20.6% 159621 ±  2%  cpuidle.C6-NHM.usage
  64832253 ±  9%+626.5%   4.71e+08 ±  4%  cpuidle.POLL.time
 95963 ±  2%+987.2%1043299 ±  8%  cpuidle.POLL.usage
582.20 ±  0%+1e+05% 583505 ±  7%  
slabinfo.f2fs_extent_node.active_objs
  7.20 ±  5%  +1.1e+05%   7994 ±  7%  
slabinfo.f2fs_extent_node.active_slabs
582.20 ±  0%+1e+05% 583664 ±  7%  slabinfo.f2fs_extent_node.num_objs
  7.20 ±  5%  +1.1e+05%   7994 ±  7%  
slabinfo.f2fs_extent_node.num_slabs
 10171 ±  6% +22.6%  12471 ± 10%  slabinfo.free_nid.active_objs
 10194 ±  6% +23.4%  12580 ±  9%  slabinfo.free_nid.num_objs
  1834 ±  1%+543.2%  11798 ±  0%  slabinfo.kmalloc-256.active_objs
 78.70 ±  6%+406.9% 398.90 ±  1%  slabinfo.kmalloc-256.active_slabs
  2524 ±  6%+403.5%  12710 ±  1%  slabinfo.kmalloc-256.num_objs
 78.70 ±  6%+406.9% 398.90 ±  1%  slabinfo.kmalloc-256.num_slabs
355.80 ±  0%   +2796.0%  10303 ±  1%  slabinfo.kmalloc-4096.active_objs
 55.00 ±  1%   +8795.8%   4892 ±  3%  slabinfo.kmalloc-4096.active_slabs
378.60 ±  0%   +2639.0%  10369 ±  1%  slabinfo.kmalloc-4096.num_objs
 55.00 ±  1%   +8795.8%   4892 ±  3%  slabinfo.kmalloc-4096.num_slabs
  2929 ± 11%   +1926.0%  59360 ±  5%  proc-vmstat.allocstall
160.70 ± 28%+461.8% 902.80 ± 39%  proc-vmstat.compact_isolated
116.60 ± 21%   +1575.8%   1954 ±124%  
proc-vmstat.compact_migrate_scanned
  1657 ± 10%  +10214.9% 170917 ± 14%  
proc-vmstat.kswapd_high_wmark_hit_quickly
 14489 ±  3%+974.7% 155724 ± 12%  
proc-vmstat.kswapd_low_wmark_hit_quickly
 16393 ±  0% +76.3%  28901 ±  0%  proc-vmstat.nr_free_pages
 17297 ±  0% +46.4%  25331 ±  2%  proc-vmstat.nr_slab_reclaimable
 19818 ±  0% +53.9%  30499 ±  0%  proc-vmstat.nr_slab_unreclaimable
  16253363 ±  0% +21.1%   19685684 ±  0%  proc-vmstat.numa_hit
  16253363 ±  0% +21.1%   19685684 ±  0%  proc-vmstat.numa_local
 16974 ±  2%   +1830.1% 327619 ± 13%  

Re: [tpmdd-devel] [PATCH 2/3] tpm: Get rid of chip->pdev

2016-02-13 Thread Jason Gunthorpe
On Sat, Feb 13, 2016 at 10:39:11AM -0500, Stefan Berger wrote:

> >@@ -347,8 +347,8 @@ static int i2c_nuvoton_recv(struct tpm_chip *chip, u8 
> >*buf, size_t count)
> >   */
> >  static int i2c_nuvoton_send(struct tpm_chip *chip, u8 *buf, size_t len)
> >  {
> >-struct device *dev = chip->pdev;
> >-struct i2c_client *client = to_i2c_client(dev);
> >+struct device *dev = >dev;
> This looks wrong or are you fixing a bug here? chip->dev.parent ?

No, in this function dev is only used for dev_err/etc so it should be
changed, like every other dev_err/etc call in this patch.

Expect for this use:

> >+struct i2c_client *client = to_i2c_client(chip->dev.parent);
> 
> Does this need to be replaced ?

Which must stay as the parent.

Jason


Re: [PATCH v3 3/7] debugfs: add support for self-protecting attribute file fops

2016-02-13 Thread Julia Lawall


On Sun, 14 Feb 2016, Nicolai Stange wrote:

> In order to protect them against file removal issues, debugfs_create_file()
> creates a lifetime managing proxy around each struct file_operations
> handed in.
> 
> In cases where this struct file_operations is able to manage file lifetime
> by itself already, the proxy created by debugfs is a waste of resources.
> 
> The most common class of struct file_operations given to debugfs are those
> defined by means of the DEFINE_SIMPLE_ATTRIBUTE() macro.
> 
> Introduce a DEFINE_DEBUGFS_ATTRIBUTE() macro to allow any
> struct file_operations of this class to be easily made file lifetime aware
> and thus, to be operated unproxied.
> 
> Specifically, introduce debugfs_attr_read() and debugfs_attr_write()
> which wrap simple_attr_read() and simple_attr_write() under the protection
> of a debugfs_use_file_start()/debugfs_use_file_finish() pair.
> 
> Make DEFINE_DEBUGFS_ATTRIBUTE() set the defined struct file_operations'
> ->read() and ->write() members to these wrappers.
> 
> Export debugfs_create_file_unsafe() in order to allow debugfs users to
> create their files in non-proxying operation mode.
> 
> Finally, add a Coccinelle script chasing down possible candidates
> for a DEFINE_SIMPLE_ATTRIBUTE()/debugfs_create_file() to
> DEFINE_DEBUGFS_ATTRIBUTE()/debugfs_create_file_unsafe() migration.
> 
> Signed-off-by: Nicolai Stange 
> ---
>  fs/debugfs/file.c  | 28 +
>  fs/debugfs/inode.c | 28 +
>  include/linux/debugfs.h| 26 +
>  .../api/debugfs/debugfs_simple_attr.cocci  | 68 
> ++

Shouldn't the .cocci file be in a different patch, since it has a 
different maintainer?

julia

>  4 files changed, 150 insertions(+)
>  create mode 100644 scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
> 
> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> index f638dbc..2da5fb0 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -285,6 +285,34 @@ const struct file_operations 
> debugfs_full_proxy_file_operations = {
>   .open = full_proxy_open,
>  };
>  
> +ssize_t debugfs_attr_read(struct file *file, char __user *buf,
> + size_t len, loff_t *ppos)
> +{
> + ssize_t ret;
> + int srcu_idx;
> +
> + ret = debugfs_use_file_start(F_DENTRY(file), _idx);
> + if (likely(!ret))
> + ret = simple_attr_read(file, buf, len, ppos);
> + debugfs_use_file_finish(srcu_idx);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(debugfs_attr_read);
> +
> +ssize_t debugfs_attr_write(struct file *file, const char __user *buf,
> +  size_t len, loff_t *ppos)
> +{
> + ssize_t ret;
> + int srcu_idx;
> +
> + ret = debugfs_use_file_start(F_DENTRY(file), _idx);
> + if (likely(!ret))
> + ret = simple_attr_write(file, buf, len, ppos);
> + debugfs_use_file_finish(srcu_idx);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(debugfs_attr_write);
> +
>  static struct dentry *debugfs_create_mode(const char *name, umode_t mode,
> struct dentry *parent, void *value,
> const struct file_operations *fops,
> diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
> index 42a9b34..f95e355 100644
> --- a/fs/debugfs/inode.c
> +++ b/fs/debugfs/inode.c
> @@ -368,6 +368,33 @@ struct dentry *debugfs_create_file(const char *name, 
> umode_t mode,
>  }
>  EXPORT_SYMBOL_GPL(debugfs_create_file);
>  
> +/**
> + * debugfs_create_file_unsafe - create a file in the debugfs filesystem
> + * @name: a pointer to a string containing the name of the file to create.
> + * @mode: the permission that the file should have.
> + * @parent: a pointer to the parent dentry for this file.  This should be a
> + *  directory dentry if set.  If this parameter is NULL, then the
> + *  file will be created in the root of the debugfs filesystem.
> + * @data: a pointer to something that the caller will want to get to later
> + *on.  The inode.i_private pointer will point to this value on
> + *the open() call.
> + * @fops: a pointer to a struct file_operations that should be used for
> + *this file.
> + *
> + * debugfs_create_file_unsafe() is completely analogous to
> + * debugfs_create_file(), the only difference being that the fops
> + * handed it will not get protected against file removals by the
> + * debugfs core.
> + *
> + * It is your responsibility to protect your struct file_operation
> + * methods against file removals by means of debugfs_use_file_start()
> + * and debugfs_use_file_finish(). ->open() is still protected by
> + * debugfs though.
> + *
> + * Any struct file_operations defined by means of
> + * DEFINE_DEBUGFS_ATTRIBUTE() is protected against file removals and
> + * thus, may be used here.
> + */
>  struct dentry *debugfs_create_file_unsafe(const char *name, umode_t 

Re: [PATCH 1/1 v3] ARM: dts: imx6dlq-wandboard-revb1.dts: use unique model id

2016-02-13 Thread Shawn Guo
On Mon, Feb 08, 2016 at 01:55:08AM +0100, Heinrich Schuchardt wrote:
> Downstream packages like Debian flash-kernel use
> /proc/device-tree/model
> to determine which dtb file to install.
> 
> Hence each dts in the Linux kernel should provide a unique model
> identifier.
> 
> Commit 8536239e371f ("ARM: dts: Restructure imx6qdl-wandboard.dtsi for new
> rev C1 board.")' created new files imx6dl-wandboard-revb1.dts and
> imx6q-wandboard-revb1.dts but used the same model identifier as in
> imx6dl-wandboard.dts and imx6q-wandboard.dts.
> 
> This patch provides unique model identifiers for revision B1 of
> the Wandboard Dual and Wandbaord Quad.
> 
> The patch leaves imx6dl-wandboard.dts and imx6q-wandboard.dts unchanged
> because it is not foreseeable if the same dts will valid for future
> board revisions or not. Furthermore we should avoid unnecessary
> changes.
> 
> v3:
>   update imx6dl-wandboard-revb1.dts
> 
> v2:
>   correct name of referenced Debian package
> 
> Signed-off-by: Heinrich Schuchardt 

Applied, thanks.


[lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number

2016-02-13 Thread kernel test robot
FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git chardev
commit 3c702e9987e261042a07e43460a8148be254412e ("gpio: add a userspace chardev 
ABI for GPIOs")


[1.951191] user_verbs: couldn't register device number
[1.952527] ucm: couldn't register device number


Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 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_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=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_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=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# 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 is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=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_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set

#
# 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 is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
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 is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
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_NUMA_BALANCING is not set
CONFIG_CGROUPS=y
# CONFIG_MEMCG is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CGROUP_SCHED is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_CGROUP_PERF is not set
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
# CONFIG_IPC_NS is not set
CONFIG_USER_NS=y
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y

Re: [PATCH 2/3] tpm: Get rid of chip->pdev

2016-02-13 Thread Jason Gunthorpe
On Sun, Feb 14, 2016 at 07:24:14AM +0200, Jarkko Sakkinen wrote:
> > This should take care of it for all drivers including vtpm.
> > 
> > https://github.com/jgunthorpe/linux/commits/for-jarkko
> > 
> > At the very least this turns silent use after free into a null pointer
> > oops.
> > 
> > We should also discuss if we want to continue to have the driver
> > module locked while /dev/tpmX is open, that is no longer needed for
> > corectness.
> 
> I'm happy the patch that was sent before although I didn't give it
> Reviewed-by because it had couple of style errors. If those two
> style errors are the *only* issues I can fix up them.

This patch replaces the get/put_device patch entirely, if Stefan is
happy with it we can just go ahead in this direction for 4.6

There was also a 0day build error on the devname patch, so the whole
series will be reposted.

Jason


Re: [PATCH v5 0/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM/Ixora carrier board

2016-02-13 Thread Shawn Guo
On Fri, Feb 05, 2016 at 05:12:19PM +0100, Marcel Ziswiler wrote:
> Petr Štetiar (2):
>   ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM
>   ARM: dts: imx6: Add support for Toradex Ixora carrier board

Applied both, thanks.


Re: [PATCH] regulator: Rename files for max77686 and max77802 drivers

2016-02-13 Thread Krzysztof Kozlowski
W dniu 12.02.2016 o 13:14, Javier Martinez Canillas pisze:
> The max77686 and max77802 regulator drivers are for sub-devices of a MFD
> driver for some PMIC blocks. But the same object file name (max77686.o)
> was used for both the common MFD driver and the max77686 regulator one.
> 
> This confuses kbuild if both drivers are built as module causing the MFD
> driver to not be copied when installing the modules.
> 
> Also, max77{686,802} are a quite generic name for MFD subdevices drivers
> so it is better to rename them to max77{686,802}-regulator like it's the
> case for most regulator drivers.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  MAINTAINERS| 2 +-
>  drivers/regulator/Makefile | 4 ++--
>  drivers/regulator/{max77686.c => max77686-regulator.c} | 0
>  drivers/regulator/{max77802.c => max77802-regulator.c} | 0
>  4 files changed, 3 insertions(+), 3 deletions(-)
>  rename drivers/regulator/{max77686.c => max77686-regulator.c} (100%)
>  rename drivers/regulator/{max77802.c => max77802-regulator.c} (100%)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 97b99f24ea53..863eb59e101b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6904,7 +6904,7 @@ MAXIM MAX77802 MULTIFUNCTION PMIC DEVICE DRIVERS
>  M:   Javier Martinez Canillas 
>  L:   linux-kernel@vger.kernel.org
>  S:   Supported
> -F:   drivers/*/*max77802.c
> +F:   drivers/*/*max77802*.c
>  F:   Documentation/devicetree/bindings/*/*max77802.txt
>  F:   include/dt-bindings/*/*max77802.h

Looks fine, but can you also update the max77686 entry with extended
wildcard?

Best regards,
Krzysztof



[PATCH v2 1/2] tracing/mm: don't trace kfree on offline CPUs

2016-02-13 Thread Denis Kirjanov
Tracepoints use RCU for protection and they must not be called on
offline CPUS. So make this tracepoint conditional.

INFO: suspicious RCU usage. ]
[   99.749382] 4.4.0-6-g0fe53e8-dirty #34 Tainted: G S
[   99.749383] ---
[   99.749385] include/trace/events/kmem.h:141 suspicious 
rcu_dereference_check() usage!
[   99.749385]
other info that might help us debug this:

[   99.749387]
RCU used illegally from offline CPU!
rcu_scheduler_active = 1, debug_locks = 1
[   99.749388] no locks held by swapper/8/0.
[   99.749388]
stack backtrace:
[   99.749390] CPU: 8 PID: 0 Comm: swapper/8 Tainted: G S  
4.4.0-6-g0fe53e8-dirty #34
[   99.749391] Call Trace:
[   99.749399] [c005b76c78d0] [c08b9540] .dump_stack+0x98/0xd4 
(unreliable)
[   99.749402] [c005b76c7950] [c010c898] 
.lockdep_rcu_suspicious+0x108/0x170
[   99.749405] [c005b76c79e0] [c029adc0] .kfree+0x390/0x440
[   99.749409] [c005b76c7a80] [c0055f74] .destroy_context+0x44/0x100
[   99.749412] [c005b76c7b00] [c00934a0] .__mmdrop+0x60/0x150
[   99.749415] [c005b76c7b90] [c00e3ff0] .idle_task_exit+0x130/0x140
[   99.749417] [c005b76c7c20] [c0075804] 
.pseries_mach_cpu_die+0x64/0x310
[   99.749420] [c005b76c7cd0] [c0043e7c] .cpu_die+0x3c/0x60
[   99.749423] [c005b76c7d40] [c00188d8] 
.arch_cpu_idle_dead+0x28/0x40
[   99.749426] [c005b76c7db0] [c0101e6c] 
.cpu_startup_entry+0x50c/0x560
[   99.749428] [c005b76c7ed0] [c0043bd8] 
.start_secondary+0x328/0x360
[   99.749431] [c005b76c7f90] [c0008a6c] 
start_secondary_prolog+0x10/0x14

Signed-off-by: Denis Kirjanov 
---
 include/trace/events/kmem.h | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
index f7554fd..9473c2d 100644
--- a/include/trace/events/kmem.h
+++ b/include/trace/events/kmem.h
@@ -133,11 +133,22 @@ DECLARE_EVENT_CLASS(kmem_free,
TP_printk("call_site=%lx ptr=%p", __entry->call_site, __entry->ptr)
 );
 
-DEFINE_EVENT(kmem_free, kfree,
+DEFINE_EVENT_CONDITION(kmem_free, kfree,
 
TP_PROTO(unsigned long call_site, const void *ptr),
 
-   TP_ARGS(call_site, ptr)
+   TP_ARGS(call_site, ptr),
+
+   /*
+* This trace can be potentially called from an offlined cpu.
+* Since trace points use RCU and RCU should not be used from
+* offline cpus, filter such calls out.
+* While this trace can be called from a preemptable section,
+* it has no impact on the condition since tasks can migrate
+* only from online cpus to other online cpus. Thus its safe
+* to use raw_smp_processor_id.
+*/
+   TP_CONDITION(cpu_online(raw_smp_processor_id()))
 );
 
 DEFINE_EVENT_CONDITION(kmem_free, kmem_cache_free,
-- 
2.4.0



[PATCH v2 2/2] tracing/rcu: don't trace rcu_callback on offline CPUs

2016-02-13 Thread Denis Kirjanov
Tracepoints use RCU for protection and they must not be called on
offline CPUS. So make this tracepoint conditional.

NFO: suspicious RCU usage. ]
[  413.344670] 4.4.0-6-g0fe53e8-dirty #33 Tainted: G S
[  413.344672] ---
[  413.344673] include/trace/events/rcu.h:457 suspicious 
rcu_dereference_check() usage!
[  413.344674]
other info that might help us debug this:

[  413.344676]
RCU used illegally from offline CPU!
rcu_scheduler_active = 1, debug_locks = 1
[  413.344678] no locks held by swapper/4/0.
[  413.344679]
stack backtrace:
[  413.344682] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G S  
4.4.0-6-g0fe53e8-dirty #33
[  413.344683] Call Trace:
[  413.344692] [c005b76b7800] [c08bb080] .dump_stack+0x98/0xd4 
(unreliable)
[  413.344698] [c005b76b7880] [c010c8b8] 
.lockdep_rcu_suspicious+0x108/0x170
[  413.344703] [c005b76b7910] [c013b9e4] 
.__call_rcu.constprop.60+0x264/0x600
[  413.344708] [c005b76b79e0] [c02bceec] .put_object+0x5c/0x80
[  413.344712] [c005b76b7a60] [c029a368] 
.kmem_cache_free+0x298/0x450
[  413.344716] [c005b76b7b00] [c0093494] .__mmdrop+0x54/0x150
[  413.344720] [c005b76b7b90] [c00e4010] .idle_task_exit+0x130/0x140
[  413.344725] [c005b76b7c20] [c0075804] 
.pseries_mach_cpu_die+0x64/0x310
[  413.344730] [c005b76b7cd0] [c0043e7c] .cpu_die+0x3c/0x60
[  413.344734] [c005b76b7d40] [c00188d8] 
.arch_cpu_idle_dead+0x28/0x40
[  413.344738] [c005b76b7db0] [c0101e8c] 
.cpu_startup_entry+0x50c/0x560
[  413.344741] [c005b76b7ed0] [c0043bd8] 
.start_secondary+0x328/0x360
[  413.344746] [c005b76b7f90] [c0008a6c] 
start_secondary_prolog+0x10/0x14

Signed-off-by: Denis Kirjanov 
---

v2: Fix the build error that was made
while sending the pacthes from another machine

 include/trace/events/rcu.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
index ef72c4a..793d306b 100644
--- a/include/trace/events/rcu.h
+++ b/include/trace/events/rcu.h
@@ -428,13 +428,15 @@ TRACE_EVENT(rcu_prep_idle,
  * number of lazy callbacks queued, and the fourth element is the
  * total number of callbacks queued.
  */
-TRACE_EVENT(rcu_callback,
+TRACE_EVENT_CONDITION(rcu_callback,
 
TP_PROTO(const char *rcuname, struct rcu_head *rhp, long qlen_lazy,
 long qlen),
 
TP_ARGS(rcuname, rhp, qlen_lazy, qlen),
 
+   TP_CONDITION(cpu_online(raw_smp_processor_id())),
+
TP_STRUCT__entry(
__field(const char *, rcuname)
__field(void *, rhp)
-- 
2.4.0



Re: [PATCH 1/3] tpm: Hold the kref during tpm_chip_find_get

2016-02-13 Thread Jason Gunthorpe
On Sun, Feb 14, 2016 at 06:55:12AM +0200, Jarkko Sakkinen wrote:
> On Fri, Feb 12, 2016 at 05:04:29PM -0700, Jason Gunthorpe wrote:
> > This was missed during the struct device conversion, we
> > need to hold a kref on the chip to make sure it isn't freed.
> > 
> > Signed-off-by: Jason Gunthorpe 
> 
> I'm bit confused about this patch. What is the regression if this
> needs

The patch is simply totally broken, the placement of the get_device is
wrong:

> > @@ -53,6 +53,8 @@ struct tpm_chip *tpm_chip_find_get(int chip_num)
> > chip = pos;
> > break;
> > }
> > +
> > +   get_device(>dev);

It needs to be moved up two lines before the break, into the if
statement.

As for the urgency - today the tpm core relies on module locking to
try and prevent tpm_chip_unregister from racing with stuff like the
above. That is totally broken in modern kernels, but it is what the
core tries to do. Within that framework the get/put are not needed
because of the module locking.

The only time these additional get/put do anything is when we are
racing with tpm_unregister, but if we are racing with unregister then
there are much bigger problems and things will crash anyhow.

So, this patch is just a tiny step.

The revised version of this patch with the rw_sem attempts to address
the complete race.

Jason


Re: [PATCH] ARM: dts: Move syscon reboot/poweroff to common dtsi for Exynos

2016-02-13 Thread Krzysztof Kozlowski
W dniu 10.02.2016 o 03:30, Javier Martinez Canillas pisze:
> All Exynos SoCs have the same syscon reboot and poweroff device nodes so
> there is no need to duplicate the same on each SoC dtsi and can be moved
> to a common dtsi that can be included by all the SoCs dtsi files.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> Hello,
> 
> The patch was tested on an Exynos5800 Peach Pi Chromebook and an
> Exynos5422 Odroid XU4 board. Reboot and poweroff worked for both.
> 
> But testing on Exynos3 and Exynos4 will be highly appreciated.

Would you be so kind and add my suggested-by (since it comes from
https://wiki.tizen.org/wiki/Exynos_Mainline_Kernel_TODO :) )

I'll test it on Exynos4 at work and then apply... but few comments below:

> 
> Best regards,
> Javier
> 
>  arch/arm/boot/dts/exynos-syscon-restart.dtsi | 23 +++
>  arch/arm/boot/dts/exynos3250.dtsi| 15 +--
>  arch/arm/boot/dts/exynos4.dtsi   | 15 +--
>  arch/arm/boot/dts/exynos5.dtsi   | 15 +--
>  arch/arm/boot/dts/exynos5410.dtsi| 15 +--
>  5 files changed, 27 insertions(+), 56 deletions(-)
>  create mode 100644 arch/arm/boot/dts/exynos-syscon-restart.dtsi
> 
> diff --git a/arch/arm/boot/dts/exynos-syscon-restart.dtsi 
> b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
> new file mode 100644
> index ..2b8acf554881
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
> @@ -0,0 +1,23 @@
> +/*
> + * Samsung's Exynos SoC syscon reboot/poweroff nodes common definition.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/ {

In some of the DTSI this was under "soc" node, not at top-level.
Unfortunately we do not have consistency here - some DTSI have "soc",
some not. Anyway I think we should move to "soc" version.

> + poweroff: syscon-poweroff {
> + compatible = "syscon-poweroff";
> + regmap = <_system_controller>;
> + offset = <0x330C>; /* PS_HOLD_CONTROL */
> + mask = <0x5200>; /* reset value */
> + };
> +
> + reboot: syscon-reboot {
> + compatible = "syscon-reboot";
> + regmap = <_system_controller>;
> + offset = <0x0400>; /* SWRESET */
> + mask = <0x1>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 18e3deffbf48..d9c221517935 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -19,6 +19,7 @@
>  
>  #include "skeleton.dtsi"
>  #include "exynos4-cpu-thermal.dtsi"
> +#include "exynos-syscon-restart.dtsi"
>  #include 
>  
>  / {
> @@ -152,20 +153,6 @@
>   interrupt-parent = <>;
>   };
>  
> - poweroff: syscon-poweroff {
> - compatible = "syscon-poweroff";
> - regmap = <_system_controller>;
> - offset = <0x330C>; /* PS_HOLD_CONTROL */
> - mask = <0x5200>; /* Reset value */
> - };
> -
> - reboot: syscon-reboot {
> - compatible = "syscon-reboot";
> - regmap = <_system_controller>;
> - offset = <0x0400>; /* SWRESET */
> - mask = <0x1>;
> - };
> -
>   mipi_phy: video-phy@10020710 {
>   compatible = "samsung,s5pv210-mipi-video-phy";
>   #phy-cells = <1>;
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index ca621a92319e..e6f6939ccdfa 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -21,6 +21,7 @@
>  
>  #include 
>  #include 
> +#include "exynos-syscon-restart.dtsi"

Just to keep it consistent and logic - include after skeleton.

Best regards,
Krzysztof


Re: [rtc-linux] [PATCH] rtc: s3c: Document required clocks in the DT binding

2016-02-13 Thread Krzysztof Kozlowski
W dniu 10.02.2016 o 02:23, Javier Martinez Canillas pisze:
> The S3C Real Time Clock driver requires the clock and source clock to
> be defined in the device node but that requirement is not documented.

+Cc: Alessandro Zummo

No, not entirely. The samsung,s3c6410-rtc needs rtc and rtc_src clocks
but rest of compatible devices need only rtc clock.

Best regards,
Krzysztof

> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt 
> b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
> index ac2fcd6ff4b8..1068ffce9f91 100644
> --- a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
> +++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
> @@ -14,6 +14,10 @@ Required properties:
>interrupt number is the rtc alarm interrupt and second interrupt number
>is the rtc tick interrupt. The number of cells representing a interrupt
>depends on the parent interrupt controller.
> +- clocks: Must contain a list of phandle and clock specifier for the rtc
> +  and source clocks.
> +- clock-names: Must contain "rtc" and "rtc_src" entries sorted in the
> +   same order as the clocks property.
>  
>  Example:
>  
> @@ -21,4 +25,6 @@ Example:
>   compatible = "samsung,s3c6410-rtc";
>   reg = <0x1007 0x100>;
>   interrupts = <44 0 45 0>;
> + clocks = < CLK_RTC>, <_osc S2MPS11_CLK_AP>;
> + clock-names = "rtc", "rtc_src";
>   };
> 



[PATCH v8 0/5] Add Support for Hi6220 PMIC Hi6553 MFD Core

2016-02-13 Thread Chen Feng
The patch sets add support for Hi6220 PMIC Hi655x MFD core and its
regulator driver.
Current testing and support board is Hikey which is one of 96boards.
It is an arm64 open source board. For more information about this board,
please access https://www.96boards.org.

This is hardware layout for access PMIC Hi655x from AP SoC Hi6220.
Between PMIC Hi655x and Hi6220, the physical signal channel is SSI.
We can use memory-mapped I/O to communicate.

++ +-+
|| | |
|Hi6220  |   SSI bus   |   Hi655x|
||-| |
||(REGMAP_MMIO)| |
++ +-+

V2: Code refactoring of regulator.

V3: Drop mtcmos from this patch and use regmap-irq.

V4: Move the vset-table to driver code and donot open code for it.

V5: Use regulators_node and of_match, donot open code fot it.

V7: Change the constraints into hikey.dts and fix code in PMIC.

V8: Change format in document, and fix bit mask in regulator.

Chen Feng (5):
  mfd: hi655x: Add document for mfd hi665x PMIC
  regulator: hi655x: Document for hi655x regulator
  mfd: hi655x: Add MFD driver for hi655x
  regulator: hi655x: enable regulator for hi655x PMIC
  arm64: dts: hisilicon: Add hi655x pmic dts node

 .../devicetree/bindings/mfd/hisilicon,hi655x.txt   |  27 +++
 .../regulator/hisilicon,hi655x-regulator.txt   |  29 +++
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |  87 
 drivers/mfd/Kconfig|  10 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/hi655x-pmic.c  | 162 +++
 drivers/regulator/Kconfig  |   8 +
 drivers/regulator/Makefile |   1 +
 drivers/regulator/hi655x-regulator.c   | 227 +
 include/linux/mfd/hi655x-pmic.h|  55 +
 10 files changed, 607 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/hisilicon,hi655x-regulator.txt
 create mode 100644 drivers/mfd/hi655x-pmic.c
 create mode 100644 drivers/regulator/hi655x-regulator.c
 create mode 100644 include/linux/mfd/hi655x-pmic.h

-- 
1.9.1



[PATCH v8 3/5] mfd: hi655x: Add MFD driver for hi655x

2016-02-13 Thread Chen Feng
Add PMIC MFD driver to support hisilicon hi665x.

Signed-off-by: Chen Feng 
Signed-off-by: Fei Wang 
Signed-off-by: Xinwei Kong 
Reviewed-by: Haojian Zhuang 
Acked-by: Lee Jones 
---
 drivers/mfd/Kconfig |  10 +++
 drivers/mfd/Makefile|   1 +
 drivers/mfd/hi655x-pmic.c   | 162 
 include/linux/mfd/hi655x-pmic.h |  55 ++
 4 files changed, 228 insertions(+)
 create mode 100644 drivers/mfd/hi655x-pmic.c
 create mode 100644 include/linux/mfd/hi655x-pmic.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9ca66de..5b1c091 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -284,6 +284,16 @@ config MFD_HI6421_PMIC
  menus in order to enable them.
  We communicate with the Hi6421 via memory-mapped I/O.
 
+config MFD_HI655X_PMIC
+   tristate "HiSilicon Hi655X series PMU/Codec IC"
+   depends on ARCH_HISI || COMPILE_TEST
+   depends on OF
+   select MFD_CORE
+   select REGMAP_MMIO
+   select REGMAP_IRQ
+   help
+ Select this option to enable Hisilicon hi655x series pmic driver.
+
 config HTC_EGPIO
bool "HTC EGPIO support"
depends on GPIOLIB && ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 0f230a6..1e166c1 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -190,6 +190,7 @@ obj-$(CONFIG_MFD_STW481X)   += stw481x.o
 obj-$(CONFIG_MFD_IPAQ_MICRO)   += ipaq-micro.o
 obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
 obj-$(CONFIG_MFD_HI6421_PMIC)  += hi6421-pmic-core.o
+obj-$(CONFIG_MFD_HI655X_PMIC)   += hi655x-pmic.o
 obj-$(CONFIG_MFD_DLN2) += dln2.o
 obj-$(CONFIG_MFD_RT5033)   += rt5033.o
 obj-$(CONFIG_MFD_SKY81452) += sky81452.o
diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
new file mode 100644
index 000..05ddc78
--- /dev/null
+++ b/drivers/mfd/hi655x-pmic.c
@@ -0,0 +1,162 @@
+/*
+ * Device driver for MFD hi655x PMIC
+ *
+ * Copyright (c) 2016 Hisilicon.
+ *
+ * Authors:
+ * Chen Feng 
+ * Fei  Wang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct mfd_cell hi655x_pmic_devs[] = {
+   { .name = "hi655x-regulator", },
+};
+
+static const struct regmap_irq hi655x_irqs[] = {
+   { .reg_offset = 0, .mask = OTMP_D1R_INT },
+   { .reg_offset = 0, .mask = VSYS_2P5_R_INT },
+   { .reg_offset = 0, .mask = VSYS_UV_D3R_INT },
+   { .reg_offset = 0, .mask = VSYS_6P0_D200UR_INT },
+   { .reg_offset = 0, .mask = PWRON_D4SR_INT },
+   { .reg_offset = 0, .mask = PWRON_D20F_INT },
+   { .reg_offset = 0, .mask = PWRON_D20R_INT },
+   { .reg_offset = 0, .mask = RESERVE_INT },
+};
+
+static const struct regmap_irq_chip hi655x_irq_chip = {
+   .name = "hi655x-pmic",
+   .irqs = hi655x_irqs,
+   .num_regs = 1,
+   .num_irqs = ARRAY_SIZE(hi655x_irqs),
+   .status_base = HI655X_IRQ_STAT_BASE,
+   .mask_base = HI655X_IRQ_MASK_BASE,
+};
+
+static struct regmap_config hi655x_regmap_config = {
+   .reg_bits = 32,
+   .reg_stride = HI655X_STRIDE,
+   .val_bits = 8,
+   .max_register = HI655X_BUS_ADDR(0xFFF),
+};
+
+static void hi655x_local_irq_clear(struct regmap *map)
+{
+   int i;
+
+   regmap_write(map, HI655X_ANA_IRQM_BASE, HI655X_IRQ_CLR);
+   for (i = 0; i < HI655X_IRQ_ARRAY; i++) {
+   regmap_write(map, HI655X_IRQ_STAT_BASE + i * HI655X_STRIDE,
+HI655X_IRQ_CLR);
+   }
+}
+
+static int hi655x_pmic_probe(struct platform_device *pdev)
+{
+   int ret;
+   struct hi655x_pmic *pmic;
+   struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
+   void __iomem *base;
+
+   pmic = devm_kzalloc(dev, sizeof(*pmic), GFP_KERNEL);
+   if (!pmic)
+   return -ENOMEM;
+   pmic->dev = dev;
+
+   pmic->res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!pmic->res)
+   return -ENOENT;
+
+   base = devm_ioremap_resource(dev, pmic->res);
+   if (!base)
+   return -ENOMEM;
+
+   pmic->regmap = devm_regmap_init_mmio_clk(dev, NULL, base,
+_regmap_config);
+
+   regmap_read(pmic->regmap, HI655X_BUS_ADDR(HI655X_VER_REG), >ver);
+   if ((pmic->ver < PMU_VER_START) || (pmic->ver > PMU_VER_END)) {
+   dev_warn(dev, "PMU version %d unsupported\n", pmic->ver);
+   return -EINVAL;
+   }
+
+   hi655x_local_irq_clear(pmic->regmap);
+
+   pmic->gpio = of_get_named_gpio(np, "pmic-gpios", 0);
+   if (!gpio_is_valid(pmic->gpio)) {
+   dev_err(dev, "Failed to get the pmic-gpios\n");
+   return 

[PATCH v8 4/5] regulator: hi655x: enable regulator for hi655x PMIC

2016-02-13 Thread Chen Feng
Add the regulator driver for hi655x PMIC.

Signed-off-by: Chen Feng 
Signed-off-by: Fei Wang 
Signed-off-by: Xinwei Kong 
Reviewed-by: Haojian Zhuang 
---
 drivers/regulator/Kconfig|   8 ++
 drivers/regulator/Makefile   |   1 +
 drivers/regulator/hi655x-regulator.c | 227 +++
 3 files changed, 236 insertions(+)
 create mode 100644 drivers/regulator/hi655x-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 8155e80..cd8ce7e 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -261,6 +261,14 @@ config REGULATOR_HI6421
  21 general purpose LDOs, 3 dedicated LDOs, and 5 BUCKs. All
  of them come with support to either ECO (idle) or sleep mode.
 
+config REGULATOR_HI655X
+   tristate "Hisilicon HI655X PMIC regulators support"
+   depends on ARCH_HISI || COMPILE_TEST
+   depends on MFD_HI655X_PMIC && OF
+   help
+ This driver provides support for the voltage regulators of the
+ Hisilicon Hi655x PMIC device.
+
 config REGULATOR_ISL9305
tristate "Intersil ISL9305 regulator"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 980b194..422786c 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
 obj-$(CONFIG_REGULATOR_FAN53555) += fan53555.o
 obj-$(CONFIG_REGULATOR_GPIO) += gpio-regulator.o
 obj-$(CONFIG_REGULATOR_HI6421) += hi6421-regulator.o
+obj-$(CONFIG_REGULATOR_HI655X) += hi655x-regulator.o
 obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
 obj-$(CONFIG_REGULATOR_ISL9305) += isl9305.o
 obj-$(CONFIG_REGULATOR_LM363X) += lm363x-regulator.o
diff --git a/drivers/regulator/hi655x-regulator.c 
b/drivers/regulator/hi655x-regulator.c
new file mode 100644
index 000..aca1846
--- /dev/null
+++ b/drivers/regulator/hi655x-regulator.c
@@ -0,0 +1,227 @@
+/*
+ * Device driver for regulators in Hi655x IC
+ *
+ * Copyright (c) 2016 Hisilicon.
+ *
+ * Authors:
+ * Chen Feng 
+ * Fei  Wang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct hi655x_regulator {
+   unsigned int disable_reg;
+   unsigned int status_reg;
+   unsigned int ctrl_regs;
+   unsigned int ctrl_mask;
+   struct regulator_desc rdesc;
+};
+
+/* LDO7 & LDO10 */
+static const unsigned int ldo7_voltages[] = {
+   180, 185, 285, 290,
+   300, 310, 320, 330,
+};
+
+static const unsigned int ldo19_voltages[] = {
+   180, 185, 190, 175,
+   280, 285, 290, 300,
+};
+
+static const unsigned int ldo22_voltages[] = {
+90, 100, 105, 110,
+   115, 1175000, 1185000, 120,
+};
+
+enum hi655x_regulator_id {
+   HI655X_LDO0,
+   HI655X_LDO1,
+   HI655X_LDO2,
+   HI655X_LDO3,
+   HI655X_LDO4,
+   HI655X_LDO5,
+   HI655X_LDO6,
+   HI655X_LDO7,
+   HI655X_LDO8,
+   HI655X_LDO9,
+   HI655X_LDO10,
+   HI655X_LDO11,
+   HI655X_LDO12,
+   HI655X_LDO13,
+   HI655X_LDO14,
+   HI655X_LDO15,
+   HI655X_LDO16,
+   HI655X_LDO17,
+   HI655X_LDO18,
+   HI655X_LDO19,
+   HI655X_LDO20,
+   HI655X_LDO21,
+   HI655X_LDO22,
+};
+
+static int hi655x_is_enabled(struct regulator_dev *rdev)
+{
+   unsigned int value = 0;
+
+   struct hi655x_regulator *regulator = rdev_get_drvdata(rdev);
+
+   regmap_read(rdev->regmap, regulator->status_reg, );
+   return (value & BIT(regulator->ctrl_mask));
+}
+
+static int hi655x_disable(struct regulator_dev *rdev)
+{
+   int ret = 0;
+
+   struct hi655x_regulator *regulator = rdev_get_drvdata(rdev);
+
+   ret = regmap_write(rdev->regmap, regulator->disable_reg,
+  BIT(regulator->ctrl_mask));
+   return ret;
+}
+
+static struct regulator_ops hi655x_regulator_ops = {
+   .enable = regulator_enable_regmap,
+   .disable = hi655x_disable,
+   .is_enabled = hi655x_is_enabled,
+   .list_voltage = regulator_list_voltage_table,
+   .get_voltage_sel = regulator_get_voltage_sel_regmap,
+   .set_voltage_sel = regulator_set_voltage_sel_regmap,
+};
+
+static struct regulator_ops hi655x_ldo_linear_ops = {
+   .enable = regulator_enable_regmap,
+   .disable = hi655x_disable,
+   .is_enabled = hi655x_is_enabled,
+   .list_voltage = regulator_list_voltage_linear,
+   .get_voltage_sel = regulator_get_voltage_sel_regmap,
+   .set_voltage_sel = regulator_set_voltage_sel_regmap,
+};
+
+#define HI655X_LDO(_ID, vreg, vmask, ereg, dreg, \
+   

[PATCH v8 5/5] arm64: dts: hisilicon: Add hi655x pmic dts node

2016-02-13 Thread Chen Feng
Add the mfd hi655x dts node and regulator support on
hi6220 platform.

Signed-off-by: Chen Feng 
Signed-off-by: Fei Wang 
Signed-off-by: Xinwei Kong 
Reviewed-by: Haojian Zhuang 
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 87 ++
 1 file changed, 87 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 8185251..775ea36 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -6,6 +6,7 @@
  */
 
 /dts-v1/;
+#include 
 
 /*Reserved 1MB memory for MCU*/
 /memreserve/ 0x05e0 0x0010;
@@ -31,6 +32,92 @@
device_type = "memory";
reg = <0x0 0x0 0x0 0x4000>;
};
+
+   pmic: pmic@f800 {
+   compatible = "hisilicon,hi655x-pmic";
+   reg = <0x0 0xf800 0x0 0x1000>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   pmic-gpios = < 2 GPIO_ACTIVE_HIGH>;
+   status = "okay";
+
+   regulators {
+   ldo2: LDO2@a21 {
+   regulator-name = "LDO2_2V8";
+   regulator-min-microvolt = <250>;
+   regulator-max-microvolt = <320>;
+   regulator-enable-ramp-delay = <120>;
+   };
+
+   ldo7: LDO7@a26 {
+   regulator-name = "LDO7_SDIO";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-enable-ramp-delay = <120>;
+   };
+
+   ldo10: LDO10@a29 {
+   regulator-name = "LDO10_2V85";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <300>;
+   regulator-enable-ramp-delay = <360>;
+   };
+
+   ldo13: LDO13@a32 {
+   regulator-name = "LDO13_1V8";
+   regulator-min-microvolt = <160>;
+   regulator-max-microvolt = <195>;
+   regulator-enable-ramp-delay = <120>;
+   };
+
+   ldo14: LDO14@a33 {
+   regulator-name = "LDO14_2V8";
+   regulator-min-microvolt = <250>;
+   regulator-max-microvolt = <320>;
+   regulator-enable-ramp-delay = <120>;
+   };
+
+   ldo15: LDO15@a34 {
+   regulator-name = "LDO15_1V8";
+   regulator-min-microvolt = <160>;
+   regulator-max-microvolt = <195>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <120>;
+   };
+
+   ldo17: LDO17@a36 {
+   regulator-name = "LDO17_2V5";
+   regulator-min-microvolt = <250>;
+   regulator-max-microvolt = <320>;
+   regulator-enable-ramp-delay = <120>;
+   };
+
+   ldo19: LDO19@a38 {
+   regulator-name = "LDO19_3V0";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <300>;
+   regulator-enable-ramp-delay = <360>;
+   };
+
+   ldo21: LDO21@a40 {
+   regulator-name = "LDO21_1V8";
+   regulator-min-microvolt = <165>;
+   regulator-max-microvolt = <200>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <120>;
+   };
+
+   ldo22: LDO22@a41 {
+   regulator-name = "LDO22_1V2";
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <120>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <120>;
+   };
+   };
+   };
 };
 
  {
-- 
1.9.1



[PATCH v8 1/5] mfd: hi655x: Add document for mfd hi665x PMIC

2016-02-13 Thread Chen Feng
DT bindings for hisilicon hi655x MFD PMIC chip.

Signed-off-by: Chen Feng 
Signed-off-by: Fei Wang 
Signed-off-by: Xinwei Kong 
Reviewed-by: Haojian Zhuang 
---
 .../devicetree/bindings/mfd/hisilicon,hi655x.txt   | 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt

diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt 
b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
new file mode 100644
index 000..0548569
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
@@ -0,0 +1,27 @@
+Hisilicon Hi655x Power Management Integrated Circuit (PMIC)
+
+The hardware layout for access PMIC Hi655x from AP SoC Hi6220.
+Between PMIC Hi655x and Hi6220, the physical signal channel is SSI.
+We can use memory-mapped I/O to communicate.
+
+++ +-+
+|| | |
+|Hi6220  |   SSI bus   |   Hi655x|
+||-| |
+||(REGMAP_MMIO)| |
+++ +-+
+
+Required properties:
+- compatible:   Should be "hisilicon,hi655x-pmic".
+- reg:  Base address of PMIC on Hi6220 SoC.
+- interrupt-controller: Hi655x has internal IRQs (has own IRQ domain).
+- pmic-gpios:   The GPIO used by PMIC IRQ.
+
+Example:
+   pmic: pmic@f800 {
+   compatible = "hisilicon,hi655x-pmic";
+   reg = <0x0 0xf800 0x0 0x1000>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   pmic-gpios = < 2 GPIO_ACTIVE_HIGH>;
+   }
-- 
1.9.1



[PATCH v8 2/5] regulator: hi655x: Document for hi655x regulator

2016-02-13 Thread Chen Feng
This patch adds the device tree binding documentation for
hi655x PMIC regulator.

Signed-off-by: Chen Feng 
Signed-off-by: Fei Wang 
Signed-off-by: Xinwei Kong 
Reviewed-by: Haojian Zhuang 
---
 .../regulator/hisilicon,hi655x-regulator.txt   | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/hisilicon,hi655x-regulator.txt

diff --git 
a/Documentation/devicetree/bindings/regulator/hisilicon,hi655x-regulator.txt 
b/Documentation/devicetree/bindings/regulator/hisilicon,hi655x-regulator.txt
new file mode 100644
index 000..14cfdc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/hisilicon,hi655x-regulator.txt
@@ -0,0 +1,29 @@
+Hisilicon Hi655x Voltage regulators
+
+Note:
+The Hi655x regulator control is managed by Hi655x PMIC.
+So the node of this regulator must be child node of Hi655x
+PMIC node.
+
+The driver uses the regulator core framework, so please also
+take the bindings of regulator.txt for reference.
+
+The valid names for regulators are:
+
+LDO2_2V8 LDO7_SDIO LDO10_2V85 LDO13_1V8 LDO14_2V8
+LDO15_1V8 LDO17_2V5 LDO19_3V0 LDO21_1V8 LDO22_1V2
+
+Example:
+pmic: pmic@f800 {
+compatible = "hisilicon,hi655x-pmic";
+   ...
+   regulators {
+   ldo2: LDO2@a21 {
+   regulator-name = "LDO2_2V8";
+   regulator-min-microvolt = <250>;
+   regulator-max-microvolt = <320>;
+   regulator-enable-ramp-delay = <120>;
+   };
+   ...
+   }
+   }
-- 
1.9.1



Re: [PATCH] drivers: stm: correct the index in master array release

2016-02-13 Thread Chunyan Zhang
On Tue, Feb 9, 2016 at 6:12 PM, Alexander Shishkin
 wrote:
> Chunyan Zhang  writes:
>
>> It would be broken if stm_data->sw_start isn't zero, because that
>> stp_master_free() get the 'master' with __stm_master()/stm_master(),
>> in which the masterID is the second input parameter minus
>> stm_data->sw_start. So freeing STM masters has to start from
>> stm_data->sw_start.
>
> No, it won't. stm_master_free() handles nonexistent masters correctly.
> It does make sense to shrink the loop in stm_unregister_device() to
> avoid going through the [0..sw_start) range, since stm_master() returns
> NULL for those, but not for the reasons given in this patch description.

Let's assume sw_start = 64, sw_end = 79, sw_nmasters should be 16, if
the loop goes through [0..16), the existed masters will not be freed.
That's what I wanted to address in this patch. I meant the number of
loop in stm_unregister_device() is correct, but the start index isn't.
Sorry for not describing clear enough in the patch logs.

Thanks,
Chunyan

>
> Regards,
> --
> Alex


[lkp] [mm/vmpressure.c] 3c1da7beee: No primary result change, 278.5% vm-scalability.time.involuntary_context_switches

2016-02-13 Thread kernel test robot
FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 3c1da7b02560cd0f0c66c5a59fce3c6746e3 ("mm/vmpressure.c: fix subtree 
pressure detection")


=
compiler/cpufreq_governor/kconfig/rootfs/runtime/tbox_group/test/testcase:
  
gcc-4.9/performance/x86_64-rhel/debian-x86_64-2015-02-07.cgz/300s/ivb43/lru-file-mmap-read/vm-scalability

commit: 
  30bdbb78009e67767983085e302bec6d97afc679
  3c1da7b02560cd0f0c66c5a59fce3c6746e3

30bdbb78009e6776 3c1da7b02560cd0f0c66c5 
 -- 
 %stddev %change %stddev
 \  |\  
193661 ±  1%+278.5% 733007 ±  1%  
vm-scalability.time.involuntary_context_switches
906499 ±  2% +18.1%1070404 ±  1%  softirqs.RCU
193661 ±  1%+278.5% 733007 ±  1%  time.involuntary_context_switches
  4216 ±  3% +86.5%   7863 ±  1%  vmstat.system.cs
  0.74 ± 85% -80.1%   0.15 ±113%  
perf-profile.cycles-pp.__alloc_pages_nodemask.alloc_pages_current.__page_cache_alloc.__do_page_cache_readahead.filemap_fault
  0.74 ± 85% -80.1%   0.15 ±113%  
perf-profile.cycles-pp.__page_cache_alloc.__do_page_cache_readahead.filemap_fault.xfs_filemap_fault.__do_fault
  0.74 ± 85% -80.1%   0.15 ±113%  
perf-profile.cycles-pp.alloc_pages_current.__page_cache_alloc.__do_page_cache_readahead.filemap_fault.xfs_filemap_fault
  1378 ±  5%  -9.8%   1242 ±  9%  
slabinfo.file_lock_cache.active_objs
  1378 ±  5%  -9.8%   1242 ±  9%  slabinfo.file_lock_cache.num_objs
 14388 ±  3%  -7.8%  13262 ±  7%  slabinfo.kmalloc-512.num_objs
 16441 ± 75%-100.0%   0.00 ± -1%  
latency_stats.avg.down.console_lock.do_con_write.con_write.n_tty_write.tty_write.redirected_tty_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
 15932 ± 45%+233.0%  53047 ± 43%  
latency_stats.avg.pipe_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
 16991 ± 74%-100.0%   0.00 ± -1%  
latency_stats.max.down.console_lock.do_con_write.con_write.n_tty_write.tty_write.redirected_tty_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
189128 ± 86% -72.1%  52770 ± 63%  
latency_stats.max.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
 36438 ± 58%+417.4% 188546 ±112%  
latency_stats.max.pipe_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
  7680 ±102% -90.3% 741.25 ± 17%  
latency_stats.max.rpc_wait_bit_killable.__rpc_wait_for_completion_task.nfs4_run_open_task.[nfsv4]._nfs4_open_and_get_state.[nfsv4].nfs4_do_open.[nfsv4].nfs4_atomic_open.[nfsv4].nfs4_file_open.[nfsv4].do_dentry_open.vfs_open.path_openat.do_filp_open.do_sys_open
  0.00 ± -1%  +Inf%  20319 ±100%  
latency_stats.sum.call_rwsem_down_read_failed.page_lock_anon_vma_read.rmap_walk.try_to_unmap.migrate_pages.migrate_misplaced_page.handle_mm_fault.__do_page_fault.do_page_fault.page_fault
  0.00 ± -1%  +Inf%  20492 ± 98%  
latency_stats.sum.call_rwsem_down_read_failed.rmap_walk.remove_migration_ptes.migrate_pages.migrate_misplaced_page.handle_mm_fault.__do_page_fault.do_page_fault.page_fault
 22837 ± 72%-100.0%   0.00 ± -1%  
latency_stats.sum.down.console_lock.do_con_write.con_write.n_tty_write.tty_write.redirected_tty_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
  0.00 ± -1%  +Inf%   5388 ±106%  
latency_stats.sum.wait_on_page_bit.__migration_entry_wait.migration_entry_wait.do_swap_page.handle_mm_fault.__do_page_fault.do_page_fault.page_fault
 17.00 ± 10% +30.9%  22.25 ± 27%  sched_debug.cfs_rq:/.load.18
 18.00 ± 11% +56.9%  28.25 ± 24%  sched_debug.cfs_rq:/.load_avg.13
 15.50 ±  9% +88.7%  29.25 ± 32%  sched_debug.cfs_rq:/.load_avg.44
  2.00 ±-50% +25.0%   2.50 ± 66%  
sched_debug.cfs_rq:/.nr_spread_over.13
  2.50 ±100%+690.0%  19.75 ±100%  
sched_debug.cfs_rq:/.nr_spread_over.7
 98.25 ± 82% -83.5%  16.25 ±  2%  
sched_debug.cfs_rq:/.runnable_load_avg.35
  7118 ±387%+637.5%  52502 ± 57%  sched_debug.cfs_rq:/.spread0.16
   -275108 ±-167%-132.9%  90504 ± 43%  sched_debug.cfs_rq:/.spread0.27
   -524687 ±-161%-118.7%  98148 ± 49%  sched_debug.cfs_rq:/.spread0.35
 46300 ± 50% +97.7%  91531 ± 40%  sched_debug.cfs_rq:/.spread0.39
 72286 ± 17% +51.4% 109469 ± 21%  sched_debug.cfs_rq:/.spread0.40
913.75 ±  6%  -7.6% 844.00 ±  0%  sched_debug.cfs_rq:/.util_avg.0
 19.75 ±  9% -17.7%  16.25 ±  2%  sched_debug.cpu.cpu_load[0].0
 98.25 ± 82% -83.7%  16.00 ±  0%  sched_debug.cpu.cpu_load[0].35
 19.75 ±  9% -16.5%  16.50 ±  3%  sched_debug.cpu.cpu_load[1].0
 98.25 ± 82% -83.7%   

[lkp] [usb] 2203f6a892: !!! IP-Config: Auto-configuration of network failed !!!

2016-02-13 Thread kernel test robot
FYI, we noticed the below changes on

https://github.com/0day-ci/linux 
Robert-Baldyga/usb-gadget-composite-introduce-new-function-API/20160203-205850
commit 2203f6a8922a447a364b12ec60b0fe4d7b15a4f9 ("usb: gadget: f_acm: 
conversion to new API")


[5.782015] usb 1-1: config 2 has an invalid interface number: 0 but max is 
-1
[5.782015] usb 1-1: config 2 has an invalid interface number: 0 but max is 
-1
[5.782018] usb 1-1: config 2 has an invalid interface number: 0 but max is 
-1
[5.782018] usb 1-1: config 2 has an invalid interface number: 0 but max is 
-1
[5.782020] usb 1-1: config 2 has 1 interface, different from the 
descriptor's value: 0
[5.782020] usb 1-1: config 2 has 1 interface, different from the 
descriptor's value: 0
[5.782023] usb 1-1: config 2 interface 0 altsetting 0 has an invalid 
endpoint with address 0x80, skipping
[5.782023] usb 1-1: config 2 interface 0 altsetting 0 has an invalid 
endpoint with address 0x80, skipping
[5.782025] usb 1-1: Duplicate descriptor for config 2 interface 0 
altsetting 0, skipping
[5.782025] usb 1-1: Duplicate descriptor for config 2 interface 0 
altsetting 0, skipping


Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.5.0-rc2 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_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_CONSTRUCTORS=y
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 is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=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_IRQ_DOMAIN_DEBUG is not set
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 is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
CONFIG_RCU_KTHREAD_PRIO=0
CONFIG_RCU_NOCB_CPU=y
# CONFIG_RCU_NOCB_CPU_NONE is not set
# CONFIG_RCU_NOCB_CPU_ZERO is not set
CONFIG_RCU_NOCB_CPU_ALL=y
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set

Re: [PATCH 3/5] irqchip: add platform device driver for mbigen device

2016-02-13 Thread kbuild test robot
Hi Ma,

[auto build test ERROR on tip/irq/core]
[also build test ERROR on v4.5-rc3 next-20160212]
[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/MaJun/irqchip-Add-support-for-Hisilicon-mbigen-v1-chip/20160214-101957
config: arm64-defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

Note: the 
linux-review/MaJun/irqchip-Add-support-for-Hisilicon-mbigen-v1-chip/20160214-101957
 HEAD 9acb433456cd9671c97c0eeb1ccca8cc3b986081 builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   drivers/irqchip/irq-mbigen-v1.c: In function 'mbigen_device_probe':
>> drivers/irqchip/irq-mbigen-v1.c:47:2: error: implicit declaration of 
>> function 'devm_ioremap' [-Werror=implicit-function-declaration]
 mgn_chip->base = devm_ioremap(>dev, res->start, resource_size(res));
 ^
>> drivers/irqchip/irq-mbigen-v1.c:47:17: warning: assignment makes pointer 
>> from integer without a cast
 mgn_chip->base = devm_ioremap(>dev, res->start, resource_size(res));
^
   cc1: some warnings being treated as errors

vim +/devm_ioremap +47 drivers/irqchip/irq-mbigen-v1.c

41  if (!mgn_chip)
42  return -ENOMEM;
43  
44  mgn_chip->pdev = pdev;
45  
46  res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
  > 47  mgn_chip->base = devm_ioremap(>dev, res->start, 
resource_size(res));
48  if (IS_ERR(mgn_chip->base))
49  return PTR_ERR(mgn_chip->base);
50  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


[next] Odroid XU3 easily over-heats

2016-02-13 Thread Krzysztof Kozlowski
Hi all,

With recent addition of cpufreq-dt support to Exynos5422
it is very easy to over-heat the Odroid XU3 leading to critical shutdown:
[  132.622032] thermal thermal_zone3: critical temperature reached(121 
C),shutting down


Reproduction:
0. next-20160212 (with recent fix for OPP from Viresh)
1. multi_v7 (on exynos defconfig there is no cpufreq for Exynos5422)
2. Run following test script:
https://github.com/krzk/tools/blob/master/tests/odroid-xu3-cpu-mmc-stress.sh

(the script essentially does only "cat /dev/mmcblk0p2 | gzip -c > /dev/null" 
for each CPU)

Observe, just before shutdown:
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:130
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:20
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:154000
/sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0 1 2 3
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:20 
30 40 50 60 70 80 90 100 110 120 
130 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:ondemand 
performance 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:130
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:cpufreq-dt
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:130
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:20
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:

/sys/class/thermal/thermal_zone0/temp:9
/sys/class/thermal/thermal_zone1/temp:98000
/sys/class/thermal/thermal_zone2/temp:113000
/sys/class/thermal/thermal_zone3/temp:119000
/sys/class/thermal/thermal_zone4/temp:81000

/sys/class/thermal/cooling_device0/cur_state:3
/sys/class/thermal/cooling_device0/max_state:3
/sys/class/thermal/cooling_device0/type:pwm-fan

Fan is working but shutdown is immediate.

What about cpufreq as cooling device? Probably that part
is missing now, right?

Best regards,
Krzysztof


Re: [tpmdd-devel] [GIT PULL] tpmdd fixes for Linux 4.5 (updated)

2016-02-13 Thread Jarkko Sakkinen
On Wed, Feb 10, 2016 at 05:48:04AM +0200, Jarkko Sakkinen wrote:
> Hi James,
> 
> As we discussed I'm sending now a revised pull request with a couple
> of new fixes to the one that I sent with the tag:
> 
>   tags/tpmdd-next-20160120

Forgot to say that these are for -rc4 (rebased on top of security/next,
which was -rc3).

/Jarkko

> /Jarkko
> 
> The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95:
> 
>   Linux 4.5-rc3 (2016-02-07 15:38:30 -0800)
> 
> are available in the git repository at:
> 
>   https://github.com/jsakkine/linux-tpmdd.git tags/tpmdd-next-20160210
> 
> for you to fetch changes up to 8e0ee3c9faed7ca68807ea45141775856c438ac0:
> 
>   tpm: fix the cleanup of struct tpm_chip (2016-02-10 04:12:08 +0200)
> 
> 
> tpmdd fixes for Linux 4.5 (updated)
> 
> 
> Jarkko Sakkinen (3):
>   tpm: fix checks for policy digest existence in tpm2_seal_trusted()
>   tpm: fix the rollback in tpm_chip_register()
>   tpm: fix the cleanup of struct tpm_chip
> 
> Jason Gunthorpe (7):
>   tpm_crb: Use the common ACPI definition of struct acpi_tpm2
>   tpm_tis: Disable interrupt auto probing on a per-device basis
>   tpm_tis: Do not fall back to a hardcoded address for TPM2
>   tpm_tis: Use devm_ioremap_resource
>   tpm_tis: Clean up the force=1 module parameter
>   tpm_crb: Drop le32_to_cpu(ioread32(..))
>   tpm_crb: Use devm_ioremap_resource
> 
> Jerry Snitselaar (1):
>   tpm: remove unneeded include of actbl2.h
> 
>  drivers/char/tpm/tpm-chip.c |  14 +--
>  drivers/char/tpm/tpm.h  |   7 --
>  drivers/char/tpm/tpm2-cmd.c |  12 +--
>  drivers/char/tpm/tpm_crb.c  | 190 -
>  drivers/char/tpm/tpm_tis.c  | 255 
> +---
>  include/keys/trusted-type.h |   2 +-
>  security/keys/trusted.c |  11 +-
>  7 files changed, 276 insertions(+), 215 deletions(-)
> 
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> tpmdd-devel mailing list
> tpmdd-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel


Re: [next] Odroid XU3 boot fail after cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequency

2016-02-13 Thread Krzysztof Kozlowski
W dniu 14.02.2016 o 14:22, Viresh Kumar pisze:
> On 14-02-16, 13:56, Krzysztof Kozlowski wrote:
>> Hi all,
>>
>> Recently Odroid XU3 failed to boot on linux-next
>> on multi_v7 defconfig. exynos defconfig boots fine.
>>
>> Probably the "cpufreq: dt: Use dev_pm_opp_set_rate() to
>> switch frequency" is important here:
>> commit 78c3ba5df96c875b1668e1cd3ee0a69e62454f32
>> Author: Viresh Kumar 
>> Date:   Tue Feb 9 10:30:46 2016 +0530
>>
>> cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequency
>> 
>> OPP core supports frequency/voltage changes based on the target
>> frequency now, use that instead of open coding the same in cpufreq-dt
>> driver.
>> 
>> Signed-off-by: Viresh Kumar 
>> Reviewed-by: Stephen Boyd 
>> Signed-off-by: Rafael J. Wysocki 
> 
> Can you please try the below untested patch please ?

Thanks for quick reply. The patch fixed the problem.

Tested-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

> diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
> index d7cd4e265766..a97b333036c9 100644
> --- a/drivers/base/power/opp/core.c
> +++ b/drivers/base/power/opp/core.c
> @@ -1156,9 +1156,15 @@ static int opp_parse_supplies(struct dev_pm_opp *opp, 
> struct device *dev,
>   return -EINVAL;
>   }
>  
> - opp->u_volt = microvolt[0];
> - opp->u_volt_min = microvolt[1];
> - opp->u_volt_max = microvolt[2];
> + if (count == 1) {
> + opp->u_volt = microvolt[0];
> + opp->u_volt_min = opp->u_volt;
> + opp->u_volt_max = opp->u_volt;
> + } else {
> + opp->u_volt = microvolt[0];
> + opp->u_volt_min = microvolt[1];
> + opp->u_volt_max = microvolt[2];
> + }
>  
>   /* Search for "opp-microamp-" */
>   prop = NULL;
> 



Re: [V3] powerpc/mm: Fix Multi hit ERAT cause by recent THP update

2016-02-13 Thread Aneesh Kumar K.V
Michael Ellerman  writes:

> On Tue, 2016-09-02 at 01:20:31 UTC, "Aneesh Kumar K.V" wrote:
>> With ppc64 we use the deposited pgtable_t to store the hash pte slot
>> information. We should not withdraw the deposited pgtable_t without
>> marking the pmd none. This ensure that low level hash fault handling
>> will skip this huge pte and we will handle them at upper levels.
>> 
>> Recent change to pmd splitting changed the above in order to handle the
>> race between pmd split and exit_mmap. The race is explained below.
>> 
>> Consider following race:
>> 
>>  CPU0CPU1
>> shrink_page_list()
>>   add_to_swap()
>> split_huge_page_to_list()
>>   __split_huge_pmd_locked()
>> pmdp_huge_clear_flush_notify()
>>  // pmd_none() == true
>>  exit_mmap()
>>unmap_vmas()
>>  zap_pmd_range()
>>// no action on pmd since 
>> pmd_none() == true
>>  pmd_populate()
>> 
>> As result the THP will not be freed. The leak is detected by check_mm():
>> 
>>  BUG: Bad rss-counter state mm:880058d2e580 idx:1 val:512
>> 
>> The above required us to not mark pmd none during a pmd split.
>> 
>> The fix for ppc is to clear the huge pte of _PAGE_USER, so that low
>> level fault handling code skip this pte. At higher level we do take ptl
>> lock. That should serialze us against the pmd split. Once the lock is
>> acquired we do check the pmd again using pmd_same. That should always
>> return false for us and hence we should retry the access. We do the
>> pmd_same check in all case after taking plt with
>> THP (do_huge_pmd_wp_page, do_huge_pmd_numa_page and
>> huge_pmd_set_accessed)
>> 
>> Also make sure we wait for irq disable section in other cpus to finish
>> before flipping a huge pte entry with a regular pmd entry. Code paths
>> like find_linux_pte_or_hugepte depend on irq disable to get
>> a stable pte_t pointer. A parallel thp split need to make sure we
>> don't convert a pmd pte to a regular pmd entry without waiting for the
>> irq disable section to finish.
>> 
>> Acked-by: Kirill A. Shutemov 
>> Signed-off-by: Aneesh Kumar K.V 
>
> Applied to powerpc fixes, thanks.
>
> https://git.kernel.org/powerpc/c/9db4cd6c21535a4846b38808f3
>

Can we apply the below hunk ?. The reason for marking pmd none was to
avoid clearing both _PAGE_USER and _PAGE_PRESENT on the pte. At pmd
level that used to mean a hugepd pointer before. We did fix that earlier
by introducing _PAGE_PTE. But then I was thinking it was harmless to
mark pmd none. Now marking it one will still result in the race I
explained above, eventhough the window is much smaller now.

diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index c8a00da39969..03f6e72697d0 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -694,7 +694,7 @@ void set_pmd_at(struct mm_struct *mm, unsigned long addr,
 void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
 pmd_t *pmdp)
 {
-   pmd_hugepage_update(vma->vm_mm, address, pmdp, ~0UL, 0);
+   pmd_hugepage_update(vma->vm_mm, address, pmdp, _PAGE_PRESENT, 0);
/*
 * This ensures that generic code that rely on IRQ disabling
 * to prevent a parallel THP split work as expected.



RE: [PATCH V6 0/8] introduce Hyper-V VM Socket(hv_sock)

2016-02-13 Thread Dexuan Cui
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf
> Of Dexuan Cui
> Sent: Tuesday, January 26, 2016 17:40
> ...
> Dexuan Cui (8):
>   Drivers: hv: vmbus: add a helper function to set a channel's pending
> send size
>   Drivers: hv: vmbus: define the new offer type for Hyper-V socket
> (hvsock)
>   Drivers: hv: vmbus: vmbus_sendpacket_ctl: hvsock: avoid unnecessary
> signaling
>   Drivers: hv: vmbus: define a new VMBus message type for hvsock
>   Drivers: hv: vmbus: add a hvsock flag in struct hv_driver
>   Drivers: hv: vmbus: add a per-channel rescind callback
>   Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister()
>   hvsock: introduce Hyper-V Socket feature

Hi David,
Greg has accepted all my VMBus driver side's patches.
I'm going to post the net/hv_sock/ patch now.

I know I should rebase my patch to the net-next tree, but net-next hasn't
contained my VMBus driver side's patches, which are a prerequisite of my
net/hv_sock/ patch.

It looks I have to wait before you merge net-next with Greg's tree, or
with the mainline (after Greg pushes the changes to the mainline)?
If so, may I know when the next merge will be happening (so I don't need
to check net-next every day :-) ) ?

Thanks,
-- Dexuan


Re: [PATCH 2/3] tpm: Get rid of chip->pdev

2016-02-13 Thread Jarkko Sakkinen
On Fri, Feb 12, 2016 at 08:33:20PM -0700, Jason Gunthorpe wrote:
> On Fri, Feb 12, 2016 at 08:31:21PM -0500, Stefan Berger wrote:
> > > I'll send you something else that might work for vtpm...'
> > 
> > The vtpm driver will introduce chip->priv, which will point to vtpm_dev. For
> > this reason we need to hold a reference to the vtpm_dev->dev in the
> > front end.
> 
> This should take care of it for all drivers including vtpm.
> 
> https://github.com/jgunthorpe/linux/commits/for-jarkko
> 
> At the very least this turns silent use after free into a null pointer
> oops.
> 
> We should also discuss if we want to continue to have the driver
> module locked while /dev/tpmX is open, that is no longer needed for
> corectness.

I'm happy the patch that was sent before although I didn't give it
Reviewed-by because it had couple of style errors. If those two
style errors are the *only* issues I can fix up them.

Unless the differences are trivial (like a missing return value or
couple of minor style errors something very obvious) for me to fixup I'd
hope to re-review the code.

I'm not trying to be difficult here. For small errors I can amend
the commits but it seems that there was something more non-trival
done

Other than the first patch (for which I'm still waiting a clear
explanation why it is wrong), these are not going to 4.5 anyway so
there's lots time to things the long way.

/Jarkko


Re: [next] Odroid XU3 boot fail after cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequency

2016-02-13 Thread Viresh Kumar
On 14-02-16, 13:56, Krzysztof Kozlowski wrote:
> Hi all,
> 
> Recently Odroid XU3 failed to boot on linux-next
> on multi_v7 defconfig. exynos defconfig boots fine.
> 
> Probably the "cpufreq: dt: Use dev_pm_opp_set_rate() to
> switch frequency" is important here:
> commit 78c3ba5df96c875b1668e1cd3ee0a69e62454f32
> Author: Viresh Kumar 
> Date:   Tue Feb 9 10:30:46 2016 +0530
> 
> cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequency
> 
> OPP core supports frequency/voltage changes based on the target
> frequency now, use that instead of open coding the same in cpufreq-dt
> driver.
> 
> Signed-off-by: Viresh Kumar 
> Reviewed-by: Stephen Boyd 
> Signed-off-by: Rafael J. Wysocki 

Can you please try the below untested patch please ?

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index d7cd4e265766..a97b333036c9 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -1156,9 +1156,15 @@ static int opp_parse_supplies(struct dev_pm_opp *opp, 
struct device *dev,
return -EINVAL;
}
 
-   opp->u_volt = microvolt[0];
-   opp->u_volt_min = microvolt[1];
-   opp->u_volt_max = microvolt[2];
+   if (count == 1) {
+   opp->u_volt = microvolt[0];
+   opp->u_volt_min = opp->u_volt;
+   opp->u_volt_max = opp->u_volt;
+   } else {
+   opp->u_volt = microvolt[0];
+   opp->u_volt_min = microvolt[1];
+   opp->u_volt_max = microvolt[2];
+   }
 
/* Search for "opp-microamp-" */
prop = NULL;

-- 
viresh


Re: [PATCH 3/3] tpm: Get rid of devname

2016-02-13 Thread Jarkko Sakkinen
On Fri, Feb 12, 2016 at 05:04:31PM -0700, Jason Gunthorpe wrote:
> Now that we have a proper struct device just use dev_name() to
> access this value instead of keeping two copies.
> 
> Signed-off-by: Jason Gunthorpe 

Reviewed-by: Jarkko Sakkinen 

/Jarkko

> ---
>  drivers/char/tpm/tpm-chip.c| 17 +++--
>  drivers/char/tpm/tpm.h |  1 -
>  drivers/char/tpm/tpm_eventlog.c|  2 +-
>  drivers/char/tpm/tpm_eventlog.h|  2 +-
>  drivers/char/tpm/tpm_i2c_nuvoton.c |  2 +-
>  drivers/char/tpm/tpm_tis.c |  2 +-
>  6 files changed, 15 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index b1364bf62492..caa52a6110ec 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -90,6 +90,7 @@ struct tpm_chip *tpmm_chip_alloc(struct device *dev,
>const struct tpm_class_ops *ops)
>  {
>   struct tpm_chip *chip;
> + int err;
>  
>   chip = kzalloc(sizeof(*chip), GFP_KERNEL);
>   if (chip == NULL)
> @@ -112,8 +113,6 @@ struct tpm_chip *tpmm_chip_alloc(struct device *dev,
>  
>   set_bit(chip->dev_num, dev_mask);
>  
> - scnprintf(chip->devname, sizeof(chip->devname), "tpm%d", chip->dev_num);
> -
>   dev_set_drvdata(dev, chip);
>  
>   chip->dev.class = tpm_class;
> @@ -128,7 +127,9 @@ struct tpm_chip *tpmm_chip_alloc(struct device *dev,
>   else
>   chip->dev.devt = MKDEV(MAJOR(tpm_devt), chip->dev_num);
>  
> - dev_set_name(>dev, "%s", chip->devname);
> + err = dev_set_name(>dev, "tpm%d", chip->dev_num);
> + if (err)
> + goto out;
>  
>   device_initialize(>dev);
>  
> @@ -137,6 +138,10 @@ struct tpm_chip *tpmm_chip_alloc(struct device *dev,
>   chip->cdev.kobj.parent = >dev.kobj;
>  
>   return chip;
> +
> +out:
> + put_device(>dev);
> + return ERR_PTR(err);
>  }
>  EXPORT_SYMBOL_GPL(tpmm_chip_alloc);
>  
> @@ -148,7 +153,7 @@ static int tpm_dev_add_device(struct tpm_chip *chip)
>   if (rc) {
>   dev_err(>dev,
>   "unable to cdev_add() %s, major %d, minor %d, err=%d\n",
> - chip->devname, MAJOR(chip->dev.devt),
> + dev_name(>dev), MAJOR(chip->dev.devt),
>   MINOR(chip->dev.devt), rc);
>  
>   device_unregister(>dev);
> @@ -159,7 +164,7 @@ static int tpm_dev_add_device(struct tpm_chip *chip)
>   if (rc) {
>   dev_err(>dev,
>   "unable to device_register() %s, major %d, minor %d, 
> err=%d\n",
> - chip->devname, MAJOR(chip->dev.devt),
> + dev_name(>dev), MAJOR(chip->dev.devt),
>   MINOR(chip->dev.devt), rc);
>  
>   return rc;
> @@ -185,7 +190,7 @@ static int tpm1_chip_register(struct tpm_chip *chip)
>   if (rc)
>   return rc;
>  
> - chip->bios_dir = tpm_bios_log_setup(chip->devname);
> + chip->bios_dir = tpm_bios_log_setup(dev_name(>dev));
>  
>   return 0;
>  }
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 371f75f4d2a7..a53fc699027b 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -181,7 +181,6 @@ struct tpm_chip {
>   unsigned int flags;
>  
>   int dev_num;/* /dev/tpm# */
> - char devname[7];
>   unsigned long is_open;  /* only one allowed */
>   int time_expired;
>  
> diff --git a/drivers/char/tpm/tpm_eventlog.c b/drivers/char/tpm/tpm_eventlog.c
> index bd72fb04225e..49e50976efc8 100644
> --- a/drivers/char/tpm/tpm_eventlog.c
> +++ b/drivers/char/tpm/tpm_eventlog.c
> @@ -397,7 +397,7 @@ static int is_bad(void *p)
>   return 0;
>  }
>  
> -struct dentry **tpm_bios_log_setup(char *name)
> +struct dentry **tpm_bios_log_setup(const char *name)
>  {
>   struct dentry **ret = NULL, *tpm_dir, *bin_file, *ascii_file;
>  
> diff --git a/drivers/char/tpm/tpm_eventlog.h b/drivers/char/tpm/tpm_eventlog.h
> index 267bfbd1b7bb..f072a1a1d5cc 100644
> --- a/drivers/char/tpm/tpm_eventlog.h
> +++ b/drivers/char/tpm/tpm_eventlog.h
> @@ -77,7 +77,7 @@ int read_log(struct tpm_bios_log *log);
>  
>  #if defined(CONFIG_TCG_IBMVTPM) || defined(CONFIG_TCG_IBMVTPM_MODULE) || \
>   defined(CONFIG_ACPI)
> -extern struct dentry **tpm_bios_log_setup(char *);
> +extern struct dentry **tpm_bios_log_setup(const char *name);
>  extern void tpm_bios_log_teardown(struct dentry **);
>  #else
>  static inline struct dentry **tpm_bios_log_setup(char *name)
> diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c 
> b/drivers/char/tpm/tpm_i2c_nuvoton.c
> index 8fb378f502e4..6dd74d114fb3 100644
> --- a/drivers/char/tpm/tpm_i2c_nuvoton.c
> +++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
> @@ -560,7 +560,7 @@ static int i2c_nuvoton_probe(struct i2c_client *client,
>   rc = devm_request_irq(dev, chip->vendor.irq,
> i2c_nuvoton_int_handler,
>

Re: [PATCH 2/3] tpm: Get rid of chip->pdev

2016-02-13 Thread Jarkko Sakkinen
On Fri, Feb 12, 2016 at 05:04:30PM -0700, Jason Gunthorpe wrote:
> This is a hold over from before the struct device conversion.
> 
> - All prints should be using >dev, which is the Linux
>   standard. This changes prints to use tpm0 as the device name,
>   not the PnP/etc ID.
> - The few places involving sysfs/modules that really do need the
>   parent just use chip->dev.parent instead
> - We no longer need to get_device(pdev) in any places since it is no
>   longer used by any of the code. The kref on the parent is held
>   by the device core during device_add and dropped in device_del

The change makes obviously sense but is too big infrastructure change
for 4.5.

I've now managed to find time to quickly try out quickly Stefans code
and got an impression how it works and understand his concerns.

I would still merge this and would not mix addressing those concerns
to this patch review since vTPM is still in RFC phase.

> Signed-off-by: Jason Gunthorpe 
> ---
>  drivers/char/tpm/tpm-chip.c | 15 ++-
>  drivers/char/tpm/tpm-dev.c  |  4 +---
>  drivers/char/tpm/tpm-interface.c| 30 --
>  drivers/char/tpm/tpm-sysfs.c|  6 +++---
>  drivers/char/tpm/tpm.h  |  3 +--
>  drivers/char/tpm/tpm2-cmd.c |  8 
>  drivers/char/tpm/tpm_atmel.c| 14 +++---
>  drivers/char/tpm/tpm_i2c_atmel.c| 16 
>  drivers/char/tpm/tpm_i2c_infineon.c |  6 +++---
>  drivers/char/tpm/tpm_i2c_nuvoton.c  | 26 +-
>  drivers/char/tpm/tpm_infineon.c | 22 +++---
>  drivers/char/tpm/tpm_nsc.c  | 20 ++--
>  drivers/char/tpm/tpm_tis.c  | 16 
>  13 files changed, 91 insertions(+), 95 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index ae2fed8a162b..b1364bf62492 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -49,7 +49,7 @@ struct tpm_chip *tpm_chip_find_get(int chip_num)
>   if (chip_num != TPM_ANY_NUM && chip_num != pos->dev_num)
>   continue;
>  
> - if (try_module_get(pos->pdev->driver->owner)) {
> + if (try_module_get(pos->dev.parent->driver->owner)) {
>   chip = pos;
>   break;
>   }
> @@ -114,13 +114,11 @@ struct tpm_chip *tpmm_chip_alloc(struct device *dev,
>  
>   scnprintf(chip->devname, sizeof(chip->devname), "tpm%d", chip->dev_num);
>  
> - chip->pdev = dev;
> -
>   dev_set_drvdata(dev, chip);
>  
>   chip->dev.class = tpm_class;
>   chip->dev.release = tpm_dev_release;
> - chip->dev.parent = chip->pdev;
> + chip->dev.parent = dev;
>  #ifdef CONFIG_ACPI
>   chip->dev.groups = chip->groups;
>  #endif
> @@ -135,7 +133,7 @@ struct tpm_chip *tpmm_chip_alloc(struct device *dev,
>   device_initialize(>dev);
>  
>   cdev_init(>cdev, _fops);
> - chip->cdev.owner = chip->pdev->driver->owner;
> + chip->cdev.owner = dev->driver->owner;
>   chip->cdev.kobj.parent = >dev.kobj;
>  
>   return chip;
> @@ -236,9 +234,8 @@ int tpm_chip_register(struct tpm_chip *chip)
>   chip->flags |= TPM_CHIP_FLAG_REGISTERED;
>  
>   if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
> - rc = __compat_only_sysfs_link_entry_to_kobj(>pdev->kobj,
> - >dev.kobj,
> - "ppi");
> + rc = __compat_only_sysfs_link_entry_to_kobj(
> + >dev.parent->kobj, >dev.kobj, "ppi");

Did you run this through checkpatch.pl?

>   if (rc && rc != -ENOENT) {
>   tpm_chip_unregister(chip);
>   return rc;
> @@ -273,7 +270,7 @@ void tpm_chip_unregister(struct tpm_chip *chip)
>   synchronize_rcu();
>  
>   if (!(chip->flags & TPM_CHIP_FLAG_TPM2))
> - sysfs_remove_link(>pdev->kobj, "ppi");
> + sysfs_remove_link(>dev.parent->kobj, "ppi");
>  
>   tpm1_chip_unregister(chip);
>   tpm_dev_del_device(chip);
> diff --git a/drivers/char/tpm/tpm-dev.c b/drivers/char/tpm/tpm-dev.c
> index de0337ebd658..4009765c14fd 100644
> --- a/drivers/char/tpm/tpm-dev.c
> +++ b/drivers/char/tpm/tpm-dev.c
> @@ -61,7 +61,7 @@ static int tpm_open(struct inode *inode, struct file *file)
>* by the check of is_open variable, which is protected
>* by driver_lock. */
>   if (test_and_set_bit(0, >is_open)) {
> - dev_dbg(chip->pdev, "Another process owns this TPM\n");
> + dev_dbg(>dev, "Another process owns this TPM\n");
>   return -EBUSY;
>   }
>  
> @@ -79,7 +79,6 @@ static int tpm_open(struct inode *inode, struct file *file)
>   INIT_WORK(>work, timeout_work);
>  
>   file->private_data = priv;
> - get_device(chip->pdev);
>   return 0;
>  }
>  
> @@ -166,7 

Re: [PATCH v2] x86/kernel: use pr_() and dev_

2016-02-13 Thread kbuild test robot
Hi Chen,

[auto build test WARNING on tip/x86/core]
[also build test WARNING on v4.5-rc3 next-20160212]
[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/Chen-Yucong/x86-kernel-use-pr_-level-and-dev_-level/20160214-121236
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> arch/x86/pci/mmconfig_64.c:16:0: warning: "pr_fmt" redefined
#define pr_fmt(fmt) "PCI: " fmt
^
   In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/pci.h:25,
from arch/x86/pci/mmconfig_64.c:8:
   include/linux/printk.h:236:0: note: this is the location of the previous 
definition
#define pr_fmt(fmt) fmt
^

vim +/pr_fmt +16 arch/x86/pci/mmconfig_64.c

 1  /*
 2   * mmconfig.c - Low-level direct PCI config space access via MMCONFIG
 3   *
 4   * This is an 64bit optimized version that always keeps the full 
mmconfig
 5   * space mapped. This allows lockless config space operation.
 6   */
 7  
 8  #include 
 9  #include 
10  #include 
11  #include 
12  #include 
13  #include 
14  #include 
15  
  > 16  #define pr_fmt(fmt) "PCI: " fmt
17  
18  static char __iomem *pci_dev_base(unsigned int seg, unsigned int bus, 
unsigned int devfn)
19  {
20  struct pci_mmcfg_region *cfg = pci_mmconfig_lookup(seg, bus);
21  
22  if (cfg && cfg->virt)
23  return cfg->virt + (PCI_MMCFG_BUS_OFFSET(bus) | (devfn 
<< 12));
24  return NULL;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH v3] arm64: defconfig: Enable samsung MFD and related configs

2016-02-13 Thread Krzysztof Kozlowski
W dniu 05.02.2016 o 15:04, Alim Akhtar pisze:
> Exynos7 based espresso board uses S2MPS15, a multifunction device.
> This patch enables S2MPS1X regulator, pmic-clk and rtc drivers utilized by
> the same.
> 
> Signed-off-by: Alim Akhtar 
> Reviewed-by: Krzysztof Kozlowski 
> ---
> Changes since v2:
> * Added Reviewed-by from Krzysztof
> * rebased on next-20160204
> 
> Changes since v1:
> * updated the comment message to describe which platfrom uses it.
> * enable COMMON_CLK_S2MPS11 which is needed to enable pmic-clk block.
> 
>  arch/arm64/configs/defconfig |3 +++
>  1 file changed, 3 insertions(+)
> 

Applying this to my tree would cause conflicts with commit efdda175c07f:
arm64: defconfig: add spmi and usb related configs
Conflicts are trivial (simple additions) but maybe it is better to avoid
them.

Olof/Arnd/Kevin, can you apply this directly to arm-soc?

Best regards,
Krzysztof

> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 86581f7..2fd2264 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -151,9 +151,11 @@ CONFIG_GPIO_XGENE=y
>  CONFIG_POWER_RESET_XGENE=y
>  CONFIG_POWER_RESET_SYSCON=y
>  # CONFIG_HWMON is not set
> +CONFIG_MFD_SEC_CORE=y
>  CONFIG_REGULATOR=y
>  CONFIG_REGULATOR_FIXED_VOLTAGE=y
>  CONFIG_REGULATOR_QCOM_SMD_RPM=y
> +CONFIG_REGULATOR_S2MPS11=y
>  CONFIG_FB=y
>  CONFIG_FB_ARMCLCD=y
>  CONFIG_FRAMEBUFFER_CONSOLE=y
> @@ -188,6 +190,7 @@ CONFIG_LEDS_TRIGGERS=y
>  CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>  CONFIG_LEDS_TRIGGER_CPU=y
>  CONFIG_RTC_CLASS=y
> +CONFIG_RTC_DRV_S5M=y
>  CONFIG_RTC_DRV_EFI=y
>  CONFIG_RTC_DRV_PL031=y
>  CONFIG_RTC_DRV_XGENE=y
> 



[next] Odroid XU3 boot fail after cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequency

2016-02-13 Thread Krzysztof Kozlowski
Hi all,

Recently Odroid XU3 failed to boot on linux-next
on multi_v7 defconfig. exynos defconfig boots fine.

Probably the "cpufreq: dt: Use dev_pm_opp_set_rate() to
switch frequency" is important here:
commit 78c3ba5df96c875b1668e1cd3ee0a69e62454f32
Author: Viresh Kumar 
Date:   Tue Feb 9 10:30:46 2016 +0530

cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequency

OPP core supports frequency/voltage changes based on the target
frequency now, use that instead of open coding the same in cpufreq-dt
driver.

Signed-off-by: Viresh Kumar 
Reviewed-by: Stephen Boyd 
Signed-off-by: Rafael J. Wysocki 


Full log:
http://www.krzk.eu/builders/boot-odroid-xu3-multi_v7/builds/276/steps/Boot%20odroid/logs/serial

dmesg:
Feb 14 10:29:58 [1.620308] vdd_ldo9: ramp_delay not set
Feb 14 10:29:58 [1.631144] vdd_ldo13: ramp_delay not set
Feb 14 10:29:58 [1.638523] vdd_ldo15: ramp_delay not set
Feb 14 10:29:58 [1.649500] vdd_sd: ramp_delay not set
Feb 14 10:29:58 [1.712318] [ cut here ]
Feb 14 10:29:58 [1.715490] kernel BUG at ../drivers/regulator/core.c:216!
...
Feb 14 10:29:58 [2.109871] [] (regulator_check_voltage) from 
[] (regulator_set_voltage_unlocked+0x58/0x230)
Feb 14 10:29:58 [2.12] [] (regulator_set_voltage_unlocked) 
from [] (regulator_set_voltage+0x28/0x54)
Feb 14 10:29:58 [2.129880] [] (regulator_set_voltage) from 
[] (_set_opp_voltage+0x30/0x98)
Feb 14 10:29:58 [2.138543] [] (_set_opp_voltage) from 
[] (dev_pm_opp_set_rate+0xf0/0x28c)
Feb 14 10:29:58 [2.147126] [] (dev_pm_opp_set_rate) from 
[] (__cpufreq_driver_target+0x184/0x2b4)
Feb 14 10:29:58 [2.156394] [] (__cpufreq_driver_target) from 
[] (dbs_check_cpu+0x1b0/0x1f4)
Feb 14 10:29:58 [2.165143] [] (dbs_check_cpu) from [] 
(cpufreq_governor_dbs+0x324/0x5c4)
Feb 14 10:29:58 [2.173637] [] (cpufreq_governor_dbs) from 
[] (__cpufreq_governor+0xe4/0x1ec)
Feb 14 10:29:58 [2.182477] [] (__cpufreq_governor) from 
[] (cpufreq_init_policy+0x64/0x8c)
Feb 14 10:29:58 [2.191141] [] (cpufreq_init_policy) from 
[] (cpufreq_online+0x2fc/0x708)
Feb 14 10:29:58 [2.199634] [] (cpufreq_online) from [] 
(subsys_interface_register+0x94/0xd8)
Feb 14 10:29:58 [2.208472] [] (subsys_interface_register) from 
[] (cpufreq_register_driver+0x14c/0x19c)
Feb 14 10:29:58 [2.218263] [] (cpufreq_register_driver) from 
[] (dt_cpufreq_probe+0x70/0xec)
Feb 14 10:29:59 [2.227104] [] (dt_cpufreq_probe) from 
[] (platform_drv_probe+0x4c/0xb0)
Feb 14 10:29:59 [2.235508] [] (platform_drv_probe) from 
[] (driver_probe_device+0x214/0x2c0)
Feb 14 10:29:59 [2.244345] [] (driver_probe_device) from 
[] (__driver_attach+0x8c/0x90)
Feb 14 10:29:59 [2.252750] [] (__driver_attach) from [] 
(bus_for_each_dev+0x68/0x9c)
Feb 14 10:29:59 [2.260895] [] (bus_for_each_dev) from 
[] (bus_add_driver+0x1a0/0x218)
Feb 14 10:29:59 [2.269128] [] (bus_add_driver) from [] 
(driver_register+0x78/0xf8)
Feb 14 10:29:59 [2.277103] [] (driver_register) from [] 
(do_one_initcall+0x90/0x1d8)
Feb 14 10:29:59 [2.285254] [] (do_one_initcall) from [] 
(kernel_init_freeable+0x15c/0x1fc)
Feb 14 10:29:59 [2.293918] [] (kernel_init_freeable) from 
[] (kernel_init+0x8/0xf0)
Feb 14 10:29:59 [2.301975] [] (kernel_init) from [] 
(ret_from_fork+0x14/0x3c)
Feb 14 10:29:59 [2.309508] Code: e1550004 baeb e3a0 e8bd8070 
(e7f001f2) 
Feb 14 10:29:59 [2.315585] ---[ end trace 42d99689dedcb6cb ]---


Device boots fine after reverting last three opp patches:
1. dd02a3d920083b6cb0ee4f0eaf2c599b740bf5fe
2. df2c8ec28e73d47392b8cb24828c15c54819da41
3. 78c3ba5df96c875b1668e1cd3ee0a69e62454f32


More details:
1. multi_v7_defconfig with enabled IPV6,NFS_V4,SENSORS_PWM_FAN,PWM_SAMSUNG
and disabled LEDS_TRIGGER_HEARTBEAT.
2. exynos5422-odroidxu3-lite.dts
3. The OPP used for cpufreq-dt are a combination of:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/exynos5420.dtsi
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/exynos5422-cpus.dtsi
4. Reproduced recently on next-20160212. First encountered on next-20160211.

Any ideas?

Best regards,
Krzysztof


Re: [PATCH 1/3] tpm: Hold the kref during tpm_chip_find_get

2016-02-13 Thread Jarkko Sakkinen
On Fri, Feb 12, 2016 at 05:04:29PM -0700, Jason Gunthorpe wrote:
> This was missed during the struct device conversion, we
> need to hold a kref on the chip to make sure it isn't freed.
> 
> Signed-off-by: Jason Gunthorpe 

I'm bit confused about this patch. What is the regression if this needs
to be dropped from my last pull request for 4.5 (that is the only one
I'm planning to include from this patch set, rest are definitely
post-4.5)?

If there is clear regression in this patch, I can do it. I didn't
reproduce any.

/Jarkko

> ---
>  drivers/char/tpm/tpm-chip.c | 2 ++
>  drivers/char/tpm/tpm.h  | 1 +
>  2 files changed, 3 insertions(+)
> 
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index 45cc39aabeee..ae2fed8a162b 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -53,6 +53,8 @@ struct tpm_chip *tpm_chip_find_get(int chip_num)
>   chip = pos;
>   break;
>   }
> +
> + get_device(>dev);
>   }
>   rcu_read_unlock();
>   return chip;
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 542a80cbfd9c..f6ba79d91857 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -207,6 +207,7 @@ struct tpm_chip {
>  static inline void tpm_chip_put(struct tpm_chip *chip)
>  {
>   module_put(chip->pdev->driver->owner);
> + put_device(>dev);
>  }
>  
>  static inline int tpm_read_index(int base, int index)
> -- 
> 2.1.4
> 


Re: [PATCH] goldfish: Return correct error code

2016-02-13 Thread Amitoj Kaur Chawla
On Sun, Feb 14, 2016 at 12:32 AM, Julia Lawall  wrote:
> There is another return -1 at the end of the function that should be
> addressed.  Maybe -EINVAL would be an appropriate value, if you don't find
> evidence of anything else.
>
> julia
Okay. Will redo and send v2.

 Amitoj


Re: [PATCH v2] x86/kernel: use pr_() and dev_

2016-02-13 Thread kbuild test robot
Hi Chen,

[auto build test WARNING on tip/x86/core]
[also build test WARNING on v4.5-rc3 next-20160212]
[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/Chen-Yucong/x86-kernel-use-pr_-level-and-dev_-level/20160214-121236
config: x86_64-randconfig-x012-201607 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> arch/x86/pci/mmconfig-shared.c:25:0: warning: "pr_fmt" redefined
#define pr_fmt(fmt) "PCI: " fmt
^
   In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/pci.h:25,
from arch/x86/pci/mmconfig-shared.c:13:
   include/linux/printk.h:236:0: note: this is the location of the previous 
definition
#define pr_fmt(fmt) fmt
^

vim +/pr_fmt +25 arch/x86/pci/mmconfig-shared.c

 9   * Per-architecture code takes care of the mappings and accesses
10   * themselves.
11   */
12  
13  #include 
14  #include 
15  #include 
16  #include 
17  #include 
18  #include 
19  #include 
20  #include 
21  #include 
22  #include 
23  #include 
24  
  > 25  #define pr_fmt(fmt) "PCI: " fmt
26  
27  /* Indicate if the mmcfg resources have been placed into the resource 
table. */
28  static bool pci_mmcfg_running_state;
29  static bool pci_mmcfg_arch_init_failed;
30  static DEFINE_MUTEX(pci_mmcfg_lock);
31  
32  LIST_HEAD(pci_mmcfg_list);
33  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


[PATCH v2] x86/kernel: use pr_() and dev_

2016-02-13 Thread Chen Yucong
arch/x86/kernel/* use a mixture of printk(KERN_ ) and pr_().
This patch converts the bulk of printk(KERN_ ) to pr_() and
uses dev_dbg() instead of the dev_printk(KERN_DEBUG,). All pr_warning()
calls have been replaced with pr_warn().

Not sure what to do about the printk(KERN_DEFAULT) and printk() without a
log level.

Signed-off-by: Chen Yucong 
---
 arch/x86/kernel/acpi/boot.c | 110 
 arch/x86/kernel/acpi/cstate.c   |   5 +-
 arch/x86/kernel/acpi/sleep.c|   2 +-
 arch/x86/kernel/alternative.c   |   8 +--
 arch/x86/kernel/amd_gart_64.c   |  13 ++---
 arch/x86/kernel/apb_timer.c |  23 
 arch/x86/kernel/apic/apic.c |  43 +++---
 arch/x86/kernel/apic/apic_flat_64.c |   4 +-
 arch/x86/kernel/apic/apic_noop.c|   2 +-
 arch/x86/kernel/apic/bigsmp_32.c|   5 +-
 arch/x86/kernel/apic/io_apic.c  |  95 +++
 arch/x86/kernel/apic/probe_32.c |   9 ++-
 arch/x86/kernel/apic/x2apic_phys.c  |   2 +-
 arch/x86/kernel/apic/x2apic_uv_x.c  |   3 +-
 arch/x86/kernel/apm_32.c|  80 --
 arch/x86/kernel/bootflag.c  |   4 +-
 arch/x86/kernel/check.c |  11 ++--
 arch/x86/kernel/cpuid.c |   2 +-
 arch/x86/kernel/crash_dump_32.c |   6 +-
 arch/x86/kernel/devicetree.c|   6 +-
 arch/x86/kernel/doublefault.c   |  17 +++---
 arch/x86/kernel/dumpstack.c |   4 +-
 arch/x86/kernel/e820.c  |  66 +++---
 arch/x86/kernel/early-quirks.c  |  38 +
 arch/x86/kernel/early_printk.c  |   4 +-
 arch/x86/kernel/fpu/init.c  |   3 +-
 arch/x86/kernel/fpu/xstate.c|   3 +-
 arch/x86/kernel/hpet.c  |  33 +--
 arch/x86/kernel/i8259.c |   5 +-
 arch/x86/kernel/irq_32.c|   6 +-
 arch/x86/kernel/jump_label.c|   4 +-
 arch/x86/kernel/kgdb.c  |   8 +--
 arch/x86/kernel/kprobes/core.c  |  11 ++--
 arch/x86/kernel/kvm.c   |  12 ++--
 arch/x86/kernel/kvmclock.c  |  10 ++--
 arch/x86/kernel/mmconf-fam10h_64.c  |   2 +-
 arch/x86/kernel/module.c|   4 +-
 arch/x86/kernel/nmi_selftest.c  |  12 ++--
 arch/x86/kernel/paravirt.c  |   2 +-
 arch/x86/kernel/pci-calgary_64.c|  87 ++--
 arch/x86/kernel/pci-iommu_table.c   |   4 +-
 arch/x86/kernel/pci-nommu.c |   3 +-
 arch/x86/kernel/pci-swiotlb.c   |   3 +-
 arch/x86/kernel/quirks.c|  48 
 arch/x86/kernel/rtc.c   |   7 +--
 arch/x86/kernel/setup.c |  22 
 arch/x86/kernel/setup_percpu.c  |   2 +-
 arch/x86/kernel/smpboot.c   |   6 +-
 arch/x86/kernel/sysfb_efi.c |   7 +--
 arch/x86/kernel/sysfb_simplefb.c|   2 +-
 arch/x86/kernel/tboot.c |  16 +++---
 arch/x86/kernel/tce_64.c|   5 +-
 arch/x86/kernel/test_nx.c   |  16 +++---
 arch/x86/kernel/test_rodata.c   |  10 ++--
 arch/x86/kernel/tsc_sync.c  |   6 +-
 arch/x86/kernel/vsmp_64.c   |   2 +-
 arch/x86/pci/mmconfig-shared.c  |  32 +--
 arch/x86/pci/mmconfig_64.c  |   4 +-
 58 files changed, 448 insertions(+), 511 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index e759076..cb3afc7 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -55,7 +55,8 @@ EXPORT_SYMBOL(acpi_disabled);
 # include 
 #endif /* X86 */
 
-#define PREFIX "ACPI: "
+#undef pr_fmt
+#define pr_fmt(fmt) "ACPI: " fmt
 
 int acpi_noirq;/* skip ACPI IRQ initialization 
*/
 int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
@@ -141,14 +142,14 @@ static int __init acpi_parse_madt(struct 
acpi_table_header *table)
 
madt = (struct acpi_table_madt *)table;
if (!madt) {
-   printk(KERN_WARNING PREFIX "Unable to map MADT\n");
+   pr_warn("Unable to map MADT\n");
return -ENODEV;
}
 
if (madt->address) {
acpi_lapic_addr = (u64) madt->address;
 
-   printk(KERN_DEBUG PREFIX "Local APIC address 0x%08x\n",
+   pr_debug("Local APIC address 0x%08x\n",
   madt->address);
}
 
@@ -170,7 +171,7 @@ static int acpi_register_lapic(int id, u8 enabled)
unsigned int ver = 0;
 
if (id >= MAX_LOCAL_APIC) {
-   printk(KERN_INFO PREFIX "skipped apicid that is too big\n");
+   pr_info("skipped apicid that is too big\n");
return -EINVAL;
}
 
@@ -210,11 +211,11 @@ acpi_parse_x2apic(struct acpi_subtable_header *header, 
const unsigned long end)
 * when we use CPU hotplug.
 */
if (!apic->apic_id_valid(apic_id) && enabled)
-   printk(KERN_WARNING PREFIX 

Linux 3.2.77

2016-02-13 Thread Ben Hutchings
I'm announcing the release of the 3.2.77 kernel.

All users of the 3.2 kernel series should upgrade.

The updated 3.2.y git tree can be found at:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.2.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git

The diff from 3.2.76 is attached to this message.

Ben.



 Makefile|   2 +-
 arch/m32r/kernel/setup.c|   3 +
 arch/parisc/include/asm/siginfo.h   |   4 +
 arch/powerpc/include/asm/synch.h|   2 +-
 arch/powerpc/include/asm/system.h   |  16 +--
 arch/sparc/kernel/sys_sparc_64.c|   2 +-
 arch/um/os-Linux/start_up.c |   2 +
 arch/x86/include/asm/boot.h |   2 +-
 arch/x86/include/asm/mmu_context.h  |  32 -
 arch/x86/kernel/process_64.c|   2 +-
 arch/x86/kernel/reboot.c|   8 ++
 arch/x86/kvm/trace.h|   2 +-
 arch/x86/kvm/x86.c  |  17 ++-
 arch/x86/mm/tlb.c   |  28 +++-
 arch/x86/xen/suspend.c  |   3 +-
 crypto/ablkcipher.c |   1 +
 crypto/af_alg.c |  55 +++-
 crypto/ahash.c  |   5 +-
 crypto/algif_hash.c | 165 ++-
 crypto/algif_skcipher.c | 169 +---
 crypto/shash.c  |   4 +-
 drivers/edac/edac_device.c  |   9 +-
 drivers/edac/edac_mc.c  |  15 +--
 drivers/edac/edac_pci.c |   9 +-
 drivers/gpu/drm/radeon/radeon_atombios.c|  12 +-
 drivers/gpu/drm/radeon/radeon_device.c  |   1 +
 drivers/infiniband/hw/mlx4/ah.c |   1 +
 drivers/infiniband/hw/qib/qib_verbs_mcast.c |  35 +++--
 drivers/input/serio/i8042-x86ia64io.h   |   7 +
 drivers/md/dm-exception-store.h |   2 +-
 drivers/md/dm-snap-persistent.c |   5 +-
 drivers/md/dm-snap-transient.c  |   4 +-
 drivers/md/dm-snap.c|  20 +--
 drivers/media/dvb/dvb-core/dvb_frontend.c   |   6 +-
 drivers/media/rc/rc-main.c  |   2 +-
 drivers/media/video/gspca/ov534.c   |   9 +-
 drivers/media/video/gspca/topro.c   |   6 +-
 drivers/media/video/usbvision/usbvision-video.c |  47 ++-
 drivers/net/usb/asix.c  |   2 +-
 drivers/net/wireless/ath/ath9k/htc_hst.c|   2 +-
 drivers/net/wireless/rtlwifi/rtl8192ce/sw.c |   2 +
 drivers/net/wireless/rtlwifi/rtl8192cu/sw.c |   2 +
 drivers/net/wireless/rtlwifi/rtl8192de/sw.c |   4 +-
 drivers/net/wireless/rtlwifi/rtl8192se/sw.c |   6 +-
 drivers/net/wireless/rtlwifi/usb.c  |   2 +
 drivers/net/wireless/wl12xx/spi.c   |   8 +-
 drivers/power/test_power.c  |   2 +
 drivers/scsi/initio.c   |  16 ---
 drivers/usb/host/xhci.c |   3 +
 drivers/usb/serial/cp210x.c |   1 +
 fs/cifs/cifs_debug.h|   8 +-
 fs/cifs/connect.c   |   2 +-
 fs/cifs/readdir.c   |   1 +
 fs/cifs/transport.c |  17 ++-
 fs/hostfs/hostfs_kern.c |   4 +-
 fs/locks.c  |  51 ---
 fs/nfs/inode.c  |  54 +---
 fs/ocfs2/dlm/dlmmaster.c|  26 ++--
 fs/ocfs2/dlmglue.c  |   6 +
 fs/udf/inode.c  |  15 +++
 fs/udf/unicode.c|  21 ++-
 include/crypto/hash.h   |   6 +
 include/crypto/if_alg.h |  11 +-
 include/linux/crypto.h  |   8 ++
 include/linux/mtd/nand.h|   4 +-
 include/linux/printk.h  |  12 +-
 kernel/futex.c  |   5 +
 kernel/time/posix-clock.c   |   4 +-
 lib/dma-debug.c |   2 +-
 mm/memcontrol.c |  11 +-
 net/ipv6/tcp_ipv6.c |   2 +
 net/sctp/sm_sideeffect.c|  34 ++---
 scripts/bloat-o-meter   |   8 +-
 sound/core/control.c|   2 +
 sound/core/hrtimer.c|   3 +-
 sound/core/pcm_compat.c |  13 +-
 sound/core/seq/seq_clientmgr.c  |   2 +-
 

Re: [PATCH] dts: ls102xa: ifc: Add the partition for NOR flash

2016-02-13 Thread Shawn Guo
On Wed, Feb 03, 2016 at 04:16:44PM +0800, Alison Wang wrote:
> According to the new mapping table, the partition for NOR flash
> is added.

How do you know that everyone using the board wants the NOR flash to be
partitioned this way?  It's really a matter of software configuration
and may vary from system to system.

Shawn

> 
> Signed-off-by: Alison Wang 
> ---
>  arch/arm/boot/dts/ls1021a-qds.dts | 60 
> +++
>  arch/arm/boot/dts/ls1021a-twr.dts | 60 
> +++
>  2 files changed, 120 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/ls1021a-qds.dts 
> b/arch/arm/boot/dts/ls1021a-qds.dts
> index 9408753..904ee09 100644
> --- a/arch/arm/boot/dts/ls1021a-qds.dts
> +++ b/arch/arm/boot/dts/ls1021a-qds.dts
> @@ -237,6 +237,66 @@
>   reg = <0x0 0x0 0x800>;
>   bank-width = <2>;
>   device-width = <1>;
> +
> + partition@0 {
> + /* 128KB for bank0 RCW */
> + reg = <0x 0x0002>;
> + label = "NOR bank0 RCW Image";
> + };
> +
> + partition@10 {
> + /* 1MB for bank0 u-boot Image */
> + reg = <0x0010 0x0010>;
> + label = "NOR bank0 u-boot Image";
> + };
> +
> + partition@20 {
> + /* 1MB for bank0 DTB */
> + reg = <0x0020 0x0010>;
> + label = "NOR bank0 DTB Image";
> + };
> +
> + partition@30 {
> + /* 7MB for bank0 Linux Kernel */
> + reg = <0x0030 0x0070>;
> + label = "NOR bank0 Linux Kernel Image";
> + };
> +
> + partition@a0 {
> + /* 54MB for bank0 Ramdisk Root File System */
> + reg = <0x00a0 0x0360>;
> + label = "NOR bank0 Ramdisk Root File System Image";
> + };
> +
> + partition@400 {
> + /* 128KB for bank4 RCW */
> + reg = <0x0400 0x0002>;
> + label = "NOR bank4 RCW Image";
> + };
> +
> + partition@410 {
> + /* 1MB for bank4 u-boot Image */
> + reg = <0x0410 0x0010>;
> + label = "NOR bank4 u-boot Image";
> + };
> +
> + partition@420 {
> + /* 1MB for bank4 DTB */
> + reg = <0x0420 0x0010>;
> + label = "NOR bank4 DTB Image";
> + };
> +
> + partition@430 {
> + /* 7MB for bank4 Linux Kernel */
> + reg = <0x0430 0x0070>;
> + label = "NOR bank4 Linux Kernel Image";
> + };
> +
> + partition@4a0 {
> + /* 54MB for bank4 Ramdisk Root File System */
> + reg = <0x04a0 0x0360>;
> + label = "NOR bank4 Ramdisk Root File System Image";
> + };
>   };
>  
>   fpga: board-control@3,0 {
> diff --git a/arch/arm/boot/dts/ls1021a-twr.dts 
> b/arch/arm/boot/dts/ls1021a-twr.dts
> index 75ecaed..f5e9616 100644
> --- a/arch/arm/boot/dts/ls1021a-twr.dts
> +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> @@ -194,6 +194,66 @@
>   reg = <0x0 0x0 0x800>;
>   bank-width = <2>;
>   device-width = <1>;
> +
> + partition@0 {
> + /* 128KB for bank0 RCW */
> + reg = <0x 0x0002>;
> + label = "NOR bank0 RCW Image";
> + };
> +
> + partition@10 {
> + /* 1MB for bank0 u-boot Image */
> + reg = <0x0010 0x0010>;
> + label = "NOR bank0 u-boot Image";
> + };
> +
> + partition@20 {
> + /* 1MB for bank0 DTB */
> + reg = <0x0020 0x0010>;
> + label = "NOR bank0 DTB Image";
> + };
> +
> + partition@30 {
> + /* 7MB for bank0 Linux Kernel */
> + reg = <0x0030 0x0070>;
> + label = "NOR bank0 Linux Kernel Image";
> + };
> +
> + partition@a0 {
> + /* 54MB for bank0 Ramdisk Root File System */
> + reg = <0x00a0 0x0360>;
> + label = "NOR bank0 Ramdisk Root File System Image";
> + };
> +
> + partition@400 {
> + /* 128KB for bank4 RCW */
> + reg = <0x0400 0x0002>;
> + label = "NOR bank4 RCW Image";
> + };
> +
> +

Re: [PATCH v2 0/4] tpm: last minute critical fixes for Linux 4.5

2016-02-13 Thread Jarkko Sakkinen
On Sun, Feb 14, 2016 at 05:27:12AM +0200, Jarkko Sakkinen wrote:
> On Sat, Feb 13, 2016 at 02:55:56PM -0700, Jason Gunthorpe wrote:
> > Hi Peter, 
> > 
> > Please don't grab my patch in this pull, it is broken.
> 
> Please send an updated fix. I'll check it through and include it to the
> final pull request.

I'm still waiting for James to pick my previous pull request so take
your time and prepare an updated patch!

/Jarkko

> > Thanks
> > Jason
> 
> /Jarkko
> 
> > 
> > On Feb 13, 2016 6:47 AM, Jarkko Sakkinen  
> > wrote:
> > >
> > > These are critical to get to Linux 4.5 in order to get the chip refcount 
> > > management stabilized and API/ABI for policy based sealing correct. 
> > >
> > > Harald Hoyer (1): 
> > >   tpm_eventlog.c: fix binary_bios_measurements 
> > >
> > > Jarkko Sakkinen (2): 
> > >   tpm: fix: keep auth session intact after unseal operation 
> > >   tpm: fix: rollback when devm_add_action() fails 
> > >
> > > Jason Gunthorpe (1): 
> > >   tpm: Hold the kref during tpm_chip_find_get 
> > >
> > > drivers/char/tpm/tpm-chip.c |  9 - 
> > > drivers/char/tpm/tpm.h  |  1 + 
> > > drivers/char/tpm/tpm2-cmd.c | 10 +++--- 
> > > drivers/char/tpm/tpm_eventlog.c | 10 -- 
> > > 4 files changed, 24 insertions(+), 6 deletions(-) 
> > >
> > > -- 
> > > 2.7.0 
> > >


Re: [PATCH v3] ARM: dts: Add dts for Uniwest evi

2016-02-13 Thread Shawn Guo
On Wed, Feb 03, 2016 at 09:37:45AM -0800, Joshua Clayton wrote:
> Uniwest evi is a portable electrical eddy current non-destructive
> testing device.
> 
> Signed-off-by: Joshua Clayton 

Applied, thanks.


Re: [PATCH v2 0/4] tpm: last minute critical fixes for Linux 4.5

2016-02-13 Thread Jarkko Sakkinen
On Sat, Feb 13, 2016 at 02:55:56PM -0700, Jason Gunthorpe wrote:
> Hi Peter, 
> 
> Please don't grab my patch in this pull, it is broken.

Please send an updated fix. I'll check it through and include it to the
final pull request.

> Thanks
> Jason

/Jarkko

> 
> On Feb 13, 2016 6:47 AM, Jarkko Sakkinen  
> wrote:
> >
> > These are critical to get to Linux 4.5 in order to get the chip refcount 
> > management stabilized and API/ABI for policy based sealing correct. 
> >
> > Harald Hoyer (1): 
> >   tpm_eventlog.c: fix binary_bios_measurements 
> >
> > Jarkko Sakkinen (2): 
> >   tpm: fix: keep auth session intact after unseal operation 
> >   tpm: fix: rollback when devm_add_action() fails 
> >
> > Jason Gunthorpe (1): 
> >   tpm: Hold the kref during tpm_chip_find_get 
> >
> > drivers/char/tpm/tpm-chip.c |  9 - 
> > drivers/char/tpm/tpm.h  |  1 + 
> > drivers/char/tpm/tpm2-cmd.c | 10 +++--- 
> > drivers/char/tpm/tpm_eventlog.c | 10 -- 
> > 4 files changed, 24 insertions(+), 6 deletions(-) 
> >
> > -- 
> > 2.7.0 
> >


[PATCH] staging: lustre/lnet: Fix wrong typecasting warning generated by sparse

2016-02-13 Thread Niranjan Dighe
Fix the following warning generated about type casting by sparse

warning: cast removes address space of expression

The current implementation casts the structure pointers with (char *)
without __user annotation and then adds sizeof struct to it, thereby
generating the sparse warning. Fixed this by removing the unnecessary
char pointer type cast.

Signed-off-by: Niranjan Dighe 
---
 drivers/staging/lustre/lnet/selftest/console.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lnet/selftest/console.c 
b/drivers/staging/lustre/lnet/selftest/console.c
index 366211e..bc236c9 100644
--- a/drivers/staging/lustre/lnet/selftest/console.c
+++ b/drivers/staging/lustre/lnet/selftest/console.c
@@ -1460,10 +1460,8 @@ lstcon_statrpc_readent(int transop, srpc_msg_t *msg,
return 0;
 
sfwk_stat = (sfw_counters_t __user *)_up->rpe_payload[0];
-   srpc_stat = (srpc_counters_t __user *)
- ((char *)sfwk_stat + sizeof(*sfwk_stat));
-   lnet_stat = (lnet_counters_t __user *)
- ((char *)srpc_stat + sizeof(*srpc_stat));
+   srpc_stat = (srpc_counters_t __user *)(sfwk_stat + 1);
+   lnet_stat = (lnet_counters_t __user *)(srpc_stat + 1);
 
if (copy_to_user(sfwk_stat, >str_fw, sizeof(*sfwk_stat)) ||
copy_to_user(srpc_stat, >str_rpc, sizeof(*srpc_stat)) ||
-- 
1.9.1



[lkp] [usb] daa556cb5d: WARNING: CPU: 0 PID: 44 at kernel/workqueue.c:1380 __queue_work+0x3d2/0x570()

2016-02-13 Thread kernel test robot
FYI, we noticed the below changes on

https://github.com/0day-ci/linux 
Amit-Pundir/usb-gadget-u_ether-Add-workqueue-as-bottom-half-handler-for-rx-data-path/20160209-052012
commit daa556cb5d704ad9b4159dc56dd0161e85b3a596 ("usb: gadget: u_ether: Add 
workqueue as bottom half handler for rx data path")


+---+--++
|   | v4.5-rc2 | daa556cb5d 
|
+---+--++
| boot_successes| 81   | 58 
|
| boot_failures | 12   | 50 
|
| invoked_oom-killer:gfp_mask=0x| 11   | 43 
|
| Mem-Info  | 11   | 43 
|
| Out_of_memory:Kill_process| 11   | 43 
|
| backtrace:vfs_read| 2| 12 
|
| backtrace:SyS_read| 2| 12 
|
| page_allocation_failure:order:#,mode  | 3| 11 
|
| warn_alloc_failed+0x  | 1| 5  
|
| backtrace:ring_buffer_consumer_thread | 1| 6  
|
| backtrace:vfs_write   | 1| 10 
|
| backtrace:SyS_write   | 1| 10 
|
| BUG:unable_to_handle_kernel   | 1|
|
| Oops  | 1| 1  
|
| EIP_is_at_perf_prepare_sample | 1| 1  
|
| Kernel_panic-not_syncing:Fatal_exception  | 1|
|
| backtrace:do_execveat_common  | 1| 5  
|
| backtrace:SyS_execve  | 1| 5  
|
| WARNING:at_kernel/workqueue.c:#__queue_work() | 0| 45 
|
| backtrace:cpu_startup_entry   | 0| 10 
|
| backtrace:vfs_writev  | 0| 29 
|
| backtrace:SyS_writev  | 0| 27 
|
| backtrace:getxattr| 0| 1  
|
| backtrace:SyS_fgetxattr   | 0| 1  
|
| backtrace:_do_fork| 0| 5  
|
| backtrace:SyS_clone   | 0| 5  
|
| backtrace:ring_buffer_producer_thread | 0| 24 
|
| backtrace:SyS_pwritev | 0| 3  
|
| backtrace:ip_auto_config  | 0| 4  
|
| backtrace:kernel_init_freeable| 0| 4  
|
| backtrace:path_listxattr  | 0| 2  
|
| backtrace:SyS_listxattr   | 0| 2  
|
| backtrace:addrconf_dad_work   | 0| 5  
|
| backtrace:common_interrupt| 0| 1  
|
| backtrace:vmalloc | 0| 1  
|
| backtrace:SyS_add_key | 0| 1  
|
| backtrace:lock_torture_stats  | 0| 1  
|
| Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 0| 1  
|
+---+--++



[   36.055351] cdc_ether 1-1:1.0 usb1: kevent 11 may have been dropped
[   36.072532] IP-Config: Failed to open irlan0
[   36.080520] [ cut here ]
[   36.081565] WARNING: CPU: 0 PID: 44 at kernel/workqueue.c:1380 
__queue_work+0x3d2/0x570()
[   36.083375] CPU: 0 PID: 44 Comm: rb_producer Not tainted 
4.5.0-rc2-1-gdaa556cb #1
[   36.084667] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   36.086434]    c020be00 c1657549 c020be30 c1049e6e c26fcefc 

[   36.099237]  002c c26fd7f0 0564 c105f0c2 c105f0c2 c82c055c 0001 
0001
[   36.113302]  c020be40 c1049f62 0009  c020be78 c105f0c2 c82c052c 

[   36.121617] Call Trace:
[   36.122473]  [] dump_stack+0x16/0x1d
[   36.123754]  [] warn_slowpath_common+0x7e/0xb0
[   36.125100]  [] ? __queue_work+0x3d2/0x570
[   36.126255]  [] ? __queue_work+0x3d2/0x570
[   36.127327]  [] warn_slowpath_null+0x22/0x30
[   36.128368]  [] __queue_work+0x3d2/0x570
[   36.129291]  [] queue_work_on+0x3f/0x80
[   36.130217]  [] rx_complete+0xca/0x160
[   36.131064]  [] usb_gadget_giveback_request+0x3d/0x50
[   36.134310]  [] 

[PATCH] Documentation/ko_KR: update maintainer information

2016-02-13 Thread SeongJae Park
Maintainer informations of Documentation/ko_KR is outdated. This commit
update the informations to the latest ones.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO   | 4 ++--
 Documentation/ko_KR/stable_api_nonsense.txt | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 1aef53e..5a81b39 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -1,6 +1,6 @@
 NOTE:
 This is a version of Documentation/HOWTO translated into korean
-This document is maintained by minchan Kim 
+This document is maintained by Minchan Kim 
 If you find any difference between this document and the original file or
 a problem with the translation, please contact the maintainer of this file.
 
@@ -14,7 +14,7 @@ try to update the original English file first.
 Documentation/HOWTO
 의 한글 번역입니다.
 
-역자: 김민찬 
+역자: 김민찬 
 감수: 이제이미 
 ==
 
diff --git a/Documentation/ko_KR/stable_api_nonsense.txt 
b/Documentation/ko_KR/stable_api_nonsense.txt
index 51f85ad..3ba10b1 100644
--- a/Documentation/ko_KR/stable_api_nonsense.txt
+++ b/Documentation/ko_KR/stable_api_nonsense.txt
@@ -1,7 +1,7 @@
 NOTE:
 This is a version of Documentation/stable_api_nonsense.txt translated
 into korean
-This document is maintained by barrios 
+This document is maintained by Minchan Kim 
 If you find any difference between this document and the original file or
 a problem with the translation, please contact the maintainer of this file.
 
@@ -15,7 +15,7 @@ try to update the original English file first.
 Documentation/stable_api_nonsense.txt
 의 한글 번역입니다.
 
-역자: 김민찬 
+역자: 김민찬 
 감수: 이제이미 
 ==
 
-- 
1.9.1



Re: [PATCH] staging: lustre/lnet: Fix wrong type casting warning generated by sparse

2016-02-13 Thread Niranjan Dighe
On Sun, Feb 14, 2016 at 3:19 AM, Dan Carpenter  wrote:
> On Sat, Feb 13, 2016 at 11:34:35PM +0530, Niranjan Dighe wrote:
>> diff --git a/drivers/staging/lustre/lnet/selftest/console.c 
>> b/drivers/staging/lustre/lnet/selftest/console.c
>> index 366211e..64b6a70 100644
>> --- a/drivers/staging/lustre/lnet/selftest/console.c
>> +++ b/drivers/staging/lustre/lnet/selftest/console.c
>> @@ -1461,9 +1461,9 @@ lstcon_statrpc_readent(int transop, srpc_msg_t *msg,
>>
>>   sfwk_stat = (sfw_counters_t __user *)_up->rpe_payload[0];
>>   srpc_stat = (srpc_counters_t __user *)
>> -   ((char *)sfwk_stat + sizeof(*sfwk_stat));
>> + ((char __user *)sfwk_stat + 
>> sizeof(*sfwk_stat));
>
> This is uglier than necessary.  Do it either like this:
>
> srpc_stat = (void __user *)sfwk_stat + sizeof(*sfwk_stat);
>
> Or probably it's actually nicer to say:
>
> srpc_stat = sfwk_stat + 1;
>
> regards,
> dan carpenter
>

Yes, thanks Dan, I will send out a new patch. Please discard this one.


[PATCH 0/5] irqchip: Add support for Hisilicon mbigen v1 chip

2016-02-13 Thread MaJun
From: Ma Jun 

This patch set is used to support the mbigen v1 chip.
Compared to mbigen v2 chip, the main difference between them is
register layout(address,format)

As a sequence of this difference, the functions used to get or calculate
register address are also changed for this reason.

I posted this driver as a independent patch set but not change the mbigen-v2
driver to support mbigen-v1 hardware.

Ma Jun (5):
  dt-binding: Change the mbigen bindding file to support the mbigen-v1
  dt-binding:Rename the mbigen binding file name
  irqchip: add platform device driver for mbigen device
  irqchip:create irq domain for each mbigen device
  irqchip:implement the mbigen irq chip operation functions

 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   74 -
 .../interrupt-controller/hisilicon,mbigen.txt  |   74 +
 drivers/irqchip/Makefile   |2 +-
 drivers/irqchip/irq-mbigen-v1.c|  295 
 4 files changed, 370 insertions(+), 75 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt
 create mode 100644 drivers/irqchip/irq-mbigen-v1.c




[PATCH 5/5] irqchip:implement the mbigen irq chip operation functions

2016-02-13 Thread MaJun
From: Ma Jun 

Add the interrupt controller chip operation functions of mbigen chip.

Signed-off-by: Ma Jun 
---
 drivers/irqchip/irq-mbigen-v1.c |   75 +++
 1 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen-v1.c b/drivers/irqchip/irq-mbigen-v1.c
index 6bbb82a..8291a47 100644
--- a/drivers/irqchip/irq-mbigen-v1.c
+++ b/drivers/irqchip/irq-mbigen-v1.c
@@ -41,6 +41,20 @@
 #define REG_MBIGEN_EXT_VEC_OFFSET  0x320
 
 /**
+ * offset of clear register in mbigen node
+ * This register is used to clear the status
+ * of interrupt
+ */
+#define REG_MBIGEN_CLEAR_OFFSET0x100
+
+/**
+ * offset of interrupt type register
+ * This register is used to configure interrupt
+ * trigger type
+ */
+#define REG_MBIGEN_TYPE_OFFSET 0x0
+
+/**
  * struct mbigen_device - holds the information of mbigen device.
  *
  * @pdev:  pointer to the platform device structure of mbigen chip.
@@ -77,8 +91,69 @@ static inline unsigned int 
get_mbigen_vec_reg(irq_hw_number_t hwirq)
return (nid - 4) * 4 + REG_MBIGEN_EXT_VEC_OFFSET;
 }
 
+static inline void get_mbigen_type_reg(irq_hw_number_t hwirq,
+   u32 *mask, u32 *addr)
+{
+   int ofst;
+
+   ofst = hwirq / 32 * 4;
+   *mask = 1 << (hwirq % 32);
+
+   *addr = ofst + REG_MBIGEN_TYPE_OFFSET;
+}
+
+static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
+   u32 *mask, u32 *addr)
+{
+   unsigned int ofst;
+
+   ofst = hwirq / 32 * 4;
+
+   *mask = 1 << (hwirq % 32);
+   *addr = ofst + REG_MBIGEN_CLEAR_OFFSET;
+}
+
+static void mbigen_eoi_irq(struct irq_data *data)
+{
+   void __iomem *base = data->chip_data;
+   u32 mask, addr;
+
+   get_mbigen_clear_reg(data->hwirq, , );
+
+   writel_relaxed(mask, base + addr);
+
+   irq_chip_eoi_parent(data);
+}
+
+static int mbigen_set_type(struct irq_data *data, unsigned int type)
+{
+   void __iomem *base = data->chip_data;
+   u32 mask, addr, val;
+
+   if (type != IRQ_TYPE_LEVEL_HIGH && type != IRQ_TYPE_EDGE_RISING)
+   return -EINVAL;
+
+   get_mbigen_type_reg(data->hwirq, , );
+
+   val = readl_relaxed(base + addr);
+
+   if (type == IRQ_TYPE_LEVEL_HIGH)
+   val |= mask;
+   else
+   val &= ~mask;
+
+   writel_relaxed(val, base + addr);
+
+   return 0;
+}
+
 static struct irq_chip mbigen_irq_chip = {
.name = "mbigen-v1",
+   .irq_mask = irq_chip_mask_parent,
+   .irq_unmask =   irq_chip_unmask_parent,
+   .irq_eoi =  mbigen_eoi_irq,
+   .irq_set_type = mbigen_set_type,
+   .irq_set_affinity = irq_chip_set_affinity_parent,
 };
 
 static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
-- 
1.7.1




[PATCH 2/5] dt-binding:Rename the mbigen binding file name

2016-02-13 Thread MaJun
From: Ma Jun 

Because added the mbigen-v1 compatible string, the origin name is
not suitable any more. So,I remove the version number from file name.

Signed-off-by: Ma Jun 
---
 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   74 
 .../interrupt-controller/hisilicon,mbigen.txt  |   74 
 2 files changed, 74 insertions(+), 74 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
deleted file mode 100644
index bdd1dea..000
--- 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Hisilicon mbigen device tree bindings.
-===
-
-Mbigen means: message based interrupt generator.
-
-MBI is kind of msi interrupt only used on Non-PCI devices.
-
-To reduce the wired interrupt number connected to GIC,
-Hisilicon designed mbigen to collect and generate interrupt.
-
-
-Non-pci devices can connect to mbigen and generate the
-interrupt by writing ITS register.
-
-The mbigen chip and devices connect to mbigen have the following properties:
-
-Mbigen main node required properties:

-- compatible: Should be "hisilicon,mbigen-v2" or "hisilicon,mbigen-v1"
-
-- reg: Specifies the base physical address and size of the Mbigen
-  registers.
-
-- interrupt controller: Identifies the node as an interrupt controller
-
-- msi-parent: Specifies the MSI controller this mbigen use.
-  For more detail information,please refer to the generic msi-parent binding in
-  Documentation/devicetree/bindings/interrupt-controller/msi.txt.
-
-- num-pins: the total number of pins implemented in this Mbigen
-  instance.
-
-- #interrupt-cells : Specifies the number of cells needed to encode an
-  interrupt source. The value must be 2.
-
-  The 1st cell is hardware pin number of the interrupt.This number is local to
-  each mbigen chip and in the range from 0 to the maximum interrupts number
-  of the mbigen.
-
-  The 2nd cell is the interrupt trigger type.
-   The value of this cell should be:
-   1: rising edge triggered
-   or
-   4: high level triggered
-
-Examples:
-
-   mbigen_device_gmac:intc {
-   compatible = "hisilicon,mbigen-v2";
-   reg = <0x0 0xc008 0x0 0x1>;
-   interrupt-controller;
-   msi-parent = <_dsa 0x40b1c>;
-   num-pins = <9>;
-   #interrupt-cells = <2>;
-   };
-
-Devices connect to mbigen required properties:
-
--interrupt-parent: Specifies the mbigen device node which device connected.
-
--interrupts:Specifies the interrupt source.
- For the specific information of each cell in this property,please refer to
- the "interrupt-cells" description mentioned above.
-
-Examples:
-   gmac0: ethernet@c208 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0 0xc208 0 0x2>,
- <0 0xc000 0 0x1000>;
-   interrupt-parent  = <_device_gmac>;
-   interrupts =<656 1>,
-   <657 1>;
-   };
diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt
new file mode 100644
index 000..bdd1dea
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt
@@ -0,0 +1,74 @@
+Hisilicon mbigen device tree bindings.
+===
+
+Mbigen means: message based interrupt generator.
+
+MBI is kind of msi interrupt only used on Non-PCI devices.
+
+To reduce the wired interrupt number connected to GIC,
+Hisilicon designed mbigen to collect and generate interrupt.
+
+
+Non-pci devices can connect to mbigen and generate the
+interrupt by writing ITS register.
+
+The mbigen chip and devices connect to mbigen have the following properties:
+
+Mbigen main node required properties:
+---
+- compatible: Should be "hisilicon,mbigen-v2" or "hisilicon,mbigen-v1"
+
+- reg: Specifies the base physical address and size of the Mbigen
+  registers.
+
+- interrupt controller: Identifies the node as an interrupt controller
+
+- msi-parent: Specifies the MSI controller this mbigen use.
+  For more detail information,please refer to the generic msi-parent binding in
+  Documentation/devicetree/bindings/interrupt-controller/msi.txt.
+
+- num-pins: the total number of pins implemented in this Mbigen
+  instance.
+

[PATCH 3/5] irqchip: add platform device driver for mbigen device

2016-02-13 Thread MaJun
From: Ma Jun 

Add the platform device driver for mbigen chip v1.
This patch just same as mbigen v2.

Signed-off-by: Ma Jun 
---
 drivers/irqchip/Makefile|2 +-
 drivers/irqchip/irq-mbigen-v1.c |   76 +++
 2 files changed, 77 insertions(+), 1 deletions(-)
 create mode 100644 drivers/irqchip/irq-mbigen-v1.c

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 83d1fce..3152450 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -25,7 +25,7 @@ obj-$(CONFIG_REALVIEW_DT) += irq-gic-realview.o
 obj-$(CONFIG_ARM_GIC_V2M)  += irq-gic-v2m.o
 obj-$(CONFIG_ARM_GIC_V3)   += irq-gic-v3.o irq-gic-common.o
 obj-$(CONFIG_ARM_GIC_V3_ITS)   += irq-gic-v3-its.o 
irq-gic-v3-its-pci-msi.o irq-gic-v3-its-platform-msi.o
-obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o
+obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o irq-mbigen-v1.o
 obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
 obj-$(CONFIG_ARM_VIC)  += irq-vic.o
 obj-$(CONFIG_ATMEL_AIC_IRQ)+= irq-atmel-aic-common.o 
irq-atmel-aic.o
diff --git a/drivers/irqchip/irq-mbigen-v1.c b/drivers/irqchip/irq-mbigen-v1.c
new file mode 100644
index 000..9445658
--- /dev/null
+++ b/drivers/irqchip/irq-mbigen-v1.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright (C) 2015 Hisilicon Limited, All Rights Reserved.
+ * Author: Jun Ma 
+ * Author: Yun Wu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct mbigen_device - holds the information of mbigen device.
+ *
+ * @pdev:  pointer to the platform device structure of mbigen chip.
+ * @base:  mapped address of this mbigen chip.
+ */
+struct mbigen_device {
+   struct platform_device  *pdev;
+   void __iomem*base;
+};
+
+static int mbigen_device_probe(struct platform_device *pdev)
+{
+   struct mbigen_device *mgn_chip;
+   struct resource *res;
+
+   mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
+   if (!mgn_chip)
+   return -ENOMEM;
+
+   mgn_chip->pdev = pdev;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   mgn_chip->base = devm_ioremap(>dev, res->start, 
resource_size(res));
+   if (IS_ERR(mgn_chip->base))
+   return PTR_ERR(mgn_chip->base);
+
+   platform_set_drvdata(pdev, mgn_chip);
+
+   return 0;
+}
+
+static const struct of_device_id mbigen_of_match[] = {
+   { .compatible = "hisilicon,mbigen-v1" },
+   { /* END */ }
+};
+MODULE_DEVICE_TABLE(of, mbigen_of_match);
+
+static struct platform_driver mbigen_platform_driver = {
+   .driver = {
+   .name   = "Hisilicon MBIGEN-V1",
+   .owner  = THIS_MODULE,
+   .of_match_table = mbigen_of_match,
+   },
+   .probe  = mbigen_device_probe,
+};
+
+module_platform_driver(mbigen_platform_driver);
+
+MODULE_AUTHOR("Jun Ma ");
+MODULE_AUTHOR("Yun Wu ");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Hisilicon MBI Generator driver");
-- 
1.7.1




[PATCH 4/5] irqchip:create irq domain for each mbigen device

2016-02-13 Thread MaJun
From: Ma Jun 

For peripheral devices which connect to mbigen,mbigen is a interrupt
controller. So, we create irq domain for each mbigen device and add
mbigen irq domain into irq hierarchy structure.

Signed-off-by: Ma Jun 
---
 drivers/irqchip/irq-mbigen-v1.c |  144 +++
 1 files changed, 144 insertions(+), 0 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen-v1.c b/drivers/irqchip/irq-mbigen-v1.c
index 9445658..6bbb82a 100644
--- a/drivers/irqchip/irq-mbigen-v1.c
+++ b/drivers/irqchip/irq-mbigen-v1.c
@@ -16,11 +16,30 @@
  * along with this program.  If not, see .
  */
 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
+/* The maximum IRQ pin number of mbigen chip(start from 0) */
+#define MAXIMUM_IRQ_PIN_NUM640
+
+/**
+ * In mbigen vector register
+ * bit[31:16]: device id
+ * bit[15:0]:  event id value
+ */
+#define IRQ_EVENT_ID_MASK  0x
+
+/* offset of vector register in mbigen node */
+#define REG_MBIGEN_VEC_OFFSET  0x300
+#define REG_MBIGEN_EXT_VEC_OFFSET  0x320
+
 /**
  * struct mbigen_device - holds the information of mbigen device.
  *
@@ -32,10 +51,120 @@ struct mbigen_device {
void __iomem*base;
 };
 
+static int get_mbigen_nid(unsigned int offset)
+{
+   int nid = 0;
+
+   if (offset < 256)
+   nid = offset / 64;
+   else if (offset < 384)
+   nid = 4;
+   else if (offset < 640)
+   nid = 5;
+
+   return nid;
+}
+
+static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq)
+{
+   unsigned int nid;
+
+   nid = get_mbigen_nid(hwirq);
+
+   if (nid < 4)
+   return (nid * 4) + REG_MBIGEN_VEC_OFFSET;
+   else
+   return (nid - 4) * 4 + REG_MBIGEN_EXT_VEC_OFFSET;
+}
+
+static struct irq_chip mbigen_irq_chip = {
+   .name = "mbigen-v1",
+};
+
+static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
+{
+   struct irq_data *d = irq_get_irq_data(desc->irq);
+   void __iomem *base = d->chip_data;
+   u32 val;
+
+   base += get_mbigen_vec_reg(d->hwirq);
+   val = readl_relaxed(base);
+
+   val &= ~IRQ_EVENT_ID_MASK;
+   val |= msg->data;
+
+   /* The address of doorbell is encoded in mbigen register by default
+* So,we don't need to program the doorbell address at here
+*/
+   writel_relaxed(val, base);
+}
+
+static int mbigen_domain_translate(struct irq_domain *d,
+   struct irq_fwspec *fwspec,
+   unsigned long *hwirq,
+   unsigned int *type)
+{
+   if (is_of_node(fwspec->fwnode)) {
+   if (fwspec->param_count != 2)
+   return -EINVAL;
+
+   if (fwspec->param[0] > MAXIMUM_IRQ_PIN_NUM)
+   return -EINVAL;
+
+   *hwirq = fwspec->param[0];
+
+   /* If there is no valid irq type, just use the default type */
+   if ((fwspec->param[1] == IRQ_TYPE_EDGE_RISING) ||
+   (fwspec->param[1] == IRQ_TYPE_LEVEL_HIGH))
+   *type = fwspec->param[1];
+   else
+   return -EINVAL;
+
+   return 0;
+   }
+   return -EINVAL;
+}
+
+static int mbigen_irq_domain_alloc(struct irq_domain *domain,
+   unsigned int virq,
+   unsigned int nr_irqs,
+   void *args)
+{
+   struct irq_fwspec *fwspec = args;
+   irq_hw_number_t hwirq;
+   unsigned int type;
+   struct mbigen_device *mgn_chip;
+   int i, err;
+
+   err = mbigen_domain_translate(domain, fwspec, , );
+   if (err)
+   return err;
+
+   err = platform_msi_domain_alloc(domain, virq, nr_irqs);
+   if (err)
+   return err;
+
+   mgn_chip = platform_msi_get_host_data(domain);
+
+   for (i = 0; i < nr_irqs; i++)
+   irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
+ _irq_chip, mgn_chip->base);
+
+   return 0;
+}
+
+static struct irq_domain_ops mbigen_domain_ops = {
+   .translate  = mbigen_domain_translate,
+   .alloc  = mbigen_irq_domain_alloc,
+   .free   = irq_domain_free_irqs_common,
+};
+
 static int mbigen_device_probe(struct platform_device *pdev)
 {
struct mbigen_device *mgn_chip;
struct resource *res;
+   struct irq_domain *domain;
+   u32 num_pins;
 
mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
if (!mgn_chip)
@@ -48,8 +177,23 @@ static int mbigen_device_probe(struct platform_device *pdev)
if (IS_ERR(mgn_chip->base))
return PTR_ERR(mgn_chip->base);
 
+   if 

[PATCH 1/5] dt-binding: Change the mbigen binding file to support the mbigen-v1

2016-02-13 Thread MaJun
From: Ma Jun 

Add the "hisilicon,mbigen-v1" string in binding file.
Signed-off-by: Ma Jun 
---
 .../interrupt-controller/hisilicon,mbigen-v2.txt   |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
index 720f7c9..bdd1dea 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
@@ -16,7 +16,7 @@ The mbigen chip and devices connect to mbigen have the 
following properties:
 
 Mbigen main node required properties:
 ---
-- compatible: Should be "hisilicon,mbigen-v2"
+- compatible: Should be "hisilicon,mbigen-v2" or "hisilicon,mbigen-v1"
 
 - reg: Specifies the base physical address and size of the Mbigen
   registers.
-- 
1.7.1




Re: [PATCH] PCI: layerscape: add ls2085a compatible

2016-02-13 Thread Shawn Guo
On Fri, Feb 05, 2016 at 05:36:28AM +, Bhupesh Sharma wrote:
> > From: Shi, Yang
> > Sent: Friday, February 05, 2016 5:19 AM
> > 
> > On 2/4/2016 2:37 PM, Bjorn Helgaas wrote:
> > > On Wed, Jan 27, 2016 at 10:05:40AM -0800, Shi, Yang wrote:
> > >> Correct FSL folks email address to nxp.com, sorry for the
> > inconvenience.
> > >
> > > Do we need some MAINTAINERS updates in addition to the ack for this
> > patch?
> > > I see a bunch of @freescale.com addresses in MAINTAINERS.
> > 
> > I guess so if the @freescale.com address is not valid anymore.
> 
> All @freescale.com address have shifted to @nxp.com.
> 
> Leo, Minghuan - can you kindly review this patch.
> 
> Shawn - can you take this through your tree, once Leo and Minghuan have 
> reviewed the code.

This is a patch that should go through PCI subsystem tree.

Shawn

> > >> On 1/27/2016 9:32 AM, Yang Shi wrote:
> > >>> The layerscape PCI host driver needs recognize ls2085a compatible
> > >>> when using firmware with ls2085a compatible property, otherwise the
> > >>> PCI bus won't be detected even though ls2085a compatible is included
> > by the dts.
> > >>>
> > >>> Signed-off-by: Yang Shi 
> > >>> ---
> > >>>   drivers/pci/host/pci-layerscape.c | 1 +
> > >>>   1 file changed, 1 insertion(+)
> > >>>
> > >>> diff --git a/drivers/pci/host/pci-layerscape.c
> > >>> b/drivers/pci/host/pci-layerscape.c
> > >>> index 3923bed..c40d8b2 100644
> > >>> --- a/drivers/pci/host/pci-layerscape.c
> > >>> +++ b/drivers/pci/host/pci-layerscape.c
> > >>> @@ -203,6 +203,7 @@ static const struct of_device_id
> > ls_pcie_of_match[] = {
> > >>> { .compatible = "fsl,ls1021a-pcie", .data = _drvdata
> > },
> > >>> { .compatible = "fsl,ls1043a-pcie", .data = _drvdata
> > },
> > >>> { .compatible = "fsl,ls2080a-pcie", .data = _drvdata
> > },
> > >>> +   { .compatible = "fsl,ls2085a-pcie", .data = _drvdata },
> > >>> { },
> > >>>   };
> > >>>   MODULE_DEVICE_TABLE(of, ls_pcie_of_match);
> > >>>
> > >>
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majord...@vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


Re: [RFC v2a 11/12] net: ceph: use vfs_time data type instead of timespec

2016-02-13 Thread Deepa Dinamani
>> static inline void ceph_encode_timespec(struct ceph_timespec *tv,
>> const struct timespec *ts)
>> {
>> tv->tv_sec = cpu_to_le32((u32)ts->tv_sec);
>> tv->tv_nsec = cpu_to_le32((u32)ts->tv_nsec);
>> }

Pointed to decode function change in previous email.
Pasting encode function change also here:

 static inline void ceph_encode_timespec(struct ceph_timespec *tv,
-   const struct timespec *ts)
+   const struct vfs_time *ts)


-Deepa


Re: [RFC v2a 11/12] net: ceph: use vfs_time data type instead of timespec

2016-02-13 Thread Deepa Dinamani
On Sat, Feb 13, 2016 at 2:08 PM, Dave Chinner  wrote:
> On Fri, Feb 12, 2016 at 01:36:05AM -0800, Deepa Dinamani wrote:
>> The VFS inode timestamps are not y2038 safe as they use
>> struct timespec. These will be changed to use struct timespec64
>> instead and that is y2038 safe.
>> But, since the above data type conversion will break the end
>> file systems, use vfs_time aliases here to access inode times.
>>
>> These timestamps are passed in as arguments to functions
>> using inode timestamps. Hence, these need to change along
>> with vfs to support 64 bit timestamps. vfs_time helps do
>> this transition.
>>
>> Signed-off-by: Deepa Dinamani 
>
> Just a point to highlight the problem with this approach:
>
>> diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
>> index f8f2359..1273db6 100644
>> --- a/net/ceph/osd_client.c
>> +++ b/net/ceph/osd_client.c
>> @@ -2401,7 +2401,7 @@ bad:
>>   */
>>  void ceph_osdc_build_request(struct ceph_osd_request *req, u64 off,
>>   struct ceph_snap_context *snapc, u64 snap_id,
>> - struct timespec *mtime)
>> + struct vfs_time *mtime)
>>  {
>>   struct ceph_msg *msg = req->r_request;
>>   void *p;
>
> So this change assumes that mtime is not passed by reference to
> another function. If we change vfs_time to be a timespec64, then
> dereferencing in this function works fine, but passing to another
> function will not because that function will be expecting a
> timespec.
>
> That, indeed, is what happens here. A few lines into this function:
>
> if (req->r_flags & CEPH_OSD_FLAG_WRITE)
> ceph_encode_timespec(p, mtime);
>
> And that function:
>
> static inline void ceph_encode_timespec(struct ceph_timespec *tv,
> const struct timespec *ts)
> {
> tv->tv_sec = cpu_to_le32((u32)ts->tv_sec);
> tv->tv_nsec = cpu_to_le32((u32)ts->tv_nsec);
> }

I'm not sure where you picked up this encode function from.

You might be missing the patches( 9 and 10) before this?:

2b5f8e517c6fd7121fc1b890c51c6256bc21beb6 net: ceph: use vfs_time data
type instead of timespec
ca5b82952a6a522ae058ccede57ba1a71da498c5 fs: ceph: Replace timespec
data type with vfs_time
3a3ac0bdd23284c4f27a7ab1c133056c1a998075 fs: ceph: Change encode and
decode functions to use vfs_time

So encode function actually looks like

-static inline void ceph_decode_timespec(struct timespec *ts,
+static inline void ceph_decode_timespec(struct vfs_time *ts,
const struct ceph_timespec *tv)
 {
-   ts->tv_sec = (__kernel_time_t)le32_to_cpu(tv->tv_sec);
-   ts->tv_nsec = (long)le32_to_cpu(tv->tv_nsec);
+   ts->tv_sec = (s64)(u32)le32_to_cpu(tv->tv_sec);
+   ts->tv_nsec = (long)(u32)le32_to_cpu(tv->tv_nsec);
 }

There is a conversion error here which I will be fixing separately
from the series.

Also, there is another commit in my tree that is pointed to in the cover letter
that is also required here:

40219ae801c0284a233ed908b07bb468d219cbc8 net: ceph: Remove
CURRENT_TIME references

Changes have been split so that they can done in manageable chunks
just like how we are not
changing all filesystems at once.

> I think an approach that requires changes to the API without
> actually beign able to verify they are correct, fully propagated or
> don't impact on write/disk formats before the final change of the
> VFS type is not going to fly. This is the sort of subtle bug that
> can occur with type changes, and hence why I think that the fs
> developers should be left to do the conversion of their filesystem
> to support 64 bit times (i.e. approach 2b).

Approach 2b has the same problem of not being able to verify the
conversion before the vfs switch. Consider what happens if you miss changing
one of the instances of direct inode time access. So 2b is also not completely
verifiable that the changes are completely propagated. The only approach that
does this is the 2c because the data types in the individual filesystems are
decoupled from vfs data types from the get go.

Besides, anything omitted by 2a or 2b in the process of conversion should be
easily verifiable when vfs does switch. At this point, there will be
warnings in case of pointer conversion or
errors in case of pass by value, if the data types do not match.

Apart from this, process of how individual filesystems are converted
will help avoid
these bugs. Here is one of the tricks I plan to do (consider example
approach 2a):

1. Change an individual filesystem to use vfs_time.
2. Change vfs to timespec64 and verify that the targeted filesystem
will actually
compile.

Tagging tricks are also useful here.

Keep in mind that timespec = timespec64 already on 64 bit systems.
But, still there might be some tricky cases which should be okay
because it will have to reviewed by individual
filesystem maintainers.

> Any change is going to take a significant 

[PATCH v3.1 4/7] debugfs: unproxify attribute files created through debugfs_create_*()

2016-02-13 Thread Nicolai Stange
Currently, the struct file_operations associated with the attribute style
files created through the debugfs_create_*() helpers are not file
lifetime aware as they are defined by means of DEFINE_SIMPLE_ATTRIBUTE().

Thus, a lifetime managing proxy is created around the original fops each
time such a file is opened which is an unnecessary waste of resources.

Migrate all usages of DEFINE_SIMPLE_ATTRIBUTE() within debugfs itself
to DEFINE_DEBUGFS_ATTRIBUTE() in order to implement file lifetime managing
within the struct file_operations thus defined.

Introduce the debugfs_create_mode_unsafe() helper, analogous to
debugfs_create_mode(), but distinct in that it creates the files in
non-proxying operation mode through debugfs_create_file_unsafe().

Feed all struct file_operations migrated to DEFINE_DEBUGFS_ATTRIBUTE()
into debugfs_create_mode_unsafe() instead of former debugfs_create_mode().

Signed-off-by: Nicolai Stange 
---
 linux-kernel@vger.kernel.org doesn't like triple-X in subject names.
 and rejected that one.
 s/XXX/*/. Otherwise identical to triple-X'ed original.

 fs/debugfs/file.c | 123 +-
 1 file changed, 75 insertions(+), 48 deletions(-)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 2da5fb0..74de110 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -329,6 +329,24 @@ static struct dentry *debugfs_create_mode(const char 
*name, umode_t mode,
return debugfs_create_file(name, mode, parent, value, fops);
 }
 
+static struct dentry *debugfs_create_mode_unsafe(const char *name, umode_t 
mode,
+   struct dentry *parent, void *value,
+   const struct file_operations *fops,
+   const struct file_operations *fops_ro,
+   const struct file_operations *fops_wo)
+{
+   /* if there are no write bits set, make read only */
+   if (!(mode & S_IWUGO))
+   return debugfs_create_file_unsafe(name, mode, parent, value,
+   fops_ro);
+   /* if there are no read bits set, make write only */
+   if (!(mode & S_IRUGO))
+   return debugfs_create_file_unsafe(name, mode, parent, value,
+   fops_wo);
+
+   return debugfs_create_file_unsafe(name, mode, parent, value, fops);
+}
+
 static int debugfs_u8_set(void *data, u64 val)
 {
*(u8 *)data = val;
@@ -339,9 +357,9 @@ static int debugfs_u8_get(void *data, u64 *val)
*val = *(u8 *)data;
return 0;
 }
-DEFINE_SIMPLE_ATTRIBUTE(fops_u8, debugfs_u8_get, debugfs_u8_set, "%llu\n");
-DEFINE_SIMPLE_ATTRIBUTE(fops_u8_ro, debugfs_u8_get, NULL, "%llu\n");
-DEFINE_SIMPLE_ATTRIBUTE(fops_u8_wo, NULL, debugfs_u8_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_u8, debugfs_u8_get, debugfs_u8_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_u8_ro, debugfs_u8_get, NULL, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_u8_wo, NULL, debugfs_u8_set, "%llu\n");
 
 /**
  * debugfs_create_u8 - create a debugfs file that is used to read and write an 
unsigned 8-bit value
@@ -370,7 +388,7 @@ DEFINE_SIMPLE_ATTRIBUTE(fops_u8_wo, NULL, debugfs_u8_set, 
"%llu\n");
 struct dentry *debugfs_create_u8(const char *name, umode_t mode,
 struct dentry *parent, u8 *value)
 {
-   return debugfs_create_mode(name, mode, parent, value, _u8,
+   return debugfs_create_mode_unsafe(name, mode, parent, value, _u8,
   _u8_ro, _u8_wo);
 }
 EXPORT_SYMBOL_GPL(debugfs_create_u8);
@@ -385,9 +403,9 @@ static int debugfs_u16_get(void *data, u64 *val)
*val = *(u16 *)data;
return 0;
 }
-DEFINE_SIMPLE_ATTRIBUTE(fops_u16, debugfs_u16_get, debugfs_u16_set, "%llu\n");
-DEFINE_SIMPLE_ATTRIBUTE(fops_u16_ro, debugfs_u16_get, NULL, "%llu\n");
-DEFINE_SIMPLE_ATTRIBUTE(fops_u16_wo, NULL, debugfs_u16_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_u16, debugfs_u16_get, debugfs_u16_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_u16_ro, debugfs_u16_get, NULL, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_u16_wo, NULL, debugfs_u16_set, "%llu\n");
 
 /**
  * debugfs_create_u16 - create a debugfs file that is used to read and write 
an unsigned 16-bit value
@@ -416,7 +434,7 @@ DEFINE_SIMPLE_ATTRIBUTE(fops_u16_wo, NULL, debugfs_u16_set, 
"%llu\n");
 struct dentry *debugfs_create_u16(const char *name, umode_t mode,
  struct dentry *parent, u16 *value)
 {
-   return debugfs_create_mode(name, mode, parent, value, _u16,
+   return debugfs_create_mode_unsafe(name, mode, parent, value, _u16,
   _u16_ro, _u16_wo);
 }
 EXPORT_SYMBOL_GPL(debugfs_create_u16);
@@ -431,9 +449,9 @@ static int debugfs_u32_get(void *data, u64 *val)
*val = *(u32 *)data;
return 0;
 }
-DEFINE_SIMPLE_ATTRIBUTE(fops_u32, debugfs_u32_get, debugfs_u32_set, 

[PATCH v3 7/7] debugfs: unproxify files created through debugfs_create_u32_array()

2016-02-13 Thread Nicolai Stange
The struct file_operations u32_array_fops associated with files created
through debugfs_create_u32_array() has been lifetime aware already:
everything needed for subsequent operation is copied to a ->f_private
buffer at file opening time in u32_array_open(). Now, ->open() is always
protected against file removal issues by the debugfs core.

There is no need for the debugfs core to wrap the u32_array_fops
with a file lifetime managing proxy.

Make debugfs_create_u32_array() create its files in non-proxying operation
mode by means of debugfs_create_file_unsafe().

Signed-off-by: Nicolai Stange 
---
 fs/debugfs/file.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 036ec3f..1a03e99 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -993,7 +993,8 @@ struct dentry *debugfs_create_u32_array(const char *name, 
umode_t mode,
data->array = array;
data->elements = elements;
 
-   return debugfs_create_file(name, mode, parent, data, _array_fops);
+   return debugfs_create_file_unsafe(name, mode, parent, data,
+   _array_fops);
 }
 EXPORT_SYMBOL_GPL(debugfs_create_u32_array);
 
-- 
2.7.1



Re: [RESEND v7 1/5] mfd: hi655x: Add document for mfd hi665x PMIC

2016-02-13 Thread Chen Feng
Thanks for your review.

On 2016/2/12 0:59, Lee Jones wrote:
> On Mon, 01 Feb 2016, Chen Feng wrote:
> 
>> DT bindings for hisilicon hi655x MFD PMIC chip.
>>
>> Signed-off-by: Chen Feng 
>> Signed-off-by: Fei Wang 
>> Signed-off-by: Xinwei Kong 
>> Reviewed-by: Haojian Zhuang 
>> ---
>>  .../devicetree/bindings/mfd/hisilicon,hi655x.txt   | 27 
>> ++
>>  1 file changed, 27 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt 
>> b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
>> new file mode 100644
>> index 000..5edc310
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
>> @@ -0,0 +1,27 @@
>> +Hisilicon hi655x Power Management Integrated Circuit (PMIC)
>> +
>> +The hardware layout for access PMIC Hi655x from AP SoC Hi6220.
>> +Between PMIC Hi655x and Hi6220, the physical signal channel is SSI.
>> +We can use memory-mapped I/O to communicate.
>> +
>> +++ +-+
>> +|| | |
>> +|Hi6220  |   SSI bus   |   Hi655x|
>> +||-| |
>> +||(REGMAP_MMIO)| |
>> +++ +-+
>> +
>> +Required properties:
>> +- compatible: Should be "hisilicon,hi655x-pmic"
>> +- reg: Base address of PMIC on hi6220 soc
> 
> s/hi6220 soc/Hi6220 SoC/
> 
>> +- interrupt-controller: Hi655x has internal IRQs (has own IRQ domain).
>> +- pmic-gpios: The gpio used by PMIC irq.
> 
> s/gpio/GPIO/
> s/irq/IRQ/
> 

I will change this and send a new V8 version.

> These are always easier to read in this format:
> 
> - compatible: Should be "hisilicon,hi655x-pmic"
> - reg:Base address of PMIC on hi6220 soc
> - interrupt-controller:   Hi655x has internal IRQs (has own IRQ domain).
> - pmic-gpios: The gpio used by PMIC irq.
> 
>> +Example:
>> +pmic: pmic@f800 {
>> +compatible = "hisilicon,hi655x-pmic";
>> +reg = <0x0 0xf800 0x0 0x1000>;
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>> +pmic-gpios = < 2 GPIO_ACTIVE_HIGH>;
>> +}
> 



[PATCH v3 6/7] debugfs: unproxify files created through debugfs_create_blob()

2016-02-13 Thread Nicolai Stange
Currently, the struct file_operations fops_blob associated with files
created through the debugfs_create_blob() helpers are not file
lifetime aware.

Thus, a lifetime managing proxy is created around fops_blob each time such
a file is opened which is an unnecessary waste of resources.

Implement file lifetime management for the fops_bool file_operations.
Namely, make read_file_blob() safe gainst file removals by means of
debugfs_use_file_start() and debugfs_use_file_finish().

Make debugfs_create_blob() create its files in non-proxying operation mode
by means of debugfs_create_file_unsafe().

Signed-off-by: Nicolai Stange 
---
 fs/debugfs/file.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index da24e0b..036ec3f 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -843,8 +843,15 @@ static ssize_t read_file_blob(struct file *file, char 
__user *user_buf,
  size_t count, loff_t *ppos)
 {
struct debugfs_blob_wrapper *blob = file->private_data;
-   return simple_read_from_buffer(user_buf, count, ppos, blob->data,
-   blob->size);
+   ssize_t r;
+   int srcu_idx;
+
+   r = debugfs_use_file_start(F_DENTRY(file), _idx);
+   if (likely(!r))
+   r = simple_read_from_buffer(user_buf, count, ppos, blob->data,
+   blob->size);
+   debugfs_use_file_finish(srcu_idx);
+   return r;
 }
 
 static const struct file_operations fops_blob = {
@@ -881,7 +888,7 @@ struct dentry *debugfs_create_blob(const char *name, 
umode_t mode,
   struct dentry *parent,
   struct debugfs_blob_wrapper *blob)
 {
-   return debugfs_create_file(name, mode, parent, blob, _blob);
+   return debugfs_create_file_unsafe(name, mode, parent, blob, _blob);
 }
 EXPORT_SYMBOL_GPL(debugfs_create_blob);
 
-- 
2.7.1



[PATCH v3 5/7] debugfs: unproxify files created through debugfs_create_bool()

2016-02-13 Thread Nicolai Stange
Currently, the struct file_operations fops_bool associated with files
created through the debugfs_create_bool() helpers are not file
lifetime aware.

Thus, a lifetime managing proxy is created around fops_bool each time such
a file is opened which is an unnecessary waste of resources.

Implement file lifetime management for the fops_bool file_operations.
Namely, make debugfs_read_file_bool() and debugfs_write_file_bool() safe
against file removals by means of debugfs_use_file_start() and
debugfs_use_file_finish().

Make debugfs_create_bool() create its files in non-proxying operation mode
through debugfs_create_mode_unsafe().

Finally, purge debugfs_create_mode() as debugfs_create_bool() had been its
last user.

Signed-off-by: Nicolai Stange 
---
 fs/debugfs/file.c | 41 -
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 74de110..da24e0b 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -313,22 +313,6 @@ ssize_t debugfs_attr_write(struct file *file, const char 
__user *buf,
 }
 EXPORT_SYMBOL_GPL(debugfs_attr_write);
 
-static struct dentry *debugfs_create_mode(const char *name, umode_t mode,
- struct dentry *parent, void *value,
- const struct file_operations *fops,
- const struct file_operations *fops_ro,
- const struct file_operations *fops_wo)
-{
-   /* if there are no write bits set, make read only */
-   if (!(mode & S_IWUGO))
-   return debugfs_create_file(name, mode, parent, value, fops_ro);
-   /* if there are no read bits set, make write only */
-   if (!(mode & S_IRUGO))
-   return debugfs_create_file(name, mode, parent, value, fops_wo);
-
-   return debugfs_create_file(name, mode, parent, value, fops);
-}
-
 static struct dentry *debugfs_create_mode_unsafe(const char *name, umode_t 
mode,
struct dentry *parent, void *value,
const struct file_operations *fops,
@@ -757,9 +741,17 @@ ssize_t debugfs_read_file_bool(struct file *file, char 
__user *user_buf,
   size_t count, loff_t *ppos)
 {
char buf[3];
-   bool *val = file->private_data;
+   bool val;
+   int r, srcu_idx;
+
+   r = debugfs_use_file_start(F_DENTRY(file), _idx);
+   if (likely(!r))
+   val = *(bool *)file->private_data;
+   debugfs_use_file_finish(srcu_idx);
+   if (r)
+   return r;
 
-   if (*val)
+   if (val)
buf[0] = 'Y';
else
buf[0] = 'N';
@@ -775,6 +767,7 @@ ssize_t debugfs_write_file_bool(struct file *file, const 
char __user *user_buf,
char buf[32];
size_t buf_size;
bool bv;
+   int r, srcu_idx;
bool *val = file->private_data;
 
buf_size = min(count, (sizeof(buf)-1));
@@ -782,8 +775,14 @@ ssize_t debugfs_write_file_bool(struct file *file, const 
char __user *user_buf,
return -EFAULT;
 
buf[buf_size] = '\0';
-   if (strtobool(buf, ) == 0)
-   *val = bv;
+   if (strtobool(buf, ) == 0) {
+   r = debugfs_use_file_start(F_DENTRY(file), _idx);
+   if (likely(!r))
+   *val = bv;
+   debugfs_use_file_finish(srcu_idx);
+   if (r)
+   return r;
+   }
 
return count;
 }
@@ -835,7 +834,7 @@ static const struct file_operations fops_bool_wo = {
 struct dentry *debugfs_create_bool(const char *name, umode_t mode,
   struct dentry *parent, bool *value)
 {
-   return debugfs_create_mode(name, mode, parent, value, _bool,
+   return debugfs_create_mode_unsafe(name, mode, parent, value, _bool,
   _bool_ro, _bool_wo);
 }
 EXPORT_SYMBOL_GPL(debugfs_create_bool);
-- 
2.7.1



[PATCH v3 3/7] debugfs: add support for self-protecting attribute file fops

2016-02-13 Thread Nicolai Stange
In order to protect them against file removal issues, debugfs_create_file()
creates a lifetime managing proxy around each struct file_operations
handed in.

In cases where this struct file_operations is able to manage file lifetime
by itself already, the proxy created by debugfs is a waste of resources.

The most common class of struct file_operations given to debugfs are those
defined by means of the DEFINE_SIMPLE_ATTRIBUTE() macro.

Introduce a DEFINE_DEBUGFS_ATTRIBUTE() macro to allow any
struct file_operations of this class to be easily made file lifetime aware
and thus, to be operated unproxied.

Specifically, introduce debugfs_attr_read() and debugfs_attr_write()
which wrap simple_attr_read() and simple_attr_write() under the protection
of a debugfs_use_file_start()/debugfs_use_file_finish() pair.

Make DEFINE_DEBUGFS_ATTRIBUTE() set the defined struct file_operations'
->read() and ->write() members to these wrappers.

Export debugfs_create_file_unsafe() in order to allow debugfs users to
create their files in non-proxying operation mode.

Finally, add a Coccinelle script chasing down possible candidates
for a DEFINE_SIMPLE_ATTRIBUTE()/debugfs_create_file() to
DEFINE_DEBUGFS_ATTRIBUTE()/debugfs_create_file_unsafe() migration.

Signed-off-by: Nicolai Stange 
---
 fs/debugfs/file.c  | 28 +
 fs/debugfs/inode.c | 28 +
 include/linux/debugfs.h| 26 +
 .../api/debugfs/debugfs_simple_attr.cocci  | 68 ++
 4 files changed, 150 insertions(+)
 create mode 100644 scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index f638dbc..2da5fb0 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -285,6 +285,34 @@ const struct file_operations 
debugfs_full_proxy_file_operations = {
.open = full_proxy_open,
 };
 
+ssize_t debugfs_attr_read(struct file *file, char __user *buf,
+   size_t len, loff_t *ppos)
+{
+   ssize_t ret;
+   int srcu_idx;
+
+   ret = debugfs_use_file_start(F_DENTRY(file), _idx);
+   if (likely(!ret))
+   ret = simple_attr_read(file, buf, len, ppos);
+   debugfs_use_file_finish(srcu_idx);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(debugfs_attr_read);
+
+ssize_t debugfs_attr_write(struct file *file, const char __user *buf,
+size_t len, loff_t *ppos)
+{
+   ssize_t ret;
+   int srcu_idx;
+
+   ret = debugfs_use_file_start(F_DENTRY(file), _idx);
+   if (likely(!ret))
+   ret = simple_attr_write(file, buf, len, ppos);
+   debugfs_use_file_finish(srcu_idx);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(debugfs_attr_write);
+
 static struct dentry *debugfs_create_mode(const char *name, umode_t mode,
  struct dentry *parent, void *value,
  const struct file_operations *fops,
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 42a9b34..f95e355 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -368,6 +368,33 @@ struct dentry *debugfs_create_file(const char *name, 
umode_t mode,
 }
 EXPORT_SYMBOL_GPL(debugfs_create_file);
 
+/**
+ * debugfs_create_file_unsafe - create a file in the debugfs filesystem
+ * @name: a pointer to a string containing the name of the file to create.
+ * @mode: the permission that the file should have.
+ * @parent: a pointer to the parent dentry for this file.  This should be a
+ *  directory dentry if set.  If this parameter is NULL, then the
+ *  file will be created in the root of the debugfs filesystem.
+ * @data: a pointer to something that the caller will want to get to later
+ *on.  The inode.i_private pointer will point to this value on
+ *the open() call.
+ * @fops: a pointer to a struct file_operations that should be used for
+ *this file.
+ *
+ * debugfs_create_file_unsafe() is completely analogous to
+ * debugfs_create_file(), the only difference being that the fops
+ * handed it will not get protected against file removals by the
+ * debugfs core.
+ *
+ * It is your responsibility to protect your struct file_operation
+ * methods against file removals by means of debugfs_use_file_start()
+ * and debugfs_use_file_finish(). ->open() is still protected by
+ * debugfs though.
+ *
+ * Any struct file_operations defined by means of
+ * DEFINE_DEBUGFS_ATTRIBUTE() is protected against file removals and
+ * thus, may be used here.
+ */
 struct dentry *debugfs_create_file_unsafe(const char *name, umode_t mode,
   struct dentry *parent, void *data,
   const struct file_operations *fops)
@@ -378,6 +405,7 @@ struct dentry *debugfs_create_file_unsafe(const char *name, 
umode_t mode,
_noop_file_operations,

[PATCH] MAINTAINERS: Add co-maintainer for remoteproc subsystems

2016-02-13 Thread Bjorn Andersson
Add myself as co-maintainer for the remote processor related subsystems,
as agreed with Ohad.

Signed-off-by: Bjorn Andersson 
---
 MAINTAINERS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4ebe2e886d36..f51056b02fcd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4989,6 +4989,7 @@ F:include/linux/hw_random.h
 
 HARDWARE SPINLOCK CORE
 M: Ohad Ben-Cohen 
+M: Bjorn Andersson 
 S: Maintained
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
 F: Documentation/hwspinlock.txt
@@ -9170,6 +9171,7 @@ F:include/linux/regmap.h
 
 REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
 M: Ohad Ben-Cohen 
+M: Bjorn Andersson 
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
 S: Maintained
 F: drivers/remoteproc/
@@ -9178,6 +9180,7 @@ F:include/linux/remoteproc.h
 
 REMOTE PROCESSOR MESSAGING (RPMSG) SUBSYSTEM
 M: Ohad Ben-Cohen 
+M: Bjorn Andersson 
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
 S: Maintained
 F: drivers/rpmsg/
-- 
2.5.0



[PATCH v3 2/7] debugfs: prevent access to removed files' private data

2016-02-13 Thread Nicolai Stange
Upon return of debugfs_remove()/debugfs_remove_recursive(), it might
still be attempted to access associated private file data through
previously opened struct file objects. If that data has been freed by
the caller of debugfs_remove*() in the meanwhile, the reading/writing
process would either encounter a fault or, if the memory address in
question has been reassigned again, unrelated data structures could get
overwritten.

However, since debugfs files are seldomly removed, usually from module
exit handlers only, the impact is very low.

Currently, there are ~1000 call sites of debugfs_create_file() spread
throughout the whole tree and touching all of those struct file_operations
in order to make them file removal aware by means of checking the result of
debugfs_use_file_start() from within their methods is unfeasible.

Instead, wrap the struct file_operations by a lifetime managing proxy at
file open:
- In debugfs_create_file(), the original fops handed in has got stashed
  away in ->d_fsdata already.
- In debugfs_create_file(), install a proxy file_operations factory,
  debugfs_full_proxy_file_operations, at ->i_fop.

This proxy factory has got an ->open() method only. It carries out some
lifetime checks and if successful, dynamically allocates and sets up a new
struct file_operations proxy at ->f_op. Afterwards, it forwards to the
->open() of the original struct file_operations in ->d_fsdata, if any.

The dynamically set up proxy at ->f_op has got a lifetime managing wrapper
set for each of the methods defined in the original struct file_operations
in ->d_fsdata.

Its ->release()er frees the proxy again and forwards to the original
->release(), if any.

In order not to mislead the VFS layer, it is strictly necessary to leave
those fields blank in the proxy that have been NULL in the original
struct file_operations also, i.e. aren't supported. This is why there is a
need for dynamically allocated proxies. The choice made not to allocate a
proxy instance for every dentry at file creation, but for every
struct file object instantiated thereof is justified by the expected usage
pattern of debugfs, namely that in general very few files get opened more
than once at a time.

The wrapper methods set in the struct file_operations implement lifetime
managing by means of the SRCU protection facilities already in place for
debugfs:
They set up a SRCU read side critical section and check whether the dentry
is still alive by means of debugfs_use_file_start(). If so, they forward
the call to the original struct file_operation stored in ->d_fsdata, still
under the protection of the SRCU read side critical section.
This SRCU read side critical section prevents any pending debugfs_remove()
and friends to return to their callers. Since a file's private data must
only be freed after the return of debugfs_remove(), the ongoing proxied
call is guarded against any file removal race.

If, on the other hand, the initial call to debugfs_use_file_start() detects
that the dentry is dead, the wrapper simply returns -EIO and does not
forward the call. Note that the ->poll() wrapper is special in that its
signature does not allow for the return of arbitrary -EXXX values and thus,
POLLHUP is returned here.

In order not to pollute debugfs with wrapper definitions that aren't ever
needed, I chose not to define a wrapper for every struct file_operations
method possible. Instead, a wrapper is defined only for the subset of
methods which are actually set by any debugfs users.
Currently, these are:

  ->llseek()
  ->read()
  ->write()
  ->unlocked_ioctl()
  ->poll()

The ->release() wrapper is special in that it does not protect the original
->release() in any way from dead files in order not to leak resources.
Thus, any ->release() handed to debugfs must implement file lifetime
management manually, if needed.
For only 33 out of a total of 434 releasers handed in to debugfs, it could
not be verified immediately whether they access data structures that might
have been freed upon a debugfs_remove() return in the meanwhile.

Export debugfs_use_file_start() and debugfs_use_file_finish() in order to
allow any ->release() to manually implement file lifetime management.

For a set of common cases of struct file_operations implemented by the
debugfs_core itself, future patches will incorporate file lifetime
management directly within those in order to allow for their unproxied
operation. Rename the original, non-proxying "debugfs_create_file()" to
"debugfs_create_file_unsafe()" and keep it for future internal use by
debugfs itself. Factor out code common to both into the new
__debugfs_create_file().

Signed-off-by: Nicolai Stange 
---
 fs/debugfs/file.c   | 157 +++-
 fs/debugfs/inode.c  |  70 ++---
 fs/debugfs/internal.h   |   6 +-
 include/linux/debugfs.h |  18 ++
 4 files changed, 224 insertions(+), 27 deletions(-)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 

[PATCH v3 1/7] debugfs: prevent access to possibly dead file_operations at file open

2016-02-13 Thread Nicolai Stange
Nothing prevents a dentry found by path lookup before a return of
__debugfs_remove() to actually get opened after that return. Now, after
the return of __debugfs_remove(), there are no guarantees whatsoever
regarding the memory the corresponding inode's file_operations object
had been kept in.

Since __debugfs_remove() is seldomly invoked, usually from module exit
handlers only, the race is hard to trigger and the impact is very low.

A discussion of the problem outlined above as well as a suggested
solution can be found in the (sub-)thread rooted at

  http://lkml.kernel.org/g/20130401203445.ga20...@zeniv.linux.org.uk
  ("Yet another pipe related oops.")

Basically, Greg KH suggests to introduce an intermediate fops and
Al Viro points out that a pointer to the original ones may be stored in
->d_fsdata.

Follow this line of reasoning:
- Add SRCU as a reverse dependency of DEBUG_FS.
- Introduce a srcu_struct object for the debugfs subsystem.
- In debugfs_create_file(), store a pointer to the original
  file_operations object in ->d_fsdata.
- Make debugfs_remove() and debugfs_remove_recursive() wait for a
  SRCU grace period after the dentry has been delete()'d and before they
  return to their callers.
- Introduce an intermediate file_operations object named
  "debugfs_open_proxy_file_operations". It's ->open() functions checks,
  under the protection of a SRCU read lock, whether the dentry is still
  alive, i.e. has not been d_delete()'d and if so, tries to acquire a
  reference on the owning module.
  On success, it sets the file object's ->f_op to the original
  file_operations and forwards the ongoing open() call to the original
  ->open().
- For clarity, rename the former debugfs_file_operations to
  debugfs_noop_file_operations -- they are in no way canonical.

The choice of SRCU over "normal" RCU is justified by the fact, that the
former may also be used to protect ->i_private data from going away
during the execution of a file's readers and writers which may (and do)
sleep.

Finally, introduce the fs/debugfs/internal.h header containing some
declarations internal to the debugfs implementation.

Signed-off-by: Nicolai Stange 
---
 fs/debugfs/file.c   | 92 -
 fs/debugfs/inode.c  | 13 ++-
 fs/debugfs/internal.h   | 24 +
 include/linux/debugfs.h |  3 --
 lib/Kconfig.debug   |  1 +
 5 files changed, 128 insertions(+), 5 deletions(-)
 create mode 100644 fs/debugfs/internal.h

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index d2ba12e..3377e0fe 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -22,6 +22,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include "internal.h"
 
 static ssize_t default_read_file(struct file *file, char __user *buf,
 size_t count, loff_t *ppos)
@@ -35,13 +38,100 @@ static ssize_t default_write_file(struct file *file, const 
char __user *buf,
return count;
 }
 
-const struct file_operations debugfs_file_operations = {
+const struct file_operations debugfs_noop_file_operations = {
.read = default_read_file,
.write =default_write_file,
.open = simple_open,
.llseek =   noop_llseek,
 };
 
+/**
+ * debugfs_use_file_start - mark the beginning of file data access
+ * @file: the file object whose data is being accessed.
+ * @srcu_idx: a pointer to some memory to store a SRCU index in.
+ *
+ * Up to a matching call to debugfs_use_file_finish(), any
+ * successive call into the file removing functions debugfs_remove()
+ * and debugfs_remove_recursive() will block. Since associated private
+ * file data may only get freed after a successful return of any of
+ * the removal functions, you may safely access it after a successful
+ * call to debugfs_use_file_start() without worrying about
+ * lifetime issues.
+ *
+ * If -%EIO is returned, the file has already been removed and thus,
+ * it is not safe to access any of its data. If, on the other hand,
+ * it is allowed to access the file data, zero is returned.
+ *
+ * Regardless of the return code, any call to
+ * debugfs_use_file_start() must be followed by a matching call
+ * to debugfs_use_file_finish().
+ */
+static int debugfs_use_file_start(const struct dentry *dentry, int *srcu_idx)
+   __acquires(_srcu)
+{
+   *srcu_idx = srcu_read_lock(_srcu);
+   barrier();
+   if (d_unlinked(dentry))
+   return -EIO;
+   return 0;
+}
+
+/**
+ * debugfs_use_file_finish - mark the end of file data access
+ * @srcu_idx: the SRCU index "created" by a former call to
+ *debugfs_use_file_start().
+ *
+ * Allow any ongoing concurrent call into debugfs_remove() or
+ * debugfs_remove_recursive() blocked by a former call to
+ * debugfs_use_file_start() to proceed and return to its caller.
+ */
+static void debugfs_use_file_finish(int srcu_idx) __releases(_srcu)
+{
+   srcu_read_unlock(_srcu, srcu_idx);
+}
+
+#define 

[PATCH v3 0/7] fix debugfs file removal races

2016-02-13 Thread Nicolai Stange
Original v2 thread is here:

  http://lkml.kernel.org/g/87fux3memd@gmail.com

In the discussion of v2, it turned out that touching each and every of
the ~1000 debugfs users in order to make them save against file
removals is unfeasible.

Thus, v3 takes a different approach: every struct file_operations
handed to debugfs is wrapped by a protecting proxy in [2/7].  Only
those struct file_operations which are easy to fix directly,
i.e. those defined by debugfs itself, opt-out from this proxying in
[3-7/7].


The Coccinelle people are CC'd because of [3/7].
Many thanks to J. Lawall who helped me very much at #cocci@freenode
in getting this done!


The SRCU part really needs some fresh review: in v2 the
rcu_assign_pointer()'ed and srcu_derefence()'d ->d_fsdata has been
effectively used as an indication of whether a file is dead or not.

With the full proxy approach in v3, ->d_fsdata can't be cleared out at
file removal because open files might still hold a reference to it and
those must be released again from the proxy's ->release().

Thus, the properly memory- and compiler-barriered accesses to
->d_fsdata have now been replaced by completely unbarriered d_delete()
and d_unlinked() calls in debugfs_use_file_start() and
debugfs_remove() (all in [1/7] now).

I believe that no extra barriers are needed:
The SRCU read side critical sections around any file usage looks like this:
srcu_read_lock();
if(d_unlinked(dentry)) {
  srcu_read_unlock();
  return -EIO
}
cope_around_with(d_inode(dentry)->i_private);
srcu_read_unlock()
- srcu_read_lock() and srcu_read_unlock() already contain a barrier()
  each. Thus, the compiler is forced to make the dentry's state being
  read at least once within the read side critical section.  
- I don't care for speculative reads to the file's private data
  in cope_around_with().
- Writes in cope_around_with() should be properly handled by the control
  dependency in that they don't occur on the bus if d_unlinked() holds.
  Furthermore, any writes in cope_around_with() are emitted by the
  compiler before the srcu_read_unlock().

For the file removing side of things, the SRCU usage looks like this:
  d_delete(dentry);
  synchronize_srcu();
  free(d_inode(dentry)->i_private);
d_delete() is defined in another compilation unit. Thus, its call can't be
reorded with the one to synchronize_srcu() and the dentry state is written
(on that CPU) before synchronize_srcu() is entered.


Changes v2 -> v3:
  [1/7] ("debugfs: prevent access to possibly dead file_operations at file 
open")
   - move the definition of the debugfs_use_file_start() and _end() from former
 [2/2] to [1/7]. Also, they've been renamed from debugfs_file_use_data*().
   - Make the ->open() proxy use the debugfs_use_file_*() helpers.
   - In debugfs_use_file_start(), use d_unlinked() rather than
 (->d_fsdata == NULL) as a flag whether the dentry is dead.
   - Make the ->open() proxy include the forwarded call to the original fops' 
->open
 within the SRCU read side critical section.
   - debugfs_proxy_file_operations has been renamed to
 "debugfs_open_proxy_file_operations"  to distinguish it from the full proxy
 introduced in [2/7].

  [2/7] ("debugfs: prevent access to removed files' private data")
   - This one has changed completely: instead of providing file
 removal-safe fops helpers to opt-into at the debugfs users, the
 original struct file_operations get completely and
 unconditionally proxied now.

  [3-7/7]
   New. Opt-out from the full proxying introduced in [2/7] for some
   special case struct file_operations provided by debugfs itself.


Changes v1 -> v2:
  [1/2] ("debugfs: prevent access to possibly dead file_operations at file 
open")
   - Resolve trivial diff conflict in debugfs_remove_recursive():
 in the meanwhile, an unrelated 'mutex_unlock(...)' had been rewritten to
 'inode_unlock(...)' which broke the diff's context.
   - Introduce the fs/debugfs/internal.h header and move the declarations of
 debugfs_noop_file_operations, debugfs_proxy_file_operations and
 debugfs_rcu from include/linux/debugfs.h thereinto. Include this header
 from file.c and inode.c.
   - Add a word about the new internal header to the commit message.
   - Move the inclusion of linux/srcu.h from include/linux/debugfs.h
 into file.c and inode.c respectively.

  [2/2] ("debugfs: prevent access to removed files' private data")
   - Move the definitions of debugfs_file_use_data_start() and
 debugfs_file_use_data_finish() from include/linux/debugfs.h to
 file.c. Export them and keep their declarations in debugfs.h,
   - In order to be able to attach proper __acquires() and __releases() tags
 to the decalarations of debugfs_file_use_data_*() in debugfs.h,
 move the debugfs_srcu declaration from internal.h into debugfs.h.
   - Since the definitions as well as the docstrings of
 debugfs_file_use_data_*() have been moved into file.c,
 

Re: [PATCH 4/4] xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.

2016-02-13 Thread Boris Ostrovsky

On 02/11/2016 04:10 PM, Konrad Rzeszutek Wilk wrote:


This patch fixes the issue by:
  1) Use kzalloc to initialize to a well known state.
  2) Put 'struct pci_sysdata' at the start of 'pcifront_sd'. That
 way access to the 'node' will access the right offset.

CC: sta...@vger.kernel.org
Signed-off-by: Konrad Rzeszutek Wilk 


Reviewed-by: Boris Ostrovsky 

(This, btw, is the second time we got bitten by pcifront_sd bit not 
being pci_sysdata. dc4fdaf0e48 was a workaround for a similar problem 
and we should have fixed it then).


-boris


[lkp] [usb] 368540a661: BUG: sleeping function called from invalid context at mm/page_alloc.c:3208

2016-02-13 Thread kernel test robot
FYI, we noticed the below changes on

https://github.com/0day-ci/linux 
Robert-Baldyga/usb-gadget-composite-introduce-new-function-API/20160203-205850
commit 368540a661833b00a81b0e9c7741d8dfd89c13f0 ("usb: gadget: f_printer: 
conversion to new API")


+--+++
|  | 
36eec5a911 | 368540a661 |
+--+++
| boot_successes   | 88 
| 8  |
| boot_failures| 4  
| 16 |
| BUG:kernel_test_oversize | 2  
||
| IP-Config:Auto-configuration_of_network_failed   | 2  
| 2  |
| BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c | 0  
| 16 |
| backtrace:cpu_startup_entry  | 0  
| 1  |
| backtrace:do_group_exit  | 0  
| 2  |
| backtrace:SyS_exit_group | 0  
| 2  |
| backtrace:do_execve  | 0  
| 3  |
| backtrace:run_init_process   | 0  
| 3  |
| backtrace:ring_buffer_producer_thread| 0  
| 1  |
| backtrace:SYSC_newstat   | 0  
| 1  |
| backtrace:SyS_newstat| 0  
| 1  |
| backtrace:_do_fork   | 0  
| 1  |
| backtrace:SyS_clone  | 0  
| 1  |
| WARNING:at_kernel/sched/core.c:#__might_sleep()  | 0  
| 1  |
| backtrace:hub_event  | 0  
| 1  |
| backtrace:vfs_write  | 0  
| 1  |
| backtrace:SyS_write  | 0  
| 1  |
+--+++



[   18.061859] dummy_udc dummy_udc.0: enabled ep1in-bulk (ep1in-bulk) maxpacket 
512 stream disabled
[   18.064543] dummy_udc dummy_udc.0: enabled ep2out-bulk (ep2out-bulk) 
maxpacket 512 stream disabled
[   18.064543] dummy_udc dummy_udc.0: enabled ep2out-bulk (ep2out-bulk) 
maxpacket 512 stream disabled
[   18.067290] BUG: sleeping function called from invalid context at 
mm/page_alloc.c:3208
[   18.067290] BUG: sleeping function called from invalid context at 
mm/page_alloc.c:3208
[   18.070263] in_atomic(): 1, irqs_disabled(): 1, pid: 190, name: initctl
[   18.070263] in_atomic(): 1, irqs_disabled(): 1, pid: 190, name: initctl
[   18.072288] 4 locks held by initctl/190:
[   18.072288] 4 locks held by initctl/190:
[   18.073493]  #0: 
[   18.073493]  #0:  ( 
(&(ptlock_ptr(page))->rlock&(ptlock_ptr(page))->rlock#2#2){..}){..}, 
at: , at: [] unmap_single_vma+0x2c4/0x5f1
[] unmap_single_vma+0x2c4/0x5f1
[   18.076730]  #1: 
[   18.076730]  #1:  ( (rcu_read_lockrcu_read_lock){..}){..}, at: , at: 
[] rcu_lock_acquire+0x0/0x20
[] rcu_lock_acquire+0x0/0x20
[   18.079469]  #2: 
[   18.079469]  #2:  ( ((_hcd->timer)(_hcd->timer)){..}){..}, 
at: , at: [] call_timer_fn+0x5/0x1f9
[] call_timer_fn+0x5/0x1f9
[   18.082291]  #3: 
[   18.082291]  #3:  ( 
(&(>lock)->rlock&(>lock)->rlock){..}){..}, at: , at: 
[] composite_setup+0x799/0x1333
[] composite_setup+0x799/0x1333
[   18.085333] CPU: 0 PID: 190 Comm: initctl Not tainted 
4.5.0-rc2-00069-g368540a #2
[   18.085333] CPU: 0 PID: 190 Comm: initctl Not tainted 
4.5.0-rc2-00069-g368540a #2
[   18.087613]  
[   18.087613]   880013c03a60 880013c03a60 
8424e680 8424e680 8800151b 8800151b

[   18.089986]  880013c03a80
[   18.089986]  880013c03a80 840e0801 840e0801 
   

[   18.092342]  880013c03ac0
[   18.092342]  880013c03ac0 840e08e8 840e08e8 
84b7ca02 84b7ca02  

[   18.094730] Call Trace:
[   18.094730] Call Trace:
[   18.095501]   
[   18.095501][] dump_stack+0x4b/0x63
 [] dump_stack+0x4b/0x63
[   18.097336]  [] ___might_sleep+0x11e/0x123
[   18.097336]  [] ___might_sleep+0x11e/0x123
[   18.099079]  [] __might_sleep+0xe2/0xee
[   18.099079]  [] __might_sleep+0xe2/0xee
[   18.100740]  [] 

[lkp] [blk] 868f2f0b72: INFO: trying to register non-static key.

2016-02-13 Thread kernel test robot
FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git 
for-4.6/drivers
commit 868f2f0b72068a097508b6e8870a8950fd8eb7ef ("blk-mq: dynamic h/w context 
count")


+---+++
|   | 3984aa5520 | 
868f2f0b72 |
+---+++
| boot_successes| 22 | 2
  |
| boot_failures | 0  | 64   
  |
| INFO:trying_to_register_non-static_key| 0  | 52   
  |
| backtrace:do_mount| 0  | 52   
  |
| backtrace:SyS_mount   | 0  | 52   
  |
| BUG:unable_to_handle_kernel   | 0  | 12   
  |
| Oops  | 0  | 12   
  |
| RIP:blk_mq_init_allocated_queue   | 0  | 6
  |
| Kernel_panic-not_syncing:Fatal_exception  | 0  | 9
  |
| backtrace:blk_mq_init_allocated_queue | 0  | 6
  |
| backtrace:blk_mq_init_queue   | 0  | 6
  |
| backtrace:init| 0  | 6
  |
| backtrace:kernel_init_freeable| 0  | 6
  |
| Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 0  | 3
  |
| RIP:__lock_acquire| 0  | 4
  |
| RIP:do_raw_spin_trylock   | 0  | 1
  |
| backtrace:cpu_startup_entry   | 0  | 2
  |
| backtrace:vmstat_shepherd | 0  | 3
  |
+---+++



[   10.685723] pidof (165) used greatest stack depth: 14016 bytes left
[   11.087599] logger (465) used greatest stack depth: 13944 bytes left
[   11.182853] UDF-fs: warning (device vdb): udf_fill_super: No partition found 
(2)
[   11.196223] INFO: trying to register non-static key.
[   11.197332] the code is fine but needs lockdep annotation.
[   11.198502] turning off the locking correctness validator.
[   11.199679] CPU: 0 PID: 515 Comm: mount Not tainted 4.5.0-rc2-5-g868f2f0 
#120
[   11.201365] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   11.203331]   88000dd2fa78 813eeaf0 

[   11.205100]  88000dd2fae0 810ad496 81039aa5 
88000dd2faa0
[   11.206961]  000181039acb  02d0 

[   11.209175] Call Trace:
[   11.209603] UDF-fs: warning (device vda): udf_fill_super: No partition found 
(2)
[   11.211190]  [] dump_stack+0x4b/0x6c
[   11.212236]  [] __lock_acquire+0x77d/0xc27
[   11.213652]  [] ? kvm_clock_read+0x25/0x37
[   11.214883]  [] lock_acquire+0x53/0x76
[   11.216006]  [] ? blk_insert_flush+0x182/0x1c5
[   11.217275]  [] _raw_spin_lock_irq+0x36/0x6c
[   11.218510]  [] ? blk_insert_flush+0x182/0x1c5
[   11.219888]  [] blk_insert_flush+0x182/0x1c5
[   11.221326]  [] blk_sq_make_request+0xf7/0x23c
[   11.222698]  [] generic_make_request+0xb8/0x156
[   11.224165]  [] submit_bio+0xeb/0xf6
[   11.225321]  [] ? __init_waitqueue_head+0x36/0x49
[   11.226738]  [] submit_bio_wait+0x4f/0x65
[   11.228201]  [] blkdev_issue_flush+0x5d/0x7f
[   11.229617]  [] xfs_blkdev_issue_flush+0x14/0x16
[   11.230991]  [] xfs_free_buftarg+0x35/0x42
[   11.232279]  [] xfs_close_devices+0x5f/0x64
[   11.233489]  [] xfs_fs_fill_super+0x318/0x4e3
[   11.234769]  [] mount_bdev+0x13e/0x193
[   11.235889]  [] ? xfs_parseargs+0x8bd/0x8bd
[   11.237107]  [] xfs_fs_mount+0x10/0x12
[   11.238223]  [] mount_fs+0xf/0x87
[   11.239245]  [] vfs_kern_mount+0x65/0x138
[   11.240484]  [] do_mount+0xa1c/0xba6
[   11.241644]  [] ? strndup_user+0x3a/0x54
[   11.242866]  [] SyS_mount+0x72/0x9a
[   11.244163]  [] entry_SYSCALL_64_fastpath+0x16/0x7a
[   11.259529] NILFS: Can't find nilfs on dev vdb.





Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.5.0-rc2 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

[lkp] [workqueue] 82607adcf9: BUG: workqueue lockup - pool cpus=0 flags=0x4 nice=0 stuck for 42s!

2016-02-13 Thread kernel test robot
FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 82607adcf9cdf40fb7b5331269780c8f70ec6e35 ("workqueue: implement lockup 
detector")


[   75.684302] virtio-pci :00:06.0: virtio_pci: leaving for legacy driver
[   88.791869] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
[   88.795120] virtio-pci :00:07.0: virtio_pci: leaving for legacy driver
[   90.789792] BUG: workqueue lockup - pool cpus=0 flags=0x4 nice=0 stuck for 
42s!
[   90.794158] Showing busy workqueues and worker pools:
[   90.796507] workqueue cgroup_pidlist_destroy: flags=0x0
[   90.798976]   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1





Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.4.0-rc4 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_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=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_KASAN_SHADOW_OFFSET=0xdc00
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_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
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 is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=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 is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# 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 is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_KTHREAD_PRIO=0
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_HUGETLB is not set
# CONFIG_CGROUP_PERF is not set
# CONFIG_CGROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
# CONFIG_PID_NS is not set
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set

Re: Kernel docs: muddying the waters a bit

2016-02-13 Thread Keith Packard
Jonathan Corbet  writes:

> Asciidoc is a credible solution to the formatted documentation problem,
> but it's not the only such; I'd like to be sure that we pick the right
> one.  I worry that asciidoc seems to be aimed mostly at small documents,
> and that the project itself seems a little lifeless - it's not a good
> sign when your main page's link to the repository has been dead for a long
> time.  (Asciidoctor seems more active, with the Github folks behind it,
> but that means bringing Ruby into the picture).

I was surprised when one of the asciidoctor developers said that
asciidoc itself was 'in maintenance mode for existing users'. I've tried
asciidoctor but never got it to the point where I was happy with the
results. Having two tools using the same nominal format doesn't seem
like a great idea to me.

It's also clear from my hacking in asciidoc that docbook is the expected
target for that tool. I've managed to make direct HTML output usable,
but LaTeX doesn't work at all. Something which focuses on direct HTML
(and ePub) output would be pretty nice.

> An alternative we haven't really looked at yet is ReStructuredText (or
> "RST") and the Sphinx system (sphinx-doc.org) built on top of it.  RST is
> YA simple markup scheme, remarkably similar to Markdown or Asciidoc;
> Sphinx is a fairly sophisticated documentation system that uses RST.

I've installed debian's python3-sphinx package; it looks like it doesn't
have a huge dependency chain below it, which is a nice change.

I translated a fairly long document from asciidoc to rst using pandoc by
using the docbook output from asciidoc -- pandoc doesn't have a native
asciidoc reader, only a writer. The result didn't totally suck, although
I haven't messed with fixing the css or using a different theme at all.

http://keithp.com/~keithp/altusmetrum-sphinx/altusmetrum.html

I installed the sphinxcontrib.fulltoc extension so that the whole TOC
was visible from each section; this made navigating a lot easier. Having
search included (if you have javascript) seems like a nice feature.

> Like asciidoc, Sphinx is Python-based, so it adds little to the toolchain
> requirements there.

Having functional native latex output means that even PDF generation is
lighterweight though.

> It produces integrated, multi-file HTML natively,
> with a TOC, an index, cross-file cross references, and more.  It can make
> things like function indexes.  It claims output in epub, docbook, and man
> (I've not yet messed with those).  The path to PDF is via latex; clearly
> the docbook path could be used too.

I've tried epub and latex backends; epub seems just fine (it's just
html, after all). LaTeX works, and generates functional PDF, but I'm
going to have to spend a bunch of time making it looks nice.

http://keithp.com/~keithp/altusmetrum-sphinx/AltusMetrum.pdf

> So can we discuss?  I'm not saying we have to use Sphinx, but, should we
> choose not to, we should do so with open eyes and good reasons for the
> course we do take.  What do you all think?

Having spent the afternoon playing with it, I'm definitely
impressed. I've spent a ton of time getting asciidoc to generate html
and pdf that I can tolerate; far too much of that involved hacking XML
files related to the docbook backend.

Pros

 * Credible HTML output without docbook

 * Credible PDF output without docbook.

 * Constructs a unified set of documents across
   multiple files.

 * Written in Python (2 or 3)

 * PanDoc already supports rst for both input and output. So, if we get
   bored with RST, we've got a way out.

Cons

 * Table formatting doesn't seem as sophisticated as asciidoc

Questions

 * Conditional text appears to be harder to manage (I haven't managed to
   make it work at all).

 * Takes over a directory making building more than one
   document in a directory hard/impossible? The config file must be
   named 'conf.py'?
   
-- 
-keith


signature.asc
Description: PGP signature


[PATCH 1/1] Documentation: Fix int/unsigned int comparison

2016-02-13 Thread Mahesh Khanwalkar
Signed int - unsigned int comparison fixed in mpssd, prctl, ptp, and
timers in Documentation. In places where 'int argc' and 'const char
**argv' are not used, they are replaced with void

Documentation/mic/mpssd/mpssd.c: Fixed comparison in sum_iovec_len and
disp_iovec

Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c: main signature
changed to void, as parameters 'argc' and 'argv' are never used

Documentation/prctl/disable-tsc-on-off-stress-test.c: main signature
changed to void

Documentation/prctl/disable-tsc-test.c: main signature changed to void

Documentation/ptp/testptp.c: Sign comparison fix
Documentation/timers/hpet_example.c: Sign comparision fix

Signed-off-by: Mahesh Khanwalkar 
---
 Documentation/mic/mpssd/mpssd.c   | 4 ++--
 Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c | 2 +-
 Documentation/prctl/disable-tsc-on-off-stress-test.c  | 2 +-
 Documentation/prctl/disable-tsc-test.c| 2 +-
 Documentation/ptp/testptp.c   | 3 ++-
 Documentation/timers/hpet_example.c   | 2 +-
 6 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/Documentation/mic/mpssd/mpssd.c b/Documentation/mic/mpssd/mpssd.c
index aaeafa1..7ce1e53 100644
--- a/Documentation/mic/mpssd/mpssd.c
+++ b/Documentation/mic/mpssd/mpssd.c
@@ -349,7 +349,7 @@ static ssize_t
 sum_iovec_len(struct mic_copy_desc *copy)
 {
ssize_t sum = 0;
-   int i;
+   unsigned int i;
 
for (i = 0; i < copy->iovcnt; i++)
sum += copy->iov[i].iov_len;
@@ -372,7 +372,7 @@ static void
 disp_iovec(struct mic_info *mic, struct mic_copy_desc *copy,
   const char *s, int line)
 {
-   int i;
+   unsigned int i;
 
for (i = 0; i < copy->iovcnt; i++)
mpsslog("%s %s %d copy->iov[%d] addr %p len 0x%zx\n",
diff --git a/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c 
b/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c
index 81fdd42..f7499d1 100644
--- a/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c
+++ b/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c
@@ -74,7 +74,7 @@ static void rdtsctask(void)
 }
 
 
-int main(int argc, char **argv)
+int main(void)
 {
int n_tasks = 100, i;
 
diff --git a/Documentation/prctl/disable-tsc-on-off-stress-test.c 
b/Documentation/prctl/disable-tsc-on-off-stress-test.c
index 4d83a27..a06f027 100644
--- a/Documentation/prctl/disable-tsc-on-off-stress-test.c
+++ b/Documentation/prctl/disable-tsc-on-off-stress-test.c
@@ -78,7 +78,7 @@ static void task(void)
 }
 
 
-int main(int argc, char **argv)
+int main(void)
 {
int n_tasks = 100, i;
 
diff --git a/Documentation/prctl/disable-tsc-test.c 
b/Documentation/prctl/disable-tsc-test.c
index 2541e65..8d494f7 100644
--- a/Documentation/prctl/disable-tsc-test.c
+++ b/Documentation/prctl/disable-tsc-test.c
@@ -57,7 +57,7 @@ static void sigsegv_cb(int sig)
printf("rdtsc() == ");
 }
 
-int main(int argc, char **argv)
+int main(void)
 {
int tsc_val = 0;
 
diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c
index 6c6247a..bee2f14 100644
--- a/Documentation/ptp/testptp.c
+++ b/Documentation/ptp/testptp.c
@@ -160,7 +160,8 @@ int main(int argc, char *argv[])
 
 
char *progname;
-   int i, c, cnt, fd;
+   unsigned int i;
+   int c, cnt, fd;
 
char *device = DEVICE;
clockid_t clkid;
diff --git a/Documentation/timers/hpet_example.c 
b/Documentation/timers/hpet_example.c
index 9a3e701..3ab4993 100644
--- a/Documentation/timers/hpet_example.c
+++ b/Documentation/timers/hpet_example.c
@@ -49,7 +49,7 @@ struct hpet_command {
 int
 main(int argc, const char ** argv)
 {
-   int i;
+   unsigned inti;
 
argc--;
argv++;
-- 
2.5.0



Re: [RFC][PATCH 00/10] Add trace event support to eBPF

2016-02-13 Thread Alexei Starovoitov
On Fri, Feb 12, 2016 at 10:11:18AM -0600, Tom Zanussi wrote:
> Hi,
> 
> As promised in previous threads, this patchset shares some common
> functionality with the hist triggers code and enables trace events to
> be accessed from eBPF programs.

great that you've started working on BPF!

> It needs to be applied on top of current tracing/for-next with the
> hist triggers v13 patches applied:
> 
>   https://lkml.org/lkml/2015/12/10/640
> 
> Any input welcome, especially things that could be done better wrt
> eBPF, since I'm not as familiar with that code...

this dependency looks odd. As I was saying a year ago I don't think
this hist triggers belong in the kernel. BPF already can do
way more complex aggregation and histograms.
Take a look at all the tools written on top of it:
https://github.com/iovisor/bcc/tree/master/tools
I don't buy into reasoning that hist triggers are needed to do
performance analysis in the busybox. If not in busybox,
just use perf+bpf or bcc.

that aside we do need to be able to attach bpf to tracepoints.
The key goal of bpf+tracepoints is to be faster than bpf+kprobe.
kprobes were good enough for almost all use cases so far except
when we started processing millions of events per second via
kprobe+bpf. At that point even optimized kprobe adds too much
overhead.

Patch 9:
+   char common_pid_field_name1[] = "common_pid";
+   key.pid = bpf_trace_event_field_read(ctx, common_pid_field_name1);

this is already achieved by bpf_get_current_pid_tgid()
and it is several times faster.

+   char count_field_name1[] = "count";
+   count = bpf_trace_event_field_read(ctx, count_field_name1);

Already possible by simple PT_REGS_PARM3(ctx) which is faster as well.
And if you're using bcc you can write
sys_read(struct pt_regs *ctx, int fd, char *buf, size_t count)
{ .. use 'count' ...}
and bcc will automatically convert 'count' to ctx->dx.
The latest perf can do this as well with slightly different syntax.

Patch 10:
+   char len_field[] = "len";
+   len = bpf_trace_event_field_read(ctx, len_field);
+
+   char name_field[] = "name";
+   bpf_trace_event_field_read_string(ctx, name_field, name, sizeof(name));
+
+   char common_pid_field[] = "common_pid";
+   common_pid = bpf_trace_event_field_read(ctx, common_pid_field);

all of the above can be done already and it's even demoed
in samples/bpf/tracex1_kern.c

The main problem with this patch set is in patch 5:
+   field_name = (char *) (long) r2;
+   field = trace_find_event_field(ctx->call, field_name);

This is very slow, since it's doing for_each_field(){strcmp()}
That's the reason that simple ctx->register or bpf_probe_read()
are much faster.

There are few other issues with this set:
Patch 2:
+   if (off < 0 || off >= TRACE_EVENT_CTX_HDR_SIZE + BUF_MAX_DATA_SIZE)
+   return false;
that will allow bpf program to read a page worth of data from some
stack pointer, since in patch 6:
+   struct trace_event_context ctx = { call, entry };
+   if (!trace_call_bpf(prog, ))
the kernel probably won't crash, but it shouldn't be allowed.

Patch 6 is odd.
We already have prog_type_kprobe to work with kprobes.
Having prog_type_trace_event there is unnecessary.

The syscall part of Patch 7 is probably unnecessary too.
When we benchmarked bpf+syscall it turned out that adding
kprobe to sys_xx is actually faster than using syscall_enter() logic.
May be things have changed. Need to re-measure.

The tracepoint part of Patch 7 makes sense, but it has too much
overhead to be competitive with kprobe.
perf_trace_buf_prepare() does local_save_flags() which is quite
expensive instruction when tracepoint is called million times a second.
perf_fetch_caller_regs() is heavy too, since it zeros pt_regs which
will be unused the bpf program.

I'm also working on bpf+tracepoint.
My plan was to add a variant of perf_trace_buf_prepare() that
doesn't populate 'struct trace_entry' and just returns a pointer.
Then perf_trace_##call() does tstruct and {assign;} into that
'entry' pointer and then call bpf prog with
'struct ctx {regs, entry_ptr, __data_size}'
Then bpf prog will call a helper to copy the data into its stack
and will access it there as normal.
It's going to be significantly faster than for_each_field+strcmp
approach and little bit faster than kprobe, but I'm not happy
with that speed yet.
I'm still thinking on how to avoid 2nd copy and extra helper.
The program should be able to access the entry_ptr directly,
but some verifier magic needs to be done. so it's still wip.

btw, ast@plumgrid is no longer functional and
please cc netdev every time kernel/bpf/ is touched.



[PATCH] i40e: remove redundant check on vsi->active_vlans

2016-02-13 Thread Colin King
From: Colin Ian King 

active_vlans is an unsigned long array, hence a null check on this
array is superfluous and can be removed.

Detected with static analysis by smatch:

drivers/net/ethernet/intel/i40e/i40e_debugfs.c:386
  i40e_dbg_dump_vsi_seid() warn: this array is probably
  non-NULL. 'vsi->active_vlans'

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c 
b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
index 10744a6..aba28be 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
@@ -383,9 +383,8 @@ static void i40e_dbg_dump_vsi_seid(struct i40e_pf *pf, int 
seid)
dev_info(>pdev->dev,
 "netdev: name = %s\n",
 vsi->netdev->name);
-   if (vsi->active_vlans)
-   dev_info(>pdev->dev,
-"vlgrp: & = %p\n", vsi->active_vlans);
+   dev_info(>pdev->dev,
+"vlgrp: & = %p\n", vsi->active_vlans);
dev_info(>pdev->dev,
 "netdev_registered = %i, current_netdev_flags = 0x%04x, 
state = %li flags = 0x%08lx\n",
 vsi->netdev_registered,
-- 
2.7.0



[PATCH] drivers/staging/android: don't use modular references in sync_debug.c

2016-02-13 Thread Paul Gortmaker
In commit 8a0044846115e74552b671a7073cffeec14b9316 ("staging/android:
create a 'sync' dir for debugfs information"), modular references were
introduced to this file.  However if we look, we find:

drivers/staging/android/Makefile:obj-$(CONFIG_SYNC) += sync.o sync_debug.o

drivers/staging/android/Kconfig:config SYNC
drivers/staging/android/Kconfig:bool "Synchronization framework"

This file isn't currently buildable as a module, and hence the code
for module_exit is just dead code.  Remove it and the module.h include.

Cc: Gustavo Padovan 
Cc: Maarten Lankhorst 
Cc: Greg Kroah-Hartman 
Signed-off-by: Paul Gortmaker 
---
 drivers/staging/android/sync_debug.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/staging/android/sync_debug.c 
b/drivers/staging/android/sync_debug.c
index fd13f1e885e5..5a7ec58fbc09 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -15,7 +15,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -335,13 +334,6 @@ static __init int sync_debugfs_init(void)
 }
 late_initcall(sync_debugfs_init);
 
-static __exit void sync_debugfs_exit(void)
-{
-   if (dbgfs)
-   debugfs_remove_recursive(dbgfs);
-}
-module_exit(sync_debugfs_exit);
-
 #define DUMP_CHUNK 256
 static char sync_dump_buf[64 * 1024];
 void sync_dump(void)
-- 
2.6.1



[PATCH] logfs: remove redundant check on block->alias_map

2016-02-13 Thread Colin King
From: Colin Ian King 

alias_map is an unsigned long array, hence a null check on this
array is superfluous and can be removed.

Detected with static analysis by smatch:

fs/logfs/readwrite.c:1282 fill_shadow_tree() warn: this array
  is probably non-NULL. 'block->alias_map'

Signed-off-by: Colin Ian King 
---
 fs/logfs/readwrite.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/logfs/readwrite.c b/fs/logfs/readwrite.c
index 20973c9..1fb9658 100644
--- a/fs/logfs/readwrite.c
+++ b/fs/logfs/readwrite.c
@@ -1279,9 +1279,8 @@ static void fill_shadow_tree(struct inode *inode, struct 
page *page,
struct shadow_tree *tree = >s_shadow_tree;
 
if (PagePrivate(page)) {
-   if (block->alias_map)
-   super->s_no_object_aliases -= bitmap_weight(
-   block->alias_map, LOGFS_BLOCK_FACTOR);
+   super->s_no_object_aliases -= bitmap_weight(
+   block->alias_map, LOGFS_BLOCK_FACTOR);
logfs_handle_transaction(inode, block->ta);
block->ops->free_block(inode->i_sb, block);
}
-- 
2.7.0



[PATCH] mm/compaction: don't use modular references for non modular code

2016-02-13 Thread Paul Gortmaker
replace module_init with subsys_initcall ; which will be two
levels earlier, but mm smells like a subsystem to me.

Compile tested only.

Cc: Vlastimil Babka 
Cc: Andrew Morton 
Signed-off-by: Paul Gortmaker 
---

[Feel free to squash this into the original, if desired.]

 mm/compaction.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 4cb1c2ef5abb..4d99e1f5055c 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "internal.h"
 
 #ifdef CONFIG_COMPACTION
@@ -1954,7 +1953,6 @@ static int __init kcompactd_init(void)
hotcpu_notifier(cpu_callback, 0);
return 0;
 }
-
-module_init(kcompactd_init)
+subsys_initcall(kcompactd_init)
 
 #endif /* CONFIG_COMPACTION */
-- 
2.6.1



Re: [PATCH v2 0/7] Use devm_request_region

2016-02-13 Thread Linus Walleij
On Wed, Feb 3, 2016 at 9:15 PM, William Breathitt Gray
 wrote:

> By the time request_region is called in several GPIO drivers, a
> corresponding device structure has already been allocated. The
> devm_request_region function should be used to help simplify the cleanup
> code and reduce the possible points of failure.
>
> Changes in v2:
>   - Remove unused extent member from 104-dio-48e, 104-idi-48,
> 104-idio-16, and ws16c48 respective private data structures
>   - Remove unused pdata pointer from sch311x_gpio_remove function

All 7 patches applied.

Yours,
Linus Walleij


Re: [PATCH] ocfs2: fix build warning

2016-02-13 Thread kbuild test robot
Hi Sudip,

[auto build test ERROR on v4.5-rc2]
[cannot apply to next-20160212]
[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/Sudip-Mukherjee/ocfs2-fix-build-warning/20160202-144936
config: i386-randconfig-x0-02140608 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   fs/ocfs2/file.c: In function 'ocfs2_file_write_iter':
>> fs/ocfs2/file.c:2369:3: error: label 'relock' used but not defined
  goto relock;
  ^

vim +/relock +2369 fs/ocfs2/file.c

9517bac6 Mark Fasheh 2007-02-09  2363   rw_level = -1;
9517bac6 Mark Fasheh 2007-02-09  2364  
9517bac6 Mark Fasheh 2007-02-09  2365   direct_io = 0;
7da839c4 Al Viro 2015-04-09  2366   iocb->ki_flags &= ~IOCB_DIRECT;
3309dd04 Al Viro 2015-04-09  2367   iov_iter_reexpand(from, 
orig_count);
7da839c4 Al Viro 2015-04-09  2368   dropped_dio = 1;
9517bac6 Mark Fasheh 2007-02-09 @2369   goto relock;
9517bac6 Mark Fasheh 2007-02-09  2370   }
9517bac6 Mark Fasheh 2007-02-09  2371  
a11f7e63 Mark Fasheh 2011-06-22  2372   if (unaligned_dio) {

:: The code at line 2369 was first introduced by commit
:: 9517bac6cc7a7aa4fee63cb38a32cb6014e264c7 ocfs2: teach 
ocfs2_file_aio_write() about sparse files

:: TO: Mark Fasheh 
:: CC: Mark Fasheh 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH 0/4] Pass correct license string to MODULE_LICENSE

2016-02-13 Thread Linus Walleij
On Tue, Feb 2, 2016 at 12:51 AM, William Breathitt Gray
 wrote:

> Several of the GPIO drivers have a copyright boilerplate lacking the "or
> later" verbiage regarding GPL compliant distribution. The MODULE_LICENSE
> string should reflect the actual copyright license terms used.
>
> William Breathitt Gray (4):
>   gpio: 104-dio-48e: Pass correct license string to MODULE_LICENSE
>   gpio: 104-idi-48: Pass the correct license string to MODULE_LICENSE
>   gpio: 104-idio-16: Pass the correct license string to MODULE_LICENSE
>   gpio: ws16c48: Pass the correct license string to MODULE_LICENSE

I squashed these four and applied. One "functional" change so just one commit.

Yours,
Linus Walleij


Re: [PATCH v2] pinctrl: mediatek: guard sub-directory with CONFIG_PINCTRL_MTK

2016-02-13 Thread Linus Walleij
On Wed, Feb 10, 2016 at 10:54 AM, Masahiro Yamada
 wrote:

> CONFIG_PINCTRL_MTK is more suitable than CONFIG_ARCH_MEDIATEK
> to guard the drivers/pinctrl/mediatek/ directory.
> (I renamed CONFIG_PINCTRL_MTK_COMMON to CONFIG_PINCTRL_MTK.)
>
> This allows COMPILE_TEST to descend into drivers/pinctrl/mediatek
> without CONFIG_ARCH_MEDIATEK define.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Series-changes: 2
>   - Rebase onto linux-pinctrl/devel

Patch applied.

THANKS for following through.

Yours,
Linus Walleij


Re: [PATCH 2/2 v2] devicetree: Add DTS file to support the Nexus7 2013 (flo) device.

2016-02-13 Thread Linus Walleij
On Fri, Feb 5, 2016 at 8:21 PM, John Stultz  wrote:

> This patch adds a dts file to support the Nexus7 2013
> device. Its based off of the qcom-apq8064-ifc6410.dts
> which is similar hardware.
>
> Also includes some comments and context folded in
> from Vinay Simha BN 
>
> Cc: Rob Herring 
> Cc: Arnd Bergmann 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 
> Cc: Andy Gross 
> Cc: Russell King 
> Cc: Vinay Simha BN 
> Cc: Bjorn Andersson 
> Cc: Stephen Boyd 
> Cc: linux-arm-...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Acked-by: Rob Herring 
> Signed-off-by: John Stultz 
> ---
> v2: Fix dts/dtb typeo in makefile pointed out by Rob

Reviewed-by: Linus Walleij 

Yours,
Linus Walleij


Re: mm, compaction: fix build errors with kcompactd

2016-02-13 Thread Paul Gortmaker
On Tue, Feb 9, 2016 at 9:15 AM, Arnd Bergmann  wrote:
> The newly added kcompactd code introduces multiple build errors:
>
> include/linux/compaction.h:91:12: error: 'kcompactd_run' defined but not used 
> [-Werror=unused-function]
> mm/compaction.c:1953:2: error: implicit declaration of function 
> 'hotcpu_notifier' [-Werror=implicit-function-declaration]
>
> This marks the new empty wrapper functions as 'inline' to avoid 
> unused-function warnings,
> and includes linux/cpu.h to get the hotcpu_notifier declaration.
>
> Fixes: 8364acdfa45a ("mm, compaction: introduce kcompactd")

The 8364acdfa45a is a linux-next ID and changes on a daily basis, so you
can't really use a "Fixes" here.  It doesn't matter if akpm just
squishes it into
the original, but I thought I'd mention it for future reference.

P.
..

> Signed-off-by: Arnd Bergmann 
> ---
> I stumbled over this while trying out the mmots patches today for an 
> unrelated reason.
>
> diff --git a/include/linux/compaction.h b/include/linux/compaction.h
> index 1367c0564d42..d7c8de583a23 100644
> --- a/include/linux/compaction.h
> +++ b/include/linux/compaction.h
> @@ -88,15 +88,15 @@ static inline bool compaction_deferred(struct zone *zone, 
> int order)
> return true;

[...]


Re: [PATCH] i2c: designware: balance clk enable/disable on removal

2016-02-13 Thread Alexey Khoroshilov
On 12.02.2016 21:54, Wolfram Sang wrote:
> On Mon, Feb 01, 2016 at 04:44:05PM +0200, Andy Shevchenko wrote:
>> On Mon, 2016-02-01 at 16:21 +0200, Jarkko Nikula wrote:
>>> On 01/30/2016 12:31 AM, Alexey Khoroshilov wrote:
 It seems clk_disable_unprepare() is missed in dw_i2c_plat_remove(),
 so the patch adds it.

 Found by Linux Driver Verification project (linuxtesting.org).

 Signed-off-by: Alexey Khoroshilov 
 ---
   drivers/i2c/busses/i2c-designware-platdrv.c | 1 +
   1 file changed, 1 insertion(+)

 diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
 b/drivers/i2c/busses/i2c-designware-platdrv.c
 index 438f1b4964c0..8f19b7b81fe0 100644
 --- a/drivers/i2c/busses/i2c-designware-platdrv.c
 +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
 @@ -267,6 +267,7 @@ static int dw_i2c_plat_remove(struct
 platform_device *pdev)
i2c_del_adapter(>adapter);

i2c_dw_disable(dev);
 +  i2c_dw_plat_prepare_clk(dev, false);

>>> I tried this quickly and it appears more work is needed. When 
>>> CONFIG_PM_SLEEP is set then autosuspending will do the unprepare and 
>>> this patch causes double unprepare at remove. But when
>>> CONFIG_PM_SLEEP 
>>> is not set then indeed those clk calls are out of sync.
>>
>> Besides that I would suggest to check carefully error patch in the
>> probe(), i.e. handling error from i2c_dw_probe(). There maybe similar
>> issue is hidden.
> 
> So, waiting for V2 on this one.
> 

I have a fix for error handling of i2c_dw_probe(), but I am not sure
what is the right approach to handle CONFIG_PM_SLEEP case.

What is a safe way to distinguish a need for the unprepare in
dw_i2c_plat_remove()?
Should we try to avoid double i2c_dw_disable(dev) in the same case?

--
Alexey





[PATCH] usb: host: ohci-pxa27x: propagate the irq error code

2016-02-13 Thread Robert Jarzmik
In several drivers in the pxa architecture, it was found that the
platform_get_irq() was not propagated. This breaks the the device-tree
probe deferral path, if -EPROBE_DEFER is returned. Unfortunately, the
error return in this case is transformed into -ENXIO, breaking the
deferral mechanism.

Even if in this specific case the driver was not broken, because the
interrupt controller is always probed before drivers, propagate the
proper return code.

Signed-off-by: Robert Jarzmik 
---
 drivers/usb/host/ohci-pxa27x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index e8c006e7a960..a667cf2d5788 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -435,7 +435,7 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver, 
struct platform_device
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
pr_err("no resource of IORESOURCE_IRQ");
-   return -ENXIO;
+   return irq;
}
 
usb_clk = devm_clk_get(>dev, NULL);
-- 
2.1.4



Re: [RFC v2a 11/12] net: ceph: use vfs_time data type instead of timespec

2016-02-13 Thread Dave Chinner
On Fri, Feb 12, 2016 at 01:36:05AM -0800, Deepa Dinamani wrote:
> The VFS inode timestamps are not y2038 safe as they use
> struct timespec. These will be changed to use struct timespec64
> instead and that is y2038 safe.
> But, since the above data type conversion will break the end
> file systems, use vfs_time aliases here to access inode times.
> 
> These timestamps are passed in as arguments to functions
> using inode timestamps. Hence, these need to change along
> with vfs to support 64 bit timestamps. vfs_time helps do
> this transition.
> 
> Signed-off-by: Deepa Dinamani 

Just a point to highlight the problem with this approach:

> diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
> index f8f2359..1273db6 100644
> --- a/net/ceph/osd_client.c
> +++ b/net/ceph/osd_client.c
> @@ -2401,7 +2401,7 @@ bad:
>   */
>  void ceph_osdc_build_request(struct ceph_osd_request *req, u64 off,
>   struct ceph_snap_context *snapc, u64 snap_id,
> - struct timespec *mtime)
> + struct vfs_time *mtime)
>  {
>   struct ceph_msg *msg = req->r_request;
>   void *p;

So this change assumes that mtime is not passed by reference to
another function. If we change vfs_time to be a timespec64, then
dereferencing in this function works fine, but passing to another
function will not because that function will be expecting a
timespec.

That, indeed, is what happens here. A few lines into this function:

if (req->r_flags & CEPH_OSD_FLAG_WRITE)
ceph_encode_timespec(p, mtime);

And that function:

static inline void ceph_encode_timespec(struct ceph_timespec *tv,
const struct timespec *ts)
{
tv->tv_sec = cpu_to_le32((u32)ts->tv_sec);
tv->tv_nsec = cpu_to_le32((u32)ts->tv_nsec);
}

expects a timespec. It will silently lose 64 bit times even if it
did compile. I note in version 2b, the mtime was not passed by
reference as a vfs time, but converted at the call site to
a timespec and so the internal usage of the timestamp remains
unchanged and unaffected by a VFS level timespec->timespec64 change.

I think an approach that requires changes to the API without
actually beign able to verify they are correct, fully propagated or
don't impact on write/disk formats before the final change of the
VFS type is not going to fly. This is the sort of subtle bug that
can occur with type changes, and hence why I think that the fs
developers should be left to do the conversion of their filesystem
to support 64 bit times (i.e. approach 2b).

Any change is going to take a significant amount of testing and
verification, and that's something we don't have yet. Nobody has
written any tests for xfstests to verify correct 64 bit timestamp
behaviour, nor do we have tests to verify 32 bit timestamp behaviour
on a 64 bit time kernel. These are things that we are going to need;
all filesystems should behave the same w.r.t. these configurations,
so we really do need regression tests for this

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com


Re: [PATCH] [media] zl10353: use div_u64 instead of do_div

2016-02-13 Thread Nicolas Pitre
On Sat, 13 Feb 2016, Ard Biesheuvel wrote:

> On 12 February 2016 at 22:01, Arnd Bergmann  wrote:
> > However, I did stumble over an older patch I did now, which I could
> > not remember what it was good for. It does fix the problem, and
> > it seems to be a better solution.
> >
> > Arnd
> >
> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > index b5acbb404854..b5ff9881bef8 100644
> > --- a/include/linux/compiler.h
> > +++ b/include/linux/compiler.h
> > @@ -148,7 +148,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, 
> > int val, int expect);
> >   */
> >  #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
> >  #define __trace_if(cond) \
> > -   if (__builtin_constant_p((cond)) ? !!(cond) :   \
> > +   if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
> > ({  \
> > int __r;\
> > static struct ftrace_branch_data\
> >
> 
> I remember seeing this patch, but I don't remember the exact context.
> But when you think about it, !!cond can be a build time constant even
> if cond is not, as long as you can prove statically that cond != 0. So

You're right.  I just tested it and to my surprise gcc is smart enough 
to figure that case out.

> I think this change is obviously correct, and an improvement since it
> will remove the profiling overhead of branches that are not true
> branches in the first place.

Indeed.


Nicolas


Re: [PATCH v2 0/4] tpm: last minute critical fixes for Linux 4.5

2016-02-13 Thread Jason Gunthorpe
Hi Peter, 

Please don't grab my patch in this pull, it is broken.

Thanks
Jason

On Feb 13, 2016 6:47 AM, Jarkko Sakkinen  
wrote:
>
> These are critical to get to Linux 4.5 in order to get the chip refcount 
> management stabilized and API/ABI for policy based sealing correct. 
>
> Harald Hoyer (1): 
>   tpm_eventlog.c: fix binary_bios_measurements 
>
> Jarkko Sakkinen (2): 
>   tpm: fix: keep auth session intact after unseal operation 
>   tpm: fix: rollback when devm_add_action() fails 
>
> Jason Gunthorpe (1): 
>   tpm: Hold the kref during tpm_chip_find_get 
>
> drivers/char/tpm/tpm-chip.c |  9 - 
> drivers/char/tpm/tpm.h  |  1 + 
> drivers/char/tpm/tpm2-cmd.c | 10 +++--- 
> drivers/char/tpm/tpm_eventlog.c | 10 -- 
> 4 files changed, 24 insertions(+), 6 deletions(-) 
>
> -- 
> 2.7.0 
>


Kernel docs: muddying the waters a bit

2016-02-13 Thread Jonathan Corbet
So I fear you all are going to hate me for this...

Asciidoc is a credible solution to the formatted documentation problem,
but it's not the only such; I'd like to be sure that we pick the right
one.  I worry that asciidoc seems to be aimed mostly at small documents,
and that the project itself seems a little lifeless - it's not a good
sign when your main page's link to the repository has been dead for a long
time.  (Asciidoctor seems more active, with the Github folks behind it,
but that means bringing Ruby into the picture).

An alternative we haven't really looked at yet is ReStructuredText (or
"RST") and the Sphinx system (sphinx-doc.org) built on top of it.  RST is
YA simple markup scheme, remarkably similar to Markdown or Asciidoc;
Sphinx is a fairly sophisticated documentation system that uses RST.

I spent a few hours reworking the asciidoc patches to do RST instead, then
built a few template files' worth of docs.  The result can be seen at:

http://static.lwn.net/kerneldoc/

It's very much a POC (however you might want to define the term), there's
lots of glitches, I chose a theme pretty much at random, etc.  But it
shows that it can be done.

Like asciidoc, Sphinx is Python-based, so it adds little to the toolchain
requirements there.  It produces integrated, multi-file HTML natively,
with a TOC, an index, cross-file cross references, and more.  It can make
things like function indexes.  It claims output in epub, docbook, and man
(I've not yet messed with those).  The path to PDF is via latex; clearly
the docbook path could be used too.

I used my same docproc hack to extract the comments here, mostly because I
had it at hand.  We could go with Jani's separate-file approach if we
wanted.  There's also a tool out there (called "breathe") that's meant to
turn doxygen-style comments into RST; I haven't had a chance to mess with
it.  We *could* also write an extension to pull the comments directly in
Sphinx if there were a compelling reason to do so.

If anybody's curious, the work done to get this far is in:

git://git.lwn.net/linux.git doc/sphinx

but it looks suspiciously like the previous asciidoc patches, and, in any
case, it would have to be thrown out, publicly disowned, and replaced
before going any further with this, should that be what we decide to do.

So can we discuss?  I'm not saying we have to use Sphinx, but, should we
choose not to, we should do so with open eyes and good reasons for the
course we do take.  What do you all think?

jon


[PATCH 2/2] drm/panel: simple: Add URT UMSH-8596MD-xT panels support

2016-02-13 Thread Maciej S. Szmigiero
Add support for United Radiant Technology UMSH-8596MD-xT
7.0" WVGA TFT LCD panels in DRM panel-simple driver.

Signed-off-by: Maciej S. Szmigiero 
---
This replaces "drm: panel-simple: implement URT UMSH-8596MD-xT panel support"
submission.

 drivers/gpu/drm/panel/panel-simple.c | 54 
 1 file changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f88a631c43ab..6530c1ffca2c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1176,6 +1176,42 @@ static const struct panel_desc shelly_sca07010_bfn_lnn = 
{
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
 };
 
+static const struct display_timing urt_umsh_8596md_timing = {
+   .pixelclock = { 3326, 3326, 3326 },
+   .hactive = { 800, 800, 800 },
+   .hfront_porch = { 41, 41, 41 },
+   .hback_porch = { 216 - 128, 216 - 128, 216 - 128 },
+   .hsync_len = { 71, 128, 128 },
+   .vactive = { 480, 480, 480 },
+   .vfront_porch = { 10, 10, 10 },
+   .vback_porch = { 35 - 2, 35 - 2, 35 - 2 },
+   .vsync_len = { 2, 2, 2 },
+   .flags = DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_NEGEDGE |
+   DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_desc urt_umsh_8596md_lvds = {
+   .timings = _umsh_8596md_timing,
+   .num_timings = 1,
+   .bpc = 6,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
+static const struct panel_desc urt_umsh_8596md_parallel = {
+   .timings = _umsh_8596md_timing,
+   .num_timings = 1,
+   .bpc = 6,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+};
+
 static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am800480r3tmqwa1h",
@@ -1280,6 +1316,24 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "shelly,sca07010-bfn-lnn",
.data = _sca07010_bfn_lnn,
}, {
+   .compatible = "urt,umsh-8596md-t",
+   .data = _umsh_8596md_parallel,
+   }, {
+   .compatible = "urt,umsh-8596md-1t",
+   .data = _umsh_8596md_parallel,
+   }, {
+   .compatible = "urt,umsh-8596md-7t",
+   .data = _umsh_8596md_parallel,
+   }, {
+   .compatible = "urt,umsh-8596md-11t",
+   .data = _umsh_8596md_lvds,
+   }, {
+   .compatible = "urt,umsh-8596md-19t",
+   .data = _umsh_8596md_lvds,
+   }, {
+   .compatible = "urt,umsh-8596md-20t",
+   .data = _umsh_8596md_parallel,
+   }, {
/* sentinel */
}
 };



[PATCH 1/2] dt-bindings: Add URT UMSH-8596MD-xT panel bindings

2016-02-13 Thread Maciej S. Szmigiero
Add DT bindings for United Radiant Technology
UMSH-8596MD-xT 7.0" WVGA TFT LCD panels.

Signed-off-by: Maciej S. Szmigiero 
---
This replaces "of: add URT UMSH-8596MD-xT panel DT bindings"
submission.

 .../bindings/display/panel/urt,umsh-8596md.txt   | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/urt,umsh-8596md.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/urt,umsh-8596md.txt 
b/Documentation/devicetree/bindings/display/panel/urt,umsh-8596md.txt
new file mode 100644
index ..088a6cea5015
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/urt,umsh-8596md.txt
@@ -0,0 +1,16 @@
+United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel
+
+Supported are LVDS versions (-11T, -19T) and parallel ones
+(-T, -1T, -7T, -20T).
+
+Required properties:
+- compatible: should be one of:
+  "urt,umsh-8596md-t",
+  "urt,umsh-8596md-1t",
+  "urt,umsh-8596md-7t",
+  "urt,umsh-8596md-11t",
+  "urt,umsh-8596md-19t",
+  "urt,umsh-8596md-20t".
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.



Re: [PATCH] staging: lustre/lnet: Fix wrong type casting warning generated by sparse

2016-02-13 Thread Dan Carpenter
On Sat, Feb 13, 2016 at 11:34:35PM +0530, Niranjan Dighe wrote:
> diff --git a/drivers/staging/lustre/lnet/selftest/console.c 
> b/drivers/staging/lustre/lnet/selftest/console.c
> index 366211e..64b6a70 100644
> --- a/drivers/staging/lustre/lnet/selftest/console.c
> +++ b/drivers/staging/lustre/lnet/selftest/console.c
> @@ -1461,9 +1461,9 @@ lstcon_statrpc_readent(int transop, srpc_msg_t *msg,
>  
>   sfwk_stat = (sfw_counters_t __user *)_up->rpe_payload[0];
>   srpc_stat = (srpc_counters_t __user *)
> -   ((char *)sfwk_stat + sizeof(*sfwk_stat));
> + ((char __user *)sfwk_stat + sizeof(*sfwk_stat));

This is uglier than necessary.  Do it either like this:

srpc_stat = (void __user *)sfwk_stat + sizeof(*sfwk_stat);

Or probably it's actually nicer to say:

srpc_stat = sfwk_stat + 1;

regards,
dan carpenter



  1   2   3   4   >