[SRU][F:linux-bluefield][PATCH v1 1/3] UBUNTU: SAUCE: Fix race condition between loading pwr-mlxbf.c and gpio-mlxbf2.c drivers

[Asmaa Mnebhi]

BugLink: https://bugs.launchpad.net/bugs/2041996

The following message is intermittently printed during boot (in 1000 reboot test):
pwr_mlxbf MLNXBF24:00: Error getting MLNXBF24 irq

Although we already handle the case where the pwr-mlxbf driver fails to find the gpio irq
due to the gpio driver not being loaded yet, there are some instances where the gpio driver
is in the process of being loaded so acpi_dev_gpio_irq_get returns some other error
besides -EPROBE_DEFER.

It doesnt hurt to always return -EPROBE_DEFER until linux is booted. if there is no
gpio driver or the gpio driver fails to load due to a bug, it has no consequences on
the pwr-mlxbf.c driver. It will keep trying until linux is done booting.

Signed-off-by: Asmaa Mnebhi <asmaa at nvidia.com>
---
 drivers/power/reset/pwr-mlxbf.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/power/reset/pwr-mlxbf.c b/drivers/power/reset/pwr-mlxbf.c
index 40cd71338010..ba40c964d8bb 100644
--- a/drivers/power/reset/pwr-mlxbf.c
+++ b/drivers/power/reset/pwr-mlxbf.c
@@ -63,11 +63,11 @@ pwr_mlxbf_probe(struct platform_device *pdev)
 	priv->hid = hid;
 
 	irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
-	if (irq == -EPROBE_DEFER) {
+
+	/* This happens if the GPIO driver is not yet completely probed, let's always defer */
+	if (irq < 0) {
+		dev_dbg(dev, "Error getting %s irq from gpio driver so defer probe\n", priv->hid);
 		return -EPROBE_DEFER;
-	} else if (irq < 0) {
-		dev_err(dev, "Error getting %s irq.\n", priv->hid);
-		return -ENXIO;
 	}
 
 	INIT_WORK(&priv->send_work, pwr_mlxbf_send_work);
-- 
2.30.1