Greg KH wrote:
> On Tue, Jul 31, 2007 at 04:00:15PM -0700, Pete Zaitcev wrote:
>> On Tue, 31 Jul 2007 17:00:04 -0500, <[EMAIL PROTECTED]> wrote:
>>
>>> + list_for_each_safe (entry, tmp, &qh->qtd_list) {
>>> + qtd = list_entry (entry, struct ehci_qtd, qtd_list);
>>> + if (cpu_to_le32 (qtd->qtd_dma) == qh->hw_current) +
return qtd;
>>> + }
>>
>> Why use list_for_each_safe when mere list_for_each would do?
>> In fact, some might ask for list_for_each_entry.
>
> Yes, I think Rusty has an automated email that checks for every new
> list_for_each that doesn't use list_for_each_entry, you don't want to
> hit that :)
>
> So could you change it to use this? I don't think that the "safe"
> version is needed here either, do you?
>
> thanks,
>
> greg k-hYes, sorry, I'm not sure what I was thinking. Here's the changed patch along with the description (again). Thanks! This patch fixes a bug with the cpu frequency change notifier and nVidia EHCI controllers. The nVidia controllers write the transfer overlay back to the qtd when they see the "inactivate" bit set in the qh, which clears the "active" bit in qtd->hw_token. When the qh was reactivated, the "active" bit in the overlay's hw_token was turned back on, but not the one in the qtd. This caused qh_completions to think that qtd was finished even though it wasn't. This patch (against 2.6.23-rc1) fixes this bug. Signed-off-by: Stuart Hayes <[EMAIL PROTECTED]>
ehci_cpufreq_nvidia_30july_c.patch
Description: ehci_cpufreq_nvidia_30july_c.patch
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
