wishbone.c: change read/write_iter() for post-5.19 kernels

If user spaces calls read(2), the vfs_read() in fs/read_write.c
does not create an iov array any more since v5.19-10288-g3e20a751aff0.

That commit does as follows:

   -       struct iovec iov = { .iov_base = buf, .iov_len = len };
   -       iov_iter_init(&iter, READ, &iov, 1, len);
   +       iov_iter_ubuf(&iter, READ, buf, len);

as a resuly, our code that checks iter->iov->nr_segs sees 0 segments,
understands we have no buffer, and returns 0. Same for write(2).

This is a hack, as I don'w know what happens if the user space uses readv/writev.
Actually, I'd better have a simple fops->read() and fops->write() in the driver,
but I'm sure I lack a lot of background knowledge here.

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

pcie-wb/wishbone.c

@@ -609,7 +609,31 @@ static int char_master_fasync(int fd, struct file *file, int on)
         return fasync_helper(fd, file, on, &context->fasync);
 }
 
-#if LINUX_VERSION_CODE > KERNEL_VERSION(4,1,0)
+#if LINUX_VERSION_CODE > KERNEL_VERSION(5,19,0)
+/*
+ * Commit v5.19-10288-g3e20a751aff0, implementing read(2), removed
+ * initialization of iter->iov (and thus iter->nr_segs). Put it back.
+ * This is a hack, as I imagine there was a reason for the change (ARub).
+ */
+static ssize_t char_master_aio_read_iter(struct kiocb *iocb,
+					 struct iov_iter *iter)
+{
+	/* From new_sync_read before v5.19-10288-g3e20a751aff0 */
+	struct iovec iov = { .iov_base = iter->ubuf, .iov_len = iter->count };
+
+	return char_master_aio_read(iocb, &iov, 1, 0);
+}
+
+static ssize_t char_master_aio_write_iter(struct kiocb *iocb,
+					  struct iov_iter *iter)
+{
+	/* From new_sync_write before v5.19-10288-g3e20a751aff0 */
+	struct iovec iov = { .iov_base = iter->ubuf, .iov_len = iter->count };
+
+	return char_master_aio_write(iocb, &iov, 1, 0);
+}
+
+#elif LINUX_VERSION_CODE > KERNEL_VERSION(4,1,0)
 
 static ssize_t char_master_aio_read_iter(struct kiocb *iocb, struct iov_iter *iter)
 {