Re: [PATCH] kbuild: run the checker after the compiler

2020-06-22 Thread Masahiro Yamada
On Tue, Jun 23, 2020 at 12:47 AM Luc Van Oostenryck
 wrote:
>
> Since the pre-git time the checker is run first, before the compiler.
> But if the source file contains some syntax error, the warnings from
> the compiler are more useful than those from sparse (and other
> checker most probably too).
>
> So move the 'check' command to run after the compiler.
>
> Signed-off-by: Luc Van Oostenryck 

Applied to linux-kbuild.
Thanks.

> ---
>  scripts/Makefile.build | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 2e8810b7e5ed..7ba6a752d5bd 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -252,9 +252,9 @@ cmd_gen_ksymdeps = \
>  endif
>
>  define rule_cc_o_c
> -   $(call cmd,checksrc)
> $(call cmd_and_fixdep,cc_o_c)
> $(call cmd,gen_ksymdeps)
> +   $(call cmd,checksrc)
> $(call cmd,checkdoc)
> $(call cmd,objtool)
> $(call cmd,modversions_c)
> @@ -277,8 +277,8 @@ endif
>
>  # Built-in and composite module parts
>  $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE
> -   $(call cmd,force_checksrc)
> $(call if_changed_rule,cc_o_c)
> +   $(call cmd,force_checksrc)
>
>  cmd_mod = { \
> echo $(if $($*-objs)$($*-y)$($*-m), $(addprefix $(obj)/, $($*-objs) 
> $($*-y) $($*-m)), $(@:.mod=.o)); \
>
> base-commit: 48778464bb7d346b47157d21ffde2af6b2d39110
> --
> 2.27.0
>


-- 
Best Regards
Masahiro Yamada


drivers/staging/wfx/fwio.c:88:2: note: in expansion of macro 'if'

2020-06-22 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   dd0d718152e4c65b173070d48ea9dfc06894c3e5
commit: 652b4afb240e5dc196995597942309e89e89c767 staging: wfx: load firmware
date:   9 months ago
config: xtensa-randconfig-m031-20200623 (attached as .config)
compiler: xtensa-linux-gcc (GCC) 9.3.0

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

All warnings (new ones prefixed by >>):

   drivers/staging/wfx/fwio.c:83:5: warning: no previous prototype for 
'sram_write_dma_safe' [-Wmissing-prototypes]
  83 | int sram_write_dma_safe(struct wfx_dev *wdev, u32 addr, const u8 
*buf, size_t len)
 | ^~~
   In file included from include/linux/firmware.h:6,
from drivers/staging/wfx/fwio.c:8:
   drivers/staging/wfx/fwio.c: In function 'sram_write_dma_safe':
   arch/xtensa/include/asm/page.h:182:9: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
 182 |  ((pfn) >= ARCH_PFN_OFFSET && ((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
 | ^~
   include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
  58 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
 |^~~~
>> drivers/staging/wfx/fwio.c:88:2: note: in expansion of macro 'if'
  88 |  if (!virt_addr_valid(buf)) {
 |  ^~
   arch/xtensa/include/asm/page.h:190:32: note: in expansion of macro 
'pfn_valid'
 190 | #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
 |^
   drivers/staging/wfx/fwio.c:88:7: note: in expansion of macro 
'virt_addr_valid'
  88 |  if (!virt_addr_valid(buf)) {
 |   ^~~
   arch/xtensa/include/asm/page.h:182:9: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
 182 |  ((pfn) >= ARCH_PFN_OFFSET && ((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
 | ^~
   include/linux/compiler.h:58:61: note: in definition of macro '__trace_if_var'
  58 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
 | ^~~~
>> drivers/staging/wfx/fwio.c:88:2: note: in expansion of macro 'if'
  88 |  if (!virt_addr_valid(buf)) {
 |  ^~
   arch/xtensa/include/asm/page.h:190:32: note: in expansion of macro 
'pfn_valid'
 190 | #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
 |^
   drivers/staging/wfx/fwio.c:88:7: note: in expansion of macro 
'virt_addr_valid'
  88 |  if (!virt_addr_valid(buf)) {
 |   ^~~
   arch/xtensa/include/asm/page.h:182:9: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
 182 |  ((pfn) >= ARCH_PFN_OFFSET && ((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
 | ^~
   include/linux/compiler.h:69:3: note: in definition of macro 
'__trace_if_value'
  69 |  (cond) ? \
 |   ^~~~
   include/linux/compiler.h:56:28: note: in expansion of macro '__trace_if_var'
  56 | #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) 
) )
 |^~
>> drivers/staging/wfx/fwio.c:88:2: note: in expansion of macro 'if'
  88 |  if (!virt_addr_valid(buf)) {
 |  ^~
   arch/xtensa/include/asm/page.h:190:32: note: in expansion of macro 
'pfn_valid'
 190 | #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
 |^
   drivers/staging/wfx/fwio.c:88:7: note: in expansion of macro 
'virt_addr_valid'
  88 |  if (!virt_addr_valid(buf)) {
 |   ^~~
   arch/xtensa/include/asm/page.h:182:9: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
 182 |  ((pfn) >= ARCH_PFN_OFFSET && ((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
 | ^~
   include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
  58 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
 |^~~~
   drivers/staging/wfx/fwio.c:96:2: note: in expansion of macro 'if'
  96 |  if (!virt_addr_valid(buf))
 |  ^~
   arch/xtensa/include/asm/page.h:190:32: note: in expansion of macro 
'pfn_valid'
 190 | #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
 |^
   drivers/staging/wfx/fwio.c:96:7: note: in expansion of macro 
'virt_addr_valid'
  96 |  if (!virt_addr_valid(buf))
 |   ^~~
   arch/xtensa/include/asm/page.h:182:9: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
 

Re: [PATCH] docs: f2fs: fix a broken table

2020-06-22 Thread Mauro Carvalho Chehab
Em Mon, 22 Jun 2020 11:22:09 -0600
Jonathan Corbet  escreveu:

> On Mon, 22 Jun 2020 10:11:06 -0700
> Eric Biggers  wrote:
> 
> > Someone already sent out a fix for this:
> > https://lkml.kernel.org/linux-doc/52f851cb5c9fd2ecae97deec7e168e66b8c295c3.1591137229.git.mchehab+hua...@kernel.org/

No problem from my side.

> > 
> > Is it intentional that you're sending out a different fix rather than 
> > applying
> > that one?  
> 
> It wasn't, actually, I'm just finding myself more than usually challenged
> these days.
> 
> That said, removing the table entirely seems ... excessive.  It's not
> terrible the way it is, or we could make it:

Jon,

I actually tried a patch close to yours before the patch I actually sent
upstream.

On my previous version, I was doing:

 ===
...
test_dummy_encryption
test_dummy_encryption=%s Enable dummy encryption, which provides a fake fscrypt
 context. The fake fscrypt context is used by xfstests.
 The argument may be either "v1" or "v2", in order to
 select the corresponding fscrypt policy version.
...
 ===

The problem with the above is that Sphinx understood the first line as one row,
and the second one as a different one. So, the HTML output would be like:


...
test_dummy_encryption
test_dummy_encryption=%s
Enable dummy encryption, which provides a fake fscrypt
context. The fake fscrypt context is used by xfstests.
The argument may be either "v1" or "v2", in order to
select the corresponding fscrypt policy version.


(e. g. it would look like the first parameter lacks description)

Which is not the intended result. I was unable to identify a way 
to teach Sphinx that the second line was a continuation of the
first (A ReST equivalent to placing a \ at the end of a line).

Still, the html output with the above is not that bad, and it should be clear
for readers that the description of the second parameter is also valid for the
first.


Thanks,
Mauro


KASAN: use-after-free Read in cgroup_throttle_swaprate

2020-06-22 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=11d6561510
kernel config:  https://syzkaller.appspot.com/x/.config?x=be4578b3f1083656
dashboard link: https://syzkaller.appspot.com/bug?extid=5e421ac7ea78f893184b
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+5e421ac7ea78f8931...@syzkaller.appspotmail.com

==
BUG: KASAN: use-after-free in atomic_read 
include/asm-generic/atomic-instrumented.h:26 [inline]
BUG: KASAN: use-after-free in blk_cgroup_congested 
include/linux/blk-cgroup.h:288 [inline]
BUG: KASAN: use-after-free in cgroup_throttle_swaprate+0x268/0x4f0 
mm/swapfile.c:3799
Read of size 4 at addr 888098690d80 by task syz-executor.1/11017

CPU: 0 PID: 11017 Comm: syz-executor.1 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
 check_memory_region_inline mm/kasan/generic.c:183 [inline]
 check_memory_region+0x2b5/0x2f0 mm/kasan/generic.c:192
 atomic_read include/asm-generic/atomic-instrumented.h:26 [inline]
 blk_cgroup_congested include/linux/blk-cgroup.h:288 [inline]
 cgroup_throttle_swaprate+0x268/0x4f0 mm/swapfile.c:3799
 wp_page_copy+0x29c/0x1ff0 mm/memory.c:2680
 do_wp_page+0x750/0x1810 mm/memory.c:2919
 handle_pte_fault mm/memory.c:4233 [inline]
 __handle_mm_fault mm/memory.c:4347 [inline]
 handle_mm_fault+0x23fc/0x2910 mm/memory.c:4384
 faultin_page mm/gup.c:888 [inline]
 __get_user_pages+0xbf5/0x16f0 mm/gup.c:1114
 __get_user_pages_locked mm/gup.c:1307 [inline]
 __get_user_pages_remote+0x130/0x680 mm/gup.c:1858
 process_vm_rw_single_vec mm/process_vm_access.c:108 [inline]
 process_vm_rw_core+0x458/0x990 mm/process_vm_access.c:218
 process_vm_rw+0x1b7/0x270 mm/process_vm_access.c:286
 __do_sys_process_vm_writev mm/process_vm_access.c:308 [inline]
 __se_sys_process_vm_writev mm/process_vm_access.c:303 [inline]
 __x64_sys_process_vm_writev+0xdc/0xf0 mm/process_vm_access.c:303
 do_syscall_64+0xf3/0x1b0 arch/x86/entry/common.c:295
 entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x45ca59
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f34c4af9c78 EFLAGS: 0246 ORIG_RAX: 0137
RAX: ffda RBX: 004fb1a0 RCX: 0045ca59
RDX: 1005 RSI: 2000 RDI: 0108
RBP: 0078bfa0 R08: 023a R09: 
R10: 2180 R11: 0246 R12: 
R13: 087c R14: 004cb674 R15: 7f34c4afa6d4

Allocated by task 1:
 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]
 cgroup1_root_to_use kernel/cgroup/cgroup-v1.c:1183 [inline]
 cgroup1_get_tree+0x747/0xae0 kernel/cgroup/cgroup-v1.c:1207
 vfs_get_tree+0x88/0x270 fs/super.c:1547
 do_new_mount fs/namespace.c:2874 [inline]
 do_mount+0x17e8/0x2900 fs/namespace.c:3199
 __do_sys_mount fs/namespace.c:3409 [inline]
 __se_sys_mount+0xd3/0x100 fs/namespace.c:3386
 do_syscall_64+0xf3/0x1b0 arch/x86/entry/common.c:295
 entry_SYSCALL_64_after_hwframe+0x49/0xb3

Freed by task 17:
 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
 process_one_work+0x76e/0xfd0 kernel/workqueue.c:2268
 worker_thread+0xa7f/0x1450 kernel/workqueue.c:2414
 kthread+0x353/0x380 kernel/kthread.c:268
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:351

The buggy address belongs to the object at 88809869
 which belongs to the cache kmalloc-8k of size 8192
The buggy address is located 3456 bytes inside of
 8192-byte region [88809869, 888098692000)
The buggy address belongs to the page:
page:ea000261a400 refcount:1 mapcount:0 mapping: index:0x0 
head:ea000261a400 order:2 compound_mapcount:0 compound_pincount:0
flags: 0xfffe010200(slab|head)
raw: 00fffe010200 

Re: [PATCH] kbuild: Provide way to actually disable stack protector

2020-06-22 Thread Kees Cook
On Tue, Jun 23, 2020 at 11:33:53AM +0900, Masahiro Yamada wrote:
> On Tue, Jun 23, 2020 at 4:02 AM Kees Cook  wrote:
> >
> > Some builds of GCC enable stack protector by default. Simply removing
> > the arguments is not sufficient to disable stack protector, as the stack
> > protector for those GCC builds must be explicitly disabled. (Removing the
> > arguments is left as-is just to be sure there are no ordering problems. If
> > -fno-stack-protector ended up _before_ -fstack-protector, it would not
> > disable it: GCC uses whichever -f... comes last on the command line.)
> >
> > Fixes: 20355e5f73a7 ("x86/entry: Exclude low level entry code from 
> > sanitizing")
> > Signed-off-by: Kees Cook 
> > ---
> >  Makefile  | 4 +++-
> >  arch/Kconfig  | 3 ---
> >  arch/arm/boot/compressed/Makefile | 4 ++--
> >  arch/x86/entry/Makefile   | 3 +++
> >  4 files changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index ac2c61c37a73..b46e91bf0b0e 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -762,7 +762,9 @@ ifneq ($(CONFIG_FRAME_WARN),0)
> >  KBUILD_CFLAGS += -Wframe-larger-than=$(CONFIG_FRAME_WARN)
> >  endif
> >
> > -stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
> > +DISABLE_STACKPROTECTOR := $(call cc-option,-fno-stack-protector)
> > +export DISABLE_STACKPROTECTOR
> > +stackp-flags-y:= 
> > $(DISABLE_STACKPROTECTOR)
> >  stackp-flags-$(CONFIG_STACKPROTECTOR) := -fstack-protector
> >  stackp-flags-$(CONFIG_STACKPROTECTOR_STRONG)  := 
> > -fstack-protector-strong
> >
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 8cc35dc556c7..1ea61290900a 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -478,9 +478,6 @@ config HAVE_STACKPROTECTOR
> >   An arch should select this symbol if:
> >   - it has implemented a stack canary (e.g. __stack_chk_guard)
> >
> > -config CC_HAS_STACKPROTECTOR_NONE
> > -   def_bool $(cc-option,-fno-stack-protector)
> > -
> >  config STACKPROTECTOR
> > bool "Stack Protector buffer overflow detection"
> > depends on HAVE_STACKPROTECTOR
> > diff --git a/arch/arm/boot/compressed/Makefile 
> > b/arch/arm/boot/compressed/Makefile
> > index 00602a6fba04..3693bac525d2 100644
> > --- a/arch/arm/boot/compressed/Makefile
> > +++ b/arch/arm/boot/compressed/Makefile
> > @@ -84,9 +84,9 @@ endif
> >
> >  # -fstack-protector-strong triggers protection checks in this code,
> >  # but it is being used too early to link to meaningful stack_chk logic.
> > -nossp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
> >  $(foreach o, $(libfdt_objs) atags_to_fdt.o, \
> > -   $(eval CFLAGS_$(o) := -I $(srctree)/scripts/dtc/libfdt 
> > $(nossp-flags-y)))
> > +   $(eval CFLAGS_$(o) := -I $(srctree)/scripts/dtc/libfdt \
> > + $(DISABLE_STACKPROTECTOR)))
> >
> >  # These were previously generated C files. When you are building the kernel
> >  # with O=, make sure to remove the stale files in the output tree. 
> > Otherwise,
> > diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile
> > index b7a5790d8d63..79902decc3d1 100644
> > --- a/arch/x86/entry/Makefile
> > +++ b/arch/x86/entry/Makefile
> > @@ -10,6 +10,9 @@ KCOV_INSTRUMENT := n
> >  CFLAGS_REMOVE_common.o = $(CC_FLAGS_FTRACE) -fstack-protector 
> > -fstack-protector-strong
> >  CFLAGS_REMOVE_syscall_32.o = $(CC_FLAGS_FTRACE) -fstack-protector 
> > -fstack-protector-strong
> >  CFLAGS_REMOVE_syscall_64.o = $(CC_FLAGS_FTRACE) -fstack-protector 
> > -fstack-protector-strong
> > +CFLAGS_common.o += $(DISABLE_STACKPROTECTOR)
> > +CFLAGS_syscall_32.o += $(DISABLE_STACKPROTECTOR)
> > +CFLAGS_syscall_64.o += $(DISABLE_STACKPROTECTOR)
> 
> There is one more c file in this directory.
> 
> Is it OK to not patch syscall_x32.c ?

Good question. Peter? (It seems all the syscall_*.c files are just a
table, not code -- why do they need any instrumentation changes?)

> 
> 
> >
> >  CFLAGS_syscall_64.o+= $(call cc-option,-Wno-override-init,)
> >  CFLAGS_syscall_32.o+= $(call cc-option,-Wno-override-init,)
> 
> 
> 
> 
> This patch is ugly.
> 
> I'd rather want to fix this by one-liner.

Why not a global export to assist? This isn't the only place it's needed
(see the arm64 chunk...)

> 
> 
> 
> 
> diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile
> index b7a5790d8d63..0d41eb91aaea 100644
> --- a/arch/x86/entry/Makefile
> +++ b/arch/x86/entry/Makefile
> @@ -11,6 +11,8 @@ CFLAGS_REMOVE_common.o = $(CC_FLAGS_FTRACE)
> -fstack-protector -fstack-protector-
>  CFLAGS_REMOVE_syscall_32.o = $(CC_FLAGS_FTRACE) -fstack-protector
> -fstack-protector-strong
>  CFLAGS_REMOVE_syscall_64.o = $(CC_FLAGS_FTRACE) -fstack-protector
> -fstack-protector-strong
> 
> +ccflags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) += -fno-stack-protector
> +

Order matters here -- when is ccflags-y applied?

>  

Re: [PATCH] ASoC: fsl_easrc: Fix uninitialized scalar variable in fsl_easrc_set_ctx_format

2020-06-22 Thread Nicolin Chen
On Mon, Jun 22, 2020 at 05:03:31PM +0800, Shengjiu Wang wrote:
> The "ret" in fsl_easrc_set_ctx_format is not initialized, then
> the unknown value maybe returned by this function.
> 
> Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers")
> Signed-off-by: Shengjiu Wang 

Acked-by: Nicolin Chen 


Re: [PATCH v7 0/7] Add interrupt support to FPGA DFL drivers

2020-06-22 Thread Xu Yilun
On Mon, Jun 22, 2020 at 05:27:20AM -0700, Tom Rix wrote:
> In addition to reviewing, I have run these changes on the pac a10 card and 
> while i do not have an afu using interrupts, I have exercised some of the new 
> interfaces.
> 
> The most useful i have submitted to selftests drivers/fpga.  In the future, 
> this would be a good place to put other fpga unit tests. 
> 
> The selftest patch depends on this change.
> 
> So you can also add
> 
> Tested-by: Tom Rix 

Yes I'll add your Tested-by tag.

Thanks,
Yilun

> 
> Tom
> 
> On 6/21/20 11:48 PM, Xu Yilun wrote:
> > Hi Moritz:
> >
> > Could you please help review the patchset when you have time?
> >
> > You have already reviewed the first 3 patches some time ago. The
> > comments are all fixed. Hao and Redhat guys also have done several
> > rounds of review. The patches are all Acked-by Hao, reviewed by
> > Marcelo & Tom.
> >
> > There is little change to the code for several months, seems it stays
> > ready and just need your final Ack.
> >
> > Actually this is the last feature for our first generation PAC A10 Card,
> > and is important for users to have the full support.
> >
> > We really need your help on code review ...
> >
> > Many thanks!
> > Yilun
> >
> > On Tue, Jun 16, 2020 at 12:08:41PM +0800, Xu Yilun wrote:
> >> This patchset add interrupt support to FPGA DFL drivers.
> >>
> >> With these patches, DFL driver will parse and assign interrupt resources
> >> for enumerated feature devices and their sub features.
> >>
> >> This patchset also introduces a set of APIs for user to monitor DFL
> >> interrupts. Three sub features (DFL FME error, DFL AFU error and user
> >> interrupt) drivers now support these APIs.
> >>
> >> Patch #1: DFL framework change. Accept interrupt info input from DFL bus
> >>   driver, and add interrupt parsing and assignment for feature
> >>   sub devices.
> >> Patch #2: DFL pci driver change, add interrupt info on DFL enumeration.
> >> Patch #3: DFL framework change. Add helper functions for feature sub
> >>   device drivers to handle interrupt and notify users.
> >> Patch #4: Add interrupt support for AFU error reporting sub feature.
> >> Patch #5: Add interrupt support for FME global error reporting sub
> >>   feature.
> >> Patch #6: Add interrupt support for a new sub feature, to handle user
> >>   interrupts implemented in AFU.
> >> Patch #7: Documentation for DFL interrupt handling.
> >>
> >> Main changes from v1:
> >>  - Early validating irq table for each feature in parse_feature_irq()
> >>in Patch #1.
> >>  - Changes IOCTL interfaces. use DFL_FPGA_FME/PORT_XXX_GET_IRQ_NUM
> >>instead of DFL_FPGA_FME/PORT_XXX_GET_INFO, delete flag field for
> >>DFL_FPGA_FME/PORT_XXX_SET_IRQ param
> >>
> >> Main changes from v2:
> >>  - put parse_feature_irqs() inside create_feature_instance().
> >>  - refines code for dfl_fpga_set_irq_triggers, delete local variable j.
> >>  - put_user() instead of copy_to_user() for DFL_FPGA_XXX_GET_IRQ_NUM IOCTL
> >>
> >> Main changes from v3:
> >>  - rebased to 5.7-rc1.
> >>  - fail the dfl enumeration when irq parsing error happens.
> >>  - Add 2 helper functions in dfl.c to handle generic irq ioctls in feature
> >>drivers.
> >>
> >> Main changes from v4:
> >>  - Minor fixes for Hao's comments.
> >>
> >> Main changes from v5:
> >>  - Remove unnecessary type casting in Patch #1 & #3.
> >>  - Minor fixes for Moritz's comments.
> >>
> >> Main changes from v6:
> >>  - Add the header file  for Patch #1, to fix build
> >>error on ARCH=xtensa
> >>  - Minor fixes in Patch #2 & #3.
> >>
> >> Xu Yilun (7):
> >>   fpga: dfl: parse interrupt info for feature devices on enumeration
> >>   fpga: dfl: pci: add irq info for feature devices enumeration
> >>   fpga: dfl: introduce interrupt trigger setting API
> >>   fpga: dfl: afu: add interrupt support for port error reporting
> >>   fpga: dfl: fme: add interrupt support for global error reporting
> >>   fpga: dfl: afu: add AFU interrupt support
> >>   Documentation: fpga: dfl: add descriptions for interrupt related
> >> interfaces.
> >>
> >>  Documentation/fpga/dfl.rst|  19 +++
> >>  drivers/fpga/dfl-afu-error.c  |  17 +++
> >>  drivers/fpga/dfl-afu-main.c   |  32 +
> >>  drivers/fpga/dfl-fme-error.c  |  18 +++
> >>  drivers/fpga/dfl-fme-main.c   |   6 +
> >>  drivers/fpga/dfl-pci.c|  76 +--
> >>  drivers/fpga/dfl.c| 310 
> >> ++
> >>  drivers/fpga/dfl.h|  57 
> >>  include/uapi/linux/fpga-dfl.h |  82 +++
> >>  9 files changed, 608 insertions(+), 9 deletions(-)
> >>
> >> -- 
> >> 2.7.4


Re: kprobe: __blkdev_put probe is missed

2020-06-22 Thread Masami Hiramatsu
On Tue, 23 Jun 2020 09:38:01 +0900
Masami Hiramatsu  wrote:

> On Tue, 23 Jun 2020 08:47:06 +0900
> Masami Hiramatsu  wrote:
> 
> > On Mon, 22 Jun 2020 09:01:48 -0400
> > Steven Rostedt  wrote:
> > 
> > > On Mon, 22 Jun 2020 08:27:53 +0800
> > > Ming Lei  wrote:
> > > 
> > > > Can you kprobe guys improve the implementation for covering this case?
> > > > For example, put probe on 3) in case the above situation is recognized.
> > > 
> > > To do so would require solving the halting problem.
> > > 
> > >   https://en.wikipedia.org/wiki/Halting_problem
> > > 
> > > Or perhaps reading the DWARF output of the compiler to determine if it
> > > optimized the location you are looking for.
> > 
> > As far as I can see, gcc-9.3 doesn't generate this information :(
> > Maybe the optimizer forgot to push the tail-call callsite information
> > to dwarf generator when making a recursive tail-call to a loop.
> > 
> > > The first case is impossible to solve, the second would take a lot of
> > > work, (are you going to fund it?)
> > 
> > What I can provide is "--skip-prologue" option for the perf-probe
> > which will be similar to the "-P" option. If the compiler correctly
> > generates the information, we can enable it automatically. But
> > as far as I can see, it doesn't.
> > 
> > [OT] DWARF has its option(and GNU extension) but it seems not correctly
> > implemented yet.
> >  
> > http://www.dwarfstd.org/ShowIssue.php?issue=100909.2
> 
> Oops, sorry, I missed the following sentences.
> 
> "Tail calls are jump-like instructions which transfer control to the start
> of some subprogram, but the call site location address isn't visible in the
> unwind information."
> 
> "Tail recursion is a call to the current function which is compiled as a
> loop into the middle of the current function."
> 
> "The DW_TAG_call_site entries describe normal and tail calls."
> 
> This means, the gcc is correctly implemented and this __blkdev_put() case
> is NOT covered by DT_TAG_call_site.
> So we can not detect it from the debuginfo.

Hmm, BTW, if optimization is further advanced, it is possible that
the loop start position is not always at the beginning of the function.
It is easy to provide --skip-prologue to perf probe but it doesn't
ensure that works always as you expected.

For example,

func()
{
1:
{ /* block which doesn't executed in tail-recursion call */
...
}
2:
{ /* block which always executed in tail-recursion call */
...
}
func()
}

In this case, it is natural that the optimizer put a jump to 2 instead
of 1. Moreover, if the number of recursion is fixed, the optimizer
can unroll the loop. In that case there are no jumps. 

So, as Steve pointed, strictly speaking, the developer needs to understand
what the source code was compiled into, before tracing/debuging it.

For the perf-probe case, I'm now thinking it is better user to
choose the line in the function explicitly. I wish I had another flag
that there was a tail-recursion, then I can warn users...

Thank you,

-- 
Masami Hiramatsu 


Re: [PATCH v7 17/19] mm: memcg/slab: use a single set of kmem_caches for all allocations

2020-06-22 Thread Shakeel Butt
On Mon, Jun 22, 2020 at 6:58 PM Roman Gushchin  wrote:
>
> Instead of having two sets of kmem_caches: one for system-wide and
> non-accounted allocations and the second one shared by all accounted
> allocations, we can use just one.
>
> The idea is simple: space for obj_cgroup metadata can be allocated on
> demand and filled only for accounted allocations.
>
> It allows to remove a bunch of code which is required to handle kmem_cache
> clones for accounted allocations.  There is no more need to create them,
> accumulate statistics, propagate attributes, etc.  It's a quite
> significant simplification.
>
> Also, because the total number of slab_caches is reduced almost twice (not
> all kmem_caches have a memcg clone), some additional memory savings are
> expected.  On my devvm it additionally saves about 3.5% of slab memory.
>
> Suggested-by: Johannes Weiner 
> Signed-off-by: Roman Gushchin 
> Reviewed-by: Vlastimil Babka 

Reviewed-by: Shakeel Butt 


Re: [PATCH] binder: fix null deref of proc->context

2020-06-22 Thread Greg Kroah-Hartman
On Mon, Jun 22, 2020 at 01:59:04PM -0700, Todd Kjos wrote:
> On Mon, Jun 22, 2020 at 1:18 PM Todd Kjos  wrote:
> >
> > On Mon, Jun 22, 2020 at 1:09 PM Christian Brauner
> >  wrote:
> > >
> > > On Mon, Jun 22, 2020 at 01:07:15PM -0700, Todd Kjos wrote:
> > > > The binder driver makes the assumption proc->context pointer is 
> > > > invariant after
> > > > initialization (as documented in the kerneldoc header for struct proc).
> > > > However, in commit f0fe2c0f050d ("binder: prevent UAF for binderfs 
> > > > devices II")
> > > > proc->context is set to NULL during binder_deferred_release().
> > > >
> > > > Another proc was in the middle of setting up a transaction to the dying
> > > > process and crashed on a NULL pointer deref on "context" which is a 
> > > > local
> > > > set to >context:
> > > >
> > > > new_ref->data.desc = (node == context->binder_context_mgr_node) ? 0 
> > > > : 1;
> > > >
> > > > Here's the stack:
> > > >
> > > > [ 5237.855435] Call trace:
> > > > [ 5237.855441] binder_get_ref_for_node_olocked+0x100/0x2ec
> > > > [ 5237.855446] binder_inc_ref_for_node+0x140/0x280
> > > > [ 5237.855451] binder_translate_binder+0x1d0/0x388
> > > > [ 5237.855456] binder_transaction+0x2228/0x3730
> > > > [ 5237.855461] binder_thread_write+0x640/0x25bc
> > > > [ 5237.855466] binder_ioctl_write_read+0xb0/0x464
> > > > [ 5237.855471] binder_ioctl+0x30c/0x96c
> > > > [ 5237.855477] do_vfs_ioctl+0x3e0/0x700
> > > > [ 5237.855482] __arm64_sys_ioctl+0x78/0xa4
> > > > [ 5237.855488] el0_svc_common+0xb4/0x194
> > > > [ 5237.855493] el0_svc_handler+0x74/0x98
> > > > [ 5237.855497] el0_svc+0x8/0xc
> > > >
> > > > The fix is to move the kfree of the binder_device to binder_free_proc()
> > > > so the binder_device is freed when we know there are no references
> > > > remaining on the binder_proc.
> > > >
> > > > Fixes: f0fe2c0f050d ("binder: prevent UAF for binderfs devices II")
> > > > Signed-off-by: Todd Kjos 
> >
> > Forgot to include stable. The issue was introduced in 5.6, so fix needed in 
> > 5.7.
> > Cc: sta...@vger.kernel.org # 5.7
> 
> Turns out the patch with the issue was also backported to 5.4.y, so
> the fix is needed there too.

With the fixes tag in there and cc: stable, it will get to the proper
trees no matter how far back it was backported :)

thanks,

greg k-h


Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency improvement

2020-06-22 Thread Greg Kroah-Hartman
On Mon, Jun 22, 2020 at 02:27:38PM -0700, Rick Lindsley wrote:
> 
> On Mon, Jun 22, 2020 at 01:48:45PM -0400, Tejun Heo wrote:
> 
> > It should be obvious that representing each consecutive memory range with a
> > separate directory entry is far from an optimal way of representing
> > something like this. It's outright silly.
> 
> On 6/22/20 11:03 AM, Greg Kroah-Hartman wrote:
> 
> > I agree.  And again, Ian, you are just "kicking the problem down the
> > road" if we accept these patches.  Please fix this up properly so that
> > this interface is correctly fixed to not do looney things like this.
> 
> Given that we cannot change the underlying machine representation of
> this hardware, what do you (all, not just you Greg) consider to be
> "properly"?

Change the userspace representation of the hardware then.  Why does
userspace care about so many individual blocks, what happens if you
provide them a larger granularity?  I can't imagine userspace really
wants to see 20k devices and manage them individually, where is the code
that does that?

What happens if you delay adding the devices until after booting?
Userspace should be event driven and only handle things after it sees
the devices being present, so try delaying and seeing what happens to
prevent this from keeping boot from progressing.

thanks,

greg k-h


Re: [TEGRA194_CPUFREQ Patch v3 3/4] cpufreq: Add Tegra194 cpufreq driver

2020-06-22 Thread Sumit Gupta

Hi Viresh,

Thank you for the review. please find my reply inline.



+++ b/drivers/cpufreq/tegra194-cpufreq.c
@@ -0,0 +1,403 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, NVIDIA CORPORATION. All rights reserved


 2020


+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+#define KHZ 1000
+#define REF_CLK_MHZ 408 /* 408 MHz */
+#define US_DELAY500
+#define US_DELAY_MIN2
+#define CPUFREQ_TBL_STEP_HZ (50 * KHZ * KHZ)
+#define MAX_CNT ~0U
+
+/* cpufreq transisition latency */
+#define TEGRA_CPUFREQ_TRANSITION_LATENCY (300 * 1000) /* unit in nanoseconds */
+
+#define LOOP_FOR_EACH_CPU_OF_CLUSTER(cl) for (cpu = (cl * 2); \
+ cpu < ((cl + 1) * 2); cpu++)


Both latency and this loop are used only once in the code, maybe just open code
it. Also you should have passed cpu as a parameter to the macro, even if it
works fine without it, for better readability.

Ok, i will open code the loop in next version. For latency value, i feel 
named macro makes readability better. So, prefer keeping it.



+
+u16 map_freq_to_ndiv(struct mrq_cpu_ndiv_limits_response *nltbl, u32 freq)


Unused routine


Sure, will remove it.


+{
+ return DIV_ROUND_UP(freq * nltbl->pdiv * nltbl->mdiv,
+ nltbl->ref_clk_hz / KHZ);
+}



+static int tegra194_cpufreq_init(struct cpufreq_policy *policy)
+{
+ struct tegra194_cpufreq_data *data = cpufreq_get_driver_data();
+ int cl = get_cpu_cluster(policy->cpu);
+ u32 cpu;
+
+ if (cl >= data->num_clusters)
+ return -EINVAL;
+
+ policy->cur = tegra194_fast_get_speed(policy->cpu); /* boot freq */
+
+ /* set same policy for all cpus in a cluster */
+ LOOP_FOR_EACH_CPU_OF_CLUSTER(cl)
+ cpumask_set_cpu(cpu, policy->cpus);
+
+ policy->freq_table = data->tables[cl];
+ policy->cpuinfo.transition_latency = TEGRA_CPUFREQ_TRANSITION_LATENCY;
+
+ return 0;
+}



+static int tegra194_cpufreq_set_target(struct cpufreq_policy *policy,
+unsigned int index)
+{
+ struct cpufreq_frequency_table *tbl = policy->freq_table + index;
+
+ on_each_cpu_mask(policy->cpus, set_cpu_ndiv, tbl, true);


I am still a bit confused. While setting the frequency you are calling this
routine for each CPU of the policy (cluster). Does that mean that CPUs within a
cluster can actually run at different frequencies at any given point of time ?

If cpufreq terms, a cpufreq policy represents a group of CPUs that change
frequency together, i.e. they share the clk line. If all CPUs in your system can
do DVFS separately, then you must have policy per CPU, instead of cluster.

T194 supports four CPU clusters, each with two cores. Each CPU cluster 
is capable of running at a specific frequency sourced by respective 
NAFLL to provide cluster specific clocks. Individual cores within a 
cluster write freq in per core register. Cluster h/w forwards the 
max(core0, core1) request to per cluster NAFLL.



+static void tegra194_cpufreq_free_resources(void)
+{
+ flush_workqueue(read_counters_wq);


Why is this required exactly? I see that you add the work request and
immediately flush it, then why would you need to do this separately ?


Ya, will remove flush_workqueue().


+ destroy_workqueue(read_counters_wq);
+}
+
+static struct cpufreq_frequency_table *
+init_freq_table(struct platform_device *pdev, struct tegra_bpmp *bpmp,
+ unsigned int cluster_id)
+{
+ struct cpufreq_frequency_table *freq_table;
+ struct mrq_cpu_ndiv_limits_response resp;
+ unsigned int num_freqs, ndiv, delta_ndiv;
+ struct mrq_cpu_ndiv_limits_request req;
+ struct tegra_bpmp_message msg;
+ u16 freq_table_step_size;
+ int err, index;
+
+ memset(, 0, sizeof(req));
+ req.cluster_id = cluster_id;
+
+ memset(, 0, sizeof(msg));
+ msg.mrq = MRQ_CPU_NDIV_LIMITS;
+ msg.tx.data = 
+ msg.tx.size = sizeof(req);
+ msg.rx.data = 
+ msg.rx.size = sizeof(resp);
+
+ err = tegra_bpmp_transfer(bpmp, );


So the firmware can actually return different frequency tables for the clusters,
right ? Else you could have received the table only once and used it for all the
CPUs.

Yes, frequency tables are returned per cluster by BPMP firmware. In T194 
SOC, currently same table values are used for all clusters. This might 
change in future.



+ if (err)
+ return ERR_PTR(err);
+
+ /*
+  * Make sure frequency table step is a multiple of mdiv to match
+  * vhint table granularity.
+  */
+ freq_table_step_size = resp.mdiv *
+ DIV_ROUND_UP(CPUFREQ_TBL_STEP_HZ, resp.ref_clk_hz);
+
+ dev_dbg(>dev, "cluster %d: frequency table step size: %d\n",
+ cluster_id, freq_table_step_size);

Re: [PATCH v7 09/19] mm: memcg/slab: charge individual slab objects instead of pages

2020-06-22 Thread Shakeel Butt
On Mon, Jun 22, 2020 at 6:58 PM Roman Gushchin  wrote:
>
> Switch to per-object accounting of non-root slab objects.
>
> Charging is performed using obj_cgroup API in the pre_alloc hook.
> Obj_cgroup is charged with the size of the object and the size of
> metadata: as now it's the size of an obj_cgroup pointer.  If the amount of
> memory has been charged successfully, the actual allocation code is
> executed.  Otherwise, -ENOMEM is returned.
>
> In the post_alloc hook if the actual allocation succeeded, corresponding
> vmstats are bumped and the obj_cgroup pointer is saved.  Otherwise, the
> charge is canceled.
>
> On the free path obj_cgroup pointer is obtained and used to uncharge the
> size of the releasing object.
>
> Memcg and lruvec counters are now representing only memory used by active
> slab objects and do not include the free space.  The free space is shared
> and doesn't belong to any specific cgroup.
>
> Global per-node slab vmstats are still modified from
> (un)charge_slab_page() functions.  The idea is to keep all slab pages
> accounted as slab pages on system level.
>
> Signed-off-by: Roman Gushchin 
> Reviewed-by: Vlastimil Babka 
> ---
[snip]
> +static inline struct kmem_cache *memcg_slab_pre_alloc_hook(struct kmem_cache 
> *s,
> +   struct obj_cgroup **objcgp,
> +   size_t objects, gfp_t flags)
> +{
> +   struct kmem_cache *cachep;
> +
> +   cachep = memcg_kmem_get_cache(s, objcgp);
> +   if (is_root_cache(cachep))
> +   return s;
> +
> +   if (obj_cgroup_charge(*objcgp, flags, objects * obj_full_size(s))) {
> +   memcg_kmem_put_cache(cachep);

I think you forgot to put obj_cgroup_put(*objcgp) here again.

> +   cachep = NULL;
> +   }
> +
> +   return cachep;
> +}
> +

After the above fix:

Reviewed-by: Shakeel Butt 


[PATCH V2 3/6] dt-bindings: regulator: add MP5496 regulator compatible

2020-06-22 Thread Kathiravan T
IPQ6018 uses the PMIC MP5496. Add the binding for the same.

Signed-off-by: Kathiravan T 
---
 Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt 
b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
index dea4384..728c001 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
@@ -19,6 +19,7 @@ Regulator nodes are identified by their compatible:
Usage: required
Value type: 
Definition: must be one of:
+   "qcom,rpm-mp5496-regulators"
"qcom,rpm-pm8841-regulators"
"qcom,rpm-pm8916-regulators"
"qcom,rpm-pm8941-regulators"
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH V2 6/6] dt-bindings: regulator: convert QCOM SMD-RPM regulator document to YAML schema

2020-06-22 Thread Kathiravan T
Convert qcom,smd-rpm-regulator.txt document to YAML schema

Signed-off-by: Kathiravan T 
---
 .../bindings/regulator/qcom,smd-rpm-regulator.txt  | 321 -
 .../bindings/regulator/qcom,smd-rpm-regulator.yaml | 106 +++
 2 files changed, 106 insertions(+), 321 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt 
b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
deleted file mode 100644
index 728c001..
--- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
+++ /dev/null
@@ -1,321 +0,0 @@
-QCOM SMD RPM REGULATOR
-
-The Qualcomm RPM over SMD regulator is modelled as a subdevice of the RPM.
-Because SMD is used as the communication transport mechanism, the RPM resides 
as
-a subnode of the SMD.  As such, the SMD-RPM regulator requires that the SMD and
-RPM nodes be present.
-
-Please refer to Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt for
-information pertaining to the SMD node.
-
-Please refer to Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt for
-information regarding the RPM node.
-
-== Regulator
-
-Regulator nodes are identified by their compatible:
-
-- compatible:
-   Usage: required
-   Value type: 
-   Definition: must be one of:
-   "qcom,rpm-mp5496-regulators"
-   "qcom,rpm-pm8841-regulators"
-   "qcom,rpm-pm8916-regulators"
-   "qcom,rpm-pm8941-regulators"
-   "qcom,rpm-pm8950-regulators"
-   "qcom,rpm-pm8994-regulators"
-   "qcom,rpm-pm8998-regulators"
-   "qcom,rpm-pma8084-regulators"
-   "qcom,rpm-pmi8994-regulators"
-   "qcom,rpm-pmi8998-regulators"
-   "qcom,rpm-pms405-regulators"
-
-- vdd_s1-supply:
-- vdd_s2-supply:
-- vdd_s3-supply:
-- vdd_s4-supply:
-- vdd_s5-supply:
-- vdd_s6-supply:
-- vdd_s7-supply:
-- vdd_s8-supply:
-   Usage: optional (pm8841 only)
-   Value type: 
-   Definition: reference to regulator supplying the input pin, as
-   described in the data sheet
-
-- vdd_s1-supply:
-- vdd_s2-supply:
-- vdd_s3-supply:
-- vdd_s4-supply:
-- vdd_l1_l2_l3-supply:
-- vdd_l4_l5_l6-supply:
-- vdd_l7-supply:
-- vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18-supply:
-   Usage: optional (pm8916 only)
-   Value type: 
-   Definition: reference to regulator supplying the input pin, as
-   described in the data sheet
-
-- vdd_s1-supply:
-- vdd_s2-supply:
-- vdd_s3-supply:
-- vdd_s4-supply:
-- vdd_s4-supply:
-- vdd_s5-supply:
-- vdd_s6-supply:
-- vdd_l1_l19-supply:
-- vdd_l2_l23-supply:
-- vdd_l3-supply:
-- vdd_l4_l5_l6_l7_l16-supply:
-- vdd_l8_l11_l12_l17_l22-supply:
-- vdd_l9_l10_l13_l14_l15_l18-supply:
-- vdd_l20-supply:
-- vdd_l21-supply:
-   Usage: optional (pm8950 only)
-   Value type: 
-   Definition: reference to regulator supplying the input pin, as
-   described in the data sheet
-
-- vdd_s1-supply:
-- vdd_s2-supply:
-- vdd_s3-supply:
-- vdd_l1_l3-supply:
-- vdd_l2_lvs1_2_3-supply:
-- vdd_l4_l11-supply:
-- vdd_l5_l7-supply:
-- vdd_l6_l12_l14_l15-supply:
-- vdd_l8_l16_l18_l19-supply:
-- vdd_l9_l10_l17_l22-supply:
-- vdd_l13_l20_l23_l24-supply:
-- vdd_l21-supply:
-- vin_5vs-supply:
-   Usage: optional (pm8941 only)
-   Value type: 
-   Definition: reference to regulator supplying the input pin, as
-   described in the data sheet
-
-- vdd_s1-supply:
-- vdd_s2-supply:
-- vdd_s3-supply:
-- vdd_s4-supply:
-- vdd_s5-supply:
-- vdd_s6-supply:
-- vdd_s7-supply:
-- vdd_s8-supply:
-- vdd_s9-supply:
-- vdd_s10-supply:
-- vdd_s11-supply:
-- vdd_s12-supply:
-- vdd_l1-supply:
-- vdd_l2_l26_l28-supply:
-- vdd_l3_l11-supply:
-- vdd_l4_l27_l31-supply:
-- vdd_l5_l7-supply:
-- vdd_l6_l12_l32-supply:
-- vdd_l5_l7-supply:
-- vdd_l8_l16_l30-supply:
-- vdd_l9_l10_l18_l22-supply:
-- vdd_l9_l10_l18_l22-supply:
-- vdd_l3_l11-supply:
-- vdd_l6_l12_l32-supply:
-- vdd_l13_l19_l23_l24-supply:
-- vdd_l14_l15-supply:
-- vdd_l14_l15-supply:
-- vdd_l8_l16_l30-supply:
-- vdd_l17_l29-supply:
-- vdd_l9_l10_l18_l22-supply:
-- vdd_l13_l19_l23_l24-supply:
-- vdd_l20_l21-supply:
-- vdd_l20_l21-supply:
-- vdd_l9_l10_l18_l22-supply:
-- vdd_l13_l19_l23_l24-supply:
-- vdd_l13_l19_l23_l24-supply:
-- vdd_l25-supply:
-- vdd_l2_l26_l28-supply:
-- vdd_l4_l27_l31-supply:
-- vdd_l2_l26_l28-supply:
-- vdd_l17_l29-supply:
-- vdd_l8_l16_l30-supply:
-- vdd_l4_l27_l31-supply:
-- vdd_l6_l12_l32-supply:
-- vdd_lvs1_2-supply:
-   Usage: optional (pm8994 only)
-   Value type: 
-   Definition: reference to regulator supplying the input pin, as
-   described in the data sheet
-
-- vdd_s1-supply:
-- 

[PATCH V2 4/6] regulator: qcom_smd: Add MP5496 regulators

2020-06-22 Thread Kathiravan T
IPQ6018 SoC uses the PMIC MP5496. SMPA2 and LDOA2 regulator controls the
APSS and SDCC voltage scaling respectively. Add support for the same.

Signed-off-by: Kathiravan T 
---
 drivers/regulator/qcom_smd-regulator.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/regulator/qcom_smd-regulator.c 
b/drivers/regulator/qcom_smd-regulator.c
index 53a64d8..e6d137a 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -198,6 +198,15 @@ static const struct regulator_ops rpm_bob_ops = {
.set_voltage = rpm_reg_set_voltage,
 };
 
+static const struct regulator_ops rpm_mp5496_ops = {
+   .enable = rpm_reg_enable,
+   .disable = rpm_reg_disable,
+   .is_enabled = rpm_reg_is_enabled,
+   .list_voltage = regulator_list_voltage_linear_range,
+
+   .set_voltage = rpm_reg_set_voltage,
+};
+
 static const struct regulator_desc pma8084_hfsmps = {
.linear_ranges = (struct linear_range[]) {
REGULATOR_LINEAR_RANGE(375000,  0,  95, 12500),
@@ -595,6 +604,24 @@ static const struct regulator_desc pms405_pldo600 = {
.ops = _smps_ldo_ops,
 };
 
+static const struct regulator_desc mp5496_smpa2 = {
+   .linear_ranges = (struct linear_range[]) {
+   REGULATOR_LINEAR_RANGE(725000, 0, 27, 12500),
+   },
+   .n_linear_ranges = 1,
+   .n_voltages = 28,
+   .ops = _mp5496_ops,
+};
+
+static const struct regulator_desc mp5496_ldoa2 = {
+   .linear_ranges = (struct linear_range[]) {
+   REGULATOR_LINEAR_RANGE(180, 0, 60, 25000),
+   },
+   .n_linear_ranges = 1,
+   .n_voltages = 61,
+   .ops = _mp5496_ops,
+};
+
 struct rpm_regulator_data {
const char *name;
u32 type;
@@ -603,6 +630,12 @@ struct rpm_regulator_data {
const char *supply;
 };
 
+static const struct rpm_regulator_data rpm_mp5496_regulators[] = {
+   { "s2", QCOM_SMD_RPM_SMPA, 2, _smpa2, "s2" },
+   { "l2", QCOM_SMD_RPM_LDOA, 2, _ldoa2, "l2" },
+   {}
+};
+
 static const struct rpm_regulator_data rpm_pm8841_regulators[] = {
{ "s1", QCOM_SMD_RPM_SMPB, 1, _hfsmps, "vdd_s1" },
{ "s2", QCOM_SMD_RPM_SMPB, 2, _ftsmps, "vdd_s2" },
@@ -901,6 +934,7 @@ static const struct rpm_regulator_data 
rpm_pms405_regulators[] = {
 };
 
 static const struct of_device_id rpm_of_match[] = {
+   { .compatible = "qcom,rpm-mp5496-regulators", .data = 
_mp5496_regulators },
{ .compatible = "qcom,rpm-pm8841-regulators", .data = 
_pm8841_regulators },
{ .compatible = "qcom,rpm-pm8916-regulators", .data = 
_pm8916_regulators },
{ .compatible = "qcom,rpm-pm8941-regulators", .data = 
_pm8941_regulators },
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH V2 5/6] dt-bindings: soc: qcom: convert the SMD-RPM document to YAML schema

2020-06-22 Thread Kathiravan T
Convert the qcom,smd-rpm.txt document to YAML schema

Signed-off-by: Kathiravan T 
---
 .../devicetree/bindings/soc/qcom/qcom,smd-rpm.txt  | 63 ---
 .../devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml | 92 ++
 2 files changed, 92 insertions(+), 63 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
deleted file mode 100644
index a817c61..
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-Qualcomm Resource Power Manager (RPM) over SMD
-
-This driver is used to interface with the Resource Power Manager (RPM) found in
-various Qualcomm platforms. The RPM allows each component in the system to vote
-for state of the system resources, such as clocks, regulators and bus
-frequencies.
-
-The SMD information for the RPM edge should be filled out.  See qcom,smd.txt 
for
-the required edge properties.  All SMD related properties will reside within 
the
-RPM node itself.
-
-= SUBDEVICES
-
-The RPM exposes resources to its subnodes.  The rpm_requests node must be
-present and this subnode may contain children that designate regulator
-resources.
-
-- compatible:
-   Usage: required
-   Value type: 
-   Definition: must be one of:
-   "qcom,rpm-apq8084"
-   "qcom,rpm-ipq6018"
-   "qcom,rpm-msm8916"
-   "qcom,rpm-msm8974"
-   "qcom,rpm-msm8976"
-   "qcom,rpm-msm8998"
-   "qcom,rpm-sdm660"
-   "qcom,rpm-qcs404"
-
-- qcom,smd-channels:
-   Usage: required
-   Value type: 
-   Definition: must be "rpm_requests"
-
-Refer to Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
-for information on the regulator subnodes that can exist under the 
rpm_requests.
-
-Example:
-
-   soc {
-   apcs: syscon@f9011000 {
-   compatible = "syscon";
-   reg = <0xf9011000 0x1000>;
-   };
-   };
-
-   smd {
-   compatible = "qcom,smd";
-
-   rpm {
-   interrupts = <0 168 1>;
-   qcom,ipc = < 8 0>;
-   qcom,smd-edge = <15>;
-
-   rpm_requests {
-   compatible = "qcom,rpm-msm8974";
-   qcom,smd-channels = "rpm_requests";
-
-   ...
-   };
-   };
-   };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml 
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
new file mode 100644
index ..06aa6b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/qcom/qcom,smd-rpm.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Qualcomm Resource Power Manager (RPM) over SMD
+
+description: |
+  This driver is used to interface with the Resource Power Manager (RPM) found
+  in various Qualcomm platforms. The RPM allows each component in the system
+  to vote for state of the system resources, such as clocks, regulators and bus
+  frequencies.
+
+  The SMD information for the RPM edge should be filled out.  See qcom,smd.txt
+  for the required edge properties.  All SMD related properties will reside
+  within the RPM node itself.
+
+  The RPM exposes resources to its subnodes.  The rpm_requests node must be
+  present and this subnode may contain children that designate regulator
+  resources.
+
+  Refer to 
Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
+  for information on the regulator subnodes that can exist under the
+  rpm_requests.
+
+maintainers:
+  - Kathiravan T 
+
+properties:
+  compatible:
+enum:
+  - qcom,rpm-apq8084
+  - qcom,rpm-ipq6018
+  - qcom,rpm-msm8916
+  - qcom,rpm-msm8974
+  - qcom,rpm-msm8976
+  - qcom,rpm-msm8996
+  - qcom,rpm-msm8998
+  - qcom,rpm-sdm660
+  - qcom,rpm-qcs404
+
+  qcom,smd-channels:
+$ref: /schemas/types.yaml#/definitions/string-array
+description: Channel name used for the RPM communication
+items:
+  - const: rpm_requests
+
+if:
+  properties:
+compatible:
+  contains:
+enum:
+  - qcom,rpm-apq8084
+  - qcom,rpm-msm8916
+  - qcom,rpm-msm8974
+then:
+  required:
+- qcom,smd-channels
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+soc {
+#address-cells = <1>;
+#size-cells = <1>;
+apcs: syscon@f9011000 {
+  

[PATCH V2 1/6] dt-bindings: soc: qcom: Add IPQ6018 compatible

2020-06-22 Thread Kathiravan T
This patch adds the dt-binding for the rpm on the Qualcomm IPQ6018
platform.

Signed-off-by: Kathiravan T 
---
 Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
index 616fddc..a817c61 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
@@ -20,6 +20,7 @@ resources.
Value type: 
Definition: must be one of:
"qcom,rpm-apq8084"
+   "qcom,rpm-ipq6018"
"qcom,rpm-msm8916"
"qcom,rpm-msm8974"
"qcom,rpm-msm8976"
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH V2 2/6] soc: qcom: smd-rpm: Add IPQ6018 compatible

2020-06-22 Thread Kathiravan T
This patch adds a compatible for the rpm on the Qualcomm IPQ6018 platform.

Signed-off-by: Kathiravan T 
---
 drivers/soc/qcom/smd-rpm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
index 005dd30..1a5226a 100644
--- a/drivers/soc/qcom/smd-rpm.c
+++ b/drivers/soc/qcom/smd-rpm.c
@@ -230,6 +230,7 @@ static void qcom_smd_rpm_remove(struct rpmsg_device *rpdev)
 
 static const struct of_device_id qcom_smd_rpm_of_match[] = {
{ .compatible = "qcom,rpm-apq8084" },
+   { .compatible = "qcom,rpm-ipq6018" },
{ .compatible = "qcom,rpm-msm8916" },
{ .compatible = "qcom,rpm-msm8974" },
{ .compatible = "qcom,rpm-msm8976" },
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH V2 0/6] Add frequency / voltage scaling support for IPQ6018 SoC

2020-06-22 Thread Kathiravan T
IPQ6018 SoC uses the PMIC MP5496. SMPA2 and LDOA2 regulator of MP5496
controls the APSS and SDCC voltage scaling respectively. Add support
for the same.

changes since V1:
- Moved YAML conversion to the last as per Mark's comments

Kathiravan T (6):
  dt-bindings: soc: qcom: Add IPQ6018 compatible
  soc: qcom: smd-rpm: Add IPQ6018 compatible
  dt-bindings: regulator: add MP5496 regulator compatible
  regulator: qcom_smd: Add MP5496 regulators
  dt-bindings: soc: qcom: convert the SMD-RPM document to YAML schema
  dt-bindings: regulator: convert QCOM SMD-RPM regulator document to
YAML schema

 .../bindings/regulator/qcom,smd-rpm-regulator.txt  | 320 -
 .../bindings/regulator/qcom,smd-rpm-regulator.yaml | 106 +++
 .../devicetree/bindings/soc/qcom/qcom,smd-rpm.txt  |  62 
 .../devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml |  92 ++
 drivers/regulator/qcom_smd-regulator.c |  34 +++
 drivers/soc/qcom/smd-rpm.c |   1 +
 6 files changed, 233 insertions(+), 382 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml
 delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH] cpufreq: cppc: Reorder code and remove apply_hisi_workaround variable

2020-06-22 Thread Viresh Kumar
With the current approach we have an extra check in the
cppc_cpufreq_get_rate() callback, which checks if hisilicon's get rate
implementation should be used instead. While it works fine, the approach
isn't very straight forward, over that we have an extra check in the
routine.

Rearrange code and update the cpufreq driver's get() callback pointer
directly for the hisilicon case. This gets the extra variable is removed
and the extra check isn't required anymore as well.

Signed-off-by: Viresh Kumar 
---
Xiongfeng Wang, will it be possible for you to give this a try as I
can't really test it locally.

 drivers/cpufreq/cppc_cpufreq.c | 91 --
 1 file changed, 42 insertions(+), 49 deletions(-)

diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
index 257d726a4456..03a21daddbec 100644
--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -45,8 +45,6 @@ struct cppc_workaround_oem_info {
u32 oem_revision;
 };
 
-static bool apply_hisi_workaround;
-
 static struct cppc_workaround_oem_info wa_info[] = {
{
.oem_id = "HISI  ",
@@ -59,50 +57,6 @@ static struct cppc_workaround_oem_info wa_info[] = {
}
 };
 
-static unsigned int cppc_cpufreq_perf_to_khz(struct cppc_cpudata *cpu,
-   unsigned int perf);
-
-/*
- * HISI platform does not support delivered performance counter and
- * reference performance counter. It can calculate the performance using the
- * platform specific mechanism. We reuse the desired performance register to
- * store the real performance calculated by the platform.
- */
-static unsigned int hisi_cppc_cpufreq_get_rate(unsigned int cpunum)
-{
-   struct cppc_cpudata *cpudata = all_cpu_data[cpunum];
-   u64 desired_perf;
-   int ret;
-
-   ret = cppc_get_desired_perf(cpunum, _perf);
-   if (ret < 0)
-   return -EIO;
-
-   return cppc_cpufreq_perf_to_khz(cpudata, desired_perf);
-}
-
-static void cppc_check_hisi_workaround(void)
-{
-   struct acpi_table_header *tbl;
-   acpi_status status = AE_OK;
-   int i;
-
-   status = acpi_get_table(ACPI_SIG_PCCT, 0, );
-   if (ACPI_FAILURE(status) || !tbl)
-   return;
-
-   for (i = 0; i < ARRAY_SIZE(wa_info); i++) {
-   if (!memcmp(wa_info[i].oem_id, tbl->oem_id, ACPI_OEM_ID_SIZE) &&
-   !memcmp(wa_info[i].oem_table_id, tbl->oem_table_id, 
ACPI_OEM_TABLE_ID_SIZE) &&
-   wa_info[i].oem_revision == tbl->oem_revision) {
-   apply_hisi_workaround = true;
-   break;
-   }
-   }
-
-   acpi_put_table(tbl);
-}
-
 /* Callback function used to retrieve the max frequency from DMI */
 static void cppc_find_dmi_mhz(const struct dmi_header *dm, void *private)
 {
@@ -402,9 +356,6 @@ static unsigned int cppc_cpufreq_get_rate(unsigned int 
cpunum)
struct cppc_cpudata *cpu = all_cpu_data[cpunum];
int ret;
 
-   if (apply_hisi_workaround)
-   return hisi_cppc_cpufreq_get_rate(cpunum);
-
ret = cppc_get_perf_ctrs(cpunum, _ctrs_t0);
if (ret)
return ret;
@@ -455,6 +406,48 @@ static struct cpufreq_driver cppc_cpufreq_driver = {
.name = "cppc_cpufreq",
 };
 
+/*
+ * HISI platform does not support delivered performance counter and
+ * reference performance counter. It can calculate the performance using the
+ * platform specific mechanism. We reuse the desired performance register to
+ * store the real performance calculated by the platform.
+ */
+static unsigned int hisi_cppc_cpufreq_get_rate(unsigned int cpunum)
+{
+   struct cppc_cpudata *cpudata = all_cpu_data[cpunum];
+   u64 desired_perf;
+   int ret;
+
+   ret = cppc_get_desired_perf(cpunum, _perf);
+   if (ret < 0)
+   return -EIO;
+
+   return cppc_cpufreq_perf_to_khz(cpudata, desired_perf);
+}
+
+static void cppc_check_hisi_workaround(void)
+{
+   struct acpi_table_header *tbl;
+   acpi_status status = AE_OK;
+   int i;
+
+   status = acpi_get_table(ACPI_SIG_PCCT, 0, );
+   if (ACPI_FAILURE(status) || !tbl)
+   return;
+
+   for (i = 0; i < ARRAY_SIZE(wa_info); i++) {
+   if (!memcmp(wa_info[i].oem_id, tbl->oem_id, ACPI_OEM_ID_SIZE) &&
+   !memcmp(wa_info[i].oem_table_id, tbl->oem_table_id, 
ACPI_OEM_TABLE_ID_SIZE) &&
+   wa_info[i].oem_revision == tbl->oem_revision) {
+   /* Overwrite the get() callback */
+   cppc_cpufreq_driver.get = hisi_cppc_cpufreq_get_rate;
+   break;
+   }
+   }
+
+   acpi_put_table(tbl);
+}
+
 static int __init cppc_cpufreq_init(void)
 {
int i, ret = 0;
-- 
2.25.0.rc1.19.g042ed3e048af



Re: [PATCH] ASoC: fsl_mqs: Fix unchecked return value for clk_prepare_enable

2020-06-22 Thread Shengjiu Wang
On Tue, Jun 23, 2020 at 12:08 AM Markus Elfring  wrote:
>
> > Fix unchecked return value for clk_prepare_enable.
> >
> > And because clk_prepare_enable and clk_disable_unprepare should
> > check input clock parameter is NULL or not, then we don't need
> > to check it before calling the function.
>
> I propose to split the adjustment of two function implementations
> into separate update steps for a small patch series.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=625d3449788f85569096780592549d0340e9c0c7#n138
>
> I suggest to improve the change descriptions accordingly.

ok, will update the patches in v2.

best regards
wang shengjiu


[PATCH 2/2] cpufreq: intel_pstate: Allow raw energy performance preference value

2020-06-22 Thread Srinivas Pandruvada
Currently using attribute "energy_performance_preference", user space can
write one of the four per-defined preference string. These preference
strings gets mapped to a hard-coded Energy-Performance Preference (EPP) or
Energy-Performance Bias (EPB) knob.

These four values supposed to cover broad spectrum of use cases, but they
are not uniformly distributed in the range. There are number of cases,
where this is not enough. For example:

Suppose user wants more performance when connected to AC. Instead of using
default "balance performance", the "performance" setting can be used. This
changes EPP value from 0x80 to 0x00. But setting EPP to 0, results in
electrical and thermal issues on some platforms. This results in CPU to do
aggressive throttling, which causes drop in performance. But some value
between 0x80 and 0x00 results in better performance. But that value can't
be fixed as the power curve is not linear. In some cases just changing EPP
from 0x80 to 0x75 is enough to get significant performance gain.

Similarly on battery EPP 0x80 can be very aggressive in power consumption.
But picking up the next choice "balance power" results in too much loss
of performance, which cause bad user experience in use case like "Google
Hangout". It was observed that some value between these two EPP is
optimal.

This change allows fine grain EPP tuning for platform like Chromebooks.
Here based on the product and use cases, different EPP values can be set.
This change is similar to the change done for:
/sys/devices/system/cpu/cpu*/power/energy_perf_bias
where user has choice to write a predefined string or raw value.

The change itself is trivial. When user preference doesn't match
predefined string preferences and value is an unsigned integer and in
range, use that value for EPP/EPB.

Suggested-by: Len Brown 
Signed-off-by: Srinivas Pandruvada 
---
 Documentation/admin-guide/pm/intel_pstate.rst |  4 +-
 drivers/cpufreq/intel_pstate.c| 63 ---
 2 files changed, 56 insertions(+), 11 deletions(-)

diff --git a/Documentation/admin-guide/pm/intel_pstate.rst 
b/Documentation/admin-guide/pm/intel_pstate.rst
index 939bfdc53f4f..1f4ef187f8a5 100644
--- a/Documentation/admin-guide/pm/intel_pstate.rst
+++ b/Documentation/admin-guide/pm/intel_pstate.rst
@@ -561,7 +561,9 @@ somewhere between the two extremes:
 Strings written to the ``energy_performance_preference`` attribute are
 internally translated to integer values written to the processor's
 Energy-Performance Preference (EPP) knob (if supported) or its
-Energy-Performance Bias (EPB) knob.
+Energy-Performance Bias (EPB) knob. It is also possible to write a positive
+integer value between 0 to 255 for EPP or 0 to 15 for EPB. Writing Invalid
+value results in error.
 
 [Note that tasks may by migrated from one CPU to another by the scheduler's
 load-balancing algorithm and if different energy vs performance hints are
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 1cf6d06f2314..251813b7060b 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -602,11 +602,12 @@ static const unsigned int epp_values[] = {
HWP_EPP_POWERSAVE
 };
 
-static int intel_pstate_get_energy_pref_index(struct cpudata *cpu_data)
+static int intel_pstate_get_energy_pref_index(struct cpudata *cpu_data, int 
*raw_epp)
 {
s16 epp;
int index = -EINVAL;
 
+   *raw_epp = 0;
epp = intel_pstate_get_epp(cpu_data, 0);
if (epp < 0)
return epp;
@@ -614,12 +615,14 @@ static int intel_pstate_get_energy_pref_index(struct 
cpudata *cpu_data)
if (boot_cpu_has(X86_FEATURE_HWP_EPP)) {
if (epp == HWP_EPP_PERFORMANCE)
return 1;
-   if (epp <= HWP_EPP_BALANCE_PERFORMANCE)
+   if (epp == HWP_EPP_BALANCE_PERFORMANCE)
return 2;
-   if (epp <= HWP_EPP_BALANCE_POWERSAVE)
+   if (epp == HWP_EPP_BALANCE_POWERSAVE)
return 3;
-   else
+   if (epp == HWP_EPP_POWERSAVE)
return 4;
+   *raw_epp = epp;
+   return 0;
} else if (boot_cpu_has(X86_FEATURE_EPB)) {
/*
 * Range:
@@ -631,6 +634,13 @@ static int intel_pstate_get_energy_pref_index(struct 
cpudata *cpu_data)
 * value which can be set. Here only using top two bits
 * effectively.
 */
+
+   if (epp & 0x03) {
+   /* Raw value was set in EPB */
+   *raw_epp = epp;
+   return 0;
+   }
+
index = (epp >> 2) + 1;
}
 
@@ -638,7 +648,8 @@ static int intel_pstate_get_energy_pref_index(struct 
cpudata *cpu_data)
 }
 
 static int intel_pstate_set_energy_pref_index(struct cpudata *cpu_data,
- int 

[PATCH 1/2] cpufreq: intel_pstate: Allow enable/disable energy efficiency

2020-06-22 Thread Srinivas Pandruvada
By default intel_pstate driver disables energy efficiency by setting
MSR_IA32_POWER_CTL bit 19 for Kaby Lake desktop CPU model in HWP mode.
This CPU model is also shared by Coffee Lake desktop CPUs. This allows
these systems to reach maximum possible frequency. But this adds power
penalty, which some customers don't want. They want some way to enable/
disable dynamically.

So, add an additional attribute "energy_efficiency_enable" under
/sys/devices/system/cpu/intel_pstate/ for these CPU models. This allows
to read and write bit 19 ("Disable Energy Efficiency Optimization") in
the MSR IA32_POWER_CTL.

This attribute is present in both HWP and non-HWP mode as this has an
effect in both modes. Refer to Intel Software Developer's manual for
details. The scope of this bit is package wide.

Suggested-by: Len Brown 
Signed-off-by: Srinivas Pandruvada 
---
 Documentation/admin-guide/pm/intel_pstate.rst |  7 +++
 drivers/cpufreq/intel_pstate.c| 49 ++-
 2 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/pm/intel_pstate.rst 
b/Documentation/admin-guide/pm/intel_pstate.rst
index 39d80bc29ccd..939bfdc53f4f 100644
--- a/Documentation/admin-guide/pm/intel_pstate.rst
+++ b/Documentation/admin-guide/pm/intel_pstate.rst
@@ -431,6 +431,13 @@ argument is passed to the kernel in the command line.
supported in the current configuration, writes to this attribute will
fail with an appropriate error.
 
+``energy_efficiency_enable``
+   This attribute is only present on platforms, which has CPUs matching
+   Kaby Lake desktop CPU model. By default "energy_efficiency" is disabled
+   on these CPU models in HWP mode by this driver. Enabling energy
+   efficiency may limit maximum operating frequency in both HWP and non
+   HWP mode.
+
 Interpretation of Policy Attributes
 ---
 
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 8e23a698ce04..1cf6d06f2314 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1218,6 +1218,44 @@ static ssize_t store_hwp_dynamic_boost(struct kobject *a,
return count;
 }
 
+#define MSR_IA32_POWER_CTL_BIT_EE  19
+
+static ssize_t show_energy_efficiency_enable(struct kobject *kobj,
+struct kobj_attribute *attr,
+char *buf)
+{
+   u64 power_ctl;
+   int enable;
+
+   rdmsrl(MSR_IA32_POWER_CTL, power_ctl);
+   enable = (power_ctl & BIT(MSR_IA32_POWER_CTL_BIT_EE)) >> 
MSR_IA32_POWER_CTL_BIT_EE;
+   return sprintf(buf, "%d\n", !enable);
+}
+
+static ssize_t store_energy_efficiency_enable(struct kobject *a,
+ struct kobj_attribute *b,
+ const char *buf, size_t count)
+{
+   u64 power_ctl;
+   u32 input;
+   int ret;
+
+   ret = kstrtouint(buf, 10, );
+   if (ret)
+   return ret;
+
+   mutex_lock(_pstate_driver_lock);
+   rdmsrl(MSR_IA32_POWER_CTL, power_ctl);
+   if (input)
+   power_ctl &= ~BIT(MSR_IA32_POWER_CTL_BIT_EE);
+   else
+   power_ctl |= BIT(MSR_IA32_POWER_CTL_BIT_EE);
+   wrmsrl(MSR_IA32_POWER_CTL, power_ctl);
+   mutex_unlock(_pstate_driver_lock);
+
+   return count;
+}
+
 show_one(max_perf_pct, max_perf_pct);
 show_one(min_perf_pct, min_perf_pct);
 
@@ -1228,6 +1266,7 @@ define_one_global_rw(min_perf_pct);
 define_one_global_ro(turbo_pct);
 define_one_global_ro(num_pstates);
 define_one_global_rw(hwp_dynamic_boost);
+define_one_global_rw(energy_efficiency_enable);
 
 static struct attribute *intel_pstate_attributes[] = {
,
@@ -1241,6 +1280,8 @@ static const struct attribute_group 
intel_pstate_attr_group = {
.attrs = intel_pstate_attributes,
 };
 
+static const struct x86_cpu_id intel_pstate_cpu_ee_disable_ids[];
+
 static void __init intel_pstate_sysfs_expose_params(void)
 {
struct kobject *intel_pstate_kobject;
@@ -1273,6 +1314,12 @@ static void __init intel_pstate_sysfs_expose_params(void)
   _dynamic_boost.attr);
WARN_ON(rc);
}
+
+   if (x86_match_cpu(intel_pstate_cpu_ee_disable_ids)) {
+   rc = sysfs_create_file(intel_pstate_kobject,
+  _efficiency_enable.attr);
+   WARN_ON(rc);
+   }
 }
 /** sysfs end /
 
@@ -1288,8 +1335,6 @@ static void intel_pstate_hwp_enable(struct cpudata 
*cpudata)
cpudata->epp_default = intel_pstate_get_epp(cpudata, 0);
 }
 
-#define MSR_IA32_POWER_CTL_BIT_EE  19
-
 /* Disable energy efficiency optimization */
 static void intel_pstate_disable_ee(int cpu)
 {
-- 
2.25.4



Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency improvement

2020-06-22 Thread Ian Kent
On Mon, 2020-06-22 at 20:03 +0200, Greg Kroah-Hartman wrote:
> On Mon, Jun 22, 2020 at 01:48:45PM -0400, Tejun Heo wrote:
> > Hello, Ian.
> > 
> > On Sun, Jun 21, 2020 at 12:55:33PM +0800, Ian Kent wrote:
> > > > > They are used for hotplugging and partitioning memory. The
> > > > > size of
> > > > > the
> > > > > segments (and thus the number of them) is dictated by the
> > > > > underlying
> > > > > hardware.
> > > > 
> > > > This sounds so bad. There gotta be a better interface for that,
> > > > right?
> > > 
> > > I'm still struggling a bit to grasp what your getting at but ...
> > 
> > I was more trying to say that the sysfs device interface with per-
> > object
> > directory isn't the right interface for this sort of usage at all.
> > Are these
> > even real hardware pieces which can be plugged in and out? While
> > being a
> > discrete piece of hardware isn't a requirement to be a device model
> > device,
> > the whole thing is designed with such use cases on mind. It
> > definitely isn't
> > the right design for representing six digit number of logical
> > entities.
> > 
> > It should be obvious that representing each consecutive memory
> > range with a
> > separate directory entry is far from an optimal way of representing
> > something like this. It's outright silly.
> 
> I agree.  And again, Ian, you are just "kicking the problem down the
> road" if we accept these patches.  Please fix this up properly so
> that
> this interface is correctly fixed to not do looney things like this.

Fine, mitigating this problem isn't the end of the story, and you
don't want to do accept a change to mitigate it because that could
mean no further discussion on it and no further work toward solving
it.

But it seems to me a "proper" solution to this will cross a number
of areas so this isn't just "my" problem and, as you point out, it's
likely to become increasingly problematic over time.

So what are your ideas and recommendations on how to handle hotplug
memory at this granularity for this much RAM (and larger amounts)?

Ian



[tip:x86/fsgsbase] BUILD SUCCESS a5d25e01c8146ad8846da4760422e12242fceafe

2020-06-22 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
x86/fsgsbase
branch HEAD: a5d25e01c8146ad8846da4760422e12242fceafe  selftests/x86: Add a 
syscall_arg_fault_64 test for negative GSBASE

elapsed time: 728m

configs tested: 126
configs skipped: 6

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
arm   corgi_defconfig
armrealview_defconfig
xtensa   allyesconfig
armmmp2_defconfig
mipsmalta_kvm_guest_defconfig
arm s3c6400_defconfig
xtensa   alldefconfig
sh  sh7785lcr_32bit_defconfig
parisc   alldefconfig
mipsmalta_qemu_32r6_defconfig
arcvdk_hs38_smp_defconfig
arm   netwinder_defconfig
mips  ath79_defconfig
xtensaxip_kc705_defconfig
armkeystone_defconfig
arm   versatile_defconfig
m68kmac_defconfig
sh   sh2007_defconfig
arm   efm32_defconfig
m68k alldefconfig
m68k apollo_defconfig
powerpc pseries_defconfig
shsh7785lcr_defconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
h8300allyesconfig
h8300allmodconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a006-20200622
i386 randconfig-a002-20200622
i386 randconfig-a003-20200622
i386 randconfig-a001-20200622
i386 randconfig-a005-20200622
i386 randconfig-a004-20200622
x86_64   randconfig-a012-20200623
x86_64   randconfig-a011-20200623
x86_64   randconfig-a013-20200623
x86_64   randconfig-a014-20200623
x86_64   randconfig-a015-20200623
x86_64   randconfig-a016-20200623
i386 randconfig-a013-20200622
i386 randconfig-a016-20200622
i386 randconfig-a012-20200622
i386 randconfig-a014-20200622
i386 randconfig-a015-20200622
i386 randconfig-a011-20200622
x86_64   randconfig-a004-20200622
x86_64   randconfig-a002-20200622
x86_64   randconfig-a003-20200622
x86_64   randconfig-a005-20200622
x86_64   randconfig-a001-20200622
x86_64   randconfig-a006-20200622
riscv

Re: [PATCH v8] mm: Proactive compaction

2020-06-22 Thread Nathan Chancellor
On Mon, Jun 22, 2020 at 09:32:12PM -0700, Nitin Gupta wrote:
> On 6/22/20 7:26 PM, Nathan Chancellor wrote:
> > On Tue, Jun 16, 2020 at 01:45:27PM -0700, Nitin Gupta wrote:
> >> For some applications, we need to allocate almost all memory as
> >> hugepages. However, on a running system, higher-order allocations can
> >> fail if the memory is fragmented. Linux kernel currently does on-demand
> >> compaction as we request more hugepages, but this style of compaction
> >> incurs very high latency. Experiments with one-time full memory
> >> compaction (followed by hugepage allocations) show that kernel is able
> >> to restore a highly fragmented memory state to a fairly compacted memory
> >> state within <1 sec for a 32G system. Such data suggests that a more
> >> proactive compaction can help us allocate a large fraction of memory as
> >> hugepages keeping allocation latencies low.
> >>
> >> For a more proactive compaction, the approach taken here is to define a
> >> new sysctl called 'vm.compaction_proactiveness' which dictates bounds
> >> for external fragmentation which kcompactd tries to maintain.
> >>
> >> The tunable takes a value in range [0, 100], with a default of 20.
> >>
> >> Note that a previous version of this patch [1] was found to introduce
> >> too many tunables (per-order extfrag{low, high}), but this one reduces
> >> them to just one sysctl. Also, the new tunable is an opaque value
> >> instead of asking for specific bounds of "external fragmentation", which
> >> would have been difficult to estimate. The internal interpretation of
> >> this opaque value allows for future fine-tuning.
> >>
> >> Currently, we use a simple translation from this tunable to [low, high]
> >> "fragmentation score" thresholds (low=100-proactiveness, high=low+10%).
> >> The score for a node is defined as weighted mean of per-zone external
> >> fragmentation. A zone's present_pages determines its weight.
> >>
> >> To periodically check per-node score, we reuse per-node kcompactd
> >> threads, which are woken up every 500 milliseconds to check the same. If
> >> a node's score exceeds its high threshold (as derived from user-provided
> >> proactiveness value), proactive compaction is started until its score
> >> reaches its low threshold value. By default, proactiveness is set to 20,
> >> which implies threshold values of low=80 and high=90.
> >>
> >> This patch is largely based on ideas from Michal Hocko [2]. See also the
> >> LWN article [3].
> >>
> >> Performance data
> >> 
> >>
> >> System: x64_64, 1T RAM, 80 CPU threads.
> >> Kernel: 5.6.0-rc3 + this patch
> >>
> >> echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
> >> echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/defrag
> >>
> >> Before starting the driver, the system was fragmented from a userspace
> >> program that allocates all memory and then for each 2M aligned section,
> >> frees 3/4 of base pages using munmap. The workload is mainly anonymous
> >> userspace pages, which are easy to move around. I intentionally avoided
> >> unmovable pages in this test to see how much latency we incur when
> >> hugepage allocations hit direct compaction.
> >>
> >> 1. Kernel hugepage allocation latencies
> >>
> >> With the system in such a fragmented state, a kernel driver then
> >> allocates as many hugepages as possible and measures allocation
> >> latency:
> >>
> >> (all latency values are in microseconds)
> >>
> >> - With vanilla 5.6.0-rc3
> >>
> >>   percentile latency
> >>   –– –––
> >>   57894
> >>  109496
> >>  25   12561
> >>  30   15295
> >>  40   18244
> >>  50   21229
> >>  60   27556
> >>  75   30147
> >>  80   31047
> >>  90   32859
> >>  95   33799
> >>
> >> Total 2M hugepages allocated = 383859 (749G worth of hugepages out of
> >> 762G total free => 98% of free memory could be allocated as hugepages)
> >>
> >> - With 5.6.0-rc3 + this patch, with proactiveness=20
> >>
> >> sysctl -w vm.compaction_proactiveness=20
> >>
> >>   percentile latency
> >>   –– –––
> >>   5   2
> >>  10   2
> >>  25   3
> >>  30   3
> >>  40   3
> >>  50   4
> >>  60   4
> >>  75   4
> >>  80   4
> >>  90   5
> >>  95 429
> >>
> >> Total 2M hugepages allocated = 384105 (750G worth of hugepages out of
> >> 762G total free => 98% of free memory could be allocated as hugepages)
> >>
> >> 2. JAVA heap allocation
> >>
> >> In this test, we first fragment memory using the same method as for (1).
> >>
> >> Then, we start a Java process with a heap size set to 700G and request
> >> the heap to be allocated with THP hugepages. We also set THP to madvise
> >> to allow hugepage backing of this heap.
> >>
> >> /usr/bin/time
> >>  java -Xms700G -Xmx700G -XX:+UseTransparentHugePages -XX:+AlwaysPreTouch
> >>
> >> The above command allocates 700G of Java heap using hugepages.
> >>
> >> - 

Re: [PATCH v1 1/3] scsi: ufs: add write booster feature support

2020-06-22 Thread Kyuho Choi
Hi Rob,

On 6/22/20, Rob Clark  wrote:
> On Sun, Jun 21, 2020 at 12:58 AM Bjorn Andersson
>  wrote:
>>
>> On Sun 21 Jun 00:40 PDT 2020, Avri Altman wrote:
>>
>> >
>> > >
>> > > On Wed, Apr 8, 2020 at 3:00 PM Asutosh Das 
>> > > wrote:
>> > > >
>> > > > The write performance of TLC NAND is considerably
>> > > > lower than SLC NAND. Using SLC NAND as a WriteBooster
>> > > > Buffer enables the write request to be processed with
>> > > > lower latency and improves the overall write performance.
>> > > >
>> > > > Adds support for shared-buffer mode WriteBooster.
>> > > >
>> > > > WriteBooster enable: SW enables it when clocks are
>> > > > scaled up, thus it's enabled only in high load conditions.
>> > > >
>> > > > WriteBooster disable: SW will disable the feature,
>> > > > when clocks are scaled down. Thus writes would go as normal
>> > > > writes.
>> > >
>> > > btw, in v5.8-rc1 (plus handful of remaining patches for lenovo c630
>> > > laptop (sdm850)), I'm seeing a lot of:
>> > >
>> > >   ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag: Sending flag query
>> > > for
>> > > idn 14 failed, err = 253
>> > >   ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag: Sending flag query
>> > > for
>> > > idn 14 failed, err = 253
>> > >   ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag_retry: query
>> > > attribute,
>> > > opcode 6, idn 14, failed with error 253 after 3 retires
>> > >   ufshcd-qcom 1d84000.ufshc: ufshcd_wb_ctrl write booster enable
>> > > failed 253
>> > >
>> > > and at least subjectively, compiling mesa seems slower, which seems
>> > > like it might be related?
>> > This looks like a device issue to be taken with the flash vendor:
>>
>> There's no way for a end-user to file a bug report with the flash vendor
>> on a device bought from an OEM and even if they would accept the bug
>> report they wouldn't re-provision the flash in an shipped device.
>>
>> So you will have to work around this in the driver.
>
> oh, ugg.. well I think these msgs from dmesg identify the part if we
> end up needing to use a denylist:
>
> scsi 0:0:0:49488: Well-known LUNSKhynix  H28S8Q302CMR A102 PQ: 0
> ANSI: 6
> scsi 0:0:0:49476: Well-known LUNSKhynix  H28S8Q302CMR A102 PQ: 0
> ANSI: 6
> scsi 0:0:0:49456: Well-known LUNSKhynix  H28S8Q302CMR A102 PQ: 0
> ANSI: 6
> scsi 0:0:0:0: Direct-Access SKhynix  H28S8Q302CMR A102 PQ: 0 ANSI:
> 6
> scsi 0:0:0:1: Direct-Access SKhynix  H28S8Q302CMR A102 PQ: 0 ANSI:
> 6
> sd 0:0:0:0: [sda] 29765632 4096-byte logical blocks: (122 GB/114 GiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 32 00 10
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports
> DPO and FUA
> sd 0:0:0:0: [sda] Optimal transfer size 786432 bytes
> scsi 0:0:0:2: Direct-Access SKhynix  H28S8Q302CMR A102 PQ: 0 ANSI:
> 6
> scsi 0:0:0:3: Direct-Access SKhynix  H28S8Q302CMR A102 PQ: 0 ANSI:
> 6
>

AFAIK, this device are ufs 2.1. It's not support writebooster.

I'd check latest linux scsi branch and ufshcd_wb_config function's
called without device capability check.

ufshcd_wb_config
 -> ufshcd_is_wb_allowed
 -> only check about hba caps with writebooster

Asutosh's first patch already check about device's capability in here.

IMO, it would be need to fixing in ufshcd_probe_hba or ufshcd_wb_config.

>
> (otoh I guess the driver could just notice that writeboost keeps
> failing and stop trying to use it)
>
> BR,
> -R
>
>
>> Regards,
>> Bjorn
>>
>> > The device reports that it supports wd, but returns inalid idn for flag
>> > 0xe...
>> >
>> > Thanks,
>> > Avri
>


Re: [PATCH v8] mm: Proactive compaction

2020-06-22 Thread Nitin Gupta
On 6/22/20 7:26 PM, Nathan Chancellor wrote:
> On Tue, Jun 16, 2020 at 01:45:27PM -0700, Nitin Gupta wrote:
>> For some applications, we need to allocate almost all memory as
>> hugepages. However, on a running system, higher-order allocations can
>> fail if the memory is fragmented. Linux kernel currently does on-demand
>> compaction as we request more hugepages, but this style of compaction
>> incurs very high latency. Experiments with one-time full memory
>> compaction (followed by hugepage allocations) show that kernel is able
>> to restore a highly fragmented memory state to a fairly compacted memory
>> state within <1 sec for a 32G system. Such data suggests that a more
>> proactive compaction can help us allocate a large fraction of memory as
>> hugepages keeping allocation latencies low.
>>
>> For a more proactive compaction, the approach taken here is to define a
>> new sysctl called 'vm.compaction_proactiveness' which dictates bounds
>> for external fragmentation which kcompactd tries to maintain.
>>
>> The tunable takes a value in range [0, 100], with a default of 20.
>>
>> Note that a previous version of this patch [1] was found to introduce
>> too many tunables (per-order extfrag{low, high}), but this one reduces
>> them to just one sysctl. Also, the new tunable is an opaque value
>> instead of asking for specific bounds of "external fragmentation", which
>> would have been difficult to estimate. The internal interpretation of
>> this opaque value allows for future fine-tuning.
>>
>> Currently, we use a simple translation from this tunable to [low, high]
>> "fragmentation score" thresholds (low=100-proactiveness, high=low+10%).
>> The score for a node is defined as weighted mean of per-zone external
>> fragmentation. A zone's present_pages determines its weight.
>>
>> To periodically check per-node score, we reuse per-node kcompactd
>> threads, which are woken up every 500 milliseconds to check the same. If
>> a node's score exceeds its high threshold (as derived from user-provided
>> proactiveness value), proactive compaction is started until its score
>> reaches its low threshold value. By default, proactiveness is set to 20,
>> which implies threshold values of low=80 and high=90.
>>
>> This patch is largely based on ideas from Michal Hocko [2]. See also the
>> LWN article [3].
>>
>> Performance data
>> 
>>
>> System: x64_64, 1T RAM, 80 CPU threads.
>> Kernel: 5.6.0-rc3 + this patch
>>
>> echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
>> echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/defrag
>>
>> Before starting the driver, the system was fragmented from a userspace
>> program that allocates all memory and then for each 2M aligned section,
>> frees 3/4 of base pages using munmap. The workload is mainly anonymous
>> userspace pages, which are easy to move around. I intentionally avoided
>> unmovable pages in this test to see how much latency we incur when
>> hugepage allocations hit direct compaction.
>>
>> 1. Kernel hugepage allocation latencies
>>
>> With the system in such a fragmented state, a kernel driver then
>> allocates as many hugepages as possible and measures allocation
>> latency:
>>
>> (all latency values are in microseconds)
>>
>> - With vanilla 5.6.0-rc3
>>
>>   percentile latency
>>   –– –––
>> 57894
>>109496
>>25   12561
>>30   15295
>>40   18244
>>50   21229
>>60   27556
>>75   30147
>>80   31047
>>90   32859
>>95   33799
>>
>> Total 2M hugepages allocated = 383859 (749G worth of hugepages out of
>> 762G total free => 98% of free memory could be allocated as hugepages)
>>
>> - With 5.6.0-rc3 + this patch, with proactiveness=20
>>
>> sysctl -w vm.compaction_proactiveness=20
>>
>>   percentile latency
>>   –– –––
>> 5   2
>>10   2
>>25   3
>>30   3
>>40   3
>>50   4
>>60   4
>>75   4
>>80   4
>>90   5
>>95 429
>>
>> Total 2M hugepages allocated = 384105 (750G worth of hugepages out of
>> 762G total free => 98% of free memory could be allocated as hugepages)
>>
>> 2. JAVA heap allocation
>>
>> In this test, we first fragment memory using the same method as for (1).
>>
>> Then, we start a Java process with a heap size set to 700G and request
>> the heap to be allocated with THP hugepages. We also set THP to madvise
>> to allow hugepage backing of this heap.
>>
>> /usr/bin/time
>>  java -Xms700G -Xmx700G -XX:+UseTransparentHugePages -XX:+AlwaysPreTouch
>>
>> The above command allocates 700G of Java heap using hugepages.
>>
>> - With vanilla 5.6.0-rc3
>>
>> 17.39user 1666.48system 27:37.89elapsed
>>
>> - With 5.6.0-rc3 + this patch, with proactiveness=20
>>
>> 8.35user 194.58system 3:19.62elapsed
>>
>> Elapsed time remains around 3:15, as proactiveness is further increased.
>>
>> 

[RFC PATCH v3 5/5] scsi: ufs: Prepare HPB read for cached sub-region

2020-06-22 Thread Daejun Park
This patch changes the read I/O to the HPB read I/O.

If the logical address of the read I/O belongs to active sub-region, the
HPB driver modifies the read I/O command to HPB read. It modifies the upiu
command of UFS instead of modifying the existing SCSI command.

In the HPB version 1.0, the maximum read I/O size that can be converted to
HPB read is 4KB.

The dirty map of the active sub-region prevents an incorrect HPB read that
has stale physical page number which is updated by previous write I/O.

Signed-off-by: Daejun Park 
---
 drivers/scsi/ufs/ufshpb.c | 235 ++
 1 file changed, 235 insertions(+)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index e1af4c2ed9ab..7c9efa46faa1 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -26,6 +26,22 @@ static inline int ufshpb_is_valid_srgn(struct ufshpb_region 
*rgn,
srgn->srgn_state == HPB_SRGN_VALID;
 }
 
+static inline bool ufshpb_is_read_cmd(struct scsi_cmnd *cmd)
+{
+   return req_op(cmd->request) == REQ_OP_READ;
+}
+
+static inline bool ufshpb_is_write_discard_cmd(struct scsi_cmnd *cmd)
+{
+   return op_is_write(req_op(cmd->request)) ||
+  op_is_discard(req_op(cmd->request));
+}
+
+static inline bool ufshpb_is_support_chunk(int transfer_len)
+{
+   return transfer_len <= HPB_MULTI_CHUNK_HIGH;
+}
+
 static inline bool ufshpb_is_general_lun(int lun)
 {
return lun < UFS_UPIU_MAX_UNIT_NUM_ID;
@@ -117,6 +133,224 @@ static inline void ufshpb_lu_put(struct ufshpb_lu *hpb)
put_device(>hpb_lu_dev);
 }
 
+static inline u32 ufshpb_get_lpn(struct scsi_cmnd *cmnd)
+{
+   return blk_rq_pos(cmnd->request) >>
+   (ilog2(cmnd->device->sector_size) - 9);
+}
+
+static inline unsigned int ufshpb_get_len(struct scsi_cmnd *cmnd)
+{
+   return blk_rq_sectors(cmnd->request) >>
+   (ilog2(cmnd->device->sector_size) - 9);
+}
+
+static void ufshpb_set_ppn_dirty(struct ufshpb_lu *hpb, int rgn_idx,
+int srgn_idx, int srgn_offset, int cnt)
+{
+   struct ufshpb_region *rgn;
+   struct ufshpb_subregion *srgn;
+   int set_bit_len;
+   int bitmap_len = hpb->entries_per_srgn;
+
+next_srgn:
+   rgn = hpb->rgn_tbl + rgn_idx;
+   srgn = rgn->srgn_tbl + srgn_idx;
+
+   if ((srgn_offset + cnt) > bitmap_len)
+   set_bit_len = bitmap_len - srgn_offset;
+   else
+   set_bit_len = cnt;
+
+   if (rgn->rgn_state != HPB_RGN_INACTIVE &&
+   srgn->srgn_state == HPB_SRGN_VALID)
+   bitmap_set(srgn->mctx->ppn_dirty, srgn_offset, set_bit_len);
+
+   srgn_offset = 0;
+   if (++srgn_idx == hpb->srgns_per_rgn) {
+   srgn_idx = 0;
+   rgn_idx++;
+   }
+
+   cnt -= set_bit_len;
+   if (cnt > 0)
+   goto next_srgn;
+
+   WARN_ON(cnt < 0);
+}
+
+static bool ufshpb_test_ppn_dirty(struct ufshpb_lu *hpb, int rgn_idx,
+  int srgn_idx, int srgn_offset, int cnt)
+{
+   struct ufshpb_region *rgn;
+   struct ufshpb_subregion *srgn;
+   int bitmap_len = hpb->entries_per_srgn;
+   int bit_len;
+
+next_srgn:
+   rgn = hpb->rgn_tbl + rgn_idx;
+   srgn = rgn->srgn_tbl + srgn_idx;
+
+   if (!ufshpb_is_valid_srgn(rgn, srgn))
+   return true;
+
+   /*
+* If the region state is active, mctx must be allocated.
+* In this case, check whether the region is evicted or
+* mctx allcation fail.
+*/
+   WARN_ON(!srgn->mctx);
+
+   if ((srgn_offset + cnt) > bitmap_len)
+   bit_len = bitmap_len - srgn_offset;
+   else
+   bit_len = cnt;
+
+   if (find_next_bit(srgn->mctx->ppn_dirty,
+ bit_len, srgn_offset) >= srgn_offset)
+   return true;
+
+   srgn_offset = 0;
+   if (++srgn_idx == hpb->srgns_per_rgn) {
+   srgn_idx = 0;
+   rgn_idx++;
+   }
+
+   cnt -= bit_len;
+   if (cnt > 0)
+   goto next_srgn;
+
+   return false;
+}
+
+static u64 ufshpb_get_ppn(struct ufshpb_lu *hpb,
+ struct ufshpb_map_ctx *mctx, int pos, int *error)
+{
+   u64 *ppn_table;
+   struct page *page;
+   int index, offset;
+
+   index = pos / (PAGE_SIZE / HPB_ENTRY_SIZE);
+   offset = pos % (PAGE_SIZE / HPB_ENTRY_SIZE);
+
+   page = mctx->m_page[index];
+   if (unlikely(!page)) {
+   *error = -ENOMEM;
+   dev_err(>hpb_lu_dev,
+   "error. cannot find page in mctx\n");
+   return 0;
+   }
+
+   ppn_table = page_address(page);
+   if (unlikely(!ppn_table)) {
+   *error = -ENOMEM;
+   dev_err(>hpb_lu_dev, "error. cannot get ppn_table\n");
+   return 0;
+   }
+
+   return ppn_table[offset];
+}
+
+static inline void

[RFC PATCH v3 4/5] scsi: ufs: L2P map management for HPB read

2020-06-22 Thread Daejun Park
This is a patch for managing L2P map in HPB module.

The HPB divides logical addresses into several regions. A region consists
of several sub-regions. The sub-region is a basic unit where L2P mapping is
managed. The driver loads L2P mapping data of each sub-region. The loaded
sub-region is called active-state. The HPB driver unloads L2P mapping data
as region unit. The unloaded region is called inactive-state.

Sub-region/region candidates to be loaded and unloaded are delivered from
the UFS device. The UFS device delivers the recommended active sub-region
and inactivate region to the driver using sensedata.
The HPB module performs L2P mapping management on the host through the
delivered information.

A pinned region is a pre-set regions on the UFS device that is always
activate-state.

The data structure for map data request and L2P map uses mempool API,
minimizing allocation overhead while avoiding static allocation.

The map_work manages active/inactive by 2 "to-do" lists.
Each hpb lun maintains 2 "to-do" lists:
  hpb->lh_inact_rgn - regions to be inactivated, and
  hpb->lh_act_srgn - subregions to be activated
Those lists are maintained on IO completion.

Signed-off-by: Daejun Park 
---
 drivers/scsi/ufs/ufshpb.c | 992 +-
 drivers/scsi/ufs/ufshpb.h |  72 +++
 2 files changed, 1060 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 84a9af2fdc80..e1af4c2ed9ab 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -15,6 +15,7 @@
 #include "ufshpb.h"
 
 static struct ufshpb_driver ufshpb_drv;
+unsigned int ufshpb_host_map_kbytes = 1 * 1024;
 
 static int ufshpb_create_sysfs(struct ufs_hba *hba, struct ufshpb_lu *hpb);
 
@@ -25,6 +26,63 @@ static inline int ufshpb_is_valid_srgn(struct ufshpb_region 
*rgn,
srgn->srgn_state == HPB_SRGN_VALID;
 }
 
+static inline bool ufshpb_is_general_lun(int lun)
+{
+   return lun < UFS_UPIU_MAX_UNIT_NUM_ID;
+}
+
+static inline bool
+ufshpb_is_pinned_region(struct ufshpb_lu *hpb, int rgn_idx)
+{
+   if (hpb->lu_pinned_end != PINNED_NOT_SET &&
+   rgn_idx >= hpb->lu_pinned_start &&
+   rgn_idx <= hpb->lu_pinned_end)
+   return true;
+
+   return false;
+}
+
+static bool ufshpb_is_empty_rsp_lists(struct ufshpb_lu *hpb)
+{
+   bool ret = true;
+   unsigned long flags;
+
+   spin_lock_irqsave(>rsp_list_lock, flags);
+   if (!list_empty(>lh_inact_rgn) || !list_empty(>lh_act_srgn))
+   ret = false;
+   spin_unlock_irqrestore(>rsp_list_lock, flags);
+
+   return ret;
+}
+
+static inline int ufshpb_may_field_valid(struct ufs_hba *hba,
+struct ufshcd_lrb *lrbp,
+struct ufshpb_rsp_field *rsp_field)
+{
+   if (be16_to_cpu(rsp_field->sense_data_len) != DEV_SENSE_SEG_LEN ||
+   rsp_field->desc_type != DEV_DES_TYPE ||
+   rsp_field->additional_len != DEV_ADDITIONAL_LEN ||
+   rsp_field->hpb_type == HPB_RSP_NONE ||
+   rsp_field->active_rgn_cnt > MAX_ACTIVE_NUM ||
+   rsp_field->inactive_rgn_cnt > MAX_INACTIVE_NUM ||
+   (!rsp_field->active_rgn_cnt && !rsp_field->inactive_rgn_cnt))
+   return -EINVAL;
+
+   if (!ufshpb_is_general_lun(lrbp->lun)) {
+   dev_warn(hba->dev, "ufshpb: lun(%d) not supported\n",
+lrbp->lun);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+
+static inline struct ufshpb_lu *ufshpb_get_hpb_data(struct scsi_cmnd *cmd)
+{
+   return cmd->device->hostdata;
+}
+
 static inline int ufshpb_get_state(struct ufshpb_lu *hpb)
 {
return atomic_read(>hpb_state);
@@ -59,6 +117,765 @@ static inline void ufshpb_lu_put(struct ufshpb_lu *hpb)
put_device(>hpb_lu_dev);
 }
 
+static struct ufshpb_req *ufshpb_get_map_req(struct ufshpb_lu *hpb,
+struct ufshpb_subregion *srgn)
+{
+   struct ufshpb_req *map_req;
+   struct request *req;
+   struct bio *bio;
+
+   map_req = kmem_cache_alloc(hpb->map_req_cache, GFP_KERNEL);
+   if (!map_req)
+   return NULL;
+
+   req = blk_get_request(hpb->sdev_ufs_lu->request_queue,
+ REQ_OP_SCSI_IN, BLK_MQ_REQ_PREEMPT);
+   if (IS_ERR(req))
+   goto free_map_req;
+
+   bio = bio_alloc(GFP_KERNEL, hpb->pages_per_srgn);
+   if (!bio) {
+   blk_put_request(req);
+   goto free_map_req;
+   }
+
+   map_req->hpb = hpb;
+   map_req->req = req;
+   map_req->bio = bio;
+
+   map_req->rgn_idx = srgn->rgn_idx;
+   map_req->srgn_idx = srgn->srgn_idx;
+   map_req->mctx = srgn->mctx;
+   map_req->lun = hpb->lun;
+
+   return map_req;
+
+free_map_req:
+   kmem_cache_free(hpb->map_req_cache, map_req);
+   return NULL;
+}
+
+static inline void 

Re: [PATCH v8] mm: Proactive compaction

2020-06-22 Thread maobibo



On 06/23/2020 10:26 AM, Nathan Chancellor wrote:
> On Tue, Jun 16, 2020 at 01:45:27PM -0700, Nitin Gupta wrote:
>> For some applications, we need to allocate almost all memory as
>> hugepages. However, on a running system, higher-order allocations can
>> fail if the memory is fragmented. Linux kernel currently does on-demand
>> compaction as we request more hugepages, but this style of compaction
>> incurs very high latency. Experiments with one-time full memory
>> compaction (followed by hugepage allocations) show that kernel is able
>> to restore a highly fragmented memory state to a fairly compacted memory
>> state within <1 sec for a 32G system. Such data suggests that a more
>> proactive compaction can help us allocate a large fraction of memory as
>> hugepages keeping allocation latencies low.
>>
>> For a more proactive compaction, the approach taken here is to define a
>> new sysctl called 'vm.compaction_proactiveness' which dictates bounds
>> for external fragmentation which kcompactd tries to maintain.
>>
>> The tunable takes a value in range [0, 100], with a default of 20.
>>
>> Note that a previous version of this patch [1] was found to introduce
>> too many tunables (per-order extfrag{low, high}), but this one reduces
>> them to just one sysctl. Also, the new tunable is an opaque value
>> instead of asking for specific bounds of "external fragmentation", which
>> would have been difficult to estimate. The internal interpretation of
>> this opaque value allows for future fine-tuning.
>>
>> Currently, we use a simple translation from this tunable to [low, high]
>> "fragmentation score" thresholds (low=100-proactiveness, high=low+10%).
>> The score for a node is defined as weighted mean of per-zone external
>> fragmentation. A zone's present_pages determines its weight.
>>
>> To periodically check per-node score, we reuse per-node kcompactd
>> threads, which are woken up every 500 milliseconds to check the same. If
>> a node's score exceeds its high threshold (as derived from user-provided
>> proactiveness value), proactive compaction is started until its score
>> reaches its low threshold value. By default, proactiveness is set to 20,
>> which implies threshold values of low=80 and high=90.
>>
>> This patch is largely based on ideas from Michal Hocko [2]. See also the
>> LWN article [3].
>>
>> Performance data
>> 
>>
>> System: x64_64, 1T RAM, 80 CPU threads.
>> Kernel: 5.6.0-rc3 + this patch
>>
>> echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
>> echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/defrag
>>
>> Before starting the driver, the system was fragmented from a userspace
>> program that allocates all memory and then for each 2M aligned section,
>> frees 3/4 of base pages using munmap. The workload is mainly anonymous
>> userspace pages, which are easy to move around. I intentionally avoided
>> unmovable pages in this test to see how much latency we incur when
>> hugepage allocations hit direct compaction.
>>
>> 1. Kernel hugepage allocation latencies
>>
>> With the system in such a fragmented state, a kernel driver then
>> allocates as many hugepages as possible and measures allocation
>> latency:
>>
>> (all latency values are in microseconds)
>>
>> - With vanilla 5.6.0-rc3
>>
>>   percentile latency
>>   –– –––
>> 57894
>>109496
>>25   12561
>>30   15295
>>40   18244
>>50   21229
>>60   27556
>>75   30147
>>80   31047
>>90   32859
>>95   33799
>>
>> Total 2M hugepages allocated = 383859 (749G worth of hugepages out of
>> 762G total free => 98% of free memory could be allocated as hugepages)
>>
>> - With 5.6.0-rc3 + this patch, with proactiveness=20
>>
>> sysctl -w vm.compaction_proactiveness=20
>>
>>   percentile latency
>>   –– –––
>> 5   2
>>10   2
>>25   3
>>30   3
>>40   3
>>50   4
>>60   4
>>75   4
>>80   4
>>90   5
>>95 429
>>
>> Total 2M hugepages allocated = 384105 (750G worth of hugepages out of
>> 762G total free => 98% of free memory could be allocated as hugepages)
>>
>> 2. JAVA heap allocation
>>
>> In this test, we first fragment memory using the same method as for (1).
>>
>> Then, we start a Java process with a heap size set to 700G and request
>> the heap to be allocated with THP hugepages. We also set THP to madvise
>> to allow hugepage backing of this heap.
>>
>> /usr/bin/time
>>  java -Xms700G -Xmx700G -XX:+UseTransparentHugePages -XX:+AlwaysPreTouch
>>
>> The above command allocates 700G of Java heap using hugepages.
>>
>> - With vanilla 5.6.0-rc3
>>
>> 17.39user 1666.48system 27:37.89elapsed
>>
>> - With 5.6.0-rc3 + this patch, with proactiveness=20
>>
>> 8.35user 194.58system 3:19.62elapsed
>>
>> Elapsed time remains around 3:15, as proactiveness is further increased.

[PATCH v2 2/3] crypto: hisilicon/zip - permit users to specify NUMA node

2020-06-22 Thread Barry Song
If users don't specify NUMA node, the driver will use the ZIP module near
the CPU allocating acomp. Otherwise, it uses the ZIP module according to
the requirement of users.

Cc: Zhou Wang 
Signed-off-by: Barry Song 
---
 drivers/crypto/hisilicon/zip/zip.h| 2 +-
 drivers/crypto/hisilicon/zip/zip_crypto.c | 6 +++---
 drivers/crypto/hisilicon/zip/zip_main.c   | 5 +++--
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/crypto/hisilicon/zip/zip.h 
b/drivers/crypto/hisilicon/zip/zip.h
index f3ed4c0e5493..4484be13812b 100644
--- a/drivers/crypto/hisilicon/zip/zip.h
+++ b/drivers/crypto/hisilicon/zip/zip.h
@@ -76,7 +76,7 @@ struct hisi_zip_sqe {
u32 rsvd1[4];
 };
 
-int zip_create_qps(struct hisi_qp **qps, int ctx_num);
+int zip_create_qps(struct hisi_qp **qps, int ctx_num, int node);
 int hisi_zip_register_to_crypto(void);
 void hisi_zip_unregister_from_crypto(void);
 #endif
diff --git a/drivers/crypto/hisilicon/zip/zip_crypto.c 
b/drivers/crypto/hisilicon/zip/zip_crypto.c
index c73707c2e539..01fd6a78111d 100644
--- a/drivers/crypto/hisilicon/zip/zip_crypto.c
+++ b/drivers/crypto/hisilicon/zip/zip_crypto.c
@@ -158,13 +158,13 @@ static void hisi_zip_release_qp(struct hisi_zip_qp_ctx 
*ctx)
hisi_qm_release_qp(ctx->qp);
 }
 
-static int hisi_zip_ctx_init(struct hisi_zip_ctx *hisi_zip_ctx, u8 req_type)
+static int hisi_zip_ctx_init(struct hisi_zip_ctx *hisi_zip_ctx, u8 req_type, 
int node)
 {
struct hisi_qp *qps[HZIP_CTX_Q_NUM] = { NULL };
struct hisi_zip *hisi_zip;
int ret, i, j;
 
-   ret = zip_create_qps(qps, HZIP_CTX_Q_NUM);
+   ret = zip_create_qps(qps, HZIP_CTX_Q_NUM, node);
if (ret) {
pr_err("Can not create zip qps!\n");
return -ENODEV;
@@ -379,7 +379,7 @@ static int hisi_zip_acomp_init(struct crypto_acomp *tfm)
struct hisi_zip_ctx *ctx = crypto_tfm_ctx(>base);
int ret;
 
-   ret = hisi_zip_ctx_init(ctx, COMP_NAME_TO_TYPE(alg_name));
+   ret = hisi_zip_ctx_init(ctx, COMP_NAME_TO_TYPE(alg_name), 
tfm->base.node);
if (ret)
return ret;
 
diff --git a/drivers/crypto/hisilicon/zip/zip_main.c 
b/drivers/crypto/hisilicon/zip/zip_main.c
index 2229a21ae7c8..e2845b2c963d 100644
--- a/drivers/crypto/hisilicon/zip/zip_main.c
+++ b/drivers/crypto/hisilicon/zip/zip_main.c
@@ -234,9 +234,10 @@ static const struct pci_device_id hisi_zip_dev_ids[] = {
 };
 MODULE_DEVICE_TABLE(pci, hisi_zip_dev_ids);
 
-int zip_create_qps(struct hisi_qp **qps, int qp_num)
+int zip_create_qps(struct hisi_qp **qps, int qp_num, int node)
 {
-   int node = cpu_to_node(smp_processor_id());
+   if (node == NUMA_NO_NODE)
+   node = cpu_to_node(smp_processor_id());
 
return hisi_qm_alloc_qps_node(_devices, qp_num, 0, node, qps);
 }
-- 
2.27.0




[PATCH v2 1/3] crypto: permit users to specify numa node of acomp hardware

2020-06-22 Thread Barry Song
For a Linux server with NUMA, there are possibly multiple (de)compressors
which are either local or remote to some NUMA node. Some drivers will
automatically use the (de)compressor near the CPU calling acomp_alloc().
However, it is not necessarily correct because users who send acomp_req
could be from different NUMA node with the CPU which allocates acomp.

Just like kernel has kmalloc() and kmalloc_node(), here crypto can have
same support.

Cc: Jonathan Cameron 
Cc: Seth Jennings 
Cc: Dan Streetman 
Cc: Vitaly Wool 
Cc: Andrew Morton 
Signed-off-by: Barry Song 
---
 -v2:
   * fix kern-doc and some codingstyle issues according to Jonathan's comment

 crypto/acompress.c |  8 
 crypto/api.c   | 22 ++
 crypto/internal.h  | 23 +++
 include/crypto/acompress.h | 18 ++
 include/linux/crypto.h |  2 ++
 5 files changed, 61 insertions(+), 12 deletions(-)

diff --git a/crypto/acompress.c b/crypto/acompress.c
index 84a76723e851..c32c72048a1c 100644
--- a/crypto/acompress.c
+++ b/crypto/acompress.c
@@ -109,6 +109,14 @@ struct crypto_acomp *crypto_alloc_acomp(const char 
*alg_name, u32 type,
 }
 EXPORT_SYMBOL_GPL(crypto_alloc_acomp);
 
+struct crypto_acomp *crypto_alloc_acomp_node(const char *alg_name, u32 type,
+   u32 mask, int node)
+{
+   return crypto_alloc_tfm_node(alg_name, _acomp_type, type, mask,
+   node);
+}
+EXPORT_SYMBOL_GPL(crypto_alloc_acomp_node);
+
 struct acomp_req *acomp_request_alloc(struct crypto_acomp *acomp)
 {
struct crypto_tfm *tfm = crypto_acomp_tfm(acomp);
diff --git a/crypto/api.c b/crypto/api.c
index edcf690800d4..4ecf712286af 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -433,8 +433,9 @@ struct crypto_tfm *crypto_alloc_base(const char *alg_name, 
u32 type, u32 mask)
 }
 EXPORT_SYMBOL_GPL(crypto_alloc_base);
 
-void *crypto_create_tfm(struct crypto_alg *alg,
-   const struct crypto_type *frontend)
+void *crypto_create_tfm_node(struct crypto_alg *alg,
+   const struct crypto_type *frontend,
+   int node)
 {
char *mem;
struct crypto_tfm *tfm = NULL;
@@ -451,6 +452,7 @@ void *crypto_create_tfm(struct crypto_alg *alg,
 
tfm = (struct crypto_tfm *)(mem + tfmsize);
tfm->__crt_alg = alg;
+   tfm->node = node;
 
err = frontend->init_tfm(tfm);
if (err)
@@ -472,7 +474,7 @@ void *crypto_create_tfm(struct crypto_alg *alg,
 out:
return mem;
 }
-EXPORT_SYMBOL_GPL(crypto_create_tfm);
+EXPORT_SYMBOL_GPL(crypto_create_tfm_node);
 
 struct crypto_alg *crypto_find_alg(const char *alg_name,
   const struct crypto_type *frontend,
@@ -490,11 +492,13 @@ struct crypto_alg *crypto_find_alg(const char *alg_name,
 EXPORT_SYMBOL_GPL(crypto_find_alg);
 
 /*
- * crypto_alloc_tfm - Locate algorithm and allocate transform
+ * crypto_alloc_tfm_node - Locate algorithm and allocate transform
  * @alg_name: Name of algorithm
  * @frontend: Frontend algorithm type
  * @type: Type of algorithm
  * @mask: Mask for type comparison
+ * @node: NUMA node in which users desire to put requests, if node is
+ * NUMA_NO_NODE, it means users have no special requirement.
  *
  * crypto_alloc_tfm() will first attempt to locate an already loaded
  * algorithm.  If that fails and the kernel supports dynamically loadable
@@ -509,8 +513,10 @@ EXPORT_SYMBOL_GPL(crypto_find_alg);
  *
  * In case of error the return value is an error pointer.
  */
-void *crypto_alloc_tfm(const char *alg_name,
-  const struct crypto_type *frontend, u32 type, u32 mask)
+
+void *crypto_alloc_tfm_node(const char *alg_name,
+  const struct crypto_type *frontend, u32 type, u32 mask,
+  int node)
 {
void *tfm;
int err;
@@ -524,7 +530,7 @@ void *crypto_alloc_tfm(const char *alg_name,
goto err;
}
 
-   tfm = crypto_create_tfm(alg, frontend);
+   tfm = crypto_create_tfm_node(alg, frontend, node);
if (!IS_ERR(tfm))
return tfm;
 
@@ -542,7 +548,7 @@ void *crypto_alloc_tfm(const char *alg_name,
 
return ERR_PTR(err);
 }
-EXPORT_SYMBOL_GPL(crypto_alloc_tfm);
+EXPORT_SYMBOL_GPL(crypto_alloc_tfm_node);
 
 /*
  * crypto_destroy_tfm - Free crypto transform
diff --git a/crypto/internal.h b/crypto/internal.h
index ff06a3bd1ca1..1b92a5a61852 100644
--- a/crypto/internal.h
+++ b/crypto/internal.h
@@ -68,13 +68,28 @@ void crypto_remove_final(struct list_head *list);
 void crypto_shoot_alg(struct crypto_alg *alg);
 struct crypto_tfm *__crypto_alloc_tfm(struct crypto_alg *alg, u32 type,
  u32 mask);
-void *crypto_create_tfm(struct crypto_alg *alg,
-   const struct 

[PATCH v2 0/3] crypto: allow users to specify acomp hardware from a desired NUMA node

2020-06-22 Thread Barry Song
For a typical Linux server, probably there are several hardware modules.
For example, numa node0 has a compressor, numa node2 has a same module.
Some drivers are automatically using the module near the CPU calling
acomp_alloc.
But it isn't necessarily correct. Just like memory allocation API like
kmalloc and kmalloc_node. Similar optimization may be done for crypto.

-v2:
  * fix kern-doc and some codingstyle issues according to Jonathan's comment
  * patch 3/3 is rebased againest "[PATCH] mm/zswap: careful error path
implementation in comp_prepare"[1]

[1] https://lkml.org/lkml/2020/6/22/347

Barry Song (3):
  crypto: permit users to specify numa node of acomp hardware
  crypto: hisilicon/zip - permit users to specify NUMA node
  mm/zswap: allocate acomp on the numa node committing acomp_req

 crypto/acompress.c|  8 
 crypto/api.c  | 22 ++
 crypto/internal.h | 23 +++
 drivers/crypto/hisilicon/zip/zip.h|  2 +-
 drivers/crypto/hisilicon/zip/zip_crypto.c |  6 +++---
 drivers/crypto/hisilicon/zip/zip_main.c   |  5 +++--
 include/crypto/acompress.h| 18 ++
 include/linux/crypto.h|  2 ++
 mm/zswap.c|  2 +-
 9 files changed, 69 insertions(+), 19 deletions(-)

-- 
2.27.0




[PATCH v2 3/3] mm/zswap: allocate acomp on the numa node committing acomp_req

2020-06-22 Thread Barry Song
zswap is allocating acomp on one different cpu with those cpus which will
eventually committing acomp_req. this patch specifies the numa node to
help compression/decompression done by local (de)compressors hardware.

Cc: Seth Jennings 
Cc: Dan Streetman 
Cc: Vitaly Wool 
Cc: Herbert Xu 
Cc: David S. Miller" 
Signed-off-by: Barry Song 
---
 -v2: patch is rebased againest "[PATCH] mm/zswap: careful error path
 implementation in comp_prepare" [1]
 [1] https://lkml.org/lkml/2020/6/22/347

 mm/zswap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/zswap.c b/mm/zswap.c
index c0a85ef46610..98db09524af6 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -438,7 +438,7 @@ static int zswap_cpu_comp_prepare(unsigned int cpu, struct 
hlist_node *node)
pr_err("Could not allocate acomp_ctx\n");
return -ENOMEM;
}
-   acomp = crypto_alloc_acomp(pool->tfm_name, 0, 0);
+   acomp = crypto_alloc_acomp_node(pool->tfm_name, 0, 0, cpu_to_node(cpu));
if (IS_ERR(acomp)) {
pr_err("could not alloc crypto acomp %s : %ld\n",
pool->tfm_name, PTR_ERR(acomp));
-- 
2.27.0




Re: [PATCH v2] GUE: Fix a typo

2020-06-22 Thread David Miller
From: Aiden Leong 
Date: Mon, 22 Jun 2020 20:04:58 -0700

> Fix a typo in gue.h
> 
> Signed-off-by: Aiden Leong 

Applied, thank you.


[PATCH 2/4] interconnect: qcom: Only wait for completion in AMC/WAKE by default

2020-06-22 Thread Mike Tipton
Change the default TCS wait behavior to only wait for completion in AMC
and WAKE. Waiting isn't necessary in the SLEEP TCS, since votes are only
being removed in this case. Resources can be safely disabled
asynchronously in parallel with the rest of the power collapse sequence.
This reduces the sleep entry latency.

Signed-off-by: Mike Tipton 
---
 drivers/interconnect/qcom/bcm-voter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/interconnect/qcom/bcm-voter.c 
b/drivers/interconnect/qcom/bcm-voter.c
index e9f66f5c8a91..bb83ce7554b7 100644
--- a/drivers/interconnect/qcom/bcm-voter.c
+++ b/drivers/interconnect/qcom/bcm-voter.c
@@ -345,7 +345,7 @@ static int qcom_icc_bcm_voter_probe(struct platform_device 
*pdev)
voter->np = np;
 
if (of_property_read_u32(np, "qcom,tcs-wait", >tcs_wait))
-   voter->tcs_wait = QCOM_ICC_TAG_ALWAYS;
+   voter->tcs_wait = QCOM_ICC_TAG_ACTIVE_ONLY;
 
mutex_init(>lock);
INIT_LIST_HEAD(>commit_list);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH 4/4] interconnect: qcom: Fix small BW votes being truncated to zero

2020-06-22 Thread Mike Tipton
Small BW votes that translate to less than a single BCM unit are
currently truncated to zero. Ensure that non-zero BW requests always
result in at least a vote of 1 to BCM.

Fixes: 976daac4a1c5 ("interconnect: qcom: Consolidate interconnect RPMh 
support")
Signed-off-by: Mike Tipton 
---
 drivers/interconnect/qcom/bcm-voter.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/interconnect/qcom/bcm-voter.c 
b/drivers/interconnect/qcom/bcm-voter.c
index a68c858ca6b7..9e2612fe7fad 100644
--- a/drivers/interconnect/qcom/bcm-voter.c
+++ b/drivers/interconnect/qcom/bcm-voter.c
@@ -54,8 +54,20 @@ static int cmp_vcd(void *priv, struct list_head *a, struct 
list_head *b)
return 1;
 }
 
+static u64 bcm_div(u64 num, u64 base)
+{
+   /* Ensure that small votes aren't lost. */
+   if (num && num < base)
+   return 1;
+
+   do_div(num, base);
+
+   return num;
+}
+
 static void bcm_aggregate(struct qcom_icc_bcm *bcm)
 {
+   struct qcom_icc_node *node;
size_t i, bucket;
u64 agg_avg[QCOM_ICC_NUM_BUCKETS] = {0};
u64 agg_peak[QCOM_ICC_NUM_BUCKETS] = {0};
@@ -63,22 +75,21 @@ static void bcm_aggregate(struct qcom_icc_bcm *bcm)
 
for (bucket = 0; bucket < QCOM_ICC_NUM_BUCKETS; bucket++) {
for (i = 0; i < bcm->num_nodes; i++) {
-   temp = bcm->nodes[i]->sum_avg[bucket] * 
bcm->aux_data.width;
-   do_div(temp, bcm->nodes[i]->buswidth * 
bcm->nodes[i]->channels);
+   node = bcm->nodes[i];
+   temp = bcm_div(node->sum_avg[bucket] * 
bcm->aux_data.width,
+  node->buswidth * node->channels);
agg_avg[bucket] = max(agg_avg[bucket], temp);
 
-   temp = bcm->nodes[i]->max_peak[bucket] * 
bcm->aux_data.width;
-   do_div(temp, bcm->nodes[i]->buswidth);
+   temp = bcm_div(node->max_peak[bucket] * 
bcm->aux_data.width,
+  node->buswidth);
agg_peak[bucket] = max(agg_peak[bucket], temp);
}
 
temp = agg_avg[bucket] * bcm->vote_scale;
-   do_div(temp, bcm->aux_data.unit);
-   bcm->vote_x[bucket] = temp;
+   bcm->vote_x[bucket] = bcm_div(temp, bcm->aux_data.unit);
 
temp = agg_peak[bucket] * bcm->vote_scale;
-   do_div(temp, bcm->aux_data.unit);
-   bcm->vote_y[bucket] = temp;
+   bcm->vote_y[bucket] = bcm_div(temp, bcm->aux_data.unit);
}
 
if (bcm->keepalive && bcm->vote_x[QCOM_ICC_BUCKET_AMC] == 0 &&
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



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

2020-06-22 Thread Vinod Koul
On 22-06-20, 15:13, Charles Keepax wrote:
> On Mon, Jun 22, 2020 at 08:28:48AM -0500, Pierre-Louis Bossart wrote:
> > On 6/22/20 1:58 AM, Vinod Koul wrote:
  +--+
> > a) can you clarify if we can go from running to free directly? is
> > this really a legit transition? There's already the option of doing
> > a stop and a a drain.
> > 
> 
> This is allowed in the current code, the kernel sends the stop
> internally in this case, so it kinda does go through the setup
> state just not from the users view point. I am not sure I have a
> good handle on if that makes sense or not.

The idea was to stop first so that we can handle dmas which might be
setup (like running/paused/prepared). So we should stop first and then
free up. But i think it was an overkill... :)

> > c) no way to stop a paused stream?
> 
> Currently the code does allow this and it certainly makes sense so
> should probably be added.

Yes will add

-- 
~Vinod


Re: [PATCH RESEND] net/cisco: Fix a sleep-in-atomic-context bug in enic_init_affinity_hint()

2020-06-22 Thread David Miller


Networking changes must be submitted with net...@vger.kernel.org

Thank you.


[PATCH 3/4] interconnect: qcom: Add support for per-BCM scaling factors

2020-06-22 Thread Mike Tipton
Currently, bcm-voter always assumes requests are made in KBps and that
BCM HW always wants them in Bps, so it always scales the requests by
1000. However, certain use cases and BCMs may use different units.
Thus, add support for BCM-specific scaling factors.

Signed-off-by: Mike Tipton 
---
 drivers/interconnect/qcom/bcm-voter.c | 4 ++--
 drivers/interconnect/qcom/icc-rpmh.c  | 3 +++
 drivers/interconnect/qcom/icc-rpmh.h  | 2 ++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/interconnect/qcom/bcm-voter.c 
b/drivers/interconnect/qcom/bcm-voter.c
index bb83ce7554b7..a68c858ca6b7 100644
--- a/drivers/interconnect/qcom/bcm-voter.c
+++ b/drivers/interconnect/qcom/bcm-voter.c
@@ -72,11 +72,11 @@ static void bcm_aggregate(struct qcom_icc_bcm *bcm)
agg_peak[bucket] = max(agg_peak[bucket], temp);
}
 
-   temp = agg_avg[bucket] * 1000ULL;
+   temp = agg_avg[bucket] * bcm->vote_scale;
do_div(temp, bcm->aux_data.unit);
bcm->vote_x[bucket] = temp;
 
-   temp = agg_peak[bucket] * 1000ULL;
+   temp = agg_peak[bucket] * bcm->vote_scale;
do_div(temp, bcm->aux_data.unit);
bcm->vote_y[bucket] = temp;
}
diff --git a/drivers/interconnect/qcom/icc-rpmh.c 
b/drivers/interconnect/qcom/icc-rpmh.c
index 3ac5182c9ab2..008846c17bec 100644
--- a/drivers/interconnect/qcom/icc-rpmh.c
+++ b/drivers/interconnect/qcom/icc-rpmh.c
@@ -136,6 +136,9 @@ int qcom_icc_bcm_init(struct qcom_icc_bcm *bcm, struct 
device *dev)
INIT_LIST_HEAD(>list);
INIT_LIST_HEAD(>ws_list);
 
+   if (!bcm->vote_scale)
+   bcm->vote_scale = 1000;
+
/* Link Qnodes to their respective BCMs */
for (i = 0; i < bcm->num_nodes; i++) {
qn = bcm->nodes[i];
diff --git a/drivers/interconnect/qcom/icc-rpmh.h 
b/drivers/interconnect/qcom/icc-rpmh.h
index 903d25e61984..200e98be5926 100644
--- a/drivers/interconnect/qcom/icc-rpmh.h
+++ b/drivers/interconnect/qcom/icc-rpmh.h
@@ -94,6 +94,7 @@ struct qcom_icc_node {
  * @addr: address offsets used when voting to RPMH
  * @vote_x: aggregated threshold values, represents sum_bw when @type is bw bcm
  * @vote_y: aggregated threshold values, represents peak_bw when @type is bw 
bcm
+ * @vote_scale: scaling factor for vote_x and vote_y
  * @dirty: flag used to indicate whether the bcm needs to be committed
  * @keepalive: flag used to indicate whether a keepalive is required
  * @aux_data: auxiliary data used when calculating threshold values and
@@ -109,6 +110,7 @@ struct qcom_icc_bcm {
u32 addr;
u64 vote_x[QCOM_ICC_NUM_BUCKETS];
u64 vote_y[QCOM_ICC_NUM_BUCKETS];
+   u64 vote_scale;
bool dirty;
bool keepalive;
struct bcm_db aux_data;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH 0/4] interconnect: qcom: Misc bcm-voter changes and fixes

2020-06-22 Thread Mike Tipton
These changes are mostly unrelated, but there are some dependencies
between them.

Mike Tipton (4):
  interconnect: qcom: Support bcm-voter-specific TCS wait behavior
  interconnect: qcom: Only wait for completion in AMC/WAKE by default
  interconnect: qcom: Add support for per-BCM scaling factors
  interconnect: qcom: Fix small BW votes being truncated to zero

 drivers/interconnect/qcom/bcm-voter.c | 63 ++-
 drivers/interconnect/qcom/icc-rpmh.c  |  3 ++
 drivers/interconnect/qcom/icc-rpmh.h  |  2 +
 3 files changed, 47 insertions(+), 21 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH 1/4] interconnect: qcom: Support bcm-voter-specific TCS wait behavior

2020-06-22 Thread Mike Tipton
Currently, all bcm-voters set tcs_cmd::wait=true for the last VCD
command in each TCS (AMC, WAKE, and SLEEP). However, some bcm-voters
don't need the completion and instead need to optimize for latency. For
instance, disabling wait-for-completion in the WAKE set can decrease
resume latency and allow for certain operations to occur in parallel
with the WAKE TCS triggering. This is only safe in very specific
situations. Keep the default behavior of always waiting, but allow it to
be overridden in devicetree.

Signed-off-by: Mike Tipton 
---
 drivers/interconnect/qcom/bcm-voter.c | 32 ++-
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/drivers/interconnect/qcom/bcm-voter.c 
b/drivers/interconnect/qcom/bcm-voter.c
index 2a11a63e7217..e9f66f5c8a91 100644
--- a/drivers/interconnect/qcom/bcm-voter.c
+++ b/drivers/interconnect/qcom/bcm-voter.c
@@ -27,6 +27,7 @@ static DEFINE_MUTEX(bcm_voter_lock);
  * @commit_list: list containing bcms to be committed to hardware
  * @ws_list: list containing bcms that have different wake/sleep votes
  * @voter_node: list of bcm voters
+ * @tcs_wait: mask for which buckets require TCS completion
  */
 struct bcm_voter {
struct device *dev;
@@ -35,6 +36,7 @@ struct bcm_voter {
struct list_head commit_list;
struct list_head ws_list;
struct list_head voter_node;
+   u32 tcs_wait;
 };
 
 static int cmp_vcd(void *priv, struct list_head *a, struct list_head *b)
@@ -89,7 +91,7 @@ static void bcm_aggregate(struct qcom_icc_bcm *bcm)
 }
 
 static inline void tcs_cmd_gen(struct tcs_cmd *cmd, u64 vote_x, u64 vote_y,
-  u32 addr, bool commit)
+  u32 addr, bool commit, bool wait)
 {
bool valid = true;
 
@@ -114,15 +116,16 @@ static inline void tcs_cmd_gen(struct tcs_cmd *cmd, u64 
vote_x, u64 vote_y,
 * Set the wait for completion flag on command that need to be completed
 * before the next command.
 */
-   cmd->wait = commit;
+   cmd->wait = wait;
 }
 
-static void tcs_list_gen(struct list_head *bcm_list, int bucket,
-struct tcs_cmd tcs_list[MAX_BCMS],
+static void tcs_list_gen(struct bcm_voter *voter, int bucket,
+struct tcs_cmd tcs_list[MAX_VCD],
 int n[MAX_VCD + 1])
 {
+   struct list_head *bcm_list = >commit_list;
struct qcom_icc_bcm *bcm;
-   bool commit;
+   bool commit, wait;
size_t idx = 0, batch = 0, cur_vcd_size = 0;
 
memset(n, 0, sizeof(int) * (MAX_VCD + 1));
@@ -135,8 +138,11 @@ static void tcs_list_gen(struct list_head *bcm_list, int 
bucket,
commit = true;
cur_vcd_size = 0;
}
+
+   wait = commit && (voter->tcs_wait & BIT(bucket));
+
tcs_cmd_gen(_list[idx], bcm->vote_x[bucket],
-   bcm->vote_y[bucket], bcm->addr, commit);
+   bcm->vote_y[bucket], bcm->addr, commit, wait);
idx++;
n[batch]++;
/*
@@ -261,8 +267,7 @@ int qcom_icc_bcm_voter_commit(struct bcm_voter *voter)
 * Construct the command list based on a pre ordered list of BCMs
 * based on VCD.
 */
-   tcs_list_gen(>commit_list, QCOM_ICC_BUCKET_AMC, cmds, 
commit_idx);
-
+   tcs_list_gen(voter, QCOM_ICC_BUCKET_AMC, cmds, commit_idx);
if (!commit_idx[0])
goto out;
 
@@ -302,7 +307,7 @@ int qcom_icc_bcm_voter_commit(struct bcm_voter *voter)
 
list_sort(NULL, >commit_list, cmp_vcd);
 
-   tcs_list_gen(>commit_list, QCOM_ICC_BUCKET_WAKE, cmds, 
commit_idx);
+   tcs_list_gen(voter, QCOM_ICC_BUCKET_WAKE, cmds, commit_idx);
 
ret = rpmh_write_batch(voter->dev, RPMH_WAKE_ONLY_STATE, cmds, 
commit_idx);
if (ret) {
@@ -310,7 +315,7 @@ int qcom_icc_bcm_voter_commit(struct bcm_voter *voter)
goto out;
}
 
-   tcs_list_gen(>commit_list, QCOM_ICC_BUCKET_SLEEP, cmds, 
commit_idx);
+   tcs_list_gen(voter, QCOM_ICC_BUCKET_SLEEP, cmds, commit_idx);
 
ret = rpmh_write_batch(voter->dev, RPMH_SLEEP_STATE, cmds, commit_idx);
if (ret) {
@@ -329,6 +334,7 @@ EXPORT_SYMBOL_GPL(qcom_icc_bcm_voter_commit);
 
 static int qcom_icc_bcm_voter_probe(struct platform_device *pdev)
 {
+   struct device_node *np = pdev->dev.of_node;
struct bcm_voter *voter;
 
voter = devm_kzalloc(>dev, sizeof(*voter), GFP_KERNEL);
@@ -336,7 +342,11 @@ static int qcom_icc_bcm_voter_probe(struct platform_device 
*pdev)
return -ENOMEM;
 
voter->dev = >dev;
-   voter->np = pdev->dev.of_node;
+   voter->np = np;
+
+   if (of_property_read_u32(np, "qcom,tcs-wait", >tcs_wait))
+   voter->tcs_wait = QCOM_ICC_TAG_ALWAYS;
+
mutex_init(>lock);
INIT_LIST_HEAD(>commit_list);
INIT_LIST_HEAD(>ws_list);
-- 
The 

[PATCH] irqchip/riscv-plic: Fix typo in irq-riscv-intc.c

2020-06-22 Thread Greentime Hu
This patch fixes a spelling typo in irq-riscv-intc.c

Signed-off-by: Greentime Hu 
---
 drivers/irqchip/irq-riscv-intc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
index a6f97fa6ff69..8017f6d32d52 100644
--- a/drivers/irqchip/irq-riscv-intc.c
+++ b/drivers/irqchip/irq-riscv-intc.c
@@ -99,7 +99,7 @@ static int __init riscv_intc_init(struct device_node *node,
 
hartid = riscv_of_parent_hartid(node);
if (hartid < 0) {
-   pr_warn("unable to fine hart id for %pOF\n", node);
+   pr_warn("unable to find hart id for %pOF\n", node);
return 0;
}
 
-- 
2.27.0



Re: [PATCH net v2] mptcp: drop sndr_key in mptcp_syn_options

2020-06-22 Thread David Miller
From: Geliang Tang 
Date: Mon, 22 Jun 2020 19:45:58 +0800

> In RFC 8684, we don't need to send sndr_key in SYN package anymore, so drop
> it.
> 
> Fixes: cc7972ea1932 ("mptcp: parse and emit MP_CAPABLE option according to v1 
> spec")
> Signed-off-by: Geliang Tang 

Applied and queued up for v5.6+ -stable, thanks.


[PATCH 2/2] interconnect: qcom: Don't redefine bucket/tag macros

2020-06-22 Thread Mike Tipton
Replace internal bucket/tag macros with those defined in dt-bindings.

Signed-off-by: Mike Tipton 
---
 drivers/interconnect/qcom/icc-rpmh.h | 18 ++
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/drivers/interconnect/qcom/icc-rpmh.h 
b/drivers/interconnect/qcom/icc-rpmh.h
index 903d25e61984..cb736b745e1a 100644
--- a/drivers/interconnect/qcom/icc-rpmh.h
+++ b/drivers/interconnect/qcom/icc-rpmh.h
@@ -6,6 +6,8 @@
 #ifndef __DRIVERS_INTERCONNECT_QCOM_ICC_RPMH_H__
 #define __DRIVERS_INTERCONNECT_QCOM_ICC_RPMH_H__
 
+#include 
+
 #define to_qcom_provider(_provider) \
container_of(_provider, struct qcom_icc_provider, provider)
 
@@ -44,22 +46,6 @@ struct bcm_db {
 #define MAX_BCM_PER_NODE   3
 #define MAX_VCD10
 
-/*
- * The AMC bucket denotes constraints that are applied to hardware when
- * icc_set_bw() completes, whereas the WAKE and SLEEP constraints are applied
- * when the execution environment transitions between active and low power 
mode.
- */
-#define QCOM_ICC_BUCKET_AMC0
-#define QCOM_ICC_BUCKET_WAKE   1
-#define QCOM_ICC_BUCKET_SLEEP  2
-#define QCOM_ICC_NUM_BUCKETS   3
-#define QCOM_ICC_TAG_AMC   BIT(QCOM_ICC_BUCKET_AMC)
-#define QCOM_ICC_TAG_WAKE  BIT(QCOM_ICC_BUCKET_WAKE)
-#define QCOM_ICC_TAG_SLEEP BIT(QCOM_ICC_BUCKET_SLEEP)
-#define QCOM_ICC_TAG_ACTIVE_ONLY   (QCOM_ICC_TAG_AMC | QCOM_ICC_TAG_WAKE)
-#define QCOM_ICC_TAG_ALWAYS(QCOM_ICC_TAG_AMC | QCOM_ICC_TAG_WAKE |\
-QCOM_ICC_TAG_SLEEP)
-
 /**
  * struct qcom_icc_node - Qualcomm specific interconnect nodes
  * @name: the node name used in debugfs
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH 1/2] dt-bindings: interconnect: Add generic qcom bindings

2020-06-22 Thread Mike Tipton
Add generic qcom interconnect bindings that are common across platforms. In
particular, these include QCOM_ICC_TAG_* macros that clients can use when
calling icc_set_tag().

Signed-off-by: Mike Tipton 
---
 include/dt-bindings/interconnect/qcom,icc.h | 26 +
 1 file changed, 26 insertions(+)
 create mode 100644 include/dt-bindings/interconnect/qcom,icc.h

diff --git a/include/dt-bindings/interconnect/qcom,icc.h 
b/include/dt-bindings/interconnect/qcom,icc.h
new file mode 100644
index ..cd34f36d
--- /dev/null
+++ b/include/dt-bindings/interconnect/qcom,icc.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_ICC_H
+#define __DT_BINDINGS_INTERCONNECT_QCOM_ICC_H
+
+/*
+ * The AMC bucket denotes constraints that are applied to hardware when
+ * icc_set_bw() completes, whereas the WAKE and SLEEP constraints are applied
+ * when the execution environment transitions between active and low power 
mode.
+ */
+#define QCOM_ICC_BUCKET_AMC0
+#define QCOM_ICC_BUCKET_WAKE   1
+#define QCOM_ICC_BUCKET_SLEEP  2
+#define QCOM_ICC_NUM_BUCKETS   3
+
+#define QCOM_ICC_TAG_AMC   (1 << QCOM_ICC_BUCKET_AMC)
+#define QCOM_ICC_TAG_WAKE  (1 << QCOM_ICC_BUCKET_WAKE)
+#define QCOM_ICC_TAG_SLEEP (1 << QCOM_ICC_BUCKET_SLEEP)
+#define QCOM_ICC_TAG_ACTIVE_ONLY   (QCOM_ICC_TAG_AMC | QCOM_ICC_TAG_WAKE)
+#define QCOM_ICC_TAG_ALWAYS(QCOM_ICC_TAG_AMC | QCOM_ICC_TAG_WAKE |\
+QCOM_ICC_TAG_SLEEP)
+
+#endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH 0/2] interconnect: qcom: Add common dt-bindings

2020-06-22 Thread Mike Tipton
Add common dt-bindings to replace internal macros.

Mike Tipton (2):
  dt-bindings: interconnect: Add generic qcom bindings
  interconnect: qcom: Don't redefine bucket/tag macros

 drivers/interconnect/qcom/icc-rpmh.h| 18 ++
 include/dt-bindings/interconnect/qcom,icc.h | 26 +
 2 files changed, 28 insertions(+), 16 deletions(-)
 create mode 100644 include/dt-bindings/interconnect/qcom,icc.h

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



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

2020-06-22 Thread Vinod Koul
On 22-06-20, 08:28, Pierre-Louis Bossart wrote:
> 
> 
> On 6/22/20 1:58 AM, Vinod Koul wrote:
> > 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..6f86db82298b 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_free()   +--+
> > +  +-|  |
> > +  | |   SETUP  |
> > +  |   +>|  
> > |<-+
> > +  |   | compr_drain_notify()+--+   
> >|
> > +  |   |  | 
> >|
> > +  |   |  | 
> >|
> > +  |   |  | compr_write()   
> >|
> > +  |   |  | 
> >|
> > +  |   |  v 
> >|
> > +  |   | +--+   
> >|
> > +  |   | |  |   
> >|
> > +  |   | |  PREPARE |   
> >|
> > +  |   | |  |   
> >|
> > +  |   | +--+   
> >|
> > +  |   |  | 
> >|
> > +  |   |  | 
> >|
> > +  |   |  | compr_start()   
> >|
> > +  |   |  | 
> >|
> > +  |   |  v 
> >|
> > +  | +--++--+  compr_pause()  
> > +--+ |
> > +  | |  |compr_drain()   |  |>| 
> >  | |
> > +  | |  DRAIN   |<---|  RUNNING | |  
> > PAUSE   | |
> > +  | |  ||  |<| 
> >  | |
> > +  | +--++--+  compr_resume() 
> > +--+ |
> > +  |   |   |  | 
> >|
> > +  |   |   |  | 
> >|
> > +  |   |   |  | 
> >|
> > +  |   |   |  |  compr_stop()   
> >|
> > +  |   |   |  
> > ++
> > +  |   |   +--+|
> > +  |   |   |  ||
> > +  +---+-->|  |<---+
> > + compr_free() |   FREE   |  compr_free()
> > +  |  |
> > +  +--+
> > +
> 
> Sorry, this confuses me even more...

Oops

> a) can you clarify if we can go from running to free directly? is this
> really a legit transition? There's already the option of doing a stop and a
> a drain.

As Charles pointed it is legit one, but then from SM we should remove
running->free arrow to clarify. 

[PATCH 18/22] gpiolib: cdev: support setting debounce

2020-06-22 Thread Kent Gibson
Add support for setting debounce on a line via the GPIO uAPI.
Where debounce is not supported by hardware, a software debounce is
provided.

Signed-off-by: Kent Gibson 

---

The implementation of the software debouncer waits for the line to be
stable for the debounce period before determining if a level change,
and a corresponding edge event, has occurred.  This provides maximum
protection against glitches, but also introduces a debounce_period
latency to edge events.

The software debouncer is integrated with the edge detection as it
utilises the line interrupt, and integration is simpler than getting
the two to interwork.  Where software debounce AND edge detection is
required, the debouncer provides both.

Due to the tight integration between the debouncer and edge detection,
and to avoid particular corner cases, it is not allowed to alter the
debounce value if edge detection is enabled.  Shanging the debounce with
edge detection enabled is a very unlikely use case, so it is preferable
to disallow it rather than complicate the code to allow it.
Should the user wish to alter the debounce value in such cases they will
need to release and re-aquire the line.

 drivers/gpio/gpiolib-cdev.c | 212 +++-
 drivers/gpio/gpiolib.h  |   4 +
 2 files changed, 214 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 7ba0929b2741..81c2fc4f0e49 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -394,6 +394,9 @@ static int linehandle_create(struct gpio_device *gdev, void 
__user *ip)
  * for the corresponding line request. Ths is drawn from the @line.
  * @line_seqno: the seqno for the current edge event in the sequence of
  * events for this line.
+ * @sw_debounced: flag indicating if the software debouncer is active
+ * @work: the worker that implements software debouncing
+ * @level: the current debounced physical level of the line
  */
 struct edge_detector {
struct line *line;
@@ -404,7 +407,15 @@ struct edge_detector {
 */
u64 timestamp;
u32 seqno;
+   /*
+* line_seqno is used by either edge_irq_thread or debounce_work_func
+* which are themselves mutually exclusive.
+*/
u32 line_seqno;
+   /* debouncer specific fields */
+   atomic_t sw_debounced;
+   struct delayed_work work;
+   atomic_t level;
 };
 
 /**
@@ -524,6 +535,10 @@ static int edge_detector_start(struct edge_detector *edet)
int ret, irq, irqflags = 0;
struct gpio_desc *desc;
 
+   if (atomic_read(>sw_debounced))
+   /* debouncer is setup and will provide edge detection */
+   return 0;
+
desc = edge_detector_desc(edet);
irq = gpiod_to_irq(desc);
 
@@ -555,23 +570,192 @@ static int edge_detector_start(struct edge_detector 
*edet)
return 0;
 }
 
+/*
+ * returns the current debounced value, or -1 if the debouncer is inactive.
+ */
+static int debounced_value(struct edge_detector *edet)
+{
+   int value;
+
+   if (!atomic_read(>sw_debounced))
+   return -1;
+
+   /*
+* minor race - debouncer may be stopped here, so edge_detector_stop
+* must leave the value unchanged so the following will read the level
+* from when the debouncer was last running.
+*/
+   value = atomic_read(>level);
+
+   if (test_bit(FLAG_ACTIVE_LOW, _detector_desc(edet)->flags))
+   value = !value;
+
+   return value;
+}
+
+static irqreturn_t debounce_irq_handler(int irq, void *p)
+{
+   struct edge_detector *edet = p;
+   struct gpio_desc *desc = edge_detector_desc(edet);
+
+   mod_delayed_work(system_wq,
+>work,
+usecs_to_jiffies(atomic_read(>debounce_period)));
+
+   return IRQ_HANDLED;
+}
+
+static void debounce_work_func(struct work_struct *work)
+{
+   struct gpioline_event le;
+   int ret, level, oldlevel;
+   struct edge_detector *edet =
+   container_of(work, struct edge_detector, work.work);
+   struct gpio_desc *desc = edge_detector_desc(edet);
+   struct line *line;
+
+   level = gpiod_get_raw_value_cansleep(desc);
+   if (level < 0) {
+   pr_debug_ratelimited("debouncer failed to read line value\n");
+   return;
+   }
+
+   oldlevel = atomic_xchg(>level, level);
+   if (oldlevel == level)
+   return;
+
+   /* -- edge detection -- */
+   line = edet->line;
+   if (line->edge_detection == GPIOLINE_EDGE_NONE)
+   return;
+
+   /* switch from physical level to logical - if they differ */
+   if (test_bit(FLAG_ACTIVE_LOW, >flags))
+   level = !level;
+
+   /* ignore edges that are not being monitored */
+   if (((line->edge_detection == GPIOLINE_EDGE_RISING) && (level == 0)) ||
+   ((line->edge_detection == 

[PATCH 22/22] tools: gpio: support monitoring multiple lines

2020-06-22 Thread Kent Gibson
Extend gpio-event-mon to support monitoring multiple lines.
This would require multiple lineevent requests to implement using uAPI V1,
but can be performed with a single line request using uAPI V2.

Signed-off-by: Kent Gibson 

---
 tools/gpio/gpio-event-mon.c | 41 -
 1 file changed, 31 insertions(+), 10 deletions(-)

diff --git a/tools/gpio/gpio-event-mon.c b/tools/gpio/gpio-event-mon.c
index ec90e44389dc..ed1adb8247c6 100644
--- a/tools/gpio/gpio-event-mon.c
+++ b/tools/gpio/gpio-event-mon.c
@@ -26,7 +26,8 @@
 #include "gpio-utils.h"
 
 int monitor_device(const char *device_name,
-  unsigned int line,
+  unsigned int *lines,
+  unsigned int num_lines,
   struct gpioline_config *config,
   unsigned int loops)
 {
@@ -47,7 +48,7 @@ int monitor_device(const char *device_name,
goto exit_free_name;
}
 
-   ret = gpiotools_request_line(device_name, , 1, config,
+   ret = gpiotools_request_line(device_name, lines, num_lines, config,
 "gpio-event-mon");
if (ret < 0)
goto exit_device_close;
@@ -63,9 +64,23 @@ int monitor_device(const char *device_name,
goto exit_line_close;
}
 
-   fprintf(stdout, "Monitoring line %d on %s\n", line, device_name);
-   fprintf(stdout, "Initial line value: %d\n",
-   gpiotools_test_bit(values.bitmap, 0));
+   if (num_lines == 1) {
+   fprintf(stdout, "Monitoring line %d on %s\n", lines[0], 
device_name);
+   fprintf(stdout, "Initial line value: %d\n",
+   gpiotools_test_bit(values.bitmap, 0));
+   } else {
+   fprintf(stdout, "Monitoring lines %d", lines[0]);
+   for (i = 1; i < num_lines - 1; i++)
+   fprintf(stdout, ", %d", lines[i]);
+   fprintf(stdout, " and %d on %s\n", lines[i], device_name);
+   fprintf(stdout, "Initial line values: %d",
+   gpiotools_test_bit(values.bitmap, 0));
+   for (i = 1; i < num_lines - 1; i++)
+   fprintf(stdout, ", %d",
+   gpiotools_test_bit(values.bitmap, i));
+   fprintf(stdout, " and %d\n",
+   gpiotools_test_bit(values.bitmap, i));
+   }
 
while (1) {
struct gpioline_event event;
@@ -124,7 +139,7 @@ void print_usage(void)
fprintf(stderr, "Usage: gpio-event-mon [options]...\n"
"Listen to events on GPIO lines, 0->1 1->0\n"
"  -n   Listen on GPIOs on a named device (must be 
stated)\n"
-   "  -o  Offset to monitor\n"
+   "  -o  Offset of line to monitor (may be repeated)\n"
"  -d Set line as open drain\n"
"  -s Set line as open source\n"
"  -r Listen for rising edges\n"
@@ -141,7 +156,8 @@ void print_usage(void)
 int main(int argc, char **argv)
 {
const char *device_name = NULL;
-   unsigned int line = -1;
+   unsigned int lines[GPIOLINES_MAX];
+   unsigned int num_lines = 0;
unsigned int loops = 0;
struct gpioline_config config;
int c;
@@ -158,7 +174,12 @@ int main(int argc, char **argv)
device_name = optarg;
break;
case 'o':
-   line = strtoul(optarg, NULL, 10);
+   if (num_lines >= GPIOLINES_MAX) {
+   print_usage();
+   return -1;
+   }
+   lines[num_lines] = strtoul(optarg, NULL, 10);
+   num_lines++;
break;
case 'b':
config.flags |= GPIOLINE_FLAG_V2_DEBOUNCE;
@@ -184,7 +205,7 @@ int main(int argc, char **argv)
}
}
 
-   if (!device_name || line == -1) {
+   if (!device_name || num_lines == 0) {
print_usage();
return -1;
}
@@ -193,5 +214,5 @@ int main(int argc, char **argv)
   "falling edges\n");
config.edge_detection = GPIOLINE_EDGE_BOTH;
}
-   return monitor_device(device_name, line, , loops);
+   return monitor_device(device_name, lines, num_lines, , loops);
 }
-- 
2.27.0



[PATCH 21/22] tools: gpio: add debounce support to gpio-event-mon

2020-06-22 Thread Kent Gibson
Add support for debouncing monitored lines to gpio-event-mon.

Signed-off-by: Kent Gibson 

---
 tools/gpio/gpio-event-mon.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/gpio/gpio-event-mon.c b/tools/gpio/gpio-event-mon.c
index d8d692f67b9e..ec90e44389dc 100644
--- a/tools/gpio/gpio-event-mon.c
+++ b/tools/gpio/gpio-event-mon.c
@@ -129,11 +129,12 @@ void print_usage(void)
"  -s Set line as open source\n"
"  -r Listen for rising edges\n"
"  -f Listen for falling edges\n"
+   "  -b  Debounce the line with period n microseconds\n"
" [-c ]Do  loops (optional, infinite loop if not 
stated)\n"
"  -? This helptext\n"
"\n"
"Example:\n"
-   "gpio-event-mon -n gpiochip0 -o 4 -r -f\n"
+   "gpio-event-mon -n gpiochip0 -o 4 -r -f -b 1\n"
);
 }
 
@@ -148,7 +149,7 @@ int main(int argc, char **argv)
memset(, 0, sizeof(config));
config.flags = GPIOLINE_FLAG_V2_DIRECTION | 
GPIOLINE_FLAG_V2_EDGE_DETECTION;
config.direction = GPIOLINE_DIRECTION_INPUT;
-   while ((c = getopt(argc, argv, "c:n:o:dsrf?")) != -1) {
+   while ((c = getopt(argc, argv, "c:n:o:b:dsrf?")) != -1) {
switch (c) {
case 'c':
loops = strtoul(optarg, NULL, 10);
@@ -159,6 +160,10 @@ int main(int argc, char **argv)
case 'o':
line = strtoul(optarg, NULL, 10);
break;
+   case 'b':
+   config.flags |= GPIOLINE_FLAG_V2_DEBOUNCE;
+   config.debounce_period = strtoul(optarg, NULL, 10);
+   break;
case 'd':
config.flags |= GPIOLINE_FLAG_V2_DRIVE;
config.drive = GPIOLINE_DRIVE_OPEN_DRAIN;
-- 
2.27.0



[PATCH 20/22] tools: gpio: switch tools to V2 uAPI

2020-06-22 Thread Kent Gibson
Update all the GPIO tools to use uAPI V2 instead of uAPI V1.
The tools command lines and behaviour remain unchanged, although lsgpio
now reports additional information not available through V1, specifically
the edge detection and debounce configuration.

Signed-off-by: Kent Gibson 

---
 tools/gpio/gpio-event-mon.c |  91 ++---
 tools/gpio/gpio-hammer.c|  28 +
 tools/gpio/gpio-utils.c | 107 ++
 tools/gpio/gpio-utils.h |  48 +---
 tools/gpio/gpio-watch.c |  10 ++--
 tools/gpio/lsgpio.c | 112 +---
 6 files changed, 217 insertions(+), 179 deletions(-)

diff --git a/tools/gpio/gpio-event-mon.c b/tools/gpio/gpio-event-mon.c
index 30ed0e06f52a..d8d692f67b9e 100644
--- a/tools/gpio/gpio-event-mon.c
+++ b/tools/gpio/gpio-event-mon.c
@@ -23,17 +23,16 @@
 #include 
 #include 
 #include 
+#include "gpio-utils.h"
 
 int monitor_device(const char *device_name,
   unsigned int line,
-  uint32_t handleflags,
-  uint32_t eventflags,
+  struct gpioline_config *config,
   unsigned int loops)
 {
-   struct gpioevent_request req;
-   struct gpiohandle_data data;
+   struct gpioline_values values;
char *chrdev_name;
-   int fd;
+   int cfd, lfd;
int ret;
int i = 0;
 
@@ -41,44 +40,37 @@ int monitor_device(const char *device_name,
if (ret < 0)
return -ENOMEM;
 
-   fd = open(chrdev_name, 0);
-   if (fd == -1) {
+   cfd = open(chrdev_name, 0);
+   if (cfd == -1) {
ret = -errno;
fprintf(stderr, "Failed to open %s\n", chrdev_name);
-   goto exit_close_error;
+   goto exit_free_name;
}
 
-   req.lineoffset = line;
-   req.handleflags = handleflags;
-   req.eventflags = eventflags;
-   strcpy(req.consumer_label, "gpio-event-mon");
-
-   ret = ioctl(fd, GPIO_GET_LINEEVENT_IOCTL, );
-   if (ret == -1) {
-   ret = -errno;
-   fprintf(stderr, "Failed to issue GET EVENT "
-   "IOCTL (%d)\n",
-   ret);
-   goto exit_close_error;
-   }
+   ret = gpiotools_request_line(device_name, , 1, config,
+"gpio-event-mon");
+   if (ret < 0)
+   goto exit_device_close;
+   else
+   lfd = ret;
 
/* Read initial states */
-   ret = ioctl(req.fd, GPIOHANDLE_GET_LINE_VALUES_IOCTL, );
-   if (ret == -1) {
-   ret = -errno;
-   fprintf(stderr, "Failed to issue GPIOHANDLE GET LINE "
-   "VALUES IOCTL (%d)\n",
+   ret = gpiotools_get_values(lfd, );
+   if (ret < 0) {
+   fprintf(stderr,
+   "Failed to issue GPIO LINE GET VALUES IOCTL (%d)\n",
ret);
-   goto exit_close_error;
+   goto exit_line_close;
}
 
fprintf(stdout, "Monitoring line %d on %s\n", line, device_name);
-   fprintf(stdout, "Initial line value: %d\n", data.values[0]);
+   fprintf(stdout, "Initial line value: %d\n",
+   gpiotools_test_bit(values.bitmap, 0));
 
while (1) {
-   struct gpioevent_data event;
+   struct gpioline_event event;
 
-   ret = read(req.fd, , sizeof(event));
+   ret = read(lfd, , sizeof(event));
if (ret == -1) {
if (errno == -EAGAIN) {
fprintf(stderr, "nothing available\n");
@@ -96,12 +88,14 @@ int monitor_device(const char *device_name,
ret = -EIO;
break;
}
-   fprintf(stdout, "GPIO EVENT %llu: ", event.timestamp);
+   fprintf(stdout, "GPIO EVENT at %llu on line %d (%d|%d) ",
+   event.timestamp, event.offset, event.line_seqno,
+   event.seqno);
switch (event.id) {
-   case GPIOEVENT_EVENT_RISING_EDGE:
+   case GPIOLINE_EVENT_RISING_EDGE:
fprintf(stdout, "rising edge");
break;
-   case GPIOEVENT_EVENT_FALLING_EDGE:
+   case GPIOLINE_EVENT_FALLING_EDGE:
fprintf(stdout, "falling edge");
break;
default:
@@ -114,9 +108,13 @@ int monitor_device(const char *device_name,
break;
}
 
-exit_close_error:
-   if (close(fd) == -1)
+exit_line_close:
+   if (close(lfd) == -1)
+   perror("Failed to close line file");
+exit_device_close:
+   if (close(cfd) == -1)
perror("Failed to close GPIO character device file");
+exit_free_name:
free(chrdev_name);
return ret;
 }
@@ 

[PATCH 15/22] gpiolib: add build option for CDEV V1 ABI

2020-06-22 Thread Kent Gibson
Add a build option to allow the removal of the CDEV v1 ABI.

Suggested-by: Bartosz Golaszewski 
Signed-off-by: Kent Gibson 

---

This patch is before the V2 implementation, and is non-functional until
that patch, as some parts of that patch would be written slightly
differently if removing V1 was not considered.
Adding this patch after that would necessitate revisiting the V2 changes,
so this ordering results in two simpler patches.

 drivers/gpio/Kconfig | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index affc1524bc2c..b966a7dc1c9a 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -81,6 +81,18 @@ config GPIO_CDEV
 
  If unsure, say Y.
 
+config GPIO_CDEV_V1
+   bool "Support GPIO ABI Version 1"
+   default y
+   depends on GPIO_CDEV
+   help
+ Say Y here to support version 1 of the GPIO CDEV ABI.
+
+ This ABI version is deprecated and will be removed in the future.
+ Please use the latest ABI for new developments.
+
+ If unsure, say Y.
+
 config GPIO_GENERIC
depends on HAS_IOMEM # Only for IOMEM drivers
tristate
-- 
2.27.0



[PATCH 19/22] gpio: uapi: document uAPI V1 as deprecated

2020-06-22 Thread Kent Gibson
Update uAPI documentation to deprecate V1 structs and ioctls.

Signed-off-by: Kent Gibson 

---
 include/uapi/linux/gpio.h | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/include/uapi/linux/gpio.h b/include/uapi/linux/gpio.h
index e4ed6f79e332..752d63f56b0d 100644
--- a/include/uapi/linux/gpio.h
+++ b/include/uapi/linux/gpio.h
@@ -238,6 +238,9 @@ struct gpioline_event {
 
 /*
  *  ABI V1
+ *
+ * This version of the ABI is deprecated and will be removed in the future.
+ * Use the latest version if the ABI, defined above, instead.
  */
 
 /* Informational flags */
@@ -261,6 +264,9 @@ struct gpioline_event {
  * @consumer: a functional name for the consumer of this GPIO line as set by
  * whatever is using it, will be empty if there is no current user but may
  * also be empty if the consumer doesn't set this up
+ *
+ * This struct part of ABI V1 and is deprecated.
+ * Use struct gpioline_info_v2 instead.
  */
 struct gpioline_info {
__u32 line_offset;
@@ -292,6 +298,9 @@ enum {
  * guarantee there are no implicit holes between it and subsequent members.
  * The 20-byte padding at the end makes sure we don't add any implicit padding
  * at the end of the structure on 64-bit architectures.
+ *
+ * This struct part of ABI V1 and is deprecated.
+ * Use struct gpioline_info_changed_v2 instead.
  */
 struct gpioline_info_changed {
struct gpioline_info info;
@@ -331,6 +340,9 @@ struct gpioline_info_changed {
  * @fd: if successful this field will contain a valid anonymous file handle
  * after a GPIO_GET_LINEHANDLE_IOCTL operation, zero or negative value
  * means error
+ *
+ * This struct part of ABI V1 and is deprecated.
+ * Use struct gpioline_request instead.
  */
 struct gpiohandle_request {
__u32 lineoffsets[GPIOHANDLES_MAX];
@@ -350,6 +362,9 @@ struct gpiohandle_request {
  * this specifies the default output value, should be 0 (low) or
  * 1 (high), anything else than 0 or 1 will be interpreted as 1 (high)
  * @padding: reserved for future use and should be zero filled
+ *
+ * This struct part of ABI V1 and is deprecated.
+ * Use struct gpioline_config instead.
  */
 struct gpiohandle_config {
__u32 flags;
@@ -362,6 +377,9 @@ struct gpiohandle_config {
  * @values: when getting the state of lines this contains the current
  * state of a line, when setting the state of lines these should contain
  * the desired target state
+ *
+ * This struct part of ABI V1 and is deprecated.
+ * Use struct gpioline_values instead.
  */
 struct gpiohandle_data {
__u8 values[GPIOHANDLES_MAX];
@@ -385,6 +403,9 @@ struct gpiohandle_data {
  * @fd: if successful this field will contain a valid anonymous file handle
  * after a GPIO_GET_LINEEVENT_IOCTL operation, zero or negative value
  * means error
+ *
+ * This struct part of ABI V1 and is deprecated.
+ * Use struct gpioline_request instead.
  */
 struct gpioevent_request {
__u32 lineoffset;
@@ -404,6 +425,9 @@ struct gpioevent_request {
  * struct gpioevent_data - The actual event being pushed to userspace
  * @timestamp: best estimate of time of event occurrence, in nanoseconds
  * @id: event identifier
+ *
+ * This struct part of ABI V1 and is deprecated.
+ * Use struct gpioline_event instead.
  */
 struct gpioevent_data {
__u64 timestamp;
@@ -428,6 +452,8 @@ struct gpioevent_data {
 
 /*
  * V1 ioctl()s
+ *
+ * These ioctl()s are deprecated.  Use the V2 equivalent instead.
  */
 #define GPIO_GET_LINEINFO_IOCTL _IOWR(0xB4, 0x02, struct gpioline_info)
 #define GPIO_GET_LINEHANDLE_IOCTL _IOWR(0xB4, 0x03, struct gpiohandle_request)
-- 
2.27.0



[RFC PATCH v3 3/5] scsi: ufs: Introduce HPB module

2020-06-22 Thread Daejun Park
This is a patch for the HPB module.
The HPB module queries UFS for device information during initialization.
We added the export symbol to two functions in ufshcd.c to initialize
the HPB module.

The HPB module can be loaded or built-in as needed.
The mininum size of the memory pool used in the HPB module is implemented
as a module parameter, so that it can be configurable by the user.

To gurantee a minimum memory pool size of 4MB:
$ insmod ufshpb.ko ufshpb_host_map_kbytes=4096

Signed-off-by: Daejun Park 
---
 drivers/scsi/ufs/Kconfig  |   9 +
 drivers/scsi/ufs/Makefile |   1 +
 drivers/scsi/ufs/ufshcd.c |   2 +
 drivers/scsi/ufs/ufshpb.c | 777 ++
 drivers/scsi/ufs/ufshpb.h | 162 
 5 files changed, 951 insertions(+)
 create mode 100644 drivers/scsi/ufs/ufshpb.c
 create mode 100644 drivers/scsi/ufs/ufshpb.h

diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 8cd90262784d..588f75fc8c0d 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -172,3 +172,12 @@ config SCSI_UFS_EXYNOS
 
  Select this if you have UFS host controller on EXYNOS chipset.
  If unsure, say N.
+
+config UFSHPB
+tristate "Support UFS Host Performance Booster"
+depends on SCSI_UFSHCD
+   help
+  A UFS HPB Feature improves random read performance. It caches
+  L2P map of UFS to host DRAM. The driver uses HPB read command
+  by piggybacking physical page number for bypassing FTL's L2P address
+  translation.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 433b871badfa..aa901b92e9e7 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o
 obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
 ufshcd-core-y  += ufshcd.o ufs-sysfs.o ufsfeature.o
 ufshcd-core-$(CONFIG_SCSI_UFS_BSG) += ufs_bsg.o
+obj-$(CONFIG_UFSHPB) += ufshpb.o
 obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
 obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
 obj-$(CONFIG_SCSI_UFS_HISI) += ufs-hisi.o
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 082dfca8e237..2218f19fa9f4 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2863,6 +2863,7 @@ int ufshcd_query_flag(struct ufs_hba *hba, enum 
query_opcode opcode,
ufshcd_release(hba);
return err;
 }
+EXPORT_SYMBOL(ufshcd_query_flag);
 
 /**
  * ufshcd_query_attr - API function for sending attribute requests
@@ -3061,6 +3062,7 @@ int ufshcd_query_descriptor_retry(struct ufs_hba *hba,
 
return err;
 }
+EXPORT_SYMBOL(ufshcd_query_descriptor_retry);
 
 /**
  * ufshcd_map_desc_id_to_length - map descriptor IDN to its length
diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
new file mode 100644
index ..84a9af2fdc80
--- /dev/null
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -0,0 +1,777 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Universal Flash Storage Host Performance Booster
+ *
+ * Copyright (C) 2017-2018 Samsung Electronics Co., Ltd.
+ *
+ * Authors:
+ * Yongmyung Lee 
+ * Jinyoung Choi 
+ */
+
+#include 
+
+#include "ufshcd.h"
+#include "ufshpb.h"
+
+static struct ufshpb_driver ufshpb_drv;
+
+static int ufshpb_create_sysfs(struct ufs_hba *hba, struct ufshpb_lu *hpb);
+
+static inline int ufshpb_is_valid_srgn(struct ufshpb_region *rgn,
+struct ufshpb_subregion *srgn)
+{
+   return rgn->rgn_state != HPB_RGN_INACTIVE &&
+   srgn->srgn_state == HPB_SRGN_VALID;
+}
+
+static inline int ufshpb_get_state(struct ufshpb_lu *hpb)
+{
+   return atomic_read(>hpb_state);
+}
+
+static inline void ufshpb_set_state(struct ufshpb_lu *hpb, int state)
+{
+   atomic_set(>hpb_state, state);
+}
+
+static inline int ufshpb_lu_get_dev(struct ufshpb_lu *hpb)
+{
+   if (get_device(>hpb_lu_dev))
+   return 0;
+
+   return -ENODEV;
+}
+
+static inline int ufshpb_lu_get(struct ufshpb_lu *hpb)
+{
+   if (!hpb || (ufshpb_get_state(hpb) != HPB_PRESENT))
+   return -ENODEV;
+
+   if (ufshpb_lu_get_dev(hpb))
+   return -ENODEV;
+
+   return 0;
+}
+
+static inline void ufshpb_lu_put(struct ufshpb_lu *hpb)
+{
+   put_device(>hpb_lu_dev);
+}
+
+static void ufshpb_init_subregion_tbl(struct ufshpb_lu *hpb,
+ struct ufshpb_region *rgn)
+{
+   int srgn_idx;
+
+   for (srgn_idx = 0; srgn_idx < rgn->srgn_cnt; srgn_idx++) {
+   struct ufshpb_subregion *srgn = rgn->srgn_tbl + srgn_idx;
+
+   srgn->rgn_idx = rgn->rgn_idx;
+   srgn->srgn_idx = srgn_idx;
+   srgn->srgn_state = HPB_SRGN_UNUSED;
+   }
+}
+
+static inline int ufshpb_alloc_subregion_tbl(struct ufshpb_lu *hpb,
+struct ufshpb_region *rgn,
+int 

[PATCH 17/22] gpiolib: cdev: report edge detection in lineinfo

2020-06-22 Thread Kent Gibson
Report the state of edge detection for a line in the gpioline_info_v2
returned by GPIO_GET_LINEINFO_V2_IOCTL, and indirectly for lines watched
by GPIO_GET_LINEINFO_WATCH_V2_IOCTL.

Signed-off-by: Kent Gibson 

---
 drivers/gpio/gpiolib-cdev.c | 14 ++
 drivers/gpio/gpiolib.c  |  2 ++
 drivers/gpio/gpiolib.h  |  2 ++
 3 files changed, 18 insertions(+)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index d4a22d78953f..7ba0929b2741 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -566,6 +566,12 @@ static void edge_detector_stop(struct edge_detector *edet)
 static int edge_detector_setup(struct edge_detector *edet,
   struct gpioline_config *lc)
 {
+   struct gpio_desc *desc = edge_detector_desc(edet);
+
+   if (lc->edge_detection & GPIOLINE_EDGE_RISING)
+   set_bit(FLAG_EDGE_RISING, >flags);
+   if (lc->edge_detection & GPIOLINE_EDGE_FALLING)
+   set_bit(FLAG_EDGE_FALLING, >flags);
if (lc->edge_detection)
return edge_detector_start(edet);
return 0;
@@ -1574,6 +1580,14 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
}
 
lc->edge_detection = 0;
+   if (test_bit(FLAG_EDGE_RISING, >flags)) {
+   lc->flags |= GPIOLINE_FLAG_V2_EDGE_DETECTION;
+   lc->edge_detection |= GPIOLINE_EDGE_RISING;
+   }
+   if (test_bit(FLAG_EDGE_FALLING, >flags)) {
+   lc->flags |= GPIOLINE_FLAG_V2_EDGE_DETECTION;
+   lc->edge_detection |= GPIOLINE_EDGE_FALLING;
+   }
 
spin_unlock_irqrestore(_lock, flags);
 }
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 517c99ddf6c8..a5f2795e17b7 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2041,6 +2041,8 @@ static bool gpiod_free_commit(struct gpio_desc *desc)
clear_bit(FLAG_PULL_UP, >flags);
clear_bit(FLAG_PULL_DOWN, >flags);
clear_bit(FLAG_BIAS_DISABLE, >flags);
+   clear_bit(FLAG_EDGE_RISING, >flags);
+   clear_bit(FLAG_EDGE_FALLING, >flags);
clear_bit(FLAG_IS_HOGGED, >flags);
 #ifdef CONFIG_OF_DYNAMIC
desc->hog = NULL;
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index 2dee4e1e12dc..1dc6d2b191af 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -114,6 +114,8 @@ struct gpio_desc {
 #define FLAG_PULL_UP13 /* GPIO has pull up enabled */
 #define FLAG_PULL_DOWN  14 /* GPIO has pull down enabled */
 #define FLAG_BIAS_DISABLE15/* GPIO has pull disabled */
+#define FLAG_EDGE_RISING 16/* GPIO CDEV detects rising edge events 
*/
+#define FLAG_EDGE_FALLING17/* GPIO CDEV detects falling edge 
events */
 
/* Connection label */
const char  *label;
-- 
2.27.0



[PATCH 08/22] gpiolib: cdev: complete the irq/thread timestamp handshake

2020-06-22 Thread Kent Gibson
Reset the timestamp field to 0 after using it in lineevent_irq_thread.

The timestamp is set by lineevent_irq_handler and is tested by
lineevent_irq_thread to determine if it is called from a nested theaded
interrupt.
lineevent_irq_thread is assuming that the nested, or otherwise, status
of the IRQ is static, i.e. it is either always nested or never nested.
This change removes that assumption, resetting the timestamp so it can
be re-used to determine the nested state of subsequent interrupts.

Signed-off-by: Kent Gibson 

---
 drivers/gpio/gpiolib-cdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index d50339ef6f05..1e8e0a0a9b51 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -559,6 +559,8 @@ static irqreturn_t lineevent_irq_thread(int irq, void *p)
else
ge.timestamp = le->timestamp;
 
+   le->timestamp = 0;
+
if (le->eflags & GPIOEVENT_REQUEST_RISING_EDGE
&& le->eflags & GPIOEVENT_REQUEST_FALLING_EDGE) {
int level = gpiod_get_value_cansleep(le->desc);
-- 
2.27.0



[PATCH 12/22] gpio: uapi: define GPIO_MAX_NAME_SIZE for array sizes

2020-06-22 Thread Kent Gibson
Replace constant array sizes with a macro constant to clarify the source
of array sizes, provide a place to document any constraints on the size,
and to simplify array sizing in userspace if constructing structs
from their composite fields.

Signed-off-by: Kent Gibson 

---

This change is not terribly important for V1, but in adding V2 more
documentation for the usage of this value is appropriate.
As it is also used with V1 it warrants a separate patch.

 include/uapi/linux/gpio.h | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/include/uapi/linux/gpio.h b/include/uapi/linux/gpio.h
index 0206383c0383..4e1139ab25bc 100644
--- a/include/uapi/linux/gpio.h
+++ b/include/uapi/linux/gpio.h
@@ -14,6 +14,11 @@
 #include 
 #include 
 
+/*
+ * The maximum size of name and label arrays.
+ */
+#define GPIO_MAX_NAME_SIZE 32
+
 /**
  * struct gpiochip_info - Information about a certain GPIO chip
  * @name: the Linux kernel name of this GPIO chip
@@ -22,8 +27,8 @@
  * @lines: number of GPIO lines on this chip
  */
 struct gpiochip_info {
-   char name[32];
-   char label[32];
+   char name[GPIO_MAX_NAME_SIZE];
+   char label[GPIO_MAX_NAME_SIZE];
__u32 lines;
 };
 
@@ -52,8 +57,8 @@ struct gpiochip_info {
 struct gpioline_info {
__u32 line_offset;
__u32 flags;
-   char name[32];
-   char consumer[32];
+   char name[GPIO_MAX_NAME_SIZE];
+   char consumer[GPIO_MAX_NAME_SIZE];
 };
 
 /* Maximum number of requested handles */
@@ -123,7 +128,7 @@ struct gpiohandle_request {
__u32 lineoffsets[GPIOHANDLES_MAX];
__u32 flags;
__u8 default_values[GPIOHANDLES_MAX];
-   char consumer_label[32];
+   char consumer_label[GPIO_MAX_NAME_SIZE];
__u32 lines;
int fd;
 };
@@ -182,7 +187,7 @@ struct gpioevent_request {
__u32 lineoffset;
__u32 handleflags;
__u32 eventflags;
-   char consumer_label[32];
+   char consumer_label[GPIO_MAX_NAME_SIZE];
int fd;
 };
 
-- 
2.27.0



[PATCH 14/22] gpiolib: make cdev a build option

2020-06-22 Thread Kent Gibson
Make the gpiolib-cdev module a build option.  This allows the CDEV
interface to be removed from the kernel to reduce kernel size in
applications where is it not required, and provides the parent for
other other CDEV interface specific build options to follow.

Suggested-by: Bartosz Golaszewski 
Signed-off-by: Kent Gibson 

---
 drivers/gpio/Kconfig| 16 ++--
 drivers/gpio/Makefile   |  2 +-
 drivers/gpio/gpiolib-cdev.h | 15 +++
 3 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c6b5c65c8405..affc1524bc2c 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -66,8 +66,20 @@ config GPIO_SYSFS
 
  This ABI is deprecated. If you want to use GPIO from userspace,
  use the character device /dev/gpiochipN with the appropriate
- ioctl() operations instead. The character device is always
- available.
+ ioctl() operations instead.
+
+config GPIO_CDEV
+   bool "/dev/gpiochipN (character device interface)"
+   default y
+   help
+ Say Y here to add the character device /dev/gpiochipN interface
+ for GPIOs. The character device allows userspace to control GPIOs
+ using ioctl() operations.
+
+ Only say N is you are sure that the GPIO character device is not
+ required.
+
+ If unsure, say Y.
 
 config GPIO_GENERIC
depends on HAS_IOMEM # Only for IOMEM drivers
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index ef666cfef9d0..45eb09808d12 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -7,8 +7,8 @@ obj-$(CONFIG_GPIOLIB)   += gpiolib.o
 obj-$(CONFIG_GPIOLIB)  += gpiolib-devres.o
 obj-$(CONFIG_GPIOLIB)  += gpiolib-legacy.o
 obj-$(CONFIG_GPIOLIB)  += gpiolib-devprop.o
-obj-$(CONFIG_GPIOLIB)  += gpiolib-cdev.o
 obj-$(CONFIG_OF_GPIO)  += gpiolib-of.o
+obj-$(CONFIG_GPIO_CDEV)+= gpiolib-cdev.o
 obj-$(CONFIG_GPIO_SYSFS)   += gpiolib-sysfs.o
 obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
 
diff --git a/drivers/gpio/gpiolib-cdev.h b/drivers/gpio/gpiolib-cdev.h
index 973578e7ad10..19a4e3d57120 100644
--- a/drivers/gpio/gpiolib-cdev.h
+++ b/drivers/gpio/gpiolib-cdev.h
@@ -5,7 +5,22 @@
 
 #include 
 
+#ifdef CONFIG_GPIO_CDEV
+
 int gpiolib_cdev_register(struct gpio_device *gdev, dev_t devt);
 void gpiolib_cdev_unregister(struct gpio_device *gdev);
 
+#else
+
+static inline int gpiolib_cdev_register(struct gpio_device *gdev, dev_t devt)
+{
+   return 0;
+}
+
+static inline void gpiolib_cdev_unregister(struct gpio_device *gdev)
+{
+}
+
+#endif /* CONFIG_GPIO_CDEV */
+
 #endif /* GPIOLIB_CDEV_H */
-- 
2.27.0



[PATCH 07/22] gpiolib: cdev: remove pointless decrement of i

2020-06-22 Thread Kent Gibson
Remove pointless decrement of variable, and associated comment.

While i is used subsequently, it is re-initialized so this decrement
serves no purpose.

Signed-off-by: Kent Gibson 

---
 drivers/gpio/gpiolib-cdev.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index b39e7ef8c0d4..d50339ef6f05 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -331,8 +331,6 @@ static int linehandle_create(struct gpio_device *gdev, void 
__user *ip)
dev_dbg(>dev, "registered chardev handle for line %d\n",
offset);
}
-   /* Let i point at the last handle */
-   i--;
lh->num_descs = handlereq.lines;
 
fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC);
-- 
2.27.0



Re: [PATCH v2 2/2] soc: mediatek: devapc: add devapc-mt6873 driver

2020-06-22 Thread Neal Liu
Hi Chun-Kuang,


On Sun, 2020-06-21 at 07:36 +0800, Chun-Kuang Hu wrote:
> Hi, Neal:
> 
> Neal Liu  於 2020年6月20日 週六 上午11:18寫道:
> >
> > Hi Chun-Kuang,
> >
> > Thanks for your quick feedback.
> >
> > On Sat, 2020-06-20 at 00:25 +0800, Chun-Kuang Hu wrote:
> > > Hi, Neal:
> > >
> > > Neal Liu  於 2020年6月19日 週五 下午6:01寫道:
> > > >
> > > > MT6873 bus frabric provides TrustZone security support and data
> > > > protection to prevent slaves from being accessed by unexpected
> > > > masters.
> > > > The security violations are logged and sent to the processor for
> > > > further analysis or countermeasures.
> > > >
> > > > Any occurrence of security violation would raise an interrupt, and
> > > > it will be handled by devapc-mt6873 driver. The violation
> > > > information is printed in order to find the murderer.
> > > >
> > > > Signed-off-by: Neal Liu 
> > > > ---
> > >
> > > [snip]
> > >
> > > > +
> > > > +/*
> > > > + * mtk_devapc_pd_get - get devapc pd_types of register address.
> > > > + *
> > > > + * Returns the value of reg addr
> > > > + */
> > > > +static void __iomem *mtk_devapc_pd_get(struct mtk_devapc_context 
> > > > *devapc_ctx,
> > > > +  int slave_type,
> > > > +  enum DEVAPC_PD_REG_TYPE 
> > > > pd_reg_type,
> > > > +  u32 index)
> > > > +{
> > > > +   struct mtk_devapc_vio_info *vio_info = 
> > > > devapc_ctx->soc->vio_info;
> > > > +   u32 slave_type_num = devapc_ctx->soc->slave_type_num;
> > > > +   const u32 *devapc_pds = devapc_ctx->soc->devapc_pds;
> > >
> > > devapc_pds = mt6873_devapc_pds;
> >
> > Are you saying all platform related variables & functions should assign
> > & call it directly in this common flow?
> > I don't think it's a good idea to go backwards since we already extract
> > the common out of it.
> 
> I think we should "do one thing in one patch". When you mix two things
> into one patch, how does reviewer know each modification belong to
> first thing or second thing? For supporting multiple SoC, the patches
> sequence look like this:
> 
> Patch 1: Add support SoC 1.
> Patch 2: Abstract function and variable for SoC 2.
> Patch 3: Add support SoC 2.
> Patch 4: Abstract function and variable for SoC 3.
> Patch 5: Add support SoC 3.
> Patch 6: Abstract function and variable for SoC 4.
> Patch 7: Add support SoC 4.
> 
> In patch 1, you should not do any thing about abstraction, but you
> want to merge patch 2, 4, 6 into this patch, so this patch's title
> should be "Add support SoC 1 and abstract function and varible for SoC
> 2, SoC 3, and SoC 4"
> 

Okay, I'll try to split driver to multiple patches for different
functionality. Thanks for suggestion.

> >
> > >
> > >
> > > > +   void __iomem *reg;
> > > > +
> > > > +   if (!devapc_pds)
> > >
> > > Never happen.
> > >
> > > > +   return NULL;
> > > > +
> > > > +   if ((slave_type < slave_type_num &&
> > > > +index < vio_info->vio_mask_sta_num[slave_type]) &&
> > > > +   pd_reg_type < PD_REG_TYPE_NUM) {
> > >
> > > Always true.
> > >
> > > > +   reg = devapc_ctx->devapc_pd_base[slave_type] +
> > > > +   devapc_pds[pd_reg_type];
> > > > +
> > > > +   if (pd_reg_type == VIO_MASK || pd_reg_type == VIO_STA)
> > > > +   reg += 0x4 * index;
> > > > +
> > > > +   } else {
> > > > +   pr_err(PFX "Out Of Boundary, 
> > > > slave_type:0x%x/pd_reg_type:0x%x/index:0x%x\n",
> > > > +  slave_type, pd_reg_type, index);
> > > > +   return NULL;
> > > > +   }
> > > > +
> > > > +   return reg;
> > > > +}
> > > > +
> > >
> > > [snip]
> > >
> > > > +
> > > > +/*
> > > > + * start_devapc - initialize devapc status and start receiving 
> > > > interrupt
> > > > + *   while devapc violation is triggered.
> > > > + */
> > > > +static void start_devapc(struct mtk_devapc_context *devapc_ctx)
> > > > +{
> > > > +   u32 slave_type_num = devapc_ctx->soc->slave_type_num;
> > > > +   const struct mtk_device_info **device_info;
> > > > +   const struct mtk_device_num *ndevices;
> > > > +   void __iomem *pd_vio_shift_sta_reg;
> > > > +   void __iomem *pd_apc_con_reg;
> > > > +   int slave_type, i, vio_idx, index;
> > > > +   u32 vio_shift_sta;
> > > > +
> > > > +   ndevices = devapc_ctx->soc->ndevices;
> > >
> > > ndevices = mtk6873_devices_num;
> > >
> > >
> > > > +
> > > > +   device_info = devapc_ctx->soc->device_info;
> > > > +
> > > > +   for (slave_type = 0; slave_type < slave_type_num; slave_type++) 
> > > > {
> > > > +   pd_apc_con_reg = mtk_devapc_pd_get(devapc_ctx, 
> > > > slave_type,
> > > > +  APC_CON, 0);
> > > > +   pd_vio_shift_sta_reg = mtk_devapc_pd_get(devapc_ctx, 
> > > > slave_type,
> > > > +  

[PATCH 16/22] gpiolib: cdev: add V2 uAPI implementation to parity with V1

2020-06-22 Thread Kent Gibson
Add implementation of the V2 uAPI up to parity with V1.

Signed-off-by: Kent Gibson 

---

This patch only covers the V2 functionality that is a direct analogue of
the V1.  New V2 functionality is added in subsequent patches.

The core of the implementation is the struct line, which is drawn from the
existing struct linehandle_state implementation, but modified to deal with
the V2 uAPI structs.

The struct edge_detector provides the the edge detection functionality,
and is drawn from the existing lineevent_state implementation.

The two uAPI versions are mostly independent - other than where they both
provide line info changes via reads on the chip fd.  As the info change
structs differ between V1 and V2, the infowatch implementation tracks which
version of the infowatch ioctl, either GPIO_GET_LINEINFO_WATCH_IOCTL or
GPIO_GET_LINEINFO_WATCH_V2_IOCTL, initiates the initial watch and returns
the corresponding info change struct to the read.  The version supported
on that fd locks to that version on the first watch request, so subsequent
watches from that process must use the same uAPI version.

 drivers/gpio/gpiolib-cdev.c | 934 ++--
 1 file changed, 905 insertions(+), 29 deletions(-)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index b6878fc87dfc..d4a22d78953f 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -1,7 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -14,11 +16,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "gpiolib.h"
@@ -34,6 +38,7 @@
  * GPIO line handle management
  */
 
+#ifdef CONFIG_GPIO_CDEV_V1
 /**
  * struct linehandle_state - contains the state of a userspace handle
  * @gdev: the GPIO device the handle pertains to
@@ -377,6 +382,699 @@ static int linehandle_create(struct gpio_device *gdev, 
void __user *ip)
put_device(>dev);
return ret;
 }
+#endif /* CONFIG_GPIO_CDEV_V1 */
+
+/**
+ * struct edge_detector - contains the state of a line edge detector
+ * @line: the corresponding line request
+ * @irq: the interrupt triggered in response to events on this GPIO
+ * @timestamp: cache for the timestamp storing it between hardirq and IRQ
+ * thread, used to bring the timestamp close to the actual event
+ * @seqno: the seqno for the current edge event in the sequence of events
+ * for the corresponding line request. Ths is drawn from the @line.
+ * @line_seqno: the seqno for the current edge event in the sequence of
+ * events for this line.
+ */
+struct edge_detector {
+   struct line *line;
+   unsigned int irq;
+   /*
+* timestamp and seqno are shared by edge_irq_handler and
+* edge_irq_thread which are themselves mutually exclusive.
+*/
+   u64 timestamp;
+   u32 seqno;
+   u32 line_seqno;
+};
+
+/**
+ * struct line - contains the state of a userspace line request
+ * @gdev: the GPIO device the line request pertains to
+ * @label: consumer label used to tag descriptors
+ * @num_descs: the number of descriptors held in the descs array
+ * @edge_detection: the type of edge detection applied
+ * @wait: wait queue that handles blocking reads of events
+ * @events: KFIFO for the GPIO events
+ * @seqno: the sequence number for edge events generated on all lines in
+ * this line request.  Note that this is not used when @num_descs is 1, as
+ * the line_seqno is then the same and is cheaper to calculate.
+ * @config_mutex: mutex serializing GPIOLINE_SET_CONFIG_IOCTL ioctl() calls to
+ * ensure consistency of configuration changes.
+ * @edets: an array of edge detectors, of size @num_descs
+ * @descs: the GPIO descriptors held by this line request, with @num_descs
+ * elements.
+ */
+struct line {
+   struct gpio_device *gdev;
+   const char *label;
+   u32 num_descs;
+   enum gpioline_edge edge_detection;
+   wait_queue_head_t wait;
+   DECLARE_KFIFO_PTR(events, struct gpioline_event);
+   atomic_t seqno;
+   struct mutex config_mutex; /* serializes line_set_config calls */
+   struct edge_detector *edets;
+   /* descs must be last so it can be dynamically sized */
+   struct gpio_desc *descs[];
+};
+
+static inline struct gpio_desc *edge_detector_desc(
+   const struct edge_detector *edet)
+{
+   return edet->line->descs[edet - >line->edets[0]];
+}
+
+static irqreturn_t edge_irq_thread(int irq, void *p)
+{
+   struct edge_detector *edet = p;
+   struct line *line = edet->line;
+   struct gpio_desc *desc = edge_detector_desc(edet);
+   struct gpioline_event le;
+   int ret;
+
+   /* Do not leak kernel stack to userspace */
+   memset(, 0, sizeof(le));
+
+   /*
+* We may be running from a nested threaded interrupt in which case
+* we didn't get the timestamp from 

[PATCH 11/22] gpiolib: cdev: remove recalculation of offset

2020-06-22 Thread Kent Gibson
Remove recalculation of offset from desc, where desc itself was calculated
from offset.

There is no benefit from for the desc -> hwgpio conversion in this
context. The only implicit benefit of the offset -> desc -> hwgpio is
the range check in the offset -> desc, but where desc is required you
still get that, and where desc isn't required it is simpler to perform
the range check directly.

Signed-off-by: Kent Gibson 

---

 drivers/gpio/gpiolib-cdev.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index a727709b24a9..b6878fc87dfc 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -834,7 +834,6 @@ static long gpio_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
void __user *ip = (void __user *)arg;
struct gpio_desc *desc;
__u32 offset;
-   int hwgpio;
 
/* We fail any subsequent ioctl():s when the chip is gone */
if (!gc)
@@ -862,12 +861,11 @@ static long gpio_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
if (copy_from_user(, ip, sizeof(lineinfo)))
return -EFAULT;
 
+   /* this doubles as a range check on line_offset */
desc = gpiochip_get_desc(gc, lineinfo.line_offset);
if (IS_ERR(desc))
return PTR_ERR(desc);
 
-   hwgpio = gpio_chip_hwgpio(desc);
-
gpio_desc_to_lineinfo(desc, );
 
if (copy_to_user(ip, , sizeof(lineinfo)))
@@ -883,13 +881,12 @@ static long gpio_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
if (copy_from_user(, ip, sizeof(lineinfo)))
return -EFAULT;
 
+   /* this doubles as a range check on line_offset */
desc = gpiochip_get_desc(gc, lineinfo.line_offset);
if (IS_ERR(desc))
return PTR_ERR(desc);
 
-   hwgpio = gpio_chip_hwgpio(desc);
-
-   if (test_and_set_bit(hwgpio, gcdev->watched_lines))
+   if (test_and_set_bit(lineinfo.line_offset, 
gcdev->watched_lines))
return -EBUSY;
 
gpio_desc_to_lineinfo(desc, );
@@ -902,13 +899,10 @@ static long gpio_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
if (copy_from_user(, ip, sizeof(offset)))
return -EFAULT;
 
-   desc = gpiochip_get_desc(gc, offset);
-   if (IS_ERR(desc))
-   return PTR_ERR(desc);
-
-   hwgpio = gpio_chip_hwgpio(desc);
+   if (offset >= gcdev->gdev->ngpio)
+   return -EINVAL;
 
-   if (!test_and_clear_bit(hwgpio, gcdev->watched_lines))
+   if (!test_and_clear_bit(offset, gcdev->watched_lines))
return -EBUSY;
 
return 0;
-- 
2.27.0



[PATCH 13/22] gpio: uapi: define uAPI V2

2020-06-22 Thread Kent Gibson
Add a new version of the uAPI to address existing 32/64bit alignment
issues, add support for debounce and event sequence numbers, and provide
some future proofing by adding padding reserved for future use.

The alignment issue relates to the gpioevent_data, which packs to different
sizes on 32bit and 64bit platforms. That creates problems for 32bit apps
running on 64bit kernels.  The patch addresses that particular issue, and
the problem more generally, by adding pad fields that explicitly pad
structs out to 64bit boundaries, so they will pack to the same size now,
and even if some of the reserved padding is used for __u64 fields in the
future.

The lack of future proofing in V1 makes it impossible to, for example,
add the debounce feature that is included in v2.
The future proofing is addressed by providing reserved padding in all
structs for future features.  Specifically, the line request, 
config, info, info_changed and event structs receive updated versions,
and the first three new ioctls.

Signed-off-by: Kent Gibson 

---

I haven't added any padding to gpiochip_info, as I haven't seen any calls
for new features for the corresponding ioctl, but I'm open to updating that
as well.

As the majority of the structs and ioctls were being replaced, it seemed
opportune to rework some of the other aspects of the uAPI.

Firstly, I've reworked the flags field throughout.  V1 has three different
flags fields, each with their own separate bit definitions.  In V2 that is
collapsed to one.  Further, the bits of the V2 flags field are used
as feature enable flags, with any other necessary configuration fields encoded
separately.  This is simpler and clearer, while also providing a foundation
for adding features in the future.

I've also merged the handle and event requests into a single request, the
line request, as the two requests where mostly the same, other than the
edge detection provided by event requests.  As a byproduct, the V2 uAPI
allows for multiple lines producing edge events on the same line handle.
This is a new capability as V1 only supports a single line in an event
request.

This means there are now only two types of file handle to be concerned with,
the chip and the line, and it is clearer which ioctls apply to which type
of handle.

There is also some minor renaming of fields for consistency compared to their
V1 counterparts, e.g. offset rather than lineoffset or line_offset, and 
consumer rather than consumer_label.

Additionally, V1 GPIOHANDLES_MAX becomes GPIOLINES_MAX in V2 for clarity,
and the gpiohandle_data __u8 array becomes a bitmap gpioline_values.

The V2 uAPI is mostly just a reorganisation of V1, so userspace code,
particularly libgpiod, should easily port to it.

The padding sizes have been carried over from the RFC version, although the
seqnos added to the gpioline_event alone would've used the all of the padding
for that struct, had they not been added here.  So I'm moderatly concerned
that those values are too small due to a lack of imagination on may part and
should be increased to decrease the probability of running out of space in
the padding and requiring creative solutions or even a V3.

Changes since the RFC:
 - document the constraints on array sizes to maintain 32/64 alignment
 - add sequence numbers to gpioline_event
 - use bitmap for values instead of array of __u8
 - gpioline_info_v2 contains gpioline_config instead of its composite fields
 - provide constants for all array sizes, especially padding
 - renamed "GPIOLINE_FLAG_V2_KERNEL" to "GPIOLINE_FLAG_V2_USED"
 - renamed "default_values" to "values"
 - made gpioline_direction zero based
 - document clock used in gpioline_event timestamp
 - add event_buffer_size to gpioline_request


 include/uapi/linux/gpio.h | 237 --
 1 file changed, 230 insertions(+), 7 deletions(-)

diff --git a/include/uapi/linux/gpio.h b/include/uapi/linux/gpio.h
index 4e1139ab25bc..e4ed6f79e332 100644
--- a/include/uapi/linux/gpio.h
+++ b/include/uapi/linux/gpio.h
@@ -11,11 +11,14 @@
 #ifndef _UAPI_GPIO_H_
 #define _UAPI_GPIO_H_
 
+#include 
 #include 
 #include 
 
 /*
  * The maximum size of name and label arrays.
+ *
+ * Must be a multiple of 8 to ensure 32/64bit alignment of structs.
  */
 #define GPIO_MAX_NAME_SIZE 32
 
@@ -32,6 +35,211 @@ struct gpiochip_info {
__u32 lines;
 };
 
+/*
+ * Maximum number of requested lines.
+ *
+ * Must be a multiple of 8 to ensure 32/64bit alignment of structs.
+ */
+#define GPIOLINES_MAX 64
+
+/* the number of __u64 required for a bitmap for GPIOLINES_MAX lines */
+#define GPIOLINES_BITMAP_SIZE  __KERNEL_DIV_ROUND_UP(GPIOLINES_MAX, 64)
+
+enum gpioline_direction {
+   GPIOLINE_DIRECTION_INPUT= 0,
+   GPIOLINE_DIRECTION_OUTPUT   = 1,
+};
+
+enum gpioline_drive {
+   GPIOLINE_DRIVE_PUSH_PULL= 0,
+   GPIOLINE_DRIVE_OPEN_DRAIN   = 1,
+   GPIOLINE_DRIVE_OPEN_SOURCE  = 2,
+};
+
+enum gpioline_bias {
+   

[PATCH 10/22] gpiolib: cdev: fix minor race in GET_LINEINFO_WATCH

2020-06-22 Thread Kent Gibson
Merge separate usage of test_bit/set_bit into test_and_set_bit to remove
the possibility of a race between the test and set.

Similarly test_bit and clear_bit.

In the existing code it is possible for two threads to race past the
test_bit and then set or clear the watch bit, and neither return EBUSY.

Signed-off-by: Kent Gibson 

---
 drivers/gpio/gpiolib-cdev.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 5f5b715ed7f7..a727709b24a9 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -889,7 +889,7 @@ static long gpio_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
 
hwgpio = gpio_chip_hwgpio(desc);
 
-   if (test_bit(hwgpio, gcdev->watched_lines))
+   if (test_and_set_bit(hwgpio, gcdev->watched_lines))
return -EBUSY;
 
gpio_desc_to_lineinfo(desc, );
@@ -897,7 +897,6 @@ static long gpio_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
if (copy_to_user(ip, , sizeof(lineinfo)))
return -EFAULT;
 
-   set_bit(hwgpio, gcdev->watched_lines);
return 0;
} else if (cmd == GPIO_GET_LINEINFO_UNWATCH_IOCTL) {
if (copy_from_user(, ip, sizeof(offset)))
@@ -909,10 +908,9 @@ static long gpio_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
 
hwgpio = gpio_chip_hwgpio(desc);
 
-   if (!test_bit(hwgpio, gcdev->watched_lines))
+   if (!test_and_clear_bit(hwgpio, gcdev->watched_lines))
return -EBUSY;
 
-   clear_bit(hwgpio, gcdev->watched_lines);
return 0;
}
return -EINVAL;
-- 
2.27.0



[PATCH 06/22] gpiolib: cdev: rename numdescs to num_descs

2020-06-22 Thread Kent Gibson
Rename numdescs to num_descs to be more consistent with the naming of
other counters and improve readability.

Signed-off-by: Kent Gibson 

---
 drivers/gpio/gpiolib-cdev.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 0d3a799e09ae..b39e7ef8c0d4 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -39,13 +39,13 @@
  * @gdev: the GPIO device the handle pertains to
  * @label: consumer label used to tag descriptors
  * @descs: the GPIO descriptors held by this handle
- * @numdescs: the number of descriptors held in the descs array
+ * @num_descs: the number of descriptors held in the descs array
  */
 struct linehandle_state {
struct gpio_device *gdev;
const char *label;
struct gpio_desc *descs[GPIOHANDLES_MAX];
-   u32 numdescs;
+   u32 num_descs;
 };
 
 #define GPIOHANDLE_REQUEST_VALID_FLAGS \
@@ -138,7 +138,7 @@ static long linehandle_set_config(struct linehandle_state 
*lh,
if (ret)
return ret;
 
-   for (i = 0; i < lh->numdescs; i++) {
+   for (i = 0; i < lh->num_descs; i++) {
desc = lh->descs[i];
linehandle_flags_to_desc_flags(gcnf.flags, >flags);
 
@@ -177,7 +177,7 @@ static long linehandle_ioctl(struct file *file, unsigned 
int cmd,
/* NOTE: It's ok to read values of output lines. */
int ret = gpiod_get_array_value_complex(false,
true,
-   lh->numdescs,
+   lh->num_descs,
lh->descs,
NULL,
vals);
@@ -185,7 +185,7 @@ static long linehandle_ioctl(struct file *file, unsigned 
int cmd,
return ret;
 
memset(, 0, sizeof(ghd));
-   for (i = 0; i < lh->numdescs; i++)
+   for (i = 0; i < lh->num_descs; i++)
ghd.values[i] = test_bit(i, vals);
 
if (copy_to_user(ip, , sizeof(ghd)))
@@ -204,13 +204,13 @@ static long linehandle_ioctl(struct file *file, unsigned 
int cmd,
return -EFAULT;
 
/* Clamp all values to [0,1] */
-   for (i = 0; i < lh->numdescs; i++)
+   for (i = 0; i < lh->num_descs; i++)
__assign_bit(i, vals, ghd.values[i]);
 
/* Reuse the array setting function */
return gpiod_set_array_value_complex(false,
 true,
-lh->numdescs,
+lh->num_descs,
 lh->descs,
 NULL,
 vals);
@@ -234,7 +234,7 @@ static int linehandle_release(struct inode *inode, struct 
file *file)
struct gpio_device *gdev = lh->gdev;
int i;
 
-   for (i = 0; i < lh->numdescs; i++)
+   for (i = 0; i < lh->num_descs; i++)
gpiod_free(lh->descs[i]);
kfree(lh->label);
kfree(lh);
@@ -333,7 +333,7 @@ static int linehandle_create(struct gpio_device *gdev, void 
__user *ip)
}
/* Let i point at the last handle */
i--;
-   lh->numdescs = handlereq.lines;
+   lh->num_descs = handlereq.lines;
 
fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC);
if (fd < 0) {
@@ -364,7 +364,7 @@ static int linehandle_create(struct gpio_device *gdev, void 
__user *ip)
fd_install(fd, file);
 
dev_dbg(>dev, "registered chardev handle for %d lines\n",
-   lh->numdescs);
+   lh->num_descs);
 
return 0;
 
-- 
2.27.0



[PATCH 09/22] gpiolib: cdev: rename priv to gcdev

2020-06-22 Thread Kent Gibson
Rename priv to gcdev to improve readability.

The name "priv" indicates that the object is pointed to by
file->private_data, not what the object is actually is.
It is always used to point to a struct gpio_chardev_data so renaming
it to gcdev seemed as good as anything, and certainly clearer than "priv".

Signed-off-by: Kent Gibson 

---
 drivers/gpio/gpiolib-cdev.c | 90 ++---
 1 file changed, 45 insertions(+), 45 deletions(-)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 1e8e0a0a9b51..5f5b715ed7f7 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -828,8 +828,8 @@ struct gpio_chardev_data {
  */
 static long gpio_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 {
-   struct gpio_chardev_data *priv = file->private_data;
-   struct gpio_device *gdev = priv->gdev;
+   struct gpio_chardev_data *gcdev = file->private_data;
+   struct gpio_device *gdev = gcdev->gdev;
struct gpio_chip *gc = gdev->chip;
void __user *ip = (void __user *)arg;
struct gpio_desc *desc;
@@ -889,7 +889,7 @@ static long gpio_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
 
hwgpio = gpio_chip_hwgpio(desc);
 
-   if (test_bit(hwgpio, priv->watched_lines))
+   if (test_bit(hwgpio, gcdev->watched_lines))
return -EBUSY;
 
gpio_desc_to_lineinfo(desc, );
@@ -897,7 +897,7 @@ static long gpio_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
if (copy_to_user(ip, , sizeof(lineinfo)))
return -EFAULT;
 
-   set_bit(hwgpio, priv->watched_lines);
+   set_bit(hwgpio, gcdev->watched_lines);
return 0;
} else if (cmd == GPIO_GET_LINEINFO_UNWATCH_IOCTL) {
if (copy_from_user(, ip, sizeof(offset)))
@@ -909,10 +909,10 @@ static long gpio_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
 
hwgpio = gpio_chip_hwgpio(desc);
 
-   if (!test_bit(hwgpio, priv->watched_lines))
+   if (!test_bit(hwgpio, gcdev->watched_lines))
return -EBUSY;
 
-   clear_bit(hwgpio, priv->watched_lines);
+   clear_bit(hwgpio, gcdev->watched_lines);
return 0;
}
return -EINVAL;
@@ -935,12 +935,12 @@ to_gpio_chardev_data(struct notifier_block *nb)
 static int lineinfo_changed_notify(struct notifier_block *nb,
   unsigned long action, void *data)
 {
-   struct gpio_chardev_data *priv = to_gpio_chardev_data(nb);
+   struct gpio_chardev_data *gcdev = to_gpio_chardev_data(nb);
struct gpioline_info_changed chg;
struct gpio_desc *desc = data;
int ret;
 
-   if (!test_bit(gpio_chip_hwgpio(desc), priv->watched_lines))
+   if (!test_bit(gpio_chip_hwgpio(desc), gcdev->watched_lines))
return NOTIFY_DONE;
 
memset(, 0, sizeof(chg));
@@ -949,9 +949,9 @@ static int lineinfo_changed_notify(struct notifier_block 
*nb,
chg.timestamp = ktime_get_ns();
gpio_desc_to_lineinfo(desc, );
 
-   ret = kfifo_in_spinlocked(>events, , 1, >wait.lock);
+   ret = kfifo_in_spinlocked(>events, , 1, >wait.lock);
if (ret)
-   wake_up_poll(>wait, EPOLLIN);
+   wake_up_poll(>wait, EPOLLIN);
else
pr_debug_ratelimited("lineinfo event FIFO is full - event 
dropped\n");
 
@@ -961,13 +961,13 @@ static int lineinfo_changed_notify(struct notifier_block 
*nb,
 static __poll_t lineinfo_watch_poll(struct file *file,
struct poll_table_struct *pollt)
 {
-   struct gpio_chardev_data *priv = file->private_data;
+   struct gpio_chardev_data *gcdev = file->private_data;
__poll_t events = 0;
 
-   poll_wait(file, >wait, pollt);
+   poll_wait(file, >wait, pollt);
 
-   if (!kfifo_is_empty_spinlocked_noirqsave(>events,
->wait.lock))
+   if (!kfifo_is_empty_spinlocked_noirqsave(>events,
+>wait.lock))
events = EPOLLIN | EPOLLRDNORM;
 
return events;
@@ -976,7 +976,7 @@ static __poll_t lineinfo_watch_poll(struct file *file,
 static ssize_t lineinfo_watch_read(struct file *file, char __user *buf,
   size_t count, loff_t *off)
 {
-   struct gpio_chardev_data *priv = file->private_data;
+   struct gpio_chardev_data *gcdev = file->private_data;
struct gpioline_info_changed event;
ssize_t bytes_read = 0;
int ret;
@@ -985,28 +985,28 @@ static ssize_t lineinfo_watch_read(struct file *file, 
char __user *buf,
return -EINVAL;
 
do {
-   spin_lock(>wait.lock);
-   if (kfifo_is_empty(>events)) {
+  

[PATCH 03/22] gpiolib: cdev: minor indentation fixes

2020-06-22 Thread Kent Gibson
Make indentation consistent with other use to improve readability.

Signed-off-by: Kent Gibson 

---
 drivers/gpio/gpiolib-cdev.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 55a9b7b44304..889ed2dc9e58 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -98,7 +98,7 @@ static int linehandle_validate_flags(u32 flags)
/* Only one bias flag can be set. */
if (((flags & GPIOHANDLE_REQUEST_BIAS_DISABLE) &&
 (flags & (GPIOHANDLE_REQUEST_BIAS_PULL_DOWN |
-   GPIOHANDLE_REQUEST_BIAS_PULL_UP))) ||
+  GPIOHANDLE_REQUEST_BIAS_PULL_UP))) ||
((flags & GPIOHANDLE_REQUEST_BIAS_PULL_DOWN) &&
 (flags & GPIOHANDLE_REQUEST_BIAS_PULL_UP)))
return -EINVAL;
@@ -212,11 +212,11 @@ static long linehandle_ioctl(struct file *filep, unsigned 
int cmd,
 
/* Reuse the array setting function */
return gpiod_set_array_value_complex(false,
- true,
- lh->numdescs,
- lh->descs,
- NULL,
- vals);
+true,
+lh->numdescs,
+lh->descs,
+NULL,
+vals);
} else if (cmd == GPIOHANDLE_SET_CONFIG_IOCTL) {
return linehandle_set_config(lh, ip);
}
@@ -225,7 +225,7 @@ static long linehandle_ioctl(struct file *filep, unsigned 
int cmd,
 
 #ifdef CONFIG_COMPAT
 static long linehandle_ioctl_compat(struct file *filep, unsigned int cmd,
-unsigned long arg)
+   unsigned long arg)
 {
return linehandle_ioctl(filep, cmd, (unsigned long)compat_ptr(arg));
 }
@@ -428,7 +428,7 @@ struct lineevent_state {
GPIOEVENT_REQUEST_FALLING_EDGE)
 
 static __poll_t lineevent_poll(struct file *filep,
-  struct poll_table_struct *wait)
+  struct poll_table_struct *wait)
 {
struct lineevent_state *le = filep->private_data;
__poll_t events = 0;
@@ -720,11 +720,11 @@ static int lineevent_create(struct gpio_device *gdev, 
void __user *ip)
 
/* Request a thread to read the events */
ret = request_threaded_irq(le->irq,
-   lineevent_irq_handler,
-   lineevent_irq_thread,
-   irqflags,
-   le->label,
-   le);
+  lineevent_irq_handler,
+  lineevent_irq_thread,
+  irqflags,
+  le->label,
+  le);
if (ret)
goto out_free_desc;
 
@@ -1052,7 +1052,7 @@ static ssize_t lineinfo_watch_read(struct file *filep, 
char __user *buf,
 static int gpio_chrdev_open(struct inode *inode, struct file *filp)
 {
struct gpio_device *gdev = container_of(inode->i_cdev,
- struct gpio_device, chrdev);
+   struct gpio_device, chrdev);
struct gpio_chardev_data *priv;
int ret = -ENOMEM;
 
-- 
2.27.0



[PATCH 04/22] gpiolib: cdev: refactor gpiohandle_flags_to_desc_flags

2020-06-22 Thread Kent Gibson
Refactor the mapping from handle flags to desc flags into a helper
function.

The assign_bit is overkill where it is replacing the set_bit cases, as is
rechecking bits known to be clear in some circumstances, but the DRY
simplification more than makes up for any performance degradation,
especially as this is not a hot path.

Signed-off-by: Kent Gibson 

---
 drivers/gpio/gpiolib-cdev.c | 60 -
 1 file changed, 19 insertions(+), 41 deletions(-)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 889ed2dc9e58..e64613b8d0ba 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -106,6 +106,22 @@ static int linehandle_validate_flags(u32 flags)
return 0;
 }
 
+static void linehandle_flags_to_desc_flags(u32 lflags, unsigned long *flagsp)
+{
+   assign_bit(FLAG_ACTIVE_LOW, flagsp,
+  lflags & GPIOHANDLE_REQUEST_ACTIVE_LOW);
+   assign_bit(FLAG_OPEN_DRAIN, flagsp,
+  lflags & GPIOHANDLE_REQUEST_OPEN_DRAIN);
+   assign_bit(FLAG_OPEN_SOURCE, flagsp,
+  lflags & GPIOHANDLE_REQUEST_OPEN_SOURCE);
+   assign_bit(FLAG_PULL_UP, flagsp,
+  lflags & GPIOHANDLE_REQUEST_BIAS_PULL_UP);
+   assign_bit(FLAG_PULL_DOWN, flagsp,
+  lflags & GPIOHANDLE_REQUEST_BIAS_PULL_DOWN);
+   assign_bit(FLAG_BIAS_DISABLE, flagsp,
+  lflags & GPIOHANDLE_REQUEST_BIAS_DISABLE);
+}
+
 static long linehandle_set_config(struct linehandle_state *lh,
  void __user *ip)
 {
@@ -113,7 +129,6 @@ static long linehandle_set_config(struct linehandle_state 
*lh,
struct gpio_desc *desc;
int i, ret;
u32 lflags;
-   unsigned long *flagsp;
 
if (copy_from_user(, ip, sizeof(gcnf)))
return -EFAULT;
@@ -125,25 +140,7 @@ static long linehandle_set_config(struct linehandle_state 
*lh,
 
for (i = 0; i < lh->numdescs; i++) {
desc = lh->descs[i];
-   flagsp = >flags;
-
-   assign_bit(FLAG_ACTIVE_LOW, flagsp,
-   lflags & GPIOHANDLE_REQUEST_ACTIVE_LOW);
-
-   assign_bit(FLAG_OPEN_DRAIN, flagsp,
-   lflags & GPIOHANDLE_REQUEST_OPEN_DRAIN);
-
-   assign_bit(FLAG_OPEN_SOURCE, flagsp,
-   lflags & GPIOHANDLE_REQUEST_OPEN_SOURCE);
-
-   assign_bit(FLAG_PULL_UP, flagsp,
-   lflags & GPIOHANDLE_REQUEST_BIAS_PULL_UP);
-
-   assign_bit(FLAG_PULL_DOWN, flagsp,
-   lflags & GPIOHANDLE_REQUEST_BIAS_PULL_DOWN);
-
-   assign_bit(FLAG_BIAS_DISABLE, flagsp,
-   lflags & GPIOHANDLE_REQUEST_BIAS_DISABLE);
+   linehandle_flags_to_desc_flags(gcnf.flags, >flags);
 
/*
 * Lines have to be requested explicitly for input
@@ -306,19 +303,7 @@ static int linehandle_create(struct gpio_device *gdev, 
void __user *ip)
goto out_free_descs;
lh->descs[i] = desc;
count = i + 1;
-
-   if (lflags & GPIOHANDLE_REQUEST_ACTIVE_LOW)
-   set_bit(FLAG_ACTIVE_LOW, >flags);
-   if (lflags & GPIOHANDLE_REQUEST_OPEN_DRAIN)
-   set_bit(FLAG_OPEN_DRAIN, >flags);
-   if (lflags & GPIOHANDLE_REQUEST_OPEN_SOURCE)
-   set_bit(FLAG_OPEN_SOURCE, >flags);
-   if (lflags & GPIOHANDLE_REQUEST_BIAS_DISABLE)
-   set_bit(FLAG_BIAS_DISABLE, >flags);
-   if (lflags & GPIOHANDLE_REQUEST_BIAS_PULL_DOWN)
-   set_bit(FLAG_PULL_DOWN, >flags);
-   if (lflags & GPIOHANDLE_REQUEST_BIAS_PULL_UP)
-   set_bit(FLAG_PULL_UP, >flags);
+   linehandle_flags_to_desc_flags(handlereq.flags, >flags);
 
ret = gpiod_set_transitory(desc, false);
if (ret < 0)
@@ -685,14 +670,7 @@ static int lineevent_create(struct gpio_device *gdev, void 
__user *ip)
le->desc = desc;
le->eflags = eflags;
 
-   if (lflags & GPIOHANDLE_REQUEST_ACTIVE_LOW)
-   set_bit(FLAG_ACTIVE_LOW, >flags);
-   if (lflags & GPIOHANDLE_REQUEST_BIAS_DISABLE)
-   set_bit(FLAG_BIAS_DISABLE, >flags);
-   if (lflags & GPIOHANDLE_REQUEST_BIAS_PULL_DOWN)
-   set_bit(FLAG_PULL_DOWN, >flags);
-   if (lflags & GPIOHANDLE_REQUEST_BIAS_PULL_UP)
-   set_bit(FLAG_PULL_UP, >flags);
+   linehandle_flags_to_desc_flags(lflags, >flags);
 
ret = gpiod_direction_input(desc);
if (ret)
-- 
2.27.0



[PATCH 05/22] gpiolib: cdev: rename 'filep' and 'filp' to 'file' to be consistent with other use

2020-06-22 Thread Kent Gibson
Rename 'filep' and 'filp' to 'file' to be consistent with other use
and improve readability.

Signed-off-by: Kent Gibson 

---

The code was using both "filep" and "filp" and I flip flopped between
which one to change to until looking at code elsewhere in the kernel
where "struct file *file" is the most common and so going with that.

 drivers/gpio/gpiolib-cdev.c | 70 ++---
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index e64613b8d0ba..0d3a799e09ae 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -164,10 +164,10 @@ static long linehandle_set_config(struct linehandle_state 
*lh,
return 0;
 }
 
-static long linehandle_ioctl(struct file *filep, unsigned int cmd,
+static long linehandle_ioctl(struct file *file, unsigned int cmd,
 unsigned long arg)
 {
-   struct linehandle_state *lh = filep->private_data;
+   struct linehandle_state *lh = file->private_data;
void __user *ip = (void __user *)arg;
struct gpiohandle_data ghd;
DECLARE_BITMAP(vals, GPIOHANDLES_MAX);
@@ -221,16 +221,16 @@ static long linehandle_ioctl(struct file *filep, unsigned 
int cmd,
 }
 
 #ifdef CONFIG_COMPAT
-static long linehandle_ioctl_compat(struct file *filep, unsigned int cmd,
+static long linehandle_ioctl_compat(struct file *file, unsigned int cmd,
unsigned long arg)
 {
-   return linehandle_ioctl(filep, cmd, (unsigned long)compat_ptr(arg));
+   return linehandle_ioctl(file, cmd, (unsigned long)compat_ptr(arg));
 }
 #endif
 
-static int linehandle_release(struct inode *inode, struct file *filep)
+static int linehandle_release(struct inode *inode, struct file *file)
 {
-   struct linehandle_state *lh = filep->private_data;
+   struct linehandle_state *lh = file->private_data;
struct gpio_device *gdev = lh->gdev;
int i;
 
@@ -412,13 +412,13 @@ struct lineevent_state {
(GPIOEVENT_REQUEST_RISING_EDGE | \
GPIOEVENT_REQUEST_FALLING_EDGE)
 
-static __poll_t lineevent_poll(struct file *filep,
+static __poll_t lineevent_poll(struct file *file,
   struct poll_table_struct *wait)
 {
-   struct lineevent_state *le = filep->private_data;
+   struct lineevent_state *le = file->private_data;
__poll_t events = 0;
 
-   poll_wait(filep, >wait, wait);
+   poll_wait(file, >wait, wait);
 
if (!kfifo_is_empty_spinlocked_noirqsave(>events, >wait.lock))
events = EPOLLIN | EPOLLRDNORM;
@@ -427,12 +427,12 @@ static __poll_t lineevent_poll(struct file *filep,
 }
 
 
-static ssize_t lineevent_read(struct file *filep,
+static ssize_t lineevent_read(struct file *file,
  char __user *buf,
  size_t count,
  loff_t *f_ps)
 {
-   struct lineevent_state *le = filep->private_data;
+   struct lineevent_state *le = file->private_data;
struct gpioevent_data ge;
ssize_t bytes_read = 0;
int ret;
@@ -448,7 +448,7 @@ static ssize_t lineevent_read(struct file *filep,
return bytes_read;
}
 
-   if (filep->f_flags & O_NONBLOCK) {
+   if (file->f_flags & O_NONBLOCK) {
spin_unlock(>wait.lock);
return -EAGAIN;
}
@@ -481,9 +481,9 @@ static ssize_t lineevent_read(struct file *filep,
return bytes_read;
 }
 
-static int lineevent_release(struct inode *inode, struct file *filep)
+static int lineevent_release(struct inode *inode, struct file *file)
 {
-   struct lineevent_state *le = filep->private_data;
+   struct lineevent_state *le = file->private_data;
struct gpio_device *gdev = le->gdev;
 
free_irq(le->irq, le);
@@ -494,10 +494,10 @@ static int lineevent_release(struct inode *inode, struct 
file *filep)
return 0;
 }
 
-static long lineevent_ioctl(struct file *filep, unsigned int cmd,
+static long lineevent_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
 {
-   struct lineevent_state *le = filep->private_data;
+   struct lineevent_state *le = file->private_data;
void __user *ip = (void __user *)arg;
struct gpiohandle_data ghd;
 
@@ -524,10 +524,10 @@ static long lineevent_ioctl(struct file *filep, unsigned 
int cmd,
 }
 
 #ifdef CONFIG_COMPAT
-static long lineevent_ioctl_compat(struct file *filep, unsigned int cmd,
+static long lineevent_ioctl_compat(struct file *file, unsigned int cmd,
   unsigned long arg)
 {
-   return lineevent_ioctl(filep, cmd, (unsigned long)compat_ptr(arg));
+   return lineevent_ioctl(file, cmd, (unsigned long)compat_ptr(arg));
 }
 #endif
 
@@ -826,9 +826,9 @@ 

[PATCH 02/22] gpiolib: cdev: sort includes

2020-06-22 Thread Kent Gibson
Sort the includes of gpiolib-cdev.c to make it easier to identify if a
module is included and to avoid duplication.

Signed-off-by: Kent Gibson 

---
 drivers/gpio/gpiolib-cdev.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index b8b872724628..55a9b7b44304 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -1,24 +1,24 @@
 // SPDX-License-Identifier: GPL-2.0
 
+#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
 #include 
+#include 
 #include 
+#include 
 #include 
 
 #include "gpiolib.h"
-- 
2.27.0



[PATCH 00/22] gpio: cdev: add uAPI V2

2020-06-22 Thread Kent Gibson
This patchset defines and implements adds a new version of the
GPIO CDEV uAPI to address existing 32/64bit alignment issues, add
support for debounce and event sequence numbers, and provide some
future proofing by adding padding reserved for future use.

The series can be partitioned into three sets; the first twelve
are minor code tidy ups or fixes that I ran across while implementing V2,
the next seven contain the V2 uAPI implementation proper, and the final
three port the GPIO tools to the V2 uAPI.

The more complicated patches include their own commentary where appropriate.

Cheers,
Kent.

Kent Gibson (22):
  gpiolib: move gpiolib-sysfs function declarations into their own
header
  gpiolib: cdev: sort includes
  gpiolib: cdev: minor indentation fixes
  gpiolib: cdev: refactor gpiohandle_flags_to_desc_flags
  gpiolib: cdev: rename 'filep' and 'filp' to 'file' to be consistent
with other use
  gpiolib: cdev: rename numdescs to num_descs
  gpiolib: cdev: remove pointless decrement of i
  gpiolib: cdev: complete the irq/thread timestamp handshake
  gpiolib: cdev: rename priv to gcdev
  gpiolib: cdev: fix minor race in GET_LINEINFO_WATCH
  gpiolib: cdev: remove recalculation of offset
  gpio: uapi: define GPIO_MAX_NAME_SIZE for array sizes
  gpio: uapi: define uAPI V2
  gpiolib: make cdev a build option
  gpiolib: add build option for CDEV V1 ABI
  gpiolib: cdev: add V2 uAPI implementation to parity with V1
  gpiolib: cdev: report edge detection in lineinfo
  gpiolib: cdev: support setting debounce
  gpio: uapi: document uAPI V1 as deprecated
  tools: gpio: switch tools to V2 uAPI
  tools: gpio: add debounce support to gpio-event-mon
  tools: gpio: support monitoring multiple lines

 drivers/gpio/Kconfig |   28 +-
 drivers/gpio/Makefile|2 +-
 drivers/gpio/gpiolib-cdev.c  | 1610 --
 drivers/gpio/gpiolib-cdev.h  |   15 +
 drivers/gpio/gpiolib-sysfs.c |1 +
 drivers/gpio/gpiolib-sysfs.h |   24 +
 drivers/gpio/gpiolib.c   |3 +
 drivers/gpio/gpiolib.h   |   24 +-
 include/uapi/linux/gpio.h|  280 +-
 tools/gpio/gpio-event-mon.c  |  133 +--
 tools/gpio/gpio-hammer.c |   28 +-
 tools/gpio/gpio-utils.c  |  107 +--
 tools/gpio/gpio-utils.h  |   48 +-
 tools/gpio/gpio-watch.c  |   10 +-
 tools/gpio/lsgpio.c  |  112 ++-
 15 files changed, 1933 insertions(+), 492 deletions(-)
 create mode 100644 drivers/gpio/gpiolib-sysfs.h


base-commit: 84651e81ee3323c7d544edfa6ac6026425fe5a52
-- 
2.27.0



[PATCH 01/22] gpiolib: move gpiolib-sysfs function declarations into their own header

2020-06-22 Thread Kent Gibson
Move gpiolib-sysfs function declarations into their own header.

These functions are in gpiolib-sysfs.c, and are only required by gpiolib.c,
and so should be in a module header, not giolib.h.

This brings gpiolib-sysfs into line with gpiolib-cdev, and is another step
towards removing the sysfs inferface.

Signed-off-by: Kent Gibson 

---
 drivers/gpio/gpiolib-sysfs.c |  1 +
 drivers/gpio/gpiolib-sysfs.h | 24 
 drivers/gpio/gpiolib.c   |  1 +
 drivers/gpio/gpiolib.h   | 18 --
 4 files changed, 26 insertions(+), 18 deletions(-)
 create mode 100644 drivers/gpio/gpiolib-sysfs.h

diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c
index 23e3d335cd54..18f94be1b458 100644
--- a/drivers/gpio/gpiolib-sysfs.c
+++ b/drivers/gpio/gpiolib-sysfs.c
@@ -11,6 +11,7 @@
 #include 
 
 #include "gpiolib.h"
+#include "gpiolib-sysfs.h"
 
 #define GPIO_IRQF_TRIGGER_FALLING  BIT(0)
 #define GPIO_IRQF_TRIGGER_RISING   BIT(1)
diff --git a/drivers/gpio/gpiolib-sysfs.h b/drivers/gpio/gpiolib-sysfs.h
new file mode 100644
index ..ddd0e503f8eb
--- /dev/null
+++ b/drivers/gpio/gpiolib-sysfs.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef GPIOLIB_SYSFS_H
+#define GPIOLIB_SYSFS_H
+
+#ifdef CONFIG_GPIO_SYSFS
+
+int gpiochip_sysfs_register(struct gpio_device *gdev);
+void gpiochip_sysfs_unregister(struct gpio_device *gdev);
+
+#else
+
+static inline int gpiochip_sysfs_register(struct gpio_device *gdev)
+{
+   return 0;
+}
+
+static inline void gpiochip_sysfs_unregister(struct gpio_device *gdev)
+{
+}
+
+#endif /* CONFIG_GPIO_SYSFS */
+
+#endif /* GPIOLIB_SYSFS_H */
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 4abd751314a5..517c99ddf6c8 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -26,6 +26,7 @@
 #include "gpiolib-of.h"
 #include "gpiolib-acpi.h"
 #include "gpiolib-cdev.h"
+#include "gpiolib-sysfs.h"
 
 #define CREATE_TRACE_POINTS
 #include 
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index 9ed242316414..2dee4e1e12dc 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -175,22 +175,4 @@ static inline int gpio_chip_hwgpio(const struct gpio_desc 
*desc)
 #define chip_dbg(gc, fmt, ...) \
dev_dbg(>gpiodev->dev, "(%s): " fmt, gc->label, ##__VA_ARGS__)
 
-#ifdef CONFIG_GPIO_SYSFS
-
-int gpiochip_sysfs_register(struct gpio_device *gdev);
-void gpiochip_sysfs_unregister(struct gpio_device *gdev);
-
-#else
-
-static inline int gpiochip_sysfs_register(struct gpio_device *gdev)
-{
-   return 0;
-}
-
-static inline void gpiochip_sysfs_unregister(struct gpio_device *gdev)
-{
-}
-
-#endif /* CONFIG_GPIO_SYSFS */
-
 #endif /* GPIOLIB_H */
-- 
2.27.0



Re: [PATCH] [net/sched] tcindex_change: Remove redundant null check

2020-06-22 Thread David Miller
From: Gaurav Singh 
Date: Sun, 21 Jun 2020 22:24:30 -0400

> arg cannot be NULL since its already being dereferenced
> before. Remove the redundant NULL check.
> 
> Signed-off-by: Gaurav Singh 

Applied, thank you.


Re: linux-next: build failure after merge of the kspp tree

2020-06-22 Thread David Miller
From: Stephen Rothwell 
Date: Tue, 23 Jun 2020 13:51:34 +1000

> I have added the following merge fix patch.
> 
> From: Stephen Rothwell 
> Date: Tue, 23 Jun 2020 13:43:06 +1000
> Subject: [PATCH] net/core/devlink.c: remove new uninitialized_var() usage
> 
> Signed-off-by: Stephen Rothwell 

Applied, thanks Stephen.


Re: [PATCH 2/3] arm64: dts: imx8qxp: add i2c aliases

2020-06-22 Thread Shawn Guo
On Mon, Jun 01, 2020 at 10:06:19AM +0800, peng@nxp.com wrote:
> From: Peng Fan 
> 
> The devices could be enumerated properly with aliases.
> 
> Signed-off-by: Peng Fan 
> ---
>  arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
> b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> index 33363c127478..8ce997110cd6 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> @@ -19,6 +19,10 @@
>   #size-cells = <2>;
>  
>   aliases {
> + i2c0 = _i2c0;
> + i2c1 = _i2c1;
> + i2c2 = _i2c2;
> + i2c3 = _i2c3;

Had a second look.  It breaks alphabetical order.  So dropped the
series.

Shawn

>   gpio0 = _gpio0;
>   gpio1 = _gpio1;
>   gpio2 = _gpio2;
> -- 
> 2.16.4
> 


[RFC PATCH v3 2/5] scsi: ufs: Add UFS-feature layer

2020-06-22 Thread Daejun Park


This patch is adding UFS feature layer to UFS core driver.

UFS Driver data structure (struct ufs_hba)
│
┌--┐
│ UFS feature  │ <-- HPB module
│layer │ <-- other extended feature module
└--┘
Each extended UFS-Feature module has a bus of ufs-ext feature type.
The UFS feature layer manages common APIs used by each extended feature
module. The APIs are set of UFS Query requests and UFS Vendor commands
related to each extended feature module.

Other extended features can also be implemented using the proposed APIs.
For example, in Write Booster, "prep_fn" can be used to guarantee the
lifetime of UFS by updating the amount of write IO.
And reset/reset_host/suspend/resume can be used to manage the kernel task
for checking lifetime of UFS.

The following 6 callback functions have been added to "ufshcd.c".
prep_fn: called after construct upiu structure
reset: called after proving hba
reset_host: called before ufshcd_host_reset_and_restore
suspend: called before ufshcd_suspend
resume: called after ufshcd_resume
rsp_upiu: called in ufshcd_transfer_rsp_status with SAM_STAT_GOOD state

Signed-off-by: Daejun Park 
---
 drivers/scsi/ufs/Makefile |   2 +-
 drivers/scsi/ufs/ufsfeature.c | 148 ++
 drivers/scsi/ufs/ufsfeature.h |  69 
 drivers/scsi/ufs/ufshcd.c |  17 
 drivers/scsi/ufs/ufshcd.h |   3 +
 5 files changed, 238 insertions(+), 1 deletion(-)
 create mode 100644 drivers/scsi/ufs/ufsfeature.c
 create mode 100644 drivers/scsi/ufs/ufsfeature.h

diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index f0c5b95ec9cc..433b871badfa 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -6,7 +6,7 @@ obj-$(CONFIG_SCSI_UFS_CDNS_PLATFORM) += cdns-pltfrm.o
 obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
 obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o
 obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
-ufshcd-core-y  += ufshcd.o ufs-sysfs.o
+ufshcd-core-y  += ufshcd.o ufs-sysfs.o ufsfeature.o
 ufshcd-core-$(CONFIG_SCSI_UFS_BSG) += ufs_bsg.o
 obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
 obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/scsi/ufs/ufsfeature.c b/drivers/scsi/ufs/ufsfeature.c
new file mode 100644
index ..94c6be6babd3
--- /dev/null
+++ b/drivers/scsi/ufs/ufsfeature.c
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Universal Flash Storage Feature Support
+ *
+ * Copyright (C) 2017-2018 Samsung Electronics Co., Ltd.
+ *
+ * Authors:
+ * Yongmyung Lee 
+ * Jinyoung Choi 
+ */
+
+#include "ufshcd.h"
+#include "ufsfeature.h"
+
+inline void ufsf_slave_configure(struct ufs_hba *hba,
+struct scsi_device *sdev)
+{
+   /* skip well-known LU */
+   if (sdev->lun >= UFS_UPIU_MAX_UNIT_NUM_ID)
+   return;
+
+   if (!(hba->dev_info.b_ufs_feature_sup & UFS_DEV_HPB_SUPPORT))
+   return;
+
+   atomic_inc(>ufsf.slave_conf_cnt);
+
+   wake_up(>ufsf.sdev_wait);
+}
+
+inline void ufsf_ops_prep_fn(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
+{
+   struct ufshpb_driver *ufshpb_drv;
+
+   ufshpb_drv = dev_get_drvdata(>ufsf.hpb_dev);
+
+   if (ufshpb_drv && ufshpb_drv->ufshpb_ops.prep_fn)
+   ufshpb_drv->ufshpb_ops.prep_fn(hba, lrbp);
+}
+
+inline void ufsf_ops_rsp_upiu(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
+{
+   struct ufshpb_driver *ufshpb_drv;
+
+   ufshpb_drv = dev_get_drvdata(>ufsf.hpb_dev);
+
+   if (ufshpb_drv && ufshpb_drv->ufshpb_ops.rsp_upiu)
+   ufshpb_drv->ufshpb_ops.rsp_upiu(hba, lrbp);
+}
+
+inline void ufsf_ops_reset_host(struct ufs_hba *hba)
+{
+   struct ufshpb_driver *ufshpb_drv;
+
+   ufshpb_drv = dev_get_drvdata(>ufsf.hpb_dev);
+
+   if (ufshpb_drv && ufshpb_drv->ufshpb_ops.reset_host)
+   ufshpb_drv->ufshpb_ops.reset_host(hba);
+}
+
+inline void ufsf_ops_reset(struct ufs_hba *hba)
+{
+   struct ufshpb_driver *ufshpb_drv;
+
+   ufshpb_drv = dev_get_drvdata(>ufsf.hpb_dev);
+
+   if (ufshpb_drv && ufshpb_drv->ufshpb_ops.reset)
+   ufshpb_drv->ufshpb_ops.reset(hba);
+}
+
+inline void ufsf_ops_suspend(struct ufs_hba *hba)
+{
+   struct ufshpb_driver *ufshpb_drv;
+
+   ufshpb_drv = dev_get_drvdata(>ufsf.hpb_dev);
+
+   if (ufshpb_drv && ufshpb_drv->ufshpb_ops.suspend)
+   ufshpb_drv->ufshpb_ops.suspend(hba);
+}
+
+inline void ufsf_ops_resume(struct ufs_hba *hba)
+{
+   struct ufshpb_driver *ufshpb_drv;
+
+   ufshpb_drv = dev_get_drvdata(>ufsf.hpb_dev);
+
+   if (ufshpb_drv && ufshpb_drv->ufshpb_ops.resume)
+   ufshpb_drv->ufshpb_ops.resume(hba);
+}
+
+struct device_type ufshpb_dev_type = {
+   .name = "ufshpb_device"
+};
+EXPORT_SYMBOL(ufshpb_dev_type);
+
+static int ufsf_bus_match(struct device *dev,
+struct device_driver 

Re: [PATCH 0/3] arm64: dts: imx8qxp: dtb aliases fix/update

2020-06-22 Thread Shawn Guo
On Mon, Jun 01, 2020 at 10:06:17AM +0800, peng@nxp.com wrote:
> From: Peng Fan 
> 
> Minor patchset to fix and update alias for i.MX8QXP
> 
> Peng Fan (3):
>   arm64: dts: imx8qxp: add alias for lsio MU
>   arm64: dts: imx8qxp: add i2c aliases
>   arm64: dts: imx8qxp: Add ethernet alias

Applied all, thanks.


[RFC PATCH v3 1/5] scsi: ufs: Add UFS feature related parameter

2020-06-22 Thread Daejun Park


This is a patch for parameters to be used for UFS features layer and HPB
module.

Signed-off-by: Daejun Park 
---
 drivers/scsi/ufs/ufs.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index f8ab16f30fdc..ae557b8d3eba 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -122,6 +122,7 @@ enum flag_idn {
QUERY_FLAG_IDN_WB_EN= 0x0E,
QUERY_FLAG_IDN_WB_BUFF_FLUSH_EN = 0x0F,
QUERY_FLAG_IDN_WB_BUFF_FLUSH_DURING_HIBERN8 = 0x10,
+   QUERY_FLAG_IDN_HPB_RESET= 0x11,
 };
 
 /* Attribute idn for Query requests */
@@ -195,6 +196,9 @@ enum unit_desc_param {
UNIT_DESC_PARAM_PHY_MEM_RSRC_CNT= 0x18,
UNIT_DESC_PARAM_CTX_CAPABILITIES= 0x20,
UNIT_DESC_PARAM_LARGE_UNIT_SIZE_M1  = 0x22,
+   UNIT_DESC_HPB_LU_MAX_ACTIVE_REGIONS = 0x23,
+   UNIT_DESC_HPB_LU_PIN_REGION_START_OFFSET= 0x25,
+   UNIT_DESC_HPB_LU_NUM_PIN_REGIONS= 0x27,
UNIT_DESC_PARAM_WB_BUF_ALLOC_UNITS  = 0x29,
 };
 
@@ -235,6 +239,8 @@ enum device_desc_param {
DEVICE_DESC_PARAM_PSA_MAX_DATA  = 0x25,
DEVICE_DESC_PARAM_PSA_TMT   = 0x29,
DEVICE_DESC_PARAM_PRDCT_REV = 0x2A,
+   DEVICE_DESC_PARAM_HPB_VER   = 0x40,
+   DEVICE_DESC_PARAM_HPB_CONTROL   = 0x42,
DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP   = 0x4F,
DEVICE_DESC_PARAM_WB_PRESRV_USRSPC_EN   = 0x53,
DEVICE_DESC_PARAM_WB_TYPE   = 0x54,
@@ -283,6 +289,10 @@ enum geometry_desc_param {
GEOMETRY_DESC_PARAM_ENM4_MAX_NUM_UNITS  = 0x3E,
GEOMETRY_DESC_PARAM_ENM4_CAP_ADJ_FCTR   = 0x42,
GEOMETRY_DESC_PARAM_OPT_LOG_BLK_SIZE= 0x44,
+   GEOMETRY_DESC_HPB_REGION_SIZE   = 0x48,
+   GEOMETRY_DESC_HPB_NUMBER_LU = 0x49,
+   GEOMETRY_DESC_HPB_SUBREGION_SIZE= 0x4A,
+   GEOMETRY_DESC_HPB_DEVICE_MAX_ACTIVE_REGIONS = 0x4B,
GEOMETRY_DESC_PARAM_WB_MAX_ALLOC_UNITS  = 0x4F,
GEOMETRY_DESC_PARAM_WB_MAX_WB_LUNS  = 0x53,
GEOMETRY_DESC_PARAM_WB_BUFF_CAP_ADJ = 0x54,
@@ -327,6 +337,7 @@ enum {
 
 /* Possible values for dExtendedUFSFeaturesSupport */
 enum {
+   UFS_DEV_HPB_SUPPORT = BIT(7),
UFS_DEV_WRITE_BOOSTER_SUP   = BIT(8),
 };
 
@@ -537,6 +548,7 @@ struct ufs_dev_info {
u8 *model;
u16 wspecversion;
u32 clk_gating_wait_us;
+   u8 b_ufs_feature_sup;
u32 d_ext_ufs_feature_sup;
u8 b_wb_buffer_type;
u32 d_wb_alloc_units;

base-commit: 3145550a7f8b08356c8ff29feaa6c56aca12901d
-- 
2.17.1


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

2020-06-22 Thread Alexey Kardashevskiy



On 23/06/2020 12:43, Leonardo Bras wrote:
> On Tue, 2020-06-23 at 12:35 +1000, Alexey Kardashevskiy wrote:
>>> I am not sure if this is true in general, but in this device (SR-IOV
>>> VF) I am testing it will return 0 windows if the default DMA window is
>>> not deleted, and 1 after it's deleted.
>>
>> Since pHyp can only create windows in "64bit space", now (I did not know
>> until a few month back) I expect that thing to return "1" always no
>> matter what happened to the default window. And removing the default
>> window will only affect the maximum number of TCEs but not the number of
>> possible windows.
> 
> Humm, something gone wrong then.
> 
> This patchset was developed mostly because on testing, DDW would never
> be created because windows_available would always be 0.

? On phyp, if there is a huge window, then it can be 0 or 1. On KVM, it
is 0 or 1 or 2.


> 
> I will take a deeper look in that.
> 
> Best regards,
> Leonardo
> 

-- 
Alexey


linux-next: build failure after merge of the kspp tree

2020-06-22 Thread Stephen Rothwell
Hi all,

After merging the kspp tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

net/core/devlink.c: In function 'devlink_nl_port_function_attrs_put':
net/core/devlink.c:586:3: warning: parameter names (without types) in function 
declaration
  586 |   int uninitialized_var(hw_addr_len);
  |   ^~~
net/core/devlink.c:589:65: error: 'hw_addr_len' undeclared (first use in this 
function); did you mean 'hw_addr'?
  589 |   err = ops->port_function_hw_addr_get(devlink, port, hw_addr, 
_addr_len, extack);
  | 
^~~
  | hw_addr
net/core/devlink.c:589:65: note: each undeclared identifier is reported only 
once for each function it appears in

Caused by commit

  2e6d06799c15 ("compiler: Remove uninitialized_var() macro")

interacting with commit

  2a916ecc4056 ("net/devlink: Support querying hardware address of port 
function")

from the net-next tree.

I have added the following merge fix patch.

From: Stephen Rothwell 
Date: Tue, 23 Jun 2020 13:43:06 +1000
Subject: [PATCH] net/core/devlink.c: remove new uninitialized_var() usage

Signed-off-by: Stephen Rothwell 
---
 net/core/devlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/devlink.c b/net/core/devlink.c
index 455998a57671..6ae36808c152 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -583,7 +583,7 @@ devlink_nl_port_function_attrs_put(struct sk_buff *msg, 
struct devlink_port *por
 
ops = devlink->ops;
if (ops->port_function_hw_addr_get) {
-   int uninitialized_var(hw_addr_len);
+   int hw_addr_len;
u8 hw_addr[MAX_ADDR_LEN];
 
err = ops->port_function_hw_addr_get(devlink, port, hw_addr, 
_addr_len, extack);
-- 
2.27.0

-- 
Cheers,
Stephen Rothwell


pgporbrv9iX5c.pgp
Description: OpenPGP digital signature


Re: [PATCH v3 12/14] tools/kernel.h: hide noinstr

2020-06-22 Thread kernel test robot
Hi Sasha,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc2 next-20200622]
[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/Sasha-Levin/Fix-up-liblockdep-for-5-8-rc/20200623-064735
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
dd0d718152e4c65b173070d48ea9dfc06894c3e5
config: x86_64-rhel (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 errors (new ones prefixed by >>):

   In file included from objtool.h:13,
from weak.c:10:
>> elf.h:42:37: error: expected identifier or '(' before ';' token
  42 |  bool changed, text, rodata, noinstr;
 | ^
   elf.h:43:1: error: no semicolon at end of struct or union [-Werror]
  43 | };
 | ^
   cc1: all warnings being treated as errors
   In file included from objtool.h:13,
from orc_dump.c:8:
>> elf.h:42:37: error: expected identifier or '(' before ';' token
  42 |  bool changed, text, rodata, noinstr;
 | ^
   elf.h:43:1: error: no semicolon at end of struct or union [-Werror]
  43 | };
 | ^
   In file included from objtool.h:13,
from builtin-orc.c:17:
>> elf.h:42:37: error: expected identifier or '(' before ';' token
  42 |  bool changed, text, rodata, noinstr;
 | ^
   elf.h:43:1: error: no semicolon at end of struct or union [-Werror]
  43 | };
 | ^
   In file included from objtool.h:13,
from arch.h:11,
from check.h:11,
from orc_gen.c:9:
>> elf.h:42:37: error: expected identifier or '(' before ';' token
  42 |  bool changed, text, rodata, noinstr;
 | ^
   elf.h:43:1: error: no semicolon at end of struct or union [-Werror]
  43 | };
 | ^
   In file included from orc_gen.c:9:
   check.h:18:14: error: declaration does not declare anything [-Werror]
  18 |  bool noinstr;
 |  ^
   cc1: all warnings being treated as errors
   mv: cannot stat 'tools/objtool/.weak.o.tmp': No such file or directory
   make[4]: *** [tools/build/Makefile.build:97: tools/objtool/weak.o] Error 1
   make[4]: *** Waiting for unfinished jobs
   In file included from objtool.h:13,
from builtin-check.c:19:
>> elf.h:42:37: error: expected identifier or '(' before ';' token
  42 |  bool changed, text, rodata, noinstr;
 | ^
   elf.h:43:1: error: no semicolon at end of struct or union [-Werror]
  43 | };
 | ^
   In file included from objtool.h:13,
from arch.h:11,
from check.c:11:
>> elf.h:42:37: error: expected identifier or '(' before ';' token
  42 |  bool changed, text, rodata, noinstr;
 | ^
   elf.h:43:1: error: no semicolon at end of struct or union [-Werror]
  43 | };
 | ^
   In file included from special.h:10,
from special.c:15:
>> elf.h:42:37: error: expected identifier or '(' before ';' token
  42 |  bool changed, text, rodata, noinstr;
 | ^
   elf.h:43:1: error: no semicolon at end of struct or union [-Werror]
  43 | };
 | ^
   In file included from check.c:12:
   check.h:18:14: error: declaration does not declare anything [-Werror]
  18 |  bool noinstr;
 |  ^
   cc1: all warnings being treated as errors
   mv: cannot stat 'tools/objtool/.builtin-orc.o.tmp': No such file or directory
   In file included from elf.c:20:
>> elf.h:42:37: error: expected identifier or '(' before ';' token
  42 |  bool changed, text, rodata, noinstr;
 | ^
   elf.h:43:1: error: no semicolon at end of struct or union [-Werror]
  43 | };
 | ^
   make[4]: *** [tools/build/Makefile.build:97: tools/objtool/builtin-orc.o] 
Error 1
   cc1: all warnings being treated as errors
   mv: cannot stat 'tools/objtool/.builtin-check.o.tmp': No such file or 
directory
   make[4]: *** [tools/build/Makefile.build:97: tools/objtool/builtin-check.o] 
Error 1
   mv: cannot stat 'tools/objtool/.orc_gen.o.tmp': No such file or directory
   cc1: all warnings being treated as errors
   make[4]: *** [tools/build/Makefile.build:97: tools/objtool/orc_gen.o] Error 1
   cc1: a

Re: [PATCH] Fix check in ethtool_rx_flow_rule_create

2020-06-22 Thread David Miller
From: Gaurav Singh 
Date: Sun, 21 Jun 2020 11:30:17 -0400

> Fix check in ethtool_rx_flow_rule_create
> 
> Signed-off-by: Gaurav Singh 

Applied and queued up for -stable with the following Fixes: tag added:

Fixes: eca4205f9ec3 ("ethtool: add ethtool_rx_flow_spec to flow_rule structure 
translator")

Thank you.


Re: [PATCH] ARM: dts: imx6qdl-gw54xx: allow boot firmware to set eth1 MAC

2020-06-22 Thread Shawn Guo
On Thu, May 28, 2020 at 12:53:16PM -0700, Tim Harvey wrote:
> The GW54xx has a PCIe based GbE as the 2nd ethernet device. The
> boot firmware will populate the local-mac-address field of the
> device aliased to ethernet1 thus adding the PCIe device to
> dt allows boot firmware to set its MAC address.
> 
> Signed-off-by: Tim Harvey 

Applied, thanks.


Re: [PATCH] ARM: dts: imx6qdl-gw53xx: allow boot firmware to set eth1 MAC

2020-06-22 Thread Shawn Guo
On Thu, May 28, 2020 at 12:53:03PM -0700, Tim Harvey wrote:
> The GW53xx has a PCIe based GbE as the 2nd ethernet device. The
> boot firmware will populate the local-mac-address field of the
> device aliased to ethernet1 thus adding the PCIe device to
> dt allows boot firmware to set its MAC address.
> 
> Signed-off-by: Tim Harvey 

Applied, thanks.


RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as module

2020-06-22 Thread Aisheng Dong
> From: Stephen Boyd 
> Sent: Saturday, June 20, 2020 11:28 AM
> Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as
> module
> 
> Quoting Aisheng Dong (2020-06-17 18:58:51)
> > > From: Anson Huang 
> > > > > +obj-$(CONFIG_MXC_CLK_SCU) += mxc-clk-scu.o
> > > >
> > > > Like i.MX pinctrl, I'm not sure if it's really necessary to build
> > > > core libraries as modules. Probably the simplest way is only
> > > > building platform drivers part as module. And leave those core libraries
> built in kernel.
> > > > This may make the code a bit cleaner.
> > > >
> > >
> > > Will discuss this with Linaro guys about it, previous requirement I
> > > received is all SoC specific modules need to be built as module.
> > >
> >
> > Okay. AFAIK it's not conflict.
> > You still make drivers into modules.
> > Only difference is for those common libraries part, we don't convert
> > them into module Which is less meaningless.
> >
> 
> What is the benefit of making the core part of the SoC driver not a module?

Usually we could try to build it as module if it's not hard.

One question is sometimes those core part are shared with some platforms which 
can't built as module.
For i.MX case, it's mainly patch 4:
[V2,4/9] clk: imx: Support building i.MX common clock driver as module
https://patchwork.kernel.org/patch/11594801/

Those libraries are also used by i.MX6&7 which can't build as module.
So we need an extra workaround patch to forcely 'select' it under 
arch/arm/mach-imx/Kconfig
[V2,2/9] ARM: imx: Select MXC_CLK for ARCH_MXC
https://patchwork.kernel.org/patch/11594793/
Then the users can't configure it as module in order to not break build.

If build-in those common libraries, the implementation could be a bit easier 
and cleaner.
So I'm not sure if we still have to build them as module.
How would you suggest for such case?

> From the module perspective it should be perfectly fine to make it a module as
> well, and then depmod will sort out loading modules in the right order.
> 
> This is for android right?

Yes, for Android GKI support.

Regards
Aisheng


[PATCH] [net/decnet] dn_route_rcv: remove redundant dev null check

2020-06-22 Thread Gaurav Singh
dev cannot be NULL here since its already being accessed
before. Remove the redundant null check.

Signed-off-by: Gaurav Singh 
---
 net/decnet/dn_route.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index 06b9983325cc..9eb7e4b62d9b 100644
--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -670,7 +670,7 @@ int dn_route_rcv(struct sk_buff *skb, struct net_device 
*dev, struct packet_type
if (decnet_debug_level & 1)
printk(KERN_DEBUG
"dn_route_rcv: got 0x%02x from %s [%d %d %d]\n",
-   (int)flags, (dev) ? dev->name : "???", len, skb->len,
+   (int)flags, dev->name, len, skb->len,
padlen);
 
if (flags & DN_RT_PKT_CNTL) {
-- 
2.17.1



Re: [PATCH 2/2] ARM: dts: Change WDOG_ANY signal from push-pull to open-drain

2020-06-22 Thread Shawn Guo
On Thu, May 28, 2020 at 02:43:43PM +, Schrempf Frieder wrote:
> From: Frieder Schrempf 
> 
> The WDOG_ANY signal is connected to the RESET_IN signal of the SoM
> and baseboard. It is currently configured as push-pull, which means
> that if some external device like a programmer wants to assert the
> RESET_IN signal by pulling it to ground, it drives against the high
> level WDOG_ANY output of the SoC.
> 
> To fix this we set the WDOG_ANY signal to open-drain configuration.
> That way we make sure that the RESET_IN can be asserted by the
> watchdog as well as by external devices.
> 
> Fixes: 1ea4b76cdfde ("ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL 
> N6310 SoM and boards")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Frieder Schrempf 

Added 'imx6ul-kontron:' to subject and applied both patches.

Shawn


Re: [PATCH 02/17] sparc64: enable HAVE_COPY_THREAD_TLS

2020-06-22 Thread David Miller
From: Christian Brauner 
Date: Tue, 23 Jun 2020 01:43:11 +0200

> diff --git a/arch/sparc/kernel/syscalls.S b/arch/sparc/kernel/syscalls.S
> index db42b4fb3708..192f3a28a2b7 100644
> --- a/arch/sparc/kernel/syscalls.S
> +++ b/arch/sparc/kernel/syscalls.S
> @@ -86,19 +86,22 @@ sys32_rt_sigreturn:
>* during system calls...
>*/
>   .align  32
> -sys_vfork: /* Under Linux, vfork and fork are just special cases of clone. */
> - sethi   %hi(0x4000 | 0x0100 | SIGCHLD), %o0
> - or  %o0, %lo(0x4000 | 0x0100 | SIGCHLD), %o0
> - ba,pt   %xcc, sys_clone
> +sys_vfork:
> + flushw
> + ba,pt   %xcc, sparc_vfork
> + add %sp, PTREGS_OFF, %o0

Please indent branch delay slot instructions with one extra space, as
was done in the code you are changing.

> + ba,pt   %xcc, sparc_fork
> + add %sp, PTREGS_OFF, %o0

Likewise.

> + ba,pt   %xcc, sparc_clone
> + add %sp, PTREGS_OFF, %o0

Likewise.


Re: [PATCH v16 00/11] Mediatek MT8183 scpsys support

2020-06-22 Thread Weiyi Lu
On Wed, 2020-06-17 at 15:05 +0800, Weiyi Lu wrote:
> This series is based on v5.8-rc1
> 

Hi Matthias,

Gentle ping. Many thanks.

> change since v15:
> - remove unneeded error log in [PATCH 06/11]
> 
> changes since v14:
> - fix commit message typo
> - use property name "mediatek,smi" for smi phandle
> 
> changes since v13:
> - document optional property "smi-comm"
> - move defines in scpsyc.h to mtk-scpsys.c directly
> - minor coding sytle fixes
> 
> change since v12:
> - separate the fix of comma at the end into a new patch [PATCH 09/11]
> 
> changes since v11:
> - re-order patches "Remove infracfg misc driver support" and "Add multiple 
> step bus protection"
> - add cap MTK_SCPD_SRAM_ISO for extra sram control
> - minor coding sytle fixes and reword commit messages
> 
> changes since v10:
> - squash PATCH 04 and PATCH 06 in v9 into its previous patch
> - add "ignore_clr_ack" for multiple step bus protection control to have a 
> clean definition of power domain data
> - keep the mask register bit definitions and do the same for MT8183
> 
> changes since v9:
> - add new PATCH 04 and PATCH 06 to replace by new method for all compatibles
> - add new PATCH 07 to remove infracfg misc driver
> - minor coding sytle fix
> 
> changes since v7:
> - reword in binding document [PATCH 02/14]
> - fix error return checking bug in subsys clock control [PATCH 10/14]
> - add power domains properity to mfgcfg patch [PATCH 14/14] from
>   https://patchwork.kernel.org/patch/11126199/
> 
> changes since v6:
> - remove the patch of SPDX license identifier because it's already fixed
> 
> changes since v5:
> - fix documentation in [PATCH 04/14]
> - remove useless variable checking and reuse API of clock control in [PATCH 
> 06/14]
> - coding style fix of bus protection control in [PATCH 08/14]
> - fix naming of new added data in [PATCH 09/14]
> - small refactor of multiple step bus protection control in [PATCH 10/14]
> 
> changes since v4:
> - add property to mt8183 smi-common
> - seperate refactor patches and new add function
> - add power controller device node
> 
> 
> Weiyi Lu (11):
>   dt-bindings: mediatek: Add property to mt8183 smi-common
>   dt-bindings: soc: Add MT8183 power dt-bindings
>   soc: mediatek: Add basic_clk_name to scp_power_data
>   soc: mediatek: Remove infracfg misc driver support
>   soc: mediatek: Add multiple step bus protection control
>   soc: mediatek: Add subsys clock control for bus protection
>   soc: mediatek: Add extra sram control
>   soc: mediatek: Add MT8183 scpsys support
>   soc: mediatek: Add a comma at the end
>   arm64: dts: Add power controller device node of MT8183
>   arm64: dts: Add power-domains property to mfgcfg
> 
>  .../mediatek,smi-common.txt   |   2 +-
>  .../bindings/soc/mediatek/scpsys.txt  |  21 +-
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi  |  63 ++
>  drivers/soc/mediatek/Kconfig  |  10 -
>  drivers/soc/mediatek/Makefile |   1 -
>  drivers/soc/mediatek/mtk-infracfg.c   |  79 --
>  drivers/soc/mediatek/mtk-scpsys.c | 704 ++
>  include/dt-bindings/power/mt8183-power.h  |  26 +
>  include/linux/soc/mediatek/infracfg.h |  39 -
>  9 files changed, 669 insertions(+), 276 deletions(-)
>  delete mode 100644 drivers/soc/mediatek/mtk-infracfg.c
>  create mode 100644 include/dt-bindings/power/mt8183-power.h
>  delete mode 100644 include/linux/soc/mediatek/infracfg.h
> 



[PATCH v2] kernel/fork.c: annotate data races for copy_process

2020-06-22 Thread Weilong Chen
KCSAN report there's a data race risk while using nr_threads.
But according to the comment above it:
'
/*
 * If multiple threads are within copy_process(), then this check
 * triggers too late. This doesn't hurt, the check is only there
 * to stop root fork bombs.
 */
'
The concurrency problem is not care. And we needn't to use READ_ONCE/atomic/etc
to protect it. Meanwhile 'max_threads' is a sysctl variable which can
be modified concurrently while being read, we can use
'data_race(nr_threads >= max_threads)' to mark both of then.

BUG: KCSAN: data-race in copy_process / copy_process

write to 0x86205cf8 of 4 bytes by task 14779 on cpu 1:
  copy_process+0x2eba/0x3c40 kernel/fork.c:2273
  _do_fork+0xfe/0x7a0 kernel/fork.c:2421
  __do_sys_clone kernel/fork.c:2576 [inline]
  __se_sys_clone kernel/fork.c:2557 [inline]
  __x64_sys_clone+0x130/0x170 kernel/fork.c:2557
  do_syscall_64+0xcc/0x3a0 arch/x86/entry/common.c:294
  entry_SYSCALL_64_after_hwframe+0x44/0xa9

read to 0x86205cf8 of 4 bytes by task 6944 on cpu 0:
  copy_process+0x94d/0x3c40 kernel/fork.c:1954
  _do_fork+0xfe/0x7a0 kernel/fork.c:2421
  __do_sys_clone kernel/fork.c:2576 [inline]
  __se_sys_clone kernel/fork.c:2557 [inline]
  __x64_sys_clone+0x130/0x170 kernel/fork.c:2557
  do_syscall_64+0xcc/0x3a0 arch/x86/entry/common.c:294
  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Link: https://groups.google.com/forum/#!msg/syzkaller-upstream-mo
deration/thvp7AHs5Ew/aPdYLXfYBQAJ

Reported-by: syzbot+52fced2d288f8ecd2...@syzkaller.appspotmail.com
Cc: Qian Cai 
Cc: Oleg Nesterov 
Cc: Christian Brauner 
Cc: Marco Elver 
Signed-off-by: Zefan Li 
Signed-off-by: Weilong Chen 
---
 kernel/fork.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index 63c8fb2f5ca7..caa9c1f27444 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1976,7 +1976,7 @@ static __latent_entropy struct task_struct *copy_process(
 * to stop root fork bombs.
 */
retval = -EAGAIN;
-   if (nr_threads >= max_threads)
+   if (data_race(nr_threads >= max_threads))
goto bad_fork_cleanup_count;
 
delayacct_tsk_init(p);  /* Must remain after dup_task_struct() */
-- 
2.17.1



[tip:x86/cleanups] BUILD SUCCESS 99e40204e014e06644072c39001a269d9689e0d1

2020-06-22 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
x86/cleanups
branch HEAD: 99e40204e014e06644072c39001a269d9689e0d1  x86/msr: Move the F15h 
MSRs where they belong

elapsed time: 722m

configs tested: 127
configs skipped: 48

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
nds32alldefconfig
mips mpc30x_defconfig
armdove_defconfig
arm  lpd270_defconfig
arm   corgi_defconfig
armrealview_defconfig
xtensa   allyesconfig
armmmp2_defconfig
mipsmalta_kvm_guest_defconfig
arm s3c6400_defconfig
xtensa   alldefconfig
sh  sh7785lcr_32bit_defconfig
parisc   alldefconfig
mipsmalta_qemu_32r6_defconfig
arcvdk_hs38_smp_defconfig
arm   netwinder_defconfig
mips  ath79_defconfig
sh   se7724_defconfig
powerpc64   defconfig
arm   versatile_defconfig
armmulti_v5_defconfig
ia64 allyesconfig
xtensaxip_kc705_defconfig
armkeystone_defconfig
m68kmac_defconfig
sh   sh2007_defconfig
arm   efm32_defconfig
m68k alldefconfig
m68k apollo_defconfig
powerpc pseries_defconfig
shsh7785lcr_defconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
h8300allyesconfig
h8300allmodconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a004-20200622
x86_64   randconfig-a002-20200622
x86_64   randconfig-a003-20200622
x86_64   randconfig-a005-20200622
x86_64   randconfig-a001-20200622
x86_64   randconfig-a006-20200622
i386 randconfig-a006-20200622
i386 randconfig-a002-20200622
i386 randconfig-a003-20200622
i386 randconfig-a001-20200622
i386 randconfig-a005-20200622
i386 randconfig-a004-20200622
i386 randconfig-a013-20200622
i386 randconfig-a016-20200622
i386 randconfig-a012-20200622
i386 randconfig-a014-20200622
i386 randconfig-a015-20200622
i386 randconfig-a011-20200622

[PATCH] net: qrtr: free flow in __qrtr_node_release

2020-06-22 Thread Carl Huang
The flow is allocated in qrtr_tx_wait, but not freed when qrtr node
is released. (*slot) becomes NULL after radix_tree_iter_delete is
called in __qrtr_node_release. The fix is to save (*slot) to a
vairable and then free it.

This memory leak is catched when kmemleak is enabled in kernel,
the report looks like below:

unreferenced object 0xa0de69e08420 (size 32):
  comm "kworker/u16:3", pid 176, jiffies 4294918275 (age 82858.876s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 28 84 e0 69 de a0 ff ff  (..i
28 84 e0 69 de a0 ff ff 03 00 00 00 00 00 00 00  (..i
  backtrace:
[] qrtr_node_enqueue+0x38e/0x400 [qrtr]
[<9cea437f>] qrtr_sendmsg+0x1e0/0x2a0 [qrtr]
[<8bddbba4>] sock_sendmsg+0x5b/0x60
[<03beb43a>] qmi_send_message.isra.3+0xbe/0x110 [qmi_helpers]
[<9c9ae7de>] qmi_send_request+0x1c/0x20 [qmi_helpers]

Signed-off-by: Carl Huang 
---
 net/qrtr/qrtr.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
index 2d8d613..1855857 100644
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -168,6 +168,7 @@ static void __qrtr_node_release(struct kref *kref)
struct radix_tree_iter iter;
unsigned long flags;
void __rcu **slot;
+   struct qrtr_tx_flow *flow;
 
spin_lock_irqsave(_nodes_lock, flags);
if (node->nid != QRTR_EP_NID_AUTO)
@@ -181,8 +182,9 @@ static void __qrtr_node_release(struct kref *kref)
 
/* Free tx flow counters */
radix_tree_for_each_slot(slot, >qrtr_tx_flow, , 0) {
+   flow = *slot;
radix_tree_iter_delete(>qrtr_tx_flow, , slot);
-   kfree(*slot);
+   kfree(flow);
}
kfree(node);
 }
-- 
2.7.4



RE: [PATCH 0/3] Use MFD for Dallas/Maxim DS1374 driver series

2020-06-22 Thread 陳昭勳
Hi, 
> 
> Hi,
> 
> On 22/06/2020 10:03:25+, Johnson CH Chen (陳昭勳) wrote:
> > Hello all,
> >
> > This patch set uses MFD structure for DS1374 so that RTC and Watchdog
> > functions can be separately. Therefore, we can add more Watchdog
> > subfunctions here.
> >
> > A DS1374 MFD core driver supports the I2C communication to RTC and
> > Watchdog devices.
> >
> > 1. Add DS1374 MFD core driver with I2C bus.
> > 2. Let DS1374 RTC driver has RTC and Alarm functions only.
> > 3. Add DS1374 Watchdog driver.
> >
> 
> For reference, this was the last attempt:
> 
> https://lore.kernel.org/linux-rtc/20170718092245.tc5oosbbb6lzvqpy@dell/
> 
> The main issue I see with your series is that there is no way to select which 
> of
> the rtc or the watchdog driver has to be used as IIRC each function is 
> mutually
> exclusive. I think you should work on the DT bindings, addressing the few
> remaining comments.
> 
Thanks for your review and good suggestion! 
Usage of rtc and watchdog should be defined in DT binding if we want to keep 
them separate.

I'll work towards these later.

> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Best regards,
Johnson


Re: [PATCH v7 8/8] block: create the request_queue debugfs_dir on registration

2020-06-22 Thread Bart Van Assche
On 2020-06-22 05:42, Luis Chamberlain wrote:
> On Sat, Jun 20, 2020 at 11:07:43AM -0700, Bart Van Assche wrote:
>> On 2020-06-19 13:47, Luis Chamberlain wrote:
>>> We were only creating the request_queue debugfs_dir only
>>> for make_request block drivers (multiqueue), but never for
>>> request-based block drivers. We did this as we were only
>>> creating non-blktrace additional debugfs files on that directory
>>> for make_request drivers. However, since blktrace *always* creates
>>> that directory anyway, we special-case the use of that directory
>>> on blktrace. Other than this being an eye-sore, this exposes
>>> request-based block drivers to the same debugfs fragile
>>> race that used to exist with make_request block drivers
>>> where if we start adding files onto that directory we can later
>>> run a race with a double removal of dentries on the directory
>>> if we don't deal with this carefully on blktrace.
>>>
>>> Instead, just simplify things by always creating the request_queue
>>> debugfs_dir on request_queue registration. Rename the mutex also to
>>> reflect the fact that this is used outside of the blktrace context.
>>
>> There are two changes in this patch: a bug fix and a rename of a mutex.
>> I don't like it to see two changes in a single patch.
> 
> I thought about doing the split first, and I did it at first, but
> then I could hear Christoph yelling at me for it. So I merged the
> two together. Although it makes it more difficult for review,
> the changes do go together.

During the past weeks I have been more busy than usual. I will try to
make sure that in the future I have the time to read all comments on the
previous versions of a patch series before replying to the latest
version of a patch series.

>> Additionally, is the new mutex name really better than the old name? The
>> proper way to use mutexes is to use mutexes to protect data instead of
>> code. Where is the documentation that mentions which member variable(s)
>> of which data structures are protected by the mutex formerly called
>> blk_trace_mutex?
> 
> It does not exist, and that is the point. The debugfs_dir use after
> free showed us *when* that UAF can happen, and so care must be taken
> if we are to use the mutex to protect the debugfs_dir but also re-use
> the same directory for other block core shenanigans.
> 
>> Since the new name makes it even less clear which data
>> is protected by this mutex, is the new name really better than the old name?
> 
> I thought the new name makes it crystal clear what is being protected. I
> can however add a comment to explain that the q->debugfs_mutex protects
> the q->debugfs_dir if it is created, otherwise it protects the ephemeral
> debugfs_dir directory which would otherwise be created in lieue of
> q->debugfs_dir, however the patch still lies under /block/.
> 
> Let me know if you think that will help.

My concern is that q->debugfs_mutex would evolve the same way as
q->sysfs_lock: at the time of introduction the role of a mutex is very
clear but over time the number of use cases grows to a point where it is
no longer possible to recognize the original purpose. I think there are
two possible approaches: either a comment is added now that explains the
role of q->debugfs_mutex or someone who has followed this conversation
yells when someone tries to use q->debugfs_mutex for another purpose
than what it was intended for.

Thanks,

Bart.



Re: [PATCH 5.7] x86/crypto: aesni: Fix build with LLVM_IAS=1

2020-06-22 Thread Sedat Dilek
On Mon, Jun 22, 2020 at 10:33 PM Nick Desaulniers
 wrote:
>
> On Mon, Jun 22, 2020 at 8:50 AM Sedat Dilek  wrote:
> >
> > When building with LLVM_IAS=1 means using Clang's Integrated Assembly (IAS)
> > from LLVM/Clang >= v10.0.1-rc1+ instead of GNU/as from GNU/binutils
> > I see the following breakage in Debian/testing AMD64:
> >
> > :15:74: error: too many positional arguments
> >  PRECOMPUTE 8*3+8(%rsp), %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7,
> >  ^
> >  arch/x86/crypto/aesni-intel_asm.S:1598:2: note: while in macro 
> > instantiation
> >  GCM_INIT %r9, 8*3 +8(%rsp), 8*3 +16(%rsp), 8*3 +24(%rsp)
> >  ^
> > :47:2: error: unknown use of instruction mnemonic without a 
> > size suffix
> >  GHASH_4_ENCRYPT_4_PARALLEL_dec %xmm9, %xmm10, %xmm11, %xmm12, %xmm13, 
> > %xmm14, %xmm0, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7, %xmm8, enc
> >  ^
> > arch/x86/crypto/aesni-intel_asm.S:1599:2: note: while in macro instantiation
> >  GCM_ENC_DEC dec
> >  ^
> > :15:74: error: too many positional arguments
> >  PRECOMPUTE 8*3+8(%rsp), %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7,
> >  ^
> > arch/x86/crypto/aesni-intel_asm.S:1686:2: note: while in macro instantiation
> >  GCM_INIT %r9, 8*3 +8(%rsp), 8*3 +16(%rsp), 8*3 +24(%rsp)
> >  ^
> > :47:2: error: unknown use of instruction mnemonic without a 
> > size suffix
> >  GHASH_4_ENCRYPT_4_PARALLEL_enc %xmm9, %xmm10, %xmm11, %xmm12, %xmm13, 
> > %xmm14, %xmm0, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7, %xmm8, enc
> >  ^
> > arch/x86/crypto/aesni-intel_asm.S:1687:2: note: while in macro instantiation
> >  GCM_ENC_DEC enc
>
> === I think from here to...
>
>
> >
> > Craig Topper suggested me in ClangBuiltLinux issue #1050:
> >
> > > I think the "too many positional arguments" is because the parser isn't 
> > > able
> > > to handle the trailing commas.
> > >
> > > The "unknown use of instruction mnemonic" is because the macro was named
> > > GHASH_4_ENCRYPT_4_PARALLEL_DEC but its being instantiated with
> > > GHASH_4_ENCRYPT_4_PARALLEL_dec I guess gas ignores case on the
> > > macro instantiation, but llvm doesn't.
>
> Yep, see also:
> commit 6f5459da2b87 ("arm64: alternative: fix build with clang
> integrated assembler")
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6f5459da2b8736720afdbd67c4bd2d1edba7d0e3
>
> >
> > First, I removed the trailing comma in the PRECOMPUTE line.
> >
> > Second, I substituted:
> > 1. GCM_ENC_DEC dec -> GCM_ENC_DEC DEC
> > 2. GCM_ENC_DEC enc -> GCM_ENC_DEC ENC
> >
> > With these changes I was able to build with LLVM_IAS=1 and boot on bare 
> > metal.
> >
> > As llvm-toolchain I used v10.0.1-rc1+ and v11.0.0-git pre-releases:
> > 1. release/10.x Git: 2dc664d578f0e9c8ea5975eed745e322fa77bffe
> > 2.   master Git: 8da5b9083691b557f50f72ab099598bb291aec5f (default)
> >
> > Just for the sake of completeness:
> > 1. CONFIG_DEBUG_INFO_DWARF4=y
> > 2. OBJDUMP=llvm-objdump (passed to my make-line)
> >
> > Please have a look into "llvm.rst" kernel-doc for further informations and
> > how to pass LLVM kbuild-options to your make-line.
> >
> > I confirmed that this works with Linux-kernel v5.7.3 and v5.7.5 final.
> >
> > NOTE: This patch is on top of Linux v5.7 final.
> >
> > Thanks to Craig and the folks from the ClangBuiltLinux project.
>
> ===...here can be cut out from the commit message.
>
> >
> > Cc: Craig Topper 
> > Cc: Craig Topper 
>
> I'd pick one or the other email addresses, and just use that one.
> Craig seems to commit to LLVM with craig.top...@intel.com, so I
> recommend that one.
>
> > Cc: Nick Desaulniers ndesaulni...@google.com
>
> Thanks for the explicit CC, though I do monitor the below list actively.
>
> > Cc: "ClangBuiltLinux" 
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1050
> > Link: 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild/llvm.rst
>
> ^ probably don't need that link either.
>
> >
> > ---
> >  arch/x86/crypto/aesni-intel_asm.S | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/x86/crypto/aesni-intel_asm.S 
> > b/arch/x86/crypto/aesni-intel_asm.S
> > index cad6e1bfa7d5..983eb2eec51a 100644
> > --- a/arch/x86/crypto/aesni-intel_asm.S
> > +++ b/arch/x86/crypto/aesni-intel_asm.S
> > @@ -266,7 +266,7 @@ ALL_F:  .octa 0x
> > PSHUFB_XMM %xmm2, %xmm0
> > movdqu %xmm0, CurCount(%arg2) # ctx_data.current_counter = iv
> >
> > -   PRECOMPUTE \SUBKEY, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7,
> > +   PRECOMPUTE \SUBKEY, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7
> > movdqu HashKey(%arg2), %xmm13
> >
> > CALC_AAD_HASH %xmm13, \AAD, \AADLEN, %xmm0, %xmm1, %xmm2, %xmm3, \
>
>
> There's a comparison on L386
>  386 .ifc \operation, dec
> Also, L407, 

[PATCH 5.7 v3] x86/crypto: aesni: Fix build with LLVM_IAS=1

2020-06-22 Thread Sedat Dilek
When building with LLVM_IAS=1 means using Clang's Integrated Assembly (IAS)
from LLVM/Clang >= v10.0.1-rc1+ instead of GNU/as from GNU/binutils
I see the following breakage in Debian/testing AMD64:

:15:74: error: too many positional arguments
 PRECOMPUTE 8*3+8(%rsp), %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7,
 ^
 arch/x86/crypto/aesni-intel_asm.S:1598:2: note: while in macro instantiation
 GCM_INIT %r9, 8*3 +8(%rsp), 8*3 +16(%rsp), 8*3 +24(%rsp)
 ^
:47:2: error: unknown use of instruction mnemonic without a size 
suffix
 GHASH_4_ENCRYPT_4_PARALLEL_dec %xmm9, %xmm10, %xmm11, %xmm12, %xmm13, %xmm14, 
%xmm0, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7, %xmm8, enc
 ^
arch/x86/crypto/aesni-intel_asm.S:1599:2: note: while in macro instantiation
 GCM_ENC_DEC dec
 ^
:15:74: error: too many positional arguments
 PRECOMPUTE 8*3+8(%rsp), %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7,
 ^
arch/x86/crypto/aesni-intel_asm.S:1686:2: note: while in macro instantiation
 GCM_INIT %r9, 8*3 +8(%rsp), 8*3 +16(%rsp), 8*3 +24(%rsp)
 ^
:47:2: error: unknown use of instruction mnemonic without a size 
suffix
 GHASH_4_ENCRYPT_4_PARALLEL_enc %xmm9, %xmm10, %xmm11, %xmm12, %xmm13, %xmm14, 
%xmm0, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7, %xmm8, enc
 ^
arch/x86/crypto/aesni-intel_asm.S:1687:2: note: while in macro instantiation
 GCM_ENC_DEC enc

Craig Topper suggested me in ClangBuiltLinux issue #1050:

> I think the "too many positional arguments" is because the parser isn't able
> to handle the trailing commas.
>
> The "unknown use of instruction mnemonic" is because the macro was named
> GHASH_4_ENCRYPT_4_PARALLEL_DEC but its being instantiated with
> GHASH_4_ENCRYPT_4_PARALLEL_dec I guess gas ignores case on the
> macro instantiation, but llvm doesn't.

First, I removed the trailing comma in the PRECOMPUTE line.

Second, I substituted:
1. GHASH_4_ENCRYPT_4_PARALLEL_DEC -> GHASH_4_ENCRYPT_4_PARALLEL_dec
2. GHASH_4_ENCRYPT_4_PARALLEL_ENC -> GHASH_4_ENCRYPT_4_PARALLEL_enc

With these changes I was able to build with LLVM_IAS=1 and boot on bare metal.

I confirmed that this works with Linux-kernel v5.7.5 final.

NOTE: This patch is on top of Linux v5.7 final.

Thanks to Craig and especially Nick for double-checking and his comments.

Suggested-by: Craig Topper 
Suggested-by: Craig Topper 
Suggested-by: Nick Desaulniers ndesaulni...@google.com
Cc: "ClangBuiltLinux" 
Link: https://github.com/ClangBuiltLinux/linux/issues/1050
Signed-off-by: Sedat Dilek 
---
Changes v2->v3:
- Add this Changelog

Changes v1->v2:
- Replace Cc by Suggested-by for Craig
- Replace Cc by Suggested-by for Nick (dropped Cc as desired)
- Really follow the suggestions of Craig
- Drop unneeded comments for my build-environment and Links

 arch/x86/crypto/aesni-intel_asm.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index cad6e1bfa7d5..c216de287742 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -266,7 +266,7 @@ ALL_F:  .octa 0x
PSHUFB_XMM %xmm2, %xmm0
movdqu %xmm0, CurCount(%arg2) # ctx_data.current_counter = iv
 
-   PRECOMPUTE \SUBKEY, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7,
+   PRECOMPUTE \SUBKEY, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7
movdqu HashKey(%arg2), %xmm13
 
CALC_AAD_HASH %xmm13, \AAD, \AADLEN, %xmm0, %xmm1, %xmm2, %xmm3, \
@@ -978,7 +978,7 @@ _initial_blocks_done\@:
 * arg1, %arg3, %arg4 are used as pointers only, not modified
 * %r11 is the data offset value
 */
-.macro GHASH_4_ENCRYPT_4_PARALLEL_ENC TMP1 TMP2 TMP3 TMP4 TMP5 \
+.macro GHASH_4_ENCRYPT_4_PARALLEL_enc TMP1 TMP2 TMP3 TMP4 TMP5 \
 TMP6 XMM0 XMM1 XMM2 XMM3 XMM4 XMM5 XMM6 XMM7 XMM8 operation
 
movdqa\XMM1, \XMM5
@@ -1186,7 +1186,7 @@ aes_loop_par_enc_done\@:
 * arg1, %arg3, %arg4 are used as pointers only, not modified
 * %r11 is the data offset value
 */
-.macro GHASH_4_ENCRYPT_4_PARALLEL_DEC TMP1 TMP2 TMP3 TMP4 TMP5 \
+.macro GHASH_4_ENCRYPT_4_PARALLEL_dec TMP1 TMP2 TMP3 TMP4 TMP5 \
 TMP6 XMM0 XMM1 XMM2 XMM3 XMM4 XMM5 XMM6 XMM7 XMM8 operation
 
movdqa\XMM1, \XMM5
-- 
2.27.0



[PATCH v2] GUE: Fix a typo

2020-06-22 Thread Aiden Leong
Fix a typo in gue.h

Signed-off-by: Aiden Leong 
---
 include/net/gue.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/gue.h b/include/net/gue.h
index 3a6595bfa641..e42402f180b7 100644
--- a/include/net/gue.h
+++ b/include/net/gue.h
@@ -21,7 +21,7 @@
  * |   |
  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *
- * C bit indicates contol message when set, data message when unset.
+ * C bit indicates control message when set, data message when unset.
  * For a control message, proto/ctype is interpreted as a type of
  * control message. For data messages, proto/ctype is the IP protocol
  * of the next header.
-- 
2.25.1



  1   2   3   4   5   6   7   8   9   10   >