[PATCH v3] powerpc/83xx: don't probe broken PCI on mpc837x_mds boards

Anton Vorontsov avorontsov at ru.mvista.com
Tue Oct 7 04:08:39 EST 2008


In the standalone setup the board's CPLD disables the PCI internal
arbiter, thus any access to the PCI bus will hang the board.

The common way to disable particular devices in the device tree is to
put the "status" property with any value other than "ok" or "okay"
into the device node we want to disable.

So, when there is no PCI arbiter on the bus the u-boot adds status =
"broken (no arbiter)" property into the PCI controller's node, and so
marks the PCI controller as unavailable.

Signed-off-by: Anton Vorontsov <avorontsov at ru.mvista.com>
---

On Fri, Oct 03, 2008 at 12:51:41PM -0500, Kumar Gala wrote:
[...]
>>> yes, but should we just have "status = disabled" since that is the
>>> effect?
>>
>> I don't know, should we? For the unavailable/disabled case the status
>> can be anything but not 'ok' or 'okay' (the only status values for the
>> available devices). So if we can encode the reason, why not do this?
>
> that works for me, just add the fact to the commit msg that the "valid  
> status's are 'ok' and 'okay' and everything else is treated as "not  
> available or disabled"

Done.

 arch/powerpc/platforms/83xx/mpc837x_mds.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/83xx/mpc837x_mds.c b/arch/powerpc/platforms/83xx/mpc837x_mds.c
index be62de2..8bb13c8 100644
--- a/arch/powerpc/platforms/83xx/mpc837x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
@@ -85,8 +85,14 @@ static void __init mpc837x_mds_setup_arch(void)
 		ppc_md.progress("mpc837x_mds_setup_arch()", 0);
 
 #ifdef CONFIG_PCI
-	for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
+	for_each_compatible_node(np, "pci", "fsl,mpc8349-pci") {
+		if (!of_device_is_available(np)) {
+			pr_warning("%s: disabled by the firmware.\n",
+				   np->full_name);
+			continue;
+		}
 		mpc83xx_add_bridge(np);
+	}
 #endif
 	mpc837xmds_usb_cfg();
 }
-- 
1.5.6.3




More information about the Linuxppc-dev mailing list