ACPI platform MSI support and its example mbigen
Subsystems (5)
Hanjun Guo
maintainerv8 cover ACPI platform MSI support and its example mbigen
From: Hanjun Guo <[email protected]>
With platform msi support landed in the kernel, and the introduction of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi is ready, this patch set add few patches to enable the ACPI platform msi support.
For platform device connecting to ITS on arm platform, we have IORT table with the named componant node to describe the mappings of paltform device and ITS, so we can retrieve the dev id and find its parent irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
v7 -> v8:
- Using _CRS instead of _PRS for Interrupt resources for mbigen
- reshuffle the patch slightly to introduce iort_node_map_platform_id() first and then retrieve the dev id for platform MSI, no functional change
- Fix the compile error with patch "irqchip: gicv3-its: platform-msi:
scan MADT to create platform msi domain", which forgot to add <include/acpi_iort.h> (added in later patches in last version).
- renew some commit message which suggested by Lorenzo
- address some othe minor issues which commented by Lorenzo
- Add review and test tag as it's no functional change except the last patch of mbigen
- rebase on top of 4.10-rc4 and test it on x86, ia64 and ARM64 platforms (also with Agustin's patch [1-2/3] "[PATCH V9 0/3] irqchip: qcom:
Add IRQ combiner driver" and Lorenzo's patch
https://patchwork.kernel.org/patch/9507041/)
v6 -> v7:
- Introduce iort_node_map_platform_id() to retrieve the dev id for both NC (named component) -> ITS/SMMU and NC -> SMMU -> ITS cases, suggested by Lorenzo;
- Reorder the patches and rewrite some commit message;
- Remove the test tags because it has major changes to retrieve the dev id, Sinan, Majun, Xinwei, could you please test them again on your platform?
- rebased on top of 4.10-rc3 and Lorenzo's patch
https://patchwork.kernel.org/patch/9507041/
- Tested against Agustin's patch [1-2/3] "[PATCH V9 0/3] irqchip: qcom:
Add IRQ combiner driver"
v5 -> v6:
- Call acpi_configure_pmsi_domain() for platform devices in acpi_platform_notify() as it's cleaner (suggested by Rafael)
- Remove the "u8 type" for iort_id_map() because it's unused
- Rebase on top of 4.10-rc2
- Collect test and review tags
v4 -> v5:
- Add mbigen support back with tested on with Agustin's patchset,
and it's a good example of how ACPI platform MSI works
- rebased on top of lastest Linus tree (commit 52bce91 splice: reinstate SIGPIPE/EPIPE handling)
v3 -> v4:
- Drop mbi-gen patches to just submit platform msi support because will rebase mbi-gen patches on top of Agustin's patchset, and discusion is going there.
- Add a patch to support device topology such as NC(named componant, paltform device) ->SMMU->ITS which suggested by Lorenzo;
- rebased on top of Lorenzo's v9 of ACPI IORT ARM SMMU support;
- rebased on top of 4.9-rc7
v2 -> v3:
- Drop RFC tag
- Rebase against v4.9-rc2 and Lorenzo's v6 of ACPI IORT ARM SMMU support [1]
- Add 3 cleanup patches (patch 1, 2, 3)
- Drop arch_init call patch from last version
- Introduce a callback for platform device to set msi domain
- Introduce a new API to get paltform device's domain instead of reusing the PCI one in previous version
- Add a patch to rework iort_node_get_id()
[1]: http://www.mail-archive.com/[email protected]/msg1251993.html
v1 -> v2:
- Fix the bug of if multi Interrupt() resoures in single _PRS, we need to calculate all the irq numbers (I missed it in previous version);
- Rebased on Marc's irq/irqchip-4.9 branch and Lorenzo's v5 SMMU patches (also Robin's SMMu patches)
- Add patch irqchip: mbigen: promote mbigen init.
Hanjun Guo (13):
ACPI: IORT: fix the indentation in iort_scan_node()
ACPI: IORT: add missing comment for iort_dev_find_its_id()
ACPI: IORT: minor cleanup for iort_match_node_callback()
irqchip: gic-v3-its: keep the head file include in alphabetic order
irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare
for ACPI
irqchip: gicv3-its: platform-msi: scan MADT to create platform msi
domain
ACPI: IORT: rename iort_node_map_rid() to make it generic
ACPI: IORT: introduce iort_node_map_platform_id() to retrieve dev id
ACPI: platform-msi: retrieve dev id from IORT
ACPI: platform: setup MSI domain for ACPI based platform device
msi: platform: make platform_msi_create_device_domain() ACPI aware
irqchip: mbigen: Add ACPI support
Kefeng Wang (2):
irqchip: mbigen: drop module owner
irqchip: mbigen: introduce mbigen_of_create_domain()
drivers/acpi/arm64/iort.c | 158 +++++++++++++++++++++----- drivers/acpi/glue.c | 6 + drivers/base/platform-msi.c | 3 +- drivers/irqchip/irq-gic-v3-its-platform-msi.c | 106 +++++++++++++---- drivers/irqchip/irq-gic-v3-its.c | 3 +- drivers/irqchip/irq-mbigen.c | 109 +++++++++++++++--- include/linux/acpi_iort.h | 8 ++ 7 files changed, 316 insertions(+), 77 deletions(-)
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 1/15 ACPI: IORT: fix the indentation in iort_scan_node()
From: Hanjun Guo <[email protected]>
The indentation is wrong when return the iort_node, fix it.
--- drivers/acpi/arm64/iort.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/acpi/arm64/iort.c +1 -1
@@ -225,7 +225,7 @@ static struct acpi_iort_node *iort_scan_node(enum acpi_iort_node_type type,if (iort_node->type == type &&ACPI_SUCCESS (callback (iort_node, context))) -return iort_node; +return iort_node; iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node, iort_node->length);
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 2/15 ACPI: IORT: add missing comment for iort_dev_find_its_id()
In reply to Hanjun GuoFrom: Hanjun Guo <[email protected]>
Add missing req_id parameter to the iort_dev_find_its_id() function kernel-doc comment.
--- drivers/acpi/arm64/iort.c | 1 + 1 file changed, 1 insertion(+)
drivers/acpi/arm64/iort.c +1 -0
@@ -450,6 +450,7 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)/** * iort_dev_find_its_id() - Find the ITS identifier for a device * @dev: The device. +* @req_id: Device's requester ID * @idx: Index of the ITS identifier list. * @its_id: ITS identifier. *
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 3/15 ACPI: IORT: minor cleanup for iort_match_node_callback()
In reply to Hanjun GuoFrom: Hanjun Guo <[email protected]>
Cleanup iort_match_node_callback() a little bit to reduce some lines of code.
--- drivers/acpi/arm64/iort.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
drivers/acpi/arm64/iort.c +2 -6
@@ -253,17 +253,15 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node, void *context) {struct device *dev = context; -acpi_status status; +acpi_status status =AE_NOT_FOUND ;if (node->type ==ACPI_IORT_NODE_NAMED_COMPONENT ) {struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER ,NULL };struct acpi_device *adev =to_acpi_device_node (dev->fwnode);struct acpi_iort_named_component *ncomp; -if (!adev) { - status =AE_NOT_FOUND ; +if (!adev) goto out; - } status =acpi_get_name (adev->handle,ACPI_FULL_PATHNAME , &buf);if (ACPI_FAILURE (status)) {
@@ -289,8 +287,6 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,*/ status = pci_rc->pci_segment_number ==pci_domain_nr (bus) ?AE_OK :AE_NOT_FOUND ; - }else { - status =AE_NOT_FOUND ; } out:return status;
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 4/15 irqchip: gic-v3-its: keep the head file include in alphabetic order
In reply to Hanjun GuoFrom: Hanjun Guo <[email protected]>
Rearrange header file includes to alphabetic order. As acpi_iort.h includes acpi.h so remove the duplidate acpi.h inclusion as well.
--- drivers/irqchip/irq-gic-v3-its.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/irqchip/irq-gic-v3-its.c +1 -2
@@ -15,14 +15,13 @@* along with this program. If not, see <http://www.gnu.org/licenses/>. */ -#include <linux/acpi.h> +#include <linux/acpi_iort.h> #include <linux/bitmap.h> #include <linux/cpu.h> #include <linux/delay.h> #include <linux/dma-iommu.h> #include <linux/interrupt.h> #include <linux/irqdomain.h> -#include <linux/acpi_iort.h> #include <linux/log2.h> #include <linux/mm.h> #include <linux/msi.h>
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 5/15 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
In reply to Hanjun GuoFrom: Hanjun Guo <[email protected]>
Adding ACPI support for platform MSI, we need to retrieve the dev id in ACPI way instead of device tree, we already have a well formed function its_pmsi_prepare() to get the dev id but it's OF dependent, so collect OF related code and put them into a single function to make its_pmsi_prepare() more friendly to ACPI later.
--- drivers/irqchip/irq-gic-v3-its-platform-msi.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-)
drivers/irqchip/irq-gic-v3-its-platform-msi.c +16 -7
@@ -24,15 +24,11 @@ .name = "ITS-pMSI", }; -static int its_pmsi_prepare (struct irq_domain *domain,struct device *dev, -int nvec,msi_alloc_info_t *info) +static int of_pmsi_get_dev_id (struct irq_domain *domain,struct device *dev, +u32 *dev_id) { -struct msi_domain_info *msi_info; -u32 dev_id;int ret, index =0 ; - msi_info =msi_get_domain_info (domain->parent); -/* Suck the DeviceID out of the msi-parent property */ do { struct of_phandle_args args;
@@ -43,11 +39,24 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,if (args.np ==irq_domain_get_of_node (domain)) {if (WARN_ON (args.args_count !=1 ))return -EINVAL ; - dev_id = args.args[0 ]; + *dev_id = args.args[0 ];break ; } }while (!ret); +return ret; +} + +static int its_pmsi_prepare (struct irq_domain *domain,struct device *dev, +int nvec,msi_alloc_info_t *info) +{ +struct msi_domain_info *msi_info; +u32 dev_id; +int ret; + + msi_info =msi_get_domain_info (domain->parent); + + ret =of_pmsi_get_dev_id (domain, dev, &dev_id);if (ret)return ret;
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 6/15 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI
In reply to Hanjun GuoFrom: Hanjun Guo <[email protected]>
Introduce its_pmsi_init_one() to refactor the code to isolate ACPI&DT common code to prepare for ACPI later.
--- drivers/irqchip/irq-gic-v3-its-platform-msi.c | 45 ++++++++++++++++----------- 1 file changed, 27 insertions(+), 18 deletions(-)
drivers/irqchip/irq-gic-v3-its-platform-msi.c +27 -18
@@ -82,34 +82,43 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, {}, }; -static int __init its_pmsi_init (void ) +static int __init its_pmsi_init_one (struct fwnode_handle *fwnode, +const char *name) { -struct device_node *np;struct irq_domain *parent; + parent =irq_find_matching_fwnode (fwnode,DOMAIN_BUS_NEXUS ); +if (!parent || !msi_get_domain_info (parent)) { +pr_err ("%s: unable to locate ITS domain\n" , name); +return -ENXIO ; + } + +if (!platform_msi_create_irq_domain (fwnode, &its_pmsi_domain_info, + parent)) { +pr_err ("%s: unable to create platform domain\n" , name); +return -ENXIO ; + } + +pr_info ("Platform MSI: %s domain created\n" , name); +return 0 ; +} + +static void __init its_pmsi_of_init (void ) +{ +struct device_node *np; +for (np =of_find_matching_node (NULL , its_device_id); np; np =of_find_matching_node (np, its_device_id)) {if (!of_property_read_bool (np,"msi-controller" ))continue ; - parent =irq_find_matching_host (np,DOMAIN_BUS_NEXUS ); -if (!parent || !msi_get_domain_info (parent)) { -pr_err ("%s: unable to locate ITS domain\n" , - np->full_name); -continue ; - } - -if (!platform_msi_create_irq_domain (of_node_to_fwnode (np), - &its_pmsi_domain_info, - parent)) { -pr_err ("%s: unable to create platform domain\n" , - np->full_name); -continue ; - } - -pr_info ("Platform MSI: %s domain created\n" , np->full_name); +its_pmsi_init_one (of_node_to_fwnode (np), np->full_name); } +} +static int __init its_pmsi_init (void ) +{ +its_pmsi_of_init ();return 0 ; }early_initcall (its_pmsi_init);
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 7/15 irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain
In reply to Hanjun GuoFrom: Hanjun Guo <[email protected]>
With the introduction of its_pmsi_init_one(), we can add some code on top for ACPI support of platform MSI.
We are scanning the MADT table to get the ITS entry(ies), then use the information to create the platform msi domain for devices connect to it, just like the PCI MSI for ITS did.
--- drivers/irqchip/irq-gic-v3-its-platform-msi.c | 37 +++++++++++++++++++++++++++ 1 file changed, 37 insertions(+)
drivers/irqchip/irq-gic-v3-its-platform-msi.c +37 -0
@@ -15,6 +15,7 @@* along with this program. If not, see <http://www.gnu.org/licenses/>. */ +#include <linux/acpi_iort.h> #include <linux/device.h> #include <linux/msi.h> #include <linux/of.h>
@@ -103,6 +104,41 @@ static int __init its_pmsi_init_one(struct fwnode_handle *fwnode,return 0 ; } +#ifdef CONFIG_ACPI +static int __init +its_pmsi_parse_madt (struct acpi_subtable_header *header, +const unsigned long end) +{ +struct acpi_madt_generic_translator *its_entry; +struct fwnode_handle *domain_handle; +const char *node_name; +int err = -ENXIO ; + + its_entry = (struct acpi_madt_generic_translator *)header; + node_name =kasprintf (GFP_KERNEL ,"ITS@0x%lx" , + (long )its_entry->base_address); + domain_handle =iort_find_domain_token (its_entry->translation_id); +if (!domain_handle) { +pr_err ("%s: Unable to locate ITS domain handle\n" , node_name); + goto out; + } + + err =its_pmsi_init_one (domain_handle, node_name); + +out: +kfree (node_name); +return err; +} + +static void __init its_pmsi_acpi_init (void ) +{ +acpi_table_parse_madt (ACPI_MADT_TYPE_GENERIC_TRANSLATOR , + its_pmsi_parse_madt,0 ); +} +#else +static inline void its_pmsi_acpi_init (void ) { } +#endif +static void __init its_pmsi_of_init (void ) {struct device_node *np;
@@ -119,6 +155,7 @@ static void __init its_pmsi_of_init(void)static int __init its_pmsi_init (void ) {its_pmsi_of_init (); +its_pmsi_acpi_init ();return 0 ; }early_initcall (its_pmsi_init);
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 8/15 ACPI: IORT: rename iort_node_map_rid() to make it generic
In reply to Hanjun GuoFrom: Hanjun Guo <[email protected]>
iort_node_map_rid() was designed to take an input id (that is not necessarily a PCI requester id) and map it to an output id (eg an SMMU streamid or an ITS deviceid) according to the mappings provided by an IORT node mapping entries. This means that the iort_node_map_rid() input id is not always a PCI requester id as its name, parameters and local variables suggest, which is misleading.
Apply the s/rid/id substitution to the iort_node_map_rid() mapping function and its users to make sure its intended usage is clearer.
--- drivers/acpi/arm64/iort.c | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-)
drivers/acpi/arm64/iort.c +15 -15
@@ -355,11 +355,11 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,return NULL ; } -static struct acpi_iort_node *iort_node_map_rid (struct acpi_iort_node *node, -u32 rid_in,u32 *rid_out, -u8 type_mask) +static struct acpi_iort_node *iort_node_map_id (struct acpi_iort_node *node, +u32 id_in,u32 *id_out, +u8 type_mask) { -u32 rid = rid_in; +u32 id = id_in;/* Parse the ID mapping tree to find specified node type */ while (node) {
@@ -367,8 +367,8 @@ static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,int i;if (IORT_TYPE_MASK (node->type) & type_mask) { -if (rid_out) - *rid_out = rid; +if (id_out) + *id_out = id;return node; }
@@ -385,9 +385,9 @@ static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node, goto fail_map; } -/* Do the RID translation */ +/* Do the ID translation */ for (i =0 ; i < node->mapping_count; i++, map++) { -if (!iort_id_map (map, node->type, rid, &rid)) +if (!iort_id_map (map, node->type, id, &id))break ; }
@@ -399,9 +399,9 @@ static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node, } fail_map: -/* Map input RID to output RID unchanged on mapping failure*/ -if (rid_out) - *rid_out = rid_in; +/* Map input ID to output ID unchanged on mapping failure */ +if (id_out) + *id_out = id_in;return NULL ; }
@@ -439,7 +439,7 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)if (!node)return req_id; -iort_node_map_rid (node, req_id, &dev_id,IORT_MSI_TYPE ); +iort_node_map_id (node, req_id, &dev_id,IORT_MSI_TYPE );return dev_id; }
@@ -462,7 +462,7 @@ static int iort_dev_find_its_id(struct device *dev, u32 req_id,if (!node)return -ENXIO ; - node =iort_node_map_rid (node, req_id,NULL ,IORT_MSI_TYPE ); + node =iort_node_map_id (node, req_id,NULL ,IORT_MSI_TYPE );if (!node)return -ENXIO ;
@@ -591,8 +591,8 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)if (!node)return NULL ; - parent =iort_node_map_rid (node, rid, &streamid, -IORT_IOMMU_TYPE ); + parent =iort_node_map_id (node, rid, &streamid, +IORT_IOMMU_TYPE ); ops =iort_iommu_xlate (dev, parent, streamid);
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 9/15 ACPI: IORT: introduce iort_node_map_platform_id() to retrieve dev id
In reply to Hanjun GuoFrom: Hanjun Guo <[email protected]>
For named components if we want to retrieve the dev id, we know that there are always two steps involved (second is optional):
(1) Retrieve the initial id (this may well provide the final mapping)
(2) Map the id (optional if (1) represents the map type we need), this
is needed for use cases such as NC (named component) -> SMMU -> ITS
mappings.we have API iort_node_get_id() for step (1) above and iort_node_map_rid() for step (2), so create a wrapper iort_node_map_platform_id() to retrieve the dev id.
iort_node_map_platform_id() will handle the parent type so type handing in iort_node_get_id() is duplicate, remove it and update current iort_node_get_id() users to move them over to iort_node_map_platform_id().
--- drivers/acpi/arm64/iort.c | 43 ++++++++++++++++++++++++++++++++++--------- 1 file changed, 34 insertions(+), 9 deletions(-)
drivers/acpi/arm64/iort.c +34 -9
@@ -318,8 +318,7 @@ static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,static struct acpi_iort_node *iort_node_get_id (struct acpi_iort_node *node, -u32 *id_out,u8 type_mask, -int index) +u32 *id_out,int index) {struct acpi_iort_node *parent;struct acpi_iort_id_mapping *map;
@@ -341,9 +340,6 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node, parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table, map->output_reference); -if (!(IORT_TYPE_MASK (parent->type) & type_mask)) -return NULL ; -if (map->flags &ACPI_IORT_ID_SINGLE_MAPPING ) {if (node->type ==ACPI_IORT_NODE_NAMED_COMPONENT || node->type ==ACPI_IORT_NODE_PCI_ROOT_COMPLEX ) {
@@ -406,6 +402,34 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,return NULL ; } +static +struct acpi_iort_node *iort_node_map_platform_id (struct acpi_iort_node *node, +u32 *id_out,u8 type_mask, +int index) +{ +struct acpi_iort_node *parent; +u32 id; + +/* step 1: retrieve the initial dev id */ + parent =iort_node_get_id (node, &id, index); +if (!parent) +return NULL ; + +/* +* optional step 2: map the initial dev id if its parent is not +* the target type we want, map it again for the use cases such +* as NC (named component) -> SMMU -> ITS. If the type is matched, +* return the initial dev id and its parent pointer directly. +*/ +if (!(IORT_TYPE_MASK (parent->type) & type_mask)) + parent =iort_node_map_id (parent, id, id_out, type_mask); +else +if (id_out) + *id_out = id; + +return parent; +} +static struct acpi_iort_node *iort_find_dev_node (struct device *dev) {struct pci_bus *pbus;
@@ -604,14 +628,15 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)if (!node)return NULL ; - parent =iort_node_get_id (node, &streamid, -IORT_IOMMU_TYPE , i++); + parent =iort_node_map_platform_id (node, &streamid, +IORT_IOMMU_TYPE , i++);while (parent) { ops =iort_iommu_xlate (dev, parent, streamid); - parent =iort_node_get_id (node, &streamid, -IORT_IOMMU_TYPE , i++); + parent =iort_node_map_platform_id (node, &streamid, +IORT_IOMMU_TYPE , + i++); } }
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 10/15 ACPI: platform-msi: retrieve dev id from IORT
In reply to Hanjun GuoFrom: Hanjun Guo <[email protected]>
For devices connecting to ITS, it needs dev id to identify itself, and this dev id is represented in the IORT table in named component node
[1] for platform devices, so in this patch we will scan the IORT to retrieve device's dev id.
With the preparation of iort_node_map_platform_id(), a new API iort_pmsi_get_dev_id() is introduced for that purpose, call it in its_pmsi_prepare() to make retrieving dev id ACPI aware.
[1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
--- 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(-)
drivers/acpi/arm64/iort.c +24 -0
@@ -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
drivers/irqchip/irq-gic-v3-its-platform-msi.c +2 -1
@@ -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;
include/linux/acpi_iort.h +5 -0
@@ -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
Signature · 1 line
1.7.12.4
Re: [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT
drivers/irqchip/irq-gic-v3-its-platform-msi.c static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, · line 64
Quoted 12 lines · Hanjun Guo
drivers/irqchip/irq-gic-v3-its-platform-msi.c +2
-1@@ -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;
Any idea what happened to the change in this function during merge?
63a52b3 platform-msi: Make platform_msi_create_device_domain() ACPI aware e07b978 irqchip/gicv3-its: platform-msi: Scan MADT to create platform msi domain 09be1d5 irqchip/gicv3-its: platform-msi: Refactor its_pmsi_init() to prepare for ACPI 4e96df9 irqchip/gicv3-its: platform-msi: Refactor its_pmsi_prepare() e593828 irqchip/gic-v3-its: Keep the include header files in alphabetic order e226a74 ACPI: platform: setup MSI domain for ACPI based platform device 79c7533 ACPI: platform-msi: retrieve devid from IORT
43394c9 ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id e6eaeae ACPI/IORT: Rename iort_node_map_rid() to make it generic 6acbb92 ACPI/IORT: Rework iort_match_node_callback() return value handling f8e2f50 ACPI/IORT: Add missing comment for iort_dev_find_its_id() 4b1eeee ACPI/IORT: Fix the indentation in iort_scan_node()
I'm getting these warnings when using the above patches on top of 4.11-rc6? The code is basically trying to read OF attribute on an ACPI system.
[ 11.644792] ------------[ cut here ]------------ [ 11.649407] WARNING: CPU: 35 PID: 1 at /local/mnt/workspace/projects/caf/kernel/drivers/irqchip/irq-gic-v3-its-platform-msi.c:41 its_pmsi_prepare+0x9c/0xfc [ 11.663305] Modules linked in: [ 11.666353] [ 11.667839] CPU: 35 PID: 1 Comm: swapper/0 Tainted: G W 4.11.0-00036-g63a52b3 #1 [ 11.676355] Hardware name: (null) (DT) [ 11.680097] task: ffff8007dbab8000 task.stack: ffff8007dbab4000 [ 11.686009] PC is at its_pmsi_prepare+0x9c/0xfc [ 11.690533] LR is at its_pmsi_prepare+0x5c/0xfc [ 11.695056] pc : [<ffff000008371b68>] lr : [<ffff000008371b28>] pstate: 20400045 [ 11.702443] sp : ffff8007dbab7a40 [ 11.705750] x29: ffff8007dbab7a40 x28: 0000000000000000 [ 11.711057] x27: ffff0000092a9000 x26: 0000000000000000 [ 11.716364] x25: ffff8007df02ba00 x24: ffff000008a745a9 [ 11.721670] x23: ffff000008a7459e x22: 000000000000000b [ 11.726976] x21: ffff8007dbab7b70 x20: ffff8007d9c48c10 [ 11.732282] x19: ffff8007dba8ba80 x18: 000000000000000a [ 11.737588] x17: 0000000000001000 x16: 0000000000000040 [ 11.742895] x15: 000000000009bb9b x14: 0040000000000041 [ 11.748201] x13: 0140000000000000 x12: 0088000000000000 [ 11.753507] x11: ffff000008af0000 x10: ffff0000094ad000 [ 11.758814] x9 : 0000000000000000 x8 : ffff8007d977ac00 [ 11.764120] x7 : 0000000000000000 x6 : 000000000000003f [ 11.769426] x5 : ffff8007dbab7a90 x4 : 0000000000000000 [ 11.774733] x3 : 0000000000000006 x2 : 00000000fffffffe [ 11.780039] x1 : ffff8007df02b760 x0 : 0000000008d8fb70 [ 11.785345] [ 11.786830] ---[ end trace 265ed4f0c6d0486b ]--- [ 11.791439] Call trace: [ 11.793879] Exception stack(0xffff8007dbab7870 to 0xffff8007dbab79a0) [ 11.800312] 7860: ffff8007dba8ba80 0001000000000000 [ 11.808134] 7880: ffff8007dbab7a40 ffff000008371b68 ffff7e0000000000 0000000000000004 [ 11.815956] 78a0: ffff000008af0000 0000820000000000 00000000000ff200 ffff8007dbab8000 [ 11.823779] 78c0: 00000000000ff000 ffff0000081cb6ec ffff8007dbab78e0 00000000000ff000 [ 11.831601] 78e0: 0000000000000040 ffff8007ffff2a80 ffff8007dbab7940 ffff000008166530 [ 11.839423] 7900: ffff8007dbab7960 ffff0000081984f4 0000000008d8fb70 ffff8007df02b760 [ 11.847245] 7920: 00000000fffffffe 0000000000000006 0000000000000000 ffff8007dbab7a90 [ 11.855067] 7940: 000000000000003f 0000000000000000 ffff8007d977ac00 0000000000000000 [ 11.862890] 7960: ffff0000094ad000 ffff000008af0000 0088000000000000 0140000000000000 [ 11.870712] 7980: 0040000000000041 000000000009bb9b 0000000000000040 0000000000001000 [ 11.878535] [<ffff000008371b68>] its_pmsi_prepare+0x9c/0xfc [ 11.884101] [<ffff000008109444>] msi_domain_prepare_irqs+0x54/0x68 [ 11.890274] [<ffff0000081095a8>] msi_domain_alloc_irqs+0x30/0x14c [ 11.896361] [<ffff0000084f00cc>] platform_msi_domain_alloc_irqs+0x54/0x8c [ 11.903142] [<ffff0000084566d8>] hidma_probe+0x5ac/0x824 [ 11.908448] [<ffff0000084d16c0>] platform_drv_probe+0x54/0xa4 [ 11.914186] [<ffff0000084cfb20>] driver_probe_device+0x140/0x2a0 [ 11.920185] [<ffff0000084cfcf4>] __driver_attach+0x74/0xa0 [ 11.925664] [<ffff0000084ce0dc>] bus_for_each_dev+0x68/0x98 [ 11.931229] [<ffff0000084cf5b8>] driver_attach+0x20/0x28 [ 11.936534] [<ffff0000084cf16c>] bus_add_driver+0xe0/0x1ec [ 11.942012] [<ffff0000084d05f4>] driver_register+0x90/0xdc [ 11.947490] [<ffff0000084d161c>] __platform_driver_register+0x48/0x50 [ 11.953924] [<ffff000008b9781c>] hidma_driver_init+0x18/0x20 [ 11.959577] [<ffff00000808318c>] do_one_initcall+0x80/0x108 [ 11.965142] [<ffff000008b60d0c>] kernel_init_freeable+0x19c/0x23c [ 11.971228] [<ffff0000087af808>] kernel_init+0x10/0xfc [ 11.976359] [<ffff000008082ec0>] ret_from_fork+0x10/0x50 [ 11.981746] hidma QCOM8062:17: HI-DMA engine driver registration complete
Signature · 3 lines
Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT
Quoted 4 lines · Sinan Kaya
Any idea what happened to the change in this function during merge?
I realized that there is a V9 out there. I'm catching up with the work.
seems to be fixing the issue.
Quoted 4 lines
63a52b3 platform-msi: Make
platform_msi_create_device_domain()ACPI aware e07b978 irqchip/gicv3-its: platform-msi: Scan MADT to create platform msi domain 09be1d5 irqchip/gicv3-its: platform-msi: Refactorits_pmsi_init()to prepare for ACPI 4e96df9 irqchip/gicv3-its: platform-msi: Refactorits_pmsi_prepare()
Quoted 8 lines
e593828 irqchip/gic-v3-its: Keep the include header files in alphabetic order e226a74 ACPI: platform: setup MSI domain for ACPI based platform device 79c7533 ACPI: platform-msi: retrieve devid from IORT
43394c9 ACPI/IORT: Introduceiort_node_map_platform_id()to retrieve dev id e6eaeae ACPI/IORT: Renameiort_node_map_rid()to make it generic 6acbb92 ACPI/IORT: Reworkiort_match_node_callback()return value handling f8e2f50 ACPI/IORT: Add missing comment foriort_dev_find_its_id()4b1eeee ACPI/IORT: Fix the indentation iniort_scan_node()
Apologies for the noise.
Signature · 3 lines
Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Hanjun Guo
maintainerRe: [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT
Hi Sinan,
Quoted 10 lines · Sinan Kaya
Quoted 4 lines · Sinan Kaya
Any idea what happened to the change in this function during merge?
I realized that there is a V9 out there. I'm catching up with the work.
seems to be fixing the issue.
Patches were merged via two trees:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=irq/core
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/core&ofs=50
So please try to merge those two trees and have a try (we tested those patches on our platform and works), if any issues please let me know.
Thanks
Hanjun
Re: [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT
Quoted 8 lines · Hanjun Guo
Patches were merged via two trees:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=irq/core
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/core&ofs=50So please try to merge those two trees and have a try (we tested those patches on our platform and works), if any issues please let me know.
Yeah, I figure that out eventually. No issues. I finished my testing today.
Signature · 3 lines
Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Hanjun Guo
maintainerRe: [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT
Quoted 11 lines · Sinan Kaya
Quoted 8 lines · Hanjun Guo
Patches were merged via two trees:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=irq/core
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/core&ofs=50So please try to merge those two trees and have a try (we tested those patches on our platform and works), if any issues please let me know.
Yeah, I figure that out eventually. No issues. I finished my testing today.
Great, thank you :)
Hanjun Guo
maintainerPATCH v8 11/15 ACPI: platform: setup MSI domain for ACPI based platform device
In reply to Hanjun GuoFrom: Hanjun Guo <[email protected]>
With the platform msi domain created, we can set up the msi domain for a platform device when it's probed.
In order to do that, we need to get the domain that the platform device connecting to, so the iort_get_platform_device_domain() is introduced to retrieve the domain from iort.
After the domain is retrieved, we need a proper way to set the domain to paltform device, as some platform devices such as an irqchip needs the msi irqdomain to be the interrupt parent domain, we need to get irqdomain before platform device is probed but after the platform device is allocated (the time slot of setting the msi domain also works for other cases). So simply call acpi_configure_pmsi_domain() in acpi_platform_notify() for platform devices will work.
--- drivers/acpi/arm64/iort.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++ drivers/acpi/glue.c | 6 ++++++ include/linux/acpi_iort.h | 3 +++ 3 files changed, 59 insertions(+)
drivers/acpi/arm64/iort.c +50 -0
@@ -548,6 +548,56 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)return irq_find_matching_fwnode (handle,DOMAIN_BUS_PCI_MSI ); } +/** +* iort_get_platform_device_domain() - Find MSI domain related to a +* platform device +* @dev: the dev pointer associated with the platform device +* +* Returns: the MSI domain for this device, NULL otherwise +*/ +static struct irq_domain *iort_get_platform_device_domain (struct device *dev) +{ +struct acpi_iort_node *node, *msi_parent; +struct fwnode_handle *iort_fwnode; +struct acpi_iort_its_group *its; +int i; + +/* find its associated iort node */ + node =iort_scan_node (ACPI_IORT_NODE_NAMED_COMPONENT , + iort_match_node_callback, dev); +if (!node) +return NULL ; + +/* then find its msi parent node */ +for (i =0 ; i < node->mapping_count; i++) { + msi_parent =iort_node_map_platform_id (node,NULL , +IORT_MSI_TYPE , i); +if (msi_parent) +break ; + } + +if (!msi_parent) +return NULL ; + +/* Move to ITS specific data */ + its = (struct acpi_iort_its_group *)msi_parent->node_data; + + iort_fwnode =iort_find_domain_token (its->identifiers[0 ]); +if (!iort_fwnode) +return NULL ; + +return irq_find_matching_fwnode (iort_fwnode,DOMAIN_BUS_PLATFORM_MSI ); +} + +void acpi_configure_pmsi_domain (struct device *dev) +{ +struct irq_domain *msi_domain; + + msi_domain =iort_get_platform_device_domain (dev); +if (msi_domain) +dev_set_msi_domain (dev, msi_domain); +} +static int __get_pci_rid (struct pci_dev *pdev,u16 alias,void *data) {u32 *rid = data;
drivers/acpi/glue.c +6 -0
@@ -6,6 +6,8 @@* * This file is released under the GPLv2. */ + +#include <linux/acpi_iort.h> #include <linux/export.h> #include <linux/init.h> #include <linux/list.h>
@@ -14,6 +16,7 @@#include <linux/rwsem.h> #include <linux/acpi.h> #include <linux/dma-mapping.h> +#include <linux/platform_device.h> #include "internal.h"
@@ -322,6 +325,9 @@ static int acpi_platform_notify(struct device *dev)if (!adev) goto out; +if (dev->bus == &platform_bus_type) +acpi_configure_pmsi_domain (dev); +if (type && type->setup) type->setup (dev);else if (adev->handler && adev->handler->bind)
include/linux/acpi_iort.h +3 -0
@@ -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); +void acpi_configure_pmsi_domain (struct device *dev);int iort_pmsi_get_dev_id (struct device *dev,u32 *dev_id);/* IOMMU interface */ void iort_set_dma_mask (struct device *dev);
@@ -47,6 +48,8 @@ static inline struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id) {return NULL ; } +static inline void acpi_configure_pmsi_domain (struct device *dev) { } +static inline int iort_pmsi_get_dev_id (struct device *dev,u32 *dev_id) {return -ENODEV ; }
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 12/15 msi: platform: make platform_msi_create_device_domain() ACPI aware
In reply to Hanjun GuoFrom: Hanjun Guo <[email protected]>
The irqdomain creation is carried out in:
platform_msi_create_device_domain()
relies on the fwnode_handle interrupt controller token to associate the interrupt controller with a specific irqdomain. Current code relies on the OF layer to retrieve a fwnode_handle for the device representing the interrupt controller from its device->of_node pointer. This makes platform_msi_create_device_domain() DT specific whilst it really is not because after the merge of commit f94277af03ea ("of/platform: Initialise dev->fwnode appropriately") the fwnode_handle can easily be retrieved from the dev->fwnode pointer in a firmware agnostic way.
Update platform_msi_create_device_domain() to retrieve the interrupt controller fwnode_handle from the dev->fwnode pointer so that it can be used seamlessly in ACPI and DT systems.
--- drivers/base/platform-msi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/base/platform-msi.c +1 -2
@@ -345,8 +345,7 @@ struct irq_domain * data->host_data = host_data; domain =irq_domain_create_hierarchy (dev->msi_domain,0 , nvec, -of_node_to_fwnode (dev->of_node), - ops, data); + dev->fwnode, ops, data);if (!domain) goto free_priv;
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 13/15 irqchip: mbigen: drop module owner
In reply to Hanjun GuoFrom: Kefeng Wang <[email protected]>
Module owner will be set by driver core, so drop it.
--- drivers/irqchip/irq-mbigen.c | 1 - 1 file changed, 1 deletion(-)
drivers/irqchip/irq-mbigen.c +0 -1
@@ -293,7 +293,6 @@ static int mbigen_device_probe(struct platform_device *pdev)static struct platform_driver mbigen_platform_driver = { .driver = { .name ="Hisilicon MBIGEN-V2" , - .owner =THIS_MODULE , .of_match_table = mbigen_of_match, }, .probe = mbigen_device_probe,
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 14/15 irqchip: mbigen: introduce mbigen_of_create_domain()
In reply to Hanjun GuoFrom: Kefeng Wang <[email protected]>
Introduce mbigen_of_create_domain() to consolidate OF related code and prepare for ACPI later, no funtional change.
--- drivers/irqchip/irq-mbigen.c | 42 +++++++++++++++++++++++++++--------------- 1 file changed, 27 insertions(+), 15 deletions(-)
drivers/irqchip/irq-mbigen.c +27 -15
@@ -236,27 +236,15 @@ static int mbigen_irq_domain_alloc(struct irq_domain *domain, .free = irq_domain_free_irqs_common, }; -static int mbigen_device_probe (struct platform_device *pdev) +static int mbigen_of_create_domain (struct platform_device *pdev, +struct mbigen_device *mgn_chip) { -struct mbigen_device *mgn_chip; +struct device *parent;struct platform_device *child;struct irq_domain *domain;struct device_node *np; -struct device *parent; -struct resource *res;u32 num_pins; - mgn_chip =devm_kzalloc (&pdev->dev,sizeof (*mgn_chip),GFP_KERNEL ); -if (!mgn_chip) -return -ENOMEM ; - - mgn_chip->pdev = pdev; - - res =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); - mgn_chip->base =devm_ioremap_resource (&pdev->dev, res); -if (IS_ERR (mgn_chip->base)) -return PTR_ERR (mgn_chip->base); -for_each_child_of_node (pdev->dev.of_node, np) {if (!of_property_read_bool (np,"interrupt-controller" ))continue ;
@@ -280,6 +268,30 @@ static int mbigen_device_probe(struct platform_device *pdev)return -ENOMEM ; } +return 0 ; +} + +static int mbigen_device_probe (struct platform_device *pdev) +{ +struct mbigen_device *mgn_chip; +struct resource *res; +int err; + + mgn_chip =devm_kzalloc (&pdev->dev,sizeof (*mgn_chip),GFP_KERNEL ); +if (!mgn_chip) +return -ENOMEM ; + + mgn_chip->pdev = pdev; + + res =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); + mgn_chip->base =devm_ioremap (&pdev->dev, res->start,resource_size (res)); +if (IS_ERR (mgn_chip->base)) +return PTR_ERR (mgn_chip->base); + + err =mbigen_of_create_domain (pdev, mgn_chip); +if (err) +return err; +platform_set_drvdata (pdev, mgn_chip);return 0 ; }
Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerPATCH v8 15/15 irqchip: mbigen: Add ACPI support
In reply to Hanjun GuoFrom: Hanjun Guo <[email protected]>
With the preparation of platform msi support and interrupt producer in DSDT, we can add mbigen ACPI support now.
We are using Interrupt resource type in _CRS methd to indicate number of irq pins instead of num_pins in DT to avoid _DSD usage in this case.
For mbigen,
Device(MBI0) {
Name(_HID, "HISI0152")
Name(_UID, Zero)
Name(_CRS, ResourceTemplate() {
Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
Interrupt(ResourceProducer,...) {12,14,....}
})
}For devices,
Device(COM0) {
Name(_HID, "ACPIIDxx")
Name(_UID, Zero)
Name(_CRS, ResourceTemplate() {
Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
})
}With the help of platform msi and interrupt producer, then devices will get the virq from mbigen's irqdomain.
--- drivers/irqchip/irq-mbigen.c | 70 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 67 insertions(+), 3 deletions(-)
drivers/irqchip/irq-mbigen.c +67 -3
@@ -16,6 +16,7 @@* along with this program. If not, see <http://www.gnu.org/licenses/>. */ +#include <linux/acpi.h> #include <linux/interrupt.h> #include <linux/irqchip.h> #include <linux/module.h>
@@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d, unsigned long *hwirq, unsigned int *type) { - if (is_of_node(fwspec->fwnode)) { + if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) { if (fwspec->param_count != 2) return -EINVAL;
@@ -271,6 +272,54 @@ static int mbigen_of_create_domain(struct platform_device *pdev,return 0 ; } +#ifdef CONFIG_ACPI +static acpi_status mbigen_acpi_process_resource (struct acpi_resource *ares, +void *context) +{ +struct acpi_resource_extended_irq *ext_irq; +u32 *num_irqs = context; + +switch (ares->type) { +case ACPI_RESOURCE_TYPE_EXTENDED_IRQ : + ext_irq = &ares->data.extended_irq; + *num_irqs += ext_irq->interrupt_count; +break ; +default : +break ; + } + +return AE_OK ; +} + +static int mbigen_acpi_create_domain (struct platform_device *pdev, +struct mbigen_device *mgn_chip) +{ +struct irq_domain *domain; +u32 num_msis =0 ; +acpi_status status; + + status =acpi_walk_resources (ACPI_HANDLE (&pdev->dev),METHOD_NAME__CRS , + mbigen_acpi_process_resource, &num_msis); +if (ACPI_FAILURE (status) || num_msis ==0 ) +return -EINVAL ; + + domain =platform_msi_create_device_domain (&pdev->dev, num_msis, + mbigen_write_msg, + &mbigen_domain_ops, + mgn_chip); +if (!domain) +return -ENOMEM ; + +return 0 ; +} +#else +static inline int mbigen_acpi_create_domain (struct platform_device *pdev, +struct mbigen_device *mgn_chip) +{ +return -ENODEV ; +} +#endif +static int mbigen_device_probe (struct platform_device *pdev) {struct mbigen_device *mgn_chip;
@@ -288,9 +337,17 @@ static int mbigen_device_probe(struct platform_device *pdev)if (IS_ERR (mgn_chip->base))return PTR_ERR (mgn_chip->base); - err =mbigen_of_create_domain (pdev, mgn_chip); -if (err) +if (IS_ENABLED (CONFIG_OF ) && pdev->dev.of_node) + err =mbigen_of_create_domain (pdev, mgn_chip); +else if (ACPI_COMPANION (&pdev->dev)) + err =mbigen_acpi_create_domain (pdev, mgn_chip); +else + err = -EINVAL ; + +if (err) { +dev_err (&pdev->dev,"Failed to create mbi-gen@%p irqdomain" , mgn_chip->base);return err; + }platform_set_drvdata (pdev, mgn_chip);return 0 ;
@@ -302,10 +359,17 @@ static int mbigen_device_probe(struct platform_device *pdev) };MODULE_DEVICE_TABLE (of, mbigen_of_match); +static const struct acpi_device_id mbigen_acpi_match[] = { + {"HISI0152" ,0 }, + {} +}; +MODULE_DEVICE_TABLE (acpi, mbigen_acpi_match); +static struct platform_driver mbigen_platform_driver = { .driver = { .name ="Hisilicon MBIGEN-V2" , .of_match_table = mbigen_of_match, + .acpi_match_table =ACPI_PTR (mbigen_acpi_match), }, .probe = mbigen_device_probe, };
Signature · 1 line
1.7.12.4
Re: [PATCH v8 15/15] irqchip: mbigen: Add ACPI support
Quoted 84 lines · Hanjun Guo
From: Hanjun Guo <[email protected]>
With the preparation of platform msi support and interrupt producer in DSDT, we can add mbigen ACPI support now.
We are using Interrupt resource type in
_CRSmethd to indicate number of irq pins instead ofnum_pinsin DT to avoid_DSDusage in this case.For mbigen,
Device(MBI0) { Name(_HID, "HISI0152") Name(_UID, Zero) Name(_CRS, ResourceTemplate() { Memory32Fixed(ReadWrite, 0xa0080000, 0x10000) Interrupt(ResourceProducer,...) {12,14,....} }) }For devices,
Device(COM0) { Name(_HID, "ACPIIDxx") Name(_UID, Zero) Name(_CRS, ResourceTemplate() { Memory32Fixed(ReadWrite, 0xb0030000, 0x10000) Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12} }) }With the help of platform msi and interrupt producer, then devices will get the virq from mbigen's irqdomain.
Signed-off-by Hanjun Guo <[email protected]>Cc Lorenzo Pieralisi <[email protected]>Cc Ma Jun <[email protected]>Cc Marc Zyngier <[email protected]>Cc Thomas Gleixner <[email protected]>--- drivers/irqchip/irq-mbigen.c | 70 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 67 insertions(+), 3 deletions(-)drivers/irqchip/irq-mbigen.c +21
-1@@ -16,6 +16,7 @@* along with this program. If not, see <http://www.gnu.org/licenses/>. */ +#include <linux/acpi.h> #include <linux/interrupt.h> #include <linux/irqchip.h> #include <linux/module.h> @@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d, unsigned long *hwirq, unsigned int *type) { - if (is_of_node(fwspec->fwnode)) { + if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) { if (fwspec->param_count != 2) return -EINVAL;@@ -271,6 +272,54 @@ static int mbigen_of_create_domain(struct platform_device *pdev,return 0 ; } +#ifdef CONFIG_ACPI +static acpi_status mbigen_acpi_process_resource (struct acpi_resource *ares, +void *context) +{ +struct acpi_resource_extended_irq *ext_irq; +u32 *num_irqs = context; + +switch (ares->type) { +case ACPI_RESOURCE_TYPE_EXTENDED_IRQ : + ext_irq = &ares->data.extended_irq; + *num_irqs += ext_irq->interrupt_count; +break ; +default : +break ; + } + +return AE_OK ; +} +
drivers/irqchip/irq-mbigen.c static int mbigen_of_create_domain(struct platform_device *pdev, · line 303
Quoted 10 lines
drivers/irqchip/irq-mbigen.c +10
-0+static int mbigen_acpi_create_domain (struct platform_device *pdev, +struct mbigen_device *mgn_chip) +{ +struct irq_domain *domain; +u32 num_msis =0 ; +acpi_status status; + + status =acpi_walk_resources (ACPI_HANDLE (&pdev->dev),METHOD_NAME__CRS , + mbigen_acpi_process_resource, &num_msis); +if (ACPI_FAILURE (status) || num_msis ==0 )
There are some trailing white spaces in this patch, I will send a updated one if no more comments.
Thanks
Hanjun
Quoted 7 lines · Hanjun Guo
From: Hanjun Guo <[email protected]>
With platform msi support landed in the kernel, and the introduction of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi is ready, this patch set add few patches to enable the ACPI platform msi support.
Quoted 5 lines
For platform device connecting to ITS on arm platform, we have IORT table with the named componant node to describe the mappings of paltform device and ITS, so we can retrieve the dev id and find its parent irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
I understand that there is a consensus on IORT/SMMUv3 specific pieces of this series while there is some ongoing work on the MBIgen part in due to dependency on Agustin's patch vs. ACPI definitions.
Can we merge the IORT/SMMUv3 specific pieces to 4.11 so that the base implementation comes in place?
Any objections to not doing so?
Signature · 3 lines
Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Quoted 14 lines · Sinan Kaya
Quoted 7 lines · Hanjun Guo
From: Hanjun Guo <[email protected]>
With platform msi support landed in the kernel, and the introduction of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi is ready, this patch set add few patches to enable the ACPI platform msi support.
Quoted 5 lines
For platform device connecting to ITS on arm platform, we have IORT table with the named componant node to describe the mappings of paltform device and ITS, so we can retrieve the dev id and find its parent irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
Quoted 6 lines
I understand that there is a consensus on IORT/SMMUv3 specific pieces of this series while there is some ongoing work on the MBIgen part in due to dependency on Agustin's patch vs. ACPI definitions.
Can we merge the IORT/SMMUv3 specific pieces to 4.11 so that the base implementation comes in place?
Sorry, but I may be missing something. Which IORT/SMMUv3 patches are we talking about? Do you have a pointer to a series?
Thanks,
M.
Signature · 1 line
Jazz is not dead. It just smells funny...
Quoted 19 lines · Marc Zyngier
Quoted 18 lines · Sinan Kaya
Quoted 7 lines · Hanjun Guo
From: Hanjun Guo <[email protected]>
With platform msi support landed in the kernel, and the introduction of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi is ready, this patch set add few patches to enable the ACPI platform msi support.
Quoted 5 lines
For platform device connecting to ITS on arm platform, we have IORT table with the named componant node to describe the mappings of paltform device and ITS, so we can retrieve the dev id and find its parent irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
I understand that there is a consensus on IORT/SMMUv3 specific pieces of this series while there is some ongoing work on the MBIgen part in due to dependency on Agustin's patch vs. ACPI definitions.
Quoted 6 lines
Quoted 2 lines
Can we merge the IORT/SMMUv3 specific pieces to 4.11 so that the base implementation comes in place?
Sorry, but I may be missing something. Which IORT/SMMUv3 patches are we talking about? Do you have a pointer to a series?
I was talking about patches V8 00-12 of this particular one.
[PATCH v8 00/15] ACPI platform MSI support and its example mbigen
Patches 13-15 are specific for MBIGEN. 00-12 are for the base functionality.
Quoted 4 lines
Thanks,
M.
Signature · 3 lines
Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Quoted 27 lines · Sinan Kaya
Quoted 19 lines · Marc Zyngier
Quoted 18 lines · Sinan Kaya
Quoted 7 lines · Hanjun Guo
From: Hanjun Guo <[email protected]>
With platform msi support landed in the kernel, and the introduction of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi is ready, this patch set add few patches to enable the ACPI platform msi support.
Quoted 5 lines
For platform device connecting to ITS on arm platform, we have IORT table with the named componant node to describe the mappings of paltform device and ITS, so we can retrieve the dev id and find its parent irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
I understand that there is a consensus on IORT/SMMUv3 specific pieces of this series while there is some ongoing work on the MBIgen part in due to dependency on Agustin's patch vs. ACPI definitions.
Quoted 6 lines
Quoted 2 lines
Can we merge the IORT/SMMUv3 specific pieces to 4.11 so that the base implementation comes in place?
Sorry, but I may be missing something. Which IORT/SMMUv3 patches are we talking about? Do you have a pointer to a series?
Quoted 5 lines
I was talking about patches V8 00-12 of this particular one.
[PATCH v8 00/15] ACPI platform MSI support and its example mbigen
Patches 13-15 are specific for MBIGEN. 00-12 are for the base functionality.
Is that to support SMMUv3's own MSI generation? It would be helpful if you explained why you want this code to be merged beforehand, potentially without any in-tree user.
Thanks,
M.
Signature · 1 line
Jazz is not dead. It just smells funny...
Quoted 4 lines · Marc Zyngier
Quoted 1 line
Patches 13-15 are specific for MBIGEN. 00-12 are for the base functionality.
Is that to support SMMUv3's own MSI generation? It would be helpful if you explained why you want this code to be merged beforehand, potentially without any in-tree user.
Sure, I'm more interested in supporting MSI on my HIDMA code rather than MSI on SMMUv3.
HIDMA MSI patches were merged November 2016.
https://github.com/torvalds/linux/commits/master/drivers/dma/qcom/hidma.c
Commits on Nov 3, 2016
@vinodkoul
dmaengine: qcom_hidma: add MSI support for interrupts ? Sinan Kaya committed with vinodkoul on Oct 21, 2016
I tested the first 12 patches of this series against HIDMA and provided my tested-by.
Signature · 3 lines
Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Quoted 13 lines · Sinan Kaya
Quoted 4 lines · Marc Zyngier
Quoted 1 line
Patches 13-15 are specific for MBIGEN. 00-12 are for the base functionality.
Is that to support SMMUv3's own MSI generation? It would be helpful if you explained why you want this code to be merged beforehand, potentially without any in-tree user.
Sure, I'm more interested in supporting MSI on my HIDMA code rather than MSI on SMMUv3.
HIDMA MSI patches were merged November 2016.
https://github.com/torvalds/linux/commits/master/drivers/dma/qcom/hidma.c
Quoted 7 lines
Commits on Nov 3, 2016
@vinodkoul
dmaengine:qcom_hidma: add MSI support for interrupts … Sinan Kaya committed with vinodkoul on Oct 21, 2016I tested the first 12 patches of this series against HIDMA and provided my tested-by.
Ok, we should have split this series before then. Now, if:
(1) Marc is ok with patches [4-7,10,12]
(2) Your HIDMA MSI does not depend on Agustin patch series to work
(3) Rafael is ok with a pull request at -rc7 (ie I won't be able to send it before then since I want to test it)
I will send a pull request to Rafael for patches [1-12] on Monday.
If any of (1)-(2)-(3) does not hold it is going to be v4.12, a single driver is not the end of the world (and this will give us time to add support for SMMUv3 MSI that this series can't handle).
Thanks,
Lorenzo
Quoted 1 line · Lorenzo Pieralisi
(2) Your HIDMA MSI does not depend on Agustin patch series to work
I confirm that my driver doesn't depend on Agustin's patch.
Signature · 3 lines
Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Hanjun Guo
maintainerQuoted 8 lines · Sinan Kaya
Quoted 7 lines · Hanjun Guo
From: Hanjun Guo <[email protected]>
With platform msi support landed in the kernel, and the introduction of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi is ready, this patch set add few patches to enable the ACPI platform msi support.
Quoted 8 lines
Quoted 5 lines
For platform device connecting to ITS on arm platform, we have IORT table with the named componant node to describe the mappings of paltform device and ITS, so we can retrieve the dev id and find its parent irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
I understand that there is a consensus on IORT/SMMUv3 specific pieces of this series while there is some ongoing work on the MBIgen part in due to dependency on Agustin's patch vs. ACPI definitions.
I think both Agustin's patch set and my mbigen one are in good shape now if I didn't miss something, Rafael and Lorenzo already acked Agustin's patch [1-2/3], I provided my review and test tags on them.
And Lorenzo said about the mbigen patches:
"I think this patch (and the FW that goes with it) is wrong, but the rest of the series, in particular the IORT bits, are ok with me." and I fixed the wrong patch and updated the _PRS to _CRS as Lorenzo suggested in v8.
So, can I kindly ask that those patches (Agustin's patch set and my mbigen one) be merged to 4.11 please? It's really important for Hisilicon (Hip06/Hip07) SoCs which native NIC [1], SAS [2], USB and even the console on Hip07-D05 drivers depend on those patches, and those platform are completely dead without them if PCI is not enabled...
Thanks
Hanjun
[1]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/hisilicon/hns/
[2]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/hisi_sas/
Hanjun, Sinan,
Quoted 11 lines · Hanjun Guo
From: Hanjun Guo <[email protected]>
With platform msi support landed in the kernel, and the introduction of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi is ready, this patch set add few patches to enable the ACPI platform msi support.
For platform device connecting to ITS on arm platform, we have IORT table with the named componant node to describe the mappings of paltform device and ITS, so we can retrieve the dev id and find its parent irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
Depending on how things go, I prepared a branch with the first 12 patches (I basically updated some logs and added some cosmetics changes) for testing (Hanjun please have a look in details since I may have misread some logs), whether or not I will send a pull request for it we shall see next week.
Here:
git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/platform-msi
Thanks,
Lorenzo
Quoted 114 lines
v7 -> v8:
- Using_CRSinstead of_PRSfor Interrupt resources for mbigen- reshuffle the patch slightly to introduce
iort_node_map_platform_id()first and then retrieve the dev id for platform MSI, no functional change- Fix the compile error with patch "irqchip: gicv3-its: platform-msi:
scan MADT to create platform msi domain", which forgot to add <include/acpi_iort.h> (added in later patches in last version).- renew some commit message which suggested by Lorenzo
- address some othe minor issues which commented by Lorenzo
- Add review and test tag as it's no functional change except the last patch of mbigen
- rebase on top of 4.10-rc4 and test it on x86, ia64 and ARM64 platforms (also with Agustin's patch [1-2/3] "[PATCH V9 0/3] irqchip: qcom:
Add IRQ combiner driver" and Lorenzo's patch
https://patchwork.kernel.org/patch/9507041/)v6 -> v7:
- Introduceiort_node_map_platform_id()to retrieve the dev id for both NC (named component) -> ITS/SMMU and NC -> SMMU -> ITS cases, suggested by Lorenzo;- Reorder the patches and rewrite some commit message;
- Remove the test tags because it has major changes to retrieve the dev id, Sinan, Majun, Xinwei, could you please test them again on your platform?
- rebased on top of 4.10-rc3 and Lorenzo's patch
https://patchwork.kernel.org/patch/9507041/- Tested against Agustin's patch [1-2/3] "[PATCH V9 0/3] irqchip: qcom:
Add IRQ combiner driver"v5 -> v6:
- Callacpi_configure_pmsi_domain()for platform devices inacpi_platform_notify()as it's cleaner (suggested by Rafael)
- Remove the "u8 type" foriort_id_map()because it's unused
- Rebase on top of 4.10-rc2
- Collect test and review tagsv4 -> v5:
- Add mbigen support back with tested on with Agustin's patchset,
and it's a good example of how ACPI platform MSI works
- rebased on top of lastest Linus tree (commit 52bce91 splice: reinstate SIGPIPE/EPIPE handling)v3 -> v4:
- Drop mbi-gen patches to just submit platform msi support because will rebase mbi-gen patches on top of Agustin's patchset, and discusion is going there.
- Add a patch to support device topology such asNC(named componant, paltform device)->SMMU->ITS which suggested by Lorenzo;
- rebased on top of Lorenzo's v9 of ACPI IORT ARM SMMU support;
- rebased on top of 4.9-rc7v2 -> v3:
- Drop RFC tag
- Rebase against v4.9-rc2 and Lorenzo's v6 of ACPI IORT ARM SMMU support [1]
- Add 3 cleanup patches (patch 1, 2, 3)
- Droparch_initcall patch from last version
- Introduce a callback for platform device to set msi domain
- Introduce a new API to get paltform device's domain instead of reusing the PCI one in previous version
- Add a patch to reworkiort_node_get_id()[1]: http://www.mail-archive.com/[email protected]/msg1251993.html
v1 -> v2:
- Fix the bug of if multiInterrupt()resoures in single_PRS, we need to calculate all the irq numbers (I missed it in previous version);
- Rebased on Marc's irq/irqchip-4.9 branch and Lorenzo's v5 SMMU patches (also Robin's SMMu patches)
- Add patch irqchip: mbigen: promote mbigen init.Hanjun Guo (13):
ACPI: IORT: fix the indentation iniort_scan_node()
ACPI: IORT: add missing comment foriort_dev_find_its_id()
ACPI: IORT: minor cleanup foriort_match_node_callback()
irqchip: gic-v3-its: keep the head file include in alphabetic order
irqchip: gicv3-its: platform-msi: refactorits_pmsi_prepare()
irqchip: gicv3-its: platform-msi: refactorits_pmsi_init()to prepare
for ACPI
irqchip: gicv3-its: platform-msi: scan MADT to create platform msi
domain
ACPI: IORT: renameiort_node_map_rid()to make it generic
ACPI: IORT: introduceiort_node_map_platform_id()to retrieve dev id
ACPI: platform-msi: retrieve dev id from IORT
ACPI: platform: setup MSI domain for ACPI based platform device
msi: platform: makeplatform_msi_create_device_domain()ACPI aware
irqchip: mbigen: Add ACPI supportKefeng Wang (2):
irqchip: mbigen: drop module owner
irqchip: mbigen: introducembigen_of_create_domain()drivers/acpi/arm64/iort.c | 158 +++++++++++++++++++++----- drivers/acpi/glue.c | 6 + drivers/base/platform-msi.c | 3 +- drivers/irqchip/irq-gic-v3-its-platform-msi.c | 106 +++++++++++++---- drivers/irqchip/irq-gic-v3-its.c | 3 +- drivers/irqchip/irq-mbigen.c | 109 +++++++++++++++--- include/linux/acpi_iort.h | 8 ++ 7 files changed, 316 insertions(+), 77 deletions(-)Signature · 1 line
1.7.12.4
Hanjun Guo
maintainerHi Lorenzo,
Quoted 20 lines · Lorenzo Pieralisi
Hanjun, Sinan,
Quoted 11 lines · Hanjun Guo
From: Hanjun Guo <[email protected]>
With platform msi support landed in the kernel, and the introduction of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi is ready, this patch set add few patches to enable the ACPI platform msi support.
For platform device connecting to ITS on arm platform, we have IORT table with the named componant node to describe the mappings of paltform device and ITS, so we can retrieve the dev id and find its parent irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
Depending on how things go, I prepared a branch with the first 12 patches (I basically updated some logs and added some cosmetics changes) for testing (Hanjun please have a look in details since I may have misread some logs), whether or not I will send a pull request for it we shall see next week.
Quoted 3 lines
Here:
git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.gitacpi/platform-msi
Thanks a lot for putting them together, I fetched your git tree and took a detail look, there is one issue in patch "msi: platform: make platform_msi_create_device_domain() ACPI aware" which has two "Cc: Greg KH <[email protected]>" in the commit log (it's in the original patch from me, my bad), others are pretty good to me (to make sure it works I retested those patches and patches in your branch work as before).
BTW, patches in Lorenzo's branch have no conflicts with Agustin's patch set + my mbigen one, so after a pull request to Rafael, could them (Agustin's patch set + my mbigen one) go via one tree such as Marc's one for 4.11? I know it's a little bit late but those patches are quite self-contained, which Agustin's changes are conditional on the ACPI_GENERIC_GSI config which is only available with ARM64 ACPI and others (interrupt combiner and mbigen) are specific to QC and Hisilicon platforms.
Marc, Lorenzo, could you give some comments that how can we proceed those patches (Agustin's patch set + my mbigen one)? It's really critical for us, thank you very much.
Best Regards
Hanjun
Quoted 44 lines · Hanjun Guo
Hi Lorenzo,
Quoted 20 lines · Lorenzo Pieralisi
Hanjun, Sinan,
Quoted 11 lines · Hanjun Guo
From: Hanjun Guo <[email protected]>
With platform msi support landed in the kernel, and the introduction of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi is ready, this patch set add few patches to enable the ACPI platform msi support.
For platform device connecting to ITS on arm platform, we have IORT table with the named componant node to describe the mappings of paltform device and ITS, so we can retrieve the dev id and find its parent irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
Depending on how things go, I prepared a branch with the first 12 patches (I basically updated some logs and added some cosmetics changes) for testing (Hanjun please have a look in details since I may have misread some logs), whether or not I will send a pull request for it we shall see next week.
Quoted 3 lines
Here:
git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.gitacpi/platform-msiThanks a lot for putting them together, I fetched your git tree and took a detail look, there is one issue in patch "msi: platform: make
platform_msi_create_device_domain()ACPI aware" which has two "Cc: Greg KH <[email protected]>" in the commit log (it's in the original patch from me, my bad), others are pretty good to me (to make sure it works I retested those patches and patches in your branch work as before).BTW, patches in Lorenzo's branch have no conflicts with Agustin's patch set + my mbigen one, so after a pull request to Rafael, could them (Agustin's patch set + my mbigen one) go via one tree such as Marc's one for 4.11? I know it's a little bit late but those patches are quite self-contained, which Agustin's changes are conditional on the
ACPI_GENERIC_GSIconfig which is only available with ARM64 ACPI and others (interrupt combiner and mbigen) are specific to QC and Hisilicon platforms.
Quoted 3 lines
Marc, Lorenzo, could you give some comments that how can we proceed those patches (Agustin's patch set + my mbigen one)? It's really critical for us, thank you very much.
Ok, given that:
- We have decided that from now onwards ACPI IORT patches should go via the ARM64 tree
- This series does not yet handle ARM SMMU MSIs (but it has to and I want to see how this will work - waiting for spec updates)
- It depends on fixes that will get merged via the v4.11 arm64 queue
- We are at -rc7 and I do not think it is fair at all to ask Will and Catalin to pull this code now given that it comes out of thin air for them
- Last but not least: it is not bad to take time for the dust to settle given that we merged lots of IORT code last two cycles
I have decided that the whole series will be considered v4.12 material, I do not expect it to be a major disruption given that we should have a stable code base for it come v4.11-rc1 (inclusive of Agustin's key probe deferral series).
Thanks,
Lorenzo