First of all, make it return int. Returning long when native method
had never allowed that is ridiculous and inconvenient.
More importantly, change the caller; if ldisc ->compat_ioctl() is NULL
or returns -ENOIOCTLCMD, tty_compat_ioctl() will try to feed cmd and
compat_ptr(arg) to ldisc's native ->ioctl().
That simplifies ->compat_ioctl() instances quite a bit - they only
need to deal with ioctls that are neither generic tty ones (those
would get shunted off to tty_ioctl()) nor simple compat pointer ones.
Note that something like TCFLSH won't reach ->compat_ioctl(),
even if ldisc ->ioctl() does handle it - it will be recognized
earlier and passed to tty_ioctl() (and ultimately - ldisc ->ioctl()).
For many ldiscs it means that NULL ->compat_ioctl() does the
right thing. Those where it won't serve (see e.g. n_r3964.c) are
also easily dealt with - we need to handle the numeric-argument
ioctls (calling the native instance) and, if such would exist,
the ioctls that need layout conversion, etc.
All in-tree ldiscs dealt with.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
the only user is very old setserial rc script and even that
(as far back as MCC Interim, AFAICS) doesn't actually fail -
just gives one message during the boot ("Cannot scan for wild
interrupts") and proceeds past that just fine.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
for pity sake, that case is identical to their default: _and_ bears
an explicit comment re leaving to ldisc. Which is what default is
doing, obviously...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
TIOCLINUX is handled by ->compat_ioctl() in the only place that has
native ->ioctl() recognizing it, TIOC{START,STOP} are simply useless
these days - unrecognized compat ioctl won't spew into syslog
anymore.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
bury the dead code (and ->tiocmget()/->tiocmset() are there, so I really
wonder why have they kept the stuff that became unreachable with the
introduction of those...)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
kill the long-dead code - it's been unreachable since 2008. Redundant, as
well - generic will do exact same thing, since ->break_ctl is NULL here...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
it's never getting called with TIOC[SG]SERIAL anymore (nor has
it ever supported those, while we are at it)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
... and fix the return value - on success it used to have ioctl(2)
fill the user-supplied struct serial_struct and return -ENOTTY.
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
add such methods for usb_serial_driver, provide tty_operations
->[sg]et_serial() calling those. For now the lack of methods
in driver means ENOIOCTLCMD from usb-serial ->[sg]et_serial(),
making tty_ioctl() fall back to calling ->ioctl(). Once all
drivers are converted, we'll be returning -ENOTTY instead,
completing the switchover.
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Pointless dead assignments in moxa_set_serial_info() killed off;
they would've been a bug, if not for the fact that user-settable
flags had never been used in that driver. Bogus from day 1,
though...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
These ioctls never reach driver's ->ioctl() - tty_ioctl() handles
them on its own. ->tiocm[gs]et() is what actually gets called,
and mos7720 provides those, with results equivalent to what the
unreachable code would be doing when called.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
That code had been live for 11 weeks back in 1992, but it had been 26 years
since sys_ioctl() began handling FIONBIO on its own. Time to to bury the body,
already...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
