Hi Daniel,
On 2020/2/18 15:42, Daniel Drake wrote:
From: Jon Derrick
The PCI devices handled by intel-iommu may have a DMA requester on
another bus, such as VMD subdevices needing to use the VMD endpoint.
The real DMA device is now used for the DMA mapping, but one case was
missed earlier: if
On Mon, Feb 17, 2020 at 07:29:18PM +0100, Jean-Philippe Brucker wrote:
> On Thu, Feb 13, 2020 at 02:56:00PM -0600, Rob Herring wrote:
> > Similar to commit 2af2e72b18b4 ("iommu/arm-smmu-v3: Defer TLB
> > invalidation until ->iotlb_sync()"), build up a list of ATC invalidation
> > commands and submi
Hi Baolu,
On Tue, Feb 18, 2020 at 10:38:14AM +0800, Lu Baolu wrote:
> > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> > index 42cdcce1602e..32f43695a22b 100644
> > --- a/drivers/iommu/intel-iommu.c
> > +++ b/drivers/iommu/intel-iommu.c
> > @@ -2541,9 +2541,6 @@ static vo
We have noticed these kernel warnings on APQ 8016 SBC (dragonboard
410c ) running stable rc 5.5, 5.4 branches and linux mainline and
linux-next master branches.
This warning started happening from linux mainline 5.3 onwards (2019-08-29)
[5.488128] [ cut here ]
[5.
Hi,
On 10/16/19 1:49 AM, Yian Chen wrote:
> VT-d RMRR (Reserved Memory Region Reporting) regions are reserved
> for device use only and should not be part of allocable memory pool of OS.
>
> BIOS e820_table reports complete memory map to OS, including OS usable
> memory ranges and BIOS reserved m
Hi Joerg,
On 2020/2/18 17:28, Joerg Roedel wrote:
Hi Baolu,
On Tue, Feb 18, 2020 at 10:38:14AM +0800, Lu Baolu wrote:
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 42cdcce1602e..32f43695a22b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu
Hi Robin,
On Mon, Jan 06, 2020 at 01:26:58PM +, Robin Murphy wrote:
> On 04/01/2020 12:20 am, Brian Masney wrote:
> > When attempting to load the qcom-iommu driver, and an -EPROBE_DEFER
> > error occurs, the following attempted NULL pointer deference occurs:
> >
> > Unable to handle kern
On 18/02/2020 12:04 pm, Stephan Gerhold wrote:
[...]
Are you going to send a patch for the diff below?
AFAICT this problem still exists in 5.6-rc2.
Your patch also seems to fix a warning during probe deferral on arm64
that has been around for quite a while. (At least for me...)
(See
https://lo
Hi Joerg and Baolu,
I'm chasing down one last issue. I'm waiting to hear back from them
testing with Joerg's patchset, but I'm guessing this will still pop
up. It looks like right around when the domain switch occurs in
iommu_need_mapping there are some dmar faults (below is from 5.6-rc1
plus ear
On Tue Feb 18 20, Joerg Roedel wrote:
Hi Baolu,
On Tue, Feb 18, 2020 at 10:38:14AM +0800, Lu Baolu wrote:
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 42cdcce1602e..32f43695a22b 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
>
On Tue, Feb 18, 2020 at 07:54:52PM +0800, Lu Baolu wrote:
> Looks good to me now. For all patches in this series,
>
> Acked-by: Lu Baolu
Thanks, queued the fixes for v5.6.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfound
Cc: "David S. Miller"
Cc: net...@vger.kernel.org
Signed-off-by: Rob Herring
---
Do not apply yet.
drivers/net/ethernet/Kconfig |1 -
drivers/net/ethernet/Makefile |1 -
drivers/net/ethernet/calxeda/Kconfig |9 -
drivers/net/ethernet/calxeda/Makefile |2 -
drive
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Signed-off-by: Rob Herring
---
Do not apply yet.
drivers/cpufreq/Kconfig.arm | 10 ---
drivers/cpufreq/Makefile | 3 +-
drivers/cpufreq/cpufreq-dt-platdev.c | 3 -
drivers/cpufreq/highbank-cpufreq.c
Cc: Borislav Petkov
Cc: Mauro Carvalho Chehab
Cc: Tony Luck
Cc: James Morse
Cc: Robert Richter
Cc: linux-e...@vger.kernel.org
Signed-off-by: Rob Herring
---
Do not apply yet.
MAINTAINERS | 6 -
drivers/edac/Kconfig| 14 --
drivers/edac/Makefile |
Calxeda has been defunct for 6 years now. Use of Calxeda servers carried
on for some time afterwards primarily as distro builders for 32-bit ARM.
AFAIK, those systems have been retired in favor of 32-bit VMs on 64-bit
hosts.
The other use of Calxeda Midway I'm aware of was testing 32-bit ARM KVM
s
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Signed-off-by: Rob Herring
---
Do not apply yet.
drivers/clk/Makefile | 1 -
drivers/clk/clk-highbank.c | 329 -
2 files changed, 330 deletions(-)
delete mode 100644 drivers/clk/clk-highbank.c
diff --gi
Cc: "Rafael J. Wysocki"
Cc: Daniel Lezcano
Cc: linux...@vger.kernel.org
Signed-off-by: Rob Herring
---
Do not apply yet.
drivers/cpuidle/Kconfig.arm | 7 ---
drivers/cpuidle/Makefile | 1 -
drivers/cpuidle/cpuidle-calxeda.c | 72 ---
3 files changed
Signed-off-by: Rob Herring
---
MAINTAINERS | 8 --
arch/arm/Kconfig| 2 -
arch/arm/Kconfig.debug | 12 +-
arch/arm/Makefile | 1 -
arch/arm/configs/multi_v7_defconfig | 5 -
arch/arm/mach-highbank/Kconfig |
Cc: Jens Axboe
Cc: linux-...@vger.kernel.org
Signed-off-by: Rob Herring
---
Do not apply yet.
drivers/ata/Kconfig | 9 -
drivers/ata/Makefile| 1 -
drivers/ata/sata_highbank.c | 635
3 files changed, 645 deletions(-)
delete mode 100644 d
Cc: Will Deacon
Cc: Robin Murphy
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Rob Herring
---
Do not apply yet.
drivers/iommu/arm-smmu-impl.c | 43 ---
1 file changed, 43 deletions(-)
diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers
Cc: devicet...@vger.kernel.org
Signed-off-by: Rob Herring
---
.../devicetree/bindings/arm/calxeda.yaml | 22 --
.../devicetree/bindings/arm/calxeda/l2ecc.txt | 15 ---
.../devicetree/bindings/ata/sata_highbank.txt | 44 ---
.../devicetree/bindings/clock/calxeda.tx
Cc: Eric Auger
Cc: Alex Williamson
Cc: Cornelia Huck
Cc: k...@vger.kernel.org
Signed-off-by: Rob Herring
---
Do not apply yet.
drivers/vfio/platform/reset/Kconfig | 8 --
drivers/vfio/platform/reset/Makefile | 2 -
.../reset/vfio_platform_calxedaxgmac.c| 74 --
Cc: devicet...@vger.kernel.org
Signed-off-by: Rob Herring
---
arch/arm/boot/dts/Makefile| 3 -
arch/arm/boot/dts/ecx-2000.dts| 103 -
arch/arm/boot/dts/ecx-common.dtsi | 230 --
arch/arm/boot/dts/highbank.dts| 161 -
4
> +static bool attach_deferred(struct device *dev)
> +{
> + return dev->archdata.iommu == DEFER_DEVICE_DOMAIN_INFO;
> +}
This is not a very useful helper.
> +
> /**
> * is_downstream_to_pci_bridge - test if a device belongs to the PCI
> *sub-hierarchy of a can
> +static void do_deferred_attach(struct device *dev)
> {
> + struct iommu_domain *domain;
>
> + dev->archdata.iommu = NULL;
> + domain = iommu_get_domain_for_dev(dev);
> + if (domain)
> + intel_iommu_attach_device(domain, dev);
> +}
> +
> +static struct dmar_domain *
On Tue, Feb 18, 2020 at 11:13:16AM -0600, Rob Herring wrote:
> Cc: Will Deacon
> Cc: Robin Murphy
> Cc: Joerg Roedel
> Cc: iommu@lists.linux-foundation.org
> Signed-off-by: Rob Herring
> ---
> Do not apply yet.
Please? ;)
> drivers/iommu/arm-smmu-impl.c | 43 -
On Tue, Feb 18, 2020 at 11:13:21AM -0600, Rob Herring wrote:
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Herring
> ---
> .../devicetree/bindings/arm/calxeda.yaml | 22 --
> .../devicetree/bindings/arm/calxeda/l2ecc.txt | 15 ---
> .../devicetree/bindings/ata/sata_highba
Extending the Arm SMMU driver to allow for modular builds changed
KBUILD_MODNAME to be "arm_smmu_mod" so that a single module could be
built from the multiple existing object files without the need to rename
any source files.
This inadvertently changed the name of the driver parameters, which may
On Tue, Feb 18, 2020 at 11:23 AM Will Deacon wrote:
>
> On Tue, Feb 18, 2020 at 11:13:21AM -0600, Rob Herring wrote:
> > Cc: devicet...@vger.kernel.org
> > Signed-off-by: Rob Herring
> > ---
> > .../devicetree/bindings/arm/calxeda.yaml | 22 --
> > .../devicetree/bindings/arm/calxed
On 18/02/2020 5:20 pm, Will Deacon wrote:
On Tue, Feb 18, 2020 at 11:13:16AM -0600, Rob Herring wrote:
Cc: Will Deacon
Cc: Robin Murphy
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Rob Herring
---
Do not apply yet.
Please? ;)
drivers/iommu/arm-smmu-impl.c |
On Tue, Feb 18, 2020 at 11:13:15AM -0600, Rob Herring wrote:
> Cc: Borislav Petkov
> Cc: Mauro Carvalho Chehab
> Cc: Tony Luck
> Cc: James Morse
> Cc: Robert Richter
> Cc: linux-e...@vger.kernel.org
> Signed-off-by: Rob Herring
> ---
> Do not apply yet.
>
> MAINTAINERS |
On 18/02/2020 5:27 pm, Will Deacon wrote:
Extending the Arm SMMU driver to allow for modular builds changed
KBUILD_MODNAME to be "arm_smmu_mod" so that a single module could be
built from the multiple existing object files without the need to rename
any source files.
This inadvertently changed t
On 18/02/2020 18:13, Rob Herring wrote:
> Cc: "Rafael J. Wysocki"
> Cc: Daniel Lezcano
> Cc: linux...@vger.kernel.org
> Signed-off-by: Rob Herring
Acked-by: Daniel Lezcano
> ---
> Do not apply yet.
>
> drivers/cpuidle/Kconfig.arm | 7 ---
> drivers/cpuidle/Makefile | 1 -
>
Currently, the implementation of qcom_iommu_domain_free() is guaranteed
to do one of two things: WARN() and leak everything, or dereference NULL
and crash. That alone is terrible, but in fact the whole idea of trying
to track the liveness of a domain via the qcom_domain->iommu pointer as
a sanity c
On Tue, 18 Feb 2020 11:13:10 -0600
Rob Herring wrote:
Hi,
> Calxeda has been defunct for 6 years now. Use of Calxeda servers carried
> on for some time afterwards primarily as distro builders for 32-bit ARM.
> AFAIK, those systems have been retired in favor of 32-bit VMs on 64-bit
> hosts.
>
>
On Tue, Jan 28, 2020 at 2:34 PM Jordan Crouse wrote:
>
> Domains which are being set up for split pagetables usually want to be
> on a specific context bank for hardware reasons. Force the context
> bank for domains with the split-pagetable quirk to context bank 0.
> If context bank 0 is taken, mo
On Tue, Feb 18, 2020 at 04:13:57PM +0530, Naresh Kamboju wrote:
> We have noticed these kernel warnings on APQ 8016 SBC (dragonboard
> 410c ) running stable rc 5.5, 5.4 branches and linux mainline and
> linux-next master branches.
>
> This warning started happening from linux mainline 5.3 onwards
On 18/02/2020 6:23 pm, Greg Kroah-Hartman wrote:
[...]
Can you bisect to find the offending commit?
This particular presentation appears to be down to the DRM driver
starting to call of_platform_depopulate(), but it's merely exposing
badness in the IOMMU driver that's been there from day 1. I
On Tue, Feb 18, 2020 at 10:19:53AM -0800, Rob Clark wrote:
> On Tue, Jan 28, 2020 at 2:34 PM Jordan Crouse wrote:
> >
> > Domains which are being set up for split pagetables usually want to be
> > on a specific context bank for hardware reasons. Force the context
> > bank for domains with the spli
On Tue, Feb 18, 2020 at 12:14 PM Andre Przywara wrote:
>
> On Tue, 18 Feb 2020 11:13:10 -0600
> Rob Herring wrote:
>
> Hi,
>
> > Calxeda has been defunct for 6 years now. Use of Calxeda servers carried
> > on for some time afterwards primarily as distro builders for 32-bit ARM.
> > AFAIK, those s
Hi Russell,
this series fixes the arm dma coherent allocator to take the bus dma
mask into account, similar to what other architectures do. Without
this devices that support 64-bit mask, but are limited by the
interconnect won't work properly.
___
iommu
The DMA coherent allocator needs to take bus limits into account for
picking the zone that the memory is allocated from.
Reported-by: Roger Quadros
Signed-off-by: Christoph Hellwig
Tested-by: Peter Ujfalusi
Tested-by: Roger Quadros
---
arch/arm/mm/dma-mapping.c | 2 +-
1 file changed, 1 inser
The core DMA code already checks for valid DMA masks earlier on, and
doesn't allow NULL struct device pointers. Remove the now not required
checks.
Signed-off-by: Christoph Hellwig
---
arch/arm/mm/dma-mapping.c | 41 ---
1 file changed, 4 insertions(+), 37 de
Merge __dma_supported into its only caller, and move the resulting
function so that it doesn't need a forward declaration. Also mark
it static as there are no callers outside of dma-mapping.c.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-iommu.h | 2 --
arch/arm/mm/dma-mapping
On Tue, Feb 18, 2020 at 06:31:51PM +, Robin Murphy wrote:
> On 18/02/2020 6:23 pm, Greg Kroah-Hartman wrote:
> [...]
> > Can you bisect to find the offending commit?
>
> This particular presentation appears to be down to the DRM driver starting
> to call of_platform_depopulate(), but it's mere
On 2/18/20 10:40 AM, Rob Herring wrote:
> On Tue, Feb 18, 2020 at 12:14 PM Andre Przywara
> wrote:
>>
>> On Tue, 18 Feb 2020 11:13:10 -0600
>> Rob Herring wrote:
>>
>> Hi,
>>
>>> Calxeda has been defunct for 6 years now. Use of Calxeda servers carried
>>> on for some time afterwards primarily as
On Tue, Feb 18, 2020 at 06:12:41PM +, Robin Murphy wrote:
> Currently, the implementation of qcom_iommu_domain_free() is guaranteed
> to do one of two things: WARN() and leak everything, or dereference NULL
> and crash. That alone is terrible, but in fact the whole idea of trying
> to track the
The following changes since commit d5226fa6dbae0569ee43ecfc08bdcd6770fc4755:
Linux 5.5 (2020-01-26 16:23:03 -0800)
are available in the Git repository at:
git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.6
for you to fetch changes up to 75467ee48a5e04cf3ae3cb39aea6adee73
intel_iommu_iova_to_phys() has a bug when it translates an IOVA for a huge
page onto its corresponding physical address. This commit fixes the bug by
accomodating the level of page entry for the IOVA and adds IOVA's lower
address to the physical address.
Signed-off-by: Yonghyun Hwang
---
drivers
Hi Jerry,
On 2020/2/18 23:45, Jerry Snitselaar wrote:
Hi Joerg and Baolu,
I'm chasing down one last issue. I'm waiting to hear back from them
testing with Joerg's patchset, but I'm guessing this will still pop
up. It looks like right around when the domain switch occurs in
iommu_need_mapping th
The pull request you sent on Tue, 18 Feb 2020 13:15:00 -0800:
> git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0a44cac8105059eb756ed4276e932e54e1ba004d
Thank you!
--
Deet-doot-dot, I am a bot.
ht
On 2020-02-17 07:50, Robin Murphy wrote:
On 17/02/2020 8:01 am, Christoph Hellwig wrote:
On Fri, Feb 14, 2020 at 02:58:16PM -0800, Isaac J. Manjarres wrote:
From: Liam Mark
Some devices have a memory map which contains gaps or holes.
In order for the device to have as much IOVA space as possi
On 18-02-20, 11:13, Rob Herring wrote:
> Cc: "Rafael J. Wysocki"
> Cc: Viresh Kumar
> Cc: linux...@vger.kernel.org
> Signed-off-by: Rob Herring
> ---
> Do not apply yet.
>
> drivers/cpufreq/Kconfig.arm | 10 ---
> drivers/cpufreq/Makefile | 3 +-
> drivers/cpufreq/cpufr
Hi Yonghyun,
Thanks for the patch.
On 2020/2/19 6:23, Yonghyun Hwang wrote:
intel_iommu_iova_to_phys() has a bug when it translates an IOVA for a huge
page onto its corresponding physical address. This commit fixes the bug by
accomodating the level of page entry for the IOVA and adds IOVA's low
From: Jon Derrick
The PCI devices handled by intel-iommu may have a DMA requester on
another bus, such as VMD subdevices needing to use the VMD endpoint.
The real DMA device is now used for the DMA mapping, but one case was
missed earlier: if the VMD device (and hence subdevices too) are under
I
Hi,
On 2020/2/19 11:21, Daniel Drake wrote:
From: Jon Derrick
The PCI devices handled by intel-iommu may have a DMA requester on
another bus, such as VMD subdevices needing to use the VMD endpoint.
The real DMA device is now used for the DMA mapping, but one case was
missed earlier: if the VMD
On Wed Feb 19 20, Lu Baolu wrote:
Hi Jerry,
On 2020/2/18 23:45, Jerry Snitselaar wrote:
Hi Joerg and Baolu,
I'm chasing down one last issue. I'm waiting to hear back from them
testing with Joerg's patchset, but I'm guessing this will still pop
up. It looks like right around when the domain swi
Hi Baolu, Yonghyun
On Wed, Feb 19, 2020 at 11:15:36AM +0800, Lu Baolu wrote:
> Hi Yonghyun,
>
> Thanks for the patch.
>
> On 2020/2/19 6:23, Yonghyun Hwang wrote:
> > intel_iommu_iova_to_phys() has a bug when it translates an IOVA for a huge
> > page onto its corresponding physical address. This
58 matches
Mail list logo
