Re: [PATCH] Kbuild: enable -Wfallthrough for clang

2020-11-07 Thread Miguel Ojeda
On Sat, Nov 7, 2020 at 8:08 AM Nick Desaulniers  wrote:
>
> Partial revert of commit e2079e93f562 ("kbuild: Do not enable
> -Wimplicit-fallthrough for clang for now")
>
> This has been fixed up over time thanks to the addition of "fallthrough"
> pseudo-keyword in
> commit 294f69e662d1 ("compiler_attributes.h: Add 'fallthrough' pseudo
> keyword for switch/case use")

I think the title is missing the "implicit"?

Acked-by: Miguel Ojeda 

Cheers,
Miguel


Re: [PATCH 19/41] ath: regd: Provide description for ath_reg_apply_ir_flags's 'reg' param

2020-11-07 Thread Kalle Valo
Lee Jones  wrote:

> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/net/wireless/ath/regd.c:378: warning: Function parameter or member 
> 'reg' not described in 'ath_reg_apply_ir_flags'
> 
> Cc: Kalle Valo 
> Cc: "David S. Miller" 
> Cc: Jakub Kicinski 
> Cc: linux-wirel...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Signed-off-by: Lee Jones 
> Signed-off-by: Kalle Valo 

3 patches applied to ath-next branch of ath.git, thanks.

aed7ee049a3e ath: regd: Provide description for ath_reg_apply_ir_flags's 'reg' 
param
206cd5800d8c ath: dfs_pattern_detector: Fix some function kernel-doc headers
748d250777e6 ath: dfs_pri_detector: Demote zero/half completed kernel-doc 
headers

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201102112410.1049272-20-lee.jo...@linaro.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



Re: [PATCH 10/41] ath9k: ar9330_1p1_initvals: Remove unused const variable 'ar9331_common_tx_gain_offset1_1'

2020-11-07 Thread Kalle Valo
Lee Jones  wrote:

> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/net/wireless/ath/ath9k/ar9330_1p1_initvals.h:1013:18: warning: 
> ‘ar9331_common_tx_gain_offset1_1’ defined but not used 
> [-Wunused-const-variable=]
> 
> Cc: QCA ath9k Development 
> Cc: Kalle Valo 
> Cc: "David S. Miller" 
> Cc: Jakub Kicinski 
> Cc: linux-wirel...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Signed-off-by: Lee Jones 
> Signed-off-by: Kalle Valo 

6 patches applied to ath-next branch of ath.git, thanks.

3fc95aacc6fa ath9k: ar9330_1p1_initvals: Remove unused const variable 
'ar9331_common_tx_gain_offset1_1'
30c2751b8458 ath9k: ar9340_initvals: Remove unused const variable 
'ar9340Modes_ub124_tx_gain_table_1p0'
9190c64e4720 ath9k: ar9485_initvals: Remove unused const variable 
'ar9485_fast_clock_1_1_baseband_postamble'
b5cafcb16f45 ath9k: ar9003_2p2_initvals: Remove unused const variables
8cc107b57109 ath9k: ar5008_phy: Demote half completed function headers
cd64cae3efd4 ath9k: dynack: Demote non-compliant function header

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201102112410.1049272-11-lee.jo...@linaro.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



Re: [PATCH net-next 09/11] ath6kl: fix enum-conversion warning

2020-11-07 Thread Kalle Valo
Arnd Bergmann  wrote:

> gcc -Wextra points out a type mismatch
> 
> drivers/net/wireless/ath/ath6kl/wmi.c: In function 'ath6kl_wmi_cmd_send':
> drivers/net/wireless/ath/ath6kl/wmi.c:1825:19: warning: implicit conversion 
> from 'enum ' to 'enum wmi_data_hdr_data_type' [-Wenum-conversion]
>  1825 |false, false, 0, NULL, if_idx);
>   |   ^
> 
> As far as I can tell, the numeric value is current here,
> so just use the correct enum literal instead of 'false'.
> 
> Fixes: bdcd81707973 ("Add ath6kl cleaned up driver")
> Signed-off-by: Arnd Bergmann 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

ce54bf5e9554 ath6kl: fix enum-conversion warning

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201026213040.3889546-9-a...@kernel.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



Re: [PATCH 01/41] wil6210: wmi: Correct misnamed function parameter 'ptr_'

2020-11-07 Thread Kalle Valo
Lee Jones  wrote:

> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/net/wireless/ath/wil6210/wmi.c:279: warning: Function parameter or 
> member 'ptr_' not described in 'wmi_buffer_block'
>  drivers/net/wireless/ath/wil6210/wmi.c:279: warning: Excess function 
> parameter 'ptr' description in 'wmi_buffer_block'
> 
> Cc: Maya Erez 
> Cc: Kalle Valo 
> Cc: "David S. Miller" 
> Cc: Jakub Kicinski 
> Cc: linux-wirel...@vger.kernel.org
> Cc: wil6...@qti.qualcomm.com
> Cc: net...@vger.kernel.org
> Signed-off-by: Lee Jones 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

c9621dd21e3b wil6210: wmi: Correct misnamed function parameter 'ptr_'

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201102112410.1049272-2-lee.jo...@linaro.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



[PATCH] bpf: remove duplicate include

2020-11-07 Thread Wang Qing
Remove duplicate header which is included twice.

Signed-off-by: Wang Qing 
---
 kernel/bpf/btf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index ed7d02e..6324de8
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /* BTF (BPF Type Format) is the meta data format which describes
-- 
2.7.4



[PATCH] scsi: core: fix -Wformat

2020-11-07 Thread Nick Desaulniers
Clang is more aggressive about -Wformat warnings when the format flag
specifies a type smaller than the parameter. Turns out, struct
Scsi_Host's member can_queue is actually an int. Fixes:

warning: format specifies type 'short' but the argument has type 'int'
[-Wformat]
shost_rd_attr(can_queue, "%hd\n");
^
  %d
Link: https://github.com/ClangBuiltLinux/linux/issues/378
Signed-off-by: Nick Desaulniers 
---
 drivers/scsi/scsi_sysfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index d6e344fa33ad..b6378c8ca783 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -370,7 +370,7 @@ static DEVICE_ATTR(eh_deadline, S_IRUGO | S_IWUSR, 
show_shost_eh_deadline, store
 
 shost_rd_attr(unique_id, "%u\n");
 shost_rd_attr(cmd_per_lun, "%hd\n");
-shost_rd_attr(can_queue, "%hd\n");
+shost_rd_attr(can_queue, "%d\n");
 shost_rd_attr(sg_tablesize, "%hu\n");
 shost_rd_attr(sg_prot_tablesize, "%hu\n");
 shost_rd_attr(unchecked_isa_dma, "%d\n");
-- 
2.29.2.222.g5d2a92d10f8-goog



[PATCH] firmware: fix spelling typo of 'wtih'

2020-11-07 Thread Wang Qing
wtih -> with

Signed-off-by: Wang Qing 
---
 drivers/firmware/raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 2371d08..30259dc
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Defines interfaces for interacting wtih the Raspberry Pi firmware's
+ * Defines interfaces for interacting with the Raspberry Pi firmware's
  * property channel.
  *
  * Copyright © 2015 Broadcom
-- 
2.7.4



Re: [Linux-kernel-mentees] [PATCH v2 net] rose: Fix Null pointer dereference in rose_send_frame()

2020-11-07 Thread Anmol Karn
Hello Sir,

On Fri, Nov 06, 2020 at 01:04:27PM -0800, Saeed Mahameed wrote:
> On Thu, 2020-11-05 at 21:26 +0530, Anmol Karn wrote:
> > rose_send_frame() dereferences `neigh->dev` when called from
> > rose_transmit_clear_request(), and the first occurance of the `neigh`
> > is in rose_loopback_timer() as `rose_loopback_neigh`, and it is
> > initialized
> > in rose_add_loopback_neigh() as NULL. i.e when `rose_loopback_neigh`
> > used in 
> > rose_loopback_timer() its `->dev` was still NULL and
> > rose_loopback_timer() 
> > was calling rose_rx_call_request() without checking for NULL.
> > 
> > - net/rose/rose_link.c
> > This bug seems to get triggered in this line:
> > 
> > rose_call = (ax25_address *)neigh->dev->dev_addr;
> > 
> > Fix it by adding NULL checking for `rose_loopback_neigh->dev` in
> > rose_loopback_timer(). 
> > 
> > Reported-and-tested-by: 
> > syzbot+a1c743815982d9496...@syzkaller.appspotmail.com 
> > Link: 
> > https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
> >  
> > Signed-off-by: Anmol Karn 
> 
> missing proper fixes tag.
> 
> > ---
> >  net/rose/rose_loopback.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
> > index 7b094275ea8b..cd7774cb1d07 100644
> > --- a/net/rose/rose_loopback.c
> > +++ b/net/rose/rose_loopback.c
> > @@ -96,7 +96,7 @@ static void rose_loopback_timer(struct timer_list
> > *unused)
> > }
> >  
> > if (frametype == ROSE_CALL_REQUEST) {
> > -   if ((dev = rose_dev_get(dest)) != NULL) {
> > +   if (rose_loopback_neigh->dev && (dev =
> > rose_dev_get(dest)) != NULL) {
> > if (rose_rx_call_request(skb, dev,
> > rose_loopback_neigh, lci_o) == 0)
> > kfree_skb(skb);
> > } else {
> 
> check patch is not happy:
> 
> WARNING:TYPO_SPELLING: 'occurance' may be misspelled - perhaps
> 'occurrence'?
> #7: 
> rose_transmit_clear_request(), and the first occurance of the `neigh`
> 
> ERROR:ASSIGN_IN_IF: do not use assignment in if condition
> #36: FILE: net/rose/rose_loopback.c:99:
> +   if (rose_loopback_neigh->dev && (dev =
> rose_dev_get(dest)) != NULL) {
> 
> total: 1 errors, 1 warnings, 0 checks, 8 lines checked
> 
> 

Thank you for your review will rectify these and send another version.

Thanks,
Anmol


Re: WARNING in input_register_device

2020-11-07 Thread Greg KH
On Fri, Nov 06, 2020 at 09:03:14AM -0800, Eric Biggers wrote:
> On Fri, Nov 06, 2020 at 03:03:36PM +0100, Greg KH wrote:
> > On Fri, Nov 06, 2020 at 04:43:17AM -0800, syzbot wrote:
> > > Hello,
> > > 
> > > syzbot found the following issue on:
> > > 
> > > HEAD commit:9e39aef3 usb: misc: brcmstb-usb-pinmap: Make 
> > > sync_all_pins..
> > > git tree:   
> > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=145ffa8a50
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=a05f5efbb00b1465
> > > dashboard link: 
> > > https://syzkaller.appspot.com/bug?extid=92340f7b2b4789907fdb
> > > compiler:   gcc (GCC) 10.1.0-syz 20200507
> > > syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=172ae7a850
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13b2474650
> > > 
> > > IMPORTANT: if you fix the issue, please add the following tag to the 
> > > commit:
> > > Reported-by: syzbot+92340f7b2b4789907...@syzkaller.appspotmail.com
> > > 
> > > microsoft 0003:045E:07DA.0001: unknown main item tag 0x0
> > > HID 045e:07da: Invalid code 65791 type 1
> > > [ cut here ]
> > > init_uevent_argv: buffer size too small
> > > WARNING: CPU: 0 PID: 5 at lib/kobject_uevent.c:259 init_uevent_argv 
> > > lib/kobject_uevent.c:259 [inline]
> > > WARNING: CPU: 0 PID: 5 at lib/kobject_uevent.c:259 
> > > kobject_uevent_env+0x1640/0x1680 lib/kobject_uevent.c:608
> > 
> > You gave it a device with a buffer that was "too small", and it rejected
> > it.
> > 
> > Which, aside from the huge warning message, is to be expected, so I
> > don't think this is really a bug here.
> > 
> 
> The purpose of WARN is for reporting recoverable kernel bugs.  So a reachable
> WARN is a bug.  Either it is reporting one, or the bug is that the use of WARN
> is wrong.

In the past, as you know, we have thought that hardware issues like this
are a "recoverable bug but someone better do something about it".  Now
that we can fake hardware devices so easily, it's probably better to
just knock this down to a dev_warn() and keep on moving.

If I get a chance, I'll write up a patch today, but anyone else should
feel free to also do it.

thanks,

greg k-h


[PATCH] locking: remove duplicate include of percpu-rwsem.h

2020-11-07 Thread Wang Qing
Remove duplicate header include which is unnecessary.

Signed-off-by: Wang Qing 
---
 kernel/locking/locktorture.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index 62d215b..af99e9c 100644
--- a/kernel/locking/locktorture.c
+++ b/kernel/locking/locktorture.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 MODULE_LICENSE("GPL");
-- 
2.7.4



[PATCH 1/2] tomoyo: Convert get_user_pages*() to pin_user_pages*()

2020-11-07 Thread Souptick Joarder
In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] & [2] could
be referred for more information. This is case 5 as per document [1].

[1] Documentation/core-api/pin_user_pages.rst

[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/

Signed-off-by: Souptick Joarder 
Cc: John Hubbard 
---
 security/tomoyo/domain.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/tomoyo/domain.c b/security/tomoyo/domain.c
index dc4ecc0..bd748be 100644
--- a/security/tomoyo/domain.c
+++ b/security/tomoyo/domain.c
@@ -914,7 +914,7 @@ bool tomoyo_dump_page(struct linux_binprm *bprm, unsigned 
long pos,
 * (represented by bprm).  'current' is the process doing
 * the execve().
 */
-   if (get_user_pages_remote(bprm->mm, pos, 1,
+   if (pin_user_pages_remote(bprm->mm, pos, 1,
FOLL_FORCE, &page, NULL, NULL) <= 0)
return false;
 #else
@@ -936,7 +936,7 @@ bool tomoyo_dump_page(struct linux_binprm *bprm, unsigned 
long pos,
}
/* Same with put_arg_page(page) in fs/exec.c */
 #ifdef CONFIG_MMU
-   put_page(page);
+   unpin_user_page(page);
 #endif
return true;
 }
-- 
1.9.1



[PATCH 2/2] tomoyo: Fixed typo in documentation

2020-11-07 Thread Souptick Joarder
Fixed typo s/Poiner/Pointer

Fixes: 5b636857fee6 ("TOMOYO: Allow using argv[]/envp[] of execve() as 
conditions.")
Signed-off-by: Souptick Joarder 
Cc: John Hubbard 
---
 security/tomoyo/domain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/tomoyo/domain.c b/security/tomoyo/domain.c
index bd748be..7b2babe 100644
--- a/security/tomoyo/domain.c
+++ b/security/tomoyo/domain.c
@@ -891,7 +891,7 @@ int tomoyo_find_next_domain(struct linux_binprm *bprm)
  *
  * @bprm: Pointer to "struct linux_binprm".
  * @pos:  Location to dump.
- * @dump: Poiner to "struct tomoyo_page_dump".
+ * @dump: Pointer to "struct tomoyo_page_dump".
  *
  * Returns true on success, false otherwise.
  */
-- 
1.9.1



[PATCH v1] i2c: nvidia-gpu: drop empty stub for runtime pm

2020-11-07 Thread Vaibhav Gupta
After the commit c5eb1190074c ("PCI / PM: Allow runtime PM without callback
functions") we no more need empty stubs for runtime-pm to work.

The driver has no device specific task(s) for .suspend() . The stub was
placed just for runtime-pm, which can be dropped now.

Reported-by: Bjorn Helgaas 
Signed-off-by: Vaibhav Gupta 
---
 drivers/i2c/busses/i2c-nvidia-gpu.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/i2c/busses/i2c-nvidia-gpu.c 
b/drivers/i2c/busses/i2c-nvidia-gpu.c
index f9a69b109e5c..6b20601ffb13 100644
--- a/drivers/i2c/busses/i2c-nvidia-gpu.c
+++ b/drivers/i2c/busses/i2c-nvidia-gpu.c
@@ -353,15 +353,7 @@ static void gpu_i2c_remove(struct pci_dev *pdev)
pci_free_irq_vectors(pdev);
 }
 
-/*
- * We need gpu_i2c_suspend() even if it is stub, for runtime pm to work
- * correctly. Without it, lspci shows runtime pm status as "D0" for the card.
- * Documentation/power/pci.rst also insists for driver to provide this.
- */
-static __maybe_unused int gpu_i2c_suspend(struct device *dev)
-{
-   return 0;
-}
+#define gpu_i2c_suspend NULL
 
 static __maybe_unused int gpu_i2c_resume(struct device *dev)
 {
-- 
2.28.0



[PATCH] sched: remove duplicate include unnecessary

2020-11-07 Thread Wang Qing
Remove duplicate header include which is unnecessary.

Signed-off-by: Wang Qing 
---
 kernel/sched/sched.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index df80bfc..dd91a8b
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -351,7 +351,6 @@ extern bool dl_cpu_busy(unsigned int cpu);
 #ifdef CONFIG_CGROUP_SCHED
 
 #include 
-#include 
 
 struct cfs_rq;
 struct rt_rq;
-- 
2.7.4



Re: [PATCH v2] Make iwmmxt.S support Clang's integrated assembler

2020-11-07 Thread Ard Biesheuvel
On Sat, 7 Nov 2020 at 01:11, Jian Cai  wrote:
>
> This patch replaces 6 IWMMXT instructions Clang's integrated assembler
> does not support in iwmmxt.S using macros, while making sure GNU
> assembler still emit the same instructions. This should be easier than
> providing full IWMMXT support in Clang.
>
> "Intel Wireless MMX Technology - Developer Guide - August, 2002" should
> be referenced for the encoding schemes of these extensions.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/975
>
> Suggested-by: Nick Desaulniers 
> Suggested-by: Ard Biesheuvel 
> Signed-off-by: Jian Cai 

Please make sure you test this carefully on BE32, as the instruction
byte order used by .inst is LE IIRC

> ---
>  arch/arm/kernel/iwmmxt.S | 89 
>  arch/arm/kernel/iwmmxt.h | 47 +
>  2 files changed, 92 insertions(+), 44 deletions(-)
>  create mode 100644 arch/arm/kernel/iwmmxt.h
>
> diff --git a/arch/arm/kernel/iwmmxt.S b/arch/arm/kernel/iwmmxt.S
> index 0dcae787b004..d2b4ac06e4ed 100644
> --- a/arch/arm/kernel/iwmmxt.S
> +++ b/arch/arm/kernel/iwmmxt.S
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include "iwmmxt.h"
>
>  #if defined(CONFIG_CPU_PJ4) || defined(CONFIG_CPU_PJ4B)
>  #define PJ4(code...)   code
> @@ -113,33 +114,33 @@ concan_save:
>
>  concan_dump:
>
> -   wstrw   wCSSF, [r1, #MMX_WCSSF]
> -   wstrw   wCASF, [r1, #MMX_WCASF]
> -   wstrw   wCGR0, [r1, #MMX_WCGR0]
> -   wstrw   wCGR1, [r1, #MMX_WCGR1]
> -   wstrw   wCGR2, [r1, #MMX_WCGR2]
> -   wstrw   wCGR3, [r1, #MMX_WCGR3]
> +   wstrw   wCSSF, r1, MMX_WCSSF
> +   wstrw   wCASF, r1, MMX_WCASF
> +   wstrw   wCGR0, r1, MMX_WCGR0
> +   wstrw   wCGR1, r1, MMX_WCGR1
> +   wstrw   wCGR2, r1, MMX_WCGR2
> +   wstrw   wCGR3, r1, MMX_WCGR3
>
>  1: @ MUP? wRn
> tst r2, #0x2
> beq 2f
>
> -   wstrd   wR0,  [r1, #MMX_WR0]
> -   wstrd   wR1,  [r1, #MMX_WR1]
> -   wstrd   wR2,  [r1, #MMX_WR2]
> -   wstrd   wR3,  [r1, #MMX_WR3]
> -   wstrd   wR4,  [r1, #MMX_WR4]
> -   wstrd   wR5,  [r1, #MMX_WR5]
> -   wstrd   wR6,  [r1, #MMX_WR6]
> -   wstrd   wR7,  [r1, #MMX_WR7]
> -   wstrd   wR8,  [r1, #MMX_WR8]
> -   wstrd   wR9,  [r1, #MMX_WR9]
> -   wstrd   wR10, [r1, #MMX_WR10]
> -   wstrd   wR11, [r1, #MMX_WR11]
> -   wstrd   wR12, [r1, #MMX_WR12]
> -   wstrd   wR13, [r1, #MMX_WR13]
> -   wstrd   wR14, [r1, #MMX_WR14]
> -   wstrd   wR15, [r1, #MMX_WR15]
> +   wstrd   wR0,  r1, MMX_WR0
> +   wstrd   wR1,  r1, MMX_WR1
> +   wstrd   wR2,  r1, MMX_WR2
> +   wstrd   wR3,  r1, MMX_WR3
> +   wstrd   wR4,  r1, MMX_WR4
> +   wstrd   wR5,  r1, MMX_WR5
> +   wstrd   wR6,  r1, MMX_WR6
> +   wstrd   wR7,  r1, MMX_WR7
> +   wstrd   wR8,  r1, MMX_WR8
> +   wstrd   wR9,  r1, MMX_WR9
> +   wstrd   wR10, r1, MMX_WR10
> +   wstrd   wR11, r1, MMX_WR11
> +   wstrd   wR12, r1, MMX_WR12
> +   wstrd   wR13, r1, MMX_WR13
> +   wstrd   wR14, r1, MMX_WR14
> +   wstrd   wR15, r1, MMX_WR15
>
>  2: teq r0, #0  @ anything to load?
> reteq   lr  @ if not, return
> @@ -147,30 +148,30 @@ concan_dump:
>  concan_load:
>
> @ Load wRn
> -   wldrd   wR0,  [r0, #MMX_WR0]
> -   wldrd   wR1,  [r0, #MMX_WR1]
> -   wldrd   wR2,  [r0, #MMX_WR2]
> -   wldrd   wR3,  [r0, #MMX_WR3]
> -   wldrd   wR4,  [r0, #MMX_WR4]
> -   wldrd   wR5,  [r0, #MMX_WR5]
> -   wldrd   wR6,  [r0, #MMX_WR6]
> -   wldrd   wR7,  [r0, #MMX_WR7]
> -   wldrd   wR8,  [r0, #MMX_WR8]
> -   wldrd   wR9,  [r0, #MMX_WR9]
> -   wldrd   wR10, [r0, #MMX_WR10]
> -   wldrd   wR11, [r0, #MMX_WR11]
> -   wldrd   wR12, [r0, #MMX_WR12]
> -   wldrd   wR13, [r0, #MMX_WR13]
> -   wldrd   wR14, [r0, #MMX_WR14]
> -   wldrd   wR15, [r0, #MMX_WR15]
> +   wldrd   wR0,  r0, MMX_WR0
> +   wldrd   wR1,  r0, MMX_WR1
> +   wldrd   wR2,  r0, MMX_WR2
> +   wldrd   wR3,  r0, MMX_WR3
> +   wldrd   wR4,  r0, MMX_WR4
> +   wldrd   wR5,  r0, MMX_WR5
> +   wldrd   wR6,  r0, MMX_WR6
> +   wldrd   wR7,  r0, MMX_WR7
> +   wldrd   wR8,  r0, MMX_WR8
> +   wldrd   wR9,  r0, MMX_WR9
> +   wldrd   wR10, r0, MMX_WR10
> +   wldrd   wR11, r0, MMX_WR11
> +   wldrd   wR12, r0, MMX_WR12
> +   wldrd   wR13, r0, MMX_WR13
> +   wldrd   wR14, r0, MMX_WR14
> +   wldrd   wR15, r0, MMX_WR15
>
> @ Load wCx
> -   wldrw   wCSSF, [r0, #MMX_WCSSF]
> -   wldrw   wCASF, [r0, #MMX_WCASF]
> -   wldrw   wCGR0, [r0, #MMX_WCGR0]
> -   wldrw   wCGR1, [r0, #MMX_WCGR1]
> -   wldrw   wCGR2, [r0, #MMX_WCGR2]
> -   wldrw   wCGR3, [r0, #MMX_WCGR3]
> +   wldrw   wCSSF, r0, MMX_WCSSF
> +   wldrw   wCASF, r0, MMX_WCASF
> +   wldrw   wCGR0, r0, MMX_WCGR0
> +   wldrw   wCGR1, r0, MMX_WCGR1
> +   wld

[PATCH] ACPI: GED: fix -Wformat

2020-11-07 Thread Nick Desaulniers
Clang is more aggressive about -Wformat warnings when the format flag
specifies a type smaller than the parameter. It turns out that gsi is an
int. Fixes:

drivers/acpi/evged.c:105:48: warning: format specifies type 'unsigned
char' but the argument has type 'unsigned int' [-Wformat]
trigger == ACPI_EDGE_SENSITIVE ? 'E' : 'L', gsi);
^~~

Link: https://github.com/ClangBuiltLinux/linux/issues/378
Fixes: commit ea6f3af4c5e6 ("ACPI: GED: add support for _Exx / _Lxx handler 
methods")
Signed-off-by: Nick Desaulniers 
---
 drivers/acpi/evged.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/evged.c b/drivers/acpi/evged.c
index b1a7f8d6965e..fe6b6792c8bb 100644
--- a/drivers/acpi/evged.c
+++ b/drivers/acpi/evged.c
@@ -101,7 +101,7 @@ static acpi_status acpi_ged_request_interrupt(struct 
acpi_resource *ares,
 
switch (gsi) {
case 0 ... 255:
-   sprintf(ev_name, "_%c%02hhX",
+   sprintf(ev_name, "_%c%02X",
trigger == ACPI_EDGE_SENSITIVE ? 'E' : 'L', gsi);
 
if (ACPI_SUCCESS(acpi_get_handle(handle, ev_name, &evt_handle)))
-- 
2.29.2.222.g5d2a92d10f8-goog



Re: [PATCH v2 0/6] platform/chrome: cros_ec_typec: Add cable

2020-11-07 Thread Greg KH
On Fri, Nov 06, 2020 at 10:40:57AM -0800, Prashant Malani wrote:
> The following series adds Type C cable registration to the cros-ec-typec
> port driver using the Type C connector class framework. The first few
> patches perform a few minor re-organizations to prepare for the cable
> registration patch.
> 
> The last couple of CLs update the USB PD VDO header file to add a
> captive cable connector for the Type C cable plug field, and then use
> the added macro to add the corresponding field of the Type C cable
> descriptor in the cros-ec-typec driver.
> 
> v1:
> https://lore.kernel.org/lkml/20201106012758.525472-1-pmal...@chromium.org/
> 
> Changes since v2:
> - Changed local variable uint32_t to u32 in patch 6/6.

Looks good to me, for all of these:

Reviewed-by: Greg Kroah-Hartman 



Re: [PATCH] ACPI: GED: fix -Wformat

2020-11-07 Thread Ard Biesheuvel
On Sat, 7 Nov 2020 at 09:34, Nick Desaulniers  wrote:
>
> Clang is more aggressive about -Wformat warnings when the format flag
> specifies a type smaller than the parameter. It turns out that gsi is an
> int. Fixes:
>
> drivers/acpi/evged.c:105:48: warning: format specifies type 'unsigned
> char' but the argument has type 'unsigned int' [-Wformat]
> trigger == ACPI_EDGE_SENSITIVE ? 'E' : 'L', gsi);
> ^~~
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/378
> Fixes: commit ea6f3af4c5e6 ("ACPI: GED: add support for _Exx / _Lxx handler 
> methods")

Please drop the word 'commit' here

> Signed-off-by: Nick Desaulniers 

Acked-by: Ard Biesheuvel 

> ---
>  drivers/acpi/evged.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/evged.c b/drivers/acpi/evged.c
> index b1a7f8d6965e..fe6b6792c8bb 100644
> --- a/drivers/acpi/evged.c
> +++ b/drivers/acpi/evged.c
> @@ -101,7 +101,7 @@ static acpi_status acpi_ged_request_interrupt(struct 
> acpi_resource *ares,
>
> switch (gsi) {
> case 0 ... 255:
> -   sprintf(ev_name, "_%c%02hhX",
> +   sprintf(ev_name, "_%c%02X",
> trigger == ACPI_EDGE_SENSITIVE ? 'E' : 'L', gsi);
>
> if (ACPI_SUCCESS(acpi_get_handle(handle, ev_name, 
> &evt_handle)))
> --
> 2.29.2.222.g5d2a92d10f8-goog
>


Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

2020-11-07 Thread Minchan Kim
Hi Andrew,

On Fri, Nov 06, 2020 at 05:59:33PM -0800, Andrew Morton wrote:
> On Thu,  5 Nov 2020 09:02:49 -0800 Minchan Kim  wrote:
> 
> > This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e.
> > 
> > While I was doing zram testing, I found sometimes decompression failed
> > since the compression buffer was corrupted. With investigation,
> > I found below commit calls cond_resched unconditionally so it could
> > make a problem in atomic context if the task is reschedule.
> > 
> > Revert the original commit for now.
> > 
> > [   55.109012] BUG: sleeping function called from invalid context at 
> > mm/vmalloc.c:108
> > [   55.110774] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 946, 
> > name: memhog
> > [   55.111973] 3 locks held by memhog/946:
> > [   55.112807]  #0: 9d01d4b193e8 (&mm->mmap_lock#2){}-{4:4}, at: 
> > __mm_populate+0x103/0x160
> > [   55.114151]  #1: a3d53de0 (fs_reclaim){+.+.}-{0:0}, at: 
> > __alloc_pages_slowpath.constprop.0+0xa98/0x1160
> > [   55.115848]  #2: 9d01d56b8110 (&zspage->lock){.+.+}-{3:3}, at: 
> > zs_map_object+0x8e/0x1f0
> > [   55.118947] CPU: 0 PID: 946 Comm: memhog Not tainted 
> > 5.9.3-00011-gc5bfc0287345-dirty #316
> > [   55.121265] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> > 1.13.0-1 04/01/2014
> > [   55.122540] Call Trace:
> > [   55.122974]  dump_stack+0x8b/0xb8
> > [   55.123588]  ___might_sleep.cold+0xb6/0xc6
> > [   55.124328]  unmap_kernel_range_noflush+0x2eb/0x350
> > [   55.125198]  unmap_kernel_range+0x14/0x30
> > [   55.125920]  zs_unmap_object+0xd5/0xe0
> > [   55.126604]  zram_bvec_rw.isra.0+0x38c/0x8e0
> > [   55.127462]  zram_rw_page+0x90/0x101
> > [   55.128199]  bdev_write_page+0x92/0xe0
> > [   55.128957]  ? swap_slot_free_notify+0xb0/0xb0
> > [   55.129841]  __swap_writepage+0x94/0x4a0
> > [   55.130636]  ? do_raw_spin_unlock+0x4b/0xa0
> > [   55.131462]  ? _raw_spin_unlock+0x1f/0x30
> > [   55.132261]  ? page_swapcount+0x6c/0x90
> > [   55.133038]  pageout+0xe3/0x3a0
> > [   55.133702]  shrink_page_list+0xb94/0xd60
> > [   55.134626]  shrink_inactive_list+0x158/0x460
> >
> > ...
> >
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -102,8 +102,6 @@ static void vunmap_pmd_range(pud_t *pud, unsigned long 
> > addr, unsigned long end,
> > if (pmd_none_or_clear_bad(pmd))
> > continue;
> > vunmap_pte_range(pmd, addr, next, mask);
> > -
> > -   cond_resched();
> > } while (pmd++, addr = next, addr != end);
> >  }
> 
> If this is triggering a warning then why isn't the might_sleep() in
> remove_vm_area() also triggering?

I don't understand what specific callpath you are talking but if
it's clearly called in atomic context, the reason would be config
combination I met.

CONFIG_PREEMPT_VOLUNTARY + no CONFIG_DEBUG_ATOMIC_SLEEP

It makes preempt_count logic void so might_sleep warning will not work.

> 
> Sigh.  I also cannot remember why these vfree() functions have to be so
> awkward.  The mutex_trylock(&vmap_purge_lock) isn't permitted in
> interrupt context because mutex_trylock() is stupid, but what was the
> issue with non-interrupt atomic code?
> 

Seems like a latency issue.

commit f9e09977671b
Author: Christoph Hellwig 
Date:   Mon Dec 12 16:44:23 2016 -0800

mm: turn vmap_purge_lock into a mutex

The purge_lock spinlock causes high latencies with non RT kernel,



[PATCH] wireless: realtek: fix spelling typo of workaround

2020-11-07 Thread Wang Qing
workarould -> workaround

Signed-off-by: Wang Qing 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
index f41a764..b4628b4
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
@@ -62,7 +62,7 @@ static void rtl8812ae_fixspur(struct ieee80211_hw *hw,
rtl_set_bbreg(hw, RRFMOD, 0xC00, 0x2);
/* 0x8AC[11:10] = 2'b10*/
 
-   /* <20120914, Kordan> A workarould to resolve
+   /* <20120914, Kordan> A workaround to resolve
 * 2480Mhz spur by setting ADC clock as 160M. (Asked by Binson)
 */
if (band_width == HT_CHANNEL_WIDTH_20 &&
@@ -82,7 +82,7 @@ static void rtl8812ae_fixspur(struct ieee80211_hw *hw,
/*0x8C4[30] = 0*/
}
} else if (rtlhal->hw_type == HARDWARE_TYPE_RTL8812AE) {
-   /* <20120914, Kordan> A workarould to resolve
+   /* <20120914, Kordan> A workaround to resolve
 * 2480Mhz spur by setting ADC clock as 160M.
 */
if (band_width == HT_CHANNEL_WIDTH_20 &&
-- 
2.7.4



[PATCH v2] Revert "kbuild: Do not enable -Wimplicit-fallthrough for clang for now"

2020-11-07 Thread Nick Desaulniers
This reverts commit e2079e93f562c7f7a030eb7642017ee5eabaaa10.

This has been fixed up over time thanks to the addition of "fallthrough"
pseudo-keyword in
commit 294f69e662d1 ("compiler_attributes.h: Add 'fallthrough' pseudo
keyword for switch/case use")

Link: https://github.com/ClangBuiltLinux/linux/issues/236
Signed-off-by: Nick Desaulniers 
---
Changes V1 -> V2:
* We actually want a revert, not a partial revert. v1 removed
  -Wimplicit-fallthrough outright, which we don't want. We still need
  cc-option for GCC < 7.

 Makefile | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index f353886dbf44..3edce16daede 100644
--- a/Makefile
+++ b/Makefile
@@ -777,11 +777,6 @@ else
 # These warnings generated too much noise in a regular build.
 # Use make W=1 to enable them (see scripts/Makefile.extrawarn)
 KBUILD_CFLAGS += -Wno-unused-but-set-variable
-
-# Warn about unmarked fall-throughs in switch statement.
-# Disabled for clang while comment to attribute conversion happens and
-# https://github.com/ClangBuiltLinux/linux/issues/636 is discussed.
-KBUILD_CFLAGS += $(call cc-option,-Wimplicit-fallthrough,)
 endif
 
 KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable)
@@ -905,6 +900,9 @@ NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) 
-print-file-name=include)
 # warn about C99 declaration after statement
 KBUILD_CFLAGS += -Wdeclaration-after-statement
 
+# Warn about unmarked fall-throughs in switch statement.
+KBUILD_CFLAGS += $(call cc-option,-Wimplicit-fallthrough,)
+
 # Variable Length Arrays (VLAs) should not be used anywhere in the kernel
 KBUILD_CFLAGS += -Wvla
 
-- 
2.29.2.222.g5d2a92d10f8-goog



Re: [PATCH v4 0/2] iommu/tegra-smmu: Two followup changes

2020-11-07 Thread Nicolin Chen
On Mon, Sep 28, 2020 at 11:13:23PM -0700, Nicolin Chen wrote:
> Two followup patches for tegra-smmu:
> PATCH-1 is a clean-up patch for the recently applied SWGROUP change.
> PATCH-2 fixes a potential race condition

These two changes have Acked-by and Reviewed-by for a month already.
Who can apply them?

Thanks
Nic

> Changelog
> v3->v4:
>  * PATCH-2: Fixed typo in subject
> v2->v3:
>  * PATCH-2: renamed "err_unlock" to "unlock"
> v1->v2:
>  * Separated first two changs of V1 so they may get applied first,
>since the other three changes need some extra time to finalize.
> 
> Nicolin Chen (2):
>   iommu/tegra-smmu: Unwrap tegra_smmu_group_get
>   iommu/tegra-smmu: Expand mutex protection range
> 
>  drivers/iommu/tegra-smmu.c | 53 ++
>  1 file changed, 25 insertions(+), 28 deletions(-)
> 
> -- 
> 2.17.1
> 


[PATCH v2] ACPI: GED: fix -Wformat

2020-11-07 Thread Nick Desaulniers
Clang is more aggressive about -Wformat warnings when the format flag
specifies a type smaller than the parameter. It turns out that gsi is an
int. Fixes:

drivers/acpi/evged.c:105:48: warning: format specifies type 'unsigned
char' but the argument has type 'unsigned int' [-Wformat]
trigger == ACPI_EDGE_SENSITIVE ? 'E' : 'L', gsi);
^~~

Link: https://github.com/ClangBuiltLinux/linux/issues/378
Fixes: ea6f3af4c5e6 ("ACPI: GED: add support for _Exx / _Lxx handler methods")
Acked-by: Ard Biesheuvel 
Signed-off-by: Nick Desaulniers 
---
 drivers/acpi/evged.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/evged.c b/drivers/acpi/evged.c
index b1a7f8d6965e..fe6b6792c8bb 100644
--- a/drivers/acpi/evged.c
+++ b/drivers/acpi/evged.c
@@ -101,7 +101,7 @@ static acpi_status acpi_ged_request_interrupt(struct 
acpi_resource *ares,
 
switch (gsi) {
case 0 ... 255:
-   sprintf(ev_name, "_%c%02hhX",
+   sprintf(ev_name, "_%c%02X",
trigger == ACPI_EDGE_SENSITIVE ? 'E' : 'L', gsi);
 
if (ACPI_SUCCESS(acpi_get_handle(handle, ev_name, &evt_handle)))
-- 
2.29.2.222.g5d2a92d10f8-goog



Re: [PATCH v7 0/3] iommu/tegra-smmu: Add PCI support

2020-11-07 Thread Nicolin Chen
On Fri, Oct 09, 2020 at 09:19:33AM -0700, Nicolin Chen wrote:
> This series is to add PCI support in tegra-smmu driver.

This v7 has fixed all the existing comments and been in the
maillist for nearly a month. Can anyone please apply them?

Thanks
Nic

> Changelog (Detail in each patch)
> v6->v7
>  * Added comments for put_device in PATCH-2
>  * Renamed goto labels in PATCH-3
>  * Kept Dmitry's Reviewed-by and Tested-by as no function change
> v5->v6
>  * Dropped a NULL check, per Dmitry's comments
>  * Added Dmitry's Reviewed-by and Tested-by
> v4->v5
>  * PATCH-1 Cleaned two variables inits
>  * PATCH-2 Fixed put() in ->of_xlate() and Updated commit message
>  * PATCH-3 Added Dmitry's Reviewed-by
> v3->v4
>  * Dropped helper function, per Thierry's comments
>  * Found another way to get smmu pointer
> v2->v3
>  * Replaced with devm_tegra_get_memory_controller
>  * Updated changes by following Dmitry's comments
> v1->v2
>  * Added PATCH-1 suggested by Dmitry
>  * Reworked PATCH-2 to unify certain code
> 
> Nicolin Chen (3):
>   iommu/tegra-smmu: Use fwspec in tegra_smmu_(de)attach_dev
>   iommu/tegra-smmu: Rework tegra_smmu_probe_device()
>   iommu/tegra-smmu: Add PCI support
> 
>  drivers/iommu/tegra-smmu.c | 187 +
>  1 file changed, 63 insertions(+), 124 deletions(-)
> 
> -- 
> 2.17.1
> 


[PATCH V3] doc: zh_CN: add translatation for tmpfs

2020-11-07 Thread Wang Qing
Translate Documentation/filesystems/tmpfs.rst into Chinese.

Signed-off-by: Wang Qing 

Changes in v3:
 - Fix patch format issue.
---
 .../translations/zh_CN/filesystems/tmpfs.rst   | 146 +
 1 file changed, 146 insertions(+)
 create mode 100644 Documentation/translations/zh_CN/filesystems/tmpfs.rst

diff --git a/Documentation/translations/zh_CN/filesystems/tmpfs.rst 
b/Documentation/translations/zh_CN/filesystems/tmpfs.rst
new file mode 100644
index 000..28f0d09
--- /dev/null
+++ b/Documentation/translations/zh_CN/filesystems/tmpfs.rst
@@ -0,0 +1,146 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/filesystems/tmpfs.rst `
+
+translated by Wang Qing
+
+=
+Tmpfs
+=
+
+Tmpfs是一个将所有文件都保存在虚拟内存中的文件系统。
+
+tmpfs中的所有内容都是临时的,也就是说没有任何文件会在硬盘上创建。
+如果卸载tmpfs实例,所有保存在其中的文件都会丢失。
+
+tmpfs将所有文件保存在内核缓存中,随着文件内容增长或缩小可以将不需要的
+页面swap出去。它具有最大限制,可以通过“mount -o remount ...”调整。
+
+和ramfs(创建tmpfs的模板)相比,tmpfs包含交换和限制检查。和tmpfs相似的另
+一个东西是RAM磁盘(/dev/ram*),可以在物理RAM中模拟固定大小的硬盘,并在
+此之上创建一个普通的文件系统。Ramdisks无法swap,因此无法调整它们的大小。
+
+由于tmpfs完全保存于页面缓存和swap中,因此所有tmpfs页面将在/proc/meminfo
+中显示为“Shmem”,而在free(1)中显示为“Shared”。请注意,这些计数还包括
+共享内存(shmem,请参阅ipcs(1))。获得计数的最可靠方法是使用df(1)和du(1)。
+
+tmpfs具有以下用途:
+
+1) 内核总有一个无法看到的内部挂载,用于共享匿名映射和SYSV共享内存。
+
+   挂载不依赖于CONFIG_TMPFS。如果CONFIG_TMPFS未设置,tmpfs对用户不可见。
+   但是内部机制始终存在。
+
+2) glibc 2.2及更高版本期望将tmpfs挂载在/dev/shm上以用于POSIX共享内存
+   (shm_open,shm_unlink)。添加内容到/etc/fstab应注意如下:
+
+   tmpfs   /dev/shmtmpfs   defaults0 0
+
+   使用时需要记住创建挂载tmpfs的目录。
+
+   SYSV共享内存无需挂载,内部已默认支持。(在2.3内核版本中,必须挂载
+   tmpfs的前身(shm fs)才能使用SYSV共享内存)
+
+3) 很多人(包括我)都觉的在/tmp和/var/tmp上挂载非常方便,并具有较大的
+   swap分区。目前循环挂载tmpfs可以正常工作,所以大多数发布都应当可以
+   使用mkinitrd通过/tmp访问/tmp。
+
+4) 也许还有更多我不知道的地方:-)
+
+
+tmpfs有三个用于调整大小的挂载选项:
+
+=  
+size   tmpfs实例分配的字节数限制。默认值是不swap时物理RAM的一半。
+   如果tmpfs实例过大,机器将死锁,因为OOM处理将无法释放该内存。
+nr_blocks  与size相同,但以PAGE_SIZE为单位。
+nr_inodes  tmpfs实例的最大inode个数。默认值是物理内存页数的一半,或者
+   (有高端内存的机器)低端内存RAM的页数,二者以较低者为准。
+=  
+
+这些参数接受后缀k,m或g表示千,兆和千兆字节,可以在remount时更改。
+size参数也接受后缀%用来限制tmpfs实例占用物理RAM的百分比:
+未指定size或nr_blocks时,默认值为size=50%
+
+如果nr_blocks=0(或size=0),block个数将不受限制;如果nr_inodes=0,
+inode个数将不受限制。这样挂载通常是不明智的,因为它允许任何具有写权限的
+用户通过访问tmpfs耗尽机器上的所有内存;但同时这样做也会增强在多个CPU的
+场景下的访问。
+
+tmpfs具有为所有文件设置NUMA内存分配策略挂载选项(如果启用了CONFIG_NUMA),
+可以通过“mount -o remount ...”调整
+
+ ==
+mpol=default 采用进程分配策略
+ (请参阅 set_mempolicy(2))
+mpol=prefer:Node 倾向从给定的节点分配
+mpol=bind:NodeList   只允许从指定的链表分配
+mpol=interleave  倾向于依次从每个节点分配
+mpol=interleave:NodeList 依次从每个节点分配
+mpol=local  prefers 从本地节点分配内存
+ ==
+
+NodeList格式是以逗号分隔的十进制数字表示大小和范围,最大和最小范围是用-
+分隔符的十进制数来表示。例如,mpol=bind0-3,5,7,9-15
+
+带有有效NodeList的内存策略将按指定格式保存,在创建文件时使用。当任务在该
+文件系统上创建文件时,会使用到挂载时的内存策略NodeList选项,如果设置的话,
+由调用任务的cpuset[请参见Documentation/admin-guide/cgroup-v1/cpusets.rst]
+以及下面列出的可选标志约束。如果NodeLists为设置为空集,则文件的内存策略将
+恢复为“默认”策略。
+
+NUMA内存分配策略有可选标志,可以用于模式结合。在挂载tmpfs时指定这些可选
+标志可以在NodeList之前生效。
+Documentation/admin-guide/mm/numa_memory_policy.rst列出所有可用的内存
+分配策略模式标志及其对内存策略。
+
+::
+
+   =static 相当于 MPOL_F_STATIC_NODES
+   =relative   相当于 MPOL_F_RELATIVE_NODES
+
+例如,mpol=bind=staticNodeList相当于MPOL_BIND|MPOL_F_STATIC_NODES的分配策略
+
+请注意,如果内核不支持NUMA,那么使用mpol选项挂载tmpfs将会失败;nodelist指定不
+在线的节点也会失败。如果您的系统依赖于此,但内核会运行不带NUMA功能(也许是安全
+revocery内核),或者具有较少的节点在线,建议从自动模式中省略mpol选项挂载选项。
+可以在以后通过“mount -o remount,mpol=Policy:NodeList MountPoint”添加到挂载点。
+
+要指定初始根目录,可以使用如下挂载选项:
+
+   ==
+模式 权限用八进制数字表示
+uid应用ID
+gid组ID
+   ==
+
+这些选项对remount没有任何影响。您可以通过chmod(1),chown(1)和chgrp(1)的更改
+已经挂载的参数。
+
+tmpfs具有选择32位还是64位inode的挂载选项:
+
+===   
+inode64   Use 64-bit inode numbers
+inode32   Use 32-bit inode numbers
+===   
+
+在32位内核上,默认是inode32,挂载时指定inode64会被拒绝。
+在64位内核上,默认配置是CONFIG_TMPFS_INODE64。inode64避免了单个设备上可能有多个
+具有相同inode编号的文件;比如32位应用程序使用glibc如果长期访问tmpfs,一旦达到33
+位inode编号,就有EOVERFLOW失败的危险,无法打开大于2GiB的文件,并返回EINVAL。
+
+所以'mount -t tmpfs -o size=10G,nr_inodes=10k,mode=700 tmpfs /mytmpfs'将在
+/mytmpfs上挂载tmpfs实例,分配只能由root用户访问的10GB RAM/SWAP,可以有10240个
+inode的实例。
+
+
+:作者:
+   Christoph Rohland , 1.12.01
+:更新:
+   Hugh Dickins, 4 June 2007
+:更新:
+   KOSAKI Motohiro, 16 Mar 2010
+:更新:
+   Chris Down, 13 July 2020
-- 
2.7.4



Re: [PATCH 2/2] tomoyo: Fixed typo in documentation

2020-11-07 Thread John Hubbard

On 11/7/20 12:24 AM, Souptick Joarder wrote:

Fixed typo s/Poiner/Pointer

Fixes: 5b636857fee6 ("TOMOYO: Allow using argv[]/envp[] of execve() as 
conditions.")
Signed-off-by: Souptick Joarder 
Cc: John Hubbard 
---
  security/tomoyo/domain.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/tomoyo/domain.c b/security/tomoyo/domain.c
index bd748be..7b2babe 100644
--- a/security/tomoyo/domain.c
+++ b/security/tomoyo/domain.c
@@ -891,7 +891,7 @@ int tomoyo_find_next_domain(struct linux_binprm *bprm)
   *
   * @bprm: Pointer to "struct linux_binprm".
   * @pos:  Location to dump.
- * @dump: Poiner to "struct tomoyo_page_dump".
+ * @dump: Pointer to "struct tomoyo_page_dump".


Not worth a separate patch, especially since the original comment is merely
copying the C sources, and as such, does not add any value.

I'd either a) craft a new documentation line that adds some value, or b) just
merge this patch into the previous one, and make a note in the commit
description to the effect that you've included a trivial typo fix as long
as you're there.


thanks,
--
John Hubbard
NVIDIA


   *
   * Returns true on success, false otherwise.
   */



Im rechtlichen Kontext

2020-11-07 Thread Wendy
Ich möchte, dass Sie sich mit mir bei der Durchführung eines Geschäftsprojekts 
zusammenschließen, das einen angemessenen Betrag an Investitionskapital in Höhe 
von 52 Millionen fünfhunderttausend US-Dollar umfasst. Da die Zeit drängt, ist 
es unbedingt erforderlich, dass Sie sich zur weiteren Klärung dieser äußerst 
wichtigen Angelegenheit an mich wenden.

Mit freundlichen Grüßen,

Wendy
E-Mail: w.vanderwo...@aol.com



Re: [PATCH 1/2] tomoyo: Convert get_user_pages*() to pin_user_pages*()

2020-11-07 Thread John Hubbard

On 11/7/20 12:24 AM, Souptick Joarder wrote:

In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] & [2] could
be referred for more information. This is case 5 as per document [1].


It turns out that Case 5 can be implemented via a better pattern, as long
as we're just dealing with a page at a time, briefly:

lock_page()
write to page's data
unlock_page()

...which neatly synchronizes with writeback and other fs activities.

I was going to track down the Case 5's and do that [1].

+CC Jan and Matthew, to keep us on the straight and narrow, just in case
I'm misunderstanding something.

[1] https://lore.kernel.org/r/e78fb7af-627b-ce80-275e-51f97f1f3...@nvidia.com

thanks,
--
John Hubbard
NVIDIA



[1] Documentation/core-api/pin_user_pages.rst

[2] "Explicit pinning of user-space pages":
 https://lwn.net/Articles/807108/

Signed-off-by: Souptick Joarder 
Cc: John Hubbard 
---
  security/tomoyo/domain.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/tomoyo/domain.c b/security/tomoyo/domain.c
index dc4ecc0..bd748be 100644
--- a/security/tomoyo/domain.c
+++ b/security/tomoyo/domain.c
@@ -914,7 +914,7 @@ bool tomoyo_dump_page(struct linux_binprm *bprm, unsigned 
long pos,
 * (represented by bprm).  'current' is the process doing
 * the execve().
 */
-   if (get_user_pages_remote(bprm->mm, pos, 1,
+   if (pin_user_pages_remote(bprm->mm, pos, 1,
FOLL_FORCE, &page, NULL, NULL) <= 0)
return false;
  #else
@@ -936,7 +936,7 @@ bool tomoyo_dump_page(struct linux_binprm *bprm, unsigned 
long pos,
}
/* Same with put_arg_page(page) in fs/exec.c */
  #ifdef CONFIG_MMU
-   put_page(page);
+   unpin_user_page(page);
  #endif
return true;
  }



Re: [PATCH v2] Revert "kbuild: Do not enable -Wimplicit-fallthrough for clang for now"

2020-11-07 Thread Nick Desaulniers
On Sat, Nov 7, 2020 at 12:45 AM Nick Desaulniers
 wrote:
>
> This reverts commit e2079e93f562c7f7a030eb7642017ee5eabaaa10.
>
> This has been fixed up over time thanks to the addition of "fallthrough"
> pseudo-keyword in
> commit 294f69e662d1 ("compiler_attributes.h: Add 'fallthrough' pseudo
> keyword for switch/case use")
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/236
> Signed-off-by: Nick Desaulniers 
> ---
> Changes V1 -> V2:
> * We actually want a revert, not a partial revert. v1 removed
>   -Wimplicit-fallthrough outright, which we don't want. We still need
>   cc-option for GCC < 7.

Gah, I tested a ton of configs with V1...but not V2...this patch is
not ready yet. Sorry for the noise.

-- 
Thanks,
~Nick Desaulniers


[PATCH V3] fsl/fman: add missing put_devcie() call in fman_port_probe()

2020-11-07 Thread Yu Kuai
if of_find_device_by_node() succeed, fman_port_probe() doesn't have a
corresponding put_device(). Thus add jump target to fix the exception
handling for this function implementation.

Fixes: 0572054617f3 ("fsl/fman: fix dereference null return value")
Signed-off-by: Yu Kuai 
---
Changes in V3:
 - move of_node_put(port_node) backward, so that error handling can be the
 reverse of the order of execution.
 - rename retur_err to put_node

 .../net/ethernet/freescale/fman/fman_port.c   | 23 ++-
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/fman_port.c 
b/drivers/net/ethernet/freescale/fman/fman_port.c
index d9baac0dbc7d..9790e483241b 100644
--- a/drivers/net/ethernet/freescale/fman/fman_port.c
+++ b/drivers/net/ethernet/freescale/fman/fman_port.c
@@ -1792,20 +1792,20 @@ static int fman_port_probe(struct platform_device 
*of_dev)
if (!fm_node) {
dev_err(port->dev, "%s: of_get_parent() failed\n", __func__);
err = -ENODEV;
-   goto return_err;
+   goto free_port;
}
 
fm_pdev = of_find_device_by_node(fm_node);
of_node_put(fm_node);
if (!fm_pdev) {
err = -EINVAL;
-   goto return_err;
+   goto put_node;
}
 
fman = dev_get_drvdata(&fm_pdev->dev);
if (!fman) {
err = -EINVAL;
-   goto return_err;
+   goto put_device;
}
 
err = of_property_read_u32(port_node, "cell-index", &val);
@@ -1813,7 +1813,7 @@ static int fman_port_probe(struct platform_device *of_dev)
dev_err(port->dev, "%s: reading cell-index for %pOF failed\n",
__func__, port_node);
err = -EINVAL;
-   goto return_err;
+   goto put_device;
}
port_id = (u8)val;
port->dts_params.id = port_id;
@@ -1847,7 +1847,7 @@ static int fman_port_probe(struct platform_device *of_dev)
}  else {
dev_err(port->dev, "%s: Illegal port type\n", __func__);
err = -EINVAL;
-   goto return_err;
+   goto put_device;
}
 
port->dts_params.type = port_type;
@@ -1861,7 +1861,7 @@ static int fman_port_probe(struct platform_device *of_dev)
dev_err(port->dev, "%s: incorrect qman-channel-id\n",
__func__);
err = -EINVAL;
-   goto return_err;
+   goto put_device;
}
port->dts_params.qman_channel_id = qman_channel_id;
}
@@ -1871,22 +1871,21 @@ static int fman_port_probe(struct platform_device 
*of_dev)
dev_err(port->dev, "%s: of_address_to_resource() failed\n",
__func__);
err = -ENOMEM;
-   goto return_err;
+   goto put_device;
}
 
port->dts_params.fman = fman;
 
-   of_node_put(port_node);
-
dev_res = __devm_request_region(port->dev, &res, res.start,
resource_size(&res), "fman-port");
if (!dev_res) {
dev_err(port->dev, "%s: __devm_request_region() failed\n",
__func__);
err = -EINVAL;
-   goto free_port;
+   goto put_device;
}
 
+   of_node_put(port_node);
port->dts_params.base_addr = devm_ioremap(port->dev, res.start,
  resource_size(&res));
if (!port->dts_params.base_addr)
@@ -1896,7 +1895,9 @@ static int fman_port_probe(struct platform_device *of_dev)
 
return 0;
 
-return_err:
+put_device:
+   put_device(&fm_pdev->dev);
+put_node:
of_node_put(port_node);
 free_port:
kfree(port);
-- 
2.25.4



Re: [PATCH v1] i2c: nvidia-gpu: drop empty stub for runtime pm

2020-11-07 Thread Vaibhav Gupta
On Sat, Nov 07, 2020 at 01:51:51PM +0530, Vaibhav Gupta wrote:
> After the commit c5eb1190074c ("PCI / PM: Allow runtime PM without callback
> functions") we no more need empty stubs for runtime-pm to work.
> 
> The driver has no device specific task(s) for .suspend() . The stub was
> placed just for runtime-pm, which can be dropped now.
> 
> Reported-by: Bjorn Helgaas 
> Signed-off-by: Vaibhav Gupta 
> ---
>  drivers/i2c/busses/i2c-nvidia-gpu.c | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-nvidia-gpu.c 
> b/drivers/i2c/busses/i2c-nvidia-gpu.c
> index f9a69b109e5c..6b20601ffb13 100644
> --- a/drivers/i2c/busses/i2c-nvidia-gpu.c
> +++ b/drivers/i2c/busses/i2c-nvidia-gpu.c
> @@ -353,15 +353,7 @@ static void gpu_i2c_remove(struct pci_dev *pdev)
>   pci_free_irq_vectors(pdev);
>  }
>  
> -/*
> - * We need gpu_i2c_suspend() even if it is stub, for runtime pm to work
> - * correctly. Without it, lspci shows runtime pm status as "D0" for the card.
> - * Documentation/power/pci.rst also insists for driver to provide this.
> - */
> -static __maybe_unused int gpu_i2c_suspend(struct device *dev)
> -{
> - return 0;
> -}
> +#define gpu_i2c_suspend NULL
>  
>  static __maybe_unused int gpu_i2c_resume(struct device *dev)
>  {
> -- 
> 2.28.0
> 
The patch is only compile-tested.

--Vaibhav


[PATCH] powerpc/32s: Use relocation offset when setting early hash table

2020-11-07 Thread Christophe Leroy
When calling early_hash_table(), the kernel hasn't been yet
relocated to its linking address, so data must be addressed
with relocation offset.

Add relocation offset to write into Hash in early_hash_table().

Reported-by: Erhard Furtner 
Reported-by: Andreas Schwab 
Fixes: 69a1593abdbc ("powerpc/32s: Setup the early hash table at all time.")
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/head_book3s_32.S | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/head_book3s_32.S 
b/arch/powerpc/kernel/head_book3s_32.S
index 5eb9eedac920..8aa7eb11754e 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -156,6 +156,7 @@ __after_mmu_off:
bl  initial_bats
bl  load_segment_registers
 BEGIN_MMU_FTR_SECTION
+   bl  reloc_offset
bl  early_hash_table
 END_MMU_FTR_SECTION_IFSET(MMU_FTR_HPTE_TABLE)
 #if defined(CONFIG_BOOTX_TEXT)
@@ -932,7 +933,7 @@ early_hash_table:
ori r6, r6, 3   /* 256kB table */
mtspr   SPRN_SDR1, r6
lis r6, early_hash@h
-   lis r3, Hash@ha
+   addis   r3, r3, Hash@ha
stw r6, Hash@l(r3)
blr
 
-- 
2.25.0



[i2c-next,PATCH] i2c: medaitek: Move suspend and resume handling to NOIRQ phase

2020-11-07 Thread qii.wang
From: Qii Wang 

Some i2c device driver indirectly uses I2C driver when it is now
being suspended. The i2c devices driver is suspended during the
NOIRQ phase and this cannot be changed due to other dependencies.
Therefore, we also need to move the suspend handling for the I2C
controller driver to the NOIRQ phase as well.

Signed-off-by: Qii Wang 
---
 drivers/i2c/busses/i2c-mt65xx.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 33de99b..6f61595 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -1258,7 +1258,8 @@ static int mtk_i2c_probe(struct platform_device *pdev)
mtk_i2c_clock_disable(i2c);
 
ret = devm_request_irq(&pdev->dev, irq, mtk_i2c_irq,
-  IRQF_TRIGGER_NONE, I2C_DRV_NAME, i2c);
+  IRQF_NO_SUSPEND | IRQF_TRIGGER_NONE,
+  I2C_DRV_NAME, i2c);
if (ret < 0) {
dev_err(&pdev->dev,
"Request I2C IRQ %d fail\n", irq);
@@ -1285,7 +1286,16 @@ static int mtk_i2c_remove(struct platform_device *pdev)
 }
 
 #ifdef CONFIG_PM_SLEEP
-static int mtk_i2c_resume(struct device *dev)
+static int mtk_i2c_suspend_noirq(struct device *dev)
+{
+   struct mtk_i2c *i2c = dev_get_drvdata(dev);
+
+   i2c_mark_adapter_suspended(&i2c->adap);
+
+   return 0;
+}
+
+static int mtk_i2c_resume_noirq(struct device *dev)
 {
int ret;
struct mtk_i2c *i2c = dev_get_drvdata(dev);
@@ -1300,12 +1310,15 @@ static int mtk_i2c_resume(struct device *dev)
 
mtk_i2c_clock_disable(i2c);
 
+   i2c_mark_adapter_resumed(&i2c->adap);
+
return 0;
 }
 #endif
 
 static const struct dev_pm_ops mtk_i2c_pm = {
-   SET_SYSTEM_SLEEP_PM_OPS(NULL, mtk_i2c_resume)
+   SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_i2c_suspend_noirq,
+ mtk_i2c_resume_noirq)
 };
 
 static struct platform_driver mtk_i2c_driver = {
-- 
1.9.1


Re: [PATCH] powerpc/32s: Setup the early hash table at all time.

2020-11-07 Thread Christophe Leroy




Le 29/10/2020 à 22:07, Andreas Schwab a écrit :

On Okt 01 2020, Christophe Leroy wrote:


At the time being, an early hash table is set up when
CONFIG_KASAN is selected.

There is nothing wrong with setting such an early hash table
all the time, even if it is not used. This is a statically
allocated 256 kB table which lies in the init data section.

This makes the code simpler and may in the future allow to
setup early IO mappings with fixmap instead of hard coding BATs.

Put create_hpte() and flush_hash_pages() in the .ref.text section
in order to avoid warning for the reference to early_hash[]. This
reference is removed by MMU_init_hw_patch() before init memory is
freed.


This breaks booting on the iBook G4.



Can you test patch 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/9e225a856a8b22e0e77587ee22ab7a2f5bca8753.1604740029.git.christophe.le...@csgroup.eu/


Thanks
Christophe


[PATCH] arm: mm: remove duplicate include

2020-11-07 Thread Wang Qing
Remove duplicate header which is included twice.

Signed-off-by: Wang Qing 
---
 arch/arm/mm/mmu.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index ab69250..4963e1c
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "fault.h"
 #include "mm.h"
-- 
2.7.4



Re: [PATCH v22 12/23] LSM: Specify which LSM to display

2020-11-07 Thread Greg KH
On Fri, Nov 06, 2020 at 04:20:43PM -0800, Casey Schaufler wrote:
> On 11/5/2020 1:22 AM, Greg KH wrote:
> > On Wed, Nov 04, 2020 at 03:41:03PM -0800, Casey Schaufler wrote:
> >> Create a new entry "display" in the procfs attr directory for
> >> controlling which LSM security information is displayed for a
> >> process. A process can only read or write its own display value.
> >>
> >> The name of an active LSM that supplies hooks for
> >> human readable data may be written to "display" to set the
> >> value. The name of the LSM currently in use can be read from
> >> "display". At this point there can only be one LSM capable
> >> of display active. A helper function lsm_task_display() is
> >> provided to get the display slot for a task_struct.
> >>
> >> Setting the "display" requires that all security modules using
> >> setprocattr hooks allow the action. Each security module is
> >> responsible for defining its policy.
> >>
> >> AppArmor hook provided by John Johansen 
> >> SELinux hook provided by Stephen Smalley 
> >>
> >> Reviewed-by: Kees Cook 
> >> Acked-by: Stephen Smalley 
> >> Acked-by: Paul Moore 
> >> Signed-off-by: Casey Schaufler 
> >> Cc: linux-...@vger.kernel.org
> >> ---
> >>  fs/proc/base.c   |   1 +
> >>  include/linux/lsm_hooks.h|  17 +++
> >>  security/apparmor/include/apparmor.h |   3 +-
> >>  security/apparmor/lsm.c  |  32 +
> >>  security/security.c  | 169 ---
> >>  security/selinux/hooks.c |  11 ++
> >>  security/selinux/include/classmap.h  |   2 +-
> >>  security/smack/smack_lsm.c   |   7 ++
> >>  8 files changed, 223 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/fs/proc/base.c b/fs/proc/base.c
> >> index 0f707003dda5..7432f24f0132 100644
> >> --- a/fs/proc/base.c
> >> +++ b/fs/proc/base.c
> >> @@ -2806,6 +2806,7 @@ static const struct pid_entry attr_dir_stuff[] = {
> >>ATTR(NULL, "fscreate",  0666),
> >>ATTR(NULL, "keycreate", 0666),
> >>ATTR(NULL, "sockcreate",0666),
> >> +  ATTR(NULL, "display",   0666),
> > That's a vague name, any chance it can be more descriptive?
> 
> Sure. How about lsm_display, or display_lsm? I wouldn't say that
> any of the files in /proc/*/attr have especially descriptive names,
> but that's hardly an excuse.

I still don't understand what "display" means in this context.  Perhaps
documentation will help clear it up?

thanks,

greg k-h


[PATCH] locking/lock_events: no need to check return value of debugfs_create functions

2020-11-07 Thread Tiezhu Yang
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Signed-off-by: Tiezhu Yang 
---
 kernel/locking/lock_events.c | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/kernel/locking/lock_events.c b/kernel/locking/lock_events.c
index fa2c2f9..bac77a1 100644
--- a/kernel/locking/lock_events.c
+++ b/kernel/locking/lock_events.c
@@ -146,9 +146,6 @@ static int __init init_lockevent_counts(void)
struct dentry *d_counts = debugfs_create_dir(LOCK_EVENTS_DIR, NULL);
int i;
 
-   if (!d_counts)
-   goto out;
-
/*
 * Create the debugfs files
 *
@@ -159,21 +156,13 @@ static int __init init_lockevent_counts(void)
for (i = 0; i < lockevent_num; i++) {
if (skip_lockevent(lockevent_names[i]))
continue;
-   if (!debugfs_create_file(lockevent_names[i], 0400, d_counts,
-(void *)(long)i, &fops_lockevent))
-   goto fail_undo;
+   debugfs_create_file(lockevent_names[i], 0400, d_counts,
+   (void *)(long)i, &fops_lockevent);
}
 
-   if (!debugfs_create_file(lockevent_names[LOCKEVENT_reset_cnts], 0200,
-d_counts, (void *)(long)LOCKEVENT_reset_cnts,
-&fops_lockevent))
-   goto fail_undo;
+   debugfs_create_file(lockevent_names[LOCKEVENT_reset_cnts], 0200, 
d_counts,
+   (void *)(long)LOCKEVENT_reset_cnts, 
&fops_lockevent);
 
return 0;
-fail_undo:
-   debugfs_remove_recursive(d_counts);
-out:
-   pr_warn("Could not create '%s' debugfs entries\n", LOCK_EVENTS_DIR);
-   return -ENOMEM;
 }
 fs_initcall(init_lockevent_counts);
-- 
2.1.0



[PATCH] tool: selftests: fix spelling typo of 'writting'

2020-11-07 Thread Wang Qing
writting -> writing

Signed-off-by: Wang Qing 
---
 tools/testing/selftests/vm/userfaultfd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/vm/userfaultfd.c 
b/tools/testing/selftests/vm/userfaultfd.c
index 9b0912a..9132fae7
--- a/tools/testing/selftests/vm/userfaultfd.c
+++ b/tools/testing/selftests/vm/userfaultfd.c
@@ -894,7 +894,7 @@ static int faulting_process(int signal_test)
count_verify[nr]);
}
/*
-* Trigger write protection if there is by writting
+* Trigger write protection if there is by writing
 * the same value back.
 */
*area_count(area_dst, nr) = count;
@@ -922,7 +922,7 @@ static int faulting_process(int signal_test)
count_verify[nr]); exit(1);
}
/*
-* Trigger write protection if there is by writting
+* Trigger write protection if there is by writing
 * the same value back.
 */
*area_count(area_dst, nr) = count;
-- 
2.7.4



Re: [PATCH] driver core: export device_is_bound() to fix build failure

2020-11-07 Thread Greg Kroah-Hartman
On Fri, Nov 06, 2020 at 03:37:44PM +, Sudip Mukherjee wrote:
> When CONFIG_MXC_CLK_SCU is configured as 'm' the build fails as it
> is unable to find device_is_bound(). The error being:
> ERROR: modpost: "device_is_bound" [drivers/clk/imx/clk-imx-scu.ko]
>   undefined!
> 
> Export the symbol so that the module finds it.
> 
> Signed-off-by: Sudip Mukherjee 
> ---

What patch caused this problem?  Can you resend this with a "Fixes:"
line so we know where to queue it up to?

thanks,

greg k-h


[PATCH] arm: mach-sa1100: remove duplicate include

2020-11-07 Thread Wang Qing
Remove duplicate header which is included twice.

Signed-off-by: Wang Qing 
---
 arch/arm/mach-sa1100/hackkit.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-sa1100/hackkit.c b/arch/arm/mach-sa1100/hackkit.c
index 3085f1c..3fe34ee
--- a/arch/arm/mach-sa1100/hackkit.c
+++ b/arch/arm/mach-sa1100/hackkit.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.7.4



Re: [f2fs-dev] [PATCH v4 2/2] f2fs: fix compat F2FS_IOC_{MOVE, GARBAGE_COLLECT}_RANGE

2020-11-07 Thread Chao Yu

On 2020/11/7 2:03, Eric Biggers wrote:

On Fri, Nov 06, 2020 at 02:53:31PM +0800, Chao Yu wrote:

+#if defined(__KERNEL__)
+struct compat_f2fs_gc_range {
+   u32 sync;
+   compat_u64 start;
+   compat_u64 len;
+};


There's no need to use '#if defined(__KERNEL__)' in kernel source files.

Likewise for compat_f2fs_move_range.


Correct.




+static int f2fs_compat_ioc_gc_range(struct file *file, unsigned long arg)
+{
+   struct f2fs_sb_info *sbi = F2FS_I_SB(file_inode(file));
+   struct compat_f2fs_gc_range __user *urange;
+   struct f2fs_gc_range range;
+   int err;
+
+   if (unlikely(f2fs_cp_error(sbi)))
+   return -EIO;
+   if (!f2fs_is_checkpoint_ready(sbi))
+   return -ENOSPC;


I still don't understand why this checkpoint-related stuff is getting added
here, and only to the compat versions of the ioctls.  It wasn't in the original
version.  If they are needed then they should be added to __f2fs_ioc_gc_range()
and __f2fs_ioc_move_range() (preferably by a separate patch) so that they are


If so, cp-related stuff will be checked redundantly in both f2fs_ioctl() and 
__f2fs_ioc_xxx() function for native GC_RANGE and MOVE_RANGE ioctls, it's not 
needed.


Thanks,


done for both the native and compat versions of these ioctls.

- Eric


___
Linux-f2fs-devel mailing list
linux-f2fs-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel



[PATCH v8 1/3] USB: PHY: JZ4770: Remove unnecessary function calls.

2020-11-07 Thread Zhou Yanjie
Remove unnecessary "of_match_ptr()", because Ingenic SoCs all
depend on Device Tree.

Suggested-by: Paul Cercueil 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
Reviewed-by: Paul Cercueil 
---

Notes:
v3:
New patch.

v3->v4:
No change.

v4->v5:
Add Paul Cercueil's Reviewed-by.

v5->v6:
No change.

v6->v7:
No change.

v7->v8:
No change.

 drivers/usb/phy/phy-jz4770.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-jz4770.c b/drivers/usb/phy/phy-jz4770.c
index f6d3731581eb..4025da20b3fd 100644
--- a/drivers/usb/phy/phy-jz4770.c
+++ b/drivers/usb/phy/phy-jz4770.c
@@ -350,7 +350,7 @@ static struct platform_driver ingenic_phy_driver = {
.probe  = jz4770_phy_probe,
.driver = {
.name   = "jz4770-phy",
-   .of_match_table = of_match_ptr(ingenic_usb_phy_of_matches),
+   .of_match_table = ingenic_usb_phy_of_matches,
},
 };
 module_platform_driver(ingenic_phy_driver);
-- 
2.11.0



[PATCH v8 2/3] dt-bindings: USB: Add bindings for Ingenic JZ4775 and X2000.

2020-11-07 Thread Zhou Yanjie
Move Ingenic USB PHY bindings from Documentation/devicetree/bindings/usb
to Documentation/devicetree/bindings/phy, and add bindings for JZ4775 SoC
and X2000 SoC.

Signed-off-by: 周琰杰 (Zhou Yanjie) 
---

Notes:
v8:
New patch.

 .../{usb/ingenic,jz4770-phy.yaml => phy/ingenic,phy-usb.yaml} | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
 rename Documentation/devicetree/bindings/{usb/ingenic,jz4770-phy.yaml => 
phy/ingenic,phy-usb.yaml} (89%)

diff --git a/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml 
b/Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml
similarity index 89%
rename from Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml
rename to Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml
index 2d61166ea5cf..9f855984c535 100644
--- a/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
 %YAML 1.2
 ---
-$id: http://devicetree.org/schemas/usb/ingenic,jz4770-phy.yaml#
+$id: http://devicetree.org/schemas/usb/ingenic,phy-usb.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
 title: Ingenic SoCs USB PHY devicetree bindings
@@ -17,9 +17,11 @@ properties:
   compatible:
 enum:
   - ingenic,jz4770-phy
+  - ingenic,jz4775-phy
   - ingenic,jz4780-phy
   - ingenic,x1000-phy
   - ingenic,x1830-phy
+  - ingenic,x2000-phy
 
   reg:
 maxItems: 1
-- 
2.11.0



[PATCH v8 3/3] PHY: Ingenic: Add USB PHY driver using generic PHY framework.

2020-11-07 Thread Zhou Yanjie
Used the generic PHY framework API to create the PHY, this driver
supoorts USB OTG PHY used in JZ4770 SoC, JZ4775 SoC, JZ4780 SoC,
X1000 SoC, X1830 SoC and X2000 SoC.

Tested-by: 周正 (Zhou Zheng) 
Tested-by: H. Nikolaus Schaller 
Co-developed-by: 漆鹏振 (Qi Pengzhen) 
Signed-off-by: 漆鹏振 (Qi Pengzhen) 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
Reviewed-by: Paul Cercueil 
---

Notes:
v1->v2:
Fix bug, ".of_match_table = of_match_ptr(ingenic_usb_phy_of_matches)" is 
wrong
and should be replaced with ".of_match_table = ingenic_usb_phy_of_matches".

v2->v3:
1.Change "depends on (MACH_INGENIC && MIPS) || COMPILE_TEST" to
  "depends on MIPS || COMPILE_TEST".
2.Keep the adjustments of "ingenic_usb_phy_init()" and 
"ingenic_usb_phu_exit()"
  positions in v2 to make them consistent with the order in 
"ingenic_usb_phy_ops",
  keep the adjustments to the positions of "ingenic_usb_phy_of_matches[]" 
in v2
  to keep them consistent with the styles of other USB PHY drivers. And 
remove
  some unnecessary changes to reduce the diff size, from the original 256 
lines
  change to the current 209 lines.

v3->v4:
Only add new generic-PHY driver, without removing the old one. Because the
jz4740-musb driver is not ready to use the generic PHY framework. When the
jz4740-musb driver is modified to use the generic PHY framework, the old
jz4770-phy driver can be "retired".

v4->v5:
1.Add an extra blank line between "devm_of_phy_provider_register" and 
"return".
2.Remove unnecessary "phy_set_drvdata".
3.Add Paul Cercueil's Reviewed-by.

v5->v6:
1.Revert the removal of "phy_set_drvdata" in v5, removing "phy_set_drvdata" 
will
  cause a kernel panic on CI20.
  Reported-by: H. Nikolaus Schaller 
2.Rewrite the macro definitions, replace the original code with 
"FIELD_PREP()"
  and "u32p_replace_bits()" according to Vinod Koul's suggestion.

v6->v7:
1.Remove the stray tab character.
2.Remove unnecessary "platform_set_drvdata".
3.Remove the "dev" field in priv structure, and use &phy->dev instead.

v7->v8:
Add support for Ingenic JZ4775 SoC and X2000 SoC.

 drivers/phy/Kconfig   |   1 +
 drivers/phy/Makefile  |   1 +
 drivers/phy/ingenic/Kconfig   |  12 +
 drivers/phy/ingenic/Makefile  |   2 +
 drivers/phy/ingenic/phy-ingenic-usb.c | 412 ++
 5 files changed, 428 insertions(+)
 create mode 100644 drivers/phy/ingenic/Kconfig
 create mode 100644 drivers/phy/ingenic/Makefile
 create mode 100644 drivers/phy/ingenic/phy-ingenic-usb.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 01b53f86004c..00dabe5fab8a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -66,6 +66,7 @@ source "drivers/phy/broadcom/Kconfig"
 source "drivers/phy/cadence/Kconfig"
 source "drivers/phy/freescale/Kconfig"
 source "drivers/phy/hisilicon/Kconfig"
+source "drivers/phy/ingenic/Kconfig"
 source "drivers/phy/lantiq/Kconfig"
 source "drivers/phy/marvell/Kconfig"
 source "drivers/phy/mediatek/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 6eb2916773c5..32261e164abd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -15,6 +15,7 @@ obj-y += allwinner/   \
   cadence/ \
   freescale/   \
   hisilicon/   \
+  ingenic/ \
   intel/   \
   lantiq/  \
   marvell/ \
diff --git a/drivers/phy/ingenic/Kconfig b/drivers/phy/ingenic/Kconfig
new file mode 100644
index ..912b14e512cb
--- /dev/null
+++ b/drivers/phy/ingenic/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Phy drivers for Ingenic platforms
+#
+config PHY_INGENIC_USB
+   tristate "Ingenic SoCs USB PHY Driver"
+   depends on MIPS || COMPILE_TEST
+   depends on USB_SUPPORT
+   select GENERIC_PHY
+   help
+ This driver provides USB PHY support for the USB controller found
+ on the JZ-series and X-series SoCs from Ingenic.
diff --git a/drivers/phy/ingenic/Makefile b/drivers/phy/ingenic/Makefile
new file mode 100644
index ..65d5ea00fc9d
--- /dev/null
+++ b/drivers/phy/ingenic/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-y  += phy-ingenic-usb.o
diff --git a/drivers/phy/ingenic/phy-ingenic-usb.c 
b/drivers/phy/ingenic/phy-ingenic-usb.c
new file mode 100644
index ..4d1587d82286
--- /dev/null
+++ b/drivers/phy/ingenic/phy-ingenic-usb.c
@@ -0,0 +1,412 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Ingenic SoCs USB PHY driver
+ * Copyright (c) Paul Cercueil 
+ * Copyright (c) 漆鹏振 (Qi Pengzhen) 
+ * Copyright (c

[PATCH v8 0/3] Use the generic PHY framework for Ingenic USB PHY.

2020-11-07 Thread Zhou Yanjie
v3->v4:
Only add new generic-PHY driver, without removing the old one. Because the
jz4740-musb driver is not ready to use the generic PHY framework. When the
jz4740-musb driver is modified to use the generic PHY framework, the old
jz4770-phy driver can be "retired".

v4->v5:
1.Add an extra blank line between "devm_of_phy_provider_register" and "return".
2.Remove unnecessary "phy_set_drvdata".
3.Add Paul Cercueil's Reviewed-by.

v5->v6:
1.Revert the removal of "phy_set_drvdata" in v5, removing "phy_set_drvdata" will
  cause a kernel panic on CI20.
  Reported-by: H. Nikolaus Schaller 
2.Rewrite the macro definitions, replace the original code with "FIELD_PREP()"
  and "u32p_replace_bits()" according to Vinod Koul's suggestion.

v6->v7:
1.Remove the stray tab character.
2.Remove unnecessary "platform_set_drvdata".
3.Remove the "dev" field in priv structure, and use &phy->dev instead.

v7->v8:
Add support for Ingenic JZ4775 SoC and X2000 SoC.

周琰杰 (Zhou Yanjie) (3):
  USB: PHY: JZ4770: Remove unnecessary function calls.
  dt-bindings: USB: Add bindings for Ingenic JZ4775 and X2000.
  PHY: Ingenic: Add USB PHY driver using generic PHY framework.

 .../ingenic,phy-usb.yaml}  |   4 +-
 drivers/phy/Kconfig|   1 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/ingenic/Kconfig|  12 +
 drivers/phy/ingenic/Makefile   |   2 +
 drivers/phy/ingenic/phy-ingenic-usb.c  | 412 +
 drivers/usb/phy/phy-jz4770.c   |   2 +-
 7 files changed, 432 insertions(+), 2 deletions(-)
 rename Documentation/devicetree/bindings/{usb/ingenic,jz4770-phy.yaml => 
phy/ingenic,phy-usb.yaml} (89%)
 create mode 100644 drivers/phy/ingenic/Kconfig
 create mode 100644 drivers/phy/ingenic/Makefile
 create mode 100644 drivers/phy/ingenic/phy-ingenic-usb.c

-- 
2.11.0



Re: [PATCH] powerpc/32s: Use relocation offset when setting early hash table

2020-11-07 Thread Serge Belyshev
Christophe Leroy  writes:

> When calling early_hash_table(), the kernel hasn't been yet
> relocated to its linking address, so data must be addressed
> with relocation offset.
>
> Add relocation offset to write into Hash in early_hash_table().
>
> Reported-by: Erhard Furtner 
> Reported-by: Andreas Schwab 
> Fixes: 69a1593abdbc ("powerpc/32s: Setup the early hash table at all time.")
> Signed-off-by: Christophe Leroy 

Tested-by: Serge Belyshev 


[PATCH] dma-pool: no need to check return value of debugfs_create functions

2020-11-07 Thread Tiezhu Yang
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Signed-off-by: Tiezhu Yang 
---
 kernel/dma/pool.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index d4637f7..5f84e6c 100644
--- a/kernel/dma/pool.c
+++ b/kernel/dma/pool.c
@@ -38,9 +38,6 @@ static void __init dma_atomic_pool_debugfs_init(void)
struct dentry *root;
 
root = debugfs_create_dir("dma_pools", NULL);
-   if (IS_ERR_OR_NULL(root))
-   return;
-
debugfs_create_ulong("pool_size_dma", 0400, root, &pool_size_dma);
debugfs_create_ulong("pool_size_dma32", 0400, root, &pool_size_dma32);
debugfs_create_ulong("pool_size_kernel", 0400, root, &pool_size_kernel);
-- 
2.1.0



[PATCH v1] scsi: isci: Don't use PCI helper functions

2020-11-07 Thread Vaibhav Gupta
PCI helper functions such as pci_enable/disable_device(),
pci_save/restore_state(), pci_set_power_state(), etc. were used by the
legacy framework to perform standard operations related to PCI PM.

This driver is using the generic framework and thus calls for those
functions should be dropped as those tasks are now performed by the PCI
core.

Signed-off-by: Vaibhav Gupta 
---
 drivers/scsi/isci/init.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c
index 93bc9019667f..c452849e7bb4 100644
--- a/drivers/scsi/isci/init.c
+++ b/drivers/scsi/isci/init.c
@@ -715,10 +715,6 @@ static int isci_suspend(struct device *dev)
isci_host_deinit(ihost);
}
 
-   pci_save_state(pdev);
-   pci_disable_device(pdev);
-   pci_set_power_state(pdev, PCI_D3hot);
-
return 0;
 }
 
@@ -726,19 +722,7 @@ static int isci_resume(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
struct isci_host *ihost;
-   int rc, i;
-
-   pci_set_power_state(pdev, PCI_D0);
-   pci_restore_state(pdev);
-
-   rc = pcim_enable_device(pdev);
-   if (rc) {
-   dev_err(&pdev->dev,
-   "enabling device failure after resume(%d)\n", rc);
-   return rc;
-   }
-
-   pci_set_master(pdev);
+   int i;
 
for_each_isci_host(i, ihost, pdev) {
sas_prep_resume_ha(&ihost->sas_ha);
-- 
2.28.0



Re: [PATCH v6 1/2] kunit: Support for Parameterized Testing

2020-11-07 Thread Marco Elver
On Sat, 7 Nov 2020 at 05:58, David Gow  wrote:
> On Sat, Nov 7, 2020 at 3:22 AM Arpitha Raghunandan <98.a...@gmail.com> wrote:
> >
> > Implementation of support for parameterized testing in KUnit.
> > This approach requires the creation of a test case using the
> > KUNIT_CASE_PARAM macro that accepts a generator function as input.
> > This generator function should return the next parameter given the
> > previous parameter in parameterized tests. It also provides
> > a macro to generate common-case generators.
> >
> > Signed-off-by: Arpitha Raghunandan <98.a...@gmail.com>
> > Co-developed-by: Marco Elver 
> > Signed-off-by: Marco Elver 
> > ---
>
> This looks good to me! A couple of minor thoughts about the output
> format below, but I'm quite happy to have this as-is regardless.
>
> Reviewed-by: David Gow 
>
> Cheers,
> -- David
>
> > Changes v5->v6:
> > - Fix alignment to maintain consistency
> > Changes v4->v5:
> > - Update kernel-doc comments.
> > - Use const void* for generator return and prev value types.
> > - Add kernel-doc comment for KUNIT_ARRAY_PARAM.
> > - Rework parameterized test case execution strategy: each parameter is 
> > executed
> >   as if it was its own test case, with its own test initialization and 
> > cleanup
> >   (init and exit are called, etc.). However, we cannot add new test cases 
> > per TAP
> >   protocol once we have already started execution. Instead, log the result 
> > of
> >   each parameter run as a diagnostic comment.
> > Changes v3->v4:
> > - Rename kunit variables
> > - Rename generator function helper macro
> > - Add documentation for generator approach
> > - Display test case name in case of failure along with param index
> > Changes v2->v3:
> > - Modifictaion of generator macro and method
> > Changes v1->v2:
> > - Use of a generator method to access test case parameters
> >
> >  include/kunit/test.h | 36 ++
> >  lib/kunit/test.c | 46 +++-
> >  2 files changed, 69 insertions(+), 13 deletions(-)
> >
> > diff --git a/include/kunit/test.h b/include/kunit/test.h
> > index db1b0ae666c4..16616d3974f9 100644
> > --- a/include/kunit/test.h
> > +++ b/include/kunit/test.h
> > @@ -107,6 +107,7 @@ struct kunit;
[...]
> > -   kunit_suite_for_each_test_case(suite, test_case)
> > -   kunit_run_case_catch_errors(suite, test_case);
> > +   kunit_suite_for_each_test_case(suite, test_case) {
> > +   struct kunit test = { .param_value = NULL, .param_index = 0 
> > };
> > +   bool test_success = true;
> > +
> > +   if (test_case->generate_params)
> > +   test.param_value = test_case->generate_params(NULL);
> > +
> > +   do {
> > +   kunit_run_case_catch_errors(suite, test_case, 
> > &test);
> > +   test_success &= test_case->success;
> > +
> > +   if (test_case->generate_params) {
> > +   kunit_log(KERN_INFO, &test,
> > + KUNIT_SUBTEST_INDENT
> > + "# %s: param-%d %s",
>
> Would it make sense to have this imitate the TAP format a bit more?
> So, have "# [ok|not ok] - [name]" as the format? [name] could be
> something like "[test_case->name]:param-[index]" or similar.
> If we keep it commented out and don't indent it further, it won't
> formally be a nested test (though if we wanted to support those later,
> it'd be easy to add), but I think it would be nicer to be consistent
> here.

The previous attempt [1] at something similar failed because it seems
we'd need to teach kunit-tool new tricks [2], too.
[1] https://lkml.kernel.org/r/20201105195503.ga2399...@elver.google.com
[2] https://lkml.kernel.org/r/20201106123433.ga3563...@elver.google.com

So if we go with a different format, we might need a patch before this
one to make kunit-tool compatible with that type of diagnostic.

Currently I think we have the following proposals for a format:

1. The current "# [test_case->name]: param-[index] [ok|not ok]" --
this works well, because no changes to kunit-tool are required, and it
also picks up the diagnostic context for the case and displays that on
test failure.

2. Your proposed "# [ok|not ok] - [test_case->name]:param-[index]".
As-is, this needs a patch for kunit-tool as well. I just checked, and
if we change it to "# [ok|not ok] - [test_case->name]: param-[index]"
(note the space after ':') it works without changing kunit-tool. ;-)

3. Something like "# [ok|not ok] param-[index] - [test_case->name]",
which I had played with earlier but kunit-tool is definitely not yet
happy with.

So my current preference is (2) with the extra space (no change to
kunit-tool required). WDYT?

> My other suggestion -- albeit one outside the scope of this initial
> version -- would be to allow the "param-%d" name to be overridden
> somehow by a test. For example, the ext4 in

Re: [PATCH v1] scsi: isci: Don't use PCI helper functions

2020-11-07 Thread Vaibhav Gupta
On Sat, Nov 07, 2020 at 03:34:19PM +0530, Vaibhav Gupta wrote:
> PCI helper functions such as pci_enable/disable_device(),
> pci_save/restore_state(), pci_set_power_state(), etc. were used by the
> legacy framework to perform standard operations related to PCI PM.
> 
> This driver is using the generic framework and thus calls for those
> functions should be dropped as those tasks are now performed by the PCI
> core.
> 
> Signed-off-by: Vaibhav Gupta 
> ---
>  drivers/scsi/isci/init.c | 18 +-
>  1 file changed, 1 insertion(+), 17 deletions(-)
> 
> diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c
> index 93bc9019667f..c452849e7bb4 100644
> --- a/drivers/scsi/isci/init.c
> +++ b/drivers/scsi/isci/init.c
> @@ -715,10 +715,6 @@ static int isci_suspend(struct device *dev)
>   isci_host_deinit(ihost);
>   }
>  
> - pci_save_state(pdev);
> - pci_disable_device(pdev);
> - pci_set_power_state(pdev, PCI_D3hot);
> -
>   return 0;
>  }
>  
> @@ -726,19 +722,7 @@ static int isci_resume(struct device *dev)
>  {
>   struct pci_dev *pdev = to_pci_dev(dev);
>   struct isci_host *ihost;
> - int rc, i;
> -
> - pci_set_power_state(pdev, PCI_D0);
> - pci_restore_state(pdev);
> -
> - rc = pcim_enable_device(pdev);
> - if (rc) {
> - dev_err(&pdev->dev,
> - "enabling device failure after resume(%d)\n", rc);
> - return rc;
> - }
> -
> - pci_set_master(pdev);
> + int i;
>  
>   for_each_isci_host(i, ihost, pdev) {
>   sas_prep_resume_ha(&ihost->sas_ha);
> -- 
> 2.28.0
> 
The patch is compile-tested only.

--Vaibhav


[tip: x86/urgent] x86/platform/uv: Recognize UV5 hubless system identifier

2020-11-07 Thread tip-bot2 for Mike Travis
The following commit has been merged into the x86/urgent branch of tip:

Commit-ID: 801284f9737883a2b2639bd494455a72c82fdedf
Gitweb:
https://git.kernel.org/tip/801284f9737883a2b2639bd494455a72c82fdedf
Author:Mike Travis 
AuthorDate:Thu, 05 Nov 2020 16:27:41 -06:00
Committer: Thomas Gleixner 
CommitterDate: Sat, 07 Nov 2020 11:17:39 +01:00

x86/platform/uv: Recognize UV5 hubless system identifier

Testing shows a problem in that UV5 hubless systems were not being
recognized.  Add them to the list of OEM IDs checked.

Fixes: 6c7794423a998 ("Add UV5 direct references")
Signed-off-by: Mike Travis 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20201105222741.157029-4-mike.tra...@hpe.com


---
 arch/x86/kernel/apic/x2apic_uv_x.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 0f848d6..3115caa 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -389,13 +389,20 @@ static int __init uv_set_system_type(char *_oem_id, char 
*_oem_table_id)
/* (Not hubless), not a UV */
return 0;
 
+   /* Is UV hubless system */
+   uv_hubless_system = 0x01;
+
+   /* UV5 Hubless */
+   if (strncmp(uv_archtype, "NSGI5", 5) == 0)
+   uv_hubless_system |= 0x20;
+
/* UV4 Hubless: CH */
-   if (strncmp(uv_archtype, "NSGI4", 5) == 0)
-   uv_hubless_system = 0x11;
+   else if (strncmp(uv_archtype, "NSGI4", 5) == 0)
+   uv_hubless_system |= 0x10;
 
/* UV3 Hubless: UV300/MC990X w/o hub */
else
-   uv_hubless_system = 0x9;
+   uv_hubless_system |= 0x8;
 
/* Copy APIC type */
uv_stringify(sizeof(oem_table_id), oem_table_id, _oem_table_id);


[tip: x86/urgent] x86/platform/uv: Fix missing OEM_TABLE_ID

2020-11-07 Thread tip-bot2 for Mike Travis
The following commit has been merged into the x86/urgent branch of tip:

Commit-ID: 1aec69ae56be28b5fd3c9daead5f3840c30153c8
Gitweb:
https://git.kernel.org/tip/1aec69ae56be28b5fd3c9daead5f3840c30153c8
Author:Mike Travis 
AuthorDate:Thu, 05 Nov 2020 16:27:39 -06:00
Committer: Thomas Gleixner 
CommitterDate: Sat, 07 Nov 2020 11:17:39 +01:00

x86/platform/uv: Fix missing OEM_TABLE_ID

Testing shows a problem in that the OEM_TABLE_ID was missing for
hubless systems.  This is used to determine the APIC type (legacy or
extended).  Add the OEM_TABLE_ID to the early hubless processing.

Fixes: 1e61f5a95f191 ("Add and decode Arch Type in UVsystab")
Signed-off-by: Mike Travis 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20201105222741.157029-2-mike.tra...@hpe.com
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 714233c..a579479 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -366,7 +366,7 @@ static int __init early_get_arch_type(void)
return ret;
 }
 
-static int __init uv_set_system_type(char *_oem_id)
+static int __init uv_set_system_type(char *_oem_id, char *_oem_table_id)
 {
/* Save OEM_ID passed from ACPI MADT */
uv_stringify(sizeof(oem_id), oem_id, _oem_id);
@@ -394,6 +394,9 @@ static int __init uv_set_system_type(char *_oem_id)
else
uv_hubless_system = 0x9;
 
+   /* Copy APIC type */
+   uv_stringify(sizeof(oem_table_id), oem_table_id, _oem_table_id);
+
pr_info("UV: OEM IDs %s/%s, SystemType %d, HUBLESS ID %x\n",
oem_id, oem_table_id, uv_system_type, 
uv_hubless_system);
return 0;
@@ -456,7 +459,7 @@ static int __init uv_acpi_madt_oem_check(char *_oem_id, 
char *_oem_table_id)
uv_cpu_info->p_uv_hub_info = &uv_hub_info_node0;
 
/* If not UV, return. */
-   if (likely(uv_set_system_type(_oem_id) == 0))
+   if (uv_set_system_type(_oem_id, _oem_table_id) == 0)
return 0;
 
/* Save and Decode OEM Table ID */


[tip: x86/urgent] x86/platform/uv: Remove spaces from OEM IDs

2020-11-07 Thread tip-bot2 for Mike Travis
The following commit has been merged into the x86/urgent branch of tip:

Commit-ID: 1aee505e0171fc38fd5ed70c7f0dcbb7398c759f
Gitweb:
https://git.kernel.org/tip/1aee505e0171fc38fd5ed70c7f0dcbb7398c759f
Author:Mike Travis 
AuthorDate:Thu, 05 Nov 2020 16:27:40 -06:00
Committer: Thomas Gleixner 
CommitterDate: Sat, 07 Nov 2020 11:17:39 +01:00

x86/platform/uv: Remove spaces from OEM IDs

Testing shows that trailing spaces caused problems with the OEM_ID and
the OEM_TABLE_ID.  One being that the OEM_ID would not string compare
correctly.  Another the OEM_ID and OEM_TABLE_ID would be concatenated
in the printout.  Remove any trailing spaces.

Fixes: 1e61f5a95f191 ("Add and decode Arch Type in UVsystab")
Signed-off-by: Mike Travis 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20201105222741.157029-3-mike.tra...@hpe.com


---
 arch/x86/kernel/apic/x2apic_uv_x.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index a579479..0f848d6 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -290,6 +290,9 @@ static void __init uv_stringify(int len, char *to, char 
*from)
 {
/* Relies on 'to' being NULL chars so result will be NULL terminated */
strncpy(to, from, len-1);
+
+   /* Trim trailing spaces */
+   (void)strim(to);
 }
 
 /* Find UV arch type entry in UVsystab */


Re: [PATCH 2/2] arm: lib: xor-neon: disable clang vectorization

2020-11-07 Thread Russell King - ARM Linux admin
On Fri, Nov 06, 2020 at 07:14:36AM +0200, Adrian Ratiu wrote:
> diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c
> index e1e76186ec23..84c91c48dfa2 100644
> --- a/arch/arm/lib/xor-neon.c
> +++ b/arch/arm/lib/xor-neon.c
> @@ -18,6 +18,10 @@ MODULE_LICENSE("GPL");
>   * Pull in the reference implementations while instructing GCC (through
>   * -ftree-vectorize) to attempt to exploit implicit parallelism and emit
>   * NEON instructions.
> +

Please tidy this up before submission; we normally continue the "*" for
blank lines in comment blocks. Thanks.

> + * On Clang the loop vectorizer is enabled by default, but due to a bug
> + * (https://bugs.llvm.org/show_bug.cgi?id=40976) vectorization is broke
> + * so xor-neon is disabled in favor of the default reg implementations.
>   */
>  #ifdef CONFIG_CC_IS_GCC
>  #pragma GCC optimize "tree-vectorize"
> -- 
> 2.29.0
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!


Re: [PATCH] netfilter: conntrack: fix -Wformat

2020-11-07 Thread Joe Perches
On Fri, 2020-11-06 at 23:55 -0800, Nick Desaulniers wrote:
> Clang is more aggressive about -Wformat warnings when the format flag
> specifies a type smaller than the parameter. Fixes 8 instances of:
> 
> warning: format specifies type 'unsigned short' but the argument has
> type 'int' [-Wformat]

Likely clang's -Wformat message is still bogus.
Wasn't that going to be fixed?

Integer promotions are already done on these types to int anyway.
Didn't we have this discussion last year?

https://lore.kernel.org/lkml/CAKwvOd=mqzj2pAZEUsW-M_62xn4pijpCJmP=b1h_-web0ne...@mail.gmail.com/
https://lore.kernel.org/lkml/CAHk-=wgoxnmsj8GEVFJSvTwdnWm8wVJthefNk2n6+4TC=20...@mail.gmail.com/
https://lore.kernel.org/lkml/a68114afb134b8633905f5a25ae7c4e6799ce8f1.ca...@perches.com/

Look at commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use
of unnecessary %h[xudi] and %hh[xudi]")

The "h" and "hh" things should never be used. The only reason for them
being used if if you have an "int", but you want to print it out as a
"char" (and honestly, that is a really bad reason, you'd be better off
just using a proper cast to make the code more obvious).

So if what you have a "char" (or unsigned char) you should always just
print it out as an "int", knowing that the compiler already did the
proper type conversion.

> diff --git a/net/netfilter/nf_conntrack_standalone.c 
> b/net/netfilter/nf_conntrack_standalone.c
[]
> @@ -50,38 +50,38 @@ print_tuple(struct seq_file *s, const struct 
> nf_conntrack_tuple *tuple,
>  
> 
>   switch (l4proto->l4proto) {
>   case IPPROTO_ICMP:
> - seq_printf(s, "type=%u code=%u id=%u ",
> + seq_printf(s, "type=%u code=%u id=%hu ",

etc...




Re: [PATCH] arm: mm: remove duplicate include

2020-11-07 Thread Mike Rapoport
On Sat, Nov 07, 2020 at 05:15:50PM +0800, Wang Qing wrote:
> Remove duplicate header which is included twice.
> 
> Signed-off-by: Wang Qing 

Reviewed-by: Mike Rapoport 

> ---
>  arch/arm/mm/mmu.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index ab69250..4963e1c
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -33,7 +33,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include "fault.h"
>  #include "mm.h"
> -- 
> 2.7.4
> 

-- 
Sincerely yours,
Mike.


Re: [PATCH] arm: mach-sa1100: remove duplicate include

2020-11-07 Thread Mike Rapoport
On Sat, Nov 07, 2020 at 05:22:26PM +0800, Wang Qing wrote:
> Remove duplicate header which is included twice.
> 
> Signed-off-by: Wang Qing 

Reviewed-by: Mike Rapoport 

> ---
>  arch/arm/mach-sa1100/hackkit.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/mach-sa1100/hackkit.c b/arch/arm/mach-sa1100/hackkit.c
> index 3085f1c..3fe34ee
> --- a/arch/arm/mach-sa1100/hackkit.c
> +++ b/arch/arm/mach-sa1100/hackkit.c
> @@ -18,7 +18,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> -- 
> 2.7.4
> 

-- 
Sincerely yours,
Mike.


[PATCH -next] irq-chip/gic-v3-its: Fixed an issue where the ITS executes the residual commands in the queue again when the ITS wakes up from sleep mode.

2020-11-07 Thread Xu Qiang
On my platform, ITS_FLAGS_SAVE_SUSPEND_STATE is not set,thus do nothing
in its suspend and resuse function.On the other hand,firmware stores
GITS_CTRL,GITS_CBASER,GITS_CWRITER and GITS_BASER in the suspend,
and restores these registers in the resume. As a result, the ITS executes
the residual commands in the queue.

Memory corruption may occur in the following scenarios:

The kernel sends three commands in the following sequence:
1.mapd(deviceA, ITT_addr1, valid:1)
2.mapti(deviceA):ITS write ITT_addr1 memory;
3.mapd(deviceA, ITT_addr1, valid:0) and kfree(ITT_addr1);
4.mapd(deviceA, ITT_addr2, valid:1);
5.mapti(deviceA):ITS write ITT_addr2 memory;

To solve this problem,dropping the checks for ITS_FLAGS_SAVE_SUSPEND_STATE.

Signed-off-by: Xu Qiang 
---
 drivers/irqchip/irq-gic-v3-its.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 0fec31931e11..06f2c1c252b9 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -42,7 +42,6 @@
 #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING  (1ULL << 0)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_22375  (1ULL << 1)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_23144  (1ULL << 2)
-#define ITS_FLAGS_SAVE_SUSPEND_STATE   (1ULL << 3)
 
 #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
 #define RDIST_FLAGS_RD_TABLES_PREALLOCATED (1 << 1)
@@ -4741,9 +4740,6 @@ static int its_save_disable(void)
list_for_each_entry(its, &its_nodes, entry) {
void __iomem *base;
 
-   if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE))
-   continue;
-
base = its->base;
its->ctlr_save = readl_relaxed(base + GITS_CTLR);
err = its_force_quiescent(base);
@@ -4762,9 +4758,6 @@ static int its_save_disable(void)
list_for_each_entry_continue_reverse(its, &its_nodes, entry) {
void __iomem *base;
 
-   if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE))
-   continue;
-
base = its->base;
writel_relaxed(its->ctlr_save, base + GITS_CTLR);
}
@@ -4784,9 +4777,6 @@ static void its_restore_enable(void)
void __iomem *base;
int i;
 
-   if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE))
-   continue;
-
base = its->base;
 
/*
@@ -5074,9 +5064,6 @@ static int __init its_probe_one(struct resource *res,
ctlr |= GITS_CTLR_ImDe;
writel_relaxed(ctlr, its->base + GITS_CTLR);
 
-   if (GITS_TYPER_HCC(typer))
-   its->flags |= ITS_FLAGS_SAVE_SUSPEND_STATE;
-
err = its_init_domain(handle, its);
if (err)
goto out_free_tables;
-- 
2.25.0



Re: [PATCH] tool: selftests: fix spelling typo of 'writting'

2020-11-07 Thread Mike Rapoport
On Sat, Nov 07, 2020 at 05:19:35PM +0800, Wang Qing wrote:
> writting -> writing
> 
> Signed-off-by: Wang Qing 

Reviewed-by: Mike Rapoport 

> ---
>  tools/testing/selftests/vm/userfaultfd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/testing/selftests/vm/userfaultfd.c 
> b/tools/testing/selftests/vm/userfaultfd.c
> index 9b0912a..9132fae7
> --- a/tools/testing/selftests/vm/userfaultfd.c
> +++ b/tools/testing/selftests/vm/userfaultfd.c
> @@ -894,7 +894,7 @@ static int faulting_process(int signal_test)
>   count_verify[nr]);
>   }
>   /*
> -  * Trigger write protection if there is by writting
> +  * Trigger write protection if there is by writing
>* the same value back.
>*/
>   *area_count(area_dst, nr) = count;
> @@ -922,7 +922,7 @@ static int faulting_process(int signal_test)
>   count_verify[nr]); exit(1);
>   }
>   /*
> -  * Trigger write protection if there is by writting
> +  * Trigger write protection if there is by writing
>* the same value back.
>*/
>   *area_count(area_dst, nr) = count;
> -- 
> 2.7.4
> 

-- 
Sincerely yours,
Mike.


RE: [PATCH] libbpf: Remove unnecessary conversion to bool

2020-11-07 Thread David Laight
From: Joe Perches
> Sent: 06 November 2020 21:50
> 
> On Fri, 2020-11-06 at 13:32 -0800, Andrii Nakryiko wrote:
> > On Thu, Nov 5, 2020 at 11:12 PM  wrote:
> > > Fix following warning from coccinelle:
> > > ./tools/lib/bpf/libbpf.c:1478:43-48: WARNING: conversion to bool not 
> > > needed here
> []
> > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> []
> > > @@ -1475,7 +1475,7 @@ static int set_kcfg_value_tri(struct extern_desc 
> > > *ext, void *ext_val,
> > > ext->name, value);
> > > return -EINVAL;
> > > }
> > > -   *(bool *)ext_val = value == 'y' ? true : false;
> > > +   *(bool *)ext_val = value == 'y';
> >
> > I actually did this intentionally. x = y == z; pattern looked too
> > obscure to my taste, tbh.
> 
> It's certainly a question of taste and obviously there is nothing
> wrong with yours.
> 
> Maybe adding parentheses makes the below look less obscure to you?
> 
>   x = (y == z);

That just leads to people thinking conditionals need to be in parentheses
and then getting the priorities for ?: all wrong as in:
x = a + (b == c) ? d : e;

It would (probably) be better to make 'ext_val' be a union type
(probably a 'pointer to a union' rather than a union of pointers)
so that all the casts go away.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)



Re: [PATCH] firmware: fix spelling typo of 'wtih'

2020-11-07 Thread Nicolas Saenz Julienne
On Sat, 2020-11-07 at 16:19 +0800, Wang Qing wrote:
> wtih -> with
> 
> Signed-off-by: Wang Qing 
> ---

Acked-by: Nicolas Saenz Julienne 

Thanks!

>  drivers/firmware/raspberrypi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> index 2371d08..30259dc
> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
> - * Defines interfaces for interacting wtih the Raspberry Pi firmware's
> + * Defines interfaces for interacting with the Raspberry Pi firmware's
>   * property channel.
>   *
>   * Copyright © 2015 Broadcom



signature.asc
Description: This is a digitally signed message part


Re: [PATCH] MIPS: reserve the memblock right after the kernel

2020-11-07 Thread Thomas Bogendoerfer
On Fri, Nov 06, 2020 at 03:10:01PM +0100, Alexander A Sverdlin wrote:
> From: Alexander Sverdlin 
> 
> Linux doesn't own the memory immediately after the kernel image. On Octeon
> bootloader places a shared structure right close after the kernel _end,
> refer to "struct cvmx_bootinfo *octeon_bootinfo" in cavium-octeon/setup.c.
> 
> If check_kernel_sections_mem() rounds the PFNs up, first memblock_alloc()
> inside early_init_dt_alloc_memory_arch() <= device_tree_init() returns
> memory block overlapping with the above octeon_bootinfo structure, which
> is being overwritten afterwards.

as this special for Octeon how about added the memblock_reserve
in octen specific code ?

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]


Re: [PATCH v3 0/4] drm/bridge: ti-sn65dsi86: Support EDID reading

2020-11-07 Thread Sam Ravnborg
Hi Stephen

On Mon, Nov 02, 2020 at 10:11:40AM -0800, Stephen Boyd wrote:
> This patch series cleans up the DDC code a little bit so that
> it is more efficient time wise and supports grabbing the EDID
> of the eDP panel over the aux channel. I timed this on a board
> I have on my desk and it takes about 20ms to grab the EDID out
> of the panel and make sure it is valid.
> 
> The first two patches seem less controversial so I stuck them at
> the beginning. The third patch does the EDID reading and caches
> it so we don't have to keep grabbing it over and over again. And
> finally the last patch updates the reply field so that short
> reads and nacks over the channel are reflected properly instead of
> treating them as some sort of error that can't be discerned.
> 
> Stephen Boyd (4):
>   drm/bridge: ti-sn65dsi86: Combine register accesses in
> ti_sn_aux_transfer()
>   drm/bridge: ti-sn65dsi86: Make polling a busy loop
>   drm/bridge: ti-sn65dsi86: Read EDID blob over DDC
>   drm/bridge: ti-sn65dsi86: Update reply on aux failures

All applied to drm-misc-next, thanks,

Sam


Re: [PATCH] Kbuild: enable -Wfallthrough for clang

2020-11-07 Thread Miguel Ojeda
On Sat, Nov 7, 2020 at 8:08 AM Nick Desaulniers  wrote:
>
> Partial revert of commit e2079e93f562 ("kbuild: Do not enable
> -Wimplicit-fallthrough for clang for now")

Wait, it says partial revert because it is one, but doing it this way
does not enable the option back for GCC (and Clang).

Shouldn't it be a full revert?

Cheers,
Miguel


Re: [PATCH net-next 08/11] ath9k: work around false-positive gcc warning

2020-11-07 Thread Kalle Valo
Johannes Berg  writes:

> On Mon, 2020-11-02 at 18:26 +0200, Kalle Valo wrote:
>> Arnd Bergmann  writes:
>> 
>> > From: Arnd Bergmann 
>> > 
>> > gcc-10 shows a false-positive warning with CONFIG_KASAN:
>> > 
>> > drivers/net/wireless/ath/ath9k/dynack.c: In function 
>> > 'ath_dynack_sample_tx_ts':
>> > include/linux/etherdevice.h:290:14: warning: writing 4 bytes into a region 
>> > of size 0 [-Wstringop-overflow=]
>> >   290 |  *(u32 *)dst = *(const u32 *)src;
>> >   |  ^~~
>> > 
>> > Until gcc is fixed, work around this by using memcpy() in place
>> > of ether_addr_copy(). Hopefully gcc-11 will not have this problem.
>> > 
>> > Link: https://godbolt.org/z/sab1MK
>> > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490
>> > Signed-off-by: Arnd Bergmann 
>> > ---
>> >  drivers/net/wireless/ath/ath9k/dynack.c | 6 ++
>> >  1 file changed, 6 insertions(+)
>> > 
>> > diff --git a/drivers/net/wireless/ath/ath9k/dynack.c 
>> > b/drivers/net/wireless/ath/ath9k/dynack.c
>> > index fbeb4a739d32..e4eb96b26ca4 100644
>> > --- a/drivers/net/wireless/ath/ath9k/dynack.c
>> > +++ b/drivers/net/wireless/ath/ath9k/dynack.c
>> > @@ -247,8 +247,14 @@ void ath_dynack_sample_tx_ts(struct ath_hw *ah, 
>> > struct sk_buff *skb,
>> >ridx = ts->ts_rateindex;
>> >  
>> >da->st_rbf.ts[da->st_rbf.t_rb].tstamp = ts->ts_tstamp;
>> > +#if defined(CONFIG_KASAN) && (CONFIG_GCC_VERSION >= 10) && 
>> > (CONFIG_GCC_VERSION < 11)
>> > +  /* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490 */
>> > +  memcpy(da->st_rbf.addr[da->st_rbf.t_rb].h_dest, hdr->addr1, ETH_ALEN);
>> > +  memcpy(da->st_rbf.addr[da->st_rbf.t_rb].h_src, hdr->addr2, ETH_ALEN);
>> > +#else
>> >ether_addr_copy(da->st_rbf.addr[da->st_rbf.t_rb].h_dest, hdr->addr1);
>> >ether_addr_copy(da->st_rbf.addr[da->st_rbf.t_rb].h_src, hdr->addr2);
>> > +#endif
>> 
>> Isn't there a better way to handle this? I really would not want
>> checking for GCC versions become a common approach in drivers.
>> 
>> I even think that using memcpy() always is better than the ugly ifdef.
>
> If you put memcpy() always somebody will surely go and clean it up to
> use ether_addr_copy() soon ...

I can always add a comment and hope that the cleanup people read
comments :) I did that now in the pending branch:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=25cfc077bd7a798d1aa527ad2aa9932bb3284376

Does that look ok? I prefer that over the ifdef.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


Re: [PATCH 2/2] ath11k: Handle errors if peer creation fails

2020-11-07 Thread Kalle Valo
Alex Dewar  writes:

> On Tue, Oct 06, 2020 at 10:26:28AM +0300, Kalle Valo wrote:
>> Alex Dewar  writes:
>> 
>> > ath11k_peer_create() is called without its return value being checked,
>> > meaning errors will be unhandled. Add missing check and, as the mutex is
>> > unconditionally unlocked on leaving this function, simplify the exit
>> > path.
>> >
>> > Addresses-Coverity-ID: 1497531 ("Code maintainability issues")
>> > Fixes: 701e48a43e15 ("ath11k: add packet log support for QCA6390")
>> > Signed-off-by: Alex Dewar 
>> > ---
>> >  drivers/net/wireless/ath/ath11k/mac.c | 21 +
>> >  1 file changed, 9 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/drivers/net/wireless/ath/ath11k/mac.c 
>> > b/drivers/net/wireless/ath/ath11k/mac.c
>> > index 7f8dd47d2333..58db1b57b941 100644
>> > --- a/drivers/net/wireless/ath/ath11k/mac.c
>> > +++ b/drivers/net/wireless/ath/ath11k/mac.c
>> > @@ -5211,7 +5211,7 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw 
>> > *hw,
>> >struct ath11k *ar = hw->priv;
>> >struct ath11k_base *ab = ar->ab;
>> >struct ath11k_vif *arvif = (void *)vif->drv_priv;
>> > -  int ret;
>> > +  int ret = 0;
>> 
>> I prefer not to initialise the ret variable.
>> 
>> >arvif->is_started = true;
>> >  
>> >/* TODO: Setup ps and cts/rts protection */
>> >  
>> > -  mutex_unlock(&ar->conf_mutex);
>> > -
>> > -  return 0;
>> > -
>> > -err:
>> > +unlock:
>> >mutex_unlock(&ar->conf_mutex);
>> >  
>> >return ret;
>> 
>> So in the pending branch I changed this to:
>> 
>>  ret = 0;
>> 
>> out:
>>  mutex_unlock(&ar->conf_mutex);
>> 
>>  return ret;
>> 
>> Please check.
>
> I'm afraid you've introduced a bug ;). The body of the first if-statement
> in the function doesn't set ret because no error has occurred. So now
> it'll jump to the label and the function will return ret uninitialized.

Ouch, so I did. Good catch! I would have hoped that GCC warns about that
but it didn't.

I fixed the bug and added also a warning messages if peer_create()
fails:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=e3e7b8072fa6bb0928b9066cf76e19e6bd2ec663

Does this look better now? :)

> With the gcc extension, ret will be initialised to zero anyway, so we're
> not saving anything by explicitly assigning to ret later in the
> function.

I prefer not to initialise ret in the beginning of the function and I
try to maintain that style in ath11k. I think it's more readable that
the error value is assigned just before the goto.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


[PATCH] panic: don't dump stack twice on warn

2020-11-07 Thread Christophe Leroy
Before commit 3f388f28639f ("panic: dump registers on panic_on_warn"),
__warn() was calling show_regs() when regs was not NULL, and
show_stack() otherwise.

After that commit, show_stack() is called regardless of whether
show_regs() has been called or not, leading to duplicated Call Trace:

[7.112617] [ cut here ]
[7.117041] WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/nohash/8xx.c:186 
mmu_mark_initmem_nx+0x24/0x94
[7.126021] CPU: 0 PID: 1 Comm: swapper Not tainted 
5.10.0-rc2-s3k-dev-01375-gf46ec0d3ecbd-dirty #4092
[7.135202] NIP:  c00128b4 LR: c0010228 CTR: 
[7.140205] REGS: c9023e40 TRAP: 0700   Not tainted  
(5.10.0-rc2-s3k-dev-01375-gf46ec0d3ecbd-dirty)
[7.149131] MSR:  00029032   CR: 24000424  XER: 
[7.155760]
[7.155760] GPR00: c0010228 c9023ef8 c210 0074c000   
c2151000 c07b3880
[7.155760] GPR08: ff000900 0074c000 c800 c33b53a8 24000822  
c0003a20 
[7.155760] GPR16:       
 
[7.155760] GPR24:       
 0080
[7.191092] NIP [c00128b4] mmu_mark_initmem_nx+0x24/0x94
[7.196333] LR [c0010228] free_initmem+0x20/0x58
[7.200855] Call Trace:
[7.203319] [c9023f18] [c0010228] free_initmem+0x20/0x58
[7.208564] [c9023f28] [c0003a3c] kernel_init+0x1c/0x114
[7.213813] [c9023f38] [c000f184] ret_from_kernel_thread+0x14/0x1c
[7.219869] Instruction dump:
[7.222805] 7d291850 7d234b78 4e800020 9421ffe0 7c0802a6 bfc10018 3fe0c060 
3bff
[7.230462] 3fff4080 3bff 90010024 57ff0010 <0fe0> 392001cd 7c3e0b78 
953e0008
[7.238327] CPU: 0 PID: 1 Comm: swapper Not tainted 
5.10.0-rc2-s3k-dev-01375-gf46ec0d3ecbd-dirty #4092
[7.247500] Call Trace:
[7.249977] [c9023dc0] [c001e070] __warn+0x8c/0xd8 (unreliable)
[7.255815] [c9023de0] [c05e0e5c] report_bug+0x11c/0x154
[7.261085] [c9023e10] [c0009ea4] program_check_exception+0x1dc/0x6e0
[7.267430] [c9023e30] [c000f43c] ret_from_except_full+0x0/0x4
[7.273238] --- interrupt: 700 at mmu_mark_initmem_nx+0x24/0x94
[7.273238] LR = free_initmem+0x20/0x58
[7.283155] [c9023ef8] [] 0x0 (unreliable)
[7.287913] [c9023f18] [c0010228] free_initmem+0x20/0x58
[7.293160] [c9023f28] [c0003a3c] kernel_init+0x1c/0x114
[7.298410] [c9023f38] [c000f184] ret_from_kernel_thread+0x14/0x1c
[7.304479] ---[ end trace 31702cd2a9570752 ]---

Only call show_stack() when regs is NULL.

Fixes: 3f388f28639f ("panic: dump registers on panic_on_warn")
Cc: Alexey Kardashevskiy 
Signed-off-by: Christophe Leroy 
---
 kernel/panic.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/panic.c b/kernel/panic.c
index 396142ee43fd..332736a72a58 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -605,7 +605,8 @@ void __warn(const char *file, int line, void *caller, 
unsigned taint,
panic("panic_on_warn set ...\n");
}
 
-   dump_stack();
+   if (!regs)
+   dump_stack();
 
print_irqtrace_events(current);
 
-- 
2.25.0



Re: [PATCH][next] ray_cs: Use fallthrough pseudo-keyword

2020-11-07 Thread Kalle Valo
"Gustavo A. R. Silva"  wrote:

> In order to enable -Wimplicit-fallthrough for Clang[1], replace the
> existing /* fall through */ comments with the new pseudo-keyword
> macro fallthrough[2].
> 
> [1] https://git.kernel.org/linus/e2079e93f562c7f7a030eb7642017ee5eabaaa10
> [2] 
> https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
> 
> Signed-off-by: Gustavo A. R. Silva 

Patch applied to wireless-drivers-next.git, thanks.

256ff2ef6c14 ray_cs: Use fallthrough pseudo-keyword

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201008220422.GA6926@embeddedor/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



Re: [PATCH][next] wlcore: Use fallthrough pseudo-keyword

2020-11-07 Thread Kalle Valo
"Gustavo A. R. Silva"  wrote:

> In order to enable -Wimplicit-fallthrough for Clang[1], replace the
> existing /* fall-through */ comments with the new pseudo-keyword
> macro fallthrough[2].
> 
> [1] https://git.kernel.org/linus/e2079e93f562c7f7a030eb7642017ee5eabaaa10
> [2] 
> https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
> 
> Signed-off-by: Gustavo A. R. Silva 

Patch applied to wireless-drivers-next.git, thanks.

a821e3858e4d wlcore: Use fallthrough pseudo-keyword

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201008220905.GA8040@embeddedor/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



Re: [PATCH v2] wireless: remove unneeded break

2020-11-07 Thread Kalle Valo
t...@redhat.com wrote:

> From: Tom Rix 
> 
> A break is not needed if it is preceded by a return
> 
> Signed-off-by: Tom Rix 

Patch applied to wireless-drivers-next.git, thanks.

3287953b0399 wireless: remove unneeded break

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201020125841.26791-1-t...@redhat.com/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



Re: [PATCH net-next 08/11] ath9k: work around false-positive gcc warning

2020-11-07 Thread Arnd Bergmann
On Sat, Nov 7, 2020 at 12:21 PM Kalle Valo  wrote:
> Johannes Berg  writes:
> > On Mon, 2020-11-02 at 18:26 +0200, Kalle Valo wrote:
> >> Arnd Bergmann  writes:
> >> Isn't there a better way to handle this? I really would not want
> >> checking for GCC versions become a common approach in drivers.
> >>
> >> I even think that using memcpy() always is better than the ugly ifdef.
> >
> > If you put memcpy() always somebody will surely go and clean it up to
> > use ether_addr_copy() soon ...
>
> I can always add a comment and hope that the cleanup people read
> comments :) I did that now in the pending branch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=25cfc077bd7a798d1aa527ad2aa9932bb3284376
>
> Does that look ok? I prefer that over the ifdef.

Fine with me. My original reason for the compiler version check
was that we can eventually restore the previous version once the
compiler is fixed for long enough that all broken compilers are
too old to build the kernel, in maybe six years from now at the
current rate of deprecating old compilers.

   Arnd


Re: [PATCH net-next 02/11] net: hostap: fix function cast warning

2020-11-07 Thread Kalle Valo
Arnd Bergmann  wrote:

> From: Arnd Bergmann 
> 
> gcc -Wextra complains about the function type cast:
> 
> drivers/net/wireless/intersil/hostap/hostap_hw.c:3173:48: warning: cast 
> between incompatible function types from ‘void (*)(struct tasklet_struct *)’ 
> to ‘void (*)(long unsigned int)’ [-Wcast-function-type]
> 
> Avoid this by just using the regular tasklet_setup() function instead
> of the incorrect homegrown version.
> 
> Fixes: 7433c9690318 ("intersil: convert tasklets to use new tasklet_setup() 
> API")
> Signed-off-by: Arnd Bergmann 

3 patches applied to wireless-drivers-next.git, thanks.

9fdd02aa5988 net: hostap: fix function cast warning
ef41937631bf rtlwifi: fix -Wpointer-sign warning
6ac654697301 rtw88: remove extraneous 'const' qualifier

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201026213040.3889546-2-a...@kernel.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



Re: [PATCH] rtl8192ce: avoid accessing the data mapped to streaming DMA

2020-11-07 Thread Kalle Valo
Jia-Ju Bai  wrote:

> In rtl92ce_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on
> line 530:
>   dma_addr_t mapping = dma_map_single(..., skb->data, ...);
> 
> On line 533, skb->data is assigned to hdr after cast:
>   struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
> 
> Then hdr->frame_control is accessed on line 534:
>   __le16 fc = hdr->frame_control;
> 
> This DMA access may cause data inconsistency between CPU and hardwre.
> 
> To fix this bug, hdr->frame_control is accessed before the DMA mapping.
> 
> Signed-off-by: Jia-Ju Bai 

Like Ping said, use "rtlwifi:" prefix and have all rtlwifi patches in
the same patchset.

4 patches set to Changes Requested.

11843533 rtl8192ce: avoid accessing the data mapped to streaming DMA
11843541 rtl8192de: avoid accessing the data mapped to streaming DMA
11843553 rtl8723ae: avoid accessing the data mapped to streaming DMA
11843557 rtl8188ee: avoid accessing the data mapped to streaming DMA

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201019030931.4796-1-baijiaju1...@gmail.com/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



[PATCH 0/2] Add missing nodes and refresh defconfig for Ingenic SoCs based boards.

2020-11-07 Thread Zhou Yanjie
1.Add missing nodes for Ingenic SoCs and Ingenic SoCs based boards.
2.Refresh defconfig for Ingenic SoCs based boards.

周琰杰 (Zhou Yanjie) (2):
  MIPS: Ingenic: Add missing nodes for Ingenic SoCs and boards.
  MIPS: Ingenic: Refresh defconfig for Ingenic SoCs based boards.

 arch/mips/boot/dts/ingenic/ci20.dts   | 16 +
 arch/mips/boot/dts/ingenic/cu1000-neo.dts | 60 +++
 arch/mips/boot/dts/ingenic/cu1830-neo.dts | 60 +++
 arch/mips/boot/dts/ingenic/jz4780.dtsi| 41 +++--
 arch/mips/boot/dts/ingenic/x1000.dtsi | 52 ++-
 arch/mips/boot/dts/ingenic/x1830.dtsi | 54 +++-
 arch/mips/configs/ci20_defconfig  | 14 ++--
 arch/mips/configs/cu1000-neo_defconfig| 28 ---
 arch/mips/configs/cu1830-neo_defconfig| 32 +
 9 files changed, 327 insertions(+), 30 deletions(-)

-- 
2.11.0



[PATCH 2/2] MIPS: Ingenic: Refresh defconfig for Ingenic SoCs based boards.

2020-11-07 Thread Zhou Yanjie
1.Refresh defconfig of CI20 to support OTG and RNG.
2.Refresh defconfig of CU1000-Neo to support OTG/RNG/OST/SC16IS752.
3.Refresh defconfig of CU1830-Neo to support OTG/DTRNG/OST/SC16IS752.

Tested-by: 周正 (Zhou Zheng) 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
---
 arch/mips/configs/ci20_defconfig   | 14 --
 arch/mips/configs/cu1000-neo_defconfig | 28 +++-
 arch/mips/configs/cu1830-neo_defconfig | 32 +---
 3 files changed, 60 insertions(+), 14 deletions(-)

diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index 052c5ad0f2b1..80fbe57d68d4 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -49,6 +49,8 @@ CONFIG_MTD_RAW_NAND=y
 CONFIG_MTD_NAND_JZ4780=y
 CONFIG_MTD_UBI=y
 CONFIG_MTD_UBI_FASTMAP=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_VENDOR_ARC is not set
 # CONFIG_NET_VENDOR_BROADCOM is not set
@@ -77,7 +79,6 @@ CONFIG_SERIAL_8250_NR_UARTS=5
 CONFIG_SERIAL_8250_RUNTIME_UARTS=5
 CONFIG_SERIAL_8250_INGENIC=y
 CONFIG_SERIAL_OF_PLATFORM=y
-# CONFIG_HW_RANDOM is not set
 CONFIG_I2C=y
 CONFIG_I2C_JZ4780=y
 CONFIG_SPI=y
@@ -99,7 +100,12 @@ CONFIG_IR_GPIO_TX=m
 CONFIG_MEDIA_SUPPORT=m
 # CONFIG_VGA_CONSOLE is not set
 # CONFIG_HID is not set
-# CONFIG_USB_SUPPORT is not set
+CONFIG_USB=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_DWC2=y
+CONFIG_USB_SERIAL=y
+CONFIG_USB_SERIAL_CH341=y
+CONFIG_USB_GADGET=y
 CONFIG_MMC=y
 CONFIG_MMC_JZ4740=y
 CONFIG_NEW_LEDS=y
@@ -131,8 +137,12 @@ CONFIG_MEMORY=y
 CONFIG_JZ4780_NEMC=y
 CONFIG_PWM=y
 CONFIG_PWM_JZ4740=m
+CONFIG_JZ4770_PHY=y
 CONFIG_EXT4_FS=y
 # CONFIG_DNOTIFY is not set
+CONFIG_AUTOFS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_FAT_DEFAULT_UTF8=y
 CONFIG_PROC_KCORE=y
 # CONFIG_PROC_PAGE_MONITOR is not set
 CONFIG_TMPFS=y
diff --git a/arch/mips/configs/cu1000-neo_defconfig 
b/arch/mips/configs/cu1000-neo_defconfig
index 55d0690a3ffe..9d75f5b77d5d 100644
--- a/arch/mips/configs/cu1000-neo_defconfig
+++ b/arch/mips/configs/cu1000-neo_defconfig
@@ -25,6 +25,7 @@ CONFIG_HIGHMEM=y
 CONFIG_HZ_100=y
 # CONFIG_SECCOMP is not set
 # CONFIG_SUSPEND is not set
+CONFIG_MODULES=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 # CONFIG_COMPACTION is not set
 CONFIG_CMA=y
@@ -32,15 +33,17 @@ CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
 CONFIG_INET=y
-CONFIG_CFG80211=y
+CONFIG_CFG80211=m
 CONFIG_UEVENT_HELPER=y
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 # CONFIG_ALLOW_DEV_COREDUMP is not set
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
 CONFIG_NETDEVICES=y
 CONFIG_STMMAC_ETH=y
 CONFIG_SMSC_PHY=y
-CONFIG_BRCMFMAC=y
+CONFIG_BRCMFMAC=m
 # CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
 # CONFIG_SERIO is not set
@@ -52,16 +55,25 @@ CONFIG_SERIAL_8250_NR_UARTS=3
 CONFIG_SERIAL_8250_RUNTIME_UARTS=3
 CONFIG_SERIAL_8250_INGENIC=y
 CONFIG_SERIAL_OF_PLATFORM=y
-# CONFIG_HW_RANDOM is not set
+CONFIG_SERIAL_SC16IS7XX=y
+# CONFIG_SERIAL_SC16IS7XX_I2C is not set
+CONFIG_SERIAL_SC16IS7XX_SPI=y
 CONFIG_I2C=y
 CONFIG_I2C_JZ4780=y
+CONFIG_SPI=y
+CONFIG_SPI_GPIO=y
 CONFIG_GPIO_SYSFS=y
-CONFIG_SENSORS_ADS7828=y
+CONFIG_SENSORS_ADS7828=m
 CONFIG_WATCHDOG=y
 CONFIG_JZ4740_WDT=y
 # CONFIG_VGA_CONSOLE is not set
 # CONFIG_HID is not set
-# CONFIG_USB_SUPPORT is not set
+CONFIG_USB=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_DWC2=y
+CONFIG_USB_SERIAL=y
+CONFIG_USB_SERIAL_CH341=y
+CONFIG_USB_GADGET=y
 CONFIG_MMC=y
 CONFIG_MMC_JZ4740=y
 CONFIG_NEW_LEDS=y
@@ -72,16 +84,22 @@ CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_JZ4740=y
 CONFIG_DMADEVICES=y
 CONFIG_DMA_JZ4780=y
+# CONFIG_INGENIC_TIMER is not set
+CONFIG_INGENIC_SYSOST=y
 # CONFIG_IOMMU_SUPPORT is not set
+CONFIG_JZ4770_PHY=y
 CONFIG_EXT4_FS=y
 # CONFIG_DNOTIFY is not set
 CONFIG_AUTOFS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_FAT_DEFAULT_UTF8=y
 CONFIG_PROC_KCORE=y
 # CONFIG_PROC_PAGE_MONITOR is not set
 CONFIG_TMPFS=y
 CONFIG_CONFIGFS_FS=y
 CONFIG_NFS_FS=y
 CONFIG_NLS=y
+CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_CODEPAGE_936=y
 CONFIG_NLS_CODEPAGE_950=y
 CONFIG_NLS_ASCII=y
diff --git a/arch/mips/configs/cu1830-neo_defconfig 
b/arch/mips/configs/cu1830-neo_defconfig
index e7064851a47a..29decd0003c6 100644
--- a/arch/mips/configs/cu1830-neo_defconfig
+++ b/arch/mips/configs/cu1830-neo_defconfig
@@ -25,6 +25,7 @@ CONFIG_HIGHMEM=y
 CONFIG_HZ_100=y
 # CONFIG_SECCOMP is not set
 # CONFIG_SUSPEND is not set
+CONFIG_MODULES=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 # CONFIG_COMPACTION is not set
 CONFIG_CMA=y
@@ -32,18 +33,20 @@ CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
 CONFIG_INET=y
-CONFIG_CFG80211=y
+CONFIG_CFG80211=m
 CONFIG_UEVENT_HELPER=y
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 # CONFIG_ALLOW_DEV_COREDUMP is not set
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
 CONFIG_MD=y
-CONFIG_BLK_DEV_MD=y
-CONFIG_BLK_DEV_DM=y
+CONFIG_BLK_DEV_MD=m
+CONFIG_BLK_DEV_DM=m
 CONFIG_NETDEVICES=y
 CONFIG_STMMAC_ETH=y
 CONFIG_ICPLUS_PHY=y
-CONFIG_BRCMFMAC=y
+CONFIG_BRCMFMAC=m
 # CONFIG_INPUT_KEYBOARD is not se

[PATCH 1/2] MIPS: Ingenic: Add missing nodes for Ingenic SoCs and boards.

2020-11-07 Thread Zhou Yanjie
1.Add OTG/OTG PHY/RNG nodes for JZ4780, CGU/OTG nodes for CI20.
2.Add OTG/OTG PHY/RNG/OST nodes for X1000, SSI/CGU/OST/OTG/SC16IS752
  nodes for CU1000-Neo.
3.Add OTG/OTG PHY/DTRNG/OST nodes for X1830, SSI/CGU/OST/OTG/SC16IS752
  nodes for CU1830-Neo.

Tested-by: 周正 (Zhou Zheng) 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
---
 arch/mips/boot/dts/ingenic/ci20.dts   | 16 +
 arch/mips/boot/dts/ingenic/cu1000-neo.dts | 60 +++
 arch/mips/boot/dts/ingenic/cu1830-neo.dts | 60 +++
 arch/mips/boot/dts/ingenic/jz4780.dtsi| 41 +++--
 arch/mips/boot/dts/ingenic/x1000.dtsi | 52 ++-
 arch/mips/boot/dts/ingenic/x1830.dtsi | 54 +++-
 6 files changed, 267 insertions(+), 16 deletions(-)

diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
b/arch/mips/boot/dts/ingenic/ci20.dts
index 75f5bfbf2c37..b31054a41754 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -93,6 +93,15 @@
clock-frequency = <4800>;
 };
 
+&cgu {
+   /*
+* Use the 32.768 kHz oscillator as the parent of the RTC for a higher
+* precision.
+*/
+   assigned-clocks = <&cgu JZ4780_CLK_RTC>;
+   assigned-clock-parents = <&cgu JZ4780_CLK_RTCLK>;
+};
+
 &mmc0 {
status = "okay";
 
@@ -396,6 +405,13 @@
status = "okay";
 };
 
+&otg {
+   status = "okay";
+
+   assigned-clocks = <&cgu JZ4780_CLK_OTGPHY>;
+   assigned-clock-rates = <4800>;
+};
+
 &pinctrl {
pins_uart0: uart0 {
function = "uart0";
diff --git a/arch/mips/boot/dts/ingenic/cu1000-neo.dts 
b/arch/mips/boot/dts/ingenic/cu1000-neo.dts
index 22a1066d637b..44d47d12db12 100644
--- a/arch/mips/boot/dts/ingenic/cu1000-neo.dts
+++ b/arch/mips/boot/dts/ingenic/cu1000-neo.dts
@@ -3,7 +3,7 @@
 
 #include "x1000.dtsi"
 #include 
-#include 
+#include 
 #include 
 
 / {
@@ -31,6 +31,18 @@
};
};
 
+   ssi: spi-gpio {
+   compatible = "spi-gpio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   num-chipselects = <1>;
+
+   mosi-gpios = <&gpd 2 GPIO_ACTIVE_HIGH>;
+   miso-gpios = <&gpd 3 GPIO_ACTIVE_HIGH>;
+   sck-gpios = <&gpd 0 GPIO_ACTIVE_HIGH>;
+   cs-gpios = <&gpd 1 GPIO_ACTIVE_HIGH>;
+   };
+
wlan_pwrseq: msc1-pwrseq {
compatible = "mmc-pwrseq-simple";
 
@@ -43,13 +55,19 @@
clock-frequency = <2400>;
 };
 
-&tcu {
+&cgu {
+   /*
+* Use the 32.768 kHz oscillator as the parent of the RTC for a higher
+* precision.
+*/
+   assigned-clocks = <&cgu X1000_CLK_RTC>;
+   assigned-clock-parents = <&cgu X1000_CLK_RTCLK>;
+};
+
+&ost {
/* 1500 kHz for the system timer and clocksource */
-   assigned-clocks = <&tcu TCU_CLK_TIMER0>, <&tcu TCU_CLK_TIMER2>;
+   assigned-clocks = <&ost OST_CLK_PERCPU_TIMER>, <&ost 
OST_CLK_GLOBAL_TIMER>;
assigned-clock-rates = <150>, <150>;
-
-   /* Use channel #0 for the system timer channel #2 for the clocksource */
-   ingenic,pwm-channels-mask = <0xfa>;
 };
 
 &uart2 {
@@ -59,6 +77,32 @@
pinctrl-0 = <&pins_uart2>;
 };
 
+&ssi {
+   status = "okay";
+
+   spi-max-frequency = <5000>;
+
+   sc16is752: expander@0 {
+   compatible = "nxp,sc16is752";
+   reg = <0>; /* CE0 */
+   spi-max-frequency = <400>;
+
+   clocks = <&exclk_sc16is752>;
+
+   interrupt-parent = <&gpc>;
+   interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   exclk_sc16is752: sc16is752 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <4800>;
+   };
+   };
+};
+
 &i2c0 {
status = "okay";
 
@@ -135,6 +179,10 @@
};
 };
 
+&otg {
+   status = "okay";
+};
+
 &pinctrl {
pins_uart2: uart2 {
function = "uart2";
diff --git a/arch/mips/boot/dts/ingenic/cu1830-neo.dts 
b/arch/mips/boot/dts/ingenic/cu1830-neo.dts
index 640f96c00d63..7a56e344e429 100644
--- a/arch/mips/boot/dts/ingenic/cu1830-neo.dts
+++ b/arch/mips/boot/dts/ingenic/cu1830-neo.dts
@@ -3,7 +3,7 @@
 
 #include "x1830.dtsi"
 #include 
-#include 
+#include 
 #include 
 
 / {
@@ -31,6 +31,18 @@
};
};
 
+   ssi0: spi-gpio {
+   compatible = "spi-gpio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   num-chipselects = <1>;
+
+   mosi-gpios = <&gpc 12 GPIO_ACTIVE_HIGH>;
+   miso-gpios = <&gpc 11 GPIO_ACTIVE_HIGH>;
+   sck-gpios = <&gpc 15 GPIO_ACTIVE_HIGH>;
+   cs-gpios = <&gpc 16 GPIO_ACTIVE_HIGH>;
+   };
+
wlan_p

[PATCH V4 3/5] arm64: dts: imx8mn: Add SAI nodes

2020-11-07 Thread Adam Ford
The i.MX8M Nano has several SAI nodes available to it.
Enable them.

Signed-off-by: Adam Ford 
---
V4:  No Change
V3:  No Change
V2:  No Change

 arch/arm64/boot/dts/freescale/imx8mn.dtsi | 72 +++
 1 file changed, 72 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 61560c083300..6ea0d43a78a3 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -260,6 +260,78 @@ spba: bus@3000 {
reg = <0x3000 0x10>;
ranges;
 
+   sai2: sai@3002 {
+   compatible = "fsl,imx8mm-sai", 
"fsl,imx8mq-sai";
+   reg = <0x3002 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MN_CLK_SAI2_IPG>,
+   <&clk IMX8MN_CLK_DUMMY>,
+   <&clk IMX8MN_CLK_SAI2_ROOT>,
+   <&clk IMX8MN_CLK_DUMMY>, <&clk 
IMX8MN_CLK_DUMMY>;
+   clock-names = "bus", "mclk0", "mclk1", 
"mclk2", "mclk3";
+   dmas = <&sdma2 2 2 0>, <&sdma2 3 2 0>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   sai3: sai@3003 {
+   compatible = "fsl,imx8mm-sai", 
"fsl,imx8mq-sai";
+   reg = <0x3003 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MN_CLK_SAI3_IPG>,
+<&clk IMX8MN_CLK_DUMMY>,
+<&clk IMX8MN_CLK_SAI3_ROOT>,
+<&clk IMX8MN_CLK_DUMMY>, <&clk 
IMX8MN_CLK_DUMMY>;
+   clock-names = "bus", "mclk0", "mclk1", 
"mclk2", "mclk3";
+   dmas = <&sdma2 4 2 0>, <&sdma2 5 2 0>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   sai5: sai@3005 {
+   compatible = "fsl,imx8mm-sai", 
"fsl,imx8mq-sai";
+   reg = <0x3005 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MN_CLK_SAI5_IPG>,
+<&clk IMX8MN_CLK_DUMMY>,
+<&clk IMX8MN_CLK_SAI5_ROOT>,
+<&clk IMX8MN_CLK_DUMMY>, <&clk 
IMX8MN_CLK_DUMMY>;
+   clock-names = "bus", "mclk0", "mclk1", 
"mclk2", "mclk3";
+   dmas = <&sdma2 8 2 0>, <&sdma2 9 2 0>;
+   dma-names = "rx", "tx";
+   fsl,shared-interrupt;
+   fsl,dataline = <0 0xf 0xf>;
+   status = "disabled";
+   };
+
+   sai6: sai@3006 {
+   compatible = "fsl,imx8mm-sai", 
"fsl,imx8mq-sai";
+   reg = <0x3006  0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MN_CLK_SAI6_IPG>,
+<&clk IMX8MN_CLK_DUMMY>,
+<&clk IMX8MN_CLK_SAI6_ROOT>,
+<&clk IMX8MN_CLK_DUMMY>, <&clk 
IMX8MN_CLK_DUMMY>;
+   clock-names = "bus", "mclk0", "mclk1", 
"mclk2", "mclk3";
+   dmas = <&sdma2 10 2 0>, <&sdma2 11 2 0>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   sai7: sai@300b {
+   compatible = "fsl,imx8mm-sai", 
"fsl,imx8mq-sai";
+   reg = <0x300b 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MN_CLK_SAI7_IPG>,
+<&clk IMX8MN_CLK_DUMMY>,
+<&clk IMX8MN_CLK_SAI7_ROOT>,
+

[PATCH V4 1/5] dt-bindings: soc: imx: Add binding doc for spba bus

2020-11-07 Thread Adam Ford
Add binding doc for fsl,spba-bus.

Signed-off-by: Adam Ford 
---
V4:  Correct errors in YAML
V3:  New to series

 .../devicetree/bindings/bus/fsl,spba-bus.yaml | 66 +++
 1 file changed, 66 insertions(+)

diff --git a/Documentation/devicetree/bindings/bus/fsl,spba-bus.yaml 
b/Documentation/devicetree/bindings/bus/fsl,spba-bus.yaml
new file mode 100644
index ..d1037acd2734
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/fsl,spba-bus.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/simple-pm-bus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Shared Peripherals Bus Interface
+
+maintainers:
+  - Shawn Guo 
+
+description: |
+  A simple bus enabling access to shared peripherals.
+
+  The "spba-bus" follows the "simple-bus" set of properties, as
+  specified in the Devicetree Specification.  It is an extension of
+  "simple-bus" because the SDMA controller uses this compatible flag to
+  determine which peripherals are available to it and the range over which
+  the SDMA can access.  There are no special clocks for the bus, because
+  the SDMA controller itself has its interrupt, and clock assignments.
+
+select:
+  properties:
+compatible:
+  contains:
+const: fsl,spba-bus
+  required:
+- compatible
+
+properties:
+  $nodename:
+pattern: "^bus(@[0-9a-f]+)?$"
+
+  compatible:
+contains:
+  const: fsl,spba-bus
+  items:
+- const: fsl,spba-bus
+- const: simple-bus
+
+  '#address-cells':
+enum: [ 1, 2 ]
+
+  '#size-cells':
+enum: [ 1, 2 ]
+
+  ranges: true
+
+required:
+  - compatible
+  - '#address-cells'
+  - '#size-cells'
+  - ranges
+
+additionalProperties: true
+
+type: object
+
+examples:
+  - |
+bus {
+compatible = "fsl,spba-bus", "simple-bus";
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+};
-- 
2.25.1



[PATCH V4 2/5] arm64: dts: imx8mn: Enable Asynchronous Sample Rate Converter

2020-11-07 Thread Adam Ford
The driver exists for the Enhanced Asynchronous Sample Rate Converter
(EASRC) Controller, but there isn't a device tree entry for it.

On the vendor kernel, they put this on a spba-bus for SDMA support.

Add the node for the spba-bus with the easrc node inside.

Signed-off-by: Adam Ford 
---
V4:  No change
V3:  Change spba-bus@3000 to spba: bus@3000
V2:  Make the DT node more in-line with the dt binding and remove
 vendor customizations that are not applicable.
 arch/arm64/boot/dts/freescale/imx8mn.dtsi | 28 +++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index a06d2a6268e6..61560c083300 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -253,6 +253,34 @@ aips1: bus@3000 {
#size-cells = <1>;
ranges;
 
+   spba: bus@3000 {
+   compatible = "fsl,spba-bus", "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x3000 0x10>;
+   ranges;
+
+   easrc: easrc@300c {
+   compatible = "fsl,imx8mn-easrc";
+   reg = <0x300c 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MN_CLK_ASRC_ROOT>;
+   clock-names = "mem";
+   dmas = <&sdma2 16 23 0> , <&sdma2 17 23 
0>,
+  <&sdma2 18 23 0> , <&sdma2 19 23 
0>,
+  <&sdma2 20 23 0> , <&sdma2 21 23 
0>,
+  <&sdma2 22 23 0> , <&sdma2 23 23 
0>;
+   dma-names = "ctx0_rx", "ctx0_tx",
+   "ctx1_rx", "ctx1_tx",
+   "ctx2_rx", "ctx2_tx",
+   "ctx3_rx", "ctx3_tx";
+   firmware-name = 
"imx/easrc/easrc-imx8mn.bin";
+   fsl,asrc-rate  = <8000>;
+   fsl,asrc-format = <2>;
+   status = "disabled";
+   };
+   };
+
gpio1: gpio@3020 {
compatible = "fsl,imx8mn-gpio", 
"fsl,imx35-gpio";
reg = <0x3020 0x1>;
-- 
2.25.1



[PATCH V4 5/5] arm64: dts: imx8mn: Add node for SPDIF

2020-11-07 Thread Adam Ford
The i.MX8M Nano can support SPDIF which is compatible to the
IP used on the i.MX35.

Add the node.

Signed-off-by: Adam Ford 
---
V4:  No Change
V3:  No Change
V2:  No Change

 arch/arm64/boot/dts/freescale/imx8mn.dtsi | 24 +++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index aa3f1eb391bd..ee1790230490 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -337,6 +337,30 @@ micfil: audio-controller@3008 {
status = "disabled";
};
 
+   spdif1: spdif@3009 {
+   compatible = "fsl,imx35-spdif";
+   reg = <0x3009 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MN_CLK_AUDIO_AHB>, 
/* core */
+<&clk IMX8MN_CLK_24M>, /* 
rxtx0 */
+<&clk IMX8MN_CLK_SPDIF1>, /* 
rxtx1 */
+<&clk IMX8MN_CLK_DUMMY>, /* 
rxtx2 */
+<&clk IMX8MN_CLK_DUMMY>, /* 
rxtx3 */
+<&clk IMX8MN_CLK_DUMMY>, /* 
rxtx4 */
+<&clk IMX8MN_CLK_AUDIO_AHB>, 
/* rxtx5 */
+<&clk IMX8MN_CLK_DUMMY>, /* 
rxtx6 */
+<&clk IMX8MN_CLK_DUMMY>, /* 
rxtx7 */
+<&clk IMX8MN_CLK_DUMMY>; /* 
spba */
+   clock-names = "core", "rxtx0",
+ "rxtx1", "rxtx2",
+ "rxtx3", "rxtx4",
+ "rxtx5", "rxtx6",
+ "rxtx7", "spba";
+   dmas = <&sdma2 28 18 0>, <&sdma2 29 18 
0>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
sai7: sai@300b {
compatible = "fsl,imx8mm-sai", 
"fsl,imx8mq-sai";
reg = <0x300b 0x1>;
-- 
2.25.1



[PATCH V4 4/5] arm64: dts: imx8mn: Add support for micfil

2020-11-07 Thread Adam Ford
The i.MX8M Nano has supports the MICFIL digital interface.
It's a 16-bit audio signal from a PDM microphone bitstream.
The driver is already in the kernel, but the node is missing.

Add the micfil node.

Signed-off-by: Adam Ford 
---
V4:  No Change
V3:  No Change
V2:  Change micfil@3008 to audio-controller@3008

 arch/arm64/boot/dts/freescale/imx8mn.dtsi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 6ea0d43a78a3..aa3f1eb391bd 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -318,6 +318,25 @@ sai6: sai@3006 {
status = "disabled";
};
 
+   micfil: audio-controller@3008 {
+   compatible = "fsl,imx8mm-micfil";
+   reg = <0x3008 0x1>;
+   interrupts = ,
+,
+,
+;
+   clocks = <&clk IMX8MN_CLK_PDM_IPG>,
+<&clk IMX8MN_CLK_PDM_ROOT>,
+<&clk IMX8MN_AUDIO_PLL1_OUT>,
+<&clk IMX8MN_AUDIO_PLL2_OUT>,
+<&clk IMX8MN_CLK_EXT3>;
+   clock-names = "ipg_clk", "ipg_clk_app",
+ "pll8k", "pll11k", 
"clkext3";
+   dmas = <&sdma2 24 25 0x8000>;
+   dma-names = "rx";
+   status = "disabled";
+   };
+
sai7: sai@300b {
compatible = "fsl,imx8mm-sai", 
"fsl,imx8mq-sai";
reg = <0x300b 0x1>;
-- 
2.25.1



Re: possible deadlock in mnt_want_write

2020-11-07 Thread syzbot
syzbot suspects this issue was fixed by commit:

commit 146d62e5a5867fbf84490d82455718bfb10fe824
Author: Amir Goldstein 
Date:   Thu Apr 18 14:42:08 2019 +

ovl: detect overlapping layers

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=11e4018450
start commit:   6d906f99 Merge tag 'arm64-fixes' of git://git.kernel.org/p..
git tree:   upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=856fc6d0fbbeede9
dashboard link: https://syzkaller.appspot.com/bug?extid=ae82084b07d0297e566b
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=111767b720
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1611ab2d20

If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: ovl: detect overlapping layers

For information about bisection process see: https://goo.gl/tpsmEJ#bisection


Re: [PATCH 01/19] drm/ttm/ttm_range_manager: Demote non-conformant kernel-doc header

2020-11-07 Thread Christian König

Am 06.11.20 um 22:49 schrieb Lee Jones:

Fixes the following W=1 kernel build warning(s):

  drivers/gpu/drm/ttm/ttm_range_manager.c:46: warning: cannot understand 
function prototype: 'struct ttm_range_manager '

Cc: Christian Koenig 
Cc: Huang Rui 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c 
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index ea77919569a2e..e0952444cea93 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -37,7 +37,7 @@
  #include 
  #include 
  
-/**

+/*
   * Currently we use a spinlock for the lock, but a mutex *may* be
   * more appropriate to reduce scheduling latency if the range manager
   * ends up with very fragmented allocation patterns.




[PATCH v2] clk: exynos7: Keep aclk_fsys1_200 enabled

2020-11-07 Thread Paweł Chmiel
This clock must be always enabled to allow access to any registers in
fsys1 CMU. Until proper solution based on runtime PM is applied
(similar to what was done for Exynos5433), fix this by calling
clk_prepare_enable() directly from clock provider driver.

It was observed on Samsung Galaxy S6 device (based on Exynos7420), where
UFS module is probed before pmic used to power that device.
In this case defer probe was happening and that clock was disabled by
UFS driver, causing whole boot to hang on next CMU access.

Signed-off-by: Paweł Chmiel 
---
Changes from v1:
  - Instead of marking clock as critical, enable it manually in driver.
---
 drivers/clk/samsung/clk-exynos7.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos7.c 
b/drivers/clk/samsung/clk-exynos7.c
index c1ff715e960c..e05b673e277f 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 
 #include "clk.h"
 #include 
@@ -571,6 +572,10 @@ static const struct samsung_cmu_info top1_cmu_info 
__initconst = {
 static void __init exynos7_clk_top1_init(struct device_node *np)
 {
samsung_cmu_register_one(np, &top1_cmu_info);
+   /*
+* Keep top FSYS1 aclk enabled permanently. It's required for CMU 
register access.
+*/
+   clk_prepare_enable(__clk_lookup("aclk_fsys1_200"));
 }
 
 CLK_OF_DECLARE(exynos7_clk_top1, "samsung,exynos7-clock-top1",
-- 
2.27.0



Re: [PATCH 00/19] [Set 2] Rid W=1 warnings from GPU

2020-11-07 Thread Christian König

Well that's quite a patch set.

First of all can you separate this a bit more by driver? I'm assuming we 
maintainers are supposed to pick that up and apply it.


radeon and amdgpu can stick together since that is mostly Alex and me, 
but I'm not sure if we want to do some of the suggested changes to radeon.


Going to pick up the single TTM change for upstreaming.

Thanks,
Christian.

Am 06.11.20 um 22:49 schrieb Lee Jones:

This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.

There are 5000 warnings to work through.  It will take a couple more
sets.  Although, ("drm/amd/display/dc/basics/fixpt31_32: Move
variables to where they're used") does take care of 2000 of them!

Lee Jones (19):
   drm/ttm/ttm_range_manager: Demote non-conformant kernel-doc header
   drm/r128/ati_pcigart: Source file headers are not good candidates for
 kernel-doc
   drm/selftests/test-drm_dp_mst_helper: Move
 'sideband_msg_req_encode_decode' onto the heap
   drm/mga/mga_dma: Demote kernel-doc abusers to standard comment blocks
   drm/mga/mga_state: Remove unused variable 'buf_priv'
   drm/radeon/atom: Move prototype into shared location
   drm/radeon/radeon_kms: Include header containing our own prototypes
   drm/omapdrm/omap_gem: Fix misnamed and missing parameter descriptions
   drm/omapdrm/omap_dmm_tiler: Demote abusive use of kernel-doc format
   drm/radeon/radeon: Move prototype into shared header
   drm/radeon/radeon_drv: Source file headers are not good candidates for
 kernel-doc
   drm/amd/display/dc/basics/fixpt31_32: Move variables to where they're
 used
   drm/radeon/radeon_drv: Move prototypes to a shared headerfile
   drm/amd/amdgpu/amdgpu_device: Provide documentation for 'reg_addr'
 params
   drm/radeon: Move prototypes to shared header
   drm/amd/amdgpu/amdgpu_kms: Remove 'struct drm_amdgpu_info_device
 dev_info' from the stack
   drm/radeon/radeon_kms: Fix misnaming of 'radeon_info_ioctl's dev param
   drm/radeon/atombios_crtc: Remove description of non-existent function
 param 'encoder'
   drm/v3d/v3d_drv: Remove unused static variable 'v3d_v3d_pm_ops'

  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|   2 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 104 +-
  .../drm/amd/display/dc/basics/fixpt31_32.c|   5 +
  .../gpu/drm/amd/display/include/fixed31_32.h  |   6 -
  drivers/gpu/drm/mga/mga_dma.c |  10 +-
  drivers/gpu/drm/mga/mga_state.c   |   2 -
  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c  |   6 +-
  drivers/gpu/drm/omapdrm/omap_gem.c|   3 +-
  drivers/gpu/drm/r128/ati_pcigart.c|   2 +-
  drivers/gpu/drm/radeon/atom.h |   6 +
  drivers/gpu/drm/radeon/atombios_crtc.c|   1 -
  drivers/gpu/drm/radeon/atombios_encoders.c|   4 -
  drivers/gpu/drm/radeon/radeon.h   |   6 +
  drivers/gpu/drm/radeon/radeon_device.c|   1 +
  drivers/gpu/drm/radeon/radeon_device.h|  32 ++
  drivers/gpu/drm/radeon/radeon_display.c   |   4 -
  drivers/gpu/drm/radeon/radeon_drv.c   |  11 +-
  drivers/gpu/drm/radeon/radeon_drv.h   |   7 ++
  drivers/gpu/drm/radeon/radeon_kms.c   |   3 +-
  .../drm/selftests/test-drm_dp_mst_helper.c|  11 +-
  drivers/gpu/drm/ttm/ttm_range_manager.c   |   2 +-
  drivers/gpu/drm/v3d/v3d_drv.c |  36 --
  22 files changed, 138 insertions(+), 126 deletions(-)
  create mode 100644 drivers/gpu/drm/radeon/radeon_device.h

Cc: Alex Deucher 
Cc: amd-...@lists.freedesktop.org
Cc: Andy Gross 
Cc: by 
Cc: Christian Koenig 
Cc: "Christian König" 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Cc: Eric Anholt 
Cc: Faith 
Cc: Gareth Hughes 
Cc: Harry Wentland 
Cc: Huang Rui 
Cc: Jeff Hartmann 
Cc: Keith Whitwell 
Cc: Leo Li 
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-me...@vger.kernel.org
Cc: Philipp Zabel 
Cc: Rob Clark 
Cc: Rob Clark 
Cc: Sumit Semwal 
Cc: Tomi Valkeinen 




[PATCH RESEND 0/2] Add dmaengine bindings for the JZ4775 and the X2000 SoCs.

2020-11-07 Thread Zhou Yanjie
Add the dmaengine bindings for the JZ4775 SoC and the X2000 SoC from Ingenic.

周琰杰 (Zhou Yanjie) (2):
  dt-bindings: dmaengine: Add JZ4775 bindings.
  dt-bindings: dmaengine: Add X2000 bindings.

 include/dt-bindings/dma/jz4775-dma.h | 44 +
 include/dt-bindings/dma/x2000-dma.h  | 54 
 2 files changed, 98 insertions(+)
 create mode 100644 include/dt-bindings/dma/jz4775-dma.h
 create mode 100644 include/dt-bindings/dma/x2000-dma.h

-- 
2.11.0



[PATCH RESEND 1/2] dt-bindings: dmaengine: Add JZ4775 bindings.

2020-11-07 Thread Zhou Yanjie
Add the dmaengine bindings for the JZ4775 SoC from Ingenic.

Signed-off-by: 周琰杰 (Zhou Yanjie) 
Acked-by: Rob Herring 
---
 include/dt-bindings/dma/jz4775-dma.h | 44 
 1 file changed, 44 insertions(+)
 create mode 100644 include/dt-bindings/dma/jz4775-dma.h

diff --git a/include/dt-bindings/dma/jz4775-dma.h 
b/include/dt-bindings/dma/jz4775-dma.h
new file mode 100644
index ..8d27e2c69dca
--- /dev/null
+++ b/include/dt-bindings/dma/jz4775-dma.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * This header provides macros for JZ4775 DMA bindings.
+ *
+ * Copyright (c) 2020 周琰杰 (Zhou Yanjie) 
+ */
+
+#ifndef __DT_BINDINGS_DMA_JZ4775_DMA_H__
+#define __DT_BINDINGS_DMA_JZ4775_DMA_H__
+
+/*
+ * Request type numbers for the JZ4775 DMA controller (written to the DRTn
+ * register for the channel).
+ */
+#define JZ4775_DMA_I2S0_TX 0x6
+#define JZ4775_DMA_I2S0_RX 0x7
+#define JZ4775_DMA_AUTO0x8
+#define JZ4775_DMA_SADC_RX 0x9
+#define JZ4775_DMA_UART3_TX0x0e
+#define JZ4775_DMA_UART3_RX0x0f
+#define JZ4775_DMA_UART2_TX0x10
+#define JZ4775_DMA_UART2_RX0x11
+#define JZ4775_DMA_UART1_TX0x12
+#define JZ4775_DMA_UART1_RX0x13
+#define JZ4775_DMA_UART0_TX0x14
+#define JZ4775_DMA_UART0_RX0x15
+#define JZ4775_DMA_SSI0_TX 0x16
+#define JZ4775_DMA_SSI0_RX 0x17
+#define JZ4775_DMA_MSC0_TX 0x1a
+#define JZ4775_DMA_MSC0_RX 0x1b
+#define JZ4775_DMA_MSC1_TX 0x1c
+#define JZ4775_DMA_MSC1_RX 0x1d
+#define JZ4775_DMA_MSC2_TX 0x1e
+#define JZ4775_DMA_MSC2_RX 0x1f
+#define JZ4775_DMA_PCM0_TX 0x20
+#define JZ4775_DMA_PCM0_RX 0x21
+#define JZ4775_DMA_SMB0_TX 0x24
+#define JZ4775_DMA_SMB0_RX 0x25
+#define JZ4775_DMA_SMB1_TX 0x26
+#define JZ4775_DMA_SMB1_RX 0x27
+#define JZ4775_DMA_SMB2_TX 0x28
+#define JZ4775_DMA_SMB2_RX 0x29
+
+#endif /* __DT_BINDINGS_DMA_JZ4775_DMA_H__ */
-- 
2.11.0



[PATCH RESEND 2/2] dt-bindings: dmaengine: Add X2000 bindings.

2020-11-07 Thread Zhou Yanjie
Add the dmaengine bindings for the X2000 SoC from Ingenic.

Signed-off-by: 周琰杰 (Zhou Yanjie) 
Acked-by: Rob Herring 
---
 include/dt-bindings/dma/x2000-dma.h | 54 +
 1 file changed, 54 insertions(+)
 create mode 100644 include/dt-bindings/dma/x2000-dma.h

diff --git a/include/dt-bindings/dma/x2000-dma.h 
b/include/dt-bindings/dma/x2000-dma.h
new file mode 100644
index ..db2cd4830b00
--- /dev/null
+++ b/include/dt-bindings/dma/x2000-dma.h
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * This header provides macros for X2000 DMA bindings.
+ *
+ * Copyright (c) 2020 周琰杰 (Zhou Yanjie) 
+ */
+
+#ifndef __DT_BINDINGS_DMA_X2000_DMA_H__
+#define __DT_BINDINGS_DMA_X2000_DMA_H__
+
+/*
+ * Request type numbers for the X2000 DMA controller (written to the DRTn
+ * register for the channel).
+ */
+#define X2000_DMA_AUTO 0x8
+#define X2000_DMA_UART5_TX 0xa
+#define X2000_DMA_UART5_RX 0xb
+#define X2000_DMA_UART4_TX 0xc
+#define X2000_DMA_UART4_RX 0xd
+#define X2000_DMA_UART3_TX 0xe
+#define X2000_DMA_UART3_RX 0xf
+#define X2000_DMA_UART2_TX 0x10
+#define X2000_DMA_UART2_RX 0x11
+#define X2000_DMA_UART1_TX 0x12
+#define X2000_DMA_UART1_RX 0x13
+#define X2000_DMA_UART0_TX 0x14
+#define X2000_DMA_UART0_RX 0x15
+#define X2000_DMA_SSI0_TX  0x16
+#define X2000_DMA_SSI0_RX  0x17
+#define X2000_DMA_SSI1_TX  0x18
+#define X2000_DMA_SSI1_RX  0x19
+#define X2000_DMA_I2C0_TX  0x24
+#define X2000_DMA_I2C0_RX  0x25
+#define X2000_DMA_I2C1_TX  0x26
+#define X2000_DMA_I2C1_RX  0x27
+#define X2000_DMA_I2C2_TX  0x28
+#define X2000_DMA_I2C2_RX  0x29
+#define X2000_DMA_I2C3_TX  0x2a
+#define X2000_DMA_I2C3_RX  0x2b
+#define X2000_DMA_I2C4_TX  0x2c
+#define X2000_DMA_I2C4_RX  0x2d
+#define X2000_DMA_I2C5_TX  0x2e
+#define X2000_DMA_I2C5_RX  0x2f
+#define X2000_DMA_UART6_TX 0x30
+#define X2000_DMA_UART6_RX 0x31
+#define X2000_DMA_UART7_TX 0x32
+#define X2000_DMA_UART7_RX 0x33
+#define X2000_DMA_UART8_TX 0x34
+#define X2000_DMA_UART8_RX 0x35
+#define X2000_DMA_UART9_TX 0x36
+#define X2000_DMA_UART9_RX 0x37
+#define X2000_DMA_SADC_RX  0x38
+
+#endif /* __DT_BINDINGS_DMA_X2000_DMA_H__ */
-- 
2.11.0



About the rockpi4 pcie controller failed to initialize problem in v5.10-rc2

2020-11-07 Thread Qu Wenruo
Hi guys,

I see your awesome contribution to support Rock Pi 4B.

However in recent rc (v5.10-rc2), I found that even with `vpcie1v8` and
`vpcie0v9` added, `regulartor_dev_lookup()` now just returns
-EPROBE_DEFER, preventing rockchip pcie controller to be initialized.

The full callchain is:

rockchip_pcie_parse_host_dt()
|- rockchip>vpcie1v8 = devm_regulator_get_optional(dev, "vpcie1v8");
   |- _regulator_get()
  |- regulator_dev_lookup()
 |- node = of_get_regulartor()
 |- if (!node) {
 |- r = of_find_regulator(); /* No @r found */
 |- return ERR_PTR(-EPROBE_DEFER);

This means we can't utilize PCIE controller completely.

But strangely, `vpcie12v` and `vpcie3v3` both initialized without problem.

Any clue on how the problem could happened? I guess it's some device
tree definition went crazy, but not familiar with device tree at all.

Thanks,
Qu



signature.asc
Description: OpenPGP digital signature


[PATCH V3 1/3] dt-bindings: arm: fsl: Add beacon,imx8mn-beacon-kit

2020-11-07 Thread Adam Ford
Add beacon,imx8mn-beacon-kit to list of compatible options.

Signed-off-by: Adam Ford 
---
V3:  Correct Typo and move to Nano section
V2:  New to series

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 85fb24da4a02..5a2608e6bc30 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -680,6 +680,7 @@ properties:
   - description: i.MX8MN based Boards
 items:
   - enum:
+  - beacon,imx8mn-beacon-kit  # i.MX8MN Beacon Development Kit
   - fsl,imx8mn-ddr4-evk   # i.MX8MN DDR4 EVK Board
   - fsl,imx8mn-evk# i.MX8MN LPDDR4 EVK Board
   - const: fsl,imx8mn
-- 
2.25.1



[PATCH V3 2/3] arm64: dts: imx: Add Beacon i.MX8M Nano development kit

2020-11-07 Thread Adam Ford
Beacon Embeddedworks is launching a development kit based on the
i.MX8M Nano SoC.  The kit consists of a System on Module (SOM)
+ baseboard.  The SOM has the SoC, eMMC, and Ethernet. The baseboard
has an wm8962 audio CODEC, a PDM microphone, and a single USB OTG.

The baseboard is capable of two different, mutually exclusive video
outputs, so the common items are in the baseboard file.  When
the video becomes available, LVDS output will be added to this kit
file, and a second kit file will be added to support HDMI.

Signed-off-by: Adam Ford 
Reviewed-by: Krzysztof Kozlowski 
---
V3:  Correct name
V2:  Correct Typo

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index 876bf484bbe6..589290d6 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -34,6 +34,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-ddr4-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-kontron-n801x-s.dts
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mn-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-var-som-symphony.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-beacon-baseboard.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mn-beacon-baseboard.dtsi
new file mode 100644
index ..376ca8ff7213
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mn-beacon-baseboard.dtsi
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2020 Compass Electronics Group, LLC
+ */
+
+/ {
+   leds {
+   compatible = "gpio-leds";
+
+   led-0 {
+   label = "gen_led0";
+   gpios = <&pca6416_1 4 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   led-1 {
+   label = "gen_led1";
+   gpios = <&pca6416_1 5 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   led-2 {
+   label = "gen_led2";
+   gpios = <&pca6416_1 6 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   led-3 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_led3>;
+   label = "heartbeat";
+   gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   reg_audio: regulator-audio {
+   compatible = "regulator-fixed";
+   regulator-name = "3v3_aud";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&pca6416_1 11 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   reg_usdhc2_vmmc: regulator-usdhc2 {
+   compatible = "regulator-fixed";
+   regulator-name = "vsd_3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   reg_usb_otg_vbus: regulator-usb {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_reg_usb_otg>;
+   regulator-name = "usb_otg_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   sound {
+   compatible = "fsl,imx-audio-wm8962";
+   model = "wm8962-audio";
+   audio-cpu = <&sai3>;
+   audio-codec = <&wm8962>;
+   audio-routing =
+   "Headphone Jack", "HPOUTL",
+   "Headphone Jack", "HPOUTR",
+   "Ext Spk", "SPKOUTL",
+   "Ext Spk", "SPKOUTR",
+   "AMIC", "MICBIAS",
+   "IN3R", "AMIC";
+   };
+};
+
+&ecspi2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_espi2>;
+   cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
+   status = "okay";
+
+   eeprom@0 {
+   compatible = "microchip,at25160bn", "atmel,at25";
+   reg = <0>;
+   spi-max-frequency = <500>;
+   spi-cpha;
+   spi-cpol;
+   pagesize = <32>;
+   size = <2048>;
+   address-width = <16>;
+   };
+};
+
+&i2c4 {
+   clock-frequency = <40>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c4>;
+   status = "okay";
+
+   pca6416_0: gpio@20 {
+   compatible = "nxp,pcal6416";
+

[PATCH V3 3/3] arm64: defconfig: Enable WM8962

2020-11-07 Thread Adam Ford
The Beacon EmbeddedWorks development kits supporting i.MX8M Mini
and Nano have an WM8962 audio CODEC installed.  Add modules for both
CONFIG_SND_SOC_WM8962 and CONFIG_SND_SOC_FSL_ASOC_CARD to enable them.

Signed-off-by: Adam Ford 
---
V3:  No Change
V2:  New to series

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 821b21a56ad7..00357f5c6fa5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -701,6 +701,7 @@ CONFIG_SND_SOC_FSL_EASRC=m
 CONFIG_SND_IMX_SOC=m
 CONFIG_SND_SOC_IMX_SPDIF=m
 CONFIG_SND_SOC_IMX_AUDMIX=m
+CONFIG_SND_SOC_FSL_ASOC_CARD=m
 CONFIG_SND_MESON_AXG_SOUND_CARD=m
 CONFIG_SND_MESON_GX_SOUND_CARD=m
 CONFIG_SND_SOC_QCOM=m
@@ -728,6 +729,7 @@ CONFIG_SND_SOC_SIMPLE_AMPLIFIER=m
 CONFIG_SND_SOC_TAS571X=m
 CONFIG_SND_SOC_WCD934X=m
 CONFIG_SND_SOC_WM8904=m
+CONFIG_SND_SOC_WM8962=m
 CONFIG_SND_SOC_WSA881X=m
 CONFIG_SND_SIMPLE_CARD=m
 CONFIG_SND_AUDIO_GRAPH_CARD=m
-- 
2.25.1



[PATCH 0/3] Switch PineTab DT LCD panel to retail one

2020-11-07 Thread Icenowy Zheng
Retail PineTabs switched to K101-IM2BYL02 panel.

This patchset tries to reflect this change, and add a DT for samples
that still have K101-IM2BA02.

Icenowy Zheng (3):
  arm64: allwinner: dts: a64: pinetab: switch LCD panel to production
one
  dt-bindings: arm: sunxi: add PineTab developer sample DT binding
  arm64: allwinner: dts: a64: add DT for PineTab developer sample

 .../devicetree/bindings/arm/sunxi.yaml|  5 
 arch/arm64/boot/dts/allwinner/Makefile|  1 +
 .../dts/allwinner/sun50i-a64-pinetab-dev.dts  | 28 +++
 .../boot/dts/allwinner/sun50i-a64-pinetab.dts |  8 ++
 4 files changed, 37 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts

-- 
2.28.0


[PATCH 1/3] arm64: allwinner: dts: a64: pinetab: switch LCD panel to production one

2020-11-07 Thread Icenowy Zheng
All retail PineTabs use the new panel. Devices with the old panel are
only available to several developers as sample.

Switch the main PineTab DT to use the new panel, as it should reflect
what the retail device uses. Another DT for developers' sample will be
added later.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
index 0494bfaf2ffa..d91a019301bf 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -150,12 +150,10 @@ &dsi {
status = "okay";
 
panel@0 {
-   compatible = "feixin,k101-im2ba02";
+   compatible = "feixin,k101-im2byl02";
reg = <0>;
-   avdd-supply = <®_dc1sw>;
-   dvdd-supply = <®_dc1sw>;
-   cvdd-supply = <®_ldo_io1>;
-   reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+   power-supply = <®_dc1sw>;
+   reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
backlight = <&backlight>;
};
 };
-- 
2.28.0


[PATCH 2/3] dt-bindings: arm: sunxi: add PineTab developer sample DT binding

2020-11-07 Thread Icenowy Zheng
Some developer samples of PineTab are distributed with the old and
incompatible LCD panel.

Add a device tree binding for this version of PineTab.

Signed-off-by: Icenowy Zheng 
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml 
b/Documentation/devicetree/bindings/arm/sunxi.yaml
index ea07f57379d3..9cc5990dc311 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -682,6 +682,11 @@ properties:
   - const: pine64,pinetab
   - const: allwinner,sun50i-a64
 
+  - description: Pine64 PineTab (Developer sample with the old LCD panel)
+items:
+  - const: pine64,pinetab-dev
+  - const: allwinner,sun50i-a64
+
   - description: Pine64 SoPine Baseboard
 items:
   - const: pine64,sopine-baseboard
-- 
2.28.0


Re: [PATCH v2 2/8] firmware: arm_scmi: introduce protocol handles

2020-11-07 Thread Cristian Marussi
Hi Thara

thanks for the feedback.

On Fri, Nov 06, 2020 at 11:26:44AM -0500, Thara Gopinath wrote:
> 
> 
> On 11/4/20 12:44 PM, Cristian Marussi wrote:
> > Hi
> > 
> > On Wed, Nov 04, 2020 at 11:16:18AM -0500, Thara Gopinath wrote:
> > > 
> > > Hi Cristian,
> > > 
> > > On 10/28/20 4:29 PM, Cristian Marussi wrote:
> > > > Add basic protocol handles definitions and helpers support.
> > > > All protocols initialization code and SCMI drivers probing is still
> > > > performed using the handle based interface.
> > > > 
> > > > Signed-off-by: Cristian Marussi 
> > > > ---
> > > >drivers/firmware/arm_scmi/common.h | 61 
> > > >drivers/firmware/arm_scmi/driver.c | 64 
> > > > ++
> > > >2 files changed, 125 insertions(+)
> > > > 
> > > > diff --git a/drivers/firmware/arm_scmi/common.h 
> > > > b/drivers/firmware/arm_scmi/common.h
> > > > index b08a8ddbc22a..f0678be02a09 100644
> > > > --- a/drivers/firmware/arm_scmi/common.h
> > > > +++ b/drivers/firmware/arm_scmi/common.h
> > > > @@ -151,6 +151,67 @@ int scmi_xfer_get_init(const struct scmi_handle 
> > > > *h, u8 msg_id, u8 prot_id,
> > > >size_t tx_size, size_t rx_size, struct scmi_xfer 
> > > > **p);
> > > >void scmi_reset_rx_to_maxsz(const struct scmi_handle *handle,
> > > > struct scmi_xfer *xfer);
> > > > +
> > > > +struct scmi_xfer_ops;
> > > > +
> > > > +/**
> > > > + * struct scmi_protocol_handle  - Reference to an initialized protocol 
> > > > instance
> > > > + *
> > > > + * @dev: A reference to the associated SCMI instance device 
> > > > (handle->dev).
> > > > + * @xops: A reference to a struct holding refs to the core xfer 
> > > > operations that
> > > > + *   can be used by the protocol implementation to generate SCMI 
> > > > messages.
> > > > + * @set_priv: A method to set protocol private data for this instance.
> > > > + * @get_priv: A method to get protocol private data previously set.
> > > > + *
> > > > + * This structure represents a protocol initialized against specific 
> > > > SCMI
> > > > + * instance and it will be used as follows:
> > > > + * - as a parameter fed from the core to the protocol initialization 
> > > > code so
> > > > + *   that it can access the core xfer operations to build and generate 
> > > > SCMI
> > > > + *   messages exclusively for the specific underlying protocol 
> > > > instance.
> > > > + * - as an opaque handle fed by an SCMI driver user when it tries to 
> > > > access
> > > > + *   this protocol through its own protocol operations.
> > > > + *   In this case this handle will be returned as an opaque object 
> > > > together
> > > > + *   with the related protocol operations when the SCMI driver tries 
> > > > to access
> > > > + *   the protocol.
> > > > + */
> > > > +struct scmi_protocol_handle {
> > > > +   struct device *dev;
> > > > +   const struct scmi_xfer_ops *xops;
> > > > +   int (*set_priv)(const struct scmi_protocol_handle *ph, void 
> > > > *priv);
> > > > +   void *(*get_priv)(const struct scmi_protocol_handle *ph);
> > > > +};
> > > 
> > > So scmi_xfer_ops are the ops that actually talks with the scmi firmware on
> > > the other end , right ? IIUC, these ops are the same for all the protocols
> > > of a scmi instance. Imho, this struct is not the right place for these ops
> > > to reside.You are inadvertently exposing scmi internal details to the 
> > > client
> > > drivers. There is no reason why this should be part of scmi_handle. The
> > > protocols can extract it from the handle during protocol_reigster, right?
> > > 
> > > So, now to the second part, why do you need a scmi_protocol_handle? Again
> > > IIUC, if you have set_priv and get_priv hooks and get_ops and put_ops 
> > > hooks,
> > > there is nothing that scmi_protocol_handle is providing extra, right? As
> > > mentioned in the comments for last patch any reason all of this cannot be
> > > rolled into scmi_protocol?
> > 
> > The basic idea for protocol_hande existence is that the protocol code
> > should be able to access the core xfer ops (without EXPORTing all
> > scmi_xfer ops) but protoX should NOT be allowed to mistakenly or
> > maliciously build and send protoY messages: since the protocol_handle
> > for protoX is embedded in a specific protocol_instance in this way you
> > can call from your protocol code something like:
> > 
> > ph->xops->xfer_get_init(ph, ...)
> 
> I am still confused by this one... scmi_protocol_instance has a pointer to
> scmi_handle. So why not handle->xops->xfer_get_init(pi, ). Here also
> protoX will not be allowed to send protoY messages, right? And then again
> set_priv and get_priv can be moved to scmi_protocol_instance right ?
> 

So given that there a number of different 'actors' playing in the SCMI
stack, the basic idea/attempt in general was to expose to each single actor
just the bare minimum needed data structs with the bare minimum needed leve

[PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

2020-11-07 Thread Icenowy Zheng
Some developers received PineTab samples that used an old LCD panel.

Add device tree for these samples.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/Makefile|  1 +
 .../dts/allwinner/sun50i-a64-pinetab-dev.dts  | 28 +++
 2 files changed, 29 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index 211d1e9d4701..a221dcebfad4 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.0.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
new file mode 100644
index ..3a4153890f3e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2020 Icenowy Zheng 
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-pinetab.dts"
+
+/ {
+   model = "PineTab Developer Sample";
+   compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
+};
+
+&dsi {
+   /delete-node/ panel@0;
+
+   panel@0 {
+   compatible = "feixin,k101-im2ba02";
+   reg = <0>;
+   avdd-supply = <®_dc1sw>;
+   dvdd-supply = <®_dc1sw>;
+   cvdd-supply = <®_ldo_io1>;
+   reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+   backlight = <&backlight>;
+   };
+};
-- 
2.28.0


Re: [PATCH] net/dsa: remove unused macros to tame gcc warning

2020-11-07 Thread Alex Shi



在 2020/11/7 上午12:39, Florian Fainelli 写道:
>> Hi Alex
>>
>> It is good to remember that there are multiple readers of source
>> files. There is the compiler which generates code from it, and there
>> is the human trying to understand what is going on, what the hardware
>> can do, how we could maybe extend the code in the future to make use
>> of bits are currently don't, etc.
>>
>> The compiler has no use of these macros, at the moment. But i as a
>> human do. It is valuable documentation, given that there is no open
>> datasheet for this hardware.
>>
>> I would say these warnings are bogus, and the code should be left
>> alone.
> Agreed, these definitions are intended to document what the hardware
> does. These warnings are getting too far.
> -- 

Thanks for all comments! I agree these info are much meaningful.
Is there other way to tame the gcc warning? like put them into a .h file
or covered by comments?

Thanks
Alex


Re: [PATCH] net/xdp: remove unused macro REG_STATE_NEW

2020-11-07 Thread Alex Shi



在 2020/11/7 上午12:13, Jesper Dangaard Brouer 写道:
> Hmm... REG_STATE_NEW is zero, so it is implicitly set via memset zero.
> But it is true that it is technically not directly used or referenced.
> 
> It is mentioned in a comment, so please send V2 with this additional change:

Hi Jesper,

Thanks a lot for comments. here is the v2:

>From 2908d25bf2e1c90ad71a83ba056743f45da283e8 Mon Sep 17 00:00:00 2001
From: Alex Shi 
Date: Fri, 6 Nov 2020 13:41:58 +0800
Subject: [PATCH v2] net/xdp: remove unused macro REG_STATE_NEW

To tame gcc warning on it:
net/core/xdp.c:20:0: warning: macro "REG_STATE_NEW" is not used
[-Wunused-macros]
And change related comments as Jesper Dangaard Brouer suggested.

Signed-off-by: Alex Shi 
---
 net/core/xdp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/core/xdp.c b/net/core/xdp.c
index 48aba933a5a8..0df5ee5682d9 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 
-#define REG_STATE_NEW  0x0
 #define REG_STATE_REGISTERED   0x1
 #define REG_STATE_UNREGISTERED 0x2
 #define REG_STATE_UNUSED   0x3
@@ -175,7 +174,7 @@ int xdp_rxq_info_reg(struct xdp_rxq_info *xdp_rxq,
return -ENODEV;
}
 
-   /* State either UNREGISTERED or NEW */
+   /* State either UNREGISTERED or zero */
xdp_rxq_info_init(xdp_rxq);
xdp_rxq->dev = dev;
xdp_rxq->queue_index = queue_index;
-- 
1.8.3.1



  1   2   3   4   >