Hello,
To use usb-skeleton.c as module we create its .ko file and using insmod we are able to insert as module and can see it in lsmod but it is not generate /dev/skel0.
We insert some print strings in skel_probe function but that string is not print when we call insmod or modprobe. Also check in dmesg, only message “usbcore: registered new interface driver skeleton” shown.
How can we get /dev/skel0 ?
Did you write the __init and __exit code? If not, then that isn’t for module format. See:
https://www.tldp.org/LDP/lkmpg/2.6/lkmpg.pdf
I haven’t used that particular file, but if you do a recursive grep you’ll find some drivers are based on this file (from the “kernel/drivers/usb/” directory):
egrep -R usb-skeleton.c *
I see “drivers/usb/misc/usblcd.c” is one of them. However, I don’t see “__init” there. If you go to the “Documentation/DocBook/writing_usb_driver.tmpl” file, and search for “__init”, you’ll find some sample init code.
Loading as a module does not create a working module. You must add what is essentially constructor and destructor code. Otherwise you have code which never executes.
Thanks for your reply.
usb-skeleton.c dosen’t have that init & exit functionality. We include that functions and also able to get Initialization success message & “usbcore: registered new interface driver skeleton” in dmesg. But even after that initialization we are not get messages print in probe function it means probe function is not called.
Also using egrep command we are able to find all usb-skeleton related files.
We took two different test with default VID-0xfff0, PID-0xfff0 & VID-0x0955, PID-0x7020 of Nvidia.
What could be the reason of probe function is still not called?
We also disabled usb-storage driver and inserted usb-skeleton.ko still the probe function of skeleton driver is not getting called.
Is any other driver is interfering skeleton driver? if so how to point out interfering driver?
Whether any further step or procedure required to such that probe functionality is called?
I am only guessing, but since this is USB something must associate a device being plugged in to that driver before the code (other than registering existence) will run and produce the device special file. Take a look at some of the other drivers which use the skeleton, and see how they associate a idProduct/idVendor combination. Take a look at which ID shows up for your device under lsusb. Make sure that association is present.
An example of brief listing of all USB devices:
lsusb
An example is that a TX2 in recovery mode shows up from (limiting to one device by ID):
lsusb -d 0955:7c18
The lsusb response for this example would have “0955:7c18” in it, and a verbose query with sudo would show idVender 0x0955 and idProduct 0x7c18. This is a special case for the TX2 in recovery mode, and there won’t be any kernel driver found (indeed, the “driver package” is user space, and is what flashes a Jetson). Some devices report as a generic class, and won’t use a custom driver; other devices work only with custom devices; a large number of physical devices are actually multiple logical devices using the same cable, and those might use both generic and custom drivers (a programmable keyboard or mouse is an example…they can be used by standard generic class drivers, but programming requires a custom driver).
For the above example, if you wanted a verbose mode listing, then you’d extend the command like this:
<b>sudo</b> lsusb -d 0955:7c18 <b>-vvv</b>
What is the full verbose lsusb of the device you want the driver to trigger? You can attach this as a file to an existing post…if you hover the mouse over the “pencil” icon for editing your post, then a paper clip icon also shows up…and with that you can attach. Or just copy and paste and use the “code” (“</>”) formatting.