From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932993AbcH2OSl (ORCPT ); Mon, 29 Aug 2016 10:18:41 -0400 Received: from cit-hm8-mail01.bmw-carit.de ([212.118.206.84]:58342 "EHLO cit-hm8-gw01.bmw-carit.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756135AbcH2OSk (ORCPT ); Mon, 29 Aug 2016 10:18:40 -0400 X-CTCH-RefID: str=0001.0A0C0208.57C4443B.00BE,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 Subject: Re: [PATCH v3 1/3] firmware_class: encapsulate firmware loading status To: "Luis R. Rodriguez" , Daniel Wagner References: <1472118723-22762-1-git-send-email-wagi@monom.org> <1472118723-22762-2-git-send-email-wagi@monom.org> <20160825175007.GA3296@wotan.suse.de> <151b26a2-6562-b37b-43e2-9040f0609a1c@bmw-carit.de> CC: , Ming Lei , Greg Kroah-Hartman From: Daniel Wagner Message-ID: <1ffedc17-d2e8-7843-d1e5-5da20d4cae91@bmw-carit.de> Date: Mon, 29 Aug 2016 16:18:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <151b26a2-6562-b37b-43e2-9040f0609a1c@bmw-carit.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.50.53] X-ClientProxiedBy: CIT-HM8-EX01.bmw-carit.intra (10.40.100.13) To CIT-HM8-EX01.bmw-carit.intra (10.40.100.13) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/29/2016 11:50 AM, Daniel Wagner wrote: > On 08/25/2016 07:50 PM, Luis R. Rodriguez wrote: >>> +#else /* CONFIG_FW_LOADER_USER_HELPER */ >>> + >>> +static int loading_timeout = 60; >>> +#define firmware_loading_timeout() (loading_timeout * HZ) >>> + >>> +#define fw_status_wait_timeout(fw_st, long) 0 >> >> The timeout makes 0 sense for when !CONFIG_FW_LOADER_USER_HELPER so can >> we do away with adding a silly 60 value to an int here and >> the silly value of (loading_timeout * HZ) ? Its not used so its not >> clear to me why this is here. > > So the main reason that silly timeout is needed is the usage of > it in device_cache_fw_images(). I suggest we add a timeout > argument to _request_firmware() and use the right timeout value > at that level. > > That allows to move the loading_timeout into the > CONFIG_FW_LOADER_USER_HELPER section. I forgot to answer your question. So we have the dependency to loading_timeout/firmware_loading_timeout from the firmware caching path. The patch added in the previous email removes that dependency. We still need the 60 second even in the !CONFIG_FW_LOADER_USER_HELPER case. I think it would be a regression if we change that value, no? cheers, daniel