All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Auger Eric <eric.auger@redhat.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"devel@acpica.org" <devel@acpica.org>
Cc: Linuxarm <linuxarm@huawei.com>,
	"steven.price@arm.com" <steven.price@arm.com>,
	"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>,
	"Sami.Mujawar@arm.com" <Sami.Mujawar@arm.com>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	wanghuiqiang <wanghuiqiang@huawei.com>
Subject: RE: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
Date: Thu, 15 Apr 2021 10:30:03 +0000	[thread overview]
Message-ID: <0c5ef81c82984f6eaabdc9b27ee79070@huawei.com> (raw)
In-Reply-To: <a64025cd-3312-9621-1771-8e0430220ed8@redhat.com>

Hi Eric,

> -----Original Message-----
> From: Auger Eric [mailto:eric.auger@redhat.com]
> Sent: 15 April 2021 10:39
> To: Shameerali Kolothum Thodi <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 <linuxarm@huawei.com>; steven.price@arm.com; Guohanjun
> (Hanjun Guo) <guohanjun@huawei.com>; Sami.Mujawar@arm.com;
> robin.murphy@arm.com; wanghuiqiang <wanghuiqiang@huawei.com>
> Subject: Re: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
> 
> 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?

That’s right. The check should be for memory descriptors within an RMR.
I got confused by the wordings in the IORT spec and that is now clarified
with Lorenzo here,

https://op-lists.linaro.org/pipermail/linaro-open-discussions/2021-April/000150.html

I will change this.
> 
> 
> > +	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?

Not really as the spec says it is M:1 mapping. So we only will have one 
single id here(also map_count for the node must be set to 1 as well).

> > +	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'?

Agree. This needs to be changed.

> > +		}
> > +
> > +		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'

Right. I will change it next revision.

Thanks for taking a look.

Regards,
Shameer

> > +		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: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Auger Eric <eric.auger@redhat.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"devel@acpica.org" <devel@acpica.org>
Cc: Linuxarm <linuxarm@huawei.com>,
	"steven.price@arm.com" <steven.price@arm.com>,
	"Guohanjun \(Hanjun Guo\)" <guohanjun@huawei.com>,
	"Sami.Mujawar@arm.com" <Sami.Mujawar@arm.com>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	wanghuiqiang <wanghuiqiang@huawei.com>
Subject: RE: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
Date: Thu, 15 Apr 2021 10:30:03 +0000	[thread overview]
Message-ID: <0c5ef81c82984f6eaabdc9b27ee79070@huawei.com> (raw)
In-Reply-To: <a64025cd-3312-9621-1771-8e0430220ed8@redhat.com>

Hi Eric,

> -----Original Message-----
> From: Auger Eric [mailto:eric.auger@redhat.com]
> Sent: 15 April 2021 10:39
> To: Shameerali Kolothum Thodi <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 <linuxarm@huawei.com>; steven.price@arm.com; Guohanjun
> (Hanjun Guo) <guohanjun@huawei.com>; Sami.Mujawar@arm.com;
> robin.murphy@arm.com; wanghuiqiang <wanghuiqiang@huawei.com>
> Subject: Re: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
> 
> 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?

That’s right. The check should be for memory descriptors within an RMR.
I got confused by the wordings in the IORT spec and that is now clarified
with Lorenzo here,

https://op-lists.linaro.org/pipermail/linaro-open-discussions/2021-April/000150.html

I will change this.
> 
> 
> > +	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?

Not really as the spec says it is M:1 mapping. So we only will have one 
single id here(also map_count for the node must be set to 1 as well).

> > +	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'?

Agree. This needs to be changed.

> > +		}
> > +
> > +		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'

Right. I will change it next revision.

Thanks for taking a look.

Regards,
Shameer

> > +		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: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Auger Eric <eric.auger@redhat.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"devel@acpica.org" <devel@acpica.org>
Cc: Linuxarm <linuxarm@huawei.com>,
	"steven.price@arm.com" <steven.price@arm.com>,
	"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>,
	"Sami.Mujawar@arm.com" <Sami.Mujawar@arm.com>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	wanghuiqiang <wanghuiqiang@huawei.com>
Subject: RE: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
Date: Thu, 15 Apr 2021 10:30:03 +0000	[thread overview]
Message-ID: <0c5ef81c82984f6eaabdc9b27ee79070@huawei.com> (raw)
In-Reply-To: <a64025cd-3312-9621-1771-8e0430220ed8@redhat.com>

Hi Eric,

> -----Original Message-----
> From: Auger Eric [mailto:eric.auger@redhat.com]
> Sent: 15 April 2021 10:39
> To: Shameerali Kolothum Thodi <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 <linuxarm@huawei.com>; steven.price@arm.com; Guohanjun
> (Hanjun Guo) <guohanjun@huawei.com>; Sami.Mujawar@arm.com;
> robin.murphy@arm.com; wanghuiqiang <wanghuiqiang@huawei.com>
> Subject: Re: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
> 
> 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?

That’s right. The check should be for memory descriptors within an RMR.
I got confused by the wordings in the IORT spec and that is now clarified
with Lorenzo here,

https://op-lists.linaro.org/pipermail/linaro-open-discussions/2021-April/000150.html

I will change this.
> 
> 
> > +	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?

Not really as the spec says it is M:1 mapping. So we only will have one 
single id here(also map_count for the node must be set to 1 as well).

> > +	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'?

Agree. This needs to be changed.

> > +		}
> > +
> > +		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'

Right. I will change it next revision.

Thanks for taking a look.

Regards,
Shameer

> > +		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

WARNING: multiple messages have this Message-ID (diff)
From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>
To: devel@acpica.org
Subject: [Devel] Re: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
Date: Thu, 15 Apr 2021 10:30:03 +0000	[thread overview]
Message-ID: <0c5ef81c82984f6eaabdc9b27ee79070@huawei.com> (raw)
In-Reply-To: a64025cd-3312-9621-1771-8e0430220ed8@redhat.com

[-- Attachment #1: Type: text/plain, Size: 7034 bytes --]

Hi Eric,

> -----Original Message-----
> From: Auger Eric [mailto:eric.auger(a)redhat.com]
> Sent: 15 April 2021 10:39
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>;
> linux-arm-kernel(a)lists.infradead.org; linux-acpi(a)vger.kernel.org;
> iommu(a)lists.linux-foundation.org; devel(a)acpica.org
> Cc: Linuxarm <linuxarm(a)huawei.com>; steven.price(a)arm.com; Guohanjun
> (Hanjun Guo) <guohanjun(a)huawei.com>; Sami.Mujawar(a)arm.com;
> robin.murphy(a)arm.com; wanghuiqiang <wanghuiqiang(a)huawei.com>
> Subject: Re: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
> 
> 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(a)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?

That’s right. The check should be for memory descriptors within an RMR.
I got confused by the wordings in the IORT spec and that is now clarified
with Lorenzo here,

https://op-lists.linaro.org/pipermail/linaro-open-discussions/2021-April/000150.html

I will change this.
> 
> 
> > +	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?

Not really as the spec says it is M:1 mapping. So we only will have one 
single id here(also map_count for the node must be set to 1 as well).

> > +	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'?

Agree. This needs to be changed.

> > +		}
> > +
> > +		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'

Right. I will change it next revision.

Thanks for taking a look.

Regards,
Shameer

> > +		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


  reply	other threads:[~2021-04-15 10:30 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
2021-04-15  9:39     ` Auger Eric
2021-04-15  9:39     ` Auger Eric
2021-04-15 10:30     ` Shameerali Kolothum Thodi [this message]
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=0c5ef81c82984f6eaabdc9b27ee79070@huawei.com \
    --to=shameerali.kolothum.thodi@huawei.com \
    --cc=Sami.Mujawar@arm.com \
    --cc=devel@acpica.org \
    --cc=eric.auger@redhat.com \
    --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=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.