On Tue, Jul 24, 2018 at 10:29:48PM -0500, Richard Kuo wrote:
> Patch series looks good. Definitely appreciate the cleanup.
>
> I can take it through my tree, or if not:
>
> Acked-by: Richard Kuo
Please take it through your tree, thanks!
___
iommu
On Thu, Jul 19, 2018 at 05:56:33AM -0700, Christoph Hellwig wrote:
> hexagon does all the required cache maintainance at dma map time, and none
> at unmap time. It thus has to implement sync_single_for_device to match
> the map cace for buffer reuse, but there is no point in doing another
>
Hi Jean,
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Tuesday, July 24, 2018 7:31 PM
>
> Hi Baolu,
>
> On 24/07/18 03:22, Lu Baolu wrote:
> > Hi,
> >
> > On 07/23/2018 12:44 PM, Liu, Yi L wrote:
> >>> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> >>> Sent:
> From: Jean-Philippe Brucker
> Sent: Tuesday, July 24, 2018 7:31 PM
>
> Hi Baolu,
>
> On 24/07/18 03:22, Lu Baolu wrote:
> > Hi,
> >
> > On 07/23/2018 12:44 PM, Liu, Yi L wrote:
> >>> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> >>> Sent: Sunday, July 22, 2018 2:09 PM
> >>>
> >>> With the
Hi Jean,
Pull Kevin in. Not sure why he was removed from cc list.
On 07/24/2018 07:30 PM, Jean-Philippe Brucker wrote:
> Hi Baolu,
>
> On 24/07/18 03:22, Lu Baolu wrote:
>> Hi,
>>
>> On 07/23/2018 12:44 PM, Liu, Yi L wrote:
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Sunday,
Hi Alex,
On 07/25/2018 02:50 AM, Alex Williamson wrote:
> On Sun, 22 Jul 2018 14:09:24 +0800
> Lu Baolu wrote:
>
>> This patch adds the support to get the iommu device for a mediated
>> device. The assumption is that each mediated device is a minimal
>> assignable set of a physical PCI device.
On 2018-07-12 7:18 AM, Zhen Lei wrote:
Because the non-strict mode introduces a vulnerability window, so add a
bootup option to make the manager can choose which mode to be used. The
default mode is IOMMU_STRICT.
Signed-off-by: Zhen Lei
---
Documentation/admin-guide/kernel-parameters.txt |
On 2018-07-12 7:18 AM, Zhen Lei wrote:
To support the non-strict mode, now we only tlbi and sync for the strict
mode. But for the non-leaf case, always follow strict mode.
Use the lowest bit of the iova parameter to pass the strict mode:
0, IOMMU_STRICT;
1, IOMMU_NON_STRICT;
Treat 0 as
Hi Rob,
On 07/20/2018 11:15 AM, Rob Herring wrote:
On Fri, Jul 13, 2018 at 11:27:56AM -0500, thor.tha...@linux.intel.com wrote:
From: Thor Thayer
Add a clock to the SMMU node bindings.
Signed-off-by: Thor Thayer
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 16
On 2018-07-12 7:18 AM, Zhen Lei wrote:
1. Save the related domain pointer in struct iommu_dma_cookie, make iovad
capable call domain->ops->flush_iotlb_all to flush TLB.
2. Add a new iommu capability: IOMMU_CAP_NON_STRICT, which used to indicate
that the iommu domain support non-strict
On 2018-07-12 7:18 AM, Zhen Lei wrote:
v2 -> v3:
Add a bootup option "iommu_strict_mode" to make the manager can choose which
mode to be used. The first 5 patches have not changed.
+ iommu_strict_mode= [arm-smmu-v3]
+ 0 - strict mode (default)
+ 1 -
Ok, there is one more issue with this version. Wait for a new one
tomorrow.
On Tue, Jul 24, 2018 at 02:01:42PM +0200, Christoph Hellwig wrote:
> Hi all,
>
> can you review these patches to switch sh to use the generic
> dma-noncoherent code? All the requirements are in mainline already
> and
On Tue, 24 Jul 2018 12:30:35 +0100
Jean-Philippe Brucker wrote:
> Hi Baolu,
>
> On 24/07/18 03:22, Lu Baolu wrote:
> > Hi,
> >
> > On 07/23/2018 12:44 PM, Liu, Yi L wrote:
> >>> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> >>> Sent: Sunday, July 22, 2018 2:09 PM
> >>>
> >>> With the
On Sun, 22 Jul 2018 14:09:24 +0800
Lu Baolu wrote:
> This patch adds the support to get the iommu device for a mediated
> device. The assumption is that each mediated device is a minimal
> assignable set of a physical PCI device. Hence, we should use the
> iommu device of the parent PCI device
On 19/07/18 11:15, Vivek Gautam wrote:
From: Sricharan R
The smmu needs to be functional only when the respective
master's using it are active. The device_link feature
helps to track such functional dependencies, so that the
iommu gets powered when the master device enables itself
using
> Subject: Re: [PATCH 4/5] sh: split arch/sh/mm/consistent.c
>
> On Mon, Jul 23, 2018 at 10:49:39AM +0200, Geert Uytterhoeven wrote:
> > > > + *dma_handle = virt_to_phys(ret);
> > > > + if (!WARN_ON(!dev))
> > > > + *dma_handle - PFN_PHYS(dev->dma_pfn_offset);
> > > vs
> > > >
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig
---
arch/sh/Kconfig | 3 +-
arch/sh/include/asm/Kbuild| 1 +
arch/sh/include/asm/dma-mapping.h | 26 ---
arch/sh/kernel/Makefile | 2 +-
Half of the file just contains platform device memory setup code which
is required for all builds, and half contains helpers for dma coherent
allocation, which is only needed if CONFIG_DMA_NONCOHERENT is enabled.
Signed-off-by: Christoph Hellwig
---
arch/sh/kernel/Makefile | 2 +-
This is a slight change in behavior as we avoid the detour through the
virtual mapping for the coherent allocator, but if this CPU really is
coherent that should be the right thing to do.
Signed-off-by: Christoph Hellwig
---
arch/sh/Kconfig | 1 +
And use it in the maple bus code to avoid a dma API dependency.
Signed-off-by: Christoph Hellwig
---
arch/sh/include/asm/cacheflush.h | 7 +++
arch/sh/mm/consistent.c | 6 +-
drivers/sh/maple/maple.c | 7 ---
3 files changed, 12 insertions(+), 8 deletions(-)
diff
Remove the indirection through the dma_ops variable, and just return
nommu_dma_ops directly from get_arch_dma_ops.
Signed-off-by: Christoph Hellwig
---
arch/sh/include/asm/dma-mapping.h | 5 ++---
arch/sh/kernel/dma-nommu.c| 8 +---
arch/sh/mm/consistent.c | 3 ---
Hi all,
can you review these patches to switch sh to use the generic
dma-noncoherent code? All the requirements are in mainline already
and we've switched various architectures over to it already.
Changes since V1:
- fixed two stupid compile errors and verified them using a local
cross
On Mon, Jul 23, 2018 at 10:49:39AM +0200, Geert Uytterhoeven wrote:
> > > + *dma_handle = virt_to_phys(ret);
> > > + if (!WARN_ON(!dev))
> > > + *dma_handle - PFN_PHYS(dev->dma_pfn_offset);
> > vs
> > > - *dma_handle = virt_to_phys(ret);
> > > - if (!WARN_ON(!dev))
> >
Hi Baolu,
On 24/07/18 03:22, Lu Baolu wrote:
> Hi,
>
> On 07/23/2018 12:44 PM, Liu, Yi L wrote:
>>> From: Lu Baolu [mailto:baolu...@linux.intel.com]
>>> Sent: Sunday, July 22, 2018 2:09 PM
>>>
>>> With the Intel IOMMU supporting PASID granularity isolation and protection,
>>> a
>>> mediated
Hi Will,
On Wed, Jun 27, 2018 at 10:07 PM, Will Deacon wrote:
> Hi Vivek,
>
> On Tue, Jun 19, 2018 at 02:04:44PM +0530, Vivek Gautam wrote:
>> On Fri, Jun 15, 2018 at 10:22 PM, Will Deacon wrote:
>> > On Fri, Jun 15, 2018 at 04:23:29PM +0530, Vivek Gautam wrote:
>> >> Qualcomm SoCs have an
Hi Will,
On 7/24/2018 2:06 PM, Will Deacon wrote:
On Thu, Jul 19, 2018 at 11:23:56PM +0530, Vivek Gautam wrote:
Currently we check if the number of context banks is not equal to
num_context_interrupts. However, there are booloaders such as, one
on sdm845 that reserves few context banks and
On Thu, Jul 19, 2018 at 11:23:56PM +0530, Vivek Gautam wrote:
> Currently we check if the number of context banks is not equal to
> num_context_interrupts. However, there are booloaders such as, one
> on sdm845 that reserves few context banks and thus kernel views
> less than the total available
27 matches
Mail list logo
