Re: [PATCH 1/3] remoteproc: qcom: mdt_loader: add include for sizes

[Bjorn Andersson]

On Tue 22 Nov 09:02 PST 2016, Stanimir Varbanov wrote:

> Add linux/sizes.h to prevent build failure on non ARM architectures
> as:
> 
> CC [M]  drivers/remoteproc/qcom_mdt_loader.o
> In file included from include/linux/cache.h:4:0,
>  from include/linux/printk.h:8,
>  from include/linux/kernel.h:13,
>  from include/asm-generic/bug.h:13,
>  from arch/x86/include/asm/bug.h:35,
>  from include/linux/bug.h:4,
>  from include/linux/thread_info.h:11,
>  from arch/x86/include/asm/elf.h:7,
>  from include/linux/elf.h:4,
>  from drivers/remoteproc/qcom_mdt_loader.c:18:
> drivers/remoteproc/qcom_mdt_loader.c: In function ‘qcom_mdt_parse’:
> drivers/remoteproc/qcom_mdt_loader.c:90:52: error: ‘SZ_4K’ undeclared
> (first use in this function)
> 
> Signed-off-by: Stanimir Varbanov 

Applied

Thanks,
Bjorn

> ---
>  drivers/remoteproc/qcom_mdt_loader.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/remoteproc/qcom_mdt_loader.c 
> b/drivers/remoteproc/qcom_mdt_loader.c
> index 114e8e4cef67..2ff18cd6c096 100644
> --- a/drivers/remoteproc/qcom_mdt_loader.c
> +++ b/drivers/remoteproc/qcom_mdt_loader.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "remoteproc_internal.h"
> -- 
> 2.7.4
> 

Re: [PATCH v4] x86/suspend: fix false positive KASAN warning on suspend/resume

[Andrey Ryabinin]

On 12/02/2016 08:42 PM, Josh Poimboeuf wrote:
> Resuming from a suspend operation is showing a KASAN false positive
> warning:
> 
>   BUG: KASAN: stack-out-of-bounds in unwind_get_return_address+0x11d/0x130 at 
> addr 8803867d7878
>   Read of size 8 by task pm-suspend/7774
>   page:ea000e19f5c0 count:0 mapcount:0 mapping:  (null) index:0x0
>   flags: 0x200()
>   page dumped because: kasan: bad access detected
>   CPU: 0 PID: 7774 Comm: pm-suspend Tainted: GB   4.9.0-rc7+ #8
>   Hardware name: Gigabyte Technology Co., Ltd. Z170X-UD5/Z170X-UD5-CF, BIOS 
> F5 03/07/2016
>   Call Trace:
> dump_stack+0x63/0x82
> kasan_report_error+0x4b4/0x4e0
> ? acpi_hw_read_port+0xd0/0x1ea
> ? kfree_const+0x22/0x30
> ? acpi_hw_validate_io_request+0x1a6/0x1a6
> __asan_report_load8_noabort+0x61/0x70
> ? unwind_get_return_address+0x11d/0x130
> unwind_get_return_address+0x11d/0x130
> ? unwind_next_frame+0x97/0xf0
> __save_stack_trace+0x92/0x100
> save_stack_trace+0x1b/0x20
> save_stack+0x46/0xd0
> ? save_stack_trace+0x1b/0x20
> ? save_stack+0x46/0xd0
> ? kasan_kmalloc+0xad/0xe0
> ? kasan_slab_alloc+0x12/0x20
> ? acpi_hw_read+0x2b6/0x3aa
> ? acpi_hw_validate_register+0x20b/0x20b
> ? acpi_hw_write_port+0x72/0xc7
> ? acpi_hw_write+0x11f/0x15f
> ? acpi_hw_read_multiple+0x19f/0x19f
> ? memcpy+0x45/0x50
> ? acpi_hw_write_port+0x72/0xc7
> ? acpi_hw_write+0x11f/0x15f
> ? acpi_hw_read_multiple+0x19f/0x19f
> ? kasan_unpoison_shadow+0x36/0x50
> kasan_kmalloc+0xad/0xe0
> kasan_slab_alloc+0x12/0x20
> kmem_cache_alloc_trace+0xbc/0x1e0
> ? acpi_get_sleep_type_data+0x9a/0x578
> acpi_get_sleep_type_data+0x9a/0x578
> acpi_hw_legacy_wake_prep+0x88/0x22c
> ? acpi_hw_legacy_sleep+0x3c7/0x3c7
> ? acpi_write_bit_register+0x28d/0x2d3
> ? acpi_read_bit_register+0x19b/0x19b
> acpi_hw_sleep_dispatch+0xb5/0xba
> acpi_leave_sleep_state_prep+0x17/0x19
> acpi_suspend_enter+0x154/0x1e0
> ? trace_suspend_resume+0xe8/0xe8
> suspend_devices_and_enter+0xb09/0xdb0
> ? printk+0xa8/0xd8
> ? arch_suspend_enable_irqs+0x20/0x20
> ? try_to_freeze_tasks+0x295/0x600
> pm_suspend+0x6c9/0x780
> ? finish_wait+0x1f0/0x1f0
> ? suspend_devices_and_enter+0xdb0/0xdb0
> state_store+0xa2/0x120
> ? kobj_attr_show+0x60/0x60
> kobj_attr_store+0x36/0x70
> sysfs_kf_write+0x131/0x200
> kernfs_fop_write+0x295/0x3f0
> __vfs_write+0xef/0x760
> ? handle_mm_fault+0x1346/0x35e0
> ? do_iter_readv_writev+0x660/0x660
> ? __pmd_alloc+0x310/0x310
> ? do_lock_file_wait+0x1e0/0x1e0
> ? apparmor_file_permission+0x18/0x20
> ? security_file_permission+0x73/0x1c0
> ? rw_verify_area+0xbd/0x2b0
> vfs_write+0x149/0x4a0
> SyS_write+0xd9/0x1c0
> ? SyS_read+0x1c0/0x1c0
> entry_SYSCALL_64_fastpath+0x1e/0xad
>   Memory state around the buggy address:
>8803867d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>8803867d7780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   >8803867d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f4
>   ^
>8803867d7880: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>8803867d7900: 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f3 f3 f3 f3 00
> 
> KASAN instrumentation poisons the stack when entering a function and
> unpoisons it when exiting the function.  However, in the suspend path,
> some functions never return, so their stack never gets unpoisoned,
> resulting in stale KASAN shadow data which can cause later false
> positive warnings like the one above.
> 
> Reported-by: Scott Bauer 
> Signed-off-by: Josh Poimboeuf 

Acked-by: Andrey Ryabinin 

Re: [PATCH] clk: Register clkdev after setup of fixed-rate and fixed-factor clocks

[Xiaolong Zhang]

On 二, 11月 29, 2016 at 01:10:54下午 -0800, Stephen Boyd wrote:
> On 11/24, Xiaolong Zhang wrote:
> > On 三, 11月 23, 2016 at 04:38:33下午 -0800, Stephen Boyd wrote:
> > 
> > > We're really off track now though. Can you please point to some
> > > code that needs this change? If we're using DT then we should be
> > > able to use the of_clk_*() path to find the clk.
> > >
> > 
> > Actually, the requirement is raised by our GPU driver. In the
> > early stage of the GPU DT driver, the GPU driver use the
> > clk_get(NULL, con_id) to get the clock instance for compatible
> > with non-DT GPU driver. The new driver have used the of_clk_get()
> > instead of the clk_get. And we reserved the modification in clock.
> > 
> 
> Ok the non-DT version of the GPU driver should be modified to
> call clk_get() and pass in the device. The con_id argument there
> should be something specific to the GPU device, and not a global
> name of a clock on the system. When the clkdev lookup is
> populated on the non-DT board make sure to set the dev_id string
> to match the device name of the GPU device.
>
Ok, Thanks sBoyd!
>
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

[Ingo Molnar]

* Boris Ostrovsky  wrote:

> > It is tricky to do so safely, because at this stage almost nothing of the C 
> > execution environment has been set up.

Yeah - but we do have a fair amount of early C code though.

> I can still give it a try but I'd rather not tie it to this (Xen PVH) patch 
> series. Which would leave me with two options: either keep what this patch 
> does, 
> leaving it as assembly (requires your ack), or have Xen code build the pages 
> on 
> its own.

If you give it a try in a subsequent patch (please Cc: me) then it's OK to me:

  Acked-by: Ingo Molnar 

Feel free to carry it in the Xen tree.

Thanks,

Ingo

Re: [PATCH] hotplug: make register and unregister notifier API symmetric

[kbuild test robot]

Hi Michal,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc7 next-20161202]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Michal-Hocko/hotplug-make-register-and-unregister-notifier-API-symmetric/20161203-114815
config: i386-randconfig-s1-201648 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   mm/built-in.o: In function `zs_unregister_cpu_notifier':
>> zsmalloc.c:(.text.unlikely+0xc7e): undefined reference to 
>> `__unregister_cpu_notifier'
   arch/x86/oprofile/built-in.o: In function `nmi_timer_shutdown':
   nmi_timer_int.c:(.text+0x1c7d): undefined reference to 
`__unregister_cpu_notifier'
   arch/x86/oprofile/built-in.o: In function `nmi_shutdown':
   nmi_int.c:(.text+0x2319): undefined reference to `__unregister_cpu_notifier'

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


.config.gz
Description: application/gzip

3.5%LOAN OFFER

[DIRECT LOANS.]

APPLY 3.5%LOAN.pdf
Description: Adobe PDF document


Application Form.pdf
Description: Adobe PDF document

Re: [PATCH 1/7] vfs - merge path_is_mountpoint() and path_is_mountpoint_rcu()

[Al Viro]

FWIW, I've folded that pile into vfs.git#work.autofs.

Problems:
* (fixed) __path_is_mountpoint() should _not_ treat NULL from
__lookup_mnt() as "nothing's mounted there" until it has checked
that mount_lock hadn't been touched - mount --move on something unrelated
can race with lockless hash lookup and lead to false negatives.
* linux/mount.h might be the wrong place for path_is_mountpoint().
Or it shouldn't be inlined.  I don't like the includes you've added there.
* path_has_submounts() is broken.  At the very least, it's
AB-BA between mount_lock and rename_lock.  I would suggest trying to
put read_seqlock_excl(_lock) around the call of d_walk() in there,
and using __lookup_mnt() in the callback (without retries on the mount_lock,
of course - read_seqlock_excl done on the outside is enough).  I'm not sure
if it won't cause trouble with contention, though; that needs testing.  As
it is, that function is broken in #work.autofs, same as it is in -mm and
-next.
* the last one (propagation-related) is too ugly to live - at the
very least, its pieces should live in fs/pnode.c; exposing propagate_next()
is simply wrong.  I hadn't picked that one at all, and I would suggest
coordinating anything in that area with ebiederman - he has some work
around fs/pnode.c and you risk stepping on his toes.

[PATCH] remoteproc: Remove "experimental" warning

[Bjorn Andersson]

Warning users that remoteproc and it's binary format are under
development doesn't serve much of a purpose. Different drivers support
different image formats and the resource table has a version field that
would need to be bumped when incompatible changes are introduced.

So lets drop this warning to clean up the kernel log.

Signed-off-by: Bjorn Andersson 
---
 drivers/remoteproc/remoteproc_core.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index f0f6ec1ab12b..fc2ebff7d332 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1298,9 +1298,6 @@ int rproc_add(struct rproc *rproc)
 
dev_info(dev, "%s is available\n", rproc->name);
 
-   dev_info(dev, "Note: remoteproc is still under development and 
considered experimental.\n");
-   dev_info(dev, "THE BINARY FORMAT IS NOT YET FINALIZED, and backward 
compatibility isn't yet guaranteed.\n");
-
/* create debugfs entries */
rproc_create_debug_dir(rproc);
ret = rproc_add_virtio_devices(rproc);
-- 
2.5.0

Re: [PATCH] hotplug: make register and unregister notifier API symmetric

[kbuild test robot]

Hi Michal,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc7 next-20161202]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Michal-Hocko/hotplug-make-register-and-unregister-notifier-API-symmetric/20161203-114815
config: i386-randconfig-r0-201648 (attached as .config)
compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/oprofile/built-in.o: In function `nmi_timer_shutdown':
>> nmi_timer_int.c:(.text+0x238b): undefined reference to 
>> `__unregister_cpu_notifier'
   arch/x86/oprofile/built-in.o: In function `nmi_shutdown':
   nmi_int.c:(.text+0x2793): undefined reference to `__unregister_cpu_notifier'

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


.config.gz
Description: application/gzip

[PATCH] btrfs: limit async_work allocation and worker func duration

[Maxim Patlasov]

Problem statement: unprivileged user who has read-write access to more than
one btrfs subvolume may easily consume all kernel memory (eventually
triggering oom-killer).

Reproducer (./mkrmdir below essentially loops over mkdir/rmdir):

[root@kteam1 ~]# cat prep.sh

DEV=/dev/sdb
mkfs.btrfs -f $DEV
mount $DEV /mnt
for i in `seq 1 16`
do
mkdir /mnt/$i
btrfs subvolume create /mnt/SV_$i
ID=`btrfs subvolume list /mnt |grep "SV_$i$" |cut -d ' ' -f 2`
mount -t btrfs -o subvolid=$ID $DEV /mnt/$i
chmod a+rwx /mnt/$i
done

[root@kteam1 ~]# sh prep.sh

[maxim@kteam1 ~]$ for i in `seq 1 16`; do ./mkrmdir /mnt/$i 2000 2000 & done

[root@kteam1 ~]# for i in `seq 1 4`; do grep "kmalloc-128" /proc/slabinfo | 
grep -v dma; sleep 60; done
kmalloc-12810144  10144128   321 : tunables000 : 
slabdata317317  0
kmalloc-128   9992352 9992352128   321 : tunables000 : 
slabdata 312261 312261  0
kmalloc-128   24226752 24226752128   321 : tunables000 
: slabdata 757086 757086  0
kmalloc-128   42754240 42754240128   321 : tunables000 
: slabdata 1336070 1336070  0

The huge numbers above come from insane number of async_work-s allocated
and queued by btrfs_wq_run_delayed_node.

The problem is caused by btrfs_wq_run_delayed_node() queuing more and more
works if the number of delayed items is above BTRFS_DELAYED_BACKGROUND. The
worker func (btrfs_async_run_delayed_root) processes at least
BTRFS_DELAYED_BATCH items (if they are present in the list). So, the machinery
works as expected while the list is almost empty. As soon as it is getting
bigger, worker func starts to process more than one item at a time, it takes
longer, and the chances to have async_works queued more than needed is getting
higher.

The problem above is worsened by another flaw of delayed-inode implementation:
if async_work was queued in a throttling branch (number of items >=
BTRFS_DELAYED_WRITEBACK), corresponding worker func won't quit until
the number of items < BTRFS_DELAYED_BACKGROUND / 2. So, it is possible that
the func occupies CPU infinitely (up to 30sec in my experiments): while the
func is trying to drain the list, the user activity may add more and more
items to the list.

The patch fixes both problems in straightforward way: refuse queuing too
many works in btrfs_wq_run_delayed_node and bail out of worker func if
at least BTRFS_DELAYED_WRITEBACK items are processed.

Signed-off-by: Maxim Patlasov 
---
 fs/btrfs/async-thread.c  |8 
 fs/btrfs/async-thread.h  |1 +
 fs/btrfs/delayed-inode.c |6 --
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c
index e0f071f..29f6252 100644
--- a/fs/btrfs/async-thread.c
+++ b/fs/btrfs/async-thread.c
@@ -86,6 +86,14 @@ btrfs_work_owner(struct btrfs_work *work)
return work->wq->fs_info;
 }
 
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq)
+{
+   int thresh = wq->normal->thresh != NO_THRESHOLD ?
+   wq->normal->thresh : num_possible_cpus();
+
+   return atomic_read(>normal->pending) > thresh * 2;
+}
+
 BTRFS_WORK_HELPER(worker_helper);
 BTRFS_WORK_HELPER(delalloc_helper);
 BTRFS_WORK_HELPER(flush_delalloc_helper);
diff --git a/fs/btrfs/async-thread.h b/fs/btrfs/async-thread.h
index 8e52484..1f95973 100644
--- a/fs/btrfs/async-thread.h
+++ b/fs/btrfs/async-thread.h
@@ -84,4 +84,5 @@ void btrfs_workqueue_set_max(struct btrfs_workqueue *wq, int 
max);
 void btrfs_set_work_high_priority(struct btrfs_work *work);
 struct btrfs_fs_info *btrfs_work_owner(struct btrfs_work *work);
 struct btrfs_fs_info *btrfs_workqueue_owner(struct __btrfs_workqueue *wq);
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq);
 #endif
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 3eeb9cd..de946dd 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1356,7 +1356,8 @@ release_path:
total_done++;
 
btrfs_release_prepared_delayed_node(delayed_node);
-   if (async_work->nr == 0 || total_done < async_work->nr)
+   if ((async_work->nr == 0 && total_done < BTRFS_DELAYED_WRITEBACK) ||
+   total_done < async_work->nr)
goto again;
 
 free_path:
@@ -1372,7 +1373,8 @@ static int btrfs_wq_run_delayed_node(struct 
btrfs_delayed_root *delayed_root,
 {
struct btrfs_async_delayed_work *async_work;
 
-   if (atomic_read(_root->items) < BTRFS_DELAYED_BACKGROUND)
+   if (atomic_read(_root->items) < BTRFS_DELAYED_BACKGROUND ||
+   btrfs_workqueue_normal_congested(fs_info->delayed_workers))
return 0;
 
async_work = kmalloc(sizeof(*async_work), GFP_NOFS);

[x86/asm] cdfac81296: kernel_BUG_at_arch/x86/kernel/alternative.c

[kernel test robot]

FYI, we noticed the following commit:

commit: cdfac8129693572ef91b9e7022d6ae07f1c8cc38 ("x86/asm: Rewrite sync_core() 
to use IRET-to-self")
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/boot

in testcase: boot

on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 256M

caused below changes:


+-+++
| | 535a025bb9 | cdfac81296 |
+-+++
| boot_successes  | 6  | 0  |
| boot_failures   | 0  | 4  |
| kernel_BUG_at_arch/x86/kernel/alternative.c | 0  | 4  |
| invalid_opcode:#[##]SMP | 0  | 4  |
| EIP_is_at_apply_alternatives| 0  | 4  |
| Kernel_panic-not_syncing:Fatal_exception| 0  | 4  |
+-+++



[0.429066] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.447516] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.455310] [ cut here ]
[0.459612] kernel BUG at arch/x86/kernel/alternative.c:386!
[0.465842] invalid opcode:  [#1] SMP
[0.469305] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.9.0-rc7-00027-gcdfac81 #1
[0.476137] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[0.483617] task: c84cb040 task.stack: c84c4000
[0.486773] EIP: 0060:[] EFLAGS: 00210246 CPU: 0
[0.490857] EIP is at apply_alternatives+0xa5/0x7e3
[0.494426] EAX: d83b0ff0 EBX: c84abb75 ECX:  EDX: 00ae
[0.499509] ESI: 0004 EDI: c84c5eb6 EBP: c84c5fbc ESP: c84c5e90
[0.503883]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
[0.508031] CR0: 80050033 CR2:  CR3: 089df000 CR4: 0690
[0.512150] Stack:
[0.514412]  c69f2b7c 0003 0004 fbfb 0ff0ae0f 0089 c84abb81 
d83b6984
[0.529825]  e58900e8 cf49340f c84c5eec 0002 c888dba0 c84c5f74 c84c5ed4 
c683cc1e
[0.537271]  c84c5f00 c84c5f14 c683d4f7 c84c5f00 002b c84c5f60 0143 
03c0003f
[0.545924] Call Trace:
[0.548885]  [] ? __kmem_cache_create+0x37d/0x5c7
[0.552895]  [] ? __cpuid+0x1a/0x2e
[0.556362]  [] ? cpuid4_cache_lookup_regs+0x4ad/0x52f


To reproduce:

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.9.0-rc7 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=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_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=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 is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_KERNEL_LZ4=y
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=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Duc Dang]

On Fri, Dec 2, 2016 at 3:39 PM, Bjorn Helgaas  wrote:
>
> On Thu, Dec 01, 2016 at 11:08:23PM -0500, Jon Masters wrote:
> > Hi Bjorn, Duc, Mark,
> >
> > I switched my brain to the on mode and went and read some specs, and a few
> > tables, so here's my 2 cents on this...
> >
> > On 12/01/2016 06:22 PM, Duc Dang wrote:
> > > On Thu, Dec 1, 2016 at 3:07 PM, Bjorn Helgaas  wrote:
> > >> On Thu, Dec 01, 2016 at 02:10:10PM -0800, Duc Dang wrote:
> >
> > > The SoC provide some number of RC bridges, each with a different base
> > > for some mmio registers. Even if segment is legitimate in MCFG, there
> > > is still a problem if a platform doesn't use the segment ordering
> > > implied by the code. But the PNP0A03 _CRS does have this base address
> > > as the first memory resource, so we could get it from there and not
> > > have hard-coded addresses and implied ording in the quirk code.
> > 
> >  I'm confused.  Doesn't the current code treat every item in PNP0A03
> >  _CRS as a window?  Do you mean the first resource is handled
> >  differently somehow?  The Consumer/Producer bit could allow us to do
> >  this by marking the RC MMIO space as "Consumer", but I didn't think
> >  that strategy was quite working yet.
> >
> > Let's see if I summarized this correctly...
> >
> > 1. The MMIO registers for the host bridge itself need to be described
> >somewhere, especially if we need to find those in a quirk and poke
> >them. Since those registers are very much part of the bridge device,
> >it makes sense for them to be in the _CRS for PNP0A08/PNP0A03.
> >
> > 2. The address space covering these registers MUST be described as a
> >ResourceConsumer in order to avoid accidentally exposing them as
> >available for use by downstream devices on the PCI bus.
> >
> > 3. The ACPI specification allows for resources of the type "Memory32Fixed".
> >This is a macro that doesn't have the notion of a producer or consumer.
> >HOWEVER various interpretations seem to be that this could/should
> >default to being interpreted as a consumed region.
>
> I agree; I think that per spec, Memory24, Memory32, Memory32Fixed, IO,
> and FixedIO should all be for consumed resources, not for bridge
> windows, since they don't have the notion of producer.
>
> I'm pretty sure there's x86 firmware in the field that uses these for
> windows, so I think we have to accept that usage, at least on x86.
>
> > 4. At one point, a regression was added to the kernel:
> >
> >63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
> >host bridge itself")
> >
> >Which lead to a series on conversations about what should happen
> >for bridge resources (e.g. https://lkml.org/lkml/2015/3/24/962 )
> >
> > 5. This resulted in the following commit reverting point 4:
> >
> >2c62e8492ed7 ("x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff]
> >available on PCI bus")
> >
> >Which also stated that:
> >
> >"This solution will also ease the way to consolidate ACPI PCI host
> > bridge common code from x86, ia64 and ARM64"
> >
> > End of summary.
> >
> > So it seems that generally there is an aversion to having bridge resources
> > be described in this manner and you would like to require that they be
> > described e.g. using QWordMemory with a ResourceConsumer type?
>
> Per spec, we should ignore the Consumer/Producer bit in Word/DWord/QWord
> descriptors.  In bridge devices on x86, I think we have to treat them as
> producers (windows) because that's how they've been typically used.
>
> > BUT if we were to do that, it would break existing shipping systems since
> > there are quirks out there that use this form to find the base CSR:
> >
> >if (acpi_res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
> > fixed32 = _res->data.fixed_memory32;
> > port->csr_base = ioremap(fixed32->address,
> >  fixed32->address_length);
> > return AE_CTRL_TERMINATE;
> > }
>
> I think this is a valid usage of FixedMemory32 in terms of the spec.
> Linux currently handles this as a window if it appears in a PNP0A03
> device because some x86 firmware used it that way.
>
> We might be able to handle it differently on arm64, e.g., by making an
> arm64 version of pci_acpi_root_prepare_resources() that checks for
> IORESOURCE_WINDOW.
>
> > 2. What would happen if we had a difference policy on arm64 for such
> >resources. x86 has an "exception" for accessing the config space
> >using IO port 0xCF8-0xCFF (a fairly reasonable exception!) and
> >we can make the rules for a new platform (i.e. actually prescribe
> >exactly what the behavior is, rather than have it not be defined).
> >This is of course terrible in that existing BIOS vendors and so on
> >won't necessarily know this when working on ARM ACPI later on.
>
> > Indeed. And 

Re: [PATCH] staging: Replaced BUG_ON with warnings

[Allen]

On Sat, Dec 3, 2016 at 12:32 PM, Shilpa Puttegowda  wrote:
> From: Shilpa P 
>
> Don't crash the Kernel for driver errors
>
> Signed-off-by: Shilpa P 
> ---
>  drivers/staging/media/bcm2048/radio-bcm2048.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>

Acked-by: Allen Pais 

[PATCH] Fix style issues in kernel/cpu.c

[Thomas Casey]

This patch fixes style issues in kernel/cpu.c such as wrapping an 80
character line, calling EXPORT_SYMBOL() immediately after a function is
defined, and whitespace and spacing issues.

Signed-off-by: Thomas Casey 
---
 kernel/cpu.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 29de1a9..15a90ba 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -228,7 +228,8 @@ static struct {
.wq = __WAIT_QUEUE_HEAD_INITIALIZER(cpu_hotplug.wq),
.lock = __MUTEX_INITIALIZER(cpu_hotplug.lock),
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
-   .dep_map = STATIC_LOCKDEP_MAP_INIT("cpu_hotplug.dep_map", 
_hotplug.dep_map),
+   .dep_map = STATIC_LOCKDEP_MAP_INIT("cpu_hotplug.dep_map",
+   _hotplug.dep_map),
 #endif
 };
 
@@ -304,7 +305,7 @@ void cpu_hotplug_begin(void)
mutex_lock(_hotplug.lock);
prepare_to_wait(_hotplug.wq, , TASK_UNINTERRUPTIBLE);
if (likely(!atomic_read(_hotplug.refcount)))
-   break;
+   break;
mutex_unlock(_hotplug.lock);
schedule();
}
@@ -353,6 +354,7 @@ EXPORT_SYMBOL_GPL(cpu_hotplug_enable);
 int register_cpu_notifier(struct notifier_block *nb)
 {
int ret;
+
cpu_maps_update_begin();
ret = raw_notifier_chain_register(_chain, nb);
cpu_maps_update_done();
@@ -363,6 +365,7 @@ int __register_cpu_notifier(struct notifier_block *nb)
 {
return raw_notifier_chain_register(_chain, nb);
 }
+EXPORT_SYMBOL(__register_cpu_notifier);
 
 static int __cpu_notify(unsigned long val, unsigned int cpu, int nr_to_call,
int *nr_calls)
@@ -661,7 +664,6 @@ void __init cpuhp_threads_init(void)
 
 #ifdef CONFIG_HOTPLUG_CPU
 EXPORT_SYMBOL(register_cpu_notifier);
-EXPORT_SYMBOL(__register_cpu_notifier);
 void unregister_cpu_notifier(struct notifier_block *nb)
 {
cpu_maps_update_begin();
@@ -1250,7 +1252,7 @@ static struct cpuhp_step cpuhp_bp_states[] = {
.teardown.single= NULL,
},
 #ifdef CONFIG_SMP
-   [CPUHP_CREATE_THREADS]= {
+   [CPUHP_CREATE_THREADS] = {
.name   = "threads:prepare",
.startup.single = smpboot_create_threads,
.teardown.single= NULL,
@@ -1366,7 +1368,8 @@ static struct cpuhp_step cpuhp_ap_states[] = {
.teardown.single= rcutree_dying_cpu,
},
/* Entry state on starting. Interrupts enabled from here on. Transient
-* state for synchronsization */
+* state for synchronsization
+*/
[CPUHP_AP_ONLINE] = {
.name   = "ap:online",
},
-- 
2.10.2

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

[hpa]

On December 2, 2016 9:49:50 PM PST, Ingo Molnar  wrote:
>
>* Boris Ostrovsky  wrote:
>
>> > It is tricky to do so safely, because at this stage almost nothing
>of the C 
>> > execution environment has been set up.
>
>Yeah - but we do have a fair amount of early C code though.
>
>> I can still give it a try but I'd rather not tie it to this (Xen PVH)
>patch 
>> series. Which would leave me with two options: either keep what this
>patch does, 
>> leaving it as assembly (requires your ack), or have Xen code build
>the pages on 
>> its own.
>
>If you give it a try in a subsequent patch (please Cc: me) then it's OK
>to me:
>
>  Acked-by: Ingo Molnar 
>
>Feel free to carry it in the Xen tree.
>
>Thanks,
>
>   Ingo

It's true that it is now possible to run pre-paging C code.  It would be so 
much better if Xen could simply go though the normal code path like any 
civilized machine.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[PATCH] staging: Replaced BUG_ON with warnings

[Shilpa Puttegowda]

From: Shilpa P 

Don't crash the Kernel for driver errors

Signed-off-by: Shilpa P 
---
 drivers/staging/media/bcm2048/radio-bcm2048.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 4d9bd02..05f5918 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -1538,7 +1538,11 @@ static int bcm2048_parse_rt_match_c(struct 
bcm2048_device *bdev, int i,
if (crc == BCM2048_RDS_CRC_UNRECOVARABLE)
return 0;
 
-   BUG_ON((index+2) >= BCM2048_MAX_RDS_RT);
+   if ((index + 2) >= BCM2048_MAX_RDS_RT) {
+   dev_err(>client->dev,
+   "Incorrect index = %d\n", index);
+   return 0;
+   }
 
if ((bdev->rds_info.radio_text[i] & BCM2048_RDS_BLOCK_MASK) ==
BCM2048_RDS_BLOCK_C) {
@@ -1561,7 +1565,11 @@ static void bcm2048_parse_rt_match_d(struct 
bcm2048_device *bdev, int i,
if (crc == BCM2048_RDS_CRC_UNRECOVARABLE)
return;
 
-   BUG_ON((index+4) >= BCM2048_MAX_RDS_RT);
+   if ((index + 4) >= BCM2048_MAX_RDS_RT) {
+   dev_err(>client->dev,
+   "Incorrect index = %d\n", index);
+   return;
+   }
 
if ((bdev->rds_info.radio_text[i] & BCM2048_RDS_BLOCK_MASK) ==
BCM2048_RDS_BLOCK_D)
-- 
1.9.1

Re: [PATCH v2] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR

[kbuild test robot]

Hi Michael,

[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on v4.9-rc7]
[cannot apply to next-20161202]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Michael-Ellerman/lkdtm-Add-tests-for-LIST_POISON-and-ZERO_SIZE_PTR/20161203-124958
config: blackfin-allyesconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
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=blackfin 

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

   In file included from include/linux/cache.h:4:0,
from include/linux/printk.h:8,
from include/linux/kernel.h:13,
from drivers/misc/lkdtm.h:6,
from drivers/misc/lkdtm_bugs.c:7:
   drivers/misc/lkdtm_bugs.c: In function 'test_poison_ptr':
>> drivers/misc/lkdtm_bugs.c:160:20: error: 'CONFIG_DEFAULT_MMAP_MIN_ADDR' 
>> undeclared (first use in this function)
 bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
   ^
   include/uapi/linux/kernel.h:10:41: note: in definition of macro 
'__ALIGN_KERNEL_MASK'
#define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
^
>> include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
#define ALIGN(x, a)  __ALIGN_KERNEL((x), (a))
 ^~
>> include/linux/mm.h:126:26: note: in expansion of macro 'ALIGN'
#define PAGE_ALIGN(addr) ALIGN(addr, PAGE_SIZE)
 ^
>> drivers/misc/lkdtm_bugs.c:160:9: note: in expansion of macro 'PAGE_ALIGN'
 bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
^~
   drivers/misc/lkdtm_bugs.c:160:20: note: each undeclared identifier is 
reported only once for each function it appears in
 bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
   ^
   include/uapi/linux/kernel.h:10:41: note: in definition of macro 
'__ALIGN_KERNEL_MASK'
#define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
^
>> include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
#define ALIGN(x, a)  __ALIGN_KERNEL((x), (a))
 ^~
>> include/linux/mm.h:126:26: note: in expansion of macro 'ALIGN'
#define PAGE_ALIGN(addr) ALIGN(addr, PAGE_SIZE)
 ^
>> drivers/misc/lkdtm_bugs.c:160:9: note: in expansion of macro 'PAGE_ALIGN'
 bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
^~

vim +/CONFIG_DEFAULT_MMAP_MIN_ADDR +160 drivers/misc/lkdtm_bugs.c

 1  /*
 2   * This is for all the tests related to logic bugs (e.g. bad 
dereferences,
 3   * bad alignment, bad loops, bad locking, bad scheduling, deep stacks, 
and
 4   * lockups) along with other things that don't fit well into existing 
LKDTM
 5   * test source files.
 6   */
   > 7  #include "lkdtm.h"
 8  #include 
 9  #include 
10  #include 
11  #include 
12  
13  /*
14   * Make sure our attempts to over run the kernel stack doesn't trigger
15   * a compiler warning when CONFIG_FRAME_WARN is set. Then make sure we
16   * recurse past the end of THREAD_SIZE by default.
17   */
18  #if defined(CONFIG_FRAME_WARN) && (CONFIG_FRAME_WARN > 0)
19  #define REC_STACK_SIZE (CONFIG_FRAME_WARN / 2)
20  #else
21  #define REC_STACK_SIZE (THREAD_SIZE / 8)
22  #endif
23  #define REC_NUM_DEFAULT ((THREAD_SIZE / REC_STACK_SIZE) * 2)
24  
25  static int recur_count = REC_NUM_DEFAULT;
26  
27  static DEFINE_SPINLOCK(lock_me_up);
28  
29  static int recursive_loop(int remaining)
30  {
31  char buf[REC_STACK_SIZE];
32  
33  /* Make sure compiler does not optimize this away. */
34  memset(buf, (remaining & 0xff) | 0x1, REC_STACK_SIZE);
35  if (!remaining)
36  return 0;
37  else
38  return recursive_loop(remaining - 1);
39  }
40  
41  /* If the depth is negative, use the default, otherwise keep parameter. 
*/
42  void __init lkdtm_bugs_init(int *recur_param)
43  {
44  if (*recur_param < 0)
45  *recur_param = recur_count;
46  else
47  recur_count = *recur_param;
48  }
49  
50  void lkdtm_PANIC(void)
51  {
52  panic("dumptest");
53  }
54  
55  void lkdtm_BUG(void)
56  {
57  BUG();
58  }
59  
60  void lk

Re: [PATCH 1/3] ARM: dts: at91: add dma1 definition to sama5d2

[Alexandre Belloni]

On 01/12/2016 at 11:49:47 +0100, Nicolas Ferre wrote :
> The sama5d2 SoC has a second DMA controller and can be used just like DMA0.
> By default both DMA controllers are configured as "Secure" in
> MATRIX_SPSELR so we can use whichever we want in a "single Secure World"
> configuration.
> Surprisingly the DMA1 has a lower address than DMA0. To avoid confusion
> place it after DMA0 node anyway.
> 

sama5d2.dtsi is probably the only one that is properly ordered and I
feel like we should keep it this way.

If one of the nodes is not ordered properly, other ones will follow...
We don't care about the name, it is just an alias. We only care about
the address.


> Signed-off-by: Nicolas Ferre 
> ---
>  arch/arm/boot/dts/sama5d2.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
> index ceb9783ff7e1..c791ce9c750c 100644
> --- a/arch/arm/boot/dts/sama5d2.dtsi
> +++ b/arch/arm/boot/dts/sama5d2.dtsi
> @@ -395,6 +395,16 @@
>   clock-names = "dma_clk";
>   };
>  
> + /* Place dma1 here despite its address */
> + dma1: dma-controller@f0004000 {
> + compatible = "atmel,sama5d4-dma";
> + reg = <0xf0004000 0x1000>;
> + interrupts = <7 IRQ_TYPE_LEVEL_HIGH 0>;
> + #dma-cells = <1>;
> + clocks = <_clk>;
> + clock-names = "dma_clk";
> + };
> +
>   pmc: pmc@f0014000 {
>   compatible = "atmel,sama5d2-pmc", "syscon";
>   reg = <0xf0014000 0x160>;
> -- 
> 2.9.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 5/7] Documentation: DT: net: cpsw: allow to specify descriptors pool size

[Ivan Khoronzhuk]

On Thu, Dec 01, 2016 at 05:34:30PM -0600, Grygorii Strashko wrote:
> Add optional property "descs_pool_size" to specify buffer descriptor's
> pool size. The "descs_pool_size" should define total number of CPDMA
> CPPI descriptors to be used for both ingress/egress packets
> processing. If not specified - the default value 256 will be used
> which will allow to place descriptor's pool into the internal CPPI
> RAM on most of TI SoC.
> 
> Signed-off-by: Grygorii Strashko 
> ---
>  Documentation/devicetree/bindings/net/cpsw.txt | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
> b/Documentation/devicetree/bindings/net/cpsw.txt
> index 5ad439f..b99d196 100644
> --- a/Documentation/devicetree/bindings/net/cpsw.txt
> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
> @@ -35,6 +35,11 @@ Optional properties:
> For example in dra72x-evm, pcf gpio has to be
> driven low so that cpsw slave 0 and phy data
> lines are connected via mux.
> +- descs_pool_size: total number of CPDMA CPPI descriptors to be used for
> +   both ingress/egress packets processing. if not
> +   specified the default value 256 will be used which
> +   will allow to place descriptors pool into the
> +   internal CPPI RAM.
Does it describe h/w? Why now module parameter? or even smth like ethtool num
ring entries?

>  
>  Slave Properties:
> -- 
> 2.10.1
> 

Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

[Andrew Cooper]

On 02/12/16 00:35, Andy Lutomirski wrote:
> On Xen PV, CPUID is likely to trap, and Xen hypercalls aren't
> guaranteed to serialize.  (Even CPUID isn't *really* guaranteed to
> serialize on Xen PV, but, in practice, any trap it generates will
> serialize.)

Well, Xen will enabled CPUID Faulting wherever it can, which is
realistically all IvyBridge hardware and newer.

All hypercalls are a privilege change to cpl0.  I'd hope this condition
is serialising, but I can't actually find any documentation proving or
disproving this.

>
> On my laptop, CPUID(eax=1, ecx=0) is ~83ns and IRET-to-self is
> ~110ns.  But Xen PV will trap CPUID if possible, so IRET-to-self
> should end up being a nice speedup.
>
> Cc: Andrew Cooper 
> Signed-off-by: Andy Lutomirski 

CC'ing xen-devel and the Xen maintainers in Linux.

As this is the only email from this series in my inbox, I will say this
here, but it should really be against patch 6.

A write to %cr2 is apparently (http://sandpile.org/x86/coherent.htm) not
serialising on the 486, but I don't have a manual to hand to check.

~Andrew

> ---
>  arch/x86/xen/enlighten.c | 35 +++
>  1 file changed, 35 insertions(+)
>
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index bdd855685403..1f765b41eee7 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -311,6 +311,39 @@ static __read_mostly unsigned int 
> cpuid_leaf1_ecx_set_mask;
>  static __read_mostly unsigned int cpuid_leaf5_ecx_val;
>  static __read_mostly unsigned int cpuid_leaf5_edx_val;
>  
> +static void xen_sync_core(void)
> +{
> + register void *__sp asm(_ASM_SP);
> +
> +#ifdef CONFIG_X86_32
> + asm volatile (
> + "pushl %%ss\n\t"
> + "pushl %%esp\n\t"
> + "addl $4, (%%esp)\n\t"
> + "pushfl\n\t"
> + "pushl %%cs\n\t"
> + "pushl $1f\n\t"
> + "iret\n\t"
> + "1:"
> + : "+r" (__sp) : : "cc");
> +#else
> + unsigned long tmp;
> +
> + asm volatile (
> + "movq %%ss, %0\n\t"
> + "pushq %0\n\t"
> + "pushq %%rsp\n\t"
> + "addq $8, (%%rsp)\n\t"
> + "pushfq\n\t"
> + "movq %%cs, %0\n\t"
> + "pushq %0\n\t"
> + "pushq $1f\n\t"
> + "iretq\n\t"
> + "1:"
> + : "=r" (tmp), "+r" (__sp) : : "cc");
> +#endif
> +}
> +
>  static void xen_cpuid(unsigned int *ax, unsigned int *bx,
> unsigned int *cx, unsigned int *dx)
>  {
> @@ -1289,6 +1322,8 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst 
> = {
>  
>   .start_context_switch = paravirt_start_context_switch,
>   .end_context_switch = xen_end_context_switch,
> +
> + .sync_core = xen_sync_core,
>  };
>  
>  static void xen_reboot(int reason)

Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses.

[Pavel Machek]

Hi!

> >Well, if you have a workload that sends and receive packets, it tends
> >to work ok, as you do tx_clean() in stmmac_poll(). My workload is not
> >like that -- it is "sending packets at 3MB/sec, receiving none". So
> >the stmmac_tx_timer() is rescheduled and rescheduled and rescheduled,
> >and then we run out of transmit descriptors, and then 40msec passes,
> >and then we clean them. Bad.
> >
> >And that's why low-res timers do not cut it.
> 
> in that case, I expect that the tuning of the driver could help you.
> I mean, by using ethtool, it could be enough to set the IC bit on all
> the descriptors. You should touch the tx_coal_frames.
> 
> Then you can use ethtool -S to monitor the status.

Yes, I did something similar. Unfortnunately that meant crash within
minutes, at least with 4.4 kernel. (If you know what was fixed between
4.4 and 4.9, that would be helpful).

> We had experimented this tuning on STB IP where just datagrams
> had to send externally. To be honest, although we had seen
> better results w/o any timer, we kept this approach enabled
> because the timer was fast enough to cover our tests on SH4 boxes.

Please reply to David, and explain how it is supposed to
work... because right now it does not. 40 msec delays are not
acceptable in default configuration.

> >>In the ring, some descriptors can raise the irq (according to a
> >>threshold) and set the IC bit. In this path, the NAPI  poll will be
> >>scheduled.
> >
> >Not NAPI poll but stmmac_tx_timer(), right?
> 
> in the xmit according the the threshold the timer is started or the
> interrupt is set inside the descriptor.
> Then stmmac_tx_clean will be always called and, if you see the flow,
> no irqlock protection is needed!

Agreed that no irqlock protection is needed if we rely on napi and timers.

> >>Concerning the lock protection, we had reviewed long time ago and
> >>IIRC, no raise condition should be present. Open to review it,
> >>again!
...
> >There's nothing that protect stmmac_poll() from running concurently
> >with stmmac_dma_interrupt(), right?
> 
> This is not necessary.

dma_interrupt accesses shared priv->xstats; variables are of type
unsigned long (not atomic_t), yet they are accesssed from interrupt
context and from stmmac_ethtool without any locking. That can result
in broken statistics AFAICT.

Please take another look. As far as I can tell, you can have two cpus
at #1 and #2 in the code, at the same time. It looks like napi_... has
some atomic opertions inside so that looks safe at the first look. But
I'm not sure if they also include enough memory barriers to make it
safe...?


static void stmmac_dma_interrupt(struct stmmac_priv *priv)
{
...
status = priv->hw->dma->dma_interrupt(priv->ioaddr, >xstats);
if (likely((status & handle_rx)) || (status & handle_tx)) {
if (likely(napi_schedule_prep(>napi))) {
#1
stmmac_disable_dma_irq(priv);
__napi_schedule(>napi);
}
}


static int stmmac_poll(struct napi_struct *napi, int budget)
{
struct stmmac_priv *priv = container_of(napi, struct stmmac_priv, napi);
int work_done = 0;

priv->xstats.napi_poll++;
stmmac_tx_clean(priv);

work_done = stmmac_rx(priv, budget);
if (work_done < budget) {
napi_complete(napi);
#2
stmmac_enable_dma_irq(priv);
}
return work_done;
}


Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

RE: [PATCH] perf/x86: fix event counter update issue

[Odzioba, Lukasz]

On Tuesday, November 29, 2016 9:33 PM, Liang, Kan wrote:
> Yes, the patch as below fixes the issue on my SLM.

It works for me as well. 
Can we still have it in 4.9?

Thanks,
Lukas

Re: [PATCH 3/3] pinctrl: sx150x: handle missing 'advanced' reg in sx1504 and sx1505

[Linus Walleij]

On Fri, Dec 2, 2016 at 11:51 AM, Peter Rosin  wrote:

> This fixes a problem where sx150x_regmap_reg_width() returns 8 for the
> data register (reg 0) for sx1504 where it should return 4, and return
> a correct 8 for sx1505 but for the wrong reason (both chips lack the
> 'advanced' register). This is not a real problem, since nothing depends
> on the function returning 4 or 8, and certainly not if it is returning
> 8 for the wrong reason. But fix this to avoid nasty surprises down the
> line.
>
> Signed-off-by: Peter Rosin 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v8] mtd: spi-nor: Add support for S3AN spi-nor devices

[Marek Vasut]

On 12/02/2016 11:52 AM, Ricardo Ribalda Delgado wrote:
> Hi Marek

Hi,

> On Thu, Dec 1, 2016 at 7:11 PM, Marek Vasut  wrote:
>> On 12/01/2016 06:52 PM, Ricardo Ribalda Delgado wrote:
>>> Hi Marek
>>
>> Hi,
>>
>>> Thanks for your review
>>>
>>> On Thu, Dec 1, 2016 at 5:05 PM, Marek Vasut  wrote:

 On 11/24/2016 05:56 PM, Ricardo Ribalda Delgado wrote:
>>>
> +#define  SPI_S3ANBIT(10) /*
> +  * Xilinx Spartan 3AN In-System 
> Flash
> +  * (MFR cannot be used for probing
> +  * because it has the same value as
> +  * ATMEL flashes)
> +  */

 I have possibly off-topic question. Altera has something very similar --
 EPCS/EPCQ flash which cannot be detected using standard READID .
 Would this patch help with supporting those degenerate flashes too?

>  };
>
>>>
>>> I dont know, but I love the term degenerated flash, please let me use it :)
>>
>> Hehe. It'd be great to know whether we don't have a possibility for a
>> generic usecase here. Can you briefly check that ?
> 
> I have taken a brief look to
> https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf
> 
> and they seem different enough to not reuse the flag :(.

OK, fine, thanks for checking.

>>> I guess they are using some bits reserved to ECC for data and that way
>>> you can squeeze some bits for user data.
>>
>> OK, comment could help clarify this, so please add one.
> 
> Will send a v9

Thanks!

-- 
Best regards,
Marek Vasut

Re: INFO: rcu_sched detected stalls on CPUs/tasks with `kswapd` and `mem_cgroup_shrink_node`

[Paul E. McKenney]

On Fri, Dec 02, 2016 at 10:37:35AM +0100, Michal Hocko wrote:
> On Thu 01-12-16 21:10:01, Boris Zhmurov wrote:
> > Michal Hocko 30/11/16 21:25:
> > 
> > >>> Do I get it right that s@cond_resched_rcu_qs@cond_resched@ didn't help?
> > >>
> > >> I didn't try that. I've tried 4 patches from Paul's linux-rcu tree.
> > >> I can try another portion of patches, no problem :)
> > > 
> > > Replacing cond_resched_rcu_qs in shrink_node_memcg by cond_resched would
> > > be really helpful to tell whether we are missing a real scheduling point
> > > or whether something more serious is going on here.
> > 
> > Well, I can confirm, that replacing cond_resched_rcu_qs in
> > shrink_node_memcg by cond_resched also makes dmesg clean from RCU CPU
> > stall warnings.
> > 
> > I've attached patch (just modification of Paul's patch), that fixes RCU
> > stall messages in situations, when all memory is used by
> > couchbase/memcached + fs cache and linux starts to use swap.
> 
> OK, thanks for the confirmation! I will send a patch because it is true
> that we do not have any scheduling point if no pages can be isolated
> fromm the LRU. This might be what you are seeing.

Thank you both!

Thanx, Paul

Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses.

[Giuseppe CAVALLARO]

On 12/2/2016 1:32 PM, Pavel Machek wrote:

Hi!


Well, if you have a workload that sends and receive packets, it tends
to work ok, as you do tx_clean() in stmmac_poll(). My workload is not
like that -- it is "sending packets at 3MB/sec, receiving none". So
the stmmac_tx_timer() is rescheduled and rescheduled and rescheduled,
and then we run out of transmit descriptors, and then 40msec passes,
and then we clean them. Bad.

And that's why low-res timers do not cut it.


in that case, I expect that the tuning of the driver could help you.
I mean, by using ethtool, it could be enough to set the IC bit on all
the descriptors. You should touch the tx_coal_frames.

Then you can use ethtool -S to monitor the status.


Yes, I did something similar. Unfortnunately that meant crash within
minutes, at least with 4.4 kernel. (If you know what was fixed between
4.4 and 4.9, that would be helpful).


4.4 has no GMAC4 support.
Alex, do you remember any patches to fix that?


We had experimented this tuning on STB IP where just datagrams
had to send externally. To be honest, although we had seen
better results w/o any timer, we kept this approach enabled
because the timer was fast enough to cover our tests on SH4 boxes.


Please reply to David, and explain how it is supposed to
work... because right now it does not. 40 msec delays are not
acceptable in default configuration.


I mean, that on UP and SMP system this schema helped
to improve the performance saving CPU on my side and this has been
tested since a long time (~4 years).
I tested something similar to yours where unidirectional traffic
with limited throughput was needed and I can confirm you that
tuning/removing coalesce parameters this helped. The tuning I decided
to keep in the driver was suitable in several user cases and if now
you have problems or you want to review it I can just confirm that
there are no problems on my side. If you want to simply the logic
around the tx process and remove timer on official driver I can accept
that. I will just ask you uto double check if the throughput and
CPU usage when request max throughput (better if on GiGa setup) has
no regressions.
Otherwise we could start thinking about adaptive schema if feasible.


In the ring, some descriptors can raise the irq (according to a
threshold) and set the IC bit. In this path, the NAPI  poll will be
scheduled.


Not NAPI poll but stmmac_tx_timer(), right?


in the xmit according the the threshold the timer is started or the
interrupt is set inside the descriptor.
Then stmmac_tx_clean will be always called and, if you see the flow,
no irqlock protection is needed!


Agreed that no irqlock protection is needed if we rely on napi and timers.


ok




Concerning the lock protection, we had reviewed long time ago and
IIRC, no raise condition should be present. Open to review it,
again!

...

There's nothing that protect stmmac_poll() from running concurently
with stmmac_dma_interrupt(), right?


This is not necessary.


dma_interrupt accesses shared priv->xstats; variables are of type
unsigned long (not atomic_t), yet they are accesssed from interrupt
context and from stmmac_ethtool without any locking. That can result
in broken statistics AFAICT.


ok we can check this and welcome patches and I'd prefer to
remove xstats from critical part of the code like ISR (that
comes from old story of the driver).



Please take another look. As far as I can tell, you can have two cpus
at #1 and #2 in the code, at the same time. It looks like napi_... has
some atomic opertions inside so that looks safe at the first look. But
I'm not sure if they also include enough memory barriers to make it
safe...?


Although I have never reproduced related issues on SMP platforms
due to reordering of memory operations but, as said above, welcome
review on this especially if you are seeing problems when manage NAPI.

FYI, the only memory barrier you will see in the driver are about the
OWN_BIT setting till now.


static void stmmac_dma_interrupt(struct stmmac_priv *priv)
{
...
status = priv->hw->dma->dma_interrupt(priv->ioaddr, >xstats);
if (likely((status & handle_rx)) || (status & handle_tx)) {
if (likely(napi_schedule_prep(>napi))) {
#1
stmmac_disable_dma_irq(priv);
__napi_schedule(>napi);
}
}


static int stmmac_poll(struct napi_struct *napi, int budget)
{
struct stmmac_priv *priv = container_of(napi, struct stmmac_priv, napi);
int work_done = 0;

priv->xstats.napi_poll++;
stmmac_tx_clean(priv);

work_done = stmmac_rx(priv, budget);
if (work_done < budget) {
napi_complete(napi);
#2
stmmac_enable_dma_irq(priv);
}


hmm, I have to check (and refresh my memory) but the driver
uses the napi_schedule_prep.

Regards

Peppe


return work_done;
}


Best regards,
   

[PATCH 3/8] rtc: add STM32 RTC driver

[Amelie Delaunay]

This patch adds support for the STM32 RTC.

Signed-off-by: Amelie Delaunay 
---
 drivers/rtc/Kconfig |  10 +
 drivers/rtc/Makefile|   1 +
 drivers/rtc/rtc-stm32.c | 777 
 3 files changed, 788 insertions(+)
 create mode 100644 drivers/rtc/rtc-stm32.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e859d14..dd8b218 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1706,6 +1706,16 @@ config RTC_DRV_PIC32
   This driver can also be built as a module. If so, the module
   will be called rtc-pic32
 
+config RTC_DRV_STM32
+   tristate "STM32 On-Chip RTC"
+   depends on ARCH_STM32
+   help
+  If you say yes here you get support for the STM32 On-Chip
+  Real Time Clock.
+
+  This driver can also be built as a module, if so, the module
+  will be called "rtc-stm32".
+
 comment "HID Sensor RTC drivers"
 
 config RTC_DRV_HID_SENSOR_TIME
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 1ac694a..87bd9cc 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -144,6 +144,7 @@ obj-$(CONFIG_RTC_DRV_SNVS)  += rtc-snvs.o
 obj-$(CONFIG_RTC_DRV_SPEAR)+= rtc-spear.o
 obj-$(CONFIG_RTC_DRV_STARFIRE) += rtc-starfire.o
 obj-$(CONFIG_RTC_DRV_STK17TA8) += rtc-stk17ta8.o
+obj-$(CONFIG_RTC_DRV_STM32)+= rtc-stm32.o
 obj-$(CONFIG_RTC_DRV_STMP) += rtc-stmp3xxx.o
 obj-$(CONFIG_RTC_DRV_ST_LPC)   += rtc-st-lpc.o
 obj-$(CONFIG_RTC_DRV_SUN4V)+= rtc-sun4v.o
diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
new file mode 100644
index 000..9e710ff
--- /dev/null
+++ b/drivers/rtc/rtc-stm32.c
@@ -0,0 +1,777 @@
+/*
+ * Copyright (C) Amelie Delaunay 2015
+ * Author:  Amelie Delaunay 
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "stm32_rtc"
+
+/* STM32 RTC registers */
+#define STM32_RTC_TR   0x00
+#define STM32_RTC_DR   0x04
+#define STM32_RTC_CR   0x08
+#define STM32_RTC_ISR  0x0C
+#define STM32_RTC_PRER 0x10
+#define STM32_RTC_ALRMAR   0x1C
+#define STM32_RTC_WPR  0x24
+
+/* STM32_RTC_TR bit fields  */
+#define STM32_RTC_TR_SEC_SHIFT 0
+#define STM32_RTC_TR_SEC   GENMASK(6, 0)
+#define STM32_RTC_TR_MIN_SHIFT 8
+#define STM32_RTC_TR_MIN   GENMASK(14, 8)
+#define STM32_RTC_TR_HOUR_SHIFT16
+#define STM32_RTC_TR_HOUR  GENMASK(21, 16)
+
+/* STM32_RTC_DR bit fields */
+#define STM32_RTC_DR_DATE_SHIFT0
+#define STM32_RTC_DR_DATE  GENMASK(5, 0)
+#define STM32_RTC_DR_MONTH_SHIFT   8
+#define STM32_RTC_DR_MONTH GENMASK(11, 8)
+#define STM32_RTC_DR_WDAY_SHIFT13
+#define STM32_RTC_DR_WDAY  GENMASK(15, 13)
+#define STM32_RTC_DR_YEAR_SHIFT16
+#define STM32_RTC_DR_YEAR  GENMASK(23, 16)
+
+/* STM32_RTC_CR bit fields */
+#define STM32_RTC_CR_FMT   BIT(6)
+#define STM32_RTC_CR_ALRAE BIT(8)
+#define STM32_RTC_CR_ALRAIEBIT(12)
+
+/* STM32_RTC_ISR bit fields */
+#define STM32_RTC_ISR_ALRAWF   BIT(0)
+#define STM32_RTC_ISR_INITSBIT(4)
+#define STM32_RTC_ISR_RSF  BIT(5)
+#define STM32_RTC_ISR_INITFBIT(6)
+#define STM32_RTC_ISR_INIT BIT(7)
+#define STM32_RTC_ISR_ALRAFBIT(8)
+
+/* STM32_RTC_PRER bit fields */
+#define STM32_RTC_PRER_PRED_S_SHIFT0
+#define STM32_RTC_PRER_PRED_S  GENMASK(14, 0)
+#define STM32_RTC_PRER_PRED_A_SHIFT16
+#define STM32_RTC_PRER_PRED_A  GENMASK(22, 16)
+
+/* STM32_RTC_ALRMAR and STM32_RTC_ALRMBR bit fields */
+#define STM32_RTC_ALRMXR_SEC_SHIFT 0
+#define STM32_RTC_ALRMXR_SEC   GENMASK(6, 0)
+#define STM32_RTC_ALRMXR_SEC_MASK  BIT(7)
+#define STM32_RTC_ALRMXR_MIN_SHIFT 8
+#define STM32_RTC_ALRMXR_MIN   GENMASK(14, 8)
+#define STM32_RTC_ALRMXR_MIN_MASK  BIT(15)
+#define STM32_RTC_ALRMXR_HOUR_SHIFT16
+#define STM32_RTC_ALRMXR_HOUR  GENMASK(21, 16)
+#define STM32_RTC_ALRMXR_PMBIT(22)
+#define STM32_RTC_ALRMXR_HOUR_MASK BIT(23)
+#define STM32_RTC_ALRMXR_DATE_SHIFT24
+#define STM32_RTC_ALRMXR_DATE  GENMASK(29, 24)
+#define STM32_RTC_ALRMXR_WDSEL BIT(30)
+#define STM32_RTC_ALRMXR_WDAY_SHIFT24
+#define STM32_RTC_ALRMXR_WDAY  GENMASK(27, 24)
+#define STM32_RTC_ALRMXR_DATE_MASK BIT(31)
+
+/* STM32_RTC_WPR key constants */
+#define RTC_WPR_1ST_KEY0xCA
+#define RTC_WPR_2ND_KEY0x53
+#define RTC_WPR_WRONG_KEY  0xFF
+
+/*
+ * RTC registers are protected agains parasitic write access.
+ * PWR_CR_DBP bit must be 

[PATCH 0/8] Add support for STM32 RTC

[Amelie Delaunay]

This patchset adds support for the STM32 Real-Time Clock.
This RTC is an independent BCD timer/counter and provides a time-of-day
clock/calendar with programmable alarm interrupt.
RTC calendar can be driven by three clock sources LSE, LSI or HSE.

Amelie Delaunay (8):
  ARM: dts: stm32: set HSE_RTC clock frequency to 1 MHz on stm32f429
  dt-bindings: document the STM32 RTC bindings
  rtc: add STM32 RTC driver
  ARM: dts: stm32: Add STM32 RTC support for STM32F429 MCU
  ARM: dts: stm32: enable RTC on stm32f429-disco
  ARM: dts: stm32: enable RTC on stm32f469-disco
  ARM: dts: stm32: enable RTC on stm32429i-eval
  ARM: configs: stm32: Add STM32 RTC support in STM32 defconfig

 .../devicetree/bindings/rtc/st,stm32-rtc.txt   |  31 +
 arch/arm/boot/dts/stm32429i-eval.dts   |   4 +
 arch/arm/boot/dts/stm32f429-disco.dts  |   6 +
 arch/arm/boot/dts/stm32f429.dtsi   |  16 +
 arch/arm/boot/dts/stm32f469-disco.dts  |   4 +
 arch/arm/configs/stm32_defconfig   |   2 +
 drivers/rtc/Kconfig|  10 +
 drivers/rtc/Makefile   |   1 +
 drivers/rtc/rtc-stm32.c| 777 +
 9 files changed, 851 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
 create mode 100644 drivers/rtc/rtc-stm32.c

-- 
1.9.1

[PATCH 2/8] dt-bindings: document the STM32 RTC bindings

[Amelie Delaunay]

This patch adds documentation of device tree bindings for the STM32 RTC.

Signed-off-by: Amelie Delaunay 
---
 .../devicetree/bindings/rtc/st,stm32-rtc.txt   | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt

diff --git a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt 
b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
new file mode 100644
index 000..4578838
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
@@ -0,0 +1,31 @@
+STM32 Real Time Clock
+
+Required properties:
+- compatible: "st,stm32-rtc".
+- reg: address range of rtc register set.
+- clocks: reference to the clock entry ck_rtc.
+- clock-names: name of the clock used. Should be "ck_rtc".
+- interrupt-parent: phandle for the interrupt controller.
+- interrupts: rtc alarm interrupt.
+- interrupt-names: rtc alarm interrupt name, should be "alarm".
+- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain
+  (RTC registers) write protection.
+
+Optional properties (to override default ck_rtc parent clock):
+- assigned-clocks: reference to the ck_rtc clock entry.
+- assigned-clock-parents: phandle of the new parent clock of ck_rtc.
+
+Example:
+
+   rtc: rtc@40002800 {
+   compatible = "st,stm32-rtc";
+   reg = <0x40002800 0x400>;
+   clocks = < 1 CLK_RTC>;
+   clock-names = "ck_rtc";
+   assigned-clocks = < 1 CLK_RTC>;
+   assigned-clock-parents = < 1 CLK_LSE>;
+   interrupt-parent = <>;
+   interrupts = <17 1>;
+   interrupt-names = "alarm";
+   st,syscfg = <>;
+   };
-- 
1.9.1

[PATCH 4/6] net: stmmac: dwmac1000: fix define DMA_BUS_MODE_RPBL_MASK

[Niklas Cassel]

From: Niklas Cassel 

DMA_BUS_MODE_RPBL_MASK is really 6 bits,
just like DMA_BUS_MODE_PBL_MASK.

Signed-off-by: Niklas Cassel 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
index ff3e5ab39bd0..52b9407a8a39 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
@@ -225,7 +225,7 @@ enum rx_tx_priority_ratio {
 
 #define DMA_BUS_MODE_FB0x0001  /* Fixed burst */
 #define DMA_BUS_MODE_MB0x0400  /* Mixed burst */
-#define DMA_BUS_MODE_RPBL_MASK 0x003e  /* Rx-Programmable Burst Len */
+#define DMA_BUS_MODE_RPBL_MASK 0x007e  /* Rx-Programmable Burst Len */
 #define DMA_BUS_MODE_RPBL_SHIFT17
 #define DMA_BUS_MODE_USP   0x0080
 #define DMA_BUS_MODE_MAXPBL0x0100
-- 
2.1.4

[PATCH 2/6] net: stmmac: simplify the common DMA init API

[Niklas Cassel]

From: Niklas Cassel 

Use struct stmmac_dma_cfg *dma_cfg as an argument rather
than using all the struct members as individual arguments.

Signed-off-by: Niklas Cassel 
---
 drivers/net/ethernet/stmicro/stmmac/common.h|  4 ++--
 drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c | 13 +++--
 drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c  |  7 ---
 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c| 14 --
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c   |  6 +-
 5 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 6d2de4e01f6d..3023ec7ae83e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -411,8 +411,8 @@ extern const struct stmmac_desc_ops ndesc_ops;
 struct stmmac_dma_ops {
/* DMA core initialization */
int (*reset)(void __iomem *ioaddr);
-   void (*init)(void __iomem *ioaddr, int pbl, int fb, int mb,
-int aal, u32 dma_tx, u32 dma_rx, int atds);
+   void (*init)(void __iomem *ioaddr, struct stmmac_dma_cfg *dma_cfg,
+u32 dma_tx, u32 dma_rx, int atds);
/* Configure the AXI Bus Mode Register */
void (*axi)(void __iomem *ioaddr, struct stmmac_axi *axi);
/* Dump DMA registers */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index 990746955216..01d0d0f315e5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -82,8 +82,9 @@ static void dwmac1000_dma_axi(void __iomem *ioaddr, struct 
stmmac_axi *axi)
writel(value, ioaddr + DMA_AXI_BUS_MODE);
 }
 
-static void dwmac1000_dma_init(void __iomem *ioaddr, int pbl, int fb, int mb,
-  int aal, u32 dma_tx, u32 dma_rx, int atds)
+static void dwmac1000_dma_init(void __iomem *ioaddr,
+  struct stmmac_dma_cfg *dma_cfg,
+  u32 dma_tx, u32 dma_rx, int atds)
 {
u32 value = readl(ioaddr + DMA_BUS_MODE);
 
@@ -99,20 +100,20 @@ static void dwmac1000_dma_init(void __iomem *ioaddr, int 
pbl, int fb, int mb,
 */
value |= DMA_BUS_MODE_MAXPBL;
value &= ~DMA_BUS_MODE_PBL_MASK;
-   value |= (pbl << DMA_BUS_MODE_PBL_SHIFT);
+   value |= (dma_cfg->pbl << DMA_BUS_MODE_PBL_SHIFT);
 
/* Set the Fixed burst mode */
-   if (fb)
+   if (dma_cfg->fixed_burst)
value |= DMA_BUS_MODE_FB;
 
/* Mixed Burst has no effect when fb is set */
-   if (mb)
+   if (dma_cfg->mixed_burst)
value |= DMA_BUS_MODE_MB;
 
if (atds)
value |= DMA_BUS_MODE_ATDS;
 
-   if (aal)
+   if (dma_cfg->aal)
value |= DMA_BUS_MODE_AAL;
 
writel(value, ioaddr + DMA_BUS_MODE);
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
index 61f54c99a7de..e5664da382f3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
@@ -32,11 +32,12 @@
 #include "dwmac100.h"
 #include "dwmac_dma.h"
 
-static void dwmac100_dma_init(void __iomem *ioaddr, int pbl, int fb, int mb,
- int aal, u32 dma_tx, u32 dma_rx, int atds)
+static void dwmac100_dma_init(void __iomem *ioaddr,
+ struct stmmac_dma_cfg *dma_cfg,
+ u32 dma_tx, u32 dma_rx, int atds)
 {
/* Enable Application Access by writing to DMA CSR0 */
-   writel(DMA_BUS_MODE_DEFAULT | (pbl << DMA_BUS_MODE_PBL_SHIFT),
+   writel(DMA_BUS_MODE_DEFAULT | (dma_cfg->pbl << DMA_BUS_MODE_PBL_SHIFT),
   ioaddr + DMA_BUS_MODE);
 
/* Mask interrupts by writing to CSR7 */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 577316de6ba8..0946546d6dcd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -97,27 +97,29 @@ static void dwmac4_dma_init_channel(void __iomem *ioaddr, 
int pbl,
writel(dma_rx_phy, ioaddr + DMA_CHAN_RX_BASE_ADDR(channel));
 }
 
-static void dwmac4_dma_init(void __iomem *ioaddr, int pbl, int fb, int mb,
-   int aal, u32 dma_tx, u32 dma_rx, int atds)
+static void dwmac4_dma_init(void __iomem *ioaddr,
+   struct stmmac_dma_cfg *dma_cfg,
+   u32 dma_tx, u32 dma_rx, int atds)
 {
u32 value = readl(ioaddr + DMA_SYS_BUS_MODE);
int i;
 
/* Set the Fixed burst mode */
-   if (fb)
+   if (dma_cfg->fixed_burst)
value |= DMA_SYS_BUS_FB;
 
/* Mixed 

RE: [RFC] ARC: mm: Restrict definition of pfn_valid() macro for CONFIG_FLATMEM

[Yuriy Kolerov]

> -Original Message-
> From: Vineet Gupta [mailto:vgu...@synopsys.com]
> Sent: Wednesday, November 30, 2016 7:55 PM
> To: Yuriy Kolerov ; Michal Hocko
> 
> Cc: linux-snps-...@lists.infradead.org; alexey.brod...@synopsys.com; linux-
> ker...@vger.kernel.org
> Subject: Re: [RFC] ARC: mm: Restrict definition of pfn_valid() macro for
> CONFIG_FLATMEM
> 
> On 11/30/2016 06:21 AM, Yuriy Kolerov wrote:
> >> On Tue 29-11-16 18:29:06, Yuriy Kolerov wrote:
> >>> > > Despite the fact that subtraction of unsigned integers is a
> >>> > > defined behaviour however such operations can lead to unexpected
> >>> > > results. Thus it is better to check both left and right
> >>> > > boundaries to avoid potential bugs as it done in the generic page.h.
> >> >
> >> > Why and which code would use an out of range pfn? Why other arches
> >> > do not need to care?
> > Actually some arches do care about checking of both left and right
> boundaries (e.g. avr32, sparc, etc). The problem is that a value of pfn may be
> calculated incorrectly in some places of the kernel. E.g. not long ago I sent 
> a
> patch which fixes truncation of the most significant byte in pfn/pte in some
> cases (in the kernel with PAE40, however it is not a FLATMEM case). So such
> situations can happens in the most unexpected places.
> >
> 
> So the point is - is this a preventive fix (desired thing) or it being there 
> would
> have helped find the PAE40 bug earlier / easier. Woudl it have prevented the
> kernel crash. If so then this is a nobrainer fix.

This fix can help to find bugs which are related to wrong pfn values and only 
for FLATMEM case (usually when PAE40 is turned off). However I have just 
figured out that it is impossible to pass such bad unsigned pfn value which 
passes pfn_valid() check (usually the kernel passes a value from unsigned long 
variable)... This fix may help in cases when the kernel accidently passes a 
signed long value as pfn to the macro. Frankly speaking there are low chances 
that such thing can ever happen so I'm a little paranoid about it.

> BTW did you try to gauge the code gen impact - this function gets pulled all
> over the place in mm code. So build kernel with and w/o change and do a
> scripts/bloat-o-meter

Report from that script (extra 112 bytes):

add/remove: 0/0 grow/shrink: 9/1 up/down: 122/-10 (112)
function old new   delta
set_zone_contiguous  212 248 +36
__pageblock_pfn_to_page  120 136 +16
vm_insert_pfn_prot   432 444 +12
vm_insert_pfn436 448 +12
kpagecount_read  360 372 +12
reserve_bootmem_region   110 120 +10
memremap 248 256  +8
kpageflags_read  840 848  +8
devm_memremap356 364  +8
pagetypeinfo_show752 742 -10
Total: Before=3785631, After=3785743, chg +0.00%

> -Vineet

[PATCH 5/8] ARM: dts: stm32: enable RTC on stm32f429-disco

[Amelie Delaunay]

This patch enables RTC on stm32f429-disco with LSI as clock source because
X2 crystal for LSE is not fitted by default.

Signed-off-by: Amelie Delaunay 
---
 arch/arm/boot/dts/stm32f429-disco.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429-disco.dts 
b/arch/arm/boot/dts/stm32f429-disco.dts
index b6e63d8..49eddf6 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -94,6 +94,12 @@
clock-frequency = <800>;
 };
 
+ {
+   assigned-clocks = < 1 CLK_RTC>;
+   assigned-clock-parents = < 1 CLK_LSI>;
+   status = "okay";
+};
+
  {
pinctrl-0 = <_pins_a>;
pinctrl-names = "default";
-- 
1.9.1

[PATCH 4/8] ARM: dts: stm32: Add STM32 RTC support for STM32F429 MCU

[Amelie Delaunay]

This patch adds STM32 RTC bindings for STM32F429.

Signed-off-by: Amelie Delaunay 
---
 arch/arm/boot/dts/stm32f429.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index d195ccf..d181025 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -125,6 +125,20 @@
status = "disabled";
};
 
+   rtc: rtc@40002800 {
+   compatible = "st,stm32-rtc";
+   reg = <0x40002800 0x400>;
+   clocks = < 1 CLK_RTC>;
+   clock-names = "ck_rtc";
+   assigned-clocks = < 1 CLK_RTC>;
+   assigned-clock-parents = < 1 CLK_LSE>;
+   interrupt-parent = <>;
+   interrupts = <17 1>;
+   interrupt-names = "alarm";
+   st,syscfg = <>;
+   status = "disabled";
+   };
+
usart2: serial@40004400 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004400 0x400>;
-- 
1.9.1

[PATCH 6/8] ARM: dts: stm32: enable RTC on stm32f469-disco

[Amelie Delaunay]

This patch enables RTC on stm32f469-disco with default LSE clock source.

Signed-off-by: Amelie Delaunay 
---
 arch/arm/boot/dts/stm32f469-disco.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f469-disco.dts 
b/arch/arm/boot/dts/stm32f469-disco.dts
index 8a163d7..af57dd5 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -78,6 +78,10 @@
clock-frequency = <800>;
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
1.9.1

[PATCH 5/6] net: stmmac: add support for independent DMA pbl for tx/rx

[Niklas Cassel]

From: Niklas Cassel 

GMAC and newer supports independent programmable burst lengths for
DMA tx/rx. Add new optional devicetree properties representing this.

To be backwards compatible, snps,pbl will still be valid, but
snps,txpbl/snps,rxpbl will override the value in snps,pbl if set.

If the IP is synthesized to use the AXI interface, there is a register
and a matching DT property inside the optional stmmac-axi-config DT node
for controlling burst lengths, named snps,blen.
However, using this register, it is not possible to control tx and rx
independently. Also, this register is not available if the IP was
synthesized with, e.g., the AHB interface.

Signed-off-by: Niklas Cassel 
---
 Documentation/devicetree/bindings/net/stmmac.txt  |  6 +-
 Documentation/networking/stmmac.txt   | 19 +--
 drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c   | 12 ++--
 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c  | 12 +++-
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c |  2 ++
 include/linux/stmmac.h|  2 ++
 6 files changed, 35 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index b95ff998ba73..8080038ff1b2 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -34,7 +34,11 @@ Optional properties:
   platforms.
 - tx-fifo-depth: See ethernet.txt file in the same directory
 - rx-fifo-depth: See ethernet.txt file in the same directory
-- snps,pbl Programmable Burst Length
+- snps,pbl Programmable Burst Length (tx and rx)
+- snps,txpbl   Tx Programmable Burst Length. Only for GMAC and newer.
+   If set, DMA tx will use this value rather than snps,pbl.
+- snps,rxpbl   Rx Programmable Burst Length. Only for GMAC and newer.
+   If set, DMA rx will use this value rather than snps,pbl.
 - snps,aal Address-Aligned Beats
 - snps,fixed-burst Program the DMA to use the fixed burst mode
 - snps,mixed-burst Program the DMA to use the mixed burst mode
diff --git a/Documentation/networking/stmmac.txt 
b/Documentation/networking/stmmac.txt
index e226f8925c9e..82c8e496b4bb 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -154,7 +154,8 @@ Where:
o pbl: the Programmable Burst Length is maximum number of beats to
be transferred in one DMA transaction.
GMAC also enables the 4xPBL by default.
-   o fixed_burst/mixed_burst/burst_len
+   o txpbl/rxpbl: GMAC and newer supports independent DMA pbl for tx/rx.
+   o fixed_burst/mixed_burst/aal
  o clk_csr: fixed CSR Clock range selection.
  o has_gmac: uses the GMAC core.
  o enh_desc: if sets the MAC will use the enhanced descriptor structure.
@@ -206,16 +207,22 @@ tuned according to the HW capabilities.
 
 struct stmmac_dma_cfg {
int pbl;
+   int txpbl;
+   int rxpbl;
int fixed_burst;
-   int burst_len_supported;
+   int mixed_burst;
+   bool aal;
 };
 
 Where:
- o pbl: Programmable Burst Length
+ o pbl: Programmable Burst Length (tx and rx)
+ o txpbl: Transmit Programmable Burst Length. Only for GMAC and newer.
+If set, DMA tx will use this value rather than pbl.
+ o rxpbl: Receive Programmable Burst Length. Only for GMAC and newer.
+If set, DMA rx will use this value rather than pbl.
  o fixed_burst: program the DMA to use the fixed burst mode
- o burst_len: this is the value we put in the register
- supported values are provided as macros in
- linux/stmmac.h header file.
+ o mixed_burst: program the DMA to use the mixed burst mode
+ o aal: Address-Aligned Beats
 
 ---
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index 01d0d0f315e5..1dd34fb4c1a9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -87,20 +87,20 @@ static void dwmac1000_dma_init(void __iomem *ioaddr,
   u32 dma_tx, u32 dma_rx, int atds)
 {
u32 value = readl(ioaddr + DMA_BUS_MODE);
+   int txpbl = dma_cfg->txpbl ?: dma_cfg->pbl;
+   int rxpbl = dma_cfg->rxpbl ?: dma_cfg->pbl;
 
/*
 * Set the DMA PBL (Programmable Burst Length) mode.
 *
 * Note: before stmmac core 3.50 this mode bit was 4xPBL, and
 * post 3.5 mode bit acts as 8*PBL.
-*
-* This configuration doesn't take care about the Separate PBL
-* so only the bits: 13-8 are programmed with the PBL passed from the
-* platform.
 */
value |= DMA_BUS_MODE_MAXPBL;
-   value &= ~DMA_BUS_MODE_PBL_MASK;
-   value |= (dma_cfg->pbl << 

[PATCH 6/6] net: smmac: allow configuring lower pbl values

[Niklas Cassel]

From: Niklas Cassel 

The driver currently always sets the PBLx8/PBLx4 bit, which means that
the pbl values configured via the pbl/txpbl/rxpbl DT properties are
always multiplied by 8/4 in the hardware.

In order to allow the DT to configure lower pbl values, while at the
same time not changing behavior of any existing device trees using the
pbl/txpbl/rxpbl settings, add a property to disable the multiplication
of the pbl by 8/4 in the hardware.

Suggested-by: Rabin Vincent 
Signed-off-by: Niklas Cassel 
---
 Documentation/devicetree/bindings/net/stmmac.txt  | 2 ++
 Documentation/networking/stmmac.txt   | 5 -
 drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c   | 3 ++-
 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c  | 3 ++-
 drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c  | 2 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 +
 include/linux/stmmac.h| 1 +
 7 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index 8080038ff1b2..128da752fec9 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -39,6 +39,8 @@ Optional properties:
If set, DMA tx will use this value rather than snps,pbl.
 - snps,rxpbl   Rx Programmable Burst Length. Only for GMAC and newer.
If set, DMA rx will use this value rather than snps,pbl.
+- snps,no-pbl-x8   Don't multiply the pbl/txpbl/rxpbl values by 8.
+   For core rev < 3.50, don't multiply the values by 4.
 - snps,aal Address-Aligned Beats
 - snps,fixed-burst Program the DMA to use the fixed burst mode
 - snps,mixed-burst Program the DMA to use the mixed burst mode
diff --git a/Documentation/networking/stmmac.txt 
b/Documentation/networking/stmmac.txt
index 82c8e496b4bb..d3376c5fbcf0 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -153,8 +153,9 @@ Where:
  o dma_cfg: internal DMA parameters
o pbl: the Programmable Burst Length is maximum number of beats to
be transferred in one DMA transaction.
-   GMAC also enables the 4xPBL by default.
+   GMAC also enables the 4xPBL by default. (8xPBL for GMAC 3.50 and newer)
o txpbl/rxpbl: GMAC and newer supports independent DMA pbl for tx/rx.
+   o pblx8: Enable 8xPBL (4xPBL for core rev < 3.50). Enabled by default.
o fixed_burst/mixed_burst/aal
  o clk_csr: fixed CSR Clock range selection.
  o has_gmac: uses the GMAC core.
@@ -209,6 +210,7 @@ struct stmmac_dma_cfg {
int pbl;
int txpbl;
int rxpbl;
+   bool pblx8;
int fixed_burst;
int mixed_burst;
bool aal;
@@ -220,6 +222,7 @@ Where:
 If set, DMA tx will use this value rather than pbl.
  o rxpbl: Receive Programmable Burst Length. Only for GMAC and newer.
 If set, DMA rx will use this value rather than pbl.
+ o pblx8: Enable 8xPBL (4xPBL for core rev < 3.50). Enabled by default.
  o fixed_burst: program the DMA to use the fixed burst mode
  o mixed_burst: program the DMA to use the mixed burst mode
  o aal: Address-Aligned Beats
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index 1dd34fb4c1a9..1d313af647b4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -96,7 +96,8 @@ static void dwmac1000_dma_init(void __iomem *ioaddr,
 * Note: before stmmac core 3.50 this mode bit was 4xPBL, and
 * post 3.5 mode bit acts as 8*PBL.
 */
-   value |= DMA_BUS_MODE_MAXPBL;
+   if (dma_cfg->pblx8)
+   value |= DMA_BUS_MODE_MAXPBL;
value |= DMA_BUS_MODE_USP;
value &= ~(DMA_BUS_MODE_PBL_MASK | DMA_BUS_MODE_RPBL_MASK);
value |= (txpbl << DMA_BUS_MODE_PBL_SHIFT);
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 0bf47825bfeb..0f7110d19a4a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -82,7 +82,8 @@ static void dwmac4_dma_init_channel(void __iomem *ioaddr,
 * on each channel
 */
value = readl(ioaddr + DMA_CHAN_CONTROL(channel));
-   value = value | DMA_BUS_MODE_PBL;
+   if (dma_cfg->pblx8)
+   value = value | DMA_BUS_MODE_PBL;
writel(value, ioaddr + DMA_CHAN_CONTROL(channel));
 
value = readl(ioaddr + DMA_CHAN_TX_CONTROL(channel));
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 56c8a2342c14..a2831773431a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ 

[PATCH 8/8] ARM: configs: stm32: Add STM32 RTC support in STM32 defconfig

[Amelie Delaunay]

This patch adds STM32 RTC support in stm32_defconfig file.

Signed-off-by: Amelie Delaunay 
---
 arch/arm/configs/stm32_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index e7b56d4..71f9787 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -59,6 +59,8 @@ CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_GPIO=y
 CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_STM32=y
 CONFIG_DMADEVICES=y
 CONFIG_STM32_DMA=y
 # CONFIG_FILE_LOCKING is not set
-- 
1.9.1

[PATCH 1/8] ARM: dts: stm32: set HSE_RTC clock frequency to 1 MHz on stm32f429

[Amelie Delaunay]

This patch set HSE_RTC clock frequency to 1 MHz, as the clock supplied to
the RTC must be 1 MHz.

Signed-off-by: Amelie Delaunay 
---
 arch/arm/boot/dts/stm32f429.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index b077f99..d195ccf 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -371,6 +371,8 @@
reg = <0x40023800 0x400>;
clocks = <_hse>, <_i2s_ckin>;
st,syscfg = <>;
+   assigned-clocks = < 1 CLK_HSE_RTC>;
+   assigned-clock-rates = <100>;
};
 
dma1: dma-controller@40026000 {
-- 
1.9.1

[PATCH 7/8] ARM: dts: stm32: enable RTC on stm32429i-eval

[Amelie Delaunay]

This patch enables RTC on stm32429i-eval with default LSE clock source.

Signed-off-by: Amelie Delaunay 
---
 arch/arm/boot/dts/stm32429i-eval.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 8b158f9..5007da9 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -134,6 +134,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-0 = <_pins_a>;
pinctrl-names = "default";
-- 
1.9.1

[PATCH 1/3] pinctrl: sx150x: access the correct bits in the 4-bit regs of sx150[147]

[Peter Rosin]

The code assumes 8-bit or 16-bit width registers, but three of the
chips (sx1501/sx1504/sx1507) are 4-bit. So, try to handle 4-bit chips as
well, they leave the high part of each register unused.

Signed-off-by: Peter Rosin 
---
 drivers/pinctrl/pinctrl-sx150x.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index 1a1c8b51a992..a121819ffc92 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -5,6 +5,7 @@
  * Copyright (c) 2010, Code Aurora Forum. All rights reserved.
  *
  * Driver for Semtech SX150X I2C GPIO Expanders
+ * The handling of the 4-bit chips (SX1501/SX1504/SX1507) is untested.
  *
  * Author: Gregory Bean 
  *
@@ -1088,7 +1089,7 @@ static int sx150x_regmap_reg_write(void *context, 
unsigned int reg,
 
val = sx150x_maybe_swizzle(pctl, reg, val);
 
-   n = width - 8;
+   n = (width - 1) & ~7;
do {
const u8 byte = (val >> n) & 0xff;
 
-- 
2.1.4

Re: [PATCH] trace: extend trace_clock to support arch_arm clock counter

[Will Deacon]

On Fri, Dec 02, 2016 at 01:44:55PM +0530, Srinivas Ramana wrote:
> Extend the trace_clock to support the arch timer cycle
> counter so that we can get the monotonic cycle count
> in the traces. This will help in correlating the traces with the
> timestamps/events in other subsystems in the soc which share
> this common counter for driving their timers.

I'm not sure I follow this reasoning. What's wrong with nanoseconds? In
particular, the "perf" trace_clock hangs off sched_clock, which should
be backed by the architected counter anyway. What does the cycle counter in
isolation tell you, given that the frequency isn't architected?

I think I'm missing something here.

Will

Re: [PATCH v2] intelrdt: resctrl: recommend locking for resctrlfs

[Thomas Gleixner]

On Thu, 1 Dec 2016, Marcelo Tosatti wrote:
> 
> There is a locking problem between different applications
> reading/writing to resctrlfs directory at the same time (read the patch
> below for details).
> 
> Suggest a standard locking scheme for applications to use.



> +To coordinate atomic operations on resctrl and avoid the problem
> +above, the following locking procedure is recommended:
> +
> +A) open /var/lock/resctrl/fs.lock with O_CREAT|O_EXCL.
> +B) if success, write pid of program accessing the directory
> +   structure to this file.
> +C) read/write the directory structure.
> +D) remove file.

What's wrong with using flock, which works from shell scripts as well?

Thanks,

tglx

[PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v6

[Mel Gorman]

SLUB has been the default small kernel object allocator for quite some time
but it is not universally used due to performance concerns and a reliance
on high-order pages. The high-order concerns has two major components --
high-order pages are not always available and high-order page allocations
potentially contend on the zone->lock. This patch addresses some concerns
about the zone lock contention by extending the per-cpu page allocator to
cache high-order pages. The patch makes the following modifications

o New per-cpu lists are added to cache the high-order pages. This increases
  the cache footprint of the per-cpu allocator and overall usage but for
  some workloads, this will be offset by reduced contention on zone->lock.
  The first MIGRATE_PCPTYPE entries in the list are per-migratetype. The
  remaining are high-order caches up to and including
  PAGE_ALLOC_COSTLY_ORDER

o pcp accounting during free is now confined to free_pcppages_bulk as it's
  impossible for the caller to know exactly how many pages were freed.
  Due to the high-order caches, the number of pages drained for a request
  is no longer precise.

o The high watermark for per-cpu pages is increased to reduce the probability
  that a single refill causes a drain on the next free.

The benefit depends on both the workload and the machine as ultimately the
determining factor is whether cache line bounces on zone->lock or contention
is a problem. The patch was tested on a variety of workloads and machines,
some of which are reported here.

This is the result from netperf running UDP_STREAM on localhost. It was
selected on the basis that it is slab-intensive and has been the subject
of previous SLAB vs SLUB comparisons with the caveat that this is not
testing between two physical hosts.

2-socket modern machine
4.9.0-rc5 4.9.0-rc5
  vanilla hopcpu-v5
Hmeansend-64 178.38 (  0.00%)  260.54 ( 46.06%)
Hmeansend-128351.49 (  0.00%)  518.56 ( 47.53%)
Hmeansend-256671.23 (  0.00%) 1005.72 ( 49.83%)
Hmeansend-1024  2663.60 (  0.00%) 3880.54 ( 45.69%)
Hmeansend-2048  5126.53 (  0.00%) 7545.38 ( 47.18%)
Hmeansend-3312  7949.99 (  0.00%)11324.34 ( 42.44%)
Hmeansend-4096  9433.56 (  0.00%)12818.85 ( 35.89%)
Hmeansend-8192 15940.64 (  0.00%)21404.98 ( 34.28%)
Hmeansend-1638426699.54 (  0.00%)32810.08 ( 22.89%)
Hmeanrecv-64 178.38 (  0.00%)  260.52 ( 46.05%)
Hmeanrecv-128351.49 (  0.00%)  518.53 ( 47.53%)
Hmeanrecv-256671.20 (  0.00%) 1005.42 ( 49.79%)
Hmeanrecv-1024  2663.45 (  0.00%) 3879.75 ( 45.67%)
Hmeanrecv-2048  5126.26 (  0.00%) 7544.23 ( 47.17%)
Hmeanrecv-3312  7949.50 (  0.00%)11322.52 ( 42.43%)
Hmeanrecv-4096  9433.04 (  0.00%)12816.68 ( 35.87%)
Hmeanrecv-8192 15939.64 (  0.00%)21402.75 ( 34.27%)
Hmeanrecv-1638426698.44 (  0.00%)32806.81 ( 22.88%)

1-socket 6 year old machine
4.9.0-rc5 4.9.0-rc5
  vanilla hopcpu-v4
Hmeansend-64  87.47 (  0.00%)  127.01 ( 45.21%)
Hmeansend-128174.36 (  0.00%)  254.86 ( 46.17%)
Hmeansend-256347.52 (  0.00%)  505.91 ( 45.58%)
Hmeansend-1024  1363.03 (  0.00%) 1962.49 ( 43.98%)
Hmeansend-2048  2632.68 (  0.00%) 3731.74 ( 41.75%)
Hmeansend-3312  4123.19 (  0.00%) 5859.08 ( 42.10%)
Hmeansend-4096  5056.48 (  0.00%) 7058.00 ( 39.58%)
Hmeansend-8192  8784.22 (  0.00%)12134.53 ( 38.14%)
Hmeansend-1638415081.60 (  0.00%)19638.90 ( 30.22%)
Hmeanrecv-64  86.19 (  0.00%)  126.34 ( 46.58%)
Hmeanrecv-128173.93 (  0.00%)  253.51 ( 45.75%)
Hmeanrecv-256346.19 (  0.00%)  503.34 ( 45.40%)
Hmeanrecv-1024  1358.28 (  0.00%) 1951.63 ( 43.68%)
Hmeanrecv-2048  2623.45 (  0.00%) 3701.67 ( 41.10%)
Hmeanrecv-3312  4108.63 (  0.00%) 5817.75 ( 41.60%)
Hmeanrecv-4096  5037.25 (  0.00%) 7004.79 ( 39.06%)
Hmeanrecv-8192  8762.32 (  0.00%)12059.83 ( 37.63%)
Hmeanrecv-1638415042.36 (  0.00%)19514.33 ( 29.73%)

This is somewhat dramatic but it's also not universal. For example, it was
observed on an older HP machine using pcc-cpufreq that there was almost
no difference but pcc-cpufreq is also a known performance hazard.

These are quite different results but illustrate that the patch is
dependent on the CPU. The results are similar for TCP_STREAM on
the two-socket machine.

The observations on sockperf are different.

2-socket modern machine
sockperf-tcp-throughput
 4.9.0-rc5 4.9.0-rc5
   vanilla hopcpu-v5
Hmean14

[PATCH 1/2] MAINTAINERS: convert first part to ReST markup

[Mauro Carvalho Chehab]

- Fix document section markups;
- Use tables;
- Use monotonic font for field names;
- adjust spaces and blank lines.

Signed-off-by: Mauro Carvalho Chehab 
---
 MAINTAINERS | 213 ++--
 1 file changed, 136 insertions(+), 77 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e13497c79fe4..1cb31237a2c0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1,12 +1,14 @@
-
-
-   List of maintainers and how to submit kernel changes
+List of maintainers and how to submit kernel changes
+
 
 Please try to follow the guidelines below.  This will make things
 easier on the maintainers.  Not all of these guidelines matter for every
 trivial patch so apply some common sense.
 
-1. Always _test_ your changes, however small, on at least 4 or
+Tips for patch submitters
+-
+
+1. Always **test** your changes, however small, on at least 4 or
5 people, preferably many more.
 
 2. Try to release a few ALPHA test versions to the net. Announce
@@ -15,7 +17,7 @@ trivial patch so apply some common sense.
you will find things like the fact version 3 firmware needs
a magic fix you didn't know about, or some clown changed the
chips on a board and not its name.  (Don't laugh!  Look at the
-   SMC etherpower for that.)
+   SMC ``etherpower`` for that.)
 
 3. Make sure your changes compile correctly in multiple
configurations. In particular check that changes work both as a
@@ -25,7 +27,7 @@ trivial patch so apply some common sense.
testing and await feedback.
 
 5. Make a patch available to the relevant maintainer in the list. Use
-   'diff -u' to make the patch easy to merge. Be prepared to get your
+   ``diff -u`` to make the patch easy to merge. Be prepared to get your
changes sent back with seemingly silly requests about formatting
and variable names.  These aren't as silly as they seem. One
job the maintainers (and especially Linus) do is to keep things
@@ -33,28 +35,34 @@ trivial patch so apply some common sense.
your driver to get around a problem actually needs to become a
generalized kernel feature ready for next time.
 
-   PLEASE check your patch with the automated style checker
-   (scripts/checkpatch.pl) to catch trivial style violations.
-   See Documentation/process/coding-style.rst for guidance here.
+   .. attention::
 
-   PLEASE CC: the maintainers and mailing lists that are generated
-   by scripts/get_maintainer.pl.  The results returned by the
-   script will be best if you have git installed and are making
-   your changes in a branch derived from Linus' latest git tree.
-   See Documentation/process/submitting-patches.rst for details.
+ **PLEASE:**
 
-   PLEASE try to include any credit lines you want added with the
-   patch. It avoids people being missed off by mistake and makes
-   it easier to know who wants adding and who doesn't.
+ - check your patch with the automated style checker
+   (``scripts/checkpatch.pl``) to catch trivial style violations.
+   See :ref:`Documentation/process/coding-style.rst `
+   for guidance here.
 
-   PLEASE document known bugs. If it doesn't work for everything
-   or does something very odd once a month document it.
+ - CC: the maintainers and mailing lists that are generated
+   by ``scripts/get_maintainer.pl``.  The results returned by the
+   script will be best if you have git installed and are making
+   your changes in a branch derived from Linus' latest git tree.
+   See :ref:`Documentation/process/submitting-patches.rst 
`
+   for details.
 
-   PLEASE remember that submissions must be made under the terms
-   of the Linux Foundation certificate of contribution and should
-   include a Signed-off-by: line.  The current version of this
-   "Developer's Certificate of Origin" (DCO) is listed in the file
-   Documentation/process/submitting-patches.rst.
+ - try to include any credit lines you want added with the
+   patch. It avoids people being missed off by mistake and makes
+   it easier to know who wants adding and who doesn't.
+
+ - document known bugs. If it doesn't work for everything
+   or does something very odd once a month document it.
+
+ - remember that submissions must be made under the terms
+   of the Linux Foundation certificate of contribution and should
+   include a Signed-off-by: line.  The current version of this
+   "Developer's Certificate of Origin" (DCO) is listed in the file
+   :ref:`Documentation/process/submitting-patches.rst 
`.
 
 6. Make sure you have the right to send any changes you make. If you
do 

[PATCH 2/2] MAINTAINERS: add it to the admin-guide

[Mauro Carvalho Chehab]

The MAINTAINER's file has different things inside it:
- Tips for patch submitters;
- Descriptions for the MAINTAINER file entries;
- the MAINTAINERS database.

As its contents is useful for someone reporting a bug or
by a newbie submitting a patch, let's add it to the documentation,
keeping just the database at the MAINTAINERS file, and a note
pointing to where the documentation was moved.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/admin-guide/index.rst   |   1 +
 Documentation/admin-guide/maintainers.rst | 184 ++
 MAINTAINERS   | 182 +
 3 files changed, 186 insertions(+), 181 deletions(-)
 create mode 100644 Documentation/admin-guide/maintainers.rst

diff --git a/Documentation/admin-guide/index.rst 
b/Documentation/admin-guide/index.rst
index 2681cbd24cdd..a2a72b749861 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -28,6 +28,7 @@ problems and bugs in particular.
bug-hunting
bug-bisect
tainted-kernels
+   maintainers
ramoops
dynamic-debug-howto
init
diff --git a/Documentation/admin-guide/maintainers.rst 
b/Documentation/admin-guide/maintainers.rst
new file mode 100644
index ..68daef3df3cf
--- /dev/null
+++ b/Documentation/admin-guide/maintainers.rst
@@ -0,0 +1,184 @@
+List of maintainers and how to submit kernel changes
+
+
+Please try to follow the guidelines below.  This will make things
+easier on the maintainers.  Not all of these guidelines matter for every
+trivial patch so apply some common sense.
+
+Tips for patch submitters
+-
+
+1. Always **test** your changes, however small, on at least 4 or
+   5 people, preferably many more.
+
+2. Try to release a few ALPHA test versions to the net. Announce
+   them onto the kernel channel and await results. This is especially
+   important for device drivers, because often that's the only way
+   you will find things like the fact version 3 firmware needs
+   a magic fix you didn't know about, or some clown changed the
+   chips on a board and not its name.  (Don't laugh!  Look at the
+   SMC ``etherpower`` for that.)
+
+3. Make sure your changes compile correctly in multiple
+   configurations. In particular check that changes work both as a
+   module and built into the kernel.
+
+4. When you are happy with a change make it generally available for
+   testing and await feedback.
+
+5. Make a patch available to the relevant maintainer in the list. Use
+   ``diff -u`` to make the patch easy to merge. Be prepared to get your
+   changes sent back with seemingly silly requests about formatting
+   and variable names.  These aren't as silly as they seem. One
+   job the maintainers (and especially Linus) do is to keep things
+   looking the same. Sometimes this means that the clever hack in
+   your driver to get around a problem actually needs to become a
+   generalized kernel feature ready for next time.
+
+   .. attention::
+
+ **PLEASE:**
+
+ - check your patch with the automated style checker
+   (``scripts/checkpatch.pl``) to catch trivial style violations.
+   See :ref:`Documentation/process/coding-style.rst `
+   for guidance here.
+
+ - CC: the maintainers and mailing lists that are generated
+   by ``scripts/get_maintainer.pl``.  The results returned by the
+   script will be best if you have git installed and are making
+   your changes in a branch derived from Linus' latest git tree.
+   See :ref:`Documentation/process/submitting-patches.rst 
`
+   for details.
+
+ - try to include any credit lines you want added with the
+   patch. It avoids people being missed off by mistake and makes
+   it easier to know who wants adding and who doesn't.
+
+ - document known bugs. If it doesn't work for everything
+   or does something very odd once a month document it.
+
+ - remember that submissions must be made under the terms
+   of the Linux Foundation certificate of contribution and should
+   include a Signed-off-by: line.  The current version of this
+   "Developer's Certificate of Origin" (DCO) is listed in the file
+   :ref:`Documentation/process/submitting-patches.rst 
`.
+
+6. Make sure you have the right to send any changes you make. If you
+   do changes at work you may find your employer owns the patch
+   not you.
+
+7. When sending security related changes or reports to a maintainer
+   please Cc: secur...@kernel.org, especially if the maintainer
+   does not respond.
+
+8. Happy hacking.
+
+Descriptions of section entries
+---

[PATCH 0/2] Add maintainers to the admin guide

[Mauro Carvalho Chehab]

That's my third attempt to add the MAINTAINERS contents to the admin-guide.

On the past approaches, was planning to keep the documentation
about what's at the MAINTAINERS file inside it, but that would
require running an external script or use some Sphinx extension.

This time, I took a much simpler approach: convert the initial
part of the MAINTAINERS file to ReST and move to a file at the
admin-guide. So, MAINTAINERS file will now contain only the
maintainer's database, and a single line pointing to its documentation.

That should hopefully be a good compromise, as we can add its
contents to a Sphinx file without causing too much hasle.


Mauro Carvalho Chehab (2):
  MAINTAINERS: convert first part to ReST markup
  MAINTAINERS: add it to the admin-guide

 Documentation/admin-guide/index.rst   |   1 +
 Documentation/admin-guide/maintainers.rst | 184 ++
 MAINTAINERS   | 125 +---
 3 files changed, 187 insertions(+), 123 deletions(-)
 create mode 100644 Documentation/admin-guide/maintainers.rst

-- 
2.9.3

Re: [PATCH v4] Fixes for compiling with clang

[Michal Marek]

On 2016-12-01 19:13, Peter Foley wrote:
> On Tue, Nov 29, 2016 at 6:22 AM, Michal Marek  wrote:
>> Dne 28.11.2016 v 07:44 Peter Foley napsal(a):
>> This adds new -Wno-* options also for the gcc case, is there a reason
>> for this? Also, the -Wno-missing-field-initializers option is not
>> available in some old gccs, so we would need a HOSTCC equivalent of
>> cc-disable-warning.
>>
>> Michal
> 
> It appeared that the conditional was simply reversed, as
> -fno-delete-null-pointer-checks is only supported by gcc, and
> explicitly not supported by clang.
> (see 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Makefile?id=61163efae02040f66a95c8ed17f4407951ba58fa)
> It could be that the fno-delete-null-pointer-checks option was simply
> misplaced, and the Wno-options should still be guarded by if(clang),
> would that be a better approach?

I think so. The -Wno-* options had not been present before clang support
was added. It really looks like the -fno-delete-null-pointer-checks
should not be there. Added Behan to CC.

Michal

Re: [PATCH 2/3] pinctrl: sx150x: rename 'reg_advance' to 'reg_advanced'

[Linus Walleij]

On Fri, Dec 2, 2016 at 11:51 AM, Peter Rosin  wrote:

> This matches the datasheets and is less confusing since the register
> has nothing to with advancing anything.
>
> Signed-off-by: Peter Rosin 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 1/1] usb: xhci: fix possible wild pointer

[Mathias Nyman]

On 02.12.2016 04:29, Lu Baolu wrote:

handle_cmd_completion() frees a command structure which might
be still referenced by xhci->current_cmd. This might cause
problem when xhci->current_cmd is accessed after that.

A real-life case could be like this. The host takes a very long
time to respond to a command, and the command timer is fired at
the same time when the command completion event arrives. The
command completion handler frees xhci->current_cmd before the
timer function can grab xhci->lock. Afterward, timer function
grabs the lock and go ahead with checking and setting members
of xhci->current_cmd.

Cc:  # v3.16+
Signed-off-by: Lu Baolu 
---
  drivers/usb/host/xhci-ring.c | 16 +++-
  1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index bdf6b13..13e05f6 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1267,14 +1267,16 @@ void xhci_handle_command_timeout(unsigned long data)
bool second_timeout = false;
xhci = (struct xhci_hcd *) data;

-   /* mark this command to be cancelled */
spin_lock_irqsave(>lock, flags);
-   if (xhci->current_cmd) {
-   if (xhci->current_cmd->status == COMP_CMD_ABORT)
-   second_timeout = true;
-   xhci->current_cmd->status = COMP_CMD_ABORT;
+   if (!xhci->current_cmd) {
+   spin_unlock_irqrestore(>lock, flags);
+   return;
}

+   if (xhci->current_cmd->status == COMP_CMD_ABORT)
+   second_timeout = true;
+   xhci->current_cmd->status = COMP_CMD_ABORT;
+
/* Make sure command ring is running before aborting it */
hw_ring_state = xhci_read_64(xhci, >op_regs->cmd_ring);
if ((xhci->cmd_ring_state & CMD_RING_STATE_RUNNING) &&
@@ -1422,6 +1424,10 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
xhci->current_cmd = list_entry(cmd->cmd_list.next,
   struct xhci_command, cmd_list);
mod_timer(>cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
+   } else if (xhci->current_cmd == cmd) {
+   xhci->current_cmd = NULL;
+   } else {
+   xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
}

  event_handled:



Thanks,

I might do some tweaking to (or remove)  the warn message when applying if
that is ok

-Mathias

[PATCH 2/5] MIPS: Stack unwinding while on IRQ stack

[Matt Redfearn]

Within unwind stack, check if the stack pointer being unwound is within
the CPU's irq_stack and if so use that page rather than the task's stack
page.

Signed-off-by: Matt Redfearn 
---

 arch/mips/kernel/process.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
index 9514e5f2209f..4fdbf7078071 100644
--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -511,7 +512,19 @@ EXPORT_SYMBOL(unwind_stack_by_address);
 unsigned long unwind_stack(struct task_struct *task, unsigned long *sp,
   unsigned long pc, unsigned long *ra)
 {
-   unsigned long stack_page = (unsigned long)task_stack_page(task);
+   unsigned long stack_page = 0;
+   int cpu;
+
+   for_each_possible_cpu(cpu) {
+   if (on_irq_stack(cpu, *sp)) {
+   stack_page = (unsigned long)irq_stack[cpu];
+   break;
+   }
+   }
+
+   if (!stack_page)
+   stack_page = (unsigned long)task_stack_page(task);
+
return unwind_stack_by_address(stack_page, sp, pc, ra);
 }
 #endif
-- 
2.7.4

[PATCH 5/5] MIPS: Select HAVE_IRQ_EXIT_ON_IRQ_STACK

[Matt Redfearn]

Since do_IRQ is now invoked on a separate IRQ stack, we select
HAVE_IRQ_EXIT_ON_IRQ_STACK so that softirq's may be invoked directly
from irq_exit(), rather than requiring do_softirq_own_stack.

Signed-off-by: Matt Redfearn 
---

 arch/mips/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index b3c5bde43d34..80832aa8e4fb 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -9,6 +9,7 @@ config MIPS
select HAVE_CONTEXT_TRACKING
select HAVE_GENERIC_DMA_COHERENT
select HAVE_IDE
+   select HAVE_IRQ_EXIT_ON_IRQ_STACK
select HAVE_OPROFILE
select HAVE_PERF_EVENTS
select PERF_USE_VMALLOC
-- 
2.7.4

[PATCH 4/5] MIPS: Switch to the irq_stack in interrupts

[Matt Redfearn]

When enterring interrupt context via handle_int or except_vec_vi, switch
to the irq_stack of the current CPU if it is not already in use.

The current stack pointer is masked with the thread size and compared to
the base or the irq stack. If it does not match then the stack pointer
is set to the top of that stack, otherwise this is a nested irq being
handled on the irq stack so the stack pointer should be left as it was.

The in-use stack pointer is placed in the callee saved register s1. It
will be saved to the stack when plat_irq_dispatch is invoked and can be
restored once control returns here.

Signed-off-by: Matt Redfearn 
---

 arch/mips/kernel/genex.S | 81 +---
 1 file changed, 76 insertions(+), 5 deletions(-)

diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S
index dc0b29612891..0a7ba4b2f687 100644
--- a/arch/mips/kernel/genex.S
+++ b/arch/mips/kernel/genex.S
@@ -187,9 +187,44 @@ NESTED(handle_int, PT_SIZE, sp)
 
LONG_L  s0, TI_REGS($28)
LONG_S  sp, TI_REGS($28)
-   PTR_LA  ra, ret_from_irq
-   PTR_LA  v0, plat_irq_dispatch
-   jr  v0
+
+   /*
+* SAVE_ALL ensures we are using a valid kernel stack for the thread.
+* Check if we are already using the IRQ stack.
+*/
+   moves1, sp # Preserve the sp
+
+   /* Get IRQ stack for this CPU */
+   ASM_CPUID_MFC0  k0, ASM_SMP_CPUID_REG
+#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
+   lui k1, %hi(irq_stack)
+#else
+   lui k1, %highest(irq_stack)
+   daddiu  k1, %higher(irq_stack)
+   dsllk1, 16
+   daddiu  k1, %hi(irq_stack)
+   dsllk1, 16
+#endif
+   LONG_SRLk0, SMP_CPUID_PTRSHIFT
+   LONG_ADDU   k1, k0
+   LONG_L  t0, %lo(irq_stack)(k1)
+
+   # Check if already on IRQ stack
+   PTR_LI  t1, ~(_THREAD_SIZE-1)
+   and t1, t1, sp
+   beq t0, t1, 2f
+
+   /* Switch to IRQ stack */
+   li  t1, _IRQ_STACK_SIZE
+   PTR_ADD sp, t0, t1
+
+2:
+   jal plat_irq_dispatch
+
+   /* Restore sp */
+   movesp, s1
+
+   j   ret_from_irq
 #ifdef CONFIG_CPU_MICROMIPS
nop
 #endif
@@ -262,8 +297,44 @@ NESTED(except_vec_vi_handler, 0, sp)
 
LONG_L  s0, TI_REGS($28)
LONG_S  sp, TI_REGS($28)
-   PTR_LA  ra, ret_from_irq
-   jr  v0
+
+   /*
+* SAVE_ALL ensures we are using a valid kernel stack for the thread.
+* Check if we are already using the IRQ stack.
+*/
+   moves1, sp # Preserve the sp
+
+   /* Get IRQ stack for this CPU */
+   ASM_CPUID_MFC0  k0, ASM_SMP_CPUID_REG
+#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
+   lui k1, %hi(irq_stack)
+#else
+   lui k1, %highest(irq_stack)
+   daddiu  k1, %higher(irq_stack)
+   dsllk1, 16
+   daddiu  k1, %hi(irq_stack)
+   dsllk1, 16
+#endif
+   LONG_SRLk0, SMP_CPUID_PTRSHIFT
+   LONG_ADDU   k1, k0
+   LONG_L  t0, %lo(irq_stack)(k1)
+
+   # Check if already on IRQ stack
+   PTR_LI  t1, ~(_THREAD_SIZE-1)
+   and t1, t1, sp
+   beq t0, t1, 2f
+
+   /* Switch to IRQ stack */
+   li  t1, _IRQ_STACK_SIZE
+   PTR_ADD sp, t0, t1
+
+2:
+   jal plat_irq_dispatch
+
+   /* Restore sp */
+   movesp, s1
+
+   j   ret_from_irq
END(except_vec_vi_handler)
 
 /*
-- 
2.7.4

Re: [PATCH] scsi: hisi_sas: fix free'ing in probe and remove

[Quentin Lambert]

On 11/29/2016 04:45 PM, John Garry wrote:

From: Xiaofei Tan 

This patch addresses 4 problems in the module probe/remove:
- When hisi_sas_shost_alloc() fails after we alloc shost memory,
we should free shost memory before the function returns.
- When hisi_sas_probe() fails after we alloc the HBA memories,
we should also free the HBA memories.
- We should free shost memory at the end of hisi_sas_remove().
- sha->core.shost is set twice, so remove extra set.

Signed-off-by: Xiaofei Tan 
Signed-off-by: John Garry 

Reviewed-by: Quentin Lambert 


diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 6d6f150..d50e9cf 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -1412,8 +1412,10 @@ static struct Scsi_Host *hisi_sas_shost_alloc(struct 
platform_device *pdev,
struct clk *refclk;
  
  	shost = scsi_host_alloc(_sas_sht, sizeof(*hisi_hba));

-   if (!shost)
-   goto err_out;
+   if (!shost) {
+   dev_err(dev, "scsi host alloc failed\n");
+   return NULL;
+   }
hisi_hba = shost_priv(shost);
  
  	hisi_hba->hw = hw;

@@ -1477,6 +1479,7 @@ static struct Scsi_Host *hisi_sas_shost_alloc(struct 
platform_device *pdev,
  
  	return shost;

  err_out:
+   kfree(shost);
dev_err(dev, "shost alloc failed\n");
return NULL;
  }
@@ -1503,10 +1506,8 @@ int hisi_sas_probe(struct platform_device *pdev,
int rc, phy_nr, port_nr, i;
  
  	shost = hisi_sas_shost_alloc(pdev, hw);

-   if (!shost) {
-   rc = -ENOMEM;
-   goto err_out_ha;
-   }
+   if (!shost)
+   return -ENOMEM;
  
  	sha = SHOST_TO_SAS_HA(shost);

hisi_hba = shost_priv(shost);
@@ -1516,12 +1517,13 @@ int hisi_sas_probe(struct platform_device *pdev,
  
  	arr_phy = devm_kcalloc(dev, phy_nr, sizeof(void *), GFP_KERNEL);

arr_port = devm_kcalloc(dev, port_nr, sizeof(void *), GFP_KERNEL);
-   if (!arr_phy || !arr_port)
-   return -ENOMEM;
+   if (!arr_phy || !arr_port) {
+   rc = -ENOMEM;
+   goto err_out_ha;
+   }
  
  	sha->sas_phy = arr_phy;

sha->sas_port = arr_port;
-   sha->core.shost = shost;
sha->lldd_ha = hisi_hba;
  
  	shost->transportt = hisi_sas_stt;

@@ -1566,6 +1568,7 @@ int hisi_sas_probe(struct platform_device *pdev,
  err_out_register_ha:
scsi_remove_host(shost);
  err_out_ha:
+   hisi_sas_free(hisi_hba);
kfree(shost);
return rc;
  }
@@ -1575,12 +1578,14 @@ int hisi_sas_remove(struct platform_device *pdev)
  {
struct sas_ha_struct *sha = platform_get_drvdata(pdev);
struct hisi_hba *hisi_hba = sha->lldd_ha;
+   struct Scsi_Host *shost = sha->core.shost;
  
  	scsi_remove_host(sha->core.shost);

sas_unregister_ha(sha);
sas_remove_host(sha->core.shost);
  
  	hisi_sas_free(hisi_hba);

+   kfree(shost);
return 0;
  }
  EXPORT_SYMBOL_GPL(hisi_sas_remove);

Re: [PATCH] HID: intel_ish-hid: use %pUL for uuid formatting

[Jiri Kosina]

On Wed, 30 Nov 2016, Rasmus Villemoes wrote:

> We have the %pU printf extension for doing exactly this. Saves some
> .text, and is likely also a little faster.
> 
> Signed-off-by: Rasmus Villemoes 

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs

Aw: Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses.

[Lino Sanfilippo]

Hi,


> 
> There's nothing that protect stmmac_poll() from running concurently
> with stmmac_dma_interrupt(), right?
> 

could it be that there is also another issue concerned locking?:
The tx completion handler takes the xmit_lock in case that the
netif_queue is stopped. This is AFAICS unnecessary, since both
xmit and completion handler are already synchronized by the private
tx lock. But it is IMHO also dangerous:

In the xmit handler we have the locking order
1. xmit_lock
2. private tx lock

while in the completion handler its the reverse:

1. private tx lock
2. xmit lock.

Do I miss something?


Regards,
Lino

Re: [PATCH] stmmac: reduce code duplication getting basic descriptors

[Alexandre Torgue]

Hi Pavel,

On 11/28/2016 01:17 PM, Pavel Machek wrote:


Remove code duplication getting basic descriptors.


I agree with your patch, it will make code easier to understand.
After fix kbuild issue you can add my Acked-by;

Regards
Alex



Signed-off-by: Pavel Machek 

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f7133d0..ed20668 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -929,6 +929,17 @@ static int stmmac_set_bfsize(int mtu, int bufsize)
return ret;
 }

+static inline struct dma_desc *stmmac_tx_desc(struct stmmac_priv *priv, int i)
+{
+   struct dma_desc *p;
+   if (priv->extend_desc)
+   p = &((priv->dma_etx + i)->basic);
+   else
+   p = priv->dma_tx + i;
+   return p;
+}
+
+
 /**
  * stmmac_clear_descriptors - clear descriptors
  * @priv: driver private structure
@@ -1078,11 +1089,7 @@ static int init_dma_desc_rings(struct net_device *dev, 
gfp_t flags)

/* TX INITIALIZATION */
for (i = 0; i < DMA_TX_SIZE; i++) {
-   struct dma_desc *p;
-   if (priv->extend_desc)
-   p = &((priv->dma_etx + i)->basic);
-   else
-   p = priv->dma_tx + i;
+   struct dma_desc *p = stmmac_tx_desc(priv, i);

if (priv->synopsys_id >= DWMAC_CORE_4_00) {
p->des0 = 0;
@@ -1129,12 +1136,7 @@ static void dma_free_tx_skbufs(struct stmmac_priv *priv)
int i;

for (i = 0; i < DMA_TX_SIZE; i++) {
-   struct dma_desc *p;
-
-   if (priv->extend_desc)
-   p = &((priv->dma_etx + i)->basic);
-   else
-   p = priv->dma_tx + i;
+   struct dma_desc *p = stmmac_tx_desc(priv, i);

if (priv->tx_skbuff_dma[i].buf) {
if (priv->tx_skbuff_dma[i].map_as_page)
@@ -1314,14 +1316,9 @@ static void __stmmac_tx_clean(struct stmmac_priv *priv)

while (entry != priv->cur_tx) {
struct sk_buff *skb = priv->tx_skbuff[entry];
-   struct dma_desc *p;
+   struct dma_desc *p = stmmac_tx_desc(priv, entry);
int status;

-   if (priv->extend_desc)
-   p = (struct dma_desc *)(priv->dma_etx + entry);
-   else
-   p = priv->dma_tx + entry;
-
status = priv->hw->desc->tx_status(>dev->stats,
  >xstats, p,
  priv->ioaddr);
@@ -2227,11 +2224,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, 
struct net_device *dev)

csum_insertion = (skb->ip_summed == CHECKSUM_PARTIAL);

-   if (likely(priv->extend_desc))
-   desc = (struct dma_desc *)(priv->dma_etx + entry);
-   else
-   desc = priv->dma_tx + entry;
-
+   desc = stmmac_tx_desc(priv, entry);
first = desc;

priv->tx_skbuff[first_entry] = skb;
@@ -2254,10 +2247,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, 
struct net_device *dev)

entry = STMMAC_GET_ENTRY(entry, DMA_TX_SIZE);

-   if (likely(priv->extend_desc))
-   desc = (struct dma_desc *)(priv->dma_etx + entry);
-   else
-   desc = priv->dma_tx + entry;
+   desc = stmmac_tx_desc(priv, entry);

des = skb_frag_dma_map(priv->device, frag, 0, len,
   DMA_TO_DEVICE);

[PATCH 1/3] ARM: dts: STiH410-b2260: Identify the UART RTS line

[Lee Jones]

Configure the UART RTS line as a GPIO for manipulation within the UART driver.

Signed-off-by: Lee Jones 
---
 arch/arm/boot/dts/stih410-b2260.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/stih410-b2260.dts 
b/arch/arm/boot/dts/stih410-b2260.dts
index 7fb507f..f46603f 100644
--- a/arch/arm/boot/dts/stih410-b2260.dts
+++ b/arch/arm/boot/dts/stih410-b2260.dts
@@ -63,6 +63,7 @@
uart0: serial@983 {
label = "LS-UART0";
status = "okay";
+   rts-gpios = < 3 GPIO_ACTIVE_LOW>;
};
 
/* Low speed expansion connector */
-- 
2.10.2

[PATCH 11/11] megaraid_sas: driver version upgrade

[Sasikumar Chandrasekaran]

Upgrade driver version.

This patch is depending on patch 10

Signed-off-by: Sasikumar Chandrasekaran 
---
 drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index e4bb93d..bc5e042 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -35,8 +35,8 @@
 /*
  * MegaRAID SAS Driver meta data
  */
-#define MEGASAS_VERSION"06.812.07.00-rc1"
-#define MEGASAS_RELDATE"August 22, 2016"
+#define MEGASAS_VERSION"07.700.00.00-rc1"
+#define MEGASAS_RELDATE"November 29, 2016"
 
 /*
  * Device IDs
-- 
1.8.3.1

[PATCH 2/3] serial: st-asc: Provide RTS functionality

[Lee Jones]

Until this point, it has not been possible for serial applications
to toggle the UART RTS line.  This can be useful with certain
configurations. For example, when using a Mezzanine on a Linaro
96board, RTS line is used to take the the on-board microcontroller
in and out of reset.

Signed-off-by: Lee Jones 
---
 drivers/tty/serial/st-asc.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index 379e5bd..ce46898 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DRIVER_NAME "st-asc"
 #define ASC_SERIAL_NAME "ttyAS"
@@ -38,6 +39,7 @@
 
 struct asc_port {
struct uart_port port;
+   struct gpio_desc *rts;
struct clk *clk;
unsigned int hw_flow_control:1;
unsigned int force_m1:1;
@@ -381,12 +383,16 @@ static unsigned int asc_tx_empty(struct uart_port *port)
 
 static void asc_set_mctrl(struct uart_port *port, unsigned int mctrl)
 {
+   struct asc_port *ascport = to_asc_port(port);
+
/*
 * This routine is used for seting signals of: DTR, DCD, CTS/RTS
 * We use ASC's hardware for CTS/RTS, so don't need any for that.
 * Some boards have DTR and DCD implemented using PIO pins,
 * code to do this should be hooked in here.
 */
+
+   gpiod_set_value(ascport->rts, mctrl & TIOCM_RTS);
 }
 
 static unsigned int asc_get_mctrl(struct uart_port *port)
@@ -731,12 +737,20 @@ MODULE_DEVICE_TABLE(of, asc_match);
 static int asc_serial_probe(struct platform_device *pdev)
 {
int ret;
+   struct device_node *np = pdev->dev.of_node;
struct asc_port *ascport;
+   struct gpio_desc *gpiod;
 
ascport = asc_of_get_asc_port(pdev);
if (!ascport)
return -ENODEV;
 
+   gpiod = devm_get_gpiod_from_child(>dev, "rts", >fwnode);
+   if (!IS_ERR(gpiod)) {
+   gpiod_direction_output(gpiod, 0);
+   ascport->rts = gpiod;
+   }
+
ret = asc_init_port(ascport, pdev);
if (ret)
return ret;
-- 
2.10.2

Re: [PATCH] mmc: sdhci-of-at91: remove bogus MMC_SDHCI_IO_ACCESSORS select

[Adrian Hunter]

On 01/12/16 06:05, Masahiro Yamada wrote:
> I see no override of read/write callbacks in sdhci-of-at91.c.
> 
> Signed-off-by: Masahiro Yamada 

Acked-by: Adrian Hunter 

> ---
> 
> BTW, this config may not be so useful in recent multi-platforms.
> Perhaps, is it better to remove this config entirely instead of
> the AT91 fix only.
> 
> 
>  drivers/mmc/host/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 39f6f96..8ac1640 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -135,7 +135,6 @@ config MMC_SDHCI_OF_AT91
>   tristate "SDHCI OF support for the Atmel SDMMC controller"
>   depends on MMC_SDHCI_PLTFM
>   depends on OF
> - select MMC_SDHCI_IO_ACCESSORS
>   help
> This selects the Atmel SDMMC driver
>  
> 

[PATCH 09/11] megaraid_sas: ldio_outstanding variable is not decremented in completion path

[Sasikumar Chandrasekaran]

ldio outstanding variable needs to be decremented in io completion path for
iMR dual queue depth

This patch is depending on patch 8

Signed-off-by: Sasikumar Chandrasekaran 
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 3aab189..e8016bc 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2558,8 +2558,6 @@ void megasas_prepare_secondRaid1_IO(struct 
megasas_instance *instance,
 
if (atomic_inc_return(>fw_outstanding) >
instance->host->can_queue) {
-   dev_err(>pdev->dev, "Throttle IOs beyond"
-   "Controller queue depth\n");
atomic_dec(>fw_outstanding);
return SCSI_MLQUEUE_HOST_BUSY;
}
@@ -2786,6 +2784,8 @@ void megasas_prepare_secondRaid1_IO(struct 
megasas_instance *instance,
extStatus, data_length, sense);
scsi_io_req->RaidContext.raid_context.status = 
0;
scsi_io_req->RaidContext.raid_context.exStatus 
= 0;
+   if (instance->ldio_threshold && 
megasas_cmd_type(scmd_local) == READ_WRITE_LDIO)
+   atomic_dec(>ldio_outstanding);
megasas_return_cmd_fusion(instance, cmd_fusion);
scsi_dma_unmap(scmd_local);
scmd_local->scsi_done(scmd_local);
@@ -3931,7 +3931,7 @@ int megasas_reset_fusion(struct Scsi_Host *shost, int 
reason)
scmd_local->result =
megasas_check_mpio_paths(instance,
scmd_local);
-   if (megasas_cmd_type(scmd_local) == 
READ_WRITE_LDIO)
+   if (instance->ldio_threshold && 
megasas_cmd_type(scmd_local) == READ_WRITE_LDIO)
atomic_dec(>ldio_outstanding);
megasas_return_cmd_fusion(instance, cmd_fusion);
scsi_dma_unmap(scmd_local);
-- 
1.8.3.1

Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted

[Vlastimil Babka]

On 12/02/2016 12:29 PM, Mel Gorman wrote:

Vlastimil Babka pointed out that commit 479f854a207c ("mm, page_alloc:
defer debugging checks of pages allocated from the PCP") will allow the
per-cpu list counter to be out of sync with the per-cpu list contents
if a struct page is corrupted.

The consequence is an infinite loop if the per-cpu lists get fully drained
by free_pcppages_bulk because all the lists are empty but the count is
positive. The infinite loop occurs here

do {
batch_free++;
if (++migratetype == MIGRATE_PCPTYPES)
migratetype = 0;
list = >lists[migratetype];
} while (list_empty(list));

From a user perspective, it's a bad page warning followed by a soft lockup
with interrupts disabled in free_pcppages_bulk().

This patch keeps the accounting in sync.

Fixes: 479f854a207c ("mm, page_alloc: defer debugging checks of pages allocated from 
the PCP")
Signed-off-by: Mel Gorman 
cc: sta...@vger.kernel.org [4.7+]


Acked-by: Vlastimil Babka 


---
 mm/page_alloc.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6de9440e3ae2..34ada718ef47 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2192,7 +2192,7 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
order,
unsigned long count, struct list_head *list,
int migratetype, bool cold)
 {
-   int i;
+   int i, alloced = 0;

spin_lock(>lock);
for (i = 0; i < count; ++i) {
@@ -2217,13 +2217,21 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
order,
else
list_add_tail(>lru, list);
list = >lru;
+   alloced++;
if (is_migrate_cma(get_pcppage_migratetype(page)))
__mod_zone_page_state(zone, NR_FREE_CMA_PAGES,
  -(1 << order));
}
+
+   /*
+* i pages were removed from the buddy list even if some leak due
+* to check_pcp_refill failing so adjust NR_FREE_PAGES based
+* on i. Do not confuse with 'alloced' which is the number of
+* pages added to the pcp list.
+*/
__mod_zone_page_state(zone, NR_FREE_PAGES, -(i << order));
spin_unlock(>lock);
-   return i;
+   return alloced;
 }

 #ifdef CONFIG_NUMA

net/can: warning in raw_setsockopt/__alloc_pages_slowpath

[Andrey Konovalov]

Hi!

I've got the following error report while running the syzkaller fuzzer.

A reproducer is attached.

On commit d8e435f3ab6fea2ea324dce72b51dd7761747523 (Nov 26).

[ cut here ]
WARNING: CPU: 0 PID: 4009 at mm/page_alloc.c:3511
__alloc_pages_slowpath+0x3d4/0x1bf0
Modules linked in:
CPU: 0 PID: 4009 Comm: a.out Not tainted 4.9.0-rc6+ #54
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 88006832f8a8 81c73b14  
 842c6320  88006832f8f0 8123dc57
 880067d86000 0db7 842c6320 0db7
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0xb3/0x10f lib/dump_stack.c:51
 [] __warn+0x1a7/0x1f0 kernel/panic.c:550
 [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
 [] __alloc_pages_slowpath+0x3d4/0x1bf0 mm/page_alloc.c:3511
 [] __alloc_pages_nodemask+0x5c2/0x710 mm/page_alloc.c:3781
 [] alloc_pages_current+0xf4/0x400 mm/mempolicy.c:2072
 [< inline >] alloc_pages ./include/linux/gfp.h:469
 [] kmalloc_order+0x1f/0x70 mm/slab_common.c:1015
 [] kmalloc_order_trace+0x1f/0x160 mm/slab_common.c:1026
 [< inline >] kmalloc_large ./include/linux/slab.h:422
 [] __kmalloc_track_caller+0x227/0x2a0 mm/slub.c:4233
 [] memdup_user+0x2c/0xa0 mm/util.c:137
 [] raw_setsockopt+0x1be/0x9f0 net/can/raw.c:506
 [< inline >] SYSC_setsockopt net/socket.c:1757
 [] SyS_setsockopt+0x154/0x240 net/socket.c:1736
 [] entry_SYSCALL_64_fastpath+0x1f/0xc2
arch/x86/entry/entry_64.S:209
---[ end trace bc80556cca970089 ]---
// autogenerated by syzkaller (http://github.com/google/syzkaller)

#ifndef __NR_setsockopt
#define __NR_setsockopt 54
#endif
#ifndef __NR_socket
#define __NR_socket 41
#endif

#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

const int kFailStatus = 67;
const int kErrorStatus = 68;
const int kRetryStatus = 69;

__attribute__((noreturn)) void fail(const char* msg, ...)
{
  int e = errno;
  fflush(stdout);
  va_list args;
  va_start(args, msg);
  vfprintf(stderr, msg, args);
  va_end(args);
  fprintf(stderr, " (errno %d)\n", e);
  exit(kFailStatus);
}

__attribute__((noreturn)) void exitf(const char* msg, ...)
{
  int e = errno;
  fflush(stdout);
  va_list args;
  va_start(args, msg);
  vfprintf(stderr, msg, args);
  va_end(args);
  fprintf(stderr, " (errno %d)\n", e);
  exit(kRetryStatus);
}

static int flag_debug;

void debug(const char* msg, ...)
{
  if (!flag_debug)
return;
  va_list args;
  va_start(args, msg);
  vfprintf(stdout, msg, args);
  va_end(args);
  fflush(stdout);
}

__thread int skip_segv;
__thread jmp_buf segv_env;

static void segv_handler(int sig, siginfo_t* info, void* uctx)
{
  if (__atomic_load_n(_segv, __ATOMIC_RELAXED))
_longjmp(segv_env, 1);
  exit(sig);
}

static void install_segv_handler()
{
  struct sigaction sa;
  memset(, 0, sizeof(sa));
  sa.sa_sigaction = segv_handler;
  sa.sa_flags = SA_NODEFER | SA_SIGINFO;
  sigaction(SIGSEGV, , NULL);
  sigaction(SIGBUS, , NULL);
}

#define NONFAILING(...)\
  {\
__atomic_fetch_add(_segv, 1, __ATOMIC_SEQ_CST);   \
if (_setjmp(segv_env) == 0) {  \
  __VA_ARGS__; \
}  \
__atomic_fetch_sub(_segv, 1, __ATOMIC_SEQ_CST);   \
  }

static uintptr_t execute_syscall(int nr, uintptr_t a0, uintptr_t a1,
 uintptr_t a2, uintptr_t a3,
 uintptr_t a4, uintptr_t a5,
 uintptr_t a6, uintptr_t a7,
 uintptr_t a8)
{
  switch (nr) {
  default:
return syscall(nr, a0, a1, a2, a3, a4, a5);
  }
}

static void setup_main_process(uint64_t pid)
{
  struct sigaction sa;
  memset(, 0, sizeof(sa));
  sa.sa_handler = SIG_IGN;
  syscall(SYS_rt_sigaction, 0x20, , NULL, 8);
  syscall(SYS_rt_sigaction, 0x21, , NULL, 8);
  install_segv_handler();

  char tmpdir_template[] = "./syzkaller.XX";
  char* tmpdir = mkdtemp(tmpdir_template);
  if (!tmpdir)
fail("failed to mkdtemp");
  if (chmod(tmpdir, 0777))
fail("failed to chmod");
  if (chdir(tmpdir))
fail("failed to chdir");
}

static void loop();

static void sandbox_common()
{
  prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0);
  setpgrp();
  setsid();

  struct rlimit rlim;
  rlim.rlim_cur = rlim.rlim_max = 128 << 20;
  setrlimit(RLIMIT_AS, );
  rlim.rlim_cur = rlim.rlim_max = 1 << 20;
  setrlimit(RLIMIT_FSIZE, );
  

Re: [PATCH v2] x86/suspend: fix false positive KASAN warning on suspend/resume

[Pavel Machek]

Hi!

> Resuming from a suspend operation is showing a KASAN false positive
> warning:

> KASAN instrumentation poisons the stack when entering a function and
> unpoisons it when exiting the function.  However, in the suspend path,
> some functions never return, so their stack never gets unpoisoned,
> resulting in stale KASAN shadow data which can cause later false
> positive warnings like the one above.
> 
> Reported-by: Scott Bauer 
> Suggested-by: Dmitry Vyukov 
> Signed-off-by: Josh Poimboeuf 

Acked-by: Pavel Machek 

> ---
>  arch/x86/kernel/acpi/wakeup_64.S | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/arch/x86/kernel/acpi/wakeup_64.S 
> b/arch/x86/kernel/acpi/wakeup_64.S
> index 169963f..1df9b75 100644
> --- a/arch/x86/kernel/acpi/wakeup_64.S
> +++ b/arch/x86/kernel/acpi/wakeup_64.S
> @@ -109,6 +109,22 @@ ENTRY(do_suspend_lowlevel)
>   movqpt_regs_r14(%rax), %r14
>   movqpt_regs_r15(%rax), %r15
>  
> +#ifdef CONFIG_KASAN
> + /*
> +  * The suspend path may have poisoned some areas deeper in the stack,
> +  * which we now need to unpoison.
> +  *
> +  * We can't call kasan_unpoison_task_stack_below() because it uses %gs
> +  * for 'current', which hasn't been set up yet.  Instead, calculate the
> +  * stack range manually and call kasan_unpoison_shadow().
> +  */
> + movq%rsp, %rdi
> + andq$CURRENT_MASK, %rdi
> + movq%rsp, %rsi
> + xorq%rdi, %rsi
> + callkasan_unpoison_shadow
> +#endif

Well... you may want to add note to kasan_unpoison_shadow()

/*
* This is called by early resume code, with cpu not yer properly
* resumed. In particular, %gs may not be set up, and thus current
* is not available.
*/

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 0/3] pinctrl: sx150x fixes for the 4-pin chips

[Linus Walleij]

On Fri, Dec 2, 2016 at 11:51 AM, Peter Rosin  wrote:

> I found some more issues when reading the sx150x code.

Thanks, I applied all for v4.10.

> Only the first patch actually fixes a problem. I didn't want to add a
> Fixes tag, since I don't know if commits on the pinctrl devel branch
> are considered stable? Or if you perhaps want to squash this patch with
> the patch it fixes?

Nah I just applied them.

This kernel cycle moves the driver and rewrites it and everything
and a bit of fuzz should be expected so last minute changes
should be regarded as business as usual.

I'm just happy about all the people that paid so much attention
to this driver in the v4.10 cycle :D

Yours,
Linus Walleij

Re: [PATCH v3 7/7] ARM: dts: stm32: add stm32 general purpose timer driver in DT

[Lee Jones]

On Fri, 02 Dec 2016, Benjamin Gaignard wrote:

> Add general purpose timers and it sub-nodes into DT for stm32f4.
> Define and enable pwm1 and pwm3 for stm32f469 discovery board
> 
> version 3:
> - use "st,stm32-timer-trigger" in DT
> 
> version 2:
> - use parameters to describe hardware capabilities
> - do not use references for pwm and iio timer subnodes
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>  arch/arm/boot/dts/stm32f429.dtsi  | 333 
> +-
>  arch/arm/boot/dts/stm32f469-disco.dts |  28 +++
>  2 files changed, 360 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi 
> b/arch/arm/boot/dts/stm32f429.dtsi
> index bca491d..8c50d03 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -48,7 +48,7 @@
>  #include "skeleton.dtsi"
>  #include "armv7-m.dtsi"
>  #include 
> -
> +#include 
>  / {
>   clocks {
>   clk_hse: clk-hse {
> @@ -355,6 +355,21 @@
>   slew-rate = <2>;
>   };
>   };
> +
> + pwm1_pins: pwm@1 {
> + pins {
> + pinmux = ,
> +  
> ,
> +  
> ;
> + };
> + };
> +
> + pwm3_pins: pwm@3 {
> + pins {
> + pinmux = ,
> +  ;
> + };
> + };
>   };
>  
>   rcc: rcc@40023810 {
> @@ -426,6 +441,322 @@
>   interrupts = <80>;
>   clocks = < 0 38>;
>   };
> +
> + gptimer1: gptimer1@4001 {

timer@xxx

Node names should be generic and not numbered.

I suggest that this isn't actually a timer either.  Is contains a
timer (and a PWM), but in it's completeness it is not a timer per
say.

> + compatible = "st,stm32-gptimer";
> + reg = <0x4001 0x400>;
> + clocks = < 0 160>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm1@0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,breakinput;
> + st,complementary;
> + status = "disabled";
> + };
> +
> + timer1@0 {
> + compatible = "st,stm32-timer-trigger";
> + interrupts = <27>;
> + st,input-triggers-names = TIM5_TRGO,
> +   TIM2_TRGO,
> +   TIM4_TRGO,
> +   TIM3_TRGO;

I'm still dubious with matching by strings.

I'll take a look at the C code to see what the alternatives could be.

> + st,output-triggers-names = TIM1_TRGO,
> +TIM1_CH1,
> +TIM1_CH2,
> +TIM1_CH3,
> +TIM1_CH4;
> + status = "disabled";
> + };
> + };
> +
> + gptimer2: gptimer2@4000 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x4000 0x400>;
> + clocks = < 0 128>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm2@0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,32bits-counter;
> + status = "disabled";
> + };
> +
> + timer2@0 {
> + compatible = "st,stm32-timer-trigger";
> + interrupts = <28>;
> + st,input-triggers-names = TIM1_TRGO,
> +   TIM8_TRGO,
> +   TIM3_TRGO,
> +   TIM4_TRGO;
> + st,output-triggers-names = TIM2_TRGO,
> +TIM2_CH1,
> +TIM2_CH2,
> +TIM2_CH3,
> +   

[PATCH 1/5] MIPS: Introduce irq_stack

[Matt Redfearn]

Allocate a per-cpu irq stack for use within interrupt handlers.

Also add a utility function on_irq_stack to determine if a given stack
pointer is within the irq stack for that cpu.

Signed-off-by: Matt Redfearn 

---

 arch/mips/include/asm/irq.h| 12 
 arch/mips/kernel/asm-offsets.c |  1 +
 arch/mips/kernel/irq.c | 11 +++
 3 files changed, 24 insertions(+)

diff --git a/arch/mips/include/asm/irq.h b/arch/mips/include/asm/irq.h
index 6bf10e796553..956db6e201d1 100644
--- a/arch/mips/include/asm/irq.h
+++ b/arch/mips/include/asm/irq.h
@@ -17,6 +17,18 @@
 
 #include 
 
+#define IRQ_STACK_SIZE THREAD_SIZE
+
+extern void *irq_stack[NR_CPUS];
+
+static inline bool on_irq_stack(int cpu, unsigned long sp)
+{
+   unsigned long low = (unsigned long)irq_stack[cpu];
+   unsigned long high = low + IRQ_STACK_SIZE;
+
+   return (low <= sp && sp <= high);
+}
+
 #ifdef CONFIG_I8259
 static inline int irq_canonicalize(int irq)
 {
diff --git a/arch/mips/kernel/asm-offsets.c b/arch/mips/kernel/asm-offsets.c
index fae2f9447792..4be2763f835d 100644
--- a/arch/mips/kernel/asm-offsets.c
+++ b/arch/mips/kernel/asm-offsets.c
@@ -102,6 +102,7 @@ void output_thread_info_defines(void)
OFFSET(TI_REGS, thread_info, regs);
DEFINE(_THREAD_SIZE, THREAD_SIZE);
DEFINE(_THREAD_MASK, THREAD_MASK);
+   DEFINE(_IRQ_STACK_SIZE, IRQ_STACK_SIZE);
BLANK();
 }
 
diff --git a/arch/mips/kernel/irq.c b/arch/mips/kernel/irq.c
index f25f7eab7307..2b0a371b42af 100644
--- a/arch/mips/kernel/irq.c
+++ b/arch/mips/kernel/irq.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 
+void *irq_stack[NR_CPUS];
+
 /*
  * 'what should we do if we get a hw irq event on an illegal vector'.
  * each architecture has to answer this themselves.
@@ -58,6 +60,15 @@ void __init init_IRQ(void)
clear_c0_status(ST0_IM);
 
arch_init_irq();
+
+   for_each_possible_cpu(i) {
+   int irq_pages = IRQ_STACK_SIZE / PAGE_SIZE;
+   void *s = (void *)__get_free_pages(GFP_KERNEL, irq_pages);
+
+   irq_stack[i] = s;
+   pr_debug("CPU%d IRQ stack at 0x%p - 0x%p\n", i,
+   irq_stack[i], irq_stack[i] + IRQ_STACK_SIZE);
+   }
 }
 
 #ifdef CONFIG_DEBUG_STACKOVERFLOW
-- 
2.7.4

Re: [PATCH v3 7/7] ARM: dts: stm32: add stm32 general purpose timer driver in DT

[Alexandre Torgue]

Hi Benjamin,

On 12/02/2016 11:17 AM, Benjamin Gaignard wrote:

Add general purpose timers and it sub-nodes into DT for stm32f4.
Define and enable pwm1 and pwm3 for stm32f469 discovery board

version 3:
- use "st,stm32-timer-trigger" in DT

version 2:
- use parameters to describe hardware capabilities
- do not use references for pwm and iio timer subnodes

Signed-off-by: Benjamin Gaignard 
---
 arch/arm/boot/dts/stm32f429.dtsi  | 333 +-
 arch/arm/boot/dts/stm32f469-disco.dts |  28 +++
 2 files changed, 360 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index bca491d..8c50d03 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -48,7 +48,7 @@
 #include "skeleton.dtsi"
 #include "armv7-m.dtsi"
 #include 
-
+#include 
 / {
clocks {
clk_hse: clk-hse {
@@ -355,6 +355,21 @@
slew-rate = <2>;
};
};
+
+   pwm1_pins: pwm@1 {
+   pins {
+   pinmux = ,
+
,
+
;
+   };
+   };
+
+   pwm3_pins: pwm@3 {
+   pins {
+   pinmux = ,
+;
+   };
+   };
};

rcc: rcc@40023810 {
@@ -426,6 +441,322 @@
interrupts = <80>;
clocks = < 0 38>;
};
+
+   gptimer1: gptimer1@4001 {


Currently, nodes are ordered following base address.


+   compatible = "st,stm32-gptimer";
+   reg = <0x4001 0x400>;
+   clocks = < 0 160>;
+   clock-names = "clk_int";
+   status = "disabled";
+
+   pwm1@0 {
+   compatible = "st,stm32-pwm";
+   st,pwm-num-chan = <4>;
+   st,breakinput;
+   st,complementary;
+   status = "disabled";
+   };
+
+   timer1@0 {
+   compatible = "st,stm32-timer-trigger";
+   interrupts = <27>;
+   st,input-triggers-names = TIM5_TRGO,
+ TIM2_TRGO,
+ TIM4_TRGO,
+ TIM3_TRGO;
+   st,output-triggers-names = TIM1_TRGO,
+  TIM1_CH1,
+  TIM1_CH2,
+  TIM1_CH3,
+  TIM1_CH4;
+   status = "disabled";
+   };
+   };
+
+   gptimer2: gptimer2@4000 {
+   compatible = "st,stm32-gptimer";
+   reg = <0x4000 0x400>;
+   clocks = < 0 128>;
+   clock-names = "clk_int";
+   status = "disabled";
+
+   pwm2@0 {
+   compatible = "st,stm32-pwm";
+   st,pwm-num-chan = <4>;
+   st,32bits-counter;
+   status = "disabled";
+   };
+
+   timer2@0 {
+   compatible = "st,stm32-timer-trigger";
+   interrupts = <28>;
+   st,input-triggers-names = TIM1_TRGO,
+ TIM8_TRGO,
+ TIM3_TRGO,
+ TIM4_TRGO;
+   st,output-triggers-names = TIM2_TRGO,
+  TIM2_CH1,
+  TIM2_CH2,
+  TIM2_CH3,
+  TIM2_CH4;
+   status = "disabled";
+   };
+   };
+
+   gptimer3: gptimer3@4400 {
+   compatible = "st,stm32-gptimer";
+   reg = <0x4400 0x400>;
+ 

[PATCH] IB/core: fix unmap_sg argument

[Sebastian Ott]

Hi,

using dapltest on s390 I ran into the following warning:

[   20.781709] mlx4_core :00:00.0: DMA-API: device driver frees DMA sg list 
with different entry count [map count=2] [unmap count=1]
[   20.781760] [ cut here ]
[   20.781767] WARNING: CPU: 4 PID: 1063 at lib/dma-debug.c:1141 
check_unmap+0x658/0xa08
[   20.781769] Modules linked in: rdma_ucm ib_ucm ib_uverbs rdma_cm configfs 
ib_cm iw_cm [...]
[   20.781797] CPU: 4 PID: 1063 Comm: dapltest Tainted: GW   
4.9.0-rc7-00039-g43c4f67 #65
[   20.781799] Hardware name: IBM  2964 N96  704
  (LPAR)
[   20.781801] task: dd8e4008 task.stack: f1448000
[   20.781803] Krnl PSW : 0404c0018000 0060af08 
(check_unmap+0x658/0xa08)
[   20.781806]R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 
RI:0 EA:3
[   20.781809] Krnl GPRS: 0002 dd8e4008 0079 
00a1d4f0
[   20.781811]0060af04  0001 
0001
[   20.781813]f8e8e880 078f2210 01e47700 
f7a11298
[   20.781814]f144ba68 008f21f8 0060af04 
f144b960
[   20.781822] Krnl Code: 0060aef8: c0200022fcc0larl
%r2,a6a878
  0060aefe: c0e5ffe474ddbrasl   
%r14,2998b8
 #0060af04: a7f40001brc 
15,60af06
 >0060af08: c0200022f976larl
%r2,a6a1f4
  0060af0e: c0e5ffe474d5brasl   
%r14,2998b8
  0060af14: 4120b050la  
%r2,80(%r11)
  0060af18: a739lghi%r3,0
  0060af1c: c0e5ffde780abrasl   
%r14,1d9f30
[   20.781847] Call Trace:
[   20.781848] ([<0060af04>] check_unmap+0x654/0xa08)
[   20.781851]  [<0060b6bc>] debug_dma_unmap_sg+0xf4/0x160 
[   20.781873]  [<03ff82245738>] __ib_umem_release+0x98/0x1a8 [ib_core] 
[   20.781881]  [<03ff82245f3e>] ib_umem_release+0x5e/0x1d0 [ib_core] 
[   20.781891]  [<03ff80139976>] mlx4_ib_destroy_qp+0x47e/0x550 [mlx4_ib] 
[   20.781898]  [<03ff8222ad2e>] ib_destroy_qp+0x116/0x188 [ib_core] 
[   20.781902]  [<03ff80052fba>] ib_uverbs_destroy_qp+0xb2/0x1a0 
[ib_uverbs] 
[   20.781905]  [<03ff8004cada>] ib_uverbs_write+0x20a/0x488 [ib_uverbs] 
[   20.781910]  [<00352756>] __vfs_write+0x36/0x138 
[   20.781912]  [<0035348c>] vfs_write+0xbc/0x1a0 
[   20.781914]  [<00354a96>] SyS_write+0x66/0xc0 
[   20.781918]  [<0087d796>] system_call+0xd6/0x270 
[   20.781919] INFO: lockdep is turned off.
[   20.781921] Last Breaking-Event-Address:
[   20.781922]  [<0060af04>] check_unmap+0x654/0xa08
[   20.781924] ---[ end trace bd581c43b9bebeea ]---
[   20.781925] Mapped at:
[   20.781929] [<0060b4a6>] debug_dma_map_sg+0x5e/0x180
[   20.781938] [<03ff82245d12>] ib_umem_get+0x4ca/0x610 [ib_core]
[   20.781943] [<03ff80136df2>] create_qp_common.isra.15+0x572/0x1010 
[mlx4_ib]
[   20.781949] [<03ff8013929e>] mlx4_ib_create_qp+0x1de/0x438 [mlx4_ib]
[   20.781953] [<03ff8004f52c>] create_qp.isra.11+0x44c/0x7f0 [ib_uverbs]

The following patch fixes this:

>8
>From ec91646d8c14e2a8dd2b62187084dab32ef8a56b Mon Sep 17 00:00:00 2001
From: Sebastian Ott 
Date: Fri, 2 Dec 2016 11:15:05 +0100
Subject: [PATCH] IB/core: fix unmap_sg argument

__ib_umem_release calls dma_unmap_sg with a different number of
sg_entries than ib_umem_get uses for dma_map_sg. This might cause
trouble for implementations that merge sglist entries and results
in the following dma debug complaint:

DMA-API: device driver frees DMA sg list with different entry
 count [map count=2] [unmap count=1]

Fix it by using the correct value.

Signed-off-by: Sebastian Ott 
---
 drivers/infiniband/core/umem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 84b4eff..1e62a5f 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -51,7 +51,7 @@ static void __ib_umem_release(struct ib_device *dev, struct 
ib_umem *umem, int d
 
if (umem->nmap > 0)
ib_dma_unmap_sg(dev, umem->sg_head.sgl,
-   umem->nmap,
+   umem->npages,
DMA_BIDIRECTIONAL);
 
for_each_sg(umem->sg_head.sgl, sg, umem->npages, i) {
-- 
2.7.4

Re: [PATCH v2] zswap: only use CPU notifier when HOTPLUG_CPU=y

[Michal Hocko]

On Wed 30-11-16 13:15:16, Yu Zhao wrote:
> __unregister_cpu_notifier() only removes registered notifier from its
> linked list when CPU hotplug is configured. If we free registered CPU
> notifier when HOTPLUG_CPU=n, we corrupt the linked list.
> 
> To fix the problem, we can either use a static CPU notifier that walks
> through each pool or just simply disable CPU notifier when CPU hotplug
> is not configured (which is perfectly safe because the code in question
> is called after all possible CPUs are online and will remain online
> until power off).
> 
> v2: #ifdef for cpu_notifier_register_done during cleanup.

this ifedfery is just ugly as hell. I am also wondering whether it is
really needed. __register_cpu_notifier and __unregister_cpu_notifier are
noops for CONFIG_HOTPLUG_CPU=n. So what's exactly that is broken here?

> Signe-off-by: Yu Zhao 
> ---
>  mm/zswap.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/mm/zswap.c b/mm/zswap.c
> index 275b22c..2915f44 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -118,7 +118,9 @@ struct zswap_pool {
>   struct kref kref;
>   struct list_head list;
>   struct work_struct work;
> +#ifdef CONFIG_HOTPLUG_CPU
>   struct notifier_block notifier;
> +#endif
>   char tfm_name[CRYPTO_MAX_ALG_NAME];
>  };
>  
> @@ -448,6 +450,7 @@ static int __zswap_cpu_comp_notifier(struct zswap_pool 
> *pool,
>   return NOTIFY_OK;
>  }
>  
> +#ifdef CONFIG_HOTPLUG_CPU
>  static int zswap_cpu_comp_notifier(struct notifier_block *nb,
>  unsigned long action, void *pcpu)
>  {
> @@ -456,27 +459,34 @@ static int zswap_cpu_comp_notifier(struct 
> notifier_block *nb,
>  
>   return __zswap_cpu_comp_notifier(pool, action, cpu);
>  }
> +#endif
>  
>  static int zswap_cpu_comp_init(struct zswap_pool *pool)
>  {
>   unsigned long cpu;
>  
> +#ifdef CONFIG_HOTPLUG_CPU
>   memset(>notifier, 0, sizeof(pool->notifier));
>   pool->notifier.notifier_call = zswap_cpu_comp_notifier;
>  
>   cpu_notifier_register_begin();
> +#endif
>   for_each_online_cpu(cpu)
>   if (__zswap_cpu_comp_notifier(pool, CPU_UP_PREPARE, cpu) ==
>   NOTIFY_BAD)
>   goto cleanup;
> +#ifdef CONFIG_HOTPLUG_CPU
>   __register_cpu_notifier(>notifier);
>   cpu_notifier_register_done();
> +#endif
>   return 0;
>  
>  cleanup:
>   for_each_online_cpu(cpu)
>   __zswap_cpu_comp_notifier(pool, CPU_UP_CANCELED, cpu);
> +#ifdef CONFIG_HOTPLUG_CPU
>   cpu_notifier_register_done();
> +#endif
>   return -ENOMEM;
>  }
>  
> @@ -484,11 +494,15 @@ static void zswap_cpu_comp_destroy(struct zswap_pool 
> *pool)
>  {
>   unsigned long cpu;
>  
> +#ifdef CONFIG_HOTPLUG_CPU
>   cpu_notifier_register_begin();
> +#endif
>   for_each_online_cpu(cpu)
>   __zswap_cpu_comp_notifier(pool, CPU_UP_CANCELED, cpu);
> +#ifdef CONFIG_HOTPLUG_CPU
>   __unregister_cpu_notifier(>notifier);
>   cpu_notifier_register_done();
> +#endif
>  }
>  
>  /*
> -- 
> 2.8.0.rc3.226.g39d4020
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v3 5/7] IIO: add bindings for stm32 timer trigger driver

[Lee Jones]

On Fri, 02 Dec 2016, Benjamin Gaignard wrote:

> Define bindings for stm32 timer trigger
> 
> version 3:
> - change file name
> - add cross reference with mfd bindings
> 
> version 2:
> - only keep one compatible
> - add DT parameters to set lists of the triggers:
>   one list describe the triggers created by the device
>   another one give the triggers accepted by the device
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>  .../bindings/iio/timer/stm32-timer-trigger.txt | 39 
> ++
>  1 file changed, 39 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt 
> b/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
> new file mode 100644
> index 000..858816d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
> @@ -0,0 +1,39 @@
> +timer trigger bindings for STM32
> +
> +Must be a sub-node of STM32 general purpose timer driver
> +Parent node properties are describe in ../mfd/stm32-general-purpose-timer.txt
> +
> +Required parameters:
> +- compatible:must be "st,stm32-iio-timer"
> +- interrupts:Interrupt for this device
> + See ../interrupt-controller/st,stm32-exti.txt
> +
> +Optional parameters:
> +- st,input-triggers-names:   List of the possible input triggers for
> + the device
> +- st,output-triggers-names:  List of the possible output triggers for
> + the device
> +
> +Possible triggers are defined in 
> include/dt-bindings/iio/timer/st,stm32-timer-trigger.h
> +
> +Example:
> + gptimer1: gptimer1@4001 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x4001 0x400>;
> + clocks = < 0 160>;
> + clock-names = "clk_int";
> +
> + timer1@0 {
> + compatible = "st,stm32-timer-trigger";
> + interrupts = <27>;
> + st,input-triggers-names = TIM5_TRGO,
> +   TIM2_TRGO,
> +   TIM4_TRGO,
> +   TIM3_TRGO;
> + st,output-triggers-names = TIM1_TRGO,
> +TIM1_CH1,
> +TIM1_CH2,
> +TIM1_CH3,
> +TIM1_CH4;

I see why you've done it like this now ... because it makes things
easier for you in the driver, since the IIO subsystem matches on names
such as these.

BUT, this is a Linux-implementation-ism.  Just use pairs of integers
and create the Linux-ism strings in the driver.

> + };
> + };

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2] x86/suspend: fix false positive KASAN warning on suspend/resume

[Josh Poimboeuf]

On Fri, Dec 02, 2016 at 04:41:09PM +0300, Andrey Ryabinin wrote:
> 
> 
> On 12/01/2016 11:31 PM, Josh Poimboeuf wrote:
> 
> >  arch/x86/kernel/acpi/wakeup_64.S | 16 
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/arch/x86/kernel/acpi/wakeup_64.S 
> > b/arch/x86/kernel/acpi/wakeup_64.S
> > index 169963f..1df9b75 100644
> > --- a/arch/x86/kernel/acpi/wakeup_64.S
> > +++ b/arch/x86/kernel/acpi/wakeup_64.S
> > @@ -109,6 +109,22 @@ ENTRY(do_suspend_lowlevel)
> > movqpt_regs_r14(%rax), %r14
> > movqpt_regs_r15(%rax), %r15
> >  
> > +#ifdef CONFIG_KASAN
> > +   /*
> > +* The suspend path may have poisoned some areas deeper in the stack,
> > +* which we now need to unpoison.
> > +*
> > +* We can't call kasan_unpoison_task_stack_below() because it uses %gs
> > +* for 'current', which hasn't been set up yet.  Instead, calculate the
> > +* stack range manually and call kasan_unpoison_shadow().
> > +*/
> > +   movq%rsp, %rdi
> > +   andq$CURRENT_MASK, %rdi
> > +   movq%rsp, %rsi
> > +   xorq%rdi, %rsi
> > +   callkasan_unpoison_shadow
> > +#endif
> > +
> 
> Looks good, but in fact we can use kasan_unpoison_task_stack_below(). We just 
> need to change it a little:
> 
> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
> index 70c0097..e779236 100644
> --- a/mm/kasan/kasan.c
> +++ b/mm/kasan/kasan.c
> @@ -80,7 +80,9 @@ void kasan_unpoison_task_stack(struct task_struct *task)
>  /* Unpoison the stack for the current task beyond a watermark sp value. */
>  asmlinkage void kasan_unpoison_task_stack_below(const void *watermark)
>  {
> -   __kasan_unpoison_stack(current, watermark);
> +   void *base = (void *)((unsigned long)watermark & ~(THREAD_SIZE - 1));
> +
> +   kasan_unpoison_shadow(base, watermark - base);
>  }
> 
> 
> With this we don't have to calculate stack range in assembly.

That is better indeed, will do a v3.

-- 
Josh

[PATCH 02/11] megaraid_sas: 128 MSIX Support

[Sasikumar Chandrasekaran]

SAS3.5 Generic Megaraid based Controllers will have the support for 128 MSI-X 
vectors,
resulting in the need to support 128 reply queues

This patch is depending on patch 1

Signed-off-by: Sasikumar Chandrasekaran 
---
 drivers/scsi/megaraid/megaraid_sas.h|  1 +
 drivers/scsi/megaraid/megaraid_sas_base.c   | 24 +---
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  4 ++--
 3 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index f24ce88..af94f58 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -2152,6 +2152,7 @@ struct megasas_instance {
bool dev_handle;
bool fw_sync_cache_support;
bool is_ventura;
+   bool msix_combined;
 };
 struct MR_LD_VF_MAP {
u32 size;
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index b7166b8..7c8c313 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5089,13 +5089,7 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
goto fail_ready_state;
}
 
-   /*
-* MSI-X host index 0 is common for all adapter.
-* It is used for all MPT based Adapters.
-*/
-   instance->reply_post_host_index_addr[0] =
-   (u32 __iomem *)((u8 __iomem *)instance->reg_set +
-   MPI2_REPLY_POST_HOST_INDEX_OFFSET);
+
 
/* Check if MSI-X is supported while in ready state */
msix_enable = (instance->instancet->read_fw_status_reg(reg_set) &
@@ -5113,6 +5107,9 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
instance->msix_vectors = ((scratch_pad_2
& MR_MAX_REPLY_QUEUES_EXT_OFFSET)
>> 
MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT) + 1;
+   if (instance->msix_vectors > 16)
+   instance->msix_combined = true;
+
if (rdpq_enable)
instance->is_rdpq = (scratch_pad_2 & 
MR_RDPQ_MODE_OFFSET) ?
1 : 0;
@@ -5146,6 +5143,19 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
else
instance->msix_vectors = 0;
}
+   /*
+* MSI-X host index 0 is common for all adapter.
+* It is used for all MPT based Adapters.
+*/
+   if (instance->msix_combined) {
+   instance->reply_post_host_index_addr[0] =
+   (u32 *)((u8 *)instance->reg_set +
+   MPI2_SUP_REPLY_POST_HOST_INDEX_OFFSET);
+   } else {
+   instance->reply_post_host_index_addr[0] =
+   (u32 *)((u8 *)instance->reg_set +
+   MPI2_REPLY_POST_HOST_INDEX_OFFSET);
+   }
 
dev_info(>pdev->dev,
"firmware supports msix\t: (%d)", fw_msix_count);
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index e048423..9de9e66 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2391,7 +2391,7 @@ static void megasas_build_ld_nonrw_fusion(struct 
megasas_instance *instance,
 * pending to be completed
 */
if (threshold_reply_count >= THRESHOLD_REPLY_COUNT) {
-   if (fusion->adapter_type == INVADER_SERIES)
+   if (instance->msix_combined)
writel(((MSIxIndex & 0x7) << 24) |
fusion->last_reply_idx[MSIxIndex],

instance->reply_post_host_index_addr[MSIxIndex/8]);
@@ -2407,7 +2407,7 @@ static void megasas_build_ld_nonrw_fusion(struct 
megasas_instance *instance,
return IRQ_NONE;
 
wmb();
-   if (fusion->adapter_type == INVADER_SERIES)
+   if (instance->msix_combined)
writel(((MSIxIndex & 0x7) << 24) |
fusion->last_reply_idx[MSIxIndex],
instance->reply_post_host_index_addr[MSIxIndex/8]);
-- 
1.8.3.1

[PATCH 04/11] megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and IO Coalescing

[Sasikumar Chandrasekaran]

Detect sequential IO streams and pass those IOs directly to FW.

This patch is depending on patch 3

Signed-off-by: Sasikumar Chandrasekaran 
---
 drivers/scsi/megaraid/megaraid_sas.h|   1 +
 drivers/scsi/megaraid/megaraid_sas_base.c   |  40 +++-
 drivers/scsi/megaraid/megaraid_sas_fp.c |   2 +
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 151 +++-
 drivers/scsi/megaraid/megaraid_sas_fusion.h | 123 +-
 5 files changed, 287 insertions(+), 30 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index af94f58..ee6bd5c 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -2073,6 +2073,7 @@ struct megasas_instance {
/* used to sync fire the cmd to fw */
spinlock_t hba_lock;
/* used to synch producer, consumer ptrs in dpc */
+   spinlock_t stream_lock;
spinlock_t completion_lock;
struct dma_pool *frame_dma_pool;
struct dma_pool *sense_dma_pool;
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 7c8c313..86f25d5 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5018,7 +5018,7 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
struct megasas_register_set __iomem *reg_set;
struct megasas_ctrl_info *ctrl_info = NULL;
unsigned long bar_list;
-   int i, loop, fw_msix_count = 0;
+   int i, j, loop, fw_msix_count = 0;
struct IOV_111 *iovPtr;
struct fusion_context *fusion;
 
@@ -5205,6 +5205,33 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
}
 
memset(instance->ld_ids, 0xff, MEGASAS_MAX_LD_IDS);
+
+   /* stream detection initialization */
+   if (instance->is_ventura) {
+   fusion->streamDetectByLD =
+   kzalloc(sizeof(PTR_LD_STREAM_DETECT) * MAX_LOGICAL_DRIVES_EXT,
+   GFP_KERNEL);
+   if (!fusion->streamDetectByLD) {
+   dev_err(>pdev->dev,
+   "unable to allocate stream detection 
for pool of LDs\n");
+   goto fail_get_ld_pd_list;
+   }
+   for (i = 0; i < MAX_LOGICAL_DRIVES_EXT; ++i) {
+   fusion->streamDetectByLD[i] =
+   kmalloc(sizeof(LD_STREAM_DETECT), GFP_KERNEL);
+   if (!fusion->streamDetectByLD[i]) {
+   dev_err(>pdev->dev,
+   "unable to allocate stream detect by 
LD\n ");
+for (j = 0; j < i; ++j)
+   kfree(fusion->streamDetectByLD[j]);
+   kfree(fusion->streamDetectByLD);
+   fusion->streamDetectByLD = NULL;
+   goto fail_get_ld_pd_list;
+   }
+   fusion->streamDetectByLD[i]->mruBitMap = 
MR_STREAM_BITMAP;
+   }
+   }
+
if (megasas_ld_list_query(instance,
  MR_LD_QUERY_TYPE_EXPOSED_TO_HOST))
megasas_get_ld_list(instance);
@@ -5324,6 +5351,8 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
 
return 0;
 
+fail_get_ld_pd_list:
+   instance->instancet->disable_intr(instance);
 fail_get_pd_list:
instance->instancet->disable_intr(instance);
megasas_destroy_irqs(instance);
@@ -5860,6 +5889,7 @@ static int megasas_probe_one(struct pci_dev *pdev,
 
spin_lock_init(>mfi_pool_lock);
spin_lock_init(>hba_lock);
+   spin_lock_init(>stream_lock);
spin_lock_init(>completion_lock);
 
mutex_init(>reset_mutex);
@@ -6360,6 +6390,14 @@ static void megasas_detach_one(struct pci_dev *pdev)
if (instance->msix_vectors)
pci_disable_msix(instance->pdev);
 
+   if (instance->is_ventura) {
+   for (i = 0; i < MAX_LOGICAL_DRIVES_EXT; ++i)
+   kfree(fusion->streamDetectByLD[i]);
+   kfree(fusion->streamDetectByLD);
+   fusion->streamDetectByLD = NULL;
+   }
+
+
if (instance->ctrl_context) {
megasas_release_fusion(instance);
pd_seq_map_sz = sizeof(struct MR_PD_CFG_SEQ_NUM_SYNC) +
diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c 
b/drivers/scsi/megaraid/megaraid_sas_fp.c
index f237d00..d9483bc 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fp.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
@@ -935,6 +935,8 @@ u8 MR_GetPhyParams(struct megasas_instance *instance, u32 
ld, u64 stripRow,
 
ld = MR_TargetIdToLdGet(ldTgtId, map);
raid = MR_LdRaidGet(ld, map);
+   /*check read ahead bit*/
+   io_info->raCapable 

[PATCH 00/11] Updates for scsi-next

[Sasikumar Chandrasekaran]

Sasikumar Chandrasekaran (11):
  megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid
Controllers
  megaraid_sas: 128 MSIX Support
  megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid
Controllers
  megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and
IO Coalescing
  megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID
1/10 Writes
  megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid
Controllers
  megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers
Capabilities
  megaraid_sas: Enable or Disable Fast path based on the PCI Threshold
Bandwidth
  megaraid_sas: ldio_outstanding variable is not decremented in
completion path
  megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid
Controllers
  megaraid_sas: driver version upgrade

 drivers/scsi/megaraid/megaraid_sas.h| 139 --
 drivers/scsi/megaraid/megaraid_sas_base.c   | 242 +++---
 drivers/scsi/megaraid/megaraid_sas_fp.c | 319 +++--
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 687 
 drivers/scsi/megaraid/megaraid_sas_fusion.h | 318 -
 5 files changed, 1474 insertions(+), 231 deletions(-)

-- 
1.8.3.1

[PATCH 1/6] net: stmmac: return error if no DMA configuration is found

[Niklas Cassel]

From: Niklas Cassel 

All drivers except pci glue layer calls stmmac_probe_config_dt.
stmmac_probe_config_dt does a kzalloc dma_cfg.

pci glue layer does kzalloc dma_cfg explicitly, so all current
drivers does a kzalloc dma_cfg.

Return an error if no DMA configuration is found, that way
we can assume that the DMA configuration always exists.

Signed-off-by: Niklas Cassel 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1f9ec02fa7f8..04f88df7da49 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1577,16 +1577,12 @@ static void stmmac_check_ether_addr(struct stmmac_priv 
*priv)
  */
 static int stmmac_init_dma_engine(struct stmmac_priv *priv)
 {
-   int pbl = DEFAULT_DMA_PBL, fixed_burst = 0, aal = 0;
-   int mixed_burst = 0;
int atds = 0;
int ret = 0;
 
-   if (priv->plat->dma_cfg) {
-   pbl = priv->plat->dma_cfg->pbl;
-   fixed_burst = priv->plat->dma_cfg->fixed_burst;
-   mixed_burst = priv->plat->dma_cfg->mixed_burst;
-   aal = priv->plat->dma_cfg->aal;
+   if (!priv->plat->dma_cfg) {
+   dev_err(priv->device, "DMA configuration not found\n");
+   return -EINVAL;
}
 
if (priv->extend_desc && (priv->mode == STMMAC_RING_MODE))
@@ -1598,8 +1594,12 @@ static int stmmac_init_dma_engine(struct stmmac_priv 
*priv)
return ret;
}
 
-   priv->hw->dma->init(priv->ioaddr, pbl, fixed_burst, mixed_burst,
-   aal, priv->dma_tx_phy, priv->dma_rx_phy, atds);
+   priv->hw->dma->init(priv->ioaddr,
+   priv->plat->dma_cfg->pbl,
+   priv->plat->dma_cfg->fixed_burst,
+   priv->plat->dma_cfg->mixed_burst,
+   priv->plat->dma_cfg->aal,
+   priv->dma_tx_phy, priv->dma_rx_phy, atds);
 
if (priv->synopsys_id >= DWMAC_CORE_4_00) {
priv->rx_tail_addr = priv->dma_rx_phy +
-- 
2.1.4

[PATCH 3/6] net: stmmac: stmmac_platform: fix parsing of DT binding

[Niklas Cassel]

From: Niklas Cassel 

commit 64c3b252e9fc ("net: stmmac: fixed the pbl setting with DT")
changed the parsing of the DT binding.

Before 64c3b252e9fc, snps,fixed-burst and snps,mixed-burst were parsed
regardless if the property snps,pbl existed or not.
After the commit, fixed burst and mixed burst are only parsed if
snps,pbl exists. Now when snps,aal has been added, it too is only
parsed if snps,pbl exists.

Since the DT binding does not specify that fixed burst, mixed burst
or aal depend on snps,pbl being specified, undo changes introduced
by 64c3b252e9fc.

The issue commit 64c3b252e9fc ("net: stmmac: fixed the pbl setting with
DT") tries to address is solved in another way:
The databook specifies that all values other than
1, 2, 4, 8, 16, or 32 results in undefined behavior,
so snps,pbl = <0> is invalid.

If pbl is 0 after parsing, set pbl to DEFAULT_DMA_PBL.
This handles the case where the property is omitted, and also handles
the case where the property is specified without any data.

Signed-off-by: Niklas Cassel 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  |  3 +++
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  | 27 +++---
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 27a03f7ee095..9ba2eb4c22fe 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1585,6 +1585,9 @@ static int stmmac_init_dma_engine(struct stmmac_priv 
*priv)
return -EINVAL;
}
 
+   if (!priv->plat->dma_cfg->pbl)
+   priv->plat->dma_cfg->pbl = DEFAULT_DMA_PBL;
+
if (priv->extend_desc && (priv->mode == STMMAC_RING_MODE))
atds = 1;
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index b46c892c7079..05b8c33effd5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -303,21 +303,20 @@ stmmac_probe_config_dt(struct platform_device *pdev, 
const char **mac)
plat->force_sf_dma_mode = 1;
}
 
-   if (of_find_property(np, "snps,pbl", NULL)) {
-   dma_cfg = devm_kzalloc(>dev, sizeof(*dma_cfg),
-  GFP_KERNEL);
-   if (!dma_cfg) {
-   of_node_put(plat->phy_node);
-   return ERR_PTR(-ENOMEM);
-   }
-   plat->dma_cfg = dma_cfg;
-   of_property_read_u32(np, "snps,pbl", _cfg->pbl);
-   dma_cfg->aal = of_property_read_bool(np, "snps,aal");
-   dma_cfg->fixed_burst =
-   of_property_read_bool(np, "snps,fixed-burst");
-   dma_cfg->mixed_burst =
-   of_property_read_bool(np, "snps,mixed-burst");
+   dma_cfg = devm_kzalloc(>dev, sizeof(*dma_cfg),
+  GFP_KERNEL);
+   if (!dma_cfg) {
+   of_node_put(plat->phy_node);
+   return ERR_PTR(-ENOMEM);
}
+   plat->dma_cfg = dma_cfg;
+
+   of_property_read_u32(np, "snps,pbl", _cfg->pbl);
+
+   dma_cfg->aal = of_property_read_bool(np, "snps,aal");
+   dma_cfg->fixed_burst = of_property_read_bool(np, "snps,fixed-burst");
+   dma_cfg->mixed_burst = of_property_read_bool(np, "snps,mixed-burst");
+
plat->force_thresh_dma_mode = of_property_read_bool(np, 
"snps,force_thresh_dma_mode");
if (plat->force_thresh_dma_mode) {
plat->force_sf_dma_mode = 0;
-- 
2.1.4

Re: 4.9-rc: only 3 CPUs out of 4 used

[Meelis Roos]

> > I have a HP ProLiant DL380 G3 server. It has two 
> > dual-core 32-bit Xeon CPUs. CONFIG_NR_CPUS=4 and has always been.
> 
> Same happens on DL360 G3 - 1U server of the same era.

And the next generation of it, DL380 G4, shows the same problem.

-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH v2 2/5] ia64: reuse append_elf_note() and final_note() functions

[Hari Bathini]

Hi Dave,


Thanks for the review.


On Thursday 01 December 2016 10:26 AM, Dave Young wrote:

Hi Hari

Personally I like V1 more, but split the patch 2 is easier for ia64
people to reivew.  I did basic x86 testing, it runs ok.

On 11/25/16 at 05:24pm, Hari Bathini wrote:

Get rid of multiple definitions of append_elf_note() & final_note()
functions. Reuse these functions compiled under CONFIG_CRASH_CORE.

Signed-off-by: Hari Bathini 
---
  arch/ia64/kernel/crash.c   |   22 --
  include/linux/crash_core.h |4 
  kernel/crash_core.c|6 +++---
  kernel/kexec_core.c|   28 
  4 files changed, 7 insertions(+), 53 deletions(-)

diff --git a/arch/ia64/kernel/crash.c b/arch/ia64/kernel/crash.c
index 2955f35..75859a0 100644
--- a/arch/ia64/kernel/crash.c
+++ b/arch/ia64/kernel/crash.c
@@ -27,28 +27,6 @@ static int kdump_freeze_monarch;
  static int kdump_on_init = 1;
  static int kdump_on_fatal_mca = 1;
  
-static inline Elf64_Word

-*append_elf_note(Elf64_Word *buf, char *name, unsigned type, void *data,
-   size_t data_len)
-{
-   struct elf_note *note = (struct elf_note *)buf;
-   note->n_namesz = strlen(name) + 1;
-   note->n_descsz = data_len;
-   note->n_type   = type;
-   buf += (sizeof(*note) + 3)/4;
-   memcpy(buf, name, note->n_namesz);
-   buf += (note->n_namesz + 3)/4;
-   memcpy(buf, data, data_len);
-   buf += (data_len + 3)/4;
-   return buf;
-}
-
-static void
-final_note(void *buf)
-{
-   memset(buf, 0, sizeof(struct elf_note));
-}
-

The above IA64 version looks better than the functions in kexec_core.c
about the Elf64_Word type usage and the simpler final_note function.


Hmmm.. Is void* better over Elf64_Word* to be agnostic of Elf32 or Elf64 
type?




Care to update crash_core.c to use this instead?


Sure. Will resend.

Thanks
Hari

Re: fsnotify_mark_srcu wtf?

[Amir Goldstein]

On Fri, Dec 2, 2016 at 12:48 PM, Jan Kara  wrote:
> On Fri 02-12-16 09:26:51, Miklos Szeredi wrote:
...
>>
>> Hmm, how about this: when removing mark from inode, drop refcount.  If
>> refcount is zero can remove from list.  Otherwise mark the mark "dead"
>> and leave it on the list.
>>
>> And fsnotify can just skip dead marks.
>
> I had this idea as well and when trying to implement this, I've stumbled
> over some problems. I think the biggest problem was that destruction of a
> notification mark is relatively complex operation (doing iput() for
> example) and quite a few places dropping mark references are in a context
> where this can cause problems. Also I don't want to defer iput() to a
> workqueue as that will have unexpected consequences such as unlinked
> watched inode lingering in the system (possibly colliding with umount
> etc.).
>

I am wondering out loud if we are trying to solve a real problem or a made
up test case. I wonder if Miklos' test program truly represents the original
bug report. I am asking because fanotify permission events are usually
associated with system security software and it usually makes sense on
a vfsmount_mark and not an inode_mark.

Maybe the break even solution is not to split destroy lists per group priority,
but to split destroy lists by inode marks and vfsmount marks
and also keep 2 separate lists per group.

I am only asking this because you mentioned iput as a thorn in the solution.
Since vfsmount mark does not pin the mount, nor hold an elevated reference,
perhaps dealing with simpler destruction of vfsmount marks can solve the
problem for "rogue fanotify permission mount watch" and maybe that is
enough for all practical matters?

Amir.

Re: [RFC PATCH] PCI: designware: add host_init() error handling

[Srinivas Kandagatla]

On 02/12/16 10:32, Joao Pinto wrote:


Hi Srinivas,

Às 11:51 AM de 12/1/2016, Srinivas Kandagatla escreveu:

 drivers/pci/host/pci-dra7xx.c   |  4 +++-
 drivers/pci/host/pci-exynos.c   |  4 +++-
 drivers/pci/host/pci-imx6.c |  4 +++-
 drivers/pci/host/pci-keystone.c |  4 +++-
 drivers/pci/host/pci-layerscape.c   | 12 
 drivers/pci/host/pcie-armada8k.c|  4 +++-
 drivers/pci/host/pcie-designware-plat.c |  4 +++-
 drivers/pci/host/pcie-designware.c  |  4 +++-
 drivers/pci/host/pcie-designware.h  |  2 +-
 drivers/pci/host/pcie-qcom.c|  6 --
 drivers/pci/host/pcie-spear13xx.c   |  4 +++-
 11 files changed, 37 insertions(+), 15 deletions(-)



Thanks for the patch!

In my opinion your idea is good but only qcom driver is able to detect failure
in the specific host init routine, all others have a 'return 0' even if
something not well init. I would recomend that we take this issue a bit further
and add the error checking to all specific pci drivers in order to make them as
robust as qcom'.

I totally agree with you, I can give this a go in next version.

Thanks,
srini



Thanks,
Joao

Re: [PATCH net v3] tipc: check minimum bearer MTU

[Ying Xue]

On 12/02/2016 04:33 PM, Michal Kubecek wrote:

Qian Zhang (张谦) reported a potential socket buffer overflow in
tipc_msg_build() which is also known as CVE-2016-8632: due to
insufficient checks, a buffer overflow can occur if MTU is too short for
even tipc headers. As anyone can set device MTU in a user/net namespace,
this issue can be abused by a regular user.

As agreed in the discussion on Ben Hutchings' original patch, we should
check the MTU at the moment a bearer is attached rather than for each
processed packet. We also need to repeat the check when bearer MTU is
adjusted to new device MTU. UDP case also needs a check to avoid
overflow when calculating bearer MTU.

Fixes: b97bf3fd8f6a ("[TIPC] Initial merge")
Signed-off-by: Michal Kubecek 
Reported-by: Qian Zhang (张谦) 
---


Thanks, it looks nice to me.

Acked-by: Ying Xue 

[PATCH 3/3] pinctrl: sx150x: handle missing 'advanced' reg in sx1504 and sx1505

[Peter Rosin]

This fixes a problem where sx150x_regmap_reg_width() returns 8 for the
data register (reg 0) for sx1504 where it should return 4, and return
a correct 8 for sx1505 but for the wrong reason (both chips lack the
'advanced' register). This is not a real problem, since nothing depends
on the function returning 4 or 8, and certainly not if it is returning
8 for the wrong reason. But fix this to avoid nasty surprises down the
line.

Signed-off-by: Peter Rosin 
---
 drivers/pinctrl/pinctrl-sx150x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index 37b8737e61a9..bdb7ea3d9911 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -967,6 +967,7 @@ static int sx150x_regmap_reg_width(struct sx150x_pinctrl 
*pctl,
reg == data->pri.x123.reg_advanced)
   ||
   (data->model == SX150X_456 &&
+   data->pri.x456.reg_advanced &&
reg == data->pri.x456.reg_advanced)) {
return 8;
} else {
-- 
2.1.4

Re: [RESEND PATCH] pinctrl: mt8173: set GPIO16 to usb iddig mode

[Linus Walleij]

On Wed, Nov 30, 2016 at 3:21 AM, Chunfeng Yun  wrote:

> the default mode of GPIO16 pin is gpio, when set EINT16 to
> IRQ_TYPE_LEVEL_HIGH, no interrupt is triggered, it can be
> fixed when set its default mode as usb iddig.
>
> Signed-off-by: Chunfeng Yun 

Patch applied with Hongzhou's ACK!

Yours,
Linus Walleij

Re: [RFC, PATCH, v3.9] default exported asm symbols to zero

[Geert Uytterhoeven]

On Fri, Dec 2, 2016 at 1:40 PM, Arnd Bergmann  wrote:
> With binutils-2.16 and before, a weak missing symbol was kept during the

2.26?

> final link, and a missing CRC for an export would lead to that CRC
> being treated as zero implicitly. With binutils-2.17, the crc

2.27?

> symbol gets dropped, and any module trying to use it will fail to
> load.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 1/3] pinctrl: sx150x: access the correct bits in the 4-bit regs of sx150[147]

[Linus Walleij]

On Fri, Dec 2, 2016 at 11:51 AM, Peter Rosin  wrote:

> The code assumes 8-bit or 16-bit width registers, but three of the
> chips (sx1501/sx1504/sx1507) are 4-bit. So, try to handle 4-bit chips as
> well, they leave the high part of each register unused.
>
> Signed-off-by: Peter Rosin 

Patch applied.

Yours,
Linus Walleij

[PATCH 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Sasikumar Chandrasekaran]

SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap to have 
different
sizes for different number of supported VDs.

This patch is depending on patch 5

Signed-off-by: Sasikumar Chandrasekaran 
---
 drivers/scsi/megaraid/megaraid_sas.h|   7 +
 drivers/scsi/megaraid/megaraid_sas_base.c   |  57 --
 drivers/scsi/megaraid/megaraid_sas_fp.c | 278 +---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 148 ++-
 drivers/scsi/megaraid/megaraid_sas_fusion.h | 177 +-
 5 files changed, 602 insertions(+), 65 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 9263ba3..2da47b9 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1437,6 +1437,12 @@ enum FW_BOOT_CONTEXT {
 #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
 #define MR_MAX_MSIX_REG_ARRAY   16
 #define MR_RDPQ_MODE_OFFSET0X0080
+
+#define MR_MAX_RAID_MAP_SIZE_OFFSET_SHIFT  16
+#define MR_MAX_RAID_MAP_SIZE_MASK  0x1FF
+#define MR_MIN_MAP_SIZE0x1
+/* 64k */
+
 #define MR_CAN_HANDLE_SYNC_CACHE_OFFSET0X0100
 
 /*
@@ -2155,6 +2161,7 @@ struct megasas_instance {
bool fw_sync_cache_support;
bool is_ventura;
bool msix_combined;
+   u16 maxRaidMapSize;
 };
 struct MR_LD_VF_MAP {
u32 size;
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 86f25d5..b74609c 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4427,8 +4427,7 @@ int megasas_alloc_cmds(struct megasas_instance *instance)
 static void megasas_update_ext_vd_details(struct megasas_instance *instance)
 {
struct fusion_context *fusion;
-   u32 old_map_sz;
-   u32 new_map_sz;
+   u32 ventura_map_sz = 0;
 
fusion = instance->ctrl_context;
/* For MFI based controllers return dummy success */
@@ -4458,21 +4457,37 @@ static void megasas_update_ext_vd_details(struct 
megasas_instance *instance)
instance->supportmax256vd ? "Extended VD(240 VD)firmware" :
"Legacy(64 VD) firmware");
 
-   old_map_sz = sizeof(struct MR_FW_RAID_MAP) +
-   (sizeof(struct MR_LD_SPAN_MAP) *
-   (instance->fw_supported_vd_count - 1));
-   new_map_sz = sizeof(struct MR_FW_RAID_MAP_EXT);
-   fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP) +
-   (sizeof(struct MR_LD_SPAN_MAP) *
-   (instance->drv_supported_vd_count - 1));
-
-   fusion->max_map_sz = max(old_map_sz, new_map_sz);
+   if (instance->maxRaidMapSize) {
+   ventura_map_sz = instance->maxRaidMapSize *
+   MR_MIN_MAP_SIZE; /* 64k */
+   fusion->current_map_sz = ventura_map_sz;
+   fusion->max_map_sz = ventura_map_sz;
+   } else {
+   fusion->old_map_sz =  sizeof(struct MR_FW_RAID_MAP) +
+   (sizeof(struct MR_LD_SPAN_MAP) *
+   (instance->fw_supported_vd_count - 1));
+   fusion->new_map_sz =  sizeof(struct MR_FW_RAID_MAP_EXT);
 
+   fusion->max_map_sz = max(fusion->old_map_sz, 
fusion->new_map_sz);
 
-   if (instance->supportmax256vd)
-   fusion->current_map_sz = new_map_sz;
-   else
-   fusion->current_map_sz = old_map_sz;
+   if (instance->supportmax256vd)
+   fusion->current_map_sz = fusion->new_map_sz;
+   else
+   fusion->current_map_sz = fusion->old_map_sz;
+   }
+   /* irrespective of FW raid maps, driver raid map is constant */
+   fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP_ALL);
+#if VD_EXT_DEBUG
+   dev_info(>pdev->dev, "instance->maxRaidMapSize 0x%x \n ",
+   instance->maxRaidMapSize);
+   dev_info(>pdev->dev,
+   "new_map_sz = 0x%x, old_map_sz = 0x%x, "
+   "ventura_map_sz = 0x%x, current_map_sz = 0x%x "
+   "fusion->drv_map_sz =0x%x, size of driver raid 
map 0x%lx\n",
+   fusion->new_map_sz, fusion->old_map_sz,
+   ventura_map_sz, fusion->current_map_sz,
+   fusion->drv_map_sz, sizeof(struct 
MR_DRV_RAID_MAP_ALL));
+#endif
 }
 
 /**
@@ -5013,7 +5028,7 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
 {
u32 max_sectors_1;
u32 max_sectors_2;
-   u32 tmp_sectors, msix_enable, scratch_pad_2;
+   u32 tmp_sectors, msix_enable, scratch_pad_2, scratch_pad_3;
resource_size_t 

[PATCH 07/11] megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers Capabilities

[Sasikumar Chandrasekaran]

The Megaraid driver has to support the SAS3.5 Generic Megaraid Controllers 
Firmware functionality.

This patch is depending on patch 6

Signed-off-by: Sasikumar Chandrasekaran 
---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 53 ++---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 18 +-
 drivers/scsi/megaraid/megaraid_sas_fusion.h |  1 +
 3 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index b74609c..cfd379a 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5058,34 +5058,29 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
 
reg_set = instance->reg_set;
 
-   switch (instance->pdev->device) {
-   case PCI_DEVICE_ID_LSI_FUSION:
-   case PCI_DEVICE_ID_LSI_PLASMA:
-   case PCI_DEVICE_ID_LSI_INVADER:
-   case PCI_DEVICE_ID_LSI_FURY:
-   case PCI_DEVICE_ID_LSI_INTRUDER:
-   case PCI_DEVICE_ID_LSI_INTRUDER_24:
-   case PCI_DEVICE_ID_LSI_CUTLASS_52:
-   case PCI_DEVICE_ID_LSI_CUTLASS_53:
+   if (fusion)
instance->instancet = _instance_template_fusion;
-   break;
-   case PCI_DEVICE_ID_LSI_SAS1078R:
-   case PCI_DEVICE_ID_LSI_SAS1078DE:
-   instance->instancet = _instance_template_ppc;
-   break;
-   case PCI_DEVICE_ID_LSI_SAS1078GEN2:
-   case PCI_DEVICE_ID_LSI_SAS0079GEN2:
-   instance->instancet = _instance_template_gen2;
-   break;
-   case PCI_DEVICE_ID_LSI_SAS0073SKINNY:
-   case PCI_DEVICE_ID_LSI_SAS0071SKINNY:
-   instance->instancet = _instance_template_skinny;
-   break;
-   case PCI_DEVICE_ID_LSI_SAS1064R:
-   case PCI_DEVICE_ID_DELL_PERC5:
-   default:
-   instance->instancet = _instance_template_xscale;
-   break;
+   else {
+   switch (instance->pdev->device) {
+   case PCI_DEVICE_ID_LSI_SAS1078R:
+   case PCI_DEVICE_ID_LSI_SAS1078DE:
+   instance->instancet = _instance_template_ppc;
+   break;
+   case PCI_DEVICE_ID_LSI_SAS1078GEN2:
+   case PCI_DEVICE_ID_LSI_SAS0079GEN2:
+   instance->instancet = _instance_template_gen2;
+   break;
+   case PCI_DEVICE_ID_LSI_SAS0073SKINNY:
+   case PCI_DEVICE_ID_LSI_SAS0071SKINNY:
+   instance->instancet = _instance_template_skinny;
+   break;
+   case PCI_DEVICE_ID_LSI_SAS1064R:
+   case PCI_DEVICE_ID_DELL_PERC5:
+   default:
+   instance->instancet = _instance_template_xscale;
+   instance->pd_list_not_supported = 1;
+   break;
+   }
}
 
if (megasas_transition_to_ready(instance, 0)) {
@@ -5827,7 +5822,9 @@ static int megasas_probe_one(struct pci_dev *pdev,
if ((instance->pdev->device == PCI_DEVICE_ID_LSI_FUSION) ||
(instance->pdev->device == PCI_DEVICE_ID_LSI_PLASMA))
fusion->adapter_type = THUNDERBOLT_SERIES;
-   else if (!instance->is_ventura)
+   else if (instance->is_ventura)
+   fusion->adapter_type = VENTURA_SERIES;
+   else
fusion->adapter_type = INVADER_SERIES;
}
break;
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index e0b188d..331cacd 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -244,7 +244,9 @@ inline void megasas_return_cmd_fusion(struct 
megasas_instance *instance,
 
reg_set = instance->reg_set;
 
-   cur_max_fw_cmds = readl(>reg_set->outbound_scratch_pad_3) & 
0x00;
+   /* ventura FW does not fill outbound_scratch_pad_3 with queue depth */
+   if (!instance->is_ventura)
+   cur_max_fw_cmds = 
readl(>reg_set->outbound_scratch_pad_3) & 0x00;
 
if (dual_qdepth_disable || !cur_max_fw_cmds)
cur_max_fw_cmds = 
instance->instancet->read_fw_status_reg(reg_set) & 0x00;
@@ -842,7 +844,7 @@ static int megasas_create_sg_sense_fusion(struct 
megasas_instance *instance)
drv_ops = (MFI_CAPABILITIES *) &(init_frame->driver_operations);
 
/* driver support Extended MSIX */
-   if (fusion->adapter_type == INVADER_SERIES)
+   if (fusion->adapter_type >= INVADER_SERIES)
drv_ops->mfi_capabilities.support_additional_msix = 1;
/* driver supports HA / Remote LUN over Fast Path interface */
drv_ops->mfi_capabilities.support_fp_remote_lun = 1;
@@ -1496,7 +1498,7 @@ static int 

[PATCH 03/11] megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid Controllers

[Sasikumar Chandrasekaran]

An UNMAP command on a PI formatted device will leave the Logical Block 
Application
Tag and Logical Block Reference Tag as all F's (for those LBAs that are 
unmapped).
To avoid IO errors if those LBAs are subsequently read before they are written 
with
valid tag fields, the MPI SCSI IO requests need to set the EEDPFlags element 
EEDP
Escape Mode field, Bits [7:6] appropriately.  A value of 2 should be set to 
disable
all PI checks if the Logical Block Application Tag is 0x for PI types 1 and 
2.
A value of 3 should be set to disable all PI checks if the Logical Block 
Application
Tag is 0x and the Logical Block Reference Tag is 0x for PI type 3.

This patch is depending on patch 2

Signed-off-by: Sasikumar Chandrasekaran 
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 +
 drivers/scsi/megaraid/megaraid_sas_fusion.h | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 9de9e66..7f26b14 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -1589,6 +1589,7 @@ static int megasas_create_sg_sense_fusion(struct 
megasas_instance *instance)
MPI2_SCSIIO_EEDPFLAGS_CHECK_REFTAG |
MPI2_SCSIIO_EEDPFLAGS_CHECK_REMOVE_OP |
MPI2_SCSIIO_EEDPFLAGS_CHECK_APPTAG |
+   MPI25_SCSIIO_EEDPFLAGS_DO_NOT_DISABLE_MODE |
MPI2_SCSIIO_EEDPFLAGS_CHECK_GUARD);
} else {
io_request->EEDPFlags = cpu_to_le16(
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.h 
b/drivers/scsi/megaraid/megaraid_sas_fusion.h
index e3bee04..9d22ade 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.h
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.h
@@ -175,6 +175,8 @@ enum REGION_TYPE {
 #define MPI2_SCSIIO_EEDPFLAGS_CHECK_APPTAG  (0x0200)
 #define MPI2_SCSIIO_EEDPFLAGS_CHECK_GUARD   (0x0100)
 #define MPI2_SCSIIO_EEDPFLAGS_INSERT_OP (0x0004)
+/* EEDP escape mode */
+#define MPI25_SCSIIO_EEDPFLAGS_DO_NOT_DISABLE_MODE  (0x0040)
 #define MPI2_FUNCTION_SCSI_IO_REQUEST   (0x00) /* SCSI IO */
 #define MPI2_FUNCTION_SCSI_TASK_MGMT(0x01)
 #define MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY   (0x03)
-- 
1.8.3.1

Re: [PATCH v2 0/7] Tests for sync infrastructure

[Shuah Khan]

On 12/01/2016 06:17 PM, Shuah Khan wrote:
> On 10/19/2016 06:49 AM, Emilio López wrote:
>> Hello everyone,
>>
>> This is a series of tests to exercise the sync kernel infrastructure. It is
>> meant to be a test suite for the work Gustavo has been doing to destage it.
>>
>> These tests were originally part of a battery of tests shipping with
>> Android's libsync that were rewritten to use the new userspace interfaces.
>>
>> This is the second iteration of the test suite. Main changes over v1 are
>> a reworked Makefile and small code style fixes.
>>
>> If you are testing this on v4.9-rc1, do note that the last test will
>> currently fail due to a regression[0].
> 
> Hi Emilio,
> 
> Thanks. I will apply these to linux-kselftest next for 4.10-rc1
> 
> -- Shuah
>>
>> As usual, all comments are welcome.
>>

Hi Emilio,

Applied to linux-kselftest next. Could you take a look at the output
and see if it can be refined. Does [BAD] mean the test failed? Results
could refined to help user understand if a test failed or not clearly.
This can be done in a separate patch as a fix in one of the 4.01-rcs

thanks,
-- Shuah

[PATCH 10/11] megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid Controllers

[Sasikumar Chandrasekaran]

Update Linux driver to use new pdTargetId field for JBOD target ID

This patch is depending on patch 9

Signed-off-by: Sasikumar Chandrasekaran 
---
 drivers/scsi/megaraid/megaraid_sas.h| 106 +---
 drivers/scsi/megaraid/megaraid_sas_base.c   |   5 +-
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  11 ++-
 drivers/scsi/megaraid/megaraid_sas_fusion.h |   3 +-
 4 files changed, 94 insertions(+), 31 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 40b8295..e4bb93d 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1320,7 +1320,56 @@ struct megasas_ctrl_info {
 #endif
} adapterOperations3;
 
-   u8  pad[0x800-0x7EC];
+   struct {
+#if defined(__BIG_ENDIAN_BITFIELD)
+   u8 reserved:7;
+   /* Indicates whether the CPLD image is part of
+   *  the package and stored in flash   
+   */
+   u8 cpldInFlash:1;
+#else
+   u8 cpldInFlash:1;
+   u8 reserved:7;
+#endif
+   u8 reserved1[3];
+   /* Null terminated string. Has the version
+   *  information if cpldInFlash = FALSE 
+   */
+   u8 userCodeDefinition[12];
+   } cpld;  /* Valid only if upgradableCPLD is TRUE */
+
+   struct {
+   #if defined(__BIG_ENDIAN_BITFIELD)
+   u16 reserved:8;
+   u16 FWSwapsBBUVPDInfo   :1;
+   u16 supportPdMapTargetId:1;
+   u16 supportSESCtrlInMultipathCfg:1;
+   u16 imageUploadSupported:1;
+   u16 supportEncryptedMfc :1;
+   u16 supportedEncAlgo:1;
+   u16 supportIbuttonLess  :1;
+   u16 ctrlInfoExtSupported:1;
+   #else
+
+   u16 ctrlInfoExtSupported:1;
+   u16 supportIbuttonLess  :1;
+   u16 supportedEncAlgo:1;
+   u16 supportEncryptedMfc :1;
+   u16 imageUploadSupported:1;
+   /* FW supports LUN based association and target port based */
+   u16 supportSESCtrlInMultipathCfg:1;
+   /* association for the SES device connected in multipath mode */
+/* FW defines Jbod target Id within MR_PD_CFG_SEQ */
+   u16 supportPdMapTargetId:1;
+   /* FW swaps relevant fields in MR_BBU_VPD_INFO_FIXED to
+   *  provide the data in little endian order 
+   */
+   u16 FWSwapsBBUVPDInfo   :1;
+   u16 reserved:8;
+   #endif
+   } adapterOperations4;
+
+u8  pad[0x800-0x7FE];  /* 0x7FE pad to 2K for 
expansion */
 } __packed;
 
 /*
@@ -1560,33 +1609,35 @@ struct megasas_header {
 typedef union _MFI_CAPABILITIES {
struct {
 #if   defined(__BIG_ENDIAN_BITFIELD)
-   u32 reserved:20;
-   u32 support_qd_throttling:1;
-   u32 support_fp_rlbypass:1;
-   u32 support_vfid_in_ioframe:1;
-   u32 support_ext_io_size:1;
-   u32 support_ext_queue_depth:1;
-   u32 security_protocol_cmds_fw:1;
-   u32 support_core_affinity:1;
-   u32 support_ndrive_r1_lb:1;
-   u32 support_max_255lds:1;
-   u32 support_fastpath_wb:1;
-   u32 support_additional_msix:1;
-   u32 support_fp_remote_lun:1;
+   u32 reserved:19;
+   u32 supportPdMapTargetId:1;
+   u32 support_qd_throttling:1;
+   u32 support_fp_rlbypass:1;
+   u32 support_vfid_in_ioframe:1;
+   u32 support_ext_io_size:1;
+   u32 support_ext_queue_depth:1;
+   u32 security_protocol_cmds_fw:1;
+   u32 support_core_affinity:1;
+   u32 support_ndrive_r1_lb:1;
+   u32 support_max_255lds:1;
+   u32 support_fastpath_wb:1;
+   u32 support_additional_msix:1;
+   u32 support_fp_remote_lun:1;
 #else
-   u32 support_fp_remote_lun:1;
-   u32 support_additional_msix:1;
-   u32 support_fastpath_wb:1;
-   u32 support_max_255lds:1;
-   u32 support_ndrive_r1_lb:1;
-   u32 support_core_affinity:1;
-   u32 security_protocol_cmds_fw:1;
-   u32 support_ext_queue_depth:1;
-   u32 support_ext_io_size:1;
-   u32 support_vfid_in_ioframe:1;
-   u32 support_fp_rlbypass:1;
-   u32 support_qd_throttling:1;
-   u32 reserved:20;
+   u32 support_fp_remote_lun:1;
+   u32 support_additional_msix:1;
+   u32 support_fastpath_wb:1;
+   u32 support_max_255lds:1;
+   u32 support_ndrive_r1_lb:1;
+   u32 

[PATCH 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Sasikumar Chandrasekaran]

Large SEQ IO workload should sent as non fast path commands

This patch is depending on patch 7

Signed-off-by: Sasikumar Chandrasekaran 
---
 drivers/scsi/megaraid/megaraid_sas.h|  8 +
 drivers/scsi/megaraid/megaraid_sas_base.c   | 49 +
 drivers/scsi/megaraid/megaraid_sas_fp.c | 21 -
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
 drivers/scsi/megaraid/megaraid_sas_fusion.h |  5 +--
 5 files changed, 86 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 2da47b9..40b8295 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1432,6 +1432,8 @@ enum FW_BOOT_CONTEXT {
 #define MFI_1068_FW_HANDSHAKE_OFFSET   0x64
 #define MFI_1068_FW_READY  0x
 
+#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
+
 #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
 #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
 #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
@@ -2104,6 +2106,10 @@ struct megasas_instance {
atomic_t ldio_outstanding;
atomic_t fw_reset_no_pci_access;
 
+   atomic64_t bytes_wrote; /* used for raid1 fast path enable or disable */
+   atomic_t r1_write_fp_capable;
+
+
struct megasas_instance_template *instancet;
struct tasklet_struct isr_tasklet;
struct work_struct work_init;
@@ -2146,6 +2152,7 @@ struct megasas_instance {
long reset_flags;
struct mutex reset_mutex;
struct timer_list sriov_heartbeat_timer;
+   struct timer_list r1_fp_hold_timer;
char skip_heartbeat_timer_del;
u8 requestorId;
char PlasmaFW111;
@@ -2162,6 +2169,7 @@ struct megasas_instance {
bool is_ventura;
bool msix_combined;
u16 maxRaidMapSize;
+   u64  pci_threshold_bandwidth; /* used to control the fp writes */
 };
 struct MR_LD_VF_MAP {
u32 size;
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index cfd379a..be11e9d 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1943,6 +1943,9 @@ void megaraid_sas_kill_hba(struct megasas_instance 
*instance)
}
/* Complete outstanding ioctls when adapter is killed */
megasas_complete_outstanding_ioctls(instance);
+   if (instance->is_ventura)
+   del_timer_sync(>r1_fp_hold_timer);
+
 }
 
  /**
@@ -2441,6 +2444,24 @@ void megasas_sriov_heartbeat_handler(unsigned long 
instance_addr)
}
 }
 
+/*Handler for disabling/enabling raid 1 fast paths*/
+void megasas_change_r1_fp_status(unsigned long instance_addr)
+{
+   struct megasas_instance *instance =
+   (struct megasas_instance *)instance_addr;
+   if (atomic64_read(>bytes_wrote) >=
+   instance->pci_threshold_bandwidth) {
+
+   atomic64_set(>bytes_wrote, 0);
+   atomic_set(>r1_write_fp_capable, 0);
+   } else {
+   atomic64_set(>bytes_wrote, 0);
+   atomic_set(>r1_write_fp_capable, 1);
+   }
+   mod_timer(>r1_fp_hold_timer,
+   jiffies + 
MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
+}
+
 /**
  * megasas_wait_for_outstanding -  Wait for all outstanding cmds
  * @instance:  Adapter soft state
@@ -5367,6 +5388,18 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
instance->skip_heartbeat_timer_del = 1;
}
 
+   if (instance->is_ventura) {
+   atomic64_set(>bytes_wrote, 0);
+   atomic_set(>r1_write_fp_capable, 1);
+   megasas_start_timer(instance,
+   >r1_fp_hold_timer,
+   megasas_change_r1_fp_status,
+   MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
+   dev_info(>pdev->dev, "starting the raid 1 fp timer"
+   " with interval %d \n",
+   MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
+   }
+
return 0;
 
 fail_get_ld_pd_list:
@@ -6160,6 +6193,9 @@ static void megasas_shutdown_controller(struct 
megasas_instance *instance,
if (instance->requestorId && !instance->skip_heartbeat_timer_del)
del_timer_sync(>sriov_heartbeat_timer);
 
+   if (instance->is_ventura)
+   del_timer_sync(>r1_fp_hold_timer);
+
megasas_flush_cache(instance);
megasas_shutdown_controller(instance, MR_DCMD_HIBERNATE_SHUTDOWN);
 
@@ -6279,6 +6315,16 @@ static void megasas_shutdown_controller(struct 
megasas_instance *instance,
megasas_setup_jbod_map(instance);
instance->unload = 0;
 
+   if (instance->is_ventura) {
+   atomic64_set(>bytes_wrote, 0);
+   

Re: [PATCH v3 3/7] PWM: add pwm-stm32 DT bindings

[Lee Jones]

On Fri, 02 Dec 2016, Benjamin Gaignard wrote:

> Define bindings for pwm-stm32
> 
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>  .../devicetree/bindings/pwm/pwm-stm32.txt  | 38 
> ++
>  1 file changed, 38 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> 
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt 
> b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> new file mode 100644
> index 000..575b9fb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> @@ -0,0 +1,38 @@
> +STMicroelectronics PWM driver bindings for STM32
> +
> +Must be a sub-node of STM32 general purpose timer driver
> +Parent node properties are describe in ../mfd/stm32-general-purpose-timer.txt
> +
> +Required parameters:
> +- compatible:Must be "st,stm32-pwm"
> +- pinctrl-names: Set to "default".
> +- pinctrl-0: List of phandles pointing to pin configuration 
> nodes
> + for PWM module.
> + For Pinctrl properties, please refer to [1].
> +
> +Optional parameters:
> +- st,breakinput: Set if the hardware have break input capabilities
> +- st,breakinput-polarity: Set break input polarity. Default is 0
> +  The value define the active polarity:
> +   - 0 (active LOW)
> +   - 1 (active HIGH)

> +- st,breakinput-polarity-high

Then assume the default if the property is not present.

> +- st,pwm-num-chan:   Number of available PWM channels.  Default is 0.

What's the point in having a PWM device with  no channels?

Best to make this a compulsory property.

> +- st,32bits-counter: Set if the hardware have a 32 bits counter
> +- st,complementary:  Set if the hardware have complementary output channels
> +
> +[1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt

Use relative path.

../pinctrl/pinctrl-bindings.txt

> +Example:
> + gptimer1: gptimer1@4001 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x4001 0x400>;
> + clocks = < 0 160>;
> + clock-names = "clk_int";
> +
> + pwm1@0 {

Don't number the node name.

pwm@xx

> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,breakinput;
> + st,complementary;
> + };
> + };

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[tip:locking/core] locking/rtmutex: Explain locking rules for rt_mutex_proxy_unlock()/init_proxy_locked()

[tip-bot for Thomas Gleixner]

Commit-ID:  84d82ec5b9046ecdf16031d3e93a66ef50257402
Gitweb: http://git.kernel.org/tip/84d82ec5b9046ecdf16031d3e93a66ef50257402
Author: Thomas Gleixner 
AuthorDate: Wed, 30 Nov 2016 21:04:45 +
Committer:  Ingo Molnar 
CommitDate: Fri, 2 Dec 2016 11:13:57 +0100

locking/rtmutex: Explain locking rules for 
rt_mutex_proxy_unlock()/init_proxy_locked()

While debugging the unlock vs. dequeue race which resulted in state
corruption of futexes the lockless nature of rt_mutex_proxy_unlock()
caused some confusion.

Add commentry to explain why it is safe to do this lockless. Add matching
comments to rt_mutex_init_proxy_locked() for completeness sake.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: David Daney 
Cc: Linus Torvalds 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Sebastian Siewior 
Cc: Steven Rostedt 
Cc: Will Deacon 
Link: http://lkml.kernel.org/r/20161130210030.591941...@linutronix.de
Signed-off-by: Ingo Molnar 
---
 kernel/locking/rtmutex.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 6e6cab7..2f443ed 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1619,11 +1619,15 @@ EXPORT_SYMBOL_GPL(__rt_mutex_init);
  * rt_mutex_init_proxy_locked - initialize and lock a rt_mutex on behalf of a
  * proxy owner
  *
- * @lock:  the rt_mutex to be locked
+ * @lock:  the rt_mutex to be locked
  * @proxy_owner:the task to set as owner
  *
  * No locking. Caller has to do serializing itself
- * Special API call for PI-futex support
+ *
+ * Special API call for PI-futex support. This initializes the rtmutex and
+ * assigns it to @proxy_owner. Concurrent operations on the rtmutex are not
+ * possible at this point because the pi_state which contains the rtmutex
+ * is not yet visible to other tasks.
  */
 void rt_mutex_init_proxy_locked(struct rt_mutex *lock,
struct task_struct *proxy_owner)
@@ -1637,10 +1641,14 @@ void rt_mutex_init_proxy_locked(struct rt_mutex *lock,
 /**
  * rt_mutex_proxy_unlock - release a lock on behalf of owner
  *
- * @lock:  the rt_mutex to be locked
+ * @lock:  the rt_mutex to be locked
  *
  * No locking. Caller has to do serializing itself
- * Special API call for PI-futex support
+ *
+ * Special API call for PI-futex support. This merrily cleans up the rtmutex
+ * (debugging) state. Concurrent operations on this rt_mutex are not
+ * possible because it belongs to the pi_state which is about to be freed
+ * and it is not longer visible to other tasks.
  */
 void rt_mutex_proxy_unlock(struct rt_mutex *lock,
   struct task_struct *proxy_owner)

[PATCH 0/2] High-order per-cpu cache v6

[Mel Gorman]

Changelog since v5
o Changelog clarification in patch 1
o Additional comments in patch 2

Changelog since v4
o Avoid pcp->count getting out of sync if struct page gets corrupted

Changelog since v3
o Allow high-order atomic allocations to use reserves

Changelog since v2
o Correct initialisation to avoid -Woverflow warning

The following is two patches that implement a per-cpu cache for high-order
allocations, primarily aimed at SLUB. The first patch is a bug fix that
is technically unrelated but was discovered by review and so batched
together. The second is the patch that implements the high-order pcpu cache.

 include/linux/mmzone.h |  20 +++-
 mm/page_alloc.c| 129 -
 2 files changed, 103 insertions(+), 46 deletions(-)

-- 
2.10.2

[PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted

[Mel Gorman]

Vlastimil Babka pointed out that commit 479f854a207c ("mm, page_alloc:
defer debugging checks of pages allocated from the PCP") will allow the
per-cpu list counter to be out of sync with the per-cpu list contents
if a struct page is corrupted.

The consequence is an infinite loop if the per-cpu lists get fully drained
by free_pcppages_bulk because all the lists are empty but the count is
positive. The infinite loop occurs here

do {
batch_free++;
if (++migratetype == MIGRATE_PCPTYPES)
migratetype = 0;
list = >lists[migratetype];
} while (list_empty(list));

>From a user perspective, it's a bad page warning followed by a soft lockup
with interrupts disabled in free_pcppages_bulk().

This patch keeps the accounting in sync.

Fixes: 479f854a207c ("mm, page_alloc: defer debugging checks of pages allocated 
from the PCP")
Signed-off-by: Mel Gorman 
cc: sta...@vger.kernel.org [4.7+]
---
 mm/page_alloc.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6de9440e3ae2..34ada718ef47 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2192,7 +2192,7 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
order,
unsigned long count, struct list_head *list,
int migratetype, bool cold)
 {
-   int i;
+   int i, alloced = 0;
 
spin_lock(>lock);
for (i = 0; i < count; ++i) {
@@ -2217,13 +2217,21 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
order,
else
list_add_tail(>lru, list);
list = >lru;
+   alloced++;
if (is_migrate_cma(get_pcppage_migratetype(page)))
__mod_zone_page_state(zone, NR_FREE_CMA_PAGES,
  -(1 << order));
}
+
+   /*
+* i pages were removed from the buddy list even if some leak due
+* to check_pcp_refill failing so adjust NR_FREE_PAGES based
+* on i. Do not confuse with 'alloced' which is the number of
+* pages added to the pcp list.
+*/
__mod_zone_page_state(zone, NR_FREE_PAGES, -(i << order));
spin_unlock(>lock);
-   return i;
+   return alloced;
 }
 
 #ifdef CONFIG_NUMA
-- 
2.10.2

Re: [PATCH v2] ACPI / APEI: Fix NMI notification handling

[Fu Wei]

Hi Rafael,

On 2 December 2016 at 07:12, Rafael J. Wysocki  wrote:
> On Thursday, December 01, 2016 11:47:17 PM Borislav Petkov wrote:
>> On Thu, Dec 01, 2016 at 11:29:45PM +0100, Rafael J. Wysocki wrote:
>> > Well, there's another ARM-related patch touching APEI.
>> >
>> > I guess whoever takes this one should also take the other one and
>> > honestly they can go in via any tree as far as I'm concerned, I'm just 
>> > trying to
>> > avoid merge clashes here. :-)
>>
>> Maybe have ARM-folk ACK the other one and take both through your ACPI
>> tree? They both do have ACPI in common :-)
>
> That one have been ACKed already.

I guess that is "[PATCH v15] acpi, apei, arm64: APEI initial support
for aarch64."

>
> OK, I'll take them both.

Great thanks, Rafael :-)

>
> Thanks,
> Rafael
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH 1/2] Add crypto driver support for some MediaTek chips

[mtk09577]

Hello,

On Fri, 2016-12-02 at 09:18 +0100, Corentin Labbe wrote:
> Hello
> 
> I have some minor comment inline
> 
> On Fri, Dec 02, 2016 at 11:26:44AM +0800, Ryder Lee wrote:
> > This adds support for the MediaTek hardware accelerator on
> > mt7623/mt2701/mt8521p SoC.
> > 
> > This driver currently implement:
> > - SHA1 and SHA2 family(HMAC) hash alogrithms.
> > - AES block cipher in CBC/ECB mode with 128/196/256 bits keys.
> 
> I see also a PRNG but is seems not really used.

Yes, PRNG is not implemented yet, i will remove it temporarily.

> > 
> > Signed-off-by: Ryder Lee 
> > ---
> >  drivers/crypto/Kconfig |   17 +
> >  drivers/crypto/Makefile|1 +
> >  drivers/crypto/mediatek/Makefile   |2 +
> >  drivers/crypto/mediatek/mtk-aes.c  |  734 +
> >  drivers/crypto/mediatek/mtk-platform.c |  575 +
> >  drivers/crypto/mediatek/mtk-platform.h |  230 ++
> >  drivers/crypto/mediatek/mtk-regs.h |  194 +
> >  drivers/crypto/mediatek/mtk-sha.c  | 1384 
> > 
> >  8 files changed, 3137 insertions(+)
> >  create mode 100644 drivers/crypto/mediatek/Makefile
> >  create mode 100644 drivers/crypto/mediatek/mtk-aes.c
> >  create mode 100644 drivers/crypto/mediatek/mtk-platform.c
> >  create mode 100644 drivers/crypto/mediatek/mtk-platform.h
> >  create mode 100644 drivers/crypto/mediatek/mtk-regs.h
> >  create mode 100644 drivers/crypto/mediatek/mtk-sha.c
> > 
> > diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> > index 4d2b81f..5d9c803 100644
> > --- a/drivers/crypto/Kconfig
> > +++ b/drivers/crypto/Kconfig
> > @@ -553,6 +553,23 @@ config CRYPTO_DEV_ROCKCHIP
> >   This driver interfaces with the hardware crypto accelerator.
> >   Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
> >  
> > +config CRYPTO_DEV_MEDIATEK
> > +   tristate "MediaTek's Cryptographic Engine driver"
> > +   depends on ARM && ARCH_MEDIATEK
> > +   select NEON
> > +   select KERNEL_MODE_NEON
> > +   select ARM_CRYPTO
> > +   select CRYPTO_AES
> > +   select CRYPTO_BLKCIPHER
> > +   select CRYPTO_SHA1_ARM_NEON
> > +   select CRYPTO_SHA256_ARM
> > +   select CRYPTO_SHA512_ARM
> > +   select CRYPTO_HMAC
> 
> Why do you select accelerated algos ?
> Adding COMPILE_TEST could be helpfull also.

Our Hardware has complex procedure on calculate HMAC, and it get a bad
performance So i decide to use ARM NEON instruction as fallback to
speedup it.
I will add COMPILE_TEST.

> [...]
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "mtk-platform.h"
> > +#include "mtk-regs.h"
> > +
> 
> Sort headers in alphabetical order
> 
> [...]
> > +
> > +   mtk_aes_unregister_algs();
> > +   mtk_aes_record_free(cryp);
> > +}
> > +EXPORT_SYMBOL(mtk_cipher_alg_release);
> 
> Why not EXPORT_SYMBOL_GPL ?
> Furthermore do you really need it to be exported ?

My mistake. I will remove it.

> [...]
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "mtk-platform.h"
> > +#include "mtk-regs.h"
> > +
> 
> Sort headers in alphabetical order
> 
> [...]
> > +
> > +static void mtk_prng_reseed(struct mtk_cryp *cryp)
> > +{
> > +   /* 8 words to seed the PRNG to provide IVs */
> > +   void __iomem *base = cryp->base;
> > +   const u32 prng_key[8] = {0x48c24cfd, 0x6c07f742,
> > +   0xaee75681, 0x0f27c239,
> > +   0x79947198, 0xe2991275,
> > +   0x21ac3c7c, 0xd008c4b4};
> 
> Why do you seed with thoses constant ?
> 
> [...]
> > +
> > +static int mtk_accelerator_init(struct mtk_cryp *cryp)
> > +{
> > +   int i, err;
> > +
> > +   /* Initialize advanced interrupt controller(AIC) */
> > +   for (i = 0; i < 5; i++) {
> 
> I see this 5 for interrupt away, so perhaps a define could be used
> 
> [...]
> 
> here 
> 
> > +   for (i = 0; i < 5; i++) {
> > +   cryp->irq[i] = platform_get_irq(pdev, i);
> > +   if (cryp->irq[i] < 0) {
> > +   dev_err(cryp->dev, "no IRQ:%d resource info\n", i);
> > +   return -ENXIO;
> > +   }
> > +   }
> [...]

> > +#ifndef __MTK_PLATFORM_H_
> > +#define __MTK_PLATFORM_H_
> > +
> > +#include 
> > +#include 
> > +#include 
> 
> Sort headers in alphabetical order
> 
> [...]
> > +#define MTK_DESC_FIRST BIT(23)
> > +#define MTK_DESC_BUF_LEN(x)((x) & 0x1)
> > +#define MTK_DESC_CT_LEN(x) (((x) & 0xff) << 24)
> > +
> > +#define WORD(x)((x) >> 2)
> 
> dangerous and ambigous define

I will define a IRQ_NUM and modify ambiguous definition.

> [...]
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> Sort headers in alphabetical order
> [...]
> Generally more function comment could be helpfull.

I will sort all header and add more function comment.

epoll_wait inaccurate timeout

[Dmitry Banschikov]

Hi!

I have a problem caused by inaccurate timeouts in epoll_wait(2).
Here are some parts of strace -tt output:

22578 09:33:46.959791 epoll_wait(5,  
22578 09:33:50.010794 <... epoll_wait resumed> [], 128, 1498) = 0
...
22034 09:35:07.686896 epoll_wait(5,  
22034 09:35:09.482526 <... epoll_wait resumed> [{EPOLLIN,
{u32=151458248, u64=151458248}}], 128, 362) = 1
...
22036 09:35:41.433241 epoll_wait(5,  
22036 09:35:43.176881 <... epoll_wait resumed> [], 128, 97) = 0

In each example epoll_wait is blocked for too longer then asked in timeout.

Is it normal?

Please CC me.



-- 

Dmitry Banschikov