Re: [PATCH v6 0/3] Cavium ARM64 uncore PMU support

On Fri, Jun 23, 2017 at 03:01:25PM +0200, Jan Glauber wrote: > Add support for various PMU counters found on the Cavium ThunderX and > OcteonTx SoC. > > The driver provides common "uncore" functions to avoid code duplication and > support adding more device PMUs (like L2 cache) in the future. >

Re: [PATCH 01/11] net: phy: Add rockchip phy driver support

On Fri, Jun 23, 2017 at 12:41:59PM +0800, David Wu wrote: > Support internal ephy currently. > > Signed-off-by: David Wu > --- > drivers/net/phy/Kconfig| 4 ++ > drivers/net/phy/Makefile | 1 + > drivers/net/phy/rockchip.c | 94 > ++ > 3

[PATCH] Staging : rts5208 : checkpatch.pl fixes

Fixed some issues reported by checkpatch.pl script. Signed-off-by: Simo Koskinen --- drivers/staging/rts5208/rtsx.c | 2 +- drivers/staging/rts5208/rtsx_chip.c | 6 -- drivers/staging/rts5208/sd.c| 14 ++ drivers/staging/rts5208/spi.c |

Re: [PATCH/RFC 6/9] perf symbols: Use already loaded module dso when loading kcore

Em Fri, Jun 23, 2017 at 02:48:24PM +0900, Namhyung Kim escreveu: > Even every module has loaded onto same addresses, some modules can be > changed and reloaded. Can you rephrase the above statement? You mean even if a module is reloaded at the same address it can have a different symtab and thus

[PATCH] Staging : rts5208 : checkpatch.pl fixes

Fixed some issues reported by checkpatch.pl script. Signed-off-by: Simo Koskinen --- drivers/staging/rts5208/rtsx.c | 2 +- drivers/staging/rts5208/rtsx_chip.c | 6 -- drivers/staging/rts5208/sd.c| 14 ++ drivers/staging/rts5208/spi.c | 11 +++

Re: [PATCH/RFC 6/9] perf symbols: Use already loaded module dso when loading kcore

Em Fri, Jun 23, 2017 at 02:48:24PM +0900, Namhyung Kim escreveu: > Even every module has loaded onto same addresses, some modules can be > changed and reloaded. Can you rephrase the above statement? You mean even if a module is reloaded at the same address it can have a different symtab and thus

Re: [PATCH 1/7] drm/bridge: Support hotplugging panel-bridge.

On 6/22/2017 7:04 PM, Boris Brezillon wrote: On Thu, 22 Jun 2017 15:16:47 +0200 Andrzej Hajda wrote: On 22.06.2017 14:41, Boris Brezillon wrote: On Thu, 22 Jun 2017 14:29:07 +0200 Andrzej Hajda wrote: On 22.06.2017 11:23, Boris Brezillon

Re: [PATCH 1/7] drm/bridge: Support hotplugging panel-bridge.

On 6/22/2017 7:04 PM, Boris Brezillon wrote: On Thu, 22 Jun 2017 15:16:47 +0200 Andrzej Hajda wrote: On 22.06.2017 14:41, Boris Brezillon wrote: On Thu, 22 Jun 2017 14:29:07 +0200 Andrzej Hajda wrote: On 22.06.2017 11:23, Boris Brezillon wrote: On Thu, 22 Jun 2017 13:47:43 +0530

[RESEND PATCH v9 3/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #126

From: Geetha Sowjanya Cavium ThunderX2 SMMU doesn't support MSI and also doesn't have unique irq lines for gerror, eventq and cmdq-sync. New named irq "combined" is set as a errata workaround, which allows to share the irq line by register single irq handler for

[RESEND PATCH v9 3/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #126

From: Geetha Sowjanya Cavium ThunderX2 SMMU doesn't support MSI and also doesn't have unique irq lines for gerror, eventq and cmdq-sync. New named irq "combined" is set as a errata workaround, which allows to share the irq line by register single irq handler for all the interrupts.

Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE

On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel wrote: > Hi Kees, > > On 22 June 2017 at 18:06, Kees Cook wrote: >> Now that explicitly executed loaders are loaded in the mmap region, >> position PIE binaries lower in the address space to avoid

Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE

On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel wrote: > Hi Kees, > > On 22 June 2017 at 18:06, Kees Cook wrote: >> Now that explicitly executed loaders are loaded in the mmap region, >> position PIE binaries lower in the address space to avoid possible >> collisions with mmap or stack regions.

Re: [PATCH/RFC 3/9] perf symbols: Discard symbols in kallsyms for loaded modules

Em Fri, Jun 23, 2017 at 02:48:21PM +0900, Namhyung Kim escreveu: > If a module is already loaded, it should have symbols and no need to > load new symbols from kallsyms. Actually kallsyms can have different > addresses if the module was reloaded. Well, if it is loaded, then it should match what

Re: [PATCH/RFC 3/9] perf symbols: Discard symbols in kallsyms for loaded modules

Em Fri, Jun 23, 2017 at 02:48:21PM +0900, Namhyung Kim escreveu: > If a module is already loaded, it should have symbols and no need to > load new symbols from kallsyms. Actually kallsyms can have different > addresses if the module was reloaded. Well, if it is loaded, then it should match what

[PATCH 2/2] tpm: use tpm2_pcr_read() in tpm2_do_selftest()

tpm2_do_selftest() performs a PCR read during the TPM initialization phase. This patch replaces the PCR read code with a call to tpm2_pcr_read(). Signed-off-by: Roberto Sassu --- drivers/char/tpm/tpm2-cmd.c | 31 +-- 1 file changed, 1

[PATCH 2/2] tpm: use tpm2_pcr_read() in tpm2_do_selftest()

tpm2_do_selftest() performs a PCR read during the TPM initialization phase. This patch replaces the PCR read code with a call to tpm2_pcr_read(). Signed-off-by: Roberto Sassu --- drivers/char/tpm/tpm2-cmd.c | 31 +-- 1 file changed, 1 insertion(+), 30 deletions(-)

[GIT PULL] ACPI fix for v4.12-rc7

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.12-rc7 with top-most commit e4330d8bf669139a983255d1801733b64c2ae841 ACPI / scan: Fix enumeration for special SPI and I2C devices on top of commit

[GIT PULL] ACPI fix for v4.12-rc7

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.12-rc7 with top-most commit e4330d8bf669139a983255d1801733b64c2ae841 ACPI / scan: Fix enumeration for special SPI and I2C devices on top of commit

[PATCH 1/2] tpm: use tpm_buf functions in tpm2_pcr_read()

tpm2_pcr_read() now builds the PCR read command buffer with tpm_buf functions. This solution is preferred to using a tpm2_cmd structure, as tpm_buf functions provide protection against buffer overflow. Signed-off-by: Roberto Sassu --- drivers/char/tpm/tpm2-cmd.c | 60

[PATCH 1/2] tpm: use tpm_buf functions in tpm2_pcr_read()

tpm2_pcr_read() now builds the PCR read command buffer with tpm_buf functions. This solution is preferred to using a tpm2_cmd structure, as tpm_buf functions provide protection against buffer overflow. Signed-off-by: Roberto Sassu --- drivers/char/tpm/tpm2-cmd.c | 60

[PATCH 0/2] Update PCR read code

This patch set updates tpm2_pcr_read(), to build the PCR read command buffer with tpm_buf functions, which offer protection against buffer overflow. It also removes duplicate code in tpm2_do_selftest(), and replaces it with a call to tpm2_pcr_read(). The previous version of the patches can be

[PATCH 0/2] Update PCR read code

This patch set updates tpm2_pcr_read(), to build the PCR read command buffer with tpm_buf functions, which offer protection against buffer overflow. It also removes duplicate code in tpm2_do_selftest(), and replaces it with a call to tpm2_pcr_read(). The previous version of the patches can be

Re: [PATCH v4] trace: ras: add ARM processor error information trace event

On Fri, 23 Jun 2017 19:13:43 +0800 Xie XiuQi wrote: > Add a new trace event for ARM processor error information, so that > the user will know what error occurred. With this information the > user may take appropriate action. > > These trace events are consistent with the

Re: [PATCH v4] trace: ras: add ARM processor error information trace event

On Fri, 23 Jun 2017 19:13:43 +0800 Xie XiuQi wrote: > Add a new trace event for ARM processor error information, so that > the user will know what error occurred. With this information the > user may take appropriate action. > > These trace events are consistent with the ARM processor error >

Re: [PATCH 0/7] drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver

On 06/22/2017 11:52 PM, Guenter Roeck wrote: On 06/22/2017 03:48 PM, Eddie James wrote: From: "Edward A. James" This series adds a hwmon driver to support the OCC on POWER8 and POWER9 processors. The OCC is an embedded processor that provides realtime power and thermal

Re: [PATCH 0/7] drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver

On 06/22/2017 11:52 PM, Guenter Roeck wrote: On 06/22/2017 03:48 PM, Eddie James wrote: From: "Edward A. James" This series adds a hwmon driver to support the OCC on POWER8 and POWER9 processors. The OCC is an embedded processor that provides realtime power and thermal monitoring and

Re: [PATCH v3 10/11] x86/mm: Enable CR4.PCIDE on supported systems

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index f33eef4ebd12..a136aac543c3 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -295,6 +295,12 @@ static void __init xen_init_capabilities(void) setup_clear_cpu_cap(X86_FEATURE_ACC);

Re: [PATCH v3 10/11] x86/mm: Enable CR4.PCIDE on supported systems

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index f33eef4ebd12..a136aac543c3 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -295,6 +295,12 @@ static void __init xen_init_capabilities(void) setup_clear_cpu_cap(X86_FEATURE_ACC);

Re: [PATCH 2/2] rt: Increase/decrease the nr of migratory tasks when enabling/disabling migration

On 06/22/2017 09:49 PM, Ingo Molnar wrote: > So AFAICS it's this block that is used twice: > + rq = task_rq_lock(p, ); + p->nr_cpus_allowed = cpumask_weight(>cpus_mask); + if (unlikely((p->sched_class == _sched_class || +p->sched_class == _sched_class) &&

Re: [PATCH 2/2] rt: Increase/decrease the nr of migratory tasks when enabling/disabling migration

On 06/22/2017 09:49 PM, Ingo Molnar wrote: > So AFAICS it's this block that is used twice: > + rq = task_rq_lock(p, ); + p->nr_cpus_allowed = cpumask_weight(>cpus_mask); + if (unlikely((p->sched_class == _sched_class || +p->sched_class == _sched_class) &&

Re: [PATCH v3 06/11] x86/mm: Rework lazy TLB mode and TLB freshness tracking

diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c index 1d7a7213a310..f5df56fb8b5c 100644 --- a/arch/x86/xen/mmu_pv.c +++ b/arch/x86/xen/mmu_pv.c @@ -1005,8 +1005,7 @@ static void xen_drop_mm_ref(struct mm_struct *mm) /* Get the "official" set of cpus referring to our

Re: [PATCH v3 06/11] x86/mm: Rework lazy TLB mode and TLB freshness tracking

diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c index 1d7a7213a310..f5df56fb8b5c 100644 --- a/arch/x86/xen/mmu_pv.c +++ b/arch/x86/xen/mmu_pv.c @@ -1005,8 +1005,7 @@ static void xen_drop_mm_ref(struct mm_struct *mm) /* Get the "official" set of cpus referring to our

Re: [patch-rt v2] rtmutex: Fix lock stealing logic

On Fri, 23 Jun 2017 09:37:14 +0200 Mike Galbraith wrote: > V2 changes: >   - beautification (ymmv) >   - enable lock stealing when waiter is queued > > rtmutex: Fix lock stealing logic > > 1. When trying to acquire an rtmutex, we first try to grab it without > queueing the

Re: [patch-rt v2] rtmutex: Fix lock stealing logic

On Fri, 23 Jun 2017 09:37:14 +0200 Mike Galbraith wrote: > V2 changes: >   - beautification (ymmv) >   - enable lock stealing when waiter is queued > > rtmutex: Fix lock stealing logic > > 1. When trying to acquire an rtmutex, we first try to grab it without > queueing the waiter, and

Re: [PATCH net-next v3 1/6] vxlan: refactor verification and application of configuration

On Fri, 2017-06-23 at 14:02 +0200, Matthias Schiffer wrote: > > It seems though that rtnl_link_ops.newlink/changelink don't allow > passing the extack yet... how do we proceed here? Treewide change > (maybe by someone who knows their Coccinelle-fu?), or would the > introduction of new versions of

Re: [PATCH net-next v3 1/6] vxlan: refactor verification and application of configuration

On Fri, 2017-06-23 at 14:02 +0200, Matthias Schiffer wrote: > > It seems though that rtnl_link_ops.newlink/changelink don't allow > passing the extack yet... how do we proceed here? Treewide change > (maybe by someone who knows their Coccinelle-fu?), or would the > introduction of new versions of

Re: Sleeping BUG in khugepaged for i586

On Fri 23-06-17 15:13:45, Vlastimil Babka wrote: > On 06/23/2017 02:08 PM, Michal Hocko wrote: > > On Thu 08-06-17 16:48:31, Michal Hocko wrote: > >> On Wed 07-06-17 13:56:01, David Rientjes wrote: > >> > >> I suspect, so cond_resched seems indeed inappropriate on 32b systems. > > > > The code

Re: Sleeping BUG in khugepaged for i586

On Fri 23-06-17 15:13:45, Vlastimil Babka wrote: > On 06/23/2017 02:08 PM, Michal Hocko wrote: > > On Thu 08-06-17 16:48:31, Michal Hocko wrote: > >> On Wed 07-06-17 13:56:01, David Rientjes wrote: > >> > >> I suspect, so cond_resched seems indeed inappropriate on 32b systems. > > > > The code

Re: [patch for-4.12] mm, thp: remove cond_resched from __collapse_huge_page_copy

On Mon 19-06-17 13:43:11, David Rientjes wrote: > This is a partial revert of commit 338a16ba1549 ("mm, thp: copying user > pages must schedule on collapse") which added a cond_resched() to > __collapse_huge_page_copy(). > > On x86 with CONFIG_HIGHPTE, __collapse_huge_page_copy is called in

Re: [patch for-4.12] mm, thp: remove cond_resched from __collapse_huge_page_copy

On Mon 19-06-17 13:43:11, David Rientjes wrote: > This is a partial revert of commit 338a16ba1549 ("mm, thp: copying user > pages must schedule on collapse") which added a cond_resched() to > __collapse_huge_page_copy(). > > On x86 with CONFIG_HIGHPTE, __collapse_huge_page_copy is called in

[PATCH v2] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

From: Rafael J. Wysocki Some recent Dell laptops, including the XPS13 model numbers 9360 and 9365, cannot be woken up from suspend-to-idle by pressing the power button which is unexpected and makes that feature less usable on those systems. Moreover, on the 9365 ACPI

[PATCH v2] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

From: Rafael J. Wysocki Some recent Dell laptops, including the XPS13 model numbers 9360 and 9365, cannot be woken up from suspend-to-idle by pressing the power button which is unexpected and makes that feature less usable on those systems. Moreover, on the 9365 ACPI S3 (suspend-to-RAM) is not

RE: New NTB API Issue

From: Logan Gunthorpe > On 6/22/2017 4:42 PM, Allen Hubbe wrote: > > From: Logan Gunthorpe > >> Any thoughts on changing the semantics of mw_get_align so it must be > >> called with the link up? > > > > The intention of these is that these calls return information from the > > local port. The

RE: New NTB API Issue

From: Logan Gunthorpe > On 6/22/2017 4:42 PM, Allen Hubbe wrote: > > From: Logan Gunthorpe > >> Any thoughts on changing the semantics of mw_get_align so it must be > >> called with the link up? > > > > The intention of these is that these calls return information from the > > local port. The

Re: [RFC 3/3] rt: Check if the task needs to migrate when re-enabling migration

On 2017-06-16 18:58:15 [+0200], To Daniel Bristot de Oliveira wrote: > Any objections? Okay, taking this for v4.9 then (mostly the same, except for one superfluous check): Subject: [PATCH] sched/migrate disable: handle updated task-mask mg-dis section If task's cpumask changes while in the task

Re: [RFC 3/3] rt: Check if the task needs to migrate when re-enabling migration

On 2017-06-16 18:58:15 [+0200], To Daniel Bristot de Oliveira wrote: > Any objections? Okay, taking this for v4.9 then (mostly the same, except for one superfluous check): Subject: [PATCH] sched/migrate disable: handle updated task-mask mg-dis section If task's cpumask changes while in the task

Re: Sleeping BUG in khugepaged for i586

On 06/23/2017 02:08 PM, Michal Hocko wrote: > On Thu 08-06-17 16:48:31, Michal Hocko wrote: >> On Wed 07-06-17 13:56:01, David Rientjes wrote: >> >> I suspect, so cond_resched seems indeed inappropriate on 32b systems. > > The code still seems to be in the mmotm tree. Even mainline at this point

Re: Sleeping BUG in khugepaged for i586

On 06/23/2017 02:08 PM, Michal Hocko wrote: > On Thu 08-06-17 16:48:31, Michal Hocko wrote: >> On Wed 07-06-17 13:56:01, David Rientjes wrote: >> >> I suspect, so cond_resched seems indeed inappropriate on 32b systems. > > The code still seems to be in the mmotm tree. Even mainline at this point

[linux-next:master 7715/9581] drivers/crypto/cavium/cpt/cptvf_algs.c:225:5: sparse: symbol 'cvm_encrypt' was not declared. Should it be static?

tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: a73468728fd8f34ccbd7c60f0808024ae491f4d6 commit: e2eb769ed0bdc06cb523f475db411ce3a5f1c465 [7715/9581] crypto: cavium - Remove the individual encrypt/decrypt function for each algorithm reproduce: #

[linux-next:master 7715/9581] drivers/crypto/cavium/cpt/cptvf_algs.c:225:5: sparse: symbol 'cvm_encrypt' was not declared. Should it be static?

tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: a73468728fd8f34ccbd7c60f0808024ae491f4d6 commit: e2eb769ed0bdc06cb523f475db411ce3a5f1c465 [7715/9581] crypto: cavium - Remove the individual encrypt/decrypt function for each algorithm reproduce: #

[RFC PATCH linux-next] crypto: cvm_encrypt() can be static

Signed-off-by: Fengguang Wu --- cptvf_algs.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.c b/drivers/crypto/cavium/cpt/cptvf_algs.c index 443c362..4303674 100644 ---

[RFC PATCH linux-next] crypto: cvm_encrypt() can be static

Signed-off-by: Fengguang Wu --- cptvf_algs.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.c b/drivers/crypto/cavium/cpt/cptvf_algs.c index 443c362..4303674 100644 --- a/drivers/crypto/cavium/cpt/cptvf_algs.c +++

Re: [PATCH] mm/page_alloc.c: eliminate unsigned confusion in __rmqueue_fallback

On 06/21/2017 08:55 PM, Rasmus Villemoes wrote: > Since current_order starts as MAX_ORDER-1 and is then only > decremented, the second half of the loop condition seems > superfluous. However, if order is 0, we may decrement current_order > past 0, making it UINT_MAX. This is obviously too subtle

Re: [PATCH] mm/page_alloc.c: eliminate unsigned confusion in __rmqueue_fallback

On 06/21/2017 08:55 PM, Rasmus Villemoes wrote: > Since current_order starts as MAX_ORDER-1 and is then only > decremented, the second half of the loop condition seems > superfluous. However, if order is 0, we may decrement current_order > past 0, making it UINT_MAX. This is obviously too subtle

[PATCH v2] PCI / PM: Avoid using device_may_wakeup() for runtime PM

From: Rafael J. Wysocki pci_target_state() calls device_may_wakeup() which checks whether or not the device may wake up the system from sleep states, but pci_target_state() is used for runtime PM too. Since runtime PM is expected to always enable remote wakeup if

[PATCH v2] PCI / PM: Avoid using device_may_wakeup() for runtime PM

From: Rafael J. Wysocki pci_target_state() calls device_may_wakeup() which checks whether or not the device may wake up the system from sleep states, but pci_target_state() is used for runtime PM too. Since runtime PM is expected to always enable remote wakeup if possible, modify

[PATCH v2 4/5] dmaengine: stm32-dma: Add support for STM32 DMAMUX

This patch adds support for STM32 DMAMUX. When the STM32 DMA controller is behind a STM32 DMAMUX the request line number has not to be handled by DMA but DMAMUX. Signed-off-by: M'boumba Cedric Madianga Signed-off-by: Pierre-Yves MORDRET ---

[PATCH v2 1/5] dt-bindings: Document the STM32 DMAMUX bindings

This patch adds the documentation of device tree bindings for the STM32 DMAMUX. Signed-off-by: M'boumba Cedric Madianga Signed-off-by: Pierre-Yves MORDRET --- Version history: v2: * Move clock bindings from optional to

[PATCH v2 4/5] dmaengine: stm32-dma: Add support for STM32 DMAMUX

This patch adds support for STM32 DMAMUX. When the STM32 DMA controller is behind a STM32 DMAMUX the request line number has not to be handled by DMA but DMAMUX. Signed-off-by: M'boumba Cedric Madianga Signed-off-by: Pierre-Yves MORDRET --- Version history: v2: * Use DMAMUX

[PATCH v2 1/5] dt-bindings: Document the STM32 DMAMUX bindings

This patch adds the documentation of device tree bindings for the STM32 DMAMUX. Signed-off-by: M'boumba Cedric Madianga Signed-off-by: Pierre-Yves MORDRET --- Version history: v2: * Move clock bindings from optional to mandatory one * Drop channelID bindings as managed

[PATCH v2 3/5] dt-bindings: stm32-dma: Add property to handle STM32 DMAMUX

This patch adds an optional property needed for STM32 DMA controller addressed via STM32 DMAMUX. Signed-off-by: M'boumba Cedric Madianga Signed-off-by: Pierre-Yves MORDRET --- Version history: v2: * Typo fix --- ---

[PATCH v2 3/5] dt-bindings: stm32-dma: Add property to handle STM32 DMAMUX

This patch adds an optional property needed for STM32 DMA controller addressed via STM32 DMAMUX. Signed-off-by: M'boumba Cedric Madianga Signed-off-by: Pierre-Yves MORDRET --- Version history: v2: * Typo fix --- --- Documentation/devicetree/bindings/dma/stm32-dma.txt | 5 - 1

[PATCH v2 0/5] Add STM32 DMAMUX support

This patchset adds support for the STM32 DMA multiplexer. It allows to map any peripheral DMA request to any channel of the product DMAs. This IP has been introduced with STM32H7 SoC. Pierre-Yves MORDRET (5): dt-bindings: Document the STM32 DMAMUX bindings dmaengine: Add STM32 DMAMUX driver

[PATCH v2 2/5] dmaengine: Add STM32 DMAMUX driver

This patch implements the STM32 DMAMUX driver. The DMAMUX request multiplexer allows routing a DMA request line between the peripherals and the DMA controllers of the product. The routing function is ensured by a programmable multi-channel DMA request line multiplexer. Each channel selects a

[RFC PATCH] pinctrl: rockchip: add irq_shutdown

Currently the rockchip pinctrl driver would try to enable/disable the gpio bank clk when enable/disable an irq. So when the irq core trying to shutdown an already disabled irq, it would result in unbalanced clk disable request: [ 35.911955] WARNING: at drivers/clk/clk.c:680 ... [ 37.272271]

[PATCH v2 0/5] Add STM32 DMAMUX support

This patchset adds support for the STM32 DMA multiplexer. It allows to map any peripheral DMA request to any channel of the product DMAs. This IP has been introduced with STM32H7 SoC. Pierre-Yves MORDRET (5): dt-bindings: Document the STM32 DMAMUX bindings dmaengine: Add STM32 DMAMUX driver

[PATCH v2 2/5] dmaengine: Add STM32 DMAMUX driver

This patch implements the STM32 DMAMUX driver. The DMAMUX request multiplexer allows routing a DMA request line between the peripherals and the DMA controllers of the product. The routing function is ensured by a programmable multi-channel DMA request line multiplexer. Each channel selects a

[RFC PATCH] pinctrl: rockchip: add irq_shutdown

Currently the rockchip pinctrl driver would try to enable/disable the gpio bank clk when enable/disable an irq. So when the irq core trying to shutdown an already disabled irq, it would result in unbalanced clk disable request: [ 35.911955] WARNING: at drivers/clk/clk.c:680 ... [ 37.272271]

[PATCH v2 5/5] ARM: configs: stm32: Add DMAMUX support in STM32 defconfig

This patch adds DMAMUX support in STM32 defconfig file Signed-off-by: M'boumba Cedric Madianga Signed-off-by: Pierre-Yves MORDRET --- Version history: v2: None --- --- arch/arm/configs/stm32_defconfig | 1 + 1 file changed, 1

[PATCH v2 5/5] ARM: configs: stm32: Add DMAMUX support in STM32 defconfig

This patch adds DMAMUX support in STM32 defconfig file Signed-off-by: M'boumba Cedric Madianga Signed-off-by: Pierre-Yves MORDRET --- Version history: v2: None --- --- arch/arm/configs/stm32_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/stm32_defconfig

Re: [PATCH v2 08/15] [media] cxd2880: Add top level of the driver

Em Mon, 19 Jun 2017 16:56:13 +0900 "Takiguchi, Yasunari" escreveu: > >> +static int cxd2880_get_frontend_t(struct dvb_frontend *fe, > >> + struct dtv_frontend_properties *c) > >> +{ > >> + enum cxd2880_ret ret = CXD2880_RESULT_OK; > >> +

Re: [PATCH v2 08/15] [media] cxd2880: Add top level of the driver

Em Mon, 19 Jun 2017 16:56:13 +0900 "Takiguchi, Yasunari" escreveu: > >> +static int cxd2880_get_frontend_t(struct dvb_frontend *fe, > >> + struct dtv_frontend_properties *c) > >> +{ > >> + enum cxd2880_ret ret = CXD2880_RESULT_OK; > >> + int result = 0; > >> + struct

[PATCH v6 2/3] perf: cavium: Support transmit-link PMU counters

Add support for the transmit-link (OCX TLK) PMU counters found on Caviums SOCs with a processor interconnect. Properties of the OCX TLK counters: - per-unit control - fixed purpose - writable - one PCI device with multiple TLK units Signed-off-by: Jan Glauber ---

[PATCH v6 3/3] perf: cavium: Add Documentation

Document Cavium SoC PMUs. Signed-off-by: Jan Glauber --- Documentation/perf/cavium-pmu.txt | 74 +++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/perf/cavium-pmu.txt diff --git a/Documentation/perf/cavium-pmu.txt

[PATCH v6 2/3] perf: cavium: Support transmit-link PMU counters

Add support for the transmit-link (OCX TLK) PMU counters found on Caviums SOCs with a processor interconnect. Properties of the OCX TLK counters: - per-unit control - fixed purpose - writable - one PCI device with multiple TLK units Signed-off-by: Jan Glauber --- drivers/edac/thunderx_edac.c

[PATCH v6 3/3] perf: cavium: Add Documentation

Document Cavium SoC PMUs. Signed-off-by: Jan Glauber --- Documentation/perf/cavium-pmu.txt | 74 +++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/perf/cavium-pmu.txt diff --git a/Documentation/perf/cavium-pmu.txt

Re: [PATCH v2 2/2] smartpqi: limit transfer length to 1MB

On Fri, Jun 23, 2017 at 05:40:06PM +0800, Yadan Fan wrote: > The smartpqi firmware will bypass the cache for any request larger > than 1MB, so we should cap the request size to avoid any > performance degradation in kernels later than v4.3 > > This degradation is caused from

[PATCH v6 0/3] Cavium ARM64 uncore PMU support

Add support for various PMU counters found on the Cavium ThunderX and OcteonTx SoC. The driver provides common "uncore" functions to avoid code duplication and support adding more device PMUs (like L2 cache) in the future. Probe and removal of the PMUs is done by hooking into the ThunderX EDAC

Re: [PATCH v2 2/2] smartpqi: limit transfer length to 1MB

On Fri, Jun 23, 2017 at 05:40:06PM +0800, Yadan Fan wrote: > The smartpqi firmware will bypass the cache for any request larger > than 1MB, so we should cap the request size to avoid any > performance degradation in kernels later than v4.3 > > This degradation is caused from

[PATCH v6 0/3] Cavium ARM64 uncore PMU support

Add support for various PMU counters found on the Cavium ThunderX and OcteonTx SoC. The driver provides common "uncore" functions to avoid code duplication and support adding more device PMUs (like L2 cache) in the future. Probe and removal of the PMUs is done by hooking into the ThunderX EDAC

[PATCH v6 1/3] perf: cavium: Support memory controller PMU counters

Add support for the PMU counters on Cavium SOC memory controllers. This patch also adds generic functions to allow supporting more devices with PMU counters. Properties of the LMC PMU counters: - not stoppable - fixed purpose - read-only - one PCI device per memory controller Signed-off-by: Jan

[PATCH v6 1/3] perf: cavium: Support memory controller PMU counters

Add support for the PMU counters on Cavium SOC memory controllers. This patch also adds generic functions to allow supporting more devices with PMU counters. Properties of the LMC PMU counters: - not stoppable - fixed purpose - read-only - one PCI device per memory controller Signed-off-by: Jan

Re: [PATCH v2 1/2] hpsa: limit transfer length to 1MB

On Fri, Jun 23, 2017 at 05:40:05PM +0800, Yadan Fan wrote: > The hpsa firmware will bypass the cache for any request larger > than 1MB, so we should cap the request size to avoid any > performance degradation in kernels later than v4.3 > > This degradation is caused from

Re: [PATCH v2 1/2] hpsa: limit transfer length to 1MB

On Fri, Jun 23, 2017 at 05:40:05PM +0800, Yadan Fan wrote: > The hpsa firmware will bypass the cache for any request larger > than 1MB, so we should cap the request size to avoid any > performance degradation in kernels later than v4.3 > > This degradation is caused from

[PATCH 0/8] STM32 SPI various fixes

This patchset answers to the reviews done after STM32 SPI driver introduction. Amelie Delaunay (8): dt-bindings: spi: stm32: use SoC specific compatible spi: stm32: fix compatible to fit with new bindings dt-bindings: spi: stm32: fix example with st,spi-midi-ns property spi: stm32:

[PATCH 0/8] STM32 SPI various fixes

This patchset answers to the reviews done after STM32 SPI driver introduction. Amelie Delaunay (8): dt-bindings: spi: stm32: use SoC specific compatible spi: stm32: fix compatible to fit with new bindings dt-bindings: spi: stm32: fix example with st,spi-midi-ns property spi: stm32:

[PATCH 2/8] spi: stm32: fix compatible to fit with new bindings

This patch updates of_device_id compatible string to fit with new bindings. Signed-off-by: Amelie Delaunay --- drivers/spi/spi-stm32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c index

[PATCH v2] iio: adc: at91-sama5d2_adc: add support for suspend/resume functionality

Added support for suspend/resume functionality for the ADC IP in sama5d2 SoC. In order to enter Suspend to ram mode (backup + self refresh mode for memory), in which the ADC IP is no longer powered, we need to reset the pins to default state, for the scenario when they are also used for I2C bus to

[PATCH 2/8] spi: stm32: fix compatible to fit with new bindings

This patch updates of_device_id compatible string to fit with new bindings. Signed-off-by: Amelie Delaunay --- drivers/spi/spi-stm32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c index 82a6616f..ca38c24 100644 ---

[PATCH v2] iio: adc: at91-sama5d2_adc: add support for suspend/resume functionality

Added support for suspend/resume functionality for the ADC IP in sama5d2 SoC. In order to enter Suspend to ram mode (backup + self refresh mode for memory), in which the ADC IP is no longer powered, we need to reset the pins to default state, for the scenario when they are also used for I2C bus to

[PATCH 4/8] spi: stm32: replace st,spi-midi with st,spi-midi-ns to fit bindings

This patch fixes the optional dt property used to set master inter-data idleness. Signed-off-by: Amelie Delaunay --- drivers/spi/spi-stm32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c index

[PATCH 4/8] spi: stm32: replace st,spi-midi with st,spi-midi-ns to fit bindings

This patch fixes the optional dt property used to set master inter-data idleness. Signed-off-by: Amelie Delaunay --- drivers/spi/spi-stm32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c index ca38c24..0997d6d 100644 ---

[PATCH 5/8] spi: stm32: use normal conditional statements instead of ternary operator

This patch replace ternary operator use by normal condition statements to ease code reading. It also removes redundant !!. Signed-off-by: Amelie Delaunay --- drivers/spi/spi-stm32.c | 44 ++-- 1 file changed, 30 insertions(+), 14

[PATCH 5/8] spi: stm32: use normal conditional statements instead of ternary operator

This patch replace ternary operator use by normal condition statements to ease code reading. It also removes redundant !!. Signed-off-by: Amelie Delaunay --- drivers/spi/spi-stm32.c | 44 ++-- 1 file changed, 30 insertions(+), 14 deletions(-) diff --git

[PATCH 3/8] dt-bindings: spi: stm32: fix example with st,spi-midi-ns property

This patch aligns example with the optional property description. Signed-off-by: Amelie Delaunay --- Documentation/devicetree/bindings/spi/spi-stm32.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 3/8] dt-bindings: spi: stm32: fix example with st,spi-midi-ns property

This patch aligns example with the optional property description. Signed-off-by: Amelie Delaunay --- Documentation/devicetree/bindings/spi/spi-stm32.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/spi/spi-stm32.txt

[PATCH 1/8] dt-bindings: spi: stm32: use SoC specific compatible

This patch replaces st,stm32-spi compatible with st,stm32h7-spi SoC specific compatible and updates the example accondingly. Signed-off-by: Amelie Delaunay --- Documentation/devicetree/bindings/spi/spi-stm32.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH 1/8] dt-bindings: spi: stm32: use SoC specific compatible

This patch replaces st,stm32-spi compatible with st,stm32h7-spi SoC specific compatible and updates the example accondingly. Signed-off-by: Amelie Delaunay --- Documentation/devicetree/bindings/spi/spi-stm32.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 7/8] spi: stm32: enhance DMA error management

This patch reworks DMA error management. In case the DMA callback is called while EOT (End Of Transfer) flag is not set, that means that DMA encountered an error. This error will result in an auto-suspend of SPI flow, which could also result in an overrun. So, in DMA mode, SUSP and OVR flags are a

[PATCH 7/8] spi: stm32: enhance DMA error management

This patch reworks DMA error management. In case the DMA callback is called while EOT (End Of Transfer) flag is not set, that means that DMA encountered an error. This error will result in an auto-suspend of SPI flow, which could also result in an overrun. So, in DMA mode, SUSP and OVR flags are a

<    5   6   7   8   9   10   11   12   13   14   >