linux-kernel - Re: [patch 0/7] staging: speakup: introduce tty-based comms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 22 Mar 2017 01:05:24 +0100
From:   Samuel Thibault <samuel.thibault@...-lyon.org>
To:     Rob Herring <robh@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        okash.khawaja@...il.com, Jiri Slaby <jslaby@...e.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devel@...verdev.osuosl.org,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        Kirk Reiser <kirk@...sers.ca>,
        Chris Brannon <chris@...-brannons.com>,
        speakup@...ux-speakup.org
Subject: Re: [patch 0/7] staging: speakup: introduce tty-based comms

Hello,

So Rob, how do you see this going?  Shall we introduce a serdev_device
*tty_port_register_serdev_device(tty, device)? Will you work on it or
should I give it a try?

Samuel

Samuel Thibault, on mer. 15 mars 2017 16:03:23 +0100, wrote:
> Rob Herring, on mer. 15 mars 2017 09:45:59 -0500, wrote:
> > On Mon, Mar 13, 2017 at 8:18 PM, Samuel Thibault
> > <samuel.thibault@...-lyon.org> wrote:
> > > Samuel Thibault, on mar. 14 mars 2017 01:47:01 +0100, wrote:
> > >> Greg KH, on mar. 14 mars 2017 06:14:04 +0800, wrote:
> > >> > On Mon, Mar 13, 2017 at 10:05:51PM +0000, okash.khawaja@...il.com wrote:
> > >> > > This patchset introduces a TTY-based way for the synths to communicate
> > >> > > with devices as an alternate for direct serial comms used by the synths
> > >> > > at the moment. It then migrates some of the synths to the TTY-based
> > >> > > comms. Synths migrated in this patchset are dummy, acntsa, bns and
> > >> > > txprt.
> > >> >
> > >> > What about using the serbus code that is now in the tree?  That should
> > >> > make this a lot easier than your patchset from what I can see.
> > >>
> > >> Mmm... AIUI from reading tty_port_register_device_attr, one
> > >> would have to have registered a speakup serdev device driver
> > >> *before* tty_port_register_device_attr gets called, so that
> > >> serdev_tty_port_register matches the driver in the loop of
> > >> of_serdev_register_devices, and no TTY cdev is created?
> > 
> > Not exactly. The driver doesn't have to be registered nor loaded, but
> > the device does have to be present so no tty cdev is created. The only
> > way a device is present currently is when a node is in the DT. I
> > expect the x86 folks will be adding ACPI support soon.
> 
> Ok, but in our case there is no hardware device that the system can
> see/probe, it's just plugged externally.
> 
> > >> That would mean that speakup can not be loaded as a module after ttyS0
> > >> initialization, that won't fly for our use needs. The line discipline
> > >> mechanism allows us to attach ourself to an existing tty.  Could we
> > >> imagine a tty_port function which removes the cdev and tries to register
> > >> the tty port again to serdev?
> > >>
> > >> What we basically need to be able to say on speakup module load is
> > >> e.g. "I'm now attaching a device to ttyS0, use this serdev_device_ops to
> > >> discuss with it".
> > >
> > > That for_each_available_child_of_node loop is really way more complex
> > > than what we need.  And what's more, it's not working without CONFIG_OF
> > > (!)
> > >
> > > It would really make sense to me to have a
> > >
> > > serdev_device *tty_port_register_serdev_device(tty, device)
> > >
> > > which unregisters the character device of the tty, and creates instead a
> > > controler with the given device plugged to it. Really much like a line
> > > discipline, but way simpler :)
> > 
> > What would trigger calling this function?
> 
> From the user point of view, loading the speakup module for the external
> device, typically, with "ttyS0" as module parameter. Then the speakup
> init function can do whatever it needs to achieve this :)