So, this is really precious.  You told me I didn't understand how
tty_clk works, so I reread it *again*, informed you that in fact it
does work the way I said it did (calling the scheduler from the input
routine), and now you're changing your argument to effectively say
that you want to change tty_clk as well.  Frankly, this smacks of
severe dishonesty; when you are proven wrong, you just post facto
change your argument.

And actually, I think this is even worse.  Now you're not only talking
about a special-case hack to short-circuit the internal queue, but
also another special-case hack to wake up processes waiting for input,
which until now has never been done outside the line discipline.  The
hacks just pile up.  You're clearly not interested in using any of the
existing internal structure of the driver, so there really isn't any
reason to put this stuff into the driver at all.  Write a seperate
one.

There are of course other ways to accomplish this, with lower design
impact.  One possibility is to just have a mode that records in the
data stream either absolute time stamps or the interval between
characters.  Both tty_chu and tty_clk (and presumably any other
similar protocol) want these timestamps anyway; the only extra
overhead here is the packing and unpacking of them from the data
stream.  It also adds minimal overhead in the non-clock case and keeps
the existing queue mechanism intact.  It's also similar to what the
FreeBSD people are doing for serial clocks with TIOCTIMESTAMP, except
that they store the time stamps out of band.  (AFAICT from looking at
their source tree, they are *not* using the line disciplines.)