Re: [PATCH v3 1/3] Correct asm VMXOFF side effects

[Randy Dunlap]

On 7/4/20 1:38 PM, David P. Reed wrote:
> Tell gcc that VMXOFF instruction clobbers condition codes
> and memory when executed.
> Also, correct original comments to remove kernel-doc syntax
> per Randy Dunlap's request.

Looks good. Thanks.  For the comment changes:
Acked-by: Randy Dunlap 

> Suggested-by: Randy Dunlap 
> Signed-off-by: David P. Reed 
> ---
>  arch/x86/include/asm/virtext.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/virtext.h b/arch/x86/include/asm/virtext.h
> index 9aad0e0876fb..0ede8d04535a 100644
> --- a/arch/x86/include/asm/virtext.h
> +++ b/arch/x86/include/asm/virtext.h
> @@ -30,7 +30,7 @@ static inline int cpu_has_vmx(void)
>  }
>  
>  
> -/** Disable VMX on the current CPU
> +/* Disable VMX on the current CPU
>   *
>   * vmxoff causes a undefined-opcode exception if vmxon was not run
>   * on the CPU previously. Only call this function if you know VMX
> @@ -38,7 +38,7 @@ static inline int cpu_has_vmx(void)
>   */
>  static inline void cpu_vmxoff(void)
>  {
> - asm volatile ("vmxoff");
> + asm volatile ("vmxoff" ::: "cc", "memory");
>   cr4_clear_bits(X86_CR4_VMXE);
>  }
>  
> @@ -47,7 +47,7 @@ static inline int cpu_vmx_enabled(void)
>   return __read_cr4() & X86_CR4_VMXE;
>  }
>  
> -/** Disable VMX if it is enabled on the current CPU
> +/* Disable VMX if it is enabled on the current CPU
>   *
>   * You shouldn't call this if cpu_has_vmx() returns 0.
>   */
> @@ -57,7 +57,7 @@ static inline void __cpu_emergency_vmxoff(void)
>   cpu_vmxoff();
>  }
>  
> -/** Disable VMX if it is supported and enabled on the current CPU
> +/* Disable VMX if it is supported and enabled on the current CPU
>   */
>  static inline void cpu_emergency_vmxoff(void)
>  {
> 


-- 
~Randy

Re: [PATCH v2 0/8] selftests/harness: Switch to TAP output

[Kees Cook]

On Mon, Jun 22, 2020 at 11:16:43AM -0700, Kees Cook wrote:
> Hi,
> 
> v2:
> - switch harness from XFAIL to SKIP
> - pass skip reason from test into TAP output
> - add acks/reviews
> v1: 
> https://lore.kernel.org/lkml/20200611224028.3275174-1-keesc...@chromium.org/
> 
> 
> I finally got around to converting the kselftest_harness.h API to actually
> use the kselftest.h API so all the tools using it can actually report
> TAP correctly. As part of this, there are a bunch of related cleanups,
> API updates, and additions.

Friendly ping -- I'd love to get this landed for -next, it makes doing
seccomp testing much nicer. :)

Thanks!

-Kees

> 
> Thanks!
> 
> -Kees
> 
> Kees Cook (8):
>   selftests/clone3: Reorder reporting output
>   selftests: Remove unneeded selftest API headers
>   selftests/binderfs: Fix harness API usage
>   selftests: Add header documentation and helpers
>   selftests/harness: Switch to TAP output
>   selftests/harness: Refactor XFAIL into SKIP
>   selftests/harness: Display signed values correctly
>   selftests/harness: Report skip reason
> 
>  tools/testing/selftests/clone3/clone3.c   |   2 +-
>  .../selftests/clone3/clone3_clear_sighand.c   |   3 +-
>  .../testing/selftests/clone3/clone3_set_tid.c |   2 +-
>  .../filesystems/binderfs/binderfs_test.c  | 284 +-
>  tools/testing/selftests/kselftest.h   |  78 -
>  tools/testing/selftests/kselftest_harness.h   | 169 ---
>  .../pid_namespace/regression_enomem.c |   1 -
>  .../selftests/pidfd/pidfd_getfd_test.c|   1 -
>  .../selftests/pidfd/pidfd_setns_test.c|   1 -
>  tools/testing/selftests/seccomp/seccomp_bpf.c |   8 +-
>  .../selftests/uevent/uevent_filtering.c   |   1 -
>  11 files changed, 356 insertions(+), 194 deletions(-)
> 
> -- 
> 2.25.1
> 

-- 
Kees Cook

Re: [PATCH 2/2] perf tools: Fix record failure when mixed with ARM SPE event

[Leo Yan]

On Fri, Jul 03, 2020 at 12:06:15PM +0800, liwei (GF) wrote:

[...]

Thanks for Mathieu's looping and agreed with his comments.

> > Last but not least do you know where the memory allocated for array 
> > arm_spe_pmus
> > is released?  If you can't find it either then we have a memory leak and it
> > would be nice to have that fixed.
>
> Yes, we have a memory leak here indeed, i forgot to free it in this function.
> As 'arm_spe_pmus' is defined as static, i think the author meant to assign it 
> only at the first call,
> but this function is only called once when we executing 'record', should i go 
> on fixing it
> or just drop the patch 1?

I personally think patch 1 is reasonable.  So for fixing memory leak,
I did a quick check, it's good to release the array "arm_spe_pmus" in
the function auxtrace_record__init(), since the array is only used in
this function.

Thanks,
Leo

Re: [PATCH 1/2] perf tools: ARM SPE code cleanup

[Leo Yan]

Hi Wei,

On Tue, Jun 23, 2020 at 08:31:40PM +0800, Wei Li wrote:
> Remove the useless check code to make it clear.
> 
> Signed-off-by: Wei Li 
> ---
>  tools/perf/arch/arm/util/auxtrace.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/perf/arch/arm/util/auxtrace.c 
> b/tools/perf/arch/arm/util/auxtrace.c
> index 0a6e75b8777a..62b7b03d691a 100644
> --- a/tools/perf/arch/arm/util/auxtrace.c
> +++ b/tools/perf/arch/arm/util/auxtrace.c
> @@ -57,7 +57,7 @@ struct auxtrace_record
>   struct evsel *evsel;
>   bool found_etm = false;
>   bool found_spe = false;
> - static struct perf_pmu **arm_spe_pmus = NULL;
> + static struct perf_pmu **arm_spe_pmus;

Here the 'static' should be removed as well.

Just for more complete background info, IIUC, at the beginning to
enable SPE's PMU event, since SPE is micro-architecture dependent
(though it's defined in ARMv8-ARM, but it might be different for
different ARM micro-architectures).  So this is why here it uses
'static' for varaible "arm_spe_pmus", it wants to initialize the
variable with finding all SPE PMU structure at the first time when
invoke the function auxtrace_record__init(), and afterwards we can
reuse the variable "arm_spe_pmus" and without calling
find_all_arm_spe_pmus() anymore.

So I struggled to figure out what's good thing to do with multiple SPE
PMU events, and your change is good thing to me.  The reason is:

- Firstly, the function auxtrace_record__init() will be invoked only
  once, the variable "arm_spe_pmus" will not be used afterwards, thus
  we don't need to check "arm_spe_pmus" is NULL or not;
- Another reason is, even though SPE is micro-architecture dependent,
  but so far it only supports "statistical-profiling-extension-v1" and
  we have no chance to use multiple SPE's PMU events in Perf command.


So after removing 'static' for varaible "arm_spe_pmus":
Reviewed-by: Leo Yan 


P.s. Sorry if it's my reason that James Clark's patch [1] has not been
merged in the mainline kernel and introduced duplicate efforts at here.
James's patch used similiar method to resolve this same issue.

[1] https://lkml.org/lkml/2019/12/20/293

>   static int nr_spes = 0;
>   int i = 0;
>  
> @@ -65,9 +65,7 @@ struct auxtrace_record
>   return NULL;
>  
>   cs_etm_pmu = perf_pmu__find(CORESIGHT_ETM_PMU_NAME);
> -
> - if (!arm_spe_pmus)
> - arm_spe_pmus = find_all_arm_spe_pmus(_spes, err);
> + arm_spe_pmus = find_all_arm_spe_pmus(_spes, err);
>  
>   evlist__for_each_entry(evlist, evsel) {
>   if (cs_etm_pmu &&
> -- 
> 2.17.1
> 

Re: ptrace: seccomp: Return value when the call was already invalid

[Kees Cook]

On Sat, Jul 04, 2020 at 01:33:56PM +0100, Will Deacon wrote:
> On Fri, Jul 03, 2020 at 08:52:05AM -0700, Kees Cook wrote:
> > On Fri, Jul 03, 2020 at 04:44:27PM +0100, Will Deacon wrote:
> > > On Fri, Jul 03, 2020 at 08:17:19AM -0700, Kees Cook wrote:
> > > > On Fri, Jul 03, 2020 at 09:39:14AM +0100, Will Deacon wrote:
> > > > > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> > > > > index 5f5b868292f5..a13661f44818 100644
> > > > > --- a/arch/arm64/kernel/syscall.c
> > > > > +++ b/arch/arm64/kernel/syscall.c
> > > > > @@ -121,12 +121,10 @@ static void el0_svc_common(struct pt_regs 
> > > > > *regs, int scno, int sc_nr,
> > > > >   user_exit();
> > > > >  
> > > > >   if (has_syscall_work(flags)) {
> > > > > - /* set default errno for user-issued syscall(-1) */
> > > > > - if (scno == NO_SYSCALL)
> > > > > - regs->regs[0] = -ENOSYS;
> > > > > - scno = syscall_trace_enter(regs);
> > > > > - if (scno == NO_SYSCALL)
> > > > > + if (syscall_trace_enter(regs))
> > > > >   goto trace_exit;
> > > > > +
> > > > > + scno = regs->syscallno;
> > > > >   }
> > > > >  
> > > > >   invoke_syscall(regs, scno, sc_nr, syscall_table);
> > > > 
> > > > What effect do either of these patches have on the existing seccomp
> > > > selftests: tools/testing/selftests/seccomp/seccomp_bpf ?
> > > 
> > > Tests! Thanks, I'll have a look.
> > 
> > Thanks!
> > 
> > (And either way, that this behavioral difference went unnoticed means we
> > need to add a test to the selftests for this patch.)
> 
> Unsurprisingly, I don't think the tests go near this. I get 75/77 passes
> on arm64 defconfig with or without these changes.

(What doesn't pass for you? I tried to go find kernelci.org test output,
but it doesn't appear to actually run selftests yet?)

Anyway, good that the test output doesn't change, bad that seccomp has
missed a corner of this architecture interface. (i.e. the entire
TRACE_syscall fixture is dedicated to exercising the changing/skipping
interface, but I see now that it doesn't at all exercise any area of
ENOSYS results.)

> We could add a test, but then we'd have to agree on what it's supposed to
> be doing ;)

Well, if you look at change_syscall() in seccomp_bpf.c (once you stop
screaming) you'll likely share my desire to have more things that are
common across architectures. ;) So, to that end, yes, please, let's
define what we'd like to see, and then build out the (likely wildly
different per-architecture expectations). If I read this thread
correctly, we need to test:

syscall(-1), direct,  returns ENOSYS
syscall(-10), direct, returns ENOSYS
syscall(-1), SECCOMP_RET_TRACE+PTRACE_CONT, returns ENOSYS
syscall(-10), SECCOMP_RET_TRACE+PTRACE_CONT, returns ENOSYS
syscall(-1), ptrace+PTRACE_SYSCALL, returns ENOSYS
syscall(-10), ptrace+PTRACE_SYSCALL, returns ENOSYS

do we need to double-check that registers before/after are otherwise
unchanged too? (I *think* just looking at syscall return should be
sufficient to catch the visible results.)

-- 
Kees Cook

Re: [PATCH] CodingStyle: Inclusive Terminology

[Willy Tarreau]

On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> +Non-inclusive terminology has that same distracting effect which is why
> +it is a style issue for Linux, it injures developer efficiency.

I'm personally thinking that for a non-native speaker it's already
difficult to find the best term to describe something, but having to
apply an extra level of filtering on the found words to figure whether
they are allowed by the language police is even more difficult. *This*
injures developers efficiency. What could improve developers efficiency
is to take care of removing *all* idiomatic or cultural words then. For
example I've been participating to projects using the term "blueprint",
I didn't understand what that meant. It was once explained to me and
given that it had no logical reason for being called this way, I now
forgot. If we follow your reasoning, Such words should be banned for
exactly the same reasons. Same for colors that probably don't mean
anything to those born blind.

For example if in my local culture we eat tomatoes at starters and
apples for dessert, it could be convenient for me to use "tomato" and
"apple" as list elements to name the pointers leading to the beginning
and the end of the list, and it might sound obvious to many people, but
not at all for many others.

Maybe instead of providing an explicit list of a few words it should
simply say that terms that take their roots in the non-technical world
and whose meaning can only be understood based on history or local
culture ought to be avoided, because *that* actually is the real
root cause of the problem you're trying to address.

Willy

高卒採用オンライン講座 〜高校訪問の重要性〜

[ジョブドラフトセミナー運営室]

いつもお世話になります。

この度は、高卒採用において効果の高い
“高校訪問”についてのセミナーをご案内申し上げます。


〜オンライン開催のためご自宅や職場で視聴可能です〜


21年高卒採用に向けて、求人票の作成が終わり
これからの時期に大切なのが“高校訪問”です。


進路指導の先生の手元には、膨大な求人票が届きます。


自社の求人票は、その中から生徒に紹介してもらえているでしょうか。


せっかく作った求人票も、見てもらえなければ意味もありません。


そうならないためにも“高校訪問”が大きな効果を発揮します。


しかしいざ訪問となると、タイミングや準備、
何をどう伝えるか、等々ポイントが多くあります。


そこで本講座では、2000社を超える企業へのアドバイス経験を元に
「15%以上を職場見学に繋げる」高校訪問の仕方をご紹介します。


　■　詳細・申込　https://hr-saiyo.work/200709/　■


求人票が見られているか不安だ、高校訪問をしようにも
どう動いたら良いかわからないといった悩みをお持ちの
企業様は、是非ともご参加ください。


オンライン開催


   　“高校訪問”の重要性と実施のポイント
〜15%を職場見学につなげる方法〜

　 日程：7月9日
　 時間：11:00〜11:45
　 会場：オンライン開催(ご自宅や職場で視聴可能)
　
　■　詳細・申込　https://hr-saiyo.work/200709/　■


　本メールのご不要な方には大変ご迷惑をおかけいたしました。
　配信停止ご希望の方は、お手数ですが「配信不要」と
　ご返信いただくか、下記アドレスよりお手続き願います。
　 https://form9dm.site/kaijo/

   ジョブドラフトセミナー運営室(株式会社ジンジブ)
　 住所：東京都港区浜松町2丁目7-19　KDX浜松町ビル5階
 　TEL：03-5777-2679
　 Mail：i...@hr-service.work

Re: [mm] 4e2c82a409: ltp.overcommit_memory01.fail

[Feng Tang]

On Thu, Jul 02, 2020 at 03:12:30PM +0800, Feng Tang wrote:
> > <<>>
> > tag=overcommit_memory01 stime=1593425044
> > cmdline="overcommit_memory"
> > contacts=""
> > analysis=exit
> > <<>>
> > tst_test.c:1247: INFO: Timeout per run is 0h 05m 00s
> > overcommit_memory.c:116: INFO: MemTotal is 16394252 kB
> > overcommit_memory.c:118: INFO: SwapTotal is 268435452 kB
> > overcommit_memory.c:122: INFO: CommitLimit is 276632576 kB
> > mem.c:817: INFO: set overcommit_ratio to 50
> > mem.c:817: INFO: set overcommit_memory to 2
> > overcommit_memory.c:187: INFO: malloc 551061440 kB failed
> > overcommit_memory.c:208: PASS: alloc failed as expected
> > overcommit_memory.c:183: INFO: malloc 276632576 kB successfully
> > overcommit_memory.c:210: FAIL: alloc passed, expected to fail
> 
> Thanks for the report!
> 
> I took a rough look, and it all happens after changing the
> overcommit policy from a looser one to OVERCOMMIT_NEVER. I suspect 
> it is due to the same cause as the previous warning message reported
> by Qian Cai https://lore.kernel.org/lkml/20200526181459.gd...@lca.pw/ 
> 
> Will further check it.

I did reproduce the problem, and from the debugging, this should
be the same root cause as 
https://lore.kernel.org/lkml/20200526181459.gd...@lca.pw/
that loosing the batch cause some accuracy problem, and the solution of
adding some sync is still needed, which is dicussed in 

First thing I tried a simple patch of using percpucounter_sum_read, and
the problem can't be reproduced:

--- a/mm/util.c
+++ b/mm/util.c
@@ -845,7 +845,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, 
int cap_sys_admin)
allowed -= min_t(long, mm->total_vm / 32, reserve);
}
 
-   if (percpu_counter_read_positive(_committed_as) < allowed)
+   if (percpu_counter_sum(_committed_as) < allowed)
return 0;
 error:
vm_unacct_memory(pages);
 

Then, I tried the sync patch we've discussed one month ago
https://lore.kernel.org/lkml/20200529154315.gi93...@shbuild999.sh.intel.com/  
with it, I run the case 200 times and the problem was not reproduced,
can we consider taking this patch?

Thanks,
Feng
 
diff --git a/include/linux/percpu_counter.h b/include/linux/percpu_counter.h
index 0a4f54d..01861ee 100644
--- a/include/linux/percpu_counter.h
+++ b/include/linux/percpu_counter.h
@@ -44,6 +44,7 @@ void percpu_counter_add_batch(struct percpu_counter *fbc, s64 
amount,
  s32 batch);
 s64 __percpu_counter_sum(struct percpu_counter *fbc);
 int __percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch);
+void percpu_counter_sync(struct percpu_counter *fbc);
 
 static inline int percpu_counter_compare(struct percpu_counter *fbc, s64 rhs)
 {
@@ -172,6 +173,9 @@ static inline bool percpu_counter_initialized(struct 
percpu_counter *fbc)
return true;
 }
 
+static inline void percpu_counter_sync(struct percpu_counter *fbc)
+{
+}
 #endif /* CONFIG_SMP */
 
 static inline void percpu_counter_inc(struct percpu_counter *fbc)
diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index a66595b..d025137 100644
--- a/lib/percpu_counter.c
+++ b/lib/percpu_counter.c
@@ -98,6 +98,20 @@ void percpu_counter_add_batch(struct percpu_counter *fbc, 
s64 amount, s32 batch)
 }
 EXPORT_SYMBOL(percpu_counter_add_batch);
 
+void percpu_counter_sync(struct percpu_counter *fbc)
+{
+   unsigned long flags;
+   s64 count;
+
+   raw_spin_lock_irqsave(>lock, flags);
+   count = __this_cpu_read(*fbc->counters);
+   fbc->count += count;
+   __this_cpu_sub(*fbc->counters, count);
+   raw_spin_unlock_irqrestore(>lock, flags);
+}
+EXPORT_SYMBOL(percpu_counter_sync);
+
+
 /*
  * Add up all the per-cpu counts, return the result.  This is a more accurate
  * but much slower version of percpu_counter_read_positive()
diff --git a/mm/util.c b/mm/util.c
index 98813da..8b9664e 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -746,14 +746,23 @@ int overcommit_ratio_handler(struct ctl_table *table, int 
write, void *buffer,
return ret;
 }
 
+static  void sync_overcommit_as(struct work_struct *dummy)
+{
+   percpu_counter_sync(_committed_as);
+}
+
 int overcommit_policy_handler(struct ctl_table *table, int write, void *buffer,
size_t *lenp, loff_t *ppos)
 {
int ret;
 
ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
-   if (ret == 0 && write)
+   if (ret == 0 && write) {
+   if (sysctl_overcommit_memory == OVERCOMMIT_NEVER)
+   schedule_on_each_cpu(sync_overcommit_as);
+
mm_compute_batch();
+   }
 
pr_info("ocommit=%lld, real=%lld policy[%d] ratio=%d\n\n\n",
percpu_counter_read_positive(_committed_as),

drivers/net/ethernet/intel/ice/ice_flex_pipe.c:2826:44: sparse: sparse: non size-preserving pointer to integer cast

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   35e884f89df4c48566d745dc5a97a0d058d04263
commit: 148beb612031255156d68b342170140524afb36e ice: Initialize Flow Director 
resources
date:   6 weeks ago
config: i386-randconfig-s001-20200705 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-3-gfa153962-dirty
git checkout 148beb612031255156d68b342170140524afb36e
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 

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


sparse warnings: (new ones prefixed by >>)

>> drivers/net/ethernet/intel/ice/ice_flex_pipe.c:2826:44: sparse: sparse: non 
>> size-preserving pointer to integer cast
--
>> drivers/net/ethernet/intel/ice/ice_flow.c:832:20: sparse: sparse: non 
>> size-preserving pointer to integer cast
>> drivers/net/ethernet/intel/ice/ice_flow.c:860:17: sparse: sparse: non 
>> size-preserving integer to pointer cast

vim +2826 drivers/net/ethernet/intel/ice/ice_flex_pipe.c

  2810  
  2811  /**
  2812   * ice_free_flow_profs - free flow profile entries
  2813   * @hw: pointer to the hardware structure
  2814   * @blk_idx: HW block index
  2815   */
  2816  static void ice_free_flow_profs(struct ice_hw *hw, u8 blk_idx)
  2817  {
  2818  struct ice_flow_prof *p, *tmp;
  2819  
  2820  mutex_lock(>fl_profs_locks[blk_idx]);
  2821  list_for_each_entry_safe(p, tmp, >fl_profs[blk_idx], 
l_entry) {
  2822  struct ice_flow_entry *e, *t;
  2823  
  2824  list_for_each_entry_safe(e, t, >entries, l_entry)
  2825  ice_flow_rem_entry(hw, (enum ice_block)blk_idx,
> 2826 ICE_FLOW_ENTRY_HNDL(e));
  2827  
  2828  list_del(>l_entry);
  2829  devm_kfree(ice_hw_to_dev(hw), p);
  2830  }
  2831  mutex_unlock(>fl_profs_locks[blk_idx]);
  2832  
  2833  /* if driver is in reset and tables are being cleared
  2834   * re-initialize the flow profile list heads
  2835   */
  2836  INIT_LIST_HEAD(>fl_profs[blk_idx]);
  2837  }
  2838  

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


.config.gz
Description: application/gzip

Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster

[Jan Ziak]

On Sun, Jul 5, 2020 at 5:27 AM Matthew Wilcox  wrote:
>
> On Sun, Jul 05, 2020 at 05:18:58AM +0200, Jan Ziak wrote:
> > On Sun, Jul 5, 2020 at 5:12 AM Matthew Wilcox  wrote:
> > >
> > > You should probably take a look at io_uring.  That has the level of
> > > complexity of this proposal and supports open/read/close along with many
> > > other opcodes.
> >
> > Then glibc can implement readfile using io_uring and there is no need
> > for a new single-file readfile syscall.
>
> It could, sure.  But there's also a value in having a simple interface
> to accomplish a simple task.  Your proposed API added a very complex
> interface to satisfy needs that clearly aren't part of the problem space
> that Greg is looking to address.

I believe that we should look at the single-file readfile syscall from
a performance viewpoint. If an application is expecting to read a
couple of small/medium-size files per second, then neither readfile
nor readfiles makes sense in terms of improving performance. The
benefits start to show up only in case an application is expecting to
read at least a hundred of files per second. The "per second" part is
important, it cannot be left out. Because readfile only improves
performance for many-file reads, the syscall that applications
performing many-file reads actually want is the multi-file version,
not the single-file version.

I am not sure I understand why you think that a pointer to an array of
readfile_t structures is very complex. If it was very complex then it
would be a deep tree or a large graph.

[PATCH v2 0/2] shtc1: add support for device tree bindings

[Chris Ruehl]

Add support for DTS bindings to the shtc driver
The patches add the compatible table and of_property_read_bool to the
shtc1.c. Newly created Yaml document has been released to the
Documentation/devicetree/hwmon/sensirion,shtc1.yaml

Signed-off-by: Chris Ruehl 
---
 Version 2
remove the #ifdef CONFIG_OF
ignore platform data if dev->of_node is valid
use boolean only therefor use sensirion,low_precise to fit the logic
add missing driver.of_match_table entry
 Version 1
initial version

[PATCH v2 1/2] hwmon: shtc1: add support for device tree bindings

[Chris Ruehl]

Add support for DTS bindings for the sensirion shtc1,shtw1 and shtc3.

Signed-off-by: Chris Ruehl 
---
 drivers/hwmon/shtc1.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/shtc1.c b/drivers/hwmon/shtc1.c
index a0078ccede03..61e9275eb666 100644
--- a/drivers/hwmon/shtc1.c
+++ b/drivers/hwmon/shtc1.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* commands (high precision mode) */
 static const unsigned char shtc1_cmd_measure_blocking_hpm[]= { 0x7C, 0xA2 
};
@@ -196,6 +197,7 @@ static int shtc1_probe(struct i2c_client *client,
enum shtcx_chips chip = id->driver_data;
struct i2c_adapter *adap = client->adapter;
struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
 
if (!i2c_check_functionality(adap, I2C_FUNC_I2C)) {
dev_err(dev, "plain i2c transactions not supported\n");
@@ -233,8 +235,13 @@ static int shtc1_probe(struct i2c_client *client,
data->client = client;
data->chip = chip;
 
-   if (client->dev.platform_data)
+   if (np) {
+   data->setup.blocking_io = of_property_read_bool(np, 
"sensirion,blocking_io");
+   data->setup.high_precision = of_property_read_bool(np, 
"sensicon,low_precision");
+   }
+   else if (client->dev.platform_data)
data->setup = *(struct shtc1_platform_data *)dev->platform_data;
+
shtc1_select_command(data);
mutex_init(>update_lock);
 
@@ -257,8 +264,19 @@ static const struct i2c_device_id shtc1_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, shtc1_id);
 
+static const struct of_device_id shtc1_of_match[] = {
+   { .compatible = "sensirion,shtc1" },
+   { .compatible = "sensirion,shtw1" },
+   { .compatible = "sensirion,shtc3" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, shtc1_of_match);
+
 static struct i2c_driver shtc1_i2c_driver = {
-   .driver.name  = "shtc1",
+   .driver = {
+   .name = "shtc1",
+   .of_match_table = shtc1_of_match,
+   },
.probe= shtc1_probe,
.id_table = shtc1_id,
 };
-- 
2.20.1

[PATCH v2 2/2] devicetree: hwmon: shtc1: Add sensirion,shtc1.yaml

[Chris Ruehl]

Add documentation for the newly added DTS support in the shtc1 driver.
To align with the drivers logic to have high precision by default
a boolean sensirion,low_precision is used to switch to low precision.

Signed-off-by: Chris Ruehl 
---
 .../bindings/hwmon/sensirion,shtc1.yaml   | 53 +++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml

diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml 
b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
new file mode 100644
index ..bcccdcadd86b
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/sensirion,shtc1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sensirion SHTC1 Humidity and Temperature Sensor IC
+
+maintainers:
+  - jdelv...@suse.com
+
+description: |
+  The SHTC1, SHTW1 and SHTC3 are digital humidity and temperature sensor
+  designed especially for battery-driven high-volume consumer electronics
+  applications.
+  For further information refere to Documentation/hwmon/shtc1.rst
+
+  This binding document describes the binding for the hardware monitor
+  portion of the driver.
+
+properties:
+  compatible:
+enum:
+  - sensirion,shtc1
+  - sensirion,shtw1
+  - sensirion,shtc3
+
+  reg: I2C address 0x70
+
+Optional properties:
+  sensirion,blocking_io: |
+bool, if set the i2c bus hold until measure finished
+  sensirion,low_precision: |
+bool, if set aquire data with low precision (not recommend)
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+Example:
+   {
+status = "okay";
+clock-frequency = <40>;
+
+shtc3@70 {
+  compatible = "sensirion,shtc3";
+  reg = <0x70>
+  sensirion,blocking_io;
+  status = "okay";
+};
+  };
-- 
2.20.1

Re: [PATCH 1/1] iommu/arm-smmu: Implement qcom,skip-init

[Bjorn Andersson]

On Sat 04 Jul 06:09 PDT 2020, Will Deacon wrote:

> [Adding Bjorn, Jordan and John because I really don't want a bunch of
> different ways to tell the driver that the firmware is screwing things up]
> 

Thanks Will.

> On Sat, Jul 04, 2020 at 02:28:09PM +0200, Konrad Dybcio wrote:
> > This adds the downstream property required to support
> > SMMUs on SDM630 and other platforms (the need for it
> > most likely depends on firmware configuration).
> > 
> > Signed-off-by: Konrad Dybcio 
> > ---
> >  .../devicetree/bindings/iommu/arm,smmu.yaml   | 10 ++
> >  drivers/iommu/arm-smmu.c  | 15 +--
> >  2 files changed, 19 insertions(+), 6 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml 
> > b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> > index d7ceb4c34423..9abd6d41a32c 100644
> > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> > @@ -102,6 +102,16 @@ properties:
> >access to SMMU configuration registers. In this case non-secure 
> > aliases of
> >secure registers have to be used during SMMU configuration.
> >  
> > +  qcom,skip-init:
> > +description: |
> > +  Disable resetting configuration for all context banks
> > +  during device reset.  This is useful for targets where
> > +  some context banks are dedicated to other execution
> > +  environments outside of Linux and those other EEs are
> > +  programming their own stream match tables, SCTLR, etc.
> > +  Without setting this option we will trample on their
> > +  configuration.
> 
> It would probably be better to know _which_ context banks we shouldn't
> touch, no? Otherwise what happens to the others?
> 

>From my investigations of the issue of maintaining the boot display
through the initialization of arm-smmu I assume the reason for skipping
this step don't want to flush out the SMR, S2CR and context bank
initialization because it would disrupt the display hardware's access to
memory.

And in itself I believe that this is quite certainly going to work -
until you start attaching devices. Because in itself this does nothing
to ensure that the driver won't overwrite stream mapping or context bank
configuration as devices are attached.

So on e.g. SDM845 we need to ensure that the driver doesn't stomp over
the display mapping left by the bootloader.


Further more, on platforms such as QCS405 (which are derived from
platforms supported by qcom_iommu today), the stream mapping registers
(SMR and S2CR) are write ignore, which means that without knowledge
about the existing mappings the hardware and driver will be out of sync.

NB. Compared to the platforms that is supported by qcom_iommu, the
stream mapping registers are readable on these newer platforms, while on
e.g. MSM8916 we get an access violation by attempting to read SMR/S2CR.

> > +
> >stream-match-mask:
> >  $ref: /schemas/types.yaml#/definitions/uint32
> >  description: |
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > index 243bc4cb2705..a5c623d4caf9 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -1655,13 +1655,16 @@ static void arm_smmu_device_reset(struct 
> > arm_smmu_device *smmu)
> >  * Reset stream mapping groups: Initial values mark all SMRn as
> >  * invalid and all S2CRn as bypass unless overridden.
> >  */
> > -   for (i = 0; i < smmu->num_mapping_groups; ++i)
> > -   arm_smmu_write_sme(smmu, i);
> >  
> > -   /* Make sure all context banks are disabled and clear CB_FSR  */
> > -   for (i = 0; i < smmu->num_context_banks; ++i) {
> > -   arm_smmu_write_context_bank(smmu, i);
> > -   arm_smmu_cb_write(smmu, i, ARM_SMMU_CB_FSR, ARM_SMMU_FSR_FAULT);
> > +   if (!of_find_property(smmu->dev->of_node, "qcom,skip-init", NULL)) {
> > +   for (i = 0; i < smmu->num_mapping_groups; ++i)
> > +   arm_smmu_write_sme(smmu, i);
> > +
> > +   /* Make sure all context banks are disabled and clear CB_FSR  */
> > +   for (i = 0; i < smmu->num_context_banks; ++i) {
> > +   arm_smmu_write_context_bank(smmu, i);
> > +   arm_smmu_cb_write(smmu, i, ARM_SMMU_CB_FSR, 
> > ARM_SMMU_FSR_FAULT);
> > +   }
> > }
> 
> Do we not need to worry about the SMRs as well?
> 

I don't think we should skip the actual initialization, because to avoid
strange side effects we need to ensure that the driver and hardware are
in sync (either for specific streams/banks or for all of them).

I've continued my work on supporting boot display on e.g. SDM845, based
on Thierry's patches, but still have some unresolved corner cases to
fully resolve - e.g. how to ensure that the display hardware's stream
mapping survives the probe deferral of the display driver. Hopefully I
will be able to post something in a few days.



That said, 

Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster

[Matthew Wilcox]

On Sun, Jul 05, 2020 at 05:18:58AM +0200, Jan Ziak wrote:
> On Sun, Jul 5, 2020 at 5:12 AM Matthew Wilcox  wrote:
> >
> > You should probably take a look at io_uring.  That has the level of
> > complexity of this proposal and supports open/read/close along with many
> > other opcodes.
> 
> Then glibc can implement readfile using io_uring and there is no need
> for a new single-file readfile syscall.

It could, sure.  But there's also a value in having a simple interface
to accomplish a simple task.  Your proposed API added a very complex
interface to satisfy needs that clearly aren't part of the problem space
that Greg is looking to address.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Stephen Rothwell]

Hi Dave,

On Sun, 5 Jul 2020 12:56:23 +1000 Dave Airlie  wrote:
>
> Sorry I misdirected what you said a bit, and I did misinterpret as
> Australia also has it's own indigenous slavery issues,

(and non-indigenous :-()

> I was trying to stop the "white slavery" is a thing crew from turning
> up on this.
> 
> Apologies for accidentally implying something what you hadn't said.

Sure

No worries, mate :-)

-- 
Cheers,
Stephen Rothwell


pgp9iVXH1cll9.pgp
Description: OpenPGP digital signature

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[James Bottomley]

On Sun, 2020-07-05 at 12:56 +1000, Dave Airlie wrote:
> On Sun, 5 Jul 2020 at 12:12, Stephen Rothwell 
> wrote:
[...]
> > > As for the non-black slavery, others have never pointed this out
> > 
> > (I did not say "non-black")
> > 
> 
> Sorry I misdirected what you said a bit, and I did misinterpret as
> Australia also has it's own indigenous slavery issues,
> 
> I was trying to stop the "white slavery" is a thing crew from turning
> up on this.
> 
> Apologies for accidentally implying something what you hadn't said.

Not at all, thank you; you just gave a precise illustration of my
point: putting statements like this in the kernel acts as a magnet for
this type of disagreement ... and not just from honourable people. 
Developers can honestly disagree about this sort of thing, while
supporting the aim of using inclusive language.  That's why this file
shouldn't be in the kernel tree.

James

Re: [mm] 4e2c82a409: ltp.overcommit_memory01.fail

[Qian Cai]

On Thu, Jul 02, 2020 at 03:12:30PM +0800, Feng Tang wrote:
> Hi,
> 
> On Thu, Jul 02, 2020 at 02:32:01PM +0800, kernel test robot wrote:
> > Greeting,
> > 
> > FYI, we noticed the following commit (built with gcc-9):
> > 
> > commit: 4e2c82a40911c19419349918e675aa202b113b4d ("[PATCH v5 3/3] mm: 
> > adjust vm_committed_as_batch according to vm overcommit policy")
> > url: 
> > https://github.com/0day-ci/linux/commits/Feng-Tang/make-vm_committed_as_batch-aware-of-vm-overcommit-policy/20200621-153906
> > 
> > 
> > in testcase: ltp
> > with following parameters:
> > 
> > disk: 1HDD
> > test: mm-01
> > 
> > test-description: The LTP testsuite contains a collection of tools for 
> > testing the Linux kernel and related features.
> > test-url: http://linux-test-project.github.io/
> > 
> > 
> > on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 
> > 16G
> > 
> > caused below changes (please refer to attached dmesg/kmsg for entire 
> > log/backtrace):
> > 
> > 
> > 
> > 
> > If you fix the issue, kindly add following tag
> > Reported-by: kernel test robot 
> > 
> > 
> > 
> > <<>>
> > tag=overcommit_memory01 stime=1593425044
> > cmdline="overcommit_memory"
> > contacts=""
> > analysis=exit
> > <<>>
> > tst_test.c:1247: INFO: Timeout per run is 0h 05m 00s
> > overcommit_memory.c:116: INFO: MemTotal is 16394252 kB
> > overcommit_memory.c:118: INFO: SwapTotal is 268435452 kB
> > overcommit_memory.c:122: INFO: CommitLimit is 276632576 kB
> > mem.c:817: INFO: set overcommit_ratio to 50
> > mem.c:817: INFO: set overcommit_memory to 2
> > overcommit_memory.c:187: INFO: malloc 551061440 kB failed
> > overcommit_memory.c:208: PASS: alloc failed as expected
> > overcommit_memory.c:183: INFO: malloc 276632576 kB successfully
> > overcommit_memory.c:210: FAIL: alloc passed, expected to fail
> 
> Thanks for the report!
> 
> I took a rough look, and it all happens after changing the
> overcommit policy from a looser one to OVERCOMMIT_NEVER. I suspect 
> it is due to the same cause as the previous warning message reported
> by Qian Cai https://lore.kernel.org/lkml/20200526181459.gd...@lca.pw/ 

Hmm, the LTP test [1] looks like a faithful implementation of
Documentation/vm/overcommit-accounting.rst which is now failing because
of this patchset.

Also, It was a mistake to merge c571686a92ff ("mm/util.c: remove the
VM_WARN_ONCE for vm_committed_as underflow check") separately (I am
taking a blame to ACK it separately and I forgot to run those tests to
double-check earlier) which is now making me wonder that VM_WARN_ONCE is
actually legitimate to catch the sign of brokenness in the first place.

[1] 
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/tunable/overcommit_memory.c

> 
> Will further check it.
> 
> Thanks,
> Feng
> 
> > overcommit_memory.c:183: INFO: malloc 137765294 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as expected
> > mem.c:817: INFO: set overcommit_memory to 0
> > overcommit_memory.c:183: INFO: malloc 140770308 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as expected
> > overcommit_memory.c:187: INFO: malloc 569659408 kB failed
> > overcommit_memory.c:208: PASS: alloc failed as expected
> > mem.c:817: INFO: set overcommit_memory to 1
> > overcommit_memory.c:183: INFO: malloc 142414852 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as expected
> > overcommit_memory.c:183: INFO: malloc 284829704 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as expected
> > overcommit_memory.c:183: INFO: malloc 569659408 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as expected
> > mem.c:817: INFO: set overcommit_memory to 0
> > mem.c:817: INFO: set overcommit_ratio to 50
> > 
> > Summary:
> > passed   7
> > failed   1
> > skipped  0
> > warnings 0
> > <<>>
> > initiation_status="ok"
> > duration=0 termination_type=exited termination_id=1 corefile=no
> > cutime=0 cstime=1
> > <<>>
> > <<>>
> > tag=overcommit_memory02 stime=1593425044
> > cmdline="overcommit_memory -R 0"
> > contacts=""
> > analysis=exit
> > <<>>
> > tst_test.c:1247: INFO: Timeout per run is 0h 05m 00s
> > overcommit_memory.c:116: INFO: MemTotal is 16394252 kB
> > overcommit_memory.c:118: INFO: SwapTotal is 268435452 kB
> > overcommit_memory.c:122: INFO: CommitLimit is 276632576 kB
> > mem.c:817: INFO: set overcommit_ratio to 0
> > mem.c:817: INFO: set overcommit_memory to 2
> > overcommit_memory.c:187: INFO: malloc 534667184 kB failed
> > overcommit_memory.c:208: PASS: alloc failed as expected
> > overcommit_memory.c:183: INFO: malloc 268435452 kB successfully
> > overcommit_memory.c:210: FAIL: alloc passed, expected to fail
> > overcommit_memory.c:183: INFO: malloc 133666730 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as expected
> > mem.c:817: INFO: set overcommit_memory to 0
> > overcommit_memory.c:183: INFO: malloc 140770304 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as 

Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster

[Jan Ziak]

On Sun, Jul 5, 2020 at 5:12 AM Matthew Wilcox  wrote:
>
> You should probably take a look at io_uring.  That has the level of
> complexity of this proposal and supports open/read/close along with many
> other opcodes.

Then glibc can implement readfile using io_uring and there is no need
for a new single-file readfile syscall.

[PATCH] ARM: dts: vf610-zii-ssmb-dtu: Pass "no-sdio"/"no-sd" properties

[Chris Healy]

esdhc0 is connected to an eMMC, so it is safe to pass the "no-sdio"/"no-sd"
properties.

esdhc1 is wired to a standard SD socket, so pass the "no-sdio" property.

Signed-off-by: Chris Healy 
---
 arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
index 0bb3dcff0b79..7d4ddfb6b5b5 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
@@ -81,6 +81,8 @@
 non-removable;
 no-1-8-v;
 keep-power-in-suspend;
+no-sdio;
+no-sd;
 status = "okay";
 };

@@ -88,6 +90,7 @@
 pinctrl-names = "default";
 pinctrl-0 = <_esdhc1>;
 bus-width = <4>;
+no-sdio;
 status = "okay";
 };

-- 
2.21.3

drivers/soc/qcom/smd-rpm.c:177:47: sparse: sparse: incorrect type in argument 2 (different address spaces)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   35e884f89df4c48566d745dc5a97a0d058d04263
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to 
define address spaces
date:   2 weeks ago
config: ia64-randconfig-s031-20200705 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-3-gfa153962-dirty
git checkout 670d0a4b10704667765f7d18f7592993d02783aa
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=ia64 

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


sparse warnings: (new ones prefixed by >>)

>> drivers/soc/qcom/smd-rpm.c:177:47: sparse: sparse: incorrect type in 
>> argument 2 (different address spaces) @@ expected void const volatile 
>> [noderef] __iomem *src @@ got unsigned char const * @@
>> drivers/soc/qcom/smd-rpm.c:177:47: sparse: expected void const volatile 
>> [noderef] __iomem *src
   drivers/soc/qcom/smd-rpm.c:177:47: sparse: got unsigned char const *

vim +177 drivers/soc/qcom/smd-rpm.c

936f14cf4e6716 Bjorn Andersson 2015-07-27  146  
5052de8deff561 Bjorn Andersson 2017-03-27  147  static int 
qcom_smd_rpm_callback(struct rpmsg_device *rpdev,
5052de8deff561 Bjorn Andersson 2017-03-27  148  
 void *data,
5052de8deff561 Bjorn Andersson 2017-03-27  149  
 int count,
5052de8deff561 Bjorn Andersson 2017-03-27  150  
 void *priv,
5052de8deff561 Bjorn Andersson 2017-03-27  151  
 u32 addr)
936f14cf4e6716 Bjorn Andersson 2015-07-27  152  {
936f14cf4e6716 Bjorn Andersson 2015-07-27  153  const struct 
qcom_rpm_header *hdr = data;
30b7ea5eda0afb Stephen Boyd2015-09-02  154  size_t hdr_length = 
le32_to_cpu(hdr->length);
936f14cf4e6716 Bjorn Andersson 2015-07-27  155  const struct 
qcom_rpm_message *msg;
5052de8deff561 Bjorn Andersson 2017-03-27  156  struct qcom_smd_rpm 
*rpm = dev_get_drvdata(>dev);
936f14cf4e6716 Bjorn Andersson 2015-07-27  157  const u8 *buf = data + 
sizeof(struct qcom_rpm_header);
30b7ea5eda0afb Stephen Boyd2015-09-02  158  const u8 *end = buf + 
hdr_length;
936f14cf4e6716 Bjorn Andersson 2015-07-27  159  char msgbuf[32];
936f14cf4e6716 Bjorn Andersson 2015-07-27  160  int status = 0;
30b7ea5eda0afb Stephen Boyd2015-09-02  161  u32 len, msg_length;
936f14cf4e6716 Bjorn Andersson 2015-07-27  162  
30b7ea5eda0afb Stephen Boyd2015-09-02  163  if 
(le32_to_cpu(hdr->service_type) != RPM_SERVICE_TYPE_REQUEST ||
30b7ea5eda0afb Stephen Boyd2015-09-02  164  hdr_length < 
sizeof(struct qcom_rpm_message)) {
b853cb9628bfbc Bjorn Andersson 2016-03-28  165  
dev_err(rpm->dev, "invalid request\n");
936f14cf4e6716 Bjorn Andersson 2015-07-27  166  return 0;
936f14cf4e6716 Bjorn Andersson 2015-07-27  167  }
936f14cf4e6716 Bjorn Andersson 2015-07-27  168  
936f14cf4e6716 Bjorn Andersson 2015-07-27  169  while (buf < end) {
936f14cf4e6716 Bjorn Andersson 2015-07-27  170  msg = (struct 
qcom_rpm_message *)buf;
30b7ea5eda0afb Stephen Boyd2015-09-02  171  msg_length = 
le32_to_cpu(msg->length);
30b7ea5eda0afb Stephen Boyd2015-09-02  172  switch 
(le32_to_cpu(msg->msg_type)) {
936f14cf4e6716 Bjorn Andersson 2015-07-27  173  case 
RPM_MSG_TYPE_MSG_ID:
936f14cf4e6716 Bjorn Andersson 2015-07-27  174  break;
936f14cf4e6716 Bjorn Andersson 2015-07-27  175  case 
RPM_MSG_TYPE_ERR:
30b7ea5eda0afb Stephen Boyd2015-09-02  176  len = 
min_t(u32, ALIGN(msg_length, 4), sizeof(msgbuf));
936f14cf4e6716 Bjorn Andersson 2015-07-27 @177  
memcpy_fromio(msgbuf, msg->message, len);
936f14cf4e6716 Bjorn Andersson 2015-07-27  178  
msgbuf[len - 1] = 0;
936f14cf4e6716 Bjorn Andersson 2015-07-27  179  
936f14cf4e6716 Bjorn Andersson 2015-07-27  180  if 
(!strcmp(msgbuf, "resource does not exist"))
936f14cf4e6716 Bjorn Andersson 2015-07-27  181  
status = -ENXIO;
936f14cf4e6716 Bjorn Andersson 2015-07-27  182  else
936f14cf4e6716 Bjorn Andersson 2015-07-27  183  
status = -EINVAL;
936f14cf4e6716 Bjorn Andersson 2015-07-27  184  break;
936f14cf4e6716 Bjorn Andersson 2015-07-27  185  }
936f14cf4e6716 Bjorn Andersson 2015-07-27  

Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster

[Matthew Wilcox]

On Sun, Jul 05, 2020 at 04:46:04AM +0200, Jan Ziak wrote:
> On Sun, Jul 5, 2020 at 4:16 AM Matthew Wilcox  wrote:
> >
> > On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote:
> > > Hello
> > >
> > > At first, I thought that the proposed system call is capable of
> > > reading *multiple* small files using a single system call - which
> > > would help increase HDD/SSD queue utilization and increase IOPS (I/O
> > > operations per second) - but that isn't the case and the proposed
> > > system call can read just a single file.
> > >
> > > Without the ability to read multiple small files using a single system
> > > call, it is impossible to increase IOPS (unless an application is
> > > using multiple reader threads or somehow instructs the kernel to
> > > prefetch multiple files into memory).
> >
> > What API would you use for this?
> >
> > ssize_t readfiles(int dfd, char **files, void **bufs, size_t *lens);
> >
> > I pretty much hate this interface, so I hope you have something better
> > in mind.
> 
> I am proposing the following:
> 
> struct readfile_t {
>   int dirfd;
>   const char *pathname;
>   void *buf;
>   size_t count;
>   int flags;
>   ssize_t retval; // set by kernel
>   int reserved; // not used by kernel
> };
> 
> int readfiles(struct readfile_t *requests, size_t count);
> 
> Returns zero if all requests succeeded, otherwise the returned value
> is non-zero (glibc wrapper: -1) and user-space is expected to check
> which requests have succeeded and which have failed. retval in
> readfile_t is set to what the single-file readfile syscall would
> return if it was called with the contents of the corresponding
> readfile_t struct.

You should probably take a look at io_uring.  That has the level of
complexity of this proposal and supports open/read/close along with many
other opcodes.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dave Airlie]

On Sun, 5 Jul 2020 at 12:12, Stephen Rothwell  wrote:
>
> Hi Dave,
>
> On Sun, 5 Jul 2020 09:34:57 +1000 Dave Airlie  wrote:
> >
> > On Sun, 5 Jul 2020 at 06:45, Stephen Rothwell  wrote:
> > >
> > > On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams 
> > >  wrote:
> > > >
> > > > +The Linux kernel is a global software project, and in 2020 there was a
> > > > +global reckoning on race relations that caused many organizations to
> > > > +re-evaluate their policies and practices relative to the inclusion of
> > > > +people of African descent. This document describes why the 'Naming'
> > >
> > > I feel a need to point out that racial issues are wider than just
> > > people of African descent ...  Also, others have pointed out that
> > > slavery is not just restricted to those of African descent.
> >
> > The racial issues are wider than that, and even wider again I'm sure,
> > but in 2020 this is as good a place to start as any, and the trigger
> > as that sentence says was in 2020, there was a reckoning about it
> > mainly due to people of African descent. That trigger has had flow on
> > effects in other countries, but I'm not sure that sentence in any way
> > diminishes that, it's merely an introduction to why this change is
> > happening now.
>
> And reading it again in the (actual) light of day, I see you are right
> and I misinterpreted this.
>
> > As for the non-black slavery, others have never pointed this out
>
> (I did not say "non-black")
>

Sorry I misdirected what you said a bit, and I did misinterpret as
Australia also has it's own indigenous slavery issues,

I was trying to stop the "white slavery" is a thing crew from turning
up on this.

Apologies for accidentally implying something what you hadn't said.

Dave.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dave Airlie]

On Sun, 5 Jul 2020 at 10:10, Matthew Wilcox  wrote:
>
> Erm, red-black trees don't have a derivation from gambling terminology 
> either. The wikipedia article says:
>
> In a 1978 paper, "A Dichromatic Framework for Balanced Trees",[6] Leonidas J. 
> Guibas and Robert Sedgewick derived the red-black tree from the symmetric 
> binary B-tree.[7] The color "red" was chosen because it was the best-looking 
> color produced by the color laser printer available to the authors while 
> working at Xerox PARC.[8] Another response from Guibas states that it was 
> because of the red and black pens available to them to draw the trees.[9]
>
> Left-right tree makes no sense. It doesn't distinguish the rbtree from its 
> predecessor the avl tree.  I don't think it's helpful to rename a standard 
> piece of computing terminology unless it's actually hurting us to have it. 
> Obviously if it were called a "master-slave" tree, I would be in favour of 
> renaming it.

As I said "it means nothing if you've never interacted with gambling
culture," red black in the context of the trees as zero meaning other
than as a name to find it on the internet, Search for that name enough
and you will undoubtedly be getting ads for online roulette sites
within hours, if you have a problem gambling past, this might not be
the desired effect you'd want.

The reasons something was named a particular thing can and will be
different from what a societal context for them means now, and I
believe it's more important to worry about current societal contexts
than legacy historical namings. I'm not seriously suggesting we rename
red-black trees, but if someone who had a problematic gambling
background had issues with them I'd definitely be open for considering
it.

Dave.

Re: [PATCH] readfile.2: new page describing readfile(2)

[Heinrich Schuchardt]

On 7/4/20 4:02 PM, Greg Kroah-Hartman wrote:
> readfile(2) is a new syscall to remove the need to do the
> open/read/close dance for small virtual files in places like procfs or
> sysfs.
>
> Signed-off-by: Greg Kroah-Hartman 
> ---
>
> This patch is for the man-pages project, not the kernel source tree
>
>  man2/readfile.2 | 159 
>  1 file changed, 159 insertions(+)
>  create mode 100644 man2/readfile.2
>
> diff --git a/man2/readfile.2 b/man2/readfile.2
> new file mode 100644
> index ..449e722c3442
> --- /dev/null
> +++ b/man2/readfile.2
> @@ -0,0 +1,159 @@
> +.\" This manpage is Copyright (C) 2020 Greg Kroah-Hartman;
> +.\"  and Copyright (C) 2020 The Linux Foundation
> +.\"
> +.\" %%%LICENSE_START(VERBATIM)
> +.\" Permission is granted to make and distribute verbatim copies of this
> +.\" manual provided the copyright notice and this permission notice are
> +.\" preserved on all copies.
> +.\"
> +.\" Permission is granted to copy and distribute modified versions of this
> +.\" manual under the conditions for verbatim copying, provided that the
> +.\" entire resulting derived work is distributed under the terms of a
> +.\" permission notice identical to this one.
> +.\"
> +.\" Since the Linux kernel and libraries are constantly changing, this
> +.\" manual page may be incorrect or out-of-date.  The author(s) assume no
> +.\" responsibility for errors or omissions, or for damages resulting from
> +.\" the use of the information contained herein.  The author(s) may not
> +.\" have taken the same level of care in the production of this manual,
> +.\" which is licensed free of charge, as they might when working
> +.\" professionally.
> +.\"
> +.\" Formatted or processed versions of this manual, if unaccompanied by
> +.\" the source, must acknowledge the copyright and authors of this work.
> +.\" %%%LICENSE_END
> +.\"
> +.TH READFILE 2 2020-07-04 "Linux" "Linux Programmer's Manual"
> +.SH NAME
> +readfile \- read a file into a buffer
> +.SH SYNOPSIS
> +.nf
> +.B #include 
> +.PP
> +.BI "ssize_t readfile(int " dirfd ", const char *" pathname ", void *" buf \
> +", size_t " count ", int " flags );
> +.fi
> +.SH DESCRIPTION
> +.BR readfile ()
> +attempts to open the file specified by
> +.IR pathname
> +and to read up to
> +.I count
> +bytes from the file into the buffer starting at
> +.IR buf .
> +It is to be a shortcut of doing the sequence of

Just my personal preference for concise language:

It replaces the sequence of

> +.BR open ()
> +and then

%s/and then /, /

> +.BR read ()
> +and then

%s/and then/, and/

> +.BR close ()
> +for small files that are read frequently, such as those in

". It reduces system call overheads especially for small files, like
those in"

readfile() makes sense even if each individual file is only read once,
not frequently.

Below you describe that file up to 2GiB can be read. So readfile() seems
to be a shortcut for larger files too.

> +.B procfs
> +or
> +.BR sysfs .

Executing readfile() generates the same file notification events as said
individual calls (cf. fanotify.7, inotify.7).

> +.PP
> +If the size of file is smaller than the value provided in
> +.I count
> +then the whole file will be copied into
> +.IR buf .
> +.PP
> +If the file is larger than the value provided in
> +.I count
> +then only
> +.I count
> +number of bytes will be copied into
> +.IR buf .
> +.PP
> +The argument
> +.I flags
> +may contain one of the following
> +.IR "access modes" :
> +.BR O_NOFOLLOW ", or " O_NOATIME .
> +.PP
> +If the pathname given in
> +.I pathname
> +is relative, then it is interpreted relative to the directory
> +referred to by the file descriptor
> +.IR dirfd .
> +.PP
> +If
> +.I pathname
> +is relative and
> +.I dirfd
> +is the special value
> +.BR AT_FDCWD ,
> +then
> +.I pathname
> +is interpreted relative to the current working
> +directory of the calling process (like
> +.BR openat ()).
> +.PP
> +If
> +.I pathname
> +is absolute, then
> +.I dirfd
> +is ignored.

readfile() blocks until either the whole file has been read, the buffer
is completely filled, or the system specific limit (see below) has been
reached.

> +.SH RETURN VALUE
> +On success, the number of bytes read is returned.
> +It is not an error if this number is smaller than the number of bytes
> +requested; this can happen if the file is smaller than the number of
> +bytes requested.

"It is not an error ..." is very vague. Are there any other cases where
a file is only partially read and the number of bytes returned is less
then the minimum of buffer size and file size? How would I discover
truncation?

Or can I rely on the call returning either an error or said minimum
number of bytes? In the latter case:

"When reading from a block device this always equals the minimum of the
buffer size specified by 'count', the file size, and the system specific
limit for read.2 calls (see below)."

> +.PP
> +On error, \-1 is returned, and
> +.I errno
> +is set 

[PATCH] HID: logitech: Use HIDPP_RECEIVER_INDEX instead of 0xff

[Mazin Rezk]

Some parts of hid-logitech-dj explicitly referred to 0xff for the
receiver index. This patch changes those references to the
HIDPP_RECEIVER_INDEX definition.

Signed-off-by: Mazin Rezk 
---
 drivers/hid/hid-logitech-dj.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 48dff5d6b605..a78c13cc9f47 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -1153,7 +1153,7 @@ static int logi_dj_recv_query_paired_devices(struct 
dj_receiver_dev *djrcv_dev)
if (!dj_report)
return -ENOMEM;
dj_report->report_id = REPORT_ID_DJ_SHORT;
-   dj_report->device_index = 0xFF;
+   dj_report->device_index = HIDPP_RECEIVER_INDEX;
dj_report->report_type = REPORT_TYPE_CMD_GET_PAIRED_DEVICES;
retval = logi_dj_recv_send_report(djrcv_dev, dj_report);
kfree(dj_report);
@@ -1175,7 +1175,7 @@ static int logi_dj_recv_switch_to_dj_mode(struct 
dj_receiver_dev *djrcv_dev,

if (djrcv_dev->type == recvr_type_dj) {
dj_report->report_id = REPORT_ID_DJ_SHORT;
-   dj_report->device_index = 0xFF;
+   dj_report->device_index = HIDPP_RECEIVER_INDEX;
dj_report->report_type = REPORT_TYPE_CMD_SWITCH;
dj_report->report_params[CMD_SWITCH_PARAM_DEVBITFIELD] = 0x3F;
dj_report->report_params[CMD_SWITCH_PARAM_TIMEOUT_SECONDS] =
@@ -1204,7 +1204,7 @@ static int logi_dj_recv_switch_to_dj_mode(struct 
dj_receiver_dev *djrcv_dev,
memset(buf, 0, HIDPP_REPORT_SHORT_LENGTH);

buf[0] = REPORT_ID_HIDPP_SHORT;
-   buf[1] = 0xFF;
+   buf[1] = HIDPP_RECEIVER_INDEX;
buf[2] = 0x80;
buf[3] = 0x00;
buf[4] = 0x00;
--
2.27.0

Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster

[Jan Ziak]

On Sun, Jul 5, 2020 at 4:16 AM Matthew Wilcox  wrote:
>
> On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote:
> > Hello
> >
> > At first, I thought that the proposed system call is capable of
> > reading *multiple* small files using a single system call - which
> > would help increase HDD/SSD queue utilization and increase IOPS (I/O
> > operations per second) - but that isn't the case and the proposed
> > system call can read just a single file.
> >
> > Without the ability to read multiple small files using a single system
> > call, it is impossible to increase IOPS (unless an application is
> > using multiple reader threads or somehow instructs the kernel to
> > prefetch multiple files into memory).
>
> What API would you use for this?
>
> ssize_t readfiles(int dfd, char **files, void **bufs, size_t *lens);
>
> I pretty much hate this interface, so I hope you have something better
> in mind.

I am proposing the following:

struct readfile_t {
  int dirfd;
  const char *pathname;
  void *buf;
  size_t count;
  int flags;
  ssize_t retval; // set by kernel
  int reserved; // not used by kernel
};

int readfiles(struct readfile_t *requests, size_t count);

Returns zero if all requests succeeded, otherwise the returned value
is non-zero (glibc wrapper: -1) and user-space is expected to check
which requests have succeeded and which have failed. retval in
readfile_t is set to what the single-file readfile syscall would
return if it was called with the contents of the corresponding
readfile_t struct.

The glibc library wrapper of this system call is expected to store the
errno in the "reserved" field. Thus, a programmer using glibc sees:

struct readfile_t {
  int dirfd;
  const char *pathname;
  void *buf;
  size_t count;
  int flags;
  ssize_t retval; // set by glibc (-1 on error)
  int errno; // set by glibc if retval is -1
};

retval and errno in glibc's readfile_t are set to what the single-file
glibc readfile would return (retval) and set (errno) if it was called
with the contents of the corresponding readfile_t struct. In case of
an error, glibc will pick one readfile_t which failed (such as: the
1st failed one) and use it to set glibc's errno.

Re: [Tech-board-discuss] [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Randy Dunlap]

On 7/4/20 6:10 PM, Kees Cook wrote:
> On Sat, Jul 04, 2020 at 08:10:33PM -0400, Matthew Wilcox wrote:
>> Left-right tree makes no sense. It doesn't distinguish the rbtree from its
>> predecessor the avl tree.  I don't think it's helpful to rename a standard
>> piece of computing terminology unless it's actually hurting us to have it.
>> Obviously if it were called a "master-slave" tree, I would be in favour of
>> renaming it.
> 
> (No one has suggested renaming red/black trees, so I think the
> slippery-slope argument can be set aside here.)

Did you read this message?

https://lore.kernel.org/ksummit-discuss/CAPM=9ty0til_qm_ufv0s0vtarkz_f-anngc+amdm5ljgaha...@mail.gmail.com/

> As for the actual proposal on white/black-list, I've always been annoyed
> by the poor description it provides (and I get to see it A LOT being
> the seccomp maintainer). I welcome allow/deny-list (though the change is
> not new for seccomp -- the man pages were updated last year (thanks
> mkerrisk). :)
> 


-- 
~Randy

Re: [PATCH] kbuild: Allow Clang global merging if !MODULES

[Nathan Chancellor]

Hi Danny,

On Thu, Jul 02, 2020 at 04:39:29PM -0700, Danny Lin wrote:
> The old reasoning for disabling Clang's global merging optimization is
> that it breaks modpost by coalescing many symbols into _MergedGlobals.
> However, modpost is only used in builds with dynamic modules;
> vmlinux.symvers is still created during standalone builds, but it's
> effectively just an empty dummy file.
> 
> Enabling the optimization whenever possible allows us to reap the
> benefits of reduced register pressure when many global variables are
> used in the same function.

Have you run into any place within the kernel that this is the case or
this more of a "could help if this ever happens" type of deal?

> An x86 defconfig kernel built with this optimization boots fine in qemu,
> and a downstream 4.14 kernel has been used on arm64 for nearly a year
> without any issues caused by this optimization.

If I am reading LLVM's source correctly, this option only seems relevant
for ARM and AArch64?

$ rg --no-heading createGlobalMergePass
llvm/lib/CodeGen/GlobalMerge.cpp:679:Pass *llvm::createGlobalMergePass(const 
TargetMachine *TM, unsigned Offset,
llvm/lib/Target/AArch64/AArch64TargetMachine.cpp:524:
addPass(createGlobalMergePass(TM, 4095, OnlyOptimizeForSize,
llvm/lib/Target/ARM/ARMTargetMachine.cpp:456:
addPass(createGlobalMergePass(TM, 127, OnlyOptimizeForSize,
llvm/include/llvm/CodeGen/Passes.h:419:  Pass *createGlobalMergePass(const 
TargetMachine *TM, unsigned MaximalOffset,

Otherwise, I think this is probably okay. According to [1], when the
optimization level is less than -O3, we get a less aggressive version of
this optimization level, which is good for code size:

https://github.com/llvm/llvm-project/commit/8207641251706ea808df6d2a1ea8f87b8ee04c6d

However, we do potentially get merging of extern globals if we do not
specify -mglobal-merge (if I am reading the source correctly), which
this commit claims might hurt performance? Not sure if there is any way
to test or verify that?

https://github.com/llvm/llvm-project/commit/de73404b8c4332190750537eb93ce0d5b6451300

> Signed-off-by: Danny Lin 
> ---
>  Makefile | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index a60c98519c37..f04c3639cf61 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -772,10 +772,13 @@ ifdef CONFIG_CC_IS_CLANG
>  KBUILD_CPPFLAGS += -Qunused-arguments
>  KBUILD_CFLAGS += -Wno-format-invalid-specifier
>  KBUILD_CFLAGS += -Wno-gnu
> +
> +ifdef CONFIG_MODULES
>  # CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as 
> the
>  # source of a reference will be _MergedGlobals and not on of the whitelisted 
> names.
>  # See modpost pattern 2
>  KBUILD_CFLAGS += -mno-global-merge
> +endif
>  else
>  
>  # These warnings generated too much noise in a regular build.
> -- 
> 2.27.0
> 

Cheers,
Nathan

Re: [PATCH 2/2] devicetree: hwmon: shtc1: Add sensirion,shtc1.yaml

[Guenter Roeck]

On 7/4/20 5:30 PM, Chris Ruehl wrote:
> Hi Guenter,
> 
> On 3/7/2020 1:49 pm, Guenter Roeck wrote:
>> On 7/2/20 8:48 PM, Chris Ruehl wrote:
>>> Add documentation for the newly added DTS support in the shtc1 driver.
>>>
>>> Signed-off-by: Chris Ruehl 
>>> ---
>>>   .../bindings/hwmon/sensirion,shtc1.yaml   | 53 +++
>>>   1 file changed, 53 insertions(+)
>>>   create mode 100644 
>>> Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml 
>>> b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
>>> new file mode 100644
>>> index ..e3e292bc6d7d
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
>>> @@ -0,0 +1,53 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/hwmon/sensirion,shtc1.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Sensirion SHTC1 Humidity and Temperature Sensor IC
>>> +
>>> +maintainers:
>>> +  - jdelv...@suse.com
>>> +
>>> +description: |
>>> +  The SHTC1, SHTW1 and SHTC3 are digital humidity and temperature sensor
>>> +  designed especially for battery-driven high-volume consumer electronics
>>> +  applications.
>>> +  For further information refere to Documentation/hwmon/shtc1.rst
>>> +
>>> +  This binding document describes the binding for the hardware monitor
>>> +  portion of the driver.
>>> +
>>> +properties:
>>> +  compatible:
>>> +    enum:
>>> +  - sensirion,shtc1
>>> +  - sensirion,shtw1
>>> +  - sensirion,shtc3
>>> +
>>> +  reg: I2C address 0x70
>>> +
>>> +Optional properties:
>>> +  sensirion,blocking_io: |
>>> +    u8, if > 0 the i2c bus hold until measure finished (default 0)
>>> +  sensirion,high_precision: |
>>> +    u8, if > 0 aquire data with high precision (default 1)
>>> +
>> Why u8 and not boolean ?
>>
>> Guenter
> The author of the driver make high_precision default (recommend) in the code,
> if I use boolean, then the device tree _must_ have have the 
> sensirion,high_precision set
> or I need to do the opposite and define sensirion,low_precision.
> (blocking_io = false default, high_precision = true default)
> 
> that's the reason I was thinking use a u8 and test with of_property_read_bool 
> to check
> the presence of it and set it if value > 0.
> 

Devicetree properties are supposed to be independent from actual 
implementations.
Declaring "we must do so because of an existing implementation" would set a 
really
bad precedence - everyone could use that later on to push through arbitrary sets
of devicetree properties. On top of that, this is supposed to be a new set of
bindings, with no one using it today. Any argument along the line of "must have"
seems irrelevant, since there is no real concern about devicetree backwards
compatibility. And on top of all that, I find the currently suggested code
really awkward and convoluted.

With that in mind, I personally would neither accept your argument nor your 
code.
If you object to defining sensirion,high_precision as boolean, and at the same
time object to defining sensirion,low_precision as well, I'd say, fine, then
let's stick with what we have today.

Anyway, I'll follow Rob's guidance.

Guenter

drivers/mtd/nand/raw/xway_nand.c:227:30: error: 'mtd' undeclared

[kernel test robot]

Hi Miquel,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   35e884f89df4c48566d745dc5a97a0d058d04263
commit: 9fdd78f7bcda3e6a9f53c355529b3bf037c0e24f mtd: rawnand: xway: Stop using 
nand_release()
date:   5 weeks ago
config: mips-xway_defconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 9fdd78f7bcda3e6a9f53c355529b3bf037c0e24f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=mips 

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

All errors (new ones prefixed by >>):

   drivers/mtd/nand/raw/xway_nand.c: In function 'xway_nand_remove':
>> drivers/mtd/nand/raw/xway_nand.c:227:30: error: 'mtd' undeclared (first use 
>> in this function)
 227 |  ret = mtd_device_unregister(mtd);
 |  ^~~
   drivers/mtd/nand/raw/xway_nand.c:227:30: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/mtd +227 drivers/mtd/nand/raw/xway_nand.c

   217  
   218  /*
   219   * Remove a NAND device.
   220   */
   221  static int xway_nand_remove(struct platform_device *pdev)
   222  {
   223  struct xway_nand_data *data = platform_get_drvdata(pdev);
   224  struct nand_chip *chip = >chip;
   225  int ret;
   226  
 > 227  ret = mtd_device_unregister(mtd);
   228  WARN_ON(ret);
   229  nand_cleanup(chip);
   230  
   231  return 0;
   232  }
   233  

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


.config.gz
Description: application/gzip

Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster

[Matthew Wilcox]

On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote:
> Hello
> 
> At first, I thought that the proposed system call is capable of
> reading *multiple* small files using a single system call - which
> would help increase HDD/SSD queue utilization and increase IOPS (I/O
> operations per second) - but that isn't the case and the proposed
> system call can read just a single file.
> 
> Without the ability to read multiple small files using a single system
> call, it is impossible to increase IOPS (unless an application is
> using multiple reader threads or somehow instructs the kernel to
> prefetch multiple files into memory).

What API would you use for this?

ssize_t readfiles(int dfd, char **files, void **bufs, size_t *lens);

I pretty much hate this interface, so I hope you have something better
in mind.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Stephen Rothwell]

Hi Dave,

On Sun, 5 Jul 2020 09:34:57 +1000 Dave Airlie  wrote:
>
> On Sun, 5 Jul 2020 at 06:45, Stephen Rothwell  wrote:
> >
> > On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams  
> > wrote:  
> > >
> > > +The Linux kernel is a global software project, and in 2020 there was a
> > > +global reckoning on race relations that caused many organizations to
> > > +re-evaluate their policies and practices relative to the inclusion of
> > > +people of African descent. This document describes why the 'Naming'  
> >
> > I feel a need to point out that racial issues are wider than just
> > people of African descent ...  Also, others have pointed out that
> > slavery is not just restricted to those of African descent.  
> 
> The racial issues are wider than that, and even wider again I'm sure,
> but in 2020 this is as good a place to start as any, and the trigger
> as that sentence says was in 2020, there was a reckoning about it
> mainly due to people of African descent. That trigger has had flow on
> effects in other countries, but I'm not sure that sentence in any way
> diminishes that, it's merely an introduction to why this change is
> happening now.

And reading it again in the (actual) light of day, I see you are right
and I misinterpreted this.

> As for the non-black slavery, others have never pointed this out

(I did not say "non-black")

> before in 30 years of master/slave terminology? surely if white
> slavery was as big a problem, they be as supportive of this, even more

(nor did I say "white slavery")

> so. It speaks volumes that I've never heard white slavery as a problem
> once in 30 years, but now I'm hearing about it a few times, and
> somehow as an excuse not to support this.

I was merely referring to some of the posts in the
us...@linux.kernel.org mailing list.  Also, I made no statement about
my support (or otherwise) for any of this.

-- 
Cheers,
Stephen Rothwell


pgpq0Xsz_EX5d.pgp
Description: OpenPGP digital signature

Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster

[Jan Ziak]

Hello

At first, I thought that the proposed system call is capable of
reading *multiple* small files using a single system call - which
would help increase HDD/SSD queue utilization and increase IOPS (I/O
operations per second) - but that isn't the case and the proposed
system call can read just a single file.

Without the ability to read multiple small files using a single system
call, it is impossible to increase IOPS (unless an application is
using multiple reader threads or somehow instructs the kernel to
prefetch multiple files into memory).

While you are at it, why not also add a readfiles system call to read
multiple, presumably small, files? The initial unoptimized
implementation of readfiles syscall can simply call readfile
sequentially.

Sincerely
Jan (atomsymbol)

Re: [PATCH 4.19 114/131] ocfs2: avoid inode removal while nfsd is accessing it

[Junxiao Bi]

On 7/2/20 3:24 PM, Linus Torvalds wrote:


On Thu, Jul 2, 2020 at 2:17 PM Pavel Machek  wrote:



commit 4cd9973f9ff69e37dd0ba2bd6e6423f8179c329a upstream.

Patch series "ocfs2: fix nfsd over ocfs2 issues", v2.

This causes locking imbalance:

This sems to be true upstream too.


When ocfs2_nfs_sync_lock() returns error, caller can not know if the
lock was taken or not.

Right you are.

And your patch looks sane:


diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index c141b06811a6..8149fb6f1f0d 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -2867,9 +2867,15 @@ int ocfs2_nfs_sync_lock(struct ocfs2_super *osb, int ex)

 status = ocfs2_cluster_lock(osb, lockres, ex ? LKM_EXMODE : LKM_PRMODE,
 0, 0);
-   if (status < 0)
+   if (status < 0) {
 mlog(ML_ERROR, "lock on nfs sync lock failed %d\n", status);

+   if (ex)
+   up_write(>nfs_sync_rwlock);
+   else
+   up_read(>nfs_sync_rwlock);
+   }
+
 return status;
  }

although the whole thing looks messy.

If the issue is a lifetime thing (like that commit says), the proper
model isn't a lock, but a refcount.

Oh well. Junxiao?


There is a block number embedded in nfs file handle, to verify it's an 
inode, need acquire this nfs_sync_lock global lock to avoid any inode 
removed from local node and other nodes in the cluster, before this 
verify done, seemed no way to use a refcount.


Thanks,

Junxiao.



Linus

Re: Are there some potentially serious problems that I should be aware of if I totally disable the CONFIG_ACPI option on the X86_64 platform?

[孙世龙 sunshilong]

I see. Thank you .

Pavel Machek  于2020年7月5日周日 上午4:09写道：
>
> On Sat 2020-07-04 21:34:36, 孙世龙 sunshilong wrote:
> > Thank you for taking the time to respond to me.
> >
> > >These machines are still mostly IBM-PC compatible, so it is likely to
> > >somehow work. You'll likely get worse power and thermal
> > >management. Try it.
> > It's an industrial personal computer with an Intel processor.
> > What I am worried about is that it may damage the hardware.
>
> I'd simply try it. Risk is really quite low...
>
> If in doubt, you could ask vendor.
>
> But you will not get definitive answers on the mailing list...
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 3/3] selftests: add readfile(2) selftests

[Heinrich Schuchardt]

On 7/4/20 4:02 PM, Greg Kroah-Hartman wrote:
> Test the functionality of readfile(2) in various ways.

Hello Greg,

I expect readfile() to generate fanotify events FAN_OPEN_PERM, FAN_OPEN,
FAN_ACCESS_PERM, FAN_ACCESS, FAN_CLOSE_NOWRITE in this sequence.

Looking at patch 1/3 you took care of notifications. Would this deserve
testing here?

Best regards

Heinrich

>
> Also provide a simple speed test program to benchmark using readfile()
> instead of using open()/read()/close().
>
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  tools/testing/selftests/Makefile  |   1 +
>  tools/testing/selftests/readfile/.gitignore   |   3 +
>  tools/testing/selftests/readfile/Makefile |   7 +
>  tools/testing/selftests/readfile/readfile.c   | 285 +
>  .../selftests/readfile/readfile_speed.c   | 301 ++
>  5 files changed, 597 insertions(+)
>  create mode 100644 tools/testing/selftests/readfile/.gitignore
>  create mode 100644 tools/testing/selftests/readfile/Makefile
>  create mode 100644 tools/testing/selftests/readfile/readfile.c
>  create mode 100644 tools/testing/selftests/readfile/readfile_speed.c
>
> diff --git a/tools/testing/selftests/Makefile 
> b/tools/testing/selftests/Makefile
> index 1195bd85af38..82359233b945 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -46,6 +46,7 @@ TARGETS += ptrace
>  TARGETS += openat2
>  TARGETS += rseq
>  TARGETS += rtc
> +TARGETS += readfile
>  TARGETS += seccomp
>  TARGETS += sigaltstack
>  TARGETS += size
> diff --git a/tools/testing/selftests/readfile/.gitignore 
> b/tools/testing/selftests/readfile/.gitignore
> new file mode 100644
> index ..f0e758d437e4
> --- /dev/null
> +++ b/tools/testing/selftests/readfile/.gitignore
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +readfile
> +readfile_speed
> diff --git a/tools/testing/selftests/readfile/Makefile 
> b/tools/testing/selftests/readfile/Makefile
> new file mode 100644
> index ..1bf1bdec40f8
> --- /dev/null
> +++ b/tools/testing/selftests/readfile/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +CFLAGS += -g -I../../../../usr/include/
> +CFLAGS += -O2 -Wl,-no-as-needed -Wall
> +
> +TEST_GEN_PROGS := readfile readfile_speed
> +
> +include ../lib.mk
> diff --git a/tools/testing/selftests/readfile/readfile.c 
> b/tools/testing/selftests/readfile/readfile.c
> new file mode 100644
> index ..f0736c6dfa69
> --- /dev/null
> +++ b/tools/testing/selftests/readfile/readfile.c
> @@ -0,0 +1,285 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Greg Kroah-Hartman 
> + * Copyright (c) 2020 The Linux Foundation
> + *
> + * Test the readfile() syscall in various ways.
> + */
> +#define _GNU_SOURCE
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "../kselftest.h"
> +
> +//#ifndef __NR_readfile
> +//#define __NR_readfile  -1
> +//#endif
> +
> +#define __NR_readfile440
> +
> +#define TEST_FILE1   "/sys/devices/system/cpu/vulnerabilities/meltdown"
> +#define TEST_FILE2   "/sys/devices/system/cpu/vulnerabilities/spectre_v1"
> +#define TEST_FILE4   "/sys/kernel/debug/usb/devices"
> +
> +static int sys_readfile(int fd, const char *filename, unsigned char *buffer,
> + size_t bufsize, int flags)
> +{
> + return syscall(__NR_readfile, fd, filename, buffer, bufsize, flags);
> +}
> +
> +/*
> + * Test that readfile() is even in the running kernel or not.
> + */
> +static void test_readfile_supported(void)
> +{
> + const char *proc_map = "/proc/self/maps";
> + unsigned char buffer[10];
> + int retval;
> +
> + if (__NR_readfile < 0)
> + ksft_exit_skip("readfile() syscall is not defined for the 
> kernel this test was built against\n");
> +
> + /*
> +  * Do a simple test to see if the syscall really is present in the
> +  * running kernel
> +  */
> + retval = sys_readfile(0, proc_map, [0], sizeof(buffer), 0);
> + if (retval == -1)
> + ksft_exit_skip("readfile() syscall not present on running 
> kernel\n");
> +
> + ksft_test_result_pass("readfile() syscall present\n");
> +}
> +
> +/*
> + * Open all files in a specific sysfs directory and read from them
> + *
> + * This tests the "openat" type functionality of opening all files relative 
> to a
> + * directory.  We don't care at the moment about the contents.
> + */
> +static void test_sysfs_files(void)
> +{
> + static unsigned char buffer[8000];
> + const char *sysfs_dir = "/sys/devices/system/cpu/vulnerabilities/";
> + struct dirent *dirent;
> + DIR *vuln_sysfs_dir;
> + int sysfs_fd;
> + int retval;
> +
> + sysfs_fd = open(sysfs_dir, O_PATH | O_DIRECTORY);
> + if (sysfs_fd == -1) {
> + ksft_test_result_skip("unable to open %s directory\n",
> +   sysfs_dir);
> +  

[PATCH] ARM: dts: vfxxx: Add node for CAAM

[Chris Healy]

Add node for CAAM device in NXP Vybrid SoC.

Signed-off-by: Andrey Smirnov 
Signed-off-by: Chris Healy 
---
 arch/arm/boot/dts/vfxxx.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 2d547e7b21ad..0fe03aa0367f 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -729,6 +729,28 @@
 dma-names = "rx","tx";
 status = "disabled";
 };
+
+crypto: crypto@400f {
+compatible = "fsl,sec-v4.0";
+#address-cells = <1>;
+#size-cells = <1>;
+reg = <0x400f 0x9000>;
+ranges = <0 0x400f 0x9000>;
+clocks = < VF610_CLK_CAAM>;
+clock-names = "ipg";
+
+sec_jr0: jr0@1000 {
+compatible = "fsl,sec-v4.0-job-ring";
+reg = <0x1000 0x1000>;
+interrupts = <102 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+sec_jr1: jr1@2000 {
+compatible = "fsl,sec-v4.0-job-ring";
+reg = <0x2000 0x1000>;
+interrupts = <102 IRQ_TYPE_LEVEL_HIGH>;
+};
+};
 };
 };
 };
--
2.21.3

RE: [PATCH] arm64: dts: exynos: Add minimal bootargs

[Alim Akhtar]

Hi Krzysztof,

> > > @@ -24,6 +24,7 @@
> > >
> > >   chosen {
> > >   stdout-path = _2;
> > > + bootargs = "earlycon=exynos4210,0x14c3
> > > console=ttySAC0,115200n8";
> 
> Hi,
> 
> The console is already chosen by stdout-path and earlycon would use it as 
> well,
> so no need for the address. It should be just "earlycon" if you want to 
> enable it
> unconditionally.
> 
Indeed only "earlycon" will do here. Thanks for point this out.

> Also, why did you use different serial for console?
> 
Once UART driver gets probed then console changes to ttySAC0. In case I am 
using stdout-path only,
after bootconsole is disabled, kernel logs re-start printing from beginning 
(which might be expected behaviour?)

[0.012416] printk: console [tty0] enabled
[0.016491] printk: bootconsole [exynos4210] disabled
[0.00] Booting Linux on physical CPU 0x00 [0x410fd032]
[0.00] Linux version 5.8.0-rc3-next-20200703-8-g4af626444f4a-dirty 
(alim@alim) (aarch64-linux-gnu-gcc (Linaro GCC 7.4-2019.02) 7.4.1 20181213 [l0
[0.00] Machine model: Samsung Exynos7 Espresso board based on Exynos7

> However the question is, are you sure you want earlycon on every, including
> successful boot? On most of the boards we do not enable by default. If
> developer needs, he can choose it for example via U-Boot "setenv opts
> earlycon".
> 
Using U-Boot is not the case always, any bootload can be used to boot the 
Linux, currently I am Coreboot.
And 'earlycon' is not setup by default.
As Espresson board is development board, IMO it is ok to keep it enable all the 
time, this helps in quickly knowing what going on incase boot fails early.
Let me know if it is ok to keep " console=ttySAC0,115200n8" or shell I just 
re-spin with only 'earlycon'? or any other suggestion?

Thanks!

> However it's a development kit so it could be enabled on default...
> 
> Best regards,
> Krzysztof
> 
> > >   };
> > >
> > >   memory@4000 {
> > >
> > > base-commit: 9e50b94b3eb0d859a2586b5a40d7fd6e5afd9210
> > > --
> > > 2.17.1
> >
> >

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Kees Cook]

On Sun, Jul 05, 2020 at 09:39:29AM +1000, Dave Airlie wrote:
> I don't totally agree on that, because like the CoC discussion, people
> need concrete examples. People need reasons, saying simply "be
> inclusive" doesn't work.
> 
> You say "be inclusive" people don't think about it, they just go "I'm
> inclusive" and proceed, never questioning what it means to be
> inclusive, they normalise inclusivity to their self image and within
> their lives where they might never confront anything like this.
> 
> I don't doubt we get the American/Ottoman/Barbery coast people and the
> correct answer to those people is to tell them to examine why they
> suddenly care about Barbery slavery now when they have never even
> heard or worried about it before. Why haven't they submitted patches
> removing slavery terminology from the kernel before?

Right; this part of the patch provides a temporal explanation for "but
why now?" and acts as an internal reference, instead of pointing to
external[1] sources, which lack the Linux-specific contextualization.

Additionally, I think it provides rebuttals to many of the specious
arguments against inclusive terminology (and it could perhaps gain
more, as we've already seen in this thread, against slippery slope
arguments). It also attempts to acknowledge what this change in the
kernel processes provides to the world in general: it's a fairly local
change to make our development community less disruptive to those that
would seek to join it -- it does not, and cannot, solve global racism
(though that would be nice).

[1] https://tools.ietf.org/id/draft-knodel-terminology-01.html

-- 
Kees Cook

drivers/bluetooth/hci_qca.c:1692:35: warning: unused variable 'qca_soc_data_wcn3990'

[kernel test robot]

Hi Rocky,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   35e884f89df4c48566d745dc5a97a0d058d04263
commit: e5d6468fe9d8dced9af0c548a359a7dbeb31c931 Bluetooth: hci_qca: Add 
support for Qualcomm Bluetooth SoC QCA6390
date:   3 months ago
config: x86_64-randconfig-a001-20200705 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
e359ab1eca5727ce4c688bb49323b8a09478d61c)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout e5d6468fe9d8dced9af0c548a359a7dbeb31c931
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

>> drivers/bluetooth/hci_qca.c:1692:35: warning: unused variable 
>> 'qca_soc_data_wcn3990' [-Wunused-const-variable]
   static const struct qca_vreg_data qca_soc_data_wcn3990 = {
 ^
>> drivers/bluetooth/hci_qca.c:1703:35: warning: unused variable 
>> 'qca_soc_data_wcn3991' [-Wunused-const-variable]
   static const struct qca_vreg_data qca_soc_data_wcn3991 = {
 ^
>> drivers/bluetooth/hci_qca.c:1714:35: warning: unused variable 
>> 'qca_soc_data_wcn3998' [-Wunused-const-variable]
   static const struct qca_vreg_data qca_soc_data_wcn3998 = {
 ^
   3 warnings generated.

vim +/qca_soc_data_wcn3990 +1692 drivers/bluetooth/hci_qca.c

0ff252c1976da5 Ben Young Tae Kim  2015-08-10  1691  
523760b7ff8871 Harish Bandi   2019-04-26 @1692  static const struct 
qca_vreg_data qca_soc_data_wcn3990 = {
fa9ad876b8e0eb Balakrishna Godavarthi 2018-08-03  1693  .soc_type = 
QCA_WCN3990,
fa9ad876b8e0eb Balakrishna Godavarthi 2018-08-03  1694  .vregs = 
(struct qca_vreg []) {
f2edd66e515b99 Bjorn Andersson2019-10-17  1695  { 
"vddio", 15000  },
f2edd66e515b99 Bjorn Andersson2019-10-17  1696  { 
"vddxo", 8  },
f2edd66e515b99 Bjorn Andersson2019-10-17  1697  { 
"vddrf", 30 },
f2edd66e515b99 Bjorn Andersson2019-10-17  1698  { 
"vddch0", 45 },
fa9ad876b8e0eb Balakrishna Godavarthi 2018-08-03  1699  },
fa9ad876b8e0eb Balakrishna Godavarthi 2018-08-03  1700  .num_vregs = 4,
fa9ad876b8e0eb Balakrishna Godavarthi 2018-08-03  1701  };
fa9ad876b8e0eb Balakrishna Godavarthi 2018-08-03  1702  
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06 @1703  static const struct 
qca_vreg_data qca_soc_data_wcn3991 = {
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06  1704  .soc_type = 
QCA_WCN3991,
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06  1705  .vregs = 
(struct qca_vreg []) {
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06  1706  { 
"vddio", 15000  },
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06  1707  { 
"vddxo", 8  },
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06  1708  { 
"vddrf", 30 },
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06  1709  { 
"vddch0", 45 },
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06  1710  },
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06  1711  .num_vregs = 4,
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06  1712  };
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06  1713  
523760b7ff8871 Harish Bandi   2019-04-26 @1714  static const struct 
qca_vreg_data qca_soc_data_wcn3998 = {
523760b7ff8871 Harish Bandi   2019-04-26  1715  .soc_type = 
QCA_WCN3998,
523760b7ff8871 Harish Bandi   2019-04-26  1716  .vregs = 
(struct qca_vreg []) {
f2edd66e515b99 Bjorn Andersson2019-10-17  1717  { 
"vddio", 1  },
f2edd66e515b99 Bjorn Andersson2019-10-17  1718  { 
"vddxo", 8  },
f2edd66e515b99 Bjorn Andersson2019-10-17  1719  { 
"vddrf", 30 },
f2edd66e515b99 Bjorn Andersson2019-10-17  1720  { 
"vddch0", 45 },
523760b7ff8871 Harish Bandi   2019-04-26  1721  },
523760b7ff8871 Harish Bandi   2019-04-26  1722  .num_vregs = 4,
523760b7ff8871 Harish Bandi   2019-04-26  1723  };
523760b7ff8871 Harish Bandi   2019-04-26  1724  

:: The code at line 1692 was first introduced by commit
:: 523760b7ff8871281aaedc44c305926469ab47f8 Bluetooth: hci_qca: Added 
support for WCN3998

:: TO: Harish Bandi 
:: CC: Marcel Holtmann 

---
0-DAY CI Kernel Test Service, 

[PATCH] ARM64: dts: update MDIO speed and preamble for zii-ultra device

[Chris Healy]

Update MDIO configuration with zii-ultra device to fully utilize
MDIO endpoint capabilities.  Device supports 12.5MHz clock and
doesn't require MDIO preamble.

Signed-off-by: Chris Healy 
---
 arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
index 6a55165bd76a..98aa67a4c040 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
@@ -132,6 +132,8 @@
 #address-cells = <1>;
 #size-cells = <0>;
 status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;

 switch: switch@0 {
 compatible = "marvell,mv88e6085";
-- 
2.21.3

Re: [Tech-board-discuss] [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Kees Cook]

On Sat, Jul 04, 2020 at 08:10:33PM -0400, Matthew Wilcox wrote:
> Left-right tree makes no sense. It doesn't distinguish the rbtree from its
> predecessor the avl tree.  I don't think it's helpful to rename a standard
> piece of computing terminology unless it's actually hurting us to have it.
> Obviously if it were called a "master-slave" tree, I would be in favour of
> renaming it.

(No one has suggested renaming red/black trees, so I think the
slippery-slope argument can be set aside here.)

As for the actual proposal on white/black-list, I've always been annoyed
by the poor description it provides (and I get to see it A LOT being
the seccomp maintainer). I welcome allow/deny-list (though the change is
not new for seccomp -- the man pages were updated last year (thanks
mkerrisk). :)

-- 
Kees Cook

Re: [PATCH v2 0/2] qlogic: use generic power management

[David Miller]

From: Vaibhav Gupta 
Date: Thu,  2 Jul 2020 22:31:41 +0530

> Linux Kernel Mentee: Remove Legacy Power Management.
> 
> The purpose of this patch series is to remove legacy power management 
> callbacks
> from qlogic ethernet drivers.
> 
> The callbacks performing suspend() and resume() operations are still calling
> pci_save_state(), pci_set_power_state(), etc. and handling the power 
> management
> themselves, which is not recommended.
> 
> The conversion requires the removal of the those function calls and change the
> callback definition accordingly and make use of dev_pm_ops structure.
> 
> All patches are compile-tested only.
> 
> V2: Fix unused variable warning in v1.

Series applied.

[PATCH] ARM: dts: update MDIO speed and preamble for zii devices

[Chris Healy]

Update MDIO configuration with zii devices to fully utilize
MDIO endpoint capabilities.  All devices support 12.5MHz clock and
don't require MDIO preamble.

Signed-off-by: Chris Healy 
---
 arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi   | 2 ++
 arch/arm/boot/dts/vf610-zii-cfu1.dts  | 2 ++
 arch/arm/boot/dts/vf610-zii-dev.dtsi  | 2 ++
 arch/arm/boot/dts/vf610-zii-spb4.dts  | 2 ++
 arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts  | 2 ++
 arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts | 2 ++
 6 files changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index 20350e803377..58cc421042e1 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -720,6 +720,8 @@
 #address-cells = <1>;
 #size-cells = <0>;
 status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;

 switch: switch@0 {
 compatible = "marvell,mv88e6085";
diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts
b/arch/arm/boot/dts/vf610-zii-cfu1.dts
index ce1920c052fc..c27cacbe6a73 100644
--- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
+++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
@@ -159,6 +159,8 @@
 #address-cells = <1>;
 #size-cells = <0>;
 status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;

 switch0: switch0@0 {
 compatible = "marvell,mv88e6085";
diff --git a/arch/arm/boot/dts/vf610-zii-dev.dtsi
b/arch/arm/boot/dts/vf610-zii-dev.dtsi
index 95d0060fb56c..9694d3b53607 100644
--- a/arch/arm/boot/dts/vf610-zii-dev.dtsi
+++ b/arch/arm/boot/dts/vf610-zii-dev.dtsi
@@ -138,6 +138,8 @@
 #address-cells = <1>;
 #size-cells = <0>;
 status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
 };
 };

diff --git a/arch/arm/boot/dts/vf610-zii-spb4.dts
b/arch/arm/boot/dts/vf610-zii-spb4.dts
index 55b4201e27f6..d2ad07ed5318 100644
--- a/arch/arm/boot/dts/vf610-zii-spb4.dts
+++ b/arch/arm/boot/dts/vf610-zii-spb4.dts
@@ -120,6 +120,8 @@
 #address-cells = <1>;
 #size-cells = <0>;
 status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;

 switch0: switch0@0 {
 compatible = "marvell,mv88e6190";
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
index a6c22a79779e..0bb3dcff0b79 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
@@ -106,6 +106,8 @@
 #address-cells = <1>;
 #size-cells = <0>;
 status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;

 switch0: switch0@0 {
 compatible = "marvell,mv88e6190";
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
index 3d05c894bdc0..e12e11805b71 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
@@ -134,6 +134,8 @@
 #address-cells = <1>;
 #size-cells = <0>;
 status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;

 switch0: switch0@0 {
 compatible = "marvell,mv88e6190";
-- 
2.21.3

Re: [PATCH net-next v2 1/2] net: dsa: microchip: split adjust_link() in phylink_mac_link_{up|down}()

[David Miller]

From: Codrin Ciubotariu 
Date: Thu, 2 Jul 2020 18:17:23 +0300

> The DSA subsystem moved to phylink and adjust_link() became deprecated in
> the process. This patch removes adjust_link from the KSZ DSA switches and
> adds phylink_mac_link_up() and phylink_mac_link_down().
> 
> Signed-off-by: Codrin Ciubotariu 
> Reviewed-by: Russell King 

Applied.

Re: [PATCH net-next v2 2/2] net: dsa: microchip: remove unused private members

[David Miller]

From: Codrin Ciubotariu 
Date: Thu, 2 Jul 2020 18:17:24 +0300

> Private structure members live_ports, on_ports, rx_ports, tx_ports are
> initialized but not used anywhere. Let's remove them.
> 
> Suggested-by: Russell King 
> Signed-off-by: Codrin Ciubotariu 

Applied.

Re: [PATCH net] hinic: fix sending mailbox timeout in aeq event work

[David Miller]

From: Luo bin 
Date: Sat, 4 Jul 2020 15:32:43 +0800

> When sending mailbox in the work of aeq event, another aeq event
> will be triggered. because the last aeq work is not exited and only
> one work can be excuted simultaneously in the same workqueue, mailbox
> sending function will return failure of timeout. We create and use
> another workqueue to fix this.
> 
> Signed-off-by: Luo bin 

Applied, thanks.

Re: [PATCH] drivers/net/wan/lapbether: Fixed the value of hard_header_len

[David Miller]

From: Xie He 
Date: Fri,  3 Jul 2020 22:12:46 -0700

> When transmitting data from upper layers or from AF_PACKET sockets,
>   this driver will first remove a pseudo header of 1 byte,
>   then the lapb module will prepend the LAPB header of 2 or 3 bytes,
>   then this driver will prepend a length field of 2 bytes,
>   then the underlying Ethernet device will prepend its own header.

Please add something like this above text to a comment:

> @@ -324,6 +323,8 @@ static int lapbeth_new_device(struct net_device *dev)
>   if (!ndev)
>   goto out;
>  
> + ndev->hard_header_len = -1 + 3 + 2 + dev->hard_header_len;
> +

Above this new line so that someone reading the code can understand
these magic numbers and what they mean.

Thank you.

drivers/mtd/nand/raw/sh_flctl.c:510:24: sparse: sparse: incorrect type in argument 1 (different base types)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   35e884f89df4c48566d745dc5a97a0d058d04263
commit: 05933aac7b11911955de307a329dc2a7a14b7bd0 ia64: remove now unused 
machvec indirections
date:   11 months ago
config: ia64-randconfig-s031-20200705 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-3-gfa153962-dirty
git checkout 05933aac7b11911955de307a329dc2a7a14b7bd0
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=ia64 

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


sparse warnings: (new ones prefixed by >>)

   drivers/mtd/nand/raw/sh_flctl.c:456:16: sparse: sparse: cast to restricted 
__le32
   drivers/mtd/nand/raw/sh_flctl.c:479:26: sparse: sparse: cast to restricted 
__be32
   drivers/mtd/nand/raw/sh_flctl.c:479:26: sparse: sparse: cast to restricted 
__be32
   drivers/mtd/nand/raw/sh_flctl.c:479:26: sparse: sparse: cast to restricted 
__be32
   drivers/mtd/nand/raw/sh_flctl.c:479:26: sparse: sparse: cast to restricted 
__be32
   drivers/mtd/nand/raw/sh_flctl.c:479:26: sparse: sparse: cast to restricted 
__be32
   drivers/mtd/nand/raw/sh_flctl.c:479:26: sparse: sparse: cast to restricted 
__be32
   drivers/mtd/nand/raw/sh_flctl.c:494:38: sparse: sparse: cast to restricted 
__be32
   drivers/mtd/nand/raw/sh_flctl.c:494:38: sparse: sparse: cast to restricted 
__be32
   drivers/mtd/nand/raw/sh_flctl.c:494:38: sparse: sparse: cast to restricted 
__be32
   drivers/mtd/nand/raw/sh_flctl.c:494:38: sparse: sparse: cast to restricted 
__be32
   drivers/mtd/nand/raw/sh_flctl.c:494:38: sparse: sparse: cast to restricted 
__be32
   drivers/mtd/nand/raw/sh_flctl.c:494:38: sparse: sparse: cast to restricted 
__be32
>> drivers/mtd/nand/raw/sh_flctl.c:510:24: sparse: sparse: incorrect type in 
>> argument 1 (different base types) @@ expected unsigned int [usertype] 
>> value @@ got restricted __be32 [usertype] @@
>> drivers/mtd/nand/raw/sh_flctl.c:510:24: sparse: expected unsigned int 
>> [usertype] value
   drivers/mtd/nand/raw/sh_flctl.c:510:24: sparse: got restricted __be32 
[usertype]
   drivers/mtd/nand/raw/sh_flctl.c:523:24: sparse: sparse: incorrect type in 
assignment (different base types) @@ expected unsigned long @@ got 
restricted __be32 [usertype] @@
   drivers/mtd/nand/raw/sh_flctl.c:523:24: sparse: expected unsigned long
   drivers/mtd/nand/raw/sh_flctl.c:523:24: sparse: got restricted __be32 
[usertype]
   include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:225:22: sparse: expected unsigned int 
[usertype] value
   include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:225:22: sparse: expected unsigned int 
[usertype] value
   include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:225:22: sparse: expected unsigned int 
[usertype] value
   include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:225:22: sparse: expected unsigned int 
[usertype] value
   include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:225:22: sparse: expected unsigned int 
[usertype] value
   

Re: [PATCH 0/7] Documentation: networking: eliminate doubled words

[David Miller]

From: Randy Dunlap 
Date: Fri,  3 Jul 2020 15:41:08 -0700

> Drop all duplicated words in Documentation/networking/ files.

Series applied, thanks Randy.

Re: [PATCH 1/2] hwmon: shtc1: add support for device tree bindings

[Chris Ruehl]

Hi Guenter,

On 3/7/2020 1:48 pm, Guenter Roeck wrote:

On 7/2/20 8:48 PM, Chris Ruehl wrote:

Add support for DTS bindings to the shtc driver, use CONFIG_OF
to compile in the code if needed.



Ah, here it is. The introducing patch should say something like "[PATCH 0/2]".


Signed-off-by: Chris Ruehl 
---
  drivers/hwmon/shtc1.c | 30 ++
  1 file changed, 30 insertions(+)

diff --git a/drivers/hwmon/shtc1.c b/drivers/hwmon/shtc1.c
index a0078ccede03..3bcabc1cbce8 100644
--- a/drivers/hwmon/shtc1.c
+++ b/drivers/hwmon/shtc1.c
@@ -14,6 +14,9 @@
  #include 
  #include 
  #include 
+#ifdef CONFIG_OF


No. Please no conditional includes.


OK, will be fixed and same for below.




+#include 
+#endif
  
  /* commands (high precision mode) */

  static const unsigned char shtc1_cmd_measure_blocking_hpm[]= { 0x7C, 0xA2 
};
@@ -196,6 +199,10 @@ static int shtc1_probe(struct i2c_client *client,
enum shtcx_chips chip = id->driver_data;
struct i2c_adapter *adap = client->adapter;
struct device *dev = >dev;
+#ifdef CONFIG_OF
+   struct device_node *np = dev->of_node;
+   u8 value;
+#endif
  
  	if (!i2c_check_functionality(adap, I2C_FUNC_I2C)) {

dev_err(dev, "plain i2c transactions not supported\n");
@@ -235,6 +242,20 @@ static int shtc1_probe(struct i2c_client *client,
  
  	if (client->dev.platform_data)

data->setup = *(struct shtc1_platform_data *)dev->platform_data;
+
+#ifdef CONFIG_OF


Unnecessary ifdef. Selection of devicetree data or not can be made
based on np != NULL. Also, if devictree data is available, platform
data should be ignored to avoid confusion.


Ok, I wasn't aware this rule. Will change it.




+   if (np) {
+   if (of_property_read_bool(np, "sensirion,blocking_io")) {
+   of_property_read_u8(np, "sensirion,blocking_io", 
);
+   data->setup.blocking_io = (value > 0) ? true : false;
+   }

Why this complexity, and why not just make the property a boolean ?


+   if (of_property_read_bool(np, "sensicon,high_precision")) {
+   of_property_read_u8(np, "sensirion,high_precision", 
);
+   data->setup.high_precision = (value > 0) ? true : false;


"sensicon,high_precision" should also be a boolean.


+   }
+   }
+#endif
+
shtc1_select_command(data);
mutex_init(>update_lock);
  
@@ -257,6 +278,15 @@ static const struct i2c_device_id shtc1_id[] = {

  };
  MODULE_DEVICE_TABLE(i2c, shtc1_id);
  
+#ifdef CONFIG_OF

+static const struct of_device_id shtc1_of_match[] = {
+   { .compatible = "sensirion,shtc1" },
+   { .compatible = "sensirion,shtw1" },
+   { .compatible = "sensirion,shtc3" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, shtc1_of_match);
+#endif
  static struct i2c_driver shtc1_i2c_driver = {
.driver.name  = "shtc1",
.probe= shtc1_probe,


Not sure how this works without setting of_match_table. I guess it just works
accidentally because .id_table also provides a devicetree match. Still,
of_match_table should be set.


Thanks, I will take care of this in the v2 version.



Guenter

Re: [PATCH] CodingStyle: Inclusive Terminology

[Kees Cook]

On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a proposal to answer the call to
> replace non-inclusive terminology.
> 
> Cc: Jonathan Corbet 
> Cc: Kees Cook 
> Signed-off-by: Chris Mason 
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: Dan Williams 

(nit: isn't this a Co-developed-by chain, not a SoB chain?)

Acked-by: Kees Cook 

Comments below...

> ---
>  Documentation/process/coding-style.rst  |   12 
>  Documentation/process/inclusive-terminology.rst |   64 
> +++
>  Documentation/process/index.rst |1 
>  3 files changed, 77 insertions(+)
>  create mode 100644 Documentation/process/inclusive-terminology.rst
> 
> diff --git a/Documentation/process/coding-style.rst 
> b/Documentation/process/coding-style.rst
> index 2657a55c6f12..4b15ab671089 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, 
> you have another
>  problem, which is called the function-growth-hormone-imbalance syndrome.
>  See chapter 6 (Functions).
>  
> +For symbol names, avoid introducing new usage of the words 'slave' and
> +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
> +'performer'.  Recommended replacements for blacklist are: 'blocklist' or
> +'denylist'.

Keeping "master" in a "master/slave" pairing (i.e. replacing only
"slave") seems incomplete to me. If "master" is paired with "slave", it
should be replaced too. Potential examples: 'primary', 'leader', 'principle',
'controller', 'sender', 'initial'.

Similarly, for "whitelist/blacklist", "whitelist" needs to replaced when
"blacklist" has been. For example, seccomp documentation[1] uses
"allow-list" and "deny-list".

[1] https://man7.org/linux/man-pages/man2/seccomp.2.html

> +Exceptions for introducing new usage is to maintain a userspace ABI, or

and API?

> +when updating code for an existing (as of 2020) hardware or protocol
> +specification that mandates those terms. For new specifications consider
> +translating specification usage of the terminology to the kernel coding
> +standard where possible. See :ref:`process/inclusive-terminology.rst
> +` for details.

Let's add:

 Where possible, old instances of this language should be replaced when
 it is not tied to external specifications nor userspace ABI/API.

>  
>  5) Typedefs
>  ---
> diff --git a/Documentation/process/inclusive-terminology.rst 
> b/Documentation/process/inclusive-terminology.rst
> new file mode 100644
> index ..a8eb26690eb4
> --- /dev/null
> +++ b/Documentation/process/inclusive-terminology.rst
> @@ -0,0 +1,64 @@
> +.. _inclusiveterminology:
> +
> +Linux kernel inclusive terminology
> +==
> +
> +The Linux kernel is a global software project, and in 2020 there was a
> +global reckoning on race relations that caused many organizations to
> +re-evaluate their policies and practices relative to the inclusion of
> +people of African descent. This document describes why the 'Naming'
> +section in :ref:`process/coding-style.rst ` recommends
> +avoiding usage of 'slave' and 'blacklist' in new additions to the Linux
> +kernel.

... usage of 'master/slave', 'slave', 'whitelist/blacklist', and
'blacklist' in the Linux kernel.

> +
> +On the triviality of replacing words
> +
> +
> +The African slave trade was a brutal system of human misery deployed at
> +global scale. Some word choice decisions in a modern software project
> +does next to nothing to compensate for that legacy. So why put any
> +effort into something so trivial in comparison? Because the goal is not
> +to repair, or erase the past. The goal is to maximize availability and
> +efficiency of the global developer community to participate in the Linux
> +kernel development process.
> +
> +Word choice and developer efficiency
> +
> +
> +Why does any software project go through the trouble of developing a
> +document like :ref:`process/coding-style.rst `? It does so
> +because a common coding style maximizes the efficiency of both
> +maintainers and developers. Developers learn common design patterns and
> +idiomatic expressions while maintainers can spot deviations from those
> +norms. Even non-compliant whitespace is considered a leading indicator
> +to deeper problems in a patchset. Coding style violations are known to
> +take a maintainer "out of the zone" of reviewing code. Maintainers are
> +also sensitive to word choice across specifications and often choose to
> +deploy Linux terminology to replace non-idiomatic word-choice in a
> +specification.
> +
> 

Re: [PATCH 2/2] devicetree: hwmon: shtc1: Add sensirion,shtc1.yaml

[Chris Ruehl]

Hi Guenter,

On 3/7/2020 1:49 pm, Guenter Roeck wrote:

On 7/2/20 8:48 PM, Chris Ruehl wrote:

Add documentation for the newly added DTS support in the shtc1 driver.

Signed-off-by: Chris Ruehl 
---
  .../bindings/hwmon/sensirion,shtc1.yaml   | 53 +++
  1 file changed, 53 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml

diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml 
b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
new file mode 100644
index ..e3e292bc6d7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/sensirion,shtc1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sensirion SHTC1 Humidity and Temperature Sensor IC
+
+maintainers:
+  - jdelv...@suse.com
+
+description: |
+  The SHTC1, SHTW1 and SHTC3 are digital humidity and temperature sensor
+  designed especially for battery-driven high-volume consumer electronics
+  applications.
+  For further information refere to Documentation/hwmon/shtc1.rst
+
+  This binding document describes the binding for the hardware monitor
+  portion of the driver.
+
+properties:
+  compatible:
+enum:
+  - sensirion,shtc1
+  - sensirion,shtw1
+  - sensirion,shtc3
+
+  reg: I2C address 0x70
+
+Optional properties:
+  sensirion,blocking_io: |
+u8, if > 0 the i2c bus hold until measure finished (default 0)
+  sensirion,high_precision: |
+u8, if > 0 aquire data with high precision (default 1)
+

Why u8 and not boolean ?

Guenter

The author of the driver make high_precision default (recommend) in the code,
if I use boolean, then the device tree _must_ have have the 
sensirion,high_precision set

or I need to do the opposite and define sensirion,low_precision.
(blocking_io = false default, high_precision = true default)

that's the reason I was thinking use a u8 and test with of_property_read_bool to 
check

the presence of it and set it if value > 0.


Chris.




+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+Example:
+   {
+status = "okay";
+clock-frequency = <40>;
+
+shtc3@70 {
+  compatible = "sensirion,shtc3";
+  reg = <0x70>
+  sensirion,blocking_io = <1>;
+  status = "okay";
+};
+  };



--
GTSYS Limited RFID Technology
9/F, Unit E, R07, Kwai Shing Industrial Building Phase 2,
42-46 Tai Lin Pai Road, Kwai Chung, N.T., Hong Kong
Tel (852) 9079 9521

Disclaimer: https://www.gtsys.com.hk/email/classified.html

fast binary calculator

[Andre Coelho]

ey


Ive made a program, that uses bit flips to quickly represent binary numbers

for instance, if i use a 128bit number than the algorithm uses

128+128+128 (and not 128*128)

for each bit.

Basically, it assigns slots to bits, so for instance

pos 1    pos 2 pos 3

0         0   0

1            1  1

so that reduces the time it takes to scan them. I also use bit flips to 
change the bit on a particular slot.



i wrote both c and java files.


later


Here is the code in c

#include 


char flipBit(char c);

char flipBit(char c) {
    if (c == '0')
    return '1';
    else
    return '0';



}


int main() {





                        char binaryNumber[] = { '0','0','0','0',0 };
                        int slot1,slot2,slot3,slot4;


                        for (slot1=0 ; slot1 < 2 ; slot1++) {
                            printf("\n%s",binaryNumber);
                            for (slot2 =1 ; slot2 < 2 ; slot2++) {
                                binaryNumber[slot2] = 
flipBit(binaryNumber[slot2]);


                                printf("\n%s",binaryNumber);

                                for (slot3=2 ; slot3 < 3 ; slot3++) {
                                    binaryNumber[slot3] = 
flipBit(binaryNumber[slot3]);

    printf("\n%s",binaryNumber);


                                    for (slot4=3 ; slot4 < 4 ; slot4++) {
                                        binaryNumber[slot4] = 
flipBit(binaryNumber[slot4]);

printf("\n%s",binaryNumber);
                                    }
                                }

                            }
                            binaryNumber[slot1] = 
flipBit(binaryNumber[slot1]);

    printf("\n");
                        }



}

--
André Albergaria Coelho
andrealberga...@gmail.com

#include 

char flipBit(char c);

char flipBit(char c) {
if (c == '0')
return '1';
else 
return '0';
}

int main() {

		char binaryNumber[] = { '0','0','0','0',0 };
		int slot1,slot2,slot3,slot4;


		for (slot1=0 ; slot1 < 2 ; slot1++) {
			printf("\n%s",binaryNumber);
			for (slot2 =1 ; slot2 < 2 ; slot2++) {
binaryNumber[slot2] = flipBit(binaryNumber[slot2]);

printf("\n%s",binaryNumber);

for (slot3=2 ; slot3 < 3 ; slot3++) {
	binaryNumber[slot3] = flipBit(binaryNumber[slot3]);
printf("\n%s",binaryNumber);


	for (slot4=3 ; slot4 < 4 ; slot4++) {
		binaryNumber[slot4] = flipBit(binaryNumber[slot4]);
		printf("\n%s",binaryNumber);
	}
}

			}
			binaryNumber[slot1] = flipBit(binaryNumber[slot1]);
printf("\n");
		}
}
import java.io.UnsupportedEncodingException;
import java.util.Arrays;


public class binPath {

	// ao inves de se usar o numero , usas a posicao dele na posicao do  numero (na array)
	// ao inves de se usar o sistema de numeros (cada posicao ocupa um elemento vezes a base)
	
	 
		
		public static void main(String[] args) {
		 
	byte[] plaintext = {0,0,0,1,1,1,0,1};
	
	
	
	// prints bits and positions
	/*byte[] b = {0,0,0,0,0,0,0,0};
	byte[] b2 = {1,1,1,1,1,1,1,1};
	

	for (int pos=0; pos < 8; pos++) {
		System.out.println("position "+pos+" "+b[pos]);
		System.out.println("position "+pos+" "+b2[pos]);
	}
	*/
	byte[] t = { 0,0,0,0 };
	
	
	
	for (int slot1 = 0 ; slot1 < 2 ; slot1++) {
		System.out.println();
		System.out.print(Arrays.toString(t));
		for (int slot2 = 1; slot2 < 2 ; slot2++) {
			t[slot2] = bitFlip(t[slot2]);
			System.out.println();
			System.out.print(Arrays.toString(t));
			
			for (int slot3 = 2; slot3 < 3 ; slot3++) {
t[slot3] = bitFlip(t[slot3]);
System.out.println();
System.out.print(Arrays.toString(t));

for (int slot4=3; slot4 < 4 ; slot4++) {
	t[slot4] = bitFlip(t[slot4]);
	System.out.println();
	System.out.print(Arrays.toString(t));
}
			}
			
		}
		t[slot1] = bitFlip(t[slot1]);
	}
	
		
		}		

			
	
	
	
	// Flips bits
	public static byte bitFlip(byte b) {
		if (b == 0)
			return 1;
		else
			return 0;
		
	}
	
}

Re: [PATCH] sched: Better document ttwu()

[Valentin Schneider]

On 03/07/20 14:32, Peter Zijlstra wrote:
> Dave hit the problem fixed by commit:
>
>   b6e13e85829f ("sched/core: Fix ttwu() race")
>
> and failed to understand much of the code involved. Per his request a
> few comments to (hopefully) clarify things.
>
> Requested-by: Dave Chinner 
> Signed-off-by: Peter Zijlstra (Intel) 

Small extra comment below, otherwise FWIW:

Reviewed-by: Valentin Schneider 

> +++ b/kernel/sched/core.c
> @@ -79,6 +79,100 @@ __read_mostly int scheduler_running;
>   */
>  int sysctl_sched_rt_runtime = 95;
>
> +
> +/*
> + * Serialization rules:
> + *
> + * Lock order:
> + *
> + *   p->pi_lock
> + * rq->lock
> + *   hrtimer_cpu_base->lock (hrtimer_start() for bandwidth controls)
> + *
> + *  rq1->lock
> + *rq2->lock  where: rq1 < rq2
> + *
> + * Regular state:
> + *
> + * Normal scheduling state is serialized by rq->lock. __schedule() takes the
> + * local CPU's rq->lock, it optionally removes the task from the runqueue and
> + * always looks at the local rq data structures to find the most elegible 
> task
> + * to run next.
> + *
> + * Task enqueue is also under rq->lock, possibly taken from another CPU.
> + * Wakeups from another LLC domain might use an IPI to transfer the enqueue 
> to
> + * the local CPU to avoid bouncing the runqueue state around [ see
> + * ttwu_queue_wakelist() ]
> + *
> + * Task wakeup, specifically wakeups that involve migration, are horribly
> + * complicated to avoid having to take two rq->locks.
> + *
> + * Special state:
> + *
> + * System-calls and anything external will use task_rq_lock() which acquires
> + * both p->pi_lock and rq->lock. As a consequence the state they change is
> + * stable while holding either lock:
> + *
> + *  - sched_setaffinity()/
> + *set_cpus_allowed_ptr():p->cpus_ptr, p->nr_cpus_allowed
> + *  - set_user_nice():   p->se.load, p->*prio
> + *  - __sched_setscheduler():p->sched_class, p->policy, p->*prio,
> + *   p->se.load, p->rt_priority,
> + *   p->dl.dl_{runtime, deadline, period, flags, bw, 
> density}

Uclamp stuff can also get updated in __sched_setscheduler(); see
__setscheduler_uclamp(). It's only p->uclamp_req AFAICT, but I don't think
there's harm in just saying p->uclamp*.

> + *  - sched_setnuma():   p->numa_preferred_nid
> + *  - sched_move_task()/
> + *cpu_cgroup_fork(): p->sched_task_group
> + *  - uclamp_update_active() p->uclamp*
> + *

Re: [RESEND PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

[Chun-Kuang Hu]

Hi, Enric:

Enric Balletbo i Serra  於 2020年6月16日 週二 上午4:31寫道：
>
> Use the drm_bridge_connector helper to create a connector for pipelines
> that use drm_bridge. This allows splitting connector operations across
> multiple bridges when necessary, instead of having the last bridge in
> the chain creating the connector and handling all connector operations
> internally.

Applied to mediatek-drm-next [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

>
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Sam Ravnborg 
> ---
>
> Changes in v4: None
> Changes in v3:
> - Move the bridge.type line to the patch that adds drm_bridge support. 
> (Laurent Pinchart)
>
> Changes in v2: None
>
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 4f3bd095c1eee..471fcafdf3488 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -17,6 +17,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -183,6 +184,7 @@ struct mtk_dsi {
> struct drm_encoder encoder;
> struct drm_bridge bridge;
> struct drm_bridge *next_bridge;
> +   struct drm_connector *connector;
> struct phy *phy;
>
> void __iomem *regs;
> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, 
> struct mtk_dsi *dsi)
>  */
> dsi->encoder.possible_crtcs = 1;
>
> -   ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
> +   ret = drm_bridge_attach(>encoder, >bridge, NULL,
> +   DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> if (ret)
> goto err_cleanup_encoder;
>
> +   dsi->connector = drm_bridge_connector_init(drm, >encoder);
> +   if (IS_ERR(dsi->connector)) {
> +   DRM_ERROR("Unable to create bridge connector\n");
> +   ret = PTR_ERR(dsi->connector);
> +   goto err_cleanup_encoder;
> +   }
> +   drm_connector_attach_encoder(dsi->connector, >encoder);
> +
> return 0;
>
>  err_cleanup_encoder:
> --
> 2.27.0
>

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Joe Perches]

On Sun, 2020-07-05 at 09:39 +1000, Dave Airlie wrote:
> Why haven't they submitted patches
> removing slavery terminology from the kernel before?

Because inhuman devices in a master/slave hierarchy isn't
anything like chattel slavery?

Blacklist/whitelist has nothing to do with skin color?

Are red-black trees next?

Re: [RESEND PATCH v4 6/7] drm/mediatek: mtk_dsi: Use the drm_panel_bridge API

[Chun-Kuang Hu]

Hi, Enric:

Enric Balletbo i Serra  於 2020年6月16日 週二 上午4:31寫道：
>
> Replace the manual panel handling code by a drm_panel_bridge. This
> simplifies the driver and allows all components in the display pipeline
> to be treated as bridges, paving the way to generic connector handling.
>

Applied to mediatek-drm-next [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

> Signed-off-by: Enric Balletbo i Serra 
> Reviewed-by: Laurent Pinchart 
> Acked-by: Sam Ravnborg 
> Reviewed-by: Chun-Kuang Hu 
> ---
>
> Changes in v4: None
> Changes in v3:
> - Use next_bridge field to store the panel bridge. (Laurent Pinchart)
> - Add the bridge.type field. (Laurent Pinchart)
> - This patch requires https://lkml.org/lkml/2020/4/16/2080 to work
>   properly.
>
> Changes in v2:
> - Do not set connector_type for panel here. (Sam Ravnborg)
>
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 173 +++--
>  1 file changed, 14 insertions(+), 159 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index e02d16a086ac0..4f3bd095c1eee 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -182,8 +182,6 @@ struct mtk_dsi {
> struct mipi_dsi_host host;
> struct drm_encoder encoder;
> struct drm_bridge bridge;
> -   struct drm_connector conn;
> -   struct drm_panel *panel;
> struct drm_bridge *next_bridge;
> struct phy *phy;
>
> @@ -212,11 +210,6 @@ static inline struct mtk_dsi *bridge_to_dsi(struct 
> drm_bridge *b)
> return container_of(b, struct mtk_dsi, bridge);
>  }
>
> -static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
> -{
> -   return container_of(c, struct mtk_dsi, conn);
> -}
> -
>  static inline struct mtk_dsi *host_to_dsi(struct mipi_dsi_host *h)
>  {
> return container_of(h, struct mtk_dsi, host);
> @@ -682,16 +675,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> mtk_dsi_lane0_ulp_mode_leave(dsi);
> mtk_dsi_clk_hs_mode(dsi, 0);
>
> -   if (dsi->panel) {
> -   if (drm_panel_prepare(dsi->panel)) {
> -   DRM_ERROR("failed to prepare the panel\n");
> -   goto err_disable_digital_clk;
> -   }
> -   }
> -
> return 0;
> -err_disable_digital_clk:
> -   clk_disable_unprepare(dsi->digital_clk);
>  err_disable_engine_clk:
> clk_disable_unprepare(dsi->engine_clk);
>  err_phy_power_off:
> @@ -718,15 +702,7 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  */
> mtk_dsi_stop(dsi);
>
> -   if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
> -   if (dsi->panel) {
> -   if (drm_panel_unprepare(dsi->panel)) {
> -   DRM_ERROR("failed to unprepare the panel\n");
> -   return;
> -   }
> -   }
> -   }
> -
> +   mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
> mtk_dsi_reset_engine(dsi);
> mtk_dsi_lane0_ulp_mode_enter(dsi);
> mtk_dsi_clk_ulp_mode_enter(dsi);
> @@ -757,19 +733,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>
> mtk_dsi_start(dsi);
>
> -   if (dsi->panel) {
> -   if (drm_panel_enable(dsi->panel)) {
> -   DRM_ERROR("failed to enable the panel\n");
> -   goto err_dsi_power_off;
> -   }
> -   }
> -
> dsi->enabled = true;
> -
> -   return;
> -err_dsi_power_off:
> -   mtk_dsi_stop(dsi);
> -   mtk_dsi_poweroff(dsi);
>  }
>
>  static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> @@ -777,34 +741,19 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> if (!dsi->enabled)
> return;
>
> -   if (dsi->panel) {
> -   if (drm_panel_disable(dsi->panel)) {
> -   DRM_ERROR("failed to disable the panel\n");
> -   return;
> -   }
> -   }
> -
> mtk_dsi_poweroff(dsi);
>
> dsi->enabled = false;
>  }
>
> -static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
> *dsi);
> -static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
> -
>  static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
>  enum drm_bridge_attach_flags flags)
>  {
> struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> -   return mtk_dsi_create_conn_enc(bridge->dev, dsi);
> -}
> -
> -static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
> -{
> -   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> -
> -   mtk_dsi_destroy_conn_enc(dsi);
> +   /* Attach the panel or bridge to the dsi bridge */
> +   return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
> +

Re: [PATCH 0/2] genirq: Kill preflow handlers

[Valentin Schneider]

Hi Marc,

On 04/07/20 10:48, Marc Zyngier wrote:
> Hi Valentin,
>
> On 2020-07-03 16:56, Valentin Schneider wrote:
>> Hi,
>>
>> while strolling around the different flow handlers, I tried to make
>> sense of
>> what preflow_handler() was about. Turns out no one uses those anymore,
>> but the
>> genirq support has remained in place.
>
> If we needed to reintroduce some form of preflow handler, we'd try and
> do it using hierarchical irqchips, if at all possible.

Right, that does sound like the most sensible approach. If I got my history
right, the preflow handlers saw the light of day before hierarchical
domains did, which I suppose is a reason why it wasn't done that way back
then.

>
>>
>> Unless we can see another user of those in the near future, this seems
>> like as
>> good a time as any for a little housecleaning.
>>
>> - Patch 1 simply deselects the (unexploited) preflow Kconfig for
>> sparc64
>> - Patch 2 is the actual cleanup
>>
>> Cheers,
>> Valentin
>>
>> Valentin Schneider (2):
>>   sparc64: Deselect IRQ_PREFLOW_FASTEOI
>>   genirq: Remove preflow handler support
>>
>>  arch/sparc/Kconfig |  1 -
>>  include/linux/irqdesc.h| 15 ---
>>  include/linux/irqhandler.h |  1 -
>>  kernel/irq/Kconfig |  4 
>>  kernel/irq/chip.c  | 13 -
>>  5 files changed, 34 deletions(-)
>
> For the whole series, and assuming that there is no regression
> (can't imagine any for unused code):
>
> Reviewed-by: Marc Zyngier 
>

Thanks!

> Thanks,
>
>  M.

Re: [RESEND PATCH v4 5/7] drm/mediatek: mtk_dsi: Use simple encoder

[Chun-Kuang Hu]

Hi, Enric:

Enric Balletbo i Serra  於 2020年6月16日 週二 上午4:31寫道：
>
> The mtk_dsi driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.

Applied to mediatek-drm-next [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

>
> Signed-off-by: Enric Balletbo i Serra 
> Reviewed-by: Laurent Pinchart 
> Acked-by: Sam Ravnborg 
> Reviewed-by: Chun-Kuang Hu 
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 13 ++---
>  1 file changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 759a5b37fb4d2..e02d16a086ac0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -789,15 +789,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> dsi->enabled = false;
>  }
>
> -static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
> -{
> -   drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
> -   .destroy = mtk_dsi_encoder_destroy,
> -};
> -
>  static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
> *dsi);
>  static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
>
> @@ -1127,8 +1118,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, 
> struct mtk_dsi *dsi)
>  {
> int ret;
>
> -   ret = drm_encoder_init(drm, >encoder, _dsi_encoder_funcs,
> -  DRM_MODE_ENCODER_DSI, NULL);
> +   ret = drm_simple_encoder_init(drm, >encoder,
> + DRM_MODE_ENCODER_DSI);
> if (ret) {
> DRM_ERROR("Failed to encoder init to drm\n");
> return ret;
> --
> 2.27.0
>

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dave Airlie]

On Sun, 5 Jul 2020 at 06:19, Dan Williams  wrote:
>
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a proposal to answer the call to
> replace non-inclusive terminology.
>
> Cc: Jonathan Corbet 
> Cc: Kees Cook 
> Signed-off-by: Chris Mason 
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: Dan Williams 

I'm sure the language could be fine tuned, but the intent is something
I support.

Acked-by: Dave Airlie 

> ---
>  Documentation/process/coding-style.rst  |   12 
>  Documentation/process/inclusive-terminology.rst |   64 
> +++
>  Documentation/process/index.rst |1
>  3 files changed, 77 insertions(+)
>  create mode 100644 Documentation/process/inclusive-terminology.rst
>
> diff --git a/Documentation/process/coding-style.rst 
> b/Documentation/process/coding-style.rst
> index 2657a55c6f12..4b15ab671089 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, 
> you have another
>  problem, which is called the function-growth-hormone-imbalance syndrome.
>  See chapter 6 (Functions).
>
> +For symbol names, avoid introducing new usage of the words 'slave' and
> +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
> +'performer'.  Recommended replacements for blacklist are: 'blocklist' or
> +'denylist'.
> +
> +Exceptions for introducing new usage is to maintain a userspace ABI, or
> +when updating code for an existing (as of 2020) hardware or protocol
> +specification that mandates those terms. For new specifications consider
> +translating specification usage of the terminology to the kernel coding
> +standard where possible. See :ref:`process/inclusive-terminology.rst
> +` for details.
>
>  5) Typedefs
>  ---
> diff --git a/Documentation/process/inclusive-terminology.rst 
> b/Documentation/process/inclusive-terminology.rst
> new file mode 100644
> index ..a8eb26690eb4
> --- /dev/null
> +++ b/Documentation/process/inclusive-terminology.rst
> @@ -0,0 +1,64 @@
> +.. _inclusiveterminology:
> +
> +Linux kernel inclusive terminology
> +==
> +
> +The Linux kernel is a global software project, and in 2020 there was a
> +global reckoning on race relations that caused many organizations to
> +re-evaluate their policies and practices relative to the inclusion of
> +people of African descent. This document describes why the 'Naming'
> +section in :ref:`process/coding-style.rst ` recommends
> +avoiding usage of 'slave' and 'blacklist' in new additions to the Linux
> +kernel.
> +
> +On the triviality of replacing words
> +
> +
> +The African slave trade was a brutal system of human misery deployed at
> +global scale. Some word choice decisions in a modern software project
> +does next to nothing to compensate for that legacy. So why put any
> +effort into something so trivial in comparison? Because the goal is not
> +to repair, or erase the past. The goal is to maximize availability and
> +efficiency of the global developer community to participate in the Linux
> +kernel development process.
> +
> +Word choice and developer efficiency
> +
> +
> +Why does any software project go through the trouble of developing a
> +document like :ref:`process/coding-style.rst `? It does so
> +because a common coding style maximizes the efficiency of both
> +maintainers and developers. Developers learn common design patterns and
> +idiomatic expressions while maintainers can spot deviations from those
> +norms. Even non-compliant whitespace is considered a leading indicator
> +to deeper problems in a patchset. Coding style violations are known to
> +take a maintainer "out of the zone" of reviewing code. Maintainers are
> +also sensitive to word choice across specifications and often choose to
> +deploy Linux terminology to replace non-idiomatic word-choice in a
> +specification.
> +
> +Non-inclusive terminology has that same distracting effect which is why
> +it is a style issue for Linux, it injures developer efficiency.
> +
> +Of course it is around this point someone jumps in with an etymological
> +argument about why people should not be offended. Etymological arguments
> +do not scale. The scope and pace of Linux to reach new developers
> +exceeds the ability of historical terminology defenders to describe "no,
> +not that connotation". The revelation of 2020 was that black voices were
> +heard on a global scale and the Linux kernel project has done its small
> +part to answer that call as it wants black voices, among all voices, in
> +its developer community.
> +
> +Really, 'blacklist' too?
> +
> +
> 

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dave Airlie]

'. Colors to represent a policy requires an indirection. The
>
> how about:
>   Using colors to represent a policy requires an indirection.

I'd totally submit that red/black trees while in no way racist, are a
horrible indirection, as it means nothing if you've never interacted
with gambling culture, (and maybe James Bond movies).

left/right trees make naturally more sense and translate into more
languages, so yes I think removal of color naming is a good thing even
for non-racist reasonings.

Dave.

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dave Airlie]

On Sun, 5 Jul 2020 at 07:25, James Bottomley
 wrote:
>
> On Sat, 2020-07-04 at 13:02 -0700, Dan Williams wrote:
> [...]
> > diff --git a/Documentation/process/inclusive-terminology.rst
> > b/Documentation/process/inclusive-terminology.rst
> > new file mode 100644
> > index ..a8eb26690eb4
> > --- /dev/null
> > +++ b/Documentation/process/inclusive-terminology.rst
>
> Could we just lose this entire document?  The one thing we should learn
> from recent history is that we really want prevent people distracting
> from the good inclusive (and technically more accurate) terminology
> will do.  One way the detractors do this by engaging in ultimately
> pointless arguments about historical accuracy of supporting statements.
>   By making pejorative statements about history (which are open to
> challenge on several fronts), this document acts as a magnet for such
> attention.  Simply leave it out and the detractors will have nothing to
> attack except the bald statement of desiring more inclusive language.
> I'd much rather defend why we want inclusive and more descriptive
> language than get into a pointless argument over whether the Ottoman
> slave trade was more or less evil than the American one.

I don't totally agree on that, because like the CoC discussion, people
need concrete examples. People need reasons, saying simply "be
inclusive" doesn't work.

You say "be inclusive" people don't think about it, they just go "I'm
inclusive" and proceed, never questioning what it means to be
inclusive, they normalise inclusivity to their self image and within
their lives where they might never confront anything like this.

I don't doubt we get the American/Ottoman/Barbery coast people and the
correct answer to those people is to tell them to examine why they
suddenly care about Barbery slavery now when they have never even
heard or worried about it before. Why haven't they submitted patches
removing slavery terminology from the kernel before?

Dave.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dave Airlie]

On Sun, 5 Jul 2020 at 06:45, Stephen Rothwell  wrote:
>
> Hi Dan,
>
> On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams  
> wrote:
> >
> > +Linux kernel inclusive terminology
> > +==
> > +
> > +The Linux kernel is a global software project, and in 2020 there was a
> > +global reckoning on race relations that caused many organizations to
> > +re-evaluate their policies and practices relative to the inclusion of
> > +people of African descent. This document describes why the 'Naming'
>
> I feel a need to point out that racial issues are wider than just
> people of African descent ...  Also, others have pointed out that
> slavery is not just restricted to those of African descent.

The racial issues are wider than that, and even wider again I'm sure,
but in 2020 this is as good a place to start as any, and the trigger
as that sentence says was in 2020, there was a reckoning about it
mainly due to people of African descent. That trigger has had flow on
effects in other countries, but I'm not sure that sentence in any way
diminishes that, it's merely an introduction to why this change is
happening now.

As for the non-black slavery, others have never pointed this out
before in 30 years of master/slave terminology? surely if white
slavery was as big a problem, they be as supportive of this, even more
so. It speaks volumes that I've never heard white slavery as a problem
once in 30 years, but now I'm hearing about it a few times, and
somehow as an excuse not to support this.

Dave.

Re: [RESEND PATCH v4 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver

[Chun-Kuang Hu]

Hi, Enric:

Enric Balletbo i Serra  於 2020年6月16日 週二 上午4:31寫道：
>
> Convert mtk_dsi to a bridge driver with built-in encoder support for
> compatibility with existing component drivers.

Applied to mediatek-drm-next [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

>
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Sam Ravnborg 
> Reviewed-by: Chun-Kuang Hu 
> ---
>
> Changes in v4:
> - Remove double call to drm_encoder_init(). (Chun-Kuang Hu)
> - Cleanup the encoder in mtk_dsi_unbind(). (Chun-Kuang Hu)
>
> Changes in v3:
> - Add the bridge.type. (Laurent Pinchart)
>
> Changes in v2: None
>
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 117 +++--
>  1 file changed, 79 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 208f49bf14a01..759a5b37fb4d2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -181,6 +181,7 @@ struct mtk_dsi {
> struct device *dev;
> struct mipi_dsi_host host;
> struct drm_encoder encoder;
> +   struct drm_bridge bridge;
> struct drm_connector conn;
> struct drm_panel *panel;
> struct drm_bridge *next_bridge;
> @@ -206,9 +207,9 @@ struct mtk_dsi {
> const struct mtk_dsi_driver_data *driver_data;
>  };
>
> -static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
> +static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
>  {
> -   return container_of(e, struct mtk_dsi, encoder);
> +   return container_of(b, struct mtk_dsi, bridge);
>  }
>
>  static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
> @@ -788,32 +789,52 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> dsi->enabled = false;
>  }
>
> -static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
> -  const struct drm_display_mode *mode,
> -  struct drm_display_mode *adjusted_mode)
> +static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
>  {
> -   return true;
> +   drm_encoder_cleanup(encoder);
>  }
>
> -static void mtk_dsi_encoder_mode_set(struct drm_encoder *encoder,
> -struct drm_display_mode *mode,
> -struct drm_display_mode *adjusted)
> +static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
> +   .destroy = mtk_dsi_encoder_destroy,
> +};
> +
> +static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
> *dsi);
> +static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
> +
> +static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
> +enum drm_bridge_attach_flags flags)
> +{
> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> +
> +   return mtk_dsi_create_conn_enc(bridge->dev, dsi);
> +}
> +
> +static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
>  {
> -   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> +
> +   mtk_dsi_destroy_conn_enc(dsi);
> +}
> +
> +static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
> +   const struct drm_display_mode *mode,
> +   const struct drm_display_mode *adjusted)
> +{
> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> drm_display_mode_to_videomode(adjusted, >vm);
>  }
>
> -static void mtk_dsi_encoder_disable(struct drm_encoder *encoder)
> +static void mtk_dsi_bridge_disable(struct drm_bridge *bridge)
>  {
> -   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> mtk_output_dsi_disable(dsi);
>  }
>
> -static void mtk_dsi_encoder_enable(struct drm_encoder *encoder)
> +static void mtk_dsi_bridge_enable(struct drm_bridge *bridge)
>  {
> -   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> mtk_output_dsi_enable(dsi);
>  }
> @@ -825,11 +846,12 @@ static int mtk_dsi_connector_get_modes(struct 
> drm_connector *connector)
> return drm_panel_get_modes(dsi->panel, connector);
>  }
>
> -static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = {
> -   .mode_fixup = mtk_dsi_encoder_mode_fixup,
> -   .mode_set = mtk_dsi_encoder_mode_set,
> -   .disable = mtk_dsi_encoder_disable,
> -   .enable = mtk_dsi_encoder_enable,
> +static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
> +   .attach = mtk_dsi_bridge_attach,
> +   .detach = mtk_dsi_bridge_detach,
> +   .disable = mtk_dsi_bridge_disable,
> +   .enable = mtk_dsi_bridge_enable,
> +   .mode_set = mtk_dsi_bridge_mode_set,
>  };
>
>  static const struct drm_connector_funcs mtk_dsi_connector_funcs = 

INFO: task hung in lru_add_drain_all

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:c28e58ee Add linux-next specific files for 20200629
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1400ab3710
kernel config:  https://syzkaller.appspot.com/x/.config?x=dcd26bbca17dd1db
dashboard link: https://syzkaller.appspot.com/bug?extid=1053252c4289b5f73548
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11c75c8310
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11fd99e310

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

INFO: task khugepaged:1160 blocked for more than 143 seconds.
  Not tainted 5.8.0-rc3-next-20200629-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
khugepaged  D28584  1160  2 0x4000
Call Trace:
 context_switch kernel/sched/core.c:3445 [inline]
 __schedule+0x8b4/0x1e80 kernel/sched/core.c:4169
 schedule+0xd0/0x2a0 kernel/sched/core.c:4244
 schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1873
 do_wait_for_common kernel/sched/completion.c:85 [inline]
 __wait_for_common kernel/sched/completion.c:106 [inline]
 wait_for_common kernel/sched/completion.c:117 [inline]
 wait_for_completion+0x163/0x260 kernel/sched/completion.c:138
 __flush_work+0x51f/0xab0 kernel/workqueue.c:3046
 lru_add_drain_all+0x3ca/0x590 mm/swap.c:808
 khugepaged_do_scan mm/khugepaged.c:2177 [inline]
 khugepaged+0x10b/0x5a10 mm/khugepaged.c:2238
 kthread+0x3b5/0x4a0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294

Showing all locks held in the system:
6 locks held by kworker/0:0/5:
1 lock held by khungtaskd/1150:
 #0: 89bc3000 (rcu_read_lock){}-{1:2}, at: 
debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:5779
1 lock held by khugepaged/1160:
 #0: 89c48448 (lock#4){+.+.}-{3:3}, at: lru_add_drain_all+0x59/0x590 
mm/swap.c:779
1 lock held by in:imklog/6654:
 #0: 8880935425f0 (>f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 
fs/file.c:928

=

NMI backtrace for cpu 1
CPU: 1 PID: 1150 Comm: khungtaskd Not tainted 5.8.0-rc3-next-20200629-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+0x18f/0x20d lib/dump_stack.c:118
 nmi_cpu_backtrace.cold+0x70/0xb1 lib/nmi_backtrace.c:101
 nmi_trigger_cpumask_backtrace+0x1b3/0x223 lib/nmi_backtrace.c:62
 trigger_all_cpu_backtrace include/linux/nmi.h:147 [inline]
 check_hung_uninterruptible_tasks kernel/hung_task.c:253 [inline]
 watchdog+0xd89/0xf30 kernel/hung_task.c:339
 kthread+0x3b5/0x4a0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.8.0-rc3-next-20200629-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:hid_apply_multiplier drivers/hid/hid-core.c:1106 [inline]
RIP: 0010:hid_setup_resolution_multiplier+0x3a3/0x9b0 
drivers/hid/hid-core.c:1163
Code: b6 14 38 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 df 04 00 00 
45 8b 74 24 04 bf 02 00 00 00 44 89 f6 e8 6d 62 90 fb <41> 83 fe 02 0f 85 74 ff 
ff ff 4c 89 24 24 e8 da 65 90 fb 49 8d 7d
RSP: 0018:c9cbec18 EFLAGS: 0293
RAX:  RBX:  RCX: 85e38373
RDX:  RSI: 8880a9598140 RDI: 0005
RBP: 88809f43e800 R08: 0001 R09: c900015ee0cc
R10: 0002 R11:  R12: 88809f43e800
R13: 88808580 R14:  R15: dc00
FS:  () GS:8880ae60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 55726aabf328 CR3: a0102000 CR4: 001506f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 hid_open_report+0x438/0x640 drivers/hid/hid-core.c:1274
 hid_parse include/linux/hid.h:1017 [inline]
 ms_probe+0x12d/0x4b0 drivers/hid/hid-microsoft.c:388
 hid_device_probe+0x2bd/0x3f0 drivers/hid/hid-core.c:2263
 really_probe+0x282/0x8a0 drivers/base/dd.c:525
 driver_probe_device+0xfe/0x1d0 drivers/base/dd.c:701
 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:807
 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
 __device_attach+0x28d/0x3f0 drivers/base/dd.c:873
 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
 device_add+0xacf/0x1b00 drivers/base/core.c:2680
 hid_add_device+0x344/0x9b0 drivers/hid/hid-core.c:2419
 usbhid_probe+0xac8/0xff0 drivers/hid/usbhid/hid-core.c:1412
 usb_probe_interface+0x2f7/0x780 drivers/usb/core/driver.c:374
 really_probe+0x282/0x8a0 

Re: [RESEND PATCH v4 3/7] drm/mediatek: mtk_dsi: Rename bridge to next_bridge

[Chun-Kuang Hu]

Hi, Enric:

Enric Balletbo i Serra  於 2020年6月16日 週二 上午4:31寫道：
>
> This is really a cosmetic change just to make a bit more readable the
> code after convert the driver to drm_bridge. The bridge variable name
> will be used by the encoder drm_bridge, and the chained bridge will be
> named next_bridge.
>

Applied to mediatek-drm-next [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

> Signed-off-by: Enric Balletbo i Serra 
> Reviewed-by: Laurent Pinchart 
> Acked-by: Sam Ravnborg 
> Reviewed-by: Chun-Kuang Hu 
> ---
>
> Changes in v4: None
> Changes in v3:
> - Replace s/bridge/next bridge/ for comment. (Laurent Pinchart)
>
> Changes in v2: None
>
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 270bf22c98feb..208f49bf14a01 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -183,7 +183,7 @@ struct mtk_dsi {
> struct drm_encoder encoder;
> struct drm_connector conn;
> struct drm_panel *panel;
> -   struct drm_bridge *bridge;
> +   struct drm_bridge *next_bridge;
> struct phy *phy;
>
> void __iomem *regs;
> @@ -894,9 +894,10 @@ static int mtk_dsi_create_conn_enc(struct drm_device 
> *drm, struct mtk_dsi *dsi)
>  */
> dsi->encoder.possible_crtcs = 1;
>
> -   /* If there's a bridge, attach to it and let it create the connector 
> */
> -   if (dsi->bridge) {
> -   ret = drm_bridge_attach(>encoder, dsi->bridge, NULL, 0);
> +   /* If there's a next bridge, attach to it and let it create the 
> connector */
> +   if (dsi->next_bridge) {
> +   ret = drm_bridge_attach(>encoder, dsi->next_bridge, NULL,
> +   0);
> if (ret) {
> DRM_ERROR("Failed to attach bridge to drm\n");
> goto err_encoder_cleanup;
> @@ -1177,7 +1178,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
> }
>
> ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
> - >panel, >bridge);
> + >panel, >next_bridge);
> if (ret)
> goto err_unregister_host;
>
> --
> 2.27.0
>

Re: [PATCH v2] Replace HTTP links with HTTPS ones: Documentation/devicetree/bindings/iio

[Matt Ranostay]

On Sat, Jul 4, 2020 at 12:34 PM Alexander A. Klimov
 wrote:
>
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>

With regards to the drivers that I've authored the changes look good to me.

Reviewed-by: Matt Ranostay 


> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
>   If both the HTTP and HTTPS versions
>   return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov 
> ---
>  Changes in v2:
>  Addressed 
> https://lore.kernel.org/linux-iio/20200704173459.78ceec60@archlinux/
>
>  Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml  | 4 ++--
>  Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt  | 2 +-
>  Documentation/devicetree/bindings/iio/iio-bindings.txt| 2 +-
>  Documentation/devicetree/bindings/iio/light/apds9300.txt  | 2 +-
>  Documentation/devicetree/bindings/iio/light/apds9960.txt  | 2 +-
>  Documentation/devicetree/bindings/iio/light/opt3001.txt   | 2 +-
>  Documentation/devicetree/bindings/iio/light/vl6180.txt| 2 +-
>  .../devicetree/bindings/iio/potentiometer/mcp41010.txt| 2 +-
>  .../devicetree/bindings/iio/potentiostat/lmp91000.txt | 4 ++--
>  .../devicetree/bindings/iio/pressure/asc,dlhl60d.yaml | 2 +-
>  .../devicetree/bindings/iio/proximity/devantech-srf04.yaml| 4 ++--
>  11 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml 
> b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
> index d124eba1ce54..fd4eaa3d0ab4 100644
> --- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
> +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
> @@ -12,8 +12,8 @@ maintainers:
>  description: |
>Analog Devices ADXL345/ADXL375 3-Axis Digital Accelerometers that supports
>both I2C & SPI interfaces.
> -http://www.analog.com/en/products/mems/accelerometers/adxl345.html
> -
> http://www.analog.com/en/products/sensors-mems/accelerometers/adxl375.html
> +https://www.analog.com/en/products/mems/accelerometers/adxl345.html
> +
> https://www.analog.com/en/products/sensors-mems/accelerometers/adxl375.html
>
>  properties:
>compatible:
> diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt 
> b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
> index 639c94ed83e9..17af395b99d9 100644
> --- a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
> +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
> @@ -6,7 +6,7 @@ Is is programmable through an SPI interface.
>
>  The internal DACs are loaded when the LOADDACS pin is pulled down.
>
> -http://www.ti.com/lit/ds/sbas106/sbas106.pdf
> +https://www.ti.com/lit/ds/sbas106/sbas106.pdf
>
>  Required Properties:
>  - compatible: Should be one of:
> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt 
> b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> index af33267727f4..aa63cac7323e 100644
> --- a/Documentation/devicetree/bindings/iio/iio-bindings.txt
> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> @@ -9,7 +9,7 @@ specifier is an array of one or more cells identifying the IIO
>  output on a device. The length of an IIO specifier is defined by the
>  value of a #io-channel-cells property in the IIO provider node.
>
> -[1] http://marc.info/?l=linux-iio=135902119507483=2
> +[1] https://marc.info/?l=linux-iio=135902119507483=2
>
>  ==IIO providers==
>
> diff --git a/Documentation/devicetree/bindings/iio/light/apds9300.txt 
> b/Documentation/devicetree/bindings/iio/light/apds9300.txt
> index aa199e09a493..3aa6db3ee99d 100644
> --- a/Documentation/devicetree/bindings/iio/light/apds9300.txt
> +++ b/Documentation/devicetree/bindings/iio/light/apds9300.txt
> @@ -1,6 +1,6 @@
>  * Avago APDS9300 ambient light sensor
>
> -http://www.avagotech.com/docs/AV02-1077EN
> +https://www.avagotech.com/docs/AV02-1077EN
>
>  Required properties:
>
> diff --git a/Documentation/devicetree/bindings/iio/light/apds9960.txt 
> b/Documentation/devicetree/bindings/iio/light/apds9960.txt
> index 3af325ad194b..c53ddb81c4aa 100644
> --- a/Documentation/devicetree/bindings/iio/light/apds9960.txt
> +++ b/Documentation/devicetree/bindings/iio/light/apds9960.txt
> @@ -1,6 +1,6 @@
>  * Avago APDS9960 gesture/RGB/ALS/proximity sensor
>
> -http://www.avagotech.com/docs/AV02-4191EN
> +https://www.avagotech.com/docs/AV02-4191EN
>
>  Required properties:
>
> diff --git a/Documentation/devicetree/bindings/iio/light/opt3001.txt 
> b/Documentation/devicetree/bindings/iio/light/opt3001.txt
> index 47b13eb8f4ec..9e6f2998e751 100644
> --- a/Documentation/devicetree/bindings/iio/light/opt3001.txt
> +++ 

Re: [PATCH] drm/mediatek: mtk_hdmi: Remove debug messages for function calls

[Chun-Kuang Hu]

Hi, Enric:

Chun-Kuang Hu  於 2020年5月19日 週二 下午11:13寫道：
>
> Hi, Enric:
>
> Enric Balletbo i Serra  於 2020年5月19日 週二 
> 下午5:41寫道：
> >
> > Equivalent information can be nowadays obtained using function tracer
> >
>
> Reviewed-by: Chun-Kuang Hu 

Applied to mediatek-drm-fixes [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-fixes

Regards,
Chun-Kuang.

>
> > Signed-off-by: Enric Balletbo i Serra 
> > ---
> >
> >  drivers/gpu/drm/mediatek/mtk_hdmi.c| 12 +---
> >  drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c |  4 
> >  2 files changed, 1 insertion(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
> > b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > index b0555a7cb3b4..172d67294435 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > @@ -1634,8 +1634,6 @@ static int mtk_hdmi_audio_startup(struct device *dev, 
> > void *data)
> >  {
> > struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
> >
> > -   dev_dbg(dev, "%s\n", __func__);
> > -
> > mtk_hdmi_audio_enable(hdmi);
> >
> > return 0;
> > @@ -1645,8 +1643,6 @@ static void mtk_hdmi_audio_shutdown(struct device 
> > *dev, void *data)
> >  {
> > struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
> >
> > -   dev_dbg(dev, "%s\n", __func__);
> > -
> > mtk_hdmi_audio_disable(hdmi);
> >  }
> >
> > @@ -1655,8 +1651,6 @@ mtk_hdmi_audio_digital_mute(struct device *dev, void 
> > *data, bool enable)
> >  {
> > struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
> >
> > -   dev_dbg(dev, "%s(%d)\n", __func__, enable);
> > -
> > if (enable)
> > mtk_hdmi_hw_aud_mute(hdmi);
> > else
> > @@ -1669,8 +1663,6 @@ static int mtk_hdmi_audio_get_eld(struct device *dev, 
> > void *data, uint8_t *buf,
> >  {
> > struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
> >
> > -   dev_dbg(dev, "%s\n", __func__);
> > -
> > memcpy(buf, hdmi->conn.eld, min(sizeof(hdmi->conn.eld), len));
> >
> > return 0;
> > @@ -1770,7 +1762,6 @@ static int mtk_drm_hdmi_probe(struct platform_device 
> > *pdev)
> > goto err_bridge_remove;
> > }
> >
> > -   dev_dbg(dev, "mediatek hdmi probe success\n");
> > return 0;
> >
> >  err_bridge_remove:
> > @@ -1793,7 +1784,7 @@ static int mtk_hdmi_suspend(struct device *dev)
> > struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
> >
> > mtk_hdmi_clk_disable_audio(hdmi);
> > -   dev_dbg(dev, "hdmi suspend success!\n");
> > +
> > return 0;
> >  }
> >
> > @@ -1808,7 +1799,6 @@ static int mtk_hdmi_resume(struct device *dev)
> > return ret;
> > }
> >
> > -   dev_dbg(dev, "hdmi resume success!\n");
> > return 0;
> >  }
> >  #endif
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
> > b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > index b55f51675205..1c3575372230 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > @@ -159,8 +159,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
> >  {
> > struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> >
> > -   dev_dbg(hdmi_phy->dev, "%s\n", __func__);
> > -
> > mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_AUTOK_EN);
> > mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_PLL_POSDIV);
> > mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3, RG_HDMITX_MHLCK_EN);
> > @@ -178,8 +176,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
> >  {
> > struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> >
> > -   dev_dbg(hdmi_phy->dev, "%s\n", __func__);
> > -
> > mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON1, 
> > RG_HDMITX_PLL_TXDIV_EN);
> > mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON1, 
> > RG_HDMITX_PLL_BIAS_LPF_EN);
> > usleep_range(100, 150);
> > --
> > 2.26.2
> >

Re: [PATCH] drm/mediatek: mtk_mt8173_hdmi_phy: Remove unnused const variables

[Chun-Kuang Hu]

Hi, Enric:

Chun-Kuang Hu  於 2020年5月19日 週二 下午11:12寫道：
>
> Hi, Enric:
>
> Enric Balletbo i Serra  於 2020年5月19日 週二 
> 下午5:40寫道：
> >
> > There are some `static const u8` variables that are not used, this
> > triggers a warning building with `make W=1`, it is safe to remove them,
> > so do it and make the compiler more happy.
> >
>
> Reviewed-by: Chun-Kuang Hu 

Applied to mediatek-drm-fixes [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-fixes

Regards,
Chun-Kuang.

>
> > Signed-off-by: Enric Balletbo i Serra 
> > ---
> >
> >  .../gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c| 48 ---
> >  1 file changed, 48 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
> > b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > index 1c3575372230..827b93786fac 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > @@ -107,54 +107,6 @@
> >  #define RGS_HDMITX_5T1_EDG (0xf << 4)
> >  #define RGS_HDMITX_PLUG_TSTBIT(0)
> >
> > -static const u8 PREDIV[3][4] = {
> > -   {0x0, 0x0, 0x0, 0x0},   /* 27Mhz */
> > -   {0x1, 0x1, 0x1, 0x1},   /* 74Mhz */
> > -   {0x1, 0x1, 0x1, 0x1}/* 148Mhz */
> > -};
> > -
> > -static const u8 TXDIV[3][4] = {
> > -   {0x3, 0x3, 0x3, 0x2},   /* 27Mhz */
> > -   {0x2, 0x1, 0x1, 0x1},   /* 74Mhz */
> > -   {0x1, 0x0, 0x0, 0x0}/* 148Mhz */
> > -};
> > -
> > -static const u8 FBKSEL[3][4] = {
> > -   {0x1, 0x1, 0x1, 0x1},   /* 27Mhz */
> > -   {0x1, 0x0, 0x1, 0x1},   /* 74Mhz */
> > -   {0x1, 0x0, 0x1, 0x1}/* 148Mhz */
> > -};
> > -
> > -static const u8 FBKDIV[3][4] = {
> > -   {19, 24, 29, 19},   /* 27Mhz */
> > -   {19, 24, 14, 19},   /* 74Mhz */
> > -   {19, 24, 14, 19}/* 148Mhz */
> > -};
> > -
> > -static const u8 DIVEN[3][4] = {
> > -   {0x2, 0x1, 0x1, 0x2},   /* 27Mhz */
> > -   {0x2, 0x2, 0x2, 0x2},   /* 74Mhz */
> > -   {0x2, 0x2, 0x2, 0x2}/* 148Mhz */
> > -};
> > -
> > -static const u8 HTPLLBP[3][4] = {
> > -   {0xc, 0xc, 0x8, 0xc},   /* 27Mhz */
> > -   {0xc, 0xf, 0xf, 0xc},   /* 74Mhz */
> > -   {0xc, 0xf, 0xf, 0xc}/* 148Mhz */
> > -};
> > -
> > -static const u8 HTPLLBC[3][4] = {
> > -   {0x2, 0x3, 0x3, 0x2},   /* 27Mhz */
> > -   {0x2, 0x3, 0x3, 0x2},   /* 74Mhz */
> > -   {0x2, 0x3, 0x3, 0x2}/* 148Mhz */
> > -};
> > -
> > -static const u8 HTPLLBR[3][4] = {
> > -   {0x1, 0x1, 0x0, 0x1},   /* 27Mhz */
> > -   {0x1, 0x2, 0x2, 0x1},   /* 74Mhz */
> > -   {0x1, 0x2, 0x2, 0x1}/* 148Mhz */
> > -};
> > -
> >  static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
> >  {
> > struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> > --
> > 2.26.2
> >

drivers/staging/wfx/./traces.h:154:1: sparse: sparse: incorrect type in argument 1 (different base types)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   35e884f89df4c48566d745dc5a97a0d058d04263
commit: 1cc298c9152352b36a7b0019b40e1863689727b2 staging: wfx: add tracepoints 
for HIF
date:   9 months ago
config: x86_64-randconfig-s021-20200705 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-3-gfa153962-dirty
git checkout 1cc298c9152352b36a7b0019b40e1863689727b2
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 

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


sparse warnings: (new ones prefixed by >>)

>> drivers/staging/wfx/./traces.h:154:1: sparse: sparse: incorrect type in 
>> argument 1 (different base types) @@ expected restricted __le16 const 
>> [usertype] *p @@ got unsigned short [usertype] * @@
   drivers/staging/wfx/./traces.h:154:1: sparse: expected restricted __le16 
const [usertype] *p
   drivers/staging/wfx/./traces.h:154:1: sparse: got unsigned short 
[usertype] *
>> drivers/staging/wfx/./traces.h:154:1: sparse: sparse: incorrect type in 
>> argument 1 (different base types) @@ expected restricted __le16 const 
>> [usertype] *p @@ got unsigned short [usertype] * @@
   drivers/staging/wfx/./traces.h:154:1: sparse: expected restricted __le16 
const [usertype] *p
   drivers/staging/wfx/./traces.h:154:1: sparse: got unsigned short 
[usertype] *

vim +154 drivers/staging/wfx/./traces.h

   153  
 > 154  DECLARE_EVENT_CLASS(hif_data,
   155  TP_PROTO(struct hif_msg *hif, int tx_fill_level, bool is_recv),
   156  TP_ARGS(hif, tx_fill_level, is_recv),
   157  TP_STRUCT__entry(
   158  __field(int, tx_fill_level)
   159  __field(int, msg_id)
   160  __field(const char *, msg_type)
   161  __field(int, msg_len)
   162  __field(int, buf_len)
   163  __field(int, if_id)
   164  __field(int, mib)
   165  __array(u8, buf, 128)
   166  ),
   167  TP_fast_assign(
   168  int header_len;
   169  
   170  __entry->tx_fill_level = tx_fill_level;
   171  __entry->msg_len = hif->len;
   172  __entry->msg_id = hif->id;
   173  __entry->if_id = hif->interface;
   174  if (is_recv)
   175  __entry->msg_type = __entry->msg_id & 0x80 ? 
"IND" : "CNF";
   176  else
   177  __entry->msg_type = "REQ";
   178  if (!is_recv &&
   179  (__entry->msg_id == HIF_REQ_ID_READ_MIB || 
__entry->msg_id == HIF_REQ_ID_WRITE_MIB)) {
   180  __entry->mib = le16_to_cpup((u16 *) hif->body);
   181  header_len = 4;
   182  } else {
   183  __entry->mib = -1;
   184  header_len = 0;
   185  }
   186  __entry->buf_len = min_t(int, __entry->msg_len, 
sizeof(__entry->buf))
   187 - sizeof(struct hif_msg) - 
header_len;
   188  memcpy(__entry->buf, hif->body + header_len, 
__entry->buf_len);
   189  ),
   190  TP_printk("%d:%d:%s_%s%s%s: %s%s (%d bytes)",
   191  __entry->tx_fill_level,
   192  __entry->if_id,
   193  __print_symbolic(__entry->msg_id, hif_msg_list),
   194  __entry->msg_type,
   195  __entry->mib != -1 ? "/" : "",
   196  __entry->mib != -1 ? __print_symbolic(__entry->mib, 
hif_mib_list) : "",
   197  __print_hex(__entry->buf, __entry->buf_len),
   198  __entry->msg_len > sizeof(__entry->buf) ? " ..." : "",
   199  __entry->msg_len
   200  )
   201  );
   202  DEFINE_EVENT(hif_data, hif_send,
   203  TP_PROTO(struct hif_msg *hif, int tx_fill_level, bool is_recv),
   204  TP_ARGS(hif, tx_fill_level, is_recv));
   205  #define _trace_hif_send(hif, tx_fill_level) trace_hif_send(hif, 
tx_fill_level, false)
   206  DEFINE_EVENT(hif_data, hif_recv,
   207  TP_PROTO(struct hif_msg *hif, int tx_fill_level, bool is_recv),
   208  TP_ARGS(hif, tx_fill_level, is_recv));
   209  #define _trace_hif_recv(hif, tx_fill_level) trace_hif_recv(hif, 
tx_fill_level, true)
   210  

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


.config.gz
Description: application/gzip

Re: [PATCH] drm/mediatek: Delete not used of_device_get_match_data

[Chun-Kuang Hu]

Hi, Matthias:

 於 2020年5月18日 週一 下午7:23寫道：
>
> From: Matthias Brugger 
>
> The driver will be loaded by via a platform device. So we
> will need to get the device_node from the parent device.
> Depending on this we will set the driver data.
> As all this is done later already, just delete the call to
> of_device_get_match_data.

Applied to mediatek-drm-fixes [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-fixes

Regards,
Chun-Kuang.

>
> Signed-off-by: Matthias Brugger 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index e2bb0d19ef99..63ec92ba0e92 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -447,7 +447,6 @@ static int mtk_drm_probe(struct platform_device *pdev)
> if (!private)
> return -ENOMEM;
>
> -   private->data = of_device_get_match_data(dev);
> private->mmsys_dev = dev->parent;
> if (!private->mmsys_dev) {
> dev_err(dev, "Failed to get MMSYS device\n");
> --
> 2.26.2
>

Re: [PATCH] net: fm10k: check size from dma region

[Zekun Shen]

On Sat, Jul 04, 2020 at 12:41:07PM -0700, Alexander Duyck wrote:
> On Sat, Jul 4, 2020 at 9:37 AM Zekun Shen  wrote:
> >
> > On Sat, Jul 04, 2020 at 09:05:48AM -0700, Alexander Duyck wrote:
> > > The upper limitation for the size should be 2K or FM10K_RX_BUFSZ, not
> > > PAGE_SIZE. Otherwise you are still capable of going out of bounds
> > > because the offset is used within the page to push the start of the
> > > region up by 2K.
> > PAGE_SIZE can drop the warning, as the dma allocated size is PAGE_SIZE.
>
> Yes, but the point I was getting at is that if you are just going to
> squelch the warning, but leave the code broken then the warning isn't
> of any use and might as well be discarded. Either you limit the value
> to 2K which is what the hardware is expected to max out at anyway, or
> you just skip the warning and assume hardware will do the right thing.
> I'm not even sure this patch is worth the effort if it is just using
> some dummy value that is still broken and simply squelches the
> warning.
>
> Could you provide more information about how you are encountering the
> error? Is this something you are seeing with an actual fm10k device,
> or is this something found via code review or static analysis?
I did not see it on a real device. I got the warning through emulation
and fuzzing, treating dma, mmio and interrupts as input vectors.
My research is on the peripheral/driver boundary.
>
> > > If this is actually fixing the warning it makes me wonder if the code
> > > performing the check is broken itself since we would still be
> > > accessing outside of the accessible DMA range.
> > The unbounded size is only passed to fm10k_add_rx_frag, which expects
> > and checks size to be less than FM10K_RX_HDR_LEN which is 256.
> >
> > In this way, any boundary between 256 and 4K should work. I could address
> > that with a second version.
>
> I was referring to the code in the DMA-API that is generating the
> warning being broken, not the code itself. If you can tell me how you
> are getting to the warning it would be useful.
>
> Anything over FM10K_RX_BUFSZ will break things. I think that is what
> you are missing. The driver splits a single 4K page into 2 pieces and
> then gives half off to the stack and uses the other half for the next
> receive. If you have a value over 2K you are going to be overwritting
> data in another buffer and/or attempting to access memory outside the
> DMA region. Both of which would likely cause significant issues and
> likely panic the system.
I agree. FM10K_RX_BUFSZ is the right boundary in that sense.

iwlwifi: TX on unused queue 5

[Paul Menzel]

Dear Linux folks,


Since at least Linux 5.2.9 a warning is thrown by *iwlwifi*.


[   21.211815] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   22.685490] rfkill: input handler disabled
[   26.529753] iwlwifi :02:00.0: RF_KILL bit toggled to disable radio.
[   26.529754] iwlwifi :02:00.0: reporting RF_KILL (radio disabled)
[   26.530095] wlan0: deauthenticating from 54:67:51:dd:7a:b3 by local choice 
(Reason: 3=DEAUTH_LEAVING)
[   26.530170] [ cut here ]
[   26.530170] TX on unused queue 5
[   26.530196] WARNING: CPU: 3 PID: 130 at 
drivers/net/wireless/intel/iwlwifi/pcie/tx.c:2337 
iwl_trans_pcie_tx+0x9be/0x1080 [iwlwifi]
[   26.530197] Modules linked in: ctr ccm fuse binfmt_misc nls_ascii nls_cp437 
vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 
videobuf2_common videodev mc btusb btrtl btbcm btintel bluetooth ecdh_generic 
ecc x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm iwlmvm 
snd_hda_codec_realtek dell_laptop dell_wmi irqbypass snd_hda_codec_generic 
iTCO_wdt dell_smbios snd_hda_codec_hdmi mac80211 ledtrig_audio 
iTCO_vendor_support mei_wdt ppdev crc32_pclmul sparse_keymap 
dell_wmi_descriptor dcdbas wmi_bmof watchdog ghash_clmulni_intel libarc4 
snd_hda_intel sdhci_pci intel_rapl_msr intel_cstate snd_intel_dspcfg 
dell_smm_hwmon tpm_tis cqhci intel_uncore snd_hda_codec sdhci tpm_tis_core i915 
iwlwifi snd_hda_core mmc_core intel_rapl_perf tpm cfg80211 xhci_pci ehci_pci 
efi_pstore snd_hwdep e1000e xhci_hcd ehci_hcd efivars snd_pcm rng_core pcspkr 
sg joydev parport_pc drm_kms_helper wmi snd_timer parport usbcore snd cec 
mei_me ptp processor_thermal_device int3403_thermal video
[   26.530218]  lpc_ich soundcore i2c_algo_bit mei i2c_i801 usb_common 
intel_rapl_common pps_core mfd_core button intel_soc_dts_iosf int3400_thermal 
dell_rbtn int3402_thermal acpi_thermal_rel int340x_thermal_zone rfkill battery 
acpi_pad ac drm pkcs8_key_parser efivarfs ip_tables x_tables autofs4 ext4 crc16 
mbcache jbd2 crc32c_generic dm_crypt dm_mod sd_mod t10_pi crc_t10dif 
crct10dif_generic crct10dif_pclmul crct10dif_common crc32c_intel ahci libahci 
aesni_intel libata glue_helper libaes crypto_simd psmouse scsi_mod evdev cryptd 
serio_raw fan
[   26.530233] CPU: 3 PID: 130 Comm: kworker/3:2 Not tainted 5.7.0-1-amd64 #1 
Debian 5.7.6-1
[   26.530234] Hardware name: Dell Inc. Latitude E7250/0TVD2T, BIOS A19 
01/23/2018
[   26.530247] Workqueue: events cfg80211_rfkill_block_work [cfg80211]
[   26.530251] RIP: 0010:iwl_trans_pcie_tx+0x9be/0x1080 [iwlwifi]
[   26.530253] Code: 80 3d a2 b7 02 00 00 b8 ea ff ff ff 0f 85 b2 f9 ff ff 89 ce 48 
c7 c7 07 64 ce c0 89 04 24 c6 05 84 b7 02 00 01 e8 24 b2 db d2 <0f> 0b 8b 04 24 
e9 90 f9 ff ff 48 c7 44 24 50 00 00 00 00 8b 44 24
[   26.530253] RSP: 0018:b76240213778 EFLAGS: 00010286
[   26.530254] RAX:  RBX: 8d1d8e57c8f0 RCX: 0998
[   26.530255] RDX: 0001 RSI: 0086 RDI: 0247
[   26.530255] RBP: 8d1dc10f9e88 R08: 0998 R09: 0004
[   26.530256] R10:  R11: 0001 R12: 0005
[   26.530256] R13: 0005 R14: 8d1d73762080 R15: 8d1dc10883e8
[   26.530257] FS:  () GS:8d1dcdd8() 
knlGS:
[   26.530258] CS:  0010 DS:  ES:  CR0: 80050033
[   26.530258] CR2: 558f3adf3808 CR3: 0003bc6d4005 CR4: 003606e0
[   26.530259] DR0:  DR1:  DR2: 
[   26.530259] DR3:  DR6: fffe0ff0 DR7: 0400
[   26.530260] Call Trace:
[   26.530268]  ? iwl_mvm_set_tx_cmd+0x1a9/0x4b0 [iwlmvm]
[   26.530273]  ? iwl_mvm_get_tx_rate.isra.0+0x87/0xe0 [iwlmvm]
[   26.530277]  ? iwl_mvm_get_tx_ant+0x40/0x70 [iwlmvm]
[   26.530281]  ? iwl_mvm_set_tx_cmd_rate+0x79/0xc0 [iwlmvm]
[   26.530286]  ? iwl_mvm_set_tx_params+0x33e/0x4f0 [iwlmvm]
[   26.530291]  iwl_mvm_tx_mpdu+0x170/0x500 [iwlmvm]
[   26.530296]  iwl_mvm_tx_skb_sta+0x19d/0x470 [iwlmvm]
[   26.530300]  iwl_mvm_tx_skb+0x17/0x40 [iwlmvm]
[   26.530304]  iwl_mvm_mac_itxq_xmit+0x76/0xa0 [iwlmvm]
[   26.530318]  ieee80211_queue_skb+0x2b7/0x450 [mac80211]
[   26.530330]  ieee80211_tx+0xe7/0x140 [mac80211]
[   26.530342]  __ieee80211_tx_skb_tid_band+0x6c/0x80 [mac80211]
[   26.530353]  ieee80211_send_deauth_disassoc+0xf5/0x120 [mac80211]
[   26.530365]  ieee80211_set_disassoc+0x361/0x5b0 [mac80211]
[   26.530368]  ? __switch_to_asm+0x40/0x70
[   26.530380]  ieee80211_mgd_deauth.cold+0x49/0x1bf [mac80211]
[   26.530392]  cfg80211_mlme_deauth+0xb3/0x1d0 [cfg80211]
[   26.530396]  ? rtc_dev_compat_ioctl+0x13/0x60
[   26.530406]  cfg80211_mlme_down+0x66/0x90 [cfg80211]
[   26.530418]  cfg80211_disconnect+0x129/0x1e0 [cfg80211]
[   26.530427]  cfg80211_leave+0x27/0x40 [cfg80211]
[   26.530435]  cfg80211_netdev_notifier_call+0x1a9/0x560 [cfg80211]
[   26.530440]  ? iwl_mvm_send_cmd+0x12/0x30 

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Joe Perches]

On 2020-07-04 14:25, James Bottomley wrote:

On Sat, 2020-07-04 at 13:02 -0700, Dan Williams wrote:
[...]

diff --git a/Documentation/process/inclusive-terminology.rst

[]

Could we just lose this entire document?


Yes please.

Re: [PATCH] habanalbas: rephrase error message

[Oded Gabbay]

On Sat, Jul 4, 2020 at 10:51 PM Omer Shpigelman  wrote:
>
> Rephrase F/W error message to make it more understandable to ordinary
> users.
>
> Signed-off-by: Omer Shpigelman 
> ---
>  drivers/misc/habanalabs/firmware_if.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/habanalabs/firmware_if.c 
> b/drivers/misc/habanalabs/firmware_if.c
> index baf790cf4b78..171baa2b56b0 100644
> --- a/drivers/misc/habanalabs/firmware_if.c
> +++ b/drivers/misc/habanalabs/firmware_if.c
> @@ -566,7 +566,8 @@ int hl_fw_init_cpu(struct hl_device *hdev, u32 
> cpu_boot_status_reg,
> "Device reports FIT image is corrupted\n");
> else
> dev_err(hdev->dev,
> -   "Device failed to load, %d\n", status);
> +   "Failed to load firmware to device, %d\n",
> +   status);
>
> rc = -EIO;
> goto out;
> --
> 2.17.1
>

This patch is:
Reviewed-by: Oded Gabbay 

[PATCH 2/2] habanalabs: set clock gating per engine

[Oded Gabbay]

For debugging purposes, we need to allow the root user better control of
the clock gating feature of the DMA and compute engines. Therefore, change
the clock gating debugfs interface to be bitmask instead of true/false.
Each bit represents a different engine, according to gaudi_engine_id enum.

See debugfs documentation for more details.

Signed-off-by: Oded Gabbay 
---
 .../ABI/testing/debugfs-driver-habanalabs |  11 +-
 drivers/misc/habanalabs/debugfs.c |  17 +--
 drivers/misc/habanalabs/device.c  |   2 +-
 drivers/misc/habanalabs/gaudi/gaudi.c | 112 --
 drivers/misc/habanalabs/goya/goya.c   |   8 +-
 drivers/misc/habanalabs/habanalabs.h  |  13 +-
 drivers/misc/habanalabs/habanalabs_drv.c  |   2 +-
 7 files changed, 103 insertions(+), 62 deletions(-)

diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs 
b/Documentation/ABI/testing/debugfs-driver-habanalabs
index f6d9c2a8d528..2e9ae311e02d 100644
--- a/Documentation/ABI/testing/debugfs-driver-habanalabs
+++ b/Documentation/ABI/testing/debugfs-driver-habanalabs
@@ -16,7 +16,16 @@ Description:Allow the root user to disable/enable in 
runtime the clock
 gating mechanism in Gaudi. Due to how Gaudi is built, the
 clock gating needs to be disabled in order to access the
 registers of the TPC and MME engines. This is sometimes needed
-during debug by the user and hence the user needs this option
+during debug by the user and hence the user needs this option.
+The user can supply a bitmask value, each bit represents
+a different engine to disable/enable its clock gating feature.
+The bitmask is composed of 20 bits:
+0  -  7 : DMA channels
+8  - 11 : MME engines
+12 - 19 : TPC engines
+The bit's location of a specific engine can be determined
+using (1 << GAUDI_ENGINE_ID_*). GAUDI_ENGINE_ID_* values
+are defined in uapi habanalabs.h file in enum gaudi_engine_id
 
 What:   /sys/kernel/debug/habanalabs/hl/command_buffers
 Date:   Jan 2019
diff --git a/drivers/misc/habanalabs/debugfs.c 
b/drivers/misc/habanalabs/debugfs.c
index fc4372c18ce2..136b8f6fa0b3 100644
--- a/drivers/misc/habanalabs/debugfs.c
+++ b/drivers/misc/habanalabs/debugfs.c
@@ -981,7 +981,7 @@ static ssize_t hl_clk_gate_read(struct file *f, char __user 
*buf,
if (*ppos)
return 0;
 
-   sprintf(tmp_buf, "%d\n", hdev->clock_gating);
+   sprintf(tmp_buf, "0x%llx\n", hdev->clock_gating_mask);
rc = simple_read_from_buffer(buf, strlen(tmp_buf) + 1, ppos, tmp_buf,
strlen(tmp_buf) + 1);
 
@@ -993,7 +993,7 @@ static ssize_t hl_clk_gate_write(struct file *f, const char 
__user *buf,
 {
struct hl_dbg_device_entry *entry = file_inode(f)->i_private;
struct hl_device *hdev = entry->hdev;
-   u32 value;
+   u64 value;
ssize_t rc;
 
if (atomic_read(>in_reset)) {
@@ -1002,19 +1002,12 @@ static ssize_t hl_clk_gate_write(struct file *f, const 
char __user *buf,
return 0;
}
 
-   rc = kstrtouint_from_user(buf, count, 10, );
+   rc = kstrtoull_from_user(buf, count, 16, );
if (rc)
return rc;
 
-   if (value) {
-   hdev->clock_gating = 1;
-   if (hdev->asic_funcs->enable_clock_gating)
-   hdev->asic_funcs->enable_clock_gating(hdev);
-   } else {
-   if (hdev->asic_funcs->disable_clock_gating)
-   hdev->asic_funcs->disable_clock_gating(hdev);
-   hdev->clock_gating = 0;
-   }
+   hdev->clock_gating_mask = value;
+   hdev->asic_funcs->set_clock_gating(hdev);
 
return count;
 }
diff --git a/drivers/misc/habanalabs/device.c b/drivers/misc/habanalabs/device.c
index 2b38a119704c..59608d1bac88 100644
--- a/drivers/misc/habanalabs/device.c
+++ b/drivers/misc/habanalabs/device.c
@@ -608,7 +608,7 @@ int hl_device_set_debug_mode(struct hl_device *hdev, bool 
enable)
hdev->in_debug = 0;
 
if (!hdev->hard_reset_pending)
-   hdev->asic_funcs->enable_clock_gating(hdev);
+   hdev->asic_funcs->set_clock_gating(hdev);
 
goto out;
}
diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c 
b/drivers/misc/habanalabs/gaudi/gaudi.c
index e22206527164..9d6aebef8854 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -98,6 +98,11 @@
 
 #define GAUDI_ARB_WDT_TIMEOUT  0x100
 
+#define GAUDI_CLK_GATE_DEBUGFS_MASK(\
+   BIT(GAUDI_ENGINE_ID_MME_0) |\
+   BIT(GAUDI_ENGINE_ID_MME_2) |\
+   GENMASK_ULL(GAUDI_ENGINE_ID_TPC_7, GAUDI_ENGINE_ID_TPC_0))
+
 static const char 

[PATCH 1/2] habanalabs: block WREG_BULK packet on PDMA

[Oded Gabbay]

WREG_BULK is a special packet that has a variable length. Therefore, we
can't parse it when validating CBs that go to the PCI DMA queue. In case
the user needs to use it, it can put multiple WREG32 packets instead.

Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/gaudi/gaudi.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c 
b/drivers/misc/habanalabs/gaudi/gaudi.c
index 834470d10b46..e22206527164 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -3865,6 +3865,12 @@ static int gaudi_validate_cb(struct hl_device *hdev,
rc = -EPERM;
break;
 
+   case PACKET_WREG_BULK:
+   dev_err(hdev->dev,
+   "User not allowed to use WREG_BULK\n");
+   rc = -EPERM;
+   break;
+
case PACKET_LOAD_AND_EXE:
rc = gaudi_validate_load_and_exe_pkt(hdev, parser,
(struct packet_load_and_exe *) user_pkt);
@@ -3880,7 +3886,6 @@ static int gaudi_validate_cb(struct hl_device *hdev,
break;
 
case PACKET_WREG_32:
-   case PACKET_WREG_BULK:
case PACKET_MSG_LONG:
case PACKET_MSG_SHORT:
case PACKET_REPEAT:
-- 
2.17.1

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[James Bottomley]

On Sat, 2020-07-04 at 13:02 -0700, Dan Williams wrote:
[...]
> diff --git a/Documentation/process/inclusive-terminology.rst
> b/Documentation/process/inclusive-terminology.rst
> new file mode 100644
> index ..a8eb26690eb4
> --- /dev/null
> +++ b/Documentation/process/inclusive-terminology.rst

Could we just lose this entire document?  The one thing we should learn
from recent history is that we really want prevent people distracting
from the good inclusive (and technically more accurate) terminology
will do.  One way the detractors do this by engaging in ultimately
pointless arguments about historical accuracy of supporting statements.
  By making pejorative statements about history (which are open to
challenge on several fronts), this document acts as a magnet for such
attention.  Simply leave it out and the detractors will have nothing to
attack except the bald statement of desiring more inclusive language. 
I'd much rather defend why we want inclusive and more descriptive
language than get into a pointless argument over whether the Ottoman
slave trade was more or less evil than the American one.

James

Re: [PATCH 1/3] readfile: implement readfile syscall

[Miklos Szeredi]

On Sat, Jul 4, 2020 at 10:50 PM Alexey Dobriyan  wrote:
>
> Al wrote:
>
> > > On Sat, Jul 04, 2020 at 09:41:09PM +0200, Miklos Szeredi wrote:
> > >  1) just leave the first explanation (it's an open + read + close
> > > equivalent) and leave out the rest
> > >
> > >  2) add a loop around the vfs_read() in the code.
> >
> > 3) don't bother with the entire thing, until somebody manages to demonstrate
> > a setup where it does make a real difference (compared to than the obvious
> > sequence of syscalls, that is).
>
> Ehh? System call overead is trivially measurable.
> https://lwn.net/Articles/814175/
>
> > At which point we'll need to figure out
> > what's going on and deal with the underlying problem of that setup.
>
> Run top?
>
> Teach userspace to read 1 page minimum?
>
> 192803 read(4, "cpu  3718263 4417 342808 7127674"..., 1024) = 1024
> 192803 read(4, " 0 21217 21617 21954 10201 15425"..., 1024) = 1024
> 192803 read(4, " 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0"..., 1024) = 1024
> 192803 read(4, "", 1024)
>
> Teach userspace to pread?
>
> 192803 openat(AT_FDCWD, "/proc/uptime", O_RDONLY) = 5
> 192803 lseek(5, 0, SEEK_SET)= 0
> 192803 read(5, "47198.56 713699.82\n", 8191) = 19
>
> Rhetorical question: what is harder: ditch the main source of overhead
> (VFS, seq_file, text) or teach userspace how to read files?
>
> Here is open+read /proc/cpuinfo in python2 and python3.
> Python2 case is terrifying.
>
> BTW is there is something broken with seqfiles and record keeping?
> Why does it return only 2 records per read?

seqfile is weird.  It uses an internal buffer (m->buf) that starts off
with a PAGE_SIZE size (m->size).  The internal buffer is filled with
whole records, if a single record is larger than the bufsize, then the
buffer is expanded until the record fits.  Then this internal buffer
is used to fill the user buffer supplied by read.  If the length of
the internal buffer (m->count) overflows the user buffer, then the
rest is set aside for the next read.  In this case the next read
starts with the tail (m->from) of the internal buffer, then, if
there's still space in the user buffer, it resets the internal buffer
(m->from = 0) and again fills it with at least one whole record and
copies as much of that to the user buffer as it can.

Note how this can lead to unfilled bytes at the end of the user
buffer.  Not sure what's the rationelle, it could just as well loop
back to filling a new buf it there's space left in the user buffer.
Maybe it was: better return whole records whenever possible.  Anyway
that can't be changed now, since it's bound to break something out
there.

Thanks,
Miklos

>
> Python 3:
>
> openat(AT_FDCWD, "/proc/cpuinfo", O_RDONLY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> ioctl(3, TCGETS, 0x7ffe6f1f0850) = -1 ENOTTY (Inappropriate ioctl for device)
> lseek(3, 0, SEEK_CUR)= 0
> ioctl(3, TCGETS, 0x7ffe6f1f0710) = -1 ENOTTY (Inappropriate ioctl for device)
> lseek(3, 0, SEEK_CUR)= 0
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> read(3, "processor\t: 0\nvendor_id\t: Genuin"..., 8192) = 3038
> read(3, "processor\t: 2\nvendor_id\t: Genuin"..., 5154) = 3038
> read(3, "processor\t: 4\nvendor_id\t: Genuin"..., 2116) = 2116
> read(3, "clmulqdq dtes64 monitor ds_cpl v"..., 8448) = 3966
> read(3, "processor\t: 8\nvendor_id\t: Genuin"..., 4482) = 3038
> read(3, "processor\t: 10\nvendor_id\t: Genui"..., 1444) = 1444
> read(3, "t\t: 64\naddress sizes\t: 46 bits p"..., 16896) = 3116
> read(3, "processor\t: 13\nvendor_id\t: Genui"..., 13780) = 3044
> read(3, "processor\t: 15\nvendor_id\t: Genui"..., 10736) = 1522
> read(3, "", 9214)= 0
>
>
> Python 2
>
> openat(AT_FDCWD, "/proc/cpuinfo", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> lseek(3, 0, SEEK_CUR)= 0
> lseek(3, 0, SEEK_CUR)= 0
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> read(3, "processor\t: 0\nvendor_id\t: Genuin"..., 1024) = 1024
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> lseek(3, 0, SEEK_CUR)= 1024
> lseek(3, 0, SEEK_CUR)= 1024
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> lseek(3, 0, SEEK_CUR)= 1024
> lseek(3, 0, SEEK_CUR)= 1024
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> lseek(3, 0, SEEK_CUR)= 1024
> lseek(3, 0, SEEK_CUR)= 1024
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> lseek(3, 0, SEEK_CUR)= 1024
> lseek(3, 0, SEEK_CUR)= 1024
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> lseek(3, 0, SEEK_CUR)= 1024
> lseek(3, 0, SEEK_CUR)= 1024
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> lseek(3, 0, SEEK_CUR)= 1024
> lseek(3, 0, SEEK_CUR)= 1024
> fstat(3, {st_mode=S_IFREG|0444, 

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Olof Johansson]

On Sat, Jul 4, 2020 at 1:19 PM Dan Williams  wrote:
>
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a proposal to answer the call to
> replace non-inclusive terminology.
>
> Cc: Jonathan Corbet 
> Cc: Kees Cook 
> Signed-off-by: Chris Mason 
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: Dan Williams 

I'm happy to support this, I agree with the general approach as well
as the motivations thereof.

At your discretion, feel free to add:

Signed-off-by: Olof Johansson 

Or Acked-by, or whatever other label you prefer to use to show
agreement and support.


-Olof

[PATCH] openrisc: Add support for external initrd images

[Stafford Horne]

In OpenRISC we set the initrd_start and initrd_end based on the symbols
we setup in vmlinux.lds.S.  However, this is not needed if we use the
generic linker description in INIT_DATA_SECTION.

Removing our own initrd setup reduces code, but also the generic code
supports loading external initrd images.  A bootloader can load a rootfs
image into memory and we can configure devicetree to load it with:

chosen {
bootargs = "earlycon";
stdout-path = "uart0:115200";
linux,initrd-start = < 0x08000100 >;
linux,initrd-end = < 0x0820 >;
};

Reported-by: Mateusz Holenko 
Signed-off-by: Stafford Horne 
---
 arch/openrisc/kernel/setup.c   |  8 +---
 arch/openrisc/kernel/vmlinux.lds.S | 12 
 2 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
index 8aa438e1f51f..b18e775f8be3 100644
--- a/arch/openrisc/kernel/setup.c
+++ b/arch/openrisc/kernel/setup.c
@@ -292,13 +292,15 @@ void __init setup_arch(char **cmdline_p)
init_mm.brk = (unsigned long)_end;
 
 #ifdef CONFIG_BLK_DEV_INITRD
-   initrd_start = (unsigned long)&__initrd_start;
-   initrd_end = (unsigned long)&__initrd_end;
if (initrd_start == initrd_end) {
+   printk(KERN_INFO "Initial ramdisk not found\n");
initrd_start = 0;
initrd_end = 0;
+   } else {
+   printk(KERN_INFO "Initial ramdisk at: 0x%p (%lu bytes)\n",
+  (void *)(initrd_start), initrd_end - initrd_start);
+   initrd_below_start_ok = 1;
}
-   initrd_below_start_ok = 1;
 #endif
 
/* setup memblock allocator */
diff --git a/arch/openrisc/kernel/vmlinux.lds.S 
b/arch/openrisc/kernel/vmlinux.lds.S
index 60449fd7f16f..22fbc5fb24b3 100644
--- a/arch/openrisc/kernel/vmlinux.lds.S
+++ b/arch/openrisc/kernel/vmlinux.lds.S
@@ -96,18 +96,6 @@ SECTIONS
 
 __init_end = .;
 
-   . = ALIGN(PAGE_SIZE);
-   .initrd : AT(ADDR(.initrd) - LOAD_OFFSET)
-   {
-   __initrd_start = .;
-   *(.initrd)
-   __initrd_end = .;
-   FILL (0);
-. = ALIGN (PAGE_SIZE);
-   }
-
-__vmlinux_end = .;/* last address of the physical file */
-
BSS_SECTION(0, 0, 0x20)
 
 _end = .;
-- 
2.26.2

arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires more registers than available

[kernel test robot]

Hi Jason,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   35e884f89df4c48566d745dc5a97a0d058d04263
commit: 07b586fe06625b0b610dc3d3a969c51913d143d4 crypto: x86/curve25519 - 
replace with formally verified implementation
date:   5 months ago
config: x86_64-randconfig-a002-20200705 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
e359ab1eca5727ce4c688bb49323b8a09478d61c)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout 07b586fe06625b0b610dc3d3a969c51913d143d4
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All errors (new ones prefixed by >>):

>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires 
>> more registers than available
   "  movq 0(%1), %%rdx;"   
/* f[0] */
   ^
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires 
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires 
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires 
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires 
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires 
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires 
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires 
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires 
>> more registers than available
   arch/x86/crypto/curve25519-x86_64.c:609:3: error: inline assembly requires 
more registers than available
   "  movq 0(%1), %%rdx;"   
/* f[0] */
   ^
   arch/x86/crypto/curve25519-x86_64.c:609:3: error: inline assembly requires 
more registers than available
   11 errors generated.

vim +518 arch/x86/crypto/curve25519-x86_64.c

   509  
   510  /* Computes the square of a field element: out <- f * f
   511   * Uses the 8-element buffer tmp for intermediate results */
   512  static inline void fsqr(u64 *out, const u64 *f, u64 *tmp)
   513  {
   514  asm volatile(
   515  /* Compute the raw multiplication: tmp <- f * f */
   516  
   517  /* Step 1: Compute all partial products */
 > 518  "  movq 0(%1), %%rdx;"  
 >  /* f[0] */
   519  "  mulxq 8(%1), %%r8, %%r14;"  "  xor %%r15, 
%%r15;" /* f[1]*f[0] */
   520  "  mulxq 16(%1), %%r9, %%r10;" "  adcx %%r14, 
%%r9;" /* f[2]*f[0] */
   521  "  mulxq 24(%1), %%rax, %%rcx;""  adcx %%rax, 
%%r10;"/* f[3]*f[0] */
   522  "  movq 24(%1), %%rdx;" 
 /* f[3] */
   523  "  mulxq 8(%1), %%r11, %%r12;" "  adcx %%rcx, 
%%r11;"/* f[1]*f[3] */
   524  "  mulxq 16(%1), %%rax, %%r13;""  adcx %%rax, 
%%r12;"/* f[2]*f[3] */
   525  "  movq 8(%1), %%rdx;" "  adcx %%r15, 
%%r13;"/* f1 */
   526  "  mulxq 16(%1), %%rax, %%rcx;""  mov $0, %%r14;"   
 /* f[2]*f[1] */
   527  
   528  /* Step 2: Compute two parallel carry chains */
   529  "  xor %%r15, %%r15;"
   530  "  adox %%rax, %%r10;"
   531  "  adcx %%r8, %%r8;"
   532  "  adox %%rcx, %%r11;"
   533  "  adcx %%r9, %%r9;"
   534  "  adox %%r15, %%r12;"
   535  "  adcx %%r10, %%r10;"
   536  "  adox %%r15, %%r13;"
   537  "  adcx %%r11, %%r11;"
   538  "  adox %%r15, %%r14;"
   539  "  adcx %%r12, %%r12;"
   540  "  adcx %%r13, %%r13;"
   541  "  adcx %%r14, %%r14;"
   542  
   543  /* Step 3: Compute intermediate squares */
   544  "  movq 0(%1), %%rdx;" "  mulx %%rdx, %%rax, 
%%rcx;"/* f[0]^2 */
   545 "  movq %%rax, 0(%0);"
   546  "  add %%rcx, %%r8;"   "  movq %%r8, 8(%0);"
   547  "  movq 8(%1), 

Re: [RFC PATCH 00/10] Netronix embedded controller driver for Kobo and Tolino ebook readers

[Jonathan Neuschäfer]

On Tue, Jun 30, 2020 at 10:14:47PM +0200, Andreas Kemnade wrote:
> On Tue, 30 Jun 2020 09:15:23 +0200
> Jonathan Neuschäfer  wrote:
> 
> > On Tue, Jun 30, 2020 at 08:40:51AM +0200, Andreas Kemnade wrote:
> > [...]
> > > got a chance to test it on a Tolino Shine 2 HD.
> > > It uses the RTC from the RC5T619 but backlight seems to go via MSP430
> > > EC.
> > > 
> > > I got this.
> > > 
> > > [1.453603] ntxec 0-0043: Netronix embedded controller version f110 
> > > detected.
> > > [   10.723638] ntxec-rtc 21a.i2c:embedded-controller@43:rtc: 
> > > registered as rtc0
> > > [   10.775276] ntxec-pwm: probe of 21a.i2c:embedded-controller@43:pwm 
> > > failed with error -5  
> > 
> > Hmm, -EIO from the PWM driver.
> > 
> turing debugging on:

(edited for compactness:)
> [  330.332971] i2c i2c-0: write slave address: addr=0x86   ACK received
> [  330.334420] i2c i2c-0: write byte: B0=0xA3  ACK received
> [  330.334790] i2c i2c-0: write byte: B1=0x0   No ACK

> [  330.352339] i2c i2c-0: write slave address: addr=0x86   ACK received
> [  330.362208] i2c i2c-0: write byte: B0=0xA1  ACK received
> [  330.362479] i2c i2c-0: write byte: B1=0xFF  No ACK

> [  330.363112] i2c i2c-0: write slave address: addr=0x86   ACK received
> [  330.363362] i2c i2c-0: write byte: B0=0xA2  ACK received
> [  330.363608] i2c i2c-0: write byte: B1=0xFF  No ACK

Hmm, it doesn't ack the writes to 0xA3, 0xA1 and 0xA2, which should
disable the PWM output and then disable the auto-off timer (according to
the vendor kernel).

And you said in your other mail that you can actually toggle the light
with writes to 0xA3, so I suspect a bug in the EC firmware here (which
may have gone unnoticed because the vendor kernel doesn't check if the
i2c transfers succeed). :/

IMHO we should get this driver merged first, and perhaps add a quirk to
deal with the missing ACKs later (unless a better solution is found).


Jonathan


signature.asc
Description: PGP signature

[PATCH] [RFC] kernfs: Allow vm_ops->close() if VMA is never split

[Richard Weinberger]

10 years ago commit a6849fa1f7d7 ("sysfs: Fail bin file mmap if vma close is 
implemented.")
removed support for vm_ops->close() for mmap on sysfs.
As far I understand the reason is that due to the wrapping in kernfs
every VMA split operation needs to be tracked to call vm_ops->close()
for all fragments. This is not feasible with reasonable effort.

Since commit 31383c6865a5 ("mm, hugetlbfs: introduce ->split() to 
vm_operations_struct")
we can get notified as soon a VMA is split, this can help to relax the 
restriction.
So I propose to allow having a custom close under the condition that a
VMA cannot get split.

Signed-off-by: Richard Weinberger 
---
 fs/kernfs/file.c | 42 ++
 1 file changed, 34 insertions(+), 8 deletions(-)

diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
index 06b342d8462b..82b09e72acff 100644
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -347,6 +347,38 @@ static void kernfs_vma_open(struct vm_area_struct *vma)
kernfs_put_active(of->kn);
 }
 
+static void kernfs_vma_close(struct vm_area_struct *vma)
+{
+   struct file *file = vma->vm_file;
+   struct kernfs_open_file *of = kernfs_of(file);
+
+   if (!of->vm_ops)
+   return;
+
+   if (!kernfs_get_active(of->kn))
+   return;
+
+   if (of->vm_ops->close)
+   of->vm_ops->close(vma);
+
+   kernfs_put_active(of->kn);
+}
+
+static int kernfs_vma_split(struct vm_area_struct *vma, unsigned long addr)
+{
+   struct file *file = vma->vm_file;
+   struct kernfs_open_file *of = kernfs_of(file);
+
+   /*
+* We cannot keep track of split operations,
+* so refuse splitting a VMA if someone uses close.
+*/
+   if (of->vm_ops && of->vm_ops->close)
+   return -EINVAL;
+
+   return 0;
+}
+
 static vm_fault_t kernfs_vma_fault(struct vm_fault *vmf)
 {
struct file *file = vmf->vma->vm_file;
@@ -457,6 +489,8 @@ static struct mempolicy *kernfs_vma_get_policy(struct 
vm_area_struct *vma,
 
 static const struct vm_operations_struct kernfs_vm_ops = {
.open   = kernfs_vma_open,
+   .close  = kernfs_vma_close,
+   .split  = kernfs_vma_split,
.fault  = kernfs_vma_fault,
.page_mkwrite   = kernfs_vma_page_mkwrite,
.access = kernfs_vma_access,
@@ -505,14 +539,6 @@ static int kernfs_fop_mmap(struct file *file, struct 
vm_area_struct *vma)
if (of->mmapped && of->vm_ops != vma->vm_ops)
goto out_put;
 
-   /*
-* It is not possible to successfully wrap close.
-* So error if someone is trying to use close.
-*/
-   rc = -EINVAL;
-   if (vma->vm_ops && vma->vm_ops->close)
-   goto out_put;
-
rc = 0;
of->mmapped = true;
of->vm_ops = vma->vm_ops;
-- 
2.26.2

Re: Writing to a const pointer: is this supposed to happen?

[Andy Shevchenko]

On Sat, Jul 4, 2020 at 11:32 PM Kars Mulder  wrote:
> On Saturday, July 04, 2020 16:39 CEST, Andy Shevchenko wrote:
> > > I've searched for a function that parses an int from a string and
> > > stores a pointer to the end; I can find some function simple_strtoul
> > > that matches this criterion, but it's documented as
> > >
> > > "This function has caveats. Please use kstrtoul instead."
> > >
> > > ... and kstrtoul does not store a pointer to the end. The documentation
> > > of kstrtoul describes simple_strtoul as obsolete as well.
> >
> >
> >  Where? We need to fix that, because using simple_strto*() is fairly legal
> > in cases like this, but "has caveats".
>
> In lib/vsprintf.c, the comments before the function's implementation say:
>
> /**
>  * simple_strtoul - convert a string to an unsigned long
>  * @cp: The start of the string
>  * @endp: A pointer to the end of the parsed string will be placed here
>  * @base: The number base to use
>  *
>  * This function has caveats. Please use kstrtoul instead.
>  */

This is correct.

> Many variants upon kstrtoul, such as kstrtoull, defined in lib/kstrtox.c,
> describe the simple_strtoull function as obsolete:
>
> /**
>  * kstrtoull - convert a string to an unsigned long long
>  * [...]
>  *
>  * Returns 0 on success, -ERANGE on overflow and -EINVAL on parsing error.

>  * Used as a replacement for the obsolete simple_strtoull. Return code 
> must
>  * be checked.
>  */

This and similar are not correct. 1/ They are not replacement per se
(because of different behaviour). 2/ They simple_strto*() are not
obsoleted.

Can you correct all places you found and make it consistent?

> I seem to have been slightly inaccurate about my claim that "kstrtoul"
> describes simple_strtoul as "obsolete" though, because in the specific
> case of kstrtoul, include/linux/kernel.h only says:
>
> /**
>  * kstrtoul - convert a string to an unsigned long
>  * [...]
>  *
>  * Returns 0 on success, -ERANGE on overflow and -EINVAL on parsing error.
>  * Used as a replacement for the simple_strtoull. Return code must be 
> checked.
> */

> (Also, there may be a documentation error here: all kstrto* functions in
> kstrtox.c and kernel.h describe themselves as replacements of simple_strtoull.
> E.g. kstrtol and kstrtoul also describe themselves as replacements of
> simple_strtoull rather than as a replacements of simple_strtol and
> simple_strtoul respectively.)
>
> By the way, I found the documentation of the caveat somewhere in
> include/linux/kernel.h:

Yes, that's what has been added lately to clarify the usage of
simple_strto*() vs. kstrto*().

> /*
>  * Use kstrto instead.
>  *
>  * NOTE: simple_strto does not check for the range overflow and,
>  *   depending on the input, may give interesting results.
>  *
>  * Use these functions if and only if you cannot use kstrto, because
>  * the conversion ends on the first non-digit character, which may be far
>  * beyond the supported range. It might be useful to parse the strings 
> like
>  * 10x50 or 12:21 without altering original string or temporary buffer in 
> use.
>  * Keep in mind above caveat.
>  */


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/3] readfile: implement readfile syscall

[Alexey Dobriyan]

Al wrote:

> > On Sat, Jul 04, 2020 at 09:41:09PM +0200, Miklos Szeredi wrote:
> >  1) just leave the first explanation (it's an open + read + close
> > equivalent) and leave out the rest
> >
> >  2) add a loop around the vfs_read() in the code.
> 
> 3) don't bother with the entire thing, until somebody manages to demonstrate
> a setup where it does make a real difference (compared to than the obvious
> sequence of syscalls, that is).

Ehh? System call overead is trivially measurable.
https://lwn.net/Articles/814175/

> At which point we'll need to figure out
> what's going on and deal with the underlying problem of that setup.

Run top?

Teach userspace to read 1 page minimum?

192803 read(4, "cpu  3718263 4417 342808 7127674"..., 1024) = 1024
192803 read(4, " 0 21217 21617 21954 10201 15425"..., 1024) = 1024
192803 read(4, " 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0"..., 1024) = 1024
192803 read(4, "", 1024)

Teach userspace to pread?

192803 openat(AT_FDCWD, "/proc/uptime", O_RDONLY) = 5
192803 lseek(5, 0, SEEK_SET)= 0
192803 read(5, "47198.56 713699.82\n", 8191) = 19

Rhetorical question: what is harder: ditch the main source of overhead
(VFS, seq_file, text) or teach userspace how to read files?

Here is open+read /proc/cpuinfo in python2 and python3.
Python2 case is terrifying.

BTW is there is something broken with seqfiles and record keeping?
Why does it return only 2 records per read?

Python 3:

openat(AT_FDCWD, "/proc/cpuinfo", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
ioctl(3, TCGETS, 0x7ffe6f1f0850) = -1 ENOTTY (Inappropriate ioctl for device)
lseek(3, 0, SEEK_CUR)= 0
ioctl(3, TCGETS, 0x7ffe6f1f0710) = -1 ENOTTY (Inappropriate ioctl for device)
lseek(3, 0, SEEK_CUR)= 0
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "processor\t: 0\nvendor_id\t: Genuin"..., 8192) = 3038
read(3, "processor\t: 2\nvendor_id\t: Genuin"..., 5154) = 3038
read(3, "processor\t: 4\nvendor_id\t: Genuin"..., 2116) = 2116
read(3, "clmulqdq dtes64 monitor ds_cpl v"..., 8448) = 3966
read(3, "processor\t: 8\nvendor_id\t: Genuin"..., 4482) = 3038
read(3, "processor\t: 10\nvendor_id\t: Genui"..., 1444) = 1444
read(3, "t\t: 64\naddress sizes\t: 46 bits p"..., 16896) = 3116
read(3, "processor\t: 13\nvendor_id\t: Genui"..., 13780) = 3044
read(3, "processor\t: 15\nvendor_id\t: Genui"..., 10736) = 1522
read(3, "", 9214)= 0


Python 2

openat(AT_FDCWD, "/proc/cpuinfo", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 0
lseek(3, 0, SEEK_CUR)= 0
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "processor\t: 0\nvendor_id\t: Genuin"..., 1024) = 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)= 1024
lseek(3, 0, SEEK_CUR)= 1024
fstat(3, 

reset-brcmstb-rescal.c:undefined reference to `devm_ioremap_resource'

[kernel test robot]

Hi Jim,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   35e884f89df4c48566d745dc5a97a0d058d04263
commit: 4cf176e52397853e4a4dd37e917c5eafb47ba8d1 reset: Add Broadcom STB RESCAL 
reset controller
date:   6 months ago
config: um-allmodconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce (this is a W=1 build):
git checkout 4cf176e52397853e4a4dd37e917c5eafb47ba8d1
# save the attached .config to linux build tree
make W=1 ARCH=um 

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

All errors (new ones prefixed by >>):

   /usr/bin/ld: arch/um/drivers/vde.o: in function `vde_open_real':
   (.text+0x9cb): warning: Using 'getgrnam' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   /usr/bin/ld: (.text+0x61d): warning: Using 'getpwuid' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   /usr/bin/ld: arch/um/drivers/vector_user.o: in function 
`user_init_socket_fds':
   vector_user.c:(.text+0x53a): warning: Using 'getaddrinfo' in statically 
linked applications requires at runtime the shared libraries from the glibc 
version used for linking
   /usr/bin/ld: arch/um/drivers/pcap.o: in function `pcap_nametoaddr':
   (.text+0x10095): warning: Using 'gethostbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   /usr/bin/ld: arch/um/drivers/pcap.o: in function `pcap_nametonetaddr':
   (.text+0x10155): warning: Using 'getnetbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   /usr/bin/ld: arch/um/drivers/pcap.o: in function `pcap_nametoproto':
   (.text+0x10395): warning: Using 'getprotobyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   /usr/bin/ld: arch/um/drivers/pcap.o: in function `pcap_nametoport':
   (.text+0x1018b): warning: Using 'getservbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   /usr/bin/ld: drivers/reset/reset-brcmstb-rescal.o: in function 
`brcm_rescal_reset_probe':
>> reset-brcmstb-rescal.c:(.text+0x21b): undefined reference to 
>> `devm_ioremap_resource'
   /usr/bin/ld: drivers/reset/reset-intel-gw.o: in function `intel_reset_probe':
   reset-intel-gw.c:(.text+0x5be): undefined reference to 
`devm_platform_ioremap_resource'
   collect2: error: ld returned 1 exit status

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


.config.gz
Description: application/gzip

[PATCH v3 2/3] Fix undefined operation fault that can hang a cpu on crash or panic

[David P. Reed]

Fix: Mask undefined operation fault during emergency VMXOFF that must be
attempted to force cpu exit from VMX root operation.
Explanation: When a cpu may be in VMX root operation (only possible when
CR4.VMXE is set), crash or panic reboot tries to exit VMX root operation
using VMXOFF. This is necessary, because any INIT will be masked while cpu
is in VMX root operation, but that state cannot be reliably
discerned by the state of the cpu.
VMXOFF faults if the cpu is not actually in VMX root operation, signalling
undefined operation.
Discovered while debugging an out-of-tree x-visor with a race. Can happen
due to certain kinds of bugs in KVM.

Fixes: 208067 
Reported-by: David P. Reed 
Suggested-by: Thomas Gleixner 
Suggested-by: Sean Christopherson 
Suggested-by: Andy Lutomirski 
Signed-off-by: David P. Reed 
---
 arch/x86/include/asm/virtext.h | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/virtext.h b/arch/x86/include/asm/virtext.h
index 0ede8d04535a..0e0900eacb9c 100644
--- a/arch/x86/include/asm/virtext.h
+++ b/arch/x86/include/asm/virtext.h
@@ -30,11 +30,11 @@ static inline int cpu_has_vmx(void)
 }
 
 
-/* Disable VMX on the current CPU
+/* Exit VMX root mode and isable VMX on the current CPU.
  *
  * vmxoff causes a undefined-opcode exception if vmxon was not run
- * on the CPU previously. Only call this function if you know VMX
- * is enabled.
+ * on the CPU previously. Only call this function if you know cpu
+ * is in VMX root mode.
  */
 static inline void cpu_vmxoff(void)
 {
@@ -47,14 +47,22 @@ static inline int cpu_vmx_enabled(void)
return __read_cr4() & X86_CR4_VMXE;
 }
 
-/* Disable VMX if it is enabled on the current CPU
+/* Safely exit VMX root mode and disable VMX if VMX enabled
+ * on the current CPU. Handle undefined-opcode fault
+ * that can occur if cpu is not in VMX root mode, due
+ * to a race.
  *
  * You shouldn't call this if cpu_has_vmx() returns 0.
  */
 static inline void __cpu_emergency_vmxoff(void)
 {
-   if (cpu_vmx_enabled())
-   cpu_vmxoff();
+   if (!cpu_vmx_enabled())
+   return;
+   asm volatile ("1:vmxoff\n\t"
+ "2:\n\t"
+ _ASM_EXTABLE(1b, 2b)
+ ::: "cc", "memory");
+   cr4_clear_bits(X86_CR4_VMXE);
 }
 
 /* Disable VMX if it is supported and enabled on the current CPU
-- 
2.26.2

[PATCH v3 0/3] Fix undefined operation VMXOFF during reboot and crash

[David P. Reed]

At the request of Sean Christopherson, the original patch was split
into three patches, each fixing a distinct issue related to the original
bug, of a hang due to VMXOFF causing an undefined operation fault
when the kernel reboots with CR4.VMXE set. The combination of
the patches is the complete fix to the reported bug, and a lurking
error in asm side effects.

David P. Reed (3):
  Correct asm VMXOFF side effects
  Fix undefined operation fault that can hang a cpu on crash or panic
  Force all cpus to exit VMX root operation on crash/panic reliably

 arch/x86/include/asm/virtext.h | 24 
 arch/x86/kernel/reboot.c   | 20 +++-
 2 files changed, 23 insertions(+), 21 deletions(-)

-- 
2.26.2

[PATCH v3 3/3] Force all cpus to exit VMX root operation on crash/panic reliably

[David P. Reed]

Fix the logic during crash/panic reboot on Intel processors that
can support VMX operation to ensure that all processors are not
in VMX root operation. Prior code made optimistic assumptions
about other cpus that would leave other cpus in VMX root operation
depending on timing of crash/panic reboot.
Builds on cpu_ermergency_vmxoff() and __cpu_emergency_vmxoff() created
in a prior patch.

Suggested-by: Sean Christopherson 
Signed-off-by: David P. Reed 
---
 arch/x86/kernel/reboot.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 0ec7ced727fe..c8e96ba78efc 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -543,24 +543,18 @@ static void emergency_vmx_disable_all(void)
 * signals when VMX is enabled.
 *
 * We can't take any locks and we may be on an inconsistent
-* state, so we use NMIs as IPIs to tell the other CPUs to disable
-* VMX and halt.
+* state, so we use NMIs as IPIs to tell the other CPUs to exit
+* VMX root operation and halt.
 *
 * For safety, we will avoid running the nmi_shootdown_cpus()
 * stuff unnecessarily, but we don't have a way to check
-* if other CPUs have VMX enabled. So we will call it only if the
-* CPU we are running on has VMX enabled.
-*
-* We will miss cases where VMX is not enabled on all CPUs. This
-* shouldn't do much harm because KVM always enable VMX on all
-* CPUs anyway. But we can miss it on the small window where KVM
-* is still enabling VMX.
+* if other CPUs might be in VMX root operation.
 */
-   if (cpu_has_vmx() && cpu_vmx_enabled()) {
-   /* Disable VMX on this CPU. */
-   cpu_vmxoff();
+   if (cpu_has_vmx()) {
+   /* Safely force out of VMX root operation on this CPU. */
+   __cpu_emergency_vmxoff();
 
-   /* Halt and disable VMX on the other CPUs */
+   /* Halt and exit VMX root operation on the other CPUs */
nmi_shootdown_cpus(vmxoff_nmi);
 
}
-- 
2.26.2

[PATCH v3 1/3] Correct asm VMXOFF side effects

[David P. Reed]

Tell gcc that VMXOFF instruction clobbers condition codes
and memory when executed.
Also, correct original comments to remove kernel-doc syntax
per Randy Dunlap's request.

Suggested-by: Randy Dunlap 
Signed-off-by: David P. Reed 
---
 arch/x86/include/asm/virtext.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/virtext.h b/arch/x86/include/asm/virtext.h
index 9aad0e0876fb..0ede8d04535a 100644
--- a/arch/x86/include/asm/virtext.h
+++ b/arch/x86/include/asm/virtext.h
@@ -30,7 +30,7 @@ static inline int cpu_has_vmx(void)
 }
 
 
-/** Disable VMX on the current CPU
+/* Disable VMX on the current CPU
  *
  * vmxoff causes a undefined-opcode exception if vmxon was not run
  * on the CPU previously. Only call this function if you know VMX
@@ -38,7 +38,7 @@ static inline int cpu_has_vmx(void)
  */
 static inline void cpu_vmxoff(void)
 {
-   asm volatile ("vmxoff");
+   asm volatile ("vmxoff" ::: "cc", "memory");
cr4_clear_bits(X86_CR4_VMXE);
 }
 
@@ -47,7 +47,7 @@ static inline int cpu_vmx_enabled(void)
return __read_cr4() & X86_CR4_VMXE;
 }
 
-/** Disable VMX if it is enabled on the current CPU
+/* Disable VMX if it is enabled on the current CPU
  *
  * You shouldn't call this if cpu_has_vmx() returns 0.
  */
@@ -57,7 +57,7 @@ static inline void __cpu_emergency_vmxoff(void)
cpu_vmxoff();
 }
 
-/** Disable VMX if it is supported and enabled on the current CPU
+/* Disable VMX if it is supported and enabled on the current CPU
  */
 static inline void cpu_emergency_vmxoff(void)
 {
-- 
2.26.2

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Stephen Rothwell]

Hi Dan,

On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams  
wrote:
>
> +Linux kernel inclusive terminology
> +==
> +
> +The Linux kernel is a global software project, and in 2020 there was a
> +global reckoning on race relations that caused many organizations to
> +re-evaluate their policies and practices relative to the inclusion of
> +people of African descent. This document describes why the 'Naming'

I feel a need to point out that racial issues are wider than just
people of African descent ...  Also, others have pointed out that
slavery is not just restricted to those of African descent.

-- 
Cheers,
Stephen Rothwell


pgpPSyeehNUWj.pgp
Description: OpenPGP digital signature

Re: Writing to a const pointer: is this supposed to happen?

[Kars Mulder]

On Saturday, July 04, 2020 16:39 CEST, Andy Shevchenko wrote: 
> > I've searched for a function that parses an int from a string and
> > stores a pointer to the end; I can find some function simple_strtoul
> > that matches this criterion, but it's documented as
> >
> > "This function has caveats. Please use kstrtoul instead."
> >
> > ... and kstrtoul does not store a pointer to the end. The documentation
> > of kstrtoul describes simple_strtoul as obsolete as well.
> 
> 
>  Where? We need to fix that, because using simple_strto*() is fairly legal
> in cases like this, but "has caveats".

In lib/vsprintf.c, the comments before the function's implementation say:

/**
 * simple_strtoul - convert a string to an unsigned long
 * @cp: The start of the string
 * @endp: A pointer to the end of the parsed string will be placed here
 * @base: The number base to use
 *
 * This function has caveats. Please use kstrtoul instead.
 */

Many variants upon kstrtoul, such as kstrtoull, defined in lib/kstrtox.c,
describe the simple_strtoull function as obsolete:

/**
 * kstrtoull - convert a string to an unsigned long long
 * [...]
 *
 * Returns 0 on success, -ERANGE on overflow and -EINVAL on parsing error.
 * Used as a replacement for the obsolete simple_strtoull. Return code must
 * be checked.
 */

I seem to have been slightly inaccurate about my claim that "kstrtoul"
describes simple_strtoul as "obsolete" though, because in the specific
case of kstrtoul, include/linux/kernel.h only says:

/**
 * kstrtoul - convert a string to an unsigned long
 * [...]
 *
 * Returns 0 on success, -ERANGE on overflow and -EINVAL on parsing error.
 * Used as a replacement for the simple_strtoull. Return code must be 
checked.
*/

(Also, there may be a documentation error here: all kstrto* functions in
kstrtox.c and kernel.h describe themselves as replacements of simple_strtoull.
E.g. kstrtol and kstrtoul also describe themselves as replacements of
simple_strtoull rather than as a replacements of simple_strtol and
simple_strtoul respectively.)

By the way, I found the documentation of the caveat somewhere in
include/linux/kernel.h:

/*
 * Use kstrto instead.
 *
 * NOTE: simple_strto does not check for the range overflow and,
 *   depending on the input, may give interesting results.
 *
 * Use these functions if and only if you cannot use kstrto, because
 * the conversion ends on the first non-digit character, which may be far
 * beyond the supported range. It might be useful to parse the strings like
 * 10x50 or 12:21 without altering original string or temporary buffer in 
use.
 * Keep in mind above caveat.
 */

Re: [PATCH] CodingStyle: Inclusive Terminology

[Randy Dunlap]

On 7/4/20 1:02 PM, Dan Williams wrote:
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a proposal to answer the call to
> replace non-inclusive terminology.
> 
> Cc: Jonathan Corbet 
> Cc: Kees Cook 
> Signed-off-by: Chris Mason 
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: Dan Williams 
> ---
>  Documentation/process/coding-style.rst  |   12 
>  Documentation/process/inclusive-terminology.rst |   64 
> +++
>  Documentation/process/index.rst |1 
>  3 files changed, 77 insertions(+)
>  create mode 100644 Documentation/process/inclusive-terminology.rst
> 
> diff --git a/Documentation/process/inclusive-terminology.rst 
> b/Documentation/process/inclusive-terminology.rst
> new file mode 100644
> index ..a8eb26690eb4
> --- /dev/null
> +++ b/Documentation/process/inclusive-terminology.rst
> @@ -0,0 +1,64 @@
> +.. _inclusiveterminology:
> +
> +Linux kernel inclusive terminology
> +==
> +
> +The Linux kernel is a global software project, and in 2020 there was a
> +global reckoning on race relations that caused many organizations to
> +re-evaluate their policies and practices relative to the inclusion of
> +people of African descent. This document describes why the 'Naming'
> +section in :ref:`process/coding-style.rst ` recommends
> +avoiding usage of 'slave' and 'blacklist' in new additions to the Linux
> +kernel.
> +
> +On the triviality of replacing words
> +
> +
> +The African slave trade was a brutal system of human misery deployed at
> +global scale. Some word choice decisions in a modern software project
> +does next to nothing to compensate for that legacy. So why put any

   do next to nothing

> +effort into something so trivial in comparison? Because the goal is not
> +to repair, or erase the past. The goal is to maximize availability and
> +efficiency of the global developer community to participate in the Linux
> +kernel development process.
> +
> +Word choice and developer efficiency
> +
> +
> +Why does any software project go through the trouble of developing a
> +document like :ref:`process/coding-style.rst `? It does so
> +because a common coding style maximizes the efficiency of both
> +maintainers and developers. Developers learn common design patterns and
> +idiomatic expressions while maintainers can spot deviations from those
> +norms. Even non-compliant whitespace is considered a leading indicator
> +to deeper problems in a patchset. Coding style violations are known to
> +take a maintainer "out of the zone" of reviewing code. Maintainers are
> +also sensitive to word choice across specifications and often choose to
> +deploy Linux terminology to replace non-idiomatic word-choice in a

 word choice

> +specification.
> +
> +Non-inclusive terminology has that same distracting effect which is why
> +it is a style issue for Linux, it injures developer efficiency.

   for Linux:

> +
> +Of course it is around this point someone jumps in with an etymological
> +argument about why people should not be offended. Etymological arguments
> +do not scale. The scope and pace of Linux to reach new developers
> +exceeds the ability of historical terminology defenders to describe "no,
> +not that connotation". The revelation of 2020 was that black voices were
> +heard on a global scale and the Linux kernel project has done its small
> +part to answer that call as it wants black voices, among all voices, in
> +its developer community.
> +
> +Really, 'blacklist' too?
> +
> +
> +While 'slave' has a direct connection to human suffering the etymology
> +of 'blacklist' is devoid of a historical racial connection. However, one
> +thought exercise is to consider replacing 'blacklist/whitelist' with
> +'redlist/greenlist'. Realize that the replacement only makes sense if
> +you have been socialized with the concepts that 'red/green' implies
> +'stop/go'. Colors to represent a policy requires an indirection. The

how about:
  Using colors to represent a policy requires an indirection.

> +socialization of 'black/white' to have the connotation of
> +'impermissible/permissible' does not support inclusion.
> +
> +Inclusion == global developer community efficiency.


Acked-by: Randy Dunlap 


thanks.
-- 
~Randy

5.8-rc1 and later breaks chrome browser

[Steve French]

I noticed that chrome crashes immediately on startup  on my desktop
booting to 5.8-rc2 or later kernels (whether I build the kernel or
using the prebuilt weekly Ubuntu mainline kernel downloads).  Works
fine with default kernels or 5.7 or 5.7.7 stable kernel etc. - just
breaks if I boot 5.8-rc2 or later.  I even tried building with today's
mainline kernel and same thing.  Any ideas how to work around this.

Message logged to dmesg is:

[  131.366543] ThreadPoolServi[2526]: segfault at 415048 ip
5652def3370d sp 7fcdc3b37df0 error 6 in
chrome[5652daa7e000+785b000]
[  131.366546] Code: Bad RIP value.

-- 
Thanks,

Steve

[PATCH] CodingStyle: Inclusive Terminology

[Dan Williams]

Recent events have prompted a Linux position statement on inclusive
terminology. Given that Linux maintains a coding-style and its own
idiomatic set of terminology here is a proposal to answer the call to
replace non-inclusive terminology.

Cc: Jonathan Corbet 
Cc: Kees Cook 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Dan Williams 
---
 Documentation/process/coding-style.rst  |   12 
 Documentation/process/inclusive-terminology.rst |   64 +++
 Documentation/process/index.rst |1 
 3 files changed, 77 insertions(+)
 create mode 100644 Documentation/process/inclusive-terminology.rst

diff --git a/Documentation/process/coding-style.rst 
b/Documentation/process/coding-style.rst
index 2657a55c6f12..4b15ab671089 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, you 
have another
 problem, which is called the function-growth-hormone-imbalance syndrome.
 See chapter 6 (Functions).
 
+For symbol names, avoid introducing new usage of the words 'slave' and
+'blacklist'. Recommended replacements for 'slave' are: 'secondary',
+'subordinate', 'replica', 'responder', 'follower', 'proxy', or
+'performer'.  Recommended replacements for blacklist are: 'blocklist' or
+'denylist'.
+
+Exceptions for introducing new usage is to maintain a userspace ABI, or
+when updating code for an existing (as of 2020) hardware or protocol
+specification that mandates those terms. For new specifications consider
+translating specification usage of the terminology to the kernel coding
+standard where possible. See :ref:`process/inclusive-terminology.rst
+` for details.
 
 5) Typedefs
 ---
diff --git a/Documentation/process/inclusive-terminology.rst 
b/Documentation/process/inclusive-terminology.rst
new file mode 100644
index ..a8eb26690eb4
--- /dev/null
+++ b/Documentation/process/inclusive-terminology.rst
@@ -0,0 +1,64 @@
+.. _inclusiveterminology:
+
+Linux kernel inclusive terminology
+==
+
+The Linux kernel is a global software project, and in 2020 there was a
+global reckoning on race relations that caused many organizations to
+re-evaluate their policies and practices relative to the inclusion of
+people of African descent. This document describes why the 'Naming'
+section in :ref:`process/coding-style.rst ` recommends
+avoiding usage of 'slave' and 'blacklist' in new additions to the Linux
+kernel.
+
+On the triviality of replacing words
+
+
+The African slave trade was a brutal system of human misery deployed at
+global scale. Some word choice decisions in a modern software project
+does next to nothing to compensate for that legacy. So why put any
+effort into something so trivial in comparison? Because the goal is not
+to repair, or erase the past. The goal is to maximize availability and
+efficiency of the global developer community to participate in the Linux
+kernel development process.
+
+Word choice and developer efficiency
+
+
+Why does any software project go through the trouble of developing a
+document like :ref:`process/coding-style.rst `? It does so
+because a common coding style maximizes the efficiency of both
+maintainers and developers. Developers learn common design patterns and
+idiomatic expressions while maintainers can spot deviations from those
+norms. Even non-compliant whitespace is considered a leading indicator
+to deeper problems in a patchset. Coding style violations are known to
+take a maintainer "out of the zone" of reviewing code. Maintainers are
+also sensitive to word choice across specifications and often choose to
+deploy Linux terminology to replace non-idiomatic word-choice in a
+specification.
+
+Non-inclusive terminology has that same distracting effect which is why
+it is a style issue for Linux, it injures developer efficiency.
+
+Of course it is around this point someone jumps in with an etymological
+argument about why people should not be offended. Etymological arguments
+do not scale. The scope and pace of Linux to reach new developers
+exceeds the ability of historical terminology defenders to describe "no,
+not that connotation". The revelation of 2020 was that black voices were
+heard on a global scale and the Linux kernel project has done its small
+part to answer that call as it wants black voices, among all voices, in
+its developer community.
+
+Really, 'blacklist' too?
+
+
+While 'slave' has a direct connection to human suffering the etymology
+of 'blacklist' is devoid of a historical racial connection. However, one
+thought exercise is to consider replacing 'blacklist/whitelist' with
+'redlist/greenlist'. Realize that the replacement only makes sense if
+you have been socialized with the concepts that 'red/green' implies

[PATCH v3 4/4] ARM: dts: rockchip: Add Radxa Rock Pi N8 initial support

[Jagan Teki]

Rock Pi N8 is a Rockchip RK3288 based SBC, which has
- VMARC RK3288 SOM (as per SMARC standard) from Vamrs.
- Compatible carrier board from Radxa.

VAMRC RK3288 SOM need to mount on top of radxa dalang
carrier board for making Rock Pi N8 SBC.

So, add initial support for Rock Pi N8 by including rk3288,
rk3288 vamrc-som and raxda dalang carrier board dtsi files.

Signed-off-by: Jagan Teki 
---
Changes for v3:
- none
Changes for v2:
- reorder dtsi include so-that common properties will
  visible to main dts.

 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/rk3288-rock-pi-n8.dts | 17 +
 2 files changed, 18 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3288-rock-pi-n8.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e8dd99201397..1d1b6ac26394 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -964,6 +964,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-popmetal.dtb \
rk3288-r89.dtb \
rk3288-rock2-square.dtb \
+   rk3288-rock-pi-n8.dtb \
rk3288-tinker.dtb \
rk3288-tinker-s.dtb \
rk3288-veyron-brain.dtb \
diff --git a/arch/arm/boot/dts/rk3288-rock-pi-n8.dts 
b/arch/arm/boot/dts/rk3288-rock-pi-n8.dts
new file mode 100644
index ..b19593021713
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-rock-pi-n8.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (c) 2019 Vamrs Limited
+ * Copyright (c) 2019 Amarula Solutions(India)
+ */
+
+/dts-v1/;
+#include "rk3288.dtsi"
+#include 
+#include "rk3288-vmarc-som.dtsi"
+
+/ {
+   model = "Radxa ROCK Pi N8";
+   compatible = "radxa,rockpi-n8", "vamrs,rk3288-vmarc-som",
+"rockchip,rk3288";
+};
-- 
2.25.1

[PATCH v3 3/4] ARM: dts: rockchip: Add VMARC RK3288 SOM initial support

[Jagan Teki]

VMARC RK3288 SOM is a standard SMARC SOM design with
Rockchip RK3288 SoC, which is designed by Vamrs.

Specification:
- Rockchip RK3288
- PMIC: RK808
- eMMC: 16GB/32GB/64GB
- SD slot
- 2xUSB-2.0, 1xUSB3.0
- USB-C for power supply
- Ethernet
- HDMI, MIPI-DSI/CSI, eDP

Add initial support for VMARC RK3288 SOM, this would use
with associated carrier board.

Signed-off-by: Jagan Teki 
---
Changes for v3:
- none
Changes for v2:
- drop pwm include
- adjust dtsi based on trivial changes in 1/4

 arch/arm/boot/dts/rk3288-vmarc-som.dtsi | 270 
 1 file changed, 270 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3288-vmarc-som.dtsi

diff --git a/arch/arm/boot/dts/rk3288-vmarc-som.dtsi 
b/arch/arm/boot/dts/rk3288-vmarc-som.dtsi
new file mode 100644
index ..0bcb9f067d66
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-vmarc-som.dtsi
@@ -0,0 +1,270 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (c) 2019 Vamrs Limited
+ * Copyright (c) 2019 Amarula Solutions(India)
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "vamrs,rk3288-vmarc-som", "rockchip,rk3288";
+
+   vccio_flash: vccio-flash-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vccio_flash";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <_io>;
+   };
+};
+
+ {
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   disable-wp;
+   non-removable;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _cmd _pwr _bus8>;
+   vmmc-supply = <_io>;
+   vqmmc-supply = <_flash>;
+   status = "okay";
+};
+
+ {
+   assigned-clocks = < SCLK_MAC>;
+   phy-supply = <_io>;
+   snps,reset-gpio = < RK_PA7 GPIO_ACTIVE_HIGH>;
+};
+
+ {
+   clock-frequency = <40>;
+   status = "okay";
+
+   rk808: pmic@1b {
+   compatible = "rockchip,rk808";
+   reg = <0x1b>;
+   interrupt-parent = <>;
+   interrupts = ;
+   pinctrl-names = "default";
+   pinctrl-0 = <_int _pwroff>;
+   rockchip,system-power-controller;
+   wakeup-source;
+   #clock-cells = <1>;
+   clock-output-names = "rk808-clkout1", "rk808-clkout2";
+
+   vcc1-supply = <_sys>;
+   vcc2-supply = <_sys>;
+   vcc3-supply = <_sys>;
+   vcc4-supply = <_sys>;
+   vcc6-supply = <_sys>;
+   vcc7-supply = <_sys>;
+   vcc8-supply = <_io>;
+   vcc9-supply = <_io>;
+   vcc10-supply = <_sys>;
+   vcc11-supply = <_sys>;
+   vcc12-supply = <_io>;
+   vddio-supply = <_io>;
+
+   regulators {
+   vdd_cpu: DCDC_REG1 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd_arm";
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
+   };
+
+   vdd_gpu: DCDC_REG2 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <85>;
+   regulator-max-microvolt = <125>;
+   regulator-name = "vdd_gpu";
+   regulator-ramp-delay = <6000>;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
+   };
+
+   vcc_ddr: DCDC_REG3 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-name = "vcc_ddr";
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
+   };
+
+   vcc_io: DCDC_REG4 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc_io";
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   regulator-suspend-microvolt = <330>;
+   };
+