Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1756181AbcJRVye (ORCPT <rfc822;w@1wt.eu>);
        Tue, 18 Oct 2016 17:54:34 -0400
Received: from mx2.suse.de ([195.135.220.15]:55975 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1756104AbcJRVyY (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 18 Oct 2016 17:54:24 -0400
Date: Tue, 18 Oct 2016 23:54:21 +0200
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Daniel Wagner <daniel.wagner@bmw-carit.de>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
        Daniel Wagner <wagi@monom.org>, linux-kernel@vger.kernel.org,
        Ming Lei <ming.lei@canonical.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Srivatsa S . Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
        "Rafael J . Wysocki" <rjw@sisk.pl>,
        Daniel Vetter <daniel.vetter@intel.com>, Takashi Iwai <tiwai@suse.com>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Arend van Spriel <arend.vanspriel@broadcom.com>
Subject: Re: [PATCH v5 2/5] firmware: encapsulate firmware loading status
Message-ID: <20161018215421.GX8651@wotan.suse.de>
References: <1473423144-21734-1-git-send-email-wagi@monom.org>
 <1473423144-21734-3-git-send-email-wagi@monom.org>
 <3484559b-bc77-d056-0775-481233d51fc0@bmw-carit.de>
 <20161005202750.GF3296@wotan.suse.de>
 <1bbbe0a7-8dc5-3efe-9422-7c52a4f6cc3a@bmw-carit.de>
 <20161010203752.GB8651@wotan.suse.de>
 <064e73ce-12c9-9d3a-94c2-f2d9d9b200f8@bmw-carit.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <064e73ce-12c9-9d3a-94c2-f2d9d9b200f8@bmw-carit.de>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1786
Lines: 47

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