On Wed, 2016-11-09 at 23:02 +0100, Luis R. Rodriguez wrote: > Actually... we also set the timeout to MAX_JIFFY_OFFSET when FW_OPT_UEVENT is > not set. This happens *only* when the UMH was explicitly requested on the > async call, when the second argument to request_firmware_nowait() is false. > There are *only* two callers that do this in the kernel. If this is correct *and* > the assessment of the cast from long to int here is correct that should mean > these two callers in the kernel that have always requested the UMH firmware > *fallback* have *always* had a faulty UMH fallback return value... Thanks for all your mails. Yes, that was my case here, and I noticed it looked broken for a long time, I didn't investigate who was using it in the kernel but I had the feeling it was a bit of an abuse of the infrastructure. I still reported the bug because the quick fix looked OK but I can understand the will to actually rethink if and how this part is really needed. Maybe I need to wait a bit before resubmitting any patch with rephrased commit log to see where this is going? Regards, -- Yves-Alexis
Attachment:
signature.asc
Description: This is a digitally signed message part