summaryrefslogtreecommitdiff
path: root/drivers/s390/char/tape.h
AgeCommit message (Collapse)AuthorFilesLines
2012-09-26s390/tape: remove even more tape block leftoversHeiko Carstens1-1/+0
Fix this compile error: In file included from drivers/s390/char/tape_core.c:29:0: drivers/s390/char/tape_std.h:103:66: warning: ‘struct request’ declared inside parameter list [enabled by default] Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-07-20s390/comments: unify copyright messages and remove file namesHeiko Carstens1-1/+0
Remove the file name from the comment at top of many files. In most cases the file name was wrong anyway, so it's rather pointless. Also unify the IBM copyright statement. We did have a lot of sightly different statements and wanted to change them one after another whenever a file gets touched. However that never happened. Instead people start to take the old/"wrong" statements to use as a template for new files. So unify all of them in one go. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2012-05-16s390/tape: remove tape block leftoversHeiko Carstens1-43/+0
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2011-03-03[S390] tape: deadlock on system work queueMartin Schwidefsky1-0/+8
The 34xx and 3590 tape driver uses the system work queue to defer work from the interrupt function to process context, e.g. a medium sense after an unsolicited interrupt. The tape commands started by the work handler need to be asynchronous, otherwise a deadlock on the system work queue can occur. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-12-07[S390] tape: remove BKL from tape driverMartin Schwidefsky1-0/+3
Replace BLK with a per device mutex. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-12-07[S390] tape: cleanup reference countingMartin Schwidefsky1-3/+3
Rename tape_get_device to tape_find_device and tape_get_device_reference to tape_get_device. The old names didn't make too much sense. Follow the get_device()/put_device() semantic and convert tape_put_device to a void function. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-06-16[S390] pm: tape power management callbacksFrank Munzert1-1/+2
Signed-off-by: Frank Munzert <munzert@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-04-23[S390] Use tape_generic_offline directly.Frank Munzert1-1/+1
tape_3590_offline and tape_34xx_offline are removed and tape_generic_offline is called directly instead. Signed-off-by: Frank Munzert <munzert@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-03-26[S390] tape message cleanupCarsten Otte1-2/+0
This is a cleanup of all the messages this driver prints. It uses the dev_message macros now. Signed-off-by: Carsten Otte <cotte@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-05-30[S390] tape: fix race with stack local wait_queue_head_t.Martin Schwidefsky1-0/+3
A wait_event call with a stack local wait_queue_head_t structure that is used to do the wake up for the wait_event is inherently racy. After the wait_event finished the wake_up call might not have completed yet. Replace the stack local wait_queue_head_t in tape_do_io and tape_do_io_interruptible with a per device wait queue. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2007-07-24[BLOCK] Get rid of request_queue_t typedefJens Axboe1-1/+1
Some of the code has been gradually transitioned to using the proper struct request_queue, but there's lots left. So do a full sweet of the kernel and get rid of this typedef and replace its uses with the proper type. Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-05-04[S390] tape: New read configuration data.Michael Holzheu1-0/+1
Instead of the deprecated read_conf_data(), implement a new function tape_3590_read_dev_chars(). Signed-off-by: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2007-02-05[S390] Add crypto support for 3592 tape devicesMichael Holzheu1-6/+16
3592 tape devices are able to write data encrpyted on tape mediums. This z/Linux device driver support includes the following functions: * ioctl to switch on/off encryption * ioctl to query encryption status of drive * ioctls to set and query key encrypting keys (kekls) * long busy interrupt handling Signed-off-by: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2006-12-08[S390] more workqueue fixes.Martin Schwidefsky1-1/+2
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel1-1/+0
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-03-24[PATCH] s390: fix endless retry loop in tape driverMichael Holzheu1-0/+1
If a tape device is assigned to another host, the interrupt for the assign operation comes back with deferred condition code 1. Under some conditions this can lead to an endless loop of retries. Check if the current request is still in IO in deferred condition code handling and prevent retries when the request has already been cancelled. Signed-off-by: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27[PATCH] s390: channel tape fixesStefan Bader1-1/+6
Tape driver fixes: - Added deferred condition handling to tape driver core. - Added ability to handle busy conditions. - Code cleanup. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+384
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!