From what I understand and looking at the supported opcodes [0] io_uring allows submitting certain "system calls" (and some other auxiliary operations you would normally expect in an async API) asynchronously. So, if you can interact with your device driver using those system calls, then you should be able to do so. I am personally not familiar with Linux, so I am unsure if those system calls are sufficient for normal operation, but it lacks ioctl, so it is not sufficient for total replacement in all cases.
I don't know the answer to that question, but if you are developing an embedded project (and especially if it's a raspberry PI) you can mmap() the hardware I2C registers to userspace memory and use them directly.
You will have to basically write the I2C driver in userspace and it won't be portable but it's not that hard and it will make for very low latency I2C communication. I had to do this once for latency.
I don't know anything either, but I assume not? With a device driver you'd be handling interrupts directly by registering an interrupt service routine and all that good stuff. io_uring is a user->kernel API because userspace doesn't handle those interrupts directly. Instead, device driver ISRs fill buffers and what have you, then kernel notifies user via io_uring that data is ready.
As neighbour says, io_uring is for really high performance (as in high throughput) stuff, so… not I2C !
But you can still want async I/O with an I2C device, of course, as in you don't want to block a thread to wait on a message. And for that I believe you can still use good old select/epoll as usual on your I2C device file, and as a consequence also just use your favourite async I/O framework of the day (libevent, node.js, what have you).
[0]: https://github.com/torvalds/linux/blob/master/include/uapi/l... search IORING_OP_