Merge latest openocd commits

.checkpatch.conf

@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+--max-line-length=120
+--tab-size=4
+--show-types
+--strict
+
+--typedefsfile tools/scripts/typedefs.txt
+
+--ignore AVOID_EXTERNS
+--ignore BLOCK_COMMENT_STYLE
+--ignore COMPLEX_MACRO
+--ignore CONST_STRUCT
+--ignore ENOSYS
+--ignore FILE_PATH_CHANGES
+--ignore GERRIT_CHANGE_ID
+--ignore LINE_SPACING
+--ignore LOGICAL_CONTINUATIONS
+--ignore MACRO_WITH_FLOW_CONTROL
+--ignore PARENTHESIS_ALIGNMENT
+--ignore PREFER_DEFINED_ATTRIBUTE_MACRO
+--ignore PREFER_FALLTHROUGH
+--ignore PREFER_KERNEL_TYPES
+--ignore SPLIT_STRING
+--ignore SSCANF_TO_KSTRTO
+--ignore SWITCH_CASE_INDENT_LEVEL
+--ignore TRACING_LOGGING
+--ignore VOLATILE

.gitignore

@@ -11,9 +11,9 @@
 *.la
 *.in
 
-# generated source files
-src/jtag/minidriver_imp.h
-src/jtag/jtag_minidriver.h
+# coverage files (gcov)
+*.gcda
+*.gcno
 
 # OpenULINK driver files generated by SDCC
 src/jtag/drivers/OpenULINK/*.rel
@@ -68,7 +68,6 @@ doxygen
 doxygen.log
 Doxyfile
 libtool
-*-libtool
 Makefile
 !contrib/loaders/**/Makefile
 stamp-h1
@@ -85,6 +84,9 @@ patches
 .cproject
 .settings
 
+# VSCode stuff
+.vscode
+
 # Emacs temp files
 *~
 
@@ -101,3 +103,14 @@ tags
 GPATH
 GRTAGS
 GTAGS
+
+# checkpatch script files
+.checkpatch-camelcase.*
+
+# clangd (e.g. for advanced code completion and linting) generates cache files
+# into .cache
+.cache
+
+# A compile_commands.json can be generated using bear and will help tools such
+# as clangd to locate header files and use correct $CFLAGS
+compile_commands.json

.gitmodules

@@ -1,6 +1,3 @@
-[submodule "tools/git2cl"]
-	path = tools/git2cl
-	url = https://git.savannah.nongnu.org/git/git2cl.git
 [submodule "jimtcl"]
 	path = jimtcl
 	url = https://github.com/msteveb/jimtcl.git

.travis.yml

@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0+
+# SPDX-License-Identifier: GPL-2.0-or-later
 # Copyright Marek Vasut <marex@denx.de>
 
 # OpenOCD on Travis CI - https://travis-ci.org/

AUTHORS

@@ -1,12 +1,2 @@
-Dominic Rath <Dominic.Rath@gmx.de>
-Magnus Lundin <lundin@mlu.mine.nu>
-Michael Fischer <fischermi@t-online.de>
-Spencer Oliver <spen@spen-soft.co.uk>
-Carsten Schlote <schlote@vahanus.net>
-Øyvind Harboe <oyvind.harboe@zylin.com>
-Duane Ellis <openocd@duaneellis.com>
-Michael Schwingen <michael@schwingen.org>
-Rick Altherr <kc8apf@users.berlios.de>
-David Brownell <dbrownell@users.sourceforge.net>
-Vincint Palatin <vpalatin@users.berlios.de>
-Zachary T Welch <zw@superlucidity.net>
+Please check the source code files and/or Git history for a list of all authors
+and contributors.

HACKING

@@ -77,6 +77,37 @@ patch:
   src/openocd -s ../tcl -f /path/to/openocd.cfg
   @endcode
 
+- Sparse Static Analyzer
+
+  Using this tool allows identifying some bug in C code.
+  In the future, OpenOCD would use the sparse attribute 'bitwise' to
+  detect incorrect endianness assignments.
+
+  Example usage:
+  @code
+  mkdir build-sparse; cd build-sparse
+  ../configure CC=cgcc CFLAGS="-Wsparse-all -Wno-declaration-after-statement \
+	   -Wno-unknown-attribute -Wno-transparent-union -Wno-tautological-compare \
+       -Wno-vla -Wno-flexible-array-array -D__FLT_EVAL_METHOD__=0"
+  make
+  @endcode
+
+- Code coverage analysis
+
+  By inspecting the code coverage, you can identify potential gaps in your testing
+  and use that information to improve your test scenarios.
+
+  Example usage:
+  @code
+  mkdir build-gcov; cd build-gcov
+  ../configure --enable-gcov [...]
+  make
+  # ... Now execute your test scenarios to collect OpenOCD code coverage ...
+  lcov --capture --directory ./src --output-file openocd-coverage.info
+  genhtml openocd-coverage.info --output-directory coverage_report
+  # ... Open coverage_report/index.html in a web browser ...
+  @endcode
+
 Please consider performing these additional checks where appropriate
 (especially Clang Static Analyzer for big portions of new code) and
 mention the results (e.g. "Valgrind-clean, no new Clang analyzer
@@ -138,11 +169,9 @@ git remote add review https://USERNAME:PASSWORD@review.openocd.org/p/openocd.git
 Gerrit server, even if you plan to use several local branches for different
 topics. It is possible because @c for/master is not a traditional Git
 branch.
-  -# You will need to install this hook, we will look into a better solution:
-@code
-scp -p -P 29418 USERNAME@review.openocd.org:hooks/commit-msg .git/hooks/
-@endcode
-  Or with http only:
+  -# You will need to install this hook to automatically add the
+     field "Change-Id:" in the commit message, as required by Gerrit.
+     We will look into a better solution:
 @code
 wget https://review.openocd.org/tools/hooks/commit-msg
 mv commit-msg .git/hooks
@@ -171,6 +200,8 @@ while(!done) {
 @endcode
    \note use "git add ." before commit to add new files.
 
+   \note check @ref checkpatch for hint about checkpatch script
+
    Commit message template, notice the short first line.
    The field '<c>specify touched area</c>'
    should identify the main part or subsystem the patch touches.
@@ -179,7 +210,9 @@ specify touched area: short comment
 <blank line>
 Longer comments over several lines, explaining (where applicable) the
 reason for the patch and the general idea the solution is based on,
-any major design decisions, etc...
+any major design decisions, etc. Limit each comment line's length to 75
+characters; since 75 it's too short for a URL, you can put the URL in a
+separate line preceded by 'Link: '.
 <blank line>
 Signed-off-by: ...
 @endcode
@@ -215,6 +248,12 @@ doc: fix typos
 @code
 git pull --rebase origin master
 @endcode
+
+-# When you create a new version of an old patch, check that the new patch
+   keeps the same 'Change-Id:' field of the old patch.
+   This allows the Gerrit server to recognize the patch as a new version of
+   the older one and keeps track of the history and the review process.
+
 -# Send the patches to the Gerrit server for review:
 @code
 git push review
@@ -227,6 +266,72 @@ git push review
 
 Further reading: http://www.coreboot.org/Git
 
+@section checkpatch About checkpatch script
+
+OpenOCD source code includes the script checkpatch to let developers to
+verify their patches before submitting them for review (see @ref gerrit).
+
+Every patch for OpenOCD project that is submitted for review on Gerrit
+is tested by Jenkins. Jenkins will run the checkpatch script to analyze
+each patch.
+If the script highlights either errors or warnings, Gerrit will add the
+score "-1" to the patch and maintainers will probably ignore the patch,
+waiting for the developer to send a fixed version.
+
+The script checkpatch verifies the SPDX tag for new files against a very
+short list of license tags.
+If the license of your contribution is not listed there, but compatible
+with OpenOCD license, please alert the maintainers or add the missing
+license in the first patch of your patch series.
+
+The script checkpatch has been originally developed for the Linux kernel
+source code, thus includes specific tests and checks related to Linux
+coding style and to Linux code structure. While the script has been
+adapted for OpenOCD specificities, it still includes some Linux related
+test. It is then possible that it triggers sometimes some <em>false
+positive</em>!
+
+If you think that the error identified by checkpatch is a false
+positive, please report it to the openocd-devel mailing list or prepare
+a patch for fixing checkpatch and send it to Gerrit for review.
+
+\attention The procedure below is allowed only for <em>exceptional
+cases</em>. Do not use it to submit normal patches.
+
+There are <em>exceptional cases</em> in which you need to skip some of
+the tests from checkpatch in order to pass the approval from Gerrit.
+
+For example, a patch that modify one line inside a big comment block
+will not show the beginning or the end of the comment block. This can
+prevent checkpatch to detect the comment block. Checkpatch can wrongly
+consider the modified comment line as a code line, triggering a set of
+false errors.
+
+Only for <em>exceptional cases</em>, it is allowed to submit patches
+to Gerrit with the special field 'Checkpatch-ignore:' in the commit
+message. This field will cause checkpatch to ignore the error types
+listed in the field, only for the patch itself.
+For errors in the commit message, the special field has to be put in
+the commit message before the line that produces the error.
+The special field must be added <em>before</em> the 'Signed-off-by:'
+line, otherwise it is ignored.
+To ignore multiple errors, either add multiple lines with the special
+field or add multiple error types, separated by space or commas, in a
+single line.
+The error type is printed by checkpatch on failure.
+For example the names of Windows APIs mix lower and upper case chars,
+in violation of OpenOCD coding style, triggering a 'CAMELCASE' error:
+@code
+CHECK:CAMELCASE: Avoid CamelCase: <WSAGetLastError>
+#96105: FILE: src/helper/log.c:505:
++       error_code = WSAGetLastError();
+@endcode
+Adding in the commit message of the patch the line:
+@code
+Checkpatch-ignore: CAMELCASE
+@endcode
+will force checkpatch to ignore the CAMELCASE error.
+
 @section timeline When can I expect my contribution to be committed?
 
 The code review is intended to take as long as a week or two to allow