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@xxxxxxxxx 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? > > 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 :) The issue that remains is the "tty" part: we'd need there the tty_port, the parent device, the tty driver, the idx. All we know when we load speakup is "ttyS0". That's where going through the cdev to attach a line discipline was simpler :) Samuel _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel