Re: [Y2038] [PATCH] dummy_hcd: replace timeval with timespec64

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

 




On Tuesday, September 15, 2015 10:49 PM, Arnd Bergmann wrote:
> On Tuesday 15 September 2015 10:40:24 Alan Stern wrote:
>> On Tue, 15 Sep 2015, Arnd Bergmann wrote:
>>
>>>>> Do you know the specific requirement on the USB frame numbers? I don't know
>>>>> enough about USB to tell if either of those matter.
>>>>
>>>> Using jiffies_to_msecs() here is a nice way. According to USB 2.0 Spec, however, the frame time is 1ms
>>>> in full / low-speed, and 125us in high-speed.
>>
>> That's not quite right.  A frame is always 1 ms, no matter what the
>> speed.  In high-speed and SuperSpeed, each 125-us period is called a
>> micro-frame.
>>
>>>>  Actually, most of HCD implement this in hardware, the
>>>> driver just read a register and return its value. It's hard to cover all platform here if we only use kernel
>>>> time wheel.
>>>
>>> ktime_get() should have a high enough resolution to cover the high-speed mode,
>>> but that would also mean changing the driver more fundamentally.
>>>
>>> The dummy driver does support emulating both superspeed and highspeed USB,
>>> so that may indeed be the right solution. At this point, we probably need
>>> Felipe, Alan and the linux-usb list to make a decision, so I've added
>>> them to Cc.
>>>
>>> My impression from your comment is that the driver should check the
>>> dummy_hcd_module_parameters variable for the device speed in order to
>>> pick the right time base for the frame number, and then calculate it
>>> using ktime_divns(ktime_get()) with an appropriate factor.
>>
>> The right place to get the speed would be hcd->speed (in
>> dummy_h_get_frame)  and _gadget->speed (in dummy_g_get_frame).  The
>> module parameters affect what speeds are allowed but they don't fully
>> determine the actual speed.  However this is moot, since the API always 
>> returns the frame number, not the micro-frame number.
> 
> Ok, thanks for the clarification!
> 
>> I agree that the monotonic clock would be better than the real-time 
>> clock.
>>
>> On the other hand, this probably doesn't matter much.  Frame numbers
>> generally aren't useful for anything other than isochronous transfers,
>> and dummy-hcd doesn't support isochronous.
> 
> Ok. I'd suggest that Pingbo uses ktime_get_ts64() for the next version
> then, and add an explanation why it is likely irrelevant. By now, the
> main advantage I see in using monotonic time is that it might save
> someone from having to look at this file when searching for possible
> leap second issues, but that's still better than nothing.
> 

I will fix it in next version.

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