[irda-users] Re: [PATCH 0/63] convert usb_control_msg() and usb_bulk_msg() to use msecs

[Nishanth A. <na...@us...>]

On Wed, Feb 09, 2005 at 10:41:44PM +0300, Evgeniy Polyakov wrote:
> On Tue, 8 Feb 2005 16:02:12 -0800
> Nishanth Aravamudan <na...@us...> wrote:
> 
> > Hi,
> > 
> > The following patchset (affecting USB, Bluetooth, IrDA, Sound, DVB and W1 --
> > hence the long To: an Cc: lists...) converts the usb_control_msg() and
> > usb_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.
> 
> As for w1 - this changes do not break anything, but
> I'm not sure that it will not break usb core code which can
> depend on jiffies and thus arch specific timings.
> 
> So I have a question: is this change intentional and thus by design requires
> milliseconds, or it just happens that HZ==1000 on the most of the platforms?

So the first check I did, at Greg's suggestion, was to verify the timing
units for usbdevfs, which are milliseconds. So we should be ok there.
Second, all of these patches don't change the fact that jiffies are
used. They only move the usage of jiffies further into the usbcore, thus
making the actual API be in human time-units and relying on correct
translation from HZ-independent units (milliseconds) to HZ-dependent
units (jiffies) in one place.

So the change is very much intentional, but it's an API change only. The
timeout parameter is not even used until usb_start_wait_urb() and
presuming msecs_to_jiffies() does what we want (and I've verified it
does for the most common cases), then the timer in usb_start_wait_urb()
will be set for the same number of jiffies.

Really, this just makes it easier for me later on to go through and
re-audit timer usage :) If we do change the timer core (and I'm working
on figuring out how exactly to do so), then only changing in one place
down the road is better than all of these patches going out then *along
with* a huge rework of core kernel code...

So, in conclusion, these patches shouldn't break anything for anyone, if
I got my conversions correct. Most drivers were passing HZ * __some_var
or HZ / 10, anyways, which is expressible easily in human time units via
1000 * __some_var or 100, respectively. So it shouldn't change anything,
except in what units we are dealing.

Let me know if you see anything that points to the contrary (in USB core
code, or anywhere else).

Thanks for the feedback!

-Nish