[PATCH 4/4] staging:rtl8192u: Remove typedef from enum opt_rst_type_e - Style

2018-09-08 Thread John Whitmore
Remove the typedef directive from enumerated type opt_rst_type_e, this change clears the checkpatch issue with defining new types in the code. This is a coding style change which should not impact runtime code execution. Signed-off-by: John Whitmore ---

[PATCH 0/4] staging:rtl8192u: Style changes r819xU_firmware.h

2018-09-08 Thread John Whitmore
This short series of patches just clears simple checkpatch issues with the header file r819xU_firmware.h. John Whitmore (4): staging:rtl8192u: Remove unused RTL8190_CPU_START_OFFSET - Style staging:rtl8192u: Refactor GET_COMMAND_PACKET_FRAG_THRESHOLD - Style staging:rtl8192u: Remove typedef

[PATCH 4/4] staging:rtl8192u: Remove typedef from enum opt_rst_type_e - Style

2018-09-08 Thread John Whitmore
Remove the typedef directive from enumerated type opt_rst_type_e, this change clears the checkpatch issue with defining new types in the code. This is a coding style change which should not impact runtime code execution. Signed-off-by: John Whitmore ---

[PATCH 0/4] staging:rtl8192u: Style changes r819xU_firmware.h

2018-09-08 Thread John Whitmore
This short series of patches just clears simple checkpatch issues with the header file r819xU_firmware.h. John Whitmore (4): staging:rtl8192u: Remove unused RTL8190_CPU_START_OFFSET - Style staging:rtl8192u: Refactor GET_COMMAND_PACKET_FRAG_THRESHOLD - Style staging:rtl8192u: Remove typedef

[PATCH 1/4] staging:rtl8192u: Remove unused RTL8190_CPU_START_OFFSET - Style

2018-09-08 Thread John Whitmore
The defined constant RTL8190_CPU_START_OFFSET is not used in the code so has been removed. This is a coding style change which should have no impact on runtime code execution. Signed-off-by: John Whitmore --- drivers/staging/rtl8192u/r819xU_firmware.h | 1 - 1 file changed, 1 deletion(-) diff

[PATCH 2/4] staging:rtl8192u: Refactor GET_COMMAND_PACKET_FRAG_THRESHOLD - Style

2018-09-08 Thread John Whitmore
The MACRO GET_COMMAND_PACKET_FRAG_THRESHOLD causes a number of checkpatch issues so has been refactored to use braces around the parameter 'v' to avoid precedence issues, and to add spaces around operators. These changes are coding style changes which should have no impact on runtime code

[PATCH 1/4] staging:rtl8192u: Remove unused RTL8190_CPU_START_OFFSET - Style

2018-09-08 Thread John Whitmore
The defined constant RTL8190_CPU_START_OFFSET is not used in the code so has been removed. This is a coding style change which should have no impact on runtime code execution. Signed-off-by: John Whitmore --- drivers/staging/rtl8192u/r819xU_firmware.h | 1 - 1 file changed, 1 deletion(-) diff

[PATCH 2/4] staging:rtl8192u: Refactor GET_COMMAND_PACKET_FRAG_THRESHOLD - Style

2018-09-08 Thread John Whitmore
The MACRO GET_COMMAND_PACKET_FRAG_THRESHOLD causes a number of checkpatch issues so has been refactored to use braces around the parameter 'v' to avoid precedence issues, and to add spaces around operators. These changes are coding style changes which should have no impact on runtime code

Re: [PATCH] lib/sg_pool: remove unnecessary null check when free the object

2018-09-08 Thread zhong jiang
Hi, Thomas Can you pick up the patch? Thanks zhong jiang On 2018/8/1 0:21, zhong jiang wrote: > kmem_cache_destroy/mempool_destroy has taken null check into account. > so remove the redundant check. > > Signed-off-by: zhong jiang > --- > lib/sg_pool.c | 7 +++ > 1 file changed, 3

Re: [PATCH] lib/sg_pool: remove unnecessary null check when free the object

2018-09-08 Thread zhong jiang
Hi, Thomas Can you pick up the patch? Thanks zhong jiang On 2018/8/1 0:21, zhong jiang wrote: > kmem_cache_destroy/mempool_destroy has taken null check into account. > so remove the redundant check. > > Signed-off-by: zhong jiang > --- > lib/sg_pool.c | 7 +++ > 1 file changed, 3

Re: [RFC][PATCH 3/8] x86/mm: break out user address space handling

2018-09-08 Thread Peter Zijlstra
On Fri, Sep 07, 2018 at 12:48:57PM -0700, Dave Hansen wrote: > +static noinline void > +__do_page_fault(struct pt_regs *regs, unsigned long hw_error_code, > + unsigned long address) > +{ > + prefetchw(>mm->mmap_sem); > + > + if (unlikely(kmmio_fault(regs, address))) > +

Re: [PATCH V2 4/8] regulator: stpmic1: add stpmic1 regulator driver

2018-09-08 Thread Antonio Borneo
On Fri, Sep 7, 2018 at 3:15 PM Pascal PAILLET-LME wrote: > > From: pascal paillet > > The stpmic1 PMIC embeds several regulators and witches with > different capabilities. While fixing Kconfig, as Mark suggest, would you mind to fix also the typo s/witches/switches/ in the commit message?

Re: [RFC][PATCH 3/8] x86/mm: break out user address space handling

2018-09-08 Thread Peter Zijlstra
On Fri, Sep 07, 2018 at 12:48:57PM -0700, Dave Hansen wrote: > +static noinline void > +__do_page_fault(struct pt_regs *regs, unsigned long hw_error_code, > + unsigned long address) > +{ > + prefetchw(>mm->mmap_sem); > + > + if (unlikely(kmmio_fault(regs, address))) > +

Re: [PATCH V2 4/8] regulator: stpmic1: add stpmic1 regulator driver

2018-09-08 Thread Antonio Borneo
On Fri, Sep 7, 2018 at 3:15 PM Pascal PAILLET-LME wrote: > > From: pascal paillet > > The stpmic1 PMIC embeds several regulators and witches with > different capabilities. While fixing Kconfig, as Mark suggest, would you mind to fix also the typo s/witches/switches/ in the commit message?

[tip:x86/pti] x86/pti/64: Remove the SYSCALL64 entry trampoline

2018-09-08 Thread tip-bot for Andy Lutomirski
Commit-ID: 344347941aba1ec906ff50b4cdb8178c906746f2 Gitweb: https://git.kernel.org/tip/344347941aba1ec906ff50b4cdb8178c906746f2 Author: Andy Lutomirski AuthorDate: Mon, 3 Sep 2018 15:59:44 -0700 Committer: Thomas Gleixner CommitDate: Sat, 8 Sep 2018 11:20:12 +0200 x86/pti/64: Remove

[tip:x86/pti] x86/pti/64: Remove the SYSCALL64 entry trampoline

2018-09-08 Thread tip-bot for Andy Lutomirski
Commit-ID: 344347941aba1ec906ff50b4cdb8178c906746f2 Gitweb: https://git.kernel.org/tip/344347941aba1ec906ff50b4cdb8178c906746f2 Author: Andy Lutomirski AuthorDate: Mon, 3 Sep 2018 15:59:44 -0700 Committer: Thomas Gleixner CommitDate: Sat, 8 Sep 2018 11:20:12 +0200 x86/pti/64: Remove

[tip:x86/pti] x86/entry/64: Document idtentry

2018-09-08 Thread tip-bot for Andy Lutomirski
Commit-ID: bd7b1f7cbf9cb35dab8e1b99145d07afc5b7a132 Gitweb: https://git.kernel.org/tip/bd7b1f7cbf9cb35dab8e1b99145d07afc5b7a132 Author: Andy Lutomirski AuthorDate: Mon, 3 Sep 2018 15:59:42 -0700 Committer: Thomas Gleixner CommitDate: Sat, 8 Sep 2018 11:20:11 +0200 x86/entry/64:

[tip:x86/pti] x86/entry/64: Use the TSS sp2 slot for SYSCALL/SYSRET scratch space

2018-09-08 Thread tip-bot for Andy Lutomirski
Commit-ID: 98f05b5138f0a9b56022295cc1387e635b25635d Gitweb: https://git.kernel.org/tip/98f05b5138f0a9b56022295cc1387e635b25635d Author: Andy Lutomirski AuthorDate: Mon, 3 Sep 2018 15:59:43 -0700 Committer: Thomas Gleixner CommitDate: Sat, 8 Sep 2018 11:20:11 +0200 x86/entry/64: Use

[tip:x86/pti] x86/entry/64: Document idtentry

2018-09-08 Thread tip-bot for Andy Lutomirski
Commit-ID: bd7b1f7cbf9cb35dab8e1b99145d07afc5b7a132 Gitweb: https://git.kernel.org/tip/bd7b1f7cbf9cb35dab8e1b99145d07afc5b7a132 Author: Andy Lutomirski AuthorDate: Mon, 3 Sep 2018 15:59:42 -0700 Committer: Thomas Gleixner CommitDate: Sat, 8 Sep 2018 11:20:11 +0200 x86/entry/64:

[tip:x86/pti] x86/entry/64: Use the TSS sp2 slot for SYSCALL/SYSRET scratch space

2018-09-08 Thread tip-bot for Andy Lutomirski
Commit-ID: 98f05b5138f0a9b56022295cc1387e635b25635d Gitweb: https://git.kernel.org/tip/98f05b5138f0a9b56022295cc1387e635b25635d Author: Andy Lutomirski AuthorDate: Mon, 3 Sep 2018 15:59:43 -0700 Committer: Thomas Gleixner CommitDate: Sat, 8 Sep 2018 11:20:11 +0200 x86/entry/64: Use

Re: [PATCH v4 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

2018-09-08 Thread Thomas Gleixner
On Sat, 8 Sep 2018, Thomas Gleixner wrote: > On Fri, 7 Sep 2018, Jiri Kosina wrote: > > So I will go through the whole codepath again, but I fear your suggestion > > would not work -- see the check for cpu_smt_control in stibp_needed(). We > > need to see the old (or new, depending on the

Re: [PATCH v4 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

2018-09-08 Thread Thomas Gleixner
On Sat, 8 Sep 2018, Thomas Gleixner wrote: > On Fri, 7 Sep 2018, Jiri Kosina wrote: > > So I will go through the whole codepath again, but I fear your suggestion > > would not work -- see the check for cpu_smt_control in stibp_needed(). We > > need to see the old (or new, depending on the

[PATCH] s390/zcrypt: Use kmemdup to replace kmalloc + memcpy

2018-09-08 Thread zhong jiang
kmemdup has implemented the function that kmalloc() + memcpy() will do. and we prefer to use the kmemdup rather than the open coded implementation. Signed-off-by: zhong jiang --- drivers/s390/crypto/zcrypt_msgtype6.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git

[PATCH] s390/zcrypt: Use kmemdup to replace kmalloc + memcpy

2018-09-08 Thread zhong jiang
kmemdup has implemented the function that kmalloc() + memcpy() will do. and we prefer to use the kmemdup rather than the open coded implementation. Signed-off-by: zhong jiang --- drivers/s390/crypto/zcrypt_msgtype6.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git

[PATCH 1/2] sound: q6core: Use kmemdup to replace kzalloc + memcpy

2018-09-08 Thread zhong jiang
kmemdup has implemented the function that kzalloc() + memcpy() will do. and we prefer to use the kmemdup rather than the open coded implementation. Signed-off-by: zhong jiang --- sound/soc/qcom/qdsp6/q6core.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git

[PATCH 0/2] sound: Use kmemdup to replace kzalloc + memcpy

2018-09-08 Thread zhong jiang
I find the issue with the help of Coccinelle. zhong jiang (2): sound: q6core: Use kmemdup to replace kzalloc + memcpy sound: skl-topology: Use kmemdup to replace kzalloc + memcpy sound/soc/intel/skylake/skl-topology.c | 3 +-- sound/soc/qcom/qdsp6/q6core.c | 8 ++-- 2 files

[PATCH 1/2] sound: q6core: Use kmemdup to replace kzalloc + memcpy

2018-09-08 Thread zhong jiang
kmemdup has implemented the function that kzalloc() + memcpy() will do. and we prefer to use the kmemdup rather than the open coded implementation. Signed-off-by: zhong jiang --- sound/soc/qcom/qdsp6/q6core.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git

[PATCH 0/2] sound: Use kmemdup to replace kzalloc + memcpy

2018-09-08 Thread zhong jiang
I find the issue with the help of Coccinelle. zhong jiang (2): sound: q6core: Use kmemdup to replace kzalloc + memcpy sound: skl-topology: Use kmemdup to replace kzalloc + memcpy sound/soc/intel/skylake/skl-topology.c | 3 +-- sound/soc/qcom/qdsp6/q6core.c | 8 ++-- 2 files

[PATCH 2/2] sound: skl-topology: Use kmemdup to replace kzalloc + memcpy

2018-09-08 Thread zhong jiang
kmemdup has implemented the function that kzalloc() + memcpy() will do. and we prefer to kmemdup rather than the open coded implementation. Signed-off-by: zhong jiang --- sound/soc/intel/skylake/skl-topology.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH 2/2] sound: skl-topology: Use kmemdup to replace kzalloc + memcpy

2018-09-08 Thread zhong jiang
kmemdup has implemented the function that kzalloc() + memcpy() will do. and we prefer to kmemdup rather than the open coded implementation. Signed-off-by: zhong jiang --- sound/soc/intel/skylake/skl-topology.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

Re: [PATCH 4.14 00/89] 4.14.69-stable review

2018-09-08 Thread Greg Kroah-Hartman
On Fri, Sep 07, 2018 at 03:37:37PM -0700, Nathan Chancellor wrote: > On Fri, Sep 07, 2018 at 11:08:54PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.69 release. > > There are 89 patches in this series, all will be posted as a response > > to this

Re: [PATCH 4.14 00/89] 4.14.69-stable review

2018-09-08 Thread Greg Kroah-Hartman
On Fri, Sep 07, 2018 at 03:37:37PM -0700, Nathan Chancellor wrote: > On Fri, Sep 07, 2018 at 11:08:54PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.69 release. > > There are 89 patches in this series, all will be posted as a response > > to this

Re: [PATCH 3.18 00/29] 3.18.122-stable review

2018-09-08 Thread Greg Kroah-Hartman
On Sat, Sep 08, 2018 at 10:53:22AM +0530, Harsh 'Shandilya wrote: > On 8 September 2018 2:40:21 AM IST, Greg Kroah-Hartman > wrote: > >This is the start of the stable review cycle for the 3.18.122 release. > >There are 29 patches in this series, all will be posted as a response > >to this one.

Re: [PATCH 3.18 00/29] 3.18.122-stable review

2018-09-08 Thread Greg Kroah-Hartman
On Sat, Sep 08, 2018 at 10:53:22AM +0530, Harsh 'Shandilya wrote: > On 8 September 2018 2:40:21 AM IST, Greg Kroah-Hartman > wrote: > >This is the start of the stable review cycle for the 3.18.122 release. > >There are 29 patches in this series, all will be posted as a response > >to this one.

[PATCH 4.14 09/89] readahead: stricter check for bdi io_pages

2018-09-08 Thread Greg Kroah-Hartman
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Markus Stockhausen commit dc30b96ab6d569060741572cf30517d3179429a8 upstream. ondemand_readahead() checks bdi->io_pages to cap the maximum pages that need to be processed. This works until the

[PATCH 4.18 012/145] readahead: stricter check for bdi io_pages

2018-09-08 Thread Greg Kroah-Hartman
4.18-stable review patch. If anyone has any objections, please let me know. -- From: Markus Stockhausen commit dc30b96ab6d569060741572cf30517d3179429a8 upstream. ondemand_readahead() checks bdi->io_pages to cap the maximum pages that need to be processed. This works until the

[PATCH 4.14 09/89] readahead: stricter check for bdi io_pages

2018-09-08 Thread Greg Kroah-Hartman
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Markus Stockhausen commit dc30b96ab6d569060741572cf30517d3179429a8 upstream. ondemand_readahead() checks bdi->io_pages to cap the maximum pages that need to be processed. This works until the

[PATCH 4.18 012/145] readahead: stricter check for bdi io_pages

2018-09-08 Thread Greg Kroah-Hartman
4.18-stable review patch. If anyone has any objections, please let me know. -- From: Markus Stockhausen commit dc30b96ab6d569060741572cf30517d3179429a8 upstream. ondemand_readahead() checks bdi->io_pages to cap the maximum pages that need to be processed. This works until the

Re: [PATCH v4 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

2018-09-08 Thread Jiri Kosina
On Sat, 8 Sep 2018, Thomas Gleixner wrote: > If after changing the SMT to enable a normal hotplug operation happens > then you need to update the MSR as well. Ah, right you are, thanks. Will fix in v5. -- Jiri Kosina SUSE Labs

Re: [PATCH v4 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

2018-09-08 Thread Jiri Kosina
On Sat, 8 Sep 2018, Thomas Gleixner wrote: > If after changing the SMT to enable a normal hotplug operation happens > then you need to update the MSR as well. Ah, right you are, thanks. Will fix in v5. -- Jiri Kosina SUSE Labs

[PATCH v2 2/2] irq/matrix: Spread managed interrupts on allocation

2018-09-08 Thread Dou Liyang
From: Dou Liyang Linux has spread out the non managed interrupt across the possible target CPUs to avoid vector space exhaustion. But, the same situation may happen on the managed interrupts. Spread managed interrupt on allocation as well. Fixes: a0c9259dc4e1("irq/matrix: Spread interrupts on

[PATCH v2 2/2] irq/matrix: Spread managed interrupts on allocation

2018-09-08 Thread Dou Liyang
From: Dou Liyang Linux has spread out the non managed interrupt across the possible target CPUs to avoid vector space exhaustion. But, the same situation may happen on the managed interrupts. Spread managed interrupt on allocation as well. Fixes: a0c9259dc4e1("irq/matrix: Spread interrupts on

[PATCH v2 1/2] irq/matrix: Split out the CPU finding code into a helper

2018-09-08 Thread Dou Liyang
From: Dou Liyang Linux finds the CPU which has the lowest vector allocation count to spread out the non managed interrupt across the possible target CPUs. This common CPU finding code will also be used in managed case, So Split it out into a helper for preparation. Signed-off-by: Dou Liyang

[PATCH v2 1/2] irq/matrix: Split out the CPU finding code into a helper

2018-09-08 Thread Dou Liyang
From: Dou Liyang Linux finds the CPU which has the lowest vector allocation count to spread out the non managed interrupt across the possible target CPUs. This common CPU finding code will also be used in managed case, So Split it out into a helper for preparation. Signed-off-by: Dou Liyang

Re: [PATCH v4 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

2018-09-08 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Jiri Kosina wrote: > On Fri, 7 Sep 2018, Thomas Gleixner wrote: > > > > + * The read-modify-write of the MSR doesn't need any race protection > > > here, > > > + * as we're running in atomic context. > > > + */ > > > +static void enable_stibp(void *info) > > > +{ > > > + u64

Re: [PATCH v4 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

2018-09-08 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Jiri Kosina wrote: > On Fri, 7 Sep 2018, Thomas Gleixner wrote: > > > > + * The read-modify-write of the MSR doesn't need any race protection > > > here, > > > + * as we're running in atomic context. > > > + */ > > > +static void enable_stibp(void *info) > > > +{ > > > + u64

[PATCH] dma: idma64: replace spin_lock_irqsave with spin_lock

2018-09-08 Thread Zhaoxiong Yuan
idma64_chan_irq() is invoked in hardirq handle function, it is unnecessary to call spin_lock_irqsave. Signed-off-by: Zhaoxiong Yuan --- drivers/dma/idma64.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/dma/idma64.c b/drivers/dma/idma64.c index

[PATCH] dma: idma64: replace spin_lock_irqsave with spin_lock

2018-09-08 Thread Zhaoxiong Yuan
idma64_chan_irq() is invoked in hardirq handle function, it is unnecessary to call spin_lock_irqsave. Signed-off-by: Zhaoxiong Yuan --- drivers/dma/idma64.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/dma/idma64.c b/drivers/dma/idma64.c index

Re: [PATCH v2 3/3] x86/pti/64: Remove the SYSCALL64 entry trampoline

2018-09-08 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Andy Lutomirski wrote: > On Fri, Sep 7, 2018 at 5:04 PM, Linus Torvalds > wrote: > > Virtual mapping tricks may be cool, but in the end, not having to use > > them is better still, I think. > > > > If (and this is a *big* if) all the percpu data is within 2GB of the > entry

Re: [PATCH v2 3/3] x86/pti/64: Remove the SYSCALL64 entry trampoline

2018-09-08 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Andy Lutomirski wrote: > On Fri, Sep 7, 2018 at 5:04 PM, Linus Torvalds > wrote: > > Virtual mapping tricks may be cool, but in the end, not having to use > > them is better still, I think. > > > > If (and this is a *big* if) all the percpu data is within 2GB of the > entry

Re: [PATCH v2 3/3] x86/pti/64: Remove the SYSCALL64 entry trampoline

2018-09-08 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Linus Torvalds wrote: > On Fri, Sep 7, 2018 at 12:54 PM Thomas Gleixner wrote: > > > > > - We execute from an extra page and read from another extra page > > > during the syscall. (The latter is because we need to use a relative > > > addressing mode to find sp1 -- it's the

Re: [PATCH v2 3/3] x86/pti/64: Remove the SYSCALL64 entry trampoline

2018-09-08 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Linus Torvalds wrote: > On Fri, Sep 7, 2018 at 12:54 PM Thomas Gleixner wrote: > > > > > - We execute from an extra page and read from another extra page > > > during the syscall. (The latter is because we need to use a relative > > > addressing mode to find sp1 -- it's the

<    1   2   3   4