All of lore.kernel.org
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
	linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org,
	iommu@lists.linux-foundation.org, devel@acpica.org
Cc: linuxarm@huawei.com, steven.price@arm.com, guohanjun@huawei.com,
	Sami.Mujawar@arm.com, robin.murphy@arm.com,
	wanghuiqiang@huawei.com
Subject: Re: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
Date: Thu, 15 Apr 2021 11:39:17 +0200	[thread overview]
Message-ID: <a64025cd-3312-9621-1771-8e0430220ed8@redhat.com> (raw)
In-Reply-To: <20201119121150.3316-3-shameerali.kolothum.thodi@huawei.com>

Hi Shameer,
On 11/19/20 1:11 PM, Shameer Kolothum wrote:
> Add support for parsing RMR node information from ACPI.
> Find associated stream ids and smmu node info from the
> RMR node and populate a linked list with RMR memory
> descriptors.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/acpi/arm64/iort.c | 122 +++++++++++++++++++++++++++++++++++++-
>  1 file changed, 121 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 9929ff50c0c0..a9705aa35028 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -40,6 +40,25 @@ struct iort_fwnode {
>  static LIST_HEAD(iort_fwnode_list);
>  static DEFINE_SPINLOCK(iort_fwnode_lock);
>  
> +struct iort_rmr_id {
> +	u32  sid;
> +	struct acpi_iort_node *smmu;
> +};
> +
> +/*
> + * One entry for IORT RMR.
> + */
> +struct iort_rmr_entry {
> +	struct list_head list;
> +
> +	unsigned int rmr_ids_num;
> +	struct iort_rmr_id *rmr_ids;
> +
> +	struct acpi_iort_rmr_desc *rmr_desc;
> +};
> +
> +static LIST_HEAD(iort_rmr_list);         /* list of RMR regions from ACPI */
> +
>  /**
>   * iort_set_fwnode() - Create iort_fwnode and use it to register
>   *		       iommu data in the iort_fwnode_list
> @@ -393,7 +412,8 @@ static struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
>  		if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
>  		    node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX ||
>  		    node->type == ACPI_IORT_NODE_SMMU_V3 ||
> -		    node->type == ACPI_IORT_NODE_PMCG) {
> +		    node->type == ACPI_IORT_NODE_PMCG ||
> +		    node->type == ACPI_IORT_NODE_RMR) {
>  			*id_out = map->output_base;
>  			return parent;
>  		}
> @@ -1647,6 +1667,103 @@ static void __init iort_enable_acs(struct acpi_iort_node *iort_node)
>  #else
>  static inline void iort_enable_acs(struct acpi_iort_node *iort_node) { }
>  #endif
> +static int iort_rmr_desc_valid(struct acpi_iort_rmr_desc *desc)
> +{
> +	struct iort_rmr_entry *e;
> +	u64 end, start = desc->base_address, length = desc->length;
> +
> +	if (!IS_ALIGNED(start, SZ_64K) || !IS_ALIGNED(length, SZ_64K))
> +		return -EINVAL;
> +
> +	end = start + length - 1;
> +
> +	/* Check for address overlap */
I don't get this check. What is the problem if you attach the same range
to different stream ids. Shouldn't you check there is no overlap for the
same sid?


> +	list_for_each_entry(e, &iort_rmr_list, list) {
> +		u64 e_start = e->rmr_desc->base_address;
> +		u64 e_end = e_start + e->rmr_desc->length - 1;
> +
> +		if (start <= e_end && end >= e_start)
> +			return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int __init iort_parse_rmr(struct acpi_iort_node *iort_node)
> +{
> +	struct iort_rmr_id *rmr_ids, *ids;
> +	struct iort_rmr_entry *e;
> +	struct acpi_iort_rmr *rmr;
> +	struct acpi_iort_rmr_desc *rmr_desc;
> +	u32 map_count = iort_node->mapping_count;
> +	int i, ret = 0, desc_count = 0;
> +
> +	if (iort_node->type != ACPI_IORT_NODE_RMR)
> +		return 0;
> +
> +	if (!iort_node->mapping_offset || !map_count) {
> +		pr_err(FW_BUG "Invalid ID mapping, skipping RMR node %p\n",
> +		       iort_node);
> +		return -EINVAL;
> +	}
> +
> +	rmr_ids = kmalloc(sizeof(*rmr_ids) * map_count, GFP_KERNEL);
> +	if (!rmr_ids)
> +		return -ENOMEM;
> +
> +	/* Retrieve associated smmu and stream id */
> +	ids = rmr_ids;
nit: do you need both rmr_ids and ids?
> +	for (i = 0; i < map_count; i++, ids++) {
> +		ids->smmu = iort_node_get_id(iort_node, &ids->sid, i);
> +		if (!ids->smmu) {
> +			pr_err(FW_BUG "Invalid SMMU reference, skipping RMR node %p\n",
> +			       iort_node);
> +			ret = -EINVAL;
> +			goto out;
> +		}
> +	}
> +
> +	/* Retrieve RMR data */
> +	rmr = (struct acpi_iort_rmr *)iort_node->node_data;
> +	if (!rmr->rmr_offset || !rmr->rmr_count) {
> +		pr_err(FW_BUG "Invalid RMR descriptor array, skipping RMR node %p\n",
> +		       iort_node);
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	rmr_desc = ACPI_ADD_PTR(struct acpi_iort_rmr_desc, iort_node,
> +				rmr->rmr_offset);
> +
> +	for (i = 0; i < rmr->rmr_count; i++, rmr_desc++) {
> +		ret = iort_rmr_desc_valid(rmr_desc);
> +		if (ret) {
> +			pr_err(FW_BUG "Invalid RMR descriptor[%d] for node %p, skipping...\n",
> +			       i, iort_node);
> +			goto out;
so I understand you skip the whole node and not just that rmr desc,
otherwise you would continue. so in that case don't you need to free
both rmr_ids and already allocated 'e'?
> +		}
> +
> +		e = kmalloc(sizeof(*e), GFP_KERNEL);
> +		if (!e) {
> +			ret = -ENOMEM;
> +			goto out;
> +		}
> +
> +		e->rmr_ids_num = map_count;
> +		e->rmr_ids = rmr_ids;
> +		e->rmr_desc = rmr_desc;
> +
> +		list_add_tail(&e->list, &iort_rmr_list);
> +		desc_count++;
> +	}
> +
> +	return 0;
> +
> +out:
> +	if (!desc_count)
don't you want to test ret instead? see comment above. + free allocated ''e'
> +		kfree(rmr_ids);
> +	return ret;
> +}
>  
>  static void __init iort_init_platform_devices(void)
>  {
> @@ -1676,6 +1793,9 @@ static void __init iort_init_platform_devices(void)
>  
>  		iort_enable_acs(iort_node);
>  
> +		if (iort_table->revision == 1)
> +			iort_parse_rmr(iort_node);
> +
>  		ops = iort_get_dev_cfg(iort_node);
>  		if (ops) {
>  			fwnode = acpi_alloc_fwnode_static();
> 
Thanks

Eric


WARNING: multiple messages have this Message-ID (diff)
From: Auger Eric <eric.auger@redhat.com>
To: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
	linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org,
	iommu@lists.linux-foundation.org, devel@acpica.org
Cc: linuxarm@huawei.com, steven.price@arm.com, guohanjun@huawei.com,
	Sami.Mujawar@arm.com, robin.murphy@arm.com,
	wanghuiqiang@huawei.com
Subject: Re: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
Date: Thu, 15 Apr 2021 11:39:17 +0200	[thread overview]
Message-ID: <a64025cd-3312-9621-1771-8e0430220ed8@redhat.com> (raw)
In-Reply-To: <20201119121150.3316-3-shameerali.kolothum.thodi@huawei.com>

Hi Shameer,
On 11/19/20 1:11 PM, Shameer Kolothum wrote:
> Add support for parsing RMR node information from ACPI.
> Find associated stream ids and smmu node info from the
> RMR node and populate a linked list with RMR memory
> descriptors.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/acpi/arm64/iort.c | 122 +++++++++++++++++++++++++++++++++++++-
>  1 file changed, 121 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 9929ff50c0c0..a9705aa35028 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -40,6 +40,25 @@ struct iort_fwnode {
>  static LIST_HEAD(iort_fwnode_list);
>  static DEFINE_SPINLOCK(iort_fwnode_lock);
>  
> +struct iort_rmr_id {
> +	u32  sid;
> +	struct acpi_iort_node *smmu;
> +};
> +
> +/*
> + * One entry for IORT RMR.
> + */
> +struct iort_rmr_entry {
> +	struct list_head list;
> +
> +	unsigned int rmr_ids_num;
> +	struct iort_rmr_id *rmr_ids;
> +
> +	struct acpi_iort_rmr_desc *rmr_desc;
> +};
> +
> +static LIST_HEAD(iort_rmr_list);         /* list of RMR regions from ACPI */
> +
>  /**
>   * iort_set_fwnode() - Create iort_fwnode and use it to register
>   *		       iommu data in the iort_fwnode_list
> @@ -393,7 +412,8 @@ static struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
>  		if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
>  		    node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX ||
>  		    node->type == ACPI_IORT_NODE_SMMU_V3 ||
> -		    node->type == ACPI_IORT_NODE_PMCG) {
> +		    node->type == ACPI_IORT_NODE_PMCG ||
> +		    node->type == ACPI_IORT_NODE_RMR) {
>  			*id_out = map->output_base;
>  			return parent;
>  		}
> @@ -1647,6 +1667,103 @@ static void __init iort_enable_acs(struct acpi_iort_node *iort_node)
>  #else
>  static inline void iort_enable_acs(struct acpi_iort_node *iort_node) { }
>  #endif
> +static int iort_rmr_desc_valid(struct acpi_iort_rmr_desc *desc)
> +{
> +	struct iort_rmr_entry *e;
> +	u64 end, start = desc->base_address, length = desc->length;
> +
> +	if (!IS_ALIGNED(start, SZ_64K) || !IS_ALIGNED(length, SZ_64K))
> +		return -EINVAL;
> +
> +	end = start + length - 1;
> +
> +	/* Check for address overlap */
I don't get this check. What is the problem if you attach the same range
to different stream ids. Shouldn't you check there is no overlap for the
same sid?


> +	list_for_each_entry(e, &iort_rmr_list, list) {
> +		u64 e_start = e->rmr_desc->base_address;
> +		u64 e_end = e_start + e->rmr_desc->length - 1;
> +
> +		if (start <= e_end && end >= e_start)
> +			return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int __init iort_parse_rmr(struct acpi_iort_node *iort_node)
> +{
> +	struct iort_rmr_id *rmr_ids, *ids;
> +	struct iort_rmr_entry *e;
> +	struct acpi_iort_rmr *rmr;
> +	struct acpi_iort_rmr_desc *rmr_desc;
> +	u32 map_count = iort_node->mapping_count;
> +	int i, ret = 0, desc_count = 0;
> +
> +	if (iort_node->type != ACPI_IORT_NODE_RMR)
> +		return 0;
> +
> +	if (!iort_node->mapping_offset || !map_count) {
> +		pr_err(FW_BUG "Invalid ID mapping, skipping RMR node %p\n",
> +		       iort_node);
> +		return -EINVAL;
> +	}
> +
> +	rmr_ids = kmalloc(sizeof(*rmr_ids) * map_count, GFP_KERNEL);
> +	if (!rmr_ids)
> +		return -ENOMEM;
> +
> +	/* Retrieve associated smmu and stream id */
> +	ids = rmr_ids;
nit: do you need both rmr_ids and ids?
> +	for (i = 0; i < map_count; i++, ids++) {
> +		ids->smmu = iort_node_get_id(iort_node, &ids->sid, i);
> +		if (!ids->smmu) {
> +			pr_err(FW_BUG "Invalid SMMU reference, skipping RMR node %p\n",
> +			       iort_node);
> +			ret = -EINVAL;
> +			goto out;
> +		}
> +	}
> +
> +	/* Retrieve RMR data */
> +	rmr = (struct acpi_iort_rmr *)iort_node->node_data;
> +	if (!rmr->rmr_offset || !rmr->rmr_count) {
> +		pr_err(FW_BUG "Invalid RMR descriptor array, skipping RMR node %p\n",
> +		       iort_node);
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	rmr_desc = ACPI_ADD_PTR(struct acpi_iort_rmr_desc, iort_node,
> +				rmr->rmr_offset);
> +
> +	for (i = 0; i < rmr->rmr_count; i++, rmr_desc++) {
> +		ret = iort_rmr_desc_valid(rmr_desc);
> +		if (ret) {
> +			pr_err(FW_BUG "Invalid RMR descriptor[%d] for node %p, skipping...\n",
> +			       i, iort_node);
> +			goto out;
so I understand you skip the whole node and not just that rmr desc,
otherwise you would continue. so in that case don't you need to free
both rmr_ids and already allocated 'e'?
> +		}
> +
> +		e = kmalloc(sizeof(*e), GFP_KERNEL);
> +		if (!e) {
> +			ret = -ENOMEM;
> +			goto out;
> +		}
> +
> +		e->rmr_ids_num = map_count;
> +		e->rmr_ids = rmr_ids;
> +		e->rmr_desc = rmr_desc;
> +
> +		list_add_tail(&e->list, &iort_rmr_list);
> +		desc_count++;
> +	}
> +
> +	return 0;
> +
> +out:
> +	if (!desc_count)
don't you want to test ret instead? see comment above. + free allocated ''e'
> +		kfree(rmr_ids);
> +	return ret;
> +}
>  
>  static void __init iort_init_platform_devices(void)
>  {
> @@ -1676,6 +1793,9 @@ static void __init iort_init_platform_devices(void)
>  
>  		iort_enable_acs(iort_node);
>  
> +		if (iort_table->revision == 1)
> +			iort_parse_rmr(iort_node);
> +
>  		ops = iort_get_dev_cfg(iort_node);
>  		if (ops) {
>  			fwnode = acpi_alloc_fwnode_static();
> 
Thanks

Eric

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Auger Eric <eric.auger@redhat.com>
To: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
	linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org,
	iommu@lists.linux-foundation.org, devel@acpica.org
Cc: linuxarm@huawei.com, steven.price@arm.com, guohanjun@huawei.com,
	Sami.Mujawar@arm.com, robin.murphy@arm.com,
	wanghuiqiang@huawei.com
Subject: Re: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
Date: Thu, 15 Apr 2021 11:39:17 +0200	[thread overview]
Message-ID: <a64025cd-3312-9621-1771-8e0430220ed8@redhat.com> (raw)
In-Reply-To: <20201119121150.3316-3-shameerali.kolothum.thodi@huawei.com>

Hi Shameer,
On 11/19/20 1:11 PM, Shameer Kolothum wrote:
> Add support for parsing RMR node information from ACPI.
> Find associated stream ids and smmu node info from the
> RMR node and populate a linked list with RMR memory
> descriptors.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/acpi/arm64/iort.c | 122 +++++++++++++++++++++++++++++++++++++-
>  1 file changed, 121 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 9929ff50c0c0..a9705aa35028 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -40,6 +40,25 @@ struct iort_fwnode {
>  static LIST_HEAD(iort_fwnode_list);
>  static DEFINE_SPINLOCK(iort_fwnode_lock);
>  
> +struct iort_rmr_id {
> +	u32  sid;
> +	struct acpi_iort_node *smmu;
> +};
> +
> +/*
> + * One entry for IORT RMR.
> + */
> +struct iort_rmr_entry {
> +	struct list_head list;
> +
> +	unsigned int rmr_ids_num;
> +	struct iort_rmr_id *rmr_ids;
> +
> +	struct acpi_iort_rmr_desc *rmr_desc;
> +};
> +
> +static LIST_HEAD(iort_rmr_list);         /* list of RMR regions from ACPI */
> +
>  /**
>   * iort_set_fwnode() - Create iort_fwnode and use it to register
>   *		       iommu data in the iort_fwnode_list
> @@ -393,7 +412,8 @@ static struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
>  		if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
>  		    node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX ||
>  		    node->type == ACPI_IORT_NODE_SMMU_V3 ||
> -		    node->type == ACPI_IORT_NODE_PMCG) {
> +		    node->type == ACPI_IORT_NODE_PMCG ||
> +		    node->type == ACPI_IORT_NODE_RMR) {
>  			*id_out = map->output_base;
>  			return parent;
>  		}
> @@ -1647,6 +1667,103 @@ static void __init iort_enable_acs(struct acpi_iort_node *iort_node)
>  #else
>  static inline void iort_enable_acs(struct acpi_iort_node *iort_node) { }
>  #endif
> +static int iort_rmr_desc_valid(struct acpi_iort_rmr_desc *desc)
> +{
> +	struct iort_rmr_entry *e;
> +	u64 end, start = desc->base_address, length = desc->length;
> +
> +	if (!IS_ALIGNED(start, SZ_64K) || !IS_ALIGNED(length, SZ_64K))
> +		return -EINVAL;
> +
> +	end = start + length - 1;
> +
> +	/* Check for address overlap */
I don't get this check. What is the problem if you attach the same range
to different stream ids. Shouldn't you check there is no overlap for the
same sid?


> +	list_for_each_entry(e, &iort_rmr_list, list) {
> +		u64 e_start = e->rmr_desc->base_address;
> +		u64 e_end = e_start + e->rmr_desc->length - 1;
> +
> +		if (start <= e_end && end >= e_start)
> +			return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int __init iort_parse_rmr(struct acpi_iort_node *iort_node)
> +{
> +	struct iort_rmr_id *rmr_ids, *ids;
> +	struct iort_rmr_entry *e;
> +	struct acpi_iort_rmr *rmr;
> +	struct acpi_iort_rmr_desc *rmr_desc;
> +	u32 map_count = iort_node->mapping_count;
> +	int i, ret = 0, desc_count = 0;
> +
> +	if (iort_node->type != ACPI_IORT_NODE_RMR)
> +		return 0;
> +
> +	if (!iort_node->mapping_offset || !map_count) {
> +		pr_err(FW_BUG "Invalid ID mapping, skipping RMR node %p\n",
> +		       iort_node);
> +		return -EINVAL;
> +	}
> +
> +	rmr_ids = kmalloc(sizeof(*rmr_ids) * map_count, GFP_KERNEL);
> +	if (!rmr_ids)
> +		return -ENOMEM;
> +
> +	/* Retrieve associated smmu and stream id */
> +	ids = rmr_ids;
nit: do you need both rmr_ids and ids?
> +	for (i = 0; i < map_count; i++, ids++) {
> +		ids->smmu = iort_node_get_id(iort_node, &ids->sid, i);
> +		if (!ids->smmu) {
> +			pr_err(FW_BUG "Invalid SMMU reference, skipping RMR node %p\n",
> +			       iort_node);
> +			ret = -EINVAL;
> +			goto out;
> +		}
> +	}
> +
> +	/* Retrieve RMR data */
> +	rmr = (struct acpi_iort_rmr *)iort_node->node_data;
> +	if (!rmr->rmr_offset || !rmr->rmr_count) {
> +		pr_err(FW_BUG "Invalid RMR descriptor array, skipping RMR node %p\n",
> +		       iort_node);
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	rmr_desc = ACPI_ADD_PTR(struct acpi_iort_rmr_desc, iort_node,
> +				rmr->rmr_offset);
> +
> +	for (i = 0; i < rmr->rmr_count; i++, rmr_desc++) {
> +		ret = iort_rmr_desc_valid(rmr_desc);
> +		if (ret) {
> +			pr_err(FW_BUG "Invalid RMR descriptor[%d] for node %p, skipping...\n",
> +			       i, iort_node);
> +			goto out;
so I understand you skip the whole node and not just that rmr desc,
otherwise you would continue. so in that case don't you need to free
both rmr_ids and already allocated 'e'?
> +		}
> +
> +		e = kmalloc(sizeof(*e), GFP_KERNEL);
> +		if (!e) {
> +			ret = -ENOMEM;
> +			goto out;
> +		}
> +
> +		e->rmr_ids_num = map_count;
> +		e->rmr_ids = rmr_ids;
> +		e->rmr_desc = rmr_desc;
> +
> +		list_add_tail(&e->list, &iort_rmr_list);
> +		desc_count++;
> +	}
> +
> +	return 0;
> +
> +out:
> +	if (!desc_count)
don't you want to test ret instead? see comment above. + free allocated ''e'
> +		kfree(rmr_ids);
> +	return ret;
> +}
>  
>  static void __init iort_init_platform_devices(void)
>  {
> @@ -1676,6 +1793,9 @@ static void __init iort_init_platform_devices(void)
>  
>  		iort_enable_acs(iort_node);
>  
> +		if (iort_table->revision == 1)
> +			iort_parse_rmr(iort_node);
> +
>  		ops = iort_get_dev_cfg(iort_node);
>  		if (ops) {
>  			fwnode = acpi_alloc_fwnode_static();
> 
Thanks

Eric


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-04-15  9:39 UTC|newest]

Thread overview: 123+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-19 12:11 [RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node Shameer Kolothum
2020-11-19 12:11 ` [Devel] " Shameer Kolothum
2020-11-19 12:11 ` Shameer Kolothum
2020-11-19 12:11 ` Shameer Kolothum
2020-11-19 12:11 ` [RFC PATCH v2 1/8] ACPICA: IORT: Update for revision E Shameer Kolothum
2020-11-19 12:11   ` [Devel] " Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2021-03-22 10:36   ` Shameerali Kolothum Thodi
2021-03-22 10:36     ` [Devel] " Shameerali Kolothum Thodi
2021-03-22 10:36     ` Shameerali Kolothum Thodi
2021-03-22 10:36     ` Shameerali Kolothum Thodi
2021-03-22 21:57     ` Kaneda, Erik
2021-03-22 21:57       ` Kaneda, Erik
2021-03-22 21:57       ` Kaneda, Erik
2021-03-23 15:53       ` Lorenzo Pieralisi
2021-03-23 15:53         ` [Devel] " Lorenzo Pieralisi
2021-03-23 15:53         ` Lorenzo Pieralisi
2021-03-23 15:53         ` Lorenzo Pieralisi
2021-03-23 18:51         ` Kaneda, Erik
2021-03-23 18:51           ` Kaneda, Erik
2021-03-23 18:51           ` Kaneda, Erik
2021-03-24  9:50           ` Lorenzo Pieralisi
2021-03-24  9:50             ` [Devel] " Lorenzo Pieralisi
2021-03-24  9:50             ` Lorenzo Pieralisi
2021-03-24  9:50             ` Lorenzo Pieralisi
2021-03-25  8:40     ` Jon Nettleton
2021-03-25  8:40       ` Jon Nettleton
2021-03-25  8:40       ` Jon Nettleton
2021-03-25 15:54       ` Shameerali Kolothum Thodi
2021-03-25 15:54         ` [Devel] " Shameerali Kolothum Thodi
2021-03-25 15:54         ` Shameerali Kolothum Thodi
2021-03-25 15:54         ` Shameerali Kolothum Thodi
2021-04-15  7:27   ` Auger Eric
2021-04-15  7:27     ` Auger Eric
2021-04-15  7:27     ` Auger Eric
2020-11-19 12:11 ` [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing Shameer Kolothum
2020-11-19 12:11   ` [Devel] " Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2021-04-15  9:39   ` Auger Eric [this message]
2021-04-15  9:39     ` Auger Eric
2021-04-15  9:39     ` Auger Eric
2021-04-15 10:30     ` Shameerali Kolothum Thodi
2021-04-15 10:30       ` [Devel] " Shameerali Kolothum Thodi
2021-04-15 10:30       ` Shameerali Kolothum Thodi
2021-04-15 10:30       ` Shameerali Kolothum Thodi
2020-11-19 12:11 ` [RFC PATCH v2 3/8] iommu/dma: Introduce generic helper to retrieve RMR info Shameer Kolothum
2020-11-19 12:11   ` [Devel] " Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-11-19 12:11 ` [RFC PATCH v2 4/8] ACPI/IORT: Add RMR memory regions reservation helper Shameer Kolothum
2020-11-19 12:11   ` [Devel] " Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-11-19 12:11 ` [RFC PATCH v2 5/8] iommu/arm-smmu-v3: Introduce strtab init helper Shameer Kolothum
2020-11-19 12:11   ` [Devel] " Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-11-19 12:11 ` [RFC PATCH v2 6/8] iommu/arm-smmu-v3: Add bypass flag to arm_smmu_write_strtab_ent() Shameer Kolothum
2020-11-19 12:11   ` [Devel] " Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-11-19 12:11 ` [RFC PATCH v2 7/8] iommu/arm-smmu-v3: Get associated RMR info and install bypass STE Shameer Kolothum
2020-11-19 12:11   ` [Devel] " Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-11-19 12:11 ` [RFC PATCH v2 8/8] iommu/arm-smmu-v3: Reserve any RMR regions associated with a dev Shameer Kolothum
2020-11-19 12:11   ` [Devel] " Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-11-19 12:11   ` Shameer Kolothum
2020-12-10 10:25 ` [RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node Steven Price
2020-12-10 10:25   ` Steven Price
2020-12-10 10:25   ` Steven Price
2020-12-14 10:55   ` Shameerali Kolothum Thodi
2020-12-14 10:55     ` [Devel] " Shameerali Kolothum Thodi
2020-12-14 10:55     ` Shameerali Kolothum Thodi
2020-12-14 10:55     ` Shameerali Kolothum Thodi
2020-12-14 12:33     ` Robin Murphy
2020-12-14 12:33       ` [Devel] " Robin Murphy
2020-12-14 12:33       ` Robin Murphy
2020-12-14 12:33       ` Robin Murphy
2020-12-14 13:42       ` Steven Price
2020-12-14 13:42         ` Steven Price
2020-12-14 13:42         ` Steven Price
2020-12-14 14:47         ` Shameerali Kolothum Thodi
2020-12-14 14:47           ` [Devel] " Shameerali Kolothum Thodi
2020-12-14 14:47           ` Shameerali Kolothum Thodi
2020-12-14 14:47           ` Shameerali Kolothum Thodi
2020-12-17 14:47           ` Jon Nettleton
2020-12-17 14:47             ` Jon Nettleton
2020-12-17 14:47             ` Jon Nettleton
2020-12-17 15:42             ` Shameerali Kolothum Thodi
2020-12-17 15:42               ` [Devel] " Shameerali Kolothum Thodi
2020-12-17 15:42               ` Shameerali Kolothum Thodi
2020-12-17 15:42               ` Shameerali Kolothum Thodi
2020-12-17 15:53               ` Jon Nettleton
2020-12-17 15:53                 ` Jon Nettleton
2020-12-17 15:53                 ` Jon Nettleton
2020-12-18 10:53                 ` Jon Nettleton
2020-12-18 10:53                   ` Jon Nettleton
2020-12-18 10:53                   ` Jon Nettleton
2021-01-04  8:55                   ` Shameerali Kolothum Thodi
2021-01-04  8:55                     ` [Devel] " Shameerali Kolothum Thodi
2021-01-04  8:55                     ` Shameerali Kolothum Thodi
2021-01-04  8:55                     ` Shameerali Kolothum Thodi
2021-01-04 10:55                     ` Jon Nettleton
2021-01-04 10:55                       ` Jon Nettleton
2021-01-04 10:55                       ` Jon Nettleton
2021-04-09  9:50 ` Auger Eric
2021-04-09  9:50   ` Auger Eric
2021-04-09  9:50   ` Auger Eric
2021-04-09 10:08   ` Shameerali Kolothum Thodi
2021-04-09 10:08     ` [Devel] " Shameerali Kolothum Thodi
2021-04-09 10:08     ` Shameerali Kolothum Thodi
2021-04-09 10:08     ` Shameerali Kolothum Thodi
2021-04-15  9:48 ` Auger Eric
2021-04-15  9:48   ` Auger Eric
2021-04-15  9:48   ` Auger Eric
2021-04-15 10:37   ` Shameerali Kolothum Thodi
2021-04-15 10:37     ` [Devel] " Shameerali Kolothum Thodi
2021-04-15 10:37     ` Shameerali Kolothum Thodi
2021-04-15 10:37     ` Shameerali Kolothum Thodi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a64025cd-3312-9621-1771-8e0430220ed8@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=Sami.Mujawar@arm.com \
    --cc=devel@acpica.org \
    --cc=guohanjun@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linuxarm@huawei.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=steven.price@arm.com \
    --cc=wanghuiqiang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.