[PATCH 25/44] arm: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c| 13 +--- arch/arm/include/asm/dma-iommu.h | 2 ++ arch/arm/include/asm/dma-mapping.h | 1 - arch/arm/mm/dma-mapping.c | 41

[PATCH 25/44] arm: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c| 13 +--- arch/arm/include/asm/dma-iommu.h | 2 ++ arch/arm/include/asm/dma-mapping.h | 1 - arch/arm/mm/dma-mapping.c | 41

[PATCH 26/44] dma-mapping: remove DMA_ERROR_CODE

And update the documentation - dma_mapping_error has been supported everywhere for a long time. Signed-off-by: Christoph Hellwig --- Documentation/DMA-API-HOWTO.txt | 31 +-- include/linux/dma-mapping.h | 5 - 2 files changed, 5 insertions(+),

[PATCH 26/44] dma-mapping: remove DMA_ERROR_CODE

And update the documentation - dma_mapping_error has been supported everywhere for a long time. Signed-off-by: Christoph Hellwig --- Documentation/DMA-API-HOWTO.txt | 31 +-- include/linux/dma-mapping.h | 5 - 2 files changed, 5 insertions(+), 31

[PATCH 29/44] dma-noop: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- lib/dma-noop.c | 12 1 file changed, 12 deletions(-) diff --git a/lib/dma-noop.c b/lib/dma-noop.c index de26c8b68f34..643a074f139d 100644 --- a/lib/dma-noop.c +++

[PATCH 28/44] sparc: remove arch specific dma_supported implementations

Usually dma_supported decisions are done by the dma_map_ops instance. Switch sparc to that model by providing a ->dma_supported instance for sbus that always returns false, and implementations tailored to the sun4u and sun4v cases for sparc64, and leave it unimplemented for PCI on sparc32, which

[PATCH 29/44] dma-noop: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- lib/dma-noop.c | 12 1 file changed, 12 deletions(-) diff --git a/lib/dma-noop.c b/lib/dma-noop.c index de26c8b68f34..643a074f139d 100644 --- a/lib/dma-noop.c +++

[PATCH 28/44] sparc: remove arch specific dma_supported implementations

Usually dma_supported decisions are done by the dma_map_ops instance. Switch sparc to that model by providing a ->dma_supported instance for sbus that always returns false, and implementations tailored to the sun4u and sun4v cases for sparc64, and leave it unimplemented for PCI on sparc32, which

[PATCH 30/44] dma-virt: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- lib/dma-virt.c | 12 1 file changed, 12 deletions(-) diff --git a/lib/dma-virt.c b/lib/dma-virt.c index dcd4df1f7174..5c4f11329721 100644 --- a/lib/dma-virt.c +++

[PATCH 27/44] sparc: remove leon_dma_ops

We can just use pci32_dma_ops directly. Signed-off-by: Christoph Hellwig Acked-by: David S. Miller --- arch/sparc/include/asm/dma-mapping.h | 3 +-- arch/sparc/kernel/ioport.c | 5 + 2 files changed, 2 insertions(+), 6 deletions(-) diff --git

[PATCH 30/44] dma-virt: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- lib/dma-virt.c | 12 1 file changed, 12 deletions(-) diff --git a/lib/dma-virt.c b/lib/dma-virt.c index dcd4df1f7174..5c4f11329721 100644 --- a/lib/dma-virt.c +++

[PATCH 27/44] sparc: remove leon_dma_ops

We can just use pci32_dma_ops directly. Signed-off-by: Christoph Hellwig Acked-by: David S. Miller --- arch/sparc/include/asm/dma-mapping.h | 3 +-- arch/sparc/kernel/ioport.c | 5 + 2 files changed, 2 insertions(+), 6 deletions(-) diff --git

[PATCH 31/44] hexagon: remove arch-specific dma_supported implementation

This implementation is simply bogus - hexagon only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig Acked-by: Richard Kuo --- arch/hexagon/include/asm/dma-mapping.h | 2 --

[PATCH 31/44] hexagon: remove arch-specific dma_supported implementation

This implementation is simply bogus - hexagon only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig Acked-by: Richard Kuo --- arch/hexagon/include/asm/dma-mapping.h | 2 -- arch/hexagon/kernel/dma.c | 9

[PATCH 34/44] arm: remove arch specific dma_supported implementation

And instead wire it up as method for all the dma_map_ops instances. Note that the code seems a little fishy for dmabounce and iommu, but for now I'd like to preserve the existing behavior 1:1. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c| 1 +

[PATCH 34/44] arm: remove arch specific dma_supported implementation

And instead wire it up as method for all the dma_map_ops instances. Note that the code seems a little fishy for dmabounce and iommu, but for now I'd like to preserve the existing behavior 1:1. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c| 1 +

[PATCH 33/44] openrisc: remove arch-specific dma_supported implementation

This implementation is simply bogus - openrisc only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig --- arch/openrisc/include/asm/dma-mapping.h | 7 --- 1 file changed, 7 deletions(-) diff --git

[PATCH 32/44] hexagon: remove the unused dma_is_consistent prototype

Signed-off-by: Christoph Hellwig --- arch/hexagon/include/asm/dma-mapping.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/hexagon/include/asm/dma-mapping.h b/arch/hexagon/include/asm/dma-mapping.h index 9c15cb5271a6..463dbc18f853 100644 ---

[PATCH 33/44] openrisc: remove arch-specific dma_supported implementation

This implementation is simply bogus - openrisc only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig --- arch/openrisc/include/asm/dma-mapping.h | 7 --- 1 file changed, 7 deletions(-) diff --git

[PATCH 32/44] hexagon: remove the unused dma_is_consistent prototype

Signed-off-by: Christoph Hellwig --- arch/hexagon/include/asm/dma-mapping.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/hexagon/include/asm/dma-mapping.h b/arch/hexagon/include/asm/dma-mapping.h index 9c15cb5271a6..463dbc18f853 100644 --- a/arch/hexagon/include/asm/dma-mapping.h +++

[PATCH 38/44] arm: implement ->dma_supported instead of ->set_dma_mask

Same behavior, less code duplication. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c index 6ecd5be5d37e..9a92de63426f 100644 ---

[PATCH 38/44] arm: implement ->dma_supported instead of ->set_dma_mask

Same behavior, less code duplication. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c index 6ecd5be5d37e..9a92de63426f 100644 ---

[PATCH 36/44] dma-mapping: remove HAVE_ARCH_DMA_SUPPORTED

Signed-off-by: Christoph Hellwig --- include/linux/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index a57875309bfd..3e5908656226 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h

[PATCH 36/44] dma-mapping: remove HAVE_ARCH_DMA_SUPPORTED

Signed-off-by: Christoph Hellwig --- include/linux/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index a57875309bfd..3e5908656226 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -549,7

[PATCH 35/44] x86: remove arch specific dma_supported implementation

And instead wire it up as method for all the dma_map_ops instances. Note that this also means the arch specific check will be fully instead of partially applied in the AMD iommu driver. Signed-off-by: Christoph Hellwig --- arch/x86/include/asm/dma-mapping.h | 3 ---

[PATCH 35/44] x86: remove arch specific dma_supported implementation

And instead wire it up as method for all the dma_map_ops instances. Note that this also means the arch specific check will be fully instead of partially applied in the AMD iommu driver. Signed-off-by: Christoph Hellwig --- arch/x86/include/asm/dma-mapping.h | 3 ---

[PATCH 37/44] mips/loongson64: implement ->dma_supported instead of ->set_dma_mask

Same behavior, less code duplication. Signed-off-by: Christoph Hellwig --- arch/mips/loongson64/common/dma-swiotlb.c | 19 +-- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/arch/mips/loongson64/common/dma-swiotlb.c

[PATCH 37/44] mips/loongson64: implement ->dma_supported instead of ->set_dma_mask

Same behavior, less code duplication. Signed-off-by: Christoph Hellwig --- arch/mips/loongson64/common/dma-swiotlb.c | 19 +-- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/arch/mips/loongson64/common/dma-swiotlb.c b/arch/mips/loongson64/common/dma-swiotlb.c

[PATCH 40/44] tile: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- arch/tile/kernel/pci-dma.c | 30 -- 1 file changed, 30 deletions(-) diff --git a/arch/tile/kernel/pci-dma.c b/arch/tile/kernel/pci-dma.c index

[PATCH 42/44] powerpc/cell: use the dma_supported method for ops switching

Besides removing the last instance of the set_dma_mask method this also reduced the code duplication. Signed-off-by: Christoph Hellwig --- arch/powerpc/platforms/cell/iommu.c | 25 + 1 file changed, 9 insertions(+), 16 deletions(-) diff --git

[PATCH 40/44] tile: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- arch/tile/kernel/pci-dma.c | 30 -- 1 file changed, 30 deletions(-) diff --git a/arch/tile/kernel/pci-dma.c b/arch/tile/kernel/pci-dma.c index

[PATCH 42/44] powerpc/cell: use the dma_supported method for ops switching

Besides removing the last instance of the set_dma_mask method this also reduced the code duplication. Signed-off-by: Christoph Hellwig --- arch/powerpc/platforms/cell/iommu.c | 25 + 1 file changed, 9 insertions(+), 16 deletions(-) diff --git

[PATCH 43/44] dma-mapping: remove the set_dma_mask method

Signed-off-by: Christoph Hellwig --- arch/powerpc/kernel/dma.c | 4 include/linux/dma-mapping.h | 6 -- 2 files changed, 10 deletions(-) diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c index 41c749586bd2..466c9f07b288 100644 ---

[PATCH 43/44] dma-mapping: remove the set_dma_mask method

Signed-off-by: Christoph Hellwig --- arch/powerpc/kernel/dma.c | 4 include/linux/dma-mapping.h | 6 -- 2 files changed, 10 deletions(-) diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c index 41c749586bd2..466c9f07b288 100644 --- a/arch/powerpc/kernel/dma.c +++

[PATCH 2/2] ALSA:line6: remove unnecessary initialization to PODHD500X.

Body: Remove Initialization from POD HD500X because it's not needed. Every time the device is connected dmesg gives the following output: "receive length failed (error -11)". To solve this problem, another flags is introduced (LINE6_CAP_CONTROL_INFO) and it is only used for PODX3 in: sysfs

[PATCH 2/2] ALSA:line6: remove unnecessary initialization to PODHD500X.

Body: Remove Initialization from POD HD500X because it's not needed. Every time the device is connected dmesg gives the following output: "receive length failed (error -11)". To solve this problem, another flags is introduced (LINE6_CAP_CONTROL_INFO) and it is only used for PODX3 in: sysfs

[PATCH 1/2] ALSA: line6: add support for POD HD500X

Add support for the Line6 POD HD500X multi effect processor for playback and capture (in/out audio) through USB. Signed-off-by: Hans P. Moller --- sound/usb/line6/podhd.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git

[PATCH 1/2] ALSA: line6: add support for POD HD500X

Add support for the Line6 POD HD500X multi effect processor for playback and capture (in/out audio) through USB. Signed-off-by: Hans P. Moller --- sound/usb/line6/podhd.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/sound/usb/line6/podhd.c

[PATCH 41/44] powerpc/cell: clean up fixed mapping dma_ops initialization

By the time cell_pci_dma_dev_setup calls cell_dma_dev_setup no device can have the fixed map_ops set yet as it's only set by the set_dma_mask method. So move the setup for the fixed case to be only called in that place instead of indirecting through cell_dma_dev_setup. Signed-off-by: Christoph

[PATCH 41/44] powerpc/cell: clean up fixed mapping dma_ops initialization

By the time cell_pci_dma_dev_setup calls cell_dma_dev_setup no device can have the fixed map_ops set yet as it's only set by the set_dma_mask method. So move the setup for the fixed case to be only called in that place instead of indirecting through cell_dma_dev_setup. Signed-off-by: Christoph

[PATCH v1] uuid: Take const on input of uuid_is_null() and guid_is_null()

The null check functions do not and must not modify contents of the UUID or GUID supplied. Mark argument explicitly to reflect that. Signed-off-by: Andy Shevchenko --- include/linux/uuid.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 44/44] powerpc: merge __dma_set_mask into dma_set_mask

Signed-off-by: Christoph Hellwig --- arch/powerpc/include/asm/dma-mapping.h | 1 - arch/powerpc/kernel/dma.c | 13 - 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/include/asm/dma-mapping.h

[PATCH v1] uuid: Take const on input of uuid_is_null() and guid_is_null()

The null check functions do not and must not modify contents of the UUID or GUID supplied. Mark argument explicitly to reflect that. Signed-off-by: Andy Shevchenko --- include/linux/uuid.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/uuid.h

[PATCH 44/44] powerpc: merge __dma_set_mask into dma_set_mask

Signed-off-by: Christoph Hellwig --- arch/powerpc/include/asm/dma-mapping.h | 1 - arch/powerpc/kernel/dma.c | 13 - 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h index

[PATCH 39/44] xen-swiotlb: remove xen_swiotlb_set_dma_mask

This just duplicates the generic implementation. Signed-off-by: Christoph Hellwig --- drivers/xen/swiotlb-xen.c | 12 1 file changed, 12 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index c3a04b2d7532..82fc54f8eb77 100644 ---

[PATCH 39/44] xen-swiotlb: remove xen_swiotlb_set_dma_mask

This just duplicates the generic implementation. Signed-off-by: Christoph Hellwig --- drivers/xen/swiotlb-xen.c | 12 1 file changed, 12 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index c3a04b2d7532..82fc54f8eb77 100644 ---

[PATCH 24/44] x86: remove DMA_ERROR_CODE

All dma_map_ops instances now handle their errors through ->mapping_error. Signed-off-by: Christoph Hellwig --- arch/x86/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h index

[PATCH 24/44] x86: remove DMA_ERROR_CODE

All dma_map_ops instances now handle their errors through ->mapping_error. Signed-off-by: Christoph Hellwig --- arch/x86/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h index

[PATCH 17/44] hexagon: switch to use ->mapping_error for error reporting

Signed-off-by: Christoph Hellwig Acked-by: Richard Kuo --- arch/hexagon/include/asm/dma-mapping.h | 2 -- arch/hexagon/kernel/dma.c | 12 +--- arch/hexagon/kernel/hexagon_ksyms.c| 1 - 3 files changed, 9 insertions(+), 6 deletions(-)

[PATCH 17/44] hexagon: switch to use ->mapping_error for error reporting

Signed-off-by: Christoph Hellwig Acked-by: Richard Kuo --- arch/hexagon/include/asm/dma-mapping.h | 2 -- arch/hexagon/kernel/dma.c | 12 +--- arch/hexagon/kernel/hexagon_ksyms.c| 1 - 3 files changed, 9 insertions(+), 6 deletions(-) diff --git

Re: [PATCH] staging: fusb302: don't bitshift __le16 type

On Fri, Jun 16, 2017 at 07:45:56PM +0200, Frans Klaver wrote: > The header field in struct pd_message is declared as an __le16 type. The > data in the message is supposed to be little endian. This means we don't > have to go and shift the individual bytes into position when we're > filling the

Re: [PATCH] staging: fusb302: don't bitshift __le16 type

On Fri, Jun 16, 2017 at 07:45:56PM +0200, Frans Klaver wrote: > The header field in struct pd_message is declared as an __le16 type. The > data in the message is supposed to be little endian. This means we don't > have to go and shift the individual bytes into position when we're > filling the

clean up and modularize arch dma_mapping interface V2

Hi all, for a while we have a generic implementation of the dma mapping routines that call into per-arch or per-device operations. But right now there still are various bits in the interfaces where don't clearly operate on these ops. This series tries to clean up a lot of those (but not all

[PATCH 02/44] ibmveth: properly unwind on init errors

That way the driver doesn't have to rely on DMA_ERROR_CODE, which is not a public API and going away. Signed-off-by: Christoph Hellwig Acked-by: David S. Miller --- drivers/net/ethernet/ibm/ibmveth.c | 159 + 1 file changed,

clean up and modularize arch dma_mapping interface V2

Hi all, for a while we have a generic implementation of the dma mapping routines that call into per-arch or per-device operations. But right now there still are various bits in the interfaces where don't clearly operate on these ops. This series tries to clean up a lot of those (but not all

[PATCH 02/44] ibmveth: properly unwind on init errors

That way the driver doesn't have to rely on DMA_ERROR_CODE, which is not a public API and going away. Signed-off-by: Christoph Hellwig Acked-by: David S. Miller --- drivers/net/ethernet/ibm/ibmveth.c | 159 + 1 file changed, 74 insertions(+), 85 deletions(-)

RE: [RFC PATCH 00/13] Switchtec NTB Support

From: Logan Gunthorpe > On 16/06/17 09:34 AM, Allen Hubbe wrote: > > In code review, I really only have found minor nits. Overall, the driver > > looks good. > > Great, thanks for such a quick review! > > > In switchtec_ntb_part_op, there is a delay of up to 50s (1000 * 50ms). > > This looks

RE: [RFC PATCH 00/13] Switchtec NTB Support

From: Logan Gunthorpe > On 16/06/17 09:34 AM, Allen Hubbe wrote: > > In code review, I really only have found minor nits. Overall, the driver > > looks good. > > Great, thanks for such a quick review! > > > In switchtec_ntb_part_op, there is a delay of up to 50s (1000 * 50ms). > > This looks

Re: [HMM 00/15] HMM (Heterogeneous Memory Management) v23

On Fri, Jun 16, 2017 at 05:55:52PM +, Bridgman, John wrote: > >-Original Message- > >From: Jerome Glisse [mailto:jgli...@redhat.com] > >Sent: Friday, June 16, 2017 10:48 AM > >To: Bridgman, John > >Cc: a...@linux-foundation.org; linux-kernel@vger.kernel.org; linux- > >m...@kvack.org;

Re: [HMM 00/15] HMM (Heterogeneous Memory Management) v23

On Fri, Jun 16, 2017 at 05:55:52PM +, Bridgman, John wrote: > >-Original Message- > >From: Jerome Glisse [mailto:jgli...@redhat.com] > >Sent: Friday, June 16, 2017 10:48 AM > >To: Bridgman, John > >Cc: a...@linux-foundation.org; linux-kernel@vger.kernel.org; linux- > >m...@kvack.org;

Re: xgetbv nondeterminism

On Fri, Jun 16, 2017 at 10:56 AM, Andy Lutomirski wrote: > On Fri, Jun 16, 2017 at 10:44 AM, H.J. Lu wrote: >> On Fri, Jun 16, 2017 at 9:38 AM, Andy Lutomirski wrote: >>> On Fri, Jun 16, 2017 at 9:17 AM, H.J. Lu wrote:

Re: xgetbv nondeterminism

On Fri, Jun 16, 2017 at 10:56 AM, Andy Lutomirski wrote: > On Fri, Jun 16, 2017 at 10:44 AM, H.J. Lu wrote: >> On Fri, Jun 16, 2017 at 9:38 AM, Andy Lutomirski wrote: >>> On Fri, Jun 16, 2017 at 9:17 AM, H.J. Lu wrote: On Fri, Jun 16, 2017 at 9:01 AM, Andy Lutomirski wrote: > On Thu,

Re: [PATCH 2/2] drm/vc4: Add get/set tiling ioctls.

Daniel Stone writes: > On 13 June 2017 at 16:49, Eric Anholt wrote: >> Daniel Stone writes: >>> I posted a DRI3 v1.1 patch series which can advertise and also transit >>> modifiers directly under X11, and have also typed up the

Re: [PATCH 2/2] drm/vc4: Add get/set tiling ioctls.

Daniel Stone writes: > On 13 June 2017 at 16:49, Eric Anholt wrote: >> Daniel Stone writes: >>> I posted a DRI3 v1.1 patch series which can advertise and also transit >>> modifiers directly under X11, and have also typed up the support for >>> Wayland which is working just fine with Weston

Re: xgetbv nondeterminism

On Fri, Jun 16, 2017 at 10:44 AM, H.J. Lu wrote: > On Fri, Jun 16, 2017 at 9:38 AM, Andy Lutomirski wrote: >> On Fri, Jun 16, 2017 at 9:17 AM, H.J. Lu wrote: >>> On Fri, Jun 16, 2017 at 9:01 AM, Andy Lutomirski wrote:

Re: xgetbv nondeterminism

On Fri, Jun 16, 2017 at 10:44 AM, H.J. Lu wrote: > On Fri, Jun 16, 2017 at 9:38 AM, Andy Lutomirski wrote: >> On Fri, Jun 16, 2017 at 9:17 AM, H.J. Lu wrote: >>> On Fri, Jun 16, 2017 at 9:01 AM, Andy Lutomirski wrote: On Thu, Jun 15, 2017 at 9:34 PM, H.J. Lu wrote: > On Thu, Jun 15,

Applied "ASoC: stm32: sai: remove spurious trace" to the asoc tree

The patch ASoC: stm32: sai: remove spurious trace has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "ASoC: stm32: sai: remove spurious trace" to the asoc tree

The patch ASoC: stm32: sai: remove spurious trace has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "ASoC: stm32: sai: typo fixes" to the asoc tree

The patch ASoC: stm32: sai: typo fixes has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the

Re: [PATCH 2/7] ASoC: stm32: change SAI configuration flag

On Fri, Jun 16, 2017 at 02:15:29PM +0200, olivier moysan wrote: > Use a specific flag for SAI interface instead > of common stm32 asoc flag. This doesn't apply against current code, please check and resend. signature.asc Description: PGP signature

Applied "ASoC: stm32: sai: typo fixes" to the asoc tree

The patch ASoC: stm32: sai: typo fixes has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the

Re: [PATCH 2/7] ASoC: stm32: change SAI configuration flag

On Fri, Jun 16, 2017 at 02:15:29PM +0200, olivier moysan wrote: > Use a specific flag for SAI interface instead > of common stm32 asoc flag. This doesn't apply against current code, please check and resend. signature.asc Description: PGP signature

RE: [HMM 00/15] HMM (Heterogeneous Memory Management) v23

>-Original Message- >From: Jerome Glisse [mailto:jgli...@redhat.com] >Sent: Friday, June 16, 2017 10:48 AM >To: Bridgman, John >Cc: a...@linux-foundation.org; linux-kernel@vger.kernel.org; linux- >m...@kvack.org; Dan Williams; Kirill A . Shutemov; John Hubbard; Sander, Ben; >Kuehling,

RE: [HMM 00/15] HMM (Heterogeneous Memory Management) v23

>-Original Message- >From: Jerome Glisse [mailto:jgli...@redhat.com] >Sent: Friday, June 16, 2017 10:48 AM >To: Bridgman, John >Cc: a...@linux-foundation.org; linux-kernel@vger.kernel.org; linux- >m...@kvack.org; Dan Williams; Kirill A . Shutemov; John Hubbard; Sander, Ben; >Kuehling,

Applied "ASoC: stm32: sai: manage master clock" to the asoc tree

The patch ASoC: stm32: sai: manage master clock has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "ASoC: stm32: sai: manage master clock" to the asoc tree

The patch ASoC: stm32: sai: manage master clock has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

[RFC v5 01/11] mm: Dont assume page-table invariance during faults

From: Peter Zijlstra One of the side effects of speculating on faults (without holding mmap_sem) is that we can race with free_pgtables() and therefore we cannot assume the page-tables will stick around. Remove the relyance on the pte pointer. Signed-off-by: Peter

[RFC v5 01/11] mm: Dont assume page-table invariance during faults

From: Peter Zijlstra One of the side effects of speculating on faults (without holding mmap_sem) is that we can race with free_pgtables() and therefore we cannot assume the page-tables will stick around. Remove the relyance on the pte pointer. Signed-off-by: Peter Zijlstra (Intel) ---

[RFC v5 04/11] mm: VMA sequence count

From: Peter Zijlstra Wrap the VMA modifications (vma_adjust/unmap_page_range) with sequence counts such that we can easily test if a VMA is changed. The unmap_page_range() one allows us to make assumptions about page-tables; when we find the seqcount hasn't changed we can

[RFC v5 04/11] mm: VMA sequence count

From: Peter Zijlstra Wrap the VMA modifications (vma_adjust/unmap_page_range) with sequence counts such that we can easily test if a VMA is changed. The unmap_page_range() one allows us to make assumptions about page-tables; when we find the seqcount hasn't changed we can assume page-tables are

[RFC v5 02/11] mm: Prepare for FAULT_FLAG_SPECULATIVE

From: Peter Zijlstra When speculating faults (without holding mmap_sem) we need to validate that the vma against which we loaded pages is still valid when we're ready to install the new PTE. Therefore, replace the pte_offset_map_lock() calls that (re)take the PTL with

[RFC v5 02/11] mm: Prepare for FAULT_FLAG_SPECULATIVE

From: Peter Zijlstra When speculating faults (without holding mmap_sem) we need to validate that the vma against which we loaded pages is still valid when we're ready to install the new PTE. Therefore, replace the pte_offset_map_lock() calls that (re)take the PTL with pte_map_lock() which can

[RFC v5 05/11] mm: fix lock dependency against mapping->i_mmap_rwsem

kworker/32:1/819 is trying to acquire lock: (>vm_sequence){+.+...}, at: [] zap_page_range_single+0xd0/0x1a0 but task is already holding lock: (>i_mmap_rwsem){..}, at: [] unmap_mapping_range+0x7c/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse

[RFC v5 06/11] mm: Protect VMA modifications using VMA sequence count

The VMA sequence count has been introduced to allow fast detection of VMA modification when running a page fault handler without holding the mmap_sem. This patch provides protection agains the VMA modification done in : - madvise() - mremap() - mpol_rebind_policy()

[RFC v5 05/11] mm: fix lock dependency against mapping->i_mmap_rwsem

kworker/32:1/819 is trying to acquire lock: (>vm_sequence){+.+...}, at: [] zap_page_range_single+0xd0/0x1a0 but task is already holding lock: (>i_mmap_rwsem){..}, at: [] unmap_mapping_range+0x7c/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse

[RFC v5 06/11] mm: Protect VMA modifications using VMA sequence count

The VMA sequence count has been introduced to allow fast detection of VMA modification when running a page fault handler without holding the mmap_sem. This patch provides protection agains the VMA modification done in : - madvise() - mremap() - mpol_rebind_policy()

[RFC v5 07/11] mm: RCU free VMAs

From: Peter Zijlstra Manage the VMAs with SRCU such that we can do a lockless VMA lookup. We put the fput(vma->vm_file) in the SRCU callback, this keeps files valid during speculative faults, this is possible due to the delayed fput work by Al Viro -- do we need

[RFC v5 07/11] mm: RCU free VMAs

From: Peter Zijlstra Manage the VMAs with SRCU such that we can do a lockless VMA lookup. We put the fput(vma->vm_file) in the SRCU callback, this keeps files valid during speculative faults, this is possible due to the delayed fput work by Al Viro -- do we need srcu_barrier() in unmount

[RFC v5 11/11] powerpc/mm: Add speculative page fault

This patch enable the speculative page fault on the PowerPC architecture. This will try a speculative page fault without holding the mmap_sem, if it returns with WM_FAULT_RETRY, the mmap_sem is acquired and the traditional page fault processing is done. Signed-off-by: Laurent Dufour

[RFC v5 11/11] powerpc/mm: Add speculative page fault

This patch enable the speculative page fault on the PowerPC architecture. This will try a speculative page fault without holding the mmap_sem, if it returns with WM_FAULT_RETRY, the mmap_sem is acquired and the traditional page fault processing is done. Signed-off-by: Laurent Dufour ---

[RFC v5 08/11] mm: Provide speculative fault infrastructure

From: Peter Zijlstra Provide infrastructure to do a speculative fault (not holding mmap_sem). The not holding of mmap_sem means we can race against VMA change/removal and page-table destruction. We use the SRCU VMA freeing to keep the VMA around. We use the VMA seqcount to

[RFC v5 08/11] mm: Provide speculative fault infrastructure

From: Peter Zijlstra Provide infrastructure to do a speculative fault (not holding mmap_sem). The not holding of mmap_sem means we can race against VMA change/removal and page-table destruction. We use the SRCU VMA freeing to keep the VMA around. We use the VMA seqcount to detect change

[RFC v5 09/11] mm: Try spin lock in speculative path

There is a deadlock when a CPU is doing a speculative page fault and another one is calling do_unmap(). The deadlock occurred because the speculative path try to spinlock the pte while the interrupt are disabled. When the other CPU in the unmap's path has locked the pte then is waiting for all

[RFC v5 09/11] mm: Try spin lock in speculative path

There is a deadlock when a CPU is doing a speculative page fault and another one is calling do_unmap(). The deadlock occurred because the speculative path try to spinlock the pte while the interrupt are disabled. When the other CPU in the unmap's path has locked the pte then is waiting for all

[RFC v5 03/11] mm: Introduce pte_spinlock for FAULT_FLAG_SPECULATIVE

When handling page fault without holding the mmap_sem the fetch of the pte lock pointer and the locking will have to be done while ensuring that the VMA is not touched in our back. So move the fetch and locking operations in a dedicated function. Signed-off-by: Laurent Dufour

[RFC v5 03/11] mm: Introduce pte_spinlock for FAULT_FLAG_SPECULATIVE

When handling page fault without holding the mmap_sem the fetch of the pte lock pointer and the locking will have to be done while ensuring that the VMA is not touched in our back. So move the fetch and locking operations in a dedicated function. Signed-off-by: Laurent Dufour --- mm/memory.c |

[RFC v5 10/11] x86/mm: Add speculative pagefault handling

From: Peter Zijlstra Try a speculative fault before acquiring mmap_sem, if it returns with VM_FAULT_RETRY continue with the mmap_sem acquisition and do the traditional fault. Signed-off-by: Peter Zijlstra (Intel) [Clearing of FAULT_FLAG_ALLOW_RETRY

[RFC v5 10/11] x86/mm: Add speculative pagefault handling

From: Peter Zijlstra Try a speculative fault before acquiring mmap_sem, if it returns with VM_FAULT_RETRY continue with the mmap_sem acquisition and do the traditional fault. Signed-off-by: Peter Zijlstra (Intel) [Clearing of FAULT_FLAG_ALLOW_RETRY is now done in handle_speculative_fault()]

[RFC v5 00/11] Speculative page faults

This is a port on kernel 4.12 of the work done by Peter Zijlstra to handle page fault without holding the mm semaphore [1]. The idea is to try to handle user space page faults without holding the mmap_sem. This should allow better concurrency for massively threaded process since the page fault

[RFC v5 00/11] Speculative page faults

This is a port on kernel 4.12 of the work done by Peter Zijlstra to handle page fault without holding the mm semaphore [1]. The idea is to try to handle user space page faults without holding the mmap_sem. This should allow better concurrency for massively threaded process since the page fault

<    1   2   3   4   5   6   7   8   9   10   >