nwbutton: lost wakeup in button_read() -- worth fixing, or is this driver done?

[old king]

Hi,

button_read() in drivers/char/nwbutton.c sleeps unconditionally: nothing is
tested before schedule(), not even whether the buffer is empty. If
button_sequence_finished() wakes button_wait_queue in the window between
read() being entered and prepare_to_wait() queuing the reader, that wakeup
is lost and the reader sleeps until some later, unrelated button sequence
completes. The race predates commit eb831743f2b4, whose changelog already called
the code "inherently racy". I have reproduced it under QEMU and prepared a fix:
a sequence counter captured before queuing and re-checked after.

Before I send that: is this driver still worth fixing? footbridge is
deprecated and its Kconfig says support goes away in 2027 unless remaining
users speak up. Every change to nwbutton.c in git history has been a
treewide cleanup rather than anything a user asked for, and
button_add_callback()/button_del_callback() have no callers in the tree. I
have no NetWinder hardware and no way to tell whether anyone else does.

The lost wakeup is also not the only problem. The same seven-line read()
ignores the caller's count -- read(fd, buf, 0) returns 2 and writes two
bytes -- and never checks signal_pending() after schedule(), so a signal
returns the previous sequence's data instead of -EINTR. I verified both
under QEMU as well, but in a single run only -- unlike the wakeup, I have
not repeated them independently.

Should I send fixes, or a patch removing the driver? Happy to write either.

Best regards,
Fan Ye