kernel.git/drivers/s390/char/tape_std.c, branch master

s390/tape: Remove tape load display support

2026-02-04T07:31:29Z

The LOAD_DISPLAY (LDD) X'9F' is still accepted by the Virtual Tape Server (VTS) but does not perform any action. Remove all functions and definitions related to this command. The tape_34xx_ioctl() function is also removed as it was mainly used to handle additional ioctl functionality. LOAD_DISPLAY was the only left case. All other ioctls are handled in tapechar_ioctl(). With LOAD_DISPLAY, the remaining definitions in asm/tape390.h are gone. Delete the file. Signed-off-by: Jan Höppner Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens

s390: Remove KMSG_COMPONENT macro

2025-11-24T10:45:21Z

The KMSG_COMPONENT macro is a leftover of the s390 specific "kernel message catalog" which never made it upstream. Remove the macro in order to get rid of a pointless indirection. Replace all users with the string it defines. In almost all cases this leads to a simple replacement like this: - #define KMSG_COMPONENT "appldata" - #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt + #define pr_fmt(fmt) "appldata: " fmt Except for some special cases this is just mechanical/scripted work. Acked-by: Thomas Richter Signed-off-by: Heiko Carstens

s390/tape: Add support for bigger block sizes

2025-10-21T08:25:55Z

The tape device type 3590/3592 and emulated 3490 VTS can handle a block size of up to 256K bytes. Currently the tape device driver is limited to a block size of 65535 bytes (64K-1). This limitation stems from the maximum of 65535 bytes of data that can be transferred with one Channel-Command Word (CCW). To work around this limitation data chaining is used which uses several CCW to transfer an entire 256K block of data. A single CCW holds a maximum of 65535 bytes of data. Set MAX_BLOCKSIZE to 262144 (= 256K) to allow for data transfers with larger block sizes. The read_block() and write_block() discipline functions calculate the number of CCWs required based on the IDAL buffer array size that was created for a given block size. If there is more than one CCW required for the data transfer, the new helper function tape_ccw_dc_idal() is used to build the data chain accordingly. The Interruption-Repsonse Block (irb) is added to the tape_request struct so that the tapechar_read/write() functions can analyze what data was read or written accordingly. Signed-off-by: Jan Höppner Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens

s390/tape: Introduce idal buffer array

2025-10-21T08:25:55Z

The tape device driver uses a single idal_buffer for I/O. While the buffer itself can be arbitrary big, the limit for data transfer for a single Channel-Command Word is at 65535 bytes (64K-1) since the count field specifying the amount of data designated by the CCW is a 16-bit unsigned value. Provide functionality that allocates an array of multiple IDAL buffer with the limitation mentioned above in mind. A call to idal_buffer_array_alloc() allocates an array with a certain amount of IDAL buffers which is determined based on the total size of @size. Each individual buffer is limited to a size of CCW_MAX_BYTE_COUNT (65535 bytes). Add helper functions that determine the size (# of elements) and the total data size covered by the array as well. Current users of the single IDAL buffer are adapted to use the new functions with one buffer to allocate. The single IDAL buffer is removed from the tape_char_data struct. Signed-off-by: Jan Höppner Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens

s390/tape: Move idal allocation to core functions

2025-10-21T08:25:55Z

Currently tapechar_check_idalbuffer() is part of tape_char.c and is used to ensure the idal buffer is big enough for the requested I/O and reallocates a new one if required. The same is done in tape_std.c when a fixed block size is set using the mtsetblk command. This is essentially duplicate code. The allocation of the buffer that is required for I/O can be considered core functionality. Move the idal buffer allocation to tape_core.c, make it generally available, and reduce code duplication. Signed-off-by: Jan Höppner Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens

s390/tape: Remove extra CCW allocation for error recovery

2025-10-21T08:25:54Z

The Read Opposite error recovery code required 2 extra CCWs to be allocated in order to transform the request. As this error recovery code for both 34xx and 3590 was removed the additional allocation isn't required anymore. Reduce it to two. Signed-off-by: Jan Höppner Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens

s390/tape: Remove 34xx Read Opposite error recovery

2025-10-21T08:25:54Z

On old native type 3490 tape devices a Read Opposite error recovery procedure on Error Recovery Action Code (ERA) 26 was issued if a Read Forward command failed. This recovery procedure was implemented with the Read Backward command. As a preparation for a subsequent commit, that adds support for bigger block sizes, remove the 34xx ERA 26 related recovery code. The recovery code would need to be adapted to the bigger block sizes, without any possibility to be tested, as modern Virtual Tape Servers (VTS) do neither report ERA 26 on a Read Forward command failure nor support the error recovery procedure anymore. Signed-off-by: Jan Höppner Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens

s390/tape: Remove count parameter from read/write_block functions

2025-10-21T08:25:54Z

The count parameter of the read/write_block discipline functions was never used. Remove it. Signed-off-by: Jan Höppner Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens

s390/drivers: Explicitly include

2025-06-17T16:18:02Z

Explicitly include in files which contain an EXPORT_SYMBOL(). See commit a934a57a42f6 ("scripts/misc-check: check missing #include when W=1") for more details. Acked-by: Alexander Gordeev Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev

treewide, timers: Rename from_timer() to timer_container_of()

2025-06-08T07:07:37Z

Move this API to the canonical timer_*() namespace. [ tglx: Redone against pre rc1 ] Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com