As reported by Sphinx:
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_wait_unlocked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1169: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_poll_wait'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1189: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_read'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2669: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_stream_enable'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2734: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_stream_disable'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2820: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_stream_init'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3010: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_read'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3098: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_poll_locked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3129: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_poll'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3152: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_enable_locked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3181: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_disable_locked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3273: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_ioctl'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3296: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_destroy_locked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3321: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_release'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3379: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_open_ioctl_locked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3534: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'read_properties_unlocked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3717: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_open_ioctl'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3760: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_register'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3789: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_unregister'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4009: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_add_config_ioctl'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4162: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_remove_config_ioctl'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4260: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_init'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4423: WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_fini'.
With Sphinx 3, C declarations can't be duplicated anymore,
so let's exclude those from the other internals found on
i915_perf.c file.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Those are already documented at:
Documentation/driver-api/firmware/request_firmware.rst
Including it twice is causing lots of warnings:
./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'.
Declaration is 'request_firmware'.
./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'.
Declaration is 'firmware_request_nowarn'.
./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'.
Declaration is 'request_firmware_direct'.
./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'.
Declaration is 'firmware_request_platform'.
./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'.
Declaration is 'firmware_request_cache'.
./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'.
Declaration is 'request_firmware_into_buf'.
./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/firmware/request_firmware'.
Declaration is 'request_firmware_nowait'.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The usage of :c:type: to reference to a struct member is wrong,
as pointed by Sphinx 3:
./Documentation/driver-api/libata.rst:511: WARNING: Unparseable C cross-reference: 'qc->complete_fn'
Invalid C declaration: Expected end of definition. [error at 2]
qc->complete_fn
--^
Instead, let's use :c:expr: for such purpose.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Which Sphinx 3, :c:type: can't be used anymore for structs,
as this should be used only for typedefs.
Rely on automarkup.py for struct references.
This file has an special case, though: it uses the tag also
to point to an array. Let's use, instead, :c:expr: for such
purpose, as it should do the right thing.
This should fix this warning:
./Documentation/dev-tools/kgdb.rst:875: WARNING: Unparseable C cross-reference: 'kdb_poll_funcs[]'
Invalid C declaration: Expected end of definition. [error at 14]
kdb_poll_funcs[]
--------------^
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Those macros are not doing the right thing with Sphinx 3,
causing parse errors:
./Documentation/driver-api/fpga/fpga-mgr.rst:104: WARNING: Unparseable C cross-reference: 'fpga_manager->state'
Invalid C declaration: Expected end of definition. [error at 12]
fpga_manager->state
------------^
./Documentation/driver-api/fpga/fpga-programming.rst:18: WARNING: Unparseable C cross-reference: 'fpga_region->info'
Invalid C declaration: Expected end of definition. [error at 11]
fpga_region->info
-----------^
./Documentation/driver-api/fpga/fpga-region.rst:62: WARNING: Unparseable C cross-reference: 'fpga_region->bridge_list'
Invalid C declaration: Expected end of definition. [error at 11]
fpga_region->bridge_list
-----------^
./Documentation/driver-api/fpga/fpga-region.rst:62: WARNING: Unparseable C cross-reference: 'fpga_region->get_bridges'
Invalid C declaration: Expected end of definition. [error at 11]
fpga_region->get_bridges
-----------^
Replace them by :c:expr:, with does what's desired.
Reviewed-by: Moritz Fischer <mdf@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Some such markups are invalid, as reported by Sphinx:
./Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3317: WARNING: Unparseable C cross-reference: 'snd_rawmidi_transmit*'
Invalid C declaration: Expected end of definition. [error at 20]
snd_rawmidi_transmit*
--------------------^
./Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3917: WARNING: Unparseable C cross-reference: 'copy_from/to_user'
Invalid C declaration: Expected end of definition. [error at 9]
copy_from/to_user
---------^
The first case seems to be better replaced by a literal.
For the second one, let's generate cross-references, by
spliting it in two.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The :c:type macros are not used properly there, as reported
by Sphinx 3:
./Documentation/block/blk-mq.rst:112: WARNING: Unparseable C cross-reference: 'hctx->dispatch'
Invalid C declaration: Expected end of definition. [error at 4]
hctx->dispatch
----^
Also, they won't be generating any cross references.
So, replace them by a literal markup.
Reviewed-by: André Almeida <andrealmeid@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
the :c:type shouldn't be used with structs with Sphinx 3,
as the C domain there uses .. c:struct for structs.
As we have the automarkup extension, let's just get rid of
all :c:type as a whole, as those will be automagically
marked as such.
This solves a bunch of warnings with Sphinx 3, like those:
.../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:490: WARNING: Unparseable C cross-reference: 'calling snd_card_free'
Invalid C declaration: Expected end of definition. [error at 8]
calling snd_card_free
--------^
.../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3328: WARNING: Unparseable C cross-reference: 'snd_rawmidi_transmit*'
Invalid C declaration: Expected end of definition. [error at 20]
snd_rawmidi_transmit*
--------------------^
.../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3928: WARNING: Unparseable C cross-reference: 'copy_from/to_user'
Invalid C declaration: Expected end of definition. [error at 9]
copy_from/to_user
---------^
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There's no need to use macros to use :c:type on this file,
as automarkup.py should do this automatically.
Also, this breaks compatibility with Sphinx 3.x, as there,
structs should be declared using .. c:struct.
So, get rid of them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The :c:type: tag has problems with Sphinx 3.x, as structs
there should be declared with c:struct.
So, remove them, relying at automarkup.py extension to
convert them into cross-references.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There is currently a problem with kernel-doc tags from blk.c:
.../Documentation/admin-guide/pstore-blk:239: ./fs/pstore/blk.c:175: WARNING: Duplicate C declaration, also defined in 'admin-guide/pstore-blk'.
Declaration is 'register_pstore_device'.
.../Documentation/admin-guide/pstore-blk:239: ./fs/pstore/blk.c:432: WARNING: Duplicate C declaration, also defined in 'admin-guide/pstore-blk'.
Declaration is 'register_pstore_blk'.
.../Documentation/admin-guide/pstore-blk:242: ./include/linux/pstore_blk.h:43: WARNING: Duplicate C declaration, also defined in 'admin-guide/pstore-blk'.
Declaration is 'pstore_device_info'.
Basically, the internal parts is shown with :export:, instead
of :internal:. Yet, there are some other exported docs that
aren't at the document, because they lack :identifiers:.
So, instead, let's just use :export: at the kAPI part of
the documentation.
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Those are already defined at kernel-api.rst, as part of the
synchronization primitives chapter.
This solves several Sphinx 3 warnings, like:
.../Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/kernel-api'.
Declaration is 'rcu_idle_enter'.
.../Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/kernel-api'.
Declaration is 'rcu_idle_exit'.
.../Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/kernel-api'.
Declaration is 'rcu_is_watching'.
.../Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/kernel-api'.
Declaration is 'call_rcu'.
.../Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/kernel-api'.
Declaration is 'synchronize_rcu'.
...
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The infrastructure.rst file already includes the external
symbols from drivers/base/core.c.
Duplicating 3 functions there causes namespace collisions:
Documentation/driver-api/device_link.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/infrastructure'.
Declaration is 'device_link_state'.
Documentation/driver-api/device_link.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/infrastructure'.
Declaration is 'device_link_add'.
Documentation/driver-api/device_link.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/infrastructure'.
Declaration is 'device_link_del'.
Documentation/driver-api/device_link.rst: WARNING: Duplicate C declaration, also defined in 'driver-api/infrastructure'.
Declaration is 'device_link_remove'.
So, drop the reference, adding just a mention to the functions
associated with device_link.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This is already included at scsi.rst. So, remove the duplication,
in order to avoid Sphinx warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As there's already a rst file with workqueue markups, containing
part of them, move the other definitions, in order to avoid
warnings with Sphinx.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The sound API is documented on two different parts:
under Documentation/driver-api/sound.rst and under
Documentation/sound/kernel-api/alsa-driver-api.rst.
The alsa-driver-api.rst seems more complete, and APIs
are split per type. There's just one missing kernel-doc
markup there.
Add it and drop the duplicated one.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This is already included at genericirq.rst. Adding it twice
causes C namespace duplication:
.../Documentation/core-api/kernel-api:237: ../kernel/irq/manage.c💯 WARNING: Duplicate C declaration, also defined in 'genericirq'.
Declaration is 'synchronize_hardirq'.
.../Documentation/core-api/kernel-api:237: ../kernel/irq/manage.c:128: WARNING: Duplicate C declaration, also defined in 'genericirq'.
Declaration is 'synchronize_irq'.
.../Documentation/core-api/kernel-api:237: ../kernel/irq/manage.c:443: WARNING: Duplicate C declaration, also defined in 'genericirq'.
Declaration is 'irq_set_affinity_notifier'.
...
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently, kernel/irq/chip.c is included twice, one for
export functions, and then for internal ones. However, as
the :export: and :internal: tags are missing, they ended
being included twice.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are some warnings produced with Sphinx 3.x:
Documentation/networking/ieee802154.rst:29: WARNING: Error in declarator or parameters
Invalid C declaration: Expecting "(" in parameters. [error at 7]
int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
-------^
Documentation/networking/ieee802154.rst:134: WARNING: Invalid C declaration: Expected end of definition. [error at 81]
void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff *skb, u8 lqi):
---------------------------------------------------------------------------------^
Documentation/networking/ieee802154.rst:139: WARNING: Invalid C declaration: Expected end of definition. [error at 95]
void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb, bool ifs_handling):
-----------------------------------------------------------------------------------------------^
Documentation/networking/ieee802154.rst:158: WARNING: Invalid C declaration: Expected end of definition. [error at 35]
int start(struct ieee802154_hw *hw):
-----------------------------------^
Documentation/networking/ieee802154.rst:162: WARNING: Invalid C declaration: Expected end of definition. [error at 35]
void stop(struct ieee802154_hw *hw):
-----------------------------------^
Documentation/networking/ieee802154.rst:166: WARNING: Invalid C declaration: Expected end of definition. [error at 61]
int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb):
-------------------------------------------------------------^
Documentation/networking/ieee802154.rst:171: WARNING: Invalid C declaration: Expected end of definition. [error at 43]
int ed(struct ieee802154_hw *hw, u8 *level):
-------------------------------------------^
Documentation/networking/ieee802154.rst:176: WARNING: Invalid C declaration: Expected end of definition. [error at 62]
int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel):
--------------------------------------------------------------^
Caused by some bad c:function: prototypes. Fix them.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The C domain functions there collide with the English ones,
due to namespace collision, generating lots of warnings with
Sphinx 3.x:
./include/linux/mutex.h:121: WARNING: Duplicate C declaration, also defined in 'translations/it_IT/kernel-hacking/locking'.
Declaration is 'mutex_init'.
./include/linux/mutex.h:152: WARNING: Duplicate C declaration, also defined in 'translations/it_IT/kernel-hacking/locking'.
Declaration is 'mutex_is_locked'.
./include/linux/mutex.h:226: WARNING: Duplicate C declaration, also defined in 'translations/it_IT/kernel-hacking/locking'.
Declaration is 'mutex_trylock_recursive'.
./kernel/locking/mutex.c:281: WARNING: Duplicate C declaration, also defined in 'translations/it_IT/kernel-hacking/locking'.
Declaration is 'mutex_lock'.
...
Add a namespace tag there, in order to prevent that.
Acked-by: Federico Vaga <federico.vaga@vaga.pv.it>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are some c-domain tags that are wrong. While this won't
cause problems with Sphinx < 3.0, this cause troubles with
newer versions, as the C parser won't recognize the contents
of the tag, and will drop it from the output.
Let's just place them at literal blocks.
Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The :c:type:`foo` only works properly with structs before
Sphinx 3.x.
On Sphinx 3.x, structs should now be declared using the
.. c:struct, and referenced via :c:struct tag.
As we now have the automarkup.py macro, that automatically
convert:
struct foo
into cross-references, let's get rid of that, solving
several warnings when building docs with Sphinx 3.x.
Reviewed-by: André Almeida <andrealmeid@collabora.com> # blk-mq.rst
Reviewed-by: Takashi Iwai <tiwai@suse.de> # sound
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are three files with replace macros for structs,
mapping them into Sphinx 2.x C domain references.
Well, this is broken on Sphinx 3.x. Also, for Sphinx 2.x,
the automarkup macro should be able to take care of them.
So, let's just drop those.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The new C domain code on Sphinx 3 doesn't allow anymore
to use c:type:: for structs.
Now that cdomain.py has backward support, let's use
c:struct:: instead.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sphinx 3.x broke support for the cdomain.py extension, as the
c domain code was rewritten. Due to that, the c tags need to
be re-written, in order to use the new c domain notation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sphinx 3.x broke support for the cdomain.py extension, as the
c domain code was rewritten. Due to that, the c tags need to
be re-written, in order to use the new c domain notation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sphinx 3.x broke support for the cdomain.py extension, as the
c domain code was rewritten. Due to that, the c tags need to
be re-written, in order to use the new c domain notation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sphinx 3.x broke support for the cdomain.py extension, as the
c domain code was rewritten. Due to that, the c tags need to
be re-written, in order to use the new c domain notation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sphinx 3.x broke support for the cdomain.py extension, as the
c domain code was rewritten. Due to that, the c tags need to
be re-written, in order to use the new c domain notation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sphinx 3 added support for declaring C macros with parameters using the
:c:macro role.
To support automarkup for both functions and parametrized macros using
the same regex (words ending in ()), try to cross-reference to both, and
only fall back to regular text if neither exist.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@protonmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
With the transition to Sphinx 3, new warnings were caused by
automarkup, exposing bugs in the name matching.
When automarkup parsed a text like "struct struct" in the documentation,
it tried to cross-reference to a "struct" symbol, which is recognized as
a C reserved word by Sphinx 3, generating a warning.
Add some C reserved words (only the ones that were causing warnings) to
a list and skip them while trying to cross-reference.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@protonmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
With the transition to Sphinx 3, new warnings were generated by
automarkup, exposing bugs in the regexes.
The warnings were caused by the expressions matching words in the
translated versions of the documentation, since any unicode character
was matched.
Fix the regular expression by making the C regexes use ASCII and
ensuring the expressions only match the beginning of words,
in order to avoid warnings like this:
WARNING: Unparseable C cross-reference: '调用debugfs_rename'
That's probably due to the lack of using spaces between words
on Chinese.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@protonmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
While Sphinx 2 used a single c:type role for struct, union, enum and
typedef, Sphinx 3 uses a specific role for each one.
To keep backward compatibility, detect the Sphinx version and use the
correct roles for that version.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@protonmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently, there's no way to exclude identifiers from
a kernel-doc markup. Add support for it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Finding where an error like this was generated:
../lib/math/div64.c:73: WARNING: Duplicate C declaration, also defined in 'kernel-api'.
Can take some time, as there's no glue about what kernel-doc
tag generated it. It is a way better to display it as:
.../Documentation/core-api/kernel-api:171: ../lib/math/div64.c:73: WARNING: Duplicate C declaration, also defined in 'kernel-api'.
Declaration is 'div_s64_rem'.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
While most of the C domain parsing is done via kernel-doc,
some RST files use C domain tags directly.
While several of them can be removed for Sphinx < 3.0, due
to automarkup.py, and several others that could be
converted into kernel-doc markups, changes like that are
time-consuming, and may not fit all cases.
As we already have the cdomain.py for handing backward
compatibility with Sphinx versions below 3.0, let's
make it more complete, in order to cover any usage of the
newer tags outside kernel-doc.
This way, it should be feasible to use the new tags inside
the Kernel tree, without losing backward compatibility.
This should allow fixing the remaining warnings with
the Kernel tags.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Since Sphinx 3.0, the C domain code was rewritten, but only
after version 3.1 it got support for setting namespaces on
C domains, with is something that it is required, in order to
document system calls, like ioctl() and others.
As part of changing the documentation subsystem to properly
build with Sphinx 3.1+, add support for such new tag:
.. c:namespace::"
Such tag optionally replaces the optional "name" tag for functions,
setting a single namespace domain for all C references found
at the file.
With that, it should be possible to convert existing
documentation to be compatible with both Sphinx 1.x/2.x and
3.1+.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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:
6fd2076ec0
Although I did a different implementation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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: 4069a572d4 ("net: phy: Document core PHY structures")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Here are some SPDX-specific changes for 5.10-rc1.
They include:
- driver fixes to make spdxcheck.pl work properly
- add GFDL licenses as "deprecated" but required due to some of
our documentation using them
- add Zlib license as "deprecated" but required because we have
code with this license in the tree.
- convert some drivers to have SPDX identifiers that previously
didn't have them.
All have been in linux-next for a very long time with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCX4c6oA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yl35ACg2i+pP5CBExSzQUtA1Tx/UD2CVNMAoIAQChwj
SHZurDuyHkEiCdB+5n1u
=C9qR
-----END PGP SIGNATURE-----
Merge tag 'spdx-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx
Pull SPDX updates from Greg KH:
"Here are some SPDX-specific changes for 5.10-rc1.
They include:
- driver fixes to make spdxcheck.pl work properly
- add GFDL licenses as "deprecated" but required due to some of our
documentation using them
- add Zlib license as "deprecated" but required because we have code
with this license in the tree.
- convert some drivers to have SPDX identifiers that previously
didn't have them.
All have been in linux-next for a very long time with no reported
issues"
* tag 'spdx-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx:
scripts/spdxcheck.py: handle license identifiers in XML comments
net/mlx5: IPsec: make spdxcheck.py happy
LICENSES/deprecated: add Zlib license text
LICENSE: add GFDL deprecated licenses
net/qla3xxx: Convert to SPDX license identifiers
net/qlge: Convert to SPDX license identifiers
net/qlcnic: Convert to SPDX license identifiers
scsi/qla2xxx: Convert to SPDX license identifiers
scsi/qla4xxx: Convert to SPDX license identifiers
Here is the "big" set of driver core patches for 5.10-rc1
They include a lot of different things, all related to the driver core
and/or some driver logic:
- sysfs common write functions to make it easier to audit sysfs
attributes
- device connection cleanups and fixes
- devm helpers for a few functions
- NOIO allocations for when devices are being removed
- minor cleanups and fixes
All have been in linux-next for a while with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCX4c4yA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ylS7gCfcS+7/PE42eXxMY0z8rBX8aDMadIAn2DVEghA
Eoh9UoMEW4g1uMKORA0c
=CVAW
-----END PGP SIGNATURE-----
Merge tag 'driver-core-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here is the "big" set of driver core patches for 5.10-rc1
They include a lot of different things, all related to the driver core
and/or some driver logic:
- sysfs common write functions to make it easier to audit sysfs
attributes
- device connection cleanups and fixes
- devm helpers for a few functions
- NOIO allocations for when devices are being removed
- minor cleanups and fixes
All have been in linux-next for a while with no reported issues"
* tag 'driver-core-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (31 commits)
regmap: debugfs: use semicolons rather than commas to separate statements
platform/x86: intel_pmc_core: do not create a static struct device
drivers core: node: Use a more typical macro definition style for ACCESS_ATTR
drivers core: Use sysfs_emit for shared_cpu_map_show and shared_cpu_list_show
mm: and drivers core: Convert hugetlb_report_node_meminfo to sysfs_emit
drivers core: Miscellaneous changes for sysfs_emit
drivers core: Reindent a couple uses around sysfs_emit
drivers core: Remove strcat uses around sysfs_emit and neaten
drivers core: Use sysfs_emit and sysfs_emit_at for show(device *...) functions
sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output
dyndbg: use keyword, arg varnames for query term pairs
driver core: force NOIO allocations during unplug
platform_device: switch to simpler IDA interface
driver core: platform: Document return type of more functions
Revert "driver core: Annotate dev_err_probe() with __must_check"
Revert "test_firmware: Test platform fw loading on non-EFI systems"
iio: adc: xilinx-xadc: use devm_krealloc()
hwmon: pmbus: use more devres helpers
devres: provide devm_krealloc()
syscore: Use pm_pr_dbg() for syscore_{suspend,resume}()
...
Here is the big set of tty and serial driver patches for 5.10-rc1.
Lots of little things in here, including:
- tasklet_setup api conversions
- sysrq support for capital letters
- vt and vc cleanups and unwinding the mess some more
- serial driver updates and minor tweaks
- new device ids
- rs485 support for some drivers
- serial binding documentation updates
- lots of small serial driver changes for reported issues
All have been in linux-next for a while with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCX4c5vA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ykVRACfWQRqsz/IIs6MZsDY9dkj4+QVUWAAn0mN2uHR
mBox8w4TdTfG96jFXSfF
=WYKP
-----END PGP SIGNATURE-----
Merge tag 'tty-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial updates from Greg KH:
"Here is the big set of tty and serial driver patches for 5.10-rc1.
Lots of little things in here, including:
- tasklet_setup api conversions
- sysrq support for capital letters
- vt and vc cleanups and unwinding the mess some more
- serial driver updates and minor tweaks
- new device ids
- rs485 support for some drivers
- serial binding documentation updates
- lots of small serial driver changes for reported issues
All have been in linux-next for a while with no reported issues"
* tag 'tty-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (79 commits)
serial: mcf: add sysrq capability
serial: fsl_lpuart: add sysrq support when using dma
fbcon: remove no-op fbcon_set_origin()
tty/sysrq: Extend the sysrq_key_table to cover capital letters
serial: max310x: rework RX interrupt handling
serial: 8250_dw: Fix clk-notifier/port suspend deadlock
serial: 8250: Skip uninitialized TTY port baud rate update
serial: 8250: Discard RTS/DTS setting from clock update method
tty: serial: imx: disable TXDC IRQ in imx_uart_shutdown() to avoid IRQ storm
serial: 8250_fsl: Fix TX interrupt handling condition
serial: pl011: Fix lockdep splat when handling magic-sysrq interrupt
tty: serial: fsl_lpuart: fix lpuart32_poll_get_char
tty: serial: lpuart: fix lpuart32_write usage
serial: qcom_geni_serial: To correct QUP Version detection logic
serial: mvebu-uart: fix unused variable warning
vt_ioctl: make VT_RESIZEX behave like VT_RESIZE
serial: mvebu-uart: simplify the return expression of mvebu_uart_probe()
tty: serial: imx: fix link error with CONFIG_SERIAL_CORE_CONSOLE=n
tty: hvc: fix link error with CONFIG_SERIAL_CORE_CONSOLE=n
pch_uart: drop double zeroing
...
Mauro Carvalho Chehab