[v9,10/15] ACPI: platform-msi: retrieve dev id from IORT

Message ID 1488890410-15503-11-git-send-email-guohanjun@huawei.com
State New
Headers show
Series
  • ACPI platform MSI support and its example mbigen
Related show

Commit Message

Hanjun Guo March 7, 2017, 12:40 p.m.
From: Hanjun Guo <hanjun.guo@linaro.org>


For devices connecting to ITS, the devices need to identify themself
through a dev id; this dev id is represented in the IORT table in named
component node [1] for platform devices, so this patch adds code that
scans the IORT table to retrieve the devices' dev id.

Leveraging the iort_node_map_platform_id() IORT API, add a new function
call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow
retrieving dev id in ACPI platforms.

[1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>

[lorenzo.pieralisi@arm.com: rewrote commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Tested-by: Ming Lei <ming.lei@canonical.com>

Tested-by: Wei Xu <xuwei5@hisilicon.com>

Tested-by: Sinan Kaya <okaya@codeaurora.org>

Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/acpi/arm64/iort.c                     | 24 ++++++++++++++++++++++++
 drivers/irqchip/irq-gic-v3-its-platform-msi.c |  3 ++-
 include/linux/acpi_iort.h                     |  5 +++++
 3 files changed, 31 insertions(+), 1 deletion(-)

-- 
1.7.12.4

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Hanjun Guo March 11, 2017, 8:56 a.m. | #1
On 2017/3/7 22:35, Lorenzo Pieralisi wrote:
> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:

>> From: Hanjun Guo <hanjun.guo@linaro.org>

>>

>> For devices connecting to ITS, the devices need to identify themself

>> through a dev id; this dev id is represented in the IORT table in named

>> component node [1] for platform devices, so this patch adds code that

>> scans the IORT table to retrieve the devices' dev id.

>>

>> Leveraging the iort_node_map_platform_id() IORT API, add a new function

>> call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow

>> retrieving dev id in ACPI platforms.

>>

>> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf

>>

>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>

>> [lorenzo.pieralisi@arm.com: rewrote commit log]

>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

>> Tested-by: Ming Lei <ming.lei@canonical.com>

>> Tested-by: Wei Xu <xuwei5@hisilicon.com>

>> Tested-by: Sinan Kaya <okaya@codeaurora.org>

>> Cc: Marc Zyngier <marc.zyngier@arm.com>

>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

>> Cc: Tomasz Nowicki <tn@semihalf.com>

>> Cc: Thomas Gleixner <tglx@linutronix.de>

>> ---

>>  drivers/acpi/arm64/iort.c                     | 24 ++++++++++++++++++++++++

>>  drivers/irqchip/irq-gic-v3-its-platform-msi.c |  3 ++-

>>  include/linux/acpi_iort.h                     |  5 +++++

>>  3 files changed, 31 insertions(+), 1 deletion(-)

>>

>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c

>> index 83cd59d..fb95ceb 100644

>> --- a/drivers/acpi/arm64/iort.c

>> +++ b/drivers/acpi/arm64/iort.c

>> @@ -468,6 +468,30 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)

>>  }

>>  

>>  /**

>> + * iort_pmsi_get_dev_id() - Get the device id for a device

>> + * @dev: The device for which the mapping is to be done.

>> + * @dev_id: The device ID found.

>> + *

>> + * Returns: 0 for successful find a dev id, -ENODEV on error

>> + */

>> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)

>> +{

>> +	int i;

>> +	struct acpi_iort_node *node;

>> +

>> +	node = iort_find_dev_node(dev);

>> +	if (!node)

>> +		return -ENODEV;

> I think that when specs are updated so that we can enable SMMU MSIs we

> shall have to find a way to get the acpi_iort_node for a device that is

> not a named component here (ie SMMU), I reckon we can use the

> fwnode_handle but I have to have a deeper look.


Seems we can do this as follows:

---
 drivers/acpi/arm64/iort.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 42 insertions(+), 1 deletion(-)



>

> This does not affect the patchset in its current form, just scanning

> the code to make sure we will be able to support SMMU MSIs too when

> time comes.


Sure, thanks!

Hanjun

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.htmldiff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 22e08d2..c794219 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -121,6 +121,31 @@ static inline void iort_delete_fwnode(struct acpi_iort_node *node)
        spin_unlock(&iort_fwnode_lock);
 }
 
+/**
+ * iort_get_iort_node() - Retrieve iort_node associated with an fwnode
+ *
+ * @fwnode: fwnode associated with device to be looked-up
+ *
+ * Returns: iort_node pointer on success, NULL on failure
+ */
+static inline
+struct acpi_iort_node *iort_get_iort_node(struct fwnode_handle *fwnode)
+{
+ struct iort_fwnode *curr;
+ struct acpi_iort_node *iort_node = NULL;
+
+ spin_lock(&iort_fwnode_lock);
+ list_for_each_entry(curr, &iort_fwnode_list, list) {
+         if (curr->fwnode == fwnode) {
+                 iort_node = curr->iort_node;
+                 break;
+         }
+ }
+ spin_unlock(&iort_fwnode_lock);
+
+ return iort_node;
+}
+
 typedef acpi_status (*iort_find_node_callback)
        (struct acpi_iort_node *node, void *context);
 
@@ -434,9 +459,25 @@ static struct acpi_iort_node *iort_find_dev_node(struct device *dev)
 {
        struct pci_bus *pbus;
 
-   if (!dev_is_pci(dev))
+ if (!dev_is_pci(dev)) {
+         struct acpi_iort_node *node;
+         /*
+          * scan iort_fwnode_list to see if it's an iort platform
+          * device (such as SMMU, PMCG),its iort node already cached
+          * and associated with fwnode when iort platform devices
+          * were initialized.
+          */
+         node = iort_get_iort_node(dev->fwnode);
+         if (node)
+                 return node;
+
+         /*
+          * if not, then it should be a platform device defined in
+          * DSDT (with Named Component node in IORT)
+          */
                return iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
                                      iort_match_node_callback, dev);
+ }
 
        /* Find a PCI root bus */
        pbus = to_pci_dev(dev)->bus;

Lorenzo Pieralisi March 29, 2017, 10:14 a.m. | #2
Hi Hanjun, Marc,

On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>

> 

> For devices connecting to ITS, the devices need to identify themself

> through a dev id; this dev id is represented in the IORT table in named

> component node [1] for platform devices, so this patch adds code that

> scans the IORT table to retrieve the devices' dev id.

> 

> Leveraging the iort_node_map_platform_id() IORT API, add a new function

> call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow

> retrieving dev id in ACPI platforms.

> 

> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf

> 

> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>

> [lorenzo.pieralisi@arm.com: rewrote commit log]

> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

> Tested-by: Ming Lei <ming.lei@canonical.com>

> Tested-by: Wei Xu <xuwei5@hisilicon.com>

> Tested-by: Sinan Kaya <okaya@codeaurora.org>

> Cc: Marc Zyngier <marc.zyngier@arm.com>

> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

> Cc: Tomasz Nowicki <tn@semihalf.com>

> Cc: Thomas Gleixner <tglx@linutronix.de>

> ---

>  drivers/acpi/arm64/iort.c                     | 24 ++++++++++++++++++++++++

>  drivers/irqchip/irq-gic-v3-its-platform-msi.c |  3 ++-

>  include/linux/acpi_iort.h                     |  5 +++++

>  3 files changed, 31 insertions(+), 1 deletion(-)


To simplify merging ACPI/IRQCHIP changes via different trees it
would be good to split this patch; I am not sure what's the best
way of handling it though given that we would end up in a merge
ordering dependency anyway (ie we can create an empty stub
for iort_pmsi_get_dev_id() but that would create a dependency
between ARM64 and irqchip trees anyway).

Please let me know what's your preferred way of handling this.

Thanks,
Lorenzo

> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c

> index 83cd59d..fb95ceb 100644

> --- a/drivers/acpi/arm64/iort.c

> +++ b/drivers/acpi/arm64/iort.c

> @@ -468,6 +468,30 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)

>  }

>  

>  /**

> + * iort_pmsi_get_dev_id() - Get the device id for a device

> + * @dev: The device for which the mapping is to be done.

> + * @dev_id: The device ID found.

> + *

> + * Returns: 0 for successful find a dev id, -ENODEV on error

> + */

> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)

> +{

> +	int i;

> +	struct acpi_iort_node *node;

> +

> +	node = iort_find_dev_node(dev);

> +	if (!node)

> +		return -ENODEV;

> +

> +	for (i = 0; i < node->mapping_count; i++) {

> +		if (iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE, i))

> +			return 0;

> +	}

> +

> +	return -ENODEV;

> +}

> +

> +/**

>   * iort_dev_find_its_id() - Find the ITS identifier for a device

>   * @dev: The device.

>   * @req_id: Device's requester ID

> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c

> index e4ba9f4..e801fc0 100644

> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c

> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c

> @@ -57,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,

>  

>  	msi_info = msi_get_domain_info(domain->parent);

>  

> -	ret = of_pmsi_get_dev_id(domain, dev, &dev_id);

> +	ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, &dev_id) :

> +		iort_pmsi_get_dev_id(dev, &dev_id);

>  	if (ret)

>  		return ret;

>  

> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h

> index 77e0809..d074c77 100644

> --- a/include/linux/acpi_iort.h

> +++ b/include/linux/acpi_iort.h

> @@ -34,6 +34,7 @@

>  bool iort_node_match(u8 type);

>  u32 iort_msi_map_rid(struct device *dev, u32 req_id);

>  struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);

> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);

>  /* IOMMU interface */

>  void iort_set_dma_mask(struct device *dev);

>  const struct iommu_ops *iort_iommu_configure(struct device *dev);

> @@ -45,6 +46,10 @@ static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)

>  static inline struct irq_domain *iort_get_device_domain(struct device *dev,

>  							u32 req_id)

>  { return NULL; }

> +

> +static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)

> +{ return -ENODEV; }

> +

>  /* IOMMU interface */

>  static inline void iort_set_dma_mask(struct device *dev) { }

>  static inline

> -- 

> 1.7.12.4

> 

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lorenzo Pieralisi March 29, 2017, 4:13 p.m. | #3
On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote:
> On 29/03/17 14:00, Hanjun Guo wrote:

> > On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:

> >> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:

> >>> Hi Lorenzo,

> >>>

> >>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:

> >>>> Hi Hanjun, Marc,

> >>>>

> >>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:

> >>>>> From: Hanjun Guo <hanjun.guo@linaro.org>

> >>>>>

> >>>>> For devices connecting to ITS, the devices need to identify themself

> >>>>> through a dev id; this dev id is represented in the IORT table in named

> >>>>> component node [1] for platform devices, so this patch adds code that

> >>>>> scans the IORT table to retrieve the devices' dev id.

> >>>>>

> >>>>> Leveraging the iort_node_map_platform_id() IORT API, add a new function

> >>>>> call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow

> >>>>> retrieving dev id in ACPI platforms.

> >>>>>

> >>>>> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf

> >>>>>

> >>>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>

> >>>>> [lorenzo.pieralisi@arm.com: rewrote commit log]

> >>>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

> >>>>> Tested-by: Ming Lei <ming.lei@canonical.com>

> >>>>> Tested-by: Wei Xu <xuwei5@hisilicon.com>

> >>>>> Tested-by: Sinan Kaya <okaya@codeaurora.org>

> >>>>> Cc: Marc Zyngier <marc.zyngier@arm.com>

> >>>>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

> >>>>> Cc: Tomasz Nowicki <tn@semihalf.com>

> >>>>> Cc: Thomas Gleixner <tglx@linutronix.de>

> >>>>> ---

> >>>>>   drivers/acpi/arm64/iort.c                     | 24 ++++++++++++++++++++++++

> >>>>>   drivers/irqchip/irq-gic-v3-its-platform-msi.c |  3 ++-

> >>>>>   include/linux/acpi_iort.h                     |  5 +++++

> >>>>>   3 files changed, 31 insertions(+), 1 deletion(-)

> >>>>

> >>>> To simplify merging ACPI/IRQCHIP changes via different trees it

> >>>> would be good to split this patch; I am not sure what's the best

> >>>> way of handling it though given that we would end up in a merge

> >>>> ordering dependency anyway (ie we can create an empty stub

> >>>> for iort_pmsi_get_dev_id() but that would create a dependency

> >>>> between ARM64 and irqchip trees anyway).

> >>>

> >>> The first 12 patches for ACPI platform MSI and later 3 patches

> >>> for mbigen have no "physical" dependency, which means they can

> >>> be merged and compiled independently, they only have functional

> >>> dependency only.

> >>>

> >>> We already had SAS, XGE, USB and even UART drivers depend on

> >>> the mbigen ACPI support, so I don't think the dependency of ACPI

> >>> platform MSI and mbigen patches cares much if those two parts are

> >>> merged in one merge window, even they are merged independently via

> >>> different tree.

> >>>

> >>>>

> >>>> Please let me know what's your preferred way of handling this.

> >>>

> >>> So in my opinion, they can be merged independently via ARM64 and

> >>> irqchip tree with no ordering dependency, is it OK?

> >>

> >> I am speaking about merging MBIgen AND ITS patches via IRQCHIP and

> >> ACPI/IORT for ARM64, that's why I replied to this patch. I do not

> >> think that's feasible to split patches in two separate branches

> >> without having a dependency between them.

> >>

> >> Sure, the last three patches can go via IRQCHIP but that was not

> >> my question :)

> > 

> > Sorry, I misunderstood that :(

> > 

> > Since it's not feasible to split patches, the best way I got is that

> > we get Marc's ack then merge it.

> 

> I believe there is a way to make this work without too much hassle. I

> suggest we drop the ITS change from this patch entirely, and I instead

> queue this patch:

> 

> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45

> 

> That way, no dependency between the two trees. Lorenzo takes all the

> patches flagged "ACPI", I take all those flagged "irqchip" or "msi", and

> everything should be perfectly standalone.

> 

> Thoughts?


Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
this patch and post the resulting branch for everyone to have a final
test.

Ok ?

Thanks !
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lorenzo Pieralisi March 29, 2017, 5:32 p.m. | #4
On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote:

> > On 29/03/17 14:00, Hanjun Guo wrote:

> > > On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:

> > >> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:

> > >>> Hi Lorenzo,

> > >>>

> > >>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:

> > >>>> Hi Hanjun, Marc,

> > >>>>

> > >>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:

> > >>>>> From: Hanjun Guo <hanjun.guo@linaro.org>

> > >>>>>

> > >>>>> For devices connecting to ITS, the devices need to identify themself

> > >>>>> through a dev id; this dev id is represented in the IORT table in named

> > >>>>> component node [1] for platform devices, so this patch adds code that

> > >>>>> scans the IORT table to retrieve the devices' dev id.

> > >>>>>

> > >>>>> Leveraging the iort_node_map_platform_id() IORT API, add a new function

> > >>>>> call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow

> > >>>>> retrieving dev id in ACPI platforms.

> > >>>>>

> > >>>>> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf

> > >>>>>

> > >>>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>

> > >>>>> [lorenzo.pieralisi@arm.com: rewrote commit log]

> > >>>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

> > >>>>> Tested-by: Ming Lei <ming.lei@canonical.com>

> > >>>>> Tested-by: Wei Xu <xuwei5@hisilicon.com>

> > >>>>> Tested-by: Sinan Kaya <okaya@codeaurora.org>

> > >>>>> Cc: Marc Zyngier <marc.zyngier@arm.com>

> > >>>>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

> > >>>>> Cc: Tomasz Nowicki <tn@semihalf.com>

> > >>>>> Cc: Thomas Gleixner <tglx@linutronix.de>

> > >>>>> ---

> > >>>>>   drivers/acpi/arm64/iort.c                     | 24 ++++++++++++++++++++++++

> > >>>>>   drivers/irqchip/irq-gic-v3-its-platform-msi.c |  3 ++-

> > >>>>>   include/linux/acpi_iort.h                     |  5 +++++

> > >>>>>   3 files changed, 31 insertions(+), 1 deletion(-)

> > >>>>

> > >>>> To simplify merging ACPI/IRQCHIP changes via different trees it

> > >>>> would be good to split this patch; I am not sure what's the best

> > >>>> way of handling it though given that we would end up in a merge

> > >>>> ordering dependency anyway (ie we can create an empty stub

> > >>>> for iort_pmsi_get_dev_id() but that would create a dependency

> > >>>> between ARM64 and irqchip trees anyway).

> > >>>

> > >>> The first 12 patches for ACPI platform MSI and later 3 patches

> > >>> for mbigen have no "physical" dependency, which means they can

> > >>> be merged and compiled independently, they only have functional

> > >>> dependency only.

> > >>>

> > >>> We already had SAS, XGE, USB and even UART drivers depend on

> > >>> the mbigen ACPI support, so I don't think the dependency of ACPI

> > >>> platform MSI and mbigen patches cares much if those two parts are

> > >>> merged in one merge window, even they are merged independently via

> > >>> different tree.

> > >>>

> > >>>>

> > >>>> Please let me know what's your preferred way of handling this.

> > >>>

> > >>> So in my opinion, they can be merged independently via ARM64 and

> > >>> irqchip tree with no ordering dependency, is it OK?

> > >>

> > >> I am speaking about merging MBIgen AND ITS patches via IRQCHIP and

> > >> ACPI/IORT for ARM64, that's why I replied to this patch. I do not

> > >> think that's feasible to split patches in two separate branches

> > >> without having a dependency between them.

> > >>

> > >> Sure, the last three patches can go via IRQCHIP but that was not

> > >> my question :)

> > > 

> > > Sorry, I misunderstood that :(

> > > 

> > > Since it's not feasible to split patches, the best way I got is that

> > > we get Marc's ack then merge it.

> > 

> > I believe there is a way to make this work without too much hassle. I

> > suggest we drop the ITS change from this patch entirely, and I instead

> > queue this patch:

> > 

> > https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45

> > 

> > That way, no dependency between the two trees. Lorenzo takes all the

> > patches flagged "ACPI", I take all those flagged "irqchip" or "msi", and

> > everything should be perfectly standalone.

> > 

> > Thoughts?

> 

> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework

> this patch and post the resulting branch for everyone to have a final

> test.


git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12

Please have a look and let me know if that's ok, I planned to send
a PR to Catalin by the end of the week (first 7 patches up to
7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform
device")).

Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
majun (F) March 30, 2017, 4:08 a.m. | #5
Hi all:

在 2017/3/30 11:07, Hanjun Guo 写道:
> On 03/30/2017 01:32 AM, Lorenzo Pieralisi wrote:

>> On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote:

>>> On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote:

>>>> On 29/03/17 14:00, Hanjun Guo wrote:

>>>>> On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:

>>>>>> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:

>>>>>>> Hi Lorenzo,

>>>>>>>

>>>>>>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:

>>>>>>>> Hi Hanjun, Marc,

>>>>>>>>

>>>>>>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:

> [...]

>>>>>>>>>    drivers/acpi/arm64/iort.c                     | 24 ++++++++++++++++++++++++

>>>>>>>>>    drivers/irqchip/irq-gic-v3-its-platform-msi.c |  3 ++-

[...]
>>>>

>>>> Thoughts?

>>>

>>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework

>>> this patch and post the resulting branch for everyone to have a final

>>> test.

>>

>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12

>>

>> Please have a look and let me know if that's ok, I planned to send

>> a PR to Catalin by the end of the week (first 7 patches up to

>> 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform

>> device")).

> 

> Perfect for me too, Lorenzo, Marc, Thank you very much.

> 

> I'm currently in paternity leave and can't reach the machine,

> I had a detail review with the patches, they looks good to me,

> Ma Jun and Wei Xu will test on Hisilicon machines and give the

> feedback.


The sas/xge/uart are working fine on my hisilicon board with
Lorenzo's branch (arm64-acpi-4.12)

Thanks
Majun

> 

> Thanks

> Hanjun

> 

> .

> 


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lorenzo Pieralisi March 30, 2017, 2:28 p.m. | #6
On Thu, Mar 30, 2017 at 09:32:57AM +0100, Wei Xu wrote:
> Hi All,

> 

> On 2017/3/30 4:07, Hanjun Guo wrote:

> > On 03/30/2017 01:32 AM, Lorenzo Pieralisi wrote:

> >> On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote:

> >>> On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote:

> >>>> On 29/03/17 14:00, Hanjun Guo wrote:

> >>>>> On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:

> >>>>>> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:

> >>>>>>> Hi Lorenzo,

> >>>>>>>

> >>>>>>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:

> >>>>>>>> Hi Hanjun, Marc,

> >>>>>>>>

> >>>>>>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:

> > [...]

> >>>>>>>>>    drivers/acpi/arm64/iort.c                     | 24 ++++++++++++++++++++++++

> >>>>>>>>>    drivers/irqchip/irq-gic-v3-its-platform-msi.c |  3 ++-

> >>>>>>>>>    include/linux/acpi_iort.h                     |  5 +++++

> >>>>>>>>>    3 files changed, 31 insertions(+), 1 deletion(-)

> >>>>>>>>

> >>>>>>>> To simplify merging ACPI/IRQCHIP changes via different trees it

> >>>>>>>> would be good to split this patch; I am not sure what's the best

> >>>>>>>> way of handling it though given that we would end up in a merge

> >>>>>>>> ordering dependency anyway (ie we can create an empty stub

> >>>>>>>> for iort_pmsi_get_dev_id() but that would create a dependency

> >>>>>>>> between ARM64 and irqchip trees anyway).

> >>>>>>>

> >>>>>>> The first 12 patches for ACPI platform MSI and later 3 patches

> >>>>>>> for mbigen have no "physical" dependency, which means they can

> >>>>>>> be merged and compiled independently, they only have functional

> >>>>>>> dependency only.

> >>>>>>>

> >>>>>>> We already had SAS, XGE, USB and even UART drivers depend on

> >>>>>>> the mbigen ACPI support, so I don't think the dependency of ACPI

> >>>>>>> platform MSI and mbigen patches cares much if those two parts are

> >>>>>>> merged in one merge window, even they are merged independently via

> >>>>>>> different tree.

> >>>>>>>

> >>>>>>>>

> >>>>>>>> Please let me know what's your preferred way of handling this.

> >>>>>>>

> >>>>>>> So in my opinion, they can be merged independently via ARM64 and

> >>>>>>> irqchip tree with no ordering dependency, is it OK?

> >>>>>>

> >>>>>> I am speaking about merging MBIgen AND ITS patches via IRQCHIP and

> >>>>>> ACPI/IORT for ARM64, that's why I replied to this patch. I do not

> >>>>>> think that's feasible to split patches in two separate branches

> >>>>>> without having a dependency between them.

> >>>>>>

> >>>>>> Sure, the last three patches can go via IRQCHIP but that was not

> >>>>>> my question :)

> >>>>>

> >>>>> Sorry, I misunderstood that :(

> >>>>>

> >>>>> Since it's not feasible to split patches, the best way I got is that

> >>>>> we get Marc's ack then merge it.

> >>>>

> >>>> I believe there is a way to make this work without too much hassle. I

> >>>> suggest we drop the ITS change from this patch entirely, and I instead

> >>>> queue this patch:

> >>>>

> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45

> >>>>

> >>>> That way, no dependency between the two trees. Lorenzo takes all the

> >>>> patches flagged "ACPI", I take all those flagged "irqchip" or "msi", and

> >>>> everything should be perfectly standalone.

> >>>>

> >>>> Thoughts?

> >>>

> >>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework

> >>> this patch and post the resulting branch for everyone to have a final

> >>> test.

> >>

> >> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12

> >>

> >> Please have a look and let me know if that's ok, I planned to send

> >> a PR to Catalin by the end of the week (first 7 patches up to

> >> 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform

> >> device")).

> > 

> > Perfect for me too, Lorenzo, Marc, Thank you very much.

> > 

> > I'm currently in paternity leave and can't reach the machine,

> > I had a detail review with the patches, they looks good to me,

> > Ma Jun and Wei Xu will test on Hisilicon machines and give the

> > feedback.

> 

> Thanks to all of you!

> Tested on D05 board with this branch, the SAS disks and XGE port are working fine.


Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull
request to Catalin tomorrow, please carry out last few checks before
I send it:

git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git tags/acpi-arm64-for-v4.12

You should try to merge it with Marc's branch:

git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-4.12

and test the resulting branch, that's how they will go upstream.

Please let me know, thank you for your help !

Lorenzo

> The log is as below:

> 

> 	estuary:/$ dmesg

> 	[    0.000000] Booting Linux on physical CPU 0x10000

> 	[    0.000000] Linux version 4.11.0-rc3-14418-gea60d0a (xuwei@EstBuildSvr1) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #28 SMP PREEMPT Thu Mar 30 16:15:42 CST 2017

> 	[    0.000000] Boot CPU: AArch64 Processor [410fd082]

> 	[    0.000000] efi: Getting EFI parameters from FDT:

> 	[    0.000000] efi: EFI v2.60 by EDK II

> 	[    0.000000] efi:  SMBIOS=0x3f040000  SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000  ACPI 2.0=0x39bc0014  MEMATTR=0x3ccb0098

> 	[    0.000000] cma: Reserved 16 MiB at 0x000000003e000000

> 

> 

> 	estuary:/$ ping 192.168.1.107

> 	PING 192.168.1.107 (192.168.1.107): 56 data bytes

> 	64 bytes from 192.168.1.107: seq=0 ttl=64 time=0.273 ms

> 	64 bytes from 192.168.1.107: seq=1 ttl=64 time=0.102 ms

> 	64 bytes from 192.168.1.107: seq=2 ttl=64 time=0.103 ms

> 	64 bytes from 192.168.1.107: seq=3 ttl=64 time=0.098 ms

> 	^C

> 	--- 192.168.1.107 ping statistics ---

> 	4 packets transmitted, 4 packets received, 0% packet loss

> 	round-trip min/avg/max = 0.098/0.144/0.273 ms

> 

> 	estuary:/$ lspci -mk

> 	30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 	91:00.0 "Class 0300" "19e5" "1711" "0000" "0000"

> 	90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 	20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 	10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 	80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 	00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 	c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 	88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 	

> 	estuary:/$ cat /dev/sd

> 	sda   sdb   sdc   sdd   sde   sdf   sdg   sdh   sdi   sdj   sdk sdl

> 	sda1  sdb1  sdc1  sdd1  sde1  sdf1  sdg1  sdh1  sdi1  sdj1  sdk1 sdl1

> 

> Best Regards,

> Wei

> 

> > 

> > Thanks

> > Hanjun

> > 

> > .

> > 

> 

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
John Garry March 30, 2017, 4:14 p.m. | #7
>>>>>

>>>>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework

>>>>> this patch and post the resulting branch for everyone to have a final

>>>>> test.

>>>>

>>>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12

>>>>

>>>> Please have a look and let me know if that's ok, I planned to send

>>>> a PR to Catalin by the end of the week (first 7 patches up to

>>>> 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform

>>>> device")).

>>>

>>> Perfect for me too, Lorenzo, Marc, Thank you very much.

>>>

>>> I'm currently in paternity leave and can't reach the machine,

>>> I had a detail review with the patches, they looks good to me,

>>> Ma Jun and Wei Xu will test on Hisilicon machines and give the

>>> feedback.

>>

>> Thanks to all of you!

>> Tested on D05 board with this branch, the SAS disks and XGE port are working fine.

>

> Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull

> request to Catalin tomorrow, please carry out last few checks before

> I send it:

>

> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git tags/acpi-arm64-for-v4.12

>

> You should try to merge it with Marc's branch:

>

> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-4.12

>

> and test the resulting branch, that's how they will go upstream.

>

> Please let me know, thank you for your help !

>


Hi Lorenzo,

xuwei is away now, and it is night time with majun, so I tested. majun 
can retest tomorrow again to triple-check. I did not touch the ITS patch 
Marc made which had the weak version of iort_pmis_get_dev_id(), but it 
should not affect anything in my test.

After merging your tag to Marc's branch, here is the git log:
git log --oneline
8b6f3f8 Merge tag 'acpi-arm64-for-v4.12' into irq/irqchip-4.12
d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device
ae7c183 ACPI: platform-msi: retrieve devid from IORT
e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support
8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic
d11349c irqchip: mbigen: Add ACPI support
aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain()
964bac1 irqchip: mbigen: drop module owner
b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware
d264edb irqchip: gicv3-its: platform-msi: scan MADT to create platform 
msi domain
baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to 
prepare for ACPI
fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
cc9eb0d irqchip: gic-v3-its: keep the include header files in alphabetic 
order
ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type
ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number
3382357 dt-bindings: mediatek: multiple bases support for sysirq
4015616 irqchip: replace moxa with ftintc010
532278c irqchip: faraday: fix the trigger types
923fa67 irqchip: refactor Gemini driver to reflect Faraday origin
44d64ce irqchip: augment Gemini bindings to reflect Faraday origin
c02ed2e Linux 4.11-rc4

And some testing:

dmesg snippet:
[    0.000000] Booting Linux on physical CPU 0x10000
[    0.000000] Linux version 4.11.0-rc4-00420-g8b6f3f8 
(johnpgarry@johnpgarry-ThinkCentre-M93p) (gcc version 4.8.5 (Linaro GCC 
4.8-2015.06) ) #4 SMP PREEMPT Thu Mar 30 16:40:36 BST 2017
[    0.000000] Boot CPU: AArch64 Processor [410fd082]
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: EFI v2.60 by EDK II
[    0.000000] efi:  SMBIOS=0x3f040000  SMBIOS 3.0=0x39af0000 
ACPI=0x39bc0000  ACPI 2.0=0x39bc0014  MEMATTR=0x3cc86018
[    0.000000] cma: Reserved 16 MiB at 0x000000003e000000
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x0000000039BC0014 000024 (v02 HISI  )
[    0.000000] ACPI: XSDT 0x0000000039BB00E8 00006C (v01 HISI   HIP07 
00000000      01000013)
[    0.000000] ACPI: FACP 0x0000000039A80000 00010C (v05 HISI   HIP07 
00000000 INTL 20151124)
[    0.000000] ACPI: DSDT 0x0000000039A40000 0074E2 (v02 HISI   HIP07 
00000000 INTL 20151218)
[    0.000000] ACPI: MCFG 0x0000000039AD0000 0000AC (v01 HISI   HIP07 
00000000 INTL 20151124)
[    0.000000] ACPI: SLIT 0x0000000039AC0000 00003C (v01 HISI   HIP07 
00000000 INTL 20151124)
[    0.000000] ACPI: SPCR 0x0000000039AB0000 000050 (v02 HISI   HIP07 
00000000 INTL 20151124)
[    0.000000] ACPI: SRAT 0x0000000039AA0000 000500 (v03 HISI   HIP07 
00000000 INTL 20151124)
[    0.000000] ACPI: GTDT 0x0000000039A70000 000098 (v02 HISI   HIP07 
00000000 INTL 20151124)
[    0.000000] ACPI: APIC 0x0000000039A60000 0013E4 (v01 HISI   HIP07 
00000000 INTL 20151124)
[    0.000000] ACPI: IORT 0x0000000039A50000 000514 (v00 HISI   HIP07 
00000000 INTL 20151218)
[    0.000000] ACPI: iBFT 0x0000000031870000 000800 (v01 HISI   HIP07 
00000000      00000000)

PCI:
root@(none)$ lspci -mk
30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
91:00.0 "Class 0300" "19e5" "1711" "0000" "0000"
90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

Integrated NIC:
root@(none)$ ifconfig eth1 172.18.45.80 up
root@(none)$ [  345.449591] hns-nic HISI00C2:01 eth1: link up
root@(none)$ ping 172.18.45.23
PING 172.18.45.23 (172.18.45.23): 56 data bytes
64 bytes from 172.18.45.23: seq=0 ttl=64 time=2026.837 ms
64 bytes from 172.18.45.23: seq=1 ttl=64 time=1026.843 ms
64 bytes from 172.18.45.23: seq=2 ttl=64 time=26.834 ms
64 bytes from 172.18.45.23: seq=3 ttl=64 time=0.075 ms
64 bytes from 172.18.45.23: seq=4 ttl=64 time=0.079 ms
^C
--- 172.18.45.23 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.075/616.133/2026.837 ms



Integrated Storage controller:
root@(none)$ fdisk -l
Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdb9f5cd0

Device    Boot     Start       End    Blocks  Id System
/dev/sdb1           2048 209717247 104857600  83 Linux
/dev/sdb2      209717248 419432447 104857600  83 Linux


Disk /dev/sda: 186.3 GiB, 200049647616 bytes, 390721968 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 131072 bytes

Disk /dev/sdc: 186.3 GiB, 200049647616 bytes, 390721968 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 131072 bytes

Disk /dev/sdd: 186.3 GiB, 200049647616 bytes, 390721968 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 131072 bytes

Disk /dev/sde: 186.3 GiB, 200049647616 bytes, 390721968 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 131072 bytes

Disk /dev/sdf: 186.3 GiB, 200049647616 bytes, 390721968 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 131072 bytes

root@(none)$

Looks ok

@majun, please test as well.

Thanks,
John

> Lorenzo

>

>> The log is as below:

>>

>> 	estuary:/$ dmesg

>> 	[    0.000000] Booting Linux on physical CPU 0x10000

>> 	[    0.000000] Linux version 4.11.0-rc3-14418-gea60d0a (xuwei@EstBuildSvr1) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #28 SMP PREEMPT Thu Mar 30 16:15:42 CST 2017

>> 	[    0.000000] Boot CPU: AArch64 Processor [410fd082]

>> 	[    0.000000] efi: Getting EFI parameters from FDT:

>> 	[    0.000000] efi: EFI v2.60 by EDK II

>> 	[    0.000000] efi:  SMBIOS=0x3f040000  SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000  ACPI 2.0=0x39bc0014  MEMATTR=0x3ccb0098

>> 	[    0.000000] cma: Reserved 16 MiB at 0x000000003e000000

>>

>>

>> 	estuary:/$ ping 192.168.1.107

>> 	PING 192.168.1.107 (192.168.1.107): 56 data bytes

>> 	64 bytes from 192.168.1.107: seq=0 ttl=64 time=0.273 ms

>> 	64 bytes from 192.168.1.107: seq=1 ttl=64 time=0.102 ms

>> 	64 bytes from 192.168.1.107: seq=2 ttl=64 time=0.103 ms

>> 	64 bytes from 192.168.1.107: seq=3 ttl=64 time=0.098 ms

>> 	^C

>> 	--- 192.168.1.107 ping statistics ---

>> 	4 packets transmitted, 4 packets received, 0% packet loss

>> 	round-trip min/avg/max = 0.098/0.144/0.273 ms

>>

>> 	estuary:/$ lspci -mk

>> 	30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>> 	91:00.0 "Class 0300" "19e5" "1711" "0000" "0000"

>> 	90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>> 	20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>> 	10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>> 	80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>> 	00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>> 	c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>> 	88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>> 	

>> 	estuary:/$ cat /dev/sd

>> 	sda   sdb   sdc   sdd   sde   sdf   sdg   sdh   sdi   sdj   sdk sdl

>> 	sda1  sdb1  sdc1  sdd1  sde1  sdf1  sdg1  sdh1  sdi1  sdj1  sdk1 sdl1

>>

>> Best Regards,

>> Wei

>>

>>>

>>> Thanks

>>> Hanjun

>>>

>>> .

>>>

>>

> _______________________________________________

> linuxarm mailing list

> linuxarm@huawei.com

> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

>

> .

>



--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lorenzo Pieralisi March 30, 2017, 4:54 p.m. | #8
On Thu, Mar 30, 2017 at 05:14:34PM +0100, John Garry wrote:
> 

> >>>>>

> >>>>>Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework

> >>>>>this patch and post the resulting branch for everyone to have a final

> >>>>>test.

> >>>>

> >>>>git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12

> >>>>

> >>>>Please have a look and let me know if that's ok, I planned to send

> >>>>a PR to Catalin by the end of the week (first 7 patches up to

> >>>>7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform

> >>>>device")).

> >>>

> >>>Perfect for me too, Lorenzo, Marc, Thank you very much.

> >>>

> >>>I'm currently in paternity leave and can't reach the machine,

> >>>I had a detail review with the patches, they looks good to me,

> >>>Ma Jun and Wei Xu will test on Hisilicon machines and give the

> >>>feedback.

> >>

> >>Thanks to all of you!

> >>Tested on D05 board with this branch, the SAS disks and XGE port are working fine.

> >

> >Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull

> >request to Catalin tomorrow, please carry out last few checks before

> >I send it:

> >

> >git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git tags/acpi-arm64-for-v4.12

> >

> >You should try to merge it with Marc's branch:

> >

> >git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-4.12

> >

> >and test the resulting branch, that's how they will go upstream.

> >

> >Please let me know, thank you for your help !

> >

> 

> Hi Lorenzo,

> 

> xuwei is away now, and it is night time with majun, so I tested.

> majun can retest tomorrow again to triple-check. I did not touch the

> ITS patch Marc made which had the weak version of

> iort_pmis_get_dev_id(), but it should not affect anything in my

> test.

> 

> After merging your tag to Marc's branch, here is the git log:

> git log --oneline

> 8b6f3f8 Merge tag 'acpi-arm64-for-v4.12' into irq/irqchip-4.12

> d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device

> ae7c183 ACPI: platform-msi: retrieve devid from IORT

> e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support

> 8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id

> 697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic

> d11349c irqchip: mbigen: Add ACPI support

> aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain()

> 964bac1 irqchip: mbigen: drop module owner

> b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware

> d264edb irqchip: gicv3-its: platform-msi: scan MADT to create

> platform msi domain

> baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init()

> to prepare for ACPI

> fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()

> cc9eb0d irqchip: gic-v3-its: keep the include header files in

> alphabetic order

> ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type

> ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number

> 3382357 dt-bindings: mediatek: multiple bases support for sysirq

> 4015616 irqchip: replace moxa with ftintc010

> 532278c irqchip: faraday: fix the trigger types

> 923fa67 irqchip: refactor Gemini driver to reflect Faraday origin

> 44d64ce irqchip: augment Gemini bindings to reflect Faraday origin

> c02ed2e Linux 4.11-rc4

> 

> And some testing:

> 

> dmesg snippet:

> [    0.000000] Booting Linux on physical CPU 0x10000

> [    0.000000] Linux version 4.11.0-rc4-00420-g8b6f3f8

> (johnpgarry@johnpgarry-ThinkCentre-M93p) (gcc version 4.8.5 (Linaro

> GCC 4.8-2015.06) ) #4 SMP PREEMPT Thu Mar 30 16:40:36 BST 2017

> [    0.000000] Boot CPU: AArch64 Processor [410fd082]

> [    0.000000] efi: Getting EFI parameters from FDT:

> [    0.000000] efi: EFI v2.60 by EDK II

> [    0.000000] efi:  SMBIOS=0x3f040000  SMBIOS 3.0=0x39af0000

> ACPI=0x39bc0000  ACPI 2.0=0x39bc0014  MEMATTR=0x3cc86018

> [    0.000000] cma: Reserved 16 MiB at 0x000000003e000000

> [    0.000000] ACPI: Early table checksum verification disabled

> [    0.000000] ACPI: RSDP 0x0000000039BC0014 000024 (v02 HISI  )

> [    0.000000] ACPI: XSDT 0x0000000039BB00E8 00006C (v01 HISI

> HIP07 00000000      01000013)

> [    0.000000] ACPI: FACP 0x0000000039A80000 00010C (v05 HISI

> HIP07 00000000 INTL 20151124)

> [    0.000000] ACPI: DSDT 0x0000000039A40000 0074E2 (v02 HISI

> HIP07 00000000 INTL 20151218)

> [    0.000000] ACPI: MCFG 0x0000000039AD0000 0000AC (v01 HISI

> HIP07 00000000 INTL 20151124)

> [    0.000000] ACPI: SLIT 0x0000000039AC0000 00003C (v01 HISI

> HIP07 00000000 INTL 20151124)

> [    0.000000] ACPI: SPCR 0x0000000039AB0000 000050 (v02 HISI

> HIP07 00000000 INTL 20151124)

> [    0.000000] ACPI: SRAT 0x0000000039AA0000 000500 (v03 HISI

> HIP07 00000000 INTL 20151124)

> [    0.000000] ACPI: GTDT 0x0000000039A70000 000098 (v02 HISI

> HIP07 00000000 INTL 20151124)

> [    0.000000] ACPI: APIC 0x0000000039A60000 0013E4 (v01 HISI

> HIP07 00000000 INTL 20151124)

> [    0.000000] ACPI: IORT 0x0000000039A50000 000514 (v00 HISI

> HIP07 00000000 INTL 20151218)

> [    0.000000] ACPI: iBFT 0x0000000031870000 000800 (v01 HISI

> HIP07 00000000      00000000)

> 

> PCI:

> root@(none)$ lspci -mk

> 30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 91:00.0 "Class 0300" "19e5" "1711" "0000" "0000"

> 90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> 

> Integrated NIC:

> root@(none)$ ifconfig eth1 172.18.45.80 up

> root@(none)$ [  345.449591] hns-nic HISI00C2:01 eth1: link up

> root@(none)$ ping 172.18.45.23

> PING 172.18.45.23 (172.18.45.23): 56 data bytes

> 64 bytes from 172.18.45.23: seq=0 ttl=64 time=2026.837 ms

> 64 bytes from 172.18.45.23: seq=1 ttl=64 time=1026.843 ms

> 64 bytes from 172.18.45.23: seq=2 ttl=64 time=26.834 ms

> 64 bytes from 172.18.45.23: seq=3 ttl=64 time=0.075 ms

> 64 bytes from 172.18.45.23: seq=4 ttl=64 time=0.079 ms

> ^C

> --- 172.18.45.23 ping statistics ---

> 5 packets transmitted, 5 packets received, 0% packet loss

> round-trip min/avg/max = 0.075/616.133/2026.837 ms

> 

> 

> 

> Integrated Storage controller:

> root@(none)$ fdisk -l

> Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors

> Units: sectors of 1 * 512 = 512 bytes

> Sector size (logical/physical): 512 bytes / 512 bytes

> I/O size (minimum/optimal): 512 bytes / 512 bytes

> Disklabel type: dos

> Disk identifier: 0xdb9f5cd0

> 

> Device    Boot     Start       End    Blocks  Id System

> /dev/sdb1           2048 209717247 104857600  83 Linux

> /dev/sdb2      209717248 419432447 104857600  83 Linux

> 

> 

> Disk /dev/sda: 186.3 GiB, 200049647616 bytes, 390721968 sectors

> Units: sectors of 1 * 512 = 512 bytes

> Sector size (logical/physical): 512 bytes / 512 bytes

> I/O size (minimum/optimal): 512 bytes / 131072 bytes

> 

> Disk /dev/sdc: 186.3 GiB, 200049647616 bytes, 390721968 sectors

> Units: sectors of 1 * 512 = 512 bytes

> Sector size (logical/physical): 512 bytes / 512 bytes

> I/O size (minimum/optimal): 512 bytes / 131072 bytes

> 

> Disk /dev/sdd: 186.3 GiB, 200049647616 bytes, 390721968 sectors

> Units: sectors of 1 * 512 = 512 bytes

> Sector size (logical/physical): 512 bytes / 512 bytes

> I/O size (minimum/optimal): 512 bytes / 131072 bytes

> 

> Disk /dev/sde: 186.3 GiB, 200049647616 bytes, 390721968 sectors

> Units: sectors of 1 * 512 = 512 bytes

> Sector size (logical/physical): 512 bytes / 512 bytes

> I/O size (minimum/optimal): 512 bytes / 131072 bytes

> 

> Disk /dev/sdf: 186.3 GiB, 200049647616 bytes, 390721968 sectors

> Units: sectors of 1 * 512 = 512 bytes

> Sector size (logical/physical): 512 bytes / 512 bytes

> I/O size (minimum/optimal): 512 bytes / 131072 bytes

> 

> root@(none)$

> 

> Looks ok


Great, thanks !

> @majun, please test as well.


Yes, final test, PR is ready to be sent, I reviewed Hanjun patches
but I just want to avoid breaking them given that we had to carry
out changes for the split PR.

Thanks,
Lorenzo

> 

> Thanks,

> John

> 

> >Lorenzo

> >

> >>The log is as below:

> >>

> >>	estuary:/$ dmesg

> >>	[    0.000000] Booting Linux on physical CPU 0x10000

> >>	[    0.000000] Linux version 4.11.0-rc3-14418-gea60d0a (xuwei@EstBuildSvr1) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #28 SMP PREEMPT Thu Mar 30 16:15:42 CST 2017

> >>	[    0.000000] Boot CPU: AArch64 Processor [410fd082]

> >>	[    0.000000] efi: Getting EFI parameters from FDT:

> >>	[    0.000000] efi: EFI v2.60 by EDK II

> >>	[    0.000000] efi:  SMBIOS=0x3f040000  SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000  ACPI 2.0=0x39bc0014  MEMATTR=0x3ccb0098

> >>	[    0.000000] cma: Reserved 16 MiB at 0x000000003e000000

> >>

> >>

> >>	estuary:/$ ping 192.168.1.107

> >>	PING 192.168.1.107 (192.168.1.107): 56 data bytes

> >>	64 bytes from 192.168.1.107: seq=0 ttl=64 time=0.273 ms

> >>	64 bytes from 192.168.1.107: seq=1 ttl=64 time=0.102 ms

> >>	64 bytes from 192.168.1.107: seq=2 ttl=64 time=0.103 ms

> >>	64 bytes from 192.168.1.107: seq=3 ttl=64 time=0.098 ms

> >>	^C

> >>	--- 192.168.1.107 ping statistics ---

> >>	4 packets transmitted, 4 packets received, 0% packet loss

> >>	round-trip min/avg/max = 0.098/0.144/0.273 ms

> >>

> >>	estuary:/$ lspci -mk

> >>	30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> >>	91:00.0 "Class 0300" "19e5" "1711" "0000" "0000"

> >>	90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> >>	20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> >>	10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> >>	80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> >>	00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> >>	c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> >>	88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

> >>	

> >>	estuary:/$ cat /dev/sd

> >>	sda   sdb   sdc   sdd   sde   sdf   sdg   sdh   sdi   sdj   sdk sdl

> >>	sda1  sdb1  sdc1  sdd1  sde1  sdf1  sdg1  sdh1  sdi1  sdj1  sdk1 sdl1

> >>

> >>Best Regards,

> >>Wei

> >>

> >>>

> >>>Thanks

> >>>Hanjun

> >>>

> >>>.

> >>>

> >>

> >_______________________________________________

> >linuxarm mailing list

> >linuxarm@huawei.com

> >http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

> >

> >.

> >

> 

> 

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
majun (F) March 31, 2017, 2:41 a.m. | #9
Hi Lorenzo:

在 2017/3/31 0:54, Lorenzo Pieralisi 写道:
> On Thu, Mar 30, 2017 at 05:14:34PM +0100, John Garry wrote:

>>

>>>>>>>

>>>>>>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework

>>>>>>> this patch and post the resulting branch for everyone to have a final

>>>>>>> test.

[...]
>>>>

>>>> Thanks to all of you!

>>>> Tested on D05 board with this branch, the SAS disks and XGE port are working fine.

>>>

>>> Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull

>>> request to Catalin tomorrow, please carry out last few checks before

>>> I send it:

>>>

>>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git tags/acpi-arm64-for-v4.12

>>>

>>> You should try to merge it with Marc's branch:

>>>

>>> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-4.12

>>>

>>> and test the resulting branch, that's how they will go upstream.

>>>

>>> Please let me know, thank you for your help !

>>>

>>

>> Hi Lorenzo,

>>

>> xuwei is away now, and it is night time with majun, so I tested.

>> majun can retest tomorrow again to triple-check. I did not touch the

>> ITS patch Marc made which had the weak version of

>> iort_pmis_get_dev_id(), but it should not affect anything in my

>> test.

>>

>> After merging your tag to Marc's branch, here is the git log:

>> git log --oneline

>> 8b6f3f8 Merge tag 'acpi-arm64-for-v4.12' into irq/irqchip-4.12

>> d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device

>> ae7c183 ACPI: platform-msi: retrieve devid from IORT

>> e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support

>> 8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id

>> 697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic

>> d11349c irqchip: mbigen: Add ACPI support

>> aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain()

>> 964bac1 irqchip: mbigen: drop module owner

>> b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware

>> d264edb irqchip: gicv3-its: platform-msi: scan MADT to create

>> platform msi domain

>> baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init()

>> to prepare for ACPI

>> fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()

>> cc9eb0d irqchip: gic-v3-its: keep the include header files in

>> alphabetic order

>> ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type

>> ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number

>> 3382357 dt-bindings: mediatek: multiple bases support for sysirq

>> 4015616 irqchip: replace moxa with ftintc010

>> 532278c irqchip: faraday: fix the trigger types

>> 923fa67 irqchip: refactor Gemini driver to reflect Faraday origin

>> 44d64ce irqchip: augment Gemini bindings to reflect Faraday origin

>> c02ed2e Linux 4.11-rc4

>>

>> And some testing:

>>

[...]
>>

>> Disk /dev/sdf: 186.3 GiB, 200049647616 bytes, 390721968 sectors

>> Units: sectors of 1 * 512 = 512 bytes

>> Sector size (logical/physical): 512 bytes / 512 bytes

>> I/O size (minimum/optimal): 512 bytes / 131072 bytes

>>

>> root@(none)$

>>

>> Looks ok

> 

> Great, thanks !

> 

>> @majun, please test as well.

> 

> Yes, final test, PR is ready to be sent, I reviewed Hanjun patches

> but I just want to avoid breaking them given that we had to carry

> out changes for the split PR.

> 

I tested these patches again as you suggested, all of the related devices,
xge/sas/usb/uart, are working fine on my hisilicon board just like before.

The git log is:
565fdf3 Merge tag 'acpi-arm64-for-v4.12' into marc-irq-4.12
d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device
ae7c183 ACPI: platform-msi: retrieve devid from IORT
e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support
8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic
d11349c irqchip: mbigen: Add ACPI support
aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain()
964bac1 irqchip: mbigen: drop module owner
b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware
d264edb irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain
baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI
fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
cc9eb0d irqchip: gic-v3-its: keep the include header files in alphabetic order
ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type
ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number
3382357 dt-bindings: mediatek: multiple bases support for sysirq
4015616 irqchip: replace moxa with ftintc010
532278c irqchip: faraday: fix the trigger types
923fa67 irqchip: refactor Gemini driver to reflect Faraday origin
44d64ce irqchip: augment Gemini bindings to reflect Faraday origin
c02ed2e Linux 4.11-rc4

Thanks
Ma Jun

> Thanks,

> Lorenzo

> 

>>

>> Thanks,

>> John

>>

>>> Lorenzo

>>>

>>>> The log is as below:

>>>>

>>>> 	estuary:/$ dmesg

>>>> 	[    0.000000] Booting Linux on physical CPU 0x10000

>>>> 	[    0.000000] Linux version 4.11.0-rc3-14418-gea60d0a (xuwei@EstBuildSvr1) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #28 SMP PREEMPT Thu Mar 30 16:15:42 CST 2017

>>>> 	[    0.000000] Boot CPU: AArch64 Processor [410fd082]

>>>> 	[    0.000000] efi: Getting EFI parameters from FDT:

>>>> 	[    0.000000] efi: EFI v2.60 by EDK II

>>>> 	[    0.000000] efi:  SMBIOS=0x3f040000  SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000  ACPI 2.0=0x39bc0014  MEMATTR=0x3ccb0098

>>>> 	[    0.000000] cma: Reserved 16 MiB at 0x000000003e000000

>>>>

>>>>

>>>> 	estuary:/$ ping 192.168.1.107

>>>> 	PING 192.168.1.107 (192.168.1.107): 56 data bytes

>>>> 	64 bytes from 192.168.1.107: seq=0 ttl=64 time=0.273 ms

>>>> 	64 bytes from 192.168.1.107: seq=1 ttl=64 time=0.102 ms

>>>> 	64 bytes from 192.168.1.107: seq=2 ttl=64 time=0.103 ms

>>>> 	64 bytes from 192.168.1.107: seq=3 ttl=64 time=0.098 ms

>>>> 	^C

>>>> 	--- 192.168.1.107 ping statistics ---

>>>> 	4 packets transmitted, 4 packets received, 0% packet loss

>>>> 	round-trip min/avg/max = 0.098/0.144/0.273 ms

>>>>

>>>> 	estuary:/$ lspci -mk

>>>> 	30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>>>> 	91:00.0 "Class 0300" "19e5" "1711" "0000" "0000"

>>>> 	90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>>>> 	20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>>>> 	10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>>>> 	80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>>>> 	00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>>>> 	c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>>>> 	88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"

>>>> 	

>>>> 	estuary:/$ cat /dev/sd

>>>> 	sda   sdb   sdc   sdd   sde   sdf   sdg   sdh   sdi   sdj   sdk sdl

>>>> 	sda1  sdb1  sdc1  sdd1  sde1  sdf1  sdg1  sdh1  sdi1  sdj1  sdk1 sdl1

>>>>

>>>> Best Regards,

>>>> Wei

>>>>

>>>>>

>>>>> Thanks

>>>>> Hanjun

>>>>>

>>>>> .

>>>>>

>>>>

>>> _______________________________________________

>>> linuxarm mailing list

>>> linuxarm@huawei.com

>>> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

>>>

>>> .

>>>

>>

>>

> --

> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in

> the body of a message to majordomo@vger.kernel.org

> More majordomo info at  http://vger.kernel.org/majordomo-info.html

> 

> .

> 


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch hide | download patch | download mbox

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 83cd59d..fb95ceb 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -468,6 +468,30 @@  u32 iort_msi_map_rid(struct device *dev, u32 req_id)
 }
 
 /**
+ * iort_pmsi_get_dev_id() - Get the device id for a device
+ * @dev: The device for which the mapping is to be done.
+ * @dev_id: The device ID found.
+ *
+ * Returns: 0 for successful find a dev id, -ENODEV on error
+ */
+int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
+{
+	int i;
+	struct acpi_iort_node *node;
+
+	node = iort_find_dev_node(dev);
+	if (!node)
+		return -ENODEV;
+
+	for (i = 0; i < node->mapping_count; i++) {
+		if (iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE, i))
+			return 0;
+	}
+
+	return -ENODEV;
+}
+
+/**
  * iort_dev_find_its_id() - Find the ITS identifier for a device
  * @dev: The device.
  * @req_id: Device's requester ID
diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index e4ba9f4..e801fc0 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -57,7 +57,8 @@  static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
 
 	msi_info = msi_get_domain_info(domain->parent);
 
-	ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
+	ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, &dev_id) :
+		iort_pmsi_get_dev_id(dev, &dev_id);
 	if (ret)
 		return ret;
 
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 77e0809..d074c77 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -34,6 +34,7 @@ 
 bool iort_node_match(u8 type);
 u32 iort_msi_map_rid(struct device *dev, u32 req_id);
 struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
+int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
 /* IOMMU interface */
 void iort_set_dma_mask(struct device *dev);
 const struct iommu_ops *iort_iommu_configure(struct device *dev);
@@ -45,6 +46,10 @@  static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
 static inline struct irq_domain *iort_get_device_domain(struct device *dev,
 							u32 req_id)
 { return NULL; }
+
+static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
+{ return -ENODEV; }
+
 /* IOMMU interface */
 static inline void iort_set_dma_mask(struct device *dev) { }
 static inline