From: Daniel Wagner
Loading firmware is an operation many drivers implement in various ways
around the completion API. And most of them do it almost in the same
way. Let's reuse the firmware_stat API which is used also by the
firmware_class loader. Apart of streamlining the firmware lo
From: Daniel Wagner
Loading firmware is an operation many drivers implement in various ways
around the completion API. And most of them do it almost in the same
way. Let's reuse the firmware_stat API which is used also by the
firmware_class loader. Apart of streamlining the firmware lo
From: Daniel Wagner
Hi,
While reviewing all the complete_all() users, I realized there is
recouring pattern how the completion API is used to synchronize the
stages of the firmware loading. Since firmware_class.c contains a
fairly complete implemetation for synching the loading, it worthwhile
From: Daniel Wagner
When running the test script you will get:
kselftest/firmware/fw_userhelper.sh: line 69: echo: write error: Resource
temporarily unavailable
and stops right there. Because the script runs with the '-e' option
which will stop the script at any error.
We should
From: Daniel Wagner
Factor out the firmware loading synchronization code in order to allow
drivers to reuse it. This also documents more clearly what is
happening. This is especial useful the drivers which will be converted
afterwards. Not everyone has to come with yet another way to handle it
From: Daniel Wagner
Loading firmware is an operation many drivers implement in various ways
around the completion API. And most of them do it almost in the same
way. Let's reuse the firmware_stat API which is used also by the
firmware_class loader. Apart of streamlining the firmware lo
From: Daniel Wagner
Loading firmware is an operation many drivers implement in various ways
around the completion API. And most of them do it almost in the same
way. Let's reuse the firmware_stat API which is used also by the
firmware_class loader. Apart of streamlining the firmware lo
From: Daniel Wagner
Some of the test are supposed to fail but we get a few ouptput lines:
./fw_filesystem.sh: line 51: printf: write error: Invalid argument
./fw_filesystem.sh: line 56: printf: write error: No such device
./fw_filesystem.sh: line 62: echo: write error: No such file or directory
From: Daniel Wagner
Loading firmware is an operation many drivers implement in various ways
around the completion API. And most of them do it almost in the same
way. Let's reuse the firmware_stat API which is used also by the
firmware_class loader. Apart of streamlining the firmware lo
On 07/28/2016 01:22 PM, Bastien Nocera wrote:
On Thu, 2016-07-28 at 09:55 +0200, Daniel Wagner wrote:
From: Daniel Wagner
Loading firmware is an operation many drivers implement in various
ways
around the completion API. And most of them do it almost in the same
way. Let's reus
Looking at the API, I really don't like the mixing of namespaces.
Either it's fw_ or it's firmware_ but not a mix of both.
I agree, that was not really clever.
struct fw_loading { ... }
__fw_loading_*()
fw_loading_*()
Would that make more sense? firmware_loading_ as pre
It's somewhat odd to me that the structure is "firmware_stat" but most
of the functions are "fw_loading_*". That seems inconsistent for a
structure that is (currently) only used by these functions.
I agree, my proposal is odd.
I would personally do either:
a) "struct fw_load_status" and "fw_
On 07/28/2016 07:57 PM, Dmitry Torokhov wrote:
On Thu, Jul 28, 2016 at 09:55:07AM +0200, Daniel Wagner wrote:
+int __firmware_stat_wait(struct firmware_stat *fwst,
+ long timeout)
+{
+ int err;
+ err = swait_event_interruptible_timeout(fwst->
On 07/28/2016 09:01 PM, Bjorn Andersson wrote:
On Thu 28 Jul 11:33 PDT 2016, Dmitry Torokhov wrote:
On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote:
From: Daniel Wagner
[..]
Do not quite like it... I'd rather asynchronous request give out a
firmware status pointer
On 07/31/2016 09:23 AM, Dmitry Torokhov wrote:
On July 30, 2016 9:58:17 AM PDT, "Luis R. Rodriguez" wrote:
On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel wrote:
On 29-07-16 08:13, Daniel Wagner wrote:
On 07/28/2016 09:01 PM, Bjorn Andersson wrote:
On Thu 28 Jul 11:3
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_f
On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:
On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
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 t
On 08/02/2016 09:41 AM, Luis R. Rodriguez wrote:
On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:
On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:
On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
So you argue for the remoteproc use case with 100+ MB firmware that
From: Daniel Wagner
Hi,
Using complete_all() is not wrong per se but it suggest that there
might be more than one reader. For -rt I am reviewing all
complete_all() users and would like to leave only the real ones in the
tree. The main problem for -rt about complete_all() is that it can be
uses
From: Daniel Wagner
carl9170_usb_stop() is used from several places to flush and cleanup any
pending work. The normal pattern is to send a request and wait for the
irq handler to call complete(). The completion is not reinitialized
during normal operation and as the old comment indicates it is
From: Daniel Wagner
There is only one waiter for the completion, therefore there
is no need to use complete_all(). Let's make that clear by
using complete() instead of complete_all().
The usage pattern of the completion is:
waiter context waker context
scan.st
" though -- but for that I can only refer you
at this point to some of Daniel Wagner and Tom Gunderson's firmwared
deamon prospect. It should help pave the way for a clean solution and
help address other stupid issues.
The firmwared project is hosted here
https://github.com/teg/firmw
22 matches
Mail list logo
