Subject: Re: [PATCH v5 2/5] firmware: encapsulate firmware loading status
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
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>
CC: 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>
From: Daniel Wagner <daniel.wagner@bmw-carit.de>
Message-ID: <1bbbe0a7-8dc5-3efe-9422-7c52a4f6cc3a@bmw-carit.de>
Date: Fri, 7 Oct 2016 13:41:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <20161005202750.GF3296@wotan.suse.de>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2973
Lines: 101

Hi Luis,

On 10/05/2016 10:27 PM, Luis R. Rodriguez wrote:
> On Tue, Sep 13, 2016 at 11:47:08AM +0200, Daniel Wagner wrote:
>> On 09/09/2016 02:12 PM, Daniel Wagner wrote:
>>> The firmware user helper code tracks the current state of the loading
>>> process via unsigned long status and a complection in struct
>>> firmware_buf. We only need this for the usermode helper as such we can
>>> encapsulate all this data into its own data structure.
>>
>> I don't think we are able to move the completion code into a
>> CONFIG_FW_LOADER_HELPER section. The direct loading path uses
>> completion as well.
>
> Where?

If you look at the current code (not these patches) you have dependency 
via the firmware_buf for two concurrent _request_firmware() calls:


1nd request (waker context)

_request_firmware()
   _request_firmware_prepare()
     fw_lookup_and_allocate_buf()   # no pendending request
                                    # returns 0 -> load firmware

   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()


>>> +#else /* CONFIG_FW_LOADER_USER_HELPER */
>>> +
>>> +#define fw_umh_wait_timeout(fw_st, long)	0
>>> +
>>> +#define fw_umh_done(fw_st)
>>> +#define fw_umh_is_done(fw_st)			true
>>> +#define fw_umh_is_aborted(fw_st)		false
>>
>> We still need the implementation for fw_umh_wait_timeout() and
>> fw_umh_start(), fw_umh_done() etc.
>
> Why?

See above.

>>> @@ -309,8 +373,7 @@ static void fw_finish_direct_load(struct device *device,
>>> 				  struct firmware_buf *buf)
>>> {
>>> 	mutex_lock(&fw_lock);
>>> -	set_bit(FW_STATUS_DONE, &buf->status);
>>> -	complete_all(&buf->completion);
>>> +	fw_umh_done(&buf->fw_umh);
>>> 	mutex_unlock(&fw_lock);
>>> }
>>
>> Here we signal that we have loaded the firmware
>
> The struct firmware_buf is only used for the sysfs stuff no?

I don't know, I was looking at the code in firmware_class.c not any 
users. Why is that important?

>>> /* wait until the shared firmware_buf becomes ready (or error) */
>>> static int sync_cached_firmware_buf(struct firmware_buf *buf)
>>> {
>>> 	int ret = 0;
>>>
>>> 	mutex_lock(&fw_lock);
>>> -	while (!test_bit(FW_STATUS_DONE, &buf->status)) {
>>> -		if (is_fw_load_aborted(buf)) {
>>> +	while (!fw_umh_is_done(&buf->fw_umh)) {
>>> +		if (fw_umh_is_aborted(&buf->fw_umh)) {
>>> 			ret = -ENOENT;
>>> 			break;
>>> 		}
>>> 		mutex_unlock(&fw_lock);
>>> -		ret = wait_for_completion_interruptible(&buf->completion);
>>> +		ret = fw_umh_wait_timeout(&buf->fw_umh, 0);
>>> 		mutex_lock(&fw_lock);
>>> 	}
>>
>> and here we here we wait for it.
>
> Likewise.

As I tried to explain above the buffering code is depending on completion.

cheers,
daniel