usb-autoload

[Okash Khawaja]

Hi,

When we implement our usb-serial driver, how will that driver tell
speakup_ltlk etc the minor device number?

I'm assuming this scenario: no speakup module is loaded, then user plugs in
usb synth, our usb-serial driver gets loaded which finds out minor device
number, and then loads something like speakup_ltlk and passes major and
minor device number to it.

I am thinking of modifying speakup driver so that it can take in dev
parameter after it has been loaded. Is there a simpler way?

Thanks,
Okash

[Okash Khawaja]

Hi,

Post by Okash Khawaja
I am thinking of modifying speakup driver so that it can take in dev
parameter after it has been loaded. Is there a simpler way?

Here's what I am thinking for usb autoload. Let's say speakup_usb_serial
is the driver which will be automatically loaded based upon usb vendor
and product id, when user plugs in native usb synth, such as triple
talk. speakup module will be pre-requisite for speakup_usb_serial so it
will already be in memory when following flow starts from inside
speakup_usb_serial. It assumes the native usb synth requires ltlk.
Functions of the form speakup.* are those exposed by speakup module.

First speakup_usb_serial will check if ltlk is already loaded
ltlk not loaded:
1. speakup.next_load_as_delayed("ltlk"): tell speakup that very next
time when ltlk is loaded, don't initialise it, i.e. don't call
do_synth_init().
2. load ltlk
3. speakup.delayed_init("ltlk", "ttyUSBX"): tell speakup to first
set dev_name of ltlk synth to ttyUSBX and then call do_synth_init

ltlk is already loaded:
1. speakup.is_initialised("ltlk")?

Post by Okash Khawaja
do nothing as ltlk is loaded and initialised so we assume it's

being used

Post by Okash Khawaja
speakup.delayed_init("ltlk", "ttyUSBX");

This should cover the scenario when ltlk is built into kernel.

Thanks,
Okash

[Samuel Thibault]

Hello,

Post by Okash Khawaja
speakup module will be pre-requisite for speakup_usb_serial so it
will already be in memory when following flow starts from inside
speakup_usb_serial.

Right, that's a good thing indeed, because that makes a place where to
store the major/minor information.

I'd say it could be done this way:

- add dev variable to the speakup module, initialized to NULL
- when a USB speakup driver gets loaded, it sets ser and dev in the
speakup module, and then loads the driver module, and if not started
yet, starts it.
- when synth_init sees that speakup's dev variable is non-NULL, use that
instead of the module parameters.

Samuel

[Okash Khawaja]

Hi,

On Fri, Sep 1, 2017 at 12:44 AM, Samuel Thibault

Post by Samuel Thibault
Hello,

Post by Okash Khawaja
speakup module will be pre-requisite for speakup_usb_serial so it
will already be in memory when following flow starts from inside
speakup_usb_serial.

Right, that's a good thing indeed, because that makes a place where to
store the major/minor information.
- add dev variable to the speakup module, initialized to NULL
- when a USB speakup driver gets loaded, it sets ser and dev in the
speakup module, and then loads the driver module, and if not started
yet, starts it.
- when synth_init sees that speakup's dev variable is non-NULL, use that
instead of the module parameters.

Okay this is a simpler approach so I'll use it. One thing I'll add is
to also add a synth_name variable to speakup. When setting dev we also
set synth_name so that dev override doesn't happen for some other
synth module that gets accidentally loaded between us setting
speakup's dev and us loading the synth driver module. Highly unlikely
but can potentially brick a synth, e.g. during testing.

Thanks,
Okash

[Samuel Thibault]

One thing I'll add is to also add a synth_name variable to speakup.

Indeed :)

Highly unlikely

"Highly unlikely" usually means it will happen :)

Samuel, who got "highly unlikely" bugs in the face when going from 10MB
files to 10GB files :)

[Okash Khawaja]

On Fri, Sep 1, 2017 at 4:27 PM, Samuel Thibault

Post by Samuel Thibault

One thing I'll add is to also add a synth_name variable to speakup.

Indeed :)

Highly unlikely

"Highly unlikely" usually means it will happen :)
Samuel, who got "highly unlikely" bugs in the face when going from 10MB
files to 10GB files :)

Haha... seems like you need to constantly plan for bad karma.

Will keep that in mind

[Samuel Thibault]

Post by Okash Khawaja
Haha... seems like you need to constantly plan for bad karma.

Writing code for a long time clearly defines some karma. Whatever you
have put under the carpet will definitely bite someday. Hopefully not
you because you'll have flown away before it bites :)

Samuel