| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
| |
dasd driver changes:
- The feature check in dasd_generic_online returns an error if
the devmap entry for the device is not yet available. Check
for the feature after the device has been created.
- Do symmetric registration/deregistration of cdev->handler.
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>
|
|
|
|
|
|
|
|
|
| |
The ioctl32_conversion routines will be deprecated: Remove them from dasd_cmb
and handle the three cmb ioctls like all other dasd ioctls.
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>
|
|
|
|
|
|
|
|
|
|
|
| |
The first blocks on a cdl formatted dasd device are smaller than the blocksize
of the device. Read requests are padded with a 'e5' pattern. Write requests
should not pad the (user) buffer with 'e5' because a write request is not
allowed to modify the buffer.
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>
|
|
|
|
|
|
|
|
|
|
|
| |
The DASD device driver never reorders the I/O requests and relies on the
hardware to write all data to nonvolatile storage before signaling a
successful write. Hence, the only thing we have to do to support write
barriers is to set the queue ordered flag.
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>
|
|
|
|
|
|
|
|
|
|
| |
The independent read-only flags in devmap, dasd_device and gendisk are not
kept in sync. Use one bit per feature in the dasd driver and keep that bit in
sync with the gendisk bit.
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>
|
|
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!
|