stl,
Perhaps the people on the USB list might be more helpful since that would
be about the USB subsystem. I can give you some general ideas though.
I'm assuming you're talking about a USB device driver, not a USB chipset
driver.
I'd guess the info you found was correct, as the actual usb docs state
(linux/Documentation/usb/callbacks.txt): "@probe: Called to see if the
driver is willing to manage a particular interface on a device."
Basically what happens is thus: 1. user plugs in a device. 2. USB chipset
detects that, powers the device, standard USB comms start, and the device
id comes through. (And yes, somewhere in here the chipset's IRQ is
triggered.) 3. The Linux USB core uses that information and calls the
hotplug service (a program in userspace), which tells the kernel what
driver handles it, possibly loading the kernel module, sending firmware or
whatever is needed, etc. 4. The kernel uses that information and calls the
function that you registered as the function pointer for probe. Somewhere
there's a call along the lines of driver_struct->probe(...). 5. Your probe
function does what it does, but one major thing it has to do is return a
value that indicates that it is your device and you handled it, OR it's not
your device and you did nothing important.
You specifically asked about the IRQ. USB devices don't have IRQ lines, the
USB chipset does. Generally speaking, you don't care about the IRQ since
that will be handled in the USB chipset driver code and will trigger the
USB core, which then will call the device-specific callbacks if necessary.
I have seen a few pathological designs that break the proper USB model and
(with on-board hardware), hard-wire an interrupt line from a device to the
uC, while still communicating through a USB chipset. Despite huge
workarounds costing many tens of thousands of dolars in developer time,
these never seem to work well and at best limp along no better than a
properly done USB connection. Why? Because you have to wait for the USB
comms anyway, there's no provision for an out-of-band channel trigger.
There's extensive documentation in Documentation/usb/. Also, there's no
substitute for reading a bit of code. I highly recommend you
become familiar with the use of cscope or a similar code delving tool.
Often times, good use of cscope won't help much in this particular case (it
doesn't ID field names as symbols), so do a text search or grep within the
usb sub-directory for the form '->probe(', which should show you where it's
called and you can then follow the chain from there.
I hope that helps some.
- Steve
Post by stlHello all,
I am writing a USB driver for a new architecture support.
I have define a usb_driver structure with a probe function as field.
But I am wondering when and how this function is called?
I have read on the book Linux Device Drivers 3rd edition (usb driver
chapter)
that this function "is called by the USB core when it thinks it has a
struct usb_interface
that this driver can handle".
So I suppose that when a usb device is attached, the corresponding IRQ is
received
from the hardware, and something in the ISR should tell the USB core that
the probe
function needs to be called.
Could someone clarify the procedure please?
Thanks in advance for your help.
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20130111/33df5c93/attachment.html>