From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: okash.khawaja@gmail.com
Cc: Jiri Slaby <jslaby@suse.com>,
Samuel Thibault <samuel.thibault@ens-lyon.org>,
linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
Kirk Reiser <kirk@reisers.ca>,
speakup@linux-speakup.org, alan@linux.intel.com,
Chris Brannon <chris@the-brannons.com>
Subject: Re: [patch 1/7] tty_port: allow a port to be opened with a tty that has no file handle
Date: Tue, 14 Mar 2017 06:12:47 +0800 [thread overview]
Message-ID: <20170313221247.GA22823@kroah.com> (raw)
In-Reply-To: <20170313220926.390471547@gmail.com>
On Mon, Mar 13, 2017 at 10:05:52PM +0000, okash.khawaja@gmail.com wrote:
> Allow access to TTY device from kernel. This is based on Alan Cox's patch
> (http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1215095.html),
> with description quoted below.
>
> "tty_port: allow a port to be opened with a tty that has no file handle
>
> Let us create tty objects entirely in kernel space.
>
> With this a kernel created non file backed tty object could be used to handle
> data, and set terminal modes. Not all ldiscs can cope with this as N_TTY in
> particular has to work back to the fs/tty layer.
>
> The tty_port code is however otherwise clean of file handles as far as I can
> tell as is the low level tty port write path used by the ldisc, the
> configuration low level interfaces and most of the ldiscs.
>
> Currently you don't have any exposure to see tty hangups because those are
> built around the file layer. However a) it's a fixed port so you probably
> don't care about that b) if you do we can add a callback and c) you almost
> certainly don't want the userspace tear down/rebuild behaviour anyway.
>
> This should however be sufficient if we wanted for example to enumerate all
> the bluetooth bound fixed ports via ACPI and make them directly available.
>
> It doesn't deal with the case of a user opening a port that's also kernel
> opened and that would need some locking out (so it returned EBUSY if bound
> to a kernel device of some kind). That needs resolving along with how you
> "up" or "down" your new bluetooth device, or enumerate it while providing
> the existing tty API to avoid regressions (and to debug)."
>
> Signed-off-by: Okash Khawaja <okash.khawaja@gmail.com>
>
> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
You do know this is already in 4.11-rc1, right? Please rebase your
patch set on 4.11-rc2 at the least and resend.
thanks,
greg k-h
next prev parent reply other threads:[~2017-03-13 22:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-13 22:05 [patch 0/7] staging: speakup: introduce tty-based comms okash.khawaja
2017-03-13 22:05 ` [patch 1/7] tty_port: allow a port to be opened with a tty that has no file handle okash.khawaja
2017-03-13 22:12 ` Greg Kroah-Hartman [this message]
2017-03-13 22:38 ` Okash Khawaja
2017-03-14 9:14 ` Dan Carpenter
2017-03-13 22:05 ` [patch 2/7] staging: speakup: spk_serial_out and spk_wait_for_xmitr to take synth arg okash.khawaja
2017-03-13 22:05 ` [patch 3/7] staging: serial: add spk_io_ops struct to spk_synth okash.khawaja
2017-03-13 22:05 ` [patch 4/7] staging: speakup: move spk_stop_serial_interrupt into synth-specific release function okash.khawaja
2017-03-13 22:05 ` [patch 5/7] staging: speakup: move those functions which do outgoing serial comms, into serialio.c okash.khawaja
2017-03-13 22:05 ` [patch 6/7] staging: speakup: add tty-based comms functions okash.khawaja
2017-03-13 22:05 ` [patch 7/7] staging: speakup: migrate acntsa, bns, dummy and txprt to ttyio okash.khawaja
2017-03-13 22:14 ` [patch 0/7] staging: speakup: introduce tty-based comms Greg Kroah-Hartman
2017-03-13 22:26 ` Samuel Thibault
2017-03-13 23:43 ` Greg Kroah-Hartman
2017-03-13 23:49 ` Samuel Thibault
2017-03-14 0:00 ` Samuel Thibault
2017-03-14 0:47 ` Samuel Thibault
2017-03-14 1:18 ` Samuel Thibault
2017-03-15 14:45 ` Rob Herring
2017-03-15 15:03 ` Samuel Thibault
2017-03-22 0:05 ` Samuel Thibault
2017-04-09 16:54 ` Okash Khawaja
2017-03-16 9:26 ` Samuel Thibault
2017-03-14 0:24 ` Samuel Thibault
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170313221247.GA22823@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alan@linux.intel.com \
--cc=chris@the-brannons.com \
--cc=devel@driverdev.osuosl.org \
--cc=jslaby@suse.com \
--cc=kirk@reisers.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=okash.khawaja@gmail.com \
--cc=samuel.thibault@ens-lyon.org \
--cc=speakup@linux-speakup.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).