]> git.baikalelectronics.ru Git - kernel.git/commit
[SCSI] a100u2w: Convert into Linux style
authorAlan Cox <alan@lxorguk.ukuu.org.uk>
Fri, 15 Jun 2007 13:45:30 +0000 (14:45 +0100)
committerJames Bottomley <jejb@mulgrave.il.steeleye.com>
Sun, 17 Jun 2007 21:09:29 +0000 (16:09 -0500)
commitd1874d9530b91d9b636cc3c38cc41c9bcf183c6b
treea1e5988f2df2395842b298b899d4cfef9209269d
parent1148a4d22a36e97b92f7d17dbe4a2eea249d3a0a
[SCSI] a100u2w: Convert into Linux style

I was investigating strange driver behaviour and thought that readable
code and proper visible types might help explain why it didn't work right
the moment a second SCB was outstanding to the controller. I was right

- Cleanup, linuxise, demacro
- Remove the BSD dual licence on the new work
- Switch the if ALPHA to if __LP64__. (struct size is then right
elsewhere) and then to CONFIG_64BIT as per Christoph's request
- Fix the recursive locking on a reset. This is the only actual real code
change (I hope ;)).

I'm not clear what the right way to handle the BIOS param stuff is on n
on x86-32/64. Using phys_to_virt and stuff is ugly and probably doesn't
make sense elsewhere

Still has a couple of odd things - and there seems to be a commonly shared
EEPROM handling error several drivers have. Roughly speaking several SCSI
drivers go

try and read EEPROM
It failed..
Write any changes between the default and the data we read

Which is great as for some paths we've no idea what was in
before, so each boot won't write it all back, won't checksum but will
repeat the bug

Also it can still sleep for a second with IRQ off, and there is some
dubious looking error path locking marked FIXME in case anyone feels
inspired to work on it. Not a newly introduced bug, and at least its now
marked.

Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
drivers/scsi/a100u2w.c
drivers/scsi/a100u2w.h