On Wed, 22 Jul 2009, Madhavi Manchala wrote: > Dear All, > > I have gone through the file_storage gadget driver code which exists > in the drivers/usb/gadget folder. I understood the code flow a bit. > However, I did not understand about the following variable. > > fsg->next_buffhd_to_fill > > The above variable is defined in the main device structure, struct > fsg_dev. As explained in the comments "There is a variable > (fsg->next_buffhd_to_fill) that points to the next buffer head to > use". > > As explained in the comments, that was used directly from the fsg main > structure in all the functions like get_next_command, do_read, > do_write, do_verify etc. In all these functions the following > statement was used. > > bh = fsg->next_buffhd_to_fill; > where bh is a struct fsg_buffhd structure type. > > My doubt about this variable is, how it will be filled and where it > will be filled? I have used the dummy hcd driver for this. There are plenty of lines in file_storage.c of the form: fsg->next_buffhg_to_file = ... That's how the variable gets set. > I have also seen that there is a wake up call to the sleeping thread > from all the completion callback routines like bulk_out_complete, > bulk_in_complete. There is a statement like > > struct fsg_buffhd *bh = req->context; > > How can the req->context is equivalent to the struct fsg_buffhd? OR Is > there any API that passes the struct fsg_buffhd pointer to the upper > layers like dummy hcd / usb core? If you look in do_set_interface(), you'll find a line that says: bh->inreq->context = bh->outreq->context = bh; That's how req->context gets set to point to an fsg_buffhd structure. 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
