>>> Could you also please send the me the FW version (output of "ethtool -i
>> eth0")
>>
>> Hi Sathya, thanks for your help. FW version is 4.6.247.5 driver version is
>> 4.4.161.0s
>
> Hi Wang, this issue (a FW bug) was fixed in the 4.9 FW series.
> The HP qualified FW (ver 4.9.416.0) is availa
Any device requiring to be attached to an iommu_domain must have
valid archdata containing the necessary iommu information, which
is SoC-specific. Add a check in the omap_iommu_attach_dev to make
sure that the device has valid archdata before accessing
different SoC-specific fields of the archdata.
A device is tied to an iommu through its archdata field. The archdata
is allocated on the fly for DT-based devices automatically through the
.add_device iommu ops. The current logic incorrectly assigned the name
of the IOMMU user device, instead of the name of the IOMMU device as
required by the at
Hi,
This is an updated series addressing Laurent's review comments on
Patch1. Patch2 is unchanged from the previous series.
Patches are based on 3.17-rc3.
v1:
http://marc.info/?l=linux-omap&m=140978874026176&w=2
Suman Anna (2):
iommu/omap: Check for valid archdata in attach_dev
iommu/omap:
Hi Laurent,
>
> On Wednesday 03 September 2014 18:58:32 Suman Anna wrote:
>> A device is tied to an iommu through its archdata field. The archdata
>> is allocated on the fly for DT-based devices automatically through the
>> .add_device iommu ops. The current logic incorrectly assigned the name
>> o
On 09/04/2014 06:38 AM, Varun Sethi wrote:
> iommu_group_get_for_dev determines the iommu group for the PCI device and adds
> the device to the group.
>
> In the PAMU driver we were again adding the device to the same group without
> checking
> if the device already had an iommu group. This resul
Hi Laurent,
> On Wednesday 03 September 2014 18:58:31 Suman Anna wrote:
>> Any device requiring to be attached to an iommu_domain must have
>> valid archdata containing the necessary iommu information, which
>> is SoC-specific. Add a check in the omap_iommu_attach_dev to make
>> sure that the devi
In order for nested translation to work correctly, we need to ensure
that the maximum output address size from stage-1 is <= the maximum
supported input address size to stage-2. The latter is currently defined
by VA_BITS, since we make use of the CPU page table functions for
allocating out tables a
From: Robin Murphy
MMU-401 is similar to MMU-400, but updated with limited ARMv8 support.
Signed-off-by: Robin Murphy
Signed-off-by: Will Deacon
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 1 +
drivers/iommu/arm-smmu.c | 1 +
2 files changed, 2 inser
In preparation for nested translation support, stick a pointer to the
iommu_domain in dev->archdata.iommu. This makes it much easier to grab
hold of the physical group configuration (e.g. cbndx) when dealing with
vSMMU accesses from a guest.
Signed-off-by: Will Deacon
---
drivers/iommu/arm-smmu.
Hi all,
This series is a collection of ARM SMMU updates I have in my tree that
I'd like to get merged for 3.18. This has mostly come out of the vSMMU
work (which is still some way off, as proper testing is proving to be
difficult), but Robin has also added minimal support for MMU-401.
There are a
From: Robin Murphy
The SMMU driver was relying on a quirk of MMU-500 r2px to identify
the correct architecture version. Since this does not apply to other
implementations, make the architecture version for each supported
implementation explicit.
While we're at it, remove the unnecessary #ifdef s
When debugging and testing code on an SMMU that supports nested
translation, it can be useful to restrict the driver to a particular
stage of translation.
This patch adds a module parameter to the ARM SMMU driver to allow this
by restricting the ability of the probe() code to detect support for
on
Arbitrary integer division is not available in all ARM CPUs, so the GCC
may spit out calls to helper functions which are not implemented in
the kernel.
This patch avoids these problems in the SMMU driver by using page shift
instead of page size, so that divisions by the page size (as required
by t
Whilst the driver currently creates one IOMMU group per device, this
will soon change when we start supporting non-transparent PCI bridges
which require all upstream masters to be assigned to the same address
space.
This patch reworks our IOMMU group code so that we can easily support
multi-master
> -Original Message-
> From: Yijing Wang [mailto:wangyij...@huawei.com]
>
> [Adding the Emulex driver developers to Cc for some input on the
> device,
> and why it might use wrong request ids]
>
> On Mon, Aug 25, 2014 at 02:44:59PM +0800, Yijing Wang wrote:
> >
iommu_group_get_for_dev determines the iommu group for the PCI device and adds
the device to the group.
In the PAMU driver we were again adding the device to the same group without
checking
if the device already had an iommu group. This resulted in the following
warning.
sysfs: cannot create du
> -Original Message-
> From: Joerg Roedel [mailto:j...@8bytes.org]
> Sent: Thursday, September 04, 2014 3:44 PM
> To: Sethi Varun-B16395
> Cc: iommu@lists.linux-foundation.org; alex.william...@redhat.com; Medve
> Emilian-EMMEDVE1; linuxppc-...@ozlabs.org; linux-ker...@vger.kernel.org
> Su
18 matches
Mail list logo
