2013-04-18 18:51:05

by Mike Miller

[permalink] [raw]
Subject: [PATCH 1/1] cciss: add cciss_allow_hpsa module parameter


Add the cciss_allow_hpsa modules parameter. This allows users to use the hpsa
driver instead of cciss for older controllers.
Tested with 3.9.0-rc7 in combination with the bug fix submitted Tuesday. My
apologies for not testing that patch with the correct kernel.

From: Mike <[email protected]>
Signed-off-by: Mike Miller <[email protected]>

---
drivers/block/cciss.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index a6c0973..081d1a8 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -75,6 +75,12 @@ module_param(cciss_simple_mode, int, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(cciss_simple_mode,
"Use 'simple mode' rather than 'performant mode'");

+static int cciss_allow_hpsa;
+module_param(cciss_allow_hpsa, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(cciss_allow_hpsa,
+ "Prevent cciss driver from accessing hardware known to be "
+ " supported by the hpsa driver");
+
static DEFINE_MUTEX(cciss_mutex);
static struct proc_dir_entry *proc_cciss;

@@ -4116,9 +4122,13 @@ static int cciss_lookup_board_id(struct pci_dev *pdev, u32 *board_id)
*board_id = ((subsystem_device_id << 16) & 0xffff0000) |
subsystem_vendor_id;

- for (i = 0; i < ARRAY_SIZE(products); i++)
+ for (i = 0; i < ARRAY_SIZE(products); i++) {
+ /* Stand aside for hpsa driver on request */
+ if (cciss_allow_hpsa)
+ return -ENODEV;
if (*board_id == products[i].board_id)
return i;
+ }
dev_warn(&pdev->dev, "unrecognized board ID: 0x%08x, ignoring.\n",
*board_id);
return -ENODEV;


2013-04-22 22:10:42

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCH 1/1] cciss: add cciss_allow_hpsa module parameter

On Thu, 18 Apr 2013 13:49:37 -0500 Mike Miller <[email protected]> wrote:

> Add the cciss_allow_hpsa modules parameter. This allows users to use the hpsa
> driver instead of cciss for older controllers.
> Tested with 3.9.0-rc7 in combination with the bug fix submitted Tuesday. My
> apologies for not testing that patch with the correct kernel.

Could you please resend Tuesday's bug fix, with a much better
explanation than v1 had? It's totally weird and wonderful that there's
an interaction between kdump and one scsi/block driver so let's try to
get a diagnosis into the record.