log_csv_error(int len, int err)
-{
- fprintf(stderr, "unable to write %d bytes to csv %s\n", len,
- strerror(err));
-}
-
int format_output(struct loopback_test *t,
struct loopback_results *r,
const char *dev_name,
Reviewed
On 04/05/2019 18:10, Srinivas Kandagatla wrote:
Normally I don't take patches that are sent after rc5 into next merge
window. Unless there is an urgent fix. In this case I will be applying
these series to nvmem next branch once rc1 is released for 5.3 merge
window.
Great, that'll done fine Sr
On 04/05/2019 09:39, Greg KH wrote:
On Fri, May 03, 2019 at 05:53:37PM +0100, Bryan O'Donoghue wrote:
V6 RESEND:
- Adding Greg to sender list. Greg looks like you are the right person to
apply this.
$ ./scripts/get_maintainer.pl --file drivers/nvmem/imx-ocotp.c
Srinivas Kanda
Add compatible for i.MX8MM as per arch/arm64/boot/dts/freescale/imx8mm.dtsi
Signed-off-by: Bryan O'Donoghue
Cc: Rob Herring
Reviewed-by: Leonard Crestez
---
Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devic
256 registers. We map the entire putative
256 OTP registers.
Signed-off-by: Bryan O'Donoghue
---
drivers/nvmem/imx-ocotp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index 2c5009691dd6..189fd5f334f4 100644
--- a/drivers/
sures that the relevant field is read and written back to the
timing register.
Fixes: 0642bac7da42 ("nvmem: imx-ocotp: add write support")
Signed-off-by: Bryan O'Donoghue
Reviewed-by: Leonard Crestez
---
drivers/nvmem/imx-ocotp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
ero.
This patch inherits the u-boot timings for the OCOTP_TIMING calculation on
the i.MX6 and i.MX8. Those timings are known to work and critically specify
values such as STROBE_PROG as a minimum timing.
Fixes: 0642bac7da42 ("nvmem: imx-ocotp: add write support")
Signed-off-by: Bryan O&#x
respective RSVD0 bits and
ignore a write-back of zero where i.MX8 will make use of the full range.
This patch expands the bit-field definition for all users to eight bits,
which is safe due to RSVD0 being a no-op for the i.MX6 and i.MX7.
Signed-off-by: Bryan O'Donoghue
Reviewed-by: Leonard Cr
failure state.
Bryan O'Donoghue (5):
nvmem: imx-ocotp: Elongate OCOTP_CTRL ADDR field to eight bits
nvmem: imx-ocotp: Ensure WAIT bits are preserved when setting timing
nvmem: imx-ocotp: Change TIMING calculation to u-boot algorithm
nvmem: imx-ocotp: Add i.MX8MM support
dt-bindings
On 06/12/2018 16:23, Greg Kroah-Hartman wrote:
On Thu, Dec 06, 2018 at 04:14:53PM +, Bryan O'Donoghue wrote:
On 06/12/2018 15:05, Greg Kroah-Hartman wrote:
On Thu, Dec 06, 2018 at 09:43:46AM +0000, Bryan O'Donoghue wrote:
On 05/12/2018 21:00, Sicilia Cristian wrote:
It doesn&#x
On 06/12/2018 15:05, Greg Kroah-Hartman wrote:
On Thu, Dec 06, 2018 at 09:43:46AM +, Bryan O'Donoghue wrote:
On 05/12/2018 21:00, Sicilia Cristian wrote:
It doesn't change the result string
So why do it then ?
Because it is easier to read this way and odds are checkpatch
On 05/12/2018 21:00, Sicilia Cristian wrote:
It doesn't change the result string
So why do it then ?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On 04/12/2018 20:58, Cristian Sicilia wrote:
Some concatenated strings are now spaced.
Signed-off-by: Cristian Sicilia
---
drivers/staging/greybus/loopback.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/staging/greybu
On 23/10/2018 17:20, Rasmus Villemoes wrote:
On 2018-10-11 01:03, Bryan O'Donoghue wrote:
On 05/10/2018 15:28, Rasmus Villemoes wrote:
Signed-off-by: Rasmus Villemoes
---
I have no idea if the performance matters (it probably doesn't). Feel
free to ignore this and the follow
On 05/10/2018 15:28, Rasmus Villemoes wrote:
Since lbid isn't mentioned anywhere else in greybus/, it's hard to
figure out how it was meant to be used. It does seem like entirely
dead (write-only) code.
yep, dead code
Reviewed-by: Bryan
On 05/10/2018 15:28, Rasmus Villemoes wrote:
Signed-off-by: Rasmus Villemoes
---
I have no idea if the performance matters (it probably doesn't). Feel
free to ignore this and the followup cleanup.
What's the problem you're fixing here ?
Is it tested ?
__
r
Cc: Greg Kroah-Hartman
Cc: Vaibhav Agarwal
Cc: Mark Greer
Cc: Viresh Kumar
Cc: Rui Miguel Silva
Cc: David Lin
Cc: "Bryan O'Donoghue"
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/greybus/arche-apb-ctrl.c| 2 --
drivers/staging/greybus/arche-platform.c
asynchronous operation error. This patch fixes
that omission.
Fixes: 12927835d211 ("greybus: loopback: Add asynchronous bi-directional
support")
Signed-off-by: Bryan O'Donoghue
Reported-by: Mitch Tasman
Cc: Johan Hovold
Cc: Alex Elder
Cc: Greg Kroah-Hartman
Cc: Mitch Tasman
Cc: gre
Asynchronous operation completion handler's lives are made easier if there
is a generic pointer that can store private data associated with the
operation. This patch adds a pointer field to struct gb_operation and
get/set methods to access that pointer.
Signed-off-by: Bryan O'Donoghue
the cringe-worthy 'pending' flag. The completion callback
triggered by operation.c will provide an authoritative result code -
including -ETIMEDOUT for asynchronous operations.
Signed-off-by: Bryan O'Donoghue
Cc: Johan Hovold
Cc: Alex Elder
Cc: Greg Kroah-Hartman
Cc: Kees
ult several members of the per connection struct gb_loopback are racy.
The solution is restoring the old location of mutex_unlock(&gb->mutex) as
it was in commit d9fb3754ecf8 ("greybus: loopback: Relax locking during
loopback operations").
Fixes: 8e1d6c336d74 ("greybus: loopback: dr
rds with err, two stones (no aggression to
birds intended) namely:
- Converting over to the core asynchronous API
- Getting rid of the timer code in loopback which will unblock what Kees is
doing.
Bryan O'Donoghue (4):
staging: greybus: loopback: Hold per-connection mutex across
operat
asynchronous operation error. This patch fixes
that omission.
Fixes: 12927835d211 ("greybus: loopback: Add asynchronous bi-directional
support")
Signed-off-by: Bryan O'Donoghue
Reported-by: Mitch Tasman
Cc: Johan Hovold
Cc: Alex Elder
Cc: Greg Kroah-Hartman
Cc: Mitch Tasman
Cc: gre
Asynchronous operation completion handler's lives are made easier if there
is a generic pointer that can store private data associated with the
operation. This patch adds a pointer field to struct gb_operation and
get/set methods to access that pointer.
Signed-off-by: Bryan O'Donoghue
the cringe-worthy 'pending' flag. The completion callback
triggered by operation.c will provide an authoritative result code -
including -ETIMEDOUT for asynchronous operations.
Signed-off-by: Bryan O'Donoghue
Cc: Johan Hovold
Cc: Alex Elder
Cc: Greg Kroah-Hartman
Cc: Kees
ult several members of the per connection struct gb_loopback are racy.
The solution is restoring the old location of mutex_unlock(&gb->mutex) as
it was in commit d9fb3754ecf8 ("greybus: loopback: Relax locking during
loopback operations").
Fixes: 8e1d6c336d74 ("greybus: loopback: dr
the core asynchronous API
- Getting rid of the timer code in loopback which will unblock what Kees is
doing.
Bryan O'Donoghue (4):
staging: greybus: loopback: Hold per-connection mutex across
operations
staging: greybus: loopback: Fix iteration count on async path
staging: greybus: op
On 05/11/17 12:24, Johan Hovold wrote:
+ if (error) {
gb->error++;
+ gb->iteration_count++;
+ }
And this looks like an unrelated bug fix that should go in it's own
patch, right?
I pinged t
the cringe-worthy 'pending' flag. The completion callback
triggered by operation.c will provide an authoritative result code -
including -ETIMEDOUT for asynchronous operations.
Signed-off-by: Bryan O'Donoghue
Cc: Johan Hovold
Cc: Alex Elder
Cc: Greg Kroah-Hartman
Cc: Kees Co
Asynchronous operation completion handler's lives are made easier if there
is a generic pointer that can store private data associated with the
operation. This patch adds a pointer field to operation.h and get/set
methods to access that pointer.
Signed-off-by: Bryan O'Donoghue
Cc: Jo
two birds with err, two stones (no aggression to
birds intended) namely:
- Converting over to the core asynchronous API
- Getting rid of the timer code in loopback which will unblock what Kees is
doing.
Bryan O'Donoghue (2):
staging: greybus: operation: add private data with get/set acce
if (gb->ts.tv_usec == 0 && gb->ts.tv_sec == 0)
- do_gettimeofday(&gb->ts);
+ if (ktime_to_ns(gb->ts) == 0)
+ gb->ts = ktime_get();
mutex_unlock(&gb->mutex);
/* Else
On 03/11/17 20:21, Kees Cook wrote:
On Mon, Oct 30, 2017 at 5:05 PM, Kees Cook wrote:
On Mon, Oct 30, 2017 at 5:01 PM, wrote:
There's a separate change to loopback.c an old patch ARAIR that will subtract
use of the timer from loopback.c so you can skip that bit.
Okay, cool. Since the op
On 02/11/17 14:32, Arnd Bergmann wrote:
This driver is the only one using the deprecated timeval_to_ns()
helper. Changing it from do_gettimeofday() to ktime_get() makes
the code more efficient, more robust against concurrent
settimeofday(), more accurate and lets us get rid of that helper
in the
;gb->kfifo_lat);
out_conn:
device_unregister(dev);
@@ -1302,7 +1282,6 @@ static void gb_loopback_disconnect(struct gb_bundle
*bundle)
kthread_stop(gb->task);
kfifo_free(&gb->kfifo_lat);
- kfifo_free(&gb->kfifo_ts);
gb_connection_latency_tag_disable(gb
On 30/10/17 11:38, Johan Hovold wrote:
On Mon, Oct 30, 2017 at 11:35:50AM +, Bryan O'Donoghue wrote:
On 30/10/17 11:32, Johan Hovold wrote:
The right thing to do here is to respin your patch from last year which
converts the loopback driver to use the timeout handling in greybus
On 30/10/17 11:32, Johan Hovold wrote:
The right thing to do here is to respin your patch from last year which
converts the loopback driver to use the timeout handling in greybus
core.
Actually I wasn't clear if you wanted to to that yourself aswell as the
rest if it.
But sure I can do that
On 24/10/17 15:49, Kees Cook wrote:
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Greg Kroah-Hartman
Cc: "Bryan O'Donoghue"
Cc: J
On 24/10/17 14:14, Kees Cook wrote:
On Tue, Oct 24, 2017 at 5:52 AM, Bryan O'Donoghue
wrote:
On 24/10/17 13:47, Kees Cook wrote:
On Tue, Oct 24, 2017 at 2:40 AM, Bryan O'Donoghue
wrote:
On 24/10/17 10:35, Bryan O'Donoghue wrote:
On 24/10/17 09:25, Kees Cook wrote:
In
On 24/10/17 13:47, Kees Cook wrote:
On Tue, Oct 24, 2017 at 2:40 AM, Bryan O'Donoghue
wrote:
On 24/10/17 10:35, Bryan O'Donoghue wrote:
On 24/10/17 09:25, Kees Cook wrote:
In preparation for unconditionally passing the struct timer_list pointer
to
all timer callbacks, switch to
On 24/10/17 09:25, Kees Cook wrote:
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Greg Kroah-Hartman
Cc: "Bryan O'Donoghue"
Cc: J
On 24/10/17 10:35, Bryan O'Donoghue wrote:
On 24/10/17 09:25, Kees Cook wrote:
In preparation for unconditionally passing the struct timer_list
pointer to
all timer callbacks, switch to using the new timer_setup() and
from_timer()
to pass the timer pointer explicitly.
Cc: Greg Kroah-Ha
issue.
Signed-off-by: Shreeya Patel
Reviewed-by: Bryan O'Donoghue
---
Changes in v2:
-Rebase the patch.
drivers/staging/greybus/tools/loopback_test.c | 35 ---
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/greybus/
On 18/07/17 11:56, kart...@techveda.org wrote:
From: Karthik Tummala
Enclosed multiple macro statements in a do - while loop as per kernel
coding standard, pointed by checkpatch.
Signed-off-by: Karthik Tummala
---
drivers/staging/greybus/loopback.c | 10 ++
1 file changed, 6 insert
On 15/05/17 17:10, Johan Hovold wrote:
On Mon, May 15, 2017 at 04:17:55PM +0100, Bryan O'Donoghue wrote:
On 15/05/17 15:26, Johan Hovold wrote:
Remove the remaining timesync bits that were left in the arche platform
driver and which prevented the driver from being compiled.
On 15/05/17 15:26, Johan Hovold wrote:
Remove the remaining timesync bits that were left in the arche platform
driver and which prevented the driver from being compiled.
Fixes: bdfb95c4baab ("staging: greybus: remove timesync protocol support")
Signed-off-by: Johan Hovold
I thought the plan w
On 15/02/17 00:09, Tobin C. Harding wrote:
> Greybus currently uses strncpy() coupled with a check for '\0' on the
> last byte of various buffers. strncpy() is passed size parameter equal
> to the size of the buffer in all instances. If the source string is
> larger than the destination buffer the
On 08/02/17 14:16, Johan Hovold wrote:
> On Wed, Feb 08, 2017 at 02:05:15PM +0000, Bryan O'Donoghue wrote:
>> On 08/02/17 11:55, Johan Hovold wrote:
>>> On Wed, Feb 08, 2017 at 11:43:57AM +, Bryan O'Donoghue wrote:
>>>> On 08/02/17 09:43, Johan Hovold wr
On 08/02/17 11:55, Johan Hovold wrote:
> On Wed, Feb 08, 2017 at 11:43:57AM +0000, Bryan O'Donoghue wrote:
>> On 08/02/17 09:43, Johan Hovold wrote:
>>> On Tue, Feb 07, 2017 at 02:31:04PM +, Bryan O'Donoghue wrote:
>>>> On 07/02/17 14:19, Johan Hovold wr
On 08/02/17 09:43, Johan Hovold wrote:
> On Tue, Feb 07, 2017 at 02:31:04PM +0000, Bryan O'Donoghue wrote:
>> On 07/02/17 14:19, Johan Hovold wrote:
>>> On Mon, Jan 23, 2017 at 01:04:14PM +0100, Johan Hovold wrote:
>>>> Add a struct timer_list to struct gb_
On 07/02/17 14:19, Johan Hovold wrote:
> On Mon, Jan 23, 2017 at 01:04:14PM +0100, Johan Hovold wrote:
>> Add a struct timer_list to struct gb_operation and use that to implement
>> generic operation timeouts.
>>
>> This simplifies the synchronous operation handling somewhat while also
>> providing
On 27/01/17 09:55, Greg Kroah-Hartman wrote:
> On Tue, Jan 24, 2017 at 03:57:54PM +0000, Bryan O'Donoghue wrote:
>> On 24/01/17 15:09, Johan Hovold wrote:
>>
>>> Bryan, if you could consider my review feedback and respin your last
>>> three patches on top of
usleep_range(us_wait, us_wait + 100);
> + else
> + msleep(us_wait / 1000);
> + }
> }
>
> gb_pm_runtime_put_autosuspend(bundle);
>
Makes sense to me, thanks.
Acked-by: Bryan O'Donogh
On 24/01/17 15:09, Johan Hovold wrote:
> Bryan, if you could consider my review feedback and respin your last
> three patches on top of my timeout patch, I think we should be good.
Sure thing
___
devel mailing list
de...@linuxdriverproject.org
http://d
On 23/01/17 15:13, Johan Hovold wrote:
> On Mon, Jan 23, 2017 at 02:32:48PM +0000, Bryan O'Donoghue wrote:
>> On 23/01/17 12:04, Johan Hovold wrote:
>>
>>> +static void gb_operation_timeout(unsigned long arg)
>>> +{
>>> + struct gb_opera
On 23/01/17 12:04, Johan Hovold wrote:
> +static void gb_operation_timeout(unsigned long arg)
> +{
> + struct gb_operation *operation = (void *)arg;
> +
> + if (gb_operation_result_set(operation, -ETIMEDOUT)) {
> + /*
> + * A stuck request message will be cancelled
On January 9, 2017 11:57:36 AM GMT+00:00, Johan Hovold wrote:
>On Mon, Jan 09, 2017 at 11:29:50AM +0000, Bryan O'Donoghue wrote:
>> On January 9, 2017 11:19:09 AM GMT+00:00, Johan Hovold
> wrote:
>> >On Sun, Jan 08, 2017 at 03:27:18PM +, Bryan O'Donoghue w
On January 9, 2017 11:19:09 AM GMT+00:00, Johan Hovold wrote:
>On Sun, Jan 08, 2017 at 03:27:18PM +0000, Bryan O'Donoghue wrote:
>> commit e854ff58ed70 ("greybus: loopback: add runtime pm support")
>> introduces pm runtime support to the loopback code. If a
>
removal of gb_dev.root.
This series fixes both issues.
Bryan O'Donoghue (2):
staging: greybus: loopback: fix gb_pm_runtime_get_sync error handling
staging: greybus: loopback: fix oops on rmmod gb_loopback
drivers/staging/greybus/loopback.c | 6 ++
1 file changed, 2 insertions(+), 4 dele
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/loopback.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/staging/greybus/loopback.c
index 83f3b9f..88d4f5c 100644
--- a/drivers/staging/greybus/loopback.c
+++ b/drive
n will not re-run gb_loopback_disconnect().
On project Ara the second module removal flow was the only practiced flow
hence it's only now in gbsim where we have more freedom to rmmod that this
bug is apparent. The fix itself is pretty straight-forward.
Signed-off-by: Bryan O'Donogh
ed-off-by: Greg Kroah-Hartman
> ---
>
> Sorry Bryan, I know it was a lot of work, and it's a great protocol and
> implementation, but it never made it into a device :(
Kill it.
One less turd to polish.
Acked-by: Bryan O'Donoghue
_
quest_send_async_timeout ->
gb_operation_request_send_async() - Greg
Using existing gb_operation_completion_wq - Viresh
Split out gb_operation_cancel() - timeout need not wait synchronously on
cancellation queue - Bryan
Move timeout to work-queue - Greg/Viresh
cancel timeout workqueue
wn
special timeout mechanisms, it just waits for operation.c to provide it
with the appropriate status code for a given operation.
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/operation.c | 66 +
drivers/staging/greybus/operation.h | 5 +++
2 fi
Asynchronous operation completion handler's lives are made easier if there
is a generic pointer that can store private data associated with the
operation. This patch adds a pointer field to operation.h and get/set
methods to access that pointer.
Signed-off-by: Bryan O'Donoghue
--
opposed to one jiffy.
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/loopback.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/staging/greybus/loopback.c
index 5cdd8d0..83f3b9f 100644
--- a/drivers/st
sec: min=0 max=0 average=0.00 jitter=0
gbphy-latency usec:min=0 max=0 average=0.00 jitter=0
Signed-off-by: Bryan O'Donoghue
Signed-off-by: Mitchell Tasman
---
drivers/staging/greybus/loopback.c | 167 +++--
1 file changed, 32 insertions(+), 135 del
On 03/01/17 10:17, Axel Haslam wrote:
> as i see it, a successful test means:
> 1- each interfaces should send an event upon completion.
yes
> 2- the iteration count should equal iteration_max on each of the interfaces
yes
> what am i missing?
count == max implies the kernel thread is still w
On 02/01/17 17:27, Axel Haslam wrote:
> Hi Bryan,
>
> On Mon, Jan 2, 2017 at 3:32 PM, Johan Hovold wrote:
>> Adding Axel on CC.
>>
>> On Thu, Dec 22, 2016 at 12:37:29AM +, Bryan O'Donoghue wrote:
>>> commit 9250c0ee2626 ("greybus: Loopback_test:
On 02/01/17 16:16, Johan Hovold wrote:
> On Tue, Dec 27, 2016 at 01:01:35PM +0000, Bryan O'Donoghue wrote:
>> Later patches don't want or need to serialize the cancellation of an
>> operation. This patch adds gb_operation_cancel_async() as a simple subset
>> of t
Later patches don't want or need to serialize the cancellation of an
operation. This patch adds gb_operation_cancel_async() as a simple subset
of the existing gb_operation_cancel() sans the synchronous wait on the
cancellation queue.
Signed-off-by: Bryan O'Donoghue
---
drivers/stagi
sec: min=0 max=0 average=0.00 jitter=0
gbphy-latency usec:min=0 max=0 average=0.00 jitter=0
Signed-off-by: Bryan O'Donoghue
Signed-off-by: Mitchell Tasman
---
drivers/staging/greybus/loopback.c | 167 +++--
1 file changed, 32 insertions(+), 135 del
Asynchronous operation completion handler's lives are made easier if there
is a generic pointer that can store private data associated with the
operation. This patch adds a pointer field to operation.h and get/set
methods to access that pointer.
Signed-off-by: Bryan O'Donoghue
--
need not wait synchronously on
cancellation queue - Bryan
Move timeout to work-queue - Greg/Viresh
cancel timeout workqueue @ operation completion point - Viresh/Bryan
Bryan O'Donoghue (5):
staging: greybus: operation: add asynchronous gb_operation_cancel
staging: greybus: operation: add g
opposed to one jiffy.
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/loopback.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/staging/greybus/loopback.c
index 5cdd8d0..83f3b9f 100644
--- a/drivers/st
wn
special timeout mechanisms, it just waits for operation.c to provide it
with the appropriate status code for a given operation.
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/operation.c | 66 +
drivers/staging/greybus/operation.h | 5 +++
2 fi
printout - Johan
Bryan O'Donoghue (2):
staging: greybus: loopback: use gb_loopback_async_wait_all don't spin
staging: greybus: loopback_test: Fix race preventing test completion
drivers/staging/greybus/loopback.c| 11 +++
drivers/staging/greybus/tools/loopback_t
nuing when the send_count == iteration_max and go to sleep until
there's something worthwhile to-do.
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/loopback.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/
rl-c.
This patch fixes the race by ensuring the poll() loop waits for all active
Interfaces to complete - as opposed to the first active Interface before
breaking the loop.
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/tools/loopback_test.c | 10 +-
1 file changed, 1 in
"%s: failed to clear host cport: %d\n",
>
Looks obviously correct to me i.e. it's never a bad idea to sanity check
a function pointer before dereferencing it.
Reviewed-by: Bryan O'Donoghue
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On 20/12/16 10:28, Johan Hovold wrote:
> On Tue, Dec 20, 2016 at 01:12:08AM +0000, Bryan O'Donoghue wrote:
>> Currently the greybus-loopback thread logic spins around waiting for
>> send_count == iteration_max which on real hardware doesn't make a
>> differ
rl-c.
This patch fixes the race by ensuring the poll() loop waits for all active
Interfaces to complete - as opposed to the first active Interface before
breaking the loop.
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/tools/loopback_test.c | 10 +-
1 file changed, 1 in
Two simple patches here resulting from using greybus on gbsim and
developing support for async. I found a bug in the user-space tool and
while doing that decided to update the kernel thread to be better behaved
when waiting for test completions.
Bryan O'Donoghue (2):
staging: greybus: loo
nuing when the send_count == iteration_max and go to sleep until
there's something worthwhile to-do.
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/loopback.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/
On Sat, 2016-11-26 at 22:50 +0100, Andrea Ghittino wrote:
> Fixes greybus user/groups permission style warnings
> found by checkpatch.pl tool
>
> Signed-off-by: Andrea Ghittino
> ---
> diff --git a/drivers/staging/greybus/camera.c
> b/drivers/staging/greybus/camera.c
> index 1c5b41a..4424f63 100
On Tue, 2016-11-22 at 13:17 +0100, Johan Hovold wrote:
> [ Resend with Greg's address fixed. ]
>
> On Mon, Nov 21, 2016 at 05:22:13PM +, Bryan O'Donoghue wrote:
> >
> > McCOY: You've got him, Jim! You've got him where you want him.
> Hey, I
meout to work-queue - Greg/Viresh
cancel timeout workqueue @ operation completion point - Viresh/Bryan
Bryan O'Donoghue (6):
staging: greybus/operation: add delayed worker for async timeouts
staging: greybus/operation: add generic asynchronous operation support
staging: greybus/
just waits for operation.c to provide it with the
appropriate status code for a given operation.
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/operation.c | 50 +
drivers/staging/greybus/operation.h | 4 +++
2 files changed, 54 insertions(+
This patch adds a delayed workqueue which will be used in later patches to
provide a timeout mechanism for asynchronous operations.
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/operation.c | 15 +++
drivers/staging/greybus/operation.h | 1 +
2 files change
the controlling sysfs interface.
This patch fixes by holding gb->mutex between gb->send_count ==
gb->iteration_max and udelay() divide - in the sending kthread. Testing on
DVT shows there's no adverse performance impact.
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/
opposed to one jiffy.
Signed-off-by: Bryan O'Donoghue
---
drivers/staging/greybus/loopback.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/staging/greybus/loopback.c
index 3dd26af..de17901 100644
--- a/drivers/st
sec: min=0 max=0 average=0.00 jitter=0
gbphy-latency usec:min=0 max=0 average=0.00 jitter=0
Signed-off-by: Bryan O'Donoghue
Signed-off-by: Mitchell Tasman
---
drivers/staging/greybus/loopback.c | 172 -
1 file changed, 35 insertions(+), 137 del
Asynchronous operation completion handler's lives are made easier if there
is a generic pointer that can store private data associated with the
operation. This patch adds a pointer field to operation.h and get/set
methods to access that pointer.
Signed-off-by: Bryan O'Donoghue
--
On Mon, 2016-10-31 at 08:50 -0500, Alex Elder wrote:
> My suggestion is to create a majordomo list:
> grey...@kernel.org
I think this is a great idea. We need a forum where we can discuss
changes to the specification and the firmware - it would be a bit anti-
social to be blitzing de...@driver
94 matches
Mail list logo
