Re: FW: FW: [PATCH 002/002] USB: serial: sierra driver autosuspend support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
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.

> 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?

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)

	Regards
		Oliver

--
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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux