[PATCH v4] page_alloc: consider highatomic reserve in watermark fast

2020-06-18 Thread Jaewon Kim
zone_watermark_fast was introduced by commit 48ee5f3696f6 ("mm,
page_alloc: shortcut watermark checks for order-0 pages"). The commit
simply checks if free pages is bigger than watermark without additional
calculation such like reducing watermark.

It considered free cma pages but it did not consider highatomic
reserved. This may incur exhaustion of free pages except high order
atomic free pages.

Assume that reserved_highatomic pageblock is bigger than watermark min,
and there are only few free pages except high order atomic free. Because
zone_watermark_fast passes the allocation without considering high order
atomic free, normal reclaimable allocation like GFP_HIGHUSER will
consume all the free pages. Then finally order-0 atomic allocation may
fail on allocation.

This means watermark min is not protected against non-atomic allocation.
The order-0 atomic allocation with ALLOC_HARDER unwantedly can be
failed. Additionally the __GFP_MEMALLOC allocation with
ALLOC_NO_WATERMARKS also can be failed.

To avoid the problem, zone_watermark_fast should consider highatomic
reserve. If the actual size of high atomic free is counted accurately
like cma free, we may use it. On this patch just use
nr_reserved_highatomic. Additionally introduce
__zone_watermark_unusable_free to factor out common parts between
zone_watermark_fast and __zone_watermark_ok.

This is an example of ALLOC_HARDER allocation failure using v4.19 based
kernel.

 Binder:9343_3: page allocation failure: order:0, mode:0x480020(GFP_ATOMIC), 
nodemask=(null)
 Call trace:
 [] dump_stack+0xb8/0xf0
 [] warn_alloc+0xd8/0x12c
 [] __alloc_pages_nodemask+0x120c/0x1250
 [] new_slab+0x128/0x604
 [] ___slab_alloc+0x508/0x670
 [] __kmalloc+0x2f8/0x310
 [] context_struct_to_string+0x104/0x1cc
 [] security_sid_to_context_core+0x74/0x144
 [] security_sid_to_context+0x10/0x18
 [] selinux_secid_to_secctx+0x20/0x28
 [] security_secid_to_secctx+0x3c/0x70
 [] binder_transaction+0xe68/0x454c
 Mem-Info:
 active_anon:102061 inactive_anon:81551 isolated_anon:0
  active_file:59102 inactive_file:68924 isolated_file:64
  unevictable:611 dirty:63 writeback:0 unstable:0
  slab_reclaimable:13324 slab_unreclaimable:44354
  mapped:83015 shmem:4858 pagetables:26316 bounce:0
  free:2727 free_pcp:1035 free_cma:178
 Node 0 active_anon:408244kB inactive_anon:326204kB active_file:236408kB 
inactive_file:275696kB unevictable:2444kB isolated(anon):0kB 
isolated(file):256kB mapped:332060kB dirty:252kB writeback:0kB shmem:19432kB 
writeback_tmp:0kB unstable:0kB all_unreclaimable? no
 Normal free:10908kB min:6192kB low:44388kB high:47060kB active_anon:409160kB 
inactive_anon:325924kB active_file:235820kB inactive_file:276628kB 
unevictable:2444kB writepending:252kB present:3076096kB managed:2673676kB 
mlocked:2444kB kernel_stack:62512kB pagetables:105264kB bounce:0kB 
free_pcp:4140kB local_pcp:40kB free_cma:712kB
 lowmem_reserve[]: 0 0
 Normal: 505*4kB (H) 357*8kB (H) 201*16kB (H) 65*32kB (H) 1*64kB (H) 0*128kB 
0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 10236kB
 138826 total pagecache pages
 5460 pages in swap cache
 Swap cache stats: add 8273090, delete 8267506, find 1004381/4060142

This is an example of ALLOC_NO_WATERMARKS allocation failure using v4.14
based kernel.

 kswapd0: page allocation failure: order:0, 
mode:0x14a(GFP_NOIO|__GFP_HIGHMEM|__GFP_MOVABLE), nodemask=(null)
 kswapd0 cpuset=/ mems_allowed=0
 CPU: 4 PID: 1221 Comm: kswapd0 Not tainted 4.14.113-18770262-userdebug #1
 Call trace:
 [<>] dump_backtrace+0x0/0x248
 [<>] show_stack+0x18/0x20
 [<>] __dump_stack+0x20/0x28
 [<>] dump_stack+0x68/0x90
 [<>] warn_alloc+0x104/0x198
 [<>] __alloc_pages_nodemask+0xdc0/0xdf0
 [<>] zs_malloc+0x148/0x3d0
 [<>] zram_bvec_rw+0x410/0x798
 [<>] zram_rw_page+0x88/0xdc
 [<>] bdev_write_page+0x70/0xbc
 [<>] __swap_writepage+0x58/0x37c
 [<>] swap_writepage+0x40/0x4c
 [<>] shrink_page_list+0xc30/0xf48
 [<>] shrink_inactive_list+0x2b0/0x61c
 [<>] shrink_node_memcg+0x23c/0x618
 [<>] shrink_node+0x1c8/0x304
 [<>] kswapd+0x680/0x7c4
 [<>] kthread+0x110/0x120
 [<>] ret_from_fork+0x10/0x18
 Mem-Info:
 active_anon:111826 inactive_anon:65557 isolated_anon:0\x0a active_file:44260 
inactive_file:83422 isolated_file:0\x0a unevictable:4158 dirty:117 writeback:0 
unstable:0\x0aslab_reclaimable:13943 slab_unreclaimable:43315\x0a 
mapped:102511 shmem:3299 pagetables:19566 bounce:0\x0a free:3510 free_pcp:553 
free_cma:0
 Node 0 active_anon:447304kB inactive_anon:262228kB active_file:177040kB 
inactive_file:333688kB unevictable:16632kB isolated(anon):0kB 
isolated(file):0kB mapped:410044kB d irty:468kB writeback:0kB shmem:13196kB 
writeback_tmp:0kB unstable:0kB all_unreclaimable? no
 Normal 

Re: [PATCH] thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power

2020-06-18 Thread Viresh Kumar
On 19-06-20, 09:51, Finley Xiao wrote:
> The function cpu_power_to_freq is used to find a frequency and set the
> cooling device to consume at most the power to be converted. For example,
> if the power to be converted is 80mW, and the em table is as follow.
> struct em_cap_state table[] = {
>   /* KHz mW */
>   { 1008000, 36, 0 },
>   { 120, 49, 0 },
>   { 1296000, 59, 0 },
>   { 1416000, 72, 0 },
>   { 1512000, 86, 0 },
> };
> The target frequency should be 1416000KHz, not 1512000KHz.
> 

Cc: v4.13+  # v4.13+

> Fixes: 349d39dc5739 ("thermal: cpu_cooling: merge frequency and power tables")
> Signed-off-by: Finley Xiao 
> ---
>  drivers/thermal/cpufreq_cooling.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/thermal/cpufreq_cooling.c 
> b/drivers/thermal/cpufreq_cooling.c
> index 9e124020519f..6c0e1b053126 100644
> --- a/drivers/thermal/cpufreq_cooling.c
> +++ b/drivers/thermal/cpufreq_cooling.c
> @@ -123,12 +123,12 @@ static u32 cpu_power_to_freq(struct 
> cpufreq_cooling_device *cpufreq_cdev,
>  {
>   int i;
>  
> - for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) {
> - if (power > cpufreq_cdev->em->table[i].power)
> + for (i = cpufreq_cdev->max_level; i >= 0; i--) {
> + if (power >= cpufreq_cdev->em->table[i].power)
>   break;
>   }
>  
> - return cpufreq_cdev->em->table[i + 1].frequency;
> + return cpufreq_cdev->em->table[i].frequency;
>  }

Acked-by: Viresh Kumar 

-- 
viresh


Re: [PATCH 3/5] f2fs: shrink node_write lock coverage

2020-06-18 Thread Jaegeuk Kim
On 06/18, Chao Yu wrote:
> - to avoid race between checkpoint and quota file writeback, it
> just needs to hold read lock of node_write in writeback path.
> - node_write lock has covered all LFS data write paths, it's not
> necessary, we only need to hold node_write lock at write path of
> quota file.

I've added this:

This refactors commit ca7f76e68074 ("f2fs: fix wrong discard space").

> 
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/compress.c | 18 +++---
>  fs/f2fs/data.c | 12 
>  fs/f2fs/segment.c  | 11 ---
>  3 files changed, 27 insertions(+), 14 deletions(-)
> 
> diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
> index 36b51795b0c3..3ff6c0305ec6 100644
> --- a/fs/f2fs/compress.c
> +++ b/fs/f2fs/compress.c
> @@ -1096,8 +1096,16 @@ static int f2fs_write_compressed_pages(struct 
> compress_ctx *cc,
>   loff_t psize;
>   int i, err;
>  
> - if (!IS_NOQUOTA(inode) && !f2fs_trylock_op(sbi))
> + if (IS_NOQUOTA(inode)) {
> + /*
> +  * We need to wait for node_write to avoid block allocation 
> during
> +  * checkpoint. This can only happen to quota writes which can 
> cause
> +  * the below discard race condition.
> +  */
> + down_read(>node_write);
> + } else if (!f2fs_trylock_op(sbi)) {
>   return -EAGAIN;
> + }
>  
>   set_new_dnode(, cc->inode, NULL, NULL, 0);
>  
> @@ -1203,7 +1211,9 @@ static int f2fs_write_compressed_pages(struct 
> compress_ctx *cc,
>   set_inode_flag(inode, FI_FIRST_BLOCK_WRITTEN);
>  
>   f2fs_put_dnode();
> - if (!IS_NOQUOTA(inode))
> + if (IS_NOQUOTA(inode))
> + up_read(>node_write);
> + else
>   f2fs_unlock_op(sbi);
>  
>   spin_lock(>i_size_lock);
> @@ -1230,7 +1240,9 @@ static int f2fs_write_compressed_pages(struct 
> compress_ctx *cc,
>  out_put_dnode:
>   f2fs_put_dnode();
>  out_unlock_op:
> - if (!IS_NOQUOTA(inode))
> + if (IS_NOQUOTA(inode))
> + up_read(>node_write);
> + else
>   f2fs_unlock_op(sbi);
>   return -EAGAIN;
>  }
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index c78ce08f6400..cbdf062d3562 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -2719,8 +2719,20 @@ int f2fs_write_single_data_page(struct page *page, int 
> *submitted,
>  
>   /* Dentry/quota blocks are controlled by checkpoint */
>   if (S_ISDIR(inode->i_mode) || IS_NOQUOTA(inode)) {
> + /*
> +  * We need to wait for node_write to avoid block allocation 
> during
> +  * checkpoint. This can only happen to quota writes which can 
> cause
> +  * the below discard race condition.
> +  */
> + if (IS_NOQUOTA(inode))
> + down_read(>node_write);
> +
>   fio.need_lock = LOCK_DONE;
>   err = f2fs_do_write_data_page();
> +
> + if (IS_NOQUOTA(inode))
> + up_read(>node_write);
> +
>   goto done;
>   }
>  
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 5b2a6f865a6d..cb861ed98ee3 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -3107,14 +3107,6 @@ void f2fs_allocate_data_block(struct f2fs_sb_info 
> *sbi, struct page *page,
>   type = CURSEG_COLD_DATA;
>   }
>  
> - /*
> -  * We need to wait for node_write to avoid block allocation during
> -  * checkpoint. This can only happen to quota writes which can cause
> -  * the below discard race condition.
> -  */
> - if (IS_DATASEG(type))
> - down_write(>node_write);
> -
>   down_read(_I(sbi)->curseg_lock);
>  
>   mutex_lock(>curseg_mutex);
> @@ -3180,9 +3172,6 @@ void f2fs_allocate_data_block(struct f2fs_sb_info *sbi, 
> struct page *page,
>  
>   up_read(_I(sbi)->curseg_lock);
>  
> - if (IS_DATASEG(type))
> - up_write(>node_write);
> -
>   if (put_pin_sem)
>   up_read(>pin_sem);
>  }
> -- 
> 2.18.0.rc1


Re: [PATCH] ASoC: fsl_spdif: Add pm runtime function

2020-06-18 Thread Nicolin Chen
On Thu, Jun 18, 2020 at 07:55:34PM +0800, Shengjiu Wang wrote:
> Add pm runtime support and move clock handling there.
> Close the clocks at suspend to reduce the power consumption.
> 
> fsl_spdif_suspend is replaced by pm_runtime_force_suspend.
> fsl_spdif_resume is replaced by pm_runtime_force_resume.
> 
> Signed-off-by: Shengjiu Wang 

LGTM, yet some nits, please add my ack after fixing:

Acked-by: Nicolin Chen 

> @@ -495,25 +496,10 @@ static int fsl_spdif_startup(struct snd_pcm_substream 
> *substream,

>  
> -disable_txclk:
> - for (i--; i >= 0; i--)
> - clk_disable_unprepare(spdif_priv->txclk[i]);
>  err:
> - if (!IS_ERR(spdif_priv->spbaclk))
> - clk_disable_unprepare(spdif_priv->spbaclk);
> -err_spbaclk:
> - clk_disable_unprepare(spdif_priv->coreclk);
> -
>   return ret;

Only "return ret;" remains now. We could clean the goto away.

> -static int fsl_spdif_resume(struct device *dev)
> +static int fsl_spdif_runtime_resume(struct device *dev)

> +disable_rx_clk:
> + clk_disable_unprepare(spdif_priv->rxclk);
> +disable_tx_clk:
> +disable_spba_clk:

Why have two duplicated ones? Could probably drop the 2nd one.


Re: [PATCH 1/5] f2fs: fix to wait page writeback before update

2020-06-18 Thread Jaegeuk Kim
On 06/19, Chao Yu wrote:
> Hi Jaegeuk,
> 
> On 2020/6/19 7:59, Jaegeuk Kim wrote:
> > Hi Chao,
> > 
> > On 06/18, Chao Yu wrote:
> >> to make page content stable for special device like raid.
> > 
> > Could you elaborate the problem a bit?
> 
> Some devices like raid5 wants page content to be stable, because
> it will calculate parity info based page content, if page is not
> stable, parity info could be corrupted, result in data inconsistency
> in stripe.

I don't get the point, since those pages are brand new pages which were not
modified before. If it's on writeback, we should not modify them regardless
of whatever raid configuration. For example, f2fs_new_node_page() waits for
writeback. Am I missing something?

> 
> Thanks,
> 
> > 
> >>
> >> Signed-off-by: Chao Yu 
> >> ---
> >>  fs/f2fs/dir.c  |  2 ++
> >>  fs/f2fs/extent_cache.c | 18 +-
> >>  fs/f2fs/f2fs.h |  2 +-
> >>  fs/f2fs/file.c |  1 +
> >>  fs/f2fs/inline.c   |  2 ++
> >>  fs/f2fs/inode.c|  3 +--
> >>  6 files changed, 16 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> >> index d35976785e8c..91e86747a604 100644
> >> --- a/fs/f2fs/dir.c
> >> +++ b/fs/f2fs/dir.c
> >> @@ -495,6 +495,8 @@ static int make_empty_dir(struct inode *inode,
> >>if (IS_ERR(dentry_page))
> >>return PTR_ERR(dentry_page);
> >>  
> >> +  f2fs_bug_on(F2FS_I_SB(inode), PageWriteback(dentry_page));
> >> +
> >>dentry_blk = page_address(dentry_page);
> >>  
> >>make_dentry_ptr_block(NULL, , dentry_blk);
> >> diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
> >> index e60078460ad1..686c68b98610 100644
> >> --- a/fs/f2fs/extent_cache.c
> >> +++ b/fs/f2fs/extent_cache.c
> >> @@ -325,9 +325,10 @@ static void __drop_largest_extent(struct extent_tree 
> >> *et,
> >>  }
> >>  
> >>  /* return true, if inode page is changed */
> >> -static bool __f2fs_init_extent_tree(struct inode *inode, struct 
> >> f2fs_extent *i_ext)
> >> +static void __f2fs_init_extent_tree(struct inode *inode, struct page 
> >> *ipage)
> >>  {
> >>struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
> >> +  struct f2fs_extent *i_ext = ipage ? _INODE(ipage)->i_ext : NULL;
> >>struct extent_tree *et;
> >>struct extent_node *en;
> >>struct extent_info ei;
> >> @@ -335,16 +336,18 @@ static bool __f2fs_init_extent_tree(struct inode 
> >> *inode, struct f2fs_extent *i_e
> >>if (!f2fs_may_extent_tree(inode)) {
> >>/* drop largest extent */
> >>if (i_ext && i_ext->len) {
> >> +  f2fs_wait_on_page_writeback(ipage, NODE, true, true);
> >>i_ext->len = 0;
> >> -  return true;
> >> +  set_page_dirty(ipage);
> >> +  return;
> >>}
> >> -  return false;
> >> +  return;
> >>}
> >>  
> >>et = __grab_extent_tree(inode);
> >>  
> >>if (!i_ext || !i_ext->len)
> >> -  return false;
> >> +  return;
> >>  
> >>get_extent_info(, i_ext);
> >>  
> >> @@ -360,17 +363,14 @@ static bool __f2fs_init_extent_tree(struct inode 
> >> *inode, struct f2fs_extent *i_e
> >>}
> >>  out:
> >>write_unlock(>lock);
> >> -  return false;
> >>  }
> >>  
> >> -bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
> >> +void f2fs_init_extent_tree(struct inode *inode, struct page *ipage)
> >>  {
> >> -  bool ret =  __f2fs_init_extent_tree(inode, i_ext);
> >> +  __f2fs_init_extent_tree(inode, ipage);
> >>  
> >>if (!F2FS_I(inode)->extent_tree)
> >>set_inode_flag(inode, FI_NO_EXTENT);
> >> -
> >> -  return ret;
> >>  }
> >>  
> >>  static bool f2fs_lookup_extent_tree(struct inode *inode, pgoff_t pgofs,
> >> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >> index b35a50f4953c..326c12fa0da5 100644
> >> --- a/fs/f2fs/f2fs.h
> >> +++ b/fs/f2fs/f2fs.h
> >> @@ -3795,7 +3795,7 @@ struct rb_entry *f2fs_lookup_rb_tree_ret(struct 
> >> rb_root_cached *root,
> >>  bool f2fs_check_rb_tree_consistence(struct f2fs_sb_info *sbi,
> >>struct rb_root_cached *root);
> >>  unsigned int f2fs_shrink_extent_tree(struct f2fs_sb_info *sbi, int 
> >> nr_shrink);
> >> -bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent 
> >> *i_ext);
> >> +void f2fs_init_extent_tree(struct inode *inode, struct page *ipage);
> >>  void f2fs_drop_extent_tree(struct inode *inode);
> >>  unsigned int f2fs_destroy_extent_node(struct inode *inode);
> >>  void f2fs_destroy_extent_tree(struct inode *inode);
> >> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> >> index 3268f8dd59bb..1862073b96d2 100644
> >> --- a/fs/f2fs/file.c
> >> +++ b/fs/f2fs/file.c
> >> @@ -1250,6 +1250,7 @@ static int __clone_blkaddrs(struct inode *src_inode, 
> >> struct inode *dst_inode,
> >>f2fs_put_page(psrc, 1);
> >>return PTR_ERR(pdst);
> >>}
> >> +   

KASAN: use-after-free Read in dev_uevent

2020-06-18 Thread syzbot
Hello,

syzbot found the following crash on:

HEAD commit:7ae77150 Merge tag 'powerpc-5.8-1' of git://git.kernel.org..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=169fa04910
kernel config:  https://syzkaller.appspot.com/x/.config?x=be4578b3f1083656
dashboard link: https://syzkaller.appspot.com/bug?extid=348b571beb5eeb70a582
compiler:   clang version 10.0.0 (https://github.com/llvm/llvm-project/ 
c2443155a0fb245c8f17f2c1c72b6ea391e86e81)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+348b571beb5eeb70a...@syzkaller.appspotmail.com

==
BUG: KASAN: use-after-free in dev_uevent+0x30a/0x580 drivers/base/core.c:1486
Read of size 8 at addr 888098662098 by task systemd-udevd/29958

CPU: 0 PID: 29958 Comm: systemd-udevd Not tainted 5.7.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1e9/0x30e lib/dump_stack.c:118
 print_address_description+0x66/0x5a0 mm/kasan/report.c:383
 __kasan_report mm/kasan/report.c:513 [inline]
 kasan_report+0x132/0x1d0 mm/kasan/report.c:530
 dev_uevent+0x30a/0x580 drivers/base/core.c:1486
 uevent_show+0x1b2/0x2f0 drivers/base/core.c:1557
 dev_attr_show+0x50/0xc0 drivers/base/core.c:1261
 sysfs_kf_seq_show+0x30e/0x4e0 fs/sysfs/file.c:60
 seq_read+0x41a/0xce0 fs/seq_file.c:208
 __vfs_read+0x9c/0x6d0 fs/read_write.c:426
 vfs_read+0x1c4/0x400 fs/read_write.c:462
 ksys_read+0x11b/0x220 fs/read_write.c:588
 do_syscall_64+0xf3/0x1b0 arch/x86/entry/common.c:295
 entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x7f28fc677910
Code: b6 fe ff ff 48 8d 3d 0f be 08 00 48 83 ec 08 e8 06 db 01 00 66 0f 1f 44 
00 00 83 3d f9 2d 2c 00 00 75 10 b8 00 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 
c3 48 83 ec 08 e8 de 9b 01 00 48 89 04 24
RSP: 002b:7ffe3053dd18 EFLAGS: 0246 ORIG_RAX: 
RAX: ffda RBX: 5562a17eb920 RCX: 7f28fc677910
RDX: 1000 RSI: 5562a17fe8c0 RDI: 0007
RBP: 7f28fc932440 R08: 7f28fc9361e8 R09: 1010
R10: 5562a17eb920 R11: 0246 R12: 1000
R13: 0d68 R14: 5562a17fe8c0 R15: 7f28fc931900

Allocated by task 29904:
 save_stack mm/kasan/common.c:48 [inline]
 set_track mm/kasan/common.c:56 [inline]
 __kasan_kmalloc+0x103/0x140 mm/kasan/common.c:494
 kmem_cache_alloc_trace+0x234/0x300 mm/slab.c:3551
 kmalloc include/linux/slab.h:555 [inline]
 kzalloc include/linux/slab.h:669 [inline]
 dev_new drivers/usb/gadget/legacy/raw_gadget.c:182 [inline]
 raw_open+0x87/0x500 drivers/usb/gadget/legacy/raw_gadget.c:372
 misc_open+0x346/0x3c0 drivers/char/misc.c:141
 chrdev_open+0x498/0x580 fs/char_dev.c:414
 do_dentry_open+0x808/0x1020 fs/open.c:828
 do_open fs/namei.c:3229 [inline]
 path_openat+0x2790/0x38b0 fs/namei.c:3346
 do_filp_open+0x191/0x3a0 fs/namei.c:3373
 do_sys_openat2+0x463/0x770 fs/open.c:1179
 do_sys_open fs/open.c:1195 [inline]
 ksys_open include/linux/syscalls.h:1388 [inline]
 __do_sys_open fs/open.c:1201 [inline]
 __se_sys_open fs/open.c:1199 [inline]
 __x64_sys_open+0x1af/0x1e0 fs/open.c:1199
 do_syscall_64+0xf3/0x1b0 arch/x86/entry/common.c:295
 entry_SYSCALL_64_after_hwframe+0x49/0xb3

Freed by task 29956:
 save_stack mm/kasan/common.c:48 [inline]
 set_track mm/kasan/common.c:56 [inline]
 kasan_set_free_info mm/kasan/common.c:316 [inline]
 __kasan_slab_free+0x114/0x170 mm/kasan/common.c:455
 __cache_free mm/slab.c:3426 [inline]
 kfree+0x10a/0x220 mm/slab.c:3757
 raw_release+0x130/0x1e0 drivers/usb/gadget/legacy/raw_gadget.c:411
 __fput+0x2ed/0x750 fs/file_table.c:281
 task_work_run+0x147/0x1d0 kernel/task_work.c:123
 exit_task_work include/linux/task_work.h:22 [inline]
 do_exit+0x5ef/0x1f80 kernel/exit.c:806
 do_group_exit+0x15e/0x2c0 kernel/exit.c:904
 get_signal+0x13cf/0x1d60 kernel/signal.c:2739
 do_signal+0x33/0x610 arch/x86/kernel/signal.c:810
 exit_to_usermode_loop arch/x86/entry/common.c:161 [inline]
 prepare_exit_to_usermode+0x32a/0x600 arch/x86/entry/common.c:196
 entry_SYSCALL_64_after_hwframe+0x49/0xb3

The buggy address belongs to the object at 888098662000
 which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 152 bytes inside of
 4096-byte region [888098662000, 888098663000)
The buggy address belongs to the page:
page:ea0002619880 refcount:1 mapcount:0 mapping: index:0x0 
head:ea0002619880 order:1 compound_mapcount:0
flags: 0xfffe010200(slab|head)
raw: 00fffe010200 ea00021d0908 ea0002a5a808 8880aa402000
raw:  888098662000 00010001 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 888098661f80: fc fc fc fc fc fc fc fc fc fc fc fc fc 

bpf test error: KASAN: use-after-free Write in afs_wake_up_async_call

2020-06-18 Thread syzbot
Hello,

syzbot found the following crash on:

HEAD commit:ef7232da ionic: export features for vlans to use
git tree:   bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=173214d110
kernel config:  https://syzkaller.appspot.com/x/.config?x=b8ad29058cb749bc
dashboard link: https://syzkaller.appspot.com/bug?extid=0710b20f5412c027fefb
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0710b20f5412c027f...@syzkaller.appspotmail.com

tipc: TX() has been purged, node left!
==
BUG: KASAN: use-after-free in afs_wake_up_async_call+0x6aa/0x770 
fs/afs/rxrpc.c:707
Write of size 1 at addr 88809a0449e4 by task kworker/u4:0/7

CPU: 0 PID: 7 Comm: kworker/u4:0 Not tainted 5.8.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Workqueue: netns cleanup_net
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x18f/0x20d lib/dump_stack.c:118
 print_address_description.constprop.0.cold+0xd3/0x413 mm/kasan/report.c:383
 __kasan_report mm/kasan/report.c:513 [inline]
 kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
 afs_wake_up_async_call+0x6aa/0x770 fs/afs/rxrpc.c:707
 rxrpc_notify_socket+0x1db/0x5d0 net/rxrpc/recvmsg.c:40
 __rxrpc_set_call_completion.part.0+0x172/0x410 net/rxrpc/recvmsg.c:76
 __rxrpc_call_completed net/rxrpc/recvmsg.c:112 [inline]
 rxrpc_call_completed+0xca/0xf0 net/rxrpc/recvmsg.c:111
 rxrpc_discard_prealloc+0x781/0xab0 net/rxrpc/call_accept.c:233
 rxrpc_listen+0x147/0x360 net/rxrpc/af_rxrpc.c:245
 afs_close_socket+0x95/0x320 fs/afs/rxrpc.c:110
 afs_net_exit+0x1bc/0x310 fs/afs/main.c:155
 ops_exit_list.isra.0+0xa8/0x150 net/core/net_namespace.c:186
 cleanup_net+0x511/0xa50 net/core/net_namespace.c:603
 process_one_work+0x965/0x1690 kernel/workqueue.c:2269
 worker_thread+0x96/0xe10 kernel/workqueue.c:2415
 kthread+0x3b5/0x4a0 kernel/kthread.c:291
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293

Allocated by task 6807:
 save_stack+0x1b/0x40 mm/kasan/common.c:48
 set_track mm/kasan/common.c:56 [inline]
 __kasan_kmalloc mm/kasan/common.c:494 [inline]
 __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:467
 kmem_cache_alloc_trace+0x153/0x7d0 mm/slab.c:3551
 kmalloc include/linux/slab.h:555 [inline]
 kzalloc include/linux/slab.h:669 [inline]
 afs_alloc_call+0x55/0x630 fs/afs/rxrpc.c:141
 afs_charge_preallocation+0xe9/0x2d0 fs/afs/rxrpc.c:757
 afs_open_socket+0x292/0x360 fs/afs/rxrpc.c:92
 afs_net_init+0xa6c/0xe30 fs/afs/main.c:125
 ops_init+0xaf/0x420 net/core/net_namespace.c:151
 setup_net+0x2de/0x860 net/core/net_namespace.c:341
 copy_net_ns+0x293/0x590 net/core/net_namespace.c:482
 create_new_namespaces+0x3fb/0xb30 kernel/nsproxy.c:110
 unshare_nsproxy_namespaces+0xbd/0x1f0 kernel/nsproxy.c:231
 ksys_unshare+0x43d/0x8e0 kernel/fork.c:2983
 __do_sys_unshare kernel/fork.c:3051 [inline]
 __se_sys_unshare kernel/fork.c:3049 [inline]
 __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3049
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Freed by task 7:
 save_stack+0x1b/0x40 mm/kasan/common.c:48
 set_track mm/kasan/common.c:56 [inline]
 kasan_set_free_info mm/kasan/common.c:316 [inline]
 __kasan_slab_free+0xf7/0x140 mm/kasan/common.c:455
 __cache_free mm/slab.c:3426 [inline]
 kfree+0x109/0x2b0 mm/slab.c:3757
 afs_put_call+0x585/0xa40 fs/afs/rxrpc.c:190
 rxrpc_discard_prealloc+0x764/0xab0 net/rxrpc/call_accept.c:230
 rxrpc_listen+0x147/0x360 net/rxrpc/af_rxrpc.c:245
 afs_close_socket+0x95/0x320 fs/afs/rxrpc.c:110
 afs_net_exit+0x1bc/0x310 fs/afs/main.c:155
 ops_exit_list.isra.0+0xa8/0x150 net/core/net_namespace.c:186
 cleanup_net+0x511/0xa50 net/core/net_namespace.c:603
 process_one_work+0x965/0x1690 kernel/workqueue.c:2269
 worker_thread+0x96/0xe10 kernel/workqueue.c:2415
 kthread+0x3b5/0x4a0 kernel/kthread.c:291
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293

The buggy address belongs to the object at 88809a044800
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 484 bytes inside of
 1024-byte region [88809a044800, 88809a044c00)
The buggy address belongs to the page:
page:ea0002681100 refcount:1 mapcount:0 mapping: index:0x0
flags: 0xfffe000200(slab)
raw: 00fffe000200 ea000291db08 ea00028c27c8 8880aa000c40
raw:  88809a044000 00010002 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 88809a044880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 88809a044900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>88809a044980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
   ^
 88809a044a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 88809a044a80: fb fb fb fb 

[PATCH] ASoC: dt-bindings: ak4642: switch to yaml base Documentation

2020-06-18 Thread Kuninori Morimoto
From: Kuninori Morimoto 

This patch switches from .txt base to .yaml base Document.

Signed-off-by: Kuninori Morimoto 
---
 .../devicetree/bindings/sound/ak4642.txt  | 37 
 .../devicetree/bindings/sound/ak4642.yaml | 57 +++
 2 files changed, 57 insertions(+), 37 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/sound/ak4642.txt
 create mode 100644 Documentation/devicetree/bindings/sound/ak4642.yaml

diff --git a/Documentation/devicetree/bindings/sound/ak4642.txt 
b/Documentation/devicetree/bindings/sound/ak4642.txt
deleted file mode 100644
index 58e48ee97175..
--- a/Documentation/devicetree/bindings/sound/ak4642.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-AK4642 I2C transmitter
-
-This device supports I2C mode only.
-
-Required properties:
-
-  - compatible : "asahi-kasei,ak4642" or "asahi-kasei,ak4643" or 
"asahi-kasei,ak4648"
-  - reg : The chip select number on the I2C bus
-
-Optional properties:
-
-  - #clock-cells : common clock binding; shall be set to 0
-  - clocks :   common clock binding; MCKI clock
-  - clock-frequency :  common clock binding; frequency of MCKO
-  - clock-output-names :   common clock binding; MCKO clock name
-
-Example 1:
-
- {
-   ak4648: ak4648@12 {
-   compatible = "asahi-kasei,ak4642";
-   reg = <0x12>;
-   };
-};
-
-Example 2:
-
- {
-   ak4643: codec@12 {
-   compatible = "asahi-kasei,ak4643";
-   reg = <0x12>;
-   #clock-cells = <0>;
-   clocks = <_clock>;
-   clock-frequency = <12288000>;
-   clock-output-names = "ak4643_mcko";
-   };
-};
diff --git a/Documentation/devicetree/bindings/sound/ak4642.yaml 
b/Documentation/devicetree/bindings/sound/ak4642.yaml
new file mode 100644
index ..c8ffc86fd2d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ak4642.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ak4642.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AK4642 I2C transmitter Device Tree Bindings
+
+maintainers:
+  - Kuninori Morimoto 
+
+properties:
+  compatible:
+enum:
+  - asahi-kasei,ak4642
+  - asahi-kasei,ak4643
+  - asahi-kasei,ak4648
+
+  reg:
+maxItems: 1
+
+  "#clock-cells":
+const: 0
+
+  "#sound-dai-cells":
+const: 0
+
+  clocks:
+maxItems: 1
+
+  clock-frequency:
+description: frequency of MCKO
+
+  clock-output-names:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+ak4643: codec@12 {
+compatible = "asahi-kasei,ak4643";
+#sound-dai-cells = <0>;
+reg = <0x12>;
+#clock-cells = <0>;
+clocks = <_clock>;
+clock-frequency = <12288000>;
+clock-output-names = "ak4643_mcko";
+};
+};
-- 
2.25.1



[PATCH] ASoC: dt-bindings: ak4613: switch to yaml base Documentation

2020-06-18 Thread Kuninori Morimoto
From: Kuninori Morimoto 

This patch switches from .txt base to .yaml base Document.

Signed-off-by: Kuninori Morimoto 
---
v1 -> v2

- use patternProperties

 .../devicetree/bindings/sound/ak4613.txt  | 27 --
 .../devicetree/bindings/sound/ak4613.yaml | 49 +++
 2 files changed, 49 insertions(+), 27 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/sound/ak4613.txt
 create mode 100644 Documentation/devicetree/bindings/sound/ak4613.yaml

diff --git a/Documentation/devicetree/bindings/sound/ak4613.txt 
b/Documentation/devicetree/bindings/sound/ak4613.txt
deleted file mode 100644
index 49a2e74fd9cb..
--- a/Documentation/devicetree/bindings/sound/ak4613.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-AK4613 I2C transmitter
-
-This device supports I2C mode only.
-
-Required properties:
-
-- compatible : "asahi-kasei,ak4613"
-- reg : The chip select number on the I2C bus
-
-Optional properties:
-- asahi-kasei,in1-single-end   : Boolean. Indicate input / output pins are 
single-ended.
-- asahi-kasei,in2-single-end rather than differential.
-- asahi-kasei,out1-single-end
-- asahi-kasei,out2-single-end
-- asahi-kasei,out3-single-end
-- asahi-kasei,out4-single-end
-- asahi-kasei,out5-single-end
-- asahi-kasei,out6-single-end
-
-Example:
-
- {
-   ak4613: ak4613@10 {
-   compatible = "asahi-kasei,ak4613";
-   reg = <0x10>;
-   };
-};
diff --git a/Documentation/devicetree/bindings/sound/ak4613.yaml 
b/Documentation/devicetree/bindings/sound/ak4613.yaml
new file mode 100644
index ..eb915377bc5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ak4613.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ak4613.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AK4613 I2C transmitter Device Tree Bindings
+
+maintainers:
+  - Kuninori Morimoto 
+
+properties:
+  compatible:
+const: asahi-kasei,ak4613
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  "#sound-dai-cells":
+const: 0
+
+patternProperties:
+  "^asahi-kasei,in[1-2]-single-end$":
+description: Input Pin 1 - 2.
+$ref: /schemas/types.yaml#/definitions/flag
+
+  "^asahi-kasei,out[1-6]-single-end$":
+description: Output Pin 1 - 6.
+$ref: /schemas/types.yaml#/definitions/flag
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+ak4613: ak4613@10 {
+compatible = "asahi-kasei,ak4613";
+reg = <0x10>;
+};
+};
-- 
2.25.1



Re: [PATCH] f2fs: fix to document reserved special compression extension

2020-06-18 Thread Jaegeuk Kim
On 06/19, Chao Yu wrote:
> There is one reserved special compression extension: '*', which
> could be set via 'compress_extension="*"' mount option to enable
> compression for all files.

Thank you for the patch. :)

> 
> Signed-off-by: Chao Yu 
> ---
>  Documentation/filesystems/f2fs.rst | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/filesystems/f2fs.rst 
> b/Documentation/filesystems/f2fs.rst
> index 099d45ac8d8f..535021c46260 100644
> --- a/Documentation/filesystems/f2fs.rst
> +++ b/Documentation/filesystems/f2fs.rst
> @@ -258,6 +258,8 @@ compress_extension=%s  Support adding specified 
> extension, so that f2fs can enab
> on compression extension list and enable compression 
> on
> these file by default rather than to enable it via 
> ioctl.
> For other files, we can still enable compression via 
> ioctl.
> +   Note that, there is one reserved special extension 
> '*', it
> +   can be set to enable compression for all files.
>  == 
> 
>  
>  Debugfs Entries
> -- 
> 2.26.2


[PATCH] ASoC: dt-bindings: renesas,fsi: use patternProperties for FSI-A/B

2020-06-18 Thread Kuninori Morimoto
From: Kuninori Morimoto 

FSI has FSI-A and FSI-B, and has fsia-xxx/fsib-xxx properties.
This patch uses patternProperties, and reduce verbose settings.

Signed-off-by: Kuninori Morimoto 
---
 .../bindings/sound/renesas,fsi.yaml   | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml 
b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
index 8a4406be387a..0dd3f7361399 100644
--- a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
+++ b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
@@ -43,30 +43,19 @@ properties:
   '#sound-dai-cells':
 const: 1
 
-  fsia,spdif-connection:
+patternProperties:
+  "^fsi(a|b),spdif-connection$":
 $ref: /schemas/types.yaml#/definitions/flag
 description: FSI is connected by S/PDIF
 
-  fsia,stream-mode-support:
+  "^fsi(a|b),stream-mode-support$":
 $ref: /schemas/types.yaml#/definitions/flag
 description: FSI supports 16bit stream mode
 
-  fsia,use-internal-clock:
+  "^fsi(a|b),use-internal-clock$":
 $ref: /schemas/types.yaml#/definitions/flag
 description: FSI uses internal clock when master mode
 
-  fsib,spdif-connection:
-$ref: /schemas/types.yaml#/definitions/flag
-description: same as fsia
-
-  fsib,stream-mode-support:
-$ref: /schemas/types.yaml#/definitions/flag
-description: same as fsia
-
-  fsib,use-internal-clock:
-$ref: /schemas/types.yaml#/definitions/flag
-description: same as fsia
-
 required:
   - compatible
   - reg
-- 
2.25.1



include/linux/blk-mq.h:300:29: error: 'MQ_RQ_IN_FLIGHT' undeclared

2020-06-18 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   5e857ce6eae7ca21b2055cca4885545e29228fe2
commit: 0fc09f920983f61be625658c62cc40ac25a7b3a5 blk-mq: export setting request 
completion state
config: powerpc64-randconfig-m031-20200618 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   In file included from include/scsi/scsi_cmnd.h:11,
from drivers/ata/libata-core.c:65:
   include/scsi/scsi_device.h:433:4: error: unknown type name 'req_flags_t'; 
did you mean 'vm_flags_t'?
 433 |req_flags_t rq_flags, int *resid);
 |^~~
 |vm_flags_t
   include/scsi/scsi_device.h: In function 'scsi_execute_req':
   include/scsi/scsi_device.h:439:9: error: implicit declaration of function 
'scsi_execute'; did you mean 'scsi_execute_req'? 
[-Werror=implicit-function-declaration]
 439 |  return scsi_execute(sdev, cmd, data_direction, buffer,
 | ^~~~
 | scsi_execute_req
   In file included from include/scsi/scsi_request.h:5,
from include/scsi/scsi_cmnd.h:12,
from drivers/ata/libata-core.c:65:
   include/linux/blk-mq.h: At top level:
   include/linux/blk-mq.h:142:2: error: unknown type name 'softirq_done_fn'
 142 |  softirq_done_fn  *complete;
 |  ^~~
   In file included from arch/powerpc/include/asm/atomic.h:11,
from include/linux/atomic.h:5,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from include/linux/spinlock.h:82,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/module.h:10,
from drivers/ata/libata-core.c:44:
   include/linux/blk-mq.h: In function 'blk_mq_mark_complete':
   include/linux/blk-mq.h:300:20: error: dereferencing pointer to incomplete 
type 'struct request'
 300 |  return cmpxchg(>state, MQ_RQ_IN_FLIGHT, MQ_RQ_COMPLETE) ==
 |^~
   arch/powerpc/include/asm/cmpxchg.h:483:19: note: in definition of macro 
'cmpxchg'
 483 |  __typeof__(*(ptr)) _o_ = (o);  \
 |   ^~~
>> include/linux/blk-mq.h:300:29: error: 'MQ_RQ_IN_FLIGHT' undeclared (first 
>> use in this function)
 300 |  return cmpxchg(>state, MQ_RQ_IN_FLIGHT, MQ_RQ_COMPLETE) ==
 | ^~~
   arch/powerpc/include/asm/cmpxchg.h:483:32: note: in definition of macro 
'cmpxchg'
 483 |  __typeof__(*(ptr)) _o_ = (o);  \
 |^
   include/linux/blk-mq.h:300:29: note: each undeclared identifier is reported 
only once for each function it appears in
 300 |  return cmpxchg(>state, MQ_RQ_IN_FLIGHT, MQ_RQ_COMPLETE) ==
 | ^~~
   arch/powerpc/include/asm/cmpxchg.h:483:32: note: in definition of macro 
'cmpxchg'
 483 |  __typeof__(*(ptr)) _o_ = (o);  \
 |^
>> include/linux/blk-mq.h:300:46: error: 'MQ_RQ_COMPLETE' undeclared (first use 
>> in this function); did you mean 'COMMAND_COMPLETE'?
 300 |  return cmpxchg(>state, MQ_RQ_IN_FLIGHT, MQ_RQ_COMPLETE) ==
 |  ^~
   arch/powerpc/include/asm/cmpxchg.h:484:32: note: in definition of macro 
'cmpxchg'
 484 |  __typeof__(*(ptr)) _n_ = (n);  \
 |^
   In file included from include/scsi/scsi_request.h:5,
from include/scsi/scsi_cmnd.h:12,
from drivers/ata/libata-core.c:65:
   include/linux/blk-mq.h: In function 'blk_mq_rq_from_pdu':
   include/linux/blk-mq.h:310:22: error: invalid application of 'sizeof' to 
incomplete type 'struct request'
 310 |  return pdu - sizeof(struct request);
 |  ^~
   include/linux/blk-mq.h: In function 'blk_mq_rq_to_pdu':
   include/linux/blk-mq.h:314:12: error: invalid use of undefined type 'struct 
request'
 314 |  return rq + 1;
 |^
   In file included from drivers/ata/libata-core.c:65:
   include/scsi/scsi_cmnd.h: In function 'scsi_bidi_cmnd':
   include/scsi/scsi_cmnd.h:215:9: error: implicit declaration of function 
'blk_bidi_rq' [-Werror=implicit-function-declaration]
 215 |  return blk_bidi_rq(cmd->request) &&
 | ^~~
   include/scsi/scsi_cmnd.h: In function 'scsi_get_lba':
   include/scsi/scsi_cmnd.h:308:9: error: implicit declaration of function 
'blk_rq_pos' [-Wer

ARM: dts: motorola-mapphone-common: remove unneeded "simple-graph-card"

2020-06-18 Thread Kuninori Morimoto
From: Kuninori Morimoto 

Audio Graph Card is using "audio-graph-card" prefix instead of
"simple-graph-card", and moreover "widgets / routing" doesn't need it.
This patch removes unsupported "simple-graph-card" prefix from
motorola-mapphone-common.dtsi and vendor-prefixes.yaml.

Signed-off-by: Kuninori Morimoto 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 +-
 arch/arm/boot/dts/motorola-mapphone-common.dtsi| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 9aeab66be85f..147afcfe81fe 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -20,7 +20,7 @@ patternProperties:
   "^(keypad|m25p|max8952|max8997|max8998|mpmc),.*": true
   "^(pinctrl-single|#pinctrl-single|PowerPC),.*": true
   "^(pl022|pxa-mmc|rcar_sound|rotary-encoder|s5m8767|sdhci),.*": true
-  "^(simple-audio-card|simple-graph-card|st-plgpio|st-spics|ts),.*": true
+  "^(simple-audio-card|st-plgpio|st-spics|ts),.*": true
 
   # Keep list in alphabetical order.
   "^abilis,.*":
diff --git a/arch/arm/boot/dts/motorola-mapphone-common.dtsi 
b/arch/arm/boot/dts/motorola-mapphone-common.dtsi
index 06fbffa81636..1990239cc6af 100644
--- a/arch/arm/boot/dts/motorola-mapphone-common.dtsi
+++ b/arch/arm/boot/dts/motorola-mapphone-common.dtsi
@@ -140,13 +140,13 @@ soundcard {
compatible = "audio-graph-card";
label = "Droid 4 Audio";
 
-   simple-graph-card,widgets =
+   widgets =
"Speaker", "Earpiece",
"Speaker", "Loudspeaker",
"Headphone", "Headphone Jack",
"Microphone", "Internal Mic";
 
-   simple-graph-card,routing =
+   routing =
"Earpiece", "EP",
"Loudspeaker", "SPKR",
"Headphone Jack", "HSL",
-- 
2.25.1



Re: [PATCH v3 2/4] bus: mhi: core: Move MHI_MAX_MTU to external header file

2020-06-18 Thread Manivannan Sadhasivam
On Thu, Jun 11, 2020 at 11:13:42AM -0700, Hemant Kumar wrote:
> Currently this macro is defined in internal MHI header as
> a TRE length mask. Moving it to external header allows MHI
> client drivers to set this upper bound for the transmit
> buffer size.
> 

So we have 2 definitions for MHI_MAX_MTU now? Why can't you remove the one
available internally?

Thanks,
Mani

> Signed-off-by: Hemant Kumar 
> ---
>  include/linux/mhi.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/linux/mhi.h b/include/linux/mhi.h
> index a39b77d..ce43f74 100644
> --- a/include/linux/mhi.h
> +++ b/include/linux/mhi.h
> @@ -16,6 +16,9 @@
>  #include 
>  #include 
>  
> +/* MHI client drivers to set this upper bound for tx buffer */
> +#define MHI_MAX_MTU 0x
> +
>  #define MHI_VOTE_BUS BIT(0) /* do not disable the mhi bus */
>  #define MHI_VOTE_DEVICE BIT(1) /* prevent mhi device from entering lpm */
>  
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 


Re: [PATCH v3 1/4] bus: mhi: core: Add helper API to return number of free TREs

2020-06-18 Thread Manivannan Sadhasivam
On Thu, Jun 11, 2020 at 11:13:41AM -0700, Hemant Kumar wrote:
> Introduce mhi_get_no_free_descriptors() API to return number
> of TREs available to queue buffer. MHI clients can use this
> API to know before hand if ring is full without calling queue
> API.
> 
> Signed-off-by: Hemant Kumar 
> ---
>  drivers/bus/mhi/core/main.c | 12 
>  include/linux/mhi.h |  9 +
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index d25f321..1bd3b1e 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -258,6 +258,18 @@ int mhi_destroy_device(struct device *dev, void *data)
>   return 0;
>  }
>  
> +int mhi_get_no_free_descriptors(struct mhi_device *mhi_dev,
> + enum dma_data_direction dir)

How about "mhi_get_nr_free_descriptors"? Also align with '('

> +{
> + struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
> + struct mhi_chan *mhi_chan = (dir == DMA_TO_DEVICE) ?
> + mhi_dev->ul_chan : mhi_dev->dl_chan;
> + struct mhi_ring *tre_ring = _chan->tre_ring;
> +
> + return get_nr_avail_ring_elements(mhi_cntrl, tre_ring);
> +}
> +EXPORT_SYMBOL_GPL(mhi_get_no_free_descriptors);
> +
>  void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason)
>  {
>   struct mhi_driver *mhi_drv;
> diff --git a/include/linux/mhi.h b/include/linux/mhi.h
> index 6af6bd6..a39b77d 100644
> --- a/include/linux/mhi.h
> +++ b/include/linux/mhi.h
> @@ -602,6 +602,15 @@ void mhi_set_mhi_state(struct mhi_controller *mhi_cntrl,
>  void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason);
>  
>  /**
> + * mhi_get_no_free_descriptors - Get transfer ring length

Is the description correct? I'd suggest to just use the below one.

> + * Get # of TD available to queue buffers

How about, "Get # of available TREs to queue buffers"?

> + * @mhi_dev: Device associated with the channels
> + * @dir: Direction of the channel
> + */
> +int mhi_get_no_free_descriptors(struct mhi_device *mhi_dev,
> + enum dma_data_direction dir);

Align this with '('

Thanks,
Mani

> +
> +/**
>   * mhi_prepare_for_power_up - Do pre-initialization before power up.
>   *This is optional, call this before power up if
>   *the controller does not want bus framework to
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 


[PATCH] um: vector: Use GFP_ATOMIC under spin lock

2020-06-18 Thread Tiezhu Yang
Use GFP_ATOMIC instead of GFP_KERNEL under spin lock to fix possible
sleep-in-atomic-context bugs.

Fixes: 9807019a62dc ("um: Loadable BPF "Firmware" for vector drivers")
Signed-off-by: Tiezhu Yang 
---
 arch/um/drivers/vector_kern.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/um/drivers/vector_kern.c b/arch/um/drivers/vector_kern.c
index 8735c46..555203e 100644
--- a/arch/um/drivers/vector_kern.c
+++ b/arch/um/drivers/vector_kern.c
@@ -1403,7 +1403,7 @@ static int vector_net_load_bpf_flash(struct net_device 
*dev,
kfree(vp->bpf->filter);
vp->bpf->filter = NULL;
} else {
-   vp->bpf = kmalloc(sizeof(struct sock_fprog), GFP_KERNEL);
+   vp->bpf = kmalloc(sizeof(struct sock_fprog), GFP_ATOMIC);
if (vp->bpf == NULL) {
netdev_err(dev, "failed to allocate memory for 
firmware\n");
goto flash_fail;
@@ -1415,7 +1415,7 @@ static int vector_net_load_bpf_flash(struct net_device 
*dev,
if (request_firmware(, efl->data, >pdev.dev))
goto flash_fail;
 
-   vp->bpf->filter = kmemdup(fw->data, fw->size, GFP_KERNEL);
+   vp->bpf->filter = kmemdup(fw->data, fw->size, GFP_ATOMIC);
if (!vp->bpf->filter)
goto free_buffer;
 
-- 
2.1.0



Re: [PATCH net-next v8 4/5] net: dp83869: Add RGMII internal delay configuration

2020-06-18 Thread kernel test robot
Hi Dan,

I love your patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Dan-Murphy/RGMII-Internal-delay-common-property/20200619-051238
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
cb8e59cc87201af93dfbb6c3dccc8fcad72a09c2
config: s390-randconfig-r014-20200618 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
487ca07fcc75d52755c9fe2ee05bcb3b6c44)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install s390 cross compiling tool for clang build
# apt-get install binutils-s390-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):

#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
^
include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
___constant_swab32(x) :   ^
include/uapi/linux/swab.h:20:12: note: expanded from macro '___constant_swab32'
(((__u32)(x) & (__u32)0xff00UL) <<  8) | ^
In file included from drivers/net/phy/dp83869.c:6:
In file included from include/linux/ethtool.h:18:
In file included from include/uapi/linux/ethtool.h:19:
In file included from include/linux/if_ether.h:19:
In file included from include/linux/skbuff.h:31:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:72:
include/asm-generic/io.h:492:45: warning: performing pointer arithmetic on a 
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu(__raw_readl(PCI_IOBASE + addr));
~~ ^
include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro 
'__le32_to_cpu'
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
^
include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
___constant_swab32(x) :   ^
include/uapi/linux/swab.h:21:12: note: expanded from macro '___constant_swab32'
(((__u32)(x) & (__u32)0x00ffUL) >>  8) | ^
In file included from drivers/net/phy/dp83869.c:6:
In file included from include/linux/ethtool.h:18:
In file included from include/uapi/linux/ethtool.h:19:
In file included from include/linux/if_ether.h:19:
In file included from include/linux/skbuff.h:31:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:72:
include/asm-generic/io.h:492:45: warning: performing pointer arithmetic on a 
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu(__raw_readl(PCI_IOBASE + addr));
~~ ^
include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro 
'__le32_to_cpu'
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
^
include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
___constant_swab32(x) :   ^
include/uapi/linux/swab.h:22:12: note: expanded from macro '___constant_swab32'
(((__u32)(x) & (__u32)0xff00UL) >> 24)))
^
In file included from drivers/net/phy/dp83869.c:6:
In file included from include/linux/ethtool.h:18:
In file included from include/uapi/linux/ethtool.h:19:
In file included from include/linux/if_ether.h:19:
In file included from include/linux/skbuff.h:31:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:72:
include/asm-generic/io.h:492:45: warning: performing pointer arithmetic on a 
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu(__raw_readl(PCI_IOBASE + addr));
~~ ^
include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro 
'__le32_to_cpu'
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
^
include/uapi/linux/swab.h:120:12: note: expanded from macro '__swab32'
__fswab32(x))
^
In file included from drivers/net/phy/dp83869.c:6:
In file included from include/linux/ethtool.h:18:
In file included from include/uapi/linux/ethtool.h:19:
In file included from include/linux/if_ether.h:19:
In file included from include/linux/skbuff.h:31:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:72:
include/asm-generic/io.h:503:33: warning: performing pointer arithmetic on a 
n

Re: [PATCH v6 23/36] drm: vmwgfx: fix common struct sg_table related issues

2020-06-18 Thread kernel test robot
Hi Marek,

I love your patch! Yet something to improve:

[auto build test ERROR on next-20200618]
[also build test ERROR on v5.8-rc1]
[cannot apply to linuxtv-media/master staging/staging-testing 
drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7 
v5.7-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Marek-Szyprowski/DRM-fix-struct-sg_table-nents-vs-orig_nents-misuse/20200619-000417
base:ce2cc8efd7a40cbd17841add878cb691d0ce0bba
config: x86_64-rhel-7.6 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

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

   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c: In function 
'vmw_ttm_unmap_from_dma':
>> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:365:31: error: incompatible type 
>> for argument 2 of 'dma_unmap_sgtable'
 365 |  dma_unmap_sgtable(dev, vmw_tt->sgt, DMA_BIDIRECTIONAL, 0);
 | ~~^
 |   |
 |   struct sg_table
   In file included from include/linux/dma-buf.h:20,
from drivers/gpu/drm/vmwgfx/ttm_object.h:40,
from drivers/gpu/drm/vmwgfx/ttm_lock.h:55,
from drivers/gpu/drm/vmwgfx/vmwgfx_drv.h:44,
from drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:28:
   include/linux/dma-mapping.h:651:75: note: expected 'struct sg_table *' but 
argument is of type 'struct sg_table'
 651 | static inline void dma_unmap_sgtable(struct device *dev, struct 
sg_table *sgt,
 |  
~^~~
   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c: In function 
'vmw_ttm_map_for_dma':
>> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:386:36: error: incompatible type 
>> for argument 2 of 'dma_map_sgtable'
 386 |  return dma_map_sgtable(dev, vmw_tt->sgt, DMA_BIDIRECTIONAL, 0);
 |  ~~^
 ||
 |struct sg_table
   In file included from include/linux/dma-buf.h:20,
from drivers/gpu/drm/vmwgfx/ttm_object.h:40,
from drivers/gpu/drm/vmwgfx/ttm_lock.h:55,
from drivers/gpu/drm/vmwgfx/vmwgfx_drv.h:44,
from drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:28:
   include/linux/dma-mapping.h:628:72: note: expected 'struct sg_table *' but 
argument is of type 'struct sg_table'
 628 | static inline int dma_map_sgtable(struct device *dev, struct 
sg_table *sgt,
 |   
~^~~
>> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:387:1: warning: control reaches 
>> end of non-void function [-Wreturn-type]
 387 | }
 | ^

vim +/dma_unmap_sgtable +365 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c

   352  
   353  /**
   354   * vmw_ttm_unmap_from_dma - unmap  device addresses previsouly mapped 
for
   355   * TTM pages
   356   *
   357   * @vmw_tt: Pointer to a struct vmw_ttm_backend
   358   *
   359   * Used to free dma mappings previously mapped by vmw_ttm_map_for_dma.
   360   */
   361  static void vmw_ttm_unmap_from_dma(struct vmw_ttm_tt *vmw_tt)
   362  {
   363  struct device *dev = vmw_tt->dev_priv->dev->dev;
   364  
 > 365  dma_unmap_sgtable(dev, vmw_tt->sgt, DMA_BIDIRECTIONAL, 0);
   366  vmw_tt->sgt.nents = vmw_tt->sgt.orig_nents;
   367  }
   368  
   369  /**
   370   * vmw_ttm_map_for_dma - map TTM pages to get device addresses
   371   *
   372   * @vmw_tt: Pointer to a struct vmw_ttm_backend
   373   *
   374   * This function is used to get device addresses from the kernel DMA 
layer.
   375   * However, it's violating the DMA API in that when this operation has 
been
   376   * performed, it's illegal for the CPU to write to the pages without 
first
   377   * unmapping the DMA mappings, or calling dma_sync_sg_for_cpu(). It is
   378   * therefore only legal to call this function if we know that the 
function
   379   * dma_sync_sg_for_cpu() is a NOP, and dma_sync_sg_for_device() is at 
most
   380   * a CPU write buffer flush.
   381   */
   382  static int vmw_ttm_map_for_dma(struct vmw_ttm_tt *vmw_tt)
   383  {
   384  struct device *dev = vmw_tt->dev_priv->dev->dev;
   385  
 > 386  return dma_map_sgtable(dev, vmw_tt->sgt, DMA_BIDIRECTIONAL, 0);
 > 387  }
   388  

---
0-DAY CI Kernel Test 

Re: kprobe: __blkdev_put probe is missed

2020-06-18 Thread Masami Hiramatsu
Hi Ming,

On Fri, 19 Jun 2020 07:19:01 +0800
Ming Lei  wrote:

> > I'm using 5.4 on ubuntu and can not reproduce it with kprobe_event.
> > 
> > root@devnote2:/sys/kernel/tracing# uname -a
> > Linux devnote2 5.4.0-37-generic #41-Ubuntu SMP Wed Jun 3 18:57:02 UTC 2020 
> > x86_64 x86_64 x86_64 GNU/Linux
> > root@devnote2:/sys/kernel/tracing# echo p __blkdev_put > kprobe_events 
> > root@devnote2:/sys/kernel/tracing# echo 1 > 
> > events/kprobes/p___blkdev_put_0/enable 
> > root@devnote2:/sys/kernel/tracing# cat trace
> > # tracer: nop
> > #
> > # entries-in-buffer/entries-written: 0/0   #P:8
> > #
> > #  _-=> irqs-off
> > # / _=> need-resched
> > #| / _---=> hardirq/softirq
> > #|| / _--=> preempt-depth
> > #||| / delay
> > #   TASK-PID   CPU#  TIMESTAMP  FUNCTION
> > #  | |   |      | |
> > root@devnote2:/sys/kernel/tracing# blockdev --getbsz /dev/nvme0n1
> > 4096
> > root@devnote2:/sys/kernel/tracing# cat trace
> > # tracer: nop
> > #
> > # entries-in-buffer/entries-written: 1/1   #P:8
> > #
> > #  _-=> irqs-off
> > # / _=> need-resched
> > #| / _---=> hardirq/softirq
> > #|| / _--=> preempt-depth
> > #||| / delay
> > #   TASK-PID   CPU#  TIMESTAMP  FUNCTION
> > #  | |   |      | |
> ><...>-111740 [002]  301734.476991: p___blkdev_put_0: 
> > (__blkdev_put+0x0/0x1e0)
> > 
> > Hmm, maybe some issue in the latest kernel...?
> 
> Hello Masami,
> 
> I am testing the latest upstream kernel, your trace actually reproduces
> this issue.

OK.

> 
> After 'blockdev --getbsz /dev/nvme0n1' returns, __blkdev_put() should
> have been called two times(one for partition, and the other for disk),
> however kprobe trace just shows one time of calling this function.
> 
> If trace_printk() is added at the entry of __blkdev_put() manually,
> you will see that __blkdev_put() is called two times in 'blockdev
> --getbsz /dev/nvme0n1'.

OK, let me check again on the latest kernel.
Here I tested with qemu.

root@devnote2:/sys/kernel/debug/tracing# uname -a
Linux devnote2 5.8.0-rc1+ #26 SMP PREEMPT Fri Jun 19 12:12:53 JST 2020 x86_64 
x86_64 x86_64 GNU/Linux

And we have a (virtual) sda with 1 partition.

root@devnote2:/sys/kernel/debug/tracing# cat /proc/partitions 
major minor  #blocks  name

   80  10240 sda
   81   9216 sda1

OK, then let's make events (for sure)

root@devnote2:/sys/kernel/debug/tracing# echo p __blkdev_put >> kprobe_events 
root@devnote2:/sys/kernel/debug/tracing# echo r __blkdev_put >> kprobe_events 
root@devnote2:/sys/kernel/debug/tracing# echo p blkdev_put >> kprobe_events 

There are 3 events in the kernel, blkdev_put() and __blkdev_put() and
the return of __blkdev_put().
Then enable it and access to */dev/sda* (a disk)

root@devnote2:/sys/kernel/debug/tracing# echo 1 > events/kprobes/enable 
root@devnote2:/sys/kernel/debug/tracing# blockdev --getbsz /dev/sda
4096
root@devnote2:/sys/kernel/debug/tracing# echo 0 > events/kprobes/enable 
root@devnote2:/sys/kernel/debug/tracing# cat trace 
# tracer: nop
#
# entries-in-buffer/entries-written: 3/3   #P:8
#
#  _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
#   TASK-PID   CPU#  TIMESTAMP  FUNCTION
#  | |   |      | |
blockdev-185   [002] ...172.604266: p_blkdev_put_0: 
(blkdev_put+0x0/0x130)
blockdev-185   [002] ...172.604276: p___blkdev_put_0: 
(__blkdev_put+0x0/0x220)
blockdev-185   [002] d..272.604288: r___blkdev_put_0: 
(blkdev_put+0x50/0x130 <- __blkdev_put)

So the __blkdev_put() is called once from blkdev_put().
Next, we do same trace with accessing */dev/sda1* (a partition).

root@devnote2:/sys/kernel/debug/tracing# echo > trace 
root@devnote2:/sys/kernel/debug/tracing# echo 1 > events/kprobes/enable 
root@devnote2:/sys/kernel/debug/tracing# blockdev --getbsz /dev/sda1 
4096
root@devnote2:/sys/kernel/debug/tracing# echo 0 > events/kprobes/enable 
root@devnote2:/sys/kernel/debug/tracing# cat trace 
# tracer: nop
#
# entries-in-buffer/entries-written: 5/5   #P:8
#
#  _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
#   TASK-PID   CPU#  TIMESTAMP  FUNCTION
#  | |   |      | |

Re: [LKP] [sched/fair] 070f5e860e: reaim.jobs_per_min -10.5% regression

2020-06-18 Thread Xing Zhengjun




On 6/18/2020 4:24 PM, Hillf Danton wrote:


On Thu, 18 Jun 2020 10:45:01 +0800 Xing Zhengjun wrote:

On 6/18/2020 12:25 AM, Vincent Guittot wrote:

Le mercredi 17 juin 2020 à 16:57:25 (+0200), Vincent Guittot a écrit :

Le mercredi 17 juin 2020 à 08:30:21 (+0800), Xing Zhengjun a écrit :



On 6/16/2020 2:54 PM, Vincent Guittot wrote:


Hi Xing,

Le mardi 16 juin 2020 à 11:17:16 (+0800), Xing Zhengjun a écrit :



On 6/15/2020 4:10 PM, Vincent Guittot wrote:

Hi Xing,

Le lundi 15 juin 2020 à 15:26:59 (+0800), Xing Zhengjun a écrit :



On 6/12/2020 7:06 PM, Hillf Danton wrote:


On Fri, 12 Jun 2020 14:36:49 +0800 Xing Zhengjun wrote:




...


...


I apply the patch based on v5.7, the test result is as the following:

=
tbox_group/testcase/rootfs/kconfig/compiler/runtime/nr_task/debug-setup/test/cpufreq_governor/ucode:

lkp-ivb-d04/reaim/debian-x86_64-20191114.cgz/x86_64-rhel-7.6/gcc-7/300s/100%/test/five_sec/performance/0x21

commit:
9f68395333ad7f5bfe2f83473fed363d4229f11c
070f5e860ee2bf588c99ef7b4c202451faa48236
v5.7
63a5d0fbb5ec62f5148c251c01e709b8358cd0ee (the test patch)

9f68395333ad7f5b 070f5e860ee2bf588c99ef7b4c2v5.7
63a5d0fbb5ec62f5148c251c01e
 --- ---
---
   %stddev %change %stddev %change %stddev %change
%stddev
   \  |\  |\
|\
0.69   -10.3%   0.62-9.1%   0.62
+1.0%   0.69reaim.child_systime
0.62-1.0%   0.61+0.5%   0.62
-0.1%   0.62reaim.child_utime
   66870   -10.0%  60187-7.6%  61787
+1.1%  67636reaim.jobs_per_min
   16717   -10.0%  15046-7.6%  15446
+1.1%  16909reaim.jobs_per_min_child


OK. So the regression disappears when the conditions on runnable_avg are 
removed.

In the meantime, I have been able to understand more deeply what was happeningi
for this bench and how it is impacted by
commit: 070f5e860ee2 ("sched/fair: Take into account runnable_avg to classify 
group")

This bench forks a new thread for each and every new step. But a newly forked
threads start with a load_avg and a runnable_avg set to max whereas the threads
are running shortly before exiting. This makes the CPU to be set overloaded in
some case whereas it isn't.

Could you try the patch below ?
It fixes the problem on my setup (I have finally been able to reproduce the 
problem)

---
   kernel/sched/fair.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0ae62807..b33a4a9e1491 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -807,7 +807,7 @@ void post_init_entity_util_avg(struct task_struct *p)
}
}
   
-	sa->runnable_avg = cpu_scale;

+   sa->runnable_avg = sa->util_avg;
   
   	if (p->sched_class != _sched_class) {

/*
--
2.17.1



The patch above tries to move back to the group in the same classification as
before but this could harm other benchmarks.

There is another way to fix this by easing the migration of task in the case
of migrate_util imbalance.

Could you also try the patch below instead of the one above ?

---
   kernel/sched/fair.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0ae62807..fcaf66c4d086 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7753,7 +7753,8 @@ static int detach_tasks(struct lb_env *env)
case migrate_util:
util = task_util_est(p);

-   if (util > env->imbalance)
+   if (util/2 > env->imbalance &&
+   env->sd->nr_balance_failed <= 
env->sd->cache_nice_tries)
goto next;


Hmm... this sheds a shaft of light on computing imbalance for
migrate_util, see below.



env->imbalance -= util;
--
2.17.1




I apply the patch based on v5.7, the test result is as the following:


Thanks.



=
tbox_group/testcase/rootfs/kconfig/compiler/runtime/nr_task/debug-setup/test/cpufreq_governor/ucode:
  
lkp-ivb-d04/reaim/debian-x86_64-20191114.cgz/x86_64-rhel-7.6/gcc-7/300s/100%/test/five_sec/performance/0x21


commit:
9f68395333ad7f5bfe2f83473fed363d4229f11c
070f5e860ee2bf588c99ef7b4c202451faa48236
v5.7
69c81543653bf5f2c7105086502889fa019c15cb  (the test patch)

9f68395333ad7f5b 070f5e860ee2bf588c99ef7b4c2v5.7
69c81543653bf5f2c7105086502
 --- 

[PATCH 4/4] powerpc/pseries/iommu: Remove default DMA window before creating DDW

2020-06-18 Thread Leonardo Bras
On LoPAR "DMA Window Manipulation Calls", it's recommended to remove the
default DMA window for the device, before attempting to configure a DDW,
in order to make the maximum resources available for the next DDW to be
created.

This is a requirement for some devices to use DDW, given they only
allow one DMA window.

If setting up a new DDW fails anywhere after the removal of this
default DMA window, restore it using reset_dma_window.

Signed-off-by: Leonardo Bras 
---
 arch/powerpc/platforms/pseries/iommu.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/iommu.c 
b/arch/powerpc/platforms/pseries/iommu.c
index de633f6ae093..68d1ea957ac7 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -1074,8 +1074,9 @@ static u64 enable_ddw(struct pci_dev *dev, struct 
device_node *pdn)
u64 dma_addr, max_addr;
struct device_node *dn;
u32 ddw_avail[3];
+
struct direct_window *window;
-   struct property *win64;
+   struct property *win64, *dfl_win;
struct dynamic_dma_window_prop *ddwprop;
struct failed_ddw_pdn *fpdn;
 
@@ -1110,8 +,19 @@ static u64 enable_ddw(struct pci_dev *dev, struct 
device_node *pdn)
if (ret)
goto out_failed;
 
-   /*
-* Query if there is a second window of size to map the
+   /*
+* First step of setting up DDW is removing the default DMA window,
+* if it's present. It will make all the resources available to the
+* new DDW window.
+* If anything fails after this, we need to restore it.
+*/
+
+   dfl_win = of_find_property(pdn, "ibm,dma-window", NULL);
+   if (dfl_win)
+   remove_dma_window(pdn, ddw_avail, dfl_win);
+
+   /*
+* Query if there is a window of size to map the
 * whole partition.  Query returns number of windows, largest
 * block assigned to PE (partition endpoint), and two bitmasks
 * of page sizes: supported and supported for migrate-dma.
@@ -1219,6 +1231,8 @@ static u64 enable_ddw(struct pci_dev *dev, struct 
device_node *pdn)
kfree(win64);
 
 out_failed:
+   if (dfl_win)
+   reset_dma_window(dev, pdn);
 
fpdn = kzalloc(sizeof(*fpdn), GFP_KERNEL);
if (!fpdn)
-- 
2.25.4



[PATCH 0/4] Remove default DMA window before creating DDW

2020-06-18 Thread Leonardo Bras
There are some devices that only allow 1 DMA window to exist at a time,
and in those cases, a DDW is never created to them, since the default DMA
window keeps using this resource.

LoPAR recommends this procedure:
1. Remove the default DMA window,
2. Query for which configs the DDW can be created,
3. Create a DDW.

Patch #1:
- After LoPAR level 2.8, there is an extension that can make
  ibm,query-pe-dma-windows to have 6 outputs instead of 5. This changes the
  order of the outputs, and that can cause some trouble. 
- query_ddw() was updated to check how many outputs the 
  ibm,query-pe-dma-windows is supposed to have, update the rtas_call() and
  deal correctly with the outputs in both cases.
- This patch looks somehow unrelated to the series, but it can avoid future
  problems on DDW creation.

Patch #2 implements a new rtas call to recover the default DMA window,
in case anything fails after it was removed, and a DDW couldn't be created.

Patch #3 moves the window-removing code from remove_ddw() to
remove_dma_window(), creating a way to delete any DMA window, so it can be
used to delete the default DMA window.

Patch #4 makes use of the remove_dma_window() from patch #3 to remove the
default DMA window before query_ddw() and the rtas call from patch #2
to recover it if something goes wrong.

All patches were tested into an LPAR with an Ethernet VF:
4005:01:00.0 Ethernet controller: Mellanox Technologies MT27700 Family
[ConnectX-4 Virtual Function]

Leonardo Bras (4):
  powerpc/pseries/iommu: Update call to ibm,query-pe-dma-windows
  powerpc/pseries/iommu: Implement ibm,reset-pe-dma-windows rtas call
  powerpc/pseries/iommu: Move window-removing part of remove_ddw into
remove_dma_window
  powerpc/pseries/iommu: Remove default DMA window before creating DDW

 arch/powerpc/platforms/pseries/iommu.c | 163 +++--
 1 file changed, 127 insertions(+), 36 deletions(-)

-- 
2.25.4



[PATCH 3/4] powerpc/pseries/iommu: Move window-removing part of remove_ddw into remove_dma_window

2020-06-18 Thread Leonardo Bras
Move the window-removing part of remove_ddw into a new function
(remove_dma_window), so it can be used to remove other DMA windows.

It's useful for removing DMA windows that don't create DIRECT64_PROPNAME
property, like the default DMA window from the device, which uses
"ibm,dma-window".

Signed-off-by: Leonardo Bras 
---
 arch/powerpc/platforms/pseries/iommu.c | 53 +++---
 1 file changed, 31 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/iommu.c 
b/arch/powerpc/platforms/pseries/iommu.c
index 5e1fbc176a37..de633f6ae093 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -767,25 +767,14 @@ static int __init disable_ddw_setup(char *str)
 
 early_param("disable_ddw", disable_ddw_setup);
 
-static void remove_ddw(struct device_node *np, bool remove_prop)
+static void remove_dma_window(struct device_node *pdn, u32 *ddw_avail,
+ struct property *win)
 {
struct dynamic_dma_window_prop *dwp;
-   struct property *win64;
-   u32 ddw_avail[3];
u64 liobn;
-   int ret = 0;
-
-   ret = of_property_read_u32_array(np, "ibm,ddw-applicable",
-_avail[0], 3);
-
-   win64 = of_find_property(np, DIRECT64_PROPNAME, NULL);
-   if (!win64)
-   return;
-
-   if (ret || win64->length < sizeof(*dwp))
-   goto delprop;
+   int ret;
 
-   dwp = win64->value;
+   dwp = win->value;
liobn = (u64)be32_to_cpu(dwp->liobn);
 
/* clear the whole window, note the arg is in kernel pages */
@@ -793,24 +782,44 @@ static void remove_ddw(struct device_node *np, bool 
remove_prop)
1ULL << (be32_to_cpu(dwp->window_shift) - PAGE_SHIFT), dwp);
if (ret)
pr_warn("%pOF failed to clear tces in window.\n",
-   np);
+   pdn);
else
pr_debug("%pOF successfully cleared tces in window.\n",
-np);
+pdn);
 
ret = rtas_call(ddw_avail[2], 1, 1, NULL, liobn);
if (ret)
pr_warn("%pOF: failed to remove direct window: rtas returned "
"%d to ibm,remove-pe-dma-window(%x) %llx\n",
-   np, ret, ddw_avail[2], liobn);
+   pdn, ret, ddw_avail[2], liobn);
else
pr_debug("%pOF: successfully removed direct window: rtas 
returned "
"%d to ibm,remove-pe-dma-window(%x) %llx\n",
-   np, ret, ddw_avail[2], liobn);
+   pdn, ret, ddw_avail[2], liobn);
+}
+
+static void remove_ddw(struct device_node *np, bool remove_prop)
+{
+   struct property *win;
+   u32 ddw_avail[3];
+   int ret = 0;
+
+   ret = of_property_read_u32_array(np, "ibm,ddw-applicable",
+_avail[0], 3);
+   if (ret)
+   return;
+
+   win = of_find_property(np, DIRECT64_PROPNAME, NULL);
+   if (!win)
+   return;
+
+   if (win->length >= sizeof(struct dynamic_dma_window_prop))
+   remove_dma_window(np, ddw_avail, win);
+
+   if (!remove_prop)
+   return;
 
-delprop:
-   if (remove_prop)
-   ret = of_remove_property(np, win64);
+   ret = of_remove_property(np, win);
if (ret)
pr_warn("%pOF: failed to remove direct window property: %d\n",
np, ret);
-- 
2.25.4



[PATCH 1/4] powerpc/pseries/iommu: Update call to ibm,query-pe-dma-windows

2020-06-18 Thread Leonardo Bras
>From LoPAR level 2.8, "ibm,ddw-extensions" index 3 can make the number of
outputs from "ibm,query-pe-dma-windows" go from 5 to 6.

This change of output size is meant to expand the address size of
largest_available_block PE TCE from 32-bit to 64-bit, which ends up
shifting page_size and migration_capable.

This ends up requiring the update of
ddw_query_response->largest_available_block from u32 to u64, and manually
assigning the values from the buffer into this struct, according to
output size.

Signed-off-by: Leonardo Bras 
---
 arch/powerpc/platforms/pseries/iommu.c | 57 +-
 1 file changed, 46 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/iommu.c 
b/arch/powerpc/platforms/pseries/iommu.c
index 6d47b4a3ce39..e5a617738c8b 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -334,7 +334,7 @@ struct direct_window {
 /* Dynamic DMA Window support */
 struct ddw_query_response {
u32 windows_available;
-   u32 largest_available_block;
+   u64 largest_available_block;
u32 page_size;
u32 migration_capable;
 };
@@ -869,14 +869,32 @@ static int find_existing_ddw_windows(void)
 }
 machine_arch_initcall(pseries, find_existing_ddw_windows);
 
+/*
+ * From LoPAR level 2.8, "ibm,ddw-extensions" index 3 can rule how many output
+ * parameters ibm,query-pe-dma-windows will have, ranging from 5 to 6.
+ */
+
+static int query_ddw_out_sz(struct device_node *par_dn)
+{
+   int ret;
+   u32 ddw_ext[3];
+
+   ret = of_property_read_u32_array(par_dn, "ibm,ddw-extensions",
+_ext[0], 3);
+   if (ret || ddw_ext[0] < 2 || ddw_ext[2] != 1)
+   return 5;
+   return 6;
+}
+
 static int query_ddw(struct pci_dev *dev, const u32 *ddw_avail,
-   struct ddw_query_response *query)
+struct ddw_query_response *query,
+struct device_node *par_dn)
 {
struct device_node *dn;
struct pci_dn *pdn;
-   u32 cfg_addr;
+   u32 cfg_addr, query_out[5];
u64 buid;
-   int ret;
+   int ret, out_sz;
 
/*
 * Get the config address and phb buid of the PE window.
@@ -888,12 +906,29 @@ static int query_ddw(struct pci_dev *dev, const u32 
*ddw_avail,
pdn = PCI_DN(dn);
buid = pdn->phb->buid;
cfg_addr = ((pdn->busno << 16) | (pdn->devfn << 8));
+   out_sz = query_ddw_out_sz(par_dn);
+
+   ret = rtas_call(ddw_avail[0], 3, out_sz, query_out,
+   cfg_addr, BUID_HI(buid), BUID_LO(buid));
+   dev_info(>dev, "ibm,query-pe-dma-windows(%x) %x %x %x returned 
%d\n",
+ddw_avail[0], cfg_addr, BUID_HI(buid), BUID_LO(buid), ret);
+
+   switch (out_sz) {
+   case 5:
+   query->windows_available = query_out[0];
+   query->largest_available_block = query_out[1];
+   query->page_size = query_out[2];
+   query->migration_capable = query_out[3];
+   break;
+   case 6:
+   query->windows_available = query_out[0];
+   query->largest_available_block = ((u64)query_out[1] << 32) |
+query_out[2];
+   query->page_size = query_out[3];
+   query->migration_capable = query_out[4];
+   break;
+   }
 
-   ret = rtas_call(ddw_avail[0], 3, 5, (u32 *)query,
- cfg_addr, BUID_HI(buid), BUID_LO(buid));
-   dev_info(>dev, "ibm,query-pe-dma-windows(%x) %x %x %x"
-   " returned %d\n", ddw_avail[0], cfg_addr, BUID_HI(buid),
-   BUID_LO(buid), ret);
return ret;
 }
 
@@ -1040,7 +1075,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct 
device_node *pdn)
 * of page sizes: supported and supported for migrate-dma.
 */
dn = pci_device_to_OF_node(dev);
-   ret = query_ddw(dev, ddw_avail, );
+   ret = query_ddw(dev, ddw_avail, , pdn);
if (ret != 0)
goto out_failed;
 
@@ -1068,7 +1103,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct 
device_node *pdn)
/* check largest block * page size > max memory hotplug addr */
max_addr = ddw_memory_hotplug_max();
if (query.largest_available_block < (max_addr >> page_shift)) {
-   dev_dbg(>dev, "can't map partition max 0x%llx with %u "
+   dev_dbg(>dev, "can't map partition max 0x%llx with %llu "
  "%llu-sized pages\n", max_addr,  
query.largest_available_block,
  1ULL << page_shift);
goto out_failed;
-- 
2.25.4



[PATCH 2/4] powerpc/pseries/iommu: Implement ibm,reset-pe-dma-windows rtas call

2020-06-18 Thread Leonardo Bras
Platforms supporting the DDW option starting with LoPAR level 2.7 implement
ibm,ddw-extensions. The first extension available (index 2) carries the
token for ibm,reset-pe-dma-windows rtas call, which is used to restore
the default DMA window for a device, if it has been deleted.

It does so by resetting the TCE table allocation for the PE to it's
boot time value, available in "ibm,dma-window" device tree node.

Signed-off-by: Leonardo Bras 
---
 arch/powerpc/platforms/pseries/iommu.c | 33 ++
 1 file changed, 33 insertions(+)

diff --git a/arch/powerpc/platforms/pseries/iommu.c 
b/arch/powerpc/platforms/pseries/iommu.c
index e5a617738c8b..5e1fbc176a37 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -1012,6 +1012,39 @@ static phys_addr_t ddw_memory_hotplug_max(void)
return max_addr;
 }
 
+/*
+ * Platforms supporting the DDW option starting with LoPAR level 2.7 implement
+ * ibm,ddw-extensions, which carries the rtas token for
+ * ibm,reset-pe-dma-windows.
+ * That rtas-call can be used to restore the default DMA window for the device.
+ */
+static void reset_dma_window(struct pci_dev *dev, struct device_node *par_dn)
+{
+   int ret;
+   u32 cfg_addr, ddw_ext[3];
+   u64 buid;
+   struct device_node *dn;
+   struct pci_dn *pdn;
+
+   ret = of_property_read_u32_array(par_dn, "ibm,ddw-extensions",
+_ext[0], 3);
+   if (ret)
+   return;
+
+   dn = pci_device_to_OF_node(dev);
+   pdn = PCI_DN(dn);
+   buid = pdn->phb->buid;
+   cfg_addr = ((pdn->busno << 16) | (pdn->devfn << 8));
+
+   ret = rtas_call(ddw_ext[1], 3, 1, NULL, cfg_addr,
+   BUID_HI(buid), BUID_LO(buid));
+   if (ret)
+   dev_info(>dev,
+"ibm,reset-pe-dma-windows(%x) %x %x %x returned %d ",
+ddw_ext[1], cfg_addr, BUID_HI(buid), BUID_LO(buid),
+ret);
+}
+
 /*
  * If the PE supports dynamic dma windows, and there is space for a table
  * that can map all pages in a linear offset, then setup such a table,
-- 
2.25.4



Re: [PATCH v5 2/3] dt-bindings: net: mscc-vsc8531: add optional clock properties

2020-06-18 Thread Florian Fainelli



On 6/18/2020 5:11 AM, Heiko Stuebner wrote:
> From: Heiko Stuebner 
> 
> Some mscc ethernet phys have a configurable clock output, so describe the
> generic properties to access them in devicetrees.
> 
> Signed-off-by: Heiko Stuebner 
> ---
>  Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt 
> b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> index 5ff37c68c941..67625ba27f53 100644
> --- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> +++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> @@ -1,6 +1,8 @@
>  * Microsemi - vsc8531 Giga bit ethernet phy
>  
>  Optional properties:
> +- clock-output-names : Name for the exposed clock output
> +- #clock-cells   : should be 0
>  - vsc8531,vddmac : The vddmac in mV. Allowed values is listed
> in the first row of Table 1 (below).
> This property is only used in combination
> 

With that approach, you also need to be careful as a driver writer to
ensure that you have at least probed the MDIO bus to ensure that the PHY
device has been created (and therefore it is available as a clock
provider) if that same Ethernet MAC is a consumer of that clock (which
it appears to be). Otherwise you may just never probe and be trapped in
a circular dependency.
-- 
Florian


Re: [LKP] [sched/fair] 070f5e860e: reaim.jobs_per_min -10.5% regression

2020-06-18 Thread Xing Zhengjun




On 6/18/2020 8:35 PM, Vincent Guittot wrote:

On Thu, 18 Jun 2020 at 04:45, Xing Zhengjun
 wrote:








This bench forks a new thread for each and every new step. But a newly forked
threads start with a load_avg and a runnable_avg set to max whereas the threads
are running shortly before exiting. This makes the CPU to be set overloaded in
some case whereas it isn't.

Could you try the patch below ?
It fixes the problem on my setup (I have finally been able to reproduce the 
problem)

---
   kernel/sched/fair.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0ae62807..b33a4a9e1491 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -807,7 +807,7 @@ void post_init_entity_util_avg(struct task_struct *p)
  }
  }

-sa->runnable_avg = cpu_scale;
+sa->runnable_avg = sa->util_avg;

  if (p->sched_class != _sched_class) {
  /*
--
2.17.1



The patch above tries to move back to the group in the same classification as
before but this could harm other benchmarks.

There is another way to fix this by easing the migration of task in the case
of migrate_util imbalance.

Could you also try the patch below instead of the one above ?

---
   kernel/sched/fair.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0ae62807..fcaf66c4d086 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7753,7 +7753,8 @@ static int detach_tasks(struct lb_env *env)
   case migrate_util:
   util = task_util_est(p);

- if (util > env->imbalance)
+ if (util/2 > env->imbalance &&
+ env->sd->nr_balance_failed <= 
env->sd->cache_nice_tries)
   goto next;

   env->imbalance -= util;
--
2.17.1




I apply the patch based on v5.7, the test result is as the following:

=
tbox_group/testcase/rootfs/kconfig/compiler/runtime/nr_task/debug-setup/test/cpufreq_governor/ucode:

lkp-ivb-d04/reaim/debian-x86_64-20191114.cgz/x86_64-rhel-7.6/gcc-7/300s/100%/test/five_sec/performance/0x21

commit:
9f68395333ad7f5bfe2f83473fed363d4229f11c
070f5e860ee2bf588c99ef7b4c202451faa48236
v5.7
69c81543653bf5f2c7105086502889fa019c15cb  (the test patch)

9f68395333ad7f5b 070f5e860ee2bf588c99ef7b4c2v5.7
69c81543653bf5f2c7105086502
 --- ---
---
   %stddev %change %stddev %change
%stddev %change %stddev
   \  |\  |\
  |\
0.69   -10.3%   0.62-9.1%   0.62
-7.6%   0.63reaim.child_systime
0.62-1.0%   0.61+0.5%   0.62
+1.9%   0.63reaim.child_utime
   66870   -10.0%  60187-7.6%  61787
-5.9%  62947reaim.jobs_per_min


There is an improvement but not at the same level as on my setup.
I'm not sure with patch you tested here. Is it the last one that
modify detach_tasks() or the previous one that modify
post_init_entity_util_avg() ?


It is the last one that modify detach_tasks().


Could you also try the other one ? Both patches were improving results
on y setup but the behavior doesn't seem to be the same on your setup.



The test result for the other one has been sent in another mail.




   16717   -10.0%  15046-7.6%  15446
-5.9%  15736reaim.jobs_per_min_child
   97.84-1.1%  96.75-0.4%  97.43
-0.4%  97.47reaim.jti
   72000   -10.8%  64216-8.3%  66000
-5.7%  67885reaim.max_jobs_per_min
0.36   +10.6%   0.40+7.8%   0.39
+6.0%   0.38reaim.parent_time
1.58 ±  2% +71.0%   2.70 ±  2% +26.9%   2.01 ±
2% +23.6%   1.95 ±  3%  reaim.std_dev_percent
0.00 ±  5%+110.4%   0.01 ±  3% +48.8%   0.01 ±
7% +43.2%   0.01 ±  5%  reaim.std_dev_time
   50800-2.4%  49600-1.6%  5
-0.8%  50400reaim.workload






...


--
Zhengjun Xing


--
Zhengjun Xing


--
Zhengjun Xing


--
Zhengjun Xing


Re: [PATCH 2/2] Revert "checkpatch: kconfig: prefer 'help' over '---help---'"

2020-06-18 Thread Masahiro Yamada
On Wed, Jun 17, 2020 at 1:37 PM Joe Perches  wrote:
>
> On Wed, 2020-06-17 at 12:02 +0900, Masahiro Yamada wrote:
> > This reverts commit 84af7a6194e493fae312a2b7fa5a3b51f76d9282.
>
> Also: https://lore.kernel.org/patchwork/patch/1255848/
> ---

Yes, I removed --help-- support in 1/2.

https://patchwork.kernel.org/patch/11608927/



>  scripts/checkkconfigsymbols.py | 2 +-
>  scripts/checkpatch.pl  | 6 +-
>  scripts/kconfig/lexer.l| 2 +-
>  3 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/scripts/checkkconfigsymbols.py b/scripts/checkkconfigsymbols.py
> index 00a10a293f4f..1548f9ce4682 100755
> --- a/scripts/checkkconfigsymbols.py
> +++ b/scripts/checkkconfigsymbols.py
> @@ -34,7 +34,7 @@ REGEX_SOURCE_SYMBOL = re.compile(SOURCE_SYMBOL)
>  REGEX_KCONFIG_DEF = re.compile(DEF)
>  REGEX_KCONFIG_EXPR = re.compile(EXPR)
>  REGEX_KCONFIG_STMT = re.compile(STMT)
> -REGEX_KCONFIG_HELP = re.compile(r"^\s+(help|---help---)\s*$")
> +REGEX_KCONFIG_HELP = re.compile(r"^\s+help\s*$")
>  REGEX_FILTER_SYMBOLS = re.compile(r"[A-Za-z0-9]$")
>  REGEX_NUMERIC = re.compile(r"0[xX][0-9a-fA-F]+|[0-9]+")
>  REGEX_QUOTES = re.compile("(\"(.*?)\")")
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 524df88f9364..738bb3fcf202 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3044,11 +3044,7 @@ sub process {
>
> if ($lines[$ln - 1] =~ 
> /^\+\s*(?:bool|tristate|prompt)\s*["']/) {
> $is_start = 1;
> -   } elsif ($lines[$ln - 1] =~ 
> /^\+\s*(?:help|---help---)\s*$/) {
> -   if ($lines[$ln - 1] =~ "---help---") {
> -   WARN("CONFIG_DESCRIPTION",
> -"prefer 'help' over 
> '---help---' for new help texts\n" . $herecurr);
> -   }
> +   } elsif ($lines[$ln - 1] =~ /^\+\s*help\s*$/) 
> {
> $length = -1;
> }
>
> diff --git a/scripts/kconfig/lexer.l b/scripts/kconfig/lexer.l
> index 6354c905b006..4b7339ff4c8b 100644
> --- a/scripts/kconfig/lexer.l
> +++ b/scripts/kconfig/lexer.l
> @@ -105,7 +105,7 @@ n   [A-Za-z0-9_-]
>  "endchoice"return T_ENDCHOICE;
>  "endif"return T_ENDIF;
>  "endmenu"  return T_ENDMENU;
> -"help"|"---help---"return T_HELP;
> +"help" return T_HELP;
>  "hex"  return T_HEX;
>  "if"   return T_IF;
>  "imply"return T_IMPLY;
>
>


-- 
Best Regards
Masahiro Yamada


Re: BUG: unable to handle kernel paging request in sys_imageblit

2020-06-18 Thread syzbot
syzbot has found a reproducer for the following crash on:

HEAD commit:435faf5c Merge tag 'riscv-for-linus-5.8-mw0' of git://git...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1768c72510
kernel config:  https://syzkaller.appspot.com/x/.config?x=3dbb617b9c2a5bdf
dashboard link: https://syzkaller.appspot.com/bug?extid=33f89a9a6b6acd893b11
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
userspace arch: i386
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11f3f48510

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+33f89a9a6b6acd893...@syzkaller.appspotmail.com

BUG: unable to handle page fault for address: f520013df608
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD 7ffcd067 P4D 7ffcd067 PUD 2c920067 PMD 29858067 PTE 0
Oops:  [#1] PREEMPT SMP KASAN
CPU: 2 PID: 8457 Comm: syz-executor.0 Not tainted 5.7.0-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
RIP: 0010:fast_imageblit drivers/video/fbdev/core/sysimgblt.c:229 [inline]
RIP: 0010:sys_imageblit+0x616/0x1240 drivers/video/fbdev/core/sysimgblt.c:275
Code: 0f b6 14 28 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 5c 0b 00 
00 8b 44 24 20 4d 8d 77 04 4c 89 fa 48 c1 ea 03 23 07 <42> 0f b6 0c 2a 4c 89 fa 
83 e2 07 33 44 24 14 83 c2 03 38 ca 7c 08
RSP: 0018:c90001867578 EFLAGS: 00010246
RAX:  RBX: 888023ac8402 RCX: 88786a40
RDX: 1920013df608 RSI: 83c3bbbc RDI: 88786a40
RBP: 0fef R08: 888029cf8040 R09: 0001
R10: 8a8b743f R11: fbfff1516e87 R12: 0007
R13: dc00 R14: c90009efb044 R15: c90009efb040
FS:  () GS:88802d00(0063) knlGS:f7f0fb40
CS:  0010 DS: 002b ES: 002b CR0: 80050033
CR2: f520013df608 CR3: 1b812000 CR4: 00340ee0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 drm_fb_helper_sys_imageblit+0x1c/0x180 drivers/gpu/drm/drm_fb_helper.c:747
 bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:139 [inline]
 bit_putcs+0x8d0/0xd60 drivers/video/fbdev/core/bitblit.c:188
 fbcon_putcs+0x345/0x3f0 drivers/video/fbdev/core/fbcon.c:1362
 do_update_region+0x398/0x630 drivers/tty/vt/vt.c:683
 invert_screen+0x2a7/0x600 drivers/tty/vt/vt.c:800
 highlight drivers/tty/vt/selection.c:57 [inline]
 clear_selection drivers/tty/vt/selection.c:84 [inline]
 clear_selection+0x55/0x70 drivers/tty/vt/selection.c:80
 vc_do_resize+0xff3/0x1370 drivers/tty/vt/vt.c:1230
 fbcon_do_set_font+0x4a0/0x950 drivers/video/fbdev/core/fbcon.c:2608
 fbcon_set_font+0x732/0x870 drivers/video/fbdev/core/fbcon.c:2705
 con_font_set drivers/tty/vt/vt.c:4571 [inline]
 con_font_op+0xd65/0x1160 drivers/tty/vt/vt.c:4636
 compat_kdfontop_ioctl drivers/tty/vt/vt_ioctl.c:1151 [inline]
 vt_compat_ioctl+0x23a/0x6c0 drivers/tty/vt/vt_ioctl.c:1213
 tty_compat_ioctl+0x19c/0x410 drivers/tty/tty_io.c:2847
 __do_compat_sys_ioctl fs/ioctl.c:865 [inline]
 __se_compat_sys_ioctl fs/ioctl.c:816 [inline]
 __ia32_compat_sys_ioctl+0x23d/0x2b0 fs/ioctl.c:816
 do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline]
 do_fast_syscall_32+0x270/0xe90 arch/x86/entry/common.c:396
 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
Modules linked in:
CR2: f520013df608
---[ end trace fbceb2e52f6d552c ]---
RIP: 0010:fast_imageblit drivers/video/fbdev/core/sysimgblt.c:229 [inline]
RIP: 0010:sys_imageblit+0x616/0x1240 drivers/video/fbdev/core/sysimgblt.c:275
Code: 0f b6 14 28 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 5c 0b 00 
00 8b 44 24 20 4d 8d 77 04 4c 89 fa 48 c1 ea 03 23 07 <42> 0f b6 0c 2a 4c 89 fa 
83 e2 07 33 44 24 14 83 c2 03 38 ca 7c 08
RSP: 0018:c90001867578 EFLAGS: 00010246
RAX:  RBX: 888023ac8402 RCX: 88786a40
RDX: 1920013df608 RSI: 83c3bbbc RDI: 88786a40
RBP: 0fef R08: 888029cf8040 R09: 0001
R10: 8a8b743f R11: fbfff1516e87 R12: 0007
R13: dc00 R14: c90009efb044 R15: c90009efb040
FS:  () GS:88802d00(0063) knlGS:f7f0fb40
CS:  0010 DS: 002b ES: 002b CR0: 80050033
CR2: f520013df608 CR3: 1b812000 CR4: 00340ee0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400



Re: [LKP] [sched/fair] 070f5e860e: reaim.jobs_per_min -10.5% regression

2020-06-18 Thread Xing Zhengjun




On 6/17/2020 10:57 PM, Vincent Guittot wrote:

Le mercredi 17 juin 2020 à 08:30:21 (+0800), Xing Zhengjun a écrit :



On 6/16/2020 2:54 PM, Vincent Guittot wrote:


Hi Xing,

Le mardi 16 juin 2020 à 11:17:16 (+0800), Xing Zhengjun a écrit :



On 6/15/2020 4:10 PM, Vincent Guittot wrote:

Hi Xing,

Le lundi 15 juin 2020 à 15:26:59 (+0800), Xing Zhengjun a écrit :



On 6/12/2020 7:06 PM, Hillf Danton wrote:


On Fri, 12 Jun 2020 14:36:49 +0800 Xing Zhengjun wrote:




...





I apply the patch based on v5.7, the test result is as the following:


TBH, I didn't expect that the results would still be bad, so i wonder if the 
threshold are
the root problem.

Could you run tests with the patch below that removes condition with 
runnable_avg ?
I just want to make sure that those 2 conditions are the root cause.

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index da3e5b54715b..f5774d0af059 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8210,10 +8210,6 @@ group_has_capacity(unsigned int imbalance_pct, struct 
sg_lb_stats *sgs)
  if (sgs->sum_nr_running < sgs->group_weight)
  return true;

-   if ((sgs->group_capacity * imbalance_pct) <
-   (sgs->group_runnable * 100))
-   return false;
-
  if ((sgs->group_capacity * 100) >
  (sgs->group_util * imbalance_pct))
  return true;
@@ -8239,10 +8235,6 @@ group_is_overloaded(unsigned int imbalance_pct, struct 
sg_lb_stats *sgs)
  (sgs->group_util * imbalance_pct))
  return true;

-   if ((sgs->group_capacity * imbalance_pct) <
-   (sgs->group_runnable * 100))
-   return true;
-
  return false;
   }



Thanks.
Vincent




I apply the patch based on v5.7, the test result is as the following:

=
tbox_group/testcase/rootfs/kconfig/compiler/runtime/nr_task/debug-setup/test/cpufreq_governor/ucode:

lkp-ivb-d04/reaim/debian-x86_64-20191114.cgz/x86_64-rhel-7.6/gcc-7/300s/100%/test/five_sec/performance/0x21

commit:
   9f68395333ad7f5bfe2f83473fed363d4229f11c
   070f5e860ee2bf588c99ef7b4c202451faa48236
   v5.7
   63a5d0fbb5ec62f5148c251c01e709b8358cd0ee (the test patch)

9f68395333ad7f5b 070f5e860ee2bf588c99ef7b4c2v5.7
63a5d0fbb5ec62f5148c251c01e
 --- ---
---
  %stddev %change %stddev %change %stddev %change
%stddev
  \  |\  |\
|\
   0.69   -10.3%   0.62-9.1%   0.62
+1.0%   0.69reaim.child_systime
   0.62-1.0%   0.61+0.5%   0.62
-0.1%   0.62reaim.child_utime
  66870   -10.0%  60187-7.6%  61787
+1.1%  67636reaim.jobs_per_min
  16717   -10.0%  15046-7.6%  15446
+1.1%  16909reaim.jobs_per_min_child


OK. So the regression disappears when the conditions on runnable_avg are 
removed.

In the meantime, I have been able to understand more deeply what was happeningi
for this bench and how it is impacted by
   commit: 070f5e860ee2 ("sched/fair: Take into account runnable_avg to classify 
group")

This bench forks a new thread for each and every new step. But a newly forked
threads start with a load_avg and a runnable_avg set to max whereas the threads
are running shortly before exiting. This makes the CPU to be set overloaded in
some case whereas it isn't.

Could you try the patch below ?
It fixes the problem on my setup (I have finally been able to reproduce the 
problem)

---
  kernel/sched/fair.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0ae62807..b33a4a9e1491 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -807,7 +807,7 @@ void post_init_entity_util_avg(struct task_struct *p)
}
}
  
-	sa->runnable_avg = cpu_scale;

+   sa->runnable_avg = sa->util_avg;
  
  	if (p->sched_class != _sched_class) {

/*



I apply the patch above based on v5.7, the test result is as the following:

=
tbox_group/testcase/rootfs/kconfig/compiler/runtime/nr_task/debug-setup/test/cpufreq_governor/ucode:

lkp-ivb-d04/reaim/debian-x86_64-20191114.cgz/x86_64-rhel-7.6/gcc-7/300s/100%/test/five_sec/performance/0x21

commit:
  9f68395333ad7f5bfe2f83473fed363d4229f11c
  070f5e860ee2bf588c99ef7b4c202451faa48236
  v5.7
  cbb4d668e7431479a7978fa79d64c2271adefab0 ( the test patch which modify
post_init_entity_util_avg())

9f68395333ad7f5b 070f5e860ee2bf588c99ef7b4c2v5.7 

[PATCH 3/3] ALSA: compress: fix partial_drain completion state

2020-06-18 Thread Vinod Koul
On partial_drain completion we should be in SNDRV_PCM_STATE_RUNNING
state, so set that for partially draining streams in
snd_compr_drain_notify() and use a flag for partially draining streams

While at it, add locks for stream state change in
snd_compr_drain_notify() as well.

Fixes: f44f2a5417b2 ("ALSA: compress: fix drain calls blocking other compress 
functions (v6)")
Reported-by: Srinivas Kandagatla 
Signed-off-by: Vinod Koul 
---
 include/sound/compress_driver.h | 12 +++-
 sound/core/compress_offload.c   |  4 
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/include/sound/compress_driver.h b/include/sound/compress_driver.h
index 3df8d8c90191..93a5897201ea 100644
--- a/include/sound/compress_driver.h
+++ b/include/sound/compress_driver.h
@@ -66,6 +66,7 @@ struct snd_compr_runtime {
  * @direction: stream direction, playback/recording
  * @metadata_set: metadata set flag, true when set
  * @next_track: has userspace signal next track transition, true when set
+ * @partial_drain: undergoing partial_drain for stream, true when set
  * @private_data: pointer to DSP private data
  * @dma_buffer: allocated buffer if any
  */
@@ -78,6 +79,7 @@ struct snd_compr_stream {
enum snd_compr_direction direction;
bool metadata_set;
bool next_track;
+   bool partial_drain;
void *private_data;
struct snd_dma_buffer dma_buffer;
 };
@@ -187,7 +189,15 @@ static inline void snd_compr_drain_notify(struct 
snd_compr_stream *stream)
if (snd_BUG_ON(!stream))
return;
 
-   stream->runtime->state = SNDRV_PCM_STATE_SETUP;
+   mutex_lock(>device->lock);
+   /* for partial_drain case we are back to running state on success */
+   if (stream->partial_drain) {
+   stream->runtime->state = SNDRV_PCM_STATE_RUNNING;
+   stream->partial_drain = false; /* clear this flag as well */
+   } else {
+   stream->runtime->state = SNDRV_PCM_STATE_SETUP;
+   }
+   mutex_unlock(>device->lock);
 
wake_up(>runtime->sleep);
 }
diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c
index e618580feac4..1c4b2cf450a0 100644
--- a/sound/core/compress_offload.c
+++ b/sound/core/compress_offload.c
@@ -803,6 +803,9 @@ static int snd_compr_stop(struct snd_compr_stream *stream)
 
retval = stream->ops->trigger(stream, SNDRV_PCM_TRIGGER_STOP);
if (!retval) {
+   /* clear flags and stop any drain wait */
+   stream->partial_drain = false;
+   stream->metadata_set = false;
snd_compr_drain_notify(stream);
stream->runtime->total_bytes_available = 0;
stream->runtime->total_bytes_transferred = 0;
@@ -960,6 +963,7 @@ static int snd_compr_partial_drain(struct snd_compr_stream 
*stream)
if (stream->next_track == false)
return -EPERM;
 
+   stream->partial_drain = true;
retval = stream->ops->trigger(stream, SND_COMPR_TRIGGER_PARTIAL_DRAIN);
if (retval) {
pr_debug("Partial drain returned failure\n");
-- 
2.26.2



[PATCH 0/3] ALSA: compress: Document stream states and fix gaplless SM

2020-06-18 Thread Vinod Koul
Srini found issue with gapless implementation which prompted to look deeper
into SM for compressed stream.

So documenting SM was first step, so first two patches add that. Last patch
fixes the issue by keeping track on partial_drain and then moving state to
'running' in snd_compr_drain_notify() for partial_drain case on success.
While at it, noticed snd_compr_drain_notify() is lockless state change, so
fixed that as well.

I have tested this on Dragon board RB3, compressed audio works out of the
box on that platform and Srini will send driver and fcplay patches for
gapless soon.

Vinod Koul (3):
  ALSA: compress: document the compress audio state machine
  ALSA: compress: document the compress gapless audio state machine
  ALSA: compress: fix partial_drain completion state

 .../sound/designs/compress-offload.rst| 84 +++
 include/sound/compress_driver.h   | 12 ++-
 sound/core/compress_offload.c |  4 +
 3 files changed, 99 insertions(+), 1 deletion(-)

-- 
2.26.2



[PATCH 1/3] ALSA: compress: document the compress audio state machine

2020-06-18 Thread Vinod Koul
So we had some discussions of the stream states, so I thought it is a
good idea to document the state transitions, so add it documentation

Signed-off-by: Vinod Koul 
---
 .../sound/designs/compress-offload.rst| 52 +++
 1 file changed, 52 insertions(+)

diff --git a/Documentation/sound/designs/compress-offload.rst 
b/Documentation/sound/designs/compress-offload.rst
index ad4bfbdacc83..7292717c43bf 100644
--- a/Documentation/sound/designs/compress-offload.rst
+++ b/Documentation/sound/designs/compress-offload.rst
@@ -151,6 +151,58 @@ Modifications include:
 - Addition of encoding options when required (derived from OpenMAX IL)
 - Addition of rateControlSupported (missing in OpenMAX AL)
 
+State Machine
+=
+
+The compressed audio stream state machine is described below ::
+
++--+
+|  |
+|   OPEN   |
+|  |
++--+
+ |
+ |
+ | compr_set_params()
+ |
+ V
++--+
+compr_drain_notify()|  |
+  +>|   SETUP  |
+  | |  |
+  | +--+
+  |  |
+  |  |
+  |  | compr_write()
+  |  |
+  |  V
+  | +--+
+  | |  |
+  | |  PREPARE |
+  | |  |
+  | +--+
+  |  |
+  |  |
+  |  | compr_start()
+  |  |
+  |  V
++--++--+ compr_pause()  
+--+
+|  ||  |--->|  
|
+|  DRAIN   |<---|  RUNNING ||  
PAUSE   |
+|  ||  |<---|  
|
++--++--+ compr_resume() 
+--+
+  |  |
+  |  |
+  |  | compr_free()
+  |  |
+  |  V
+  | +--+
+  | compr_free()|  |
+  +>|  |
+|   STOP   |
+|  |
++--+
+
 
 Gapless Playback
 
-- 
2.26.2



[PATCH 2/3] ALSA: compress: document the compress gapless audio state machine

2020-06-18 Thread Vinod Koul
Also documented the galpess transitions. Please note that these are not
really stream states, but show how the stream steps in gapless mode

Signed-off-by: Vinod Koul 
---
 .../sound/designs/compress-offload.rst| 32 +++
 1 file changed, 32 insertions(+)

diff --git a/Documentation/sound/designs/compress-offload.rst 
b/Documentation/sound/designs/compress-offload.rst
index 7292717c43bf..3e241530e173 100644
--- a/Documentation/sound/designs/compress-offload.rst
+++ b/Documentation/sound/designs/compress-offload.rst
@@ -251,6 +251,38 @@ Sequence flow for gapless would be:
 
 (note: order for partial_drain and write for next track can be reversed as 
well)
 
+Gapless Playback SM
+===
+
+For Gapless, we move from running state to partial drain and back, along
+with setting of meta_data and signalling for next track ::
+
+
++--+
+compr_drain_notify()|  |
+  +>|  RUNNING |
+  | |  |
+  | +--+
+  |  |
+  |  |
+  |  | compr_next_track()
+  |  |
+  |  V
+  | +--+
+  | |  |
+  | |NEXT_TRACK|
+  | |  |
+  | +--+
+  |  |
+  |  |
+  |  | compr_partial_drain()
+  |  |
+  |  V
+  | +--+
+  | |  |
+  + | PARTIAL_ |
+|  DRAIN   |
++--+
 
 Not supported
 =
-- 
2.26.2



[PATCH] Revert "Makefile: install modules.builtin even if CONFIG_MODULES=n"

2020-06-18 Thread Masahiro Yamada
This reverts commit e0b250b57dcf403529081e5898a9de717f96b76b.

Now that "make install" copies modules.builtin to $(INSTALL_MOD_PATH),
it breaks systems that do not set INSTALL_MOD_PATH for "make install".

While modules.builtin is useful for CONFIG_MODULES=n, this way gives
unexpected impact to existing systems. Maybe "make modules_install"
can install modules.builtin irrespective of CONFIG_MODULES as Jonas
originally suggested. Anyway, this commit should be reverted ASAP.

Reported-by: Douglas Anderson 
Reported-by: Guenter Roeck 
Cc: Jonas Karlman 
Signed-off-by: Masahiro Yamada 
---

 Makefile | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/Makefile b/Makefile
index 29abe44ada91..9880e911afe3 100644
--- a/Makefile
+++ b/Makefile
@@ -1336,16 +1336,6 @@ dt_binding_check: scripts_dtc
 # ---
 # Modules
 
-# install modules.builtin regardless of CONFIG_MODULES
-PHONY += _builtin_inst_
-_builtin_inst_:
-   @mkdir -p $(MODLIB)/
-   @cp -f modules.builtin $(MODLIB)/
-   @cp -f $(objtree)/modules.builtin.modinfo $(MODLIB)/
-
-PHONY += install
-install: _builtin_inst_
-
 ifdef CONFIG_MODULES
 
 # By default, build modules as well
@@ -1389,7 +1379,7 @@ PHONY += modules_install
 modules_install: _modinst_ _modinst_post
 
 PHONY += _modinst_
-_modinst_: _builtin_inst_
+_modinst_:
@rm -rf $(MODLIB)/kernel
@rm -f $(MODLIB)/source
@mkdir -p $(MODLIB)/kernel
@@ -1399,6 +1389,8 @@ _modinst_: _builtin_inst_
ln -s $(CURDIR) $(MODLIB)/build ; \
fi
@sed 's:^:kernel/:' modules.order > $(MODLIB)/modules.order
+   @cp -f modules.builtin $(MODLIB)/
+   @cp -f $(objtree)/modules.builtin.modinfo $(MODLIB)/
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
 
 # This depmod is only for convenience to give the initial
-- 
2.25.1



[PATCH net 1/2] of: of_mdio: Correct loop scanning logic

2020-06-18 Thread Florian Fainelli
Commit 209c65b61d94 ("drivers/of/of_mdio.c:fix of_mdiobus_register()")
introduced a break of the loop on the premise that a successful
registration should exit the loop. The premise is correct but not to
code, because rc && rc != -ENODEV is just a special error condition,
that means we would exit the loop even with rc == -ENODEV which is
absolutely not correct since this is the error code to indicate to the
MDIO bus layer that scanning should continue.

Fix this by explicitly checking for rc = 0 as the only valid condition
to break out of the loop.

Fixes: 209c65b61d94 ("drivers/of/of_mdio.c:fix of_mdiobus_register()")
Signed-off-by: Florian Fainelli 
---
 drivers/of/of_mdio.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index a04afe79529c..7496dc64d6b5 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -315,9 +315,10 @@ int of_mdiobus_register(struct mii_bus *mdio, struct 
device_node *np)
 
if (of_mdiobus_child_is_phy(child)) {
rc = of_mdiobus_register_phy(mdio, child, addr);
-   if (rc && rc != -ENODEV)
+   if (!rc)
+   break;
+   if (rc != -ENODEV)
goto unregister;
-   break;
}
}
}
-- 
2.17.1



[PATCH net 0/2] net: phy: MDIO bus scanning fixes

2020-06-18 Thread Florian Fainelli
Hi all,

This patch series fixes two problems with the current MDIO bus scanning
logic which was identified while moving from 4.9 to 5.4 on devices that
do rely on scanning the MDIO bus at runtime because they use pluggable
cards.

Florian Fainelli (2):
  of: of_mdio: Correct loop scanning logic
  net: phy: Check harder for errors in get_phy_id()

 drivers/net/phy/phy_device.c | 6 --
 drivers/of/of_mdio.c | 5 +++--
 2 files changed, 7 insertions(+), 4 deletions(-)

-- 
2.17.1



[PATCH net 2/2] net: phy: Check harder for errors in get_phy_id()

2020-06-18 Thread Florian Fainelli
Commit 02a6efcab675 ("net: phy: allow scanning busses with missing
phys") added a special condition to return -ENODEV in case -ENODEV or
-EIO was returned from the first read of the MII_PHYSID1 register.

In case the MDIO bus data line pull-up is not strong enough, the MDIO
bus controller will not flag this as a read error. This can happen when
a pluggable daughter card is not connected and weak internal pull-ups
are used (since that is the only option, otherwise the pins are
floating).

The second read of MII_PHYSID2 will be correctly flagged an error
though, but now we will return -EIO which will be treated as a hard
error, thus preventing MDIO bus scanning loops to continue succesfully.

Apply the same logic to both register reads, thus allowing the scanning
logic to proceed.

Fixes: 02a6efcab675 ("net: phy: allow scanning busses with missing phys")
Signed-off-by: Florian Fainelli 
---
 drivers/net/phy/phy_device.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 04946de74fa0..85ba95b598b5 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -794,8 +794,10 @@ static int get_phy_id(struct mii_bus *bus, int addr, u32 
*phy_id,
 
/* Grab the bits from PHYIR2, and put them in the lower half */
phy_reg = mdiobus_read(bus, addr, MII_PHYSID2);
-   if (phy_reg < 0)
-   return -EIO;
+   if (phy_reg < 0) {
+   /* returning -ENODEV doesn't stop bus scanning */
+   return (phy_reg == -EIO || phy_reg == -ENODEV) ? -ENODEV : -EIO;
+   }
 
*phy_id |= phy_reg;
 
-- 
2.17.1



Re: treewide: replace '---help---' in Kconfig files with 'help'

2020-06-18 Thread Masahiro Yamada
On Mon, Jun 15, 2020 at 5:06 PM Geert Uytterhoeven  wrote:
>
> Hi Yamada-san,
>
> On Sat, 13 Jun 2020, Linux Kernel Mailing List wrote:
> > Commit: a7f7f6248d9740d710fd6bd190293fe5e16410ac
> > Parent: e4a42c82e943b97ce124539fcd7a47445b43fa0d
> > Refname:refs/heads/master
> > Web:
> > https://git.kernel.org/torvalds/c/a7f7f6248d9740d710fd6bd190293fe5e16410ac
> > Author: Masahiro Yamada 
> > AuthorDate: Sun Jun 14 01:50:22 2020 +0900
> > Committer:  Masahiro Yamada 
> > CommitDate: Sun Jun 14 01:57:21 2020 +0900
> >
> >treewide: replace '---help---' in Kconfig files with 'help'
> >
> >Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over
> >'---help---'"), the number of '---help---' has been gradually
> >decreasing, but there are still more than 2400 instances.
> >
> >This commit finishes the conversion. While I touched the lines,
> >I also fixed the indentation.
> >
> >There are a variety of indentation styles found.
> >
> >  a) 4 spaces + '---help---'
> >  b) 7 spaces + '---help---'
> >  c) 8 spaces + '---help---'
> >  d) 1 space + 1 tab + '---help---'
> >  e) 1 tab + '---help---'(correct indentation)
> >  f) 1 tab + 1 space + '---help---'
> >  g) 1 tab + 2 spaces + '---help---'
> >
> >In order to convert all of them to 1 tab + 'help', I ran the
> >following commend:
> >
> >  $ find . -name 'Kconfig*' | xargs sed -i 
> > 's/^[[:space:]]*---help---/\thelp/'
> >
> >Signed-off-by: Masahiro Yamada 
> > diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> > index 88b05b5256a9..1fa2fe2ef053 100644
> > --- a/arch/ia64/Kconfig
> > +++ b/arch/ia64/Kconfig
> > @@ -266,7 +266,7 @@ config PERMIT_BSP_REMOVE
> >   bool "Support removal of Bootstrap Processor"
> >   depends on HOTPLUG_CPU
> >   default n
> > - ---help---
> > + help
> >   Say Y here if your platform SAL will support removal of BSP with 
> > HOTPLUG_CPU
> >   support.
> >
> > @@ -274,7 +274,7 @@ config FORCE_CPEI_RETARGET
> >   bool "Force assumption that CPEI can be re-targeted"
> >   depends on PERMIT_BSP_REMOVE
> >   default n
> > - ---help---
> > + help
> >   Say Y if you need to force the assumption that CPEI can be 
> > re-targeted to
> >   any cpu in the system. This hint is available via ACPI 3.0 
> > specifications.
> >   Tiger4 systems are capable of re-directing CPEI to any CPU other than 
> > BSP.
>
> I guess help text blocks like the above should be indented?
> Unfortunately there are many of them.

Yes, the help body should be indented by 1 tab + 2 spaces,
which is documented in
Documentation/process/coding-style.rst

Since there are too many, I cannot fix them all.


> Thanks!
>
> 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



-- 
Best Regards
Masahiro Yamada


[PATCH v2 03/10] perf pmu: Add bison debug build flag

2020-06-18 Thread Ian Rogers
Allow pmu parser to be debugged as the parse-events and expr currently are.
Enabling this requires the C code to set perf_pmu_debug.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/Build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 4e1aa52d75a8..3ae4adc8e966 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -213,7 +213,7 @@ $(OUTPUT)util/pmu-flex.c: util/pmu.l 
$(OUTPUT)util/pmu-bison.c
 
 $(OUTPUT)util/pmu-bison.c: util/pmu.y
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,bison)$(BISON) -v $< -d -o $@ -p perf_pmu_
+   $(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) -o $@ 
-p perf_pmu_
 
 CFLAGS_parse-events-flex.o  += -w
 CFLAGS_pmu-flex.o   += -w
-- 
2.27.0.111.gc72c7da667-goog



[PATCH v2 08/10] perf expr: Avoid implicit lex function declaration

2020-06-18 Thread Ian Rogers
Add include and a dependency.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/Build  | 2 ++
 tools/perf/util/expr.y | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 53383bd6f4e2..43a9ae712544 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -211,6 +211,8 @@ $(OUTPUT)util/expr-bison.c $(OUTPUT)util/expr-bison.h: 
util/expr.y
$(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) \
-o $(OUTPUT)util/expr-bison.c -p expr_
 
+$(OUTPUT)util/expr-bison.o: $(OUTPUT)util/expr-flex.h
+
 $(OUTPUT)util/pmu-flex.c $(OUTPUT)util/pmu-flex.h: util/pmu.l 
$(OUTPUT)util/pmu-bison.c
$(call rule_mkdir)
$(Q)$(call echo-cmd,flex)$(FLEX) -o $(OUTPUT)util/pmu-flex.c \
diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
index bf3e898e3055..f34a5e544a41 100644
--- a/tools/perf/util/expr.y
+++ b/tools/perf/util/expr.y
@@ -39,6 +39,8 @@
 %type  expr if_expr
 
 %{
+#include "expr-flex.h"
+
 static void expr_error(double *final_val __maybe_unused,
   struct expr_parse_ctx *ctx __maybe_unused,
   void *scanner,
-- 
2.27.0.111.gc72c7da667-goog



[PATCH v2 10/10] perf parse-events: Disable a subset of bison warnings

2020-06-18 Thread Ian Rogers
Rather than disable all warnings with -w, disable specific warnings.
Predicate enabling the warnings on a recent version of bison.
Tested with GCC 9.3.0 and clang 9.0.1.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/Build | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 935ba132614c..c1692076469c 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -234,9 +234,17 @@ endif
 CFLAGS_parse-events-flex.o  += $(flex_flags)
 CFLAGS_pmu-flex.o   += $(flex_flags)
 CFLAGS_expr-flex.o  += $(flex_flags)
-CFLAGS_parse-events-bison.o += -DYYENABLE_NLS=0 -w
-CFLAGS_pmu-bison.o  += -DYYENABLE_NLS=0 -DYYLTYPE_IS_TRIVIAL=0 -w
-CFLAGS_expr-bison.o += -DYYENABLE_NLS=0 -DYYLTYPE_IS_TRIVIAL=0 -w
+
+bison_flags := -DYYENABLE_NLS=0
+BISON_GE_353 := $(shell expr $(shell $(BISON) --version | grep bison | sed -e 
's/.\+ \([0-9]\+\).\([0-9]\+\).\([0-9]\+\)/\1\2\3/g') \>\= 353)
+ifeq ($(BISON_GE_353),1)
+  bison_flags += -Wno-unused-parameter -Wno-nested-externs 
-Wno-error=implicit-function-declaration
+else
+  bison_flags += -w
+endif
+CFLAGS_parse-events-bison.o += $(bison_flags)
+CFLAGS_pmu-bison.o  += -DYYLTYPE_IS_TRIVIAL=0 $(bison_flags)
+CFLAGS_expr-bison.o += -DYYLTYPE_IS_TRIVIAL=0 $(bison_flags)
 
 $(OUTPUT)util/parse-events.o: $(OUTPUT)util/parse-events-flex.c 
$(OUTPUT)util/parse-events-bison.c
 $(OUTPUT)util/pmu.o: $(OUTPUT)util/pmu-flex.c $(OUTPUT)util/pmu-bison.c
-- 
2.27.0.111.gc72c7da667-goog



[PATCH v2 09/10] perf parse-events: Avoid implicit lex function declaration

2020-06-18 Thread Ian Rogers
Add include and a dependency.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/Build  | 2 ++
 tools/perf/util/parse-events.y | 1 +
 2 files changed, 3 insertions(+)

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 43a9ae712544..935ba132614c 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -201,6 +201,8 @@ $(OUTPUT)util/parse-events-bison.c 
$(OUTPUT)util/parse-events-bison.h: util/pars
$(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) \
-o $(OUTPUT)util/parse-events-bison.c -p parse_events_
 
+$(OUTPUT)util/parse-events-bison.o: $(OUTPUT)util/parse-events-flex.h
+
 $(OUTPUT)util/expr-flex.c $(OUTPUT)util/expr-flex.h: util/expr.l 
$(OUTPUT)util/expr-bison.c
$(call rule_mkdir)
$(Q)$(call echo-cmd,flex)$(FLEX) -o $(OUTPUT)util/expr-flex.c \
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index acef87d9af58..ae0aa47dbafb 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -17,6 +17,7 @@
 #include "evsel.h"
 #include "parse-events.h"
 #include "parse-events-bison.h"
+#include "parse-events-flex.h"
 
 void parse_events_error(YYLTYPE *loc, void *parse_state, void *scanner, char 
const *msg);
 
-- 
2.27.0.111.gc72c7da667-goog



[PATCH v2 02/10] perf parse-events: Use automatic variable for yacc input

2020-06-18 Thread Ian Rogers
This reduces the command line size slightly.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/Build | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 66cf009f78d8..4e1aa52d75a8 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -197,7 +197,7 @@ $(OUTPUT)util/parse-events-flex.c: util/parse-events.l 
$(OUTPUT)util/parse-event
 
 $(OUTPUT)util/parse-events-bison.c: util/parse-events.y
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,bison)$(BISON) -v util/parse-events.y -d 
$(PARSER_DEBUG_BISON) -o $@ -p parse_events_
+   $(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) -o $@ 
-p parse_events_
 
 $(OUTPUT)util/expr-flex.c: util/expr.l $(OUTPUT)util/expr-bison.c
$(call rule_mkdir)
@@ -205,7 +205,7 @@ $(OUTPUT)util/expr-flex.c: util/expr.l 
$(OUTPUT)util/expr-bison.c
 
 $(OUTPUT)util/expr-bison.c: util/expr.y
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,bison)$(BISON) -v util/expr.y -d 
$(PARSER_DEBUG_BISON) -o $@ -p expr_
+   $(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) -o $@ 
-p expr_
 
 $(OUTPUT)util/pmu-flex.c: util/pmu.l $(OUTPUT)util/pmu-bison.c
$(call rule_mkdir)
@@ -213,7 +213,7 @@ $(OUTPUT)util/pmu-flex.c: util/pmu.l 
$(OUTPUT)util/pmu-bison.c
 
 $(OUTPUT)util/pmu-bison.c: util/pmu.y
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,bison)$(BISON) -v util/pmu.y -d -o $@ -p perf_pmu_
+   $(Q)$(call echo-cmd,bison)$(BISON) -v $< -d -o $@ -p perf_pmu_
 
 CFLAGS_parse-events-flex.o  += -w
 CFLAGS_pmu-flex.o   += -w
-- 
2.27.0.111.gc72c7da667-goog



[PATCH v2 04/10] perf pmu: Add flex debug build flag

2020-06-18 Thread Ian Rogers
Allow pmu parser's flex to be debugged as the parse-events and
expr currently are. Enabling this requires the C code to call
perf_pmu__flex_debug.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/Build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 3ae4adc8e966..e63bfc46d50f 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -209,7 +209,7 @@ $(OUTPUT)util/expr-bison.c: util/expr.y
 
 $(OUTPUT)util/pmu-flex.c: util/pmu.l $(OUTPUT)util/pmu-bison.c
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,flex)$(FLEX) -o $@ 
--header-file=$(OUTPUT)util/pmu-flex.h $<
+   $(Q)$(call echo-cmd,flex)$(FLEX) -o $@ 
--header-file=$(OUTPUT)util/pmu-flex.h $(PARSER_DEBUG_FLEX) $<
 
 $(OUTPUT)util/pmu-bison.c: util/pmu.y
$(call rule_mkdir)
-- 
2.27.0.111.gc72c7da667-goog



[PATCH v2 06/10] perf parse-events: Declare bison header file output

2020-06-18 Thread Ian Rogers
Declare bison header file output so that C files can depend upon
them. As there are multiple output targets $@ is replaced by the
target name.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/Build | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 55c78ac53f04..504a6bb991ba 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -196,27 +196,30 @@ $(OUTPUT)util/parse-events-flex.c 
$(OUTPUT)util/parse-events-flex.h: util/parse-
$(Q)$(call echo-cmd,flex)$(FLEX) -o $(OUTPUT)util/parse-events-flex.c \
--header-file=$(OUTPUT)util/parse-events-flex.h 
$(PARSER_DEBUG_FLEX) $<
 
-$(OUTPUT)util/parse-events-bison.c: util/parse-events.y
+$(OUTPUT)util/parse-events-bison.c $(OUTPUT)util/parse-events-bison.h: 
util/parse-events.y
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) -o $@ 
-p parse_events_
+   $(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) \
+   -o $(OUTPUT)util/parse-events-bison.c -p parse_events_
 
 $(OUTPUT)util/expr-flex.c $(OUTPUT)util/expr-flex.h: util/expr.l 
$(OUTPUT)util/expr-bison.c
$(call rule_mkdir)
$(Q)$(call echo-cmd,flex)$(FLEX) -o $(OUTPUT)util/expr-flex.c \
--header-file=$(OUTPUT)util/expr-flex.h $(PARSER_DEBUG_FLEX) $<
 
-$(OUTPUT)util/expr-bison.c: util/expr.y
+$(OUTPUT)util/expr-bison.c $(OUTPUT)util/expr-bison.h: util/expr.y
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) -o $@ 
-p expr_
+   $(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) \
+   -o $(OUTPUT)util/expr-bison.c -p expr_
 
 $(OUTPUT)util/pmu-flex.c $(OUTPUT)util/pmu-flex.h: util/pmu.l 
$(OUTPUT)util/pmu-bison.c
$(call rule_mkdir)
$(Q)$(call echo-cmd,flex)$(FLEX) -o $(OUTPUT)util/pmu-flex.c \
--header-file=$(OUTPUT)util/pmu-flex.h $(PARSER_DEBUG_FLEX) $<
 
-$(OUTPUT)util/pmu-bison.c: util/pmu.y
+$(OUTPUT)util/pmu-bison.c $(OUTPUT)util/pmu-bison.h: util/pmu.y
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) -o $@ 
-p perf_pmu_
+   $(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) \
+   -o $(OUTPUT)util/pmu-bison.c -p perf_pmu_
 
 CFLAGS_parse-events-flex.o  += -w
 CFLAGS_pmu-flex.o   += -w
-- 
2.27.0.111.gc72c7da667-goog



[PATCH v2 01/10] perf parse-events: Use automatic variable for flex input

2020-06-18 Thread Ian Rogers
This reduces the command line size slightly.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/Build | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 8d18380ecd10..66cf009f78d8 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -193,7 +193,7 @@ CFLAGS_genelf_debug.o  += -Wno-packed
 
 $(OUTPUT)util/parse-events-flex.c: util/parse-events.l 
$(OUTPUT)util/parse-events-bison.c
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,flex)$(FLEX) -o $@ 
--header-file=$(OUTPUT)util/parse-events-flex.h $(PARSER_DEBUG_FLEX) 
util/parse-events.l
+   $(Q)$(call echo-cmd,flex)$(FLEX) -o $@ 
--header-file=$(OUTPUT)util/parse-events-flex.h $(PARSER_DEBUG_FLEX) $<
 
 $(OUTPUT)util/parse-events-bison.c: util/parse-events.y
$(call rule_mkdir)
@@ -201,7 +201,7 @@ $(OUTPUT)util/parse-events-bison.c: util/parse-events.y
 
 $(OUTPUT)util/expr-flex.c: util/expr.l $(OUTPUT)util/expr-bison.c
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,flex)$(FLEX) -o $@ 
--header-file=$(OUTPUT)util/expr-flex.h $(PARSER_DEBUG_FLEX) util/expr.l
+   $(Q)$(call echo-cmd,flex)$(FLEX) -o $@ 
--header-file=$(OUTPUT)util/expr-flex.h $(PARSER_DEBUG_FLEX) $<
 
 $(OUTPUT)util/expr-bison.c: util/expr.y
$(call rule_mkdir)
@@ -209,7 +209,7 @@ $(OUTPUT)util/expr-bison.c: util/expr.y
 
 $(OUTPUT)util/pmu-flex.c: util/pmu.l $(OUTPUT)util/pmu-bison.c
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,flex)$(FLEX) -o $@ 
--header-file=$(OUTPUT)util/pmu-flex.h util/pmu.l
+   $(Q)$(call echo-cmd,flex)$(FLEX) -o $@ 
--header-file=$(OUTPUT)util/pmu-flex.h $<
 
 $(OUTPUT)util/pmu-bison.c: util/pmu.y
$(call rule_mkdir)
-- 
2.27.0.111.gc72c7da667-goog



[PATCH v2 07/10] perf parse-events: Disable a subset of flex warnings

2020-06-18 Thread Ian Rogers
Rather than disable all warnings with -w, disable specific warnings.
Predicate enabling the warnings on more recent flex versions.
Tested with GCC 9.3.0 and clang 9.0.1.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/Build | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 504a6bb991ba..53383bd6f4e2 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -221,9 +221,15 @@ $(OUTPUT)util/pmu-bison.c $(OUTPUT)util/pmu-bison.h: 
util/pmu.y
$(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) \
-o $(OUTPUT)util/pmu-bison.c -p perf_pmu_
 
-CFLAGS_parse-events-flex.o  += -w
-CFLAGS_pmu-flex.o   += -w
-CFLAGS_expr-flex.o  += -w
+FLEX_GE_264 := $(shell expr $(shell $(FLEX) --version | sed -e  's/flex 
\([0-9]\+\).\([0-9]\+\).\([0-9]\+\)/\1\2\3/g') \>\= 264)
+ifeq ($(FLEX_GE_264),1)
+  flex_flags := -Wno-switch-enum -Wno-switch-default -Wno-unused-function 
-Wno-redundant-decls
+else
+  flex_flags := -w
+endif
+CFLAGS_parse-events-flex.o  += $(flex_flags)
+CFLAGS_pmu-flex.o   += $(flex_flags)
+CFLAGS_expr-flex.o  += $(flex_flags)
 CFLAGS_parse-events-bison.o += -DYYENABLE_NLS=0 -w
 CFLAGS_pmu-bison.o  += -DYYENABLE_NLS=0 -DYYLTYPE_IS_TRIVIAL=0 -w
 CFLAGS_expr-bison.o += -DYYENABLE_NLS=0 -DYYLTYPE_IS_TRIVIAL=0 -w
-- 
2.27.0.111.gc72c7da667-goog



[PATCH v2 05/10] perf parse-events: Declare flex header file output

2020-06-18 Thread Ian Rogers
Declare flex header file output so that bison C files can depend upon
them. As there are multiple output targets $@ is replaced by the target
name.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/Build | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index e63bfc46d50f..55c78ac53f04 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -191,25 +191,28 @@ CFLAGS_llvm-utils.o += 
-DPERF_INCLUDE_DIR="BUILD_STR($(perf_include_dir_SQ))"
 # avoid compiler warnings in 32-bit mode
 CFLAGS_genelf_debug.o  += -Wno-packed
 
-$(OUTPUT)util/parse-events-flex.c: util/parse-events.l 
$(OUTPUT)util/parse-events-bison.c
+$(OUTPUT)util/parse-events-flex.c $(OUTPUT)util/parse-events-flex.h: 
util/parse-events.l $(OUTPUT)util/parse-events-bison.c
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,flex)$(FLEX) -o $@ 
--header-file=$(OUTPUT)util/parse-events-flex.h $(PARSER_DEBUG_FLEX) $<
+   $(Q)$(call echo-cmd,flex)$(FLEX) -o $(OUTPUT)util/parse-events-flex.c \
+   --header-file=$(OUTPUT)util/parse-events-flex.h 
$(PARSER_DEBUG_FLEX) $<
 
 $(OUTPUT)util/parse-events-bison.c: util/parse-events.y
$(call rule_mkdir)
$(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) -o $@ 
-p parse_events_
 
-$(OUTPUT)util/expr-flex.c: util/expr.l $(OUTPUT)util/expr-bison.c
+$(OUTPUT)util/expr-flex.c $(OUTPUT)util/expr-flex.h: util/expr.l 
$(OUTPUT)util/expr-bison.c
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,flex)$(FLEX) -o $@ 
--header-file=$(OUTPUT)util/expr-flex.h $(PARSER_DEBUG_FLEX) $<
+   $(Q)$(call echo-cmd,flex)$(FLEX) -o $(OUTPUT)util/expr-flex.c \
+   --header-file=$(OUTPUT)util/expr-flex.h $(PARSER_DEBUG_FLEX) $<
 
 $(OUTPUT)util/expr-bison.c: util/expr.y
$(call rule_mkdir)
$(Q)$(call echo-cmd,bison)$(BISON) -v $< -d $(PARSER_DEBUG_BISON) -o $@ 
-p expr_
 
-$(OUTPUT)util/pmu-flex.c: util/pmu.l $(OUTPUT)util/pmu-bison.c
+$(OUTPUT)util/pmu-flex.c $(OUTPUT)util/pmu-flex.h: util/pmu.l 
$(OUTPUT)util/pmu-bison.c
$(call rule_mkdir)
-   $(Q)$(call echo-cmd,flex)$(FLEX) -o $@ 
--header-file=$(OUTPUT)util/pmu-flex.h $(PARSER_DEBUG_FLEX) $<
+   $(Q)$(call echo-cmd,flex)$(FLEX) -o $(OUTPUT)util/pmu-flex.c \
+   --header-file=$(OUTPUT)util/pmu-flex.h $(PARSER_DEBUG_FLEX) $<
 
 $(OUTPUT)util/pmu-bison.c: util/pmu.y
$(call rule_mkdir)
-- 
2.27.0.111.gc72c7da667-goog



Re: linux-next: Fixes tag needs some work in the pinctrl tree

2020-06-18 Thread Sivaprakash Murugesan

Hi Linus,

I just sent version2 of this patch with correct fixes tag. please pick 
it up.


Thanks,

Siva

On 6/16/2020 4:42 PM, Stephen Rothwell wrote:

Hi all,

In commit

   912f25eca000 ("pinctrl: qcom: ipq6018 Add missing pins in qpic pin group")

Fixes tag

   Fixes: ef1ea54 (pinctrl: qcom: Add ipq6018 pinctrl driver)

has these problem(s):

   - SHA1 should be at least 12 digits long
 Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
 or later) just making sure it is not set (or set to "auto").



[PATCH v2 00/10] perf parse-events: enable more flex/bison warnings

2020-06-18 Thread Ian Rogers
All C compiler warnings are disabled are disabled by -w. This change
removes the -w from flex and bison targets. To avoid implicit
declarations header files are declared as targets and included.

Tested with GCC 9.3.0 and clang 9.0.1.

v2. predicates disabling the warnings on more recent bison and flex
versions (3.5.3 and 2.6.4 respectively). An alternative would be
to disabled a large number of warnings to cover the warnings
generated in older distributions:
  flex_flags := -Wno-switch-enum -Wno-switch-default -Wno-unused-function \
-Wno-redundant-decls -Wno-sign-compare -Wno-unused-parameter \
-Wno-missing-prototypes -Wno-misleading-indentation
  bison_flags := -DYYENABLE_NLS=0 -Wno-unused-parameter -Wno-nested-externs \
-Wno-implicit-function-declaration -Wno-switch-enum

Previously posted as a single change:
https://lore.kernel.org/lkml/20200609234344.3795-2-irog...@google.com/

Ian Rogers (10):
  perf parse-events: Use automatic variable for flex input
  perf parse-events: Use automatic variable for yacc input
  perf pmu: Add bison debug build flag
  perf pmu: Add flex debug build flag
  perf parse-events: Declare flex header file output
  perf parse-events: Declare bison header file output
  perf parse-events: Disable a subset of flex warnings
  perf expr: Avoid implicit lex function declaration
  perf parse-events: Avoid implicit lex function declaration
  perf parse-events: Disable a subset of bison warnings

 tools/perf/util/Build  | 62 +++---
 tools/perf/util/expr.y |  2 ++
 tools/perf/util/parse-events.y |  1 +
 3 files changed, 46 insertions(+), 19 deletions(-)

-- 
2.27.0.111.gc72c7da667-goog



[PATCH V2] pinctrl: qcom: ipq6018 Add missing pins in qpic pin group

2020-06-18 Thread Sivaprakash Murugesan
The patch adds missing qpic data pins to qpic pingroup. These pins are
necessary for the qpic nand to work.

Fixes: ef1ea54eab0e ("pinctrl: qcom: Add ipq6018 pinctrl driver")
Signed-off-by: Sivaprakash Murugesan 
---
[V2]
 * Corrected Fixes tag
 drivers/pinctrl/qcom/pinctrl-ipq6018.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-ipq6018.c 
b/drivers/pinctrl/qcom/pinctrl-ipq6018.c
index 38c33a778cb8..ec50a3b4bd16 100644
--- a/drivers/pinctrl/qcom/pinctrl-ipq6018.c
+++ b/drivers/pinctrl/qcom/pinctrl-ipq6018.c
@@ -367,7 +367,8 @@ static const char * const wci20_groups[] = {
 
 static const char * const qpic_pad_groups[] = {
"gpio0", "gpio1", "gpio2", "gpio3", "gpio4", "gpio9", "gpio10",
-   "gpio11", "gpio17",
+   "gpio11", "gpio17", "gpio15", "gpio12", "gpio13", "gpio14", "gpio5",
+   "gpio6", "gpio7", "gpio8",
 };
 
 static const char * const burn0_groups[] = {
-- 
2.7.4



Re: [PATCH 2/2] riscv: Use PUD/PGDIR entries for linear mapping when possible

2020-06-18 Thread Alex Ghiti

Hi Atish,

Le 6/18/20 à 8:47 PM, Atish Patra a écrit :

On Wed, Jun 3, 2020 at 8:38 AM Alexandre Ghiti  wrote:

Improve best_map_size so that PUD or PGDIR entries are used for linear
mapping when possible as it allows better TLB utilization.

Signed-off-by: Alexandre Ghiti 
---
  arch/riscv/mm/init.c | 45 +---
  1 file changed, 34 insertions(+), 11 deletions(-)

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 9a5c97e091c1..d275f9f834cf 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -424,13 +424,29 @@ static void __init create_pgd_mapping(pgd_t *pgdp,
 create_pgd_next_mapping(nextp, va, pa, sz, prot);
  }

-static uintptr_t __init best_map_size(phys_addr_t base, phys_addr_t size)
+static bool is_map_size_ok(uintptr_t map_size, phys_addr_t base,
+  uintptr_t base_virt, phys_addr_t size)
  {
-   /* Upgrade to PMD_SIZE mappings whenever possible */
-   if ((base & (PMD_SIZE - 1)) || (size & (PMD_SIZE - 1)))
-   return PAGE_SIZE;
+   return !((base & (map_size - 1)) || (base_virt & (map_size - 1)) ||
+   (size < map_size));
+}
+
+static uintptr_t __init best_map_size(phys_addr_t base, uintptr_t base_virt,
+ phys_addr_t size)
+{
+#ifndef __PAGETABLE_PMD_FOLDED
+   if (is_map_size_ok(PGDIR_SIZE, base, base_virt, size))
+   return PGDIR_SIZE;
+
+   if (pgtable_l4_enabled)
+   if (is_map_size_ok(PUD_SIZE, base, base_virt, size))
+   return PUD_SIZE;
+#endif
+
+   if (is_map_size_ok(PMD_SIZE, base, base_virt, size))
+   return PMD_SIZE;

-   return PMD_SIZE;
+   return PAGE_SIZE;
  }

  /*
@@ -576,7 +592,7 @@ void create_kernel_page_table(pgd_t *pgdir, uintptr_t 
map_size)
  asmlinkage void __init setup_vm(uintptr_t dtb_pa)
  {
 uintptr_t va, end_va;
-   uintptr_t map_size = best_map_size(load_pa, MAX_EARLY_MAPPING_SIZE);
+   uintptr_t map_size;

 load_pa = (uintptr_t)(&_start);
 load_sz = (uintptr_t)(&_end) - load_pa;
@@ -587,6 +603,7 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)

 kernel_virt_addr = KERNEL_VIRT_ADDR;

+   map_size = best_map_size(load_pa, PAGE_OFFSET, MAX_EARLY_MAPPING_SIZE);
 va_pa_offset = PAGE_OFFSET - load_pa;
 va_kernel_pa_offset = kernel_virt_addr - load_pa;
 pfn_base = PFN_DOWN(load_pa);
@@ -700,6 +717,8 @@ static void __init setup_vm_final(void)

 /* Map all memory banks */
 for_each_memblock(memory, reg) {
+   uintptr_t remaining_size;
+
 start = reg->base;
 end = start + reg->size;

@@ -707,15 +726,19 @@ static void __init setup_vm_final(void)
 break;
 if (memblock_is_nomap(reg))
 continue;
-   if (start <= __pa(PAGE_OFFSET) &&
-   __pa(PAGE_OFFSET) < end)
-   start = __pa(PAGE_OFFSET);

-   map_size = best_map_size(start, end - start);
-   for (pa = start; pa < end; pa += map_size) {
+   pa = start;
+   remaining_size = reg->size;
+
+   while (remaining_size) {
 va = (uintptr_t)__va(pa);
+   map_size = best_map_size(pa, va, remaining_size);
+
 create_pgd_mapping(swapper_pg_dir, va, pa,
map_size, PAGE_KERNEL);
+
+   pa += map_size;
+   remaining_size -= map_size;
 }
 }


This may not work in the RV32 with 2G memory  and if the map_size is
determined to be a page size
for the last memblock. Both pa & remaining_size will overflow and the
loop will try to map memory from zero again.


I'm not sure I understand: if pa starts at 0x8000_ and size is 2G, 
then pa will overflow in the last iteration, but remaining_size will 
then be equal to 0 right ?


And by the way, I realize that this loop only handles sizes that are 
aligned on map_size.


Thanks,

Alex





--
2.20.1






Re: [PATCH] soc: qcom: rpmh: Remove serialization of TCS commands

2020-06-18 Thread Doug Anderson
Hi,

On Fri, May 29, 2020 at 3:52 AM Maulik Shah  wrote:
>
> From: Lina Iyer 
>
> Requests sent to RPMH can be sent as fire-n-forget or response required,
> with the latter ensuring the command has been completed by the hardware
> accelerator. Commands in a request with tcs_cmd::wait set, would ensure
> that those select commands are sent as response required, even though
> the actual TCS request may be fire-n-forget.
>
> Also, commands with .wait flag were also guaranteed to be complete
> before the following command in the TCS is sent. This means that the
> next command of the same request blocked until the current request is
> completed. This could mean waiting for a voltage to settle or series of
> NOCs be configured before the next command is sent. But drivers using
> this feature have never cared about the serialization aspect. By not
> enforcing the serialization we can allow the hardware to run in parallel
> improving the performance.
>
> Let's clarify the usage of this member in the tcs_cmd structure to mean
> only completion and not serialization. This should also improve the
> performance of bus requests where changes could happen in parallel.
> Also, CPU resume from deep idle may see benefits from certain wake
> requests.
>
> Signed-off-by: Lina Iyer 

You are posting the patch and so you need your SoB too.


> ---
>  drivers/soc/qcom/rpmh-rsc.c | 19 ---
>  include/soc/qcom/tcs.h  |  5 +++--
>  2 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
> index 076fd27..d99e639 100644
> --- a/drivers/soc/qcom/rpmh-rsc.c
> +++ b/drivers/soc/qcom/rpmh-rsc.c
> @@ -413,8 +413,7 @@ static irqreturn_t tcs_tx_done(int irq, void *p)
> cmd = >cmds[j];
> sts = read_tcs_cmd(drv, RSC_DRV_CMD_STATUS, i, j);
> if (!(sts & CMD_STATUS_ISSUED) ||
> -  ((req->wait_for_compl || cmd->wait) &&
> -  !(sts & CMD_STATUS_COMPL))) {
> +  (cmd->wait && !(sts & CMD_STATUS_COMPL))) {

I don't quite understand this part of the change.  Why don't you need
to check "req->wait_for_compl" anymore?  You are still setting
"CMD_MSGID_RESP_REQ" if "req->wait_for_compl" is set and none of the
code in your patch actually sets "cmd->wait" (unlike what's implied in
your change to the header file).  Maybe some previous version of the
patch _was_ actually setting "cmd->wait" and when you stopped doing
that you forgot to restore this part of the change?


> pr_err("Incomplete request: %s: addr=%#x 
> data=%#x",
>drv->name, cmd->addr, cmd->data);
> err = -EIO;
> @@ -433,7 +432,6 @@ static irqreturn_t tcs_tx_done(int irq, void *p)
>  skip:
> /* Reclaim the TCS */
> write_tcs_reg(drv, RSC_DRV_CMD_ENABLE, i, 0);
> -   write_tcs_reg(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, i, 0);

Should you also be removing the write to RSC_DRV_CMD_WAIT_FOR_CMPL in
both tcs_write() and tcs_invalidate()?  Those are the only two places
left that set this register and they both always set it to 0.


> writel_relaxed(BIT(i), drv->tcs_base + RSC_DRV_IRQ_CLEAR);
> spin_lock(>lock);
> clear_bit(i, drv->tcs_in_use);
> @@ -465,23 +463,23 @@ static irqreturn_t tcs_tx_done(int irq, void *p)
>  static void __tcs_buffer_write(struct rsc_drv *drv, int tcs_id, int cmd_id,
>const struct tcs_request *msg)
>  {
> -   u32 msgid, cmd_msgid;
> +   u32 msgid;
> +   u32 cmd_msgid = CMD_MSGID_LEN | CMD_MSGID_WRITE;
> u32 cmd_enable = 0;
> -   u32 cmd_complete;
> struct tcs_cmd *cmd;
> int i, j;
>
> -   cmd_msgid = CMD_MSGID_LEN;
> +   /* Convert all commands to RR when the request has wait_for_compl set 
> */
> cmd_msgid |= msg->wait_for_compl ? CMD_MSGID_RESP_REQ : 0;
> -   cmd_msgid |= CMD_MSGID_WRITE;
> -
> -   cmd_complete = read_tcs_reg(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, tcs_id);
>
> for (i = 0, j = cmd_id; i < msg->num_cmds; i++, j++) {
> cmd = >cmds[i];
> cmd_enable |= BIT(j);
> -   cmd_complete |= cmd->wait << j;
> msgid = cmd_msgid;
> +   /*
> +* Additionally, if the cmd->wait is set, make the command
> +* response reqd even if the overall request was 
> fire-n-forget.
> +*/
> msgid |= cmd->wait ? CMD_MSGID_RESP_REQ : 0;
>
> write_tcs_cmd(drv, RSC_DRV_CMD_MSGID, tcs_id, j, msgid);
> @@ -490,7 +488,6 @@ static void __tcs_buffer_write(struct rsc_drv *drv, int 
> tcs_id, int cmd_id,
> trace_rpmh_send_msg_rcuidle(drv, tcs_id, j, msgid, cmd);
> }
>
> -   write_tcs_reg(drv, 

Re: [PATCH v3] exfat: remove EXFAT_SB_DIRTY flag

2020-06-18 Thread Tetsuhiro Kohada

I mentioned rmdir as an example.
However, this problem is not only with rmdirs.
VOL_DIRTY remains when some functions abort with an error.
In original, VOL_DIRTY is not cleared even if performe 'sync'.
With this patch, it ensures that VOL_DIRTY will be cleared by 'sync'.

Is my description insufficient?


I understood what you said. However, it is a natural result
when deleting the related code with EXFAT_SB_DIRTY flag.

So I thought it would be better to separate it into new problems
related to VOL_DIRTY-set under not real errors.


I see.
It seems that it is better to consider separately when consistency is corrupted 
and when it is kept.


BTW
Even with this patch applied,  VOL_DIRTY remains until synced in the above
case.
It's not  easy to reproduce as rmdir, but I'll try to fix it in the future.


I think it's not a problem not to clear VOL_DIRTY under real errors,
because VOL_DIRTY is just like a hint to note that write was not finished 
clearly.

If you mean there are more situation like ENOTEMPTY you mentioned,
please make new patch to fix them.


Hmm.
VOL_DIRTY is easily cleared by another write operation.
For that purpose, I think MediaFailure is more appropriate.

BR
---
Tetsuhiro Kohada 


Re: [PATCH v3] HID: i2c-hid: Enable touchpad wakeup from Suspend-to-Idle

2020-06-18 Thread Kai-Heng Feng
Hi,

> On Jun 18, 2020, at 23:28, Hans de Goede  wrote:
> 
> Hi,
> 
> On 6/18/20 4:55 PM, Kai-Heng Feng wrote:
>> Many laptops can be woken up from Suspend-to-Idle by touchpad. This is
>> also the default behavior on other OSes.
>> So let's enable the wakeup support if the system defaults to
>> Suspend-to-Idle.
> 
> I have been debugging a spurious wakeup issue on an Asus T101HA,
> where the system would not stay suspended when the lid was closed.
> 
> The issue turns out to be that the touchpad is generating touch
> events when the lid/display gets close to the touchpad. In this case
> wakeup is already enabled by default because it is an USB device.

Sounds like a mechanical/hardware issue to me.
I've seen some old laptops have the same issue.

Swollen battery can push up the touchpad, makes it contact to touchscreen, and 
wakes up the system.

> 
> So I do not believe that this is a good idea, most current devices
> with a HID multi-touch touchpad use i2c-hid and also use S2idle,
> so this will basically enable wakeup by touchpad on almost all
> current devices.

However, it's really handy to wake up the system from touchpad.

> 
> There will likely be other devices with the same issue as the T101HA,
> but currently we are not seeing this issue because by default i2c-hid
> devices do not have wakeup enabled. This change will thus likely cause
> new spurious wakeup issues on more devices. So this seems like a
> bad idea.

But only under lid is closed?

I wonder if it's okay to handle the case in s2idle_loop() or in userspace?
Lid close -> Wakeup event from touchpad -> Found the lid is closed 
-> Turn off touchpad wakeup -> continue suspend.

> 
> Also your commit message mentions touchpads, but the change
> will also enable wakeup on most touchscreens out there, meaning
> that just picking up a device in tablet mode and accidentally
> touching the screen will wake it up.

I tried touch and i2c-hid touchscreen and it doesn't wake up the system.
However we should still handle the two different cases, probably differentiate 
touchpad and touchscreen in hid-multitouch.

> 
> Also hid multi-touch devices have 3 modes, see the diagrams
> in Microsoft hw design guides for win8/10 touch devices:
> 1. Reporting events with low latency (high power mode)
> 2. Reporting events with high latency (lower power mode)
> 3. Not reporting events (lowest power mode)
> 
> I actually still need to write some patches for hid-multitouch.c
> to set the mode to 2 or 3 on suspend depending on the device_may_wakeup
> setting of the parent. Once that patch is written, it should
> put most i2c-hid mt devices in mode 3, hopefully also helping
> with Linux' relative high power consumption when a device is
> suspended. With your change instead my to-be-written patch
> would put the device in mode 2, which would still be an
> improvement but less so.

IIRC, touchpad and touchscreen connect to different parents on all laptops I 
worked on.
So I think it's possible to enable mode 2 for touchpad, and mode 3 for 
touchscreen.

Touchpad wake is really handy, let's figure out how to enable it while covering 
all potential regression risks.

Kai-Heng

> 
> Regards,
> 
> Hans
> 
> 
> 
> 
> 
> 
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> v3:
>>  - Use device_init_wakeup().
>>  - Wording change.
>> v2:
>>  - Fix compile error when ACPI is not enabled.
>>  drivers/hid/i2c-hid/i2c-hid-core.c | 10 ++
>>  1 file changed, 10 insertions(+)
>> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c 
>> b/drivers/hid/i2c-hid/i2c-hid-core.c
>> index 294c84e136d7..dae1d072daf6 100644
>> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
>> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
>> @@ -931,6 +931,12 @@ static void i2c_hid_acpi_fix_up_power(struct device 
>> *dev)
>>  acpi_device_fix_up_power(adev);
>>  }
>>  +static void i2c_hid_acpi_enable_wakeup(struct device *dev)
>> +{
>> +if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0)
>> +device_init_wakeup(dev, true);
>> +}
>> +
>>  static const struct acpi_device_id i2c_hid_acpi_match[] = {
>>  {"ACPI0C50", 0 },
>>  {"PNP0C50", 0 },
>> @@ -945,6 +951,8 @@ static inline int i2c_hid_acpi_pdata(struct i2c_client 
>> *client,
>>  }
>>static inline void i2c_hid_acpi_fix_up_power(struct device *dev) {}
>> +
>> +static inline void i2c_hid_acpi_enable_wakeup(struct device *dev) {}
>>  #endif
>>#ifdef CONFIG_OF
>> @@ -1072,6 +1080,8 @@ static int i2c_hid_probe(struct i2c_client *client,
>>  i2c_hid_acpi_fix_up_power(>dev);
>>  +   i2c_hid_acpi_enable_wakeup(>dev);
>> +
>>  device_enable_async_suspend(>dev);
>>  /* Make sure there is something at this address */
> 



Re: [kbuild-all] security/integrity/ima/ima_crypto.c:575:12: warning: stack frame size of 1152 bytes in function 'ima_calc_field_array_hash_tfm'

2020-06-18 Thread Herbert Xu
On Fri, Jun 19, 2020 at 10:43:22AM +0800, Rong Chen wrote:
> 
> Could you take a look at this warning? Roberto mentioned you in previous
> report:
> https://lore.kernel.org/linux-integrity/9dbec9465bda4f8995a42593eb0db...@huawei.com/

Well having a shash descriptor on the stack is always pushing
the envelope.  Doing it when you put another 256-byte string is
obviously not a good idea.  The good thing is that the string
isn't necessary, so how about:

---8<---
The function ima_calc_field_array_hash_tfm uses a stack descriptor
for shash.  As hashing requires a large amount of space this means
that you shouldn't put any other large data on the stack at the same
time, for example, you definitely shouldn't put a 256-byte string
which you're going to hash on the stack.

Luckily this string is mostly composed of zeroes so we could just
use ZERO_PAGE instead.

Reported-by: kbuild test robot 
Signed-off-by: Herbert Xu 

diff --git a/security/integrity/ima/ima_crypto.c 
b/security/integrity/ima/ima_crypto.c
index 220b14920c37..0a925d1a1bf7 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -11,6 +11,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -605,11 +606,11 @@ static int ima_calc_field_array_hash_tfm(struct 
ima_field_data *field_data,
return rc;
 
for (i = 0; i < num_fields; i++) {
-   u8 buffer[IMA_EVENT_NAME_LEN_MAX + 1] = { 0 };
u8 *data_to_hash = field_data[i].data;
u32 datalen = field_data[i].len;
u32 datalen_to_hash =
!ima_canonical_fmt ? datalen : cpu_to_le32(datalen);
+   u32 padlen = 0;
 
if (strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
rc = crypto_shash_update(shash,
@@ -617,14 +618,21 @@ static int ima_calc_field_array_hash_tfm(struct 
ima_field_data *field_data,
sizeof(datalen_to_hash));
if (rc)
break;
-   } else if (strcmp(td->fields[i]->field_id, "n") == 0) {
-   memcpy(buffer, data_to_hash, datalen);
-   data_to_hash = buffer;
-   datalen = IMA_EVENT_NAME_LEN_MAX + 1;
-   }
+   } else if (strcmp(td->fields[i]->field_id, "n") == 0 &&
+  datalen < IMA_EVENT_NAME_LEN_MAX + 1)
+   padlen = IMA_EVENT_NAME_LEN_MAX + 1 - datalen;
+
rc = crypto_shash_update(shash, data_to_hash, datalen);
if (rc)
break;
+
+   if (padlen) {
+   const u8 *zero = page_address(ZERO_PAGE(0));
+
+   rc = crypto_shash_update(shash, zero, padlen);
+   if (rc)
+   break;
+   }
}
 
if (!rc)
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


[rcu:rcu/next] BUILD SUCCESS 2cb3e01520e4c6cd28ac8301e4616c62c313a833

2020-06-18 Thread kernel test robot
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  rcu/next
branch HEAD: 2cb3e01520e4c6cd28ac8301e4616c62c313a833  lib/test_vmalloc.c: Add 
test cases for kvfree_rcu()

elapsed time: 721m

configs tested: 80
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
i386  allnoconfig
i386defconfig
i386  debian-10.3
i386 allyesconfig
ia64defconfig
ia64  allnoconfig
ia64 allmodconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nios2allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allmodconfig
xtensa  defconfig
h8300allyesconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips  allnoconfig
mips allyesconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
powerpc defconfig
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
um   allmodconfig
x86_64   rhel-7.6
x86_64rhel-7.6-kselftests
x86_64   rhel-8.3
x86_64  kexec
x86_64   rhel
x86_64 rhel-7.2-clear
x86_64lkp
x86_64  fedora-25

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


Re: [PATCH net] net: dsa: bcm_sf2: Fix node reference count

2020-06-18 Thread David Miller
From: Florian Fainelli 
Date: Wed, 17 Jun 2020 20:42:44 -0700

> of_find_node_by_name() will do an of_node_put() on the "from" argument.
> With CONFIG_OF_DYNAMIC enabled which checks for device_node reference
> counts, we would be getting a warning like this:
 ...
> Fix this by adding a of_node_get() to increment the reference count
> prior to the call.
> 
> Fixes: afa3b592953b ("net: dsa: bcm_sf2: Ensure correct sub-node is parsed")
> Signed-off-by: Florian Fainelli 

Applied and queued up for v5.7 -stable, thanks.


Re: [PATCH 0/5] net: hns3: a bundle of minor cleanup and fixes

2020-06-18 Thread David Miller
From: Barry Song 
Date: Thu, 18 Jun 2020 13:02:06 +1200

> some minor changes to either improve the readability or make the code align
> with linux APIs better.

Series applied, thanks.


Re: [PATCHv2] tpm: ibmvtpm: Wait for ready buffer before probing for TPM2 attributes

2020-06-18 Thread Jerry Snitselaar

On Fri Jun 19 20, David Gibson wrote:

The tpm2_get_cc_attrs_tbl() call will result in TPM commands being issued,
which will need the use of the internal command/response buffer.  But,
we're issuing this *before* we've waited to make sure that buffer is
allocated.

This can result in intermittent failures to probe if the hypervisor / TPM
implementation doesn't respond quickly enough.  I find it fails almost
every time with an 8 vcpu guest under KVM with software emulated TPM.

To fix it, just move the tpm2_get_cc_attrs_tlb() call after the
existing code to wait for initialization, which will ensure the buffer
is allocated.

Fixes: 18b3670d79ae9 ("tpm: ibmvtpm: Add support for TPM2")
Signed-off-by: David Gibson 
---


Reviewed-by: Jerry Snitselaar 



Changes from v1:
* Fixed a formatting error in the commit message
* Added some more detail to the commit message

drivers/char/tpm/tpm_ibmvtpm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 09fe45246b8cc..994385bf37c0c 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -683,13 +683,6 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
if (rc)
goto init_irq_cleanup;

-   if (!strcmp(id->compat, "IBM,vtpm20")) {
-   chip->flags |= TPM_CHIP_FLAG_TPM2;
-   rc = tpm2_get_cc_attrs_tbl(chip);
-   if (rc)
-   goto init_irq_cleanup;
-   }
-
if (!wait_event_timeout(ibmvtpm->crq_queue.wq,
ibmvtpm->rtce_buf != NULL,
HZ)) {
@@ -697,6 +690,13 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
goto init_irq_cleanup;
}

+   if (!strcmp(id->compat, "IBM,vtpm20")) {
+   chip->flags |= TPM_CHIP_FLAG_TPM2;
+   rc = tpm2_get_cc_attrs_tbl(chip);
+   if (rc)
+   goto init_irq_cleanup;
+   }
+
return tpm_chip_register(chip);
init_irq_cleanup:
do {
--
2.26.2





Re: common KUnit Kconfig and file naming (was: Re: [PATCH] lib: kunit_test_overflow: add KUnit test of check_*_overflow functions)

2020-06-18 Thread Kees Cook
On Thu, Jun 18, 2020 at 01:27:55PM -0700, Brendan Higgins wrote:
> I am cool with changing *-test.c to *-kunit.c. The *-test.c was a hold

I am fine with basically any decision as long as there's a single naming
convention, *except* for this part. Dashes in source files creates
confusion for module naming. Separators should be underscores. This is
a standing pet-peeve of mine, and while I certainly can't fix it
universally in the kernel, we can at least avoid creating an entire
subsystem that gets this wrong for all modules. :)

To illustrate:

$ modinfo dvb-bt8xx
filename: .../kernel/drivers/media/pci/bt8xx/dvb-bt8xx.ko
...
name:   dvb_bt8xx
   ^ does not match the .ko file, nor source.

Primarily my issue is the disconnect between "dmesg" output and finding
the source. It's not like, a huge deal, but it bugs me. :) As in:

$ strings drivers/media/pci/bt8xx/dvb-bt8xx.o | grep 'Init Error'
4dvb_bt8xx: or51211: Init Error - Can't Reset DVR (%i)


All this said, if there really is some good reason to use dashes, I will
get over it. :P

(And now that I've had to say all this "out loud", I wonder if maybe I
could actually fix this all at the root cause: KBUILD_MOD_NAME... it is
sometimes used for identifiers, which is why it does the underscore
replacement... I wonder if it could be split into "name" and
"identifier"...)

-- 
Kees Cook


Re: [PATCH][next] mISDN: hfcsusb: Use struct_size() helper

2020-06-18 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Wed, 17 Jun 2020 18:15:57 -0500

> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
> 
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied, thanks.


Re: [PATCH] lan743x: allow mac address to come from dt

2020-06-18 Thread David Miller
From: Tim Harvey 
Date: Wed, 17 Jun 2020 15:59:10 -0700

> If a valid mac address is present in dt, use that before using
> CSR's or a random mac address.
> 
> Signed-off-by: Tim Harvey 

Applied to net-next, thanks.


Re: [PATCH resend net] net: ethtool: add missing NETIF_F_GSO_FRAGLIST feature string

2020-06-18 Thread David Miller
From: Alexander Lobakin 
Date: Wed, 17 Jun 2020 20:42:47 +

> Commit 3b33583265ed ("net: Add fraglist GRO/GSO feature flags") missed
> an entry for NETIF_F_GSO_FRAGLIST in netdev_features_strings array. As
> a result, fraglist GSO feature is not shown in 'ethtool -k' output and
> can't be toggled on/off.
> The fix is trivial.
> 
> Fixes: 3b33583265ed ("net: Add fraglist GRO/GSO feature flags")
> Signed-off-by: Alexander Lobakin 

Applied and queued up for v5.6 -stable, thank you.


Re: [PATCH][next] enetc: Use struct_size() helper in kzalloc()

2020-06-18 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Wed, 17 Jun 2020 13:53:17 -0500

> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
> 
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied to net-next, thanks.


Re: [PATCH v2] tg3: driver sleeps indefinitely when EEH errors exceed eeh_max_freezes

2020-06-18 Thread David Miller
From: David Christensen 
Date: Wed, 17 Jun 2020 11:51:17 -0700

> The driver function tg3_io_error_detected() calls napi_disable twice,
> without an intervening napi_enable, when the number of EEH errors exceeds
> eeh_max_freezes, resulting in an indefinite sleep while holding rtnl_lock.
> 
> Add check for pcierr_recovery which skips code already executed for the
> "Frozen" state.
> 
> Signed-off-by: David Christensen 

Applied and queued up for -stable, thanks.


Re: severe proc dentry lock contention

2020-06-18 Thread Eric W. Biederman
Junxiao Bi  writes:

> On 6/18/20 5:02 PM, ebied...@xmission.com wrote:
>
>> Matthew Wilcox  writes:
>>
>>> On Thu, Jun 18, 2020 at 03:17:33PM -0700, Junxiao Bi wrote:
 When debugging some performance issue, i found that thousands of threads
 exit around same time could cause a severe spin lock contention on proc
 dentry "/proc/$parent_process_pid/task/", that's because threads needs to
 clean up their pid file from that dir when exit. Check the following
 standalone test case that simulated the case and perf top result on v5.7
 kernel. Any idea on how to fix this?
>>> Thanks, Junxiao.
>>>
>>> We've looked at a few different ways of fixing this problem.
>>>
>>> Even though the contention is within the dcache, it seems like a usecase
>>> that the dcache shouldn't be optimised for -- generally we do not have
>>> hundreds of CPUs removing dentries from a single directory in parallel.
>>>
>>> We could fix this within procfs.  We don't have a great patch yet, but
>>> the current approach we're looking at allows only one thread at a time
>>> to call dput() on any /proc/*/task directory.
>>>
>>> We could also look at fixing this within the scheduler.  Only allowing
>>> one CPU to run the threads of an exiting process would fix this particular
>>> problem, but might have other consequences.
>>>
>>> I was hoping that 7bc3e6e55acf would fix this, but that patch is in 5.7,
>>> so that hope is ruled out.
>> Does anyone know if problem new in v5.7?  I am wondering if I introduced
>> this problem when I refactored the code or if I simply churned the code
>> but the issue remains effectively the same.
> It's not new issue, we see it in old kernel like v4.14
>>
>> Can you try only flushing entries when the last thread of the process is
>> reaped?  I think in practice we would want to be a little more
>> sophisticated but it is a good test case to see if it solves the issue.
>
> Thank you. i will try and let you know.

Assuming this works we can remove the hacking part of always doing
this by only doing this if SIGNAL_GROUP_EXIT when we know this
thundering herd will appear.

We still need to do something with the list however.

If your testing works out performance wise I will figure out what
we need to make the hack generale and safe.

Eric



> Thanks,
>
> Junxiao.
>
>>
>> diff --git a/kernel/exit.c b/kernel/exit.c
>> index cebae77a9664..d56e4eb60bdd 100644
>> --- a/kernel/exit.c
>> +++ b/kernel/exit.c
>> @@ -152,7 +152,7 @@ void put_task_struct_rcu_user(struct task_struct *task)
>>   void release_task(struct task_struct *p)
>>   {
>>  struct task_struct *leader;
>> -struct pid *thread_pid;
>> +struct pid *thread_pid = NULL;
>>  int zap_leader;
>>   repeat:
>>  /* don't need to get the RCU readlock here - the process is dead and
>> @@ -165,7 +165,8 @@ void release_task(struct task_struct *p)
>>  write_lock_irq(_lock);
>>  ptrace_release_task(p);
>> -thread_pid = get_pid(p->thread_pid);
>> +if (p == p->group_leader)
>> +thread_pid = get_pid(p->thread_pid);
>>  __exit_signal(p);
>>  /*
>> @@ -188,8 +189,10 @@ void release_task(struct task_struct *p)
>>  }
>>  write_unlock_irq(_lock);
>> -proc_flush_pid(thread_pid);
>> -put_pid(thread_pid);
>> +if (thread_pid) {
>> +proc_flush_pid(thread_pid);
>> +put_pid(thread_pid);
>> +}
>>  release_thread(p);
>>  put_task_struct_rcu_user(p);
>>   


Re: [PATCH net-next v8 5/5] net: phy: DP83822: Add setting the fixed internal delay

2020-06-18 Thread kernel test robot
Hi Dan,

I love your patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Dan-Murphy/RGMII-Internal-delay-common-property/20200619-051238
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
cb8e59cc87201af93dfbb6c3dccc8fcad72a09c2
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
487ca07fcc75d52755c9fe2ee05bcb3b6c44)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> drivers/net/phy/dp83822.c:284:7: warning: variable 'rgmii_delay' is used 
>> uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (rx_int_delay <= 0)
^
drivers/net/phy/dp83822.c:296:7: note: uninitialized use occurs here
if (rgmii_delay) {
^~~
drivers/net/phy/dp83822.c:284:3: note: remove the 'if' if its condition is 
always false
if (rx_int_delay <= 0)
^~
drivers/net/phy/dp83822.c:276:17: note: initialize the variable 'rgmii_delay' 
to silence this warning
int rgmii_delay;
^
= 0
1 warning generated.

vim +284 drivers/net/phy/dp83822.c

   272  
   273  static int dp83822_config_init(struct phy_device *phydev)
   274  {
   275  struct device *dev = >mdio.dev;
   276  int rgmii_delay;
   277  s32 rx_int_delay;
   278  s32 tx_int_delay;
   279  int err = 0;
   280  
   281  if (phy_interface_is_rgmii(phydev)) {
   282  rx_int_delay = phy_get_internal_delay(phydev, dev, 
NULL, 0,
   283true);
 > 284  if (rx_int_delay <= 0)
   285  rx_int_delay = 0;
   286  else
   287  rgmii_delay = DP83822_RX_CLK_SHIFT;
   288  
   289  tx_int_delay = phy_get_internal_delay(phydev, dev, 
NULL, 0,
   290false);
   291  if (tx_int_delay <= 0)
   292  tx_int_delay = 0;
   293  else
   294  rgmii_delay |= DP83822_TX_CLK_SHIFT;
   295  
   296  if (rgmii_delay) {
   297  err = phy_set_bits_mmd(phydev, DP83822_DEVADDR,
   298 MII_DP83822_RCSR, 
rgmii_delay);
   299  if (err)
   300  return err;
   301  }
   302  }
   303  
   304  return dp8382x_disable_wol(phydev);
   305  }
   306  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


[PATCHv2] tpm: ibmvtpm: Wait for ready buffer before probing for TPM2 attributes

2020-06-18 Thread David Gibson
The tpm2_get_cc_attrs_tbl() call will result in TPM commands being issued,
which will need the use of the internal command/response buffer.  But,
we're issuing this *before* we've waited to make sure that buffer is
allocated.

This can result in intermittent failures to probe if the hypervisor / TPM
implementation doesn't respond quickly enough.  I find it fails almost
every time with an 8 vcpu guest under KVM with software emulated TPM.

To fix it, just move the tpm2_get_cc_attrs_tlb() call after the
existing code to wait for initialization, which will ensure the buffer
is allocated.

Fixes: 18b3670d79ae9 ("tpm: ibmvtpm: Add support for TPM2")
Signed-off-by: David Gibson 
---

Changes from v1:
 * Fixed a formatting error in the commit message
 * Added some more detail to the commit message
 
drivers/char/tpm/tpm_ibmvtpm.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 09fe45246b8cc..994385bf37c0c 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -683,13 +683,6 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
if (rc)
goto init_irq_cleanup;
 
-   if (!strcmp(id->compat, "IBM,vtpm20")) {
-   chip->flags |= TPM_CHIP_FLAG_TPM2;
-   rc = tpm2_get_cc_attrs_tbl(chip);
-   if (rc)
-   goto init_irq_cleanup;
-   }
-
if (!wait_event_timeout(ibmvtpm->crq_queue.wq,
ibmvtpm->rtce_buf != NULL,
HZ)) {
@@ -697,6 +690,13 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
goto init_irq_cleanup;
}
 
+   if (!strcmp(id->compat, "IBM,vtpm20")) {
+   chip->flags |= TPM_CHIP_FLAG_TPM2;
+   rc = tpm2_get_cc_attrs_tbl(chip);
+   if (rc)
+   goto init_irq_cleanup;
+   }
+
return tpm_chip_register(chip);
 init_irq_cleanup:
do {
-- 
2.26.2



RE: [PATCH v2 1/3] docs: IOMMU user API

2020-06-18 Thread Liu, Yi L
Hi Alex,

> From: Alex Williamson 
> Sent: Friday, June 19, 2020 10:55 AM
> 
> On Fri, 19 Jun 2020 02:15:36 +
> "Liu, Yi L"  wrote:
> 
> > Hi Alex,
> >
> > > From: Alex Williamson 
> > > Sent: Friday, June 19, 2020 5:48 AM
> > >
> > > On Wed, 17 Jun 2020 08:28:24 +
> > > "Tian, Kevin"  wrote:
> > >
> > > > > From: Liu, Yi L 
> > > > > Sent: Wednesday, June 17, 2020 2:20 PM
> > > > >
> > > > > > From: Jacob Pan 
> > > > > > Sent: Tuesday, June 16, 2020 11:22 PM
> > > > > >
> > > > > > On Thu, 11 Jun 2020 17:27:27 -0700 Jacob Pan
> > > > > >  wrote:
> > > > > >
> > > > > > > >
> > > > > > > > But then I thought it even better if VFIO leaves the
> > > > > > > > entire
> > > > > > > > copy_from_user() to the layer consuming it.
> > > > > > > >
> > > > > > > OK. Sounds good, that was what Kevin suggested also. I just
> > > > > > > wasn't sure how much VFIO wants to inspect, I thought VFIO
> > > > > > > layer wanted to do a sanity check.
> > > > > > >
> > > > > > > Anyway, I will move copy_from_user to iommu uapi layer.
> > > > > >
> > > > > > Just one more point brought up by Yi when we discuss this offline.
> > > > > >
> > > > > > If we move copy_from_user to iommu uapi layer, then there will
> > > > > > be
> > > > > multiple
> > > > > > copy_from_user calls for the same data when a VFIO container
> > > > > > has
> > > > > multiple domains,
> > > > > > devices. For bind, it might be OK. But might be additional
> > > > > > overhead for TLB
> > > > > flush
> > > > > > request from the guest.
> > > > >
> > > > > I think it is the same with bind and TLB flush path. will be
> > > > > multiple copy_from_user.
> > > >
> > > > multiple copies is possibly fine. In reality we allow only one
> > > > group per nesting container (as described in patch [03/15]), and
> > > > usually there is just one SVA-capable device per group.
> > > >
> > > > >
> > > > > BTW. for moving data copy to iommy layer, there is another point
> > > > > which need to consider. VFIO needs to do unbind in bind path if
> > > > > bind failed, so it will assemble unbind_data and pass to iommu
> > > > > layer. If iommu layer do the copy_from_user, I think it will be 
> > > > > failed. any
> idea?
> > >
> > > If a call into a UAPI fails, there should be nothing to undo.
> > > Creating a partial setup for a failed call that needs to be undone
> > > by the caller is not good practice.
> >
> > is it still a problem if it's the VFIO to undo the partial setup
> > before returning to user space?
> 
> Yes.  If a UAPI function fails there should be no residual effect.

ok. the iommu_sva_bind_gpasid() is per device call. There is no residual
effect if it failed. so no partial setup will happen per device.

but VFIO needs to use iommu_group_for_each_dev() to do bind, so
if iommu_group_for_each_dev() failed, I guess VFIO needs to undo
the partial setup for the group. right?

> > > > This might be mitigated if we go back to use the same bind_data
> > > > for both bind/unbind. Then you can reuse the user object for unwinding.
> > > >
> > > > However there is another case where VFIO may need to assemble the
> > > > bind_data itself. When a VM is killed, VFIO needs to walk
> > > > allocated PASIDs and unbind them one-by-one. In such case
> > > > copy_from_user doesn't work since the data is created by kernel.
> > > > Alex, do you have a suggestion how this usage can be supported?
> > > > e.g. asking IOMMU driver to provide two sets of APIs to handle 
> > > > user/kernel
> generated requests?
> > >
> > > Yes, it seems like vfio would need to make use of a driver API to do
> > > this, we shouldn't be faking a user buffer in the kernel in order to
> > > call through to a UAPI.  Thanks,
> >
> > ok, so if VFIO wants to issue unbind by itself, it should use an API
> > which passes kernel buffer to IOMMU layer. If the unbind request is
> > from user space, then VFIO should use another API which passes user
> > buffer pointer to IOMMU layer. makes sense. will align with jacob.
> 
> Sounds right to me.  Different approaches might be used for the driver API 
> versus
> the UAPI, perhaps there is no buffer.  Thanks,

thanks for your coaching. It may require Jacob to add APIs in iommu layer
for the two purposes.

Regards,
Yi Liu

> Alex



Re: [PATCH] clk: imx: vf610: add CAAM clock

2020-06-18 Thread Chris Healy
On a Vybrid VF610 based platform I tested this with 5.8-rc1.  With the
necessary DTS patch, the CAAM worked correctly for me.

Tested-by: Chris Healy 

On Mon, Jun 1, 2020 at 4:06 PM Andrey Smirnov  wrote:
>
> According to Vybrid Security RM, CCM_CCGR11[CG176] can be used to gate
> CAAM ipg clock.
>
> Signed-off-by: Horia Geantă 
> Signed-off-by: Andrey Smirnov 
> Cc: Chris Healy 
> Cc: Shawn Guo 
> Cc: Fabio Estevam 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@nxp.com
> ---
>  drivers/clk/imx/clk-vf610.c | 1 +
>  include/dt-bindings/clock/vf610-clock.h | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
> index cd04e7dc1878..5129ef8e1d6e 100644
> --- a/drivers/clk/imx/clk-vf610.c
> +++ b/drivers/clk/imx/clk-vf610.c
> @@ -438,6 +438,7 @@ static void __init vf610_clocks_init(struct device_node 
> *ccm_node)
> clk[VF610_CLK_SNVS] = imx_clk_gate2("snvs-rtc", "ipg_bus", CCM_CCGR6, 
> CCM_CCGRx_CGn(7));
> clk[VF610_CLK_DAP] = imx_clk_gate("dap", "platform_bus", CCM_CCSR, 
> 24);
> clk[VF610_CLK_OCOTP] = imx_clk_gate("ocotp", "ipg_bus", CCM_CCGR6, 
> CCM_CCGRx_CGn(5));
> +   clk[VF610_CLK_CAAM] = imx_clk_gate2("caam", "ipg_bus", CCM_CCGR11, 
> CCM_CCGRx_CGn(0));
>
> imx_check_clocks(clk, ARRAY_SIZE(clk));
>
> diff --git a/include/dt-bindings/clock/vf610-clock.h 
> b/include/dt-bindings/clock/vf610-clock.h
> index 95394f35a74a..0f2d60e884dc 100644
> --- a/include/dt-bindings/clock/vf610-clock.h
> +++ b/include/dt-bindings/clock/vf610-clock.h
> @@ -195,6 +195,7 @@
>  #define VF610_CLK_WKPU 186
>  #define VF610_CLK_TCON0187
>  #define VF610_CLK_TCON1188
> -#define VF610_CLK_END  189
> +#define VF610_CLK_CAAM 189
> +#define VF610_CLK_END  190
>
>  #endif /* __DT_BINDINGS_CLOCK_VF610_H */
> --
> 2.21.3


Re: [PATCH 0/3] kcsan: Re-add GCC support, and compiler flags improvements

2020-06-18 Thread Paul E. McKenney
On Thu, Jun 18, 2020 at 11:31:15AM +0200, Marco Elver wrote:
> Re-add GCC as a supported compiler and clean up compiler flags.
> 
> To use KCSAN with GCC before GCC 11 is released, the following will get
> a stable GCC 10 and cherry-pick the patches required for KCSAN support:
> 
>   git clone git://gcc.gnu.org/git/gcc.git && cd gcc
>   git checkout -b gcc-10-for-kcsan releases/gcc-10.1.0
>   git cherry-pick \
>   4089df8ef4a63126b0774c39b6638845244c20d2 \
>   ab2789ec507a94f1a75a6534bca51c7b39037ce0 \
>   06712fc68dc9843d9af7c7ac10047f49d305ad76
>   ./configure --prefix  --enable-languages=c,c++
>   make -j$(nproc) && make install

Unless there are objections, I will pull this in Friday (tomorrow)
afternoon, Pacific Time.

Thanx, Paul

> Marco Elver (3):
>   kcsan: Re-add GCC as a supported compiler
>   kcsan: Simplify compiler flags
>   kcsan: Disable branch tracing in core runtime
> 
>  Documentation/dev-tools/kcsan.rst | 3 ++-
>  kernel/kcsan/Makefile | 4 ++--
>  lib/Kconfig.kcsan | 3 ++-
>  scripts/Makefile.kcsan| 2 +-
>  4 files changed, 7 insertions(+), 5 deletions(-)
> 
> -- 
> 2.27.0.290.gba653c62da-goog
> 


Re: [PATCH 6/7] rcutorture: Add support to get the number of wakeups of main GP kthread

2020-06-18 Thread Paul E. McKenney
On Thu, Jun 18, 2020 at 09:00:12PM -0400, Joel Fernandes wrote:
> On Thu, Jun 18, 2020 at 05:12:44PM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 18, 2020 at 08:01:56PM -0400, Joel Fernandes wrote:
> > > On Thu, Jun 18, 2020 at 03:40:58PM -0700, Paul E. McKenney wrote:
> > > > On Thu, Jun 18, 2020 at 04:29:54PM -0400, Joel Fernandes (Google) wrote:
> > > > > This is useful to check for any improvements or degradation related to
> > > > > number of GP kthread wakeups during testing.
> > > > > 
> > > > > Signed-off-by: Joel Fernandes (Google) 
> > > > 
> > > > This was a good way to collect the data for your testing, but
> > > > we can expect rcutorture to only do so much.  ;-)
> > > 
> > > np, I will push this one into a git tag for the next time I need it ;)
> > 
> > Sounds like a plan!
> 
> In case it is at all an option, I could put this as a statistic under
> rcu_torture_stats_print(), that way it all is on the same line. But I take it
> you are not too thrilled to have it for now.

The thing is that rcutorture is a stress test, not a performance or
energy-efficiency test.  So rcutorture will continue to wake things
up just to brutalize RCU, which makes such a statistic less helpful.

It might be something for rcuperf/rcuscale, although it is not clear that
a pure performance/scalability test would give a useful read on wakeups.
I would expect better results from a more random real-world workload.

But I bet that people already have this sort of thing set up.  For
example, doesn't kbuild test robot track this sort of thing?

Thanx, Paul

> thanks,
> 
>  - Joel
> 
> 
> 
> > Thanx, Paul
> > 
> > > thanks,
> > > 
> > >  - Joel
> > > 
> > > 
> > > > Thanx, Paul
> > > > 
> > > > > ---
> > > > >  kernel/rcu/Kconfig.debug |  1 +
> > > > >  kernel/rcu/rcu.h |  2 ++
> > > > >  kernel/rcu/rcutorture.c  | 23 ++-
> > > > >  kernel/rcu/tree.c|  7 +++
> > > > >  4 files changed, 32 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/kernel/rcu/Kconfig.debug b/kernel/rcu/Kconfig.debug
> > > > > index 3cf6132a4bb9f..3323e3378af5a 100644
> > > > > --- a/kernel/rcu/Kconfig.debug
> > > > > +++ b/kernel/rcu/Kconfig.debug
> > > > > @@ -50,6 +50,7 @@ config RCU_TORTURE_TEST
> > > > >   select TASKS_RCU
> > > > >   select TASKS_RUDE_RCU
> > > > >   select TASKS_TRACE_RCU
> > > > > + select SCHEDSTATS
> > > > >   default n
> > > > >   help
> > > > > This option provides a kernel module that runs torture tests
> > > > > diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> > > > > index cf66a3ccd7573..7e867e81d9738 100644
> > > > > --- a/kernel/rcu/rcu.h
> > > > > +++ b/kernel/rcu/rcu.h
> > > > > @@ -511,6 +511,7 @@ srcu_batches_completed(struct srcu_struct *sp) { 
> > > > > return 0; }
> > > > >  static inline void rcu_force_quiescent_state(void) { }
> > > > >  static inline void show_rcu_gp_kthreads(void) { }
> > > > >  static inline int rcu_get_gp_kthreads_prio(void) { return 0; }
> > > > > +static inline struct task_struct *rcu_get_main_gp_kthread(void) { 
> > > > > return 0; }
> > > > >  static inline void rcu_fwd_progress_check(unsigned long j) { }
> > > > >  #else /* #ifdef CONFIG_TINY_RCU */
> > > > >  bool rcu_dynticks_zero_in_eqs(int cpu, int *vp);
> > > > > @@ -519,6 +520,7 @@ unsigned long rcu_exp_batches_completed(void);
> > > > >  unsigned long srcu_batches_completed(struct srcu_struct *sp);
> > > > >  void show_rcu_gp_kthreads(void);
> > > > >  int rcu_get_gp_kthreads_prio(void);
> > > > > +struct task_struct *rcu_get_main_gp_kthread(void);
> > > > >  void rcu_fwd_progress_check(unsigned long j);
> > > > >  void rcu_force_quiescent_state(void);
> > > > >  extern struct workqueue_struct *rcu_gp_wq;
> > > > > diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> > > > > index d0d265304d147..959a1f84d6904 100644
> > > > > --- a/kernel/rcu/rcutorture.c
> > > > > +++ b/kernel/rcu/rcutorture.c
> > > > > @@ -23,6 +23,7 @@
> > > > >  #include 
> > > > >  #include 
> > > > >  #include 
> > > > > +#include 
> > > > >  #include 
> > > > >  #include 
> > > > >  #include 
> > > > > @@ -460,9 +461,29 @@ static void rcu_sync_torture_init(void)
> > > > >   INIT_LIST_HEAD(_torture_removed);
> > > > >  }
> > > > >  
> > > > > +unsigned long rcu_gp_nr_wakeups;
> > > > > +
> > > > > +static void rcu_flavor_init(void)
> > > > > +{
> > > > > + rcu_sync_torture_init();
> > > > > +
> > > > > + /* Make sure schedstat is enabled for GP thread wakeup count. */
> > > > > + force_schedstat_enabled();
> > > > > + rcu_gp_nr_wakeups = 
> > > > > rcu_get_main_gp_kthread()->se.statistics.nr_wakeups;
> > > > > +}
> > > > > +
> > > > > +static void rcu_flavor_cleanup(void)
> > > > > +{
> > > > > + unsigned long now_nr = 
> > > > > 

[PATCH v3 1/2] fs: Break generic_file_buffered_read up into multiple functions

2020-06-18 Thread Kent Overstreet
This is prep work for changing generic_file_buffered_read() to use
find_get_pages_contig() to batch up all the pagecache lookups.

This patch should be functionally identical to the existing code and
changes as little as of the flow control as possible. More refactoring
could be done, this patch is intended to be relatively minimal.

Signed-off-by: Kent Overstreet 
---
 mm/filemap.c | 418 ---
 1 file changed, 228 insertions(+), 190 deletions(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index 23a051a7ef..dc4a72042e 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1975,6 +1975,210 @@ static void shrink_readahead_size_eio(struct 
file_ra_state *ra)
ra->ra_pages /= 4;
 }
 
+static int generic_file_buffered_read_page_ok(struct kiocb *iocb,
+   struct iov_iter *iter,
+   struct page *page)
+{
+   struct address_space *mapping = iocb->ki_filp->f_mapping;
+   struct inode *inode = mapping->host;
+   struct file_ra_state *ra = >ki_filp->f_ra;
+   unsigned int offset = iocb->ki_pos & ~PAGE_MASK;
+   unsigned int bytes, copied;
+   loff_t isize, end_offset;
+
+   BUG_ON(iocb->ki_pos >> PAGE_SHIFT != page->index);
+
+   /*
+* i_size must be checked after we know the page is Uptodate.
+*
+* Checking i_size after the check allows us to calculate
+* the correct value for "bytes", which means the zero-filled
+* part of the page is not copied back to userspace (unless
+* another truncate extends the file - this is desired though).
+*/
+
+   isize = i_size_read(inode);
+   if (unlikely(iocb->ki_pos >= isize))
+   return 1;
+
+   end_offset = min_t(loff_t, isize, iocb->ki_pos + iter->count);
+
+   bytes = min_t(loff_t, end_offset - iocb->ki_pos, PAGE_SIZE - offset);
+
+   /* If users can be writing to this page using arbitrary
+* virtual addresses, take care about potential aliasing
+* before reading the page on the kernel side.
+*/
+   if (mapping_writably_mapped(mapping))
+   flush_dcache_page(page);
+
+   /*
+* Ok, we have the page, and it's up-to-date, so
+* now we can copy it to user space...
+*/
+
+   copied = copy_page_to_iter(page, offset, bytes, iter);
+
+   iocb->ki_pos += copied;
+
+   /*
+* When a sequential read accesses a page several times,
+* only mark it as accessed the first time.
+*/
+   if (iocb->ki_pos >> PAGE_SHIFT != ra->prev_pos >> PAGE_SHIFT)
+   mark_page_accessed(page);
+
+   ra->prev_pos = iocb->ki_pos;
+
+   if (copied < bytes)
+   return -EFAULT;
+
+   return !iov_iter_count(iter) || iocb->ki_pos == isize;
+}
+
+static struct page *
+generic_file_buffered_read_readpage(struct file *filp,
+   struct address_space *mapping,
+   struct page *page)
+{
+   struct file_ra_state *ra = >f_ra;
+   int error;
+
+   /*
+* A previous I/O error may have been due to temporary
+* failures, eg. multipath errors.
+* PG_error will be set again if readpage fails.
+*/
+   ClearPageError(page);
+   /* Start the actual read. The read will unlock the page. */
+   error = mapping->a_ops->readpage(filp, page);
+
+   if (unlikely(error)) {
+   put_page(page);
+   return error != AOP_TRUNCATED_PAGE ? ERR_PTR(error) : NULL;
+   }
+
+   if (!PageUptodate(page)) {
+   error = lock_page_killable(page);
+   if (unlikely(error)) {
+   put_page(page);
+   return ERR_PTR(error);
+   }
+   if (!PageUptodate(page)) {
+   if (page->mapping == NULL) {
+   /*
+* invalidate_mapping_pages got it
+*/
+   unlock_page(page);
+   put_page(page);
+   return NULL;
+   }
+   unlock_page(page);
+   shrink_readahead_size_eio(ra);
+   put_page(page);
+   return ERR_PTR(-EIO);
+   }
+   unlock_page(page);
+   }
+
+   return page;
+}
+
+static struct page *
+generic_file_buffered_read_pagenotuptodate(struct file *filp,
+  struct iov_iter *iter,
+  struct page *page,
+  loff_t pos, loff_t count)
+{
+   struct address_space *mapping = filp->f_mapping;
+   struct inode *inode = mapping->host;
+   int error;
+
+   /*
+* See comment in do_read_cache_page on why
+* wait_on_page_locked is 

Re: [PATCH V3 0/5] Enable USB support in IPQ8074

2020-06-18 Thread Sivaprakash Murugesan

Hi Vinod, Bjorn

This series is completely reviewed and acked now, can you

take this for merging?

On 6/16/2020 3:57 PM, Sivaprakash Murugesan wrote:

Ping!

Hi Vinod,

can you please review this patch series?

On 6/8/2020 7:41 PM, Sivaprakash Murugesan wrote:

IPQ8074 has two super speed USB ports, with QMP and QUSB2 PHYs.
This patch set enables the USB PHYs and USB dwc3 in IPQ8074.

[V3]
  * Rebased patch 3 on 5.7 and linux-next tag next-20200608
[V2]
  * Added new device compatible qcom,ipq8074-qusb2-phy for qusb2
  * Addressed Bjorn's review comments on dts and binding

Sivaprakash Murugesan (5):
   dt-bindings: phy: qcom,qmp: Add ipq8074 usb dt bindings
   dt-bindings: phy: qcom,qusb2: Add ipq8074 device compatible
   phy: qcom-qmp: Add USB QMP PHY support for IPQ8074
   phy: qcom-qusb2: Add ipq8074 device compatible
   arm64: dts: ipq8074: enable USB support

  .../devicetree/bindings/phy/qcom,qmp-phy.yaml |   2 +
  .../devicetree/bindings/phy/qcom,qusb2-phy.yaml |   1 +
  arch/arm64/boot/dts/qcom/ipq8074-hk01.dts  | 24 +++
  arch/arm64/boot/dts/qcom/ipq8074.dtsi  | 167 
+

  drivers/phy/qualcomm/phy-qcom-qmp.c    | 102 +
  drivers/phy/qualcomm/phy-qcom-qusb2.c |   3 +
  6 files changed, 299 insertions(+)



[PATCH v3 2/2] fs: generic_file_buffered_read() now uses find_get_pages_contig

2020-06-18 Thread Kent Overstreet
Convert generic_file_buffered_read() to get pages to read from in
batches, and then copy data to userspace from many pages at once - in
particular, we now don't touch any cachelines that might be contended
while we're in the loop to copy data to userspace.

This is is a performance improvement on workloads that do buffered reads
with large blocksizes, and a very large performance improvement if that
file is also being accessed concurrently by different threads.

On smaller reads (512 bytes), there's a very small performance
improvement (1%, within the margin of error).

Signed-off-by: Kent Overstreet 
---
 mm/filemap.c | 279 +--
 1 file changed, 159 insertions(+), 120 deletions(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index dc4a72042e..d8bd5e9647 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1975,67 +1975,6 @@ static void shrink_readahead_size_eio(struct 
file_ra_state *ra)
ra->ra_pages /= 4;
 }
 
-static int generic_file_buffered_read_page_ok(struct kiocb *iocb,
-   struct iov_iter *iter,
-   struct page *page)
-{
-   struct address_space *mapping = iocb->ki_filp->f_mapping;
-   struct inode *inode = mapping->host;
-   struct file_ra_state *ra = >ki_filp->f_ra;
-   unsigned int offset = iocb->ki_pos & ~PAGE_MASK;
-   unsigned int bytes, copied;
-   loff_t isize, end_offset;
-
-   BUG_ON(iocb->ki_pos >> PAGE_SHIFT != page->index);
-
-   /*
-* i_size must be checked after we know the page is Uptodate.
-*
-* Checking i_size after the check allows us to calculate
-* the correct value for "bytes", which means the zero-filled
-* part of the page is not copied back to userspace (unless
-* another truncate extends the file - this is desired though).
-*/
-
-   isize = i_size_read(inode);
-   if (unlikely(iocb->ki_pos >= isize))
-   return 1;
-
-   end_offset = min_t(loff_t, isize, iocb->ki_pos + iter->count);
-
-   bytes = min_t(loff_t, end_offset - iocb->ki_pos, PAGE_SIZE - offset);
-
-   /* If users can be writing to this page using arbitrary
-* virtual addresses, take care about potential aliasing
-* before reading the page on the kernel side.
-*/
-   if (mapping_writably_mapped(mapping))
-   flush_dcache_page(page);
-
-   /*
-* Ok, we have the page, and it's up-to-date, so
-* now we can copy it to user space...
-*/
-
-   copied = copy_page_to_iter(page, offset, bytes, iter);
-
-   iocb->ki_pos += copied;
-
-   /*
-* When a sequential read accesses a page several times,
-* only mark it as accessed the first time.
-*/
-   if (iocb->ki_pos >> PAGE_SHIFT != ra->prev_pos >> PAGE_SHIFT)
-   mark_page_accessed(page);
-
-   ra->prev_pos = iocb->ki_pos;
-
-   if (copied < bytes)
-   return -EFAULT;
-
-   return !iov_iter_count(iter) || iocb->ki_pos == isize;
-}
-
 static struct page *
 generic_file_buffered_read_readpage(struct file *filp,
struct address_space *mapping,
@@ -2179,6 +2118,83 @@ generic_file_buffered_read_no_cached_page(struct kiocb 
*iocb,
return generic_file_buffered_read_readpage(filp, mapping, page);
 }
 
+static int generic_file_buffered_read_get_pages(struct kiocb *iocb,
+   struct iov_iter *iter,
+   struct page **pages,
+   unsigned int nr)
+{
+   struct file *filp = iocb->ki_filp;
+   struct address_space *mapping = filp->f_mapping;
+   struct file_ra_state *ra = >f_ra;
+   pgoff_t index = iocb->ki_pos >> PAGE_SHIFT;
+   pgoff_t last_index = (iocb->ki_pos + iter->count + PAGE_SIZE-1) >> 
PAGE_SHIFT;
+   int i, j, nr_got, err = 0;
+
+   nr = min_t(unsigned long, last_index - index, nr);
+find_page:
+   if (fatal_signal_pending(current))
+   return -EINTR;
+
+   nr_got = find_get_pages_contig(mapping, index, nr, pages);
+   if (nr_got)
+   goto got_pages;
+
+   if (iocb->ki_flags & IOCB_NOWAIT)
+   return -EAGAIN;
+
+   page_cache_sync_readahead(mapping, ra, filp, index, last_index - index);
+
+   nr_got = find_get_pages_contig(mapping, index, nr, pages);
+   if (nr_got)
+   goto got_pages;
+
+   pages[0] = generic_file_buffered_read_no_cached_page(iocb, iter);
+   err = PTR_ERR_OR_ZERO(pages[0]);
+   if (!IS_ERR_OR_NULL(pages[0]))
+   nr_got = 1;
+got_pages:
+   for (i = 0; i < nr_got; i++) {
+   struct page *page = pages[i];
+   pgoff_t pg_index = index + i;
+   loff_t pg_pos = max(iocb->ki_pos,
+   (loff_t) pg_index << PAGE_SHIFT);
+   loff_t pg_count = 

[PATCH v3 0/2] generic_file_buffered_read() refactoring & optimization

2020-06-18 Thread Kent Overstreet
Ok - here's a new version, I fixed the checkpatch stuff and the thing with ret
should be more readable now:

Kent Overstreet (2):
  fs: Break generic_file_buffered_read up into multiple functions
  fs: generic_file_buffered_read() now uses find_get_pages_contig

 mm/filemap.c | 497 +--
 1 file changed, 287 insertions(+), 210 deletions(-)

-- 
2.26.2



[PATCH] f2fs: fix to document reserved special compression extension

2020-06-18 Thread Chao Yu
There is one reserved special compression extension: '*', which
could be set via 'compress_extension="*"' mount option to enable
compression for all files.

Signed-off-by: Chao Yu 
---
 Documentation/filesystems/f2fs.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/filesystems/f2fs.rst 
b/Documentation/filesystems/f2fs.rst
index 099d45ac8d8f..535021c46260 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -258,6 +258,8 @@ compress_extension=%s  Support adding specified extension, 
so that f2fs can enab
on compression extension list and enable compression on
these file by default rather than to enable it via 
ioctl.
For other files, we can still enable compression via 
ioctl.
+   Note that, there is one reserved special extension '*', 
it
+   can be set to enable compression for all files.
 == 

 
 Debugfs Entries
-- 
2.26.2



Re: [PATCH][next] net: stmmac: selftests: Use struct_size() helper in kzalloc()

2020-06-18 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Tue, 16 Jun 2020 18:03:28 -0500

> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
> 
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied to net-next, thanks.


Re: [PATCH v1 6/6] console: Fix trivia typo 'change' -> 'chance'

2020-06-18 Thread Benjamin Herrenschmidt
On Thu, 2020-06-18 at 19:47 +0300, Andy Shevchenko wrote:
> I bet the word 'chance' has to be used in 'had a chance to be called',
> but, alas, I'm not native speaker...

Yup, typo :)

> Signed-off-by: Andy Shevchenko 
> 

Acked-by: Benjamin Herrenschmidt 

> ---
>  kernel/printk/printk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index aaea3ad182e1..6623e975675a 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2705,7 +2705,7 @@ static int try_enable_new_console(struct console 
> *newcon, bool user_specified)
>   /*
>* Some consoles, such as pstore and netconsole, can be enabled even
>* without matching. Accept the pre-enabled consoles only when match()
> -  * and setup() had a change to be called.
> +  * and setup() had a chance to be called.
>*/
>   if (newcon->flags & CON_ENABLED && c->user_specified == user_specified)
>   return 0;



Re: [PATCH v1 5/6] console: Propagate error code from console ->setup()

2020-06-18 Thread Benjamin Herrenschmidt
On Thu, 2020-06-18 at 19:47 +0300, Andy Shevchenko wrote:
> Since console ->setup() hook returns meaningful error codes,
> propagate it to the caller of try_enable_new_console().
> 
> Signed-off-by: Andy Shevchenko 
> 

Acked-by: Benjamin Herrenschmidt 

> ---A
>  kernel/printk/printk.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 8c14835be46c..aaea3ad182e1 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2668,7 +2668,7 @@ early_param("keep_bootcon", keep_bootcon_setup);
>  static int try_enable_new_console(struct console *newcon, bool 
> user_specified)
>  {
>   struct console_cmdline *c;
> - int i;
> + int i, err;
>  
>   for (i = 0, c = console_cmdline;
>i < MAX_CMDLINECONSOLES && c->name[0];
> @@ -2691,8 +2691,8 @@ static int try_enable_new_console(struct console 
> *newcon, bool user_specified)
>   return 0;
>  
>   if (newcon->setup &&
> - newcon->setup(newcon, c->options) != 0)
> - return -EIO;
> + (err = newcon->setup(newcon, c->options)) != 0)
> + return err;
>   }
>   newcon->flags |= CON_ENABLED;
>   if (i == preferred_console) {



RE: [RESEND v5 2/2] phy: intel: Add Keem Bay eMMC PHY support

2020-06-18 Thread Wan Mohamad, Wan Ahmad Zainie



> -Original Message-
> From: Shevchenko, Andriy 
> Sent: Wednesday, June 17, 2020 10:01 PM
> To: Wan Mohamad, Wan Ahmad Zainie
> 
> Cc: kis...@ti.com; vk...@kernel.org; robh...@kernel.org; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; Hunter, Adrian
> 
> Subject: Re: [RESEND v5 2/2] phy: intel: Add Keem Bay eMMC PHY support
> 
> On Wed, Jun 17, 2020 at 07:32:52AM +0800, Wan Ahmad Zainie wrote:
> > Add support for eMMC PHY on Intel Keem Bay SoC.
> 
> ...
> 
> > +   ret = regmap_read_poll_timeout(priv->syscfg, PHY_STAT,
> > +  dllrdy, IS_DLLRDY(dllrdy),
> > +  0, 50 * USEC_PER_MSEC);
> > +   if (ret) {
> > +   dev_err(>dev, "dllrdy failed, ret=%d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   return ret;
> > +}
> 
> This has no changes.
> 
> Are you sure the version is correct?

Ah. Sorry Andy. I misunderstood your earlier review comment.
You mean return inside the last if(...) should be discarded.

Kishon, should I send another version, or is it acceptable?

> 
> --
> With Best Regards,
> Andy Shevchenko
> 



Re: [PATCH V3 0/5] Enable USB support in IPQ8074

2020-06-18 Thread Sricharan Ramabadhran

Hi Siva,

On 6/8/2020 7:41 PM, Sivaprakash Murugesan wrote:

IPQ8074 has two super speed USB ports, with QMP and QUSB2 PHYs.
This patch set enables the USB PHYs and USB dwc3 in IPQ8074.

[V3]
  * Rebased patch 3 on 5.7 and linux-next tag next-20200608
[V2]
  * Added new device compatible qcom,ipq8074-qusb2-phy for qusb2
  * Addressed Bjorn's review comments on dts and binding

Sivaprakash Murugesan (5):
   dt-bindings: phy: qcom,qmp: Add ipq8074 usb dt bindings
   dt-bindings: phy: qcom,qusb2: Add ipq8074 device compatible
   phy: qcom-qmp: Add USB QMP PHY support for IPQ8074
   phy: qcom-qusb2: Add ipq8074 device compatible
   arm64: dts: ipq8074: enable USB support

  .../devicetree/bindings/phy/qcom,qmp-phy.yaml  |   2 +
  .../devicetree/bindings/phy/qcom,qusb2-phy.yaml|   1 +
  arch/arm64/boot/dts/qcom/ipq8074-hk01.dts  |  24 +++
  arch/arm64/boot/dts/qcom/ipq8074.dtsi  | 167 +
  drivers/phy/qualcomm/phy-qcom-qmp.c| 102 +
  drivers/phy/qualcomm/phy-qcom-qusb2.c  |   3 +
  6 files changed, 299 insertions(+)


 Tested this series on hk01.c1 for USB mass storage.

 Tested-by: Sricharan R 

Regards,

 Sricharan





[PATCH v3] ASoC: qcom: Kconfig: Tweak dependencies on SND_SOC_SDM845

2020-06-18 Thread John Stultz
CROS_EC isn't strictly required for audio to work
on other SDM845 platforms (like the Dragonboard 845c).

So lets remove the dependency and select the related
CROS_EC options via imply.

Cc: Srinivas Kandagatla 
Cc: Rohit kumar 
Cc: Patrick Lai 
Cc: Banajit Goswami 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
Signed-off-by: John Stultz 
---
v2: Switch to using imply as suggested by Srinivas
---
 sound/soc/qcom/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index f51b28d1b94d..0ea4cde9f4f0 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -99,12 +99,12 @@ config SND_SOC_MSM8996
 
 config SND_SOC_SDM845
tristate "SoC Machine driver for SDM845 boards"
-   depends on QCOM_APR && CROS_EC && I2C && SOUNDWIRE
+   depends on QCOM_APR && I2C && SOUNDWIRE
select SND_SOC_QDSP6
select SND_SOC_QCOM_COMMON
select SND_SOC_RT5663
select SND_SOC_MAX98927
-   select SND_SOC_CROS_EC_CODEC
+   imply SND_SOC_CROS_EC_CODEC
help
  To add support for audio on Qualcomm Technologies Inc.
  SDM845 SoC-based systems.
-- 
2.17.1



Re: [PATCH V3 4/5] phy: qcom-qusb2: Add ipq8074 device compatible

2020-06-18 Thread Sricharan Ramabadhran



On 6/8/2020 7:41 PM, Sivaprakash Murugesan wrote:

Add ipq8074 qusb2 device compatible for high speed usb support.

Signed-off-by: Sivaprakash Murugesan 
---
  drivers/phy/qualcomm/phy-qcom-qusb2.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 393011a..557547d 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -810,6 +810,9 @@ static const struct phy_ops qusb2_phy_gen_ops = {
  
  static const struct of_device_id qusb2_phy_of_match_table[] = {

{
+   .compatible = "qcom,ipq8074-qusb2-phy",
+   .data   = _phy_cfg,
+   }, {
.compatible = "qcom,msm8996-qusb2-phy",
.data   = _phy_cfg,
}, {


Reviewed-by: Sricharan R 

Regards,

 Sricharan




Re: [RFC PATCH] xen/privcmd: Convert get_user_pages*() to pin_user_pages*()

2020-06-18 Thread Souptick Joarder
On Wed, Jun 17, 2020 at 11:29 PM Boris Ostrovsky
 wrote:
>
> On 6/16/20 11:14 PM, Souptick Joarder wrote:
> > In 2019, we introduced pin_user_pages*() and now we are converting
> > get_user_pages*() to the new API as appropriate. [1] & [2] could
> > be referred for more information.
> >
> > [1] Documentation/core-api/pin_user_pages.rst
> >
> > [2] "Explicit pinning of user-space pages":
> > https://lwn.net/Articles/807108/
> >
> > Signed-off-by: Souptick Joarder 
> > Cc: John Hubbard 
> > ---
> > Hi,
> >
> > I have compile tested this patch but unable to run-time test,
> > so any testing help is much appriciated.
> >
> > Also have a question, why the existing code is not marking the
> > pages dirty (since it did FOLL_WRITE) ?
>
>
> Indeed, seems to me it should. Paul?
>
>
> >
> >  drivers/xen/privcmd.c | 7 ++-
> >  1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index a250d11..543739e 100644
> > --- a/drivers/xen/privcmd.c
> > +++ b/drivers/xen/privcmd.c
> > @@ -594,7 +594,7 @@ static int lock_pages(
> >   if (requested > nr_pages)
> >   return -ENOSPC;
> >
> > - pinned = get_user_pages_fast(
> > + pinned = pin_user_pages_fast(
> >   (unsigned long) kbufs[i].uptr,
> >   requested, FOLL_WRITE, pages);
> >   if (pinned < 0)
> > @@ -614,10 +614,7 @@ static void unlock_pages(struct page *pages[], 
> > unsigned int nr_pages)
> >   if (!pages)
> >   return;
> >
> > - for (i = 0; i < nr_pages; i++) {
> > - if (pages[i])
> > - put_page(pages[i]);
> > - }
> > + unpin_user_pages(pages, nr_pages);
>
>
> Why are you no longer checking for valid pages?

My understanding is, in case of lock_pages() end up returning partial
mapped pages,
we should pass no. of partial mapped pages to unlock_pages(), not nr_pages.
This will avoid checking extra check to validate the pages[i].

and if lock_pages() returns 0 in success, anyway we have all the pages[i] valid.
I will try to correct it in v2.

But I agree, there is no harm to check for pages[i] and I believe,
unpin_user_pages()
is the right place to do so.

John any thought ?


Re: [kbuild-all] security/integrity/ima/ima_crypto.c:575:12: warning: stack frame size of 1152 bytes in function 'ima_calc_field_array_hash_tfm'

2020-06-18 Thread Rong Chen

Hi Herbert,

Could you take a look at this warning? Roberto mentioned you in previous 
report:

https://lore.kernel.org/linux-integrity/9dbec9465bda4f8995a42593eb0db...@huawei.com/

Best Regards,
Rong Chen

On 6/17/20 9:35 PM, kernel test robot wrote:

Hi Roberto,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   69119673bd50b176ded34032fadd41530fb5af21
commit: 1ea973df6e2166d1a576cabe5d08925d3261ff9d ima: Calculate and extend PCR 
with digests in ima_template_entry
date:   8 weeks ago
config: mips-randconfig-r014-20200617 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
487ca07fcc75d52755c9fe2ee05bcb3b6c44)
reproduce (this is a W=1 build):
 wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # install mips cross compiling tool for clang build
 # apt-get install binutils-mips-linux-gnu
 git checkout 1ea973df6e2166d1a576cabe5d08925d3261ff9d
 # save the attached .config to linux build tree
 COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):


security/integrity/ima/ima_crypto.c:575:12: warning: stack frame size of 1152 
bytes in function 'ima_calc_field_array_hash_tfm' [-Wframe-larger-than=]

static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
^
1 warning generated.

vim +/ima_calc_field_array_hash_tfm +575 security/integrity/ima/ima_crypto.c

3bcced39ea7d1b Dmitry Kasatkin 2014-02-26  571
3323eec921efd8 Mimi Zohar  2009-02-04  572  /*
a71dc65d30a472 Roberto Sassu   2013-06-07  573   * Calculate the hash of 
template data
3323eec921efd8 Mimi Zohar  2009-02-04  574   */
a71dc65d30a472 Roberto Sassu   2013-06-07 @575  static int 
ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
7ca79645a1f883 Roberto Sassu   2020-03-25  576  
 struct ima_template_entry *entry,
6d94809af6b083 Roberto Sassu   2020-03-25  577  
 int tfm_idx)
3323eec921efd8 Mimi Zohar  2009-02-04  578  {
6d94809af6b083 Roberto Sassu   2020-03-25  579  
SHASH_DESC_ON_STACK(shash, ima_algo_array[tfm_idx].tfm);
7ca79645a1f883 Roberto Sassu   2020-03-25  580  struct ima_template_desc 
*td = entry->template_desc;
7ca79645a1f883 Roberto Sassu   2020-03-25  581  int num_fields = 
entry->template_desc->num_fields;
a71dc65d30a472 Roberto Sassu   2013-06-07  582  int rc, i;
3323eec921efd8 Mimi Zohar  2009-02-04  583
6d94809af6b083 Roberto Sassu   2020-03-25  584  shash->tfm = 
ima_algo_array[tfm_idx].tfm;
3323eec921efd8 Mimi Zohar  2009-02-04  585
357aabed626fe3 Behan Webster   2014-04-04  586  rc = 
crypto_shash_init(shash);
a71dc65d30a472 Roberto Sassu   2013-06-07  587  if (rc != 0)
a71dc65d30a472 Roberto Sassu   2013-06-07  588  return rc;
a71dc65d30a472 Roberto Sassu   2013-06-07  589
a71dc65d30a472 Roberto Sassu   2013-06-07  590  for (i = 0; i < 
num_fields; i++) {
e3b64c268b485f Roberto Sassu   2014-02-03  591  u8 
buffer[IMA_EVENT_NAME_LEN_MAX + 1] = { 0 };
e3b64c268b485f Roberto Sassu   2014-02-03  592  u8 
*data_to_hash = field_data[i].data;
e3b64c268b485f Roberto Sassu   2014-02-03  593  u32 datalen = 
field_data[i].len;
98e1d55d033eed Andreas Steffen 2016-12-19  594  u32 
datalen_to_hash =
98e1d55d033eed Andreas Steffen 2016-12-19  595  
!ima_canonical_fmt ? datalen : cpu_to_le32(datalen);
e3b64c268b485f Roberto Sassu   2014-02-03  596
b6f8f16f41d928 Roberto Sassu   2013-11-08  597  if 
(strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
357aabed626fe3 Behan Webster   2014-04-04  598  rc = 
crypto_shash_update(shash,
98e1d55d033eed Andreas Steffen 2016-12-19  599  
(const u8 *) _to_hash,
98e1d55d033eed Andreas Steffen 2016-12-19  600  
sizeof(datalen_to_hash));
b6f8f16f41d928 Roberto Sassu   2013-11-08  601  if (rc)
b6f8f16f41d928 Roberto Sassu   2013-11-08  602  
break;
e3b64c268b485f Roberto Sassu   2014-02-03  603  } else if 
(strcmp(td->fields[i]->field_id, "n") == 0) {
e3b64c268b485f Roberto Sassu   2014-02-03  604  
memcpy(buffer, data_to_hash, datalen);
e3b64c268b485f Roberto Sassu   2014-02-03  605  
data_to_hash = buffer;
e3b64c268b485f Roberto Sassu   2014-02-03  606  datalen 
= IMA_EVENT_NAME_LEN_MAX + 1;
b6f8f16f41d928 Roberto 

Re: [PATCH v2 net 0/2] Reapply DSA fix for dpaa-eth with proper Fixes: tag

2020-06-18 Thread David Miller
From: Vladimir Oltean 
Date: Tue, 16 Jun 2020 18:19:08 +0300

> From: Vladimir Oltean 
> 
> Joakim notified me that this fix breaks stable trees.
> It turns out that my assessment about who-broke-who was wrong.
> The real Fixes: tag should have been:
> 
> Fixes: 060ad66f9795 ("dpaa_eth: change DMA device")
> 
> which changes the device on which SET_NETDEV_DEV is made.
> 
> git describe --tags 060ad66f97954
> v5.4-rc3-783-g060ad66f9795
> 
> Which means that it shouldn't have been backported to 4.19 and below.
> This series reverts the commit with the misleading commit message, and
> reapplies it with a corrected one. The resulting code is exactly the
> same, but now, the revert should make it to the stable trees (along with
> the bad fix), and the new fix should only make it down to v5.4.y.
> 
> Changes in v2:
> Corrected the reversed sysfs paths in the new commit description.

This is so messy.

What's done is done, just submit the necessary revert to -stable
if necessary and let's not just change things back and forth
because then we'll have two commits which make identical changes
and each having a different Fixes: tag which is confusing.

Thanks.


Re: [PATCH 4/7] x86/entry: Increase entry_stack size to a full page

2020-06-18 Thread Lai Jiangshan
On Fri, Jun 19, 2020 at 4:37 AM Peter Zijlstra  wrote:
>
> Marco crashed in bad_iret with a Clang11/KCSAN build due to
> overflowing the stack. Now that we run C code on it, expand it to a
> full page.

Some of my experimental code also once got crashed due to overflowing
the stack. I'm glad to have the stack expanded, thanks.

Reviewed-by: Lai Jiangshan 

>
> Suggested-by: Andy Lutomirski 
> Reported-by: Marco Elver 
> Signed-off-by: Peter Zijlstra (Intel) 
> ---
>  arch/x86/include/asm/processor.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -370,7 +370,7 @@ struct x86_hw_tss {
>  #define IO_BITMAP_OFFSET_INVALID   (__KERNEL_TSS_LIMIT + 1)
>
>  struct entry_stack {
> -   unsigned long   words[64];
> +   charstack[PAGE_SIZE];
>  };
>
>  struct entry_stack_page {
>
>


Re: [PATCH 0/3] zone-append support in aio and io-uring

2020-06-18 Thread Damien Le Moal
On 2020/06/19 2:55, Kanchan Joshi wrote:
> On Wed, Jun 17, 2020 at 11:56:34PM -0700, Christoph Hellwig wrote:
>> On Wed, Jun 17, 2020 at 10:53:36PM +0530, Kanchan Joshi wrote:
>>> This patchset enables issuing zone-append using aio and io-uring direct-io 
>>> interface.
>>>
>>> For aio, this introduces opcode IOCB_CMD_ZONE_APPEND. Application uses 
>>> start LBA
>>> of the zone to issue append. On completion 'res2' field is used to return
>>> zone-relative offset.
>>>
>>> For io-uring, this introduces three opcodes: 
>>> IORING_OP_ZONE_APPEND/APPENDV/APPENDV_FIXED.
>>> Since io_uring does not have aio-like res2, cqe->flags are repurposed to 
>>> return zone-relative offset
>>
>> And what exactly are the semantics supposed to be?  Remember the
>> unix file abstractions does not know about zones at all.
>>
>> I really don't think squeezing low-level not quite block storage
>> protocol details into the Linux read/write path is a good idea.
> 
> I was thinking of raw block-access to zone device rather than pristine file
> abstraction. And in that context, semantics, at this point, are unchanged
> (i.e. same as direct writes) while flexibility of async-interface gets
> added.

The aio->aio_offset use by the user and kernel differs for regular writes and
zone append writes. This is a significant enough change to say that semantic
changed. Yes both cases are direct IOs, but specification of the write location
by the user and where the data actually lands on disk are different.

There are a lot of subtle things that can happen that makes mapping of zone
append operations to POSIX semantic difficult. E.g. for a regular file, using
zone append for any write issued to a file open with O_APPEND maps well to POSIX
only for blocking writes. For asynchronous writes, that is not true anymore
since the order of data defined by the automatic append after the previous async
write breaks: data can land anywhere in the zone regardless of the offset
specified on submission.

> Synchronous-writes on single-zone sound fine, but synchronous-appends on
> single-zone do not sound that fine.

Why not ? This is a perfectly valid use case that actually does not have any
semantic problem. It indeed may not be the  most effective method to get high
performance but saying that it is "not fine" is not correct in my opinion.

> 
>> What could be a useful addition is a way for O_APPEND/RWF_APPEND writes
>> to report where they actually wrote, as that comes close to Zone Append
>> while still making sense at our usual abstraction level for file I/O.
> 
> Thanks for suggesting this. O and RWF_APPEND may not go well with block
> access as end-of-file will be picked from dev inode. But perhaps a new
> flag like RWF_ZONE_APPEND can help to transform writes (aio or uring)
> into append without introducing new opcodes.

Yes, RWF_ZONE_APPEND may be better if the semantic of RWF_APPEND cannot be
cleanly reused. But as Christoph said, RWF_ZONE_APPEND semantic need to be
clarified so that all reviewer can check the code against the intended behavior,
and comment on that intended behavior too.

> And, I think, this can fit fine on file-abstraction of ZoneFS as well.

May be. Depends on what semantic you are after for user zone append interface.
Ideally, we should have at least the same for raw block device and zonefs. But
zonefs may be able to do a better job thanks to its real regular file
abstraction of zones. As Christoph said, we started looking into it but lacked
time to complete this work. This is still on-going.

-- 
Damien Le Moal
Western Digital Research


Re: [PATCH v6 23/36] drm: vmwgfx: fix common struct sg_table related issues

2020-06-18 Thread kernel test robot
Hi Marek,

I love your patch! Perhaps something to improve:

[auto build test WARNING on next-20200618]
[also build test WARNING on v5.8-rc1]
[cannot apply to linuxtv-media/master staging/staging-testing 
drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7 
v5.7-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Marek-Szyprowski/DRM-fix-struct-sg_table-nents-vs-orig_nents-misuse/20200619-000417
base:ce2cc8efd7a40cbd17841add878cb691d0ce0bba
config: x86_64-randconfig-s021-20200618 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-rc1-10-gc17b1b06-dirty
# save the attached .config to linux build tree
make W=1 C=1 ARCH=x86_64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:365:38: sparse: sparse: incorrect 
>> type in argument 2 (different base types) @@ expected struct sg_table 
>> *sgt @@ got struct sg_table sgt @@
>> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:365:38: sparse: expected 
>> struct sg_table *sgt
>> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:365:38: sparse: got struct 
>> sg_table sgt
   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:386:43: sparse: sparse: incorrect 
type in argument 2 (different base types) @@ expected struct sg_table *sgt 
@@ got struct sg_table sgt @@
   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:386:43: sparse: expected 
struct sg_table *sgt
   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:386:43: sparse: got struct 
sg_table sgt

vim +365 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c

   352  
   353  /**
   354   * vmw_ttm_unmap_from_dma - unmap  device addresses previsouly mapped 
for
   355   * TTM pages
   356   *
   357   * @vmw_tt: Pointer to a struct vmw_ttm_backend
   358   *
   359   * Used to free dma mappings previously mapped by vmw_ttm_map_for_dma.
   360   */
   361  static void vmw_ttm_unmap_from_dma(struct vmw_ttm_tt *vmw_tt)
   362  {
   363  struct device *dev = vmw_tt->dev_priv->dev->dev;
   364  
 > 365  dma_unmap_sgtable(dev, vmw_tt->sgt, DMA_BIDIRECTIONAL, 0);
   366  vmw_tt->sgt.nents = vmw_tt->sgt.orig_nents;
   367  }
   368  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


Re: [RESEND, PATCH v2] lib: overflow-test: add KUnit test of check_*_overflow functions

2020-06-18 Thread Kees Cook
On Thu, Jun 18, 2020 at 11:08:14AM -0300, Vitor Massaru Iha wrote:
> This adds the conversion of the runtime tests of check_*_overflow functions,
> from `lib/test_overflow.c`to KUnit tests.
> 
> The log similar to the one seen in dmesg running test_overflow.c can be
> seen in `test.log`.
> 
> Signed-off-by: Vitor Massaru Iha 
> Tested-by: David Gow 
> ---
> v2:
>   * moved lib/test_overflow.c to lib/overflow-test.c; 

I still don't want a dash in the filename, as this creates a difference
between the source name and the module name. While I still prefer
overflow_kunit.c, I can get over it and accept overflow_test.c :)

> * back to original license;
> * fixed style code;
> * keeps __initconst and added _refdata on overflow_test_cases variable;
> * keeps macros intact making asserts with the variable err;
> * removed duplicate test_s8_overflow();
>   * fixed typos on commit message;
> ---
>  lib/Kconfig.debug| 20 +++--
>  lib/Makefile |  2 +-
>  lib/{test_overflow.c => overflow-test.c} | 54 +---
>  3 files changed, 38 insertions(+), 38 deletions(-)
>  rename lib/{test_overflow.c => overflow-test.c} (96%)
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index d74ac0fd6b2d..fb8a3955e969 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -2000,9 +2000,6 @@ config TEST_UUID
>  config TEST_XARRAY
>   tristate "Test the XArray code at runtime"
>  
> -config TEST_OVERFLOW
> - tristate "Test check_*_overflow() functions at runtime"
> -
>  config TEST_RHASHTABLE
>   tristate "Perform selftest on resizable hash table"
>   help
> @@ -2155,6 +2152,23 @@ config SYSCTL_KUNIT_TEST
>  
> If unsure, say N.
>  
> +config OVERFLOW_KUNIT_TEST
> + tristate "KUnit test for overflow" if !KUNIT_ALL_TESTS
> + depends on KUNIT
> + default KUNIT_ALL_TESTS
> + help
> +   This builds the overflow KUnit tests.
> +
> +   KUnit tests run during boot and output the results to the debug log
> +   in TAP format (http://testanything.org/). Only useful for kernel devs
> +   running KUnit test harness and are not for inclusion into a production
> +   build.
> +
> +   For more information on KUnit and unit tests in general please refer
> +   to the KUnit documentation in Documentation/dev-tools/kunit/.
> +
> +   If unsure, say N.
> +
>  config LIST_KUNIT_TEST
>   tristate "KUnit Test for Kernel Linked-list structures" if 
> !KUNIT_ALL_TESTS
>   depends on KUNIT
> diff --git a/lib/Makefile b/lib/Makefile
> index b1c42c10073b..3b725c9f92d4 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -75,7 +75,6 @@ obj-$(CONFIG_TEST_LIST_SORT) += test_list_sort.o
>  obj-$(CONFIG_TEST_MIN_HEAP) += test_min_heap.o
>  obj-$(CONFIG_TEST_LKM) += test_module.o
>  obj-$(CONFIG_TEST_VMALLOC) += test_vmalloc.o
> -obj-$(CONFIG_TEST_OVERFLOW) += test_overflow.o
>  obj-$(CONFIG_TEST_RHASHTABLE) += test_rhashtable.o
>  obj-$(CONFIG_TEST_SORT) += test_sort.o
>  obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o
> @@ -318,3 +317,4 @@ obj-$(CONFIG_OBJAGG) += objagg.o
>  # KUnit tests
>  obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
>  obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
> +obj-$(CONFIG_OVERFLOW_KUNIT_TEST) += overflow-test.o
> diff --git a/lib/test_overflow.c b/lib/overflow-test.c
> similarity index 96%
> rename from lib/test_overflow.c
> rename to lib/overflow-test.c
> index 7a4b6f6c5473..d40ef06b1ade 100644
> --- a/lib/test_overflow.c
> +++ b/lib/overflow-test.c
> @@ -4,14 +4,11 @@
>   */
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
> +#include 
>  #include 
>  #include 
> -#include 
>  #include 
> -#include 
>  #include 
> -#include 
> -#include 
>  #include 
>  
>  #define DEFINE_TEST_ARRAY(t) \
> @@ -270,7 +267,7 @@ DEFINE_TEST_FUNC(u64, "%llu");
>  DEFINE_TEST_FUNC(s64, "%lld");
>  #endif
>  
> -static int __init test_overflow_calculation(void)
> +static void __init overflow_calculation_test(struct kunit *test)
>  {
>   int err = 0;
>  
> @@ -285,10 +282,10 @@ static int __init test_overflow_calculation(void)
>   err |= test_s64_overflow();
>  #endif
>  
> - return err;
> + KUNIT_EXPECT_FALSE(test, err);
>  }

Ah! Well, yes, I guess that is one way to do it. :) I'm just curious:
why the change away from doing EXPECTs on individual tests?

>  
> -static int __init test_overflow_shift(void)
> +static void __init overflow_shift_test(struct kunit *test)
>  {
>   int err = 0;
>  
> @@ -479,7 +476,7 @@ static int __init test_overflow_shift(void)
>   err |= TEST_ONE_SHIFT(0, 31, s32, 0, false);
>   err |= TEST_ONE_SHIFT(0, 63, s64, 0, false);
>  
> - return err;
> + KUNIT_EXPECT_FALSE(test, err);
>  }
>  
>  /*
> @@ -555,7 +552,7 @@ DEFINE_TEST_ALLOC(kvzalloc_node, kvfree, 0, 1, 1);
>  DEFINE_TEST_ALLOC(devm_kmalloc,  devm_kfree, 1, 1, 0);
>  DEFINE_TEST_ALLOC(devm_kzalloc,  devm_kfree, 1, 1, 0);
>  

Re: PC speaker

2020-06-18 Thread Randy Dunlap
On 6/18/20 10:49 AM, R.F. Burns wrote:
> Is it possible to write a kernel module which, when loaded, will blow
> the PC speaker?
> 

Are you still having problems with those school students?


https://marc.info/?l=linux-kernel=118167999520788=2

-- 
~Randy



Re: [PATCH v3 1/1] mfd: Add I2C based System Configuaration (SYSCON) access

2020-06-18 Thread Chen-Yu Tsai
On Thu, Jun 18, 2020 at 6:07 PM Lee Jones  wrote:
>
> On Thu, 18 Jun 2020, Arnd Bergmann wrote:
>
> > On Thu, Jun 18, 2020 at 10:03 AM Lee Jones  wrote:
> > >
> > > The existing SYSCON implementation only supports MMIO (memory mapped)
> > > accesses, facilitated by Regmap.  This extends support for registers
> > > held behind I2C busses.
> > >
> > > Signed-off-by: Lee Jones 
> >
> > The implementation looks fine to me, but can you explain how this is going 
> > to
> > be used, and what the advantage is over open-coding the 
> > devm_regmap_init_i2c()
> > in each driver that would use this?
>
> Does Regmap let you register/initialise an I2C address more than once?
>
> When I attempt it, I get:
>
> [0.522988] i2c i2c-0: Failed to register i2c client tmp105 at 0x32 (-16)
> [0.523341] i2c i2c-0: of_i2c: Failure registering 
> /bus@400/motherboard/iofpga@7,/i2c@16000/temp@32
> [0.523691] i2c i2c-0: Failed to create I2C device for 
> /bus@400/motherboard/iofpga@7,/i2c@16000/temp@32
>
> > Is this about using proper locking through the regmap framework for
> > shared i2c clients, or to reduce memory consumption when lots of drivers
> > access the same regmap?
>
> All of those things are valid.
>
> My use-case is regarding MFDs sharing an I2C interfaced address space
> with their children.

Is that an issue with the standard mfd + regmap pattern?

For the AXP20x PMICs, we register the regmap in the parent mfd driver [1],
and store that in dev_data for child drivers to fetch [2]. You could
easily just fetch the regmap with dev_get_regmap() and a pointer to the
parent device.

> > My impression of the existing syscon code is that the main value-add over
> > other ways of doing the same is the syscon_regmap_lookup_by_phandle()
> > interface that gives other drivers a much simpler way of getting the
> > regmap just based on the DT node. Are you planning to add something
> > like that here as well? An ideal driver interface might allow
> > syscon_regmap_lookup_by_phandle() to work for both mmio and i2c
> > based syscons, or additional ones as well, but implementing this would
> > be rather tricky when the i2c core is a loadable module.

The current MMIO syscon is decoupled from the DM, and there is no way
for drivers to export or register a syscon, meaning I have to open code
syscon_regmap_lookup_by_phandle() [3] if I want to only expose certain
registers and not the full address range, or if I want to share the
regmap with the existing driver (for locking purposes), or both [4].
Maybe there's room for improvement here? The same applies to the new
I2C case, and likely any other future syscon variants.

IMHO people are getting it wrong if they have both a syscon and a driver
for the same device.

> I expect the API would be expanded to cover other use-cases.  This is
> a bare bones implementation which has been kept as atomic as possible
> for ease of review.

Regards
ChenYu

[1] https://elixir.bootlin.com/linux/latest/source/drivers/mfd/axp20x-i2c.c#L43
[2] 
https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/pinctrl-axp209.c#L433
[3] 
https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c#L1093
[4] 
https://elixir.bootlin.com/linux/latest/source/drivers/clk/sunxi-ng/ccu-sun8i-r40.c#L1333


[PATCH v3] driver core: platform: expose numa_node to users in sysfs

2020-06-18 Thread Barry Song
Some platform devices like ARM SMMU are memory-mapped and populated by 
ACPI/IORT.
In this case, NUMA topology of those platform devices are exported by firmware 
as
well. Software might care about the numa_node of those devices in order to 
achieve
NUMA locality.
This patch will show the numa_node for this kind of devices in sysfs. For those
platform devices without numa, numa_node won't be visible.

Cc: Prime Zeng 
Cc: Robin Murphy 
Signed-off-by: Barry Song 
---
 -v3: rebase to 5.8-rc1; refine commit log

 Documentation/ABI/testing/sysfs-bus-platform | 10 
 drivers/base/platform.c  | 26 +++-
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
b/Documentation/ABI/testing/sysfs-bus-platform
index 5172a6124b27..194ca700e962 100644
--- a/Documentation/ABI/testing/sysfs-bus-platform
+++ b/Documentation/ABI/testing/sysfs-bus-platform
@@ -18,3 +18,13 @@ Description:
devices to opt-out of driver binding using a driver_override
name such as "none".  Only a single driver may be specified in
the override, there is no support for parsing delimiters.
+
+What:  /sys/bus/platform/devices/.../numa_node
+Date:  June 2020
+Contact:   Barry Song 
+Description:
+   This file contains the NUMA node to which the platform device
+   is attached. It won't be visible if the node is unknown. The
+   value comes from an ACPI _PXM method or a similar firmware
+   source. Initial users for this file would be devices like
+   arm smmu which are populated by arm64 acpi_iort.
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index c0d0a5490ac6..4369dfd57815 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1076,13 +1076,37 @@ static ssize_t driver_override_show(struct device *dev,
 }
 static DEVICE_ATTR_RW(driver_override);
 
+static ssize_t numa_node_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   return sprintf(buf, "%d\n", dev_to_node(dev));
+}
+static DEVICE_ATTR_RO(numa_node);
+
+static umode_t platform_dev_attrs_visible(struct kobject *kobj, struct 
attribute *a,
+   int n)
+{
+   struct device *dev = container_of(kobj, typeof(*dev), kobj);
+
+   if (a == _attr_numa_node.attr &&
+   dev_to_node(dev) == NUMA_NO_NODE)
+   return 0;
+
+   return a->mode;
+}
 
 static struct attribute *platform_dev_attrs[] = {
_attr_modalias.attr,
+   _attr_numa_node.attr,
_attr_driver_override.attr,
NULL,
 };
-ATTRIBUTE_GROUPS(platform_dev);
+
+static struct attribute_group platform_dev_group = {
+   .attrs = platform_dev_attrs,
+   .is_visible = platform_dev_attrs_visible,
+};
+__ATTRIBUTE_GROUPS(platform_dev);
 
 static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
 {
-- 
2.23.0




[git pull] drm fixes for 5.7-rc2

2020-06-18 Thread Dave Airlie
Hi Linus,

rc2 fixes, just i915 and amd here, i915 has some workaround movement
so they get applied at the right times, and a timeslicing fix, along
with some display fixes. AMD has a few display floating point fix and
a devcgroup fix for amdkfd.

drm-fixes-2020-06-19:
drm fixes for 5.8-rc2

i915:
- Fix for timeslicing and virtual engines/unpremptable requests
  (+ 1 dependency patch)
- Fixes into TypeC register programming and interrupt storm detecting
- Disable DIP on MST ports with the transcoder clock still on
- Avoid missing GT workarounds at reset for HSW and older gens
- Fix for unwinding multiple requests missing force restore
- Fix encoder type check for DDI vswing sequence
- Build warning fixes

amdgpu:
- Fix kvfree/kfree mixup
- Fix hawaii device id in powertune configuration
- Display FP fixes
- Documentation fixes

amdkfd:
- devcgroup check fix
The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:

  Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-06-19

for you to fetch changes up to 8a7a3d1d0dcf2bb63dafe7275020420005e13e54:

  Merge tag 'amd-drm-fixes-5.8-2020-06-17' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-06-19
10:02:30 +1000)


drm fixes for 5.8-rc2

i915:
- Fix for timeslicing and virtual engines/unpremptable requests
  (+ 1 dependency patch)
- Fixes into TypeC register programming and interrupt storm detecting
- Disable DIP on MST ports with the transcoder clock still on
- Avoid missing GT workarounds at reset for HSW and older gens
- Fix for unwinding multiple requests missing force restore
- Fix encoder type check for DDI vswing sequence
- Build warning fixes

amdgpu:
- Fix kvfree/kfree mixup
- Fix hawaii device id in powertune configuration
- Display FP fixes
- Documentation fixes

amdkfd:
- devcgroup check fix


Alex Deucher (2):
  drm/amdgpu/pm: update comment to clarify Overdrive interfaces
  drm/amdgpu: fix documentation around busy_percentage

Arnd Bergmann (2):
  drm/i915/pmu: avoid an maybe-uninitialized warning
  drm/i915: work around false-positive maybe-uninitialized warning

Chris Wilson (10):
  drm/i915/gt: Incorporate the virtual engine into timeslicing
  drm/i915/selftests: Restore to default heartbeat
  drm/i915/gt: Prevent timeslicing into unpreemptable requests
  drm/i915/gt: Incrementally check for rewinding
  drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds
  drm/i915/gt: Move ivb GT workarounds from init_clock_gating to workarounds
  drm/i915/gt: Move vlv GT workarounds from init_clock_gating to workarounds
  drm/i915/gt: Move snb GT workarounds from init_clock_gating to workarounds
  drm/i915/gt: Move ilk GT workarounds from init_clock_gating to workarounds
  drm/i915/gt: Move gen4 GT workarounds from init_clock_gating to
workarounds

Dave Airlie (2):
  Merge tag 'drm-intel-fixes-2020-06-18' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge tag 'amd-drm-fixes-5.8-2020-06-17' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Denis Efremov (2):
  drm/amd/display: Use kvfree() to free coeff in build_regamma()
  drm/amd/display: Use kfree() to free rgb_user in
calculate_user_regamma_ramp()

Imre Deak (2):
  drm/i915/icl: Disable DIP on MST ports with the transcoder clock still on
  drm/i915/icl+: Fix hotplug interrupt disabling after storm detection

Khaled Almahallawy (1):
  drm/i915/tc: fix the reset of ln0

Lorenz Brun (1):
  drm/amdkfd: Use correct major in devcgroup check

Rodrigo Siqueira (1):
  drm/amd/display: Rework dsc to isolate FPU operations

Sandeep Raghuraman (1):
  drm/amdgpu: Replace invalid device ID with a valid device ID

Vandita Kulkarni (1):
  drm/i915/display: Fix the encoder type check

 Documentation/gpu/amdgpu.rst   |   9 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |   4 +-
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h  |   3 +-
 drivers/gpu/drm/amd/display/dc/dsc/Makefile|   2 -
 drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c|  18 +-
 drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c   | 151 -
 drivers/gpu/drm/amd/display/dc/dsc/rc_calc.h   |   5 +-
 drivers/gpu/drm/amd/display/dc/dsc/rc_calc_dpi.c   |  27 +--
 .../drm/amd/display/modules/color/color_gamma.c|   4 +-
 drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c   |   2 +-
 drivers/gpu/drm/i915/display/intel_ddi.c   |  12 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c|   8 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c  |   4 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c|  52 -
 drivers/gpu/drm/i915/gt/intel_ring.c   |   4 +
 

Re: [PATCH 2/2] net: ethernet: mvneta: Add 2500BaseX support for SoCs without comphy

2020-06-18 Thread David Miller
From: Sascha Hauer 
Date: Tue, 16 Jun 2020 10:31:40 +0200

> The older SoCs like Armada XP support a 2500BaseX mode in the datasheets
> referred to as DR-SGMII (Double rated SGMII) or HS-SGMII (High Speed
> SGMII). This is an upclocked 1000BaseX mode, thus
> PHY_INTERFACE_MODE_2500BASEX is the appropriate mode define for it.
> adding support for it merely means writing the correct magic value into
> the MVNETA_SERDES_CFG register.
> 
> Signed-off-by: Sascha Hauer 

Applied.


Re: [PATCH 1/2] net: ethernet: mvneta: Fix Serdes configuration for SoCs without comphy

2020-06-18 Thread David Miller
From: Sascha Hauer 
Date: Tue, 16 Jun 2020 10:31:39 +0200

> The MVNETA_SERDES_CFG register is only available on older SoCs like the
> Armada XP. On newer SoCs like the Armada 38x the fields are moved to
> comphy. This patch moves the writes to this register next to the comphy
> initialization, so that depending on the SoC either comphy or
> MVNETA_SERDES_CFG is configured.
> With this we no longer write to the MVNETA_SERDES_CFG on SoCs where it
> doesn't exist.
> 
> Suggested-by: Russell King 
> Signed-off-by: Sascha Hauer 

Applied.


Re: [PATCH v2 1/3] docs: IOMMU user API

2020-06-18 Thread Alex Williamson
On Fri, 19 Jun 2020 02:15:36 +
"Liu, Yi L"  wrote:

> Hi Alex,
> 
> > From: Alex Williamson 
> > Sent: Friday, June 19, 2020 5:48 AM
> > 
> > On Wed, 17 Jun 2020 08:28:24 +
> > "Tian, Kevin"  wrote:
> >   
> > > > From: Liu, Yi L 
> > > > Sent: Wednesday, June 17, 2020 2:20 PM
> > > >  
> > > > > From: Jacob Pan 
> > > > > Sent: Tuesday, June 16, 2020 11:22 PM
> > > > >
> > > > > On Thu, 11 Jun 2020 17:27:27 -0700
> > > > > Jacob Pan  wrote:
> > > > >  
> > > > > > >
> > > > > > > But then I thought it even better if VFIO leaves the entire
> > > > > > > copy_from_user() to the layer consuming it.
> > > > > > >  
> > > > > > OK. Sounds good, that was what Kevin suggested also. I just wasn't
> > > > > > sure how much VFIO wants to inspect, I thought VFIO layer wanted to 
> > > > > > do
> > > > > > a sanity check.
> > > > > >
> > > > > > Anyway, I will move copy_from_user to iommu uapi layer.  
> > > > >
> > > > > Just one more point brought up by Yi when we discuss this offline.
> > > > >
> > > > > If we move copy_from_user to iommu uapi layer, then there will be  
> > > > multiple  
> > > > > copy_from_user calls for the same data when a VFIO container has  
> > > > multiple domains,  
> > > > > devices. For bind, it might be OK. But might be additional overhead 
> > > > > for TLB  
> > > > flush  
> > > > > request from the guest.  
> > > >
> > > > I think it is the same with bind and TLB flush path. will be multiple
> > > > copy_from_user.  
> > >
> > > multiple copies is possibly fine. In reality we allow only one group per
> > > nesting container (as described in patch [03/15]), and usually there
> > > is just one SVA-capable device per group.
> > >  
> > > >
> > > > BTW. for moving data copy to iommy layer, there is another point which
> > > > need to consider. VFIO needs to do unbind in bind path if bind failed,
> > > > so it will assemble unbind_data and pass to iommu layer. If iommu layer
> > > > do the copy_from_user, I think it will be failed. any idea?  
> > 
> > If a call into a UAPI fails, there should be nothing to undo.  Creating
> > a partial setup for a failed call that needs to be undone by the caller
> > is not good practice.  
> 
> is it still a problem if it's the VFIO to undo the partial setup before
> returning to user space?

Yes.  If a UAPI function fails there should be no residual effect.
 
> > > This might be mitigated if we go back to use the same bind_data for both
> > > bind/unbind. Then you can reuse the user object for unwinding.
> > >
> > > However there is another case where VFIO may need to assemble the
> > > bind_data itself. When a VM is killed, VFIO needs to walk allocated PASIDs
> > > and unbind them one-by-one. In such case copy_from_user doesn't work
> > > since the data is created by kernel. Alex, do you have a suggestion how 
> > > this
> > > usage can be supported? e.g. asking IOMMU driver to provide two sets of
> > > APIs to handle user/kernel generated requests?  
> > 
> > Yes, it seems like vfio would need to make use of a driver API to do
> > this, we shouldn't be faking a user buffer in the kernel in order to
> > call through to a UAPI.  Thanks,  
> 
> ok, so if VFIO wants to issue unbind by itself, it should use an API which
> passes kernel buffer to IOMMU layer. If the unbind request is from user
> space, then VFIO should use another API which passes user buffer pointer
> to IOMMU layer. makes sense. will align with jacob.

Sounds right to me.  Different approaches might be used for the driver
API versus the UAPI, perhaps there is no buffer.  Thanks,

Alex



  1   2   3   4   5   6   7   8   9   10   >