Polling a Loop Device Through a Kernel Module

Emitting a poll/select event from a timer handler through a wait queue

Call wake_up_interruptible() on the polled queue just force the .poll method to be called again. User space process receive notification only when .poll method returns mask which have polled bits set.

Check that your .poll method actually returns non-zero mask.

Reading a device from kernel interrupt

After reading the answer of @VivekS in this post I took a look at Linux Device Drivers, chapter 10, which states:

A handler can't transfer data to or from user space, because it
doesn't execute in the context of a process. Handlers also cannot do
anything that would sleep, such as calling wait_event, allocating
memory with anything other than GFP_ATOMIC, or locking a semaphore.
Finally, handlers cannot call schedule.

Using select()/poll() in device driver

You may want to write your own custom sk_buff handler, which calls the kernel_select() that tries to lock the semaphore and does a blocking wait when the socket is open.

Not sure if you have already gone through this link Simulate effect of select() and poll() in kernel socket programming

linux device driver select/epoll support

Yes, the kernel will loop through all the file descriptors and call the poll() method. It needs to sample the current state of all the file descriptors in order to report them back to the caller in userspace.

Note, that this is true for select and poll, I'm not familiar with epoll, but if it uses the same file op, then it should apply here as well.

Writing to Linux device driver causes infinite loop

I think the kernel write operation is supposed to return the number of bytes written. You return 0. So the write system call returns to userspace with 0. However, since your userspace code is using stdio, then your userspace code tries the write again, assuming the system call simply didn't write out all the data. If you return the length of the input, then stdio will know all the data was written. Alternatively you can use the write system call directly rather than fputs. Your kernel code will still be incorrect, but your program will terminate.
You can test this using strace and see all the system calls.