summaryrefslogtreecommitdiff
path: root/init
diff options
context:
space:
mode:
authorSalyzyn, Mark <mark_salyzyn@adaptec.com>2007-07-27 10:29:26 -0400
committerJames Bottomley <jejb@mulgrave.localdomain>2007-07-28 10:11:32 -0400
commit9859c1aa7e16822c574e1be89d61fbfe6188b50f (patch)
treeadb8dcd33a391e4ed043e35cb748dcf41b000804 /init
parentb90f90d2303f27b9b241ab78419a07b41de5ac62 (diff)
downloadlinux-stable-9859c1aa7e16822c574e1be89d61fbfe6188b50f.tar.gz
linux-stable-9859c1aa7e16822c574e1be89d61fbfe6188b50f.tar.bz2
linux-stable-9859c1aa7e16822c574e1be89d61fbfe6188b50f.zip
[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 <aacraid@adaptec.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Diffstat (limited to 'init')
0 files changed, 0 insertions, 0 deletions