From: Hanjun Guo <guohanjun@huawei.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Greg KH <gregkh@linuxfoundation.org>,
Tomasz Nowicki <tn@semihalf.com>, Ma Jun <majun258@huawei.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Sinan Kaya <okaya@codeaurora.org>,
huxinwei@huawei.com, yimin@huawei.com, linuxarm@huawei.com,
Hanjun Guo <hanjun.guo@linaro.org>
Subject: Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT
Date: Sat, 11 Mar 2017 16:56:02 +0800 [thread overview]
Message-ID: <58C3BBA2.1090600@huawei.com> (raw)
In-Reply-To: <20170307143525.GA26990@red-moon>
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(-)
diff --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;
>
> 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
WARNING: multiple messages have this Message-ID (diff)
From: guohanjun@huawei.com (Hanjun Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT
Date: Sat, 11 Mar 2017 16:56:02 +0800 [thread overview]
Message-ID: <58C3BBA2.1090600@huawei.com> (raw)
In-Reply-To: <20170307143525.GA26990@red-moon>
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 at 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(-)
diff --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;
>
> 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
WARNING: multiple messages have this Message-ID (diff)
From: Hanjun Guo <guohanjun@huawei.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
<linux-acpi@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Greg KH <gregkh@linuxfoundation.org>,
Tomasz Nowicki <tn@semihalf.com>, Ma Jun <majun258@huawei.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Sinan Kaya <okaya@codeaurora.org>, <huxinwei@huawei.com>,
<yimin@huawei.com>, <linuxarm@huawei.com>,
Hanjun Guo <hanjun.guo@linaro.org>
Subject: Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT
Date: Sat, 11 Mar 2017 16:56:02 +0800 [thread overview]
Message-ID: <58C3BBA2.1090600@huawei.com> (raw)
In-Reply-To: <20170307143525.GA26990@red-moon>
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(-)
diff --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;
>
> 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
next prev parent reply other threads:[~2017-03-11 8:58 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-07 12:39 [PATCH v9 00/15] ACPI platform MSI support and its example mbigen Hanjun Guo
2017-03-07 12:39 ` Hanjun Guo
2017-03-07 12:39 ` Hanjun Guo
2017-03-07 12:39 ` [PATCH v9 01/15] ACPI/IORT: Fix the indentation in iort_scan_node() Hanjun Guo
2017-03-07 12:39 ` Hanjun Guo
2017-03-07 12:39 ` Hanjun Guo
2017-03-07 12:39 ` [PATCH v9 02/15] ACPI/IORT: Add missing comment for iort_dev_find_its_id() Hanjun Guo
2017-03-07 12:39 ` Hanjun Guo
2017-03-07 12:39 ` Hanjun Guo
2017-03-07 12:39 ` [PATCH v9 03/15] ACPI/IORT: Rework iort_match_node_callback() return value handling Hanjun Guo
2017-03-07 12:39 ` Hanjun Guo
2017-03-07 12:39 ` Hanjun Guo
2017-03-07 12:39 ` [PATCH v9 04/15] irqchip: gic-v3-its: keep the include header files in alphabetic order Hanjun Guo
2017-03-07 12:39 ` Hanjun Guo
2017-03-07 12:39 ` Hanjun Guo
2017-03-07 12:40 ` [PATCH v9 05/15] irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare() Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` [PATCH v9 06/15] irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` [PATCH v9 07/15] irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` [PATCH v9 08/15] ACPI/IORT: Rename iort_node_map_rid() to make it generic Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` [PATCH v9 09/15] ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 14:35 ` Lorenzo Pieralisi
2017-03-07 14:35 ` Lorenzo Pieralisi
2017-03-07 14:35 ` Lorenzo Pieralisi
2017-03-11 8:56 ` Hanjun Guo [this message]
2017-03-11 8:56 ` Hanjun Guo
2017-03-11 8:56 ` Hanjun Guo
2017-03-29 10:14 ` Lorenzo Pieralisi
2017-03-29 10:14 ` Lorenzo Pieralisi
2017-03-29 11:52 ` Hanjun Guo
2017-03-29 11:52 ` Hanjun Guo
2017-03-29 11:52 ` Hanjun Guo
2017-03-29 12:38 ` Lorenzo Pieralisi
2017-03-29 12:38 ` Lorenzo Pieralisi
2017-03-29 13:00 ` Hanjun Guo
2017-03-29 13:00 ` Hanjun Guo
2017-03-29 14:52 ` Marc Zyngier
2017-03-29 14:52 ` Marc Zyngier
2017-03-29 16:13 ` Lorenzo Pieralisi
2017-03-29 16:13 ` Lorenzo Pieralisi
2017-03-29 17:32 ` Lorenzo Pieralisi
2017-03-29 17:32 ` Lorenzo Pieralisi
2017-03-30 3:07 ` Hanjun Guo
2017-03-30 3:07 ` Hanjun Guo
2017-03-30 4:08 ` majun (Euler7)
2017-03-30 4:08 ` majun (Euler7)
2017-03-30 4:08 ` majun (Euler7)
2017-03-30 8:32 ` Wei Xu
2017-03-30 8:32 ` Wei Xu
2017-03-30 8:32 ` Wei Xu
2017-03-30 14:28 ` Lorenzo Pieralisi
2017-03-30 14:28 ` Lorenzo Pieralisi
2017-03-30 16:14 ` John Garry
2017-03-30 16:14 ` John Garry
2017-03-30 16:14 ` John Garry
2017-03-30 16:54 ` Lorenzo Pieralisi
2017-03-30 16:54 ` Lorenzo Pieralisi
2017-03-31 2:41 ` majun (Euler7)
2017-03-31 2:41 ` majun (Euler7)
2017-03-31 2:41 ` majun (Euler7)
2017-03-07 12:40 ` [PATCH v9 11/15] ACPI: platform: setup MSI domain for ACPI based platform device Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` [PATCH v9 12/15] msi: platform: make platform_msi_create_device_domain() ACPI aware Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` [PATCH v9 13/15] irqchip: mbigen: drop module owner Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` [PATCH v9 14/15] irqchip: mbigen: introduce mbigen_of_create_domain() Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` [PATCH v9 15/15] irqchip: mbigen: Add ACPI support Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-07 12:40 ` Hanjun Guo
2017-03-21 14:45 ` Lorenzo Pieralisi
2017-03-21 14:45 ` Lorenzo Pieralisi
2017-03-22 14:12 ` John Garry
2017-03-22 14:12 ` John Garry
2017-03-22 14:12 ` John Garry
2017-03-27 8:46 ` Marc Zyngier
2017-03-27 8:46 ` Marc Zyngier
2017-03-27 8:46 ` Marc Zyngier
2017-03-27 12:24 ` Gabriele Paoloni
2017-03-27 12:24 ` Gabriele Paoloni
2017-03-27 15:27 ` Lorenzo Pieralisi
2017-03-27 15:27 ` Lorenzo Pieralisi
2017-03-27 18:56 ` Al Stone
2017-03-27 18:56 ` Al Stone
2017-03-27 20:23 ` Hanjun Guo
2017-03-27 20:23 ` Hanjun Guo
2017-03-07 14:43 ` [PATCH v9 00/15] ACPI platform MSI support and its example mbigen Lorenzo Pieralisi
2017-03-07 14:43 ` Lorenzo Pieralisi
2017-03-07 14:43 ` Lorenzo Pieralisi
2017-03-09 13:22 ` Hanjun Guo
2017-03-09 13:22 ` Hanjun Guo
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=58C3BBA2.1090600@huawei.com \
--to=guohanjun@huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=hanjun.guo@linaro.org \
--cc=huxinwei@huawei.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=majun258@huawei.com \
--cc=marc.zyngier@arm.com \
--cc=okaya@codeaurora.org \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--cc=tn@semihalf.com \
--cc=wangkefeng.wang@huawei.com \
--cc=yimin@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.