Re: 回复: INFO: rcu detected stall in tc_modify_qdisc

[Dmitry Vyukov]

On Wed, Jul 29, 2020 at 9:13 PM Vinicius Costa Gomes
 wrote:
>
> Hi,
>
> "Zhang, Qiang"  writes:
>
> > 
> > 发件人: linux-kernel-ow...@vger.kernel.org 
> >  代表 syzbot 
> > 
> > 发送时间: 2020年7月29日 13:53
> > 收件人: da...@davemloft.net; fweis...@gmail.com; j...@mojatatu.com; 
> > j...@resnulli.us; linux-kernel@vger.kernel.org; mi...@kernel.org; 
> > net...@vger.kernel.org; syzkaller-b...@googlegroups.com; 
> > t...@linutronix.de; vinicius.go...@intel.com; xiyou.wangc...@gmail.com
> > 主题: INFO: rcu detected stall in tc_modify_qdisc
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:181964e6 fix a braino in cmsghdr_from_user_compat_to_kern()
> > git tree:   net
> > console output: https://syzkaller.appspot.com/x/log.txt?x=12925e3890
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267
> > dashboard link: https://syzkaller.appspot.com/bug?extid=9f78d5c664a8c33f4cce
> > compiler:   gcc (GCC) 10.1.0-syz 20200507
> > syz repro:
> > https://syzkaller.appspot.com/x/repro.syz?x=16587f8c90
>
> It seems that syzkaller is generating an schedule with too small
> intervals (3ns in this case) which causes a hrtimer busy-loop which
> starves other kernel threads.
>
> We could put some limits on the interval when running in software mode,
> but I don't like this too much, because we are talking about users with
> CAP_NET_ADMIN and they have easier ways to do bad things to the system.

Hi Vinicius,

Could you explain why you don't like the argument if it's for CAP_NET_ADMIN?
Good code should check arguments regardless I think and it's useful to
protect root from, say, programming bugs rather than kill the machine
on any bug and misconfiguration. What am I missing?

Also are we talking about CAP_NET_ADMIN in a user ns as well
(effectively nobody)?

Re: [PATCH v2] checkpatch: Fix the usage of capture group ( ... )

[Lukas Bulwahn]

On Tue, 14 Jul 2020, Mrinal Pandey wrote:

> The usage of "capture group (...)" in the immediate condition after `&&`
> results in `$1` being uninitialized. This issues a warning "Use of
> uninitialized value $1 in regexp compilation at ./scripts/checkpatch.pl
> line 2638".
> 
> I noticed this bug while running checkpatch on the set of commits from
> v5.7 to v5.8-rc1 of the kernel on the commits with a diff content in
> their commit message.
> 
> This bug was introduced in the script by commit e518e9a59ec3
> ("checkpatch: emit an error when there's a diff in a changelog"). It has
> been in the script since then.
> 
> The author intended to store the match made by capture group in variable
> `$1`. This should have contained the name of the file as `[\w/]+` matched.
> However, this couldn't be accomplished due to usage of capture group and
> `$1` in the same regular expression.
> 
> Fix this by placing the capture group in the condition before `&&`.
> Thus, `$1` can be initialized to the text that capture group matches
> thereby setting it to the desired and required value.
> 
> Reviewed-by: Lukas Bulwahn 
> Tested-by: Lukas Bulwahn 
> Signed-off-by: Mrinal Pandey 
> ---
> Changes since v1:
> Add Reviewed-by and Tested-by tag
>

Hi Joe,

did you see this quick fix to checkpatch.pl? Can you comment on the 
commit and can we get a quick ack on that fix, please?

General question on patches for ./scripts/checkpatch.pl:

How do they travel to Linus?

Do you pick those patches and provide them to Andrew Morton?
Or do you just ack them and we need to send them to Andrew Morton to get 
them into mainline?

(get_maintainers tells us to just send those patches to you and Andy.)


Lukas


>  scripts/checkpatch.pl | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 4c820607540b..e73e998d582a 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2636,8 +2636,8 @@ sub process {
>  
>  # Check if the commit log has what seems like a diff which can confuse patch
>   if ($in_commit_log && !$commit_log_has_diff &&
> - (($line =~ m@^\s+diff\b.*a/[\w/]+@ &&
> -   $line =~ m@^\s+diff\b.*a/([\w/]+)\s+b/$1\b@) ||
> + (($line =~ m@^\s+diff\b.*a/([\w/]+)@ &&
> +   $line =~ m@^\s+diff\b.*a/[\w/]+\s+b/$1\b@) ||
>$line =~ m@^\s*(?:\-\-\-\s+a/|\+\+\+\s+b/)@ ||
>$line =~ m/^\s*\@\@ \-\d+,\d+ \+\d+,\d+ \@\@/)) {
>   ERROR("DIFF_IN_COMMIT_MSG",
> -- 
> 2.25.1
> 
> 

Re: [PATCH v4 06/10] powerpc/smp: Generalize 2nd sched domain

[Gautham R Shenoy]

On Mon, Jul 27, 2020 at 11:02:26AM +0530, Srikar Dronamraju wrote:
> Currently "CACHE" domain happens to be the 2nd sched domain as per
> powerpc_topology. This domain will collapse if cpumask of l2-cache is
> same as SMT domain. However we could generalize this domain such that it
> could mean either be a "CACHE" domain or a "BIGCORE" domain.
> 
> While setting up the "CACHE" domain, check if shared_cache is already
> set.
> 
> Cc: linuxppc-dev 
> Cc: LKML 
> Cc: Michael Ellerman 
> Cc: Nicholas Piggin 
> Cc: Anton Blanchard 
> Cc: Oliver O'Halloran 
> Cc: Nathan Lynch 
> Cc: Michael Neuling 
> Cc: Gautham R Shenoy 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Valentin Schneider 
> Cc: Jordan Niethe 
> Signed-off-by: Srikar Dronamraju 

Reviewed-by: Gautham R. Shenoy 

> ---
> Changelog v1 -> v2:
>   Moved shared_cache topology fixup to fixup_topology (Gautham)
> 
>  arch/powerpc/kernel/smp.c | 48 +++
>  1 file changed, 34 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index d997c7411664..3c5ccf6d2b1c 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -85,6 +85,14 @@ EXPORT_PER_CPU_SYMBOL(cpu_l2_cache_map);
>  EXPORT_PER_CPU_SYMBOL(cpu_core_map);
>  EXPORT_SYMBOL_GPL(has_big_cores);
> 
> +enum {
> +#ifdef CONFIG_SCHED_SMT
> + smt_idx,
> +#endif
> + bigcore_idx,
> + die_idx,
> +};
> +
>  #define MAX_THREAD_LIST_SIZE 8
>  #define THREAD_GROUP_SHARE_L1   1
>  struct thread_groups {
> @@ -851,13 +859,7 @@ static int powerpc_shared_cache_flags(void)
>   */
>  static const struct cpumask *shared_cache_mask(int cpu)
>  {
> - if (shared_caches)
> - return cpu_l2_cache_mask(cpu);
> -
> - if (has_big_cores)
> - return cpu_smallcore_mask(cpu);
> -
> - return per_cpu(cpu_sibling_map, cpu);
> + return per_cpu(cpu_l2_cache_map, cpu);
>  }
> 
>  #ifdef CONFIG_SCHED_SMT
> @@ -867,11 +869,16 @@ static const struct cpumask *smallcore_smt_mask(int cpu)
>  }
>  #endif
> 
> +static const struct cpumask *cpu_bigcore_mask(int cpu)
> +{
> + return per_cpu(cpu_sibling_map, cpu);
> +}
> +
>  static struct sched_domain_topology_level powerpc_topology[] = {
>  #ifdef CONFIG_SCHED_SMT
>   { cpu_smt_mask, powerpc_smt_flags, SD_INIT_NAME(SMT) },
>  #endif
> - { shared_cache_mask, powerpc_shared_cache_flags, SD_INIT_NAME(CACHE) },
> + { cpu_bigcore_mask, SD_INIT_NAME(BIGCORE) },
>   { cpu_cpu_mask, SD_INIT_NAME(DIE) },
>   { NULL, },
>  };
> @@ -1311,7 +1318,6 @@ static void add_cpu_to_masks(int cpu)
>  void start_secondary(void *unused)
>  {
>   unsigned int cpu = smp_processor_id();
> - struct cpumask *(*sibling_mask)(int) = cpu_sibling_mask;
> 
>   mmgrab(_mm);
>   current->active_mm = _mm;
> @@ -1337,14 +1343,20 @@ void start_secondary(void *unused)
>   /* Update topology CPU masks */
>   add_cpu_to_masks(cpu);
> 
> - if (has_big_cores)
> - sibling_mask = cpu_smallcore_mask;
>   /*
>* Check for any shared caches. Note that this must be done on a
>* per-core basis because one core in the pair might be disabled.
>*/
> - if (!cpumask_equal(cpu_l2_cache_mask(cpu), sibling_mask(cpu)))
> - shared_caches = true;
> + if (!shared_caches) {
> + struct cpumask *(*sibling_mask)(int) = cpu_sibling_mask;
> + struct cpumask *mask = cpu_l2_cache_mask(cpu);
> +
> + if (has_big_cores)
> + sibling_mask = cpu_smallcore_mask;
> +
> + if (cpumask_weight(mask) > cpumask_weight(sibling_mask(cpu)))
> + shared_caches = true;
> + }
> 
>   set_numa_node(numa_cpu_lookup_table[cpu]);
>   set_numa_mem(local_memory_node(numa_cpu_lookup_table[cpu]));
> @@ -1375,9 +1387,17 @@ static void fixup_topology(void)
>  #ifdef CONFIG_SCHED_SMT
>   if (has_big_cores) {
>   pr_info("Big cores detected but using small core scheduling\n");
> - powerpc_topology[0].mask = smallcore_smt_mask;
> + powerpc_topology[smt_idx].mask = smallcore_smt_mask;
>   }
>  #endif
> + if (shared_caches) {
> + pr_info("Using shared cache scheduler topology\n");
> + powerpc_topology[bigcore_idx].mask = shared_cache_mask;
> + powerpc_topology[bigcore_idx].sd_flags = 
> powerpc_shared_cache_flags;
> +#ifdef CONFIG_SCHED_DEBUG
> + powerpc_topology[bigcore_idx].name = "CACHE";
> +#endif
> + }
>  }
> 
>  void __init smp_cpus_done(unsigned int max_cpus)
> -- 
> 2.17.1
> 

Re: [PATCH 1/1] Input: atmel_mxt_ts: split large i2c transfers into blocks

[Dmitry Torokhov]

Hi Jiada,

On Wed, Jul 29, 2020 at 06:22:52PM +0900, Jiada Wang wrote:
> From: Jiada wang 
> 
> Some I2C controllers constrain maximum transferred data in an I2C
> transaction by set max_[read|write]_len of i2c_adapter_quirk.
> Large i2c transfer transaction beyond this limitation may fail to complete,
> cause I2C controller driver aborts the transaction and returns failure.
> 
> Therefore this patch was created to split large i2c transaction into
> smaller chunks which can complete within max_[read|write]_len defined
> by I2C controller driver.

Can we consider implementing this chunking logic in i2c core? Otherwise
we will need to adjust pretty much every driver to do this.

Thanks.

-- 
Dmitry

[tip:WIP.x86/kaslr] BUILD SUCCESS 4b23103abfba11df3daf26ca006489a467da5b65

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
WIP.x86/kaslr
branch HEAD: 4b23103abfba11df3daf26ca006489a467da5b65  x86/kaslr: Add a check 
that the random address is in range

elapsed time: 720m

configs tested: 66
configs skipped: 46

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

arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
i386 allyesconfig
i386defconfig
sparcallyesconfig
sparc   defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a004-20200729
x86_64   randconfig-a005-20200729
x86_64   randconfig-a002-20200729
x86_64   randconfig-a006-20200729
x86_64   randconfig-a003-20200729
x86_64   randconfig-a001-20200729
i386 randconfig-a003-20200729
i386 randconfig-a004-20200729
i386 randconfig-a005-20200729
i386 randconfig-a002-20200729
i386 randconfig-a006-20200729
i386 randconfig-a001-20200729
i386 randconfig-a016-20200729
i386 randconfig-a012-20200729
i386 randconfig-a013-20200729
i386 randconfig-a014-20200729
i386 randconfig-a011-20200729
i386 randconfig-a015-20200729
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

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

KASAN: invalid-free in snd_seq_port_disconnect

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:d3590ebf Merge tag 'audit-pr-20200729' of git://git.kernel..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1797d38890
kernel config:  https://syzkaller.appspot.com/x/.config?x=812bbfcb6ae2cd60
dashboard link: https://syzkaller.appspot.com/bug?extid=9d2abfef257f3e2d4713
compiler:   clang version 10.0.0 (https://github.com/llvm/llvm-project/ 
c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=14761be490

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+9d2abfef257f3e2d4...@syzkaller.appspotmail.com

==
BUG: KASAN: double-free or invalid-free in snd_seq_port_disconnect+0x570/0x610 
sound/core/seq/seq_ports.c:614

CPU: 1 PID: 7530 Comm: syz-executor.0 Not tainted 5.8.0-rc7-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+0x1f0/0x31e lib/dump_stack.c:118
 print_address_description+0x66/0x5a0 mm/kasan/report.c:383
 kasan_report_invalid_free+0x54/0xd0 mm/kasan/report.c:477
 __kasan_slab_free+0xae/0x170 mm/kasan/common.c:443
 __cache_free mm/slab.c:3426 [inline]
 kfree+0x10a/0x220 mm/slab.c:3757
 snd_seq_port_disconnect+0x570/0x610 sound/core/seq/seq_ports.c:614
 snd_seq_ioctl_unsubscribe_port+0x349/0x6c0 sound/core/seq/seq_clientmgr.c:1525
 snd_seq_oss_midi_close+0x397/0x620 sound/core/seq/oss/seq_oss_midi.c:405
 snd_seq_oss_synth_reset+0x335/0x8b0 sound/core/seq/oss/seq_oss_synth.c:406
 snd_seq_oss_reset+0x5b/0x250 sound/core/seq/oss/seq_oss_init.c:435
 snd_seq_oss_ioctl+0x5c2/0x1090 sound/core/seq/oss/seq_oss_ioctl.c:93
 odev_ioctl+0x51/0x70 sound/core/seq/oss/seq_oss.c:174
 vfs_ioctl fs/ioctl.c:48 [inline]
 ksys_ioctl fs/ioctl.c:753 [inline]
 __do_sys_ioctl fs/ioctl.c:762 [inline]
 __se_sys_ioctl+0xf9/0x160 fs/ioctl.c:760
 do_syscall_64+0x73/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45c429
Code: 8d b6 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 
5b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f25d0cb3c78 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 000154c0 RCX: 0045c429
RDX:  RSI: 5100 RDI: 0003
RBP: 0078bfd8 R08:  R09: 
R10:  R11: 0246 R12: 0078bfac
R13: 7ffe03b9f5df R14: 7f25d0cb49c0 R15: 0078bfac

Allocated by task 7529:
 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]
 snd_seq_port_connect+0x66/0x460 sound/core/seq/seq_ports.c:553
 snd_seq_ioctl_subscribe_port+0x349/0x6c0 sound/core/seq/seq_clientmgr.c:1484
 snd_seq_oss_midi_open+0x4db/0x830 sound/core/seq/oss/seq_oss_midi.c:364
 snd_seq_oss_synth_setup_midi+0x108/0x510 sound/core/seq/oss/seq_oss_synth.c:269
 snd_seq_oss_open+0x899/0xe90 sound/core/seq/oss/seq_oss_init.c:261
 odev_open+0x5e/0x90 sound/core/seq/oss/seq_oss.c:125
 chrdev_open+0x498/0x580 fs/char_dev.c:414
 do_dentry_open+0x813/0x1070 fs/open.c:828
 do_open fs/namei.c:3243 [inline]
 path_openat+0x278d/0x37f0 fs/namei.c:3360
 do_filp_open+0x191/0x3a0 fs/namei.c:3387
 do_sys_openat2+0x463/0x770 fs/open.c:1179
 do_sys_open fs/open.c:1195 [inline]
 __do_sys_openat fs/open.c:1209 [inline]
 __se_sys_openat fs/open.c:1204 [inline]
 __x64_sys_openat+0x1c8/0x1f0 fs/open.c:1204
 do_syscall_64+0x73/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Freed by task 7529:
 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
 snd_seq_port_disconnect+0x570/0x610 sound/core/seq/seq_ports.c:614
 snd_seq_ioctl_unsubscribe_port+0x349/0x6c0 sound/core/seq/seq_clientmgr.c:1525
 snd_seq_oss_midi_close+0x397/0x620 sound/core/seq/oss/seq_oss_midi.c:405
 snd_seq_oss_synth_reset+0x335/0x8b0 sound/core/seq/oss/seq_oss_synth.c:406
 snd_seq_oss_reset+0x5b/0x250 sound/core/seq/oss/seq_oss_init.c:435
 snd_seq_oss_ioctl+0x5c2/0x1090 sound/core/seq/oss/seq_oss_ioctl.c:93
 odev_ioctl+0x51/0x70 sound/core/seq/oss/seq_oss.c:174
 vfs_ioctl fs/ioctl.c:48 [inline]
 ksys_ioctl fs/ioctl.c:753 [inline]
 __do_sys_ioctl fs/ioctl.c:762 [inline]
 __se_sys_ioctl+0xf9/0x160 fs/ioctl.c:760
 do_syscall_64+0x73/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x4

[PATCH v3 3/3] cpuidle-pseries : Fixup exit latency for CEDE(0)

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

We are currently assuming that CEDE(0) has exit latency 10us, since
there is no way for us to query from the platform.  However, if the
wakeup latency of an Extended CEDE state is smaller than 10us, then we
can be sure that the exit latency of CEDE(0) cannot be more than that.
that.

In this patch, we fix the exit latency of CEDE(0) if we discover an
Extended CEDE state with wakeup latency smaller than 10us.

Benchmark results:

On POWER8, this patch does not have any impact since the advertized
latency of Extended CEDE (1) is 30us which is higher than the default
latency of CEDE (0) which is 10us.

On POWER9 we see improvement the single-threaded performance of ebizzy,
and no regression in the wakeup latency or the number of
context-switches.

ebizzy:
2 ebizzy threads bound to the same big-core. 25% improvement in the
avg records/s with patch.
x without_patch
* with_patch
N   Min   MaxMedian   AvgStddev
x  10   2491089   5834307   5398375   4244335 1596244.9
*  10   2893813   5834474   5832448 5327281.3 1055941.4

context_switch2 :
There is no major regression observed with this patch as seen from the
context_switch2 benchmark.

context_switch2 across CPU0 CPU1 (Both belong to same big-core, but different
small cores). We observe a minor 0.14% regression in the number of
context-switches (higher is better).
x without_patch
* with_patch
N   Min   MaxMedian   AvgStddev
x 500348872362236354712 354745.69  2711.827
* 500349422361452353942  354215.4 2576.9258
Difference at 99.0% confidence
-530.288 +/- 430.963
-0.149484% +/- 0.121485%
(Student's t, pooled s = 2645.24)

context_switch2 across CPU0 CPU8 (Different big-cores). We observe a 0.37%
improvement in the number of context-switches (higher is better).
x without_patch
* with_patch
N   Min   MaxMedian   AvgStddev
x 500287956294940288896 288977.23 646.59295
* 500288300294646289582 290064.76 1161.9992
Difference at 99.0% confidence
1087.53 +/- 153.194
0.376337% +/- 0.0530125%
(Student's t, pooled s = 940.299)

schbench:
No major difference could be seen until the 99.9th percentile.

Without-patch
Latency percentiles (usec)
50.0th: 29
75.0th: 39
90.0th: 49
95.0th: 59
*99.0th: 13104
99.5th: 14672
99.9th: 15824
min=0, max=17993

With-patch:
Latency percentiles (usec)
50.0th: 29
75.0th: 40
90.0th: 50
95.0th: 61
*99.0th: 13648
99.5th: 14768
99.9th: 15664
min=0, max=29812

Signed-off-by: Gautham R. Shenoy 
---
v2-->v3 : Made notation consistent with first two patches.
 drivers/cpuidle/cpuidle-pseries.c | 41 +--
 1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-pseries.c 
b/drivers/cpuidle/cpuidle-pseries.c
index f528da7..8d19820 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -350,13 +350,50 @@ static int pseries_cpuidle_driver_init(void)
return 0;
 }
 
-static void __init parse_xcede_idle_states(void)
+static void __init fixup_cede0_latency(void)
 {
+   int i;
+   u64 min_latency_us = dedicated_states[1].exit_latency; /* CEDE latency 
*/
+   struct xcede_latency_payload *payload;
+
if (parse_cede_parameters())
return;
 
pr_info("cpuidle : Skipping the %d Extended CEDE idle states\n",
nr_xcede_records);
+
+   payload = _latency_parameter.payload;
+   for (i = 0; i < nr_xcede_records; i++) {
+   struct xcede_latency_record *record = >records[i];
+   u64 latency_tb = be64_to_cpu(record->latency_ticks);
+   u64 latency_us = tb_to_ns(latency_tb) / NSEC_PER_USEC;
+
+   if (latency_us < min_latency_us)
+   min_latency_us = latency_us;
+   }
+
+   /*
+* By default, we assume that CEDE(0) has exit latency 10us,
+* since there is no way for us to query from the platform.
+*
+* However, if the wakeup latency of an Extended CEDE state is
+* smaller than 10us, then we can be sure that CEDE(0)
+* requires no more than that.
+*
+* Perform the fix-up.
+*/
+   if (min_latency_us < dedicated_states[1].exit_latency) {
+   u64 cede0_latency = min_latency_us - 1;
+
+   if (cede0_latency <= 0)
+   cede0_latency = min_latency_us;
+
+   dedicated_states[1].exit_latency = cede0_latency;
+   dedicated_states[1].target_residency = 10 * (cede0_latency);
+   pr_info("cpuidle : Fixed up CEDE exit latency 

Re: [PATCH 3/3] drm/ingenic: ipu: Only enable clock when needed

[Sam Ravnborg]

On Thu, Jul 30, 2020 at 03:46:26AM +0200, Paul Cercueil wrote:
> Instead of keeping the IPU clock enabled constantly, enable and disable
> it on demand, when the IPU plane is used.

This explains what the patch does - but fails to mention why.
Could you please add the why part too.

With the chagelog updated:
Reviewed-by: Sam Ravnborg 

Sam
> 
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/gpu/drm/ingenic/ingenic-ipu.c | 23 ---
>  1 file changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c 
> b/drivers/gpu/drm/ingenic/ingenic-ipu.c
> index f4f0abcd6692..17e682cf1eba 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-ipu.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c
> @@ -49,6 +49,7 @@ struct ingenic_ipu {
>   struct regmap *map;
>   struct clk *clk;
>   const struct soc_info *soc_info;
> + bool clk_enabled;
>  
>   unsigned int num_w, num_h, denom_w, denom_h;
>  
> @@ -288,12 +289,23 @@ static void ingenic_ipu_plane_atomic_update(struct 
> drm_plane *plane,
>   const struct drm_format_info *finfo;
>   u32 ctrl, stride = 0, coef_index = 0, format = 0;
>   bool needs_modeset, upscaling_w, upscaling_h;
> + int err;
>  
>   if (!state || !state->fb)
>   return;
>  
>   finfo = drm_format_info(state->fb->format->format);
>  
> + if (!ipu->clk_enabled) {
> + err = clk_enable(ipu->clk);
> + if (err) {
> + dev_err(ipu->dev, "Unable to enable clock: %d\n", err);
> + return;
> + }
> +
> + ipu->clk_enabled = true;
> + }
> +
>   /* Reset all the registers if needed */
>   needs_modeset = drm_atomic_crtc_needs_modeset(state->crtc->state);
>   if (needs_modeset) {
> @@ -578,6 +590,11 @@ static void ingenic_ipu_plane_atomic_disable(struct 
> drm_plane *plane,
>   regmap_clear_bits(ipu->map, JZ_REG_IPU_CTRL, JZ_IPU_CTRL_CHIP_EN);
>  
>   ingenic_drm_plane_disable(ipu->master, plane);
> +
> + if (ipu->clk_enabled) {
> + clk_disable(ipu->clk);
> + ipu->clk_enabled = false;
> + }
>  }
>  
>  static const struct drm_plane_helper_funcs ingenic_ipu_plane_helper_funcs = {
> @@ -761,9 +778,9 @@ static int ingenic_ipu_bind(struct device *dev, struct 
> device *master, void *d)
>   drm_object_attach_property(>base, ipu->sharpness_prop,
>  ipu->sharpness);
>  
> - err = clk_prepare_enable(ipu->clk);
> + err = clk_prepare(ipu->clk);
>   if (err) {
> - dev_err(dev, "Unable to enable clock\n");
> + dev_err(dev, "Unable to prepare clock\n");
>   return err;
>   }
>  
> @@ -775,7 +792,7 @@ static void ingenic_ipu_unbind(struct device *dev,
>  {
>   struct ingenic_ipu *ipu = dev_get_drvdata(dev);
>  
> - clk_disable_unprepare(ipu->clk);
> + clk_unprepare(ipu->clk);
>  }
>  
>  static const struct component_ops ingenic_ipu_ops = {
> -- 
> 2.27.0

[PATCH v3 0/3] cpuidle-pseries: Parse extended CEDE information for idle.

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

This is a v3 of the patch series to parse the extended CEDE
information in the pseries-cpuidle driver.

The previous two versions of the patches can be found here:

v2: 
https://lore.kernel.org/lkml/1596005254-25753-1-git-send-email-...@linux.vnet.ibm.com/

v1: 
https://lore.kernel.org/linuxppc-dev/1594120299-31389-1-git-send-email-...@linux.vnet.ibm.com/

The change from v2 --> v1 :

 * Patch 1: Got rid of some #define-s which were needed mainly for Patches4 and
   5 of v1, but were retained in v2.

 * Patch 2:

* Based on feedback from Michael Ellerman, rewrote the
  function to parse the extended idle states by explicitly
  defining the structure of the object that is returned by
  ibm,get-system-parameters(CEDE_LATENCY_TOKEN) rtas-call. In
  the previous versions we were passing a character array and
  subsequently parsing the individual elements which can be
  bug-prone. This also gets rid of the excessive (cast *)ing
  that was in the previous versions.

  * Marked some of the functions static and annotated some of
  the functions with __init and data with __initdata. This
  makes Sparse happy.

  * Added comments for CEDE_LATENCY_TOKEN.

  * Renamed add_pseries_idle_states() to
parse_xcede_idle_states(). Again, this is because Patch 4
and 5 from v1 are no longer there.

 * Patch 3: No functional changes, but minor changes to be consistent
   with Patch 1 and 2 of this series.
 
I have additionally tested the code on POWER8 dedicated LPAR and found
that it has no impact, since the wakeup latency of CEDE(1) is 30us
which is greater that default latency that we are assuming for
CEDE(0). So we do not need to fixup CEDE(0) latency on POWER8.

Vaidy, I have removed your Reviewed-by for v1, since the code has
changed a little bit.

Gautham R. Shenoy (3):
  cpuidle-pseries: Set the latency-hint before entering CEDE
  cpuidle-pseries: Add function to parse extended CEDE records
  cpuidle-pseries : Fixup exit latency for CEDE(0)

 drivers/cpuidle/cpuidle-pseries.c | 190 +-
 1 file changed, 188 insertions(+), 2 deletions(-)

-- 
1.9.4

[PATCH v3 2/3] cpuidle-pseries: Add function to parse extended CEDE records

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

Currently we use CEDE with latency-hint 0 as the only other idle state
on a dedicated LPAR apart from the polling "snooze" state.

The platform might support additional extended CEDE idle states, which
can be discovered through the "ibm,get-system-parameter" rtas-call
made with CEDE_LATENCY_TOKEN.

This patch adds a function to obtain information about the extended
CEDE idle states from the platform and parse the contents to populate
an array of extended CEDE states. These idle states thus discovered
will be added to the cpuidle framework in the next patch.

dmesg on a POWER8 and POWER9 LPAR, demonstrating the output of parsing
the extended CEDE latency parameters are as follows

POWER8
[   10.093279] xcede : xcede_record_size = 10
[   10.093285] xcede : Record 0 : hint = 1, latency = 0x3c00 tb ticks, 
Wake-on-irq = 1
[   10.093291] xcede : Record 1 : hint = 2, latency = 0x4e2000 tb ticks, 
Wake-on-irq = 0
[   10.093297] cpuidle : Skipping the 2 Extended CEDE idle states

POWER9
[5.913180] xcede : xcede_record_size = 10
[5.913183] xcede : Record 0 : hint = 1, latency = 0x400 tb ticks, 
Wake-on-irq = 1
[5.913188] xcede : Record 1 : hint = 2, latency = 0x3e8000 tb ticks, 
Wake-on-irq = 0
[5.913193] cpuidle : Skipping the 2 Extended CEDE idle states

Signed-off-by: Gautham R. Shenoy 
---
v2-->v3 : Cleaned up parse_cede_parameters(). Silenced some sparse warnings.
drivers/cpuidle/cpuidle-pseries.c | 142 ++
 1 file changed, 142 insertions(+)

diff --git a/drivers/cpuidle/cpuidle-pseries.c 
b/drivers/cpuidle/cpuidle-pseries.c
index f5865a2..f528da7 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static struct cpuidle_driver pseries_idle_driver = {
.name = "pseries_idle",
@@ -87,6 +88,137 @@ static void check_and_cede_processor(void)
 }
 
 #define NR_DEDICATED_STATES2 /* snooze, CEDE */
+/*
+ * XCEDE : Extended CEDE states discovered through the
+ * "ibm,get-systems-parameter" rtas-call with the token
+ * CEDE_LATENCY_TOKEN
+ */
+#define MAX_XCEDE_STATES   4
+#defineXCEDE_LATENCY_RECORD_SIZE   10
+#define XCEDE_LATENCY_PARAM_MAX_LENGTH (2 + 2 + \
+   (MAX_XCEDE_STATES * 
XCEDE_LATENCY_RECORD_SIZE))
+
+/*
+ * Section 7.3.16 System Parameters Option of PAPR version 2.8.1 has a
+ * table with all the parameters to ibm,get-system-parameters.
+ * CEDE_LATENCY_TOKEN corresponds to the token value for Cede Latency
+ * Settings Information.
+ */
+#define CEDE_LATENCY_TOKEN 45
+
+/*
+ * If the platform supports the cede latency settings
+ * information system parameter it must provide the following
+ * information in the NULL terminated parameter string:
+ *
+ * a. The first byte is the length “N” of each cede
+ *latency setting record minus one (zero indicates a length
+ *of 1 byte).
+ *
+ * b. For each supported cede latency setting a cede latency
+ *setting record consisting of the first “N” bytes as per
+ *the following table.
+ *
+ * -
+ * | Field   | Field  |
+ * | Name| Length |
+ * -
+ * | Cede Latency| 1 Byte |
+ * | Specifier Value ||
+ * -
+ * | Maximum wakeup  ||
+ * | latency in  | 8 Bytes|
+ * | tb-ticks||
+ * -
+ * | Responsive to   ||
+ * | external| 1 Byte |
+ * | interrupts  ||
+ * -
+ *
+ * This version has cede latency record size = 10.
+ *
+ * The structure xcede_latency_payload represents a) and b) with
+ * xcede_latency_record representing the table in b).
+ *
+ * xcede_latency_parameter is what gets returned by
+ * ibm,get-systems-parameter rtas-call when made with
+ * CEDE_LATENCY_TOKEN.
+ *
+ * These structures are only used to represent the data sent obtained
+ * by the rtas-call. The data is in Big-Endian.
+ */
+struct xcede_latency_record {
+   u8  hint;
+   __be64  latency_ticks;
+   u8  wake_on_irqs;
+} __packed;
+
+struct xcede_latency_payload {
+   u8 record_size;
+   struct xcede_latency_record records[MAX_XCEDE_STATES];
+} __packed;
+
+struct xcede_latency_parameter {
+   __be16  payload_size;
+   struct xcede_latency_payload payload;
+   u8 null_char;
+} __packed;
+
+static unsigned int nr_xcede_records;
+static struct xcede_latency_parameter xcede_latency_parameter __initdata;
+
+static int __init parse_cede_parameters(void)
+{
+   int ret, i;
+   u16 payload_size;
+   u8 xcede_record_size;
+   u32 total_xcede_records_size;
+   struct xcede_latency_payload *payload;
+
+   memset(_latency_parameter, 0, 

[PATCH v3 1/3] cpuidle-pseries: Set the latency-hint before entering CEDE

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

As per the PAPR, each H_CEDE call is associated with a latency-hint to
be passed in the VPA field "cede_latency_hint". The CEDE states that
we were implicitly entering so far is CEDE with latency-hint = 0.

This patch explicitly sets the latency hint corresponding to the CEDE
state that we are currently entering. While at it, we save the
previous hint, to be restored once we wakeup from CEDE. This will be
required in the future when we expose extended-cede states through the
cpuidle framework, where each of them will have a different
cede-latency hint.

Signed-off-by: Gautham R. Shenoy 
---
v2-->v3 : Got rid of the usused NR_CEDE_STATES definition

 drivers/cpuidle/cpuidle-pseries.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-pseries.c 
b/drivers/cpuidle/cpuidle-pseries.c
index 3e058ad2..f5865a2 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -86,19 +86,26 @@ static void check_and_cede_processor(void)
}
 }
 
+#define NR_DEDICATED_STATES2 /* snooze, CEDE */
+
+u8 cede_latency_hint[NR_DEDICATED_STATES];
 static int dedicated_cede_loop(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
 {
+   u8 old_latency_hint;
 
pseries_idle_prolog();
get_lppaca()->donate_dedicated_cpu = 1;
+   old_latency_hint = get_lppaca()->cede_latency_hint;
+   get_lppaca()->cede_latency_hint = cede_latency_hint[index];
 
HMT_medium();
check_and_cede_processor();
 
local_irq_disable();
get_lppaca()->donate_dedicated_cpu = 0;
+   get_lppaca()->cede_latency_hint = old_latency_hint;
 
pseries_idle_epilog();
 
@@ -130,7 +137,7 @@ static int shared_cede_loop(struct cpuidle_device *dev,
 /*
  * States for dedicated partition case.
  */
-static struct cpuidle_state dedicated_states[] = {
+static struct cpuidle_state dedicated_states[NR_DEDICATED_STATES] = {
{ /* Snooze */
.name = "snooze",
.desc = "snooze",
@@ -233,7 +240,7 @@ static int pseries_idle_probe(void)
max_idle_state = ARRAY_SIZE(shared_states);
} else {
cpuidle_state_table = dedicated_states;
-   max_idle_state = ARRAY_SIZE(dedicated_states);
+   max_idle_state = NR_DEDICATED_STATES;
}
} else
return -ENODEV;
-- 
1.9.4

Re: [PATCH] drivers: soc: xilinx: Call InitFinalize from late_initcall_sync instead of probe

[Michal Simek]

On 23. 07. 20 1:25, Amit Sunil Dhamne wrote:
> From: Rajan Vaja 
> 
> Initially all devices are in power up state. Firmware expect that
> processor should call InitFinalize API once it have requested devices
> which are required so that it can turn off all unused devices and
> save power. From Linux, PM driver calls InitFinalize to inform the
> firmware that it can power down the unused devices. Upon
> InitFinalize() call firmware power downs all unused devices.
> 
> There are chances that PM driver is probed along with or before other
> device drivers. So in that case some of the devices may not be
> requested from firmware which is done by genpd driver. Due to that
> firmware will consider those devices as unused and firmware will power
> down those devices. Later when any device driver is probed, genpd
> driver will ask firmware to power up that device using request node
> API. So for those devices, power transition will be like on->off->on
> which creates unnecessary power glitch to those devices.
> 
> To avoid such unnecessary power transitions and as ideal behavior
> InitFinalize should be called after all drivers are probed. So call
> InitFinalize from late_initcall_sync.
> 
> Signed-off-by: Rajan Vaja 
> Signed-off-by: Amit Sunil Dhamne 
> ---
>  drivers/soc/xilinx/zynqmp_power.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/xilinx/zynqmp_power.c 
> b/drivers/soc/xilinx/zynqmp_power.c
> index 31ff49fcd078..fa05cf12d5f3 100644
> --- a/drivers/soc/xilinx/zynqmp_power.c
> +++ b/drivers/soc/xilinx/zynqmp_power.c
> @@ -178,7 +178,6 @@ static int zynqmp_pm_probe(struct platform_device *pdev)
>   u32 pm_api_version;
>   struct mbox_client *client;
>  
> - zynqmp_pm_init_finalize();
>   zynqmp_pm_get_api_version(_api_version);
>  
>   /* Check PM API version number */
> @@ -246,6 +245,13 @@ static int zynqmp_pm_remove(struct platform_device *pdev)
>   return 0;
>  }
>  
> +static int __init do_init_finalize(void)
> +{
> + return zynqmp_pm_init_finalize();
> +}
> +
> +late_initcall_sync(do_init_finalize);
> +
>  static const struct of_device_id pm_of_match[] = {
>   { .compatible = "xlnx,zynqmp-power", },
>   { /* end of table */ },
> 

Applied.
M

Re: [PATCH] Module argument to control whether intel-spi-pci attempts to turn the SPI flash chip writeable

[Greg Kroah-Hartman]

On Wed, Jul 29, 2020 at 05:54:35PM -0300, Daniel Gutson wrote:
> On Mon, Jul 27, 2020 at 12:31 PM Daniel Gutson  wrote:
> >
> > On Mon, Jul 27, 2020 at 12:15 PM Arnd Bergmann  wrote:
> > >
> > > On Mon, Jul 27, 2020 at 5:05 PM Daniel Gutson  
> > > wrote:
> > > > On Sun, Jul 26, 2020 at 4:17 AM Greg Kroah-Hartman 
> > > >  wrote:
> > > >>
> > > >> On Sat, Jul 25, 2020 at 02:20:03PM -0300, Daniel Gutson wrote:
> > > >> > El sáb., 25 jul. 2020 2:56 a. m., Greg Kroah-Hartman <
> > > >> > gre...@linuxfoundation.org> escribió:
> > > >> >
> > > >> >
> > > >> > 1) I just did the same that intel-spi.c does.
> > > >>
> > > >> No need to copy bad examples :)
> > > >
> > > >
> > > > Didn't know it was a bad example. What's is the current modern 
> > > > mechanism that replaces initialization-time configuration?
> > >
> > > I'd say you'd generally want this to be a per-instance setting, which
> > > could be a sysfs attribute of the physical device, or an ioctl for an
> > > existing user space abstraction.
> >
> > But still, they are not equivalent. The initial configuration remains
> > constant for the rest of the life of the driver, whereas the
> > sysfs attribute is set after the initialization and can be re-set over
> > time. I'm not asking module parameters "to come back" if
> > they are now considered obsolete, I'm just trying to understand.
> >
> > >
> > > In the changelog, you should also explain what this is used for. Do
> > > you actually want to write to a device that is marked read-only, or
> > > are you just trying to make the interface more consistent between the
> > > two drivers?
> >
> > The device can either be locked or unlocked. If it is unlocked, it can
> > be set writable depending on the module
> > argument in intel-spi, or straight writable in intel-spi-pci. Which is
> > dangerous.
> > I wanted to make, as you say, the interface consistent.
> > Exposing an interface to the user (via a sysfs attribute) to try to
> > make the driver writable is definitively a bad idea.
> > I'd rather do nothing (no module arg) rather than open that
> > here-be-dragons door.
> 
> ping.
> This is a real existing problem that I'm trying to address.
> There's currently no way to prevent the kernel to try to turn
> the SPI flash chip writable for the device IDs handled by
> intel-spi-pci. And allowing userspace to switch it between
> writable/non-writable is not an option.
> What other mechanism can I use other than the module parameter,

Again, module parameters are working on a per-chunk-of-code basis, while
you want to work on a per-device basis, which is why you should not use
a module parameter.

good luck!

greg k-h

drivers/rtc/rtc-pcf85063.c:292:40: warning: Clarify calculation precedence for '&' and

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   d3590ebf6f91350192737dd1d1b219c05277f067
commit: f86dc5bde18e540743eaef20529d9f2b67283abd rtc: pcf85063: return 
meaningful value for RTC_VL_READ
date:   8 months ago
compiler: or1k-linux-gcc (GCC) 9.3.0

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


cppcheck warnings: (new ones prefixed by >>)

>> drivers/rtc/rtc-pcf85063.c:292:40: warning: Clarify calculation precedence 
>> for '&' and '?'. [clarifyCalculation]
 status = status & PCF85063_REG_SC_OS ? RTC_VL_DATA_INVALID : 0;
  ^

vim +292 drivers/rtc/rtc-pcf85063.c

   279  
   280  static int pcf85063_ioctl(struct device *dev, unsigned int cmd,
   281unsigned long arg)
   282  {
   283  struct pcf85063 *pcf85063 = dev_get_drvdata(dev);
   284  int status, ret = 0;
   285  
   286  switch (cmd) {
   287  case RTC_VL_READ:
   288  ret = regmap_read(pcf85063->regmap, PCF85063_REG_SC, 
);
   289  if (ret < 0)
   290  return ret;
   291  
 > 292  status = status & PCF85063_REG_SC_OS ? 
 > RTC_VL_DATA_INVALID : 0;
   293  
   294  return put_user(status, (unsigned int __user *)arg);
   295  
   296  default:
   297  return -ENOIOCTLCMD;
   298  }
   299  }
   300  

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

Re: [PATCH 2/3] drm/ingenic: ipu: Remove YUV422 from supported formats on JZ4725B

[Sam Ravnborg]

On Thu, Jul 30, 2020 at 03:46:25AM +0200, Paul Cercueil wrote:
> When configuring the IPU for packed YUV 4:2:2, depending on the scaling
> ratios given by the source and destination resolutions, it is possible
> to crash the IPU block beyond repair, to the point where a software
> reset of the IP does not fix it.

"beyond repair" - I read this as the HW is fried and you cannot make it
work again whatsoever.
Here it is stated that a software reset does not fix it.
If a power cycle fixes it please state so - both here and in the comment
in the code below. So people are not scared away and think they will
damage their HW.

Sam

This can happen anytime, in the first
> few frames, or after dozens of minutes. The same crash also happens when
> the IPU is fully controlled by the LCD controller (in that case no HW
> register is written at any moment after startup), which points towards a
> hardware bug.
> 
> Thanksfully multiplanar YUV is not affected.
> 
> Until this bug is fixed or worked around, address this issue by removing
> support for YUV 4:2:2 on the IPU of the JZ4725B.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/gpu/drm/ingenic/ingenic-ipu.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c 
> b/drivers/gpu/drm/ingenic/ingenic-ipu.c
> index 7eae56fa92ea..f4f0abcd6692 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-ipu.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c
> @@ -795,10 +795,16 @@ static int ingenic_ipu_remove(struct platform_device 
> *pdev)
>  }
>  
>  static const u32 jz4725b_ipu_formats[] = {
> + /*
> +  * While officially supported, packed YUV 4:2:2 formats can cause
> +  * random hardware crashes on JZ4725B, beyond repair, under certain
> +  * circumstances. It seems to happen with some specific resize ratios.
> +  * Until a proper workaround or fix is found, disable these formats.
>   DRM_FORMAT_YUYV,
>   DRM_FORMAT_YVYU,
>   DRM_FORMAT_UYVY,
>   DRM_FORMAT_VYUY,
> + */
>   DRM_FORMAT_YUV411,
>   DRM_FORMAT_YUV420,
>   DRM_FORMAT_YUV422,
> -- 
> 2.27.0

Re: [PATCH 1/3] drm/ingenic: ipu: Only restart manually on older SoCs

[Sam Ravnborg]

On Thu, Jul 30, 2020 at 03:46:24AM +0200, Paul Cercueil wrote:
> On older SoCs, it is necessary to restart manually the IPU when a frame
> is done processing. Doing so on newer SoCs (JZ4760/70) kinds of work
> too, until the input or output resolutions or the framerate are too
> high.
> 
> Make it work properly on newer SoCs by letting the LCD controller
> trigger the IPU frame restart signal.
> 
> Signed-off-by: Paul Cercueil 
Reviewed-by: Sam Ravnborg 
> ---
>  drivers/gpu/drm/ingenic/ingenic-ipu.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c 
> b/drivers/gpu/drm/ingenic/ingenic-ipu.c
> index 7a0a8bd865d3..7eae56fa92ea 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-ipu.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c
> @@ -35,6 +35,7 @@ struct soc_info {
>   const u32 *formats;
>   size_t num_formats;
>   bool has_bicubic;
> + bool manual_restart;
>  
>   void (*set_coefs)(struct ingenic_ipu *ipu, unsigned int reg,
> unsigned int sharpness, bool downscale,
> @@ -645,7 +646,8 @@ static irqreturn_t ingenic_ipu_irq_handler(int irq, void 
> *arg)
>   unsigned int dummy;
>  
>   /* dummy read allows CPU to reconfigure IPU */
> - regmap_read(ipu->map, JZ_REG_IPU_STATUS, );
> + if (ipu->soc_info->manual_restart)
> + regmap_read(ipu->map, JZ_REG_IPU_STATUS, );
>  
>   /* ACK interrupt */
>   regmap_write(ipu->map, JZ_REG_IPU_STATUS, 0);
> @@ -656,7 +658,8 @@ static irqreturn_t ingenic_ipu_irq_handler(int irq, void 
> *arg)
>   regmap_write(ipu->map, JZ_REG_IPU_V_ADDR, ipu->addr_v);
>  
>   /* Run IPU for the new frame */
> - regmap_set_bits(ipu->map, JZ_REG_IPU_CTRL, JZ_IPU_CTRL_RUN);
> + if (ipu->soc_info->manual_restart)
> + regmap_set_bits(ipu->map, JZ_REG_IPU_CTRL, JZ_IPU_CTRL_RUN);
>  
>   drm_crtc_handle_vblank(crtc);
>  
> @@ -806,6 +809,7 @@ static const struct soc_info jz4725b_soc_info = {
>   .formats= jz4725b_ipu_formats,
>   .num_formats= ARRAY_SIZE(jz4725b_ipu_formats),
>   .has_bicubic= false,
> + .manual_restart = true,
>   .set_coefs  = jz4725b_set_coefs,
>  };
>  
> @@ -831,6 +835,7 @@ static const struct soc_info jz4760_soc_info = {
>   .formats= jz4760_ipu_formats,
>   .num_formats= ARRAY_SIZE(jz4760_ipu_formats),
>   .has_bicubic= true,
> + .manual_restart = false,
>   .set_coefs  = jz4760_set_coefs,
>  };
>  
> -- 
> 2.27.0

Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

[Greg KH]

On Wed, Jul 29, 2020 at 06:45:46PM -0500, John Donnelly wrote:
> 
> 
> On 7/29/20 9:16 AM, Mike Snitzer wrote:
> > On Wed, Jul 29 2020 at  7:55am -0400,
> > Greg KH  wrote:
> > 
> > > On Wed, Jul 29, 2020 at 01:51:19PM +0200, Greg KH wrote:
> > > > On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Snitzer wrote:
> > > > > This mail needs to be saent to sta...@vger.kernel.org (now cc'd).
> > > > > 
> > > > > Greg et al: please backport 2df3bae9a6543e90042291707b8db0cbfbae9ee9
> > > > 
> > > > Now backported, thanks.
> > > 
> > > Nope, it broke the build, I need something that actually works :)
> > > 
> > 
> > OK, I'll defer to John Donnelly to get back with you (and rest of
> > stable@).  He is more invested due to SUSE also having this issue.  I
> > can put focus to it if John cannot sort this out.
> > 
> > Mike
> > 
> 
> 
> Hi.
> 
> 
> Thank you for reaching out.
> 
> What specifically is broken? . If it that applying
> 2df3bae9a6543e90042291707b8db0cbfbae9ee9 to 4.14.y is failing?

yes, try it yourself and see!

[PATCH V1 2/6] rpmsg: glink: Deny intent request if reusable intent fits

[Deepak Kumar Singh]

From: Chris Lew 

In high traffic scenarios a remote may request extra intents to send
data faster. If the work thread that handles these intent requests is
starved of cpu time, then these requests can build up. Some remote
procs may not be able to handle this burst of built up intent requests.

In order to prevent intent build up, deny intent requests that can be
fulfilled by default intents that are reusable.

Signed-off-by: Chris Lew 
Signed-off-by: Deepak Kumar Singh 
---
 drivers/rpmsg/qcom_glink_native.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/rpmsg/qcom_glink_native.c 
b/drivers/rpmsg/qcom_glink_native.c
index 2668c66..df3c608 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -734,9 +734,11 @@ static void qcom_glink_handle_rx_done(struct qcom_glink 
*glink,
 static void qcom_glink_handle_intent_req(struct qcom_glink *glink,
 u32 cid, size_t size)
 {
-   struct glink_core_rx_intent *intent;
+   struct glink_core_rx_intent *intent = NULL;
+   struct glink_core_rx_intent *tmp;
struct glink_channel *channel;
unsigned long flags;
+   int iid;
 
spin_lock_irqsave(>idr_lock, flags);
channel = idr_find(>rcids, cid);
@@ -747,6 +749,19 @@ static void qcom_glink_handle_intent_req(struct qcom_glink 
*glink,
return;
}
 
+   spin_lock_irqsave(>intent_lock, flags);
+   idr_for_each_entry(>liids, tmp, iid) {
+   if (tmp->size >= size && tmp->reuse) {
+   intent = tmp;
+   break;
+   }
+   }
+   spin_unlock_irqrestore(>intent_lock, flags);
+   if (intent) {
+   qcom_glink_send_intent_req_ack(glink, channel, !!intent);
+   return;
+   }
+
intent = qcom_glink_alloc_intent(glink, channel, size, false);
if (intent)
qcom_glink_advertise_intent(glink, channel, intent);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v1] scsi: stex: use generic power management

[Vaibhav Gupta]

Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.

Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the unnecessary load from the driver.
This also avoids the need for the driver to directly call most of the PCI
helper functions and device power state control functions, as through
the generic framework PCI Core takes care of the necessary operations,
and drivers are required to do only device-specific jobs.

Signed-off-by: Vaibhav Gupta 
---
 drivers/scsi/stex.c | 35 +--
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index d4f10c0d813c..9500666b521a 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -1972,9 +1972,9 @@ static int stex_choice_sleep_mic(struct st_hba *hba, 
pm_message_t state)
}
 }
 
-static int stex_suspend(struct pci_dev *pdev, pm_message_t state)
+static int stex_suspend_late(struct device *dev, pm_message_t state)
 {
-   struct st_hba *hba = pci_get_drvdata(pdev);
+   struct st_hba *hba = dev_get_drvdata(dev);
 
if ((hba->cardtype == st_yel || hba->cardtype == st_P3)
&& hba->supports_pm == 1)
@@ -1984,9 +1984,24 @@ static int stex_suspend(struct pci_dev *pdev, 
pm_message_t state)
return 0;
 }
 
-static int stex_resume(struct pci_dev *pdev)
+static int stex_suspend(struct device *dev)
 {
-   struct st_hba *hba = pci_get_drvdata(pdev);
+   return stex_suspend_late(dev, PMSG_SUSPEND);
+}
+
+static int stex_hibernate(struct device *dev)
+{
+   return stex_suspend_late(dev, PMSG_HIBERNATE);
+}
+
+static int stex_freeze(struct device *dev)
+{
+   return stex_suspend_late(dev, PMSG_FREEZE);
+}
+
+static int stex_resume(struct device *dev)
+{
+   struct st_hba *hba = dev_get_drvdata(dev);
 
hba->mu_status = MU_STATE_STARTING;
stex_handshake(hba);
@@ -2000,14 +2015,22 @@ static int stex_halt(struct notifier_block *nb, 
unsigned long event, void *buf)
 }
 MODULE_DEVICE_TABLE(pci, stex_pci_tbl);
 
+static const struct dev_pm_ops stex_pm_ops = {
+   .suspend= stex_suspend,
+   .resume = stex_resume,
+   .freeze = stex_freeze,
+   .thaw   = stex_resume,
+   .poweroff   = stex_hibernate,
+   .restore= stex_resume,
+};
+
 static struct pci_driver stex_pci_driver = {
.name   = DRV_NAME,
.id_table   = stex_pci_tbl,
.probe  = stex_probe,
.remove = stex_remove,
.shutdown   = stex_shutdown,
-   .suspend= stex_suspend,
-   .resume = stex_resume,
+   .driver.pm  = _pm_ops,
 };
 
 static int __init stex_init(void)
-- 
2.27.0

linux-next: manual merge of the iommu tree with the dma-mapping tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the iommu tree got a conflict in:

  drivers/iommu/Kconfig

between commit:

  2f9237d4f6df ("dma-mapping: make support for dma ops optional")

from the dma-mapping tree and commit:

  ab65ba57e3ac ("iommu/vt-d: Move Kconfig and Makefile bits down into intel 
directory")

from the iommu tree.

I fixed it up (I used the ;atter and applied the folowing merge fix
patch as well) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

From: Stephen Rothwell 
Date: Thu, 30 Jul 2020 15:14:18 +1000
Subject: [PATCH] merge fix for "dma-mapping: make support for dma ops optional"

Signed-off-by: Stephen Rothwell 
---
 drivers/iommu/intel/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/intel/Kconfig b/drivers/iommu/intel/Kconfig
index 877beec9d987..5337ee1584b0 100644
--- a/drivers/iommu/intel/Kconfig
+++ b/drivers/iommu/intel/Kconfig
@@ -6,6 +6,7 @@ config DMAR_TABLE
 config INTEL_IOMMU
bool "Support for Intel IOMMU using DMA Remapping Devices"
depends on PCI_MSI && ACPI && (X86 || IA64)
+   select DMA_OPS
select IOMMU_API
select IOMMU_IOVA
select NEED_DMA_MAP_STATE
-- 
2.27.0

-- 
Cheers,
Stephen Rothwell


pgpJd_nduNeiC.pgp
Description: OpenPGP digital signature

[PATCH V1 4/6] rpmsg: glink: Remove the rpmsg dev in close_ack

[Deepak Kumar Singh]

From: Arun Kumar Neelakantam 

Un-register and register of rpmsg driver is sending invalid open_ack
on closed channel.

To avoid sending invalid open_ack case unregister the rpmsg device
after receiving the local_close_ack from remote side.

Signed-off-by: Deepak Kumar Singh 
signed-off-by: Arun Kumar Neelakantam 
---
 drivers/rpmsg/qcom_glink_native.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/rpmsg/qcom_glink_native.c 
b/drivers/rpmsg/qcom_glink_native.c
index ac179b1..031bc1d 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -1526,6 +1526,7 @@ static void qcom_glink_rx_close(struct qcom_glink *glink, 
unsigned int rcid)
 
rpmsg_unregister_device(glink->dev, );
}
+   channel->rpdev = NULL;
 
qcom_glink_send_close_ack(glink, channel->rcid);
 
@@ -1539,6 +1540,7 @@ static void qcom_glink_rx_close(struct qcom_glink *glink, 
unsigned int rcid)
 
 static void qcom_glink_rx_close_ack(struct qcom_glink *glink, unsigned int 
lcid)
 {
+   struct rpmsg_channel_info chinfo;
struct glink_channel *channel;
unsigned long flags;
 
@@ -1553,6 +1555,16 @@ static void qcom_glink_rx_close_ack(struct qcom_glink 
*glink, unsigned int lcid)
channel->lcid = 0;
spin_unlock_irqrestore(>idr_lock, flags);
 
+   /* Decouple the potential rpdev from the channel */
+   if (channel->rpdev) {
+   strlcpy(chinfo.name, channel->name, sizeof(chinfo.name));
+   chinfo.src = RPMSG_ADDR_ANY;
+   chinfo.dst = RPMSG_ADDR_ANY;
+
+   rpmsg_unregister_device(glink->dev, );
+   }
+   channel->rpdev = NULL;
+
kref_put(>refcount, qcom_glink_channel_release);
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH V1 3/6] rpmsg: glink: Add TX_DATA_CONT command while sending

[Deepak Kumar Singh]

From: Arun Kumar Neelakantam 

With current design the transport can send packets of size upto
FIFO_SIZE which is 16k and return failure for all packets above 16k.

Add TX_DATA_CONT command to send packets greater than 16k by splitting
into 8K chunks.

Signed-off-by: Arun Kumar Neelakantam 
Signed-off-by: Deepak Kumar Singh 
---
 drivers/rpmsg/qcom_glink_native.c | 38 ++
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/rpmsg/qcom_glink_native.c 
b/drivers/rpmsg/qcom_glink_native.c
index df3c608..ac179b1 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -1289,6 +1289,8 @@ static int __qcom_glink_send(struct glink_channel 
*channel,
} __packed req;
int ret;
unsigned long flags;
+   int chunk_size = len;
+   int left_size = 0;
 
if (!glink->intentless) {
while (!intent) {
@@ -1322,18 +1324,46 @@ static int __qcom_glink_send(struct glink_channel 
*channel,
iid = intent->id;
}
 
+   if (wait && (chunk_size > SZ_8K)) {
+   chunk_size = SZ_8K;
+   left_size = len - chunk_size;
+   }
req.msg.cmd = cpu_to_le16(RPM_CMD_TX_DATA);
req.msg.param1 = cpu_to_le16(channel->lcid);
req.msg.param2 = cpu_to_le32(iid);
-   req.chunk_size = cpu_to_le32(len);
-   req.left_size = cpu_to_le32(0);
+   req.chunk_size = cpu_to_le32(chunk_size);
+   req.left_size = cpu_to_le32(left_size);
 
-   ret = qcom_glink_tx(glink, , sizeof(req), data, len, wait);
+   ret = qcom_glink_tx(glink, , sizeof(req), data, chunk_size, wait);
 
/* Mark intent available if we failed */
-   if (ret && intent)
+   if (ret && intent) {
intent->in_use = false;
+   return ret;
+   }
 
+   while (left_size > 0) {
+   data = (void *)((char *)data + chunk_size);
+   chunk_size = left_size;
+   if (chunk_size > SZ_8K)
+   chunk_size = SZ_8K;
+   left_size -= chunk_size;
+
+   req.msg.cmd = cpu_to_le16(RPM_CMD_TX_DATA_CONT);
+   req.msg.param1 = cpu_to_le16(channel->lcid);
+   req.msg.param2 = cpu_to_le32(iid);
+   req.chunk_size = cpu_to_le32(chunk_size);
+   req.left_size = cpu_to_le32(left_size);
+
+   ret = qcom_glink_tx(glink, , sizeof(req), data,
+   chunk_size, wait);
+
+   /* Mark intent available if we failed */
+   if (ret && intent) {
+   intent->in_use = false;
+   break;
+   }
+   }
return ret;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH V1 6/6] rpmsg: glink: Send READ_NOTIFY command in FIFO full case

[Deepak Kumar Singh]

From: Arun Kumar Neelakantam 

The current design sleeps unconditionally in TX FIFO full case and
wakeup only after sleep timer expires which adds random delays in
clients TX path.

Avoid sleep and use READ_NOTIFY command so that writer can be woken up
when remote notifies about read completion by sending IRQ.

Signed-off-by: Deepak Kumar Singh 
Signed-off-by: Arun Kumar Neelakantam 
---
 drivers/rpmsg/qcom_glink_native.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/rpmsg/qcom_glink_native.c 
b/drivers/rpmsg/qcom_glink_native.c
index efaf32d..098039d 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -92,6 +92,8 @@ struct glink_core_rx_intent {
  * @rcids: idr of all channels with a known remote channel id
  * @features:  remote features
  * @intentless:flag to indicate that there is no intent
+ * @tx_avail_notify: Waitqueue for pending tx tasks
+ * @sent_read_notify: flag to check cmd sent or not
  */
 struct qcom_glink {
struct device *dev;
@@ -118,6 +120,8 @@ struct qcom_glink {
unsigned long features;
 
bool intentless;
+   wait_queue_head_t tx_avail_notify;
+   bool sent_read_notify;
 };
 
 enum {
@@ -301,6 +305,20 @@ static void qcom_glink_tx_write(struct qcom_glink *glink,
glink->tx_pipe->write(glink->tx_pipe, hdr, hlen, data, dlen);
 }
 
+static void qcom_glink_send_read_notify(struct qcom_glink *glink)
+{
+   struct glink_msg msg;
+
+   msg.cmd = cpu_to_le16(RPM_CMD_READ_NOTIF);
+   msg.param1 = 0;
+   msg.param2 = 0;
+
+   qcom_glink_tx_write(glink, , sizeof(msg), NULL, 0);
+
+   mbox_send_message(glink->mbox_chan, NULL);
+   mbox_client_txdone(glink->mbox_chan, 0);
+}
+
 static int qcom_glink_tx(struct qcom_glink *glink,
 const void *hdr, size_t hlen,
 const void *data, size_t dlen, bool wait)
@@ -321,12 +339,21 @@ static int qcom_glink_tx(struct qcom_glink *glink,
goto out;
}
 
+   if (!glink->sent_read_notify) {
+   glink->sent_read_notify = true;
+   qcom_glink_send_read_notify(glink);
+   }
+
/* Wait without holding the tx_lock */
spin_unlock_irqrestore(>tx_lock, flags);
 
-   usleep_range(1, 15000);
+   wait_event_timeout(glink->tx_avail_notify,
+   qcom_glink_tx_avail(glink) >= tlen, 10 * HZ);
 
spin_lock_irqsave(>tx_lock, flags);
+
+   if (qcom_glink_tx_avail(glink) >= tlen)
+   glink->sent_read_notify = false;
}
 
qcom_glink_tx_write(glink, hdr, hlen, data, dlen);
@@ -1000,6 +1027,9 @@ static irqreturn_t qcom_glink_native_intr(int irq, void 
*data)
unsigned int cmd;
int ret = 0;
 
+   /* To wakeup any blocking writers */
+   wake_up_all(>tx_avail_notify);
+
for (;;) {
avail = qcom_glink_rx_avail(glink);
if (avail < sizeof(msg))
@@ -1542,6 +1572,9 @@ static void qcom_glink_rx_close_ack(struct qcom_glink 
*glink, unsigned int lcid)
struct glink_channel *channel;
unsigned long flags;
 
+   /* To wakeup any blocking writers */
+   wake_up_all(>tx_avail_notify);
+
spin_lock_irqsave(>idr_lock, flags);
channel = idr_find(>lcids, lcid);
if (WARN(!channel, "close ack on unknown channel\n")) {
@@ -1658,6 +1691,7 @@ struct qcom_glink *qcom_glink_native_probe(struct device 
*dev,
spin_lock_init(>rx_lock);
INIT_LIST_HEAD(>rx_queue);
INIT_WORK(>rx_work, qcom_glink_work);
+   init_waitqueue_head(>tx_avail_notify);
 
spin_lock_init(>idr_lock);
idr_init(>lcids);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH V1 5/6] rpmsg: glink: Remove channel decouple from rpdev release

[Deepak Kumar Singh]

From: Chris Lew 

If a channel is being rapidly restarting and the kobj release worker
is busy, there is a chance the the rpdev_release function will run
after the channel struct itself has been released.

There should not be a need to decouple the channel from rpdev in the
rpdev release since that should only happen from the close commands.

Signed-off-by: Chris Lew 
Signed-off-by: Deepak Kumar Singh 
---
 drivers/rpmsg/qcom_glink_native.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/rpmsg/qcom_glink_native.c 
b/drivers/rpmsg/qcom_glink_native.c
index 031bc1d..efaf32d 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -1419,9 +1419,7 @@ static const struct rpmsg_endpoint_ops glink_endpoint_ops 
= {
 static void qcom_glink_rpdev_release(struct device *dev)
 {
struct rpmsg_device *rpdev = to_rpmsg_device(dev);
-   struct glink_channel *channel = to_glink_channel(rpdev->ept);
 
-   channel->rpdev = NULL;
kfree(rpdev);
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH V1 1/6] rpmsg: glink: fix destroy channel endpoint logic

[Deepak Kumar Singh]

From: Konstantin Dorfman 

When rpmsg client driver destroys last channel endpoint, remove rpmsg
device is triggered. In both cases (destroy endpoint and remove device)
a glink close command sent to the remote peer.

This change, when for removing rpmsg device endpoint already destroyed
will avoid sending second glink close command.

Signed-off-by: Konstantin Dorfman 
Signed-off-by: Deepak Kumar Singh 
---
 drivers/rpmsg/qcom_glink_native.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/rpmsg/qcom_glink_native.c 
b/drivers/rpmsg/qcom_glink_native.c
index 1995f5b..2668c66 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -1210,6 +1210,10 @@ static void qcom_glink_destroy_ept(struct rpmsg_endpoint 
*ept)
unsigned long flags;
 
spin_lock_irqsave(>recv_lock, flags);
+   if (!channel->ept.cb) {
+   spin_unlock_irqrestore(>recv_lock, flags);
+   return;
+   }
channel->ept.cb = NULL;
spin_unlock_irqrestore(>recv_lock, flags);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH V1 0/6] Glink native fixes upstreaming

[Deepak Kumar Singh]

Includes fixes for -
Few race conditions while channel release and close
Proper unregistration of rpmsg device to avoid use of stale device
Send notify command to remote when glink fifo is full
Handling packet size larger that 16K

Arun Kumar Neelakantam (3):
  rpmsg: glink: Add TX_DATA_CONT command while sending
  rpmsg: glink: Remove the rpmsg dev in close_ack
  rpmsg: glink: Send READ_NOTIFY command in FIFO full case

Chris Lew (2):
  rpmsg: glink: Deny intent request if reusable intent fits
  rpmsg: glink: Remove channel decouple from rpdev release

Konstantin Dorfman (1):
  rpmsg: glink: fix destroy channel endpoint logic

 drivers/rpmsg/qcom_glink_native.c | 109 +++---
 1 file changed, 101 insertions(+), 8 deletions(-)

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

Re: [PATCH v5 0/6] Add support for GPU DDR BW scaling

[Viresh Kumar]

On 22-07-20, 11:00, Viresh Kumar wrote:
> On 21-07-20, 07:28, Rob Clark wrote:
> > With your ack, I can add the patch the dev_pm_opp_set_bw patch to my
> > tree and merge it via msm-next -> drm-next -> linus
> 
> I wanted to send it via my tree, but its okay. Pick this patch from
> linux-next and add my Ack, I will drop it after that.
> 
> a8351c12c6c7 OPP: Add and export helper to set bandwidth

Oops, sorry for the trouble but this needs to go via my tree only :(

I maintain two different branches, one for OPP and another one for
cpufreq. There was no dependency within the OPP branch and so I
dropped it that day and asked you to take it.

But when I tried to send a pull request today I realised that one of
the qcom patches in the cpufreq branch is dependent on it and I need
to keep this patch in my tree.

-- 
viresh

[PATCH] f2fs: make file immutable even if releasing zero compression block

[Daeho Jeong]

From: Daeho Jeong 

When we use F2FS_IOC_RELEASE_COMPRESS_BLOCKS ioctl, if we can't find
any compressed blocks in the file even with large file size, the
ioctl just ends up without changing the file's status as immutable.
It makes the user, who expects that the file is immutable when it
returns successfully, confused.

Signed-off-by: Daeho Jeong 
---
 fs/f2fs/file.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index cc7f5670390f..8a422400e824 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -3535,14 +3535,14 @@ static int f2fs_release_compress_blocks(struct file 
*filp, unsigned long arg)
if (ret)
goto out;
 
-   if (!F2FS_I(inode)->i_compr_blocks)
-   goto out;
-
F2FS_I(inode)->i_flags |= F2FS_IMMUTABLE_FL;
f2fs_set_inode_flags(inode);
inode->i_ctime = current_time(inode);
f2fs_mark_inode_dirty_sync(inode, true);
 
+   if (!F2FS_I(inode)->i_compr_blocks)
+   goto out;
+
down_write(_I(inode)->i_gc_rwsem[WRITE]);
down_write(_I(inode)->i_mmap_sem);
 
-- 
2.28.0.rc0.142.g3c755180ce-goog

Re: [PATCH v18 3/3] Input: new da7280 haptic driver

[Dmitry Torokhov]

On Wed, Jul 29, 2020 at 02:09:48PM +, Roy Im wrote:
> Hello Dmitry and Uwe,
> 
> Wednesday, July 29, 2020 3:37 PM, Dmitry Torokhov wrote: 
> 
> > On Wed, Jul 29, 2020 at 11:59:40AM +0900, Roy Im wrote:
> > > Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with multiple
> > > mode and integrated waveform memory and wideband support.
> > > It communicates via an I2C bus to the device.
> > 
> > A few questions/suggestions...
> > 
> > >
> > > Reviewed-by: Jes Sorensen .
> > >
> > > Signed-off-by: Roy Im 
> > >
> > > ---
> > > v18:
> > >   - Corrected comments in Kconfig
> > >   - Updated to preferred style for multi line comments in c file.
> > > v17:
> > >   - fixed an issue.
> > > v16:
> > >   - Corrected some code and updated description in Kconfig.
> > > v15:
> > >   - Removed some defines and updated some comments.
> > > v14:
> > >   - Updated pwm related code, alignments and comments.
> > > v13:
> > >   - Updated some conditions in pwm function and alignments.
> > > v12: No changes.
> > > v11:
> > >   - Updated the pwm related code, comments and typo.
> > > v10:
> > >   - Updated the pwm related function and added some comments.
> > > v9:
> > >   - Removed the header file and put the definitions into the c file.
> > >   - Updated the pwm code and error logs with %pE
> > 
> > I believe the %pE is to format an escaped buffer, you probably want to %pe 
> > (lowercase) to print errors. I am also not quite sure
> > if we want to use it in cases when we have non-pointer error, or we should 
> > stick with %d as most of the kernel does.
> 
> Right, it should be %pe as you and Uwe said, Uwe suggested %pe to understand 
> easier.. do you still prefer to stick with %d?

Depends on the situation. If you already have ERR_PTR-encoded error
there is no reason for not using %pe, but if you have integer error, or
you have already converted pointer to integer I'd prefer we stick with
%d.

As I mentioned in another message maybe we should consider adding '%de'
or similar for formatting integer errors.

Thanks.

-- 
Dmitry

Re: [PATCH v18 3/3] Input: new da7280 haptic driver

[Dmitry Torokhov]

Hi Uwe,

On Wed, Jul 29, 2020 at 09:21:45AM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> On Tue, Jul 28, 2020 at 11:36:38PM -0700, Dmitry Torokhov wrote:
> > > v9: 
> > >   - Removed the header file and put the definitions into the c file.
> > >   - Updated the pwm code and error logs with %pE
> > 
> > I believe the %pE is to format an escaped buffer, you probably want to
> > %pe (lowercase) to print errors. I am also not quite sure if we want to
> > use it in cases when we have non-pointer error, or we should stick with
> > %d as most of the kernel does.
> 
> compared with %d %pe is easier to understand as it emits "-ETIMEOUT"
> instead of "-110". And yes, %pE is wrong.

While I can see that symbolic name instead of a numeric constant might
be appealing, I do not believe that we want fragments like this with
endless conversions between integer and pointer errors:

if (haptics->const_op_mode == DA7280_PWM_MODE) {
haptics->pwm_dev = devm_pwm_get(dev, NULL);
if (IS_ERR(haptics->pwm_dev)) {
error = PTR_ERR(haptics->pwm_dev);
if (error != -EPROBE_DEFER)
dev_err(dev, "unable to request PWM: %pE\n",
ERR_PTR(error));
return error;
}

Maybe we should introduce something like '%de' for the integer error
case? In the meantime I would prefer using %d when we have integer
error. We should not see these error messages anyway ;)

Thanks.

-- 
Dmitry

INFO: task hung in pipe_write (4)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:26027945 Add linux-next specific files for 20200724
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15d5c5d890
kernel config:  https://syzkaller.appspot.com/x/.config?x=785eb1cc9c75f625
dashboard link: https://syzkaller.appspot.com/bug?extid=2bb1411e81c5c86571b6
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=16be896490

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+2bb1411e81c5c8657...@syzkaller.appspotmail.com

INFO: task syz-executor.0:16173 blocked for more than 143 seconds.
  Not tainted 5.8.0-rc6-next-20200724-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.0  D29144 16173  15761 0x
Call Trace:
 context_switch kernel/sched/core.c:3533 [inline]
 __schedule+0x908/0x21e0 kernel/sched/core.c:4289
 schedule+0xd0/0x2a0 kernel/sched/core.c:4364
 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:4423
 __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
 __mutex_lock+0x3e2/0x10d0 kernel/locking/mutex.c:1103
 __pipe_lock fs/pipe.c:87 [inline]
 pipe_write+0x12c/0x16c0 fs/pipe.c:435
 call_write_iter include/linux/fs.h:1883 [inline]
 new_sync_write+0x422/0x650 fs/read_write.c:515
 vfs_write+0x5c6/0x6f0 fs/read_write.c:595
 ksys_write+0x1ee/0x250 fs/read_write.c:648
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45c369
Code: Bad RIP value.
RSP: 002b:7fffaa3d45a8 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 00037380 RCX: 0045c369
RDX: 0208e24b RSI: 2040 RDI: 
RBP: 0078bf40 R08:  R09: 
R10:  R11: 0246 R12: 007903f0
R13:  R14: 0dce R15: 0078bf0c
INFO: task syz-executor.0:16251 blocked for more than 143 seconds.
  Not tainted 5.8.0-rc6-next-20200724-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.0  D29144 16251  15761 0x
Call Trace:
 context_switch kernel/sched/core.c:3533 [inline]
 __schedule+0x908/0x21e0 kernel/sched/core.c:4289
 schedule+0xd0/0x2a0 kernel/sched/core.c:4364
 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:4423
 __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
 __mutex_lock+0x3e2/0x10d0 kernel/locking/mutex.c:1103
 __pipe_lock fs/pipe.c:87 [inline]
 pipe_write+0x12c/0x16c0 fs/pipe.c:435
 call_write_iter include/linux/fs.h:1883 [inline]
 new_sync_write+0x422/0x650 fs/read_write.c:515
 vfs_write+0x5c6/0x6f0 fs/read_write.c:595
 ksys_write+0x1ee/0x250 fs/read_write.c:648
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45c369
Code: Bad RIP value.
RSP: 002b:7fffaa3d45a8 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 00037380 RCX: 0045c369
RDX: 0208e24b RSI: 2040 RDI: 
RBP: 0078bf40 R08:  R09: 
R10:  R11: 0246 R12: 007903f0
R13:  R14: 0dce R15: 0078bf0c
INFO: task syz-executor.0:16285 blocked for more than 143 seconds.
  Not tainted 5.8.0-rc6-next-20200724-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.0  D29144 16285  15761 0x
Call Trace:
 context_switch kernel/sched/core.c:3533 [inline]
 __schedule+0x908/0x21e0 kernel/sched/core.c:4289
 schedule+0xd0/0x2a0 kernel/sched/core.c:4364
 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:4423
 __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
 __mutex_lock+0x3e2/0x10d0 kernel/locking/mutex.c:1103
 __pipe_lock fs/pipe.c:87 [inline]
 pipe_write+0x12c/0x16c0 fs/pipe.c:435
 call_write_iter include/linux/fs.h:1883 [inline]
 new_sync_write+0x422/0x650 fs/read_write.c:515
 vfs_write+0x5c6/0x6f0 fs/read_write.c:595
 ksys_write+0x1ee/0x250 fs/read_write.c:648
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45c369
Code: Bad RIP value.
RSP: 002b:7fffaa3d45a8 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 00037380 RCX: 0045c369
RDX: 0208e24b RSI: 2040 RDI: 
RBP: 0078bf40 R08:  R09: 
R10:  R11: 0246 R12: 007903f0
R13:  R14: 0dce R15: 0078bf0c
INFO: task syz-executor.0:16290 blocked for more than 144 seconds.
  Not tainted 5.8.0-rc6-next-20200724-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.0  D30096 16290  15761 0x
Call Trace:
 

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

[Stephen Rothwell]

Hi Stephen,

On Thu, 30 Jul 2020 12:59:04 +1000 Stephen Rothwell  
wrote:
>
> Hi James,
> 
> On Thu, 30 Jul 2020 12:35:03 +1000 (AEST) James Morris  
> wrote:
> >
> > On Thu, 30 Jul 2020, Stephen Rothwell wrote:
> >   
> > > > I am still applying the above patch ...
> > > 
> > > The merge window is coming up fast ... is anything happening about this
> > > failure?
> > 
> > A new patch is coming, but I'm not sure this code has had enough review 
> > from the core VFS folk.
> > 
> > Please drop secure_uffd_v5.9 for the time being.  
> 
> You just need to remove/revert it from your security tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next-testing).

In today's linux-next I have reverted the three commits in that branch:

d08ac70b1e0d Wire UFFD up to SELinux
2b72259a271a Teach SELinux about anonymous inodes
2749d3f84a70 Add a new LSM-supporting anonymous inode interface

-- 
Cheers,
Stephen Rothwell


pgpQ28eD0aATv.pgp
Description: OpenPGP digital signature

Re: [PATCH v4] kvm,x86: Exit to user space in case page fault error

[Pankaj Gupta]

> Page fault error handling behavior in kvm seems little inconsistent when
> page fault reports error. If we are doing fault synchronously
> then we capture error (-EFAULT) returned by __gfn_to_pfn_memslot() and
> exit to user space and qemu reports error, "error: kvm run failed Bad 
> address".
>
> But if we are doing async page fault, then async_pf_execute() will simply
> ignore the error reported by get_user_pages_remote() or
> by kvm_mmu_do_page_fault(). It is assumed that page fault was successful
> and either a page ready event is injected in guest or guest is brought
> out of artificial halt state and run again. In both the cases when guest
> retries the instruction, it takes exit again as page fault was not
> successful in previous attempt. And then this infinite loop continues
> forever.
>
> Trying fault in a loop will make sense if error is temporary and will
> be resolved on retry. But I don't see any intention in the code to
> determine if error is temporary or not.  Whether to do fault synchronously
> or asynchronously, depends on so many variables but none of the varibales
s/varibales/variables
> is whether error is temporary or not. (kvm_can_do_async_pf()).
>
> And that makes it very inconsistent or unpredictable to figure out whether
> kvm will exit to qemu with error or it will just retry and go into an
> infinite loop.
>
> This patch tries to make this behavior consistent. That is instead of
> getting into infinite loop of retrying page fault, exit to user space
> and stop VM if page fault error happens.
>
> In future this can be improved by injecting errors into guest. As of
> now we don't have any race free method to inject errors in guest.
>
> When page fault error happens in async path save that pfn and when next
> time guest retries, do a sync fault instead of async fault. So that if error
> is encountered, we exit to qemu and avoid infinite loop.
>
> We maintain a cache of error gfns and force sync fault if a gfn is
> found in cache of error gfn. There is a small possibility that we
> miss an error gfn (as it got overwritten by a new error gfn). But
> its just a hint and sooner or later some error pfn will match
> and we will force sync fault and exit to user space.
>
> Changes from v3:
> - Added function kvm_find_and_remove_error_gfn() and removed
>   kvm_find_error_gfn() and kvm_del_error_gfn(). (Vitaly)
>
> - Added a macro GFN_INVALID (Vitaly).
>
> - Used gpa_to_gfn() to convert gpa to gfn (Vitaly)
>
> Change from v2:
> - Fixed a warning by converting kvm_find_error_gfn() static.
>
> Change from v1:
> - Maintain a cache of error gfns, instead of single gfn. (Vitaly)
>
> Signed-off-by: Vivek Goyal 
> ---
>  arch/x86/include/asm/kvm_host.h |  2 ++
>  arch/x86/kvm/mmu.h  |  2 +-
>  arch/x86/kvm/mmu/mmu.c  |  2 +-
>  arch/x86/kvm/x86.c  | 54 +++--
>  include/linux/kvm_types.h   |  1 +
>  5 files changed, 56 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index be5363b21540..e6f8d3f1a377 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -137,6 +137,7 @@ static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t 
> base_gfn, int level)
>  #define KVM_NR_VAR_MTRR 8
>
>  #define ASYNC_PF_PER_VCPU 64
> +#define ERROR_GFN_PER_VCPU 64
>
>  enum kvm_reg {
> VCPU_REGS_RAX = __VCPU_REGS_RAX,
> @@ -778,6 +779,7 @@ struct kvm_vcpu_arch {
> unsigned long nested_apf_token;
> bool delivery_as_pf_vmexit;
> bool pageready_pending;
> +   gfn_t error_gfns[ERROR_GFN_PER_VCPU];
> } apf;
>
> /* OSVW MSRs (AMD only) */
> diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
> index 444bb9c54548..d0a2a12c7bb6 100644
> --- a/arch/x86/kvm/mmu.h
> +++ b/arch/x86/kvm/mmu.h
> @@ -60,7 +60,7 @@ void kvm_init_mmu(struct kvm_vcpu *vcpu, bool reset_roots);
>  void kvm_init_shadow_mmu(struct kvm_vcpu *vcpu, u32 cr0, u32 cr4, u32 efer);
>  void kvm_init_shadow_ept_mmu(struct kvm_vcpu *vcpu, bool execonly,
>  bool accessed_dirty, gpa_t new_eptp);
> -bool kvm_can_do_async_pf(struct kvm_vcpu *vcpu);
> +bool kvm_can_do_async_pf(struct kvm_vcpu *vcpu, gfn_t gfn);
>  int kvm_handle_page_fault(struct kvm_vcpu *vcpu, u64 error_code,
> u64 fault_address, char *insn, int insn_len);
>
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 6d6a0ae7800c..b51d4aa405e0 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -4078,7 +4078,7 @@ static bool try_async_pf(struct kvm_vcpu *vcpu, bool 
> prefault, gfn_t gfn,
> if (!async)
> return false; /* *pfn has correct page already */
>
> -   if (!prefault && kvm_can_do_async_pf(vcpu)) {
> +   if (!prefault && kvm_can_do_async_pf(vcpu, gpa_to_gfn(cr2_or_gpa))) {
> 

Re: [PATCH v2 7/7] cpufreq: make schedutil the default for arm and arm64

[Viresh Kumar]

On 22-07-20, 10:37, Ionela Voinescu wrote:
> From: Valentin Schneider 
> 
> schedutil is already a hard-requirement for EAS, which has lead to making
> it default on arm (when CONFIG_BIG_LITTLE), see:
> 
>   commit 8fdcca8e254a ("cpufreq: Select schedutil when using big.LITTLE")
> 
> One thing worth pointing out is that schedutil isn't only relevant for
> asymmetric CPU capacity systems; for instance, schedutil is the only
> governor that honours util-clamp performance requests. Another good example
> of this is x86 switching to using it by default in:
> 
>   commit a00ec3874e7d ("cpufreq: intel_pstate: Select schedutil as the 
> default governor")
> 
> Arguably it should be made the default for all architectures, but it seems
> better to wait for them to also gain frequency invariance powers. Make it
> the default for arm && arm64 for now.
> 
> Signed-off-by: Valentin Schneider 
> Signed-off-by: Ionela Voinescu 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Russell King 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> ---
>  drivers/cpufreq/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index e91750132552..2c7171e0b001 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -37,7 +37,7 @@ config CPU_FREQ_STAT
>  choice
>   prompt "Default CPUFreq governor"
>   default CPU_FREQ_DEFAULT_GOV_USERSPACE if ARM_SA1100_CPUFREQ || 
> ARM_SA1110_CPUFREQ
> - default CPU_FREQ_DEFAULT_GOV_SCHEDUTIL if BIG_LITTLE
> + default CPU_FREQ_DEFAULT_GOV_SCHEDUTIL if ARM64 || ARM
>   default CPU_FREQ_DEFAULT_GOV_SCHEDUTIL if X86_INTEL_PSTATE && SMP
>   default CPU_FREQ_DEFAULT_GOV_PERFORMANCE
>   help

Applied. Thanks.

-- 
viresh

Re: [PATCH v3 5/6] platform/input: cros_ec: Replace -ENOTSUPP with -ENOPROTOOPT

[Dmitry Torokhov]

On Sun, Jul 26, 2020 at 03:01:00PM -0700, Guenter Roeck wrote:
> -ENOTSUPP is not a SUSV4 error code and should not be used. Use
> -ENOPROTOOPT instead to report EC_RES_INVALID_VERSION responses
> from the EC. This matches match the NFS response for unsupported
> protocol versions.
> 
> Cc: Gwendal Grignou 
> Cc: Yu-Hsuan Hsu 
> Cc: Prashant Malani 
> Cc: Brian Norris 
> Signed-off-by: Guenter Roeck 

Acked-by: Dmitry Torokhov 

for the input bit.

> ---
> v3: Added patch
> 
>  drivers/input/keyboard/cros_ec_keyb.c   | 2 +-
>  drivers/platform/chrome/cros_ec_proto.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c 
> b/drivers/input/keyboard/cros_ec_keyb.c
> index fc1793ca2f17..15d17c717081 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -348,7 +348,7 @@ static int cros_ec_keyb_info(struct cros_ec_device 
> *ec_dev,
>   params->event_type = event_type;
>  
>   ret = cros_ec_cmd_xfer_status(ec_dev, msg);
> - if (ret == -ENOTSUPP) {
> + if (ret == -ENOPROTOOPT) {
>   /* With older ECs we just return 0 for everything */
>   memset(result, 0, result_size);
>   ret = 0;
> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index 3e745e0fe092..e5bbec979a2a 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -555,7 +555,7 @@ EXPORT_SYMBOL(cros_ec_cmd_xfer);
>   *
>   * Return:
>   * >=0 - The number of bytes transferred
> - * -ENOTSUPP - Operation not supported
> + * -ENOPROTOOPT - Operation not supported
>   * -EPROTO - Protocol error
>   */
>  int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
> @@ -569,7 +569,7 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
>   } else if (msg->result == EC_RES_INVALID_VERSION) {
>   dev_dbg(ec_dev->dev, "Command invalid version (err:%d)\n",
>   msg->result);
> - return -ENOTSUPP;
> + return -ENOPROTOOPT;
>   } else if (msg->result != EC_RES_SUCCESS) {
>   dev_dbg(ec_dev->dev, "Command result (err: %d)\n", msg->result);
>   return -EPROTO;
> -- 
> 2.17.1
> 

-- 
Dmitry

回复: KASAN: use-after-free Read in delete_and_unsubscribe_port (2)

[Zhang, Qiang]

发件人: linux-kernel-ow...@vger.kernel.org  代表 
syzbot 
发送时间: 2020年7月30日 11:33
收件人: alsa-devel-ow...@alsa-project.org; alsa-de...@alsa-project.org; 
linux-kernel@vger.kernel.org; pe...@perex.cz; syzkaller-b...@googlegroups.com; 
ti...@suse.com
主题: Re: KASAN: use-after-free Read in delete_and_unsubscribe_port (2)

syzbot has found a reproducer for the following issue on:

HEAD commit:d3590ebf Merge tag 'audit-pr-20200729' of git://git.kernel..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1207e0b890
kernel config:  https://syzkaller.appspot.com/x/.config?x=812bbfcb6ae2cd60
dashboard link: https://syzkaller.appspot.com/bug?extid=1a54a94bd32716796edd
compiler:   clang version 10.0.0 (https://github.com/llvm/llvm-project/ 
c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11b227f890

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1a54a94bd32716796...@syzkaller.appspotmail.com

==
BUG: KASAN: use-after-free in list_empty include/linux/list.h:282 [inline]
BUG: KASAN: use-after-free in delete_and_unsubscribe_port+0x8b/0x450 
sound/core/seq/seq_ports.c:530
Read of size 8 at addr 888098523060 by task syz-executor.0/7202

CPU: 1 PID: 7202 Comm: syz-executor.0 Not tainted 5.8.0-rc7-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+0x1f0/0x31e 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
 list_empty include/linux/list.h:282 [inline]


 It 's looks likely "subs->ref_count" problem.


 delete_and_unsubscribe_port+0x8b/0x450 sound/core/seq/seq_ports.c:530
 snd_seq_port_disconnect+0x568/0x610 sound/core/seq/seq_ports.c:612
 snd_seq_ioctl_unsubscribe_port+0x349/0x6c0 sound/core/seq/seq_clientmgr.c:1525
 snd_seq_oss_midi_close+0x397/0x620 sound/core/seq/oss/seq_oss_midi.c:405
 snd_seq_oss_synth_reset+0x335/0x8b0 sound/core/seq/oss/seq_oss_synth.c:406
 snd_seq_oss_reset+0x5b/0x250 sound/core/seq/oss/seq_oss_init.c:435
 snd_seq_oss_ioctl+0x5c2/0x1090 sound/core/seq/oss/seq_oss_ioctl.c:93
 odev_ioctl+0x51/0x70 sound/core/seq/oss/seq_oss.c:174
 vfs_ioctl fs/ioctl.c:48 [inline]
 ksys_ioctl fs/ioctl.c:753 [inline]
 __do_sys_ioctl fs/ioctl.c:762 [inline]
 __se_sys_ioctl+0xf9/0x160 fs/ioctl.c:760
 do_syscall_64+0x73/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45c429
Code: 8d b6 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 
5b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f6e48930c78 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 000154c0 RCX: 0045c429
RDX:  RSI: 5100 RDI: 0003
RBP: 0078bf38 R08:  R09: 
R10:  R11: 0246 R12: 0078bf0c
R13: 7ffe51b9d10f R14: 7f6e489319c0 R15: 0078bf0c

Allocated by task 7202:
 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]
 snd_seq_port_connect+0x66/0x460 sound/core/seq/seq_ports.c:553
 snd_seq_ioctl_subscribe_port+0x349/0x6c0 sound/core/seq/seq_clientmgr.c:1484
 snd_seq_oss_midi_open+0x4db/0x830 sound/core/seq/oss/seq_oss_midi.c:364
 snd_seq_oss_synth_setup_midi+0x108/0x510 sound/core/seq/oss/seq_oss_synth.c:269
 snd_seq_oss_open+0x899/0xe90 sound/core/seq/oss/seq_oss_init.c:261
 odev_open+0x5e/0x90 sound/core/seq/oss/seq_oss.c:125
 chrdev_open+0x498/0x580 fs/char_dev.c:414
 do_dentry_open+0x813/0x1070 fs/open.c:828
 do_open fs/namei.c:3243 [inline]
 path_openat+0x278d/0x37f0 fs/namei.c:3360
 do_filp_open+0x191/0x3a0 fs/namei.c:3387
 do_sys_openat2+0x463/0x770 fs/open.c:1179
 do_sys_open fs/open.c:1195 [inline]
 __do_sys_openat fs/open.c:1209 [inline]
 __se_sys_openat fs/open.c:1204 [inline]
 __x64_sys_openat+0x1c8/0x1f0 fs/open.c:1204
 do_syscall_64+0x73/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Freed by task 7203:
 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
 snd_seq_port_disconnect+0x570/0x610 sound/core/seq/seq_ports.c:614
 snd_seq_ioctl_unsubscribe_port+0x349/0x6c0 sound/core/seq/s

Re: [PATCH v2 4/7] cpufreq: report whether cpufreq supports Frequency Invariance (FI)

[Viresh Kumar]

On 22-07-20, 10:37, Ionela Voinescu wrote:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 3497c1cd6818..1d0b046fe8e9 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -61,6 +61,9 @@ static struct cpufreq_driver *cpufreq_driver;
>  static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
>  static DEFINE_RWLOCK(cpufreq_driver_lock);
>  
> +/* Mark support for the scheduler's frequency invariance engine */
> +static DEFINE_STATIC_KEY_FALSE(cpufreq_set_freq_scale);
> +
>  /* Flag to suspend/resume CPUFreq governors */
>  static bool cpufreq_suspended;
>  
> @@ -69,6 +72,25 @@ static inline bool has_target(void)
>   return cpufreq_driver->target_index || cpufreq_driver->target;
>  }
>  
> +static inline
> +void enable_cpufreq_freq_invariance(struct cpufreq_driver *driver)
> +{
> + if ((driver->target || driver->target_index || driver->fast_switch) &&
> + !driver->setpolicy) {

Just checking for !driver->setpolicy should be enough here.

> + static_branch_enable_cpuslocked(_set_freq_scale);
> + pr_debug("%s: Driver %s can provide frequency invariance.",
> +  __func__, driver->name);

I think a simpler print will work well too.

pr_debug("Freq invariance enabled");

__func__ isn't really required as this is the only print with that
kind of info in cpufreq.c.

> + } else
> + pr_err("%s: Driver %s cannot provide frequency invariance.",
> + __func__, driver->name);

Why not supporting freq-invariance an error ? I will just drop this
message completely.

-- 
viresh

Re: [PATCH] dax: Fix wrong error-number passed into xas_set_err()

[Pankaj Gupta]

> The error-number passed into xas_set_err() should be negative. Otherwise,
> the xas_error() will return 0, and grab_mapping_entry() will return the
> found entry instead of a SIGBUS error when the entry is not a value.
> And then, the subsequent code path would be wrong.
>
> Signed-off-by: Hao Li 
> ---
>  fs/dax.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 11b16729b86f..acac675fe7a6 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -488,7 +488,7 @@ static void *grab_mapping_entry(struct xa_state *xas,
> if (dax_is_conflict(entry))
> goto fallback;
> if (!xa_is_value(entry)) {
> -   xas_set_err(xas, EIO);
> +   xas_set_err(xas, -EIO);
> goto out_unlock;
> }
>
> --

Reviewed-by: Pankaj Gupta 

> 2.28.0
>
>
> ___
> Linux-nvdimm mailing list -- linux-nvd...@lists.01.org
> To unsubscribe send an email to linux-nvdimm-le...@lists.01.org

Re: [PATCH v2] PCI/P2PDMA: Allow P2PDMA on all AMD CPUs newer than the Zen family

[Alex Deucher]

On Wed, Jul 29, 2020 at 7:18 PM Logan Gunthorpe  wrote:
>
> In order to avoid needing to add every new AMD CPU host bridge to the list
> every cycle, allow P2PDMA if the CPUs vendor is AMD and family is
> greater than 0x17 (Zen).

Might want to say "greater than or equal to" to clarify that all Zen
parts (Zen1, Zen2, etc.) support p2p.  With that clarified,
Reviewed-by: Alex Deucher 

>
> This should cut down a bunch of the churn adding to the list of allowed
> host bridges.
>
> Signed-off-by: Logan Gunthorpe 
> Cc: Bjorn Helgaas 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: Huang Rui 
>
> ---
>
> Here's a reworked patch to enable P2PDMA on Zen2 (and in fact all
> subsequent Zen platforms).
>
> This should remove all the churn on the list for the AMD side. Still
> don't have a good solution for Intel.
>
>  drivers/pci/p2pdma.c | 26 --
>  1 file changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index e8e444eeb1cd..f1cab2c50595 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -273,6 +273,24 @@ static void seq_buf_print_bus_devfn(struct seq_buf *buf, 
> struct pci_dev *pdev)
> seq_buf_printf(buf, "%s;", pci_name(pdev));
>  }
>
> +#ifdef CONFIG_X86
> +static bool cpu_supports_p2pdma(void)
> +{
> +   struct cpuinfo_x86 *c = _data(0);
> +
> +   /* Any AMD CPU who's family id is newer than Zen will support p2pdma 
> */
> +   if (c->x86_vendor == X86_VENDOR_AMD && c->x86 >= 0x17)
> +   return true;
> +
> +   return false;
> +}
> +#else
> +static bool cpu_supports_p2pdma(void)
> +{
> +   return false;
> +}
> +#endif
> +
>  static const struct pci_p2pdma_whitelist_entry {
> unsigned short vendor;
> unsigned short device;
> @@ -280,11 +298,6 @@ static const struct pci_p2pdma_whitelist_entry {
> REQ_SAME_HOST_BRIDGE= 1 << 0,
> } flags;
>  } pci_p2pdma_whitelist[] = {
> -   /* AMD ZEN */
> -   {PCI_VENDOR_ID_AMD, 0x1450, 0},
> -   {PCI_VENDOR_ID_AMD, 0x15d0, 0},
> -   {PCI_VENDOR_ID_AMD, 0x1630, 0},
> -
> /* Intel Xeon E5/Core i7 */
> {PCI_VENDOR_ID_INTEL,   0x3c00, REQ_SAME_HOST_BRIDGE},
> {PCI_VENDOR_ID_INTEL,   0x3c01, REQ_SAME_HOST_BRIDGE},
> @@ -473,7 +486,8 @@ upstream_bridge_distance(struct pci_dev *provider, struct 
> pci_dev *client,
>   acs_redirects, acs_list);
>
> if (map_type == PCI_P2PDMA_MAP_THRU_HOST_BRIDGE) {
> -   if (!host_bridge_whitelist(provider, client))
> +   if (!cpu_supports_p2pdma() &&
> +   !host_bridge_whitelist(provider, client))
> map_type = PCI_P2PDMA_MAP_NOT_SUPPORTED;
> }
>
>
> base-commit: 92ed301919932f13b9172e525674157e983d
> --
> 2.20.1

Re: [PATCH v1 4/6] mm/page_isolation: cleanup set_migratetype_isolate()

[Pankaj Gupta]

> Let's clean it up a bit, simplifying error handling and getting rid of
> the label.
>
> Cc: Andrew Morton 
> Cc: Michal Hocko 
> Cc: Michael S. Tsirkin 
> Signed-off-by: David Hildenbrand 
> ---
>  mm/page_isolation.c | 18 +++---
>  1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index 02a01bff6b219..5f869bef23fa4 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -17,12 +17,9 @@
>
>  static int set_migratetype_isolate(struct page *page, int migratetype, int 
> isol_flags)
>  {
> -   struct page *unmovable = NULL;
> -   struct zone *zone;
> +   struct zone *zone = page_zone(page);
> +   struct page *unmovable;
> unsigned long flags;
> -   int ret = -EBUSY;
> -
> -   zone = page_zone(page);
>
> spin_lock_irqsave(>lock, flags);
>
> @@ -51,21 +48,20 @@ static int set_migratetype_isolate(struct page *page, int 
> migratetype, int isol_
> NULL);
>
> __mod_zone_freepage_state(zone, -nr_pages, mt);
> -   ret = 0;
> +   spin_unlock_irqrestore(>lock, flags);
> +   drain_all_pages(zone);
> +   return 0;
> }
>
> -out:
> spin_unlock_irqrestore(>lock, flags);
> -   if (!ret) {
> -   drain_all_pages(zone);
> -   } else if ((isol_flags & REPORT_FAILURE) && unmovable)
> +   if (isol_flags & REPORT_FAILURE)
> /*
>  * printk() with zone->lock held will likely trigger a
>  * lockdep splat, so defer it here.
>  */
> dump_page(unmovable, "unmovable page");
>
> -   return ret;
> +   return -EBUSY;
>  }
>
>  static void unset_migratetype_isolate(struct page *page, unsigned 
> migratetype)
> --

This clean up looks good to me.

Reviewed-by: Pankaj Gupta 

> 2.26.2
>
>

Re: [PATCH v2 3/7] arch_topology: disable frequency invariance for CONFIG_BL_SWITCHER

[Viresh Kumar]

On 22-07-20, 10:37, Ionela Voinescu wrote:
> +++ b/drivers/base/arch_topology.c
> @@ -27,6 +27,7 @@ __weak bool arch_freq_counters_available(struct cpumask 
> *cpus)
>  }
>  DEFINE_PER_CPU(unsigned long, freq_scale) = SCHED_CAPACITY_SCALE;
>  
> +#ifndef CONFIG_BL_SWITCHER
>  void arch_set_freq_scale(struct cpumask *cpus, unsigned long cur_freq,
>unsigned long max_freq)
>  {
> @@ -46,6 +47,7 @@ void arch_set_freq_scale(struct cpumask *cpus, unsigned 
> long cur_freq,
>   for_each_cpu(i, cpus)
>   per_cpu(freq_scale, i) = scale;
>  }
> +#endif

I don't really like this change, the ifdef hackery is disgusting and
then we are putting that in a completely different part of the kernel.

There are at least these two ways of solving this, maybe more:

- Fix the bl switcher driver and add the complexity in it (which you
  tried to do earlier).

- Add a cpufreq flag to skip arch-set-freq-scale call.

Rafael ?

-- 
viresh

Re: [PATCH v1 2/6] mm/page_isolation: don't dump_page(NULL) in set_migratetype_isolate()

[Pankaj Gupta]

> Right now, if we have two isolations racing, we might trigger the
> WARN_ON_ONCE() and to dump_page(NULL), dereferencing NULL. Let's just
> return directly.
>
> In the future, we might want to report -EAGAIN to the caller instead, as
> this could indicate a temporary isolation failure only.
>
> Cc: Andrew Morton 
> Cc: Michal Hocko 
> Cc: Michael S. Tsirkin 
> Signed-off-by: David Hildenbrand 
> ---
>  mm/page_isolation.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index f6d07c5f0d34d..553b49a34cf71 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -29,10 +29,12 @@ static int set_migratetype_isolate(struct page *page, int 
> migratetype, int isol_
> /*
>  * We assume the caller intended to SET migrate type to isolate.
>  * If it is already set, then someone else must have raced and
> -* set it before us.  Return -EBUSY
> +* set it before us.
>  */
> -   if (is_migrate_isolate_page(page))
> -   goto out;
> +   if (is_migrate_isolate_page(page)) {
> +   spin_unlock_irqrestore(>lock, flags);
> +   return -EBUSY;
> +   }
>
> /*
>  * FIXME: Now, memory hotplug doesn't call shrink_slab() by itself.
> --

Reviewed-by: Pankaj Gupta 

> 2.26.2
>
>

[PATCH 2/2] Input: atmel_mxt_ts - output status from T42 Touch Suppression

[Jiada Wang]

From: Nick Dyer 

This patch outputs status from T42 touch suppression

Signed-off-by: Nick Dyer 
Acked-by: Benson Leung 
Acked-by: Yufeng Shen 
(cherry picked from ndyer/linux/for-upstream commit 
ab95b5a30d2c098daaa9f88d9fcfae7eb516)
Signed-off-by: George G. Davis 
[jiada: Replace dev_info() with dev_dbg(),
Move logical continuation to previous line to address checkpatch CHECK]
Signed-off-by: Jiada Wang 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 25 
 1 file changed, 25 insertions(+)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 729c8dcb9cd1..b260f8c70c11 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -160,6 +160,9 @@ struct t37_debug {
 #define MXT_T48_MSG_NOISESUP_STATCHG   BIT(4)
 #define MXT_T48_MSG_NOISESUP_NLVLCHG   BIT(5)
 
+/* Define for MXT_PROCI_TOUCHSUPPRESSION_T42 */
+#define MXT_T42_MSG_TCHSUP BIT(0)
+
 /* T100 Multiple Touch Touchscreen */
 #define MXT_T100_CTRL  0
 #define MXT_T100_CFG1  1
@@ -326,6 +329,8 @@ struct mxt_data {
u8 T9_reportid_min;
u8 T9_reportid_max;
u8 T19_reportid;
+   u8 T42_reportid_min;
+   u8 T42_reportid_max;
u16 T44_address;
u8 T48_reportid;
u8 T100_reportid_min;
@@ -960,6 +965,17 @@ static void mxt_proc_t100_message(struct mxt_data *data, 
u8 *message)
data->update_input = true;
 }
 
+static void mxt_proc_t42_messages(struct mxt_data *data, u8 *msg)
+{
+   struct device *dev = >client->dev;
+   u8 status = msg[1];
+
+   if (status & MXT_T42_MSG_TCHSUP)
+   dev_dbg(dev, "T42 suppress\n");
+   else
+   dev_dbg(dev, "T42 normal\n");
+}
+
 static int mxt_proc_t48_messages(struct mxt_data *data, u8 *msg)
 {
struct device *dev = >client->dev;
@@ -987,6 +1003,9 @@ static int mxt_proc_message(struct mxt_data *data, u8 
*message)
 
if (report_id == data->T6_reportid) {
mxt_proc_t6_messages(data, message);
+   } else if (report_id >= data->T42_reportid_min &&
+  report_id <= data->T42_reportid_max) {
+   mxt_proc_t42_messages(data, message);
} else if (report_id == data->T48_reportid) {
mxt_proc_t48_messages(data, message);
} else if (!data->input_dev) {
@@ -1633,6 +1652,8 @@ static void mxt_free_object_table(struct mxt_data *data)
data->T9_reportid_min = 0;
data->T9_reportid_max = 0;
data->T19_reportid = 0;
+   data->T42_reportid_min = 0;
+   data->T42_reportid_max = 0;
data->T44_address = 0;
data->T48_reportid = 0;
data->T100_reportid_min = 0;
@@ -1707,6 +1728,10 @@ static int mxt_parse_object_table(struct mxt_data *data,
object->num_report_ids - 1;
data->num_touchids = object->num_report_ids;
break;
+   case MXT_PROCI_TOUCHSUPPRESSION_T42:
+   data->T42_reportid_min = min_id;
+   data->T42_reportid_max = max_id;
+   break;
case MXT_SPT_MESSAGECOUNT_T44:
data->T44_address = object->start_address;
break;
-- 
2.17.1

[PATCH 1/2] Input: atmel_mxt_ts - output status from T48 Noise Suppression

[Jiada Wang]

From: Nick Dyer 

This patch outputs status from T48 Noise Suppression

Signed-off-by: Nick Dyer 
Acked-by: Benson Leung 
Acked-by: Yufeng Shen 
(cherry picked from ndyer/linux/for-upstream commit 
2895a6ff150a49f27a02938f8d262be238b296d8)
Signed-off-by: George G. Davis 
[jiada: Replace bits with symbolic names,
Fixed typo in commit title & message]
Signed-off-by: Jiada Wang 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index a2189739e30f..729c8dcb9cd1 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -153,6 +153,13 @@ struct t37_debug {
 #define MXT_RESET_VALUE0x01
 #define MXT_BACKUP_VALUE   0x55
 
+/* Define for MXT_PROCG_NOISESUPPRESSION_T48 */
+#define MXT_T48_MSG_NOISESUP_FREQCHG   BIT(0)
+#define MXT_T48_MSG_NOISESUP_APXCHGBIT(1)
+#define MXT_T48_MSG_NOISESUP_ALGOERR   BIT(2)
+#define MXT_T48_MSG_NOISESUP_STATCHG   BIT(4)
+#define MXT_T48_MSG_NOISESUP_NLVLCHG   BIT(5)
+
 /* T100 Multiple Touch Touchscreen */
 #define MXT_T100_CTRL  0
 #define MXT_T100_CFG1  1
@@ -320,6 +327,7 @@ struct mxt_data {
u8 T9_reportid_max;
u8 T19_reportid;
u16 T44_address;
+   u8 T48_reportid;
u8 T100_reportid_min;
u8 T100_reportid_max;
 
@@ -952,6 +960,24 @@ static void mxt_proc_t100_message(struct mxt_data *data, 
u8 *message)
data->update_input = true;
 }
 
+static int mxt_proc_t48_messages(struct mxt_data *data, u8 *msg)
+{
+   struct device *dev = >client->dev;
+   u8 status, state;
+
+   status = msg[1];
+   state  = msg[4];
+
+   dev_dbg(dev, "T48 state %d status %02X %s%s%s%s%s\n", state, status,
+   status & MXT_T48_MSG_NOISESUP_FREQCHG ? "FREQCHG " : "",
+   status & MXT_T48_MSG_NOISESUP_APXCHG ? "APXCHG " : "",
+   status & MXT_T48_MSG_NOISESUP_ALGOERR ? "ALGOERR " : "",
+   status & MXT_T48_MSG_NOISESUP_STATCHG ? "STATCHG " : "",
+   status & MXT_T48_MSG_NOISESUP_NLVLCHG ? "NLVLCHG " : "");
+
+   return 0;
+}
+
 static int mxt_proc_message(struct mxt_data *data, u8 *message)
 {
u8 report_id = message[0];
@@ -961,6 +987,8 @@ static int mxt_proc_message(struct mxt_data *data, u8 
*message)
 
if (report_id == data->T6_reportid) {
mxt_proc_t6_messages(data, message);
+   } else if (report_id == data->T48_reportid) {
+   mxt_proc_t48_messages(data, message);
} else if (!data->input_dev) {
/*
 * Do not report events if input device
@@ -1606,6 +1634,7 @@ static void mxt_free_object_table(struct mxt_data *data)
data->T9_reportid_max = 0;
data->T19_reportid = 0;
data->T44_address = 0;
+   data->T48_reportid = 0;
data->T100_reportid_min = 0;
data->T100_reportid_max = 0;
data->max_reportid = 0;
@@ -1684,6 +1713,9 @@ static int mxt_parse_object_table(struct mxt_data *data,
case MXT_SPT_GPIOPWM_T19:
data->T19_reportid = min_id;
break;
+   case MXT_PROCG_NOISESUPPRESSION_T48:
+   data->T48_reportid = min_id;
+   break;
case MXT_TOUCH_MULTITOUCHSCREEN_T100:
data->multitouch = MXT_TOUCH_MULTITOUCHSCREEN_T100;
data->T100_reportid_min = min_id;
-- 
2.17.1

Re: [PATCH] Revert "Bluetooth: btusb: Disable runtime suspend on Realtek devices"

[Kai-Heng Feng]

Hi Abhishek,

> On Jul 30, 2020, at 07:17, Abhishek Pandit-Subedi 
>  wrote:
> 
> This reverts commit 7ecacafc240638148567742cca41aa7144b4fe1e.
> 
> Testing this change on a board with RTL8822CE, I found that enabling
> autosuspend has no effect on the stability of the system. The board
> continued working after autosuspend, suspend and reboot.

The original issue was found on 8723DE. Do you have one to test with?
The rtw88 codebase has changed a lot and maybe it's already fixed in mainline.
Let me do some test and I'll report back.

> 
> The original commit makes it impossible to enable autosuspend on working
> systems so it should be reverted. Disabling autosuspend should be done
> via module param or udev in userspace instead.
> 
> Signed-off-by: Abhishek Pandit-Subedi 
> ---
> We have a few Chromebooks using the RTL 8822CE part over USB and they
> are running without problems with autosuspend enabled. While bringing up
> a new board, I found some power regressions that I was able to narrow
> down to this change so I'm requesting a revert.
> 
> I tested this on Hp Chromebook 14a (running 4.14 kernel and 5.4 kernel)
> with this revert:
> * Enabled autosuspend, used it normally with a HID device
> * Suspended the Chromebook and verified it worked normally on resume
> * Rebooted the Chromebook and verified Bluetooth was working on next
>  boot
> 
> I didn't see the issue that was originally reported with this fix. For
> the original reporter, if you're still seeing this issue, there are
> other ways to disable autosuspend for your device:
> * set module param: enable_autosuspend=0
> * change your kconfig so BT_HCIBTUSB_AUTOSUSPEND=n
> * use a udev rule to disable autosuspend for specific vid:pid
> 
> Keeping this change in the kernel makes it impossible to enable
> autosuspend so it should be reverted.

It's apparently a driver/firmware/hardware issue, so the fix should keep inside 
the kernel.
However, the fix can be more precise and target only 8723DE.

Kai-Heng

> 
> drivers/bluetooth/btusb.c | 4 
> 1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 1f51494f581812..8d2608ddfd0875 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -4086,10 +4086,6 @@ static int btusb_probe(struct usb_interface *intf,
>   set_bit(BTUSB_USE_ALT1_FOR_WBS, >flags);
>   else
>   bt_dev_err(hdev, "Device does not support ALT setting 
> 1");
> -
> - err = usb_autopm_get_interface(intf);
> - if (err < 0)
> - goto out_free_dev;
>   }
> 
>   if (!reset)
> -- 
> 2.28.0.rc0.142.g3c755180ce-goog
> 

Re: [PATCH v2 2/7] cpufreq: set invariance scale factor on transition end

[Viresh Kumar]

On 22-07-20, 10:37, Ionela Voinescu wrote:
> While the move of the invariance setter calls (arch_set_freq_scale())
> from cpufreq drivers to cpufreq core maintained the previous
> functionality for existing drivers that use target_index() and
> fast_switch() for frequency switching, it also gives the possibility
> of adding support for users of the target() callback, which is exploited
> here.
> 
> To be noted that the target() callback has been flagged as deprecated
> since:
> 
> commit 9c0ebcf78fde ("cpufreq: Implement light weight ->target_index() 
> routine")
> 
> It also doesn't have that many users:
> 
>   cpufreq-nforce2.c:371:2:  .target = nforce2_target,
>   cppc_cpufreq.c:416:2: .target = cppc_cpufreq_set_target,
>   gx-suspmod.c:439:2:   .target = cpufreq_gx_target,
>   pcc-cpufreq.c:573:2:  .target = pcc_cpufreq_target,
> 
> Similarly to the path taken for target_index() calls in the cpufreq core
> during a frequency change, all of the drivers above will mark the end of a
> frequency change by a call to cpufreq_freq_transition_end().
> 
> Therefore, cpufreq_freq_transition_end() can be used as the location for
> the arch_set_freq_scale() call to potentially inform the scheduler of the
> frequency change.
> 
> This change maintains the previous functionality for the drivers that
> implement the target_index() callback, while also adding support for the
> few drivers that implement the deprecated target() callback.
> 
> Two notes are worthwhile here:
>  - In __target_index(), cpufreq_freq_transition_end() is called only for
>drivers that have synchronous notifications enabled. There is only one
>driver that disables them,
> 
>drivers/cpufreq/powernow-k8.c:1142: .flags = CPUFREQ_ASYNC_NOTIFICATION,
> 
>which is deprecated.

I don't think this is deprecated.

-- 
viresh

[PATCH] cpufreq: cached_resolved_idx can not be negative

[Viresh Kumar]

It is not possible for cached_resolved_idx to be invalid here as the
cpufreq core always sets index to a positive value.

Change its type to unsigned int and fix qcom usage a bit.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/qcom-cpufreq-hw.c | 5 +
 include/linux/cpufreq.h   | 2 +-
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c 
b/drivers/cpufreq/qcom-cpufreq-hw.c
index 0a04b6f03b9a..8c0842bd6c5a 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -66,13 +66,10 @@ static unsigned int qcom_cpufreq_hw_fast_switch(struct 
cpufreq_policy *policy,
unsigned int target_freq)
 {
void __iomem *perf_state_reg = policy->driver_data;
-   int index;
+   unsigned int index;
unsigned long freq;
 
index = policy->cached_resolved_idx;
-   if (index < 0)
-   return 0;
-
writel_relaxed(index, perf_state_reg);
 
freq = policy->freq_table[index].frequency;
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index e62b022cb07e..58687a5bf9c8 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -127,7 +127,7 @@ struct cpufreq_policy {
 
 /* Cached frequency lookup from cpufreq_driver_resolve_freq. */
unsigned int cached_target_freq;
-   int cached_resolved_idx;
+   unsigned int cached_resolved_idx;
 
/* Synchronization for frequency transitions */
booltransition_ongoing; /* Tracks transition status 
*/
-- 
2.14.1

RE: [PATCH -next] irqchip/imx-intmux: Fix irqdata regs save in imx_intmux_runtime_suspend()

[Joakim Zhang]

> -Original Message-
> From: Marc Zyngier 
> Sent: 2020年7月30日 1:00
> To: Wei Yongjun 
> Cc: Hulk Robot ; Thomas Gleixner ;
> Jason Cooper ; Shawn Guo ;
> Sascha Hauer ; Joakim Zhang
> ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH -next] irqchip/imx-intmux: Fix irqdata regs save in
> imx_intmux_runtime_suspend()
> 
> On 2020-07-29 16:58, Wei Yongjun wrote:
> > Gcc report warning as follows:
> >
> > drivers/irqchip/irq-imx-intmux.c:316:29: warning:
> >  variable 'irqchip_data' set but not used [-Wunused-but-set-variable]
> >   316 |  struct intmux_irqchip_data irqchip_data;
> >   | ^~~~
> >
> > irqdata regs is stored to this variable on the stack in
> > imx_intmux_runtime_suspend(), which means a nop. this commit fix to
> > save regs to the right place.
> >
> > Fixes: bb403111e017 ("irqchip/imx-intmux: Implement intmux runtime
> > power management")
> > Reported-by: Hulk Robot 
> > Signed-off-by: Wei Yongjun 
> > ---
> >  drivers/irqchip/irq-imx-intmux.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)

[...]
> Amazing. Thanks for fixing this.
> 
> Johakim: I guess this was never tested, was it?


Hi Marc,

Firstly, thanks Wei Yongjun for fixing this.

I do the intmux function test for each version.

At my side, I test intmux with CAN device. This intmux in M4 core subsystem, 
devices located in M4 core subsystem will route irqs into intmux.
CAN transceiver is controlled by an I/O expander which is lined to I2C from M4 
core subsystem. And CAN device is located in A35 core subsystem.

After implementing runtime pm, I test CAN work fine when do suspend/resume test 
and I check the runtime status. I guess intmux register's state will not lost 
in M4 core subsystem when system suspended.

However, this is a silly mistake, I am so sorry for this.

Best Regards,
Joakim Zhang
>  M.
> --
> Jazz is not dead. It just smells funny...

[PATCH] soc: mediatek: Check if power domains can be powered on at boot time

[Nicolas Boichat]

In the error case, where a power domain cannot be powered on
successfully at boot time (in mtk_register_power_domains),
pm_genpd_init would still be called with is_off=false, and the
system would later try to disable the power domain again, triggering
warnings as disabled clocks are disabled again (and other potential
issues).

Fixes: c84e358718a66f7 ("soc: Mediatek: Add SCPSYS power domain driver")
Signed-off-by: Nicolas Boichat 

---

 drivers/soc/mediatek/mtk-scpsys.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index f669d3754627dad..0055a52a49733d5 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -524,6 +524,7 @@ static void mtk_register_power_domains(struct 
platform_device *pdev,
for (i = 0; i < num; i++) {
struct scp_domain *scpd = >domains[i];
struct generic_pm_domain *genpd = >genpd;
+   bool on;
 
/*
 * Initially turn on all domains to make the domains usable
@@ -531,9 +532,9 @@ static void mtk_register_power_domains(struct 
platform_device *pdev,
 * software.  The unused domains will be switched off during
 * late_init time.
 */
-   genpd->power_on(genpd);
+   on = genpd->power_on(genpd) >= 0;
 
-   pm_genpd_init(genpd, NULL, false);
+   pm_genpd_init(genpd, NULL, !on);
}
 
/*
-- 
2.28.0.rc0.142.g3c755180ce-goog

[tip:x86/urgent] BUILD SUCCESS bdd65589593edd79b6a12ce86b3b7a7c6dae5208

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
x86/urgent
branch HEAD: bdd65589593edd79b6a12ce86b3b7a7c6dae5208  x86/i8259: Use 
printk_deferred() to prevent deadlock

elapsed time: 722m

configs tested: 65
configs skipped: 46

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

arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
i386defconfig
sparcallyesconfig
sparc   defconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a004-20200729
x86_64   randconfig-a005-20200729
x86_64   randconfig-a002-20200729
x86_64   randconfig-a006-20200729
x86_64   randconfig-a003-20200729
x86_64   randconfig-a001-20200729
i386 randconfig-a003-20200729
i386 randconfig-a004-20200729
i386 randconfig-a005-20200729
i386 randconfig-a002-20200729
i386 randconfig-a006-20200729
i386 randconfig-a001-20200729
i386 randconfig-a016-20200729
i386 randconfig-a012-20200729
i386 randconfig-a013-20200729
i386 randconfig-a014-20200729
i386 randconfig-a011-20200729
i386 randconfig-a015-20200729
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

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

[PATCH v5 3/4] LSM: Define SELinux function to measure state and policy

[Lakshmi Ramasubramanian]

SELinux configuration and policy are some of the critical data for this
security module that needs to be measured. This measurement can be used
by an attestation service, for instance, to verify if the configuration
and policies have been setup correctly and that they haven't been tampered
with at runtime.

Measure SELinux configuration, policy capabilities settings, and the
loaded policy by calling the IMA hooks ima_measure_lsm_state() and
ima_measure_lsm_policy() respectively.

Sample measurement of SELinux state and hash of the policy:

10 e32e...5ac3 ima-buf sha256:86e8...4594 selinux-state-1595389364:287899386 
696e697469616c697a65643d313b656e61626c65643d313b656e666f7263696e673d303b636865636b72657170726f743d313b6e6574776f726b5f706565725f636f6e74726f6c733d313b6f70656e5f7065726d733d313b657874656e6465645f736f636b65745f636c6173733d313b616c776179735f636865636b5f6e6574776f726b3d303b6367726f75705f7365636c6162656c3d313b6e6e705f6e6f737569645f7472616e736974696f6e3d313b67656e66735f7365636c6162656c5f73796d6c696e6b733d303
10 f4a7...9408 ima-ng sha256:8d1d...1834 
selinux-policy-hash-1595389353:863934271

To verify the measurement check the following:

Execute the following command to extract the measured data
from the IMA log for SELinux configuration (selinux-state).

  grep -m 1 "selinux-state" 
/sys/kernel/security/integrity/ima/ascii_runtime_measurements | cut -d' ' -f 6 
| xxd -r -p

The output should be the list of key-value pairs. For example,
 
initialized=1;enabled=1;enforcing=0;checkreqprot=1;network_peer_controls=1;open_perms=1;extended_socket_class=1;always_check_network=0;cgroup_seclabel=1;nnp_nosuid_transition=1;genfs_seclabel_symlinks=0;

To verify the measured data with the current SELinux state:

 => enabled should be set to 1 if /sys/fs/selinux folder exists,
0 otherwise

For other entries, compare the integer value in the files
 => /sys/fs/selinux/enforce
 => /sys/fs/selinux/checkreqprot
And, each of the policy capabilities files under
 => /sys/fs/selinux/policy_capabilities

For selinux-policy-hash, the hash of SELinux policy is included
in the IMA log entry.

To verify the measured data with the current SELinux policy run
the following commands and verify the output hash values match.

  sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1

  grep -m 1 "selinux-policy-hash" 
/sys/kernel/security/integrity/ima/ascii_runtime_measurements | cut -d' ' -f 4

Signed-off-by: Lakshmi Ramasubramanian 
Suggested-by: Stephen Smalley 
Reported-by: kernel test robot  # error: implicit declaration 
of function 'vfree'
Reported-by: kernel test robot  # error: implicit declaration 
of function 'crypto_alloc_shash'
Reported-by: kernel test robot  # sparse: symbol 
'security_read_selinux_policy' was not declared. Should it be static?
---
 security/selinux/Makefile   |   2 +
 security/selinux/hooks.c|   1 +
 security/selinux/include/security.h |  15 +++
 security/selinux/measure.c  | 150 
 security/selinux/selinuxfs.c|   3 +
 security/selinux/ss/services.c  |  71 +++--
 6 files changed, 233 insertions(+), 9 deletions(-)
 create mode 100644 security/selinux/measure.c

diff --git a/security/selinux/Makefile b/security/selinux/Makefile
index 4d8e0e8adf0b..83d512116341 100644
--- a/security/selinux/Makefile
+++ b/security/selinux/Makefile
@@ -16,6 +16,8 @@ selinux-$(CONFIG_NETLABEL) += netlabel.o
 
 selinux-$(CONFIG_SECURITY_INFINIBAND) += ibpkey.o
 
+selinux-$(CONFIG_IMA) += measure.o
+
 ccflags-y := -I$(srctree)/security/selinux 
-I$(srctree)/security/selinux/include
 
 $(addprefix $(obj)/,$(selinux-y)): $(obj)/flask.h
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index efa6108b1ce9..5521dfc1900b 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7394,6 +7394,7 @@ int selinux_disable(struct selinux_state *state)
}
 
selinux_mark_disabled(state);
+   selinux_measure_state(state);
 
pr_info("SELinux:  Disabled at runtime.\n");
 
diff --git a/security/selinux/include/security.h 
b/security/selinux/include/security.h
index b0e02cfe3ce1..77f42d9b544b 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -222,16 +222,31 @@ static inline bool 
selinux_policycap_genfs_seclabel_symlinks(void)
return state->policycap[POLICYDB_CAPABILITY_GENFS_SECLABEL_SYMLINKS];
 }
 
+static inline bool selinux_checkreqprot(const struct selinux_state *state)
+{
+   return READ_ONCE(state->checkreqprot);
+}
+
 int security_mls_enabled(struct selinux_state *state);
 int security_load_policy(struct selinux_state *state,
 void *data, size_t len);
 int security_read_policy(struct selinux_state *state,
 void **data, size_t *len);
+int security_read_policy_kernel(struct selinux_state *state,
+   void **data, size_t *len);
 size_t security_policydb_len(struct selinux_state 

[PATCH v5 0/4] LSM: Measure security module data

[Lakshmi Ramasubramanian]

Critical data structures of security modules are currently not measured.
Therefore an attestation service, for instance, would not be able to
attest whether the security modules are always operating with the policies
and configuration that the system administrator had setup. The policies
and configuration for the security modules could be tampered with by
malware by exploiting kernel vulnerabilities or modified through some
inadvertent actions on the system. Measuring such critical data would
enable an attestation service to better assess the state of the system.

IMA subsystem measures system files, command line arguments passed to
kexec, boot aggregate, keys, etc. It can be used to measure critical
data structures of security modules as well.

This change aims to address measuring critical data structures
of security modules when they are initialized and when they are
updated at runtime.

This series is based on commit 3db0d0c276a7 ("integrity: remove
redundant initialization of variable ret") in next-integrity

Change log:

  v5:
  => Append timestamp to "event name" string in the call to
 the IMA hooks so that LSM data is always measured by IMA.
  => Removed workqueue patch that was handling periodic checking
 of the LSM data. This change will be introduced as a separate
 patch set while keeping this patch set focussed on measuring
 the LSM data on initialization and on updates at runtime.
  => Handle early boot measurement of LSM data.

  v4:
  => Added LSM_POLICY func and IMA hook to measure LSM policy.
  => Pass SELinux policy data, instead of the hash of the policy,
 to the IMA hook to measure.
  => Include "initialized" flag in SELinux measurement.
 Also, measure SELinux state even when initialization is not yet
 completed. But measure SELinux policy only after initialization.

  v3:
  => Loop through policy_capabilities to build the state data
 to measure instead of hardcoding to current set of
 policy capabilities.
  => Added error log messages for failure conditions.

  v2:
  => Pass selinux_state struct as parameter to the function
 that measures SELinux data.
  => Use strings from selinux_policycap_names array for SELinux
 state measurement.
  => Refactored security_read_policy() to alloc kernel or user
 virtual memory and then read the SELinux policy.

  v1:
  => Per Stephen Smalley's suggestion added selinux_state booleans
 and hash of SELinux policy in the measured data for SELinux.
  => Call IMA hook from the security module directly instead of
 redirecting through the LSM.

Lakshmi Ramasubramanian (4):
  IMA: Add func to measure LSM state and policy
  IMA: Define IMA hooks to measure LSM state and policy
  LSM: Define SELinux function to measure state and policy
  IMA: Handle early boot data measurement

 Documentation/ABI/testing/ima_policy |   9 +
 include/linux/ima.h  |  14 ++
 security/integrity/ima/Kconfig   |   5 +-
 security/integrity/ima/Makefile  |   2 +-
 security/integrity/ima/ima.h |  45 +++--
 security/integrity/ima/ima_api.c |   2 +-
 security/integrity/ima/ima_asymmetric_keys.c |   6 +-
 security/integrity/ima/ima_init.c|   2 +-
 security/integrity/ima/ima_main.c|  64 ++-
 security/integrity/ima/ima_policy.c  |  33 +++-
 security/integrity/ima/ima_queue_data.c  | 175 +++
 security/integrity/ima/ima_queue_keys.c  | 174 --
 security/selinux/Makefile|   2 +
 security/selinux/hooks.c |   1 +
 security/selinux/include/security.h  |  15 ++
 security/selinux/measure.c   | 150 
 security/selinux/selinuxfs.c |   3 +
 security/selinux/ss/services.c   |  71 +++-
 18 files changed, 551 insertions(+), 222 deletions(-)
 create mode 100644 security/integrity/ima/ima_queue_data.c
 delete mode 100644 security/integrity/ima/ima_queue_keys.c
 create mode 100644 security/selinux/measure.c

-- 
2.27.0

[PATCH v5 2/4] IMA: Define IMA hooks to measure LSM state and policy

[Lakshmi Ramasubramanian]

IMA subsystem needs to define IMA hooks that the security modules can
call to measure state and policy data.

Define two new IMA hooks, namely ima_lsm_state() and ima_lsm_policy(),
that the security modules can call to measure LSM state and LSM policy
respectively. Return the status of the measurement operation from these
two IMA hooks.

Signed-off-by: Lakshmi Ramasubramanian 
---
 include/linux/ima.h   | 14 +
 security/integrity/ima/ima.h  |  6 ++--
 security/integrity/ima/ima_main.c | 50 ++-
 3 files changed, 60 insertions(+), 10 deletions(-)

diff --git a/include/linux/ima.h b/include/linux/ima.h
index d15100de6cdd..442ca0dce3c8 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -26,6 +26,10 @@ extern int ima_post_read_file(struct file *file, void *buf, 
loff_t size,
 extern void ima_post_path_mknod(struct dentry *dentry);
 extern int ima_file_hash(struct file *file, char *buf, size_t buf_size);
 extern void ima_kexec_cmdline(int kernel_fd, const void *buf, int size);
+extern int ima_measure_lsm_state(const char *lsm_event_name, const void *buf,
+int size);
+extern int ima_measure_lsm_policy(const char *lsm_event_name, const void *buf,
+ int size);
 
 #ifdef CONFIG_IMA_KEXEC
 extern void ima_add_kexec_buffer(struct kimage *image);
@@ -104,6 +108,16 @@ static inline int ima_file_hash(struct file *file, char 
*buf, size_t buf_size)
 }
 
 static inline void ima_kexec_cmdline(int kernel_fd, const void *buf, int size) 
{}
+static inline int ima_measure_lsm_state(const char *lsm_event_name,
+   const void *buf, int size)
+{
+   return -EOPNOTSUPP;
+}
+static inline int ima_measure_lsm_policy(const char *lsm_event_name,
+const void *buf, int size)
+{
+   return -EOPNOTSUPP;
+}
 #endif /* CONFIG_IMA */
 
 #ifndef CONFIG_IMA_KEXEC
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 1b5f4b2f17d0..8ed9f5e1dd40 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -267,9 +267,9 @@ void ima_store_measurement(struct integrity_iint_cache 
*iint, struct file *file,
   struct evm_ima_xattr_data *xattr_value,
   int xattr_len, const struct modsig *modsig, int pcr,
   struct ima_template_desc *template_desc);
-void process_buffer_measurement(struct inode *inode, const void *buf, int size,
-   const char *eventname, enum ima_hooks func,
-   int pcr, const char *keyring);
+int process_buffer_measurement(struct inode *inode, const void *buf, int size,
+  const char *eventname, enum ima_hooks func,
+  int pcr, const char *keyring);
 void ima_audit_measurement(struct integrity_iint_cache *iint,
   const unsigned char *filename);
 int ima_alloc_init_template(struct ima_event_data *event_data,
diff --git a/security/integrity/ima/ima_main.c 
b/security/integrity/ima/ima_main.c
index 8a91711ca79b..74d421e40c8f 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -736,9 +736,9 @@ int ima_load_data(enum kernel_load_data_id id)
  *
  * Based on policy, the buffer is measured into the ima log.
  */
-void process_buffer_measurement(struct inode *inode, const void *buf, int size,
-   const char *eventname, enum ima_hooks func,
-   int pcr, const char *keyring)
+int process_buffer_measurement(struct inode *inode, const void *buf, int size,
+  const char *eventname, enum ima_hooks func,
+  int pcr, const char *keyring)
 {
int ret = 0;
const char *audit_cause = "ENOMEM";
@@ -758,7 +758,7 @@ void process_buffer_measurement(struct inode *inode, const 
void *buf, int size,
u32 secid;
 
if (!ima_policy_flag)
-   return;
+   return 0;
 
/*
 * Both LSM hooks and auxilary based buffer measurements are
@@ -772,7 +772,7 @@ void process_buffer_measurement(struct inode *inode, const 
void *buf, int size,
action = ima_get_action(inode, current_cred(), secid, 0, func,
, , keyring);
if (!(action & IMA_MEASURE))
-   return;
+   return 0;
}
 
if (!pcr)
@@ -787,7 +787,7 @@ void process_buffer_measurement(struct inode *inode, const 
void *buf, int size,
pr_err("template %s init failed, result: %d\n",
   (strlen(template->name) ?
template->name : template->fmt), ret);
-   return;
+   return ret;
}
}
 
@@ 

[PATCH v5 1/4] IMA: Add func to measure LSM state and policy

[Lakshmi Ramasubramanian]

Critical data structures of security modules need to be measured to
enable an attestation service to verify if the configuration and
policies for the security modules have been setup correctly and
that they haven't been tampered with at runtime. A new IMA policy is
required for handling this measurement.

Define two new IMA policy func namely LSM_STATE and LSM_POLICY to
measure the state and the policy provided by the security modules.
Update ima_match_rules() and ima_validate_rule() to check for
the new func and ima_parse_rule() to handle the new func.

Signed-off-by: Lakshmi Ramasubramanian 
---
 Documentation/ABI/testing/ima_policy |  9 
 security/integrity/ima/ima.h |  2 ++
 security/integrity/ima/ima_api.c |  2 +-
 security/integrity/ima/ima_policy.c  | 31 
 4 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/Documentation/ABI/testing/ima_policy 
b/Documentation/ABI/testing/ima_policy
index cd572912c593..b7c7fb548c0c 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -30,6 +30,7 @@ Description:
[FIRMWARE_CHECK]
[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
[KEXEC_CMDLINE] [KEY_CHECK]
+   [LSM_STATE] [LSM_POLICY]
mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
   [[^]MAY_EXEC]
fsmagic:= hex value
@@ -125,3 +126,11 @@ Description:
keys added to .builtin_trusted_keys or .ima keyring:
 
measure func=KEY_CHECK 
keyrings=.builtin_trusted_keys|.ima
+
+   Example of measure rule using LSM_STATE to measure LSM state:
+
+   measure func=LSM_STATE template=ima-buf
+
+   Example of measure rule using LSM_POLICY to measure LSM policy:
+
+   measure func=LSM_POLICY template=ima-ng
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 38043074ce5e..1b5f4b2f17d0 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -200,6 +200,8 @@ static inline unsigned int ima_hash_key(u8 *digest)
hook(POLICY_CHECK, policy)  \
hook(KEXEC_CMDLINE, kexec_cmdline)  \
hook(KEY_CHECK, key)\
+   hook(LSM_STATE, lsm_state)  \
+   hook(LSM_POLICY, lsm_policy)\
hook(MAX_CHECK, none)
 
 #define __ima_hook_enumify(ENUM, str)  ENUM,
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index 4f39fb93f278..8c8b4e4a6493 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -176,7 +176,7 @@ void ima_add_violation(struct file *file, const unsigned 
char *filename,
  * subj=, obj=, type=, func=, mask=, fsmagic=
  * subj,obj, and type: are LSM specific.
  * func: FILE_CHECK | BPRM_CHECK | CREDS_CHECK | MMAP_CHECK | MODULE_CHECK
- * | KEXEC_CMDLINE | KEY_CHECK
+ * | KEXEC_CMDLINE | KEY_CHECK | LSM_STATE | LSM_POLICY
  * mask: contains the permission mask
  * fsmagic: hex value
  *
diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index 07f033634b27..a0f5c39d9084 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -442,13 +442,20 @@ static bool ima_match_rules(struct ima_rule_entry *rule, 
struct inode *inode,
 {
int i;
 
-   if (func == KEY_CHECK) {
-   return (rule->flags & IMA_FUNC) && (rule->func == func) &&
-  ima_match_keyring(rule, keyring, cred);
-   }
if ((rule->flags & IMA_FUNC) &&
(rule->func != func && func != POST_SETATTR))
return false;
+
+   switch (func) {
+   case KEY_CHECK:
+   return ima_match_keyring(rule, keyring, cred);
+   case LSM_STATE:
+   case LSM_POLICY:
+   return true;
+   default:
+   break;
+   }
+
if ((rule->flags & IMA_MASK) &&
(rule->mask != mask && func != POST_SETATTR))
return false;
@@ -1044,6 +1051,18 @@ static bool ima_validate_rule(struct ima_rule_entry 
*entry)
if (ima_rule_contains_lsm_cond(entry))
return false;
 
+   break;
+   case LSM_STATE:
+   case LSM_POLICY:
+   if (entry->action & ~(MEASURE | DONT_MEASURE))
+   return false;
+
+   if (entry->flags & ~(IMA_FUNC | IMA_PCR))
+   return false;
+
+   if (ima_rule_contains_lsm_cond(entry))
+   return false;
+
break;
default:
return false;
@@ -1176,6 +1195,10 @@ static int ima_parse_rule(char *rule, struct 
ima_rule_entry 

[PATCH v5 4/4] IMA: Handle early boot data measurement

[Lakshmi Ramasubramanian]

The current implementation of early boot measurement in
the IMA subsystem is very specific to asymmetric keys. It does not
handle measurement of other data such as Linux Security Module (LSM)
data. Since most security modules are initialized very early in
the boot cycle, data provided by those modules are not measured
by IMA. Any other subsystem that initializes early in the boot cycle
and needs IMA to measure their data would suffer from the same issue.

Update the early boot key measurement to handle any early boot data.
Change the kernel configuration CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS to
CONFIG_IMA_QUEUE_EARLY_BOOT_DATA so it can be used for enabling
early boot data measurement. Change this new configuration to support
SECURITY subsystem in addition to KEYS subsystem, which is currently
supported. This can be extended to include more subsystems in the future
by updating this kernel configuration.

Update LSM hooks namely ima_measure_lsm_state() and ima_measure_lsm_policy
to utilize early boot measurement support.

Signed-off-by: Lakshmi Ramasubramanian 
---
 security/integrity/ima/Kconfig   |   5 +-
 security/integrity/ima/Makefile  |   2 +-
 security/integrity/ima/ima.h |  37 ++--
 security/integrity/ima/ima_asymmetric_keys.c |   6 +-
 security/integrity/ima/ima_init.c|   2 +-
 security/integrity/ima/ima_main.c|  22 ++-
 security/integrity/ima/ima_policy.c  |   2 +-
 security/integrity/ima/ima_queue_data.c  | 175 +++
 security/integrity/ima/ima_queue_keys.c  | 174 --
 9 files changed, 223 insertions(+), 202 deletions(-)
 create mode 100644 security/integrity/ima/ima_queue_data.c
 delete mode 100644 security/integrity/ima/ima_queue_keys.c

diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 080c53545ff0..86cba844f73c 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -322,10 +322,9 @@ config IMA_MEASURE_ASYMMETRIC_KEYS
depends on ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y
default y
 
-config IMA_QUEUE_EARLY_BOOT_KEYS
+config IMA_QUEUE_EARLY_BOOT_DATA
bool
-   depends on IMA_MEASURE_ASYMMETRIC_KEYS
-   depends on SYSTEM_TRUSTED_KEYRING
+   depends on SECURITY || (IMA_MEASURE_ASYMMETRIC_KEYS && 
SYSTEM_TRUSTED_KEYRING)
default y
 
 config IMA_SECURE_AND_OR_TRUSTED_BOOT
diff --git a/security/integrity/ima/Makefile b/security/integrity/ima/Makefile
index 67dabca670e2..cbbbc9848d2f 100644
--- a/security/integrity/ima/Makefile
+++ b/security/integrity/ima/Makefile
@@ -13,4 +13,4 @@ ima-$(CONFIG_IMA_APPRAISE_MODSIG) += ima_modsig.o
 ima-$(CONFIG_HAVE_IMA_KEXEC) += ima_kexec.o
 ima-$(CONFIG_IMA_BLACKLIST_KEYRING) += ima_mok.o
 ima-$(CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS) += ima_asymmetric_keys.o
-ima-$(CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS) += ima_queue_keys.o
+ima-$(CONFIG_IMA_QUEUE_EARLY_BOOT_DATA) += ima_queue_data.o
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 8ed9f5e1dd40..ebe4d9bb2f2b 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -229,29 +229,34 @@ extern const char *const func_tokens[];
 
 struct modsig;
 
-#ifdef CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS
+#ifdef CONFIG_IMA_QUEUE_EARLY_BOOT_DATA
 /*
- * To track keys that need to be measured.
+ * To track data that needs to be measured.
  */
-struct ima_key_entry {
+struct ima_data_entry {
struct list_head list;
void *payload;
size_t payload_len;
-   char *keyring_name;
+   const char *event_name;
+   const char *event_data;
+   enum ima_hooks func;
 };
-void ima_init_key_queue(void);
-bool ima_should_queue_key(void);
-bool ima_queue_key(struct key *keyring, const void *payload,
-  size_t payload_len);
-void ima_process_queued_keys(void);
+void ima_init_data_queue(void);
+bool ima_should_queue_data(void);
+bool ima_queue_data(const char *event_name, const void *payload,
+   size_t payload_len, const char *event_data,
+   enum ima_hooks func);
+void ima_process_queued_data(void);
 #else
-static inline void ima_init_key_queue(void) {}
-static inline bool ima_should_queue_key(void) { return false; }
-static inline bool ima_queue_key(struct key *keyring,
-const void *payload,
-size_t payload_len) { return false; }
-static inline void ima_process_queued_keys(void) {}
-#endif /* CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS */
+static inline void ima_init_data_queue(void) {}
+static inline bool ima_should_queue_data(void) { return false; }
+static inline bool ima_queue_data(const char *event_name,
+ const void *payload,
+ size_t payload_len,
+ const char *event_data,
+ enum ima_hooks func) { return false; }
+static inline void 

Re: [PATCH v2] mm: vmstat: fix /proc/sys/vm/stat_refresh generating false warnings

[Hugh Dickins]

On Tue, 14 Jul 2020, Roman Gushchin wrote:

> I've noticed a number of warnings like "vmstat_refresh: nr_free_cma
> -5" or "vmstat_refresh: nr_zone_write_pending -11" on our production
> hosts. The numbers of these warnings were relatively low and stable,
> so it didn't look like we are systematically leaking the counters.
> The corresponding vmstat counters also looked sane.

nr_zone_write_pending: yes, I've looked at our machines, and see that
showing up for us too (-49 was the worst I saw).  Not at all common,
but seen.  And not followed by increasingly worse numbers, so a state
that corrects itself.  nr_dirty too (fewer instances, bigger numbers);
but never nr_writeback, which you'd expect to go along with those.

I wish I could explain that (I've wondered if somewhere delays
incrementing the stat, and can be interrupted by the decrementer of
the stat before it has reached incrementing), but have not succeeded.
Perhaps it is all down to the vmstat_refresh() skid that you hide in
this patch; but I'm not convinced.

> 
> These warnings are generated by the vmstat_refresh() function, which
> assumes that atomic zone and numa counters can't go below zero.
> However, on a SMP machine it's not quite right: due to per-cpu
> caching it can in theory be as low as -(zone threshold) * NR_CPUs.
> 
> For instance, let's say all cma pages are in use and NR_FREE_CMA_PAGES
> reached 0. Then we've reclaimed a small number of cma pages on each
> CPU except CPU0, so that most percpu NR_FREE_CMA_PAGES counters are
> slightly positive (the atomic counter is still 0). Then somebody on
> CPU0 consumes all these pages. The number of pages can easily exceed
> the threshold and a negative value will be committed to the atomic
> counter.
> 
> To fix the problem and avoid generating false warnings, let's just
> relax the condition and warn only if the value is less than minus
> the maximum theoretically possible drift value, which is 125 *
> number of online CPUs. It will still allow to catch systematic leaks,
> but will not generate bogus warnings.

Sorry, but despite the acks of others, I want to NAK this in its
present form.

You're right that there's a possibility of a spurious warning,
but is that so terrible?

I'm imagining a threshold of 125, and 128 cpus, and the following
worst case.  Yes, it is possible that when vmstat_refresh() schedules
its refresh on all the cpus, that the first 127 cpus to complete all
sync a count of 0, but immediately after each allocates 125 of whatever
(raising their per-cpu counters without touching the global counter);
and then, before the 128th cpu starts its sync, somehow that 128th
gets to be the lucky cpu to free all of those 127*125 items,
so arriving at a mistaken count of -15875 for that stat.

And I guess you could even devise a test which conspires to do that.
But is it so likely, that it's worth throwing away the warning when
we leak (or perhaps it's unleak) 16000 huge pages?  I don't think so:
I think it makes those warnings pretty much useless, and it would be
better just to delete the code that issues them.

But there's other things you could do, that we can probably agree on.

When stat_refresh first went in, there were two stats (NR_ALLOC_BATCH
and NR_PAGES_SCANNED) which were peculiarly accounted, and gave rise
to negative reports: the original commit just filtered those cases out
in a switch.  Maybe you should filter out NR_ZONE_WRITE_PENDING and
NR_FREE_CMA_PAGES, if there's nothing to fix in their accounting.

I'm not sure exactly what your objection is to the warning: would
you prefer pr_info or pr_debug to pr_warn?  I'd prefer to leave it
as pr_warn, but can compromise.

(IIRC xfstests can fail a test if an unexpected message appears
in the log; but xfstests does not use /proc/sys/vm/stat_refresh.)

But a better idea is perhaps to redefine the behavior of
"echo >/proc/sys/vm/stat_refresh".  What if
"echo someparticularstring >/proc/sys/vm/stat_refresh" were to
disable or enable the warning (permanently? or just that time?):
disable would be more "back-compatible", but I think it's okay
if you prefer enable.  Or "someparticularstring" could actually
specify the warning threshold you want to use - you might echo
125 or 16000, I might echo 0.  We can haggle over the default.

And there's a simpler change we already made internally: we didn't
mind the warning at all, but the accompanying -EINVALs became very
annoying.  A lot of testing scripts have "set -e" in them, and for
test B of feature B to fail because earlier test A of feature A
had tickled a bug in A that wrapped some stat negative, that
was very irritating.  We deleted those "err = -EINVAL;"s -
which might be what's actually most annoying you too?

Nit in this patch called out below.

Hugh

> 
> Signed-off-by: Roman Gushchin 
> Cc: Hugh Dickins 
> ---
>  Documentation/admin-guide/sysctl/vm.rst |  4 ++--
>  mm/vmstat.c | 30 -
>  2 files changed, 21 insertions(+), 

Re: [PATCH v2 1/7] cpufreq: move invariance setter calls in cpufreq core

[Viresh Kumar]

On 27-07-20, 15:48, Rafael J. Wysocki wrote:
> On Wed, Jul 22, 2020 at 11:38 AM Ionela Voinescu
>  wrote:
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 036f4cc42ede..bac4101546db 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -2058,9 +2058,16 @@ EXPORT_SYMBOL(cpufreq_unregister_notifier);
> >  unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
> > unsigned int target_freq)
> >  {
> > +   unsigned int freq;
> > +
> > target_freq = clamp_val(target_freq, policy->min, policy->max);
> > +   freq = cpufreq_driver->fast_switch(policy, target_freq);
> > +
> > +   if (freq)
> > +   arch_set_freq_scale(policy->related_cpus, freq,
> > +   policy->cpuinfo.max_freq);
> 
> Why can't arch_set_freq_scale() handle freq == 0?

Actually there is no need to. AFAIU the freq returned by fast_switch
can never be 0 (yeah qcom driver does it right now and I am fixing
it). And so we can drop this check altogether.

-- 
viresh

Re: [RFC PATCH] iomap: add support to track dirty state of sub pages

[yukuai (C)]

On 2020/7/30 11:19, Matthew Wilcox wrote:

Maybe let the discussion on removing the ->uptodate array finish
before posting another patch for review?


Hi, Matthew!

Of course, I missed the discussion thread before sending this path.
And thanks for your suggestions.

Best regards,
Yu Kuai

Re: [PATCH v2] usb: typec: tcpm: Migrate workqueue to RT priority for processing events

[Badhri Jagan Sridharan]

Hi Guenter,

I see that Hans is saying that he has submitted some patch here.
https://lore.kernel.org/lkml/65f27abc-69c8-3877-be5b-e5e478153...@redhat.com/
But, haven't found the actual patches yet !

Thanks,
Badhri

On Wed, Jul 29, 2020 at 8:03 PM Guenter Roeck  wrote:
>
> On 7/29/20 7:28 PM, Badhri Jagan Sridharan wrote:
> > Hi Greg,
> >
> > Sure just sent the new patch v3.
> >
> > Patch applies cleanly on my end. So wondering what I am missing.
>
> I expected your patch to conflict with Hans' patch series.
> Maybe those are in a different tree/branch ?
>
> Guenter
>
> > Just in case if you are still noticing merge conflicts.
> >
> > Here is the git log of my local tree:
> > 633198cd2945b7 (HEAD -> usb-next-1) usb: typec: tcpm: Migrate workqueue to 
> > RT priority for processing events
> > fa56dd9152ef95 (origin/usb-next) Merge tag 'usb-serial-5.9-rc1' of 
> > https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into 
> > usb-next
> > 25252919a1050e xhci: dbgtty: Make some functions static
> > b0e02550346e67 xhci: dbc: Make function xhci_dbc_ring_alloc() static
> > ca6377900974c3 Revert "usb: dwc2: override PHY input signals with usb role 
> > switch support"
> > 09df709cb5aeb2 Revert "usb: dwc2: don't use ID/Vbus detection if 
> > usb-role-switch on STM32MP15 SoCs"
> > 17a82716587e9d USB: iowarrior: fix up report size handling for some devices
> > e98ba8cc3f8a89 Merge tag 'usb-for-v5.9' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb 
> >  into usb-next
> > c97793089b11f7 Merge 5.8-rc7 into usb-next
> > 92ed301919932f (tag: v5.8-rc7, origin/usb-linus, origin/main) Linux 5.8-rc7
> >
> > Was comparing against 
> > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/log/?h=usb-next
> >
> > Thanks,
> > Badhri
> >
> > On Wed, Jul 29, 2020 at 7:53 AM Greg Kroah-Hartman 
> > mailto:gre...@linuxfoundation.org>> wrote:
> >
> > On Thu, Jul 23, 2020 at 07:05:51PM -0700, Badhri Jagan Sridharan wrote:
> > > "tReceiverResponse 15 ms Section 6.6.2
> > > The receiver of a Message requiring a response Shall respond
> > > within tReceiverResponse in order to ensure that the
> > > sender’s SenderResponseTimer does not expire."
> > >
> > > When the cpu complex is busy running other lower priority
> > > work items, TCPM's work queue sometimes does not get scheduled
> > > on time to meet the above requirement from the spec.
> > > Moving to kthread_work apis to run with real time priority.
> > > Just lower than the default threaded irq priority,
> > > MAX_USER_RT_PRIO/2 + 1. (Higher number implies lower priority).
> > >
> > > Further, as observed in 1ff688209e2e, moving to hrtimers to
> > > overcome scheduling latency while scheduling the delayed work.
> > >
> > > TCPM has three work streams:
> > > 1. tcpm_state_machine
> > > 2. vdm_state_machine
> > > 3. event_work
> > >
> > > tcpm_state_machine and vdm_state_machine both schedule work in
> > > future i.e. delayed. Hence each of them have a corresponding
> > > hrtimer, tcpm_state_machine_timer & vdm_state_machine_timer.
> > >
> > > When work is queued right away kthread_queue_work is used.
> > > Else, the relevant timer is programmed and made to queue
> > > the kthread_work upon timer expiry.
> > >
> > > kthread_create_worker only creates one kthread worker thread,
> > > hence single threadedness of workqueue is retained.
> > >
> > > Signed-off-by: Badhri Jagan Sridharan  > >
> >
> > This doesn't apply against my usb-next branch at all.
> >
> > Can you rebase and resend?
> >
> > Remember to collect the reviewed-by tags as well when you do so.
> >
> > thanks,
> >
> > greg k-h
> >
>

[PATCH 2/3] PCI: iproc: Stop using generic config read/write functions

[Mark Tomlinson]

The pci_generic_config_write32() function will give warning messages
whenever writing less than 4 bytes at a time. As there is nothing we can
do about this without changing the hardware, the message is just a
nuisance. So instead of using the generic functions, use the functions
that have already been written for reading/writing the config registers.

Signed-off-by: Mark Tomlinson 
---
 drivers/pci/controller/pcie-iproc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/pcie-iproc.c 
b/drivers/pci/controller/pcie-iproc.c
index 2c836eede42c..68ecd3050529 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -709,12 +709,13 @@ static int iproc_pcie_config_read32(struct pci_bus *bus, 
unsigned int devfn,
 {
int ret;
struct iproc_pcie *pcie = iproc_data(bus);
+   int busno = bus->number;
 
iproc_pcie_apb_err_disable(bus, true);
if (pcie->iproc_cfg_read)
ret = iproc_pcie_config_read(bus, devfn, where, size, val);
else
-   ret = pci_generic_config_read32(bus, devfn, where, size, val);
+   ret = iproc_pci_raw_config_read32(pcie, busno, devfn, where, 
size, val);
iproc_pcie_apb_err_disable(bus, false);
 
return ret;
@@ -724,9 +725,11 @@ static int iproc_pcie_config_write32(struct pci_bus *bus, 
unsigned int devfn,
 int where, int size, u32 val)
 {
int ret;
+   struct iproc_pcie *pcie = iproc_data(bus);
+   int busno = bus->number;
 
iproc_pcie_apb_err_disable(bus, true);
-   ret = pci_generic_config_write32(bus, devfn, where, size, val);
+   ret = iproc_pci_raw_config_write32(pcie, busno, devfn, where, size, 
val);
iproc_pcie_apb_err_disable(bus, false);
 
return ret;
-- 
2.28.0

[PATCH 3/3] PCI: iproc: Set affinity mask on MSI interrupts

[Mark Tomlinson]

The core interrupt code expects the irq_set_affinity call to update the
effective affinity for the interrupt. This was not being done, so update
iproc_msi_irq_set_affinity() to do so.

Signed-off-by: Mark Tomlinson 
---
 drivers/pci/controller/pcie-iproc-msi.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/controller/pcie-iproc-msi.c 
b/drivers/pci/controller/pcie-iproc-msi.c
index 3176ad3ab0e5..908475d27e0e 100644
--- a/drivers/pci/controller/pcie-iproc-msi.c
+++ b/drivers/pci/controller/pcie-iproc-msi.c
@@ -209,15 +209,20 @@ static int iproc_msi_irq_set_affinity(struct irq_data 
*data,
struct iproc_msi *msi = irq_data_get_irq_chip_data(data);
int target_cpu = cpumask_first(mask);
int curr_cpu;
+   int ret;
 
curr_cpu = hwirq_to_cpu(msi, data->hwirq);
if (curr_cpu == target_cpu)
-   return IRQ_SET_MASK_OK_DONE;
+   ret = IRQ_SET_MASK_OK_DONE;
+   else {
+   /* steer MSI to the target CPU */
+   data->hwirq = hwirq_to_canonical_hwirq(msi, data->hwirq) + 
target_cpu;
+   ret = IRQ_SET_MASK_OK;
+   }
 
-   /* steer MSI to the target CPU */
-   data->hwirq = hwirq_to_canonical_hwirq(msi, data->hwirq) + target_cpu;
+   irq_data_update_effective_affinity(data, cpumask_of(target_cpu));
 
-   return IRQ_SET_MASK_OK;
+   return ret;
 }
 
 static void iproc_msi_irq_compose_msi_msg(struct irq_data *data,
-- 
2.28.0

[PATCH 1/3] PCI: iproc: Add bus number parameter to read/write functions

[Mark Tomlinson]

This makes the read/write functions more generic, allowing them to be
used from other places.

Signed-off-by: Mark Tomlinson 
---
 drivers/pci/controller/pcie-iproc.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/controller/pcie-iproc.c 
b/drivers/pci/controller/pcie-iproc.c
index 8c7f875acf7f..2c836eede42c 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -660,13 +660,13 @@ static void __iomem *iproc_pcie_bus_map_cfg_bus(struct 
pci_bus *bus,
  where);
 }
 
-static int iproc_pci_raw_config_read32(struct iproc_pcie *pcie,
+static int iproc_pci_raw_config_read32(struct iproc_pcie *pcie, int busno,
   unsigned int devfn, int where,
   int size, u32 *val)
 {
void __iomem *addr;
 
-   addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
+   addr = iproc_pcie_map_cfg_bus(pcie, busno, devfn, where & ~0x3);
if (!addr) {
*val = ~0;
return PCIBIOS_DEVICE_NOT_FOUND;
@@ -680,14 +680,14 @@ static int iproc_pci_raw_config_read32(struct iproc_pcie 
*pcie,
return PCIBIOS_SUCCESSFUL;
 }
 
-static int iproc_pci_raw_config_write32(struct iproc_pcie *pcie,
+static int iproc_pci_raw_config_write32(struct iproc_pcie *pcie, int busno,
unsigned int devfn, int where,
int size, u32 val)
 {
void __iomem *addr;
u32 mask, tmp;
 
-   addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
+   addr = iproc_pcie_map_cfg_bus(pcie, busno, devfn, where & ~0x3);
if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
 
@@ -793,7 +793,7 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
}
 
/* make sure we are not in EP mode */
-   iproc_pci_raw_config_read32(pcie, 0, PCI_HEADER_TYPE, 1, _type);
+   iproc_pci_raw_config_read32(pcie, 0, 0, PCI_HEADER_TYPE, 1, _type);
if ((hdr_type & 0x7f) != PCI_HEADER_TYPE_BRIDGE) {
dev_err(dev, "in EP mode, hdr=%#02x\n", hdr_type);
return -EFAULT;
@@ -803,15 +803,16 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
 #define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c
 #define PCI_CLASS_BRIDGE_MASK  0x00
 #define PCI_CLASS_BRIDGE_SHIFT 8
-   iproc_pci_raw_config_read32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
+   iproc_pci_raw_config_read32(pcie, 0, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
4, );
class &= ~PCI_CLASS_BRIDGE_MASK;
class |= (PCI_CLASS_BRIDGE_PCI << PCI_CLASS_BRIDGE_SHIFT);
-   iproc_pci_raw_config_write32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
+   iproc_pci_raw_config_write32(pcie, 0, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
 4, class);
 
/* check link status to see if link is active */
-   iproc_pci_raw_config_read32(pcie, 0, IPROC_PCI_EXP_CAP + PCI_EXP_LNKSTA,
+   iproc_pci_raw_config_read32(pcie, 0, 0,
+   IPROC_PCI_EXP_CAP + PCI_EXP_LNKSTA,
2, _status);
if (link_status & PCI_EXP_LNKSTA_NLW)
link_is_active = true;
@@ -821,19 +822,19 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
 #define PCI_TARGET_LINK_SPEED_MASK 0xf
 #define PCI_TARGET_LINK_SPEED_GEN2 0x2
 #define PCI_TARGET_LINK_SPEED_GEN1 0x1
-   iproc_pci_raw_config_read32(pcie, 0,
+   iproc_pci_raw_config_read32(pcie, 0, 0,
IPROC_PCI_EXP_CAP + PCI_EXP_LNKCTL2,
4, _ctrl);
if ((link_ctrl & PCI_TARGET_LINK_SPEED_MASK) ==
PCI_TARGET_LINK_SPEED_GEN2) {
link_ctrl &= ~PCI_TARGET_LINK_SPEED_MASK;
link_ctrl |= PCI_TARGET_LINK_SPEED_GEN1;
-   iproc_pci_raw_config_write32(pcie, 0,
+   iproc_pci_raw_config_write32(pcie, 0, 0,
IPROC_PCI_EXP_CAP + PCI_EXP_LNKCTL2,
4, link_ctrl);
msleep(100);
 
-   iproc_pci_raw_config_read32(pcie, 0,
+   iproc_pci_raw_config_read32(pcie, 0, 0,
IPROC_PCI_EXP_CAP + PCI_EXP_LNKSTA,
2, _status);
if (link_status & PCI_EXP_LNKSTA_NLW)
-- 
2.28.0

Re: KASAN: use-after-free Read in delete_and_unsubscribe_port (2)

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:d3590ebf Merge tag 'audit-pr-20200729' of git://git.kernel..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1207e0b890
kernel config:  https://syzkaller.appspot.com/x/.config?x=812bbfcb6ae2cd60
dashboard link: https://syzkaller.appspot.com/bug?extid=1a54a94bd32716796edd
compiler:   clang version 10.0.0 (https://github.com/llvm/llvm-project/ 
c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11b227f890

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1a54a94bd32716796...@syzkaller.appspotmail.com

==
BUG: KASAN: use-after-free in list_empty include/linux/list.h:282 [inline]
BUG: KASAN: use-after-free in delete_and_unsubscribe_port+0x8b/0x450 
sound/core/seq/seq_ports.c:530
Read of size 8 at addr 888098523060 by task syz-executor.0/7202

CPU: 1 PID: 7202 Comm: syz-executor.0 Not tainted 5.8.0-rc7-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+0x1f0/0x31e 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
 list_empty include/linux/list.h:282 [inline]
 delete_and_unsubscribe_port+0x8b/0x450 sound/core/seq/seq_ports.c:530
 snd_seq_port_disconnect+0x568/0x610 sound/core/seq/seq_ports.c:612
 snd_seq_ioctl_unsubscribe_port+0x349/0x6c0 sound/core/seq/seq_clientmgr.c:1525
 snd_seq_oss_midi_close+0x397/0x620 sound/core/seq/oss/seq_oss_midi.c:405
 snd_seq_oss_synth_reset+0x335/0x8b0 sound/core/seq/oss/seq_oss_synth.c:406
 snd_seq_oss_reset+0x5b/0x250 sound/core/seq/oss/seq_oss_init.c:435
 snd_seq_oss_ioctl+0x5c2/0x1090 sound/core/seq/oss/seq_oss_ioctl.c:93
 odev_ioctl+0x51/0x70 sound/core/seq/oss/seq_oss.c:174
 vfs_ioctl fs/ioctl.c:48 [inline]
 ksys_ioctl fs/ioctl.c:753 [inline]
 __do_sys_ioctl fs/ioctl.c:762 [inline]
 __se_sys_ioctl+0xf9/0x160 fs/ioctl.c:760
 do_syscall_64+0x73/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45c429
Code: 8d b6 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 
5b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f6e48930c78 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 000154c0 RCX: 0045c429
RDX:  RSI: 5100 RDI: 0003
RBP: 0078bf38 R08:  R09: 
R10:  R11: 0246 R12: 0078bf0c
R13: 7ffe51b9d10f R14: 7f6e489319c0 R15: 0078bf0c

Allocated by task 7202:
 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]
 snd_seq_port_connect+0x66/0x460 sound/core/seq/seq_ports.c:553
 snd_seq_ioctl_subscribe_port+0x349/0x6c0 sound/core/seq/seq_clientmgr.c:1484
 snd_seq_oss_midi_open+0x4db/0x830 sound/core/seq/oss/seq_oss_midi.c:364
 snd_seq_oss_synth_setup_midi+0x108/0x510 sound/core/seq/oss/seq_oss_synth.c:269
 snd_seq_oss_open+0x899/0xe90 sound/core/seq/oss/seq_oss_init.c:261
 odev_open+0x5e/0x90 sound/core/seq/oss/seq_oss.c:125
 chrdev_open+0x498/0x580 fs/char_dev.c:414
 do_dentry_open+0x813/0x1070 fs/open.c:828
 do_open fs/namei.c:3243 [inline]
 path_openat+0x278d/0x37f0 fs/namei.c:3360
 do_filp_open+0x191/0x3a0 fs/namei.c:3387
 do_sys_openat2+0x463/0x770 fs/open.c:1179
 do_sys_open fs/open.c:1195 [inline]
 __do_sys_openat fs/open.c:1209 [inline]
 __se_sys_openat fs/open.c:1204 [inline]
 __x64_sys_openat+0x1c8/0x1f0 fs/open.c:1204
 do_syscall_64+0x73/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Freed by task 7203:
 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
 snd_seq_port_disconnect+0x570/0x610 sound/core/seq/seq_ports.c:614
 snd_seq_ioctl_unsubscribe_port+0x349/0x6c0 sound/core/seq/seq_clientmgr.c:1525
 snd_seq_oss_midi_close+0x397/0x620 sound/core/seq/oss/seq_oss_midi.c:405
 snd_seq_oss_synth_reset+0x335/0x8b0 sound/core/seq/oss/seq_oss_synth.c:406
 snd_seq_oss_reset+0x5b/0x250 sound/core/seq/oss/seq_oss_init.c:435
 snd_seq_oss_ioctl+0x5c2/0x1090 sound/core/seq/oss/seq_oss_ioctl.c:93
 odev_ioctl+0x51/0x70 sound/core/seq/oss/seq_oss.c:174
 vfs_ioctl fs/ioctl.c:48 [inline]
 ksys_ioctl fs/ioctl.c:753 [

[PATCH -next 0/3] scsi: Remove superfluous memset()

[Li Heng]

*** BLURB HERE ***

Li Heng (3):
  scsi: Remove superfluous memset()
  scsi: Remove superfluous memset()
  scsi: Remove superfluous memset()

 drivers/scsi/mpt3sas/mpt3sas_base.c | 1 -
 drivers/scsi/pmcraid.c  | 1 -
 drivers/scsi/qla2xxx/qla_mbx.c  | 2 --
 3 files changed, 4 deletions(-)

--
2.7.4

[PATCH -next 3/3] scsi: Remove superfluous memset()

[Li Heng]

Fixes coccicheck warning:

./drivers/scsi/mpt3sas/mpt3sas_base.c:5247:16-34: WARNING: dma_alloc_coherent 
use in ioc -> request already zeroes out memory,  so memset is not needed

dma_alloc_coherent use in status already zeroes out memory, so memset is not 
needed

Signed-off-by: Li Heng 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 1d64524..61219ad 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -5257,7 +5257,6 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
_base_release_memory_pools(ioc);
goto retry_allocation;
}
-   memset(ioc->request, 0, sz);
 
if (retry_sz)
ioc_err(ioc, "request pool: dma_alloc_coherent succeed: 
hba_depth(%d), chains_per_io(%d), frame_sz(%d), total(%d kb)\n",
-- 
2.7.4

[PATCH -next 1/3] scsi: Remove superfluous memset()

[Li Heng]

Fixes coccicheck warning:

./drivers/scsi/pmcraid.c:4709:3-21: WARNING: dma_alloc_coherent use in 
pinstance -> hrrq_start [ i ] already zeroes out memory,  so memset is not 
needed

dma_alloc_coherent use in status already zeroes out memory, so memset is not 
needed

Signed-off-by: Li Heng 
---
 drivers/scsi/pmcraid.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index aa9ae2a..d99568f 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -4716,7 +4716,6 @@ static int pmcraid_allocate_host_rrqs(struct 
pmcraid_instance *pinstance)
return -ENOMEM;
}
 
-   memset(pinstance->hrrq_start[i], 0, buffer_size);
pinstance->hrrq_curr[i] = pinstance->hrrq_start[i];
pinstance->hrrq_end[i] =
pinstance->hrrq_start[i] + PMCRAID_MAX_CMD - 1;
-- 
2.7.4

[PATCH -next 2/3] scsi: Remove superfluous memset()

[Li Heng]

Fixes coccicheck warning:

./drivers/scsi/qla2xxx/qla_mbx.c:4928:15-33: WARNING: dma_alloc_coherent use in 
els_cmd_map already zeroes out memory,  so memset is not needed

dma_alloc_coherent use in status already zeroes out memory, so memset is not 
needed

Signed-off-by: Li Heng 
---
 drivers/scsi/qla2xxx/qla_mbx.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_mbx.c b/drivers/scsi/qla2xxx/qla_mbx.c
index 7388343..14656da 100644
--- a/drivers/scsi/qla2xxx/qla_mbx.c
+++ b/drivers/scsi/qla2xxx/qla_mbx.c
@@ -4933,8 +4933,6 @@ qla25xx_set_els_cmds_supported(scsi_qla_host_t *vha)
return QLA_MEMORY_ALLOC_FAILED;
}
 
-   memset(els_cmd_map, 0, ELS_CMD_MAP_SIZE);
-
/* List of Purex ELS */
cmd_opcode[0] = ELS_FPIN;
cmd_opcode[1] = ELS_RDP;
-- 
2.7.4

[PATCH] firewire: firewire-cdev.h: Avoid the use of one-element array

[Qianli Zhao]

From: Qianli Zhao 

There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a structure. Kernel code should
always use “flexible array members”[1] for these cases. The older style of
one-element or zero-length arrays should no longer be used[2].

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://github.com/KSPP/linux/issues/21

Signed-off-by: Qianli Zhao 
---
 include/uapi/linux/firewire-cdev.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/uapi/linux/firewire-cdev.h 
b/include/uapi/linux/firewire-cdev.h
index 7e5b5c1..487de87f 100644
--- a/include/uapi/linux/firewire-cdev.h
+++ b/include/uapi/linux/firewire-cdev.h
@@ -118,7 +118,7 @@ struct fw_cdev_event_response {
__u32 type;
__u32 rcode;
__u32 length;
-   __u32 data[0];
+   __u32 data[];
 };
 
 /**
@@ -142,7 +142,7 @@ struct fw_cdev_event_request {
__u64 offset;
__u32 handle;
__u32 length;
-   __u32 data[0];
+   __u32 data[];
 };
 
 /**
@@ -205,7 +205,7 @@ struct fw_cdev_event_request2 {
__u32 generation;
__u32 handle;
__u32 length;
-   __u32 data[0];
+   __u32 data[];
 };
 
 /**
@@ -344,7 +344,7 @@ struct fw_cdev_event_iso_resource {
  * @data:  Incoming data
  *
  * If @type is %FW_CDEV_EVENT_PHY_PACKET_SENT, @length is 0 and @data empty,
- * except in case of a ping packet:  Then, @length is 4, and @data[0] is the
+ * except in case of a ping packet:  Then, @length is 4, and @data[] is the
  * ping time in 49.152MHz clocks if @rcode is %RCODE_COMPLETE.
  *
  * If @type is %FW_CDEV_EVENT_PHY_PACKET_RECEIVED, @length is 8 and @data
@@ -355,7 +355,7 @@ struct fw_cdev_event_phy_packet {
__u32 type;
__u32 rcode;
__u32 length;
-   __u32 data[0];
+   __u32 data[];
 };
 
 /**
-- 
2.7.4

[PATCH v2 1/1] power_supply: wilco_ec: Add long life charging mode

[Crag Wang]

This is a long life mode set in the factory for extended warranty
battery, the power charging rate is customized so that battery at
work last longer.

Presently switching to a different battery charging mode is through
EC PID 0x0710 to configure the battery firmware, this operation will
be blocked by EC with failure code 0x01 when PLL mode is already
in use.

Signed-off-by: Crag Wang 
Reviewed-by: Mario Limonciello 
---
 Documentation/ABI/testing/sysfs-class-power-wilco | 4 
 drivers/power/supply/power_supply_sysfs.c | 1 +
 drivers/power/supply/wilco-charger.c  | 5 +
 include/linux/power_supply.h  | 1 +
 4 files changed, 11 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-power-wilco 
b/Documentation/ABI/testing/sysfs-class-power-wilco
index da1d6ffe5e3c..84fde1d0ada0 100644
--- a/Documentation/ABI/testing/sysfs-class-power-wilco
+++ b/Documentation/ABI/testing/sysfs-class-power-wilco
@@ -14,6 +14,10 @@ Description:
Charging begins when level drops below
charge_control_start_threshold, and ceases when
level is above charge_control_end_threshold.
+   Long Life: Customized charge rate for last longer battery life.
+   On Wilco device this mode is pre-configured in the 
factory
+   through EC's private PID. Swiching to a different mode 
will
+   be denied by Wilco EC when Long Life mode is enabled.
 
 What:  
/sys/class/power_supply/wilco-charger/charge_control_start_threshold
 Date:  April 2019
diff --git a/drivers/power/supply/power_supply_sysfs.c 
b/drivers/power/supply/power_supply_sysfs.c
index bc79560229b5..cfb87b8b8392 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -87,6 +87,7 @@ static const char * const POWER_SUPPLY_CHARGE_TYPE_TEXT[] = {
[POWER_SUPPLY_CHARGE_TYPE_STANDARD] = "Standard",
[POWER_SUPPLY_CHARGE_TYPE_ADAPTIVE] = "Adaptive",
[POWER_SUPPLY_CHARGE_TYPE_CUSTOM]   = "Custom",
+   [POWER_SUPPLY_CHARGE_TYPE_LONGLIFE] = "Long Life",
 };
 
 static const char * const POWER_SUPPLY_HEALTH_TEXT[] = {
diff --git a/drivers/power/supply/wilco-charger.c 
b/drivers/power/supply/wilco-charger.c
index b3c6d7cdd731..98ade073ef05 100644
--- a/drivers/power/supply/wilco-charger.c
+++ b/drivers/power/supply/wilco-charger.c
@@ -27,6 +27,7 @@ enum charge_mode {
CHARGE_MODE_AC = 3, /* Mostly AC use, used for Trickle */
CHARGE_MODE_AUTO = 4,   /* Used for Adaptive */
CHARGE_MODE_CUSTOM = 5, /* Used for Custom */
+   CHARGE_MODE_LONGLIFE = 6, /* Used for Long Life */
 };
 
 #define CHARGE_LOWER_LIMIT_MIN 50
@@ -48,6 +49,8 @@ static int psp_val_to_charge_mode(int psp_val)
return CHARGE_MODE_AUTO;
case POWER_SUPPLY_CHARGE_TYPE_CUSTOM:
return CHARGE_MODE_CUSTOM;
+   case POWER_SUPPLY_CHARGE_TYPE_LONGLIFE:
+   return CHARGE_MODE_LONGLIFE;
default:
return -EINVAL;
}
@@ -67,6 +70,8 @@ static int charge_mode_to_psp_val(enum charge_mode mode)
return POWER_SUPPLY_CHARGE_TYPE_ADAPTIVE;
case CHARGE_MODE_CUSTOM:
return POWER_SUPPLY_CHARGE_TYPE_CUSTOM;
+   case CHARGE_MODE_LONGLIFE:
+   return POWER_SUPPLY_CHARGE_TYPE_LONGLIFE;
default:
return -EINVAL;
}
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index ac1345a48ad0..528a3eaa2320 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -48,6 +48,7 @@ enum {
POWER_SUPPLY_CHARGE_TYPE_STANDARD,  /* normal speed */
POWER_SUPPLY_CHARGE_TYPE_ADAPTIVE,  /* dynamically adjusted speed */
POWER_SUPPLY_CHARGE_TYPE_CUSTOM,/* use CHARGE_CONTROL_* props */
+   POWER_SUPPLY_CHARGE_TYPE_LONGLIFE,  /* slow speed, longer life */
 };
 
 enum {
-- 
2.17.1

---
The original author, Nick no longer being around and that's why he's not on CC.

Re: [PATCH 2/2] rcu/tree: Clarify comments about FQS loop reporting quiescent states

[Joel Fernandes]

On Wed, Jul 29, 2020 at 11:02 PM Joel Fernandes (Google)
 wrote:
>
> At least since v4.19, the FQS loop no longer reports quiescent states

I meant here, "FQS loop no longer reports quiescent states for offline CPUs."

Sorry,

 - Joel


> unless it is a dire situation where an offlined CPU failed to report
> a quiescent state. Let us clarify the comment in rcu_gp_init() inorder
> to keep the comment current.
>
> Signed-off-by: Joel Fernandes (Google) 
> ---
>  kernel/rcu/tree.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 1e51962b565b..929568ff5989 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -1701,8 +1701,8 @@ static bool rcu_gp_init(void)
>
> /*
>  * Apply per-leaf buffered online and offline operations to the
> -* rcu_node tree.  Note that this new grace period need not wait
> -* for subsequent online CPUs, and that quiescent-state forcing
> +* rcu_node tree.  Note that this new grace period need not wait for
> +* subsequent online CPUs, and that RCU hooks in CPU offlining path
>  * will handle subsequent offline CPUs.
>  */
> rcu_state.gp_state = RCU_GP_ONOFF;
> --
> 2.28.0.rc0.142.g3c755180ce-goog
>

Re: [PATCH 1/1] staging: android: ashmem: Fix lockdep warning for write operation

[Joel Fernandes]

On Wed, Jul 15, 2020 at 10:45 PM Suren Baghdasaryan  wrote:
>
> syzbot report [1] describes a deadlock when write operation against an
> ashmem fd executed at the time when ashmem is shrinking its cache results
> in the following lock sequence:
>
> Possible unsafe locking scenario:
>
> CPU0CPU1
> 
>lock(fs_reclaim);
> lock(>s_type->i_mutex_key#13);
> lock(fs_reclaim);
>lock(>s_type->i_mutex_key#13);
>
> kswapd takes fs_reclaim and then inode_lock while generic_perform_write
> takes inode_lock and then fs_reclaim. However ashmem does not support
> writing into backing shmem with a write syscall. The only way to change
> its content is to mmap it and operate on mapped memory. Therefore the race
> that lockdep is warning about is not valid. Resolve this by introducing a
> separate lockdep class for the backing shmem inodes.
>
> [1]: https://lkml.kernel.org/lkml/0b5f9d059aa20...@google.com/
>
> Signed-off-by: Suren Baghdasaryan 
> ---

Once Eric's nits are resolved:

Reviewed-by: Joel Fernandes (Google) 

Thanks.

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

[Willy Tarreau]

Hi Kees,

On Wed, Jul 29, 2020 at 08:17:48PM -0700, Kees Cook wrote:
> And just another heads-up, the patch[1] (which was never sent to a public
> list) also breaks arm64 (circular header needs?):
(...)

Definitely, we've just got a report about this, I'll have a look once
I'm at the office. I'd like to check that we don't obviously break
another arch by just removing percpu. If at least shuffling them around
is sufficient that'd be nice. Otherwise we'll likely need a separate
header (which is not a bad thing for the long term).

Thanks!
Willy

Re: [PATCH] include: Replace HTTP links with HTTPS ones

[Kees Cook]

On Wed, Jul 29, 2020 at 02:45:10PM -0700, Andrew Morton wrote:
> On Wed, 29 Jul 2020 14:21:12 -0700 Kees Cook  wrote:
> 
> > On Sun, Jul 26, 2020 at 01:01:17PM +0200, Alexander A. Klimov wrote:
> > > Rationale:
> > > Reduces attack surface on kernel devs opening the links for MITM
> > > as HTTPS traffic is much harder to manipulate.
> > > 
> > > Signed-off-by: Alexander A. Klimov 
> > 
> > Reviewed-by: Kees Cook 
> > 
> > Jon, do you want to take this?
> 
> I added this to -mm yesterday.

Ah excellent. :) Thanks!

-- 
Kees Cook

Re: [RFC PATCH] iomap: add support to track dirty state of sub pages

[Matthew Wilcox]

On Thu, Jul 30, 2020 at 09:19:01AM +0800, Yu Kuai wrote:
> +++ b/fs/iomap/buffered-io.c
> @@ -29,7 +29,9 @@ struct iomap_page {
>   atomic_tread_count;
>   atomic_twrite_count;
>   spinlock_t  uptodate_lock;
> + spinlock_t  dirty_lock;

No need for a separate spinlock.  Just rename uptodate_lock.  Maybe
'bitmap_lock'.

>   DECLARE_BITMAP(uptodate, PAGE_SIZE / 512);
> + DECLARE_BITMAP(dirty, PAGE_SIZE / 512);

This is inefficient and poses difficulties for the THP patchset.
Maybe let the discussion on removing the ->uptodate array finish
before posting another patch for review?

> +static void
> +iomap_iop_set_or_clear_range_dirty(
> + struct page *page,
> + unsigned int off,
> + unsigned int len,
> + bool is_set)

Please follow normal kernel programming style.  This isn't XFS.
Also 'set or clear' with a bool to indicate which to do is horrible
style.  Separate functions!

> @@ -1386,7 +1432,8 @@ iomap_writepage_map(struct iomap_writepage_ctx *wpc,
>   for (i = 0, file_offset = page_offset(page);
>i < (PAGE_SIZE >> inode->i_blkbits) && file_offset < end_offset;
>i++, file_offset += len) {
> - if (iop && !test_bit(i, iop->uptodate))
> + if (iop && (!test_bit(i, iop->uptodate) ||
> + !test_bit(i, iop->dirty)))
>   continue;

Surely we don't need to test ->uptodate here at all.  Why would we write
back a block which isn't dirty?

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

[Kees Cook]

On Wed, Jul 29, 2020 at 04:43:04PM -0700, Linus Torvalds wrote:
> On Wed, Jul 29, 2020 at 4:08 PM Stephen Rothwell  
> wrote:
> >
> > include/linux/random.h:123:24: error: variable 'net_rand_state' with 
> > 'latent_entropy' attribute must not be local
> >   123 | DECLARE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;
> 
> Hmm.
> 
> Ok, this shows a limitation of my allmodconfig testing (and all my
> normal builds) - no plugins. So that problem wasn't as obvious as it
> should have been.

I'll look into this more tomorrow. (But yes, __latent_entropy is
absolutely used for globals already, as you found, but this is the first
percpu it was applied to...)

> Adding the gcc plugin people. Otherwise the only option seems to be to
> just remove that __latent_entropy marker.

And just another heads-up, the patch[1] (which was never sent to a public
list) also breaks arm64 (circular header needs?):

$ make CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 defconfig
...
$ make -j$(getconf _NPROCESSORS_ONLN) CROSS_COMPILE=aarch64-linux-gnu- 
ARCH=arm64
...
In file included from ./arch/arm64/include/asm/smp.h:33,
 from ./include/linux/smp.h:82,
 from ./include/linux/percpu.h:7,
 from ./include/linux/random.h:14,
 from arch/arm64/kernel/pointer_auth.c:5:
./arch/arm64/include/asm/pointer_auth.h: In function ‘ptrauth_keys_init_user’:
./arch/arm64/include/asm/pointer_auth.h:40:3: error: implicit declaration of 
function ‘get_random_bytes’; did you mean ‘get_random_once’? 
[-Werror=implicit-function-declaration]
   40 |   get_random_bytes(>apia, sizeof(keys->apia));
  |   ^


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f227e3ec3b5cad859ad15666874405e8c1bbc1d4

-- 
Kees Cook

Re: [RFC PATCH] iomap: add support to track dirty state of sub pages

[yukuai (C)]

On 2020/7/30 10:27, Gao Xiang wrote:

Hi Kuai,

On Thu, Jul 30, 2020 at 09:19:01AM +0800, Yu Kuai wrote:

commit 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O
without buffer heads") replace the per-block structure buffer_head with
the per-page structure iomap_page. However, iomap_page can't track the
dirty state of sub pages, which will cause performance issue since sub
pages will be writeback even if they are not dirty.

For example, if block size is 4k and page size is 64k:

dd if=/dev/zero of=testfile bs=4k count=16 oflag=sync

With buffer_head implementation, the above dd cmd will writeback 4k in
each round. However, with iomap_page implementation, the range of
writeback in each round is from the start of the page to the end offset
we just wrote.

Thus add support to track dirty state for sub pages in iomap_page.


AFAIK, the current focus is also on the numbers in the original
discussion thread, so it'd be better to show some numbers with
large PAGE_SIZE on this with some workloads as well.

https://lore.kernel.org/r/20200729230503.ga2...@dread.disaster.area



Hi, Xiang!

The problem was found by iozone to test 4k sequintail write in my
case, thanks for pointing out the discussion thread. I'll test it if
this patch have any effect on that situation.

Thanks,
Yu Kuai


e.g. My guess is if the dirty blocks in the page are highly fragmented, maybe
it'd be better to writeback the whole page in an IO rather than individual 
blocks.

At a very quick glance, the approach looks good to me.

Thanks,
Gao Xiang



Signed-off-by: Yu Kuai 
---
  fs/iomap/buffered-io.c | 51 +-
  1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index bcfc288dba3f..ac2676146b98 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -29,7 +29,9 @@ struct iomap_page {
atomic_tread_count;
atomic_twrite_count;
spinlock_t  uptodate_lock;
+   spinlock_t  dirty_lock;
DECLARE_BITMAP(uptodate, PAGE_SIZE / 512);
+   DECLARE_BITMAP(dirty, PAGE_SIZE / 512);
  };
  
  static inline struct iomap_page *to_iomap_page(struct page *page)

@@ -53,7 +55,9 @@ iomap_page_create(struct inode *inode, struct page *page)
atomic_set(>read_count, 0);
atomic_set(>write_count, 0);
spin_lock_init(>uptodate_lock);
+   spin_lock_init(>dirty_lock);
bitmap_zero(iop->uptodate, PAGE_SIZE / SECTOR_SIZE);
+   bitmap_zero(iop->dirty, PAGE_SIZE / SECTOR_SIZE);
  
  	/*

 * migrate_page_move_mapping() assumes that pages with private data have
@@ -135,6 +139,44 @@ iomap_adjust_read_range(struct inode *inode, struct 
iomap_page *iop,
*lenp = plen;
  }
  
+static void

+iomap_iop_set_or_clear_range_dirty(
+   struct page *page,
+   unsigned int off,
+   unsigned int len,
+   bool is_set)
+{
+   struct iomap_page *iop = to_iomap_page(page);
+   struct inode *inode = page->mapping->host;
+   unsigned int first = off >> inode->i_blkbits;
+   unsigned int last = (off + len - 1) >> inode->i_blkbits;
+   unsigned long flags;
+   unsigned int i;
+
+   spin_lock_irqsave(>dirty_lock, flags);
+   for (i = first; i <= last; i++)
+   if (is_set)
+   set_bit(i, iop->dirty);
+   else
+   clear_bit(i, iop->dirty);
+   spin_unlock_irqrestore(>dirty_lock, flags);
+}
+
+static void
+iomap_set_or_clear_range_dirty(
+   struct page *page,
+   unsigned int off,
+   unsigned int len,
+   bool is_set)
+{
+   if (PageError(page))
+   return;
+
+   if (page_has_private(page))
+   iomap_iop_set_or_clear_range_dirty(
+   page, off, len, is_set);

3> +}

+
  static void
  iomap_iop_set_range_uptodate(struct page *page, unsigned off, unsigned len)
  {
@@ -705,6 +747,8 @@ __iomap_write_end(struct inode *inode, loff_t pos, unsigned 
len,
if (unlikely(copied < len && !PageUptodate(page)))
return 0;
iomap_set_range_uptodate(page, offset_in_page(pos), len);
+   iomap_set_or_clear_range_dirty(
+   page, offset_in_page(pos), len, true);
iomap_set_page_dirty(page);
return copied;
  }
@@ -1030,6 +1074,8 @@ iomap_page_mkwrite_actor(struct inode *inode, loff_t pos, 
loff_t length,
WARN_ON_ONCE(!PageUptodate(page));
iomap_page_create(inode, page);
set_page_dirty(page);
+   iomap_set_or_clear_range_dirty(
+   page, offset_in_page(pos), length, true);
}
  
  	return length;

@@ -1386,7 +1432,8 @@ iomap_writepage_map(struct iomap_writepage_ctx *wpc,
for (i = 0, file_offset = page_offset(page);
 i < (PAGE_SIZE >> inode->i_blkbits) && file_offset < end_offset;
 i++, file_offset += 

Re: linux-next: build warning after merge of the pm tree

[Neal Liu]

This warning should be fixed also.
Should I send another patch?

Thanks !

On Thu, 2020-07-30 at 12:55 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> drivers/acpi/processor_idle.c: In function 'acpi_idle_enter_s2idle':
> drivers/acpi/processor_idle.c:666:4: warning: 'return' with no value, in 
> function returning non-void [-Wreturn-type]
>   666 |return;
>   |^~
> drivers/acpi/processor_idle.c:657:12: note: declared here
>   657 | static int acpi_idle_enter_s2idle(struct cpuidle_device *dev,
>   |^~
> drivers/acpi/processor_idle.c:670:4: warning: 'return' with no value, in 
> function returning non-void [-Wreturn-type]
>   670 |return;
>   |^~
> drivers/acpi/processor_idle.c:657:12: note: declared here
>   657 | static int acpi_idle_enter_s2idle(struct cpuidle_device *dev,
>   |^~
> 
> Introduced by commit
> 
>   efe9711214e6 ("cpuidle: change enter_s2idle() prototype")
> 

[PATCH][next] net/sched: act_pedit: Use flex_array_size() helper in memcpy()

[Gustavo A. R. Silva]

Make use of the flex_array_size() helper to calculate the size of a
flexible array member within an enclosing structure.

This helper offers defense-in-depth against potential integer
overflows, while at the same time makes it explicitly clear that
we are dealing with a flexible array member.

Signed-off-by: Gustavo A. R. Silva 
---
 net/sched/act_pedit.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c
index 66986db062ed..c158bfed86d5 100644
--- a/net/sched/act_pedit.c
+++ b/net/sched/act_pedit.c
@@ -436,8 +436,7 @@ static int tcf_pedit_dump(struct sk_buff *skb, struct 
tc_action *a,
return -ENOBUFS;
 
spin_lock_bh(>tcf_lock);
-   memcpy(opt->keys, p->tcfp_keys,
-  p->tcfp_nkeys * sizeof(struct tc_pedit_key));
+   memcpy(opt->keys, p->tcfp_keys, flex_array_size(opt, keys, 
p->tcfp_nkeys));
opt->index = p->tcf_index;
opt->nkeys = p->tcfp_nkeys;
opt->flags = p->tcfp_flags;
-- 
2.27.0

Re: [PATCH v4 4/4] bus: mhi: clients: Add userspace client interface driver

[Hemant Kumar]

Hi Greg,

On 7/28/20 11:17 PM, Greg KH wrote:

On Tue, Jul 28, 2020 at 08:46:35PM -0700, Hemant Kumar wrote:

This MHI client driver allows userspace clients to transfer
raw data between MHI device and host using standard file operations.
Device file node is created with format

/dev/mhi__

Currently it supports LOOPBACK channel.

Signed-off-by: Hemant Kumar 
---
  drivers/bus/mhi/Kconfig  |   6 +
  drivers/bus/mhi/Makefile |   1 +
  drivers/bus/mhi/clients/Kconfig  |  15 +
  drivers/bus/mhi/clients/Makefile |   3 +
  drivers/bus/mhi/clients/uci.c| 690 +++
  5 files changed, 715 insertions(+)
  create mode 100644 drivers/bus/mhi/clients/Kconfig
  create mode 100644 drivers/bus/mhi/clients/Makefile
  create mode 100644 drivers/bus/mhi/clients/uci.c

diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
index 6a217ff..927c392 100644
--- a/drivers/bus/mhi/Kconfig
+++ b/drivers/bus/mhi/Kconfig
@@ -20,3 +20,9 @@ config MHI_BUS_DEBUG
 Enable debugfs support for use with the MHI transport. Allows
 reading and/or modifying some values within the MHI controller
 for debug and test purposes.
+
+if MHI_BUS
+
+source "drivers/bus/mhi/clients/Kconfig"
+
+endif
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index 19e6443..48f6028 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -1,2 +1,3 @@
  # core layer
  obj-y += core/
+obj-y += clients/
diff --git a/drivers/bus/mhi/clients/Kconfig b/drivers/bus/mhi/clients/Kconfig
new file mode 100644
index 000..37aaf51
--- /dev/null
+++ b/drivers/bus/mhi/clients/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+menu "MHI clients support"
+
+config MHI_UCI
+   tristate "MHI UCI"
+   depends on MHI_BUS
+   help
+MHI based userspace client interface driver is used for transferring
+raw data between host and device using standard file operations from
+userspace. Open, read, write, and close operations are supported
+by this driver. Please check mhi_uci_match_table for all supported
+channels that are exposed to userspace.
+
+endmenu
diff --git a/drivers/bus/mhi/clients/Makefile b/drivers/bus/mhi/clients/Makefile
new file mode 100644
index 000..cd34282
--- /dev/null
+++ b/drivers/bus/mhi/clients/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_MHI_UCI) += uci.o
diff --git a/drivers/bus/mhi/clients/uci.c b/drivers/bus/mhi/clients/uci.c
new file mode 100644
index 000..3ddf017
--- /dev/null
+++ b/drivers/bus/mhi/clients/uci.c
@@ -0,0 +1,690 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEVICE_NAME "mhi"
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+#define MAX_UCI_DEVICES (64)
+
+/**
+ * struct uci_chan - MHI channel for a uci device
+ * @wq: wait queue for reader/writer
+ * @lock: spin lock
+ * @pending: list of rx buffers userspace is waiting to read
+ * @cur_buf: current buffer userspace is reading
+ * @rx_size: size of the current rx buffer userspace is reading
+ */
+struct uci_chan {
+   wait_queue_head_t wq;
+
+   /* protects pending and cur_buf members */
+   spinlock_t lock;
+
+   struct list_head pending;
+   struct uci_buf *cur_buf;
+   size_t rx_size;
+};
+
+/**
+ * struct uci_buf - uci buffer
+ * @data: data buffer
+ * @len: length of data buffer
+ * @node: list node of the uci buffer
+ */
+struct uci_buf {
+   void *data;
+   size_t len;
+   struct list_head node;
+};
+
+/**
+ * struct mhi_uci_drv - MHI uci driver
+ * @head: list head of a uci device nodes
+ * @lock: mutex lock
+ * @class: current buffer userspace is reading
+ * @major: major number for uci driver
+ * @devt: dev_t object to hold major and minor info
+ */
+struct mhi_uci_drv {
+   struct list_head head;
+
+   /* protects mhi_uci_drv struct members */
+   struct mutex lock;
+
+   struct class *class;
+   int major;
+   dev_t devt;
+};


So this is just a single static structure for some "global" variables
for the driver?  Why make it a structure at all?

And why have a local list of all devices, doesn't the driver core give
that to you already?  You shouldn't need that if you are doing things
properly...Done, will get rid of this struct and use static global variable for 

major number, class and idr



+
+/**
+ * struct uci_dev - MHI uci device
+ * @node: uci device node
+ * @devt: dev_t object to hold major and minor info
+ * @dev: uci device object
+ * @mhi_dev: associated mhi device object
+ * @chan: MHI channel name
+ * @lock: mutex lock
+ * @ul_chan: uplink uci channel object
+ * @dl_chan: downlink uci channel object
+ * @mtu: max tx buffer length
+ * @actual_mtu: maximum size of incoming buffer
+ * @ref_count: uci_dev reference count
+ * @enabled: uci device node 

Re: [PATCH v2] usb: typec: tcpm: Migrate workqueue to RT priority for processing events

[Guenter Roeck]

On 7/29/20 7:28 PM, Badhri Jagan Sridharan wrote:
> Hi Greg,
> 
> Sure just sent the new patch v3.
> 
> Patch applies cleanly on my end. So wondering what I am missing.

I expected your patch to conflict with Hans' patch series.
Maybe those are in a different tree/branch ?

Guenter

> Just in case if you are still noticing merge conflicts.
> 
> Here is the git log of my local tree:
> 633198cd2945b7 (HEAD -> usb-next-1) usb: typec: tcpm: Migrate workqueue to RT 
> priority for processing events
> fa56dd9152ef95 (origin/usb-next) Merge tag 'usb-serial-5.9-rc1' of 
> https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next
> 25252919a1050e xhci: dbgtty: Make some functions static
> b0e02550346e67 xhci: dbc: Make function xhci_dbc_ring_alloc() static
> ca6377900974c3 Revert "usb: dwc2: override PHY input signals with usb role 
> switch support"
> 09df709cb5aeb2 Revert "usb: dwc2: don't use ID/Vbus detection if 
> usb-role-switch on STM32MP15 SoCs"
> 17a82716587e9d USB: iowarrior: fix up report size handling for some devices
> e98ba8cc3f8a89 Merge tag 'usb-for-v5.9' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb 
>  into usb-next
> c97793089b11f7 Merge 5.8-rc7 into usb-next
> 92ed301919932f (tag: v5.8-rc7, origin/usb-linus, origin/main) Linux 5.8-rc7
> 
> Was comparing against 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/log/?h=usb-next
> 
> Thanks,
> Badhri
> 
> On Wed, Jul 29, 2020 at 7:53 AM Greg Kroah-Hartman 
> mailto:gre...@linuxfoundation.org>> wrote:
> 
> On Thu, Jul 23, 2020 at 07:05:51PM -0700, Badhri Jagan Sridharan wrote:
> > "tReceiverResponse 15 ms Section 6.6.2
> > The receiver of a Message requiring a response Shall respond
> > within tReceiverResponse in order to ensure that the
> > sender’s SenderResponseTimer does not expire."
> >
> > When the cpu complex is busy running other lower priority
> > work items, TCPM's work queue sometimes does not get scheduled
> > on time to meet the above requirement from the spec.
> > Moving to kthread_work apis to run with real time priority.
> > Just lower than the default threaded irq priority,
> > MAX_USER_RT_PRIO/2 + 1. (Higher number implies lower priority).
> >
> > Further, as observed in 1ff688209e2e, moving to hrtimers to
> > overcome scheduling latency while scheduling the delayed work.
> >
> > TCPM has three work streams:
> > 1. tcpm_state_machine
> > 2. vdm_state_machine
> > 3. event_work
> >
> > tcpm_state_machine and vdm_state_machine both schedule work in
> > future i.e. delayed. Hence each of them have a corresponding
> > hrtimer, tcpm_state_machine_timer & vdm_state_machine_timer.
> >
> > When work is queued right away kthread_queue_work is used.
> > Else, the relevant timer is programmed and made to queue
> > the kthread_work upon timer expiry.
> >
> > kthread_create_worker only creates one kthread worker thread,
> > hence single threadedness of workqueue is retained.
> >
> > Signed-off-by: Badhri Jagan Sridharan  >
> 
> This doesn't apply against my usb-next branch at all.
> 
> Can you rebase and resend?
> 
> Remember to collect the reviewed-by tags as well when you do so.
> 
> thanks,
> 
> greg k-h
> 

[PATCH 2/2] rcu/tree: Clarify comments about FQS loop reporting quiescent states

[Joel Fernandes (Google)]

At least since v4.19, the FQS loop no longer reports quiescent states
unless it is a dire situation where an offlined CPU failed to report
a quiescent state. Let us clarify the comment in rcu_gp_init() inorder
to keep the comment current.

Signed-off-by: Joel Fernandes (Google) 
---
 kernel/rcu/tree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 1e51962b565b..929568ff5989 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1701,8 +1701,8 @@ static bool rcu_gp_init(void)
 
/*
 * Apply per-leaf buffered online and offline operations to the
-* rcu_node tree.  Note that this new grace period need not wait
-* for subsequent online CPUs, and that quiescent-state forcing
+* rcu_node tree.  Note that this new grace period need not wait for
+* subsequent online CPUs, and that RCU hooks in CPU offlining path
 * will handle subsequent offline CPUs.
 */
rcu_state.gp_state = RCU_GP_ONOFF;
-- 
2.28.0.rc0.142.g3c755180ce-goog

[PATCH -next] scsi: Remove superfluous memset()

[Li Heng]

Fixes coccicheck warning:

./drivers/scsi/mvsas/mv_init.c:244:11-29: WARNING: dma_alloc_coherent use in 
mvi -> tx already zeroes out memory,  so memset is not needed
./drivers/scsi/mvsas/mv_init.c:250:15-33: WARNING: dma_alloc_coherent use in 
mvi -> rx_fis already zeroes out memory,  so memset is not needed
./drivers/scsi/mvsas/mv_init.c:256:11-29: WARNING: dma_alloc_coherent use in 
mvi -> rx already zeroes out memory,  so memset is not needed
./drivers/scsi/mvsas/mv_init.c:265:13-31: WARNING: dma_alloc_coherent use in 
mvi -> slot already zeroes out memory,  so memset is not needed

dma_alloc_coherent use in status already zeroes out memory, so memset is not 
needed

Signed-off-by: Li Heng 
---
 drivers/scsi/mvsas/mv_init.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index 978f528..6aa2697 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -246,19 +246,16 @@ static int mvs_alloc(struct mvs_info *mvi, struct 
Scsi_Host *shost)
 >tx_dma, GFP_KERNEL);
if (!mvi->tx)
goto err_out;
-   memset(mvi->tx, 0, sizeof(*mvi->tx) * MVS_CHIP_SLOT_SZ);
mvi->rx_fis = dma_alloc_coherent(mvi->dev, MVS_RX_FISL_SZ,
 >rx_fis_dma, GFP_KERNEL);
if (!mvi->rx_fis)
goto err_out;
-   memset(mvi->rx_fis, 0, MVS_RX_FISL_SZ);
 
mvi->rx = dma_alloc_coherent(mvi->dev,
 sizeof(*mvi->rx) * (MVS_RX_RING_SZ + 1),
 >rx_dma, GFP_KERNEL);
if (!mvi->rx)
goto err_out;
-   memset(mvi->rx, 0, sizeof(*mvi->rx) * (MVS_RX_RING_SZ + 1));
mvi->rx[0] = cpu_to_le32(0xfff);
mvi->rx_cons = 0xfff;
 
@@ -267,7 +264,6 @@ static int mvs_alloc(struct mvs_info *mvi, struct Scsi_Host 
*shost)
   >slot_dma, GFP_KERNEL);
if (!mvi->slot)
goto err_out;
-   memset(mvi->slot, 0, sizeof(*mvi->slot) * slot_nr);
 
mvi->bulk_buffer = dma_alloc_coherent(mvi->dev,
   TRASH_BUCKET_SIZE,
-- 
2.7.4

[PATCH 1/2] rcu/tree: Add a warning if CPU being onlined did not report QS already

[Joel Fernandes (Google)]

Add a warning if CPU being onlined did not report QS already. This is to
simplify the code in the CPU onlining path and also to make clear about
where QS is reported. The act of QS reporting in CPU onlining path is
is likely unnecessary as shown by code reading and testing with
rcutorture's TREE03 and hotplug parameters.

Cc: Paul E. McKenney 
Cc: Neeraj Upadhyay 
Suggested-by: Paul E. McKenney 
Signed-off-by: Joel Fernandes (Google) 

---
 kernel/rcu/tree.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 65e1b5e92319..1e51962b565b 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3996,7 +3996,19 @@ void rcu_cpu_starting(unsigned int cpu)
rcu_gpnum_ovf(rnp, rdp); /* Offline-induced counter wrap? */
rdp->rcu_onl_gp_seq = READ_ONCE(rcu_state.gp_seq);
rdp->rcu_onl_gp_flags = READ_ONCE(rcu_state.gp_flags);
-   if (rnp->qsmask & mask) { /* RCU waiting on incoming CPU? */
+
+   /*
+* Delete QS reporting from here, by June 2021, if warning does not
+* fire. Let us make the rules for reporting QS for an offline CPUs
+* more explicit. The CPU onlining path does not need to report QS for
+* an offline CPU. Either the QS should have reported during CPU
+* offlining, or during rcu_gp_init() if it detected a race with either
+* CPU offlining or task unblocking on previously offlined CPUs. Note
+* that the FQS loop also does not report QS for an offline CPU any
+* longer (unless it splats due to an offline CPU blocking the GP for
+* too long).
+*/
+   if (WARN_ON_ONCE(rnp->qsmask & mask)) { /* RCU waiting on incoming CPU? 
*/
rcu_disable_urgency_upon_qs(rdp);
/* Report QS -after- changing ->qsmaskinitnext! */
rcu_report_qs_rnp(mask, rnp, rnp->gp_seq, flags);
-- 
2.28.0.rc0.142.g3c755180ce-goog

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

[Stephen Rothwell]

Hi James,

On Thu, 30 Jul 2020 12:35:03 +1000 (AEST) James Morris  
wrote:
>
> On Thu, 30 Jul 2020, Stephen Rothwell wrote:
> 
> > > I am still applying the above patch ...  
> > 
> > The merge window is coming up fast ... is anything happening about this
> > failure?  
> 
> A new patch is coming, but I'm not sure this code has had enough review 
> from the core VFS folk.
> 
> Please drop secure_uffd_v5.9 for the time being.

You just need to remove/revert it from your security tree
(git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next-testing).
-- 
Cheers,
Stephen Rothwell


pgpSB7cdUZdMq.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 9/9] mfd: mt6360: Merge different sub-devices i2c read/write

[Gene Chen]

Lee Jones  於 2020年7月29日 週三 下午6:12寫道：
>
> On Wed, 29 Jul 2020, Gene Chen wrote:
>
> > Lee Jones  於 2020年7月27日 週一 下午8:43寫道：
> > >
> > > On Fri, 17 Jul 2020, Gene Chen wrote:
> > >
> > > > From: Gene Chen 
> > > >
> > > > Remove unuse register definition.
> > >
> > > This should not be in here.
> > >
> > > > Merge different sub-devices i2c read/write function into one regmap,
> > >
> > > "I2C", "functions", "Regmap".
> > >
> >
> > ACK
> >
> > > > because pmic and ldo part need crc bits for access protection.
> > >
> > > "PMIC", "LDO", "CRC".
> > >
> >
> > ACK
> >
> > > > Signed-off-by: Gene Chen 
> > > > ---
> > > >  drivers/mfd/Kconfig|   1 +
> > > >  drivers/mfd/mt6360-core.c  | 229 
> > > > +-
> > > >  include/linux/mfd/mt6360.h | 240 
> > > > -
> > > >  3 files changed, 204 insertions(+), 266 deletions(-)
> > > >  delete mode 100644 include/linux/mfd/mt6360.h
> > > >
> > > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > > > index a37d7d1..0684ddc 100644
> > > > --- a/drivers/mfd/Kconfig
> > > > +++ b/drivers/mfd/Kconfig
> > > > @@ -913,6 +913,7 @@ config MFD_MT6360
> > > >   select MFD_CORE
> > > >   select REGMAP_I2C
> > > >   select REGMAP_IRQ
> > > > + select CRC8
> > > >   depends on I2C
> > > >   help
> > > > Say Y here to enable MT6360 PMU/PMIC/LDO functional support.
> > > > diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c
> > > > index 3186a7c..97ef1ad 100644
> > > > --- a/drivers/mfd/mt6360-core.c
> > > > +++ b/drivers/mfd/mt6360-core.c
> > > > @@ -14,7 +14,46 @@
> > > >  #include 
> > > >  #include 
> > > >
> > > > -#include 
> > > > +enum {
> > > > + MT6360_SLAVE_TCPC = 0,
> > > > + MT6360_SLAVE_PMIC,
> > > > + MT6360_SLAVE_LDO,
> > > > + MT6360_SLAVE_PMU,
> > > > + MT6360_SLAVE_MAX,
> > > > +};
> > > > +
> > > > +struct mt6360_data {
> > > > + struct i2c_client *i2c[MT6360_SLAVE_MAX];
> > > > + struct device *dev;
> > > > + struct regmap *regmap;
> > > > + struct regmap_irq_chip_data *irq_data;
> > > > + unsigned int chip_rev;mt6360_data
> > > > + u8 crc8_tbl[CRC8_TABLE_SIZE];
> > > > +};
> > >
> > > Make sure all of these entries are still used.
> > >
> > > > +#define MT6360_PMU_SLAVEID   0x34
> > > > +#define MT6360_PMIC_SLAVEID  0x1A
> > > > +#define MT6360_LDO_SLAVEID   0x64
> > > > +#define MT6360_TCPC_SLAVEID  0x4E
> > >
> > > Can these be placed into ID order?
> > >
> >
> > ACK
> >
> > > > +#define MT6360_REG_TCPCSTART 0x00
> > > > +#define MT6360_REG_TCPCEND   0xFF
> > > > +#define MT6360_REG_PMICSTART 0x100
> > > > +#define MT6360_REG_PMICEND   0x13B
> > > > +#define MT6360_REG_LDOSTART  0x200
> > > > +#define MT6360_REG_LDOEND0x21C
> > > > +#define MT6360_REG_PMUSTART  0x300
> > > > +#define MT6360_PMU_DEV_INFO  0x300
> > > > +#define MT6360_PMU_CHG_IRQ1  0x3D0
> > > > +#define MT6360_PMU_CHG_MASK1 0x3F0
> > > > +#define MT6360_REG_PMUEND0x3FF
> > > > +
> > > > +/* from 0x3D0 to 0x3DF */
> > >
> > > We don't need this in here.
> > >
> >
> > ACK
> >
> > > > +#define MT6360_PMU_IRQ_REGNUM16
> > > > +
> > > > +#define CHIP_VEN_MASK0xF0
> > > > +#define CHIP_VEN_MT6360  0x50
> > > > +#define CHIP_REV_MASK0x0F
> > > >
> > > >  /* reg 0 -> 0 ~ 7 */
> > > >  #define MT6360_CHG_TREG_EVT  4
> > > > @@ -220,12 +259,6 @@ static const struct regmap_irq_chip 
> > > > mt6360_irq_chip = {
> > > >   .use_ack = true,
> > > >  };
> > > >
> > > > -static const struct regmap_config mt6360_pmu_regmap_config = {
> > > > - .reg_bits = 8,
> > > > - .val_bits = 8,
> > > > - .max_register = MT6360_PMU_MAXREG,
> > > > -};
> > > > -
> > > >  static const struct resource mt6360_adc_resources[] = {
> > > >   DEFINE_RES_IRQ_NAMED(MT6360_ADC_DONEI, "adc_donei"),
> > > >  };
> > > > @@ -310,11 +343,153 @@ static int mt6360_check_vendor_info(struct 
> > > > mt6360_data *data)
> > > >   return 0;
> > > >  }
> > > >
> > > > -static const unsigned short mt6360_slave_addr[MT6360_SLAVE_MAX] = {
> > > > - MT6360_PMU_SLAVEID,
> > > > +static const u16 mt6360_slave_addrs[MT6360_SLAVE_MAX] = {
> > > > + MT6360_TCPC_SLAVEID,
> > > >   MT6360_PMIC_SLAVEID,
> > > >   MT6360_LDO_SLAVEID,
> > > > - MT6360_TCPC_SLAVEID,
> > > > + MT6360_PMU_SLAVEID,
> > > > +};
> > > > +
> > > > +static int mt6360_xlate_pmicldo_addr(u8 *addr, int rw_size)
> > > > +{
> > > > + u8 flags[4] = { 0x00, 0x40, 0x80, 0xc0 };
> > > > +
> > > > + if (rw_size < 1 || rw_size > 4)
> > > > + return -EINVAL;
> > > > +
> > > > + *addr &= 0x3f;
> > > > + *addr |= flags[rw_size - 1];
> > > > +
> > > > + return 0;
> > > > +}
> > >
> > > You need some comments in here to explain what's going on.
> > >

Re: [PATCH v16 1/3] dt-bindings: Add keypad devicetree documentation

[Yingjoe Chen]

Hi,

Summary should specified this patch is for MediaTek:

dt-bindings: add MediaTek keypad devicetree documentation


On Mon, 2020-07-27 at 19:45 +0800, Fengping Yu wrote:
> From: "fengping.yu" 

> Add Mediatek matrix keypad dt-bindings doc as yaml schema.
> 
> Signed-off-by: fengping.yu 
> ---
>  .../devicetree/bindings/input/mtk-kpd.yaml| 96 +++
>  1 file changed, 96 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/input/mtk-kpd.yaml
> 
> diff --git a/Documentation/devicetree/bindings/input/mtk-kpd.yaml 
> b/Documentation/devicetree/bindings/input/mtk-kpd.yaml
> new file mode 100644
> index ..3bf09e7395d0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/mtk-kpd.yaml
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +version: 1
> +
> +$id: http://devicetree.org/schemas/input/mtk-keypad.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek's Keypad Controller device tree bindings
> +
> +maintainer:
> +  - Fengping Yu 
> +
> +description: |
> +  Mediatek's Keypad controller is used to interface a SoC with a matrix-type
> +  keypad device. The keypad controller supports multiple row and column 
> lines.
> +  A key can be placed at each intersection of a unique row and a unique 
> column.
> +  The keypad controller can sense a key-press and key-release and report the
> +  event using a interrupt to the cpu.
> +
> +properties:
> +  compatible:
> +oneOf:
> +  - const: "mediatek,mt6779-keypad"
> +  - const: "mediatek,mt6873-keypad"
> +
> +  clock-names:
> +description: Names of the clocks listed in clocks property in the same 
> order
> +maxItems: 1

Please list the clock-names required. In this case, 'kpd'


> +
> +  clocks:
> +description: Must contain one entry, for the module clock
> +refs: devicetree/bindings/clocks/clock-bindings.txt for details.
> +
> +  interrupts:
> +description: A single interrupt specifier
> +maxItems: 1
> +
> +  linux,keymap:
> +description: The keymap for keys as described in the binding document
> +refs: devicetree/bindings/input/matrix-keymap.txt
> +minItems: 1
> +maxItems: 16

Why is this max at 16?


> +
> +  pinctrl-0:
> +description: Specify pin control groups used for this controller
> +refs: devicetree/bindings/pinctrl/pinctrl-bindings.txt
> +
> +  pinctrl-names:
> +description: Names for optional pin modes
> +maxItems: 1

I'm not sure we should list pinctrl here. 


> +
> +  reg:
> +description: The base address of the Keypad register bank
> +maxItems: 1
> +
> +  wakeup-source:
> +description: use any event on keypad as wakeup event
> +type: boolean
> +
> +  keypad,num-columns:
> +description: Number of column lines connected to the keypad controller,
> +it is not equal to PCB columns number, instead you should add required 
> value
> +for each IC
> +
> +  keypad,num-rows:
> +description: Number of row lines connected to the keypad controller, it 
> is
> +not equal to PCB rows number, instead you should add required value for 
> each IC

So the values depend on IC HW. These are not listed as required. Can
your driver works without them? Default value?

> +
> +  mediatek,debounce-us:
> +description: Debounce interval in microseconds, if not specified, the 
> default
> +value is 16000
> +maximum: 256000
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - linux,keymap
> +  - pinctrl
> +  - clocks
> +  - clock-names
> +
> +examples:
> +  - |
> +
> +  keypad: kp@1001 {

This should be 'keypad' or instead of kp.

Joe.C

> +compatible = "mediatek,mt6779-keypad";
> +reg = <0 0x1001 0 0x1000>;
> +linux,keymap = < MATRIX_KEY(0x00, 0x00, KEY_VOLUMEDOWN) >;
> +interrupts = ;
> +clocks = <>;
> +clock-names = "kpd";
> +pinctrl-names = "default";
> +pinctrl-0 = <_gpios_def_cfg>;
> +  };

linux-next: build warning after merge of the pm tree

[Stephen Rothwell]

Hi all,

After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

drivers/acpi/processor_idle.c: In function 'acpi_idle_enter_s2idle':
drivers/acpi/processor_idle.c:666:4: warning: 'return' with no value, in 
function returning non-void [-Wreturn-type]
  666 |return;
  |^~
drivers/acpi/processor_idle.c:657:12: note: declared here
  657 | static int acpi_idle_enter_s2idle(struct cpuidle_device *dev,
  |^~
drivers/acpi/processor_idle.c:670:4: warning: 'return' with no value, in 
function returning non-void [-Wreturn-type]
  670 |return;
  |^~
drivers/acpi/processor_idle.c:657:12: note: declared here
  657 | static int acpi_idle_enter_s2idle(struct cpuidle_device *dev,
  |^~

Introduced by commit

  efe9711214e6 ("cpuidle: change enter_s2idle() prototype")

-- 
Cheers,
Stephen Rothwell


pgpjl7fVAVKIR.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 4/4] vfio/type1: Use iommu_aux_at(de)tach_group() APIs

[Lu Baolu]

Hi Alex,

On 7/30/20 4:32 AM, Alex Williamson wrote:

On Tue, 14 Jul 2020 13:57:03 +0800
Lu Baolu  wrote:


Replace iommu_aux_at(de)tach_device() with iommu_aux_at(de)tach_group().
It also saves the IOMMU_DEV_FEAT_AUX-capable physcail device in the
vfio_group data structure so that it could be reused in other places.

Signed-off-by: Lu Baolu 
---
  drivers/vfio/vfio_iommu_type1.c | 44 ++---
  1 file changed, 7 insertions(+), 37 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 5e556ac9102a..f8812e68de77 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -100,6 +100,7 @@ struct vfio_dma {
  struct vfio_group {
struct iommu_group  *iommu_group;
struct list_headnext;
+   struct device   *iommu_device;
boolmdev_group; /* An mdev group */
boolpinned_page_dirty_scope;
  };
@@ -1627,45 +1628,13 @@ static struct device *vfio_mdev_get_iommu_device(struct 
device *dev)
return NULL;
  }
  
-static int vfio_mdev_attach_domain(struct device *dev, void *data)

-{
-   struct iommu_domain *domain = data;
-   struct device *iommu_device;
-
-   iommu_device = vfio_mdev_get_iommu_device(dev);
-   if (iommu_device) {
-   if (iommu_dev_feature_enabled(iommu_device, IOMMU_DEV_FEAT_AUX))
-   return iommu_aux_attach_device(domain, iommu_device);
-   else
-   return iommu_attach_device(domain, iommu_device);
-   }
-
-   return -EINVAL;
-}
-
-static int vfio_mdev_detach_domain(struct device *dev, void *data)
-{
-   struct iommu_domain *domain = data;
-   struct device *iommu_device;
-
-   iommu_device = vfio_mdev_get_iommu_device(dev);
-   if (iommu_device) {
-   if (iommu_dev_feature_enabled(iommu_device, IOMMU_DEV_FEAT_AUX))
-   iommu_aux_detach_device(domain, iommu_device);
-   else
-   iommu_detach_device(domain, iommu_device);
-   }
-
-   return 0;
-}
-
  static int vfio_iommu_attach_group(struct vfio_domain *domain,
   struct vfio_group *group)
  {
if (group->mdev_group)
-   return iommu_group_for_each_dev(group->iommu_group,
-   domain->domain,
-   vfio_mdev_attach_domain);
+   return iommu_aux_attach_group(domain->domain,
+ group->iommu_group,
+ group->iommu_device);


No, we previously iterated all devices in the group and used the aux
interface only when we have an iommu_device supporting aux.  If we
simply assume an mdev group only uses an aux domain we break existing
users, ex. SR-IOV VF backed mdevs.  Thanks,


Oh, yes. Sorry! I didn't consider the physical device backed mdevs
cases.

Looked into this part of code, it seems that there's a lock issue here.
The group->mutex is held in iommu_group_for_each_dev() and will be
acquired again in iommu_attach_device().

How about making it like:

static int vfio_iommu_attach_group(struct vfio_domain *domain,
   struct vfio_group *group)
{
if (group->mdev_group) {
struct device *iommu_device = group->iommu_device;

if (WARN_ON(!iommu_device))
return -EINVAL;

if (iommu_dev_feature_enabled(iommu_device, 
IOMMU_DEV_FEAT_AUX))
return iommu_aux_attach_device(domain->domain, 
iommu_device);

else
return iommu_attach_device(domain->domain, 
iommu_device);

} else {
return iommu_attach_group(domain->domain, 
group->iommu_group);

}
}

The caller (vfio_iommu_type1_attach_group) has guaranteed that all mdevs
in an iommu group should be derived from a same physical device.

Any thoughts?



Alex


Best regards,
baolu





else
return iommu_attach_group(domain->domain, group->iommu_group);
  }
@@ -1674,8 +1643,8 @@ static void vfio_iommu_detach_group(struct vfio_domain 
*domain,
struct vfio_group *group)
  {
if (group->mdev_group)
-   iommu_group_for_each_dev(group->iommu_group, domain->domain,
-vfio_mdev_detach_domain);
+   iommu_aux_detach_group(domain->domain, group->iommu_group,
+  group->iommu_device);
else
iommu_detach_group(domain->domain, group->iommu_group);
  }
@@ -2007,6 +1976,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
return 0;
}
  
+		group->iommu_device = iommu_device;

bus = 

[PATCH v2] mm/slab.c: add node spinlock protect in __cache_free_alien

[qiang.zhang]

From: Zhang Qiang 

Due to cpu hotplug, the "cpuup_canceled" func be called, it's currently
manipulating the alien cache for the canceled cpu's node and this node
may be the same as the node which node's alien cache being operated in
the "__cache_free_alien" func, so we should add a protect for node's alien
cache in "__cache_free_alien" func.

Fixes: 6731d4f12315 ("slab: Convert to hotplug state machine")
Signed-off-by: Zhang Qiang 
---
 v1->v2:
 change submission information and fixes tags.

 mm/slab.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index a89633603b2d..290523c90b4e 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -759,8 +759,10 @@ static int __cache_free_alien(struct kmem_cache *cachep, 
void *objp,
 
n = get_node(cachep, node);
STATS_INC_NODEFREES(cachep);
+   spin_lock(>list_lock);
if (n->alien && n->alien[page_node]) {
alien = n->alien[page_node];
+   spin_unlock(>list_lock);
ac = >ac;
spin_lock(>lock);
if (unlikely(ac->avail == ac->limit)) {
@@ -769,14 +771,15 @@ static int __cache_free_alien(struct kmem_cache *cachep, 
void *objp,
}
ac->entry[ac->avail++] = objp;
spin_unlock(>lock);
-   slabs_destroy(cachep, );
} else {
+   spin_unlock(>list_lock);
n = get_node(cachep, page_node);
spin_lock(>list_lock);
free_block(cachep, , 1, page_node, );
spin_unlock(>list_lock);
-   slabs_destroy(cachep, );
}
+
+   slabs_destroy(cachep, );
return 1;
 }
 
-- 
2.26.2

Re: [PATCH v2] usb: typec: tcpm: Migrate workqueue to RT priority for processing events

[Badhri Jagan Sridharan]

Hi Greg,

Sure just sent the new patch v3.

Patch applies cleanly on my end. So wondering what I am missing.
Just in case if you are still noticing merge conflicts.

Here is the git log of my local tree:
633198cd2945b7 (HEAD -> usb-next-1) usb: typec: tcpm: Migrate
workqueue to RT priority for processing events
fa56dd9152ef95 (origin/usb-next) Merge tag 'usb-serial-5.9-rc1' of
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into
usb-next
25252919a1050e xhci: dbgtty: Make some functions static
b0e02550346e67 xhci: dbc: Make function xhci_dbc_ring_alloc() static
ca6377900974c3 Revert "usb: dwc2: override PHY input signals with usb
role switch support"
09df709cb5aeb2 Revert "usb: dwc2: don't use ID/Vbus detection if
usb-role-switch on STM32MP15 SoCs"
17a82716587e9d USB: iowarrior: fix up report size handling for some devices
e98ba8cc3f8a89 Merge tag 'usb-for-v5.9' of
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
c97793089b11f7 Merge 5.8-rc7 into usb-next
92ed301919932f (tag: v5.8-rc7, origin/usb-linus, origin/main) Linux 5.8-rc7

Was comparing against
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/log/?h=usb-next

Thanks,
Badhri


On Wed, Jul 29, 2020 at 7:53 AM Greg Kroah-Hartman
 wrote:
>
> On Thu, Jul 23, 2020 at 07:05:51PM -0700, Badhri Jagan Sridharan wrote:
> > "tReceiverResponse 15 ms Section 6.6.2
> > The receiver of a Message requiring a response Shall respond
> > within tReceiverResponse in order to ensure that the
> > sender’s SenderResponseTimer does not expire."
> >
> > When the cpu complex is busy running other lower priority
> > work items, TCPM's work queue sometimes does not get scheduled
> > on time to meet the above requirement from the spec.
> > Moving to kthread_work apis to run with real time priority.
> > Just lower than the default threaded irq priority,
> > MAX_USER_RT_PRIO/2 + 1. (Higher number implies lower priority).
> >
> > Further, as observed in 1ff688209e2e, moving to hrtimers to
> > overcome scheduling latency while scheduling the delayed work.
> >
> > TCPM has three work streams:
> > 1. tcpm_state_machine
> > 2. vdm_state_machine
> > 3. event_work
> >
> > tcpm_state_machine and vdm_state_machine both schedule work in
> > future i.e. delayed. Hence each of them have a corresponding
> > hrtimer, tcpm_state_machine_timer & vdm_state_machine_timer.
> >
> > When work is queued right away kthread_queue_work is used.
> > Else, the relevant timer is programmed and made to queue
> > the kthread_work upon timer expiry.
> >
> > kthread_create_worker only creates one kthread worker thread,
> > hence single threadedness of workqueue is retained.
> >
> > Signed-off-by: Badhri Jagan Sridharan 
>
> This doesn't apply against my usb-next branch at all.
>
> Can you rebase and resend?
>
> Remember to collect the reviewed-by tags as well when you do so.
>
> thanks,
>
> greg k-h

Re: [PATCH v2 2/4] i2c: mediatek: Add access to more than 8GB dram in i2c driver

[Yingjoe Chen]

On Tue, 2020-07-28 at 20:30 +0800, Qii Wang wrote:
> Newer MTK chip support more than 8GB of dram. Replace support_33bits
> with more general dma_max_support and remove mtk_i2c_set_4g_mode.
> 
> Signed-off-by: Qii Wang 

Qii,

After you remove I2C_DMA_4G_MODE Matthias mentioned, you can have:

Reviewed-by: Yingjoe Chen 

Joe.C

Re: [PATCH-next v5 0/7] x86/boot: Remove run-time relocations from compressed kernel

[Kees Cook]

On Wed, Jul 29, 2020 at 06:23:41PM -0400, Arvind Sankar wrote:
> On Wed, Jul 29, 2020 at 03:04:43PM -0700, Kees Cook wrote:
> > On Fri, Jul 17, 2020 at 04:17:54PM -0400, Arvind Sankar wrote:
> > > Same as v5 previously posted, but rebased onto next-20200717.
> > > 
> > > v5: 
> > > https://lore.kernel.org/lkml/20200715004133.1430068-1-nived...@alum.mit.edu/
> > 
> > BTW, some bits of feedback on process:
> > 
> > - please don't re-use version numbers, this is confusing :)
> 
> This was a special case as there were no actual changes in this version.

It ended up missing some review tags, etc.

> > - please fix whatever is happening with the "In-Reply-To:" headers, the
> >   threading is extremely hard to understand (each patch isn't a reply to
> >   the cover letter, and everything is a reply to a single earlier email)
> 
> I think this is because I'm passing --in-reply-to to format-patch.
> Seems like I should specify that in send-email instead, hopefully that
> will fix the threading.

Ah yes, I think would do it -- it overrides the normal threading that
send-email does. Usually --in-reply-to is for a single email.

Thanks for checking!

-- 
Kees Cook

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

[James Morris]

On Thu, 30 Jul 2020, Stephen Rothwell wrote:

> > I am still applying the above patch ...
> 
> The merge window is coming up fast ... is anything happening about this
> failure?

A new patch is coming, but I'm not sure this code has had enough review 
from the core VFS folk.

Please drop secure_uffd_v5.9 for the time being.


-- 
James Morris

[tip:sched/core] BUILD SUCCESS fcd7c9c3c35aed58aba2eea6d375f0e5b03bd6d6

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git  
sched/core
branch HEAD: fcd7c9c3c35aed58aba2eea6d375f0e5b03bd6d6  arm, arm64: Fix 
selection of CONFIG_SCHED_THERMAL_PRESSURE

elapsed time: 720m

configs tested: 66
configs skipped: 1

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

arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
powerpc defconfig
x86_64   randconfig-a004-20200729
x86_64   randconfig-a005-20200729
x86_64   randconfig-a002-20200729
x86_64   randconfig-a006-20200729
x86_64   randconfig-a003-20200729
x86_64   randconfig-a001-20200729
i386 randconfig-a003-20200729
i386 randconfig-a004-20200729
i386 randconfig-a005-20200729
i386 randconfig-a002-20200729
i386 randconfig-a006-20200729
i386 randconfig-a001-20200729
i386 randconfig-a016-20200729
i386 randconfig-a012-20200729
i386 randconfig-a013-20200729
i386 randconfig-a014-20200729
i386 randconfig-a011-20200729
i386 randconfig-a015-20200729
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

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

[tip:locking/header] BUILD SUCCESS 459e39538e612b8dd130d34b93c9bfc89ecc836c

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git  
locking/header
branch HEAD: 459e39538e612b8dd130d34b93c9bfc89ecc836c  locking/qspinlock: Do 
not include atomic.h from qspinlock_types.h

elapsed time: 720m

configs tested: 66
configs skipped: 1

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

arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a004-20200729
x86_64   randconfig-a005-20200729
x86_64   randconfig-a002-20200729
x86_64   randconfig-a006-20200729
x86_64   randconfig-a003-20200729
x86_64   randconfig-a001-20200729
i386 randconfig-a003-20200729
i386 randconfig-a004-20200729
i386 randconfig-a005-20200729
i386 randconfig-a002-20200729
i386 randconfig-a006-20200729
i386 randconfig-a001-20200729
i386 randconfig-a016-20200729
i386 randconfig-a012-20200729
i386 randconfig-a013-20200729
i386 randconfig-a014-20200729
i386 randconfig-a011-20200729
i386 randconfig-a015-20200729
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

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

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

[Willy Tarreau]

On Wed, Jul 29, 2020 at 07:12:58PM -0700, Linus Torvalds wrote:
> On Wed, Jul 29, 2020 at 5:09 PM Linus Torvalds
>  wrote:
> >
> > Removing the __latent_entropy marker obviously fixes things.
> 
> Ok, I did that for now. I spent a few minutes looking at the gcc
> plugin in case I'd be hit by some sudden stroke of genius, but that
> didn't happen, so let's avoid the issue until somebody who knows the
> gcc plugins better can come up with what the right solution is.

I've looked if we couldn't we work around this by declaring another
static variable with __latent_entropy and use it to initialize
net_rand_state early, for example in prandom_init(), but there we
already fill net_rand_state with randoms so I'm wondering if that
__latent_entropy is used before prandom_init() or if its sole purpose
is to provide extra initial entropy to be combined with the one
prandom_init() will add.

Willy

Re: [PATCH v4 08/17] fs/kernel_read_file: Add file_size output argument

[James Morris]

On Wed, 29 Jul 2020, Kees Cook wrote:

> In preparation for adding partial read support, add an optional output
> argument to kernel_read_file*() that reports the file size so callers
> can reason more easily about their reading progress.
> 
> Acked-by: Scott Branden 
> Reviewed-by: Mimi Zohar 
> Reviewed-by: Luis Chamberlain 
> Signed-off-by: Kees Cook 


Reviewed-by: James Morris 


-- 
James Morris

[PATCH -next] um: Remove redundant NULL check

[Li Heng]

Fix below warnings reported by coccicheck:
./arch/um/drivers/vector_user.c:403:2-7: WARNING: NULL check before some 
freeing functions is not needed.

Signed-off-by: Li Heng 
---
 arch/um/drivers/vector_user.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/um/drivers/vector_user.c b/arch/um/drivers/vector_user.c
index c4a0f26..e836d49 100644
--- a/arch/um/drivers/vector_user.c
+++ b/arch/um/drivers/vector_user.c
@@ -399,8 +399,7 @@ static struct vector_fds *user_init_fd_fds(struct arglist 
*ifspec)
 fd_cleanup:
if (fd >= 0)
os_close_file(fd);
-   if (result != NULL)
-   kfree(result);
+   kfree(result);
return NULL;
 }
 
-- 
2.7.4

Re: [RFC PATCH] iomap: add support to track dirty state of sub pages

[Gao Xiang]

Hi Kuai,

On Thu, Jul 30, 2020 at 09:19:01AM +0800, Yu Kuai wrote:
> commit 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O
> without buffer heads") replace the per-block structure buffer_head with
> the per-page structure iomap_page. However, iomap_page can't track the
> dirty state of sub pages, which will cause performance issue since sub
> pages will be writeback even if they are not dirty.
> 
> For example, if block size is 4k and page size is 64k:
> 
> dd if=/dev/zero of=testfile bs=4k count=16 oflag=sync
> 
> With buffer_head implementation, the above dd cmd will writeback 4k in
> each round. However, with iomap_page implementation, the range of
> writeback in each round is from the start of the page to the end offset
> we just wrote.
> 
> Thus add support to track dirty state for sub pages in iomap_page.

AFAIK, the current focus is also on the numbers in the original
discussion thread, so it'd be better to show some numbers with
large PAGE_SIZE on this with some workloads as well.

https://lore.kernel.org/r/20200729230503.ga2...@dread.disaster.area

e.g. My guess is if the dirty blocks in the page are highly fragmented, maybe
it'd be better to writeback the whole page in an IO rather than individual 
blocks.

At a very quick glance, the approach looks good to me.

Thanks,
Gao Xiang

> 
> Signed-off-by: Yu Kuai 
> ---
>  fs/iomap/buffered-io.c | 51 +-
>  1 file changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index bcfc288dba3f..ac2676146b98 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -29,7 +29,9 @@ struct iomap_page {
>   atomic_tread_count;
>   atomic_twrite_count;
>   spinlock_t  uptodate_lock;
> + spinlock_t  dirty_lock;
>   DECLARE_BITMAP(uptodate, PAGE_SIZE / 512);
> + DECLARE_BITMAP(dirty, PAGE_SIZE / 512);
>  };
>  
>  static inline struct iomap_page *to_iomap_page(struct page *page)
> @@ -53,7 +55,9 @@ iomap_page_create(struct inode *inode, struct page *page)
>   atomic_set(>read_count, 0);
>   atomic_set(>write_count, 0);
>   spin_lock_init(>uptodate_lock);
> + spin_lock_init(>dirty_lock);
>   bitmap_zero(iop->uptodate, PAGE_SIZE / SECTOR_SIZE);
> + bitmap_zero(iop->dirty, PAGE_SIZE / SECTOR_SIZE);
>  
>   /*
>* migrate_page_move_mapping() assumes that pages with private data have
> @@ -135,6 +139,44 @@ iomap_adjust_read_range(struct inode *inode, struct 
> iomap_page *iop,
>   *lenp = plen;
>  }
>  
> +static void
> +iomap_iop_set_or_clear_range_dirty(
> + struct page *page,
> + unsigned int off,
> + unsigned int len,
> + bool is_set)
> +{
> + struct iomap_page *iop = to_iomap_page(page);
> + struct inode *inode = page->mapping->host;
> + unsigned int first = off >> inode->i_blkbits;
> + unsigned int last = (off + len - 1) >> inode->i_blkbits;
> + unsigned long flags;
> + unsigned int i;
> +
> + spin_lock_irqsave(>dirty_lock, flags);
> + for (i = first; i <= last; i++)
> + if (is_set)
> + set_bit(i, iop->dirty);
> + else
> + clear_bit(i, iop->dirty);
> + spin_unlock_irqrestore(>dirty_lock, flags);
> +}
> +
> +static void
> +iomap_set_or_clear_range_dirty(
> + struct page *page,
> + unsigned int off,
> + unsigned int len,
> + bool is_set)
> +{
> + if (PageError(page))
> + return;
> +
> + if (page_has_private(page))
> + iomap_iop_set_or_clear_range_dirty(
> + page, off, len, is_set);
3> +}
> +
>  static void
>  iomap_iop_set_range_uptodate(struct page *page, unsigned off, unsigned len)
>  {
> @@ -705,6 +747,8 @@ __iomap_write_end(struct inode *inode, loff_t pos, 
> unsigned len,
>   if (unlikely(copied < len && !PageUptodate(page)))
>   return 0;
>   iomap_set_range_uptodate(page, offset_in_page(pos), len);
> + iomap_set_or_clear_range_dirty(
> + page, offset_in_page(pos), len, true);
>   iomap_set_page_dirty(page);
>   return copied;
>  }
> @@ -1030,6 +1074,8 @@ iomap_page_mkwrite_actor(struct inode *inode, loff_t 
> pos, loff_t length,
>   WARN_ON_ONCE(!PageUptodate(page));
>   iomap_page_create(inode, page);
>   set_page_dirty(page);
> + iomap_set_or_clear_range_dirty(
> + page, offset_in_page(pos), length, true);
>   }
>  
>   return length;
> @@ -1386,7 +1432,8 @@ iomap_writepage_map(struct iomap_writepage_ctx *wpc,
>   for (i = 0, file_offset = page_offset(page);
>i < (PAGE_SIZE >> inode->i_blkbits) && file_offset < end_offset;
>i++, file_offset += len) {
> - if (iop && !test_bit(i, iop->uptodate))
> + if (iop && (!test_bit(i, iop->uptodate) ||
> + 

Re: [PATCH v4 07/17] fs/kernel_read_file: Switch buffer size arg to size_t

[James Morris]

On Wed, 29 Jul 2020, Kees Cook wrote:

> In preparation for further refactoring of kernel_read_file*(), rename
> the "max_size" argument to the more accurate "buf_size", and correct
> its type to size_t. Add kerndoc to explain the specifics of how the
> arguments will be used. Note that with buf_size now size_t, it can no
> longer be negative (and was never called with a negative value). Adjust
> callers to use it as a "maximum size" when *buf is NULL.
> 
> Acked-by: Scott Branden 
> Reviewed-by: Mimi Zohar 
> Reviewed-by: Luis Chamberlain 
> Signed-off-by: Kees Cook 


Reviewed-by: James Morris 


-- 
James Morris