diff mbox

hpsa: add support for legacy boards

Message ID 1499755744-79217-1-git-send-email-hare@suse.de (mailing list archive)
State Changes Requested, archived
Headers show

Commit Message

Hannes Reinecke July 11, 2017, 6:49 a.m. UTC
Add support for legacy boards, ensuring to enable the driver for
those boards only when 'hpsa_allow_any' is set.

Signed-off-by: Hannes Reinecke <hare@suse.com>
---
 drivers/scsi/hpsa.c | 35 +++++++++++++++++++++++++++++++++--
 drivers/scsi/hpsa.h | 44 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 77 insertions(+), 2 deletions(-)

Comments

Meelis Roos July 11, 2017, 2:25 p.m. UTC | #1
> Add support for legacy boards, ensuring to enable the driver for
> those boards only when 'hpsa_allow_any' is set.

Applied this patch, made sure I had compiled in hpsa and not cciss to 
avoid any variables from initramfs, and still I get this:

[    4.015080] hpsa 0000:00:04.0: unrecognized board ID: 0x40800e11, ignoring.
[    4.098473] hpsa 0000:00:04.0: Board ID not found

Boot command line was "root=/dev/sda1 console=ttyS0,9600 ro hpsa_allow_any=1" - 
seems correct.

By looking at the code, I should see "unsupported board ID:" and it 
should work, but I see "unrecognized board ID:" and it does not work.

Hmm, trying hpsa.hpsa_allow_any=1. Much better:

[    3.891531] hpsa 0000:00:04.0: unsupported board ID: 0x40800e11
[    3.962367] hpsa 0000:00:04.0: unsupported board ID: 0x40800e11
[    4.033493] hpsa 0000:00:04.0: Controller reports max supported commands of 0 Using 16 instead. Ensure that firmware is up to date.
[    4.175134] hpsa 0000:00:04.0: Physical aborts not supported
[    4.242931] hpsa 0000:00:04.0: Logical aborts not supported
[    4.309594] hpsa 0000:00:04.0: HP SSD Smart Path aborts not supported
[    4.460889] hpsa 0000:00:04.0: Controller reports max supported commands of 0 Using 16 instead. Ensure that firmware is up to date.
[    4.584679] scsi host0: hpsa
[    4.587842] hpsa 0000:00:04.0: report luns requested format 2, got 0
[    4.613215] hpsa 0000:00:04.0: scsi 0:0:0:0: masked Direct-Access     COMPAQ   BD03685A24       PHYS DRV SSDSmartPathCap- En- Exp=0
[    4.613219] hpsa 0000:00:04.0: C0:B1:T0:L0 Volume status is not available through vital product data pages.
[    4.613224] hpsa 0000:00:04.0: scsi 0:1:0:0: offline Direct-Access     COMPAQ   LOGICAL VOLUME   RAID-1(+0) SSDSmartPathCap- En- Exp=1
[    4.613229] hpsa 0000:00:04.0: scsi 0:3:0:0: added RAID              COMPAQ   Smart Array 5i   controller SSDSmartPathCap- En- Exp=1
[    6.187725] scsi 0:3:0:0: RAID              COMPAQ   Smart Array 5i   2.62 PQ: 0 ANSI: 0
[...]
[    6.726872] VFS: Cannot open root device "sda1" or unknown-block(0,0): error -6
[    6.814364] Please append a correct "root=" boot option; here are the available partitions:
[    6.914403] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Controller is detected, there is something behind it but no sda is 
detected and no bootup.

What next?

And, for readability, we should use something like "Using unsupported 
board ID", not plain "unsupported board ID" - the last one leaves 
assumption that it will not work, although it should.
Don Brace July 11, 2017, 3:38 p.m. UTC | #2
> -----Original Message-----
> From: mroos@math.ut.ee [mailto:mroos@math.ut.ee] On Behalf Of Meelis
> Roos
> Sent: Tuesday, July 11, 2017 9:26 AM
> To: Hannes Reinecke <hare@suse.de>
> Cc: Martin K. Petersen <martin.petersen@oracle.com>; Christoph Hellwig
> <hch@lst.de>; James Bottomley
> <james.bottomley@hansenpartnership.com>; Don Brace
> <don.brace@microsemi.com>; Jens Axboe <axboe@kernel.dk>; linux-
> scsi@vger.kernel.org; Hannes Reinecke <hare@suse.com>
> Subject: Re: [PATCH] hpsa: add support for legacy boards
> 
> EXTERNAL EMAIL
> 
> 
> > Add support for legacy boards, ensuring to enable the driver for
> > those boards only when 'hpsa_allow_any' is set.
> 
> Applied this patch, made sure I had compiled in hpsa and not cciss to
> avoid any variables from initramfs, and still I get this:
> 
> [    4.015080] hpsa 0000:00:04.0: unrecognized board ID: 0x40800e11, ignoring.
> [    4.098473] hpsa 0000:00:04.0: Board ID not found
> 
> Boot command line was "root=/dev/sda1 console=ttyS0,9600 ro
> hpsa_allow_any=1" -
> seems correct.
> 
> By looking at the code, I should see "unsupported board ID:" and it
> should work, but I see "unrecognized board ID:" and it does not work.
> 
> Hmm, trying hpsa.hpsa_allow_any=1. Much better:
> 
> [    3.891531] hpsa 0000:00:04.0: unsupported board ID: 0x40800e11
> [    3.962367] hpsa 0000:00:04.0: unsupported board ID: 0x40800e11
> [    4.033493] hpsa 0000:00:04.0: Controller reports max supported commands
> of 0 Using 16 instead. Ensure that firmware is up to date.
> [    4.175134] hpsa 0000:00:04.0: Physical aborts not supported
> [    4.242931] hpsa 0000:00:04.0: Logical aborts not supported
> [    4.309594] hpsa 0000:00:04.0: HP SSD Smart Path aborts not supported
> [    4.460889] hpsa 0000:00:04.0: Controller reports max supported commands
> of 0 Using 16 instead. Ensure that firmware is up to date.
> [    4.584679] scsi host0: hpsa
> [    4.587842] hpsa 0000:00:04.0: report luns requested format 2, got 0
> [    4.613215] hpsa 0000:00:04.0: scsi 0:0:0:0: masked Direct-Access     COMPAQ
> BD03685A24       PHYS DRV SSDSmartPathCap- En- Exp=0
> [    4.613219] hpsa 0000:00:04.0: C0:B1:T0:L0 Volume status is not available
> through vital product data pages.
> [    4.613224] hpsa 0000:00:04.0: scsi 0:1:0:0: offline Direct-Access     COMPAQ
> LOGICAL VOLUME   RAID-1(+0) SSDSmartPathCap- En- Exp=1
> [    4.613229] hpsa 0000:00:04.0: scsi 0:3:0:0: added RAID              COMPAQ
> Smart Array 5i   controller SSDSmartPathCap- En- Exp=1
> [    6.187725] scsi 0:3:0:0: RAID              COMPAQ   Smart Array 5i   2.62 PQ: 0
> ANSI: 0
> [...]
> [    6.726872] VFS: Cannot open root device "sda1" or unknown-block(0,0):
> error -6
> [    6.814364] Please append a correct "root=" boot option; here are the
> available partitions:
> [    6.914403] Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)
> 
> Controller is detected, there is something behind it but no sda is
> detected and no bootup.
> 
> What next?
> 
> And, for readability, we should use something like "Using unsupported
> board ID", not plain "unsupported board ID" - the last one leaves
> assumption that it will not work, although it should.
> 
> --
> Meelis Roos (mroos@linux.ee)

The 5i controller is probably too old for the hpsa driver to support. 
The hpsa driver is looking for information to determine if the drive is online/offline and
this information is not available.

What was the original issue you were having with the cciss driver?
Meelis Roos July 11, 2017, 3:58 p.m. UTC | #3
> The 5i controller is probably too old for the hpsa driver to support. 
> The hpsa driver is looking for information to determine if the drive is online/offline and
> this information is not available.
> 
> What was the original issue you were having with the cciss driver?

Christoph Hellwig updated block layer with "block: Make most 
scsi_req_init() calls implicit" and at first try, cciss was left without 
the needed initialization. This caused OOPS in udev probing but the 
system worked. The issue was fixed by Christoph quickly.

But he suggested it might be worth trying hpsa driver instead of cciss, 
with a longer term goal to to move users of cciss over to hpsa if 
possible. Now that I have tested it, it seems not all older cards are 
supported in hpsa - it's more than ID-s and interrupt masks.
Christoph Hellwig July 12, 2017, 7:11 a.m. UTC | #4
On Tue, Jul 11, 2017 at 06:58:36PM +0300, Meelis Roos wrote:
> > The 5i controller is probably too old for the hpsa driver to support. 
> > The hpsa driver is looking for information to determine if the drive is online/offline and
> > this information is not available.
> > 
> > What was the original issue you were having with the cciss driver?
> 
> Christoph Hellwig updated block layer with "block: Make most 
> scsi_req_init() calls implicit" and at first try, cciss was left without 
> the needed initialization. This caused OOPS in udev probing but the 
> system worked. The issue was fixed by Christoph quickly.

The original patch is from Bart, but otherwise correct.

> But he suggested it might be worth trying hpsa driver instead of cciss, 
> with a longer term goal to to move users of cciss over to hpsa if 
> possible. Now that I have tested it, it seems not all older cards are 
> supported in hpsa - it's more than ID-s and interrupt masks.

Seems like it.  And the idea behind this game is that we'd like to slowly
get rid of old request_fn based drivers.  Given that hpsa supports very
similar hardware cciss is a target for removal once that hardware is
switched over.  But it seems like we'll need more work in this area..

> 
> -- 
> Meelis Roos (mroos@linux.ee)
---end quoted text---
Hannes Reinecke July 12, 2017, 7:12 a.m. UTC | #5
On 07/12/2017 09:11 AM, Christoph Hellwig wrote:
> On Tue, Jul 11, 2017 at 06:58:36PM +0300, Meelis Roos wrote:
>>> The 5i controller is probably too old for the hpsa driver to support. 
>>> The hpsa driver is looking for information to determine if the drive is online/offline and
>>> this information is not available.
>>>
>>> What was the original issue you were having with the cciss driver?
>>
>> Christoph Hellwig updated block layer with "block: Make most 
>> scsi_req_init() calls implicit" and at first try, cciss was left without 
>> the needed initialization. This caused OOPS in udev probing but the 
>> system worked. The issue was fixed by Christoph quickly.
> 
> The original patch is from Bart, but otherwise correct.
> 
>> But he suggested it might be worth trying hpsa driver instead of cciss, 
>> with a longer term goal to to move users of cciss over to hpsa if 
>> possible. Now that I have tested it, it seems not all older cards are 
>> supported in hpsa - it's more than ID-s and interrupt masks.
> 
> Seems like it.  And the idea behind this game is that we'd like to slowly
> get rid of old request_fn based drivers.  Given that hpsa supports very
> similar hardware cciss is a target for removal once that hardware is
> switched over.  But it seems like we'll need more work in this area..
> 
I'll give it a shot.
I seem to have an oldish cciss board floating about; let's see how far I
get with those.

Cheers,

Hannes
Hannes Reinecke Aug. 2, 2017, 3:05 p.m. UTC | #6
On 07/11/2017 04:25 PM, Meelis Roos wrote:
>> Add support for legacy boards, ensuring to enable the driver for
>> those boards only when 'hpsa_allow_any' is set.
> 
> Applied this patch, made sure I had compiled in hpsa and not cciss to 
> avoid any variables from initramfs, and still I get this:
> 
> [    4.015080] hpsa 0000:00:04.0: unrecognized board ID: 0x40800e11, ignoring.
> [    4.098473] hpsa 0000:00:04.0: Board ID not found
> 
> Boot command line was "root=/dev/sda1 console=ttyS0,9600 ro hpsa_allow_any=1" - 
> seems correct.
> 
> By looking at the code, I should see "unsupported board ID:" and it 
> should work, but I see "unrecognized board ID:" and it does not work.
> 
> Hmm, trying hpsa.hpsa_allow_any=1. Much better:
> 
> [    3.891531] hpsa 0000:00:04.0: unsupported board ID: 0x40800e11
> [    3.962367] hpsa 0000:00:04.0: unsupported board ID: 0x40800e11
> [    4.033493] hpsa 0000:00:04.0: Controller reports max supported commands of 0 Using 16 instead. Ensure that firmware is up to date.
> [    4.175134] hpsa 0000:00:04.0: Physical aborts not supported
> [    4.242931] hpsa 0000:00:04.0: Logical aborts not supported
> [    4.309594] hpsa 0000:00:04.0: HP SSD Smart Path aborts not supported
> [    4.460889] hpsa 0000:00:04.0: Controller reports max supported commands of 0 Using 16 instead. Ensure that firmware is up to date.
> [    4.584679] scsi host0: hpsa
> [    4.587842] hpsa 0000:00:04.0: report luns requested format 2, got 0
> [    4.613215] hpsa 0000:00:04.0: scsi 0:0:0:0: masked Direct-Access     COMPAQ   BD03685A24       PHYS DRV SSDSmartPathCap- En- Exp=0
> [    4.613219] hpsa 0000:00:04.0: C0:B1:T0:L0 Volume status is not available through vital product data pages.
> [    4.613224] hpsa 0000:00:04.0: scsi 0:1:0:0: offline Direct-Access     COMPAQ   LOGICAL VOLUME   RAID-1(+0) SSDSmartPathCap- En- Exp=1
> [    4.613229] hpsa 0000:00:04.0: scsi 0:3:0:0: added RAID              COMPAQ   Smart Array 5i   controller SSDSmartPathCap- En- Exp=1
> [    6.187725] scsi 0:3:0:0: RAID              COMPAQ   Smart Array 5i   2.62 PQ: 0 ANSI: 0
> [...]
> [    6.726872] VFS: Cannot open root device "sda1" or unknown-block(0,0): error -6
> [    6.814364] Please append a correct "root=" boot option; here are the available partitions:
> [    6.914403] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
> 
> Controller is detected, there is something behind it but no sda is 
> detected and no bootup.
> 
> What next?
> 
As Don indicated, older controller probably don't support volume state
information. But that shouldn't distract us. Will be sending a patch.

Cheers,

Hannes
diff mbox

Patch

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8914eab..2cf6ccc 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -148,6 +148,8 @@ 
 	{PCI_VENDOR_ID_HP, 0x333f, 0x103c, 0x333f},
 	{PCI_VENDOR_ID_HP,     PCI_ANY_ID,	PCI_ANY_ID, PCI_ANY_ID,
 		PCI_CLASS_STORAGE_RAID << 8, 0xffff << 8, 0},
+	{PCI_VENDOR_ID_COMPAQ,     PCI_ANY_ID,	PCI_ANY_ID, PCI_ANY_ID,
+		PCI_CLASS_STORAGE_RAID << 8, 0xffff << 8, 0},
 	{0,}
 };
 
@@ -158,6 +160,26 @@ 
  *  access = Address of the struct of function pointers
  */
 static struct board_type products[] = {
+	{0x40700E11, "Smart Array 5300", &SA5A_access},
+	{0x40800E11, "Smart Array 5i", &SA5B_access},
+	{0x40820E11, "Smart Array 532", &SA5B_access},
+	{0x40830E11, "Smart Array 5312", &SA5B_access},
+	{0x409A0E11, "Smart Array 641", &SA5A_access},
+	{0x409B0E11, "Smart Array 642", &SA5A_access},
+	{0x409C0E11, "Smart Array 6400", &SA5A_access},
+	{0x409D0E11, "Smart Array 6400 EM", &SA5A_access},
+	{0x40910E11, "Smart Array 6i", &SA5A_access},
+	{0x3225103C, "Smart Array P600", &SA5A_access},
+	{0x3223103C, "Smart Array P800", &SA5A_access},
+	{0x3234103C, "Smart Array P400", &SA5A_access},
+	{0x3235103C, "Smart Array P400i", &SA5A_access},
+	{0x3211103C, "Smart Array E200i", &SA5A_access},
+	{0x3212103C, "Smart Array E200", &SA5A_access},
+	{0x3213103C, "Smart Array E200i", &SA5A_access},
+	{0x3214103C, "Smart Array E200i", &SA5A_access},
+	{0x3215103C, "Smart Array E200i", &SA5A_access},
+	{0x3237103C, "Smart Array E500", &SA5A_access},
+	{0x323D103C, "Smart Array P700m", &SA5A_access},
 	{0x3241103C, "Smart Array P212", &SA5_access},
 	{0x3243103C, "Smart Array P410", &SA5_access},
 	{0x3245103C, "Smart Array P410i", &SA5_access},
@@ -7243,8 +7265,17 @@  static int hpsa_lookup_board_id(struct pci_dev *pdev, u32 *board_id)
 		    subsystem_vendor_id;
 
 	for (i = 0; i < ARRAY_SIZE(products); i++)
-		if (*board_id == products[i].board_id)
-			return i;
+		if (*board_id == products[i].board_id) {
+			if (products[i].access != &SA5A_access &&
+			    products[i].access != &SA5B_access)
+				return i;
+			if (hpsa_allow_any) {
+				dev_warn(&pdev->dev,
+					 "unsupported board ID: 0x%08x\n",
+					 *board_id);
+				return i;
+			}
+		}
 
 	if ((subsystem_vendor_id != PCI_VENDOR_ID_HP &&
 		subsystem_vendor_id != PCI_VENDOR_ID_COMPAQ) ||
diff --git a/drivers/scsi/hpsa.h b/drivers/scsi/hpsa.h
index 1c49741..e700d2b 100644
--- a/drivers/scsi/hpsa.h
+++ b/drivers/scsi/hpsa.h
@@ -447,6 +447,25 @@  static void SA5_intr_mask(struct ctlr_info *h, unsigned long val)
 	}
 }
 
+/*
+ *  This card is the opposite of the other cards.
+ *   0 turns interrupts on...
+ *   0x04 turns them off...
+ */
+static void SA5B_intr_mask(struct ctlr_info *h, unsigned long val)
+{
+	if (val) { /* Turn interrupts on */
+		h->interrupts_enabled = 1;
+		writel(0, h->vaddr + SA5_REPLY_INTR_MASK_OFFSET);
+		(void) readl(h->vaddr + SA5_REPLY_INTR_MASK_OFFSET);
+	} else { /* Turn them off */
+		h->interrupts_enabled = 0;
+		writel(SA5B_INTR_OFF,
+		       h->vaddr + SA5_REPLY_INTR_MASK_OFFSET);
+		(void) readl(h->vaddr + SA5_REPLY_INTR_MASK_OFFSET);
+	}
+}
+
 static void SA5_performant_intr_mask(struct ctlr_info *h, unsigned long val)
 {
 	if (val) { /* turn on interrupts */
@@ -549,6 +568,16 @@  static bool SA5_ioaccel_mode1_intr_pending(struct ctlr_info *h)
 		true : false;
 }
 
+/*
+ *      Returns true if an interrupt is pending..
+ */
+static bool SA5B_intr_pending(struct ctlr_info *h)
+{
+	unsigned long register_value  =
+		readl(h->vaddr + SA5_INTR_STATUS);
+	return (register_value & SA5B_INTR_PENDING);
+}
+
 #define IOACCEL_MODE1_REPLY_QUEUE_INDEX  0x1A0
 #define IOACCEL_MODE1_PRODUCER_INDEX     0x1B8
 #define IOACCEL_MODE1_CONSUMER_INDEX     0x1BC
@@ -587,6 +616,21 @@  static unsigned long SA5_ioaccel_mode1_completed(struct ctlr_info *h, u8 q)
 	.command_completed = SA5_completed,
 };
 
+/* Duplicate entry of the above to mark unsupported boards */
+static struct access_method SA5A_access = {
+	.submit_command = SA5_submit_command,
+	.set_intr_mask = SA5_intr_mask,
+	.intr_pending = SA5_intr_pending,
+	.command_completed = SA5_completed,
+};
+
+static struct access_method SA5B_access = {
+	.submit_command = SA5_submit_command,
+	.set_intr_mask = SA5B_intr_mask,
+	.intr_pending = SA5B_intr_pending,
+	.command_completed = SA5_completed,
+};
+
 static struct access_method SA5_ioaccel_mode1_access = {
 	.submit_command = SA5_submit_command,
 	.set_intr_mask = SA5_performant_intr_mask,