dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
Subsystems (2)
PATCH v2 1/1 dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
The Davicom DM9100 and DM9102 chips are used on the motherboards of some SPARC systems (supported by the tulip driver) and also in PCI expansion cards (supported by the dmfe driver). There is no difference in the PCI device ids for the two different configurations, so these drivers both claim the device ids. However, it is possible to distinguish the two configurations by the presence of Open Firmware properties for them, so we do that.
---
Changes from v1, as you requested:
- Downgraded log messages from ERR to INFO
- Removed dummy length parameter to of_get_property()
Ben.
drivers/net/tulip/Kconfig | 4 ++++ drivers/net/tulip/dmfe.c | 17 +++++++++++++++++ drivers/net/tulip/tulip_core.c | 32 +++++++++++++++++++++++++------- 3 files changed, 46 insertions(+), 7 deletions(-)
drivers/net/tulip/Kconfig +4 -0
@@ -101,6 +101,10 @@ config TULIP_NAPI_HW_MITIGATION If in doubt, say Y. +config TULIP_DM910X + def_bool y + depends on TULIP && SPARC + config DE4X5 tristate "Generic DECchip & DIGITAL EtherWORKS PCI/EISA" depends on PCI || EISA
drivers/net/tulip/dmfe.c +17 -0
@@ -377,6 +377,23 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,if (!printed_version++)printk (version); +/* +* SPARC on-board DM910x chips should be handled by the main +* tulip driver, except for early DM9100s. +*/ +#ifdef CONFIG_TULIP_DM910X +if (ent->driver_data ==PCI_DM9100_ID && pdev->revision >=0x30 || + ent->driver_data ==PCI_DM9102_ID ) { +struct device_node *dp =pci_device_to_OF_node (pdev); + +if (dp &&of_get_property (dp,"local-mac-address" ,NULL )) { + printk(KERN_INFO DRV_NAME + ": skipping on-board DM910x (use tulip)\n"); +return -ENODEV ; + } + } +#endif +/* Init network device */ dev =alloc_etherdev (sizeof (*db));if (dev ==NULL )
drivers/net/tulip/tulip_core.c +25 -7
@@ -196,9 +196,13 @@ struct tulip_chip_table tulip_tbl[] = { | HAS_NWAY | HAS_PCI_MWI, tulip_timer, tulip_media_task },/* DM910X */ +#ifdef CONFIG_TULIP_DM910X {"Davicom DM9102/DM9102A" ,128 ,0x0001ebef ,HAS_MII |HAS_MEDIA_TABLE |CSR12_IN_SROM |HAS_ACPI , tulip_timer, tulip_media_task }, +#else + { NULL }, +#endif /* RS7112 */ { "Conexant LANfinity", 256, 0x0001ebef,
@@ -228,8 +232,10 @@ static struct pci_device_id tulip_pci_tbl[] = { { 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, { 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 }, { 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 }, +#ifdef CONFIG_TULIP_DM910X { 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X }, { 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X }, +#endif { 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, { 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 }, { 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
@@ -1299,18 +1305,30 @@ static int __devinit tulip_init_one (struct pci_dev *pdev, }/* -* Early DM9100's need software CRC and the DMFE driver +* DM910x chips should be handled by the dmfe driver, except +* on-board chips on SPARC systems. Also, early DM9100s need +* software CRC which only the dmfe driver supports. */ -if (pdev->vendor ==0x1282 && pdev->device ==0x9100 ) - { -/* Read Chip revision */ -if (pdev->revision <0x30 ) - { - printk(KERN_ERR PFX "skipping early DM9100 with Crc bug (use dmfe)\n"); +#ifdef CONFIG_TULIP_DM910X +if (chip_idx ==DM910X ) { +struct device_node *dp; + +if (pdev->vendor ==0x1282 && pdev->device ==0x9100 && + pdev->revision <0x30 ) { + printk(KERN_INFO PFX + "skipping early DM9100 with Crc bug (use dmfe)\n"); +return -ENODEV ; + } + + dp =pci_device_to_OF_node (pdev); +if (!(dp &&of_get_property (dp,"local-mac-address" ,NULL ))) { + printk(KERN_INFO PFX + "skipping DM910x expansion card (use dmfe)\n");return -ENODEV ; } } +#endif /* * Looks for early PCI chipsets where people report hangs
Signature · 1 line
1.6.5.7
Quoted 9 lines · Ben Hutchings
The Davicom DM9100 and DM9102 chips are used on the motherboards of some SPARC systems (supported by the tulip driver) and also in PCI expansion cards (supported by the dmfe driver). There is no difference in the PCI device ids for the two different configurations, so these drivers both claim the device ids. However, it is possible to distinguish the two configurations by the presence of Open Firmware properties for them, so we do that.
Signed-off-by Ben Hutchings <[email protected]>
thanks for respinning this several times!
grant
Quoted 125 lines
---
Changes from v1, as you requested:
- Downgraded log messages from ERR to INFO
- Removed dummy length parameter toof_get_property()Ben.
drivers/net/tulip/Kconfig | 4 ++++ drivers/net/tulip/dmfe.c | 17 +++++++++++++++++ drivers/net/tulip/tulip_core.c | 32 +++++++++++++++++++++++++------- 3 files changed, 46 insertions(+), 7 deletions(-)drivers/net/tulip/Kconfig +4
-0@@ -101,6 +101,10 @@ config TULIP_NAPI_HW_MITIGATION If in doubt, say Y. +config TULIP_DM910X + def_bool y + depends on TULIP && SPARC + config DE4X5 tristate "Generic DECchip & DIGITAL EtherWORKS PCI/EISA" depends on PCI || EISAdrivers/net/tulip/dmfe.c +17
-0@@ -377,6 +377,23 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,if (!printed_version++)printk (version); +/* +* SPARC on-board DM910x chips should be handled by the main +* tulip driver, except for early DM9100s. +*/ +#ifdef CONFIG_TULIP_DM910X +if (ent->driver_data ==PCI_DM9100_ID && pdev->revision >=0x30 || + ent->driver_data ==PCI_DM9102_ID ) { +struct device_node *dp =pci_device_to_OF_node (pdev); + +if (dp &&of_get_property (dp,"local-mac-address" ,NULL )) { + printk(KERN_INFO DRV_NAME + ": skipping on-board DM910x (use tulip)\n"); +return -ENODEV ; + } + } +#endif +/* Init network device */ dev =alloc_etherdev (sizeof (*db));if (dev ==NULL )drivers/net/tulip/tulip_core.c +25
-7@@ -196,9 +196,13 @@ struct tulip_chip_table tulip_tbl[] = { | HAS_NWAY | HAS_PCI_MWI, tulip_timer, tulip_media_task },/* DM910X */ +#ifdef CONFIG_TULIP_DM910X {"Davicom DM9102/DM9102A" ,128 ,0x0001ebef ,HAS_MII |HAS_MEDIA_TABLE |CSR12_IN_SROM |HAS_ACPI , tulip_timer, tulip_media_task }, +#else + { NULL }, +#endif /* RS7112 */ { "Conexant LANfinity", 256, 0x0001ebef,@@ -228,8 +232,10 @@ static struct pci_device_id tulip_pci_tbl[] = { { 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, { 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 }, { 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 }, +#ifdef CONFIG_TULIP_DM910X { 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X }, { 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X }, +#endif { 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, { 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 }, { 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },@@ -1299,18 +1305,30 @@ static int __devinit tulip_init_one (struct pci_dev *pdev, }/* -* Early DM9100's need software CRC and the DMFE driver +* DM910x chips should be handled by the dmfe driver, except +* on-board chips on SPARC systems. Also, early DM9100s need +* software CRC which only the dmfe driver supports. */ -if (pdev->vendor ==0x1282 && pdev->device ==0x9100 ) - { -/* Read Chip revision */ -if (pdev->revision <0x30 ) - { - printk(KERN_ERR PFX "skipping early DM9100 with Crc bug (use dmfe)\n"); +#ifdef CONFIG_TULIP_DM910X +if (chip_idx ==DM910X ) { +struct device_node *dp; + +if (pdev->vendor ==0x1282 && pdev->device ==0x9100 && + pdev->revision <0x30 ) { + printk(KERN_INFO PFX + "skipping early DM9100 with Crc bug (use dmfe)\n"); +return -ENODEV ; + } + + dp =pci_device_to_OF_node (pdev); +if (!(dp &&of_get_property (dp,"local-mac-address" ,NULL ))) { + printk(KERN_INFO PFX + "skipping DM910x expansion card (use dmfe)\n");return -ENODEV ; } } +#endif /* * Looks for early PCI chipsets where people report hangs Signature · 1 line
1.6.5.7
From: Grant Grundler <[email protected]>
Date: Tue, 5 Jan 2010 09:58:17 -0700
Quoted 9 lines · Ben Hutchings
Quoted 8 lines
The Davicom DM9100 and DM9102 chips are used on the motherboards of some SPARC systems (supported by the tulip driver) and also in PCI expansion cards (supported by the dmfe driver). There is no difference in the PCI device ids for the two different configurations, so these drivers both claim the device ids. However, it is possible to distinguish the two configurations by the presence of Open Firmware properties for them, so we do that.
Quoted 3 lines
Quoted 1 line
Signed-off-by Ben Hutchings <[email protected]>Signed-off-by Grant Grundler <[email protected]>
Applied, thanks everyone.
David Miller
maintainerFrom: David Miller <[email protected]>
Date: Thu, 07 Jan 2010 00:51:25 -0800 (PST)
Quoted 12 lines
From: Grant Grundler <[email protected]>
Date: Tue, 5 Jan 2010 09:58:17 -0700Quoted 9 lines · Ben Hutchings
Quoted 8 lines
The Davicom DM9100 and DM9102 chips are used on the motherboards of some SPARC systems (supported by the tulip driver) and also in PCI expansion cards (supported by the dmfe driver). There is no difference in the PCI device ids for the two different configurations, so these drivers both claim the device ids. However, it is possible to distinguish the two configurations by the presence of Open Firmware properties for them, so we do that.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Ben Hutchings <[email protected]>Signed-off-by Grant Grundler <[email protected]>Applied, thanks everyone.
Sorry, had to revert, doesn't build:
CHK include/linux/version.h
CHK include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-sparc
CALL scripts/checksyscalls.sh
CC [M] drivers/net/tulip/dmfe.odrivers/net/tulip/dmfe.c: In function 'dmfe_init_one':drivers/net/tulip/dmfe.c:386: warning: suggest parentheses around && within || drivers/net/tulip/dmfe.c:389: error: implicit declaration of function 'of_get_property' make[1]: *** [drivers/net/tulip/dmfe.o] Error 1
make: *** [drivers/net/tulip/dmfe.o] Error 2
Please fix this up and resubmit, thanks.
PATCH v3 1/1 dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
The Davicom DM9100 and DM9102 chips are used on the motherboards of some SPARC systems (supported by the tulip driver) and also in PCI expansion cards (supported by the dmfe driver). There is no difference in the PCI device ids for the two different configurations, so these drivers both claim the device ids. However, it is possible to distinguish the two configurations by the presence of Open Firmware properties for them, so we do that.
---
Quoted 2 lines · David Miller
From: David Miller <[email protected]>
Date: Thu, 07 Jan 2010 00:51:25 -0800 (PST)
[...]
Quoted 3 lines
Quoted 1 line
Applied, thanks everyone.
Sorry, had to revert, doesn't build:
[...]
When I asked for testing on SPARC, I intended that testers should actually build both drivers!
Here's one more try. I added conditional inclusion of <linux/of.h> in dmfe.c. It has to be conditional because that header doesn't compile on architectures without OF support. I also added parentheses to keep the compiler happy.
Ben.
drivers/net/tulip/Kconfig | 4 ++++ drivers/net/tulip/dmfe.c | 21 +++++++++++++++++++++ drivers/net/tulip/tulip_core.c | 32 +++++++++++++++++++++++++------- 3 files changed, 50 insertions(+), 7 deletions(-)
drivers/net/tulip/Kconfig +4 -0
@@ -101,6 +101,10 @@ config TULIP_NAPI_HW_MITIGATION If in doubt, say Y. +config TULIP_DM910X + def_bool y + depends on TULIP && SPARC + config DE4X5 tristate "Generic DECchip & DIGITAL EtherWORKS PCI/EISA" depends on PCI || EISA
drivers/net/tulip/dmfe.c +21 -0
@@ -92,6 +92,10 @@#include <asm/uaccess.h> #include <asm/irq.h> +#ifdef CONFIG_TULIP_DM910X +#include <linux/of.h> +#endif +/* Board/System/Debug information/definition ---------------- */ #define PCI_DM9132_ID 0x91321282/* Davicom DM9132 ID */
@@ -377,6 +381,23 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,if (!printed_version++)printk (version); +/* +* SPARC on-board DM910x chips should be handled by the main +* tulip driver, except for early DM9100s. +*/ +#ifdef CONFIG_TULIP_DM910X +if ((ent->driver_data ==PCI_DM9100_ID && pdev->revision >=0x30 ) || + ent->driver_data ==PCI_DM9102_ID ) { +struct device_node *dp =pci_device_to_OF_node (pdev); + +if (dp &&of_get_property (dp,"local-mac-address" ,NULL )) { + printk(KERN_INFO DRV_NAME + ": skipping on-board DM910x (use tulip)\n"); +return -ENODEV ; + } + } +#endif +/* Init network device */ dev =alloc_etherdev (sizeof (*db));if (dev ==NULL )
drivers/net/tulip/tulip_core.c +25 -7
@@ -196,9 +196,13 @@ struct tulip_chip_table tulip_tbl[] = { | HAS_NWAY | HAS_PCI_MWI, tulip_timer, tulip_media_task },/* DM910X */ +#ifdef CONFIG_TULIP_DM910X {"Davicom DM9102/DM9102A" ,128 ,0x0001ebef ,HAS_MII |HAS_MEDIA_TABLE |CSR12_IN_SROM |HAS_ACPI , tulip_timer, tulip_media_task }, +#else + { NULL }, +#endif /* RS7112 */ { "Conexant LANfinity", 256, 0x0001ebef,
@@ -228,8 +232,10 @@ static struct pci_device_id tulip_pci_tbl[] = { { 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, { 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 }, { 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 }, +#ifdef CONFIG_TULIP_DM910X { 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X }, { 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X }, +#endif { 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, { 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 }, { 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
@@ -1299,18 +1305,30 @@ static int __devinit tulip_init_one (struct pci_dev *pdev, }/* -* Early DM9100's need software CRC and the DMFE driver +* DM910x chips should be handled by the dmfe driver, except +* on-board chips on SPARC systems. Also, early DM9100s need +* software CRC which only the dmfe driver supports. */ -if (pdev->vendor ==0x1282 && pdev->device ==0x9100 ) - { -/* Read Chip revision */ -if (pdev->revision <0x30 ) - { - printk(KERN_ERR PFX "skipping early DM9100 with Crc bug (use dmfe)\n"); +#ifdef CONFIG_TULIP_DM910X +if (chip_idx ==DM910X ) { +struct device_node *dp; + +if (pdev->vendor ==0x1282 && pdev->device ==0x9100 && + pdev->revision <0x30 ) { + printk(KERN_INFO PFX + "skipping early DM9100 with Crc bug (use dmfe)\n"); +return -ENODEV ; + } + + dp =pci_device_to_OF_node (pdev); +if (!(dp &&of_get_property (dp,"local-mac-address" ,NULL ))) { + printk(KERN_INFO PFX + "skipping DM910x expansion card (use dmfe)\n");return -ENODEV ; } } +#endif /* * Looks for early PCI chipsets where people report hangs
Signature · 1 line
1.6.5.7
Quoted 9 lines · Ben Hutchings
The Davicom DM9100 and DM9102 chips are used on the motherboards of some SPARC systems (supported by the tulip driver) and also in PCI expansion cards (supported by the dmfe driver). There is no difference in the PCI device ids for the two different configurations, so these drivers both claim the device ids. However, it is possible to distinguish the two configurations by the presence of Open Firmware properties for them, so we do that.
Signed-off-by Ben Hutchings <[email protected]>
thanks,
grant
Quoted 149 lines
---
Quoted 2 lines · David Miller
From: David Miller <[email protected]>
Date: Thu, 07 Jan 2010 00:51:25 -0800 (PST)[...]
Quoted 3 lines
Quoted 1 line
Applied, thanks everyone.
Sorry, had to revert, doesn't build:
[...]
When I asked for testing on SPARC, I intended that testers should actually build both drivers!
Here's one more try. I added conditional inclusion of <
linux/of.h> indmfe.c. It has to be conditional because that header doesn't compile on architectures without OF support. I also added parentheses to keep the compiler happy.Ben.
drivers/net/tulip/Kconfig | 4 ++++ drivers/net/tulip/dmfe.c | 21 +++++++++++++++++++++ drivers/net/tulip/tulip_core.c | 32 +++++++++++++++++++++++++------- 3 files changed, 50 insertions(+), 7 deletions(-)drivers/net/tulip/Kconfig +4
-0@@ -101,6 +101,10 @@ config TULIP_NAPI_HW_MITIGATION If in doubt, say Y. +config TULIP_DM910X + def_bool y + depends on TULIP && SPARC + config DE4X5 tristate "Generic DECchip & DIGITAL EtherWORKS PCI/EISA" depends on PCI || EISAdrivers/net/tulip/dmfe.c +21
-0@@ -92,6 +92,10 @@#include <asm/uaccess.h> #include <asm/irq.h> +#ifdef CONFIG_TULIP_DM910X +#include <linux/of.h> +#endif +/* Board/System/Debug information/definition ---------------- */ #define PCI_DM9132_ID 0x91321282/* Davicom DM9132 ID */ @@ -377,6 +381,23 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,if (!printed_version++)printk (version); +/* +* SPARC on-board DM910x chips should be handled by the main +* tulip driver, except for early DM9100s. +*/ +#ifdef CONFIG_TULIP_DM910X +if ((ent->driver_data ==PCI_DM9100_ID && pdev->revision >=0x30 ) || + ent->driver_data ==PCI_DM9102_ID ) { +struct device_node *dp =pci_device_to_OF_node (pdev); + +if (dp &&of_get_property (dp,"local-mac-address" ,NULL )) { + printk(KERN_INFO DRV_NAME + ": skipping on-board DM910x (use tulip)\n"); +return -ENODEV ; + } + } +#endif +/* Init network device */ dev =alloc_etherdev (sizeof (*db));if (dev ==NULL )drivers/net/tulip/tulip_core.c +25
-7@@ -196,9 +196,13 @@ struct tulip_chip_table tulip_tbl[] = { | HAS_NWAY | HAS_PCI_MWI, tulip_timer, tulip_media_task },/* DM910X */ +#ifdef CONFIG_TULIP_DM910X {"Davicom DM9102/DM9102A" ,128 ,0x0001ebef ,HAS_MII |HAS_MEDIA_TABLE |CSR12_IN_SROM |HAS_ACPI , tulip_timer, tulip_media_task }, +#else + { NULL }, +#endif /* RS7112 */ { "Conexant LANfinity", 256, 0x0001ebef,@@ -228,8 +232,10 @@ static struct pci_device_id tulip_pci_tbl[] = { { 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, { 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 }, { 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 }, +#ifdef CONFIG_TULIP_DM910X { 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X }, { 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X }, +#endif { 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, { 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 }, { 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },@@ -1299,18 +1305,30 @@ static int __devinit tulip_init_one (struct pci_dev *pdev, }/* -* Early DM9100's need software CRC and the DMFE driver +* DM910x chips should be handled by the dmfe driver, except +* on-board chips on SPARC systems. Also, early DM9100s need +* software CRC which only the dmfe driver supports. */ -if (pdev->vendor ==0x1282 && pdev->device ==0x9100 ) - { -/* Read Chip revision */ -if (pdev->revision <0x30 ) - { - printk(KERN_ERR PFX "skipping early DM9100 with Crc bug (use dmfe)\n"); +#ifdef CONFIG_TULIP_DM910X +if (chip_idx ==DM910X ) { +struct device_node *dp; + +if (pdev->vendor ==0x1282 && pdev->device ==0x9100 && + pdev->revision <0x30 ) { + printk(KERN_INFO PFX + "skipping early DM9100 with Crc bug (use dmfe)\n"); +return -ENODEV ; + } + + dp =pci_device_to_OF_node (pdev); +if (!(dp &&of_get_property (dp,"local-mac-address" ,NULL ))) { + printk(KERN_INFO PFX + "skipping DM910x expansion card (use dmfe)\n");return -ENODEV ; } } +#endif /* * Looks for early PCI chipsets where people report hangs Signature · 1 line
1.6.5.7
From: Grant Grundler <[email protected]>
Date: Thu, 7 Jan 2010 11:46:24 -0700
Quoted 9 lines · Ben Hutchings
Quoted 8 lines
The Davicom DM9100 and DM9102 chips are used on the motherboards of some SPARC systems (supported by the tulip driver) and also in PCI expansion cards (supported by the dmfe driver). There is no difference in the PCI device ids for the two different configurations, so these drivers both claim the device ids. However, it is possible to distinguish the two configurations by the presence of Open Firmware properties for them, so we do that.
Quoted 3 lines
Quoted 1 line
Signed-off-by Ben Hutchings <[email protected]>Signed-off-by Grant Grundler <[email protected]>
Applied.