Only register one si per bmc. Use any user-provided devices first, followed
by the first device with an irq, followed by the first device discovered.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
 drivers/char/ipmi/ipmi_si_intf.c |   33 +++++++++++++++++++++++++++++++++
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index d2bdf92..95af023 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -3258,6 +3258,7 @@ static __devinit int init_ipmi_si(void)
 	int  i;
 	char *str;
 	int  rv;
+	struct smi_info *e;
 
 	if (initialized)
 		return 0;
@@ -3292,6 +3293,14 @@ static __devinit int init_ipmi_si(void)
 
 	hardcode_find_bmc();
 
+	/* If the user gave us a device, they presumably want us to use it */
+	mutex_lock(&smi_infos_lock);
+	if (!list_empty(&smi_infos)) {
+		mutex_unlock(&smi_infos_lock);
+		return 0;
+	}
+	mutex_unlock(&smi_infos_lock);
+
 #ifdef CONFIG_DMI
 	dmi_find_bmc();
 #endif
@@ -3315,6 +3324,30 @@ static __devinit int init_ipmi_si(void)
 	of_register_platform_driver(&ipmi_of_platform_driver);
 #endif
 
+	/* Try to register something with interrupts first */
+
+	mutex_lock(&smi_infos_lock);
+	list_for_each_entry(e, &smi_infos, link) {
+		if (e->irq) {
+			if (!try_smi_init(e)) {
+				mutex_unlock(&smi_infos_lock);
+				return 0;
+			}
+		}
+	}
+
+	/* Fall back to the preferred device */
+
+	list_for_each_entry(e, &smi_infos, link) {
+		if (!e->irq) {
+			if (!try_smi_init(e)) {
+				mutex_unlock(&smi_infos_lock);
+				return 0;
+			}
+		}
+	}
+	mutex_unlock(&smi_infos_lock);
+
 	if (si_trydefaults) {
 		mutex_lock(&smi_infos_lock);
 		if (list_empty(&smi_infos)) {
-- 
1.6.5.2

--

[ message continues ]

If I understand this correctly, this would really be "Only register one 
si per system".  Unfortunately, there are systems that have more than 
one BMC each with their own interface.  Also, I believe the driver would 
not function between the previous patch and this patch, which isn't the 
best.

The spec is rather fuzzy about the whole subject of multiple BMCs and 
interfaces, but reality is that there are systems that will be broken 
with this.


--

[ message continues ]

The spec explicitly says that while a system may have multiple BMCs, 
only one BMC may respond to GetDeviceID (6.11 of the 2.0 spec). Is the 

That's true. I can fix that up fairly easily.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

That section is quite misleading.  There may be management controllers 
that are not BMCs, and they may have system interfaces.  There may only 
be on BMC in a system, though, per the spec.  That really has more to do 
with event handling and the main SDR repository, though.

However, IBM makes some systems that can plug together for scalability.  
Each individual system has a BMC, and when you plug them together into 
an SMP system, all the BMCs are still there.  At least that's how I 
understand it.  I'm not sure if the other BMCs become satellite MCs in 
that case, which would be legit, sort of.  So I guess the answer to you 
question would be: "Yes, the world is not compatible with the spec".

-corey
--

[ message continues ]

Hm. Ok. In that case we seem to be in a difficult position - we're not 
supposed to register multiple SIs per BMC, but we're also not supposed 
to send anything other than GetDeviceID to an SI before we decide to use 
it. The options here would seem to be to disambiguate by either 
registering all SIs of a type (on the assumption that if we have 
multiple BMCs, they'll all present their SIs in the same way, and we 
won't have multiple SIs of the same type if we don't have multiple 
BMCs), or taking a risk on that bit of the spec by getting the GUID for 
each SI.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]