[3.5.y.z extended stable] Patch "[SCSI] hpsa: return 0 from driver probe function on success, not 1" has been added to staging queue

Luis Henriques luis.henriques at canonical.com
Tue Dec 10 14:29:09 UTC 2013


This is a note to let you know that I have just added a patch titled

    [SCSI] hpsa: return 0 from driver probe function on success, not 1

to the linux-3.5.y-queue branch of the 3.5.y.z extended stable tree 
which can be found at:

 http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.5.y-queue

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.5.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Luis

------

>From f677b8a43c780efd95329ea9f8d71d7a02487b43 Mon Sep 17 00:00:00 2001
From: "Stephen M. Cameron" <scameron at beardog.cce.hp.com>
Date: Fri, 1 Nov 2013 11:02:25 -0500
Subject: [SCSI] hpsa: return 0 from driver probe function on success, not 1

commit 88bf6d62db4393fa03a58bada9d746312d5b496f upstream.

A return value of 1 is interpreted as an error.  See pci_driver.
in local_pci_probe().  If you're wondering how this ever could
have worked, it's because it used to be the case that only return
values less than zero were interpreted as failure.  But even in
the current kernel if the driver registers its various entry
points with the kernel, and then returns a value which is
interpreted as failure, those registrations aren't undone, so
the driver still mostly works.  However, the driver's remove
function wouldn't be called on rmmod, and pci power management
functions wouldn't work.  In the case of Smart Array, since it
has a battery backed cache (or else no cache) even if the driver
is not shut down properly as long as there is no outstanding
i/o, nothing too bad happens, which is why it took so long to
notice.

Requesting backport to stable because the change to pci-driver.c
which requires driver probe functions to return 0 occurred between
2.6.35 and 2.6.36 (the pci power management breakage) and again
between 3.7 and 3.8 (pci_dev->driver getting set to NULL in
local_pci_probe() preventing driver remove function from being
called on rmmod.)

Signed-off-by: Stephen M. Cameron <scameron at beardog.cce.hp.com>
Signed-off-by: James Bottomley <JBottomley at Parallels.com>
Signed-off-by: Luis Henriques <luis.henriques at canonical.com>
---
 drivers/scsi/hpsa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index ac56c29..c60f737 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -4859,7 +4859,7 @@ reinit_after_soft_reset:
 	hpsa_hba_inquiry(h);
 	hpsa_register_scsi(h);	/* hook ourselves into SCSI subsystem */
 	start_controller_lockup_detector(h);
-	return 1;
+	return 0;

 clean4:
 	hpsa_free_sg_chain_blocks(h);
--
1.8.3.2





More information about the kernel-team mailing list