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 since 2.6.30. Serial drivers like ftdi_sio aren't supposed to use the interface's driver_data field. However, that doesn't matter: If the driver_data field had not been set to NULL then it would contain a pointer to the usb_serial structure -- and ftdi_sio_shutdown() is already provided with such a pointer as its argument. Since usb-serial already uses the interface's driver_data field for its own purposes, you must not store audio data there too. > So these are the questions I have: > > - Is there an easy/obvious reason, why this pointer is reset at > _shutdown, that I'm missing? Yes: Because you're not supposed to be using the pointer. > - How could I debug this? Ideally, I'd like to put a watch on > usb_serial->interface->dev->driver_data and see when it changes (and > what changes it) - but its not even a variable :) There's nothing to debug; I can tell you where the pointer is set to NULL. In usb-serial.c, near the start of usb_serial_disconnect() you'll see: usb_set_intfdata(interface, NULL); That's what does it. > I have just learned that I could recompile a kernel and use something > called kgdb, which needs two machines; I found > http://linux-hacks.blogspot.com/2008/05/setting-up-kgdb-using-kvmqemu.html > that uses a VM instead - but I'm afraid using a VM will mess up > everything USB related. Any links to some resources related to this kind > of debugging? I don't know if it was present in 2.6.30, but in more recent kernels you can look through samples/hw_breakpoint. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
