From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756135AbcHBFxP (ORCPT ); Tue, 2 Aug 2016 01:53:15 -0400 Received: from cit-hm8-mail01.bmw-carit.de ([212.118.206.84]:34746 "EHLO cit-hm8-gw01.bmw-carit.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751624AbcHBFxH (ORCPT ); Tue, 2 Aug 2016 01:53:07 -0400 X-CTCH-RefID: str=0001.0A0C0206.57A03461.0117,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 Subject: Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion To: "Luis R. Rodriguez" References: <1469692512-16863-1-git-send-email-wagi@monom.org> <1469692512-16863-8-git-send-email-wagi@monom.org> <20160728183343.GD16852@dtor-ws> <20160728190151.GV13516@tuxbot> <20160730165817.GQ3296@wotan.suse.de> <37a3cd66-262e-ffbe-ea7a-a6d5b1ca1c8b@bmw-carit.de> <20160801194408.GZ3296@wotan.suse.de> CC: Dmitry Torokhov , Arend van Spriel , Bjorn Andersson , Daniel Wagner , Bastien Nocera , Greg Kroah-Hartman , Johannes Berg , Kalle Valo , Ohad Ben-Cohen , Mimi Zohar , David Howells , Andy Lutomirski , David Woodhouse , Julia Lawall , , , , From: Daniel Wagner Message-ID: <0f9350fa-e8b5-9d64-b2d3-afda5e5f6bbf@bmw-carit.de> Date: Tue, 2 Aug 2016 07:49:19 +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: <20160801194408.GZ3296@wotan.suse.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.50.51] 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 Hi Luis, >> I was ignorant on all the nasty details around the firmware loading. >> If I parse Luis' patches correctly they introduce an API which calls >> kernel_read_file_from_path() asynchronously: >> >> sysdata_file_request_async(..., &cookie) >> *coookie = async_schedule_domain(request_sysdata_file_work_func(), ..) >> >> request_sysdata_file_work_fun() >> _sysdata_file_request() >> fw_get_filesystem_firmware() >> kernel_read_file_from_path() >> >> sysdata_synchronize_request(&cookie); >> >> Doesn't look like what your asking for. > > No, but its also a generic kernel read issue as I noted in my last > reply. Okay, got it. >>> If we want to overhaul firmware loading support we need to figure >>> out how to support case when a driver want to [asynchronously] request >>> firmware/config/blob and the rest of the system is not ready. Even if we >>> want kernel to do read/load the data we need userspace to tell kernel >>> when firmware partition is available, until then the kernel should not >>> fail the request. >> >> I gather from Luis' blog post and comments that he is on the quest >> on removing userspace support completely. > > No, I explained in my last proposed documentation patch series that we cannot > get rid of the usermode helper. I stand corrected. > Its not well understood why so I explained and documented why. Obviously, I got lost somewhere there :) > Best we can do is compartamentalize its uses. Sounds like a plan. > The sysdata API's main goal rather is to provide a flexible API first, > compartamentalizing the usermode helper was secondary. But now it seems > I may just also add devm support too to help simplify code further. I missed the point that you plan to add usermode helper support to the sysdata API. > What Dmitry notes is an existential issue with kernel_read_file_from_path() > and we need a common solution for it. Understood. I guess best thing to keep that discussion in the other subthread. >> Maybe this attempt here could be a step before. Step 1 would be >> changing request_firmware_nowait() to request_firmware_async so >> drivers don't have to come up with their own sync primitives, e.g. >> >> cookie = request_firmware_async() >> fw_load_wait(cookie) > > That's one of the features already part of async mechanism of the sysdata API :) Yes, I realized that too :) cheers, daniel Thanks for the feedback.