Skip to content
Snippets Groups Projects
  1. Oct 25, 2020
  2. Oct 21, 2020
  3. Oct 20, 2020
  4. Oct 17, 2020
  5. Oct 16, 2020
  6. Oct 15, 2020
    • Sumera Priyadarsini's avatar
      coccinelle: iterators: Add for_each_child.cocci script · 82c2d813
      Sumera Priyadarsini authored
      
      While iterating over child nodes with the for_each functions, if
      control is transferred from the middle of the loop, as in the case
      of a break or return or goto, there is no decrement in the
      reference counter thus ultimately resulting in a memory leak.
      
      Add this script to detect potential memory leaks caused by
      the absence of of_node_put() before break, goto, or, return
      statements which transfer control outside the loop.
      
      Signed-off-by: default avatarSumera Priyadarsini <sylphrenadin@gmail.com>
      Signed-off-by: default avatarJulia Lawall <julia.lawall@inria.fr>
      82c2d813
    • Mauro Carvalho Chehab's avatar
      scripts: kernel-doc: try to use c:function if possible · 6e9e4158
      Mauro Carvalho Chehab authored
      There are a few namespace clashes by using c:macro everywhere:
      
      basically, when using it, we can't have something like:
      
      	.. c:struct:: pwm_capture
      
      	.. c:macro:: pwm_capture
      
      So, we need to use, instead:
      
      	.. c:function:: int pwm_capture (struct pwm_device * pwm, struct pwm_capture * result, unsigned long timeout)
      
      for the function declaration.
      
      The kernel-doc change was proposed by Jakob Lykke Andersen here:
      
      	https://github.com/jakobandersen/linux_docs/commit/6fd2076ec001cca7466857493cd678df4dfe4a65
      
      
      
      Although I did a different implementation.
      
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      6e9e4158
    • Mauro Carvalho Chehab's avatar
      scripts: kernel-doc: fix line number handling · 5ef09c96
      Mauro Carvalho Chehab authored
      
      Address several issues related to pointing to the wrong line
      number:
      
      1) ensure that line numbers will always be initialized
      
         When section is the default (Description), the line number
         is not initializing, producing this:
      
      	$ ./scripts/kernel-doc --enable-lineno ./drivers/media/v4l2-core/v4l2-mem2mem.c|less
      
      	**Description**
      
      	#define LINENO 0
      	In case of streamoff or release called on any context,
      	1] If the context is currently running, then abort job will be called
      	2] If the context is queued, then the context will be removed from
      	   the job_queue
      
        Which is not right. Ensure that the line number will always
        be there. After applied, the result now points to the right location:
      
      	**Description**
      
      	#define LINENO 410
      	In case of streamoff or release called on any context,
      	1] If the context is currently running, then abort job will be called
      	2] If the context is queued, then the context will be removed from
      	   the job_queue
      
      2) The line numbers for function prototypes are always + 1,
         because it is taken at the line after handling the prototype.
         Change the logic to point to the next line after the /** */
         block;
      
      3) The "DOC:" line number should point to the same line as this
         markup is found, and not to the next one.
      
      Probably part of the issues were due to a but that was causing
      the line number offset to be incremented by one, if --export
      were used.
      
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      5ef09c96
    • Mauro Carvalho Chehab's avatar
      scripts: kernel-doc: allow passing desired Sphinx C domain dialect · 93351d41
      Mauro Carvalho Chehab authored
      
      When kernel-doc is called via kerneldoc.py, there's no need to
      auto-detect the Sphinx version, as the Sphinx module already
      knows it. So, add an optional parameter to allow changing the
      Sphinx dialect.
      
      As kernel-doc can also be manually called, keep the auto-detection
      logic if the parameter was not specified. On such case, emit
      a warning if sphinx-build can't be found at PATH.
      
      I ended using a suggestion from Joe for using a more readable
      regex, instead of using a complex one with a hidden group like:
      
      	m/^(\d+)\.(\d+)(?:\.?(\d+)?)/
      
      in order to get the optional <patch> argument.
      
      Thanks-to: Joe Perches <joe@perches.com>
      Suggested-by: default avatarJonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      93351d41
    • Mauro Carvalho Chehab's avatar
      scripts: kernel-doc: don't mangle with parameter list · ed8348e2
      Mauro Carvalho Chehab authored
      
      While kernel-doc needs to parse parameters in order to
      identify its name, it shouldn't be touching the type,
      as parsing it is very difficult, and errors happen.
      
      One current error is when parsing this parameter:
      
      	const u32 (*tab)[256]
      
      Found at ./lib/crc32.c, on this function:
      
      	u32 __pure crc32_be_generic (u32 crc, unsigned char const *p, size_t len, const u32 (*tab)[256], u32 polynomial);
      
      The current logic mangles it, producing this output:
      
      	const u32 ( *tab
      
      That's something that it is not recognizeable.
      
      So, instead, let's push the argument as-is, and use it
      when printing the function prototype and when describing
      each argument.
      
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      ed8348e2
    • Mauro Carvalho Chehab's avatar
      scripts: kernel-doc: fix typedef identification · 47bcacfd
      Mauro Carvalho Chehab authored
      
      Some typedef expressions are output as normal functions.
      
      As we need to be clearer about the type with Sphinx 3.x,
      detect such cases.
      
      While here, fix a wrongly-indented block.
      
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      47bcacfd
    • Mauro Carvalho Chehab's avatar
      scripts: kernel-doc: reimplement -nofunction argument · eab795dd
      Mauro Carvalho Chehab authored
      
      Right now, the build system doesn't use -nofunction, as
      it is pretty much useless, because it doesn't consider
      the other output modes (extern, internal), working only
      with all.
      
      Also, it is limited to exclude functions.
      
      Re-implement it in order to allow excluding any symbols from
      the document output, no matter what mode is used.
      
      The parameter was also renamed to "-nosymbol", as it express
      better its meaning.
      
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      eab795dd
    • Mauro Carvalho Chehab's avatar
      scripts: kernel-doc: fix troubles with line counts · dbe8ba00
      Mauro Carvalho Chehab authored
      
      There's currently a bug with the way kernel-doc script
      counts line numbers that can be seen with:
      
      	$ ./scripts/kernel-doc -rst  -enable-lineno include/linux/math64.h >all && ./scripts/kernel-doc -rst -internal -enable-lineno include/linux/math64.h >int && diff -U0 int all
      
      	--- int	2020-09-28 12:58:08.927486808 +0200
      	+++ all	2020-09-28 12:58:08.905486845 +0200
      	@@ -1 +1 @@
      	-#define LINENO 27
      	+#define LINENO 26
      	@@ -3 +3 @@
      	-#define LINENO 16
      	+#define LINENO 15
      	@@ -9 +9 @@
      	-#define LINENO 17
      	+#define LINENO 16
      	...
      
      This is happening with perl version 5.30.3, but I'm not
      so sure if this is a perl bug, or if this is due to something
      else.
      
      In any case, fixing it is easy. Basically, when "-internal"
      parameter is used, the process_export_file() function opens the
      handle "IN". This makes the line number to be incremented, as the
      handler for the main open is also "IN".
      
      Fix the problem by using a different handler for the
      main open().
      
      While here, add a missing close for it.
      
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      dbe8ba00
    • Mauro Carvalho Chehab's avatar
      scripts: kernel-doc: use a less pedantic markup for funcs on Sphinx 3.x · e3ad05fe
      Mauro Carvalho Chehab authored
      Unfortunately, Sphinx 3.x parser for c functions is too pedantic:
      
      	https://github.com/sphinx-doc/sphinx/issues/8241
      
      
      
      While it could be relaxed with some configurations, there are
      several corner cases that it would make it hard to maintain,
      and will require teaching conf.py about several macros.
      
      So, let's instead use the :c:macro notation. This will
      produce an output that it is not as nice as currently, but it
      should still be acceptable, and will provide cross-references,
      removing thousands of warnings when building with newer
      versions of Sphinx.
      
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      e3ad05fe
    • Mauro Carvalho Chehab's avatar
      scripts: kernel-doc: make it more compatible with Sphinx 3.x · efa44475
      Mauro Carvalho Chehab authored
      
      With Sphinx 3.x, the ".. c:type:" tag was changed to accept either:
      
      	.. c:type:: typedef-like declaration
      	.. c:type:: name
      
      Using it for other types (including functions) don't work anymore.
      
      So, there are newer tags for macro, enum, struct, union, and others,
      which doesn't exist on older versions.
      
      Add a check for the Sphinx version and change the produced tags
      accordingly.
      
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      efa44475
    • Mauro Carvalho Chehab's avatar
      scripts: kernel-doc: add support for typedef enum · d38c8cfb
      Mauro Carvalho Chehab authored
      
      The PHY kernel-doc markup has gained support for documenting
      a typedef enum.
      
      However, right now the parser was not prepared for it.
      
      So, add support for parsing it.
      
      Fixes: 4069a572 ("net: phy: Document core PHY structures")
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      d38c8cfb
  7. Oct 14, 2020
Loading