Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ

2019-06-10 Thread Kalle Valo
Eugeniu Rosca  writes:

> The wl1837mod datasheet [1] says about the WL_IRQ pin:
>
>  ---8<---
> SDIO available, interrupt out. Active high. [..]
> Set to rising edge (active high) on powerup.
>  ---8<---
>
> That's the reason of seeing the interrupt configured as:
>  - IRQ_TYPE_EDGE_RISING on HiKey 960/970
>  - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms
>
> We assert that all those platforms have the WL_IRQ pin connected
> to the SoC _directly_ (confirmed on HiKey 970 [2]).
>
> That's not the case for R-Car Kingfisher extension target, which carries
> a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present
> between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively
> reversing the requirement quoted from [1]. IOW, in Kingfisher DTS
> configuration we would need to use IRQ_TYPE_EDGE_FALLING or
> IRQ_TYPE_LEVEL_LOW.
>
> Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq:
> support platform dependent interrupt types") made a special case out
> of these interrupt types. After this commit, it is impossible to provide
> an IRQ configuration via DTS which would describe an inverter present
> between the WL18* chip and the SoC, generating the need for workarounds
> like [3].
>
> Create a boolean OF property, called "invert-irq" to specify that
> the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter.
>
> This solution has been successfully tested on R-Car H3ULCB-KF-M06 using
> the DTS configuration [4] combined with the "invert-irq" property.
>
> [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
> [2] 
> https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/
> [3] 
> https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WL-side.patch
> [4] https://patchwork.kernel.org/patch/10895879/
> ("arm64: dts: ulcb-kf: Add support for TI WL1837")
>
> Signed-off-by: Eugeniu Rosca 

Tony&Eyal, do you agree with this?

-- 
Kalle Valo


[RFC PATCH v1 3/3] LSM/x86/sgx: Call new LSM hooks from SGX subsystem

2019-06-10 Thread Cedric Xing
There are three places LSM hooks are called from within the SGX subsystem.

The first place is to invoke security_file_mprotect() in sgx_mmap() to validate
requested protection. Given the architecture of SGX subsystem, all enclaves
look like file mappings of /dev/sgx/enclave device file, meaning the existing
security_mmap_file() invoked inside vm_mmap_pgoff() cannot provide any
meaningful information to LSM. Based on the idea that mmap(prot) is equivalent
to mmap(PROT_NONE) followed by mprotect(prot), security_file_mprotect() shall
be queried with more specific enclave/page information.

Secondly, security_enclave_load() is invoked upon loading of every enclave
page.

Lastly, security_enclave_init() is invoked before initializing (EINIT) every
enclave.

Signed-off-by: Cedric Xing 
---
 arch/x86/kernel/cpu/sgx/driver/ioctl.c | 72 +++---
 arch/x86/kernel/cpu/sgx/driver/main.c  | 12 -
 2 files changed, 74 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/cpu/sgx/driver/ioctl.c 
b/arch/x86/kernel/cpu/sgx/driver/ioctl.c
index b186fb7b48d5..a3f22a6f6d2b 100644
--- a/arch/x86/kernel/cpu/sgx/driver/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/driver/ioctl.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "driver.h"
 
 struct sgx_add_page_req {
@@ -575,6 +576,42 @@ static int sgx_encl_add_page(struct sgx_encl *encl, 
unsigned long addr,
return ret;
 }
 
+static int sgx_encl_prepare_page(struct file *filp, unsigned long dst,
+unsigned long src, void *buf)
+{
+   struct vm_area_struct *vma;
+   unsigned long prot;
+   int rc = 0;
+
+   if (dst & ~PAGE_SIZE)
+   return -EINVAL;
+
+   down_read(¤t->mm->mmap_sem);
+
+   vma = find_vma(current->mm, dst);
+   if (vma && dst >= vma->vm_start)
+   prot = vma->vm_flags & (VM_READ | VM_WRITE | VM_EXEC);
+   else
+   prot = 0;
+
+   vma = find_vma(current->mm, src);
+   if (!vma || src < vma->vm_start || src + PAGE_SIZE > vma->vm_end)
+   rc = -EFAULT;
+
+   if (!rc && !(vma->vm_flags & VM_MAYEXEC))
+   rc = -EACCES;
+
+   if (!rc)
+   rc = security_enclave_load(filp, dst, PAGE_SIZE, prot, vma);
+
+   if (!rc && copy_from_user(buf, (void __user *)src, PAGE_SIZE))
+   rc = -EFAULT;
+
+   up_read(¤t->mm->mmap_sem);
+
+   return rc;
+}
+
 /**
  * sgx_ioc_enclave_add_page - handler for %SGX_IOC_ENCLAVE_ADD_PAGE
  *
@@ -613,10 +650,9 @@ static long sgx_ioc_enclave_add_page(struct file *filep, 
unsigned int cmd,
 
data = kmap(data_page);
 
-   if (copy_from_user((void *)data, (void __user *)addp->src, PAGE_SIZE)) {
-   ret = -EFAULT;
+   ret = sgx_encl_prepare_page(filep, addp->addr, addp->src, data);
+   if (ret)
goto out;
-   }
 
ret = sgx_encl_add_page(encl, addp->addr, data, &secinfo, addp->mrmask);
if (ret)
@@ -718,6 +754,29 @@ static int sgx_encl_init(struct sgx_encl *encl, struct 
sgx_sigstruct *sigstruct,
return ret;
 }
 
+static int sgx_encl_prepare_sigstruct(struct file *filp, unsigned long src,
+ struct sgx_sigstruct *ss)
+{
+   struct vm_area_struct *vma;
+   int rc = 0;
+
+   down_read(¤t->mm->mmap_sem);
+
+   vma = find_vma(current->mm, src);
+   if (!vma || src < vma->vm_start || src + sizeof(*ss) > vma->vm_end)
+   rc = -EFAULT;
+
+   if (!rc && copy_from_user(ss, (void __user *)src, sizeof(*ss)))
+   rc = -EFAULT;
+
+   if (!rc)
+   rc = security_enclave_init(filp, ss, vma);
+
+   up_read(¤t->mm->mmap_sem);
+
+   return rc;
+}
+
 /**
  * sgx_ioc_enclave_init - handler for %SGX_IOC_ENCLAVE_INIT
  *
@@ -753,12 +812,9 @@ static long sgx_ioc_enclave_init(struct file *filep, 
unsigned int cmd,
((unsigned long)sigstruct + PAGE_SIZE / 2);
memset(einittoken, 0, sizeof(*einittoken));
 
-   if (copy_from_user(sigstruct, (void __user *)initp->sigstruct,
-  sizeof(*sigstruct))) {
-   ret = -EFAULT;
+   ret = sgx_encl_prepare_sigstruct(filep, initp->sigstruct, sigstruct);
+   if (ret)
goto out;
-   }
-
 
ret = sgx_encl_init(encl, sigstruct, einittoken);
 
diff --git a/arch/x86/kernel/cpu/sgx/driver/main.c 
b/arch/x86/kernel/cpu/sgx/driver/main.c
index 58ba6153070b..c634df440c16 100644
--- a/arch/x86/kernel/cpu/sgx/driver/main.c
+++ b/arch/x86/kernel/cpu/sgx/driver/main.c
@@ -63,14 +63,22 @@ static long sgx_compat_ioctl(struct file *filep, unsigned 
int cmd,
 static int sgx_mmap(struct file *file, struct vm_area_struct *vma)
 {
struct sgx_encl *encl = file->private_data;
+   unsigned long prot;
+   int rc;
 
vma->vm_ops = &sgx_vm_ops;
vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
vma->vm_private_data = encl;
 

[RFC PATCH v1 0/3] security/x86/sgx: SGX specific LSM hooks

2019-06-10 Thread Cedric Xing
This series intends to make the new SGX subsystem and the existing LSM
architecture work together smoothly so that, say, SGX cannot be abused to work
around restrictions set forth by LSM. This series applies on top of Jarkko
Sakkinen's SGX series v20 (https://lkml.org/lkml/2019/4/17/344), where abundant
details of this SGX/LSM problem could be found.

This series is an alternative to Sean Christopherson's recent RFC series
(https://lkml.org/lkml/2019/6/5/1070) that was trying to solve the same
problem. The key problem is for LSM to determine the "maximal (most permissive)
protection" allowed for individual enclave pages. Sean's approach is to take
that from user mode code as a parameter of the EADD ioctl, validate it with LSM
ahead of time, and then enforce it inside the SGX subsystem. The major
disadvantage IMHO is that a priori knowledge of "maximal protection" is needed,
but it isn't always available in certain use cases. In fact, it is an unusual
approach to take "maximal protection" from user code, as what SELinux is doing
today is to determine "maximal protection" of a vma using attributes associated
with vma->vm_file instead. When it comes to enclaves, vma->vm_file always
points /dev/sgx/enclave, so what's missing is a new way for LSM modules to
remember origins of enclave pages so that they don't solely depend on
vma->vm_file to determine "maximal protection".

This series takes advantage of the fact that enclave pages cannot be remapped
(to different linear address), therefore the pair of { vma->vm_file,
linear_address } can be used to uniquely identify an enclave page. Then by
notifying LSM on creation of every enclave page (via a new LSM hook -
security_enclave_load), LSM modules would be able to track origin and
protection changes of every page, hence be able to judge correctly upon
mmap/mprotect requests.

Cedric Xing (3):
  LSM/x86/sgx: Add SGX specific LSM hooks
  LSM/x86/sgx: Implement SGX specific hooks in SELinux
  LSM/x86/sgx: Call new LSM hooks from SGX subsystem

 arch/x86/kernel/cpu/sgx/driver/ioctl.c |  72 +-
 arch/x86/kernel/cpu/sgx/driver/main.c  |  12 +-
 include/linux/lsm_hooks.h  |  33 +++
 include/linux/security.h   |  26 +++
 security/security.c|  21 ++
 security/selinux/Makefile  |   2 +
 security/selinux/hooks.c   |  77 ++-
 security/selinux/include/intel_sgx.h   |  18 ++
 security/selinux/include/objsec.h  |   3 +
 security/selinux/intel_sgx.c   | 292 +
 10 files changed, 545 insertions(+), 11 deletions(-)
 create mode 100644 security/selinux/include/intel_sgx.h
 create mode 100644 security/selinux/intel_sgx.c

-- 
2.17.1



[RFC PATCH v1 2/3] LSM/x86/sgx: Implement SGX specific hooks in SELinux

2019-06-10 Thread Cedric Xing
In this patch, SELinux maintains two bits per enclave page, namely SGX__EXECUTE
and SGX__EXECMOD.

SGX__EXECUTE is set initially (by selinux_enclave_load) for every enclave page
that was loaded from a potentially executable source page. SGX__EXECMOD is set
for every page that was loaded from a file that has FILE__EXECMOD.

At runtime, on every protection change (resulted in a call to
selinux_file_mprotect), SGX__EXECUTE is cleared for a page if VM_WRITE is
requested, unless SGX__EXECMOD is set.

To track enclave page protection changes, SELinux has been changed in four
different places.

Firstly, storage is required for storing per page SGX__EXECUTE and SGX__EXECMOD
bits. Given every enclave instance is uniquely tied to an open file (i.e.
struct file), the storage is allocated by extending `file_security_struct`.
More precisely, a new field `esec` has been added, initially zero, to point to
the data structure for tracking per page protection. `esec` will be
allocated/initialized at the first invocation of selinux_enclave_load().

Then, selinux_enclave_load() initializes those 2 bits for every new enclave as
described above. One more detail worth noting, is that selinux_enclave_load()
sets SGX__EXECUTE/SGX__EXECMOD for EAUG'ed pages (for upcoming SGX2) only if
the calling process has FILE__EXECMOD on the sigstruct file.

Afterwards, every change on protection will go through selinux_file_mprotect()
so will be noted. Please note that user space could munmap() then mmap() to
work around mprotect(), but that "leak" could be "plugged" by SGX subsystem
calling security_file_mprotect() explicitly whenever new mappings are created.

Finally, the storage for page protection tracking must be freed when the
associated file is closed. Hence a new selinux_file_free_security() has been
added.

Signed-off-by: Cedric Xing 
---
 security/selinux/Makefile|   2 +
 security/selinux/hooks.c |  77 ++-
 security/selinux/include/intel_sgx.h |  18 ++
 security/selinux/include/objsec.h|   3 +
 security/selinux/intel_sgx.c | 292 +++
 5 files changed, 391 insertions(+), 1 deletion(-)
 create mode 100644 security/selinux/include/intel_sgx.h
 create mode 100644 security/selinux/intel_sgx.c

diff --git a/security/selinux/Makefile b/security/selinux/Makefile
index ccf950409384..58a05a9639e0 100644
--- a/security/selinux/Makefile
+++ b/security/selinux/Makefile
@@ -14,6 +14,8 @@ selinux-$(CONFIG_SECURITY_NETWORK_XFRM) += xfrm.o
 
 selinux-$(CONFIG_NETLABEL) += netlabel.o
 
+selinux-$(CONFIG_INTEL_SGX) += intel_sgx.o
+
 ccflags-y := -I$(srctree)/security/selinux 
-I$(srctree)/security/selinux/include
 
 $(addprefix $(obj)/,$(selinux-y)): $(obj)/flask.h
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 3ec702cf46ca..17f855871a41 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -103,6 +103,7 @@
 #include "netlabel.h"
 #include "audit.h"
 #include "avc_ss.h"
+#include "intel_sgx.h"
 
 struct selinux_state selinux_state;
 
@@ -3485,6 +3486,11 @@ static int selinux_file_alloc_security(struct file *file)
return file_alloc_security(file);
 }
 
+static void selinux_file_free_security(struct file *file)
+{
+   sgxsec_enclave_free(file);
+}
+
 /*
  * Check whether a task has the ioctl permission and cmd
  * operation to an inode.
@@ -3656,6 +3662,7 @@ static int selinux_file_mprotect(struct vm_area_struct 
*vma,
 unsigned long reqprot,
 unsigned long prot)
 {
+   int rc;
const struct cred *cred = current_cred();
u32 sid = cred_sid(cred);
 
@@ -3664,7 +3671,7 @@ static int selinux_file_mprotect(struct vm_area_struct 
*vma,
 
if (default_noexec &&
(prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) {
-   int rc = 0;
+   rc = 0;
if (vma->vm_start >= vma->vm_mm->start_brk &&
vma->vm_end <= vma->vm_mm->brk) {
rc = avc_has_perm(&selinux_state,
@@ -3691,6 +3698,12 @@ static int selinux_file_mprotect(struct vm_area_struct 
*vma,
return rc;
}
 
+#ifdef CONFIG_INTEL_SGX
+   rc = sgxsec_mprotect(vma, prot);
+   if (rc <= 0)
+   return rc;
+#endif
+
return file_map_prot_check(vma->vm_file, prot, vma->vm_flags&VM_SHARED);
 }
 
@@ -6726,6 +6739,62 @@ static void selinux_bpf_prog_free(struct bpf_prog_aux 
*aux)
 }
 #endif
 
+#ifdef CONFIG_INTEL_SGX
+
+static int selinux_enclave_load(struct file *encl, unsigned long addr,
+   unsigned long size, unsigned long prot,
+   struct vm_area_struct *source)
+{
+   if (source) {
+   /**
+* Adding page from source => EADD request
+*/
+   int rc = selinux_file_mprotect(source, prot, prot);
+   if (rc)
+   return rc;
+
+  

[RFC PATCH v1 1/3] LSM/x86/sgx: Add SGX specific LSM hooks

2019-06-10 Thread Cedric Xing
This patch has made two changes to LSM hooks.

The first change is the addition of two new SGX specific LSM hooks.

security_enclave_load() - is called whenever new EPC pages are added to an
enclave, so that an LSM module could initialize internal states for those
pages. An LSM module may track protections ever granted to enclave pages in
order to come to reasonable decisions in security_file_mprotect() hook in
future.

security_enclave_init() - is called when an enclave is about to be intialized
(by EINIT). An LSM module may approve/decline the request by looking into the
SIGSTRUCT, or the file from which the SIGSTRUCT was loaded from.

The second change is to export symbol security_file_mprotect() to make it
available to kernel modules. The SGX module will invoke
security_file_mprotect() to validate protection for the virtual memory range
being mmap()'ed.

Please see include/linux/lsm_hooks.h for more information.

Signed-off-by: Cedric Xing 
---
 include/linux/lsm_hooks.h | 33 +
 include/linux/security.h  | 26 ++
 security/security.c   | 21 +
 3 files changed, 80 insertions(+)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 47f58cfb6a19..ceb18c5c25f3 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1446,6 +1446,27 @@
  * @bpf_prog_free_security:
  * Clean up the security information stored inside bpf prog.
  *
+ * Security hooks for SGX enclaves
+ *
+ * @enclave_load:
+ * Check permissions before loading pages into enclaves. Must be called
+ * with current->mm->mmap_sem locked.
+ * @encl: file pointer identifying the enclave
+ * @addr: linear address to which new pages are being added. Must be page
+ * aligned
+ * @size: total size of pages being added. Must be integral multiple of
+ * page size
+ * @prot: requested protection. Shall be the same protection as the VMA
+ * covering the target linear range, or 0 if target range not mapped
+ * @source: the VMA containing the source pages. Shall be NULL if there's
+ * no source pages (e.g. EAUG)
+ *
+ * @enclave_init:
+ * Check SIGSTRUCT before initializing (EINIT) enclaves. Must be called
+ * with current->mm->mmap_sem locked.
+ * @encl: file pointer identifying the enclave being initialized
+ * @sigstruct: pointer to sigstruct in kernel memory
+ * @sigstruct_vma: vma containing the original sigstruct in user space
  */
 union security_list_options {
int (*binder_set_context_mgr)(struct task_struct *mgr);
@@ -1807,6 +1828,14 @@ union security_list_options {
int (*bpf_prog_alloc_security)(struct bpf_prog_aux *aux);
void (*bpf_prog_free_security)(struct bpf_prog_aux *aux);
 #endif /* CONFIG_BPF_SYSCALL */
+#ifdef CONFIG_INTEL_SGX
+   int (*enclave_load)(struct file *encl, unsigned long addr,
+   unsigned long size, unsigned long prot,
+   struct vm_area_struct *source);
+   int (*enclave_init)(struct file *encl,
+   const struct sgx_sigstruct *sigstruct,
+   struct vm_area_struct *sigstruct_vma);
+#endif /* CONFIG_INTEL_SGX */
 };
 
 struct security_hook_heads {
@@ -2046,6 +2075,10 @@ struct security_hook_heads {
struct hlist_head bpf_prog_alloc_security;
struct hlist_head bpf_prog_free_security;
 #endif /* CONFIG_BPF_SYSCALL */
+#ifdef CONFIG_INTEL_SGX
+   struct hlist_head enclave_load;
+   struct hlist_head enclave_init;
+#endif /* CONFIG_INTEL_SGX */
 } __randomize_layout;
 
 /*
diff --git a/include/linux/security.h b/include/linux/security.h
index 659071c2e57c..d44655dd06dd 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1829,5 +1829,31 @@ static inline void security_bpf_prog_free(struct 
bpf_prog_aux *aux)
 #endif /* CONFIG_SECURITY */
 #endif /* CONFIG_BPF_SYSCALL */
 
+#ifdef CONFIG_INTEL_SGX
+struct sgx_sigstruct;
+#ifdef CONFIG_SECURITY
+extern int security_enclave_load(struct file *encl, unsigned long addr,
+unsigned long size, unsigned long prot,
+struct vm_area_struct *source);
+extern int security_enclave_init(struct file *encl,
+const struct sgx_sigstruct *sigstruct,
+struct vm_area_struct *sigstruct_vma);
+#else
+static inline int security_enclave_load(struct file *encl, unsigned long addr,
+   unsigned long size, unsigned long prot,
+   struct vm_area_struct *source)
+{
+   return 0;
+}
+
+static inline int security_enclave_init(struct file *encl,
+   const struct sigstruct *sigstruct,
+   struct vm_area_struct *sigstruct_vma)
+{
+   return 0;
+}
+#endif /* CONFIG_SECURITY */
+#endif /* CONFIG_INTE

Re: [PATCH] hwmon: pmbus: protect read-modify-write with lock

2019-06-10 Thread Wolfram Sang
Hi Krzysztof,

> patch and send it to the wrong list of people. You can ignore this
> patchset, it was resent to the proper mailing list instead.

Thanks for the heads up.

Regards,

   Wolfram



signature.asc
Description: PGP signature


Re: [PATCH] arm: dts: dra72x: Disable usb4_tm target module

2019-06-10 Thread Tony Lindgren
* Keerthy  [190603 23:13]:
> usb4_tm is unsed on dra72 and accessing the module
> with ti,sysc is causing a boot crash hence disable its target
> module.

Thanks for testing and fixing this, applying into fixes.

Tony


Re: [PATCH v3] vt: Fix a missing-check bug in con_init()

2019-06-10 Thread Jiri Slaby
On 09. 06. 19, 2:15, Nicolas Pitre wrote:
 +fail1:
 +  while (currcons > 0) {
 +  currcons--;
 +  kfree(vc_cons[currcons].d->vc_screenbuf);
 +fail2:
 +  kfree(vc_cons[currcons].d);
 +  vc_cons[currcons].d = NULL;
 +  }
>>
>> Wait, will that even work?  You can jump into the middle of a while
>> loop?
> 
> Absolutely.

In C99, exceptions are only blocks with variable-sized declarations
(like "int a[b]").

thanks,
-- 
js
suse labs


Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting

2019-06-10 Thread Ryder Lee
On Mon, 2019-06-10 at 06:47 +0200, Sebastian Gottschall wrote:
> okay. curious is, that my variant works with sane results too.
> i will test your variant and check the results
> 
> Sebastian

Please don't top post as it's hard to track the thread.

More specifically, IBRSSI is obtained from packet's L-STF portion and
MTK HW PD (packet detection) will take it as a reference. (with
variation more or less)

As for RCPI which is calculated from packet's data portion. The other
MTK chipsets may use IBRSSI as their baseband couldn't report RCPI.

Ryder

> Am 10.06.2019 um 06:22 schrieb Ryder Lee:
> > On Mon, 2019-06-10 at 10:09 +0800, Ryder Lee wrote:
> >> On Sun, 2019-06-09 at 16:44 +0200, Sebastian Gottschall wrote:
> >>> according to my findings
> >>>
> >>> MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
> >>> so it must be rxdg4 = rxd[4] etc.
> >> RXV start from 1 in the code.
> >>
> >> That is: RXV1 <-> rxdg0, RXV2 <-> rxdg1 ...so RXV4 <-> rxdg3
> >>
> >>> however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal 
> >>> calculation.
> >>> i already wrote a similar code for this driver which i sended to felix a 
> >>> long time ago.
> >>> my variant looks like
> >>>   status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 
> >>> 220) / 2;
> >>>   status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, 
> >>> rxdg4) - 220) / 2;
> >>>   status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, 
> >>> rxdg4) - 220) / 2;
> >>>   status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, 
> >>> rxdg4) - 220) / 2;
> >>>   status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, 
> >>> rxdg4) - 220) / 2;
> > mt7615 actually doesn't use in-band RSSI for signal calculation, but it
> > occurs to me that i should modify the code to compare per-chain's
> > signal. Something like this:
> >
> > status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
> > status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
> > status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
> > status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
> > status->signal = status->chain_signal[0];
> >
> > switch (status->chains) {
> > case 0xf:
> > status->signal = max(status->signal,
> >  status->chain_signal[3]);
> > case 0x7:
> > status->signal = max(status->signal,
> >  status->chain_signal[2]);
> > case 0x3:
> > status->signal = max(status->signal,
> >  status->chain_signal[1]);
> > break;
> > default:
> > break;
> > }
> >
> >
> > I could send a v2 or you can take care of that.
> >
> > Ryder
> >
> >




Re: [PATCH] staging: rtl8723bs: core: rtw_mlme_ext.c: Remove unused variables

2019-06-10 Thread Nishka Dasgupta

On 10/06/19 11:19 AM, Greg KH wrote:

On Mon, Jun 10, 2019 at 10:08:21AM +0530, Nishka Dasgupta wrote:

On 09/06/19 4:32 PM, Greg KH wrote:

On Fri, Jun 07, 2019 at 12:41:23PM +0530, Nishka Dasgupta wrote:

Remove variables that are declared and assigned values but not otherwise
used.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 
---
   drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 9 -
   1 file changed, 9 deletions(-)


You sent me 8 patches for this driver, yet only 2 were ordered in a
series.  I have no idea what order to apply these in :(

Please resend them _all_ in a numbered patch series so I have a chance
to get this correct.


Yes, I can do that. Who do I send the patch series to in that case? The
maintainers list is slightly different for each file, and most of the
patches in this driver are for different and unrelated files (except, I
think, the two that I did send as a patch series). Do I combine the
maintainers lists and send the entire patch series to everyone listed as a
maintainer for any one of the patches in it?


The maintainer and mailing list is the same for all of the files in a
single driver.  If not, then something is wrong.


I'm using get_maintainers.pl with no arguments, and for rtl8723bs, I am 
getting a lot of different mailing lists.

E.g
For core/rtw_ieee80211.c, I'm getting the following list:
Greg Kroah-Hartman 
Michael Straube 
Andy Shevchenko 
Hardik Singh Rathore 
Payal Kshirsagar 
Nishka Dasgupta 
de...@driverdev.osuosl.org (open list:STAGING SUBSYSTEM)
linux-kernel@vger.kernel.org (open list)

Which is not the same as for core/rtw_mlme_ext.c (the current patch).


And yes, you can combine the list of people if you wish but be sure you
are not just randomly including people who happened to touch the driver
"last".


Okay, I'll combine then. But is there any metric I should be using to 
filter the output of get_maintainer.pl? Currently I'm running it with no 
arguments and just adding everyone.


Thanking you,
Nishka


greg k-h





Re: [PATCH 08/14] ASoC: Intel: Skylake: Properly cleanup on component removal

2019-06-10 Thread Cezary Rojewski

On 2019-06-05 15:45, Amadeusz Sławiński wrote:

When we remove component we need to reverse things which were done on
init, this consists of topology cleanup, lists cleanup and releasing
firmware.

Currently cleanup handlers are put in wrong places or otherwise missing.
So add proper component cleanup function and perform cleanups in it.

Signed-off-by: Amadeusz Sławiński 
---
  sound/soc/intel/skylake/skl-pcm.c  |  8 ++--
  sound/soc/intel/skylake/skl-topology.c | 15 +++
  sound/soc/intel/skylake/skl-topology.h |  2 ++
  sound/soc/intel/skylake/skl.c  |  2 --
  4 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/sound/soc/intel/skylake/skl-pcm.c 
b/sound/soc/intel/skylake/skl-pcm.c
index 44062806fbed..7e8110c15258 100644
--- a/sound/soc/intel/skylake/skl-pcm.c
+++ b/sound/soc/intel/skylake/skl-pcm.c
@@ -1459,8 +1459,12 @@ static int skl_platform_soc_probe(struct 
snd_soc_component *component)
  
  static void skl_pcm_remove(struct snd_soc_component *component)

  {
-   /* remove topology */
-   snd_soc_tplg_component_remove(component, SND_SOC_TPLG_INDEX_ALL);
+   struct hdac_bus *bus = dev_get_drvdata(component->dev);
+   struct skl *skl = bus_to_skl(bus);
+
+   skl_tplg_exit(component, bus);
+
+   skl_debugfs_exit(skl);
  }
  
  static const struct snd_soc_component_driver skl_component  = {

diff --git a/sound/soc/intel/skylake/skl-topology.c 
b/sound/soc/intel/skylake/skl-topology.c
index 44f3b29a7210..3964262109ac 100644
--- a/sound/soc/intel/skylake/skl-topology.c
+++ b/sound/soc/intel/skylake/skl-topology.c
@@ -3748,3 +3748,18 @@ int skl_tplg_init(struct snd_soc_component *component, 
struct hdac_bus *bus)
  
  	return 0;

  }
+
+void skl_tplg_exit(struct snd_soc_component *component, struct hdac_bus *bus)
+{
+   struct skl *skl = bus_to_skl(bus);
+   struct skl_pipeline *ppl, *tmp;
+
+   if (!list_empty(&skl->ppl_list))
+   list_for_each_entry_safe(ppl, tmp, &skl->ppl_list, node)
+   list_del(&ppl->node);
+
+   /* clean up topology */
+   snd_soc_tplg_component_remove(component, SND_SOC_TPLG_INDEX_ALL);
+
+   release_firmware(skl->tplg);
+}


In debugfs cleanup patch:
[PATCH 07/14] ASoC: Intel: Skylake: Add function to cleanup debugfs 
interface


you define skl_debugfs_exit separately - its usage is split and present 
in this very patch instead. However, for tplg counterpart - 
skl_tplg_exit - you've decided to combine both together. Why not 
separate tplg cleanup too?



diff --git a/sound/soc/intel/skylake/skl-topology.h 
b/sound/soc/intel/skylake/skl-topology.h
index 82282cac9751..7d32c61c73e7 100644
--- a/sound/soc/intel/skylake/skl-topology.h
+++ b/sound/soc/intel/skylake/skl-topology.h
@@ -471,6 +471,8 @@ void skl_tplg_set_be_dmic_config(struct snd_soc_dai *dai,
struct skl_pipe_params *params, int stream);
  int skl_tplg_init(struct snd_soc_component *component,
struct hdac_bus *ebus);
+void skl_tplg_exit(struct snd_soc_component *component,
+   struct hdac_bus *bus);
  struct skl_module_cfg *skl_tplg_fe_get_cpr_module(
struct snd_soc_dai *dai, int stream);
  int skl_tplg_update_pipe_params(struct device *dev,
diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c
index 6d6401410250..e4881ff427ea 100644
--- a/sound/soc/intel/skylake/skl.c
+++ b/sound/soc/intel/skylake/skl.c
@@ -1119,14 +1119,12 @@ static void skl_remove(struct pci_dev *pci)
struct skl *skl = bus_to_skl(bus);
  
  	cancel_work_sync(&skl->probe_work);

-   release_firmware(skl->tplg);
  
  	pm_runtime_get_noresume(&pci->dev);
  
  	/* codec removal, invoke bus_device_remove */

snd_hdac_ext_bus_device_remove(bus);
  
-	skl->debugfs = NULL;

skl_platform_unregister(&pci->dev);
skl_free_dsp(skl);
skl_machine_device_unregister(skl);



Re: [PATCH 4/7] staging: kpc2000: use __func__ in debug messages in core.c

2019-06-10 Thread Simon Sandström
On 06/06, Greg KH wrote:
> On Tue, Jun 04, 2019 at 12:29:13AM +0200, Simon Sandström wrote:
> >  
> > -   dev_dbg(&pdev->dev, "kp2000_pcie_probe(pdev = [%p], id = [%p])\n",
> > -   pdev, id);
> > +   dev_dbg(&pdev->dev, "%s(pdev = [%p], id = [%p])\n",
> > +   __func__, pdev, id);
> 
> debugging lines that say "called this function!" can all be removed, as
> we have ftrace in the kernel tree, we can use that instead.  I'll take
> this, but feel free to clean them up as follow-on patches.
> 
> thanks,
> 
> greg k-h

Can they be removed even if they print function arguments or other
variables?

- Simon


Re: Linux 4.19 and GCC 9

2019-06-10 Thread Ivan Babrou
Looks like 4.19.49 received some patches for GCC 9+, but unfortunately
perf still doesn't want to compile:

[07:15:32]In file included from /usr/include/string.h:635,
[07:15:32] from util/debug.h:7,
[07:15:32] from builtin-help.c:15:
[07:15:32]In function 'strncpy',
[07:15:32] inlined from 'add_man_viewer' at builtin-help.c:192:2,
[07:15:32] inlined from 'perf_help_config' at builtin-help.c:284:3:
[07:15:32]/usr/include/x86_64-linux-gnu/bits/string3.h:126:10: error:
'__builtin_strncpy' output truncated before terminating nul copying as
many bytes from a string as its length [-Werror=stringop-truncation]
[07:15:32] 126 | return __builtin___strncpy_chk (__dest, __src, __len,
__bos (__dest));
[07:15:32] | ^~
[07:15:32]builtin-help.c: In function 'perf_help_config':
[07:15:32]builtin-help.c:187:15: note: length computed here
[07:15:32] 187 | size_t len = strlen(name);
[07:15:32] | ^~~~
[07:15:32]cc1: all warnings being treated as errors



On Fri, May 17, 2019 at 11:27 AM Arnaldo Carvalho de Melo
 wrote:
>
> On May 17, 2019 2:23:10 PM GMT-03:00, Ivan Babrou  wrote:
> >On Fri, May 17, 2019 at 8:22 AM Arnaldo Carvalho de Melo
> > wrote:
> >>
> >> Em Fri, May 17, 2019 at 11:01:45AM +0200, Miguel Ojeda escreveu:
> >> > On Fri, May 17, 2019 at 10:51 AM Greg KH
> > wrote:
> >> > >
> >> > > On Fri, May 17, 2019 at 10:35:29AM +0200, Miguel Ojeda wrote:
> >> > > > On Fri, May 17, 2019 at 9:38 AM Peter Zijlstra
> > wrote:
> >> > > > >
> >> > > > > Right; if there is anything you can reproduce on linus.git
> >I'll happily
> >> > > > > have a look. If it doesn't reproduce all you have to do is
> >find the
> >> > > > > patches that make it work and ask Greg.
> >> > > >
> >> > > > Just to clarify: Linus' master is clean of these issues with
> >GCC 9.1.1.
> >> > >
> >> > > Great!  Care to find the patches that did that work and send me
> >the git
> >> > > commit ids so that I can queue them up?  I don't have gcc9 here
> >yet on
> >> > > my systems, so I can not test for this.
> >> >
> >> > I am unsure about the perf and the objtools parts (Peter/Josh?),
> >but
> >>
> >> I'm not noticing these while building upstream perf with gcc 9.1.1 on
>
> ^^^
>
> >at
> >> least fedora:30.
> >>
> >> 33  fedora:30 : Ok   gcc (GCC) 9.1.1 20190503
> >(Red Hat 9.1.1-1)
> >
> >I've tried to replicate this in fedora:30 docker container and it's
> >there:
> >
> >[root@linuxkit-0251 perf]# gcc --version
> >gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1)
> >
> >[root@linuxkit-0251 perf]# pwd
> >/tmp/linux-4.19.44/tools/perf
>  ^^
>
> That is not upstream perf, please look for patches from 4.19 to Linus' master 
> Branch for fixes.
>
> I'll triple check here in a f30 container just in case meanwhile.
>
> Thanks,
>
> - Arnaldo
> >
> >[root@linuxkit-0251 perf]# make -j1
> >...
> >trace/beauty/ioctl.c: In function ‘ioctl__scnprintf_kvm_cmd’:
> >trace/beauty/ioctl.c:85:82: error: array subscript [-2147483648, -1]
> >is outside array bounds of ‘const char *[0]’ [-Werror=array-bounds]
> >   85 |  if (nr < strarray__kvm_ioctl_cmds.nr_entries &&
> >strarray__kvm_ioctl_cmds.entries[nr] != NULL)
> >  |
> >^~~~
> >In file included from trace/beauty/ioctl.c:82:
> >/tmp/linux-4.19.44/tools/perf/trace/beauty/generated/ioctl/kvm_ioctl_array.c:1:20:
> >note: while referencing ‘kvm_ioctl_cmds’
> >1 | static const char *kvm_ioctl_cmds[] = {
> >  |^~
> >In file included from /usr/include/string.h:494,
> > from util/debug.h:7,
> > from builtin-help.c:15:
> >In function ‘strncpy’,
> >inlined from ‘add_man_viewer’ at builtin-help.c:192:2,
> >inlined from ‘perf_help_config’ at builtin-help.c:284:3:
> >/usr/include/bits/string_fortified.h:106:10: error:
> >‘__builtin_strncpy’ output truncated before terminating nul copying as
> >many bytes from a string as its length [-Werror=stringop-truncation]
> >106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos
> >(__dest));
> >|
> >^~
> >builtin-help.c: In function ‘perf_help_config’:
> >builtin-help.c:187:15: note: length computed here
> >  187 |  size_t len = strlen(name);
> >  |   ^~~~
> >trace/beauty/ioctl.c: In function ‘ioctl__scnprintf_perf_cmd’:
> >trace/beauty/ioctl.c:109:84: error: array subscript [-2147483648, -1]
> >is outside array bounds of ‘const char *[0]’ [-Werror=array-bounds]
> >  109 |  if (nr < strarray__perf_ioctl_cmds.nr_entries &&
> >strarray__perf_ioctl_cmds.entries[nr] != NULL)
> >  |
> >~^~~~
> >In file included from trace/beauty/ioctl.c:106:
> >/tmp/linux-4.19.44/tools/perf/trace/beauty/generated/ioctl/perf_ioctl_array.c:1:20:
> >note: while 

[PATCH] spi: qup: fix PIO/DMA transfers.

2019-06-10 Thread Jorge Ramirez-Ortiz
- DMA/PIO:
  If an error IRQ occurred during PIO or DMA mode make sure to log it so
on completion the transfer can be marked as an error.

- PIO:
  Do not complete a transaction until all data has been transferred or
an error IRQ was flagged.

1) If there was no error IRQ, ignore the done flag IRQ
(QUP_OP_MAX_INPUT_DONE_FLAG) until all data for the transfer has been
processed: not doing so risks completing the transfer returning
uninitialized data in the buffers.

2) Under stress testing we have identified the need to
protect read/write operations against spurious IN/OUT service events.

Signed-off-by: Jorge Ramirez-Ortiz 
---
 drivers/spi/spi-qup.c | 51 ++-
 1 file changed, 45 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index 974a8ce58b68..0a2ffd2f968a 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -281,6 +281,9 @@ static void spi_qup_read(struct spi_qup *controller, u32 
*opflags)
writel_relaxed(QUP_OP_IN_SERVICE_FLAG,
   controller->base + QUP_OPERATIONAL);
 
+   if (!remainder)
+   goto exit;
+
if (is_block_mode) {
num_words = (remainder > words_per_block) ?
words_per_block : remainder;
@@ -310,11 +313,13 @@ static void spi_qup_read(struct spi_qup *controller, u32 
*opflags)
 * to refresh opflags value because MAX_INPUT_DONE_FLAG may now be
 * present and this is used to determine if transaction is complete
 */
-   *opflags = readl_relaxed(controller->base + QUP_OPERATIONAL);
-   if (is_block_mode && *opflags & QUP_OP_MAX_INPUT_DONE_FLAG)
-   writel_relaxed(QUP_OP_IN_SERVICE_FLAG,
-  controller->base + QUP_OPERATIONAL);
-
+exit:
+   if (!remainder) {
+   *opflags = readl_relaxed(controller->base + QUP_OPERATIONAL);
+   if (is_block_mode && *opflags & QUP_OP_MAX_INPUT_DONE_FLAG)
+   writel_relaxed(QUP_OP_IN_SERVICE_FLAG,
+  controller->base + QUP_OPERATIONAL);
+   }
 }
 
 static void spi_qup_write_to_fifo(struct spi_qup *controller, u32 num_words)
@@ -362,6 +367,10 @@ static void spi_qup_write(struct spi_qup *controller)
writel_relaxed(QUP_OP_OUT_SERVICE_FLAG,
   controller->base + QUP_OPERATIONAL);
 
+   /* make sure the interrupt is valid */
+   if (!remainder)
+   return;
+
if (is_block_mode) {
num_words = (remainder > words_per_block) ?
words_per_block : remainder;
@@ -575,10 +584,24 @@ static int spi_qup_do_pio(struct spi_device *spi, struct 
spi_transfer *xfer,
return 0;
 }
 
+static bool spi_qup_data_pending(struct spi_qup *controller)
+{
+   unsigned int remainder_tx, remainder_rx;
+
+   remainder_tx = DIV_ROUND_UP(spi_qup_len(controller) -
+   controller->tx_bytes, controller->w_size);
+
+   remainder_rx = DIV_ROUND_UP(spi_qup_len(controller) -
+   controller->rx_bytes, controller->w_size);
+
+   return remainder_tx || remainder_rx;
+}
+
 static irqreturn_t spi_qup_qup_irq(int irq, void *dev_id)
 {
struct spi_qup *controller = dev_id;
u32 opflags, qup_err, spi_err;
+   unsigned long flags;
int error = 0;
 
qup_err = readl_relaxed(controller->base + QUP_ERROR_FLAGS);
@@ -610,6 +633,11 @@ static irqreturn_t spi_qup_qup_irq(int irq, void *dev_id)
error = -EIO;
}
 
+   spin_lock_irqsave(&controller->lock, flags);
+   if (!controller->error)
+   controller->error = error;
+   spin_unlock_irqrestore(&controller->lock, flags);
+
if (spi_qup_is_dma_xfer(controller->mode)) {
writel_relaxed(opflags, controller->base + QUP_OPERATIONAL);
} else {
@@ -618,11 +646,22 @@ static irqreturn_t spi_qup_qup_irq(int irq, void *dev_id)
 
if (opflags & QUP_OP_OUT_SERVICE_FLAG)
spi_qup_write(controller);
+
+   if (!spi_qup_data_pending(controller))
+   complete(&controller->done);
}
 
-   if ((opflags & QUP_OP_MAX_INPUT_DONE_FLAG) || error)
+   if (error)
complete(&controller->done);
 
+   if (opflags & QUP_OP_MAX_INPUT_DONE_FLAG) {
+   if (!spi_qup_is_dma_xfer(controller->mode)) {
+   if (spi_qup_data_pending(controller))
+   return IRQ_HANDLED;
+   }
+   complete(&controller->done);
+   }
+
return IRQ_HANDLED;
 }
 
-- 
2.21.0



Re: [PATCH] staging: rtl8723bs: core: rtw_mlme_ext.c: Remove unused variables

2019-06-10 Thread Greg KH
On Mon, Jun 10, 2019 at 12:44:05PM +0530, Nishka Dasgupta wrote:
> On 10/06/19 11:19 AM, Greg KH wrote:
> > On Mon, Jun 10, 2019 at 10:08:21AM +0530, Nishka Dasgupta wrote:
> > > On 09/06/19 4:32 PM, Greg KH wrote:
> > > > On Fri, Jun 07, 2019 at 12:41:23PM +0530, Nishka Dasgupta wrote:
> > > > > Remove variables that are declared and assigned values but not 
> > > > > otherwise
> > > > > used.
> > > > > Issue found with Coccinelle.
> > > > > 
> > > > > Signed-off-by: Nishka Dasgupta 
> > > > > ---
> > > > >drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 9 -
> > > > >1 file changed, 9 deletions(-)
> > > > 
> > > > You sent me 8 patches for this driver, yet only 2 were ordered in a
> > > > series.  I have no idea what order to apply these in :(
> > > > 
> > > > Please resend them _all_ in a numbered patch series so I have a chance
> > > > to get this correct.
> > > 
> > > Yes, I can do that. Who do I send the patch series to in that case? The
> > > maintainers list is slightly different for each file, and most of the
> > > patches in this driver are for different and unrelated files (except, I
> > > think, the two that I did send as a patch series). Do I combine the
> > > maintainers lists and send the entire patch series to everyone listed as a
> > > maintainer for any one of the patches in it?
> > 
> > The maintainer and mailing list is the same for all of the files in a
> > single driver.  If not, then something is wrong.
> 
> I'm using get_maintainers.pl with no arguments, and for rtl8723bs, I am
> getting a lot of different mailing lists.
> E.g
> For core/rtw_ieee80211.c, I'm getting the following list:
> Greg Kroah-Hartman 
> Michael Straube 
> Andy Shevchenko 
> Hardik Singh Rathore 
> Payal Kshirsagar 
> Nishka Dasgupta 
> de...@driverdev.osuosl.org (open list:STAGING SUBSYSTEM)
> linux-kernel@vger.kernel.org (open list)
> 
> Which is not the same as for core/rtw_mlme_ext.c (the current patch).
> 
> > And yes, you can combine the list of people if you wish but be sure you
> > are not just randomly including people who happened to touch the driver
> > "last".
> 
> Okay, I'll combine then. But is there any metric I should be using to filter
> the output of get_maintainer.pl? Currently I'm running it with no arguments
> and just adding everyone.

Look at the "role" that each person has.  Here is the output of
get_maintainer.pl when I run it on the first file above:

$ ./scripts/get_maintainer.pl --file 
drivers/staging/rtl8723bs/core/rtw_ieee80211.c
Greg Kroah-Hartman  (supporter:STAGING 
SUBSYSTEM,commit_signer:16/16=100%)
Michael Straube  
(commit_signer:14/16=88%,authored:14/16=88%,added_lines:43/59=73%,removed_lines:114/130=88%)
Payal Kshirsagar  
(commit_signer:1/16=6%,authored:1/16=6%,added_lines:3/59=5%)
Hardik Singh Rathore  
(commit_signer:1/16=6%,authored:1/16=6%,added_lines:13/59=22%,removed_lines:13/130=10%)
Andy Shevchenko  (commit_signer:1/16=6%)
de...@driverdev.osuosl.org (open list:STAGING SUBSYSTEM)
linux-kernel@vger.kernel.org (open list)


That shows that "Greg Kroah-Hartman" is a reviewer for this subsystem,
Michael and Payal and Hardik and Andy have all submitted patches
"recently", and then devel@ is the mailing list for the patches to be
sent to.

So, just include the maintainer and the mailing list and you will be
fine.  No need to bother lkml with staging patches, nor the people who
last sent cleanup patches.

hope this helps,

greg k-h


Re: [PATCH] mm: align up min_free_kbytes to multipy of 4

2019-06-10 Thread Michal Hocko
On Sun 09-06-19 17:10:28, ChenGang wrote:
> Usually the value of min_free_kbytes is multiply of 4,
> and in this case ,the right shift is ok.
> But if it's not, the right-shifting operation will lose the low 2 bits,
> and this cause kernel don't reserve enough memory.
> So it's necessary to align the value of min_free_kbytes to multiply of 4.
> For example, if min_free_kbytes is 64, then should keep 16 pages,
> but if min_free_kbytes is 65 or 66, then should keep 17 pages.

Could you describe the actual problem? Do we ever generate
min_free_kbytes that would lead to unexpected reserves or is this trying
to compensate for those values being configured from the userspace? If
later why do we care at all?

Have you seen this to be an actual problem or is this mostly motivated
by the code reading?

> Signed-off-by: ChenGang 
> ---
>  mm/page_alloc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d66bc8a..1baeeba 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7611,7 +7611,8 @@ static void setup_per_zone_lowmem_reserve(void)
>  
>  static void __setup_per_zone_wmarks(void)
>  {
> - unsigned long pages_min = min_free_kbytes >> (PAGE_SHIFT - 10);
> + unsigned long pages_min =
> + (PAGE_ALIGN(min_free_kbytes * 1024) / 1024) >> (PAGE_SHIFT - 
> 10);
>   unsigned long lowmem_pages = 0;
>   struct zone *zone;
>   unsigned long flags;
> -- 
> 1.8.5.6
> 

-- 
Michal Hocko
SUSE Labs


Re: [PATCH] kernel/isolation: Asset that a housekeeping CPU comes up at boot time

2019-06-10 Thread Nicholas Piggin
Nicholas Piggin's on June 1, 2019 9:39 pm:
> With the change to allow the boot CPU0 to be isolated, it is possible
> to specify command line options that result in no housekeeping CPU
> online at boot.
> 
> An 8 CPU system booted with "nohz_full=0-6 maxcpus=4", for example.
> 
> It is not easily possible at housekeeping init time to know all the
> various SMP options that will result in an invalid configuration, so
> this patch adds a sanity check after SMP init, to ensure that a
> housekeeping CPU has been onlined.
> 
> The panic is undesirable, but it's better than the alternative of an
> obscure non deterministic failure. The panic will reliably happen
> when advanced parameters are used incorrectly.

Ping on this one? This should resolve Frederic's remaining objection
to the series (at least until he solves it more generally).

As the series has already been merged, should we get this upstream
before release?

Thanks,
Nick


Re: [PATCH 4.14 00/35] 4.14.125-stable review

2019-06-10 Thread Naresh Kamboju
On Sun, 9 Jun 2019 at 22:20, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.14.125 release.
> There are 35 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue 11 Jun 2019 04:40:01 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.125-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.14.125-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 396ea3538ca4ce6f760fff7a837e10f2450c5526
git describe: v4.14.123-106-g396ea3538ca4
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.123-106-g396ea3538ca4

No regressions (compared to build v4.14.123)

No fixes (compared to build v4.14.123)

Ran 23749 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-commands-tests
* ltp-hugetlb-tests
* ltp-math-tests
* ltp-mm-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org


[PATCH 00/11] perf intel-pt: Prepare for PEBS via PT

2019-06-10 Thread Adrian Hunter
Hi

PEBS via PT is a new feature that encodes PEBS events into the Intel PT trace.
This patch series is preparation.  Alex has posted his kernel support:

https://lkml.org/lkml/2019/5/2/323

This patch set adds the packet definitions and a new packet decoder test,
followed by patches that enable synthesizing PEBS samples.

 
Adrian Hunter (11):
  perf intel-pt: Add new packets for PEBS via PT
  perf intel-pt: Add Intel PT packet decoder test
  perf intel-pt: Add decoder support for PEBS via PT
  perf intel-pt: Prepare to synthesize PEBS samples
  perf intel-pt: Factor out common sample preparation for re-use
  perf intel-pt: Synthesize PEBS sample basic information
  perf intel-pt: Add gp registers to synthesized PEBS sample
  perf intel-pt: Add xmm registers to synthesized PEBS sample
  perf intel-pt: Add lbr information to synthesized PEBS sample
  perf intel-pt: Add memory information to synthesized PEBS sample
  perf intel-pt: Add callchain to synthesized PEBS sample

 tools/perf/arch/x86/include/arch-tests.h   |   1 +
 tools/perf/arch/x86/tests/Build|   2 +-
 tools/perf/arch/x86/tests/arch-tests.c |   4 +
 .../arch/x86/tests/intel-pt-pkt-decoder-test.c | 304 +
 .../perf/util/intel-pt-decoder/intel-pt-decoder.c  | 114 +++-
 .../perf/util/intel-pt-decoder/intel-pt-decoder.h  | 137 ++
 .../util/intel-pt-decoder/intel-pt-pkt-decoder.c   | 140 +-
 .../util/intel-pt-decoder/intel-pt-pkt-decoder.h   |  21 +-
 tools/perf/util/intel-pt.c | 296 +++-
 9 files changed, 1002 insertions(+), 17 deletions(-)
 create mode 100644 tools/perf/arch/x86/tests/intel-pt-pkt-decoder-test.c


Regards
Adrian



Re: [PATCH v2] kasan: add memory corruption identification for software tag-based mode

2019-06-10 Thread Walter Wu
On Fri, 2019-06-07 at 21:18 +0800, Dmitry Vyukov wrote:
> > diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> > index b40ea104dd36..be0667225b58 100644
> > --- a/include/linux/kasan.h
> > +++ b/include/linux/kasan.h
> > @@ -164,7 +164,11 @@ void kasan_cache_shutdown(struct kmem_cache *cache);
> >
> >  #else /* CONFIG_KASAN_GENERIC */
> >
> > +#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > +void kasan_cache_shrink(struct kmem_cache *cache);
> > +#else
> 
> Please restructure the code so that we don't duplicate this function
> name 3 times in this header.
> 
We have fixed it, Thank you for your reminder.


> >  static inline void kasan_cache_shrink(struct kmem_cache *cache) {}
> > +#endif
> >  static inline void kasan_cache_shutdown(struct kmem_cache *cache) {}
> >
> >  #endif /* CONFIG_KASAN_GENERIC */
> > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> > index 9950b660e62d..17a4952c5eee 100644
> > --- a/lib/Kconfig.kasan
> > +++ b/lib/Kconfig.kasan
> > @@ -134,6 +134,15 @@ config KASAN_S390_4_LEVEL_PAGING
> >   to 3TB of RAM with KASan enabled). This options allows to force
> >   4-level paging instead.
> >
> > +config KASAN_SW_TAGS_IDENTIFY
> > +   bool "Enable memory corruption idenitfication"
> 
> s/idenitfication/identification/
> 
I should replace my glasses.


> > +   depends on KASAN_SW_TAGS
> > +   help
> > + Now tag-based KASAN bug report always shows invalid-access error, 
> > This
> > + options can identify it whether it is use-after-free or 
> > out-of-bound.
> > + This will make it easier for programmers to see the memory 
> > corruption
> > + problem.
> 
> This description looks like a change description, i.e. it describes
> the current behavior and how it changes. I think code comments should
> not have such, they should describe the current state of the things.
> It should also mention the trade-off, otherwise it raises reasonable
> questions like "why it's not enabled by default?" and "why do I ever
> want to not enable it?".
> I would do something like:
> 
> This option enables best-effort identification of bug type
> (use-after-free or out-of-bounds)
> at the cost of increased memory consumption for object quarantine.
> 
I totally agree with your comments. Would you think we should try to add the 
cost?
It may be that it consumes about 1/128th of available memory at full quarantine 
usage rate.


> 
> 
> 
> > +
> >  config TEST_KASAN
> > tristate "Module for testing KASAN for bug detection"
> > depends on m && KASAN
> > diff --git a/mm/kasan/Makefile b/mm/kasan/Makefile
> > index 5d1065efbd47..d8540e5070cb 100644
> > --- a/mm/kasan/Makefile
> > +++ b/mm/kasan/Makefile
> > @@ -19,3 +19,4 @@ CFLAGS_tags.o := $(call cc-option, -fno-conserve-stack 
> > -fno-stack-protector)
> >  obj-$(CONFIG_KASAN) := common.o init.o report.o
> >  obj-$(CONFIG_KASAN_GENERIC) += generic.o generic_report.o quarantine.o
> >  obj-$(CONFIG_KASAN_SW_TAGS) += tags.o tags_report.o
> > +obj-$(CONFIG_KASAN_SW_TAGS_IDENTIFY) += quarantine.o
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 80bbe62b16cd..e309fbbee831 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -81,7 +81,7 @@ static inline depot_stack_handle_t save_stack(gfp_t flags)
> > return depot_save_stack(&trace, flags);
> >  }
> >
> > -static inline void set_track(struct kasan_track *track, gfp_t flags)
> > +void set_track(struct kasan_track *track, gfp_t flags)
> 
> If you make it non-static, it should get kasan_ prefix. The name is too 
> generic.
> 
Ok, We will add it into next version.


> 
> >  {
> > track->pid = current->pid;
> > track->stack = save_stack(flags);
> > @@ -457,7 +457,7 @@ static bool __kasan_slab_free(struct kmem_cache *cache, 
> > void *object,
> > return false;
> >
> > set_track(&get_alloc_info(cache, object)->free_track, GFP_NOWAIT);
> > -   quarantine_put(get_free_info(cache, object), cache);
> > +   quarantine_put(get_free_info(cache, tagged_object), cache);
> >
> > return IS_ENABLED(CONFIG_KASAN_GENERIC);
> >  }
> > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > index 3e0c11f7d7a1..1be04abe2e0d 100644
> > --- a/mm/kasan/kasan.h
> > +++ b/mm/kasan/kasan.h
> > @@ -98,6 +98,12 @@ struct kasan_alloc_meta {
> >  struct qlist_node {
> > struct qlist_node *next;
> >  };
> > +struct qlist_object {
> > +   unsigned long addr;
> > +   unsigned int size;
> > +   struct kasan_track free_track;
> > +   struct qlist_node qnode;
> > +};
> >  struct kasan_free_meta {
> > /* This field is used while the object is in the quarantine.
> >  * Otherwise it might be used for the allocator freelist.
> > @@ -133,11 +139,12 @@ void kasan_report(unsigned long addr, size_t size,
> > bool is_write, unsigned long ip);
> >  void kasan_report_invalid_free(void *object, unsigned long ip);
> >
> > -#if defined(CONFIG_KASAN

[PATCH 01/11] perf intel-pt: Add new packets for PEBS via PT

2019-06-10 Thread Adrian Hunter
Add 3 new packets to supports PEBS via PT, namely Block Begin Packet (BBP),
Block Item Packet (BIP) and Block End Packet (BEP). PEBS data is encoded
into multiple BIP packets that come between BBP and BEP. The BEP packet
might be associated with a FUP packet. That is indicated by using a
separate packet type (INTEL_PT_BEP_IP) similar to other packets types with
the _IP suffix.

Refer to the Intel SDM for more information about PEBS via PT.

Decoding of BIP packets conflicts with single-byte TNT packets. Since BIP
packets only occur in the context of a block (i.e. between BBP and BEP),
that context must be recorded and passed to the packet decoder.

Signed-off-by: Adrian Hunter 
---
 .../util/intel-pt-decoder/intel-pt-decoder.c  |  38 -
 .../intel-pt-decoder/intel-pt-pkt-decoder.c   | 140 +-
 .../intel-pt-decoder/intel-pt-pkt-decoder.h   |  21 ++-
 tools/perf/util/intel-pt.c|   3 +-
 4 files changed, 193 insertions(+), 9 deletions(-)

diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c 
b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
index 9eb778f9c911..44218f9cf16a 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
@@ -140,6 +140,7 @@ struct intel_pt_decoder {
int mtc_shift;
struct intel_pt_stack stack;
enum intel_pt_pkt_state pkt_state;
+   enum intel_pt_pkt_ctx pkt_ctx;
struct intel_pt_pkt packet;
struct intel_pt_pkt tnt;
int pkt_step;
@@ -558,7 +559,7 @@ static int intel_pt_get_split_packet(struct 
intel_pt_decoder *decoder)
memcpy(buf + len, decoder->buf, n);
len += n;
 
-   ret = intel_pt_get_packet(buf, len, &decoder->packet);
+   ret = intel_pt_get_packet(buf, len, &decoder->packet, 
&decoder->pkt_ctx);
if (ret < (int)old_len) {
decoder->next_buf = decoder->buf;
decoder->next_len = decoder->len;
@@ -593,6 +594,7 @@ static int intel_pt_pkt_lookahead(struct intel_pt_decoder 
*decoder,
 {
struct intel_pt_pkt_info pkt_info;
const unsigned char *buf = decoder->buf;
+   enum intel_pt_pkt_ctx pkt_ctx = decoder->pkt_ctx;
size_t len = decoder->len;
int ret;
 
@@ -611,7 +613,8 @@ static int intel_pt_pkt_lookahead(struct intel_pt_decoder 
*decoder,
if (!len)
return INTEL_PT_NEED_MORE_BYTES;
 
-   ret = intel_pt_get_packet(buf, len, &pkt_info.packet);
+   ret = intel_pt_get_packet(buf, len, &pkt_info.packet,
+ &pkt_ctx);
if (!ret)
return INTEL_PT_NEED_MORE_BYTES;
if (ret < 0)
@@ -686,6 +689,10 @@ static int intel_pt_calc_cyc_cb(struct intel_pt_pkt_info 
*pkt_info)
case INTEL_PT_MNT:
case INTEL_PT_PTWRITE:
case INTEL_PT_PTWRITE_IP:
+   case INTEL_PT_BBP:
+   case INTEL_PT_BIP:
+   case INTEL_PT_BEP:
+   case INTEL_PT_BEP_IP:
return 0;
 
case INTEL_PT_MTC:
@@ -878,7 +885,7 @@ static int intel_pt_get_next_packet(struct intel_pt_decoder 
*decoder)
}
 
ret = intel_pt_get_packet(decoder->buf, decoder->len,
- &decoder->packet);
+ &decoder->packet, &decoder->pkt_ctx);
if (ret == INTEL_PT_NEED_MORE_BYTES && BITS_PER_LONG == 32 &&
decoder->len < INTEL_PT_PKT_MAX_SZ && !decoder->next_buf) {
ret = intel_pt_get_split_packet(decoder);
@@ -1624,6 +1631,10 @@ static int intel_pt_walk_psbend(struct intel_pt_decoder 
*decoder)
case INTEL_PT_MWAIT:
case INTEL_PT_PWRE:
case INTEL_PT_PWRX:
+   case INTEL_PT_BBP:
+   case INTEL_PT_BIP:
+   case INTEL_PT_BEP:
+   case INTEL_PT_BEP_IP:
decoder->have_tma = false;
intel_pt_log("ERROR: Unexpected packet\n");
err = -EAGAIN;
@@ -1717,6 +1728,10 @@ static int intel_pt_walk_fup_tip(struct intel_pt_decoder 
*decoder)
case INTEL_PT_MWAIT:
case INTEL_PT_PWRE:
case INTEL_PT_PWRX:
+   case INTEL_PT_BBP:
+   case INTEL_PT_BIP:
+   case INTEL_PT_BEP:
+   case INTEL_PT_BEP_IP:
intel_pt_log("ERROR: Missing TIP after FUP\n");
decoder->pkt_state = INTEL_PT_STATE_ERR3;
decoder->pkt_step = 0;
@@ -2038,6 +2053,12 @@ static int intel_pt_walk_trace(struct intel_pt_decoder 
*decoder)
decoder->state.pwrx_payload = decoder->packet.payload;
return 0;
 
+   case INTEL_PT_BBP:
+   cas

[PATCH 07/11] perf intel-pt: Add gp registers to synthesized PEBS sample

2019-06-10 Thread Adrian Hunter
Add general purpose register information from PEBS data in the Intel PT
trace to the synthesized PEBS sample.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/intel-pt.c | 69 ++
 1 file changed, 69 insertions(+)

diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 4517c02fa478..3a6d5af6a71b 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -43,6 +43,8 @@
 #include "intel-pt.h"
 #include "config.h"
 
+#include "../arch/x86/include/uapi/asm/perf_regs.h"
+
 #include "intel-pt-decoder/intel-pt-log.h"
 #include "intel-pt-decoder/intel-pt-decoder.h"
 #include "intel-pt-decoder/intel-pt-insn-decoder.h"
@@ -1443,6 +1445,60 @@ static int intel_pt_synth_pwrx_sample(struct 
intel_pt_queue *ptq)
pt->pwr_events_sample_type);
 }
 
+/*
+ * PEBS gp_regs array indexes plus 1 so that 0 means not present. Refer
+ * intel_pt_add_gp_regs().
+ */
+static const int pebs_gp_regs[] = {
+   [PERF_REG_X86_FLAGS]= 1,
+   [PERF_REG_X86_IP]   = 2,
+   [PERF_REG_X86_AX]   = 3,
+   [PERF_REG_X86_CX]   = 4,
+   [PERF_REG_X86_DX]   = 5,
+   [PERF_REG_X86_BX]   = 6,
+   [PERF_REG_X86_SP]   = 7,
+   [PERF_REG_X86_BP]   = 8,
+   [PERF_REG_X86_SI]   = 9,
+   [PERF_REG_X86_DI]   = 10,
+   [PERF_REG_X86_R8]   = 11,
+   [PERF_REG_X86_R9]   = 12,
+   [PERF_REG_X86_R10]  = 13,
+   [PERF_REG_X86_R11]  = 14,
+   [PERF_REG_X86_R12]  = 15,
+   [PERF_REG_X86_R13]  = 16,
+   [PERF_REG_X86_R14]  = 17,
+   [PERF_REG_X86_R15]  = 18,
+};
+
+static u64 *intel_pt_add_gp_regs(struct regs_dump *intr_regs, u64 *pos,
+const struct intel_pt_blk_items *items,
+u64 regs_mask)
+{
+   const u64 *gp_regs = items->val[INTEL_PT_GP_REGS_POS];
+   u32 mask = items->mask[INTEL_PT_GP_REGS_POS];
+   u32 bit;
+   int i;
+
+   for (i = 0, bit = 1; i < PERF_REG_X86_64_MAX; i++, bit <<= 1) {
+   /* Get the PEBS gp_regs array index */
+   int n = pebs_gp_regs[i] - 1;
+
+   if (n < 0)
+   continue;
+   /*
+* Add only registers that were requested (i.e. 'regs_mask') and
+* that were provided (i.e. 'mask'), and update the resulting
+* mask (i.e. 'intr_regs->mask') accordingly.
+*/
+   if (mask & 1 << n && regs_mask & bit) {
+   intr_regs->mask |= bit;
+   *pos++ = gp_regs[n];
+   }
+   }
+
+   return pos;
+}
+
 static int intel_pt_synth_pebs_sample(struct intel_pt_queue *ptq)
 {
const struct intel_pt_blk_items *items = &ptq->state->items;
@@ -1493,6 +1549,19 @@ static int intel_pt_synth_pebs_sample(struct 
intel_pt_queue *ptq)
sample.time = tsc_to_perf_time(timestamp, &pt->tc);
}
 
+   if (sample_type & PERF_SAMPLE_REGS_INTR &&
+   items->mask[INTEL_PT_GP_REGS_POS]) {
+   u64 regs[sizeof(sample.intr_regs.mask)];
+   u64 regs_mask = evsel->attr.sample_regs_intr;
+
+   sample.intr_regs.abi = items->is_32_bit ?
+  PERF_SAMPLE_REGS_ABI_32 :
+  PERF_SAMPLE_REGS_ABI_64;
+   sample.intr_regs.regs = regs;
+
+   intel_pt_add_gp_regs(&sample.intr_regs, regs, items, regs_mask);
+   }
+
return intel_pt_deliver_synth_event(pt, ptq, event, &sample, 
sample_type);
 }
 
-- 
2.17.1



[PATCH 10/11] perf intel-pt: Add memory information to synthesized PEBS sample

2019-06-10 Thread Adrian Hunter
Add memory information from PEBS data in the Intel PT trace to the
synthesized PEBS sample. This provides sample types PERF_SAMPLE_ADDR,
PERF_SAMPLE_WEIGHT, and PERF_SAMPLE_TRANSACTION, but not
PERF_SAMPLE_DATA_SRC.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/intel-pt.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index a73d92189b45..0b7beb98a028 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -1662,6 +1662,33 @@ static int intel_pt_synth_pebs_sample(struct 
intel_pt_queue *ptq)
}
}
 
+   if (sample_type & PERF_SAMPLE_ADDR && items->has_mem_access_address)
+   sample.addr = items->mem_access_address;
+
+   if (sample_type & PERF_SAMPLE_WEIGHT) {
+   /*
+* Refer kernel's setup_pebs_adaptive_sample_data() and
+* intel_hsw_weight().
+*/
+   if (items->has_mem_access_latency)
+   sample.weight = items->mem_access_latency;
+   if (!sample.weight && items->has_tsx_aux_info) {
+   /* Cycles last block */
+   sample.weight = (u32)items->tsx_aux_info;
+   }
+   }
+
+   if (sample_type & PERF_SAMPLE_TRANSACTION && items->has_tsx_aux_info) {
+   u64 ax = items->has_rax ? items->rax : 0;
+   /* Refer kernel's intel_hsw_transaction() */
+   u64 txn = (u8)(items->tsx_aux_info >> 32);
+
+   /* For RTM XABORTs also log the abort code from AX */
+   if (txn & PERF_TXN_TRANSACTION && ax & 1)
+   txn |= ((ax >> 24) & 0xff) << PERF_TXN_ABORT_SHIFT;
+   sample.transaction = txn;
+   }
+
return intel_pt_deliver_synth_event(pt, ptq, event, &sample, 
sample_type);
 }
 
-- 
2.17.1



[PATCH 08/11] perf intel-pt: Add xmm registers to synthesized PEBS sample

2019-06-10 Thread Adrian Hunter
Add xmm register information from PEBS data in the Intel PT trace to the
synthesized PEBS sample.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/intel-pt.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 3a6d5af6a71b..0175a4ec248f 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -1499,6 +1499,31 @@ static u64 *intel_pt_add_gp_regs(struct regs_dump 
*intr_regs, u64 *pos,
return pos;
 }
 
+#ifndef PERF_REG_X86_XMM0
+#define PERF_REG_X86_XMM0 32
+#endif
+
+static void intel_pt_add_xmm(struct regs_dump *intr_regs, u64 *pos,
+const struct intel_pt_blk_items *items,
+u64 regs_mask)
+{
+   u32 mask = items->has_xmm & (regs_mask >> PERF_REG_X86_XMM0);
+   const u64 *xmm = items->xmm;
+
+   /*
+* If there are any XMM registers, then there should be all of them.
+* Nevertheless, follow the logic to add only registers that were
+* requested (i.e. 'regs_mask') and that were provided (i.e. 'mask'),
+* and update the resulting mask (i.e. 'intr_regs->mask') accordingly.
+*/
+   intr_regs->mask |= (u64)mask << PERF_REG_X86_XMM0;
+
+   for (; mask; mask >>= 1, xmm++) {
+   if (mask & 1)
+   *pos++ = *xmm;
+   }
+}
+
 static int intel_pt_synth_pebs_sample(struct intel_pt_queue *ptq)
 {
const struct intel_pt_blk_items *items = &ptq->state->items;
@@ -1553,13 +1578,16 @@ static int intel_pt_synth_pebs_sample(struct 
intel_pt_queue *ptq)
items->mask[INTEL_PT_GP_REGS_POS]) {
u64 regs[sizeof(sample.intr_regs.mask)];
u64 regs_mask = evsel->attr.sample_regs_intr;
+   u64 *pos;
 
sample.intr_regs.abi = items->is_32_bit ?
   PERF_SAMPLE_REGS_ABI_32 :
   PERF_SAMPLE_REGS_ABI_64;
sample.intr_regs.regs = regs;
 
-   intel_pt_add_gp_regs(&sample.intr_regs, regs, items, regs_mask);
+   pos = intel_pt_add_gp_regs(&sample.intr_regs, regs, items, 
regs_mask);
+
+   intel_pt_add_xmm(&sample.intr_regs, pos, items, regs_mask);
}
 
return intel_pt_deliver_synth_event(pt, ptq, event, &sample, 
sample_type);
-- 
2.17.1



[PATCH 06/11] perf intel-pt: Synthesize PEBS sample basic information

2019-06-10 Thread Adrian Hunter
Synthesize a PEBS sample using basic information (ip, timestamp) only.
Other PEBS information will be added in later patches.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/intel-pt.c | 52 --
 1 file changed, 50 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 1f5520f964ab..4517c02fa478 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -1443,9 +1443,57 @@ static int intel_pt_synth_pwrx_sample(struct 
intel_pt_queue *ptq)
pt->pwr_events_sample_type);
 }
 
-static int intel_pt_synth_pebs_sample(struct intel_pt_queue *ptq 
__maybe_unused)
+static int intel_pt_synth_pebs_sample(struct intel_pt_queue *ptq)
 {
-   return 0;
+   const struct intel_pt_blk_items *items = &ptq->state->items;
+   struct perf_sample sample = { .ip = 0, };
+   union perf_event *event = ptq->event_buf;
+   struct intel_pt *pt = ptq->pt;
+   struct perf_evsel *evsel = pt->pebs_evsel;
+   u64 sample_type = evsel->attr.sample_type;
+   u64 id = evsel->id[0];
+   u8 cpumode;
+
+   if (intel_pt_skip_event(pt))
+   return 0;
+
+   intel_pt_prep_a_sample(ptq, event, &sample);
+
+   sample.id = id;
+   sample.stream_id = id;
+
+   if (!evsel->attr.freq)
+   sample.period = evsel->attr.sample_period;
+
+   /* No support for non-zero CS base */
+   if (items->has_ip)
+   sample.ip = items->ip;
+   else if (items->has_rip)
+   sample.ip = items->rip;
+   else
+   sample.ip = ptq->state->from_ip;
+
+   /* No support for guest mode at this time */
+   cpumode = sample.ip < ptq->pt->kernel_start ?
+ PERF_RECORD_MISC_USER :
+ PERF_RECORD_MISC_KERNEL;
+
+   event->sample.header.misc = cpumode | PERF_RECORD_MISC_EXACT_IP;
+
+   sample.cpumode = cpumode;
+
+   if (sample_type & PERF_SAMPLE_TIME) {
+   u64 timestamp = 0;
+
+   if (items->has_timestamp)
+   timestamp = items->timestamp;
+   else if (!pt->timeless_decoding)
+   timestamp = ptq->timestamp;
+   if (timestamp)
+   sample.time = tsc_to_perf_time(timestamp, &pt->tc);
+   }
+
+   return intel_pt_deliver_synth_event(pt, ptq, event, &sample, 
sample_type);
 }
 
 static int intel_pt_synth_error(struct intel_pt *pt, int code, int cpu,
-- 
2.17.1



[PATCH 04/11] perf intel-pt: Prepare to synthesize PEBS samples

2019-06-10 Thread Adrian Hunter
Add infrastructure to prepare for synthesizing PEBS samples but leave the
actual synthesis to later patches.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/intel-pt.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index f43d3ac2db8b..389ec4612f86 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -104,6 +104,9 @@ struct intel_pt {
u64 pwrx_id;
u64 cbr_id;
 
+   bool sample_pebs;
+   struct perf_evsel *pebs_evsel;
+
u64 tsc_bit;
u64 mtc_bit;
u64 mtc_freq_bits;
@@ -1431,6 +1434,11 @@ static int intel_pt_synth_pwrx_sample(struct 
intel_pt_queue *ptq)
pt->pwr_events_sample_type);
 }
 
+static int intel_pt_synth_pebs_sample(struct intel_pt_queue *ptq 
__maybe_unused)
+{
+   return 0;
+}
+
 static int intel_pt_synth_error(struct intel_pt *pt, int code, int cpu,
pid_t pid, pid_t tid, u64 ip, u64 timestamp)
 {
@@ -1518,6 +1526,16 @@ static int intel_pt_sample(struct intel_pt_queue *ptq)
ptq->ipc_cyc_cnt = ptq->state->tot_cyc_cnt;
}
 
+   /*
+* Do PEBS first to allow for the possibility that the PEBS timestamp
+* precedes the current timestamp.
+*/
+   if (pt->sample_pebs && state->type & INTEL_PT_BLK_ITEMS) {
+   err = intel_pt_synth_pebs_sample(ptq);
+   if (err)
+   return err;
+   }
+
if (pt->sample_pwr_events && (state->type & INTEL_PT_PWR_EVT)) {
if (state->type & INTEL_PT_CBR_CHG) {
err = intel_pt_synth_cbr_sample(ptq);
-- 
2.17.1



[PATCH 05/11] perf intel-pt: Factor out common sample preparation for re-use

2019-06-10 Thread Adrian Hunter
Factor out common sample preparation for re-use when synthesizing PEBS
samples.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/intel-pt.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 389ec4612f86..1f5520f964ab 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -1078,28 +1078,37 @@ static inline bool intel_pt_skip_event(struct intel_pt 
*pt)
   pt->num_events++ < pt->synth_opts.initial_skip;
 }
 
+static void intel_pt_prep_a_sample(struct intel_pt_queue *ptq,
+  union perf_event *event,
+  struct perf_sample *sample)
+{
+   event->sample.header.type = PERF_RECORD_SAMPLE;
+   event->sample.header.size = sizeof(struct perf_event_header);
+
+   sample->pid = ptq->pid;
+   sample->tid = ptq->tid;
+   sample->cpu = ptq->cpu;
+   sample->insn_len = ptq->insn_len;
+   memcpy(sample->insn, ptq->insn, INTEL_PT_INSN_BUF_SZ);
+}
+
 static void intel_pt_prep_b_sample(struct intel_pt *pt,
   struct intel_pt_queue *ptq,
   union perf_event *event,
   struct perf_sample *sample)
 {
+   intel_pt_prep_a_sample(ptq, event, sample);
+
if (!pt->timeless_decoding)
sample->time = tsc_to_perf_time(ptq->timestamp, &pt->tc);
 
sample->ip = ptq->state->from_ip;
sample->cpumode = intel_pt_cpumode(pt, sample->ip);
-   sample->pid = ptq->pid;
-   sample->tid = ptq->tid;
sample->addr = ptq->state->to_ip;
sample->period = 1;
-   sample->cpu = ptq->cpu;
sample->flags = ptq->flags;
-   sample->insn_len = ptq->insn_len;
-   memcpy(sample->insn, ptq->insn, INTEL_PT_INSN_BUF_SZ);
 
-   event->sample.header.type = PERF_RECORD_SAMPLE;
event->sample.header.misc = sample->cpumode;
-   event->sample.header.size = sizeof(struct perf_event_header);
 }
 
 static int intel_pt_inject_event(union perf_event *event,
-- 
2.17.1



[PATCH 09/11] perf intel-pt: Add lbr information to synthesized PEBS sample

2019-06-10 Thread Adrian Hunter
Add lbr information from PEBS data in the Intel PT trace to the synthesized
PEBS sample.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/intel-pt.c | 72 ++
 1 file changed, 72 insertions(+)

diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 0175a4ec248f..a73d92189b45 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -1524,6 +1524,58 @@ static void intel_pt_add_xmm(struct regs_dump 
*intr_regs, u64 *pos,
}
 }
 
+#define LBR_INFO_MISPRED   (1ULL << 63)
+#define LBR_INFO_IN_TX (1ULL << 62)
+#define LBR_INFO_ABORT (1ULL << 61)
+#define LBR_INFO_CYCLES0x
+
+/* Refer kernel's intel_pmu_store_pebs_lbrs() */
+static u64 intel_pt_lbr_flags(u64 info)
+{
+   union {
+   struct branch_flags flags;
+   u64 result;
+   } u = {
+   .flags = {
+   .mispred= !!(info & LBR_INFO_MISPRED),
+   .predicted  = !(info & LBR_INFO_MISPRED),
+   .in_tx  = !!(info & LBR_INFO_IN_TX),
+   .abort  = !!(info & LBR_INFO_ABORT),
+   .cycles = info & LBR_INFO_CYCLES,
+   }
+   };
+
+   return u.result;
+}
+
+static void intel_pt_add_lbrs(struct branch_stack *br_stack,
+ const struct intel_pt_blk_items *items)
+{
+   u64 *to;
+   int i;
+
+   br_stack->nr = 0;
+
+   to = &br_stack->entries[0].from;
+
+   for (i = INTEL_PT_LBR_0_POS; i <= INTEL_PT_LBR_2_POS; i++) {
+   u32 mask = items->mask[i];
+   const u64 *from = items->val[i];
+
+   for (; mask; mask >>= 3, from += 3) {
+   if ((mask & 7) == 7) {
+   *to++ = from[0];
+   *to++ = from[1];
+   *to++ = intel_pt_lbr_flags(from[2]);
+   br_stack->nr += 1;
+   }
+   }
+   }
+}
+
+/* INTEL_PT_LBR_0, INTEL_PT_LBR_1 and INTEL_PT_LBR_2 */
+#define LBRS_MAX (INTEL_PT_BLK_ITEM_ID_CNT * 3)
+
 static int intel_pt_synth_pebs_sample(struct intel_pt_queue *ptq)
 {
const struct intel_pt_blk_items *items = &ptq->state->items;
@@ -1590,6 +1642,26 @@ static int intel_pt_synth_pebs_sample(struct 
intel_pt_queue *ptq)
intel_pt_add_xmm(&sample.intr_regs, pos, items, regs_mask);
}
 
+   if (sample_type & PERF_SAMPLE_BRANCH_STACK) {
+   struct {
+   struct branch_stack br_stack;
+   struct branch_entry entries[LBRS_MAX];
+   } br;
+
+   if (items->mask[INTEL_PT_LBR_0_POS] ||
+   items->mask[INTEL_PT_LBR_1_POS] ||
+   items->mask[INTEL_PT_LBR_2_POS]) {
+   intel_pt_add_lbrs(&br.br_stack, items);
+   sample.branch_stack = &br.br_stack;
+   } else if (pt->synth_opts.last_branch) {
+   intel_pt_copy_last_branch_rb(ptq);
+   sample.branch_stack = ptq->last_branch;
+   } else {
+   br.br_stack.nr = 0;
+   sample.branch_stack = &br.br_stack;
+   }
+   }
+
return intel_pt_deliver_synth_event(pt, ptq, event, &sample, 
sample_type);
 }
 
-- 
2.17.1



[PATCH 02/11] perf intel-pt: Add Intel PT packet decoder test

2019-06-10 Thread Adrian Hunter
Add Intel PT packet decoder test. This test feeds byte sequences to the
Intel PT packet decoder and checks the results. Changes to the packet
context are also checked.

Signed-off-by: Adrian Hunter 
---
 tools/perf/arch/x86/include/arch-tests.h  |   1 +
 tools/perf/arch/x86/tests/Build   |   2 +-
 tools/perf/arch/x86/tests/arch-tests.c|   4 +
 .../x86/tests/intel-pt-pkt-decoder-test.c | 304 ++
 4 files changed, 310 insertions(+), 1 deletion(-)
 create mode 100644 tools/perf/arch/x86/tests/intel-pt-pkt-decoder-test.c

diff --git a/tools/perf/arch/x86/include/arch-tests.h 
b/tools/perf/arch/x86/include/arch-tests.h
index 613709cfbbd0..c41c5affe4be 100644
--- a/tools/perf/arch/x86/include/arch-tests.h
+++ b/tools/perf/arch/x86/include/arch-tests.h
@@ -9,6 +9,7 @@ struct test;
 int test__rdpmc(struct test *test __maybe_unused, int subtest);
 int test__perf_time_to_tsc(struct test *test __maybe_unused, int subtest);
 int test__insn_x86(struct test *test __maybe_unused, int subtest);
+int test__intel_pt_pkt_decoder(struct test *test, int subtest);
 int test__bp_modify(struct test *test, int subtest);
 
 #ifdef HAVE_DWARF_UNWIND_SUPPORT
diff --git a/tools/perf/arch/x86/tests/Build b/tools/perf/arch/x86/tests/Build
index 3d83d0c6982d..2997c506550c 100644
--- a/tools/perf/arch/x86/tests/Build
+++ b/tools/perf/arch/x86/tests/Build
@@ -4,5 +4,5 @@ perf-$(CONFIG_DWARF_UNWIND) += dwarf-unwind.o
 perf-y += arch-tests.o
 perf-y += rdpmc.o
 perf-y += perf-time-to-tsc.o
-perf-$(CONFIG_AUXTRACE) += insn-x86.o
+perf-$(CONFIG_AUXTRACE) += insn-x86.o intel-pt-pkt-decoder-test.o
 perf-$(CONFIG_X86_64) += bp-modify.o
diff --git a/tools/perf/arch/x86/tests/arch-tests.c 
b/tools/perf/arch/x86/tests/arch-tests.c
index d47d3f8e3c8e..6763135aec17 100644
--- a/tools/perf/arch/x86/tests/arch-tests.c
+++ b/tools/perf/arch/x86/tests/arch-tests.c
@@ -23,6 +23,10 @@ struct test arch_tests[] = {
.desc = "x86 instruction decoder - new instructions",
.func = test__insn_x86,
},
+   {
+   .desc = "Intel PT packet decoder",
+   .func = test__intel_pt_pkt_decoder,
+   },
 #endif
 #if defined(__x86_64__)
{
diff --git a/tools/perf/arch/x86/tests/intel-pt-pkt-decoder-test.c 
b/tools/perf/arch/x86/tests/intel-pt-pkt-decoder-test.c
new file mode 100644
index ..901bf1f449c4
--- /dev/null
+++ b/tools/perf/arch/x86/tests/intel-pt-pkt-decoder-test.c
@@ -0,0 +1,304 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+
+#include "intel-pt-decoder/intel-pt-pkt-decoder.h"
+
+#include "debug.h"
+#include "tests/tests.h"
+#include "arch-tests.h"
+
+/**
+ * struct test_data - Test data.
+ * @len: number of bytes to decode
+ * @bytes: bytes to decode
+ * @ctx: packet context to decode
+ * @packet: expected packet
+ * @new_ctx: expected new packet context
+ * @ctx_unchanged: the packet context must not change
+ */
+struct test_data {
+   int len;
+   u8 bytes[INTEL_PT_PKT_MAX_SZ];
+   enum intel_pt_pkt_ctx ctx;
+   struct intel_pt_pkt packet;
+   enum intel_pt_pkt_ctx new_ctx;
+   int ctx_unchanged;
+} data[] = {
+   /* Padding Packet */
+   {1, {0}, 0, {INTEL_PT_PAD, 0, 0}, 0, 1 },
+   /* Short Taken/Not Taken Packet */
+   {1, {4}, 0, {INTEL_PT_TNT, 1, 0}, 0, 0 },
+   {1, {6}, 0, {INTEL_PT_TNT, 1, 0x20ULL << 58}, 0, 0 },
+   {1, {0x80}, 0, {INTEL_PT_TNT, 6, 0}, 0, 0 },
+   {1, {0xfe}, 0, {INTEL_PT_TNT, 6, 0x3fULL << 58}, 0, 0 },
+   /* Long Taken/Not Taken Packet */
+   {8, {0x02, 0xa3, 2}, 0, {INTEL_PT_TNT, 1, 0xa302ULL << 47}, 0, 0 },
+   {8, {0x02, 0xa3, 3}, 0, {INTEL_PT_TNT, 1, 0x1a302ULL << 47}, 0, 0 },
+   {8, {0x02, 0xa3, 0, 0, 0, 0, 0, 0x80}, 0, {INTEL_PT_TNT, 47, 0xa302ULL 
<< 1}, 0, 0 },
+   {8, {0x02, 0xa3, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff}, 0, {INTEL_PT_TNT, 
47, 0xa302ULL << 1}, 0, 0 },
+   /* Target IP Packet */
+   {1, {0x0d}, 0, {INTEL_PT_TIP, 0, 0}, 0, 0 },
+   {3, {0x2d, 1, 2}, 0, {INTEL_PT_TIP, 1, 0x201}, 0, 0 },
+   {5, {0x4d, 1, 2, 3, 4}, 0, {INTEL_PT_TIP, 2, 0x4030201}, 0, 0 },
+   {7, {0x6d, 1, 2, 3, 4, 5, 6}, 0, {INTEL_PT_TIP, 3, 0x60504030201}, 0, 0 
},
+   {7, {0x8d, 1, 2, 3, 4, 5, 6}, 0, {INTEL_PT_TIP, 4, 0x60504030201}, 0, 0 
},
+   {9, {0xcd, 1, 2, 3, 4, 5, 6, 7, 8}, 0, {INTEL_PT_TIP, 6, 
0x807060504030201}, 0, 0 },
+   /* Packet Generation Enable */
+   {1, {0x11}, 0, {INTEL_PT_TIP_PGE, 0, 0}, 0, 0 },
+   {3, {0x31, 1, 2}, 0, {INTEL_PT_TIP_PGE, 1, 0x201}, 0, 0 },
+   {5, {0x51, 1, 2, 3, 4}, 0, {INTEL_PT_TIP_PGE, 2, 0x4030201}, 0, 0 },
+   {7, {0x71, 1, 2, 3, 4, 5, 6}, 0, {INTEL_PT_TIP_PGE, 3, 0x60504030201}, 
0, 0 },
+   {7, {0x91, 1, 2, 3, 4, 5, 6}, 0, {INTEL_PT_TIP_PGE, 4, 0x60504030201}, 
0, 0 },
+   {9, {0xd1, 1, 2, 3, 4, 5, 6, 7, 8}, 0, {INTEL_PT_TIP_PGE, 6, 
0x807060504030201}, 0, 0 },
+   /* Packet Generation Disable */
+   {1, {0x01}, 0, {INTE

[PATCH 03/11] perf intel-pt: Add decoder support for PEBS via PT

2019-06-10 Thread Adrian Hunter
PEBS data is encoded in Block Item Packets (BIP). Populate a new structure
intel_pt_blk_items with the values and, upon a Block End Packet (BEP),
report them as a new Intel PT sample type INTEL_PT_BLK_ITEMS.

Signed-off-by: Adrian Hunter 
---
 .../util/intel-pt-decoder/intel-pt-decoder.c  |  78 +-
 .../util/intel-pt-decoder/intel-pt-decoder.h  | 137 ++
 2 files changed, 214 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c 
b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
index 44218f9cf16a..3dcade00f7d0 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
@@ -141,6 +141,9 @@ struct intel_pt_decoder {
struct intel_pt_stack stack;
enum intel_pt_pkt_state pkt_state;
enum intel_pt_pkt_ctx pkt_ctx;
+   enum intel_pt_pkt_ctx prev_pkt_ctx;
+   enum intel_pt_blk_type blk_type;
+   int blk_type_pos;
struct intel_pt_pkt packet;
struct intel_pt_pkt tnt;
int pkt_step;
@@ -174,6 +177,7 @@ struct intel_pt_decoder {
bool set_fup_mwait;
bool set_fup_pwre;
bool set_fup_exstop;
+   bool set_fup_bep;
bool sample_cyc;
unsigned int fup_tx_flags;
unsigned int tx_flags;
@@ -559,6 +563,7 @@ static int intel_pt_get_split_packet(struct 
intel_pt_decoder *decoder)
memcpy(buf + len, decoder->buf, n);
len += n;
 
+   decoder->prev_pkt_ctx = decoder->pkt_ctx;
ret = intel_pt_get_packet(buf, len, &decoder->packet, 
&decoder->pkt_ctx);
if (ret < (int)old_len) {
decoder->next_buf = decoder->buf;
@@ -884,6 +889,7 @@ static int intel_pt_get_next_packet(struct intel_pt_decoder 
*decoder)
return ret;
}
 
+   decoder->prev_pkt_ctx = decoder->pkt_ctx;
ret = intel_pt_get_packet(decoder->buf, decoder->len,
  &decoder->packet, &decoder->pkt_ctx);
if (ret == INTEL_PT_NEED_MORE_BYTES && BITS_PER_LONG == 32 &&
@@ -1123,6 +1129,14 @@ static bool intel_pt_fup_event(struct intel_pt_decoder 
*decoder)
decoder->state.to_ip = 0;
ret = true;
}
+   if (decoder->set_fup_bep) {
+   decoder->set_fup_bep = false;
+   decoder->state.type |= INTEL_PT_BLK_ITEMS;
+   decoder->state.type &= ~INTEL_PT_BRANCH;
+   decoder->state.from_ip = decoder->ip;
+   decoder->state.to_ip = 0;
+   ret = true;
+   }
return ret;
 }
 
@@ -1600,6 +1614,46 @@ static void intel_pt_calc_cyc_timestamp(struct 
intel_pt_decoder *decoder)
intel_pt_log_to("Setting timestamp", decoder->timestamp);
 }
 
+static void intel_pt_bbp(struct intel_pt_decoder *decoder)
+{
+   if (decoder->prev_pkt_ctx == INTEL_PT_NO_CTX) {
+   memset(decoder->state.items.mask, 0, 
sizeof(decoder->state.items.mask));
+   decoder->state.items.is_32_bit = false;
+   }
+   decoder->blk_type = decoder->packet.payload;
+   decoder->blk_type_pos = intel_pt_blk_type_pos(decoder->blk_type);
+   if (decoder->blk_type == INTEL_PT_GP_REGS)
+   decoder->state.items.is_32_bit = decoder->packet.count;
+   if (decoder->blk_type_pos < 0) {
+   intel_pt_log("WARNING: Unknown block type %u\n",
+decoder->blk_type);
+   } else if (decoder->state.items.mask[decoder->blk_type_pos]) {
+   intel_pt_log("WARNING: Duplicate block type %u\n",
+decoder->blk_type);
+   }
+}
+
+static void intel_pt_bip(struct intel_pt_decoder *decoder)
+{
+   uint32_t id = decoder->packet.count;
+   uint32_t bit = 1 << id;
+   int pos = decoder->blk_type_pos;
+
+   if (pos < 0 || id >= INTEL_PT_BLK_ITEM_ID_CNT) {
+   intel_pt_log("WARNING: Unknown block item %u type %d\n",
+id, decoder->blk_type);
+   return;
+   }
+
+   if (decoder->state.items.mask[pos] & bit) {
+   intel_pt_log("WARNING: Duplicate block item %u type %d\n",
+id, decoder->blk_type);
+   }
+
+   decoder->state.items.mask[pos] |= bit;
+   decoder->state.items.val[pos][id] = decoder->packet.payload;
+}
+
 /* Walk PSB+ packets when already in sync. */
 static int intel_pt_walk_psbend(struct intel_pt_decoder *decoder)
 {
@@ -2054,10 +2108,31 @@ static int intel_pt_walk_trace(struct intel_pt_decoder 
*decoder)
return 0;
 
case INTEL_PT_BBP:
+   intel_pt_bbp(decoder);
+   break;
+
case INTEL_PT_BIP:
+   intel_pt_bip(decoder);
+   break;
+
case INTEL_PT_BEP:
+   decoder->state.type = INTEL_PT_BLK_ITEMS

[PATCH 11/11] perf intel-pt: Add callchain to synthesized PEBS sample

2019-06-10 Thread Adrian Hunter
Like other synthesized events, if there is also an Intel PT branch trace,
then a call stack can also be synthesized.  Add that.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/intel-pt.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 0b7beb98a028..ea03bdaf8009 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -1626,6 +1626,14 @@ static int intel_pt_synth_pebs_sample(struct 
intel_pt_queue *ptq)
sample.time = tsc_to_perf_time(timestamp, &pt->tc);
}
 
+   if (sample_type & PERF_SAMPLE_CALLCHAIN &&
+   pt->synth_opts.callchain) {
+   thread_stack__sample(ptq->thread, ptq->cpu, ptq->chain,
+pt->synth_opts.callchain_sz, sample.ip,
+pt->kernel_start);
+   sample.callchain = ptq->chain;
+   }
+
if (sample_type & PERF_SAMPLE_REGS_INTR &&
items->mask[INTEL_PT_GP_REGS_POS]) {
u64 regs[sizeof(sample.intr_regs.mask)];
-- 
2.17.1



Re: [PATCH 5.1 56/85] doc: Cope with the deprecation of AutoReporter

2019-06-10 Thread Greg Kroah-Hartman
On Mon, Jun 10, 2019 at 08:27:30AM +0200, Jiri Slaby wrote:
> On 07. 06. 19, 17:39, Greg Kroah-Hartman wrote:
> > From: Jonathan Corbet 
> > 
> > commit 2404dad1f67f8917e30fc22a85e0dbcc85b99955 upstream.
> > 
> > AutoReporter is going away; recent versions of sphinx emit a warning like:
> > 
> >   Documentation/sphinx/kerneldoc.py:125:
> >   RemovedInSphinx20Warning: AutodocReporter is now deprecated.
> >   Use sphinx.util.docutils.switch_source_input() instead.
> > 
> > Make the switch.  But switch_source_input() only showed up in 1.7, so we
> > have to do ugly version checks to keep things working in older versions.
> 
> Hi,
> 
> this patch breaks our build of kernel-docs on 5.1.*:
> https://build.opensuse.org/package/live_build_log/Kernel:stable/kernel-docs/standard/x86_64
> 
> The error is:
> [  250s] reST markup error:
> [  250s]
> /home/abuild/rpmbuild/BUILD/kernel-docs-5.1.8/linux-5.1/Documentation/gpu/i915.rst:403:
> (SEVERE/4) Title level inconsistent:
> [  250s]
> [  250s] Global GTT Fence Handling
> [  250s] ~
> 
> Reverting the patch from 5.1.* makes it work again.
> 
> 5.2-rc3 (includes the patch) is OK:
> https://build.opensuse.org/package/live_build_log/Kernel:HEAD/kernel-docs/standard/x86_64
> 
> So 5.1.* must be missing something now.

Odd.  running 'make htmldocs' on 5.1 with these patches applied works
for me here.

What version of sphinx are you using to build the package with?

thanks,

greg k-h


Re: [PATCH] staging: rtl8723bs: core: rtw_mlme_ext.c: Remove unused variables

2019-06-10 Thread Nishka Dasgupta

On 10/06/19 12:55 PM, Greg KH wrote:

On Mon, Jun 10, 2019 at 12:44:05PM +0530, Nishka Dasgupta wrote:

On 10/06/19 11:19 AM, Greg KH wrote:

On Mon, Jun 10, 2019 at 10:08:21AM +0530, Nishka Dasgupta wrote:

On 09/06/19 4:32 PM, Greg KH wrote:

On Fri, Jun 07, 2019 at 12:41:23PM +0530, Nishka Dasgupta wrote:

Remove variables that are declared and assigned values but not otherwise
used.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 
---
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 9 -
1 file changed, 9 deletions(-)


You sent me 8 patches for this driver, yet only 2 were ordered in a
series.  I have no idea what order to apply these in :(

Please resend them _all_ in a numbered patch series so I have a chance
to get this correct.


Yes, I can do that. Who do I send the patch series to in that case? The
maintainers list is slightly different for each file, and most of the
patches in this driver are for different and unrelated files (except, I
think, the two that I did send as a patch series). Do I combine the
maintainers lists and send the entire patch series to everyone listed as a
maintainer for any one of the patches in it?


The maintainer and mailing list is the same for all of the files in a
single driver.  If not, then something is wrong.


I'm using get_maintainers.pl with no arguments, and for rtl8723bs, I am
getting a lot of different mailing lists.
E.g
For core/rtw_ieee80211.c, I'm getting the following list:
Greg Kroah-Hartman 
Michael Straube 
Andy Shevchenko 
Hardik Singh Rathore 
Payal Kshirsagar 
Nishka Dasgupta 
de...@driverdev.osuosl.org (open list:STAGING SUBSYSTEM)
linux-kernel@vger.kernel.org (open list)

Which is not the same as for core/rtw_mlme_ext.c (the current patch).


And yes, you can combine the list of people if you wish but be sure you
are not just randomly including people who happened to touch the driver
"last".


Okay, I'll combine then. But is there any metric I should be using to filter
the output of get_maintainer.pl? Currently I'm running it with no arguments
and just adding everyone.


Look at the "role" that each person has.  Here is the output of
get_maintainer.pl when I run it on the first file above:

$ ./scripts/get_maintainer.pl --file 
drivers/staging/rtl8723bs/core/rtw_ieee80211.c
Greg Kroah-Hartman  (supporter:STAGING 
SUBSYSTEM,commit_signer:16/16=100%)
Michael Straube  
(commit_signer:14/16=88%,authored:14/16=88%,added_lines:43/59=73%,removed_lines:114/130=88%)
Payal Kshirsagar  
(commit_signer:1/16=6%,authored:1/16=6%,added_lines:3/59=5%)
Hardik Singh Rathore  
(commit_signer:1/16=6%,authored:1/16=6%,added_lines:13/59=22%,removed_lines:13/130=10%)
Andy Shevchenko  (commit_signer:1/16=6%)
de...@driverdev.osuosl.org (open list:STAGING SUBSYSTEM)
linux-kernel@vger.kernel.org (open list)


That shows that "Greg Kroah-Hartman" is a reviewer for this subsystem,
Michael and Payal and Hardik and Andy have all submitted patches
"recently", and then devel@ is the mailing list for the patches to be
sent to.

So, just include the maintainer and the mailing list and you will be
fine.  No need to bother lkml with staging patches, nor the people who
last sent cleanup patches.

hope this helps,


This helps a lot; thank you!

Nishka


greg k-h





Re: [PATCH 5.1 56/85] doc: Cope with the deprecation of AutoReporter

2019-06-10 Thread Jiri Slaby
On 10. 06. 19, 9:31, Greg Kroah-Hartman wrote:
> On Mon, Jun 10, 2019 at 08:27:30AM +0200, Jiri Slaby wrote:
>> On 07. 06. 19, 17:39, Greg Kroah-Hartman wrote:
>>> From: Jonathan Corbet 
>>>
>>> commit 2404dad1f67f8917e30fc22a85e0dbcc85b99955 upstream.
>>>
>>> AutoReporter is going away; recent versions of sphinx emit a warning like:
>>>
>>>   Documentation/sphinx/kerneldoc.py:125:
>>>   RemovedInSphinx20Warning: AutodocReporter is now deprecated.
>>>   Use sphinx.util.docutils.switch_source_input() instead.
>>>
>>> Make the switch.  But switch_source_input() only showed up in 1.7, so we
>>> have to do ugly version checks to keep things working in older versions.
>>
>> Hi,
>>
>> this patch breaks our build of kernel-docs on 5.1.*:
>> https://build.opensuse.org/package/live_build_log/Kernel:stable/kernel-docs/standard/x86_64
>>
>> The error is:
>> [  250s] reST markup error:
>> [  250s]
>> /home/abuild/rpmbuild/BUILD/kernel-docs-5.1.8/linux-5.1/Documentation/gpu/i915.rst:403:
>> (SEVERE/4) Title level inconsistent:
>> [  250s]
>> [  250s] Global GTT Fence Handling
>> [  250s] ~
>>
>> Reverting the patch from 5.1.* makes it work again.
>>
>> 5.2-rc3 (includes the patch) is OK:
>> https://build.opensuse.org/package/live_build_log/Kernel:HEAD/kernel-docs/standard/x86_64
>>
>> So 5.1.* must be missing something now.
> 
> Odd.  running 'make htmldocs' on 5.1 with these patches applied works
> for me here.
> 
> What version of sphinx are you using to build the package with?

>From the log, it looks like 1.8.5 (it's tumbleweed):

$ osc rbl Kernel:stable/kernel-docs/standard/x86_64|grep -i sphinx
[   11s] cycle: python3-sphinx_rtd_theme -> python3-Sphinx
[   11s]   breaking dependency python3-Sphinx -> python3-sphinx_rtd_theme
[   32s] [226/263] cumulate python3-sphinxcontrib-websupport-1.1.0-1.2
[   32s] [239/263] cumulate python3-Sphinx-1.8.5-2.2
[   32s] [242/263] cumulate python3-sphinx_rtd_theme-0.4.1-1.3
[   72s]
python3-sphinxcontrib-websupport-1.1.0
[   72s] python3-sphinx_rtd_theme-0.4.1-1.3

[   73s] python3-Sphinx-1.8.5-2.2

[   73s] update-alternatives: using /usr/bin/sphinx-apidoc-3.7 to
provide /usr/bin/sphinx-apidoc (sphinx-apidoc) in auto mode
[  101s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i
/home/abuild/rpmbuild/BUILD/kernel-docs-5.1.8/patches.kernel.org/5.1.8-055-docs-Fix-conf.py-for-Sphin-2.0.patch
[  101s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i
/home/abuild/rpmbuild/BUILD/kernel-docs-5.1.8/patches.kernel.org/5.1.8-057-doc-Cope-with-Sphinx-logging-deprecations.patch
[  102s]   SPHINX  htmldocs -->
file:///home/abuild/rpmbuild/BUILD/kernel-docs-5.1.8/linux-5.1/html/Documentation/output
[  103s] Running Sphinx v1.8.5

thanks,
-- 
js
suse labs


[PATCH v4 2/2] media: atmel: atmel-sama5d2-isc: fixed checkpatch warnings

2019-06-10 Thread Eugen.Hristev
From: Eugen Hristev 

Checkpatch complaining that locks do not have comments,
unaligned code and macro reuse of same argument in to_isc_clk.
Fixed them by renaming, realigning and adding struct comments

Signed-off-by: Eugen Hristev 
---
Changes in v4:
- s/sync/serialize as requested by Sakari

Changes in v3:
- new patch, addresses the checkpatch issues that Hans asked to fix


 drivers/media/platform/atmel/atmel-isc.h | 51 +---
 drivers/media/platform/atmel/atmel-sama5d2-isc.c |  4 +-
 2 files changed, 48 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.h 
b/drivers/media/platform/atmel/atmel-isc.h
index f633e10..5be5b09 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -24,14 +24,14 @@ struct isc_clk {
struct clk_hw   hw;
struct clk  *clk;
struct regmap   *regmap;
-   spinlock_t  lock;
+   spinlock_t  lock;   /* serialize access to clock registers */
u8  id;
u8  parent_id;
u32 div;
struct device   *dev;
 };
 
-#define to_isc_clk(hw) container_of(hw, struct isc_clk, hw)
+#define to_isc_clk(v) container_of(v, struct isc_clk, hw)
 
 struct isc_buffer {
struct vb2_v4l2_buffer  vb;
@@ -146,6 +146,47 @@ struct isc_ctrls {
 
 #define ISC_PIPE_LINE_NODE_NUM 11
 
+/*
+ * struct isc_device - ISC device driver data/config struct
+ * @regmap:Register map
+ * @hclock:Hclock clock input (refer datasheet)
+ * @ispck: iscpck clock (refer datasheet)
+ * @isc_clks:  ISC clocks
+ *
+ * @dev:   Registered device driver
+ * @v4l2_dev:  v4l2 registered device
+ * @video_dev: registered video device
+ *
+ * @vb2_vidq:  video buffer 2 video queue
+ * @dma_queue_lock:lock to serialize the dma buffer queue
+ * @dma_queue: the queue for dma buffers
+ * @cur_frm:   current isc frame/buffer
+ * @sequence:  current frame number
+ * @stop:  true if isc is not streaming, false if streaming
+ * @comp:  completion reference that signals frame completion
+ *
+ * @fmt:   current v42l format
+ * @user_formats:  list of formats that are supported and agreed with sd
+ * @num_user_formats:  how many formats are in user_formats
+ *
+ * @config:current ISC format configuration
+ * @try_config:the current ISC try format , not yet activated
+ *
+ * @ctrls: holds information about ISC controls
+ * @do_wb_ctrl:control regarding the DO_WHITE_BALANCE button
+ * @awb_work:  workqueue reference for autowhitebalance histogram
+ * analysis
+ *
+ * @lock:  lock for serializing userspace file operations
+ * with ISC operations
+ * @awb_lock:  lock for serializing awb work queue operations
+ * with DMA/buffer operations
+ *
+ * @pipeline:  configuration of the ISC pipeline
+ *
+ * @current_subdev:current subdevice: the sensor
+ * @subdev_entities:   list of subdevice entitites
+ */
 struct isc_device {
struct regmap   *regmap;
struct clk  *hclock;
@@ -157,7 +198,7 @@ struct isc_device {
struct video_device video_dev;
 
struct vb2_queuevb2_vidq;
-   spinlock_t  dma_queue_lock;
+   spinlock_t  dma_queue_lock; /* serialize access to dma 
queue */
struct list_headdma_queue;
struct isc_buffer   *cur_frm;
unsigned intsequence;
@@ -175,8 +216,8 @@ struct isc_device {
struct v4l2_ctrl*do_wb_ctrl;
struct work_struct  awb_work;
 
-   struct mutexlock;
-   spinlock_t  awb_lock;
+   struct mutexlock; /* serialize access to file operations */
+   spinlock_t  awb_lock; /* serialize access to DMA buffers 
from awb work queue */
 
struct regmap_field *pipeline[ISC_PIPE_LINE_NODE_NUM];
 
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c 
b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 93fb839..127e79c 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -87,8 +87,8 @@ static int isc_parse_dt(struct device *dev, struct isc_device 
*isc)
break;
}
 
-   subdev_entity = devm_kzalloc(dev,
- sizeof(*subdev_entity), GFP_KERNEL);
+   subdev_entity = devm_kzalloc(dev, sizeof(*subdev_entity),
+GFP_KERNEL);
if (!subdev_entity) {
of_node_put(rem);
ret = -ENOMEM;
-- 
2.7.4



[PATCH] tty: serial: msm_serial: avoid system lockup condition

2019-06-10 Thread Jorge Ramirez-Ortiz
The function msm_wait_for_xmitr can be taken with interrupts
disabled. In order to avoid a potential system lockup - demonstrated
under stress testing conditions on SoC QCS404/5 - make sure we wait
for a bounded amount of time.

Tested on SoC QCS404.

Signed-off-by: Jorge Ramirez-Ortiz 
---
 drivers/tty/serial/msm_serial.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index 23833ad952ba..0d4f1fe2b3a2 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -383,10 +383,14 @@ static void msm_request_rx_dma(struct msm_port *msm_port, 
resource_size_t base)
 
 static inline void msm_wait_for_xmitr(struct uart_port *port)
 {
+   unsigned int timeout = 50;
+
while (!(msm_read(port, UART_SR) & UART_SR_TX_EMPTY)) {
if (msm_read(port, UART_ISR) & UART_ISR_TX_READY)
break;
udelay(1);
+   if (timeout--)
+   break;
}
msm_write(port, UART_CR_CMD_RESET_TX_READY, UART_CR);
 }
-- 
2.21.0



Re: [PATCH v2 1/4] perf trace: Exit when build eBPF program failure

2019-06-10 Thread Leo Yan
On Thu, Jun 06, 2019 at 10:34:24AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jun 06, 2019 at 10:30:19AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Jun 06, 2019 at 05:48:42PM +0800, Leo Yan escreveu:
> > > +++ b/tools/perf/builtin-trace.c
> > > @@ -3664,6 +3664,14 @@ static int trace__config(const char *var, const 
> > > char *value, void *arg)
> > >  "event selector. use 'perf list' 
> > > to list available events",
> > >  parse_events_option);
> > >   err = parse_events_option(&o, value, 0);
> > > +
> > > + /*
> > > +  * When parse option successfully parse_events_option() will
> > > +  * return 0, otherwise means the paring failure.  And it
> > > +  * returns 1 for eBPF program building failure; so adjust the
> > > +  * err value to -1 for the failure.
> > > +  */
> > > + err = err ? -1 : 0;
> > 
> > I'll rewrite the comment above to make it more succint and fix things
> > like 'paring' (parsing):
> > 
> > /*
> >  * parse_events_option() returns !0 to indicate failure
> >  * while the perf_config code that calls trace__config()
> >  * expects < 0 returns to indicate error, so:
> >  */
> > 
> >  if (err)
> > err = -1;
> 
> Even shorter, please let me know if I can keep your
> Signed-off-by/authorship for this one.

Sorry I miss this email.

> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> index f7e4e50bddbd..1a2a605cf068 100644
> --- a/tools/perf/builtin-trace.c
> +++ b/tools/perf/builtin-trace.c
> @@ -3703,7 +3703,12 @@ static int trace__config(const char *var, const char 
> *value, void *arg)
>   struct option o = OPT_CALLBACK('e', "event", &trace->evlist, 
> "event",
>  "event selector. use 'perf list' 
> to list available events",
>  parse_events_option);
> - err = parse_events_option(&o, value, 0);
> + /*
> +  * We can't propagate parse_event_option() return, as it is 1
> +  * for failure while perf_config() expects -1.
> +  */
> + if (parse_events_option(&o, value, 0))
> + err = -1;
>   } else if (!strcmp(var, "trace.show_timestamp")) {
>   trace->show_tstamp = perf_config_bool(var, value);
>   } else if (!strcmp(var, "trace.show_duration")) {


Yeah, the change looks good to me. And very appreciate your effort to
improve the patch quality.

Thanks,
Leo.


Re: Linux 4.19 and GCC 9

2019-06-10 Thread Greg KH
On Mon, Jun 10, 2019 at 12:21:51AM -0700, Ivan Babrou wrote:
> Looks like 4.19.49 received some patches for GCC 9+, but unfortunately
> perf still doesn't want to compile:
> 
> [07:15:32]In file included from /usr/include/string.h:635,
> [07:15:32] from util/debug.h:7,
> [07:15:32] from builtin-help.c:15:
> [07:15:32]In function 'strncpy',
> [07:15:32] inlined from 'add_man_viewer' at builtin-help.c:192:2,
> [07:15:32] inlined from 'perf_help_config' at builtin-help.c:284:3:
> [07:15:32]/usr/include/x86_64-linux-gnu/bits/string3.h:126:10: error:
> '__builtin_strncpy' output truncated before terminating nul copying as
> many bytes from a string as its length [-Werror=stringop-truncation]
> [07:15:32] 126 | return __builtin___strncpy_chk (__dest, __src, __len,
> __bos (__dest));
> [07:15:32] | ^~
> [07:15:32]builtin-help.c: In function 'perf_help_config':
> [07:15:32]builtin-help.c:187:15: note: length computed here
> [07:15:32] 187 | size_t len = strlen(name);
> [07:15:32] | ^~~~
> [07:15:32]cc1: all warnings being treated as errors


Any chance in finding a patch in Linus's tree that resolves this?  I
don't have gcc9 on my systems here yet to test this.

thanks,

greg k-h


Re: [PATCH] perf record: Add support to collect callchains from kernel or user space only.

2019-06-10 Thread 禹舟键
Hi Arnaldo,  Jirka

> perf_event_attr.exclude_callchain_kernel to 0

I don't think we should set 0 for the desired callchins,  because we
will set exclude_callchain_user to 1 if perf_evsel is function event.

void perf_evsel__config(struct perf_evsel *evsel, struct record_opts
*opts, struct callchain_param *callchain)
{
...
if (perf_evsel__is_function_event(evsel))
evsel->attr.exclude_callchain_user = 1;

if (callchain && callchain->enabled && !evsel->no_aux_samples)
perf_evsel__config_callchain(evsel, opts, callchain);
}

If we set exclude_callchain_user to 0 , it will catch user callchain
for function_event.  So, it will be best to just set the
exclude_callchain_xxx to 1.

> So that the user don't try using:

> perf record --user-callchains --kernel-callchains

> expecting to get both user and kernel callchains and instead gets
> nothing.

I will add a note in the doc.


Arnaldo Carvalho de Melo  于2019年6月7日周五 上午2:15写道:
>
> Em Thu, Jun 06, 2019 at 04:46:14PM +0200, Jiri Olsa escreveu:
> > On Thu, Jun 06, 2019 at 11:26:44AM -0300, Arnaldo Carvalho de Melo wrote:
> > > So that the user don't try using:
>
> > > pref record --user-callchains --kernel-callchains
>
> > > expecting to get both user and kernel callchains and instead gets
> > > nothing.
>
> > good catch.. we should add the logic to keep both (default)
> > in this case.. so do nothing ;-)
>
> Yeah, not using both or using both should amount to the same behaviour.
>
> Can be done with a patch on top of what I have in my tree now.
>
> - Arnaldo


[PATCH stable 4.4 v2] coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping

2019-06-10 Thread Michal Hocko
From: Andrea Arcangeli 

Upstream 04f5866e41fb70690e28397487d8bd8eea7d712a commit.

The core dumping code has always run without holding the mmap_sem for
writing, despite that is the only way to ensure that the entire vma
layout will not change from under it.  Only using some signal
serialization on the processes belonging to the mm is not nearly enough.
This was pointed out earlier.  For example in Hugh's post from Jul 2017:

  https://lkml.kernel.org/r/alpine.LSU.2.11.1707191716030.2055@eggly.anvils

  "Not strictly relevant here, but a related note: I was very surprised
   to discover, only quite recently, how handle_mm_fault() may be called
   without down_read(mmap_sem) - when core dumping. That seems a
   misguided optimization to me, which would also be nice to correct"

In particular because the growsdown and growsup can move the
vm_start/vm_end the various loops the core dump does around the vma will
not be consistent if page faults can happen concurrently.

Pretty much all users calling mmget_not_zero()/get_task_mm() and then
taking the mmap_sem had the potential to introduce unexpected side
effects in the core dumping code.

Adding mmap_sem for writing around the ->core_dump invocation is a
viable long term fix, but it requires removing all copy user and page
faults and to replace them with get_dump_page() for all binary formats
which is not suitable as a short term fix.

For the time being this solution manually covers the places that can
confuse the core dump either by altering the vma layout or the vma flags
while it runs.  Once ->core_dump runs under mmap_sem for writing the
function mmget_still_valid() can be dropped.

Allowing mmap_sem protected sections to run in parallel with the
coredump provides some minor parallelism advantage to the swapoff code
(which seems to be safe enough by never mangling any vma field and can
keep doing swapins in parallel to the core dumping) and to some other
corner case.

In order to facilitate the backporting I added "Fixes: 86039bd3b4e6"
however the side effect of this same race condition in /proc/pid/mem
should be reproducible since before 2.6.12-rc2 so I couldn't add any
other "Fixes:" because there's no hash beyond the git genesis commit.

Because find_extend_vma() is the only location outside of the process
context that could modify the "mm" structures under mmap_sem for
reading, by adding the mmget_still_valid() check to it, all other cases
that take the mmap_sem for reading don't need the new check after
mmget_not_zero()/get_task_mm().  The expand_stack() in page fault
context also doesn't need the new check, because all tasks under core
dumping are frozen.

Link: http://lkml.kernel.org/r/20190325224949.11068-1-aarca...@redhat.com
Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory 
externalization")
Signed-off-by: Andrea Arcangeli 
Reported-by: Jann Horn 
Suggested-by: Oleg Nesterov 
Acked-by: Peter Xu 
Reviewed-by: Mike Rapoport 
Reviewed-by: Oleg Nesterov 
Reviewed-by: Jann Horn 
Acked-by: Jason Gunthorpe 
Acked-by: Michal Hocko 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Joel Fernandes (Google) 
[mho...@suse.com: stable 4.4 backport
 - drop infiniband part because of missing 5f9794dc94f59
 - drop userfaultfd_event_wait_completion hunk because of
   missing 9cd75c3cd4c3d]
 - handle binder_update_page_range because of missing 720c241924046
]
Signed-off-by: Michal Hocko 
---

Hi,
this is v2 of the backport. It turned out that the khugepaged part of my
backport was in fact missing in the upstream commit as well so Anrea has
posted a follow up fix with the full explanation [1] and that patch
should be routed to stable trees on its own.

A further review of the backport is highly appreciated of course.

[1] http://lkml.kernel.org/r/20190607161558.32104-1-aarca...@redhat.com

 drivers/android/binder.c |  6 ++
 fs/proc/task_mmu.c   | 18 ++
 fs/userfaultfd.c | 10 --
 include/linux/mm.h   | 21 +
 mm/mmap.c|  7 ++-
 5 files changed, 59 insertions(+), 3 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 260ce0e60187..1fb1cddbd19a 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -570,6 +570,12 @@ static int binder_update_page_range(struct binder_proc 
*proc, int allocate,
 
if (mm) {
down_write(&mm->mmap_sem);
+   if (!mmget_still_valid(mm)) {
+   if (allocate == 0)
+   goto free_range;
+   goto err_no_vma;
+   }
+
vma = proc->vma;
if (vma && mm != proc->vma_vm_mm) {
pr_err("%d: vma mm and task mm mismatch\n",
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 75691a20313c..ad1ccdcef74e 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -947,6 +947,24 @@ static ssize_t clear_refs_write(struct

[PATCH] vsprintf: fix data type of variable in string_nocheck()

2019-06-10 Thread 남영민
This patch fixes data type of precision with int.
The precision is declared as signed int in struct printf_spec.

Signed-off-by: Youngmin Nam 
---
 lib/vsprintf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 63937044c57d..cd0cd9279b12 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -599,7 +599,7 @@ static char *string_nocheck(char *buf, char *end, const 
char *s,
struct printf_spec spec)
 {
int len = 0;
-   size_t lim = spec.precision;
+   int lim = spec.precision;
 
while (lim--) {
char c = *s++;
-- 
2.21.0



[PATCH v2] staging: kpc2000: kpc_i2c: remove the macros inb_p and outb_p

2019-06-10 Thread Hao Xu
remove inb_p and outb_p to call readq/writeq directly.

Signed-off-by: Hao Xu 
---
Changes in v2:
- remove the macros inb_p/outb_p and use readq/writeq directly, per 
https://lkml.kernel.org/lkml/20190608134505.ga...@arch-01.home/
---
 drivers/staging/kpc2000/kpc2000_i2c.c | 112 --
 1 file changed, 53 insertions(+), 59 deletions(-)

diff --git a/drivers/staging/kpc2000/kpc2000_i2c.c 
b/drivers/staging/kpc2000/kpc2000_i2c.c
index 69e8773..246d5b3 100644
--- a/drivers/staging/kpc2000/kpc2000_i2c.c
+++ b/drivers/staging/kpc2000/kpc2000_i2c.c
@@ -122,12 +122,6 @@ struct i2c_device {
 /* Not really a feature, but it's convenient to handle it as such */
 #define FEATURE_IDF BIT(15)
 
-// FIXME!
-#undef inb_p
-#define inb_p(a) readq((void *)a)
-#undef outb_p
-#define outb_p(d, a) writeq(d, (void *)a)
-
 /* Make sure the SMBus host is ready to start transmitting.
  * Return 0 if it is, -EBUSY if it is not.
  */
@@ -135,7 +129,7 @@ static int i801_check_pre(struct i2c_device *priv)
 {
int status;
 
-   status = inb_p(SMBHSTSTS(priv));
+   status = readq((void *)SMBHSTSTS(priv));
if (status & SMBHSTSTS_HOST_BUSY) {
dev_err(&priv->adapter.dev, "SMBus is busy, can't use it! 
(status=%x)\n", status);
return -EBUSY;
@@ -144,8 +138,8 @@ static int i801_check_pre(struct i2c_device *priv)
status &= STATUS_FLAGS;
if (status) {
//dev_dbg(&priv->adapter.dev, "Clearing status flags (%02x)\n", 
status);
-   outb_p(status, SMBHSTSTS(priv));
-   status = inb_p(SMBHSTSTS(priv)) & STATUS_FLAGS;
+   writeq(status, (void *)SMBHSTSTS(priv));
+   status = readq((void *)SMBHSTSTS(priv)) & STATUS_FLAGS;
if (status) {
dev_err(&priv->adapter.dev, "Failed clearing status 
flags (%02x)\n", status);
return -EBUSY;
@@ -164,15 +158,15 @@ static int i801_check_post(struct i2c_device *priv, int 
status, int timeout)
dev_err(&priv->adapter.dev, "Transaction timeout\n");
/* try to stop the current command */
dev_dbg(&priv->adapter.dev, "Terminating the current 
operation\n");
-   outb_p(inb_p(SMBHSTCNT(priv)) | SMBHSTCNT_KILL, 
SMBHSTCNT(priv));
+   writeq(readq((void *)SMBHSTCNT(priv)) | SMBHSTCNT_KILL, (void 
*)SMBHSTCNT(priv));
usleep_range(1000, 2000);
-   outb_p(inb_p(SMBHSTCNT(priv)) & (~SMBHSTCNT_KILL), 
SMBHSTCNT(priv));
+   writeq(readq((void *)SMBHSTCNT(priv)) & (~SMBHSTCNT_KILL), 
(void *)SMBHSTCNT(priv));
 
/* Check if it worked */
-   status = inb_p(SMBHSTSTS(priv));
+   status = readq((void *)SMBHSTSTS(priv));
if ((status & SMBHSTSTS_HOST_BUSY) || !(status & 
SMBHSTSTS_FAILED))
dev_err(&priv->adapter.dev, "Failed terminating the 
transaction\n");
-   outb_p(STATUS_FLAGS, SMBHSTSTS(priv));
+   writeq(STATUS_FLAGS, (void *)SMBHSTSTS(priv));
return -ETIMEDOUT;
}
 
@@ -191,8 +185,8 @@ static int i801_check_post(struct i2c_device *priv, int 
status, int timeout)
 
if (result) {
/* Clear error flags */
-   outb_p(status & STATUS_FLAGS, SMBHSTSTS(priv));
-   status = inb_p(SMBHSTSTS(priv)) & STATUS_FLAGS;
+   writeq(status & STATUS_FLAGS, (void *)SMBHSTSTS(priv));
+   status = readq((void *)SMBHSTSTS(priv)) & STATUS_FLAGS;
if (status)
dev_warn(&priv->adapter.dev, "Failed clearing status 
flags at end of transaction (%02x)\n", status);
}
@@ -212,19 +206,19 @@ static int i801_transaction(struct i2c_device *priv, int 
xact)
/* the current contents of SMBHSTCNT can be overwritten, since PEC,
 * INTREN, SMBSCMD are passed in xact
 */
-   outb_p(xact | I801_START, SMBHSTCNT(priv));
+   writeq(xact | I801_START, (void *)SMBHSTCNT(priv));
 
/* We will always wait for a fraction of a second! */
do {
usleep_range(250, 500);
-   status = inb_p(SMBHSTSTS(priv));
+   status = readq((void *)SMBHSTSTS(priv));
} while ((status & SMBHSTSTS_HOST_BUSY) && (timeout++ < MAX_RETRIES));
 
result = i801_check_post(priv, status, timeout > MAX_RETRIES);
if (result < 0)
return result;
 
-   outb_p(SMBHSTSTS_INTR, SMBHSTSTS(priv));
+   writeq(SMBHSTSTS_INTR, (void *)SMBHSTSTS(priv));
return 0;
 }
 
@@ -236,13 +230,13 @@ static void i801_wait_hwpec(struct i2c_device *priv)
 
do {
usleep_range(250, 500);
-   status = inb_p(SMBHSTSTS(priv));
+   status = readq((void *)SMBHSTSTS(priv));
} while ((!(status & SMBHSTSTS_INTR)) && (timeout++ < MAX_RETRIES));
 
if (timeout > MAX_RE

Re: [PATCH 5.1 56/85] doc: Cope with the deprecation of AutoReporter

2019-06-10 Thread Greg Kroah-Hartman
On Mon, Jun 10, 2019 at 09:34:10AM +0200, Jiri Slaby wrote:
> On 10. 06. 19, 9:31, Greg Kroah-Hartman wrote:
> > On Mon, Jun 10, 2019 at 08:27:30AM +0200, Jiri Slaby wrote:
> >> On 07. 06. 19, 17:39, Greg Kroah-Hartman wrote:
> >>> From: Jonathan Corbet 
> >>>
> >>> commit 2404dad1f67f8917e30fc22a85e0dbcc85b99955 upstream.
> >>>
> >>> AutoReporter is going away; recent versions of sphinx emit a warning like:
> >>>
> >>>   Documentation/sphinx/kerneldoc.py:125:
> >>>   RemovedInSphinx20Warning: AutodocReporter is now deprecated.
> >>>   Use sphinx.util.docutils.switch_source_input() instead.
> >>>
> >>> Make the switch.  But switch_source_input() only showed up in 1.7, so we
> >>> have to do ugly version checks to keep things working in older versions.
> >>
> >> Hi,
> >>
> >> this patch breaks our build of kernel-docs on 5.1.*:
> >> https://build.opensuse.org/package/live_build_log/Kernel:stable/kernel-docs/standard/x86_64
> >>
> >> The error is:
> >> [  250s] reST markup error:
> >> [  250s]
> >> /home/abuild/rpmbuild/BUILD/kernel-docs-5.1.8/linux-5.1/Documentation/gpu/i915.rst:403:
> >> (SEVERE/4) Title level inconsistent:
> >> [  250s]
> >> [  250s] Global GTT Fence Handling
> >> [  250s] ~
> >>
> >> Reverting the patch from 5.1.* makes it work again.
> >>
> >> 5.2-rc3 (includes the patch) is OK:
> >> https://build.opensuse.org/package/live_build_log/Kernel:HEAD/kernel-docs/standard/x86_64
> >>
> >> So 5.1.* must be missing something now.
> > 
> > Odd.  running 'make htmldocs' on 5.1 with these patches applied works
> > for me here.
> > 
> > What version of sphinx are you using to build the package with?
> 
> >From the log, it looks like 1.8.5 (it's tumbleweed):
> 
> $ osc rbl Kernel:stable/kernel-docs/standard/x86_64|grep -i sphinx
> [   11s] cycle: python3-sphinx_rtd_theme -> python3-Sphinx
> [   11s]   breaking dependency python3-Sphinx -> python3-sphinx_rtd_theme
> [   32s] [226/263] cumulate python3-sphinxcontrib-websupport-1.1.0-1.2
> [   32s] [239/263] cumulate python3-Sphinx-1.8.5-2.2
> [   32s] [242/263] cumulate python3-sphinx_rtd_theme-0.4.1-1.3
> [   72s]
> python3-sphinxcontrib-websupport-1.1.0
> [   72s] python3-sphinx_rtd_theme-0.4.1-1.3
> 
> [   73s] python3-Sphinx-1.8.5-2.2
> 
> [   73s] update-alternatives: using /usr/bin/sphinx-apidoc-3.7 to
> provide /usr/bin/sphinx-apidoc (sphinx-apidoc) in auto mode
> [  101s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i
> /home/abuild/rpmbuild/BUILD/kernel-docs-5.1.8/patches.kernel.org/5.1.8-055-docs-Fix-conf.py-for-Sphin-2.0.patch
> [  101s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i
> /home/abuild/rpmbuild/BUILD/kernel-docs-5.1.8/patches.kernel.org/5.1.8-057-doc-Cope-with-Sphinx-logging-deprecations.patch
> [  102s]   SPHINX  htmldocs -->
> file:///home/abuild/rpmbuild/BUILD/kernel-docs-5.1.8/linux-5.1/html/Documentation/output
> [  103s] Running Sphinx v1.8.5

Hm, 2.1 here:
Running Sphinx v2.1.0
perhaps Tumbleweed needs to update?  :)

Anyway, this should not be breaking, if Jon doesn't have any ideas, I'll
just drop these changes.

thanks,

greg k-h


Re: [PATCH] drivers/ata: print trim features at device initialization

2019-06-10 Thread Konstantin Khlebnikov

On 10.06.2019 0:37, James Bottomley wrote:

On Sat, 2019-06-08 at 17:13 +0300, Konstantin Khlebnikov wrote:

On 08.06.2019 11:25, Christoph Hellwig wrote:> On Fri, Jun 07, 2019
at 10:34:39AM +0300, Konstantin Khlebnikov wrote:
  >
  > Do we really need to spam dmesg with even more ATA crap?  What
about
  > a sysfs file that can be read on demand instead?
  >

Makes sense.

Trim state is exposed for ata_device:
/sys/class/ata_device/devX.Y/trim
but there is no link from scsi device to ata device so they hard to
match.

I'll think about it.


Nope. There is no obvious way to link scsi device with ata_device.
ata_device is built on top of "transport_class" and
"attribute_container".
This some extremely over engineered sysfs framework used only in
ata/scsi. I don't want to touch this.


You don't need to know any of that.  The problem is actually when the
ata transport classes were first created, the devices weren't properly
parented.  What should have happened, like every other transport class,
is that the devices should have descended down to the scsi device as
the leaf in an integrated fashion.  Instead, what we seem to have is
three completely separate trees.

So if you look at a SAS device, you see from the pci device:

host2/port-2:0/end_device-2:0/target2:0:0/2:0:0:0/block/sdb/sdb1

But if you look at a SATA device, you see three separate paths:

ata3/host3/target3\:0\:0/3\:0\:0\:0/block/sda/sda1
ata3/link3/dev3.0/ata_device/dev3.0
ata3/ata_port/ata3

Instead of an integrated tree

Unfortunately, this whole thing is unfixable now.  If I integrate the
tree properly, the separate port and link directories will get subsumed
and we won't be able to recover them with judicious linking so scripts
relying on them will break.  The best we can probably do is add
additional links with what we have.

To follow the way we usually do it, there should be a link from the ata
device to the scsi target, but that wouldn't help you find the "trim"
files, so it sounds like you want a link from the scsi device to the ata 
device, which would?


Yes, I'm talking about link from scsi device to leaf ata_device node.

In libata scsi_device has one to one relation with ata_device.
So making link like /sys/class/block/sda/device/ata_device should be possible 
easy.
But I haven't found implicit reference from struct ata_device to ata_device in 
sysfs.

In simplest ahci case whole path looks like:
/sys/devices/pci:00/:00:1f.2/ata1/link1/dev1.0/ata_device/dev1.0
|__|__ata_host__|port|link_|_tdev_|___ata_device___|


/sys/class/ata_device/dev1.0 points directly to leaf ata_device
While in struct ata_device tdev is different intermediate node.

It would be nice merge tdev and ata_device into one node, or at least embed leaf
struct device into struct ata_device too.

As I see ata registers only "transport" device while scsi transport template
magically matches it and creates actual ata device of ata_dev_class.
I see no reason for this complexity. Why ata host couldn't enumerate and
register all these devices explicitly?


Re: [PATCH v3 5/8] arm64: Fix incorrect irqflag restore for priority masking

2019-06-10 Thread Julien Thierry



On 07/06/2019 17:29, Marc Zyngier wrote:
> On 06/06/2019 10:31, Julien Thierry wrote:
>> When using IRQ priority masking to disable interrupts, in order to deal
>> with the PSR.I state, local_irq_save() would convert the I bit into a
>> PMR value (GIC_PRIO_IRQOFF). This resulted in local_irq_restore()
>> potentially modifying the value of PMR in undesired location due to the
>> state of PSR.I upon flag saving [1].
>>
>> In an attempt to solve this issue in a less hackish manner, introduce
>> a bit (GIC_PRIO_IGNORE_PMR) for the PMR values that can represent
>> whether PSR.I is being used to disable interrupts, in which case it
>> takes precedence of the status of interrupt masking via PMR.
>>
>> GIC_PRIO_IGNORE_PMR is chosen such that ( |
>> GIC_PRIO_IGNORE_PMR) does not mask more interrupts than  as
>> some sections (e.g. arch_cpu_idle(), interrupt acknowledge path)
>> requires PMR not to mask interrupts that could be signaled to the
>> CPU when using only PSR.I.
>>
> 
> s/GIC_PRIO_IGNORE_PMR/GIC_PRIO_PSR_I_SET/
> 
>> [1] https://www.spinics.net/lists/arm-kernel/msg716956.html
>>
>> Fixes: commit 4a503217ce37 ("arm64: irqflags: Use ICC_PMR_EL1 for interrupt 
>> masking")
>> Signed-off-by: Julien Thierry 
>> Reported-by: Zenghui Yu 
>> Cc: Steven Rostedt 
>> Cc: Wei Li 
>> Cc: Catalin Marinas 
>> Cc: Will Deacon 
>> Cc: Christoffer Dall 
>> Cc: Marc Zyngier 
>> Cc: James Morse 
>> Cc: Suzuki K Pouloze 
>> Cc: Oleg Nesterov 
>> ---
>>  arch/arm64/include/asm/arch_gicv3.h |  4 ++-
>>  arch/arm64/include/asm/daifflags.h  | 68 
>> ++---
>>  arch/arm64/include/asm/irqflags.h   | 67 
>> +++-
>>  arch/arm64/include/asm/kvm_host.h   |  7 ++--
>>  arch/arm64/include/asm/ptrace.h | 10 --
>>  arch/arm64/kernel/entry.S   | 38 ++---
>>  arch/arm64/kernel/process.c |  2 +-
>>  arch/arm64/kernel/smp.c |  8 +++--
>>  arch/arm64/kvm/hyp/switch.c |  2 +-
>>  9 files changed, 123 insertions(+), 83 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/arch_gicv3.h 
>> b/arch/arm64/include/asm/arch_gicv3.h
>> index 14b41dd..9e991b6 100644
>> --- a/arch/arm64/include/asm/arch_gicv3.h
>> +++ b/arch/arm64/include/asm/arch_gicv3.h
>> @@ -163,7 +163,9 @@ static inline bool gic_prio_masking_enabled(void)
>>
>>  static inline void gic_pmr_mask_irqs(void)
>>  {
>> -BUILD_BUG_ON(GICD_INT_DEF_PRI <= GIC_PRIO_IRQOFF);
>> +BUILD_BUG_ON(GICD_INT_DEF_PRI < (GIC_PRIO_IRQOFF |
>> + GIC_PRIO_PSR_I_SET));
>> +BUILD_BUG_ON(GICD_INT_DEF_PRI >= GIC_PRIO_IRQON);
>>  gic_write_pmr(GIC_PRIO_IRQOFF);
>>  }
>>
>> diff --git a/arch/arm64/include/asm/daifflags.h 
>> b/arch/arm64/include/asm/daifflags.h
>> index db452aa..f93204f 100644
>> --- a/arch/arm64/include/asm/daifflags.h
>> +++ b/arch/arm64/include/asm/daifflags.h
>> @@ -18,6 +18,7 @@
>>
>>  #include 
>>
>> +#include 
>>  #include 
>>
>>  #define DAIF_PROCCTX0
>> @@ -32,6 +33,11 @@ static inline void local_daif_mask(void)
>>  :
>>  :
>>  : "memory");
>> +
>> +/* Don't really care for a dsb here, we don't intend to enable IRQs */
>> +if (system_uses_irq_prio_masking())
>> +gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
>> +
>>  trace_hardirqs_off();
>>  }
>>
>> @@ -43,7 +49,7 @@ static inline unsigned long local_daif_save(void)
>>
>>  if (system_uses_irq_prio_masking()) {
>>  /* If IRQs are masked with PMR, reflect it in the flags */
>> -if (read_sysreg_s(SYS_ICC_PMR_EL1) <= GIC_PRIO_IRQOFF)
>> +if (read_sysreg_s(SYS_ICC_PMR_EL1) != GIC_PRIO_IRQON)
>>  flags |= PSR_I_BIT;
>>  }
>>
>> @@ -59,36 +65,44 @@ static inline void local_daif_restore(unsigned long 
>> flags)
>>  if (!irq_disabled) {
>>  trace_hardirqs_on();
>>
>> -if (system_uses_irq_prio_masking())
>> -arch_local_irq_enable();
>> -} else if (!(flags & PSR_A_BIT)) {
>> -/*
>> - * If interrupts are disabled but we can take
>> - * asynchronous errors, we can take NMIs
>> - */
>>  if (system_uses_irq_prio_masking()) {
>> -flags &= ~PSR_I_BIT;
>> +gic_write_pmr(GIC_PRIO_IRQON);
>> +dsb(sy);
>> +}
>> +} else if (system_uses_irq_prio_masking()) {
>> +u64 pmr;
>> +
>> +if (!(flags & PSR_A_BIT)) {
>>  /*
>> - * There has been concern that the write to daif
>> - * might be reordered before this write to PMR.
>> - * From the ARM ARM DDI 0487D.a, section D1.7.1
>> - * "Accessing PSTATE fields":
>> - *   Writes to the PSTATE fields have side-effects on
>> - *   various aspects of the PE ope

Re: [PATCH 4/7] staging: kpc2000: use __func__ in debug messages in core.c

2019-06-10 Thread Greg KH
On Mon, Jun 10, 2019 at 09:20:09AM +0200, Simon Sandström wrote:
> On 06/06, Greg KH wrote:
> > On Tue, Jun 04, 2019 at 12:29:13AM +0200, Simon Sandström wrote:
> > >  
> > > - dev_dbg(&pdev->dev, "kp2000_pcie_probe(pdev = [%p], id = [%p])\n",
> > > - pdev, id);
> > > + dev_dbg(&pdev->dev, "%s(pdev = [%p], id = [%p])\n",
> > > + __func__, pdev, id);
> > 
> > debugging lines that say "called this function!" can all be removed, as
> > we have ftrace in the kernel tree, we can use that instead.  I'll take
> > this, but feel free to clean them up as follow-on patches.
> > 
> > thanks,
> > 
> > greg k-h
> 
> Can they be removed even if they print function arguments or other
> variables?

Of course!


Re: [PATCH v3 6/8] arm64: irqflags: Introduce explicit debugging for IRQ priorities

2019-06-10 Thread Julien Thierry



On 07/06/2019 17:31, Marc Zyngier wrote:
> On 06/06/2019 10:31, Julien Thierry wrote:
>> Using IRQ priority masking to enable/disable interrupts is a bit
>> sensitive as it requires to deal with both ICC_PMR_EL1 and PSR.I.
>>
>> Introduce some validity checks to both highlight the states in which
>> functions dealing with IRQ enabling/disabling can (not) be called, and
>> bark a warning when called in an unexpected state.
>>
>> Since these checks are done on hotpaths, introduce a build option to
>> choose whether to do the checking.
>>
>> Signed-off-by: Julien Thierry 
>> Cc: Catalin Marinas 
>> Cc: Will Deacon 
>> ---
>>  arch/arm64/Kconfig  | 11 +++
>>  arch/arm64/include/asm/cpufeature.h |  6 ++
>>  arch/arm64/include/asm/daifflags.h  |  7 +++
>>  arch/arm64/include/asm/irqflags.h   | 14 +-
>>  4 files changed, 37 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 697ea05..8acc40e 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -1436,6 +1436,17 @@ config ARM64_PSEUDO_NMI
>>
>>If unsure, say N
>>
>> +if ARM64_PSEUDO_NMI
>> +config ARM64_DEBUG_PRIORITY_MASKING
>> +bool "Debug interrupt priority masking"
>> +help
>> +  This adds runtime checks to functions enabling/disabling
>> +  interrupts when using priority masking. The additional checks verify
>> +  the validity of ICC_PMR_EL1 when calling concerned functions.
>> +
>> +  If unsure, say N
>> +endif
>> +
>>  config RELOCATABLE
>>  bool
>>  help
>> diff --git a/arch/arm64/include/asm/cpufeature.h 
>> b/arch/arm64/include/asm/cpufeature.h
>> index bc895c8..693a086 100644
>> --- a/arch/arm64/include/asm/cpufeature.h
>> +++ b/arch/arm64/include/asm/cpufeature.h
>> @@ -617,6 +617,12 @@ static inline bool system_uses_irq_prio_masking(void)
>> cpus_have_const_cap(ARM64_HAS_IRQ_PRIO_MASKING);
>>  }
>>
>> +static inline bool system_has_prio_mask_debugging(void)
>> +{
>> +return IS_ENABLED(CONFIG_ARM64_DEBUG_PRIORITY_MASKING) &&
>> +   system_uses_irq_prio_masking();
>> +}
>> +
>>  #define ARM64_SSBD_UNKNOWN  -1
>>  #define ARM64_SSBD_FORCE_DISABLE0
>>  #define ARM64_SSBD_KERNEL   1
>> diff --git a/arch/arm64/include/asm/daifflags.h 
>> b/arch/arm64/include/asm/daifflags.h
>> index f93204f..eca5bee 100644
>> --- a/arch/arm64/include/asm/daifflags.h
>> +++ b/arch/arm64/include/asm/daifflags.h
>> @@ -28,6 +28,10 @@
>>  /* mask/save/unmask/restore all exceptions, including interrupts. */
>>  static inline void local_daif_mask(void)
>>  {
>> +WARN_ON(system_has_prio_mask_debugging() &&
>> +(read_sysreg_s(SYS_ICC_PMR_EL1) == (GIC_PRIO_IRQOFF |
>> +GIC_PRIO_PSR_I_SET)));
>> +
>>  asm volatile(
>>  "msrdaifset, #0xf   // local_daif_mask\n"
>>  :
>> @@ -62,6 +66,9 @@ static inline void local_daif_restore(unsigned long flags)
>>  {
>>  bool irq_disabled = flags & PSR_I_BIT;
>>
>> +WARN_ON(system_has_prio_mask_debugging() &&
>> +!(read_sysreg(daif) & PSR_I_BIT));
>> +
>>  if (!irq_disabled) {
>>  trace_hardirqs_on();
>>
>> diff --git a/arch/arm64/include/asm/irqflags.h 
>> b/arch/arm64/include/asm/irqflags.h
>> index b6f757f..cac2d2a 100644
>> --- a/arch/arm64/include/asm/irqflags.h
>> +++ b/arch/arm64/include/asm/irqflags.h
>> @@ -40,6 +40,12 @@
>>   */
>>  static inline void arch_local_irq_enable(void)
>>  {
>> +if (system_has_prio_mask_debugging()) {
>> +u32 pmr = read_sysreg_s(SYS_ICC_PMR_EL1);
>> +
>> +WARN_ON_ONCE(pmr != GIC_PRIO_IRQON && pmr != GIC_PRIO_IRQOFF);
>> +}
>> +
>>  asm volatile(ALTERNATIVE(
>>  "msrdaifclr, #2 // arch_local_irq_enable\n"
>>  "nop",
>> @@ -53,6 +59,12 @@ static inline void arch_local_irq_enable(void)
>>
>>  static inline void arch_local_irq_disable(void)
>>  {
>> +if (system_has_prio_mask_debugging()) {
>> +u32 pmr = read_sysreg_s(SYS_ICC_PMR_EL1);
>> +
>> +WARN_ON_ONCE(pmr != GIC_PRIO_IRQON && pmr != GIC_PRIO_IRQOFF);
>> +}
>> +
>>  asm volatile(ALTERNATIVE(
>>  "msrdaifset, #2 // arch_local_irq_disable",
>>  __msr_s(SYS_ICC_PMR_EL1, "%0"),
>> @@ -86,7 +98,7 @@ static inline int arch_irqs_disabled_flags(unsigned long 
>> flags)
>>
>>  asm volatile(ALTERNATIVE(
>>  "and%w0, %w1, #" __stringify(PSR_I_BIT),
>> -"eor%w0, %w1, #" __stringify(GIC_PRIO_IRQOFF),
>> +"eor%w0, %w1, #" __stringify(GIC_PRIO_IRQON),
> 
> Err... Which version is the correct one? This one, or the previous one?
> 

Argh, bad fixup of the patches. This one is the correct one (any state
!= GIC_PRIO_IRQON means interrupts are disabled), but the correct value
should already be in use in the previous patch.

Will fix that in the next posting.

Re: [PATCH trivial] dmaengine: Grammar s/the its/its/, s/need/needs/

2019-06-10 Thread Vinod Koul
On 07-06-19, 13:30, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 

Applied, thanks

-- 
~Vinod


[PATCH v2] tty: serial: msm_serial: avoid system lockup condition

2019-06-10 Thread Jorge Ramirez-Ortiz
The function msm_wait_for_xmitr can be taken with interrupts
disabled. In order to avoid a potential system lockup - demonstrated
under stress testing conditions on SoC QCS404/5 - make sure we wait
for a bounded amount of time.

Tested on SoC QCS404.

Signed-off-by: Jorge Ramirez-Ortiz 
---
 drivers/tty/serial/msm_serial.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index 23833ad952ba..3657a24913fc 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -383,10 +383,14 @@ static void msm_request_rx_dma(struct msm_port *msm_port, 
resource_size_t base)
 
 static inline void msm_wait_for_xmitr(struct uart_port *port)
 {
+   unsigned int timeout = 50;
+
while (!(msm_read(port, UART_SR) & UART_SR_TX_EMPTY)) {
if (msm_read(port, UART_ISR) & UART_ISR_TX_READY)
break;
udelay(1);
+   if (!timeout--)
+   break;
}
msm_write(port, UART_CR_CMD_RESET_TX_READY, UART_CR);
 }
-- 
2.21.0



Re: [PATCH 5.1 56/85] doc: Cope with the deprecation of AutoReporter

2019-06-10 Thread Jiri Slaby
On 10. 06. 19, 9:48, Greg Kroah-Hartman wrote:
>> [  103s] Running Sphinx v1.8.5
> 
> Hm, 2.1 here:
>   Running Sphinx v2.1.0
> perhaps Tumbleweed needs to update?  :)

Heh, it was submitted 3 days ago :):
  https://build.opensuse.org/request/show/708276
(And is blocked by a failing sphinx-test AFAICT.)

> Anyway, this should not be breaking, if Jon doesn't have any ideas, I'll
> just drop these changes.

OK. In the meantime, I have reverted the commit in Kernel:stable for the
time being.

thanks,
-- 
js
suse labs


Re: [PATCH 3/8] pinctrl: msm: Add ability for drivers to supply a reserved GPIO list

2019-06-10 Thread Lee Jones
On Fri, 07 Jun 2019, Bjorn Andersson wrote:

> On Fri 07 Jun 16:02 PDT 2019, Linus Walleij wrote:
> 
> > On Wed, Jun 5, 2019 at 1:43 PM Lee Jones  wrote:
> > 
> > > When booting MSM based platforms with Device Tree or some ACPI
> > > implementations, it is possible to provide a list of reserved pins
> > > via the 'gpio-reserved-ranges' and 'gpios' properties respectively.
> > > However some ACPI tables are not populated with this information,
> > > thus it has to come from a knowledgable device driver instead.
> > >
> > > Here we provide the MSM common driver with additional support to
> > > parse this informtion and correctly populate the widely used
> > > 'valid_mask'.
> > >
> > > Signed-off-by: Lee Jones 
> > 
> > Exactly how we should use of the API, so if Björn can supply an
> > ACK to patches 3 and 4 I'm happy to apply them.
> > 
> > Björn?
> > 
> 
> I'm waiting for a version that does not specify the reserved_gpios for
> struct msm_pinctrl_soc_data sdm845_pinctrl {}, as this would override
> the ability of getting these from DT.
> 
> I haven't seen such revision yet, will review it once I find it.

Just testing it now.  It should be on the list by the time you start.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH/RFC] dmaengine: Create symlinks from DMA channels to slaves

2019-06-10 Thread Vinod Koul
On 07-06-19, 13:38, Geert Uytterhoeven wrote:
> Currently it is not easy to find out which DMA channels are in use, and
> by which slave devices.
> 
> Fix this by creating in sysfs a "slave" symlink from the DMA channel to
> the actual slave device when a channel is requested, and removing it
> again when the channel is released.
> 
> For now this is limited to DT and ACPI.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> Questions:
>   1. Do you think this is useful?

Yes for me at least :)

>   2. Should backlinks (e.g. "dma:") be created from the slave
>  device to the DMA channel?
>  This requires storing the name in struct dma_chan, for later
>  symlink removal.

that would certainly be more helpful

>   3. Should this be extended to other ways of requesting channels?
>  In many cases, no device pointer is available, so a device pointer
>  parameter has to be added to all DMA channel request APIs that
>  don't have it yet.

I think that would need to be done.

> ---
>  drivers/dma/dmaengine.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 03ac4b96117cd8db..c11476f76fc96bcf 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -706,6 +706,10 @@ struct dma_chan *dma_request_chan(struct device *dev, 
> const char *name)
>  
>   if (chan) {
>   /* Valid channel found or requester needs to be deferred */
> + if (!IS_ERR(chan) &&
> +  sysfs_create_link(&chan->dev->device.kobj, &dev->kobj,
> +"slave"))
> + dev_err(dev, "Cannot create DMA slave symlink\n");
>   if (!IS_ERR(chan) || PTR_ERR(chan) == -EPROBE_DEFER)
>   return chan;
>   }
> @@ -786,6 +790,7 @@ void dma_release_channel(struct dma_chan *chan)
>   /* drop PRIVATE cap enabled by __dma_request_channel() */
>   if (--chan->device->privatecnt == 0)
>   dma_cap_clear(DMA_PRIVATE, chan->device->cap_mask);
> + sysfs_remove_link(&chan->dev->device.kobj, "slave");
>   mutex_unlock(&dma_list_mutex);
>  }
>  EXPORT_SYMBOL_GPL(dma_release_channel);
> -- 
> 2.17.1

-- 
~Vinod


Re: [RFC PATCH 1/6] ASoC: core: add support to snd_soc_dai_get_sdw_stream()

2019-06-10 Thread Srinivas Kandagatla




On 10/06/2019 05:34, Vinod Koul wrote:

On 07-06-19, 09:56, Srinivas Kandagatla wrote:

On platforms which have smart speaker amplifiers connected via
soundwire and modeled as aux devices in ASoC, in such usecases machine
driver should be able to get sdw master stream from dai so that it can
use the runtime stream to setup slave streams.

soundwire already as a set function, get function would provide more
flexibility to above configurations.

Signed-off-by: Srinivas Kandagatla 
---
  include/sound/soc-dai.h | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index f5d70041108f..9f90b936fd9a 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -177,6 +177,7 @@ struct snd_soc_dai_ops {
  
  	int (*set_sdw_stream)(struct snd_soc_dai *dai,

void *stream, int direction);
+   void *(*get_sdw_stream)(struct snd_soc_dai *dai, int direction);


So who would be calling this API? Machine or someone else?


From Machine driver in my case where smart speaker amplifiers are 
modeled as aux device which is also dai less.


--srini




[PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards

2019-06-10 Thread xieqinick
From: Nick Xie 

Add devicetree support for Khadas Edge/Edge-V/Captain boards.
Khadas Edge is an expandable Rockchip RK3399 board with goldfinger.
Khadas Captain is the carrier board for Khadas Edge.
Khadas Edge-V is a Khadas VIM form factor Rockchip RK3399 board.

Signed-off-by: Nick Xie 
---
Changes for v2:
- DTS tidy up
- Use full name for patch and Signed-off lines
- Add entries to rockchip.yaml
- Rename DTS for Khadas Captain board

 .../devicetree/bindings/arm/rockchip.yaml  |   8 +
 arch/arm64/boot/dts/rockchip/Makefile  |   3 +
 .../dts/rockchip/rk3399-khadas-edge-captain.dts|  27 +
 .../boot/dts/rockchip/rk3399-khadas-edge-v.dts |  27 +
 .../arm64/boot/dts/rockchip/rk3399-khadas-edge.dts |  13 +
 .../boot/dts/rockchip/rk3399-khadas-edge.dtsi  | 790 +
 6 files changed, 868 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-captain.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-v.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml 
b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 5c6bbf1..eef822c 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -316,6 +316,14 @@ properties:
   - const: haoyu,marsboard-rk3066
   - const: rockchip,rk3066a
 
+  - description: Khadas Edge series boards
+items:
+  - enum:
+  - khadas,edge
+  - khadas,edge-captain
+  - khadas,edge-v
+  - const: rockchip,rk3399
+
   - description: mqmaker MiQi
 items:
   - const: mqmaker,miqi
diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index 5f2687a..b50889a 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -16,6 +16,9 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-bob.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-scarlet-inx.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-scarlet-kd.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-captain.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-v.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-captain.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-captain.dts
new file mode 100644
index 000..8302e51
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-captain.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include "rk3399-khadas-edge.dtsi"
+
+/ {
+   model = "Khadas Edge-Captain";
+   compatible = "khadas,edge-captain", "rockchip,rk3399";
+};
+
+&gmac {
+   status = "okay";
+};
+
+&pcie_phy {
+   status = "okay";
+};
+
+&pcie0 {
+   ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+   num-lanes = <4>;
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-v.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-v.dts
new file mode 100644
index 000..f5dcb99
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-v.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include "rk3399-khadas-edge.dtsi"
+
+/ {
+   model = "Khadas Edge-V";
+   compatible = "khadas,edge-v", "rockchip,rk3399";
+};
+
+&gmac {
+   status = "okay";
+};
+
+&pcie_phy {
+   status = "okay";
+};
+
+&pcie0 {
+   ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+   num-lanes = <4>;
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dts
new file mode 100644
index 000..31616e7
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include "rk3399-khadas-edge.dtsi"
+
+/ {
+   model = "Khadas Edge";
+   compatible = "khadas,edge", "rockchip,rk3399";
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
new file mode 100644
index 000..216dd68
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
@@ -0,0 +1,790 @@
+// SPDX-License-Identifier: 

Re: [PATCH] [RFC] dmaengine: add fifo_size member

2019-06-10 Thread Jon Hunter


On 07/06/2019 14:35, Peter Ujfalusi wrote:
> 
> 
> On 07/06/2019 15.58, Jon Hunter wrote:
>>> Imho if you can explain it without using 'HACK' in the sentences it
>>> might be OK, but it does not feel right.
>>
>> I don't perceive this as a hack. Although from looking at the
>> description of the src/dst_maxburst these are burst size with regard to
>> the device, so maybe it is a stretch.
>>
>>> However since your ADMA and ADMIF is highly coupled and it does needs
>>> special maxburst information (burst and allocated FIFO depth) I would
>>> rather use src_maxburst/dst_maxburst alone for DEV_TO_MEM/MEM_TO_DEV:
>>>
>>> ADMA_BURST_SIZE(maxburst)   ((maxburst) & 0xff)
>>> ADMA_FIFO_SIZE(maxburst)(((maxburst) >> 8) & 0xff)
>>>
>>> So lower 1 byte is the burst value you want from ADMA
>>> the other 3 bytes are the allocated FIFO size for the given ADMAIF channel.
>>>
>>> Sure, you need a header for this to make sure there is no
>>> misunderstanding between the two sides.
>>
>> I don't like this because as I mentioned to Dmitry, the ADMA can perform
>> memory-to-memory transfers where such encoding would not be applicable.
> 
> mem2mem does not really use dma_slave_config, it is for used by
> is_slave_direction() == true type of transfers.
> 
> But true, if you use ADMA against anything other than ADMAIF then this
> might be not right for non cyclic transfers.
> 
>> That does not align with the description in the
>> include/linux/dmaengine.h either.
> 
> True.
> 
>>> Or pass the allocated FIFO size via maxburst and then the ADMA driver
>>> will pick a 'good/safe' burst value for it.
>>>
>>> Or new member, but do you need two of them for src/dst? Probably
>>> fifo_depth is better word for it, or allocated_fifo_depth.
>>
>> Right, so looking at the struct dma_slave_config we have ...
>>
>> u32 src_maxburst;
>> u32 dst_maxburst;
>> u32 src_port_window_size;
>> u32 dst_port_window_size;
>>
>> Now if we could make these window sizes a union like the following this
>> could work ...
>>
>> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
>> index 8fcdee1c0cf9..851251263527 100644
>> --- a/include/linux/dmaengine.h
>> +++ b/include/linux/dmaengine.h
>> @@ -360,8 +360,14 @@ struct dma_slave_config {
>> enum dma_slave_buswidth dst_addr_width;
>> u32 src_maxburst;
>> u32 dst_maxburst;
>> -   u32 src_port_window_size;
>> -   u32 dst_port_window_size;
>> +   union {
>> +   u32 port_window_size;
>> +   u32 port_fifo_size;
>> +   } src;
>> +   union {
>> +   u32 port_window_size;
>> +   u32 port_fifo_size;
>> +   } dst;
> 
> What if in the future someone will have a setup where they would need both?

I think if you look at the description for the port_window_size you will
see that this is not applicable for FIFOs and so these would be mutually
exclusive AFAICT. However, if there was an even weirder DMA out there in
the future it could always be patched :-)

> So not sure. Your problems are coming from a split DMA setup where the
> two are highly coupled, but sits in a different place and need to be
> configured as one device.
> 
> I think xilinx_dma is facing with similar issues and they have a custom
> API to set parameters which does not fit or is peripheral specific:
> include/linux/dma/xilinx_dma.h
> 
> Not sure if that is an acceptable solution.

I am not a fan of that but it could work.

Cheers
Jon

-- 
nvpublic


Re: [PATCH] [RFC] dmaengine: add fifo_size member

2019-06-10 Thread Jon Hunter


On 07/06/2019 21:53, Dmitry Osipenko wrote:
> 07.06.2019 16:35, Peter Ujfalusi пишет:
>>
>>
>> On 07/06/2019 15.58, Jon Hunter wrote:
 Imho if you can explain it without using 'HACK' in the sentences it
 might be OK, but it does not feel right.
>>>
>>> I don't perceive this as a hack. Although from looking at the
>>> description of the src/dst_maxburst these are burst size with regard to
>>> the device, so maybe it is a stretch.
>>>
 However since your ADMA and ADMIF is highly coupled and it does needs
 special maxburst information (burst and allocated FIFO depth) I would
 rather use src_maxburst/dst_maxburst alone for DEV_TO_MEM/MEM_TO_DEV:

 ADMA_BURST_SIZE(maxburst)  ((maxburst) & 0xff)
 ADMA_FIFO_SIZE(maxburst)   (((maxburst) >> 8) & 0xff)

 So lower 1 byte is the burst value you want from ADMA
 the other 3 bytes are the allocated FIFO size for the given ADMAIF channel.

 Sure, you need a header for this to make sure there is no
 misunderstanding between the two sides.
>>>
>>> I don't like this because as I mentioned to Dmitry, the ADMA can perform
>>> memory-to-memory transfers where such encoding would not be applicable.
>>
>> mem2mem does not really use dma_slave_config, it is for used by
>> is_slave_direction() == true type of transfers.
>>
>> But true, if you use ADMA against anything other than ADMAIF then this
>> might be not right for non cyclic transfers.
>>
>>> That does not align with the description in the
>>> include/linux/dmaengine.h either.
>>
>> True.
>>
 Or pass the allocated FIFO size via maxburst and then the ADMA driver
 will pick a 'good/safe' burst value for it.

 Or new member, but do you need two of them for src/dst? Probably
 fifo_depth is better word for it, or allocated_fifo_depth.
>>>
>>> Right, so looking at the struct dma_slave_config we have ...
>>>
>>> u32 src_maxburst;
>>> u32 dst_maxburst;
>>> u32 src_port_window_size;
>>> u32 dst_port_window_size;
>>>
>>> Now if we could make these window sizes a union like the following this
>>> could work ...
>>>
>>> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
>>> index 8fcdee1c0cf9..851251263527 100644
>>> --- a/include/linux/dmaengine.h
>>> +++ b/include/linux/dmaengine.h
>>> @@ -360,8 +360,14 @@ struct dma_slave_config {
>>> enum dma_slave_buswidth dst_addr_width;
>>> u32 src_maxburst;
>>> u32 dst_maxburst;
>>> -   u32 src_port_window_size;
>>> -   u32 dst_port_window_size;
>>> +   union {
>>> +   u32 port_window_size;
>>> +   u32 port_fifo_size;
>>> +   } src;
>>> +   union {
>>> +   u32 port_window_size;
>>> +   u32 port_fifo_size;
>>> +   } dst;
>>
>> What if in the future someone will have a setup where they would need both?
>>
>> So not sure. Your problems are coming from a split DMA setup where the
>> two are highly coupled, but sits in a different place and need to be
>> configured as one device.
>>
>> I think xilinx_dma is facing with similar issues and they have a custom
>> API to set parameters which does not fit or is peripheral specific:
>> include/linux/dma/xilinx_dma.h
>>
>> Not sure if that is an acceptable solution.
> 
> If there are no other drivers with the exactly same requirement, then
> the custom API is an a good variant given that there is a precedent
> already. It is always possible to convert to a common thing later on
> since that's all internal to kernel.
> 
> Jon / Sameer, you should check all the other drivers thoroughly to find
> anyone who is doing the same thing as you need in order to achieve
> something that is really common. I'm also wondering if it will be
> possible to make dma_slave_config more flexible in order to start
> accepting vendor specific properties in a somewhat common fashion, maybe
> Vinod and Dan already have some thoughts on it? Apparently there is
> already a need for the customization and people are just starting to
> invent their own thing, but maybe that's fine too. That's really up to
> subsys maintainer to decide in what direction to steer.

I am not a fan of having custom APIs, however, I would agree that
extending the dma_slave_config to allow a DMA specific structure to be
passed with additional configuration would be useful in this case as
well as the Xilinx case.

Cheers
Jon

-- 
nvpublic


Re: [PATCH 3/8] pinctrl: msm: Add ability for drivers to supply a reserved GPIO list

2019-06-10 Thread Lee Jones
On Fri, 07 Jun 2019, Bjorn Andersson wrote:

> On Wed 05 Jun 04:42 PDT 2019, Lee Jones wrote:
> 
> > When booting MSM based platforms with Device Tree or some ACPI
> > implementations, it is possible to provide a list of reserved pins
> > via the 'gpio-reserved-ranges' and 'gpios' properties respectively.
> > However some ACPI tables are not populated with this information,
> > thus it has to come from a knowledgable device driver instead.
> > 
> > Here we provide the MSM common driver with additional support to
> > parse this informtion and correctly populate the widely used
> > 'valid_mask'.
> > 
> > Signed-off-by: Lee Jones 
> > ---
> >  drivers/pinctrl/qcom/pinctrl-msm.c | 18 ++
> >  drivers/pinctrl/qcom/pinctrl-msm.h |  1 +
> >  2 files changed, 19 insertions(+)
> > 
> > diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
> > b/drivers/pinctrl/qcom/pinctrl-msm.c
> > index ee8119879c4c..3ac740b36508 100644
> > --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> > +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> > @@ -607,8 +607,23 @@ static int msm_gpio_init_valid_mask(struct gpio_chip 
> > *chip)
> > int ret;
> > unsigned int len, i;
> > unsigned int max_gpios = pctrl->soc->ngpios;
> > +   const int *reserved = pctrl->soc->reserved_gpios;
> > u16 *tmp;
> >  
> > +   /* Driver provided reserved list overrides DT and ACPI */
> > +   if (reserved) {
> > +   bitmap_fill(chip->valid_mask, max_gpios);
> > +   for (i = 0; reserved[i] >= 0; i++) {
> > +   if (i >= max_gpios || reserved[i] >= max_gpios) {
> 
> reserved is a list of GPIOs to reserve, I don't see a reason to check
> if that list is longer than the number of GPIOs (i.e. the first half of
> the condition).
> 
> It wouldn't make sense to be, but there's no logical issue with it and I
> had to read the conditional a few extra times to be sure what was going
> on.

If nothing else, it's an early hard stop in case someone forgot to
terminate the reserved array.

> Apart from that you have my
> 
> Reviewed-by: Bjorn Andersson 

Thanks Bjorn.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH bpf v2] xdp: fix hang while unregistering device bound to xdp socket

2019-06-10 Thread Ilya Maximets
On 08.06.2019 2:31, Jakub Kicinski wrote:
> On Fri,  7 Jun 2019 20:31:43 +0300, Ilya Maximets wrote:
>> +static int xsk_notifier(struct notifier_block *this,
>> +unsigned long msg, void *ptr)
>> +{
>> +struct sock *sk;
>> +struct net_device *dev = netdev_notifier_info_to_dev(ptr);
>> +struct net *net = dev_net(dev);
>> +int i, unregister_count = 0;
> 
> Please order the var declaration lines longest to shortest.
> (reverse christmas tree)

Hi.
I'm not a fan of mixing 'struct's with bare types in the declarations.
Moving the 'sk' to the third place will make a hole like this:

struct net_device *dev = netdev_notifier_info_to_dev(ptr);
struct net *net = dev_net(dev);
struct sock *sk;
int i, unregister_count = 0;

Which is not looking good.
Moving to the 4th place:

struct net_device *dev = netdev_notifier_info_to_dev(ptr);
struct net *net = dev_net(dev);
int i, unregister_count = 0;
struct sock *sk;

This variant doesn't look good for me because of mixing 'struct's with
bare integers.

Do you think I need to use one of above variants?

> 
>> +mutex_lock(&net->xdp.lock);
>> +sk_for_each(sk, &net->xdp.list) {
>> +struct xdp_sock *xs = xdp_sk(sk);
>> +
>> +mutex_lock(&xs->mutex);
>> +switch (msg) {
>> +case NETDEV_UNREGISTER:
> 
> You should probably check the msg type earlier and not take all the
> locks and iterate for other types..

Yeah. I thought about it too. Will fix in the next version.

Best regards, Ilya Maximets.


Re: [PATCH v2] intel_th: msu: Fix unused variable warning on arm64 platform

2019-06-10 Thread Zhangshaokun
Hi Alexander,

A gentle ping.

On 2019/5/20 19:32, Shaokun Zhang wrote:
> drivers/hwtracing/intel_th/msu.c: In function ‘msc_buffer_win_alloc’:
> drivers/hwtracing/intel_th/msu.c:783:21: warning: unused variable ‘i’ 
> [-Wunused-variable]
>   int ret = -ENOMEM, i;
>  ^
> drivers/hwtracing/intel_th/msu.c: In function ‘msc_buffer_win_free’:
> drivers/hwtracing/intel_th/msu.c:863:6: warning: unused variable ‘i’ 
> [-Wunused-variable]
>   int i;
>   ^
> Fix this compiler warning on arm64 platform.
> 
> Cc: Alexander Shishkin 
> Cc: Greg Kroah-Hartman 
> Suggested-by: Alexander Shishkin 
> Signed-off-by: Shaokun Zhang 
> ---
>  drivers/hwtracing/intel_th/msu.c | 40 
> +++-
>  1 file changed, 27 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/hwtracing/intel_th/msu.c 
> b/drivers/hwtracing/intel_th/msu.c
> index 81bb54fa3ce8..49e64ca760e6 100644
> --- a/drivers/hwtracing/intel_th/msu.c
> +++ b/drivers/hwtracing/intel_th/msu.c
> @@ -767,6 +767,30 @@ static int __msc_buffer_win_alloc(struct msc_window *win,
>   return -ENOMEM;
>  }
>  
> +#ifdef CONFIG_X86
> +static void msc_buffer_set_uc(struct msc_window *win, unsigned int nr_blocks)
> +{
> + int i;
> +
> + for (i = 0; i < nr_blocks; i++)
> + /* Set the page as uncached */
> + set_memory_uc((unsigned long)msc_win_block(win, i), 1);
> +}
> +
> +static void msc_buffer_set_wb(struct msc_window *win)
> +{
> + int i;
> +
> + for (i = 0; i < win->nr_blocks; i++)
> + /* Reset the page to write-back */
> + set_memory_wb((unsigned long)msc_win_block(win, i), 1);
> +}
> +#else /* !X86 */
> +static inline void msc_buffer_set_uc(struct msc_window *win,
> +  unsigned int nr_blocks) {}
> +static inline void msc_buffer_set_wb(struct msc_window *win) {}
> +#endif /* CONFIG_X86 */
> +
>  /**
>   * msc_buffer_win_alloc() - alloc a window for a multiblock mode
>   * @msc: MSC device
> @@ -780,7 +804,7 @@ static int __msc_buffer_win_alloc(struct msc_window *win,
>  static int msc_buffer_win_alloc(struct msc *msc, unsigned int nr_blocks)
>  {
>   struct msc_window *win;
> - int ret = -ENOMEM, i;
> + int ret = -ENOMEM;
>  
>   if (!nr_blocks)
>   return 0;
> @@ -811,11 +835,7 @@ static int msc_buffer_win_alloc(struct msc *msc, 
> unsigned int nr_blocks)
>   if (ret < 0)
>   goto err_nomem;
>  
> -#ifdef CONFIG_X86
> - for (i = 0; i < ret; i++)
> - /* Set the page as uncached */
> - set_memory_uc((unsigned long)msc_win_block(win, i), 1);
> -#endif
> + msc_buffer_set_uc(win, ret);
>  
>   win->nr_blocks = ret;
>  
> @@ -860,8 +880,6 @@ static void __msc_buffer_win_free(struct msc *msc, struct 
> msc_window *win)
>   */
>  static void msc_buffer_win_free(struct msc *msc, struct msc_window *win)
>  {
> - int i;
> -
>   msc->nr_pages -= win->nr_blocks;
>  
>   list_del(&win->entry);
> @@ -870,11 +888,7 @@ static void msc_buffer_win_free(struct msc *msc, struct 
> msc_window *win)
>   msc->base_addr = 0;
>   }
>  
> -#ifdef CONFIG_X86
> - for (i = 0; i < win->nr_blocks; i++)
> - /* Reset the page to write-back */
> - set_memory_wb((unsigned long)msc_win_block(win, i), 1);
> -#endif
> + msc_buffer_set_wb(win);
>  
>   __msc_buffer_win_free(msc, win);
>  
> 



Re: [PATCH 1/2] mfd: core: Support multiple OF child devices of the same type

2019-06-10 Thread Lee Jones
On Thu, 06 Jun 2019, Robert Hancock wrote:

> On 2019-06-05 11:27 p.m., Lee Jones wrote:
>  Without having the .of_full_name support, both MFD cells ended up
>  wrongly matching against the i2c@c device tree node since we just
>  picked the first one where of_compatible matched.
> >>>
> >>> What is contained in each of their resources?
> >>
> >> These are the resource entries for those two devices:
> >>
> >> static const struct resource dbe_i2c1_resources[] = {
> >> {
> >>.start  = 0xc,
> >>.end= 0xc,
> >>.name   = "xi2c1_regs",
> >>.flags  = IORESOURCE_MEM,
> >>.desc   = IORES_DESC_NONE
> >> },
> >> };
> >>
> >> static const struct resource dbe_i2c2_resources[] = {
> >> {
> >>.start  = 0xd,
> >>.end= 0xd,
> >>.name   = "xi2c2_regs",
> >>.flags  = IORESOURCE_MEM,
> >>.desc   = IORES_DESC_NONE
> >> },
> >> };
> > 
> > This is your problem.  You are providing the memory resources through
> > *both* DT and MFD.  I don't believe I've seen your MFD driver, but it
> > looks like it's probably not required at all.  Just allow DT to probe
> > each of your child devices.  You can obtain the IO memory from there
> > directly using the usual platform_get_resource() calls.
> 
> As far as I can tell, the DT child devices underneath a PCIe device
> don't get probed and drivers loaded automatically - possibly for valid
> reasons. The MFD driver appears to be required in order to actually get
> drivers attached to those DT nodes.

You need to call of_platform_populate().

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH 4.19 00/51] 4.19.50-stable review

2019-06-10 Thread Naresh Kamboju
On Sun, 9 Jun 2019 at 22:17, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.19.50 release.
> There are 51 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue 11 Jun 2019 04:40:08 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.50-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.19.50-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 4954dbe53dd310cc698cab437bfe8bd965d26685
git describe: v4.19.48-126-g4954dbe53dd3
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.48-126-g4954dbe53dd3

No regressions (compared to build v4.19.48)

No fixes (compared to build v4.19.48)

Ran 24961 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH v1 1/3] clocksource/drivers/tegra: Remove duplicated use of per_cpu_ptr

2019-06-10 Thread Daniel Lezcano


Hi Dmitry,


On 09/06/2019 21:27, Dmitry Osipenko wrote:
> It was left unnoticed by accident, which means that the code could be
> cleaned up a tad more.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/clocksource/timer-tegra.c | 40 +++
>  1 file changed, 25 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/clocksource/timer-tegra.c 
> b/drivers/clocksource/timer-tegra.c
> index 9406855781ff..6da169de47f9 100644
> --- a/drivers/clocksource/timer-tegra.c
> +++ b/drivers/clocksource/timer-tegra.c
> @@ -216,6 +216,19 @@ static inline unsigned int tegra_irq_idx_for_cpu(int 
> cpu, bool tegra20)
>   return TIMER10_IRQ_IDX + cpu;
>  }
>  
> +static inline unsigned long tegra_rate_for_timer(struct timer_of *to,
> +  bool tegra20)
> +{
> + /*
> +  * TIMER1-9 are fixed to 1MHz, TIMER10-13 are running off the
> +  * parent clock.
> +  */
> + if (tegra20)
> + return 100;

Mind to take the opportunity to convert the literal value to a constant?

> +
> + return to->of_clk.rate;
> +}
> +
>  static int __init tegra_init_timer(struct device_node *np, bool tegra20,
>  int rating)
>  {
> @@ -268,30 +281,27 @@ static int __init tegra_init_timer(struct device_node 
> *np, bool tegra20,
>  
>   for_each_possible_cpu(cpu) {
>   struct timer_of *cpu_to = per_cpu_ptr(&tegra_to, cpu);
> + unsigned long flags = IRQF_TIMER | IRQF_NOBALANCING;
> + unsigned long rate = tegra_rate_for_timer(&tegra_to, tegra20);
>   unsigned int base = tegra_base_for_cpu(cpu, tegra20);
>   unsigned int idx = tegra_irq_idx_for_cpu(cpu, tegra20);
> + unsigned int irq = irq_of_parse_and_map(np, idx);
>  
> - /*
> -  * TIMER1-9 are fixed to 1MHz, TIMER10-13 are running off the
> -  * parent clock.
> -  */
> - if (tegra20)
> - cpu_to->of_clk.rate = 100;
> -
> - cpu_to = per_cpu_ptr(&tegra_to, cpu);
> - cpu_to->of_base.base = timer_reg_base + base;
> - cpu_to->clkevt.rating = rating;
> - cpu_to->clkevt.cpumask = cpumask_of(cpu);
> - cpu_to->clkevt.irq = irq_of_parse_and_map(np, idx);
> - if (!cpu_to->clkevt.irq) {
> + if (!irq) {
>   pr_err("failed to map irq for cpu%d\n", cpu);
>   ret = -EINVAL;
>   goto out_irq;
>   }
>  
> + cpu_to->clkevt.irq = irq;
> + cpu_to->clkevt.rating = rating;
> + cpu_to->clkevt.cpumask = cpumask_of(cpu);
> + cpu_to->of_base.base = timer_reg_base + base;
> + cpu_to->of_clk.rate = rate;
> +
>   irq_set_status_flags(cpu_to->clkevt.irq, IRQ_NOAUTOEN);
> - ret = request_irq(cpu_to->clkevt.irq, tegra_timer_isr,
> -   IRQF_TIMER | IRQF_NOBALANCING,
> +
> + ret = request_irq(cpu_to->clkevt.irq, tegra_timer_isr, flags,
> cpu_to->clkevt.name, &cpu_to->clkevt);
>   if (ret) {
>   pr_err("failed to set up irq for cpu%d: %d\n",
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog



I NEED YOUR PARTNERSHIP.

2019-06-10 Thread DR. OMAR KALIFA
-- 
Hello,

Compliment of the season. My name is Dr. Omar Kalifa. i work with one
of the reputable banks here in West Africa.I have a lucrative and
profitable business to discuse with you. Reply if you are intersted
for more details.

Regards,
Dr. Omar Kalifa


Re: [RFC PATCH 5/6] dt-bindings: soundwire: add bindings for Qcom controller

2019-06-10 Thread Srinivas Kandagatla




On 10/06/2019 05:51, Vinod Koul wrote:

On 07-06-19, 09:56, Srinivas Kandagatla wrote:

This patch adds bindings for Qualcomm soundwire controller.

Qualcomm SoundWire Master controller is present in most Qualcomm SoCs
either integrated as part of WCD audio codecs via slimbus or
as part of SOC I/O.

Signed-off-by: Srinivas Kandagatla 
---
  .../bindings/soundwire/qcom,swr.txt   | 62 +++


So I was expecting to see bus support patches for OF first. I think you
have missed those changes. Please do include those in v2 with bindings
and OF support for bus.


I was planning to post bus bindings along with soundwire slave bindings 
of WSA881x driver!

I will be sending this soon!




  1 file changed, 62 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/soundwire/qcom,swr.txt

diff --git a/Documentation/devicetree/bindings/soundwire/qcom,swr.txt 
b/Documentation/devicetree/bindings/soundwire/qcom,swr.txt
new file mode 100644
index ..eb84d0f4f36f
--- /dev/null
+++ b/Documentation/devicetree/bindings/soundwire/qcom,swr.txt
@@ -0,0 +1,62 @@
+Qualcomm SoundWire Controller
+
+This binding describes the Qualcomm SoundWire Controller Bindings.
+
+Required properties:
+
+- compatible:  Must be "qcom,soundwire-v..",
+   example:
+   "qcom,soundwire-v1.3.0"
+   "qcom,soundwire-v1.5.0"
+   "qcom,soundwire-v1.6.0"
+- reg: SoundWire controller address space.
+- interrupts:  SoundWire controller interrupt.
+- clock-names: Must contain "iface".
+- clocks:  Interface clocks needed for controller.
+- #sound-dai-cells:Must be 1 for digital audio interfaces on the 
controllers.
+- #address-cells:  Must be 1 for SoundWire devices;
+- #size-cells: Must be <0> as SoundWire addresses have no size 
component.
+- qcom,dout-ports: Must be count of data out ports
+- qcom,din-ports:  Must be count of data in ports


On these I think we should have specified dpn properties as specified in
DisCo, but then looking at spec we do not define that for master, but
bus seems to have it.

Pierre do you why master does not have dpn properties in DisCo?


+- qcom,ports-offset1:  Must be frame offset1 of each data port.
+   Out followed by In. Used for Block size calculation.
+- qcom,ports-offset2:  Must be frame offset2 of each data port.
+   Out followed by In. Used for Block size calculation.
+- qcom,ports-sinterval-low: Must be sample interval low of each data port.
+   Out followed by In. Used for Sample Interval 
calculation.


These are software so do not belong here
These are board-specfic properties w.r.t this controller ports 
configuration.

I don't see any other option to specify this?
Do you have any alternative suggestions?

--srini




[PATCH v5 02/15] Revert "ARM: dts: imx6: Use correct SDMA script for SPI cores"

2019-06-10 Thread yibin . gong
From: Robin Gong 

  There are two ways for SDMA accessing SPBA devices: one is SDMA->AIPS
->SPBA(masterA port), another is SDMA->SPBA(masterC port). Please refer
to the 'Figure 58-1. i.MX 6Dual/6Quad SPBA connectivity' of i.mx6DQ
Reference Manual. SDMA provide the corresponding app_2_mcu/mcu_2_app and
shp_2_mcu/mcu_2_shp script for such two options. So both AIPS and SPBA
scripts should keep the same behaviour, the issue only caught in AIPS
script sounds not solide.
  The issue is more likely as the ecspi errata
ERR009165(http://www.nxp.com/docs/en/errata/IMX6DQCE.pdf):
eCSPI: TXFIFO empty flag glitch can cause the current FIFO transfer to
   be sent twice
So revert commit 'dd4b487b32a3' firstly.

Signed-off-by: Robin Gong 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 929fc7d..b352ea2 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -339,7 +339,7 @@
clocks = <&clks IMX6QDL_CLK_ECSPI1>,
 <&clks IMX6QDL_CLK_ECSPI1>;
clock-names = "ipg", "per";
-   dmas = <&sdma 3 8 1>, <&sdma 4 8 2>;
+   dmas = <&sdma 3 7 1>, <&sdma 4 7 2>;
dma-names = "rx", "tx";
status = "disabled";
};
@@ -353,7 +353,7 @@
clocks = <&clks IMX6QDL_CLK_ECSPI2>,
 <&clks IMX6QDL_CLK_ECSPI2>;
clock-names = "ipg", "per";
-   dmas = <&sdma 5 8 1>, <&sdma 6 8 2>;
+   dmas = <&sdma 5 7 1>, <&sdma 6 7 2>;
dma-names = "rx", "tx";
status = "disabled";
};
@@ -367,7 +367,7 @@
clocks = <&clks IMX6QDL_CLK_ECSPI3>,
 <&clks IMX6QDL_CLK_ECSPI3>;
clock-names = "ipg", "per";
-   dmas = <&sdma 7 8 1>, <&sdma 8 8 2>;
+   dmas = <&sdma 7 7 1>, <&sdma 8 7 2>;
dma-names = "rx", "tx";
status = "disabled";
};
@@ -381,7 +381,7 @@
clocks = <&clks IMX6QDL_CLK_ECSPI4>,
 <&clks IMX6QDL_CLK_ECSPI4>;
clock-names = "ipg", "per";
-   dmas = <&sdma 9 8 1>, <&sdma 10 8 2>;
+   dmas = <&sdma 9 7 1>, <&sdma 10 7 2>;
dma-names = "rx", "tx";
status = "disabled";
};
-- 
2.7.4



[PATCH v5 06/15] spi: imx: fix ERR009165

2019-06-10 Thread yibin . gong
From: Robin Gong 

Change to XCH  mode even in dma mode, please refer to the below
errata:
https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf

Signed-off-by: Robin Gong 
Acked-by: Mark Brown 
---
 drivers/spi/spi-imx.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 09c9a1e..6795910 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -585,8 +585,9 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data 
*spi_imx,
ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
spi_imx->spi_bus_clk = clk;
 
+   /* ERR009165: work in XHC mode as PIO */
if (spi_imx->usedma)
-   ctrl |= MX51_ECSPI_CTRL_SMC;
+   ctrl &= ~MX51_ECSPI_CTRL_SMC;
 
writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
 
@@ -612,12 +613,14 @@ static int mx51_ecspi_prepare_transfer(struct 
spi_imx_data *spi_imx,
 
 static void mx51_setup_wml(struct spi_imx_data *spi_imx)
 {
+   u32 tx_wml = 0;
+
/*
 * Configure the DMA register: setup the watermark
 * and enable DMA request.
 */
writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml - 1) |
-   MX51_ECSPI_DMA_TX_WML(spi_imx->wml) |
+   MX51_ECSPI_DMA_TX_WML(tx_wml) |
MX51_ECSPI_DMA_RXT_WML(spi_imx->wml) |
MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
@@ -1171,7 +1174,11 @@ static int spi_imx_dma_configure(struct spi_master 
*master)
tx.direction = DMA_MEM_TO_DEV;
tx.dst_addr = spi_imx->base_phys + MXC_CSPITXDATA;
tx.dst_addr_width = buswidth;
-   tx.dst_maxburst = spi_imx->wml;
+   /*
+* For ERR009165 with tx_wml = 0 could enlarge burst size to fifo size
+* to speed up fifo filling as possible.
+*/
+   tx.dst_maxburst = spi_imx->devtype_data->fifo_size;
ret = dmaengine_slave_config(master->dma_tx, &tx);
if (ret) {
dev_err(spi_imx->dev, "TX dma configuration failed with %d\n", 
ret);
@@ -1265,10 +1272,6 @@ static int spi_imx_sdma_init(struct device *dev, struct 
spi_imx_data *spi_imx,
 {
int ret;
 
-   /* use pio mode for i.mx6dl chip TKT238285 */
-   if (of_machine_is_compatible("fsl,imx6dl"))
-   return 0;
-
spi_imx->wml = spi_imx->devtype_data->fifo_size / 2;
 
/* Prepare for TX DMA: */
-- 
2.7.4



[PATCH v5 12/15] ARM: dts: imx6ul: add dma support on ecspi

2019-06-10 Thread yibin . gong
From: Robin Gong 

Add dma support on ecspi.

Signed-off-by: Robin Gong 
---
 arch/arm/boot/dts/imx6ul.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index fc388b8..4a34316 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -227,6 +227,8 @@
clocks = <&clks IMX6UL_CLK_ECSPI1>,
 <&clks IMX6UL_CLK_ECSPI1>;
clock-names = "ipg", "per";
+   dmas = <&sdma 3 7 1>, <&sdma 4 7 2>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
@@ -239,6 +241,8 @@
clocks = <&clks IMX6UL_CLK_ECSPI2>,
 <&clks IMX6UL_CLK_ECSPI2>;
clock-names = "ipg", "per";
+   dmas = <&sdma 5 7 1>, <&sdma 6 7 2>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
@@ -251,6 +255,8 @@
clocks = <&clks IMX6UL_CLK_ECSPI3>,
 <&clks IMX6UL_CLK_ECSPI3>;
clock-names = "ipg", "per";
+   dmas = <&sdma 7 7 1>, <&sdma 8 7 2>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
@@ -263,6 +269,8 @@
clocks = <&clks IMX6UL_CLK_ECSPI4>,
 <&clks IMX6UL_CLK_ECSPI4>;
clock-names = "ipg", "per";
+   dmas = <&sdma 9 7 1>, <&sdma 10 7 2>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
-- 
2.7.4



[PATCH v5 04/15] dmaengine: imx-sdma: remove dupilicated sdma_load_context

2019-06-10 Thread yibin . gong
From: Robin Gong 

Since sdma_transfer_init() will do sdma_load_context before any
sdma transfer, no need once more in sdma_config_channel().

Signed-off-by: Robin Gong 
Acked-by: Vinod Koul 
---
 drivers/dma/imx-sdma.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 21db6b69..dbd1dcd 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1134,7 +1134,6 @@ static void sdma_set_watermarklevel_for_p2p(struct 
sdma_channel *sdmac)
 static int sdma_config_channel(struct dma_chan *chan)
 {
struct sdma_channel *sdmac = to_sdma_chan(chan);
-   int ret;
 
sdma_disable_channel(chan);
 
@@ -1174,9 +1173,7 @@ static int sdma_config_channel(struct dma_chan *chan)
sdmac->watermark_level = 0; /* FIXME: M3_BASE_ADDRESS */
}
 
-   ret = sdma_load_context(sdmac);
-
-   return ret;
+   return 0;
 }
 
 static int sdma_set_channel_priority(struct sdma_channel *sdmac,
-- 
2.7.4



[PATCH v5 00/15] add ecspi ERR009165 for i.mx6/7 soc family

2019-06-10 Thread yibin . gong
From: Robin Gong 

  There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO
transfer to be send twice in DMA mode. Please get more information from:
https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf. The workaround is adding
new sdma ram script which works in XCH  mode as PIO inside sdma instead
of SMC mode, meanwhile, 'TX_THRESHOLD' should be 0. The issue should be
exist on all legacy i.mx6/7 soc family before i.mx6ul.
  NXP fix this design issue from i.mx6ul, so newer chips including i.mx6ul/
6ull/6sll do not need this workaroud anymore. All other i.mx6/7/8 chips
still need this workaroud. This patch set add new 'fsl,imx6ul-ecspi'
for ecspi driver and 'ecspi_fixed' in sdma driver to choose if need errata
or not.
  The first two reverted patches should be the same issue, though, it
seems 'fixed' by changing to other shp script. Hope Sean or Sascha could
have the chance to test this patch set if could fix their issues.
  Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1 not work
on i.mx8mm because the event id is zero.

PS:
   Please get sdma firmware from below linux-firmware and copy it to your
local rootfs /lib/firmware/imx/sdma.
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma

v2:
  1.Add commit log for reverted patches.
  2.Add comment for 'ecspi_fixed' in sdma driver.
  3.Add 'fsl,imx6sll-ecspi' compatible instead of 'fsl,imx6ul-ecspi'
rather than remove.
v3:
  1.Confirm with design team make sure ERR009165 fixed on i.mx6ul/i.mx6ull
/i.mx6sll, not fixed on i.mx8m/8mm and other i.mx6/7 legacy chips.
Correct dts related dts patch in v2.
  2.Clean eratta information in binding doc and new 'tx_glitch_fixed' flag
in spi-imx driver to state ERR009165 fixed or not.
  3.Enlarge burst size to fifo size for tx since tx_wml set to 0 in the
errata workaroud, thus improve performance as possible.
v4:
  1.add Ack tag from Mark and Vinod
  2. remove checking 'event_id1' zero as 'event_id0'.
v5:
  1.Add another patch for compatible with the current uart driver which
using rom script, so both uart ram script and rom script supported
in latest firmware, by default uart rom script used. UART driver
will be broken without this patch. Latest sdma firmware has been
already updated in linux-firmware. 

Robin Gong (15):
  Revert "ARM: dts: imx6q: Use correct SDMA script for SPI5 core"
  Revert "ARM: dts: imx6: Use correct SDMA script for SPI cores"
  Revert "dmaengine: imx-sdma: refine to load context only once"
  dmaengine: imx-sdma: remove dupilicated sdma_load_context
  dmaengine: imx-sdma: add mcu_2_ecspi script
  spi: imx: fix ERR009165
  spi: imx: remove ERR009165 workaround on i.mx6ul
  spi: imx: add new i.mx6ul compatible name in binding doc
  dmaengine: imx-sdma: remove ERR009165 on i.mx6ul
  dma: imx-sdma: add i.mx6ul/6sx compatible name
  dmaengine: imx-sdma: fix ecspi1 rx dma not work on i.mx8mm
  ARM: dts: imx6ul: add dma support on ecspi
  ARM: dts: imx6sll: correct sdma compatible
  arm64: defconfig: Enable SDMA on i.mx8mq/8mm
  dmaengine: imx-sdma: add uart rom script

 .../devicetree/bindings/dma/fsl-imx-sdma.txt   |  2 +
 .../devicetree/bindings/spi/fsl-imx-cspi.txt   |  1 +
 arch/arm/boot/dts/imx6q.dtsi   |  2 +-
 arch/arm/boot/dts/imx6qdl.dtsi |  8 +-
 arch/arm/boot/dts/imx6sll.dtsi |  2 +-
 arch/arm/boot/dts/imx6ul.dtsi  |  8 ++
 arch/arm64/configs/defconfig   |  3 +
 drivers/dma/imx-sdma.c | 88 --
 drivers/spi/spi-imx.c  | 61 ---
 include/linux/platform_data/dma-imx-sdma.h | 11 ++-
 10 files changed, 145 insertions(+), 41 deletions(-)

-- 
2.7.4



[PATCH v5 10/15] dma: imx-sdma: add i.mx6ul/6sx compatible name

2019-06-10 Thread yibin . gong
From: Robin Gong 

Add i.mx6ul and i.mx6sx compatible name in binding doc.

Signed-off-by: Robin Gong 
---
 Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt 
b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index 9d8bbac..d024a83 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -9,6 +9,8 @@ Required properties:
   "fsl,imx53-sdma"
   "fsl,imx6q-sdma"
   "fsl,imx7d-sdma"
+  "fsl,imx6sx-sdma"
+  "fsl,imx6ul-sdma"
   "fsl,imx8mq-sdma"
   The -to variants should be preferred since they allow to determine the
   correct ROM script addresses needed for the driver to work without additional
-- 
2.7.4



[PATCH v5 11/15] dmaengine: imx-sdma: fix ecspi1 rx dma not work on i.mx8mm

2019-06-10 Thread yibin . gong
From: Robin Gong 

Because the number of ecspi1 rx event on i.mx8mm is 0, the condition
check ignore such special case without dma channel enabled, which caused
ecspi1 rx works failed. Actually, no need to check event_id0/event_id1
and replace checking 'event_id1' with 'DMA_DEV_TO_DEV', so that configure
event_id1 only in case DEV_TO_DEV.

Signed-off-by: Robin Gong 
Acked-by: Vinod Koul 
---
 drivers/dma/imx-sdma.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 525ca89..f7c150d 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1202,7 +1202,7 @@ static int sdma_config_channel(struct dma_chan *chan)
if ((sdmac->peripheral_type != IMX_DMATYPE_MEMORY) &&
(sdmac->peripheral_type != IMX_DMATYPE_DSP)) {
/* Handle multiple event channels differently */
-   if (sdmac->event_id1) {
+   if (sdmac->direction == DMA_DEV_TO_DEV) {
if (sdmac->peripheral_type == IMX_DMATYPE_ASRC_SP ||
sdmac->peripheral_type == IMX_DMATYPE_ASRC)
sdma_set_watermarklevel_for_p2p(sdmac);
@@ -1370,9 +1370,9 @@ static void sdma_free_chan_resources(struct dma_chan 
*chan)
 
sdma_channel_synchronize(chan);
 
-   if (sdmac->event_id0)
-   sdma_event_disable(sdmac, sdmac->event_id0);
-   if (sdmac->event_id1)
+   sdma_event_disable(sdmac, sdmac->event_id0);
+
+   if (sdmac->direction == DMA_DEV_TO_DEV)
sdma_event_disable(sdmac, sdmac->event_id1);
 
sdmac->event_id0 = 0;
@@ -1670,13 +1670,11 @@ static int sdma_config(struct dma_chan *chan,
memcpy(&sdmac->slave_config, dmaengine_cfg, sizeof(*dmaengine_cfg));
 
/* Set ENBLn earlier to make sure dma request triggered after that */
-   if (sdmac->event_id0) {
-   if (sdmac->event_id0 >= sdmac->sdma->drvdata->num_events)
-   return -EINVAL;
-   sdma_event_enable(sdmac, sdmac->event_id0);
-   }
+   if (sdmac->event_id0 >= sdmac->sdma->drvdata->num_events)
+   return -EINVAL;
+   sdma_event_enable(sdmac, sdmac->event_id0);
 
-   if (sdmac->event_id1) {
+   if (sdmac->direction == DMA_DEV_TO_DEV) {
if (sdmac->event_id1 >= sdmac->sdma->drvdata->num_events)
return -EINVAL;
sdma_event_enable(sdmac, sdmac->event_id1);
-- 
2.7.4



[PATCH v5 13/15] ARM: dts: imx6sll: correct sdma compatible

2019-06-10 Thread yibin . gong
From: Robin Gong 

Correct sdma compatible since ecspi errata ERR009165 has been fixed
on i.mx6sll as i.mx6ul.

Signed-off-by: Robin Gong 
---
 arch/arm/boot/dts/imx6sll.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6sll.dtsi b/arch/arm/boot/dts/imx6sll.dtsi
index 1b4899f..d810e10 100644
--- a/arch/arm/boot/dts/imx6sll.dtsi
+++ b/arch/arm/boot/dts/imx6sll.dtsi
@@ -619,7 +619,7 @@
};
 
sdma: dma-controller@20ec000 {
-   compatible = "fsl,imx6sll-sdma", 
"fsl,imx35-sdma";
+   compatible = "fsl,imx6sll-sdma", 
"fsl,imx6ul-sdma";
reg = <0x020ec000 0x4000>;
interrupts = ;
clocks = <&clks IMX6SLL_CLK_IPG>,
-- 
2.7.4



I BRING CALVARY GREETNG FROM MRS.SUZAN BONI.

2019-06-10 Thread suzanboni
-- 

Dear friend.
I got your details after an extensive on-line search Via (Network
Power Charitable Trust) for a reliable person, I'm Mrs.Suzan Boni, a
57years old dying woman who was diagnosed for cancer about 4 years
ago, I have decided to donate my fund ($2,000,000.00) to you for
charitable goals.

I want you to use this fund to help the orphanage homes, poor, sick
ones in the hospital, widows, help women with cancer, help in the
church of the God ,since i do not have any child to inherit the fund.
I took this decision because I can't take this money to the grave, I
don't have any child that will inherit this money, again I and my late
husband vowed to use our last wealth to help the less privileged since
we have no child, our relatives are wicked and selfish, they tried to
frustrate our Christian life and our marriage.

Beloved I don't need telephone communication because of my health
condition please reply me through my Email for me to give you other
details.Proverbs19:17: He who gives to the poor lends to the lord and
the lord will reward such a person for his good work. Beloved let us
join hands together to help our Fellow brothers and Sister who are
poor, sick and Homeless, so that blessings will be ours portion while
Glory goes to the lord our creator. I am waiting for your soonest
response. Thanks and God Bless You Yours Loving Sister in Christ.

Please reply me through my private email address.
This is my private email address, suzanbo...@gmail.com

Mrs. Suzan boni.


Re: [PATCH] vsprintf: fix data type of variable in string_nocheck()

2019-06-10 Thread Sergey Senozhatsky
On (06/10/19 16:47), 남영민 wrote:
> This patch fixes data type of precision with int.
> The precision is declared as signed int in struct printf_spec.
> 
> Signed-off-by: Youngmin Nam 

Looks OK to me.

FWIW
Reviewed-by: Sergey Senozhatsky 

-ss


[PATCH v5 09/15] dmaengine: imx-sdma: remove ERR009165 on i.mx6ul

2019-06-10 Thread yibin . gong
From: Robin Gong 

ECSPI issue fixed from i.mx6ul at hardware level, no need
ERR009165 anymore on those chips such as i.mx8mq. Add i.mx6sx
from where i.mx6ul source.

Signed-off-by: Robin Gong 
Acked-by: Vinod Koul 
---
 drivers/dma/imx-sdma.c | 51 +-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 61af656..525ca89 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -419,6 +419,13 @@ struct sdma_driver_data {
int num_events;
struct sdma_script_start_addrs  *script_addrs;
bool check_ratio;
+   /*
+* ecspi ERR009165 fixed should be done in sdma script
+* and it has been fixed in soc from i.mx6ul.
+* please get more information from the below link:
+* https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
+*/
+   bool ecspi_fixed;
 };
 
 struct sdma_engine {
@@ -539,6 +546,31 @@ static struct sdma_driver_data sdma_imx6q = {
.script_addrs = &sdma_script_imx6q,
 };
 
+static struct sdma_script_start_addrs sdma_script_imx6sx = {
+   .ap_2_ap_addr = 642,
+   .uart_2_mcu_addr = 817,
+   .mcu_2_app_addr = 747,
+   .uartsh_2_mcu_addr = 1032,
+   .mcu_2_shp_addr = 960,
+   .app_2_mcu_addr = 683,
+   .shp_2_mcu_addr = 891,
+   .spdif_2_mcu_addr = 1100,
+   .mcu_2_spdif_addr = 1134,
+};
+
+static struct sdma_driver_data sdma_imx6sx = {
+   .chnenbl0 = SDMA_CHNENBL0_IMX35,
+   .num_events = 48,
+   .script_addrs = &sdma_script_imx6sx,
+};
+
+static struct sdma_driver_data sdma_imx6ul = {
+   .chnenbl0 = SDMA_CHNENBL0_IMX35,
+   .num_events = 48,
+   .script_addrs = &sdma_script_imx6sx,
+   .ecspi_fixed = true,
+};
+
 static struct sdma_script_start_addrs sdma_script_imx7d = {
.ap_2_ap_addr = 644,
.uart_2_mcu_addr = 819,
@@ -584,9 +616,15 @@ static const struct platform_device_id sdma_devtypes[] = {
.name = "imx6q-sdma",
.driver_data = (unsigned long)&sdma_imx6q,
}, {
+   .name = "imx6sx-sdma",
+   .driver_data = (unsigned long)&sdma_imx6sx,
+   }, {
.name = "imx7d-sdma",
.driver_data = (unsigned long)&sdma_imx7d,
}, {
+   .name = "imx6ul-sdma",
+   .driver_data = (unsigned long)&sdma_imx6ul,
+   }, {
.name = "imx8mq-sdma",
.driver_data = (unsigned long)&sdma_imx8mq,
}, {
@@ -602,7 +640,9 @@ static const struct of_device_id sdma_dt_ids[] = {
{ .compatible = "fsl,imx35-sdma", .data = &sdma_imx35, },
{ .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, },
{ .compatible = "fsl,imx25-sdma", .data = &sdma_imx25, },
+   { .compatible = "fsl,imx6sx-sdma", .data = &sdma_imx6sx, },
{ .compatible = "fsl,imx7d-sdma", .data = &sdma_imx7d, },
+   { .compatible = "fsl,imx6ul-sdma", .data = &sdma_imx6ul, },
{ .compatible = "fsl,imx8mq-sdma", .data = &sdma_imx8mq, },
{ /* sentinel */ }
 };
@@ -1166,8 +1206,17 @@ static int sdma_config_channel(struct dma_chan *chan)
if (sdmac->peripheral_type == IMX_DMATYPE_ASRC_SP ||
sdmac->peripheral_type == IMX_DMATYPE_ASRC)
sdma_set_watermarklevel_for_p2p(sdmac);
-   } else
+   } else {
+   /*
+* ERR009165 fixed from i.mx6ul, no errata need,
+* set bit31 to let sdma script skip the errata.
+*/
+   if (sdmac->peripheral_type == IMX_DMATYPE_CSPI &&
+   sdmac->direction == DMA_MEM_TO_DEV &&
+   sdmac->sdma->drvdata->ecspi_fixed)
+   __set_bit(31, &sdmac->watermark_level);
__set_bit(sdmac->event_id0, sdmac->event_mask);
+   }
 
/* Address */
sdmac->shp_addr = sdmac->per_address;
-- 
2.7.4



[PATCH v5 08/15] spi: imx: add new i.mx6ul compatible name in binding doc

2019-06-10 Thread yibin . gong
From: Robin Gong 

ERR009165 fixed from i.mx6ul, add its compatible name in binding
doc.

Signed-off-by: Robin Gong 
Acked-by: Mark Brown 
---
 Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt 
b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
index 2d32641..b3d02a3 100644
--- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
+++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
@@ -10,6 +10,7 @@ Required properties:
   - "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35
   - "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51
   - "fsl,imx53-ecspi" for SPI compatible with the one integrated on i.MX53 and 
later Soc
+  - "fsl,imx6ul-ecspi" for SPI compatible with the one integrated on i.MX6UL 
and later Soc
   - "fsl,imx8mq-ecspi" for SPI compatible with the one integrated on i.MX8M
 - reg : Offset and length of the register set for the device
 - interrupts : Should contain CSPI/eCSPI interrupt
-- 
2.7.4



[PATCH v5 07/15] spi: imx: remove ERR009165 workaround on i.mx6ul

2019-06-10 Thread yibin . gong
From: Robin Gong 

ERR009165 fixed on i.mx6ul/6ull/6sll. All other i.mx6/7 and
i.mx8m/8mm still need this errata. Please refer to nxp official
errata document from https://www.nxp.com/ .

For removing workaround on those chips. Add new i.mx6ul type.

Signed-off-by: Robin Gong 
Acked-by: Mark Brown 
---
 drivers/spi/spi-imx.c | 50 +-
 1 file changed, 45 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 6795910..91660dc 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -57,6 +57,7 @@ enum spi_imx_devtype {
IMX35_CSPI, /* CSPI on all i.mx except above */
IMX51_ECSPI,/* ECSPI on i.mx51 */
IMX53_ECSPI,/* ECSPI on i.mx53 and later */
+   IMX6UL_ECSPI,   /* ERR009165 fix from i.mx6ul */
 };
 
 struct spi_imx_data;
@@ -75,6 +76,11 @@ struct spi_imx_devtype_data {
bool has_slavemode;
unsigned int fifo_size;
bool dynamic_burst;
+   /*
+* ERR009165 fixed or not:
+* https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
+*/
+   bool tx_glitch_fixed;
enum spi_imx_devtype devtype;
 };
 
@@ -128,7 +134,8 @@ static inline int is_imx35_cspi(struct spi_imx_data *d)
 
 static inline int is_imx51_ecspi(struct spi_imx_data *d)
 {
-   return d->devtype_data->devtype == IMX51_ECSPI;
+   return d->devtype_data->devtype == IMX51_ECSPI ||
+  d->devtype_data->devtype == IMX6UL_ECSPI;
 }
 
 static inline int is_imx53_ecspi(struct spi_imx_data *d)
@@ -585,9 +592,16 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data 
*spi_imx,
ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
spi_imx->spi_bus_clk = clk;
 
-   /* ERR009165: work in XHC mode as PIO */
-   if (spi_imx->usedma)
-   ctrl &= ~MX51_ECSPI_CTRL_SMC;
+   /*
+* ERR009165: work in XHC mode instead of SMC as PIO on the chips
+* before i.mx6ul.
+*/
+   if (spi_imx->usedma) {
+   if (spi_imx->devtype_data->tx_glitch_fixed)
+   ctrl |= MX51_ECSPI_CTRL_SMC;
+   else
+   ctrl &= ~MX51_ECSPI_CTRL_SMC;
+   }
 
writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
 
@@ -615,6 +629,8 @@ static void mx51_setup_wml(struct spi_imx_data *spi_imx)
 {
u32 tx_wml = 0;
 
+   if (spi_imx->devtype_data->tx_glitch_fixed)
+   tx_wml = spi_imx->wml;
/*
 * Configure the DMA register: setup the watermark
 * and enable DMA request.
@@ -1012,6 +1028,23 @@ static struct spi_imx_devtype_data 
imx53_ecspi_devtype_data = {
.devtype = IMX53_ECSPI,
 };
 
+static struct spi_imx_devtype_data imx6ul_ecspi_devtype_data = {
+   .intctrl = mx51_ecspi_intctrl,
+   .prepare_message = mx51_ecspi_prepare_message,
+   .prepare_transfer = mx51_ecspi_prepare_transfer,
+   .trigger = mx51_ecspi_trigger,
+   .rx_available = mx51_ecspi_rx_available,
+   .reset = mx51_ecspi_reset,
+   .setup_wml = mx51_setup_wml,
+   .fifo_size = 64,
+   .has_dmamode = true,
+   .dynamic_burst = true,
+   .has_slavemode = true,
+   .tx_glitch_fixed = true,
+   .disable = mx51_ecspi_disable,
+   .devtype = IMX6UL_ECSPI,
+};
+
 static const struct platform_device_id spi_imx_devtype[] = {
{
.name = "imx1-cspi",
@@ -1035,6 +1068,9 @@ static const struct platform_device_id spi_imx_devtype[] 
= {
.name = "imx53-ecspi",
.driver_data = (kernel_ulong_t) &imx53_ecspi_devtype_data,
}, {
+   .name = "imx6ul-ecspi",
+   .driver_data = (kernel_ulong_t) &imx6ul_ecspi_devtype_data,
+   }, {
/* sentinel */
}
 };
@@ -1047,6 +1083,7 @@ static const struct of_device_id spi_imx_dt_ids[] = {
{ .compatible = "fsl,imx35-cspi", .data = &imx35_cspi_devtype_data, },
{ .compatible = "fsl,imx51-ecspi", .data = &imx51_ecspi_devtype_data, },
{ .compatible = "fsl,imx53-ecspi", .data = &imx53_ecspi_devtype_data, },
+   { .compatible = "fsl,imx6ul-ecspi", .data = &imx6ul_ecspi_devtype_data, 
},
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, spi_imx_dt_ids);
@@ -1178,7 +1215,10 @@ static int spi_imx_dma_configure(struct spi_master 
*master)
 * For ERR009165 with tx_wml = 0 could enlarge burst size to fifo size
 * to speed up fifo filling as possible.
 */
-   tx.dst_maxburst = spi_imx->devtype_data->fifo_size;
+   if (spi_imx->devtype_data->tx_glitch_fixed)
+   tx.dst_maxburst = spi_imx->wml;
+   else
+   tx.dst_maxburst = spi_imx->devtype_data->fifo_size;
ret = dmaengine_slave_config(master->dma_tx, &tx);
if (ret) {
dev_err(spi_imx->dev, "TX dma configuration failed with %d\n", 
ret);
-- 
2.7.4



[PATCH v5 01/15] Revert "ARM: dts: imx6q: Use correct SDMA script for SPI5 core"

2019-06-10 Thread yibin . gong
From: Robin Gong 

  There are two ways for SDMA accessing SPBA devices: one is SDMA->AIPS
->SPBA(masterA port), another is SDMA->SPBA(masterC port). Please refer
to the 'Figure 58-1. i.MX 6Dual/6Quad SPBA connectivity' of i.mx6DQ
Reference Manual. SDMA provide the corresponding app_2_mcu/mcu_2_app and
shp_2_mcu/mcu_2_shp script for such two options. So both AIPS and SPBA
scripts should keep the same behaviour, the issue only caught in AIPS
script sounds not solide.
  The issue is more likely as the ecspi errata
ERR009165(http://www.nxp.com/docs/en/errata/IMX6DQCE.pdf):
eCSPI: TXFIFO empty flag glitch can cause the current FIFO transfer to
   be sent twice
So revert commit 'df07101e1c4a' firstly.

Signed-off-by: Robin Gong 
---
 arch/arm/boot/dts/imx6q.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index d038f41..7175898 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -172,7 +172,7 @@
clocks = <&clks IMX6Q_CLK_ECSPI5>,
 <&clks IMX6Q_CLK_ECSPI5>;
clock-names = "ipg", "per";
-   dmas = <&sdma 11 8 1>, <&sdma 12 8 2>;
+   dmas = <&sdma 11 7 1>, <&sdma 12 7 2>;
dma-names = "rx", "tx";
status = "disabled";
};
-- 
2.7.4



[PATCH v5 05/15] dmaengine: imx-sdma: add mcu_2_ecspi script

2019-06-10 Thread yibin . gong
From: Robin Gong 

Add mcu_2_ecspi script to fix ecspi errata ERR009165.

Signed-off-by: Robin Gong 
Acked-by: Vinod Koul 
---
 drivers/dma/imx-sdma.c | 3 +++
 include/linux/platform_data/dma-imx-sdma.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index dbd1dcd..61af656 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -924,6 +924,9 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
emi_2_per = sdma->script_addrs->mcu_2_ata_addr;
break;
case IMX_DMATYPE_CSPI:
+   per_2_emi = sdma->script_addrs->app_2_mcu_addr;
+   emi_2_per = sdma->script_addrs->mcu_2_ecspi_addr;
+   break;
case IMX_DMATYPE_EXT:
case IMX_DMATYPE_SSI:
case IMX_DMATYPE_SAI:
diff --git a/include/linux/platform_data/dma-imx-sdma.h 
b/include/linux/platform_data/dma-imx-sdma.h
index 6eaa53c..f794fee 100644
--- a/include/linux/platform_data/dma-imx-sdma.h
+++ b/include/linux/platform_data/dma-imx-sdma.h
@@ -51,6 +51,7 @@ struct sdma_script_start_addrs {
/* End of v2 array */
s32 zcanfd_2_mcu_addr;
s32 zqspi_2_mcu_addr;
+   s32 mcu_2_ecspi_addr;
/* End of v3 array */
 };
 
-- 
2.7.4



[PATCH v5 03/15] Revert "dmaengine: imx-sdma: refine to load context only once"

2019-06-10 Thread yibin . gong
From: Robin Gong 

This reverts commit ad0d92d7ba6aecbe2705907c38ff8d8be4da1e9c, because
in spi-imx case, burst length may be changed dynamically.

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ca296f0..21db6b69 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -377,7 +377,6 @@ struct sdma_channel {
unsigned long   watermark_level;
u32 shp_addr, per_addr;
enum dma_status status;
-   boolcontext_loaded;
struct imx_dma_data data;
struct work_struct  terminate_worker;
 };
@@ -988,9 +987,6 @@ static int sdma_load_context(struct sdma_channel *sdmac)
int ret;
unsigned long flags;
 
-   if (sdmac->context_loaded)
-   return 0;
-
if (sdmac->direction == DMA_DEV_TO_MEM)
load_address = sdmac->pc_from_device;
else if (sdmac->direction == DMA_DEV_TO_DEV)
@@ -1033,8 +1029,6 @@ static int sdma_load_context(struct sdma_channel *sdmac)
 
spin_unlock_irqrestore(&sdma->channel_0_lock, flags);
 
-   sdmac->context_loaded = true;
-
return ret;
 }
 
@@ -1074,7 +1068,6 @@ static void sdma_channel_terminate_work(struct 
work_struct *work)
sdmac->desc = NULL;
spin_unlock_irqrestore(&sdmac->vc.lock, flags);
vchan_dma_desc_free_list(&sdmac->vc, &head);
-   sdmac->context_loaded = false;
 }
 
 static int sdma_disable_channel_async(struct dma_chan *chan)
-- 
2.7.4



[PATCH v5 14/15] arm64: defconfig: Enable SDMA on i.mx8mq/8mm

2019-06-10 Thread yibin . gong
From: Robin Gong 

Enable SDMA support on i.mx8mq/8mm chips, including enabling
CONFIG_FW_LOADER_USER_HELPER/CONFIG_FW_LOADER_USER_HELPER_FALLBACK
for firmware loaded by udev.

Signed-off-by: Robin Gong 
---
 arch/arm64/configs/defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index bb0705e..e8aabc52 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -195,6 +195,8 @@ CONFIG_PCIE_HISI_STB=y
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_FW_LOADER_USER_HELPER=y
+CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
 CONFIG_HISILICON_LPC=y
 CONFIG_SIMPLE_PM_BUS=y
 CONFIG_MTD=y
@@ -627,6 +629,7 @@ CONFIG_RTC_DRV_XGENE=y
 CONFIG_DMADEVICES=y
 CONFIG_FSL_EDMA=y
 CONFIG_DMA_BCM2835=m
+CONFIG_IMX_SDMA=y
 CONFIG_K3_DMA=y
 CONFIG_MV_XOR=y
 CONFIG_MV_XOR_V2=y
-- 
2.7.4



[PATCH v5 15/15] dmaengine: imx-sdma: add uart rom script

2019-06-10 Thread yibin . gong
From: Robin Gong 

For the compatibility of NXP internal legacy kernel before 4.19 which
is based on uart ram script and upstreaming kernel based on uart rom
script, add both uart ram/rom script in latest sdma firmware. By default
uart rom script used.
Besides, add two multi-fifo scripts for SAI/PDM on i.mx8m/8mm and add
back qspi script miss for v4(i.mx7d/8m/8mm family, but v3 is for i.mx6).

rom script:
uart_2_mcu_addr
uartsh_2_mcu_addr /* through spba bus */
ram script:
uart_2_mcu_ram_addr
uartsh_2_mcu_ram_addr /* through spba bus */

Please get latest sdma firmware from the below and put them into the path
(/lib/firmware/imx/sdma/):
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
/tree/imx/sdma

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c |  4 ++--
 include/linux/platform_data/dma-imx-sdma.h | 10 --
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index f7c150d..deea9aa 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1733,8 +1733,8 @@ static void sdma_issue_pending(struct dma_chan *chan)
 
 #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V134
 #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V238
-#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V341
-#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V442
+#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V345
+#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V446
 
 static void sdma_add_scripts(struct sdma_engine *sdma,
const struct sdma_script_start_addrs *addr)
diff --git a/include/linux/platform_data/dma-imx-sdma.h 
b/include/linux/platform_data/dma-imx-sdma.h
index f794fee..e12d2e8 100644
--- a/include/linux/platform_data/dma-imx-sdma.h
+++ b/include/linux/platform_data/dma-imx-sdma.h
@@ -20,12 +20,12 @@ struct sdma_script_start_addrs {
s32 per_2_firi_addr;
s32 mcu_2_firi_addr;
s32 uart_2_per_addr;
-   s32 uart_2_mcu_addr;
+   s32 uart_2_mcu_ram_addr;
s32 per_2_app_addr;
s32 mcu_2_app_addr;
s32 per_2_per_addr;
s32 uartsh_2_per_addr;
-   s32 uartsh_2_mcu_addr;
+   s32 uartsh_2_mcu_ram_addr;
s32 per_2_shp_addr;
s32 mcu_2_shp_addr;
s32 ata_2_mcu_addr;
@@ -52,7 +52,13 @@ struct sdma_script_start_addrs {
s32 zcanfd_2_mcu_addr;
s32 zqspi_2_mcu_addr;
s32 mcu_2_ecspi_addr;
+   s32 mcu_2_sai_addr;
+   s32 sai_2_mcu_addr;
+   s32 uart_2_mcu_addr;
+   s32 uartsh_2_mcu_addr;
/* End of v3 array */
+   s32 mcu_2_zqspi_addr;
+   /* End of v4 array */
 };
 
 /**
-- 
2.7.4



[PATCH v2 00/02] fix return value issue of soft offlining hugepages

2019-06-10 Thread Naoya Horiguchi
Hi everyone,

This is an update of the fix of return value issue of hugepage soft-offlining
(v1: https://patchwork.kernel.org/patch/10962135/).

The code itself has no change since v1 but I updated the description.
Jerry helped testing and finally confirmed that the patch is OK.

In previous discussion, it's pointed out by Mike that this problem contained
two separate issues (a problem of dissolve_free_huge_page() and a problem of
soft_offline_huge_page() itself) and I agree with it (althouth I stated
differently at v1). So I separated the patch.

Hopefully this will help finishing the issue.

Thanks,
Naoya Horiguchi


[PATCH v2 1/2] mm: soft-offline: return -EBUSY if set_hwpoison_free_buddy_page() fails

2019-06-10 Thread Naoya Horiguchi
The pass/fail of soft offline should be judged by checking whether the
raw error page was finally contained or not (i.e. the result of
set_hwpoison_free_buddy_page()), but current code do not work like that.
So this patch is suggesting to fix it.

Signed-off-by: Naoya Horiguchi 
Fixes: 6bc9b56433b76 ("mm: fix race on soft-offlining")
Cc:  # v4.19+
---
 mm/memory-failure.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git v5.2-rc3/mm/memory-failure.c v5.2-rc3_patched/mm/memory-failure.c
index fc8b517..7ea485e 100644
--- v5.2-rc3/mm/memory-failure.c
+++ v5.2-rc3_patched/mm/memory-failure.c
@@ -1733,6 +1733,8 @@ static int soft_offline_huge_page(struct page *page, int 
flags)
if (!ret) {
if (set_hwpoison_free_buddy_page(page))
num_poisoned_pages_inc();
+   else
+   ret = -EBUSY;
}
}
return ret;
-- 
2.7.0



[PATCH v2 2/2] mm: hugetlb: soft-offline: dissolve_free_huge_page() return zero on !PageHuge

2019-06-10 Thread Naoya Horiguchi
madvise(MADV_SOFT_OFFLINE) often returns -EBUSY when calling soft offline
for hugepages with overcommitting enabled. That was caused by the suboptimal
code in current soft-offline code. See the following part:

ret = migrate_pages(&pagelist, new_page, NULL, MPOL_MF_MOVE_ALL,
MIGRATE_SYNC, MR_MEMORY_FAILURE);
if (ret) {
...
} else {
/*
 * We set PG_hwpoison only when the migration source hugepage
 * was successfully dissolved, because otherwise hwpoisoned
 * hugepage remains on free hugepage list, then userspace will
 * find it as SIGBUS by allocation failure. That's not expected
 * in soft-offlining.
 */
ret = dissolve_free_huge_page(page);
if (!ret) {
if (set_hwpoison_free_buddy_page(page))
num_poisoned_pages_inc();
}
}
return ret;

Here dissolve_free_huge_page() returns -EBUSY if the migration source page
was freed into buddy in migrate_pages(), but even in that case we actually
has a chance that set_hwpoison_free_buddy_page() succeeds. So that means
current code gives up offlining too early now.

dissolve_free_huge_page() checks that a given hugepage is suitable for
dissolving, where we should return success for !PageHuge() case because
the given hugepage is considered as already dissolved.

This change also affects other callers of dissolve_free_huge_page(),
which are cleaned up together.

Reported-by: Chen, Jerry T 
Tested-by: Chen, Jerry T 
Signed-off-by: Naoya Horiguchi 
Fixes: 6bc9b56433b76 ("mm: fix race on soft-offlining")
Cc:  # v4.19+
---
 mm/hugetlb.c| 15 +--
 mm/memory-failure.c |  5 +
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git v5.2-rc3/mm/hugetlb.c v5.2-rc3_patched/mm/hugetlb.c
index ac843d3..048d071 100644
--- v5.2-rc3/mm/hugetlb.c
+++ v5.2-rc3_patched/mm/hugetlb.c
@@ -1519,7 +1519,12 @@ int dissolve_free_huge_page(struct page *page)
int rc = -EBUSY;
 
spin_lock(&hugetlb_lock);
-   if (PageHuge(page) && !page_count(page)) {
+   if (!PageHuge(page)) {
+   rc = 0;
+   goto out;
+   }
+
+   if (!page_count(page)) {
struct page *head = compound_head(page);
struct hstate *h = page_hstate(head);
int nid = page_to_nid(head);
@@ -1564,11 +1569,9 @@ int dissolve_free_huge_pages(unsigned long start_pfn, 
unsigned long end_pfn)
 
for (pfn = start_pfn; pfn < end_pfn; pfn += 1 << minimum_order) {
page = pfn_to_page(pfn);
-   if (PageHuge(page) && !page_count(page)) {
-   rc = dissolve_free_huge_page(page);
-   if (rc)
-   break;
-   }
+   rc = dissolve_free_huge_page(page);
+   if (rc)
+   break;
}
 
return rc;
diff --git v5.2-rc3/mm/memory-failure.c v5.2-rc3_patched/mm/memory-failure.c
index 7ea485e..3a83e27 100644
--- v5.2-rc3/mm/memory-failure.c
+++ v5.2-rc3_patched/mm/memory-failure.c
@@ -1859,11 +1859,8 @@ static int soft_offline_in_use_page(struct page *page, 
int flags)
 
 static int soft_offline_free_page(struct page *page)
 {
-   int rc = 0;
-   struct page *head = compound_head(page);
+   int rc = dissolve_free_huge_page(page);
 
-   if (PageHuge(head))
-   rc = dissolve_free_huge_page(page);
if (!rc) {
if (set_hwpoison_free_buddy_page(page))
num_poisoned_pages_inc();
-- 
2.7.0



Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

2019-06-10 Thread Christoph Hellwig
On Sat, Jun 08, 2019 at 04:52:24PM -0500, Larry Finger wrote:
> On 6/7/19 12:29 PM, Christoph Hellwig wrote:
>> I don't think we should work around this in the driver, we need to fix
>> it in the core.  I'm curious why my previous patch didn't work.  Can
>> you throw in a few printks what failed?  I.e. did dma_direct_supported
>> return false?  Did the actual allocation fail?
>
> Routine dma_direct_supported() returns true.
>
> The failure is in routine dma_set_mask() in the following if test:
>
> if (!dev->dma_mask || !dma_supported(dev, mask))
> return -EIO;
>
> For b43legacy, dev->dma_mask is 0xc2656848.
> dma_supported(dev, mask) is 0xc08b, mask is 0x3fff, and 
> the routine returns -EIO.
>
> For b43,   dev->dma_mask is 0xc26568480001,
> dma_supported(dev, mask) is 0xc08b, mask is 0x, and 
> the routine returns 0.

I don't fully understand what values the above map to.  Can you send
me your actual debugging patch as well?


Re: [alsa-devel] [PATCH 08/14] ASoC: Intel: Skylake: Properly cleanup on component removal

2019-06-10 Thread Amadeusz Sławiński
On Mon, 10 Jun 2019 09:17:21 +0200
Cezary Rojewski  wrote:

> On 2019-06-05 15:45, Amadeusz Sławiński wrote:
> > When we remove component we need to reverse things which were done
> > on init, this consists of topology cleanup, lists cleanup and
> > releasing firmware.
> > 
> > Currently cleanup handlers are put in wrong places or otherwise
> > missing. So add proper component cleanup function and perform
> > cleanups in it.
> > 
> > Signed-off-by: Amadeusz Sławiński
> >  ---
> >   sound/soc/intel/skylake/skl-pcm.c  |  8 ++--
> >   sound/soc/intel/skylake/skl-topology.c | 15 +++
> >   sound/soc/intel/skylake/skl-topology.h |  2 ++
> >   sound/soc/intel/skylake/skl.c  |  2 --
> >   4 files changed, 23 insertions(+), 4 deletions(-)
> > 
> > diff --git a/sound/soc/intel/skylake/skl-pcm.c
> > b/sound/soc/intel/skylake/skl-pcm.c index
> > 44062806fbed..7e8110c15258 100644 ---
> > a/sound/soc/intel/skylake/skl-pcm.c +++
> > b/sound/soc/intel/skylake/skl-pcm.c @@ -1459,8 +1459,12 @@ static
> > int skl_platform_soc_probe(struct snd_soc_component *component) 
> >   static void skl_pcm_remove(struct snd_soc_component *component)
> >   {
> > -   /* remove topology */
> > -   snd_soc_tplg_component_remove(component,
> > SND_SOC_TPLG_INDEX_ALL);
> > +   struct hdac_bus *bus = dev_get_drvdata(component->dev);
> > +   struct skl *skl = bus_to_skl(bus);
> > +
> > +   skl_tplg_exit(component, bus);
> > +
> > +   skl_debugfs_exit(skl);
> >   }
> >   
> >   static const struct snd_soc_component_driver skl_component  = {
> > diff --git a/sound/soc/intel/skylake/skl-topology.c
> > b/sound/soc/intel/skylake/skl-topology.c index
> > 44f3b29a7210..3964262109ac 100644 ---
> > a/sound/soc/intel/skylake/skl-topology.c +++
> > b/sound/soc/intel/skylake/skl-topology.c @@ -3748,3 +3748,18 @@ int
> > skl_tplg_init(struct snd_soc_component *component, struct hdac_bus
> > *bus) return 0;
> >   }
> > +
> > +void skl_tplg_exit(struct snd_soc_component *component, struct
> > hdac_bus *bus) +{
> > +   struct skl *skl = bus_to_skl(bus);
> > +   struct skl_pipeline *ppl, *tmp;
> > +
> > +   if (!list_empty(&skl->ppl_list))
> > +   list_for_each_entry_safe(ppl, tmp, &skl->ppl_list,
> > node)
> > +   list_del(&ppl->node);
> > +
> > +   /* clean up topology */
> > +   snd_soc_tplg_component_remove(component,
> > SND_SOC_TPLG_INDEX_ALL); +
> > +   release_firmware(skl->tplg);
> > +}  
> 
> In debugfs cleanup patch:
> [PATCH 07/14] ASoC: Intel: Skylake: Add function to cleanup debugfs 
> interface
> 
> you define skl_debugfs_exit separately - its usage is split and
> present in this very patch instead. However, for tplg counterpart - 
> skl_tplg_exit - you've decided to combine both together. Why not 
> separate tplg cleanup too?
> 

This is done because skl_debugfs_exit() can be introduced standalone.
However skl_tplg_exit() has code that is being moved from other places.
If I introduced it in separate commit, other one would be adding call
to this function while removing things that happen inside, losing part
of information, about the fact that code is actually just being moved.

> > diff --git a/sound/soc/intel/skylake/skl-topology.h
> > b/sound/soc/intel/skylake/skl-topology.h index
> > 82282cac9751..7d32c61c73e7 100644 ---
> > a/sound/soc/intel/skylake/skl-topology.h +++
> > b/sound/soc/intel/skylake/skl-topology.h @@ -471,6 +471,8 @@ void
> > skl_tplg_set_be_dmic_config(struct snd_soc_dai *dai, struct
> > skl_pipe_params *params, int stream); int skl_tplg_init(struct
> > snd_soc_component *component, struct hdac_bus *ebus);
> > +void skl_tplg_exit(struct snd_soc_component *component,
> > +   struct hdac_bus *bus);
> >   struct skl_module_cfg *skl_tplg_fe_get_cpr_module(
> > struct snd_soc_dai *dai, int stream);
> >   int skl_tplg_update_pipe_params(struct device *dev,
> > diff --git a/sound/soc/intel/skylake/skl.c
> > b/sound/soc/intel/skylake/skl.c index 6d6401410250..e4881ff427ea
> > 100644 --- a/sound/soc/intel/skylake/skl.c
> > +++ b/sound/soc/intel/skylake/skl.c
> > @@ -1119,14 +1119,12 @@ static void skl_remove(struct pci_dev *pci)
> > struct skl *skl = bus_to_skl(bus);
> >   
> > cancel_work_sync(&skl->probe_work);
> > -   release_firmware(skl->tplg);
> >   
> > pm_runtime_get_noresume(&pci->dev);
> >   
> > /* codec removal, invoke bus_device_remove */
> > snd_hdac_ext_bus_device_remove(bus);
> >   
> > -   skl->debugfs = NULL;
> > skl_platform_unregister(&pci->dev);
> > skl_free_dsp(skl);
> > skl_machine_device_unregister(skl);
> >   
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel



[GIT PULL] Immutable branch between MFD and Cros due for the v5.3 merge window

2019-06-10 Thread Lee Jones
As requested.

Enjoy!

The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:

  Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-cros-v5.3

for you to fetch changes up to 3aa6be30da899619c44aa654313ba66eb44e7291:

  mfd: cros_ec: Update I2S API (2019-06-10 09:15:08 +0100)


Immutable branch between MFD and Cros due for the v5.3 merge window


Gwendal Grignou (30):
  mfd: cros_ec: Update license term
  mfd: cros_ec: Zero BUILD_ macro
  mfd: cros_ec: set comments properly
  mfd: cros_ec: add ec_align macros
  mfd: cros_ec: Define commands as 4-digit UPPER CASE hex values
  mfd: cros_ec: use BIT macro
  mfd: cros_ec: Update ACPI interface definition
  mfd: cros_ec: move HDMI CEC API definition
  mfd: cros_ec: Remove zero-size structs
  mfd: cros_ec: Add Flash V2 commands API
  mfd: cros_ec: Add PWM_SET_DUTY API
  mfd: cros_ec: Add lightbar v2 API
  mfd: cros_ec: Expand hash API
  mfd: cros_ec: Add EC transport protocol v4
  mfd: cros_ec: Complete MEMS sensor API
  mfd: cros_ec: Fix event processing API
  mfd: cros_ec: Add fingerprint API
  mfd: cros_ec: Fix temperature API
  mfd: cros_ec: Complete Power and USB PD API
  mfd: cros_ec: Add API for keyboard testing
  mfd: cros_ec: Add Hibernate API
  mfd: cros_ec: Add Smart Battery Firmware update API
  mfd: cros_ec: Add I2C passthru protection API
  mfd: cros_ec: Add API for EC-EC communication
  mfd: cros_ec: Add API for Touchpad support
  mfd: cros_ec: Add API for Fingerprint support
  mfd: cros_ec: Add API for rwsig
  mfd: cros_ec: Add SKU ID and Secure storage API
  mfd: cros_ec: Add Management API entry points
  mfd: cros_ec: Update I2S API

 include/linux/mfd/cros_ec_commands.h | 3658 +++---
 sound/soc/codecs/cros_ec_codec.c |8 +-
 2 files changed, 2915 insertions(+), 751 deletions(-)

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH 1/1] irqchip/gic: Add support for Amazon Graviton variant of GICv3+GICv2m

2019-06-10 Thread Marc Zyngier
Hi Zeev,

On 07/06/2019 00:17, Zeev Zilberman wrote:
> The patch adds support for Amazon Graviton custom variant of GICv2m, where
> hw irq is encoded using the MSI message address, as opposed to standard
> GICv2m, where hw irq is encoded in the MSI message data.
> In addition, the Graviton flavor of GICv2m is used along GICv3 (and not
> GICv2).
> 
> Signed-off-by: Zeev Zilberman 
> Signed-off-by: Benjamin Herrenschmidt 

There seem to be some confusion about who is the author of this patch.
As you're the one posting the patch, your SoB tag should be the last
one. And assuming the patch has been developed together with Ben, it
should read:

Co-developed-by: Benjamin Herrenschmidt 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Zeev Zilberman 

> ---
> diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c
> index 3c77ab6..eeed19f 100644
> --- a/drivers/irqchip/irq-gic-v2m.c
> +++ b/drivers/irqchip/irq-gic-v2m.c
> @@ -56,6 +56,7 @@
>  
>  /* List of flags for specific v2m implementation */
>  #define GICV2M_NEEDS_SPI_OFFSET  0x0001
> +#define GICV2M_GRAVITON_ADDRESS_ONLY 0x0002
>  
>  static LIST_HEAD(v2m_nodes);
>  static DEFINE_SPINLOCK(v2m_lock);
> @@ -98,15 +99,26 @@ static struct msi_domain_info gicv2m_msi_domain_info = {
>   .chip   = &gicv2m_msi_irq_chip,
>  };
>  
> +static phys_addr_t gicv2m_get_msi_addr(struct v2m_data *v2m, int hwirq)
> +{
> + if (v2m->flags & GICV2M_GRAVITON_ADDRESS_ONLY)
> + return v2m->res.start | ((hwirq - 32) << 3);
> + else
> + return v2m->res.start + V2M_MSI_SETSPI_NS;
> +}
> +
>  static void gicv2m_compose_msi_msg(struct irq_data *data, struct msi_msg 
> *msg)
>  {
>   struct v2m_data *v2m = irq_data_get_irq_chip_data(data);
> - phys_addr_t addr = v2m->res.start + V2M_MSI_SETSPI_NS;
> + phys_addr_t addr = gicv2m_get_msi_addr(v2m, data->hwirq);
>  
>   msg->address_hi = upper_32_bits(addr);
>   msg->address_lo = lower_32_bits(addr);
> - msg->data = data->hwirq;
>  
> + if (v2m->flags & GICV2M_GRAVITON_ADDRESS_ONLY)
> + msg->data = 0;
> + else
> + msg->data = data->hwirq;
>   if (v2m->flags & GICV2M_NEEDS_SPI_OFFSET)
>   msg->data -= v2m->spi_offset;
>  
> @@ -188,7 +200,7 @@ static int gicv2m_irq_domain_alloc(struct irq_domain 
> *domain, unsigned int virq,
>   hwirq = v2m->spi_start + offset;
>  
>   err = iommu_dma_prepare_msi(info->desc,
> - v2m->res.start + V2M_MSI_SETSPI_NS);
> + gicv2m_get_msi_addr(v2m, hwirq));
>   if (err)
>   return err;
>  
> @@ -307,7 +319,7 @@ static int gicv2m_allocate_domains(struct irq_domain 
> *parent)
>  
>  static int __init gicv2m_init_one(struct fwnode_handle *fwnode,
> u32 spi_start, u32 nr_spis,
> -   struct resource *res)
> +   struct resource *res, u32 flags)
>  {
>   int ret;
>   struct v2m_data *v2m;
> @@ -320,6 +332,7 @@ static int __init gicv2m_init_one(struct fwnode_handle 
> *fwnode,
>  
>   INIT_LIST_HEAD(&v2m->entry);
>   v2m->fwnode = fwnode;
> + v2m->flags = flags;
>  
>   memcpy(&v2m->res, res, sizeof(struct resource));
>  
> @@ -334,7 +347,14 @@ static int __init gicv2m_init_one(struct fwnode_handle 
> *fwnode,
>   v2m->spi_start = spi_start;
>   v2m->nr_spis = nr_spis;
>   } else {
> - u32 typer = readl_relaxed(v2m->base + V2M_MSI_TYPER);
> + u32 typer;
> +
> + /* Graviton should always have explicit spi_start/nr_spis */
> + if (v2m->flags & GICV2M_GRAVITON_ADDRESS_ONLY) {
> + ret = -EINVAL;
> + goto err_iounmap;
> + }
> + typer = readl_relaxed(v2m->base + V2M_MSI_TYPER);
>  
>   v2m->spi_start = V2M_MSI_TYPER_BASE_SPI(typer);
>   v2m->nr_spis = V2M_MSI_TYPER_NUM_SPI(typer);
> @@ -355,18 +375,21 @@ static int __init gicv2m_init_one(struct fwnode_handle 
> *fwnode,
>*
>* Broadom NS2 GICv2m implementation has an erratum where the MSI data
>* is 'spi_number - 32'
> +  *
> +  * Reading that register fails on the Graviton implementation
>*/
> - switch (readl_relaxed(v2m->base + V2M_MSI_IIDR)) {
> - case XGENE_GICV2M_MSI_IIDR:
> - v2m->flags |= GICV2M_NEEDS_SPI_OFFSET;
> - v2m->spi_offset = v2m->spi_start;
> - break;
> - case BCM_NS2_GICV2M_MSI_IIDR:
> - v2m->flags |= GICV2M_NEEDS_SPI_OFFSET;
> - v2m->spi_offset = 32;
> - break;
> + if (!(v2m->flags & GICV2M_GRAVITON_ADDRESS_ONLY)) {
> + switch (readl_relaxed(v2m->base + V2M_MSI_IIDR)) {
> + case XGENE_GICV2M_MSI_IIDR:
> + v2m->flags |= GICV2M_NEEDS_SPI_OFFSET;
> + v2m->spi_offs

Re: [PATCH 4.19 01/51] ethtool: fix potential userspace buffer overflow

2019-06-10 Thread Pavel Machek
Hi!

> From: Vivien Didelot 
> 
> [ Upstream commit 0ee4e76937d69128a6a66861ba393ebdc2ffc8a2 ]
> 
> ethtool_get_regs() allocates a buffer of size ops->get_regs_len(),
> and pass it to the kernel driver via ops->get_regs() for filling.
> 
> There is no restriction about what the kernel drivers can or cannot do
> with the open ethtool_regs structure. They usually set regs->version
> and ignore regs->len or set it to the same size as ops->get_regs_len().
> 
> But if userspace allocates a smaller buffer for the registers dump,
> we would cause a userspace buffer overflow in the final copy_to_user()
> call, which uses the regs.len value potentially reset by the driver.
> 
> To fix this, make this case obvious and store regs.len before calling
> ops->get_regs(), to only copy as much data as requested by userspace,
> up to the value returned by ops->get_regs_len().
> 
> While at it, remove the redundant check for non-null regbuf.

Mainline differs from 4.19-stable here, and while the non-null check
is redundant in -mainline, it does not seem to be redundant in
-stable.

In stable, if get_regs_len() returns < 0, we'll pass it to vzalloc.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH 2/4] mm: thp: make deferred split shrinker memcg aware

2019-06-10 Thread Kirill Tkhai
Hi, Yang,

On 07.06.2019 09:07, Yang Shi wrote:
> Currently THP deferred split shrinker is not memcg aware, this may cause
> premature OOM with some configuration. For example the below test would
> run into premature OOM easily:
> 
> $ cgcreate -g memory:thp
> $ echo 4G > /sys/fs/cgroup/memory/thp/memory/limit_in_bytes
> $ cgexec -g memory:thp transhuge-stress 4000
> 
> transhuge-stress comes from kernel selftest.
> 
> It is easy to hit OOM, but there are still a lot THP on the deferred
> split queue, memcg direct reclaim can't touch them since the deferred
> split shrinker is not memcg aware.
> 
> Convert deferred split shrinker memcg aware by introducing per memcg
> deferred split queue.  The THP should be on either per node or per memcg
> deferred split queue if it belongs to a memcg.  When the page is
> immigrated to the other memcg, it will be immigrated to the target
> memcg's deferred split queue too.
> 
> And, move deleting THP from deferred split queue in page free before
> memcg uncharge so that the page's memcg information is available.
> 
> Reuse the second tail page's deferred_list for per memcg list since the
> same THP can't be on multiple deferred split queues.
> 
> Cc: Kirill Tkhai 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: "Kirill A . Shutemov" 
> Cc: Hugh Dickins 
> Cc: Shakeel Butt 
> Cc: David Rientjes 
> Signed-off-by: Yang Shi 
> ---
>  include/linux/huge_mm.h| 15 ++
>  include/linux/memcontrol.h |  4 +++
>  include/linux/mm_types.h   |  1 +
>  mm/huge_memory.c   | 71 
> +-
>  mm/memcontrol.c| 19 +
>  mm/swap.c  |  4 +++
>  6 files changed, 94 insertions(+), 20 deletions(-)
> 
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index 7cd5c15..8137c3a 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -250,6 +250,17 @@ static inline bool thp_migration_supported(void)
>   return IS_ENABLED(CONFIG_ARCH_ENABLE_THP_MIGRATION);
>  }
>  
> +static inline struct list_head *page_deferred_list(struct page *page)
> +{
> + /*
> +  * Global or memcg deferred list in the second tail pages is
> +  * occupied by compound_head.
> +  */
> + return &page[2].deferred_list;
> +}
> +
> +extern void del_thp_from_deferred_split_queue(struct page *);
> +
>  #else /* CONFIG_TRANSPARENT_HUGEPAGE */
>  #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
>  #define HPAGE_PMD_MASK ({ BUILD_BUG(); 0; })
> @@ -368,6 +379,10 @@ static inline bool thp_migration_supported(void)
>  {
>   return false;
>  }
> +
> +static inline void del_thp_from_deferred_split_queue(struct page *page)
> +{
> +}
>  #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>  
>  #endif /* _LINUX_HUGE_MM_H */
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index bc74d6a..5d3c10c 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -316,6 +316,10 @@ struct mem_cgroup {
>   struct list_head event_list;
>   spinlock_t event_list_lock;
>  
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> + struct deferred_split deferred_split_queue;
> +#endif
> +
>   struct mem_cgroup_per_node *nodeinfo[0];
>   /* WARNING: nodeinfo must be the last member here */
>  };
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 8ec38b1..4eabf80 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -139,6 +139,7 @@ struct page {
>   struct {/* Second tail page of compound page */
>   unsigned long _compound_pad_1;  /* compound_head */
>   unsigned long _compound_pad_2;
> + /* For both global and memcg */
>   struct list_head deferred_list;
>   };
>   struct {/* Page table pages */
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 81cf759..3307697 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -492,10 +492,15 @@ pmd_t maybe_pmd_mkwrite(pmd_t pmd, struct 
> vm_area_struct *vma)
>   return pmd;
>  }
>  
> -static inline struct list_head *page_deferred_list(struct page *page)
> +static inline struct deferred_split *get_deferred_split_queue(struct page 
> *page)
>  {
> - /* ->lru in the tail pages is occupied by compound_head. */
> - return &page[2].deferred_list;
> + struct mem_cgroup *memcg = compound_head(page)->mem_cgroup;
> + struct pglist_data *pgdat = NODE_DATA(page_to_nid(page));
> +
> + if (memcg)
> + return &memcg->deferred_split_queue;
> + else
> + return &pgdat->deferred_split_queue;

memory_cgrp_subsys is not early initialized, so at the beginning of boot
root_mem_cgroup is NULL, and pages will use &pgdat->deferred_split_queue
list head. But after root_mem_cgroup is initialized, another list head
will be used, won't it?! So there will be two different list heads used
for same cgroup.

This ma

Re: [PATCH 1/3] mm: thp: make deferred split shrinker memcg aware

2019-06-10 Thread Kirill Tkhai
On 29.05.2019 14:25, Yang Shi wrote:
> 
> 
> On 5/29/19 4:14 PM, Kirill Tkhai wrote:
>> On 29.05.2019 05:43, Yang Shi wrote:
>>>
>>> On 5/28/19 10:42 PM, Kirill Tkhai wrote:
 Hi, Yang,

 On 28.05.2019 15:44, Yang Shi wrote:
> Currently THP deferred split shrinker is not memcg aware, this may cause
> premature OOM with some configuration. For example the below test would
> run into premature OOM easily:
>
> $ cgcreate -g memory:thp
> $ echo 4G > /sys/fs/cgroup/memory/thp/memory/limit_in_bytes
> $ cgexec -g memory:thp transhuge-stress 4000
>
> transhuge-stress comes from kernel selftest.
>
> It is easy to hit OOM, but there are still a lot THP on the deferred
> split queue, memcg direct reclaim can't touch them since the deferred
> split shrinker is not memcg aware.
>
> Convert deferred split shrinker memcg aware by introducing per memcg
> deferred split queue.  The THP should be on either per node or per memcg
> deferred split queue if it belongs to a memcg.  When the page is
> immigrated to the other memcg, it will be immigrated to the target
> memcg's deferred split queue too.
>
> And, move deleting THP from deferred split queue in page free before
> memcg uncharge so that the page's memcg information is available.
>
> Reuse the second tail page's deferred_list for per memcg list since the
> same THP can't be on multiple deferred split queues.
>
> Cc: Kirill Tkhai 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: "Kirill A . Shutemov" 
> Cc: Hugh Dickins 
> Cc: Shakeel Butt 
> Signed-off-by: Yang Shi 
> ---
>    include/linux/huge_mm.h    |  24 ++
>    include/linux/memcontrol.h |   6 ++
>    include/linux/mm_types.h   |   7 +-
>    mm/huge_memory.c   | 182 
> +
>    mm/memcontrol.c    |  20 +
>    mm/swap.c  |   4 +
>    6 files changed, 194 insertions(+), 49 deletions(-)
>
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index 7cd5c15..f6d1cde 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -250,6 +250,26 @@ static inline bool thp_migration_supported(void)
>    return IS_ENABLED(CONFIG_ARCH_ENABLE_THP_MIGRATION);
>    }
>    +static inline struct list_head *page_deferred_list(struct page *page)
> +{
> +    /*
> + * Global deferred list in the second tail pages is occupied by
> + * compound_head.
> + */
> +    return &page[2].deferred_list;
> +}
> +
> +static inline struct list_head *page_memcg_deferred_list(struct page 
> *page)
> +{
> +    /*
> + * Memcg deferred list in the second tail pages is occupied by
> + * compound_head.
> + */
> +    return &page[2].memcg_deferred_list;
> +}
> +
> +extern void del_thp_from_deferred_split_queue(struct page *);
> +
>    #else /* CONFIG_TRANSPARENT_HUGEPAGE */
>    #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
>    #define HPAGE_PMD_MASK ({ BUILD_BUG(); 0; })
> @@ -368,6 +388,10 @@ static inline bool thp_migration_supported(void)
>    {
>    return false;
>    }
> +
> +static inline void del_thp_from_deferred_split_queue(struct page *page)
> +{
> +}
>    #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>      #endif /* _LINUX_HUGE_MM_H */
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index bc74d6a..9ff5fab 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -316,6 +316,12 @@ struct mem_cgroup {
>    struct list_head event_list;
>    spinlock_t event_list_lock;
>    +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +    struct list_head split_queue;
> +    unsigned long split_queue_len;
> +    spinlock_t split_queue_lock;
> +#endif
> +
>    struct mem_cgroup_per_node *nodeinfo[0];
>    /* WARNING: nodeinfo must be the last member here */
>    };
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 8ec38b1..405f5e6 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -139,7 +139,12 @@ struct page {
>    struct {    /* Second tail page of compound page */
>    unsigned long _compound_pad_1;    /* compound_head */
>    unsigned long _compound_pad_2;
> -    struct list_head deferred_list;
> +    union {
> +    /* Global THP deferred split list */
> +    struct list_head deferred_list;
> +    /* Memcg THP deferred split list */
> +    struct list_head memcg_deferred_list;
 Why we need two namesakes for this list entry?

 For me it looks redundantly

Re: [RFC PATCH 6/6] soundwire: qcom: add support for SoundWire controller

2019-06-10 Thread Srinivas Kandagatla

Thanks for taking time to review!


On 10/06/2019 07:40, Vinod Koul wrote:

On 07-06-19, 09:56, Srinivas Kandagatla wrote:

Qualcomm SoundWire Master controller is present in most Qualcomm SoCs
either integrated as part of WCD audio codecs via slimbus or
as part of SOC I/O.

This patchset adds support to a very basic controller which has been
tested with WCD934x SoundWire controller connected to WSA881x smart
speaker amplifiers.

Signed-off-by: Srinivas Kandagatla 
---
  drivers/soundwire/Kconfig  |   9 +
  drivers/soundwire/Makefile |   4 +
  drivers/soundwire/qcom.c   | 983 +


Can you split this to two patches (at least), master driver followed by
DAI driver


Sure.




+
+#define SWRM_COMP_HW_VERSION   0x00


What does COMP stand for?


Controller splits registers into "Component(core configuration 
registers)", "Interrupt" "Command Fifo" and so on...





+#define SWRM_COMP_CFG_ADDR 0x04
+#define SWRM_COMP_CFG_IRQ_LEVEL_OR_PULSE_MSK   BIT(1)
+#define SWRM_COMP_CFG_ENABLE_MSK   BIT(0)
+#define SWRM_COMP_PARAMS   0x100
+#define SWRM_COMP_PARAMS_DOUT_PORTS_MASK   GENMASK(4, 0)
+#define SWRM_COMP_PARAMS_DIN_PORTS_MASK
GENMASK(9, 5)
+#define SWRM_COMP_PARAMS_WR_FIFO_DEPTH GENMASK(14, 10)
+#define SWRM_COMP_PARAMS_RD_FIFO_DEPTH GENMASK(19, 15)
+#define SWRM_COMP_PARAMS_AUTO_ENUM_SLAVES  GENMASK(32. 20)


Thats a lot of text, So as others have said we need to rethink the
naming conventions, perhaps QC_SDW_PARAM_AUTO_ENUM (feel free to drop
SDW as well from here as it QC specific!

Also move common ones to core..


+#define SWRM_INTERRUPT_STATUS  0x200
+#define SWRM_INTERRUPT_STATUS_RMSK GENMASK(16, 0)
+#define SWRM_INTERRUPT_STATUS_SLAVE_PEND_IRQ   BIT(0)
+#define SWRM_INTERRUPT_STATUS_NEW_SLAVE_ATTACHED   BIT(1)
+#define SWRM_INTERRUPT_STATUS_CHANGE_ENUM_SLAVE_STATUS BIT(2)
+#define SWRM_INTERRUPT_STATUS_MASTER_CLASH_DET BIT(3)
+#define SWRM_INTERRUPT_STATUS_RD_FIFO_OVERFLOW BIT(4)
+#define SWRM_INTERRUPT_STATUS_RD_FIFO_UNDERFLOWBIT(5)
+#define SWRM_INTERRUPT_STATUS_WR_CMD_FIFO_OVERFLOW BIT(6)
+#define SWRM_INTERRUPT_STATUS_CMD_ERRORBIT(7)
+#define SWRM_INTERRUPT_STATUS_DOUT_PORT_COLLISION  BIT(8)
+#define SWRM_INTERRUPT_STATUS_READ_EN_RD_VALID_MISMATCHBIT(9)
+#define SWRM_INTERRUPT_STATUS_SPECIAL_CMD_ID_FINISHED  BIT(10)
+#define SWRM_INTERRUPT_STATUS_NEW_SLAVE_AUTO_ENUM_FINISHED BIT(11)
+#define SWRM_INTERRUPT_STATUS_AUTO_ENUM_FAILED BIT(12)
+#define SWRM_INTERRUPT_STATUS_AUTO_ENUM_TABLE_IS_FULL  BIT(13)
+#define SWRM_INTERRUPT_STATUS_BUS_RESET_FINISHED   BIT(14)
+#define SWRM_INTERRUPT_STATUS_CLK_STOP_FINISHEDBIT(15)
+#define SWRM_INTERRUPT_STATUS_ERROR_PORT_TEST  BIT(16)
+#define SWRM_INTERRUPT_MASK_ADDR   0x204
+#define SWRM_INTERRUPT_CLEAR   0x208
+#define SWRM_CMD_FIFO_WR_CMD   0x300
+#define SWRM_CMD_FIFO_RD_CMD   0x304
+#define SWRM_CMD_FIFO_CMD  0x308
+#define SWRM_CMD_FIFO_STATUS   0x30C
+#define SWRM_CMD_FIFO_CFG_ADDR 0x314
+#define SWRM_CMD_FIFO_CFG_NUM_OF_CMD_RETRY_SHFT0x0
+#define SWRM_CMD_FIFO_RD_FIFO_ADDR 0x318
+#define SWRM_ENUMERATOR_CFG_ADDR   0x500
+#define SWRM_MCP_FRAME_CTRL_BANK_ADDR(m)   (0x101C + 0x40 * (m))
+#define SWRM_MCP_FRAME_CTRL_BANK_SSP_PERIOD_SHFT   16
+#define SWRM_MCP_FRAME_CTRL_BANK_ROW_CTRL_SHFT 3
+#define SWRM_MCP_FRAME_CTRL_BANK_COL_CTRL_BMSK GENMASK(2, 0)
+#define SWRM_MCP_FRAME_CTRL_BANK_COL_CTRL_SHFT 0
+#define SWRM_MCP_CFG_ADDR  0x1048
+#define SWRM_MCP_CFG_MAX_NUM_OF_CMD_NO_PINGS_BMSK  GENMASK(21, 17)
+#define SWRM_MCP_CFG_MAX_NUM_OF_CMD_NO_PINGS_SHFT  0x11
+#define SWRM_MCP_STATUS0x104C
+#define SWRM_MCP_STATUS_BANK_NUM_MASK  BIT(0)
+#define SWRM_MCP_SLV_STATUS0x1090
+#define SWRM_MCP_SLV_STATUS_MASK   GENMASK(1, 0)
+#define SWRM_DP_PORT_CTRL_BANK(n, m)   (0x1124 + 0x100 * (n - 1) + 0x40 * m)
+#define SWRM_DP_PORT_CTRL2_BANK(n, m)  (0x1126 + 0x100 * (n - 1) + 0x40 * m)
+#define SWRM_DP_PORT_CTR

Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ

2019-06-10 Thread Tony Lindgren
Hi,

* Kalle Valo  [190610 07:01]:
> Eugeniu Rosca  writes:
> 
> > The wl1837mod datasheet [1] says about the WL_IRQ pin:
> >
> >  ---8<---
> > SDIO available, interrupt out. Active high. [..]
> > Set to rising edge (active high) on powerup.
> >  ---8<---
> >
> > That's the reason of seeing the interrupt configured as:
> >  - IRQ_TYPE_EDGE_RISING on HiKey 960/970
> >  - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms
> >
> > We assert that all those platforms have the WL_IRQ pin connected
> > to the SoC _directly_ (confirmed on HiKey 970 [2]).
> >
> > That's not the case for R-Car Kingfisher extension target, which carries
> > a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present
> > between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively
> > reversing the requirement quoted from [1]. IOW, in Kingfisher DTS
> > configuration we would need to use IRQ_TYPE_EDGE_FALLING or
> > IRQ_TYPE_LEVEL_LOW.
> >
> > Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq:
> > support platform dependent interrupt types") made a special case out
> > of these interrupt types. After this commit, it is impossible to provide
> > an IRQ configuration via DTS which would describe an inverter present
> > between the WL18* chip and the SoC, generating the need for workarounds
> > like [3].
> >
> > Create a boolean OF property, called "invert-irq" to specify that
> > the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter.
> >
> > This solution has been successfully tested on R-Car H3ULCB-KF-M06 using
> > the DTS configuration [4] combined with the "invert-irq" property.
> >
> > [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
> > [2] 
> > https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/
> > [3] 
> > https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WL-side.patch
> > [4] https://patchwork.kernel.org/patch/10895879/
> > ("arm64: dts: ulcb-kf: Add support for TI WL1837")
> >
> > Signed-off-by: Eugeniu Rosca 
> 
> Tony&Eyal, do you agree with this?

Yeah if there's some hardware between the WLAN device and the SoC
inverting the interrupt, I don't think we have clear a way to deal
with it short of setting up a separate irqchip that does the
translation.

But in some cases we also do not want to invert the interrupt, so
I think this property should take IRQ_TYPE_EDGE_RISING and
IRQ_TYPE_EDGE_RISING values to override the setting for
the WLAN end of the hardware?

Let's wait a bit longer for comments from Eyal too.

Regards,

Tony


[PATCH v4 1/2] dt-bindings: interrupt-controller: Amazon's Annapurna Labs FIC

2019-06-10 Thread Talel Shenhar
Document Amazon's Annapurna Labs Fabric Interrupt Controller SoC binding.

Signed-off-by: Talel Shenhar 
---
 .../interrupt-controller/amazon,al-fic.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt 
b/Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt
new file mode 100644
index 000..4e82fd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt
@@ -0,0 +1,29 @@
+Amazon's Annapurna Labs Fabric Interrupt Controller
+
+Required properties:
+
+- compatible: should be "amazon,al-fic"
+- reg: physical base address and size of the registers
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: must be 2.
+  First cell defines the index of the interrupt within the controller.
+  Second cell is used to specify the trigger type and must be one of the
+  following:
+- bits[3:0] trigger type and level flags
+   1 = low-to-high edge triggered
+   4 = active high level-sensitive
+- interrupt-parent: specifies the parent interrupt controller.
+- interrupts: describes which input line in the interrupt parent, this
+  fic's output is connected to. This field property depends on the parent's
+  binding
+
+Example:
+
+amazon_fic: interrupt-controller@0xfd8a8500 {
+   compatible = "amazon,al-fic";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   reg = <0x0 0xfd8a8500 0x0 0x1000>;
+   interrupt-parent = <&gic>;
+   interrupts = ;
+};
-- 
2.7.4



[PATCH v4 0/2] Amazon's Annapurna Labs Fabric Interrupt Controller

2019-06-10 Thread Talel Shenhar
This series introduces support for Amazon's Annapurna Labs Fabric Interrupt
Controller.

The Amazon's Annapurna Labs FIC (Fabric Interrupt Controller) has 32
inputs/sources. This FIC may be cascaded into another FIC or connected
directly to the main CPU Interrupt Controller (e.g. GIC).

Changes since v3:
=
- tightened the verification for supported trigger types
- updated dt-binding's example to meet the binding description
  (interrupt-cells to 2)
- added description to interrupt-cells to explain each field
- changed pr_err to pr_debug inside al_fic_irq_set_type in order to allow
  the user to enable printouts for verbose information in case of errors

Changes since v2:
=
- updated dt-bindings to use proper format for entry name
- removed kernel-doc format style from Copyright
- removed unneeded/misplaced selects from Kconfig
- changed used mmio operation to relaxed flavor
- changed error return value from EPERM to EINVAL int case of attempting to
  reconfigure the FIC after it has been configured
- fixed commenting format
- used drivers define instead of subsystem internals
- moved al_fic_hw_init function to caller
- removed al_fic_wire_get_domain from documentation
- removed argument validation from al_fic_wire_init

Changes since v1:
=
- removing unused exported APIs
- updating cover letter and commit message accordingly



Talel Shenhar (2):
  dt-bindings: interrupt-controller: Amazon's Annapurna Labs FIC
  irqchip: al-fic: Introduce Amazon's Annapurna Labs Fabric Interrupt
Controller Driver

 .../interrupt-controller/amazon,al-fic.txt |  29 +++
 MAINTAINERS|   6 +
 drivers/irqchip/Kconfig|   8 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-al-fic.c   | 278 +
 5 files changed, 322 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt
 create mode 100644 drivers/irqchip/irq-al-fic.c

-- 
2.7.4



[PATCH v4 2/2] irqchip: al-fic: Introduce Amazon's Annapurna Labs Fabric Interrupt Controller Driver

2019-06-10 Thread Talel Shenhar
The Amazon's Annapurna Labs Fabric Interrupt Controller has 32 inputs.
A FIC (Fabric Interrupt Controller) may be cascaded into another FIC or
directly to the main CPU Interrupt Controller (e.g. GIC).

Signed-off-by: Talel Shenhar 
---
 MAINTAINERS  |   6 +
 drivers/irqchip/Kconfig  |   8 ++
 drivers/irqchip/Makefile |   1 +
 drivers/irqchip/irq-al-fic.c | 278 +++
 4 files changed, 293 insertions(+)
 create mode 100644 drivers/irqchip/irq-al-fic.c

diff --git a/MAINTAINERS b/MAINTAINERS
index f485597..b4f5255 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1209,6 +1209,12 @@ S:   Maintained
 F: Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt
 F: drivers/irqchip/irq-vic.c
 
+AMAZON ANNAPURNA LABS FIC DRIVER
+M: Talel Shenhar 
+S: Maintained
+F: Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt
+F: drivers/irqchip/irq-al-fic.c
+
 ARM SMMU DRIVERS
 M: Will Deacon 
 R: Robin Murphy 
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 51a5ef0..7237892 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -89,6 +89,14 @@ config ALPINE_MSI
select PCI_MSI
select GENERIC_IRQ_CHIP
 
+config AL_FIC
+   bool "Amazon's Annapurna Labs Fabric Interrupt Controller"
+   depends on OF || COMPILE_TEST
+   select GENERIC_IRQ_CHIP
+   select IRQ_DOMAIN
+   help
+ Support Amazon's Annapurna Labs Fabric Interrupt Controller.
+
 config ATMEL_AIC_IRQ
bool
select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 794c13d..a20eba5 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_IRQCHIP)  += irqchip.o
 
+obj-$(CONFIG_AL_FIC)   += irq-al-fic.o
 obj-$(CONFIG_ALPINE_MSI)   += irq-alpine-msi.o
 obj-$(CONFIG_ATH79)+= irq-ath79-cpu.o
 obj-$(CONFIG_ATH79)+= irq-ath79-misc.o
diff --git a/drivers/irqchip/irq-al-fic.c b/drivers/irqchip/irq-al-fic.c
new file mode 100644
index 000..1a57cee
--- /dev/null
+++ b/drivers/irqchip/irq-al-fic.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* FIC Registers */
+#define AL_FIC_CAUSE   0x00
+#define AL_FIC_MASK0x10
+#define AL_FIC_CONTROL 0x28
+
+#define CONTROL_TRIGGER_RISING BIT(3)
+#define CONTROL_MASK_MSI_X BIT(5)
+
+#define NR_FIC_IRQS 32
+
+MODULE_AUTHOR("Talel Shenhar");
+MODULE_DESCRIPTION("Amazon's Annapurna Labs Interrupt Controller Driver");
+MODULE_LICENSE("GPL v2");
+
+enum al_fic_state {
+   AL_FIC_UNCONFIGURED = 0,
+   AL_FIC_CONFIGURED_LEVEL,
+   AL_FIC_CONFIGURED_RISING_EDGE,
+};
+
+struct al_fic {
+   void __iomem *base;
+   struct irq_domain *domain;
+   const char *name;
+   unsigned int parent_irq;
+   enum al_fic_state state;
+};
+
+static void al_fic_set_trigger(struct al_fic *fic,
+  struct irq_chip_generic *gc,
+  enum al_fic_state new_state)
+{
+   irq_flow_handler_t handler;
+   u32 control = readl_relaxed(fic->base + AL_FIC_CONTROL);
+
+   if (new_state == AL_FIC_CONFIGURED_LEVEL) {
+   handler = handle_level_irq;
+   control &= ~CONTROL_TRIGGER_RISING;
+   } else {
+   handler = handle_edge_irq;
+   control |= CONTROL_TRIGGER_RISING;
+   }
+   gc->chip_types->handler = handler;
+   fic->state = new_state;
+   writel_relaxed(control, fic->base + AL_FIC_CONTROL);
+}
+
+static int al_fic_irq_set_type(struct irq_data *data, unsigned int flow_type)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+   struct al_fic *fic = gc->private;
+   enum al_fic_state new_state;
+   int ret = 0;
+
+   irq_gc_lock(gc);
+
+   if (((flow_type & IRQ_TYPE_SENSE_MASK) != IRQ_TYPE_LEVEL_HIGH) &&
+   ((flow_type & IRQ_TYPE_SENSE_MASK) != IRQ_TYPE_EDGE_RISING)) {
+   pr_debug("fic doesn't support flow type %d\n", flow_type);
+   ret = -EINVAL;
+   goto err;
+   }
+
+   new_state = (flow_type & IRQ_TYPE_LEVEL_HIGH) ?
+   AL_FIC_CONFIGURED_LEVEL : AL_FIC_CONFIGURED_RISING_EDGE;
+
+   /*
+* A given FIC instance can be either all level or all edge triggered.
+* This is generally fixed depending on what pieces of HW it's wired up
+* to.
+*
+* We configure it based on the sensitivity of the first source
+* being setup, and reject any subsequent attempt at configuring it in a
+* different way.
+*/
+   if

[PATCH v3 7/8] usb: dwc3: qcom: Start USB in 'host mode' on the SDM845

2019-06-10 Thread Lee Jones
When booting with Device Tree, the current default boot configuration
table option, the request to boot via 'host mode' comes from the
'dr_mode' property.  A property of the same name can be used inside
ACPI tables too.  However it is missing from the SDM845's ACPI tables
so we have to supply this information using Platform Device Properties
instead.

This does not change the behaviour of any currently supported devices.
The property is only set on ACPI enabled platforms, thus for H/W
booting DT, unless a 'dr_mode' property is present, the default is
still OTG (On-The-Go) as per [0].  Any new ACPI devices added will
also be able to over-ride this implementation by providing a 'dr_mode'
property in their ACPI tables.  In cases where 'dr_mode' is omitted
from the tables AND 'host mode' should not be the default (very
unlikely), then we will have to add some way of choosing between them
at run time - most likely by ACPI HID.

[0] Documentation/devicetree/bindings/usb/generic.txt

Signed-off-by: Lee Jones 
---
 drivers/usb/dwc3/dwc3-qcom.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 1e1f12b7991d..55ba04254e38 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -444,6 +444,11 @@ static int dwc3_qcom_clk_init(struct dwc3_qcom *qcom, int 
count)
return 0;
 }
 
+static const struct property_entry dwc3_qcom_acpi_properties[] = {
+   PROPERTY_ENTRY_STRING("dr_mode", "host"),
+   {}
+};
+
 static int dwc3_qcom_acpi_register_core(struct platform_device *pdev)
 {
struct dwc3_qcom*qcom = platform_get_drvdata(pdev);
@@ -488,6 +493,13 @@ static int dwc3_qcom_acpi_register_core(struct 
platform_device *pdev)
goto out;
}
 
+   ret = platform_device_add_properties(qcom->dwc3,
+dwc3_qcom_acpi_properties);
+   if (ret < 0) {
+   dev_err(&pdev->dev, "failed to add properties\n");
+   goto out;
+   }
+
ret = platform_device_add(qcom->dwc3);
if (ret)
dev_err(&pdev->dev, "failed to add device\n");
-- 
2.17.1



[PATCH v3 2/8] i2c: i2c-qcom-geni: Signify successful driver probe

2019-06-10 Thread Lee Jones
The Qualcomm Geni I2C driver currently probes silently which can be
confusing when debugging potential issues.  Add a low level (INFO)
print when each I2C controller is successfully initially set-up.

Signed-off-by: Lee Jones 
Acked-by: Ard Biesheuvel 
---
 drivers/i2c/busses/i2c-qcom-geni.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c 
b/drivers/i2c/busses/i2c-qcom-geni.c
index 9e3b8a98688d..a89bfce5388e 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -596,6 +596,8 @@ static int geni_i2c_probe(struct platform_device *pdev)
return ret;
}
 
+   dev_dbg(&pdev->dev, "Geni-I2C adaptor successfully added\n");
+
return 0;
 }
 
-- 
2.17.1



Re: [PATCH 4.19 01/51] ethtool: fix potential userspace buffer overflow

2019-06-10 Thread Michal Kubecek
On Mon, Jun 10, 2019 at 10:21:12AM +0200, Pavel Machek wrote:
> Hi!
> 
> > From: Vivien Didelot 
> > 
> > [ Upstream commit 0ee4e76937d69128a6a66861ba393ebdc2ffc8a2 ]
> > 
> > ethtool_get_regs() allocates a buffer of size ops->get_regs_len(),
> > and pass it to the kernel driver via ops->get_regs() for filling.
> > 
> > There is no restriction about what the kernel drivers can or cannot do
> > with the open ethtool_regs structure. They usually set regs->version
> > and ignore regs->len or set it to the same size as ops->get_regs_len().
> > 
> > But if userspace allocates a smaller buffer for the registers dump,
> > we would cause a userspace buffer overflow in the final copy_to_user()
> > call, which uses the regs.len value potentially reset by the driver.
> > 
> > To fix this, make this case obvious and store regs.len before calling
> > ops->get_regs(), to only copy as much data as requested by userspace,
> > up to the value returned by ops->get_regs_len().
> > 
> > While at it, remove the redundant check for non-null regbuf.
> 
> Mainline differs from 4.19-stable here, and while the non-null check
> is redundant in -mainline, it does not seem to be redundant in
> -stable.
> 
> In stable, if get_regs_len() returns < 0, we'll pass it to vzalloc.

Right. :-(

I guess we should also pick commit f9fc54d313fa ("ethtool: check the
return value of get_regs_len") to stable branches before 5.0.

Michal


  1   2   3   4   5   6   7   8   9   >