netsniff-ng.git - A high-performance Linux networking toolkit

Age	Commit message (Expand)	Author	Files	Lines
2013-05-10	docs: minor: fix mentioning of Documentation/	Daniel Borkmann	1	-1/+1
2013-04-11	docs: move some of them to the root directory	Daniel Borkmann	1	-0/+833

: failed to download firmware (-12) Which are more or less duplicate, as they print error for the same root cause. With this patch this is all we get now: bootrom 1-3.3.1: failed to download ara_00000126_00001001_fffe0001_ffe5001a_s2l.tftf firmware (-12) Reported-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> 2016-07-22greybus: bootrom: Skip setting timeout in failure path of size requestViresh Kumar1-3/+5 The currently set value of next_request_type in the error path of gb_bootrom_firmware_size_request() is not correct, as it should have been NEXT_REQ_FIRMWARE_SIZE for the failure case (as we should be waiting for another similar request). But, if an error occurs in gb_bootrom_firmware_size_request(), then the ES3 bootrom will never be able to recover from it and send another request. And so there is no point waiting for another request and timing out. Skip doing that in error path. Reported-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> 2016-07-22greybus: vibrator: integrate runtime pmAnn Chen1-4/+34 Integrate greybus drivers with the Linux Kernel RuntimePM framework for vibrator driver. Testing Done: AP side (kernel) can control the vibrator driver with suspend and resume. Signed-off-by: Ann Chen <chen_ann@projectara.com> Reviewed-by: David Lin <dtwlin@google.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> 2016-07-22greybus: control: Print bundle-id in print messagesViresh Kumar1-14/+16 The new power management specific operations added to the control protocol do not print the bundle-id in the error messages and it is not possible to identify which bundle-id the operation failed for. Fix that and do minor rewriting of the print messages to make them more readable. Tested on EVT 2.0 with gpbridge-test module. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Sandeep Patil <sspatil@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> 2016-07-22greybus: operation: print id when synchronous operation timeoutDavid Lin1-2/+2 In case of a synchronous operation timeout error, it's helpful for purpose of debugging to print the operation id in the error message, so that we know if the response is received at a later time after operation time out. Testing Done: - Observe the error message below when response comes later after operation timeout: [ 792.973978] greybus greybus1: 0/0:0: synchronous operation id 0x0005 of type 0x21 failed: -110 [ 800.646694] greybus greybus1: 0/0:0: unexpected response id 0x0005 received Signed-off-by: David Lin <dtwlin@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> 2016-07-22greybus: audio: Avoid using ARA keywordVaibhav Agarwal