According to the VT220 specification the possible character combinations sent on RETURN are only CR or CRLF [0]. The Return key sends either a CR character (0/13) or a CR character (0/13) and an LF character (0/10), depending on the set/reset state of line feed/new line mode (LNM). The sclip/vt220 driver however uses LFCR. This can confuse tools, for example the kunit runner. Link: https://vt100.net/docs/vt220-rm/chapter3.html#S3.2 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@xxxxxxxxxxxxxxx Signed-off-by: Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxxxx> --- I'm not entirely sure that SCLP is meant to follow the VT220 standard here. The only other reference observation I found is the QEMU code and they are doing "what Linux does". It would also be possible to hack around this in the kunit runner. --- drivers/s390/char/sclp_vt220.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/s390/char/sclp_vt220.c b/drivers/s390/char/sclp_vt220.c index 218ae604f737ff9e20764ebce857ce427e4a7c44..33b9c968dbcba6584015d70a8500f9f5f70227db 100644 --- a/drivers/s390/char/sclp_vt220.c +++ b/drivers/s390/char/sclp_vt220.c @@ -319,7 +319,7 @@ sclp_vt220_add_msg(struct sclp_vt220_request *request, buffer = (void *) ((addr_t) sccb + sccb->header.length); if (convertlf) { - /* Perform Linefeed conversion (0x0a -> 0x0a 0x0d)*/ + /* Perform Linefeed conversion (0x0a -> 0x0d 0x0a)*/ for (from=0, to=0; (from < count) && (to < sclp_vt220_space_left(request)); from++) { @@ -328,8 +328,8 @@ sclp_vt220_add_msg(struct sclp_vt220_request *request, /* Perform conversion */ if (c == 0x0a) { if (to + 1 < sclp_vt220_space_left(request)) { - ((unsigned char *) buffer)[to++] = c; ((unsigned char *) buffer)[to++] = 0x0d; + ((unsigned char *) buffer)[to++] = c; } else break; -- 2.47.0
