[PATCH 0/63] convert usb_control_msg() and usb_bulk_msg() to use msecs

Evgeniy Polyakov johnpol at 2ka.mipt.ru
Sat Feb 12 00:30:45 CET 2005


On Wed, 9 Feb 2005 11:39:29 -0800
Nishanth Aravamudan <nacc at us.ibm.com> wrote:

[ subscribers-only mail lists removed from Cc: ]

> On Wed, Feb 09, 2005 at 10:41:44PM +0300, Evgeniy Polyakov wrote:
> > On Tue, 8 Feb 2005 16:02:12 -0800
> > Nishanth Aravamudan <nacc at us.ibm.com> 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!

Ok, I did not find anything suspicious after diagonal view, 
so I'm ok with all your changes for w1 and usb.

I will apply them to my tree when Greg pushes usb changes upstream.


Thank you.
 
> -Nish


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt



More information about the lm-sensors mailing list