linux-kernel - Re: [RFC v0 7/8] Input: ims-pcu: use firmware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0f9350fa-e8b5-9d64-b2d3-afda5e5f6bbf@bmw-carit.de>
Date:	Tue, 2 Aug 2016 07:49:19 +0200
From:	Daniel Wagner <daniel.wagner@...-carit.de>
To:	"Luis R. Rodriguez" <mcgrof@...nel.org>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Arend van Spriel <arend.vanspriel@...adcom.com>,
	Bjorn Andersson <bjorn.andersson@...aro.org>,
	Daniel Wagner <wagi@...om.org>,
	Bastien Nocera <hadess@...ess.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Johannes Berg <johannes.berg@...el.com>,
	Kalle Valo <kvalo@...eaurora.org>,
	Ohad Ben-Cohen <ohad@...ery.com>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	David Howells <dhowells@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	David Woodhouse <dwmw2@...radead.org>,
	Julia Lawall <julia.lawall@...6.fr>,
	<linux-input@...r.kernel.org>, <linux-kselftest@...r.kernel.org>,
	<linux-wireless@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of
 completion

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.