convert usb_control_msg() and usb_bulk_msg() to use
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest2 of 63 patches 2 repliesIn review
2 of 63 patches are in this archive. The cover letter announces 63.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 2/63 | include/usb: change USB_CTRL_{SET,GET}_TIMEOUT to msecsinclude/ | +3 | 0 replies | |
| 54/63 | w1/dscore: change parameters ofdrivers/ | +5 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/63] convert usb_control_msg() and usb_bulk_msg() to use
Hi,
The following patchset (affecting USB, Bluetooth, IrDA, Sound, DVB and W1 --
hence the long To: an Cc: lists...) converts the usb_control_msg() andusb_bulk_msg() functions to use milliseconds in the timeout parameter instead
of jiffies. This is not a problem for almost all cases, as the requested delays are usually quite long wrt. these two functions.
I see several reasons for committing these changes:
1) Expressing time in milliseconds makes the code cleaner and easier to understand. It also makes the delay independent (from a code perspective) of HZ's value, which would be important for dynamic-HZ or tickless systems.
2) Also for dynamic-HZ/tickless systems, it becomes unclear what exactly HZ represents. Milliseconds have meaning in the human world beyond the kernel. This ties in pretty strongly with 1)'s point about understanding.
3) As the time/timer subsystem evolves and changes, the overall message I am seeing is that jiffies are not a proper expression of time. Thus, I am hoping these patches minimize this particular interface's usage of jiffies in this way; while, in the end, the call to usb_start_wait_for_urb ends up with the same jiffies-based time, if the timer subsystem were to, for instance, convert to nanoseconds, we could instead pass on the parameter multiplied by a million. It simply makes adjusting to any new time system that much easier.
Exceptions do exist, of course, and the following files do not use a HZ-relative timeout variable; thus I was unsure how exactly to proceed. Given that HZ=1000 in i386, the constants used technically correspond directly to milliseconds. I am unsure if that is the intent of the author in all cases, though. I left the hard-coded non-HZ related values alone in all cases.
drivers/isdn/hisax/hfc_usb.cdrivers/usb/media/dabusb.cdrivers/usb/media/dsbr100.cdrivers/usb/media/stv680.cdrivers/usb/media/w9968cf.cdrivers/usb/misc/emi26.cdrivers/usb/misc/emi62.cdrivers/usb/serial/cypress_m8.cdrivers/usb/serial/ftdi_sio.cdrivers/usb/serial/io_edgeport.cdrivers/usb/serial/kobil_sct.cdrivers/usb/serial/pl2303.cdrivers/media/dvb/dibusb/dvb-dibusb-usb.cdrivers/usb/media/dabusb.cdrivers/w1/dscore.c
As always, any comments or suggestions are greatly appreciated.
-Nish