Hi Joerg,
On 5/21/21 2:53 PM, Rolf Eike Beer wrote:
Am Donnerstag, 22. April 2021, 07:34:17 CEST schrieb Lu Baolu:
Hi Rolf,
On 4/22/21 1:39 PM, Rolf Eike Beer wrote:
iommu_device_sysfs_add() is called before, so is has to be cleaned on
subsequent errors.
Fixes: 39ab9555c2411 ("iommu: Add sys
On 2021/5/19 2:58, Alex Williamson wrote:
> On Fri, 9 Apr 2021 11:44:20 +0800
> Shenming Lu wrote:
>
>> To set up nested mode, drivers such as vfio_pci need to register a
>> handler to receive stage/level 1 faults from the IOMMU, but since
>> currently each device can only have one iommu dev faul
Add compatible for the second version of IOMMU hardware block.
RK356x IOMMU can also be link to a power domain.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
---
.../devicetree/bindings/iommu/rockchip,iommu.yaml | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
d
This series adds the IOMMU driver for rk356x SoC.
Since a new compatible is needed to distinguish this second version of
IOMMU hardware block from the first one, it is an opportunity to convert
the binding to DT schema.
version 5:
- Add internal ops inside the driver to be able to add variants.
Convert Rockchip IOMMU to DT schema
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
---
.../bindings/iommu/rockchip,iommu.txt | 38 -
.../bindings/iommu/rockchip,iommu.yaml| 80 +++
2 files changed, 80 insertions(+), 38 deletions(-)
delete mode
This second version of the hardware block has a different bits
mapping for page table entries.
Add the ops matching to this new mapping.
Define a new compatible to distinguish it from the first version.
Signed-off-by: Benjamin Gaignard
---
version 5:
- Use internal ops to support v2 hardware blo
Add internal ops to be able to handle incoming variant v2.
The goal is to keep the overall structure of the framework but
to allow to add the evolution of this hardware block.
The ops are global for a SoC because iommu domains are not
attached to a specific devices if they are for a virtuel device
Am Freitag, 21. Mai 2021, 10:36:36 CEST schrieb Benjamin Gaignard:
> Add internal ops to be able to handle incoming variant v2.
> The goal is to keep the overall structure of the framework but
> to allow to add the evolution of this hardware block.
>
> The ops are global for a SoC because iommu do
Am Freitag, 21. Mai 2021, 10:36:37 CEST schrieb Benjamin Gaignard:
> This second version of the hardware block has a different bits
> mapping for page table entries.
> Add the ops matching to this new mapping.
> Define a new compatible to distinguish it from the first version.
>
> Signed-off-by: B
Am Freitag, 21. Mai 2021, 10:36:35 CEST schrieb Benjamin Gaignard:
> Add compatible for the second version of IOMMU hardware block.
> RK356x IOMMU can also be link to a power domain.
>
> Signed-off-by: Benjamin Gaignard
> Reviewed-by: Rob Herring
Reviewed-by: Heiko Stuebner
> ---
> .../devic
Am Freitag, 21. Mai 2021, 10:36:34 CEST schrieb Benjamin Gaignard:
> Convert Rockchip IOMMU to DT schema
>
> Signed-off-by: Benjamin Gaignard
> Reviewed-by: Rob Herring
Reviewed-by: Heiko Stuebner
___
iommu mailing list
iommu@lists.linux-foundatio
On 2021-05-21 04:05, chenxiang wrote:
From: Xiang Chen
The issue is reported by tool TscanCode, and it is possible to deference
null pointer when prev is NULL which is the initial value.
No it isn't. This is literally explained in the comment visible in the
diff context below...
Robin.
S
On 2021-05-21 09:36, Benjamin Gaignard wrote:
Add compatible for the second version of IOMMU hardware block.
RK356x IOMMU can also be link to a power domain.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
---
.../devicetree/bindings/iommu/rockchip,iommu.yaml | 7 ++-
在 2021/5/21 18:36, Robin Murphy 写道:
On 2021-05-21 04:05, chenxiang wrote:
From: Xiang Chen
The issue is reported by tool TscanCode, and it is possible to deference
null pointer when prev is NULL which is the initial value.
No it isn't. This is literally explained in the comment visible in
On 13/05/2021 14:45, Shameer Kolothum wrote:
> Hi,
>
> v3 -->v4
> -Included the SMMUv2 SMR bypass install changes suggested by
> Steve(patch #7)
> -As per Robin's comments, RMR reserve implementation is now
> more generic (patch #8) and dropped v3 patches 8 and 10.
> -Rebase to 5.13-rc1
>
> T
On 2021-05-21 09:36, Benjamin Gaignard wrote:
Add internal ops to be able to handle incoming variant v2.
The goal is to keep the overall structure of the framework but
to allow to add the evolution of this hardware block.
The ops are global for a SoC because iommu domains are not
attached to a s
> -Original Message-
> From: Steven Price [mailto:steven.pr...@arm.com]
> Sent: 21 May 2021 13:55
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: Linuxarm ; lorenzo.pieral...@arm.com;
> j...@8by
Le 21/05/2021 à 14:58, Robin Murphy a écrit :
On 2021-05-21 09:36, Benjamin Gaignard wrote:
Add internal ops to be able to handle incoming variant v2.
The goal is to keep the overall structure of the framework but
to allow to add the evolution of this hardware block.
The ops are global for a S
This series adds the IOMMU driver for rk356x SoC.
Since a new compatible is needed to distinguish this second version of
IOMMU hardware block from the first one, it is an opportunity to convert
the binding to DT schema.
version 6:
- Remove #include
- Remove pt_address_mask field
- Only use on
Add internal ops to be able to handle incoming variant v2.
The goal is to keep the overall structure of the framework but
to allow to add the evolution of this hardware block.
The ops are global for a SoC because iommu domains are not
attached to a specific devices if they are for a virtuel device
Convert Rockchip IOMMU to DT schema
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
.../bindings/iommu/rockchip,iommu.txt | 38 -
.../bindings/iommu/rockchip,iommu.yaml| 80 +++
2 files changed, 80 insertions(+),
Add compatible for the second version of IOMMU hardware block.
RK356x IOMMU can also be link to a power domain.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
.../devicetree/bindings/iommu/rockchip,iommu.yaml | 7 ++-
1 file changed, 6 in
This second version of the hardware block has a different bits
mapping for page table entries.
Add the ops matching to this new mapping.
Define a new compatible to distinguish it from the first version.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Heiko Stuebner
---
version 5:
- Use internal o
On 2021-05-21 09:36, Benjamin Gaignard wrote:
This second version of the hardware block has a different bits
mapping for page table entries.
Add the ops matching to this new mapping.
Define a new compatible to distinguish it from the first version.
Signed-off-by: Benjamin Gaignard
---
version 5
When we allocate new pagetable pages, we don't modify them between the
initial dma_map_single() call and the dma_sync_single_for_device() call
via rk_iommu_flush(), so the latter is entirely pointless.
Signed-off-by: Robin Murphy
---
drivers/iommu/rockchip-iommu.c | 3 ---
1 file changed, 3 dele
On 2021-05-21 14:38, Benjamin Gaignard wrote:
Le 21/05/2021 à 14:58, Robin Murphy a écrit :
On 2021-05-21 09:36, Benjamin Gaignard wrote:
Add internal ops to be able to handle incoming variant v2.
The goal is to keep the overall structure of the framework but
to allow to add the evolution of t
On Fri, Apr 23, 2021 at 1:57 PM Jean-Philippe Brucker
wrote:
>
> The ACPI Virtual I/O Translation Table describes topology of
> para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT.
> For now it describes the relation between virtio-iommu and the endpoints
> it manages.
>
> Three
On Fri, Apr 23, 2021 at 1:57 PM Jean-Philippe Brucker
wrote:
>
> Some of the IOMMU setup code in IORT is fairly generic and can be reused
> by VIOT. Extract it from IORT.
Except that iort_iommu_configure_id() is not really generic AFAICS.
___
iommu mail
On Thu, May 20, 2021 at 10:03 PM Wang Xingang wrote:
>
> From: Xingang Wang
>
> When booting with devicetree, the pci_request_acs() is called after the
> enumeration and initialization of PCI devices, thus the ACS is not
> enabled. And ACS should be enabled when IOMMU is detected for the
> PCI ho
On Tue, May 18, 2021 at 09:19:21PM +, John Stultz wrote:
> From: Saravana Kannan
>
> This patch revives changes from Saravana Kannan to switch the
> qcom-pdc driver to use IRQCHIP_PLATFORM_DRIVER helper macros,
> and allows qcom-pdc driver to be loaded as a permanent module.
>
> Earlier atte
On Tue, May 18, 2021 at 09:19:22PM +, John Stultz wrote:
> Allow the qcom_scm driver to be loadable as a permenent module.
>
> This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to
> ensure that drivers that call into the qcom_scm driver are
> also built as modules. While not ideal in
Hi BaoLu,
On Thu, 20 May 2021 11:15:21 +0800, Lu Baolu
wrote:
> We are about to use iommu_sva_alloc/free_pasid() helpers in iommu core.
> That means the pasid life cycle will be managed by iommu core. Use a
> local array to save the per pasid private data instead of attaching it
> the real pasid
32 matches
Mail list logo
