sdaau | 20 Apr 17:45 2010
Picon
Picon

ftdi_sio, and usb_serial->interface->dev->driver_data being null

Hi all,

I am trying to learn more about interfacing with FT232, and I started 
with ftdi_sio.c as a base, and my final goal is being able to interface 
with snd_pcm and ALSA (and I'm trying to use usbaudio functions as 
examples).

For that purpose, I am trying to build a module, where a modification of 
ftdi_sio.c is one object, and another .c file with corresponding ALSA 
functions is another object built into this module. Needless to say, I'm 
quite struggling to keep all the structs involved in mind :)

For now, I just want to come to the point where probe and disconnect 
work. I have tried to add additional commands to ftdi_sio_probe and 
ftdi_shutdown, so functions (my_extra_probe and my_extra_disconnect) in 
the other .c file get called.

Probe seems to work fine (i.e. a new card can be seen in cat 
/dev/sndstat), however, it is the disconnect I have a problem with. The 
problem is that in ftdi_sio_probe, after my_extra_probe, what 
corresponds to usb_serial->interface->dev->driver_data is a valid 
pointer -- however, whenever ftdi_shutdown is called, this 
...->driver_data is always a null pointer (even if ftdi_open was never 
called). Unfortunately, the functions from usbaudio are using precisely 
this "property" to proceed with deregistering. Below is a snippet from 
these two functions:

---
/* Probe function to check for special devices */
static int ftdi_sio_probe(struct usb_serial *serial,
(Continue reading)

Greg KH | 20 Apr 18:36 2010

Re: ftdi_sio, and usb_serial->interface->dev->driver_data being null

On Tue, Apr 20, 2010 at 05:45:44PM +0200, sdaau wrote:
> Hi all,
>
> I am trying to learn more about interfacing with FT232, and I started with 
> ftdi_sio.c as a base, and my final goal is being able to interface with 
> snd_pcm and ALSA (and I'm trying to use usbaudio functions as examples).

A usb serial audio device?  Huh?  That doesn't sound correct at all.

> For that purpose, I am trying to build a module, where a modification of 
> ftdi_sio.c is one object, and another .c file with corresponding ALSA 
> functions is another object built into this module. Needless to say, I'm 
> quite struggling to keep all the structs involved in mind :)

What exacly are you trying to do here that you would need to modify both
of these drivers?

> For now, I just want to come to the point where probe and disconnect work. 
> I have tried to add additional commands to ftdi_sio_probe and 
> ftdi_shutdown, so functions (my_extra_probe and my_extra_disconnect) in the 
> other .c file get called.
>
> Probe seems to work fine (i.e. a new card can be seen in cat /dev/sndstat), 
> however, it is the disconnect I have a problem with. The problem is that in 
> ftdi_sio_probe, after my_extra_probe, what corresponds to 
> usb_serial->interface->dev->driver_data is a valid pointer -- however, 
> whenever ftdi_shutdown is called, this ...->driver_data is always a null 
> pointer (even if ftdi_open was never called). Unfortunately, the functions 
> from usbaudio are using precisely this "property" to proceed with 
> deregistering. Below is a snippet from these two functions:
(Continue reading)

Alan Stern | 20 Apr 19:07 2010
Picon

Re: ftdi_sio, and usb_serial->interface->dev->driver_data being null

On Tue, 20 Apr 2010, sdaau wrote:

> Hi all,
> 
> I am trying to learn more about interfacing with FT232, and I started 
> with ftdi_sio.c as a base, and my final goal is being able to interface 
> with snd_pcm and ALSA (and I'm trying to use usbaudio functions as 
> examples).
> 
> For that purpose, I am trying to build a module, where a modification of 
> ftdi_sio.c is one object, and another .c file with corresponding ALSA 
> functions is another object built into this module. Needless to say, I'm 
> quite struggling to keep all the structs involved in mind :)
> 
> For now, I just want to come to the point where probe and disconnect 
> work. I have tried to add additional commands to ftdi_sio_probe and 
> ftdi_shutdown, so functions (my_extra_probe and my_extra_disconnect) in 
> the other .c file get called.
> 
> Probe seems to work fine (i.e. a new card can be seen in cat 
> /dev/sndstat), however, it is the disconnect I have a problem with. The 
> problem is that in ftdi_sio_probe, after my_extra_probe, what 
> corresponds to usb_serial->interface->dev->driver_data is a valid 
> pointer -- however, whenever ftdi_shutdown is called, this 
> ...->driver_data is always a null pointer (even if ftdi_open was never 
> called). Unfortunately, the functions from usbaudio are using precisely 
> this "property" to proceed with deregistering. Below is a snippet from 
> these two functions:

You must be using a rather old kernel.  ftdi_shutdown hasn't existed 
(Continue reading)

sdaau | 20 Apr 22:55 2010
Picon
Picon

Re: ftdi_sio, and usb_serial->interface->dev->driver_data being null

Hi guys,

Thanks so much for your quick and prompt answers!

 >
 > A usb serial audio device?  Huh?  That doesn't sound correct at all.
 >

Nope, I'm aware it doesn't :) But, again - I'm trying to learn more 
about sound drivers, and since I have an FT232 based device, I took it 
up as a learning challenge to have this device appear as a sound-card - 
and possibly be able to play back/capture data received from FT232 on PC 
speakers.

Even from my very limited understanding, I get that is generally not a 
good plan - since FT232 supports only bulk transport, and I understand 
for streaming data I'd want isochronous. But if I could get the device 
to appear as a soundcard, and play back some data received from FT232 - 
even with drops/retransmits and such - my learning goal is achieved :)

>
> What exacly are you trying to do here that you would need to modify both
> of these drivers?
>
 >
 > I'm missing the connection between these two drivers.
 >

Well, I tried first by building based on usb-skeleton, and indeed I 
could both read and write data to FT232 - but only after I executed stty 
(Continue reading)

Gregg Levine | 22 Apr 08:54 2010
Picon

Re: ftdi_sio, and usb_serial->interface->dev->driver_data being null

On Tue, Apr 20, 2010 at 4:55 PM, sdaau <sd@...> wrote:
> Hi guys,
>
> Thanks so much for your quick and prompt answers!
>
>>
>> A usb serial audio device?  Huh?  That doesn't sound correct at all.
>>
>
> Nope, I'm aware it doesn't :) But, again - I'm trying to learn more about
> sound drivers, and since I have an FT232 based device, I took it up as a
> learning challenge to have this device appear as a sound-card - and possibly
> be able to play back/capture data received from FT232 on PC speakers.
>
> Even from my very limited understanding, I get that is generally not a good
> plan - since FT232 supports only bulk transport, and I understand for
> streaming data I'd want isochronous. But if I could get the device to appear
> as a soundcard, and play back some data received from FT232 - even with
> drops/retransmits and such - my learning goal is achieved :)
>
>>
>> What exacly are you trying to do here that you would need to modify both
>> of these drivers?
>>
>>
>> I'm missing the connection between these two drivers.
>>
>
> Well, I tried first by building based on usb-skeleton, and indeed I could
> both read and write data to FT232 - but only after I executed stty (that is,
(Continue reading)

sdaau | 22 Apr 09:03 2010
Picon
Picon

Re: ftdi_sio, and usb_serial->interface->dev->driver_data being null

Hi Gregg,

Thanks for your mail!

> Is this being done for fun? (Which I can certainly understand!) Or
> is it being done as a part of a requirement for school work?
>

It is a part of my academic research (so I guess it fails under school
work in some sense - though of graduate character :) - although I tried 
to choose my academic topics based on what I consider "fun" :) )

> I ask this because during the time that I've been associated with
> Linux, going on about eleven years now I have encountered some
> unusual applications. And as it happens yours is one of the better
> ones.
>
> Would it be possible to try out your last known working code solution
> here?
>

Unfortunately, I haven't gone beyond the "probe" and "disconnect" - and 
as you can see, I got stuck at "disconnect" :)

In any case, I intend to release the code GPL once it gets done (and 
write a paper as well) so I'll post here as soon as I got close to 
anything resembling working code :)

Cheers!

(Continue reading)


Gmane