Messages in this thread | | | Date | Tue, 18 Oct 2016 23:54:21 +0200 | From | "Luis R. Rodriguez" <> | Subject | Re: [PATCH v5 2/5] firmware: encapsulate firmware loading status |
| |
On Tue, Oct 18, 2016 at 03:30:45PM +0200, Daniel Wagner wrote: > On 10/10/2016 10:37 PM, Luis R. Rodriguez wrote: > > > > fw_get_fileystem_firmware() > > > fw_finish_direct_load() > > > complete_all() > > > > > > > > > 2nd request (waiter context) > > > > > > _request_firmware() > > > _request_firmware_prepare() > > > fw_lookup_allocate_buf() # finds previously allocated buf > > > # returns 1 -> wait for loading > > > sync_cached_firmware_buf() > > > wait_for_completion_interruptible_timeout() > > > > No, that's wait_for_completion_interruptible() not > > wait_for_completion_interruptible_timeout() > > I confused that one from _request_firmware_load().
Right and wait_for_completion_interruptible() has no timeout.
> > Also note that we only call sync_cached_firmware_buf() > > *iff* fw_lookup_and_allocate_buf() returned the 1 -- I mentioned > > when this happens above. That happens only if we already had the entry on > > the fw cache. As it stands -- concurrent calls against the same fw name > > could cause a clash here, as such, the wait_for_completion_interruptible() > > is indeed still needed. > > > > Further optimizations can be considered later but for indeed, agreed > > that completion is needed even for the direct fw load case. The timeout > > though, I don't see a reason for it. > > So I think I found the source of the confusion about fw_umh_wait_timeout(). > When providing a timeout value of 0 you get the > wait_for_completion_interruptible() version.
I fail to see that, how so? Note that 0 does is not allowed anyway:
static inline long firmware_loading_timeout(void) { return loading_timeout > 0 ? loading_timeout * HZ : MAX_JIFFY_OFFSET; }
Luis
| |