[PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

It's bus specific aspect to map a given device on the bus and relevant firmware description of its DMA configuration. So, this change introduces '/dma_configure/' as bus callback giving flexibility to busses for implementing its own dma configuration function. The change eases the addition of new

[PATCH v2 2/2] drivers: remove force dma flag from buses

With each bus implementing its own DMA configuration callback, there is no need for bus to explicitly have force_dma in its global structure. This patch modifies of_dma_configure API to accept an input parameter which specifies if implicit DMA configuration is required even when it is not described

RE: [PATCH 1/4] iommu: Add virtio-iommu driver

> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Wednesday, February 14, 2018 10:54 PM > > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio-mmio transport without > emulating > page tables. This implementatio

Re: [PATCH] iommu/mediatek: Fix protect memory setting

Hi Joerg, On Tue, 2018-03-20 at 13:57 -0500, Joerg Roedel wrote: > On Sun, Mar 18, 2018 at 09:52:54AM +0800, Yong Wu wrote: > > To avoid adding this complex macro or a new function, I put > > it in the code and backup its value in the suspend registers. > > Missing Signed-off-by. Signed-off-by a

RE: [PATCH v5 2/7] vfio/type1: Check reserve region conflict and update iova list

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, March 21, 2018 6:38 AM > > On Mon, 19 Mar 2018 07:51:58 + > "Tian, Kevin" wrote: > > > > From: Shameer Kolothum > > > Sent: Friday, March 16, 2018 12:35 AM > > > > > > This retrieves the reserved regions associate

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, March 21, 2018 6:55 AM > > On Mon, 19 Mar 2018 08:28:32 + > "Tian, Kevin" wrote: > > > > From: Shameer Kolothum > > > Sent: Friday, March 16, 2018 12:35 AM > > > > > > This series introduces an iova list associate

Re: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

On Mon, 19 Mar 2018 08:28:32 + "Tian, Kevin" wrote: > > From: Shameer Kolothum > > Sent: Friday, March 16, 2018 12:35 AM > > > > This series introduces an iova list associated with a vfio > > iommu. The list is kept updated taking care of iommu apertures, > > and reserved regions. Also this

Re: [PATCH v5 2/7] vfio/type1: Check reserve region conflict and update iova list

On Mon, 19 Mar 2018 07:51:58 + "Tian, Kevin" wrote: > > From: Shameer Kolothum > > Sent: Friday, March 16, 2018 12:35 AM > > > > This retrieves the reserved regions associated with dev group and > > checks for conflicts with any existing dma mappings. Also update > > the iova list excluding

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 16:28 +0100, Joerg Roedel wrote: > On Thu, Mar 15, 2018 at 02:42:00PM +, Dmitry Safonov wrote: > > But even with loop-limit we will need ratelimit each printk() > > *also*. > > Otherwise loop-limit will be based on time spent printing, not on > > anything else.. > > The pa

Re: [PATCH] iommu/mediatek: Fix protect memory setting

On Sun, Mar 18, 2018 at 09:52:54AM +0800, Yong Wu wrote: > To avoid adding this complex macro or a new function, I put > it in the code and backup its value in the suspend registers. Missing Signed-off-by. > --- > drivers/iommu/mtk_iommu.c | 15 ++- > drivers/iommu/mtk_iommu.h | 1 +

Re: [PATCH 1/1] iommu/vt-d: Use real PASID for flush in caching mode

On Fri, Mar 16, 2018 at 12:31:36PM +0800, Lu Baolu wrote: > If caching mode is supported, the hardware will cache > none-present or erroneous translation entries. Hence, > software should explicitly invalidate the PASID cache > after a PASID table entry becomes present. We should > issue such inval

Re: [PATCH 1/3] dt-bindings: iommu: ipmmu-vmsa: Add device tree support for r8a774[35]

On Wed, Jan 24, 2018 at 03:42:00PM +, Biju Das wrote: > Document r8a774[35] specific compatible strings. The Renesas RZ/G1[ME] > (r8a774[35]) IPMMU are identical to the R-Car Gen2 family. > > Signed-off-by: Biju Das > Reviewed-by: Chris Paterson > --- > Documentation/devicetree/bindings/iom

Re: [PATCH v2 06/21] fpga: Remove depends on HAS_DMA in case of platform dependency

On Tue, Mar 20, 2018 at 5:04 AM, Geert Uytterhoeven wrote: Hi Geert, > Hi Alan, > > On Mon, Mar 19, 2018 at 5:06 PM, Alan Tull wrote: >> On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven >> wrote: >> This essentially removes this commit >> >> commit 1c8cb409491403036919dd1c6b45013dc8835a44 >

Re: [PATCH 12/14] dma-direct: handle the memory encryption bit in common code

On Mon, Mar 19, 2018 at 08:49:30PM +0100, Christoph Hellwig wrote: > On Mon, Mar 19, 2018 at 06:01:41PM +, Catalin Marinas wrote: > > I don't particularly like maintaining an arm64-specific dma-direct.h > > either but arm64 seems to be the only architecture that needs to > > potentially force a

Re: use generic dma-direct and swiotlb code for x86 V3

On Tue, Mar 20, 2018 at 11:25:21AM +, Konrad Rzeszutek Wilk wrote: > Are you testing with swiotlb=force? I've done swiotlb=force testing with earlier versions, and otherwise relied on a VM with more the 4gb of memory and emulated devices without 64-bit capability. _

Re: [PATCH] iommu/ipmmu-vmsa: Document R-Car M3-N IPMMU DT bindings

On Tue, Mar 20, 2018 at 7:48 AM, Magnus Damm wrote: > From: Magnus Damm > > Update the IPMMU DT binding documentation to include the r8a77965 compat > string for the IPMMU devices included in the R-Car M3-N SoC. > > Signed-off-by: Magnus Damm (as already supplied to Jacopo's submission) Reviewe

Re: use generic dma-direct and swiotlb code for x86 V3

On Tue, Mar 20, 2018, 5:03 AM Ingo Molnar wrote: > > * Christoph Hellwig wrote: > > > On Tue, Mar 20, 2018 at 09:37:51AM +0100, Ingo Molnar wrote: > > > > git://git.infradead.org/users/hch/misc.git dma-direct-x86 > > > > > > Btw., what's the upstreaming route for these patches? > > > > > > While

Re: [PATCH v2 10/21] lightnvm: Remove depends on HAS_DMA in case of platform dependency

Hi Madalin-cristian, On Mon, Mar 19, 2018 at 6:27 AM, Madalin-cristian Bucur wrote: >> -Original Message- >> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] >> On Behalf Of Geert Uytterhoeven >> Remove dependencies on HAS_DMA where a Kconfig symbol depends on >> a

Re: [PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)

> To play it safe, you want to postpone the subsystem patches until the core > part has landed upstream. I will rebase and resubmit after v4.17-rc1. Thanks for the heads up. I'll wait for the rebased patch then and apply it after rc1 for 4.17. signature.asc Description: PGP signature _

Re: [PATCH v2 14/21] mtd: Remove depends on HAS_DMA in case of platform dependency

Hi Boris, On Sun, Mar 18, 2018 at 11:04 PM, Boris Brezillon wrote: > On Fri, 16 Mar 2018 14:51:47 +0100 > Geert Uytterhoeven wrote: > >> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another >> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". >> In most case

Re: [PATCH v2 06/21] fpga: Remove depends on HAS_DMA in case of platform dependency

Hi Alan, On Mon, Mar 19, 2018 at 5:06 PM, Alan Tull wrote: > On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven > wrote: > This essentially removes this commit > > commit 1c8cb409491403036919dd1c6b45013dc8835a44 > Author: Sudip Mukherjee > Date: Wed Aug 3 13:45:46 2016 -0700 > > drivers/

Re: [PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)

Hi Wolfram, On Fri, Mar 16, 2018 at 10:23 PM, Wolfram Sang wrote: >> To avoid allmodconfig/allyesconfig regressions on NO_DMA=y platforms, >> this (drivers) series should be applied after the previous (core) >> series (but not many people may notice/care ;-) > > I still don't get if there is a de

Re: [PATCH v9 3/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

Hi Robin, On 3/14/2018 11:16 PM, Robin Murphy wrote: On 13/03/18 08:55, Vivek Gautam wrote: From: Sricharan R The smmu device probe/remove and add/remove master device callbacks gets called when the smmu is not linked to its master, that is without the context of the master device. So callin

Re: use generic dma-direct and swiotlb code for x86 V3

* Christoph Hellwig wrote: > On Tue, Mar 20, 2018 at 09:37:51AM +0100, Ingo Molnar wrote: > > > git://git.infradead.org/users/hch/misc.git dma-direct-x86 > > > > Btw., what's the upstreaming route for these patches? > > > > While it's a multi-arch series it's all pretty x86-heavy as well so we

Re: use generic dma-direct and swiotlb code for x86 V3

On Tue, Mar 20, 2018 at 09:37:51AM +0100, Ingo Molnar wrote: > > git://git.infradead.org/users/hch/misc.git dma-direct-x86 > > Btw., what's the upstreaming route for these patches? > > While it's a multi-arch series it's all pretty x86-heavy as well so we can > host it > in -tip (in tip:core/dm

Re: use generic dma-direct and swiotlb code for x86 V3

* Christoph Hellwig wrote: > On Mon, Mar 19, 2018 at 11:27:37AM -0400, Konrad Rzeszutek Wilk wrote: > > On Mon, Mar 19, 2018 at 11:38:12AM +0100, Christoph Hellwig wrote: > > > Hi all, > > > > > > this series switches the x86 code the the dma-direct implementation > > > for direct (non-iommu) d

Re: [PATCH] iommu/ipmmu-vmsa: Document R-Car M3-N IPMMU DT bindings

Hi Magnus, Thank you for the patch. On Tuesday, 20 March 2018 08:48:11 EET Magnus Damm wrote: > From: Magnus Damm > > Update the IPMMU DT binding documentation to include the r8a77965 compat > string for the IPMMU devices included in the R-Car M3-N SoC. > > Signed-off-by: Magnus Damm Reviewe

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

Hi Lukasz, On 3/14/2018 5:57 PM, Lukas Wunner wrote: On Wed, Mar 14, 2018 at 12:14:15PM +, Robin Murphy wrote: On Wed, Mar 14, 2018 at 8:12 PM, Rafael J. Wysocki wrote: On Tuesday, March 13, 2018 12:23:34 PM CET Tomasz Figa wrote: On Tue, Mar 13, 2018 at 7:34 PM, Vivek Gautam wrote: