PCI: of: warn on bogus device_type property
v2 cover PCI: of: warn on bogus device_type property
The purpose of this series lies in its final patch, where a new check is added whenever a PCI devicetree node is found to already exist when one might otherwise be dynamically created.
PCI has a well-defined bus and device discovery process. The PCI_DYNAMIC_OF_NODES Kconfig option allows PCI devices to *also* have a devicetree node. This enables certain things that are not possible with PCI enumeration alone.
While working on a Qualcomm platform, I learned that some PCI endpoint nodes were defined with device_type = "pci" properties. Herve Codina pointed out that this was not correct. Rob Herring indicated that people seem to have trouble getting the PCI devicetree nodes right, and asked whether we could warn if this particular problem occurred.
The last patch in this series implements that check and warning. The first three patches are fairly trivial changes to clean up some related code. This is the only changed patch since v1.
-Alex
Between version 1 and version 2:
- Check the PCI devicetree node even when PCI_DYNAMIC_OF_NODES is not enabled
Version 1 is available here:
https://lore.kernel.org/lkml/[email protected]/
Alex Elder (4):
PCI: of: drop the reg_num argument to of_pci_set_address()
PCI: of: don't zero flags in of_pci_get_addr_flags()
PCI: of: make a flags argument optional
PCI: of: introduce of_pci_verify_node()
drivers/pci/bus.c | 1 + drivers/pci/of.c | 26 ++++++++++++++++++++++++++ drivers/pci/of_property.c | 20 ++++++++++---------- drivers/pci/pci.h | 3 +++ 4 files changed, 40 insertions(+), 10 deletions(-)
base-commit: db2ddb87143519e20a95aa36c60b36107b736a58
Signature · 1 line
2.53.0
PATCH v2 1/4 PCI: of: drop the reg_num argument to of_pci_set_address()
The reg_num argument passed to of_pci_set_address() is always zero, so get rid of it.
--- drivers/pci/of_property.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/pci/of_property.c +5 -5
@@ -52,7 +52,7 @@ enum of_pci_prop_compatible { };static void of_pci_set_address (struct pci_dev *pdev,u32 *prop,u64 addr, -u32 reg_num,u32 flags,bool reloc) +u32 flags,bool reloc) {if (pdev) { prop[0] = FIELD_PREP(OF_PCI_ADDR_FIELD_BUS, pdev->bus->number) |
@@ -61,7 +61,7 @@ static void of_pci_set_address(struct pci_dev *pdev, u32 *prop, u64 addr, }else prop[0 ] =0 ; - prop[0 ] |= flags | reg_num; + prop[0 ] |= flags;if (!reloc) { prop[0 ] |=OF_PCI_ADDR_FIELD_NONRELOC ; prop[1 ] =upper_32_bits (addr);
@@ -131,7 +131,7 @@ static int of_pci_prop_ranges(struct pci_dev *pdev, struct of_changeset *ocs,continue ; val64 =pci_bus_address (pdev, &res[j] - pdev->resource); -of_pci_set_address (pdev, rp[i].parent_addr, val64,0 , flags, +of_pci_set_address (pdev, rp[i].parent_addr, val64, flags, false);if (pci_is_bridge (pdev)) { memcpy(rp[i].child_addr, rp[i].parent_addr,
@@ -164,7 +164,7 @@ static int of_pci_prop_reg(struct pci_dev *pdev, struct of_changeset *ocs,struct of_pci_addr_pair reg = {0 };/* configuration space */ -of_pci_set_address (pdev, reg.phys_addr,0 ,0 ,0 , true); +of_pci_set_address (pdev, reg.phys_addr,0 ,0 , true);return of_changeset_add_prop_u32_array (ocs, np,"reg" , (u32 *)®,sizeof (reg) /sizeof (u32));
@@ -458,7 +458,7 @@ static int of_pci_host_bridge_prop_ranges(struct pci_host_bridge *bridge,/* PCI bus address */ val64 = res->start;of_pci_set_address (NULL , &ranges[ranges_sz], - val64 - window->offset,0 , flags, false); + val64 - window->offset, flags, false); ranges_sz +=OF_PCI_ADDRESS_CELLS ;/* Host bus address */
Signature · 1 line
2.53.0
[email protected]
AI reviewRe: [PATCH v2 1/4] PCI: of: drop the reg_num argument to of_pci_set_address()
Sashiko has reviewed this patch and found no issues. It looks great!
Quoted 5 lines
The
reg_numargument passed toof_pci_set_address()is always zero, so get rid of it.Reviewed-by Herve Codina <[email protected]>Signed-off-by Alex Elder <[email protected]>
Sashiko has reviewed this patch and found no issues. It looks great!
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
PATCH v2 2/4 PCI: of: don't zero flags in of_pci_get_addr_flags()
In reply to Alex ElderThe flags variable whose address is passed to of_pci_get_addr_flags() is zeroed before assigning a value to it. Skip the zeroing and just assign it instead.
--- drivers/pci/of_property.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/pci/of_property.c +1 -3
@@ -82,12 +82,10 @@ static int of_pci_get_addr_flags(const struct resource *res, u32 *flags)else return -EINVAL ; - *flags =0 ; + *flags =FIELD_PREP (OF_PCI_ADDR_FIELD_SS , ss);if (res->flags &IORESOURCE_PREFETCH ) *flags |=OF_PCI_ADDR_FIELD_PREFETCH ; - *flags |=FIELD_PREP (OF_PCI_ADDR_FIELD_SS , ss); -return 0 ; }
Signature · 1 line
2.53.0
[email protected]
AI reviewRe: [PATCH v2 2/4] PCI: of: don't zero flags in of_pci_get_addr_flags()
Sashiko has reviewed this patch and found no issues. It looks great!
Quoted 6 lines
The flags variable whose address is passed to
of_pci_get_addr_flags()is zeroed before assigning a value to it. Skip the zeroing and just assign it instead.Reviewed-by Herve Codina <[email protected]>Signed-off-by Alex Elder <[email protected]>
Sashiko has reviewed this patch and found no issues. It looks great!
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
PATCH v2 3/4 PCI: of: make a flags argument optional
In reply to Alex ElderThe address of a u32 object is passed to of_pci_get_addr_flags() so it can be filled with the computed flags value.
Allow a null pointer to be passed, so that the validity of the resource's flags can be checked without filling in the flags value.
--- drivers/pci/of_property.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/pci/of_property.c +5 -3
@@ -82,9 +82,11 @@ static int of_pci_get_addr_flags(const struct resource *res, u32 *flags)else return -EINVAL ; - *flags =FIELD_PREP (OF_PCI_ADDR_FIELD_SS , ss); -if (res->flags &IORESOURCE_PREFETCH ) - *flags |=OF_PCI_ADDR_FIELD_PREFETCH ; +if (flags) { + *flags =FIELD_PREP (OF_PCI_ADDR_FIELD_SS , ss); +if (res->flags &IORESOURCE_PREFETCH ) + *flags |=OF_PCI_ADDR_FIELD_PREFETCH ; + }return 0 ; }
Signature · 1 line
2.53.0
[email protected]
AI reviewRe: [PATCH v2 3/4] PCI: of: make a flags argument optional
Sashiko has reviewed this patch and found no issues. It looks great!
Quoted 7 lines
The address of a u32 object is passed to
of_pci_get_addr_flags()so it can be filled with the computed flags value.Allow a null pointer to be passed, so that the validity of the resource's flags can be checked without filling in the flags value.
Signed-off-by Alex Elder <[email protected]>
Sashiko has reviewed this patch and found no issues. It looks great!
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
Re: [PATCH v2 3/4] PCI: of: make a flags argument optional
In reply to Alex ElderHi Alex,
Quoted 11 lines · On Wed, 12 Aug 2026 12:22:46 -0500 Alex Elder <[email protected]> wrote:
The address of a u32 object is passed to
of_pci_get_addr_flags()so it can be filled with the computed flags value.Allow a null pointer to be passed, so that the validity of the resource's flags can be checked without filling in the flags value.
Signed-off-by Alex Elder <[email protected]>--- drivers/pci/of_property.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
Ok but nothing in the series call of_pci_get_addr_flags() with a NULL flags argument.
Is this modification really needed in this series?
Best regards
Hervé
Re: [PATCH v2 3/4] PCI: of: make a flags argument optional
Quoted 11 lines · Herve Codina
Hi Alex,
Quoted 6 lines · On Wed, 12 Aug 2026 12:22:46 -0500 Alex Elder <[email protected]> wrote:
The address of a u32 object is passed to
of_pci_get_addr_flags()so it can be filled with the computed flags value.Allow a null pointer to be passed, so that the validity of the resource's flags can be checked without filling in the flags value.
Quoted 8 lines
Quoted 5 lines
Signed-off-by Alex Elder <[email protected]>--- drivers/pci/of_property.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)Ok but nothing in the series call
of_pci_get_addr_flags()with a NULL flags argument.
You're right. This is needed for the dynamic range update series.
https://lore.kernel.org/lkml/[email protected]/
I'll move it out of this series and into that one.
-Alex
Quoted 6 lines
Is this modification really needed in this series?
Best regards
Hervé
PATCH v2 4/4 PCI: of: introduce of_pci_verify_node()
In reply to Alex ElderCommit 407d1a51921e9 ("PCI: Create device tree node for bridge") linked the PCI enumeration process together with devicetree, creating a devicetree node for discovered PCI bridges. Its successor commit ae9813db1dc5a ("PCI:
Add quirks to generate device tree node for Xilinx Alveo U50") shows how to use a PCI final fixup quirk to also create a devicetree node for a non-bridge PCI device. These changes allowed devicetree overlays to describe components downstream of a PCI device, by providing a place to attach the overlay.
Note that the dynamic devicetree node is only created if the device didn't already have an assigned node.
Later, commit aa7b4bbcb3a1d ("arm64: dts: qcom: qcs6490-rb3gen2: Add TC9563 PCIe switch node") *pre-defined* devicetree nodes to represent the PCI device nodes that would (also) be discovered via the PCI enumeration process. The devicetree node in this case is created with the content from the DTS file. So when a (host) bridge is done being initialized during PCI enumeration, no node is dynamically created (the commits mentioned above do not apply).
Ideally, any pre-defined PCI devicetree node would contain exactly the same information as whatever the dynamic creation process would produce (though it could include more).
However that is not the case for the pre-defined Qualcomm RB3gen2 nodes. And in particular, the endpoint (function) nodes include this property:
device_type = "pci";
This is simply wrong; that property is meant only for bridge nodes.
Rob Herring requested that a runtime check to be added to spot this specific error, only for non-bridge PCI devices.
(There are many things that could be verified for statically-defined devicetree nodes, but this is all we'll do for now.)
---
v2: Verify even if PCI_DYNAMIC_OF_NODES is not defined (Sashiko)
drivers/pci/bus.c | 1 + drivers/pci/of.c | 26 ++++++++++++++++++++++++++ drivers/pci/pci.h | 3 +++ 3 files changed, 30 insertions(+)
drivers/pci/bus.c +1 -0
@@ -351,6 +351,7 @@ void pci_bus_add_device(struct pci_dev *dev)* are not assigned yet for some devices. */ pcibios_bus_add_device (dev); +of_pci_verify_node (dev);pci_fixup_device (pci_fixup_final, dev);if (pci_is_bridge (dev))of_pci_make_dev_node (dev);
drivers/pci/of.c +26 -0
@@ -1006,3 +1006,29 @@ int of_pci_get_equalization_presets(struct device *dev,return 0 ; }EXPORT_SYMBOL_GPL (of_pci_get_equalization_presets); + +/* +* Check a pre-existing devicetree node for errors. The PCI enumeration +* process gathered a lot of information about the device, and ideally it +* matches what the devicetree node says. +*/ +void of_pci_verify_node (struct pci_dev *pdev) +{ +struct device_node *np =pci_device_to_OF_node (pdev); + +/* If there's no pre-existing node, there's nothing to check */ +if (!np) +return ; + +if (pci_is_bridge (pdev)) +return ; + +/* +* Currently we just verify that non-bridges don't contain a +* device_type = "pci" property. +*/ +if (!of_node_is_type (np,"pci" )) +return ; + +dev_err (&pdev->dev,"\"pci\" device_type NOT VALID for PCI endpoint\n" ); +}
drivers/pci/pci.h +3 -0
@@ -1205,6 +1205,7 @@ bool of_pci_supply_present(struct device_node *np);int of_pci_get_equalization_presets (struct device *dev,struct pci_eq_presets *presets,int num_lanes); +void of_pci_verify_node (struct pci_dev *pdev);#else static inline int of_get_pci_domain_nr (struct device_node *node)
@@ -1260,6 +1261,8 @@ static inline int of_pci_get_equalization_presets(struct device *dev, return 0; } + +static inline void of_pci_verify_node (struct pci_dev *pdev) { }#endif /* CONFIG_OF */ struct of_changeset ;
Signature · 1 line
2.53.0
[email protected]
AI reviewRe: [PATCH v2 4/4] PCI: of: introduce of_pci_verify_node()
Sashiko has reviewed this patch and found no issues. It looks great!
Quoted 17 lines
Commit
407d1a51921e9("PCI: Create device tree node for bridge") linked the PCI enumeration process together with devicetree, creating a devicetree node for discovered PCI bridges. Its successor commitae9813db1dc5a("PCI:
Add quirks to generate device tree node for Xilinx Alveo U50") shows how to use a PCI final fixup quirk to also create a devicetree node for a non-bridge PCI device. These changes allowed devicetree overlays to describe components downstream of a PCI device, by providing a place to attach the overlay.Note that the dynamic devicetree node is only created if the device didn't already have an assigned node.
Later, commit
aa7b4bbcb3a1d("arm64: dts: qcom: qcs6490-rb3gen2: Add TC9563 PCIe switch node") *pre-defined* devicetree nodes to represent the PCI device nodes that would (also) be discovered via the PCI enumeration [ ... ]
Quoted 4 lines
(There are many things that could be verified for statically-defined devicetree nodes, but this is all we'll do for now.)
Signed-off-by Alex Elder <[email protected]>
Sashiko has reviewed this patch and found no issues. It looks great!
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4
Re: [PATCH v2 4/4] PCI: of: introduce of_pci_verify_node()
In reply to Alex ElderHi Alex,
Quoted 63 lines · On Wed, 12 Aug 2026 12:22:47 -0500 Alex Elder <[email protected]> wrote:
Commit
407d1a51921e9("PCI: Create device tree node for bridge") linked the PCI enumeration process together with devicetree, creating a devicetree node for discovered PCI bridges. Its successor commitae9813db1dc5a("PCI:
Add quirks to generate device tree node for Xilinx Alveo U50") shows how to use a PCI final fixup quirk to also create a devicetree node for a non-bridge PCI device. These changes allowed devicetree overlays to describe components downstream of a PCI device, by providing a place to attach the overlay.Note that the dynamic devicetree node is only created if the device didn't already have an assigned node.
Later, commit
aa7b4bbcb3a1d("arm64: dts: qcom: qcs6490-rb3gen2: Add TC9563 PCIe switch node") *pre-defined* devicetree nodes to represent the PCI device nodes that would (also) be discovered via the PCI enumeration process. The devicetree node in this case is created with the content from the DTS file. So when a (host) bridge is done being initialized during PCI enumeration, no node is dynamically created (the commits mentioned above do not apply).Ideally, any pre-defined PCI devicetree node would contain exactly the same information as whatever the dynamic creation process would produce (though it could include more).
However that is not the case for the pre-defined Qualcomm RB3gen2 nodes. And in particular, the endpoint (function) nodes include this property:
device_type = "pci";This is simply wrong; that property is meant only for bridge nodes.
Rob Herring requested that a runtime check to be added to spot this specific error, only for non-bridge PCI devices.
(There are many things that could be verified for statically-defined devicetree nodes, but this is all we'll do for now.)
Signed-off-by Alex Elder <[email protected]>---
v2: Verify even ifPCI_DYNAMIC_OF_NODESis not defined (Sashiko)drivers/pci/bus.c | 1 + drivers/pci/of.c | 26 ++++++++++++++++++++++++++ drivers/pci/pci.h | 3 +++ 3 files changed, 30 insertions(+)drivers/pci/bus.c +1
-0@@ -351,6 +351,7 @@ void pci_bus_add_device(struct pci_dev *dev)* are not assigned yet for some devices. */ pcibios_bus_add_device (dev); +of_pci_verify_node (dev);pci_fixup_device (pci_fixup_final, dev);if (pci_is_bridge (dev))of_pci_make_dev_node (dev);drivers/pci/of.c +0
-0
drivers/pci/of.c int of_pci_get_equalization_presets(struct device *dev, · line 1014
Quoted 9 lines
drivers/pci/of.c +6
-0@@ -1006,3 +1006,29 @@ int of_pci_get_equalization_presets(struct device *dev,return 0 ; }EXPORT_SYMBOL_GPL (of_pci_get_equalization_presets); + +/* +* Check a pre-existing devicetree node for errors. The PCI enumeration +* process gathered a lot of information about the device, and ideally it +* matches what the devicetree node says. +*/
Can you switch the kernel doc format [0] or move the comment into the function itself ?
[0] https://elixir.bootlin.com/linux/v7.2/source/Documentation/doc-guide/kernel-doc.rst#L67
drivers/pci/of.c int of_pci_get_equalization_presets(struct device *dev, · line 1024
Quoted 10 lines
drivers/pci/of.c +10
-0+void of_pci_verify_node (struct pci_dev *pdev) +{ +struct device_node *np =pci_device_to_OF_node (pdev); + +/* If there's no pre-existing node, there's nothing to check */ +if (!np) +return ; + +if (pci_is_bridge (pdev)) +return ;
The property 'device_type = "pci"' is needed for bridges.
You could check that it is well present in case of bridges.
drivers/pci/of.c int of_pci_get_equalization_presets(struct device *dev, · line 1034
Quoted 10 lines
drivers/pci/of.c +10
-0+ +/* +* Currently we just verify that non-bridges don't contain a +* device_type = "pci" property. +*/ +if (!of_node_is_type (np,"pci" )) +return ; + +dev_err (&pdev->dev,"\"pci\" device_type NOT VALID for PCI endpoint\n" ); +}
Best regards,
Hervé
Re: [PATCH v2 4/4] PCI: of: introduce of_pci_verify_node()
Quoted 71 lines · Herve Codina
Hi Alex,
Quoted 66 lines · On Wed, 12 Aug 2026 12:22:47 -0500 Alex Elder <[email protected]> wrote:
Commit
407d1a51921e9("PCI: Create device tree node for bridge") linked the PCI enumeration process together with devicetree, creating a devicetree node for discovered PCI bridges. Its successor commitae9813db1dc5a("PCI:
Add quirks to generate device tree node for Xilinx Alveo U50") shows how to use a PCI final fixup quirk to also create a devicetree node for a non-bridge PCI device. These changes allowed devicetree overlays to describe components downstream of a PCI device, by providing a place to attach the overlay.Note that the dynamic devicetree node is only created if the device didn't already have an assigned node.
Later, commit
aa7b4bbcb3a1d("arm64: dts: qcom: qcs6490-rb3gen2: Add TC9563 PCIe switch node") *pre-defined* devicetree nodes to represent the PCI device nodes that would (also) be discovered via the PCI enumeration process. The devicetree node in this case is created with the content from the DTS file. So when a (host) bridge is done being initialized during PCI enumeration, no node is dynamically created (the commits mentioned above do not apply).Ideally, any pre-defined PCI devicetree node would contain exactly the same information as whatever the dynamic creation process would produce (though it could include more).
However that is not the case for the pre-defined Qualcomm RB3gen2 nodes. And in particular, the endpoint (function) nodes include this property:
device_type = "pci";This is simply wrong; that property is meant only for bridge nodes.
Rob Herring requested that a runtime check to be added to spot this specific error, only for non-bridge PCI devices.
(There are many things that could be verified for statically-defined devicetree nodes, but this is all we'll do for now.)
Signed-off-by Alex Elder <[email protected]>---
v2: Verify even ifPCI_DYNAMIC_OF_NODESis not defined (Sashiko)drivers/pci/bus.c | 1 + drivers/pci/of.c | 26 ++++++++++++++++++++++++++ drivers/pci/pci.h | 3 +++ 3 files changed, 30 insertions(+)drivers/pci/bus.c +1
-0@@ -351,6 +351,7 @@ void pci_bus_add_device(struct pci_dev *dev)* are not assigned yet for some devices. */ pcibios_bus_add_device (dev); +of_pci_verify_node (dev);pci_fixup_device (pci_fixup_final, dev);if (pci_is_bridge (dev))of_pci_make_dev_node (dev);drivers/pci/of.c +0
-0@@ -1006,3 +1006,29 @@ int of_pci_get_equalization_presets(struct device *dev,return 0 ; }EXPORT_SYMBOL_GPL (of_pci_get_equalization_presets);
Quoted 8 lines
drivers/pci/of.c int of_pci_get_equalization_presets(struct device *dev, · line 1014
Quoted 6 lines
drivers/pci/of.c +6
-0+ +/* +* Check a pre-existing devicetree node for errors. The PCI enumeration +* process gathered a lot of information about the device, and ideally it +* matches what the devicetree node says. +*/ Can you switch the kernel doc format [0] or move the comment into the function itself ?
Sure. I think it could be simplified too. I'll take another shot at it in version 3.
Quoted 15 lines
[0] https://elixir.bootlin.com/linux/v7.2/source/Documentation/doc-guide/kernel-doc.rst#L67
drivers/pci/of.c int of_pci_get_equalization_presets(struct device *dev, · line 1024
Quoted 10 lines
drivers/pci/of.c +10
-0+void of_pci_verify_node (struct pci_dev *pdev) +{ +struct device_node *np =pci_device_to_OF_node (pdev); + +/* If there's no pre-existing node, there's nothing to check */ +if (!np) +return ; + +if (pci_is_bridge (pdev)) +return ;The property '
device_type= "pci"' is needed for bridges.
Quoted 1 line
You could check that it is well present in case of bridges.
I think that's a good suggestion. As I said in the comment, there is a lot we *could* check, but Rob seemed to indicate he didn't want to go very far down that slippery slope. So I limited what this patch does to specifically looking for the device type in non-bridge nodes.
I will add the check you suggest in v3.
Quoted 10 lines
drivers/pci/of.c int of_pci_get_equalization_presets(struct device *dev, · line 1034
Quoted 10 lines
drivers/pci/of.c +10
-0+ +/* +* Currently we just verify that non-bridges don't contain a +* device_type = "pci" property. +*/ +if (!of_node_is_type (np,"pci" )) +return ; + +dev_err (&pdev->dev,"\"pci\" device_type NOT VALID for PCI endpoint\n" ); +}
Thanks a lot for the review.
-Alex
Quoted 3 lines
Best regards,
Hervé
Hi Alex,
Can you add me in Cc in all patches of the series for next iterations?
Best regards,
Hervé
Quoted 43 lines · On Wed, 12 Aug 2026 12:22:43 -0500 Alex Elder <[email protected]> wrote:
The purpose of this series lies in its final patch, where a new check is added whenever a PCI devicetree node is found to already exist when one might otherwise be dynamically created.
PCI has a well-defined bus and device discovery process. The
PCI_DYNAMIC_OF_NODESKconfigoption allows PCI devices to *also* have a devicetree node. This enables certain things that are not possible with PCI enumeration alone.While working on a Qualcomm platform, I learned that some PCI endpoint nodes were defined with
device_type= "pci" properties. Herve Codina pointed out that this was not correct. Rob Herring indicated that people seem to have trouble getting the PCI devicetree nodes right, and asked whether we could warn if this particular problem occurred.The last patch in this series implements that check and warning. The first three patches are fairly trivial changes to clean up some related code. This is the only changed patch since v1.
-Alex
Between version 1 and version 2:
- Check the PCI devicetree node even whenPCI_DYNAMIC_OF_NODESis not enabledVersion 1 is available here:
https://lore.kernel.org/lkml/[email protected]/Alex Elder (4):
PCI: of: drop thereg_numargument toof_pci_set_address()
PCI: of: don't zero flags inof_pci_get_addr_flags()
PCI: of: make a flags argument optional
PCI: of: introduceof_pci_verify_node()drivers/pci/bus.c | 1 + drivers/pci/of.c | 26 ++++++++++++++++++++++++++ drivers/pci/of_property.c | 20 ++++++++++---------- drivers/pci/pci.h | 3 +++ 4 files changed, 40 insertions(+), 10 deletions(-)base-commit:
db2ddb87143519e20a95aa36c60b36107b736a58