his series has a dependency on the ACPICA header patch
here[1].
Tested on a Kunpeng920 server machine with SMMUv3, the 3408iMR RAID
controller card works as expected,
Tested-by: Hanjun Guo
Thanks
Hanjun
___
iommu mailing list
iommu@lists.linux-foundation.
On 2022/5/4 0:33, Shameer Kolothum wrote:
This will provide a way for SMMU drivers to retrieve StreamIDs
associated with IORT RMR nodes and use that to set bypass settings
for those IDs.
Tested-by: Steven Price
Signed-off-by: Shameer Kolothum
Reviewed-by: Hanjun Guo
Thanks
Hanjun
Tested-by: Steven Price
Signed-off-by: Shameer Kolothum
Reviewed-by: Hanjun Guo
Thanks
Hanjun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
]
Reviewed-by: Lorenzo Pieralisi
Reviewed-by: Christoph Hellwig
Tested-by: Steven Price
Signed-off-by: Shameer Kolothum
Reviewed-by: Hanjun Guo
Thanks
Hanjun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org
the
function to return void instead.
Reviewed-by: Christoph Hellwig
Tested-by: Steven Price
Signed-off-by: Shameer Kolothum
Reviewed-by: Hanjun Guo
Thanks
Hanjun
___
iommu mailing list
iommu@lists.linux-foundation.org
https
sted by Jon N.
I use the updated firmware from Huiqiang(Cced), tested on
my Kunpeng 920 server, the 3408iMRraid and 3416iMRraid can
work as expected with SMMUv3 enabled.
Tested-by: Hanjun Guo
Tested-by: Huiqiang Wang
Thanks
Hanjun
___
iommu mailing
amp; ACPI_IORT_NC_STALL_SUPPORTED)
+ props[1] = PROPERTY_ENTRY_BOOL("dma-can-stall");
if (device_add_properties(dev, props))
dev_warn(dev, "Could not add device properties\n");
Acked-by: Hanjun Guo
___
iomm
: Jonathan Cameron
Acked-by: Will Deacon
Reviewed-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
include/linux/iommu.h | 2 --
drivers/acpi/arm64/iort.c | 13 +++--
Acked-by: Hanjun Guo
___
iom
On 2020/11/12 20:55, Jean-Philippe Brucker wrote:
Copy the "Stall supported" bit, that tells whether a platform device
supports stall, into the fwspec struct.
Signed-off-by: Jean-Philippe Brucker
Acked-by: Hanjun Guo
___
iommu mailing
Robin Murphy
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Anshuman Khandual
Signed-off-by: Ard Biesheuvel
[nsaenz: Rebased, removed documentation change and add declaration in
acpi_iort.h]
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v3:
- Use min_not_zero()
- Check ACPI revision
- R
On 2020/10/16 15:27, Hanjun Guo wrote:
The patch only takes the address limit field into account if its value
> 0.
Sorry I missed the if (*->memory_address_limit) check, thanks
for the reminding.
Also, before commit 7fb89e1d44cb6aec ("ACPI/IORT: take _DMA methods
into accoun
Hi Ard,
On 2020/10/16 14:54, Ard Biesheuvel wrote:
On Fri, 16 Oct 2020 at 08:51, Hanjun Guo wrote:
On 2020/10/16 2:03, Catalin Marinas wrote:
On Thu, Oct 15, 2020 at 10:26:18PM +0800, Hanjun Guo wrote:
On 2020/10/15 3:12, Nicolas Saenz Julienne wrote:
From: Ard Biesheuvel
We recently
On 2020/10/16 2:03, Catalin Marinas wrote:
On Thu, Oct 15, 2020 at 10:26:18PM +0800, Hanjun Guo wrote:
On 2020/10/15 3:12, Nicolas Saenz Julienne wrote:
From: Ard Biesheuvel
We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than
size >= 32), but with the
wrong DMA size in IORT, we still have the ZONE_DMA created which
is actually not needed?
Cc: Jeremy Linton
Cc: Lorenzo Pieralisi
Cc: Nicolas Saenz Julienne
Cc: Rob Herring
Cc: Christoph Hellwig
Cc: Robin Murphy
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Anshuman Kha
On 2020/7/2 16:22, Hanjun Guo wrote:
As I said in previous email, I'm not against this patch, and seems
have no regressions for platforms that using named component node
such as D05/D06 (I will test it shortly to make sure), but it's better
to update the wording of the spec (even
On 2020/7/9 17:21, Lorenzo Pieralisi wrote:
On Thu, Jul 02, 2020 at 04:22:00PM +0800, Hanjun Guo wrote:
Hi Robin,
On 2020/7/2 0:12, Robin Murphy wrote:
On 2020-06-30 14:04, Hanjun Guo wrote:
On 2020/6/30 18:24, Lorenzo Pieralisi wrote:
On Tue, Jun 30, 2020 at 11:06:41AM +0800, Hanjun Guo
Hi Robin,
On 2020/7/2 0:12, Robin Murphy wrote:
On 2020-06-30 14:04, Hanjun Guo wrote:
On 2020/6/30 18:24, Lorenzo Pieralisi wrote:
On Tue, Jun 30, 2020 at 11:06:41AM +0800, Hanjun Guo wrote:
[...]
For devices that aren't described in the DSDT - IORT translations
are determined by
On 2020/6/30 18:24, Lorenzo Pieralisi wrote:
On Tue, Jun 30, 2020 at 11:06:41AM +0800, Hanjun Guo wrote:
[...]
For devices that aren't described in the DSDT - IORT translations
are determined by their ACPI parent device. Do you see/Have you
found any issue with this approach ?
The spec
On 2020/6/29 17:05, Lorenzo Pieralisi wrote:
On Mon, Jun 29, 2020 at 12:24:43PM +0800, Hanjun Guo wrote:
Hi Lorenzo,
On 2020/6/19 16:20, Lorenzo Pieralisi wrote:
When the iort_match_node_callback is invoked for a named component
the match should be executed upon a device with an ACPI
first parent node with a companion set and
check the parent node against the named component entry to check whether
there is a match and therefore an IORT node describing the in/out ID
translation for the device has been found.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc
On 2020/3/26 23:08, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Use the accessor functions instead of directly dereferencing
> dev->iommu_fwspec.
>
> Tested-by: Hanjun Guo
> Reviewed-by: Jean-Philippe Brucker
> Signed-off-by: Joerg Roedel
> ---
> drivers/
On 2020/3/6 18:09, Jean-Philippe Brucker wrote:
> On Fri, Mar 06, 2020 at 04:39:37PM +0800, Hanjun Guo wrote:
>> Hi Joerg,
>>
>> On 2020/2/28 23:08, Joerg Roedel wrote:
>>> Hi,
>>>
>>> here is a patch-set to rename iommu_param to dev_iommu and
>
---
> include/linux/iommu.h | 4
> 2 files changed, 15 deletions(-)
Acked-by: Hanjun Guo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
drivers/acpi/pci_root.c | 3 +++
> include/linux/acpi_iort.h | 8
Acked-by: Hanjun Guo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
s patch set against 5.6-rc2 on a Kunpeng920 ARM server,
I just confirmed that this patch set didn't break anything in
my box with ACPI booting, PCI devices work as expected, FWIW,
Tested-by: Hanjun Guo
Thanks
Hanjun
___
iommu mailing list
iommu@
Hi Joerg,
On 2020/2/28 23:08, Joerg Roedel wrote:
> Hi,
>
> here is a patch-set to rename iommu_param to dev_iommu and
> establish it as a struct for generic per-device iommu-data.
> Also move the iommu_fwspec pointer from struct device into
> dev_iommu to have less iommu-related pointers in stru
structure in order to enable PASID for platform
> devices.
>
> Signed-off-by: Jean-Philippe Brucker
> ---
> drivers/acpi/arm64/iort.c | 18 ++
> 1 file changed, 18 insertions(+)
Acked-by: Hanjun Guo
___
iommu mai
fffULL)
> #define IORT_IRQ_TRIGGER_MASK(irq) ((irq >> 32) & 0xULL)
>
> -/*
> - * PMCG model identifiers for use in smmu pmu driver. Please note
> - * that this is purely for the use of software and has nothing to
> - * do with hardware or with IORT specifica
Hi John,
On 2019/9/30 22:33, John Garry wrote:
> In the IORT, a PMCG node includes a node reference to its associated
> device.
>
> Set the PMCG platform device parent device for future referencing.
>
> For now, we only consider setting for when the associated component is an
> SMMUv3.
>
> Sign
Hi Zhen,
On 2019/4/7 20:41, Zhen Lei wrote:
> As Robin Murphy's suggestion:
> "It's also not necessarily obvious to the user how this interacts with
> IOMMU_DEFAULT_PASSTHROUGH, so if we really do go down this route, maybe it
> would be better to refactor the whole lot into a single selection of s
Hi Jean,
On 2019/1/31 22:55, Jean-Philippe Brucker wrote:
> Hi,
>
> On 31/01/2019 13:52, Zhen Lei wrote:
>> Currently, many peripherals are faster than before. For example, the top
>> speed of the older netcard is 10Gb/s, and now it's more than 25Gb/s. But
>> when iommu page-table mapping enabled
tions(-)
Robin and Lorenzo know this better than me, but it's
pretty straight forward to me,
Acked-by: Hanjun Guo
Thanks
Hanjun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 2018/12/11 21:43, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Replace the iommu-check with a proper and readable function
> call.
>
> Cc: Lorenzo Pieralisi
> Acked-by: Robin Murphy
> Signed-off-by: Joerg Roedel
Acked-by: Ha
Signed-off-by: Joerg Roedel
> ---
> drivers/acpi/arm64/iort.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
Acked-by: Hanjun Guo
Thanks
Hanjun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 2018/7/13 9:48, Leizhen (ThunderTown) wrote:
>
>
> On 2018/7/13 1:01, Will Deacon wrote:
>> On Thu, Jul 12, 2018 at 05:28:43PM +0800, Zhen Lei wrote:
>>> Stream bypass is not security. A malicious device can be hot plugged
>>> without match any drivers, but it can access to any memory. So chan
Hi Robin,
On 2018/5/31 19:24, Robin Murphy wrote:
> On 31/05/18 08:42, Zhen Lei wrote:
>> In common, a IOMMU unmap operation follow the below steps:
>> 1. remove the mapping in page table of the specified iova range
>> 2. execute tlbi command to invalid the mapping which is cached in TLB
>> 3. wai
On 2017/8/31 16:20, Yisheng Xie wrote:
Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:
https://www.spinics.net/lists/arm-kernel/msg565155.html
But for some platform devices(aka on-chip integrated devices), there is also
SVM requirement, which works based on the SMMU
On 2017/8/3 21:35, Hanjun Guo wrote:
> On 2017/8/3 0:21, Lorenzo Pieralisi wrote:
>> > Patch that I will send upstream below, please check, thanks.
>> >
>> > -- >8 --
>> > Subject: [PATCH] ACPI/IORT: numa: Add numa node mapping for smmuv3 devices
>>
On 2017/8/3 0:21, Lorenzo Pieralisi wrote:
> Patch that I will send upstream below, please check, thanks.
>
> -- >8 --
> Subject: [PATCH] ACPI/IORT: numa: Add numa node mapping for smmuv3 devices
>
> ARM IORT specification(rev. C) has added provision to define proximity
> domain in SMMUv3 IORT tab
Hi Ganapat,
On 2017/6/8 12:44, Ganapatrao Kulkarni wrote:
> Add code to parse proximity domain in SMMUv3 IORT table to
> set numa node mapping for smmuv3 devices.
>
> Signed-off-by: Ganapatrao Kulkarni
> ---
> drivers/acpi/arm64/iort.c | 28 ++--
> 1 file changed, 26 inse
On 2017/5/17 18:13, Shameerali Kolothum Thodi wrote:
#ifdef CONFIG_ACPI
+static void acpi_smmu_get_options(u32 model, struct arm_smmu_device
+*smmu) {
+ if (model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
+ smmu->options |= ARM_SMMU_OPT_PAGE0_REGS_ONLY;
>
HiSIlicon hip06/07 boards
+
/* Masks for Flags field above */
#define ACPI_IORT_SMMU_V3_COHACC_OVERRIDE (1)
Looks good to me,
Reviewed-by: Hanjun Guo
By the way, how will this patch be merged? There are pending patches
on top of it, Rafael suggested to work with ACPICA upstream first [1],
Robin, will wo
[+Cc Lv Zheng]
On 2017/6/2 0:21, Lorenzo Pieralisi wrote:
> On Thu, Jun 01, 2017 at 07:35:37PM +0530, Ganapatrao Kulkarni wrote:
>> ARM IORT specification has provision to define Proximity domain
>> in SMMUv3 IORT table. Adding required code to parse Proximity domain of
>> SMMUv3 IORT table. Parse
On 2017/5/5 20:08, Geetha sowjanya wrote:
From: Linu Cherian
Add SMMUv3 model definition for ThunderX2.
Signed-off-by: Linu Cherian
Signed-off-by: Geetha Sowjanya
---
include/acpi/actbl2.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
in
On 2017/4/12 0:57, Sunil Kovvuri wrote:
On Tue, Apr 11, 2017 at 9:29 PM, Robin Murphy wrote:
On 11/04/17 15:42, linucher...@gmail.com wrote:
From: Linu Cherian
Add SMMuV3 model definitions.
Signed-off-by: Linu Cherian
---
include/acpi/actbl2.h | 5 +
1 file changed, 5 insertions(+)
d
On 02/03/2017 03:01 AM, Nate Watterson wrote:
On 2017-02-01 13:52, Lorenzo Pieralisi wrote:
I debugged the issue and Nate's fix is correct, the fact that you
can't it hit it with mainline is just a matter of timing because it has
to do with the CTX pointer value (we OR it with the existing valu
si patches, and test it on Hisilicon D03 (ARM64 platform with
SMMUv3) with ACPI, it boots ok as before and the native NIC and
SAS (platform devices) are working properly.
for ACPI and the core code changes:
Tested-by: Hanjun Guo
Thanks
Hanjun
___
iom
Hi Lorenzo, Sricharan,
On 01/24/2017 08:37 PM, Lorenzo Pieralisi wrote:
[+hanjun, tomasz, sinan]
It is quite a key patchset, I would be glad if they can test on their
respective platforms with IORT.
ACPI patches are conflict with my acpi platform msi patches (I need
them to enable devices on
ions.
>
> Signed-off-by: Lorenzo Pieralisi
> Cc: Will Deacon
> Cc: Hanjun Guo
Add this patch on top of your v9 acpi smmu patchset,
tested on Hisilicon D03 (ARM64), devices with SMMU
enabled work fine,
Tested-by: Hanjun Guo
Reviewed-by: Hanjun Guo
Thanks
Hanjun
__
DMA
configuration for a device.
Signed-off-by: Lorenzo Pieralisi
Acked-by: Rafael J. Wysocki [ACPI core]
Reviewed-by: Tomasz Nowicki
Tested-by: Hanjun Guo
Tested-by: Tomasz Nowicki
Cc: Hanjun Guo
Acked-by: Hanjun Guo
Thanks
Hanjun
___
iommu
: Lorenzo Pieralisi
Reviewed-by: Tomasz Nowicki
Tested-by: Hanjun Guo
Tested-by: Tomasz Nowicki
Cc: Hanjun Guo
Cc: Tomasz Nowicki
Cc: "Rafael J. Wysocki"
---
drivers/acpi/arm64/iort.c | 39 +++
1 file changed, 39 insertions(+)
Acked-by:
Tested-by: Hanjun Guo
Tested-by: Tomasz Nowicki
Cc: Hanjun Guo
Cc: Tomasz Nowicki
Cc: "Rafael J. Wysocki"
---
drivers/acpi/arm64/iort.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
Acked-by: Hanjun Guo
Tha
when the corresponding ARM SMMU
driver support is added to the kernel) to be used to define the
platform devices names, init the IOMMUs, count their resources and
finally initialize them.
Signed-off-by: Lorenzo Pieralisi
Reviewed-by: Tomasz Nowicki
Tested-by: Hanjun Guo
Tested-by: Tomasz Nowicki
a trivial function that allows detecting
if a given IORT node type is present or not in the ACPI table, providing
an ACPI IORT equivalent for of_find_matching_node().
Signed-off-by: Lorenzo Pieralisi
Reviewed-by: Tomasz Nowicki
Tested-by: Hanjun Guo
Tested-by: Tomasz Nowicki
Cc: Hanjun Guo
On 2016/11/21 18:01, Lorenzo Pieralisi wrote:
This patch series is v9 of a previous posting:
https://lkml.org/lkml/2016/11/16/386
v8 -> v9
- Updated bypass flag handling in ARM SMMU v3 according to
reviews
- Removed SMMUv1/v2 configuration interrupt handling
-
On 11/09/2016 10:19 PM, Lorenzo Pieralisi wrote:
This patch series is v7 of a previous posting:
https://lkml.org/lkml/2016/10/18/506
v6 -> v7
- Rebased against v4.9-rc4
- Fixed IORT probing on ACPI systems with missing IORT table
- Fixed SMMUv1/v2 global interrupt detect
ssful SMMU probe, whilst the third is
indicative of the kind of catastrophic system failure which isn't going
to get much further anyway. Consequently, there is little harm in
ignoring the return value either way.
CC: Lorenzo Pieralisi
Signed-off-by: Robin Murphy
Tested-by: Hanjun Guo
it on Hisilicon D03 board with SMMv3
enabled, USB and SAS are working properly with configuration
in IORT (yes, I need to add patch from Robin - iommu/arm-smmu: Don't
inadvertently reject multiple SMMUv3s),
Tested-by: Hanjun Guo
Thanks
Hanjun
___
iommu m
On 2016/9/13 16:24, Lorenzo Pieralisi wrote:
On Tue, Sep 13, 2016 at 04:15:31PM +0800, Hanjun Guo wrote:
[...]
+static acpi_status __init iort_match_iommu_callback(struct
acpi_iort_node *node,
+void *context)
+{
+int ret;
+struct fwnode_handle *fwnode
common set of components (eg IOMMUs) rather than a
specific node type.
Upgrade the IORT iort_node_map_rid() API to work with a
type mask instead of a single node type so that it can
be used for mappings that span multiple components types
(ie IOMMUs).
Signed-off-by: Lorenzo Pieralisi
Cc: Hanjun Guo
and hook it up in the ACPI kernel layer that implements DMA
configuration for a device.
Signed-off-by: Lorenzo Pieralisi
Cc: Hanjun Guo
Cc: Tomasz Nowicki
Cc: "Rafael J. Wysocki"
---
drivers/acpi/arm64/iort.c | 96
+++
drivers/acpi/scan.c
iort_iommu_config)
that contains hooks (to be defined when the corresponding ARM SMMU
driver support is added to the kernel) to be used to define the
platform devices names, init the IOMMUs, count their resources and
finally initialize them.
Signed-off-by: Lorenzo Pieralisi
Cc: Hanjun Guo
Cc
On 2016/9/5 22:57, Lorenzo Pieralisi wrote:
On Mon, Sep 05, 2016 at 09:19:43PM +0800, Hanjun Guo wrote:
On 2016/8/15 23:23, Lorenzo Pieralisi wrote:
The platform device kernel API does not provide functions to
retrieve a platform device through the corresponding struct
device fwnode pointer
we need such
API to retrieve the platform device with fwnode handle, actually
Kefeng introduced a similar patch [1], but your patch is more
generic, so this patch make sense to me,
Reviewed-by: Hanjun Guo
Thanks
Hanjun
[1]: https://patchwork.kern
components and their respective fwnode.
Signed-off-by: Lorenzo Pieralisi
Cc: Hanjun Guo
Cc: Tomasz Nowicki
Cc: "Rafael J. Wysocki"
---
drivers/acpi/arm64/iort.c | 65 +++
include/linux/iort.h | 8 ++
2 files changed, 73 insertion
/* __IORT_H__ */
Reviewed-by: Hanjun Guo
Thanks
Hanjun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
ism as FWNODE_IRQCHIP as mentioned in
change log,
Reviewed-by: Hanjun Guo
Thanks
Hanjun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Output Reference : 004C /* point to smmu
pcie */
[0004] Flags (decoded below) : 0001
Single Mapping : 1
I mounted a USB storage and copy the data (should trigger the DMA :)),
and it works fine (if the wrong stream id is configured, I can'
On 2016/6/21 22:27, Lorenzo Pieralisi wrote:
Hi Hanjun,
On Tue, Jun 21, 2016 at 06:37:17PM +0800, Hanjun Guo wrote:
Hi Lorenzo,
On 2016/6/7 21:30, Lorenzo Pieralisi wrote:
This RFC patch series is v2 of a previous posting:
https://lkml.org/lkml/2016/4/14/702
v1 -> v2:
- Rebased
Hi Lorenzo,
On 2016/6/7 21:30, Lorenzo Pieralisi wrote:
This RFC patch series is v2 of a previous posting:
https://lkml.org/lkml/2016/4/14/702
v1 -> v2:
- Rebased on top of dependencies series [1][2][3](v4.7-rc1)
- Removed IOMMU fwnode generalization
- Implemented ARM S
70 matches
Mail list logo
