On Thu, 6 Aug 2009, Oliver Neukum wrote: > Am Donnerstag, 6. August 2009 03:30:20 schrieb Rory Filer: > > > I have a few questions on this quirks.c file and its use: > > > > 1) It looks like quirks.c can be compiled separately as a kernel module and > > then loaded at runtime. This would be very handy in the event it becomes > > necessary some day to override one of our devices being in this list. > > quirks.c has the quirks that must always be present, even before a specific > driver is loaded. Therefore it is always part of usbcore and cannot be loaded > separately. But if usbcore is a module, then it can be loaded (along with quirks.c) at runtime. > If you have devices that should be on the list for only some versions of their > firmware, you should use the BCD version to make them distinguishable. > > > 2) If the answer to question 1 is NO, you can't treat quirks.c as a kernel > > module, then is there another way to override an entry without having to > > rebuild the whole kernel? > > You could override them from a driver. The need to do that never arose > up to now. Alternatively, if usbcore was built as a loadable module, then you could rebuild usbcore alone without having to rebuild the whole kernel. > > > 3) Just so I'm clear on this, if a device is present in the quirks list, it > > doesn't stop the kernel from suspending it, it just ensures that a > > device will be disconnected and re-enumerated as part of the resume, > > correct? Don't forget that devices can be on the quirks list for reasons totally unconnected with suspend/resume. > It will be reset and if the descriptors still match it will be logically considered > the same device. > A quirk however can influence autosuspend. Usbcore will not autosuspend > a quirky device if > - its driver has no reset_resume method > - remote wakeup is requested > (either condition) > > > 4) In our testing we've only seen a small number of our modems crash when > > they are resumed. Once they are up again they appear to be re-enumerated > > properly and we can access the various ttyUSBx's again. > > > > reading through the quirks.c file in drivers/usb/core I note there > > aren't very many devices listed in there. My question is, what does it take > > for a device to become eligible for inclusion in this file/driver? > > It > - needs a reset, that is it is not functional after resumption without a reset > - it would simply reenumerate but its driver has a sensible reset_resume method > (either condition) I would clarify that second condition: The device is able to resume but after a resume it doesn't function properly. (In other words, it needs to be reset in order to work okay.) If the driver has a reset_resume method then so much the better, but this isn't necessary. There are also other qualifications for a device to be listed in the quirks file. Basically, it should exhibit any of the problems described by the quirk flags. These are all things that usbcore needs to know about even before the device is bound to a driver, or even if there is no driver. 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
