Re: [PATCH] iommu/vt-d: quirk_ioat_snb_local_iommu: replace WARN_TAINT with pr_warn + add_taint

2020-03-09 Thread Lu Baolu
On 2020/3/10 2:25, Hans de Goede wrote: Quoting from the comment describing the WARN functions in include/asm-generic/bug.h: * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report * significant kernel issues that need prompt attention if they should ever * appear at runtime.

Re: [PATCH 2/2] iommu/vt-d: dmar_parse_one_rmrr: replace WARN_TAINT with pr_warn + add_taint

2020-03-09 Thread Lu Baolu
On 2020/3/9 22:01, Hans de Goede wrote: Quoting from the comment describing the WARN functions in include/asm-generic/bug.h: * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report * significant kernel issues that need prompt attention if they should ever * appear at runtime.

Re: [PATCH 1/2] iommu/vt-d: dmar: replace WARN_TAINT with pr_warn + add_taint

2020-03-09 Thread Lu Baolu
On 2020/3/9 22:01, Hans de Goede wrote: Quoting from the comment describing the WARN functions in include/asm-generic/bug.h: * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report * significant kernel issues that need prompt attention if they should ever * appear at runtime.

Re: [Patch V1 1/2] iommu/vt-d: Fix debugfs register reads

2020-03-09 Thread Lu Baolu
On 2020/3/10 4:09, Megha Dey wrote: Commit 6825d3ea6cde ("iommu/vt-d: Add debugfs support to show register contents") dumps the register contents for all IOMMU devices. Currently, a 64 bit read(dmar_readq) is done for all the IOMMU registers, even though some of the registers are 32 bits, which

Re: [Patch V1 0/2] iommu/vtd: Fixes to the IOMMU debugfs

2020-03-09 Thread Lu Baolu
Hi Megha, Thanks for the fixes. For two patches in this series: Acked-by: Lu Baolu Best regards, baolu On 2020/3/10 4:09, Megha Dey wrote: This patchset aims to fix some of the existing issues in the iommu debugfs. The first patch aims to fix the debugfs register reads by using the correct

[Patch V1 1/2] iommu/vt-d: Fix debugfs register reads

2020-03-09 Thread Megha Dey
Commit 6825d3ea6cde ("iommu/vt-d: Add debugfs support to show register contents") dumps the register contents for all IOMMU devices. Currently, a 64 bit read(dmar_readq) is done for all the IOMMU registers, even though some of the registers are 32 bits, which is incorrect. Use the correct read fu

[Patch V1 0/2] iommu/vtd: Fixes to the IOMMU debugfs

2020-03-09 Thread Megha Dey
This patchset aims to fix some of the existing issues in the iommu debugfs. The first patch aims to fix the debugfs register reads by using the correct read function variant while reading the contents of iommu registers while the second patch ensures the debugfs directory is populated even if DMA

[Patch V1 2/2] iommu/vt-d: Populate debugfs if IOMMUs are detected

2020-03-09 Thread Megha Dey
Currently, the intel iommu debugfs directory(/sys/kernel/debug/iommu/intel) gets populated only when DMA remapping is enabled (dmar_disabled = 0) irrespective of whether interrupt remapping is enabled or not. Instead, populate the intel iommu debugfs directory if any IOMMUs are detected. Signed-o

[PATCH 2/3] dt-bindings: remoteproc: qcom: Add modem-firmware bindings

2020-03-09 Thread Sibi Sankar
Introduce modem-firmware binding to allow Q6 modem to boot on platforms which do not have trustZone. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/remoteproc/qcom

[PATCH 3/3] remoteproc: qcom_q6v5_mss: Request direct mapping for firmware subdevice

2020-03-09 Thread Sibi Sankar
The Q6 modem sub-system has direct access to DDR through memnoc and an indirect access routed through a SMMU which MSS CE (crypto engine sub-component of MSS) uses during out of reset sequence. Request direct mapping for the modem-firmware subdevice since smmu is not expected to provide access cont

[PATCH 1/3] iommu: Export "iommu_request_dm_for_dev"

2020-03-09 Thread Sibi Sankar
Export "iommu_request_dm_for_dev" to allow for modular builds of drivers requesting for direct mapping. Signed-off-by: Sibi Sankar --- drivers/iommu/iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 3e3528436e0b2..06a36230fe22d 100644

[PATCH 0/3] Request direct mapping for modem firmware subdevice

2020-03-09 Thread Sibi Sankar
The Q6 modem sub-system has direct access to DDR through memnoc and an indirect access routed through a SMMU which MSS CE (crypto engine sub-component of MSS) uses during out of reset sequence. Request direct mapping for the modem-firmware subdevice since smmu is not expected to provide access cont

[PATCH] iommu/vt-d: quirk_ioat_snb_local_iommu: replace WARN_TAINT with pr_warn + add_taint

2020-03-09 Thread Hans de Goede
Quoting from the comment describing the WARN functions in include/asm-generic/bug.h: * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report * significant kernel issues that need prompt attention if they should ever * appear at runtime. * * Do not use these macros when checking for

Re: [PATCH 00/14] iommu: Move iommu_fwspec out of 'struct device'

2020-03-09 Thread Joerg Roedel
Hi Jean-Philippe, On Fri, Mar 06, 2020 at 11:09:55AM +0100, Jean-Philippe Brucker wrote: > I think that's because patch 01/14 move the fwspec access too early. In > > err = pci_for_each_dma_alias(to_pci_dev(dev), > iort_pci_iommu_init,

Re: [PATCH 2/2] iommu/vt-d: dmar_parse_one_rmrr: replace WARN_TAINT with pr_warn + add_taint

2020-03-09 Thread Barret Rhoden via iommu
On 3/9/20 12:01 PM, Hans de Goede wrote: Hi, On 3/9/20 4:57 PM, Barret Rhoden wrote: On 3/9/20 10:01 AM, Hans de Goede wrote: Quoting from the comment describing the WARN functions in include/asm-generic/bug.h:   * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report   * signifi

Re: [PATCH 2/2] iommu/vt-d: dmar_parse_one_rmrr: replace WARN_TAINT with pr_warn + add_taint

2020-03-09 Thread Hans de Goede
Hi, On 3/9/20 4:57 PM, Barret Rhoden wrote: On 3/9/20 10:01 AM, Hans de Goede wrote: Quoting from the comment describing the WARN functions in include/asm-generic/bug.h:   * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report   * significant kernel issues that need prompt attentio

Re: [PATCH 2/2] iommu/vt-d: dmar_parse_one_rmrr: replace WARN_TAINT with pr_warn + add_taint

2020-03-09 Thread Barret Rhoden via iommu
On 3/9/20 10:01 AM, Hans de Goede wrote: Quoting from the comment describing the WARN functions in include/asm-generic/bug.h: * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report * significant kernel issues that need prompt attention if they should ever * appear at runtime.

[PATCH v2] [dma-coherent] Fix integer overflow in the reserved-memory dma allocation

2020-03-09 Thread Kevin Grandemange
pageno is an int and the PAGE_SHIFT shift is done on an int, overflowing if the memory is bigger than 2G This can be reproduced using for example a reserved-memory of 4G reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges;

Re: [PATCH] [dma-coherent] Fix integer overflow in the reserved-memory dma allocation

2020-03-09 Thread Kevin Grandemange
On 3/9/20 2:56 PM, Robin Murphy wrote: > On 09/03/2020 11:02 am, Kevin Grandemange wrote: >> pageno is an int and the PAGE_SHIFT shift is done on an int, >> overflowing if the memory is bigger than 2G >> >> This can be reproduced using for example a reserved-memory of 4G > > Nit: the example shows

[PATCH 1/2] iommu/vt-d: dmar: replace WARN_TAINT with pr_warn + add_taint

2020-03-09 Thread Hans de Goede
Quoting from the comment describing the WARN functions in include/asm-generic/bug.h: * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report * significant kernel issues that need prompt attention if they should ever * appear at runtime. * * Do not use these macros when checking for

[PATCH 0/2] iommu/vt-d: replace WARN_TAINT with pr_warn + add_taint

2020-03-09 Thread Hans de Goede
Hi All, The iommu/vt-d code calls WARN_TAINT(... TAINT_FIRMWARE_WORKAROUND ...) in various places. Since the firmware is outside of the kernel's control this should not be using the WARN_TAINT macro for this, calling the WARN* macros based on external inputs is wrong, as there is nothing we can do

[PATCH 2/2] iommu/vt-d: dmar_parse_one_rmrr: replace WARN_TAINT with pr_warn + add_taint

2020-03-09 Thread Hans de Goede
Quoting from the comment describing the WARN functions in include/asm-generic/bug.h: * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report * significant kernel issues that need prompt attention if they should ever * appear at runtime. * * Do not use these macros when checking for

[PATCH] [dma-coherent] Fix integer overflow in the reserved-memory dma allocation

2020-03-09 Thread Kevin Grandemange
pageno is an int and the PAGE_SHIFT shift is done on an int, overflowing if the memory is bigger than 2G This can be reproduced using for example a reserved-memory of 4G reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges;

Re: [PATCH] [dma-coherent] Fix integer overflow in the reserved-memory dma allocation

2020-03-09 Thread Robin Murphy
On 09/03/2020 11:02 am, Kevin Grandemange wrote: pageno is an int and the PAGE_SHIFT shift is done on an int, overflowing if the memory is bigger than 2G This can be reproduced using for example a reserved-memory of 4G Nit: the example shows 16GB, not 4. reserved-memory {

Re: [PATCH v4 23/26] iommu/arm-smmu-v3: Add stall support for platform devices

2020-03-09 Thread Jonathan Cameron
On Wed, 4 Mar 2020 15:08:33 +0100 Jean-Philippe Brucker wrote: > On Thu, Feb 27, 2020 at 06:17:26PM +, Jonathan Cameron wrote: > > On Mon, 24 Feb 2020 19:23:58 +0100 > > Jean-Philippe Brucker wrote: > > > > > From: Jean-Philippe Brucker > > > > > > The SMMU provides a Stall model for ha