Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Tuesday, July 14, 2020 9:40 PM
>
> Hi Shimoda-san,
>
> On Tue, Jul 14, 2020 at 1:42 PM Yoshihiro Shimoda
> wrote:
> > > From: Geert Uytterhoeven, Sent: Tuesday, July 14, 2020 5:42 PM
> > > On Tue, Jul 14, 2020 at 10:30 AM Lad, Prabhakar
> > > wro
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: Wednesday, July 15, 2020 3:37 PM
> To: Makarand Pawagi
> Cc: Diana Madalina Craciun (OSS) ; Laurentiu
> Tudor ; linux-arm-ker...@lists.infradead.org;
> iommu@lists.linux-foundation.org; linux-a...@vger.kernel.org;
> devicet...@vger
Hi Jacob,
On 7/16/20 12:01 AM, Jacob Pan wrote:
On Wed, 15 Jul 2020 08:47:36 +0800
Lu Baolu wrote:
Hi Jacob,
On 7/15/20 12:39 AM, Jacob Pan wrote:
On Tue, 14 Jul 2020 13:57:01 +0800
Lu Baolu wrote:
This adds two new aux-domain APIs for a use case like vfio/mdev
where sub-devices deriv
Hi, Yi,
On Mon, Jul 13, 2020 at 08:25:20PM -0700, Liu, Yi L wrote:
> > From: Fenghua Yu
> > Sent: Tuesday, July 14, 2020 7:48 AM
> > From: Ashok Raj
Thank you for your comments!
But I think we don't need to update this patch because the current text
is better than suggested changes. I would ra
Hi Bjorn,
I love your patch! Perhaps something to improve:
[auto build test WARNING on iommu/next]
[also build test WARNING on arm-perf/for-next/perf v5.8-rc5 next-20200715]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On Tue, 14 Jul 2020 13:04:12 -0600
Alex Williamson wrote:
> > > The
> > > mangling of the user provided argsz above makes me cringe a
> > > little too for that reason, once we start modifying the user
> > > values in the core it could get messy for the vendor drivers.
> > >
> > We do have v
On 02/07/2020 11:37, Miles Chen wrote:
In previous disscusion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.
Check 4GB mode by reading infracfg register, remove the usage
of the unexported symbol max_pfn.
[1] https://lkml.org/lkml/2020
On Thu, Jul 02, 2020 at 05:37:17PM +0800, Miles Chen wrote:
> Add a description for mediatek,infracfg. We can check if 4GB mode
> is enable by reading it instead of checking the unexported
> symbol "max_pfn".
>
> This is a step towards building mtk_iommu as a kernel module.
You determined this be
On 2020-07-15 04:43, Claire Chang wrote:
On Mon, Jul 13, 2020 at 7:40 PM Robin Murphy wrote:
On 2020-07-13 10:12, Claire Chang wrote:
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at une
On Sat, 11 Jul 2020, Michael S. Tsirkin wrote:
> On Fri, Jul 10, 2020 at 10:23:22AM -0700, Stefano Stabellini wrote:
> > Sorry for the late reply -- a couple of conferences kept me busy.
> >
> >
> > On Wed, 1 Jul 2020, Michael S. Tsirkin wrote:
> > > On Wed, Jul 01, 2020 at 10:34:53AM -0700, Stef
On Wed, 15 Jul 2020 08:47:36 +0800
Lu Baolu wrote:
> Hi Jacob,
>
> On 7/15/20 12:39 AM, Jacob Pan wrote:
> > On Tue, 14 Jul 2020 13:57:01 +0800
> > Lu Baolu wrote:
> >
> >> This adds two new aux-domain APIs for a use case like vfio/mdev
> >> where sub-devices derived from an aux-domain capab
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets. See the 'v1' notes below for more info.
v8:
Commit: "device core: Introduce DMA range map, supplanting ...
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.
On 2020-06-19 09:20, Lorenzo Pieralisi wrote:
From: Diana Craciun
The DPRC driver is not taking into account the msi-map property
and assumes that the icid is the same as the stream ID. Although
this assumption is correct, generalize the code to include a
translation between icid and streamID.
On 13-07-20, 22:35, Lad Prabhakar wrote:
> Renesas RZ/G2H (R8A774E1) SoC also has the R-Car gen3 compatible
> DMA controllers, therefore document RZ/G2H specific bindings.
Applied, thanks
--
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.or
On 2020-07-15 08:06, Tomasz Nowicki wrote:
Add specific compatible string for Marvell usage due to errata of
accessing 64bits registers of ARM SMMU, in AP806.
AP806 SoC uses the generic ARM-MMU500, and there's no specific
implementation of Marvell, this compatible is used for errata only.
Revi
On 2020-07-15 08:06, Tomasz Nowicki wrote:
From: Hanna Hawa
Due to erratum #582743, the Marvell Armada-AP806 can't access 64bit to
ARM SMMUv2 registers.
Provide implementation relevant hooks:
- split the writeq/readq to two accesses of writel/readl.
- mask the MMU_IDR2.PTFSv8 fields to not use
On Mon, Jul 13, 2020 at 11:36 PM Lad Prabhakar
wrote:
> From: Marian-Cristian Rotariu
>
> This patch adds the SoC specific part of the Ethernet AVB
> device tree node.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Geert Uytterhoeven
i.e. will queue
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
wrote:
> From: Marian-Cristian Rotariu
>
> Add GPIO device nodes to the DT of the r8a774e1 SoC.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.9
On 2020-07-15 08:06, Tomasz Nowicki wrote:
'cfg_probe' hook is called at the very end of configuration probing
procedure and therefore features override and workaround may become
complex like for ID register fixups. In preparation for adding Marvell
errata move 'cfg_probe' a bit earlier to have c
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
wrote:
> From: Marian-Cristian Rotariu
>
> Add sys-dmac[0-2] device nodes for RZ/G2H (R8A774E1) SoC.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
wrote:
> From: Marian-Cristian Rotariu
>
> Add RZ/G2H (R8A774E1) IPMMU nodes.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting
On Thu, Jul 09, 2020 at 10:52:52AM +, Makarand Pawagi wrote:
[...]
> > fsl_mc_bus_probe(struct platform_device *pdev)
> > >> struct fsl_mc_io *mc_io = NULL;
> > >> int container_id;
> > >> phys_addr_t mc_portal_phys_addr;
> > >> - u32 mc_portal_size;
> >
On Tue, Jul 14, 2020 at 12:21 PM Lad Prabhakar
wrote:
> Add an entry for r8a77961 in soc_rcar_gen3[] list so that we dont
> enable iommu unconditionally.
>
> Fixes: 17fe161816398 ("iommu/renesas: Add support for r8a77961")
> Signed-off-by: Lad Prabhakar
Reviewed-by: Geert Uytterhoeven
Gr{oetje
On Tue, Jul 14, 2020 at 12:21 PM Lad Prabhakar
wrote:
> From: Marian-Cristian Rotariu
>
> Add support for RZ/G2H (R8A774E1) SoC IPMMUs.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Gee
On Fri, Jun 19, 2020 at 09:20:04AM +0100, Lorenzo Pieralisi wrote:
> There is nothing PCI specific in iort_msi_map_rid().
>
> Rename the function using a bus protocol agnostic name,
> iort_msi_map_id(), and convert current callers to it.
>
> Signed-off-by: Lorenzo Pieralisi
> Cc: Will Deacon
>
On Thu, Jul 09, 2020 at 10:35:14AM +0100, Lorenzo Pieralisi wrote:
> On Fri, Jun 19, 2020 at 09:20:06AM +0100, Lorenzo Pieralisi wrote:
> > Some HW devices are created as child devices of proprietary busses,
> > that have a bus specific policy defining how the child devices
> > wires representing t
On Wed, Jul 15, 2020 at 11:46 AM Claire Chang wrote:
>
> On Tue, Jul 14, 2020 at 7:01 PM Christoph Hellwig wrote:
> >
> > On Mon, Jul 13, 2020 at 12:55:43PM +0100, Robin Murphy wrote:
> > > On 2020-07-13 10:12, Claire Chang wrote:
> > >> The bounced DMA ops provide an implementation of DMA ops th
On Tue, Jul 14, 2020 at 02:39:24PM +0200, Nicolas Saenz Julienne wrote:
> This is my attempt at fixing one of the regressions we've seen[1] after
> the introduction of per-zone atomic pools.
>
> This combined with "dma-pool: Do not allocate pool memory from CMA"[2]
> should fix the boot issues on
From: Marcin Wojtas
Add IOMMU node for Marvell AP806 based SoCs together with platform
and PCI device Stream ID mapping.
Signed-off-by: Marcin Wojtas
Signed-off-by: Tomasz Nowicki
---
arch/arm64/boot/dts/marvell/armada-7040.dtsi | 28 +
arch/arm64/boot/dts/marvell/armada-8040.dts
Add specific compatible string for Marvell usage due to errata of
accessing 64bits registers of ARM SMMU, in AP806.
AP806 SoC uses the generic ARM-MMU500, and there's no specific
implementation of Marvell, this compatible is used for errata only.
Reviewed-by: Rob Herring
Signed-off-by: Hanna Haw
'cfg_probe' hook is called at the very end of configuration probing
procedure and therefore features override and workaround may become
complex like for ID register fixups. In preparation for adding Marvell
errata move 'cfg_probe' a bit earlier to have chance to adjust
the detected features before
From: Hanna Hawa
Due to erratum #582743, the Marvell Armada-AP806 can't access 64bit to
ARM SMMUv2 registers.
Provide implementation relevant hooks:
- split the writeq/readq to two accesses of writel/readl.
- mask the MMU_IDR2.PTFSv8 fields to not use AArch64 format (but
only AARCH32_L) since wi
The series is meant to support SMMU for AP806 and a workaround
for accessing ARM SMMU 64bit registers is the gist of it.
For the record, AP-806 can't access SMMU registers with 64bit width.
This patches split the readq/writeq into two 32bit accesses instead
and update DT bindings.
The series was
34 matches
Mail list logo
