From: Salyzyn, Mark Date: Fri, 27 Jul 2007 14:29:26 +0000 (-0400) Subject: [SCSI] aacraid: fix Sunrise Lake reset handling X-Git-Tag: v2.6.23-rc2~164^2~7 X-Git-Url: https://err.no/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9859c1aa7e16822c574e1be89d61fbfe6188b50f;p=linux-2.6 [SCSI] aacraid: fix Sunrise Lake reset handling The patch is *much* smaller than the description. I am attempting to answer to those that want to understand an issue that was reported in May this year. If a Sunrise Lake based card that requires an alternate reset mechanism is set up to ignore the commanded IOP_RESET it reports 0x00000010 (IOP_RESET ignored) instead of 0x3803000F (use alternate reset mechanism to reset all cores), and thus the reset platform function decides to switch to IOP_RESET_ALWAYS because the reset platform function parameters indicate that we *need* to reset the card. IOP_RESET_ALWAYS then responds with the 0x3803000F return code, but alas we treat this as an error instead of using the alternate reset mechanism (put a 0x03 into the register offset 0x38). The reset fails, but the fact that the IOP_RESET_ALWAYS command was issued has put the card in a purposeful shutdown state in preparation for the alternate hardware reset to be applied. Yuck. IOP_RESET is ignored in internal production cards, typically to ensure that we catch all adapter lockup issues without the driver progressing further, so this would not appear to be a field issue and thus this patch was destined to be only in the internal Adaptec source tree. IOP_RESET_ALWAYS is reserved for kexec/kdump/FirmwareUpdate/AutomatedTestFrames so we did not function as expected in any case. Also in the past we have had OEMs specifically request that cards not be resetable after a BlinkLED/FirmwareAssert for one reason or another and To head off the possibility that the Sunrise Lake based cards would suffer a similar fate, we propose the enclosed fix. Yinghai Lu of SUN had a pre-production card with IOP_RESET disabled when he reported an issue to the linux kernel list back in May regarding a kexec problem resulting from this reset being ignore. His fix was to update the Firmware to one that did not ignore the IOP_RESET. Previous kernels did not attempt to reset the adapter and that is why it surfaced as a regression in his hands. The current list of aacraid based cards that use Sunrise Lake: 9005:0285:9005:02b5 Adaptec 5445 9005:0285:9005:02b6 Adaptec 5805 9005:0285:9005:02b7 Adaptec 5085 9005:0285:9005:02c3 Adaptec 51205 9005:0285:9005:02c4 Adaptec 51605 9005:0285:9005:02ce Adaptec 51245 9005:0285:9005:02cf Adaptec 51645 9005:0285:9005:02d0 Adaptec 52445 9005:0285:9005:02d1 Adaptec 5405 9005:0285:9005:02b8 ICP ICP5445SL 9005:0285:9005:02b9 ICP ICP5085SL 9005:0285:9005:02ba ICP ICP5805SL 9005:0285:9005:02c5 ICP ICP5125SL 9005:0285:9005:02c6 ICP ICP5165SL 9005:0285:108e:7aac SUN STK RAID REM 9005:0285:108e:0286 SUN STK RAID INT 9005:0285:108e:0287 SUN STK RAID EXT 9005:0285:108e:7aae SUN STK RAID EM All of these are publicly released with IOP_RESET enabled. So there is no immediate need for this patch. Signed-off-by: Mark Salyzyn Signed-off-by: James Bottomley --- diff --git a/drivers/scsi/aacraid/rx.c b/drivers/scsi/aacraid/rx.c index ebc65b9fea..73eef3dc5d 100644 --- a/drivers/scsi/aacraid/rx.c +++ b/drivers/scsi/aacraid/rx.c @@ -472,7 +472,7 @@ static int aac_rx_restart_adapter(struct aac_dev *dev, int bled) else { bled = aac_adapter_sync_cmd(dev, IOP_RESET_ALWAYS, 0, 0, 0, 0, 0, 0, &var, NULL, NULL, NULL, NULL); - if (!bled && (var != 0x00000001)) + if (!bled && (var != 0x00000001) && (var != 0x3803000F)) bled = -EINVAL; } if (bled && (bled != -ETIMEDOUT))