From: Daniel Wagner
All other test use '=l' instead of '-i' to as option name for defining how many
loops should be executed. Let's streamline posix03 and posix04.
Signed-off-by: Daniel Wagner
---
posix03.c | 6 +++---
posix04.c | 6 +++---
2 files changed, 6 i
From: Daniel Wagner
Hi Jeff,
I had a bunch of small patches in my tree, which I forgot to send.
So here they are...
cheers,
daniel
Daniel Wagner (3):
Synchronize all clients on start up
posix03, posix04: Use '-l' instead of '-i' as option argument name
posix03: Do no
From: Daniel Wagner
kill(0, SIGINT) sends to all in the process group the signal
including the parent shell.
Instead remember the PIDs of all children and just send the signal
to these processes.
Reported-by: Dave Chinner
Signed-off-by: Daniel Wagner
---
posix03.c | 17 +++--
1
From: Daniel Wagner
The child process start working as soon as they are forked. Sometimes
that leads to a workload pattern that no contention happens at all even
with a high number of processes. Since the main motivation of this
this is to benchmark the contention overhead let the clients wait
On 09/19/2016 08:59 AM, Niklas Cassel wrote:
I've already sent patches for these errors (among others errors)
http://marc.info/?l=linux-kernel&m=144873518310721&w=2
http://marc.info/?l=linux-kernel&m=144873519510723&w=2
Excellent! As I said, the build robot keeps nagging me about such errors
From: Daniel Wagner
The crisv32_intem_init() function doesn't match the necessary callback
function signature. Newer gcc version are checking the pointer types
and through an error if they don't match.
Reported-by: kbuild test robot
Signed-off-by: Daniel Wagner
Cc: Mikael Starvik
From: Daniel Wagner
intmem_allocaionts is list head. Comparing the list head with prev and
next works so far because the entry was placed at the beginning of
struct intmem_allocation. Let's use list_entry to recover the correct
pointer and which makes this code slightly more robust.
Newe
From: Daniel Wagner
Hi,
I got a love letter from kbuild about incompatible pointer types. I
added the new compiler flag [1] so it seems I am in charge cleaning up.
kbuild tells me:
All errors (new ones prefixed by >>):
arch/cris/arch-v32/mm/intmem.c: In function 'crisv32_
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().
While we are at it, we do a small optimization with the
reinitialization of the completion before we u
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().
While we are at it, we do a small optimization with the reinitialization
of the completion before we u
From: Daniel Wagner
Hi,
Using complete_all() is not wrong per se but it suggest that there
might be more than one waiter. 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
The kthread_stop() waits for the thread to exit. There is no need for an
additional synchronization needed to join on the kthread.
The completation was added by 89fac11cb3e7 ("adt7470: make automatic fan
control really work").
Signed-off-by: Daniel Wagner
Cc:
Hi Luis,
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
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
sym_eh_ha
From: Daniel Wagner
Hi,
Using complete_all() is not wrong per se but it suggest that there
might be more than one waiter. 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
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
virtscs
From: Daniel Wagner
The (re)initialzing of the completion object should be done before we
trigger the transfer. Doing this after triggering the hardware opens up
a race window. Without the timeout we would problaly even deadlock. Use
also reinit_completion because we initalize the whole data
From: Daniel Wagner
fw_load_from_user_helper() and _request_firmware_load() are used when
CONFIG_FW_LOADER_USER_HELPER is enabled. In order to clearly mark which
part of the code is depending on UMH we stream line these functions to
match with the rest of the code, e.g. fw_umh_done().
Suggested
From: Daniel Wagner
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.
Cc: Ming Lei
Cc
From: Daniel Wagner
fw_lock is to use to protect 'corner cases' inside firmware_class. It
is not exactly clear what those corner cases are nor what it exactly
protects. fw_umh can be used without needing the fw_lock to protect
its state transition and wake ups.
fw_umh is holds th
From: Daniel Wagner
We track the state of the loading with bit ops. Since the state machine
has only a couple of states and they are all mutual exclusive there are
only a few simple state transition we can model this simplify.
UNKNOWN -> LOADING -> DONE | ABORTED
Cc: Ming L
From: Daniel Wagner
Hi,
The firmware user helper code tracks the current state of the loading
process via an member of struct firmware_buf and a completion. Let's
encapsulate this simple state machine into struct fw_status. The aim is
to increase readability and reduce the usage of the fw
From: Daniel Wagner
The lock is also used to generate warnings when a direct
firmware load is requested too early.
The usermodehelper locking code was added by b298d289c792 ("PM / Sleep:
Fix freezer failures due to racy usermodehelper_is_disabled()").
As Luis points out:
"R
On 09/08/2016 05:49 PM, Ming Lei wrote:
On Thu, Sep 8, 2016 at 8:26 PM, Daniel Wagner wrote:
if (ret != 0 && test_bit(...))
return -ENOENT;
Another question, why do you want to return -ENOENT when
userspace aborts the load? And looks it will always be ove
On 09/08/2016 03:45 AM, Luis R. Rodriguez wrote:
On Wed, Sep 07, 2016 at 10:45:07AM +0200, Daniel Wagner wrote:
From: Daniel Wagner
We track the state of the loading with bit ops. Since the state machine
has only a couple of states and there are only a few simple state
transition
And they
esume.
Okay, so let's finish this round of refactoring first. I prefer going in
smaller steps and see if there are any regressions with those changes.
Signed-off-by: Daniel Wagner
Cc: Ming Lei
Cc: Luis R. Rodriguez
Cc: Greg Kroah-Hartman
---
drivers/base/firmware_class.c | 52 ++
On 09/07/2016 10:45 AM, Daniel Wagner wrote:
@@ -702,7 +760,7 @@ static ssize_t firmware_loading_store(struct device *dev,
dev_err(dev, "%s: unexpected value (%d)\n", __func__, loading);
/* fallthrough */
case -1:
- fw_load_abo
Hi Ming,
On 09/08/2016 01:26 PM, Ming Lei wrote:
On Wed, Sep 7, 2016 at 4:45 PM, Daniel Wagner wrote:
From: Daniel Wagner
+static int fw_status_wait_timeout(struct fw_status *fw_st, long timeout)
+{
+ int ret;
+
+ ret = wait_for_completion_interruptible_timeout(&fw_st->com
On 09/08/2016 10:05 AM, Daniel Wagner wrote:
This while loop was originally a goto loop:
1f2b79599ee8 ("firmware loader: always let firmware_buf own the pages
buffer")
I don't think the code doesn't do what it was indented to do. The reason
is that callin
On 09/08/2016 03:39 AM, Luis R. Rodriguez wrote:
On Wed, Sep 07, 2016 at 10:45:06AM +0200, Daniel Wagner wrote:
From: Daniel Wagner
timeout = MAX_JIFFY_OFFSET;
}
- retval = wait_for_completion_interruptible_timeout(&buf->com
On 09/07/2016 06:42 PM, Thomas Gleixner wrote:
On Wed, 7 Sep 2016, Binoy Jayan wrote:
This work is based on work by Daniel Wagner. A few tracepoints are added
Interesting. The patch you are referring to was written by Carsten
Emde. Can you please get these attributions right? They want to be
From: Daniel Wagner
Hi,
This is version depends on Luis' '[PATCH v4 0/5] firmware: add SmPL
grammar to avoid issues' series [1]. Because of that I was able to get
rid of loading_timeout and firmware_loading_timeout() in the
!FW_LOADER_USER_HELPER_FALLBACK case.
cheers,
dani
From: Daniel Wagner
fw_lock is to use to protect 'corner cases' inside firmware_class. It
is not exactly clear what those corner cases are nor what it exactly
protects. fw_status can be used without needing the fw_lock to protect
its state transition and wake ups.
fw_status is holds
From: Daniel Wagner
We track the state of the loading with bit ops. Since the state machine
has only a couple of states and there are only a few simple state
transition we can model this simplify.
UNKNOWN -> LOADING -> DONE | ABORTED
Signed-off-by: Daniel Wagner
Cc: Ming L
From: Daniel Wagner
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.
Signed-off-by
From: Daniel Wagner
When we load the firmware directly we don't need to take the umh
lock. So move this part inside fw_load_from_user_helper which is only
available when CONFIG_FW_LOADER_USER_HELPER is set.
This avoids a dependency on firmware_loading_timeout() even
heers,
daniel
>From cc2f610078ebe9ba8d850cbf602aa529df690cdb Mon Sep 17 00:00:00 2001
From: Daniel Wagner
Date: Wed, 31 Aug 2016 09:37:38 +0200
Subject: [PATCH] tracing: Add hist trigger support for generic fields
Whenever a trace is printed the generic fields (CPU, COMM) are
reconstructed (see trace_print_context(
Hi Luis,
On 08/30/2016 09:34 PM, Luis R. Rodriguez wrote:
On Mon, Aug 29, 2016 at 04:18:33PM +0200, Daniel Wagner wrote:
On 08/29/2016 11:50 AM, Daniel Wagner wrote:
I forgot to answer your question. So we have the dependency to
loading_timeout/firmware_loading_timeout from the firmware
Hi Luis,
On 08/24/2016 02:45 AM, mcg...@kernel.org wrote:
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 22d1760a4278..dca4f9cbf4db 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1412,7 +1412,7 @@ static int cache_firmware(con
On 08/30/2016 04:20 PM, Daniel Wagner wrote:
> Just setting the size of the type is not enough. The hist_field_*
> getter function want to know the offset too:
With this hack here it should work. The COMM generic field is handled via
the tracing_map_ops. We could do it also there but t
On 08/30/2016 04:01 PM, Daniel Wagner wrote:
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 03c0a48..ab8958f 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -152,7 +152,8 @@ EXPORT_SYMBOL_GPL(trace_define_field);
Hi Steven,
>> 'hist:key=ltype,latency:val=hitcount:sort=latency if cpu==1'
>
> What about using "CPU" (all caps)? Look at
> kernel/trace/trace_events_filter.c for FILTER_CPU.
>
> Lets not add fields when we can fix the generic code to process these.
Well at least the size info needs to be added
Hi Binoy,
On 08/30/2016 12:28 PM, Binoy Jayan wrote:
Examples of triggers:
echo 'hist:key=latency.log2:val=hitcount:sort=latency' >
/sys/kernel/debug/tracing/events/latency/latency_preempt/trigger
echo 'hist:key=cpu,latency:val=hitcount:sort=latency if cpu==1' >
/sys/kernel/debug/tracing/event
Hi Binoy,
On 08/30/2016 12:28 PM, Binoy Jayan wrote:
+static inline void trace_latency_preempt_mark_ts(enum latency_type ltype)
+{
+ this_cpu_write(lat_ts[ltype], (cycle_t) trace_clock_local());
+}
+
+static inline void latency_trace(enum latency_type type)
+{
+ trace_latency_preempt
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
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 wh
Hi Binoy,
Some minor nitpicking.
On 08/29/2016 08:55 AM, Binoy Jayan wrote:
+DECLARE_EVENT_CLASS(latency_template,
+ TP_PROTO(int ltype, int cpu, cycles_t latency),
+
+ TP_ARGS(ltype, cpu, latency),
+
+ TP_STRUCT__entry(
+ __field(int,ltype)
+
From: Daniel Wagner
We track the state of the loading with bit ops. Since the state machine
has only a couple of states and there are only a few simple state
transition we can model this simplify.
UNKNOWN -> LOADING -> DONE | ABORTED
Signed-off-by: Daniel Wagner
Cc: Ming L
From: Daniel Wagner
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.
Signed-off-by
From: Daniel Wagner
This version should address all comments from Luis. In the last patch
the fw_lock dependency is dropped. This only works if we garantee not
to race between the reader and the writer side in combination in going
to sleep and waking up. So here that should now be a good
From: Daniel Wagner
fw_lock is to use to protect 'corner cases' inside firmware_class. It
is not exactly clear what those corner cases are nor what it exactly
protects. fw_status can be used without needing the fw_lock to protect
its state transition and wake ups.
fw_status is holds
Hi Binoy,
On 08/24/2016 01:17 PM, Binoy Jayan wrote:
Histogram output:
cat /sys/kernel/debug/tracing/events/latency/latency_irqs/hist
cat /sys/kernel/debug/tracing/events/latency/latency_preempt/hist
cat /sys/kernel/debug/tracing/events/latency/latency_critical_timings/hist
cat /sys/kernel/debug
From: Daniel Wagner
The firmware user helper code tracks the current state of the loading
process via an member of struct firmware_buf and a completion. Let's
encapsulate this simple state machine into struct fw_status.
We don't need the fw_lock to protect the state machine anymore
From: Daniel Wagner
Hi,
As requested an splited up version.
cheers,
daniel
changes since v1:
- moved swait change into its own patch
- added ifdef section for FW_LOADER_USER_HELPER_FALLBACK
- updated commit message highlighting the mutex usage drop a bit
https://lkml.org/lkml/2016/8
From: Daniel Wagner
complete_all() can only be issued once before it needs to be
reinitialized. To ensure we never call complete_all() twice we use
swait and make the code here a bit more robust.
Signed-off-by: Daniel Wagner
Cc: Ming Lei
Cc: Luis R. Rodriguez
Cc: Greg Kroah-Hartman
On 18.08.2016 18:30, Luis R. Rodriguez wrote:
> On Wed, Aug 17, 2016 at 08:47:24AM +0200, Daniel Wagner wrote:
>> On 08/10/2016 08:52 PM, Luis R. Rodriguez wrote:
>> The current 'state machine' uses three variables to handle the state
>> and the trans
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
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
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
On Thu, Aug 18, 2016 at 12:39:25PM +0530, Binoy Jayan wrote:
> static struct trace_array*irqsoff_trace __read_mostly;
> static int tracer_enabled __read_mostly;
>
> static DEFINE_PER_CPU(int, tracing_cpu);
> -
> +static DEFINE_PER_CPU(cycle_t, ts_irqs);
>
On Thu, Aug 18, 2016 at 12:39:24PM +0530, Binoy Jayan wrote:
> Not for inclusion!
>
> Not-Signed-off-by: Daniel Wagner
I wrote that for the initial RFC. Since you are now taking care of the
patch set, you can drop the 'Not for inclusion!' and here is my
Signed-off-by: Daniel Wanger
Hi Luis,
On 08/10/2016 08:52 PM, Luis R. Rodriguez wrote:
On Wed, Aug 10, 2016 at 09:02:08AM +0200, Daniel Wagner wrote:
On 10.08.2016 03:10, Luis R. Rodriguez wrote:
On Thu, Aug 04, 2016 at 02:27:16PM +0200, Daniel Wagner wrote:
From: Daniel Wagner
I see. But in this case the code in
From: Daniel Wagner
3e9389573574 ("um: Use asm-generic/irqflags.h") introduced a typo.
Signed-off-by: Daniel Wagner
---
Hi Richard,
I just saw that the original patch made into mainline including a fat
typo. I just wonder why the compiler didn't complain or why it just
wo
On 10.08.2016 03:10, Luis R. Rodriguez wrote:
> On Thu, Aug 04, 2016 at 02:27:16PM +0200, Daniel Wagner wrote:
>> From: Daniel Wagner
>> In [0] we have a discussion on how the firmware_class API might be
>> changed to improve the current handling of firmware loading. This
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 co
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 co
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 co
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 co
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
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 co
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
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 co
From: Daniel Wagner
The firmware user helper code tracks the current state of the loading
process via an member of struct firmware_buf and a completion. Let's
encapsulate this simple state machine into struct fw_status. The aim is
to encrease readiblity and reduce the usage of the fw_lock.
From: Daniel Wagner
The firmware user helper code tracks the current state of the loading
process via an member of struct firmware_buf and a completion. Let's
encapsulate this simple state machine into struct fw_status. The aim is
to encrease readiblity and reduce the usage of the fw_lock.
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
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:
brcmstb_send_i2c_cmd()
reinit_completion()
...
/* ini
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:
bcm_kona_send_i2c_cmd()
reinit_compl
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:
bcm_iproc_i2c_xfer_single_msg()
reinit_compl
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:
meson_i2c_xfer_msg()
reinit_completion()
...
/* Star
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
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
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 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
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/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->
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 03:10 PM, Steven Rostedt wrote:
Note, Daniel did start work on upstreaming this previously:
http://lkml.kernel.org/r/1430388385-29558-1-git-send-email-daniel.wag...@bmw-carit.de
There are a few things that do need to be cleaned up before this can go
upstream. Please coordinate
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
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
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
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
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
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
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
Since the -Wincompatible-pointer-types is reported as error, alpha
doesn't build anymore. Let's fix it in a minimal way.
fs/binfmt_em86.c:73:35: error: passing argument 2 of ‘copy_strings_kernel’ from
incompatible pointer type [-Werror=incompatible-pointer-types]
On 06/26/2016 02:16 PM, Thorsten Leemhuis wrote:
> On 02.06.2016 15:29, Daniel Wagner wrote:
>>> Hmmm, Ok. I've been running the lockperf test and kernel builds all
>>> day on a filesystem that is identical in shape and size to yours
>>> (i.e. xfs_info output is
301 - 400 of 735 matches
Mail list logo
