[PATCH 0/5] staging: speakup: replace serial comms with tty io

[PATCH 0/5] staging: speakup: replace serial comms with tty io

[Okash Khawaja]

Hi,

Sending these as a series of patches. After applying all,
speakup_dummy should use tty to write out on /dev/ttyS0. Other drivers
should function the same way they did before applying. Please test
what you can.

Thanks,
Okash

Re: [PATCH 0/5] staging: speakup: replace serial comms with tty io

[Samuel Thibault]

Okash Khawaja, on Wed 08 Feb 2017 22:43:07 +0000, wrote:
> Sending these as a series of patches. After applying all,
> speakup_dummy should use tty to write out on /dev/ttyS0. Other drivers
> should function the same way they did before applying. Please test
> what you can.

This is fine enough for the speakup mailing, but for actual submission
you will need a different text :)

Basically you'll have to give the overall rationale: again briefly
explain that speakup used to poke ports by hand, and this patchset
migrates it to using the proper TTY subsystem, and give the list of
patches with a couple of words to say which does what: add what's needed
in TTY, introduce methods to finish abstracting away serial port access
from drivers, addi a speakup line discipline, and migrate drivers to it.

Samuel

Re: [PATCH 0/5] staging: speakup: replace serial comms with tty io

[Samuel Thibault]

Hello,

Okash Khawaja, on Wed 08 Feb 2017 22:43:07 +0000, wrote:
> Please test what you can.

I'd say you should also add to your series a patch which migrates all
drivers for which it makes sense (no use of serial input, no internal
port knocking), so that people can just apply the series and see their
own driver use the tty ops.

Samuel

Re: [PATCH 0/5] staging: speakup: replace serial comms with tty io

[Okash Khawaja]

Hi,

> On 9 Feb 2017, at 10:20, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> 
> Hello,
> 
> Okash Khawaja, on Wed 08 Feb 2017 22:43:07 +0000, wrote:
>> Please test what you can.
> 
> I'd say you should also add to your series a patch which migrates all
> drivers for which it makes sense (no use of serial input, no internal
> port knocking), so that people can just apply the series and see their
> own driver use the tty ops.
> 
> Samuel

Sounds good. On it now

Re: [PATCH 0/5] staging: speakup: replace serial comms with tty io

[Okash Khawaja]

Hi,

> On 9 Feb 2017, at 10:20, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> 
> Hello,
> 
> Okash Khawaja, on Wed 08 Feb 2017 22:43:07 +0000, wrote:
>> Please test what you can.
> 
> I'd say you should also add to your series a patch which migrates all
> drivers for which it makes sense (no use of serial input, no internal
> port knocking),

Can you briefly explain internal port knocking in speakup? Are these the synths which use synth_portlist array?

Thanks

Re: [PATCH 0/5] staging: speakup: replace serial comms with tty io

[Samuel Thibault]

Okash Khawaja, on Mon 13 Feb 2017 13:12:57 +0000, wrote:
> > On 9 Feb 2017, at 10:20, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> > Okash Khawaja, on Wed 08 Feb 2017 22:43:07 +0000, wrote:
> >> Please test what you can.
> > 
> > I'd say you should also add to your series a patch which migrates all
> > drivers for which it makes sense (no use of serial input, no internal
> > port knocking),
> 
> Can you briefly explain internal port knocking in speakup? Are these the synths which use synth_portlist array?

They are often called somethingpc, for instance acntpc. You can see
there that it uses in/out calls (inb, inw, outb, outw). They may indeed
use their own synth_portlist to provide non-standard adresses to use,
but that's not necessarily the case.

I can see at least acntpc, apollo, audptr, decext, decpc, dtlk, keypc,
spkout which seem to be using them. You can find just a little more
information on these in speakup/doc/spkguide.txt and.

For the pc ones, I'm not surprised. For decext for instance, it's
more surprising: AIUI it's an external device. It probably just needs
to be migrated to using spk_serial_in_nowait. apollo seems to be
manipulating the modem control lines (DTR and RTS), we'd need to add
serialio/ttyio methods for that too.  I'm also noticing that there is a
spk_serial_tx_busy() macro that some are using. That will perhaps need
to be replaced by some tty ops, depending whether the models which are
behind are actually external or internal.  In all cases, ideally you'd
find a user on this list that could test patches. Personally, I can only
test the ltlk driver, which doesn't seem to need patching.

So, to sum it up, I'd say for now make your patch migrate the drivers
which are know not to use inb/inw/outb/outw*, spk_serial_tx_busy,
spk_serial_in*.

Then for those drivers which do use them, ask on this list whether
people have them to test patches to make them migrate to proper
serialio/ttyio methods, each of them needing careful inspection of what
it is actually doing. But that can be done later; at least having a
first list of drivers migrated will be plenty.

Samuel