Hi Michael, thanks for the reply. My gadget-driver is actually an almost copy of drivers/usb/gadget/function/f_serial.c, except that the above TTY-layer has been removed. I wrote this driver for my learning, to learn simply sending/receiving of bytes using a host-driver as the peer. This test-driver of mine loads/works/communicates fine if * I load my test-driver, exposing *gser* function. * I load the gadget using *gser* function. However, if * I change the exposed function to something like *ajaytest* in my test-driver. * Then load the driver (successfully). * Then try loading the gadget using *ajaytest* function, the gadget fails to load, saying "Function not found". Let me see if I can post my code, probably on github, for a better public-view. On Fri, Sep 17, 2021 at 7:47 PM Michael Sweet <msweet@xxxxxxxxxx> wrote: > > Ajay, > > It is really hard to help further without seeing source code... > > I assume you've verified that your gadget driver module is loaded? > > And in your code: > > - Did you use the MODULE_LICENSE, MODULE_AUTHOR, and MODULE_DESCRIPTION macros to define your driver metadata? > - Did you use the module_init and module_exit macros? > > > > On Sep 15, 2021, at 9:51 AM, Ajay Garg <ajaygargnsit@xxxxxxxxx> wrote: > > > > Any pointers, please? > > > > On Sat, 11 Sep 2021, 20:28 Ajay Garg, <ajaygargnsit@xxxxxxxxx> wrote: > > Hi Michael, > > > > Thanks for the reply. > > > > I am a bit of old-school, and would prefer things in one place only > > (in the kernel) :) > > Thus : > > > > a) > > I wish to have all the endpoints configuration/management in the > > kernel only (like done in drivers/usb/gadget/function/f_serial.c, > > drivers/usb/gadget/function/u_serial.c). > > > > b) > > Only the attributes like vendorId/productId would be in configfs, to > > help setup the device. > > > > c) > > No user-space management of kernel objects. > > > > > > Either-way, I think that my issue of "function exposure" would remain > > the same, irrespective of whether we use configfs for managing the > > kernel-objects (please correct me if I am wrong). > > > > > > Thanks again for your time, look forward to listening back ! > > > > > > Thanks and Regards, > > Ajay > > > > On Sat, Sep 11, 2021 at 8:01 PM Michael Sweet <msweet@xxxxxxxxxx> wrote: > > > > > > Ajay, > > > > > > Quick question (as someone who has been down this road), do you need to do a kernel driver or could you just use the functionfs support to implement everything in userspace? I found that path to be much easier and less error-prone (and one of these days I'm going to be contributing some documentation changes to make some things clearer...) and I was able to get my IPP-USB implementation up and running very quickly. > > > > > > > > > > On Sep 11, 2021, at 1:43 AM, Ajay Garg <ajaygargnsit@xxxxxxxxx> wrote: > > > > > > > > Hi All. > > > > > > > > As a first step, I have been able to load a gadget on configfs, which > > > > binds to the function "gser" (thus loading up the usb_f_serial module > > > > when the gadget mounts). Things work well till here. > > > > > > > > Now, I have written a brand-new gadget-side device-driver, trying to > > > > create a new function "gusb", via DECLARE_USB_FUNCTION_INIT. > > > > However, now when I try to load the gadget for binding to "gusb", I > > > > get the error that the function cannot be found. > > > > > > > > Seems that firing up a new gadget-side driver, that registers a new > > > > function via DECLARE_USB_FUNCTION_INIT, is not enough to make the new > > > > function visible across the kernel. > > > > > > > > Kindly let know what I am missing. > > > > Will be grateful for pointers. > > > > > > > > > > > > Thanks and Regards, > > > > Ajay > > > > > > > > > > ________________________ > > > Michael Sweet > > > > > > > > > > > ________________________ > Michael Sweet > > >
