doc: Fix links to Zephyr include directory on Github

At some recent point, directory <zephyr-root>/include was moved to
<zephyr-root>/include/zephyr. However, links from documentation to
Zephyr source on Github were not updated. Update them now.

Signed-off-by: Aleksandar Markovic <aleksandar.markovic.sa@gmail.com>

doc/build/cmake/index.rst

@@ -92,7 +92,7 @@ Devicetree
    preprocessor macros.
 
    Source code should access preprocessor macros generated from devicetree by
-   including the :zephyr_file:`devicetree.h <include/devicetree.h>` header,
+   including the :zephyr_file:`devicetree.h <include/zephyr/devicetree.h>` header,
    which includes :file:`devicetree_unfixed.h`.
 
    :file:`gen_defines.py` also writes the final devicetree to

doc/connectivity/networking/api/dns_resolve.rst

@@ -30,7 +30,7 @@ about LLMNR.
 
 For more information about DNS configuration variables, see:
 :zephyr_file:`subsys/net/lib/dns/Kconfig`. The DNS resolver API can be found at
-:zephyr_file:`include/net/dns_resolve.h`.
+:zephyr_file:`include/zephyr/net/dns_resolve.h`.
 
 Sample usage
 ************

doc/connectivity/networking/api/net_buf.rst

@@ -13,7 +13,7 @@ Overview
 
 Network buffers are a core concept of how the networking stack
 (as well as the Bluetooth stack) pass data around. The API for them is
-defined in :zephyr_file:`include/net/buf.h`:.
+defined in :zephyr_file:`include/zephyr/net/buf.h`:.
 
 Creating buffers
 ****************

doc/connectivity/networking/api/net_l2.rst

@@ -13,11 +13,11 @@ Overview
 The L2 stack is designed to hide the whole networking link-layer part
 and the related device drivers from the upper network stack. This is made
 through a :c:struct:`net_if` declared in
-:zephyr_file:`include/net/net_if.h`.
+:zephyr_file:`include/zephyr/net/net_if.h`.
 
 The upper layers are unaware of implementation details beyond the net_if
 object and the generic API provided by the L2 layer in
-:zephyr_file:`include/net/net_l2.h` as :c:struct:`net_l2`.
+:zephyr_file:`include/zephyr/net/net_l2.h` as :c:struct:`net_l2`.
 
 Only the L2 layer can talk to the device driver, linked to the net_if
 object. The L2 layer dictates the API provided by the device driver,
@@ -119,7 +119,7 @@ here as well.  There are two specific differences however:
 - It requires a dedicated device driver API: :c:struct:`ieee802154_radio_api`,
   which overloads :c:struct:`net_if_api`. This is because 802.15.4 L2 needs more from the device
   driver than just ``send()`` and ``recv()`` functions.  This dedicated API is
-  declared in :zephyr_file:`include/net/ieee802154_radio.h`. Each and every
+  declared in :zephyr_file:`include/zephyr/net/ieee802154_radio.h`. Each and every
   IEEE 802.15.4 device driver must provide a valid pointer on such
   relevantly filled-in API structure.
 

doc/connectivity/networking/api/net_mgmt.rst

@@ -119,7 +119,7 @@ An example follows.
 		net_mgmt_add_event_callback(&ipv4_callback);
 	}
 
-See :zephyr_file:`include/net/net_event.h` for available generic core events that
+See :zephyr_file:`include/zephyr/net/net_event.h` for available generic core events that
 can be listened to.
 
 
@@ -133,9 +133,9 @@ associated mgmt_request code.
 Management request code are defined in relevant places depending on
 the targeted layer or eventually, if l2 is the layer, on the
 technology as well. For instance, all IP layer management request code
-will be found in the :zephyr_file:`include/net/net_event.h` header file. But in case
+will be found in the :zephyr_file:`include/zephyr/net/net_event.h` header file. But in case
 of an L2 technology, let's say Ethernet, these would be found in
-:zephyr_file:`include/net/ethernet.h`
+:zephyr_file:`include/zephyr/net/ethernet.h`
 
 You define your handler modeled with this signature:
 
@@ -162,9 +162,9 @@ Signaling a network event
 
 You can signal a specific network event using the :c:func:`net_mgmt_event_notify`
 function and provide the network event code. See
-:zephyr_file:`include/net/net_mgmt.h` for details. As for the management request
+:zephyr_file:`include/zephyr/net/net_mgmt.h` for details. As for the management request
 code, event code can be also found on specific L2 technology mgmt headers,
-for example :zephyr_file:`include/net/ieee802154_mgmt.h` would be the right place if
+for example :zephyr_file:`include/zephyr/net/ieee802154_mgmt.h` would be the right place if
 802.15.4 L2 is the technology one wants to listen to events.
 
 API Reference

doc/connectivity/networking/api/net_pkt.rst

@@ -17,7 +17,7 @@ metadata for the core to hold important information. Such an object is
 called net_pkt in this document.
 
 The data structure and the whole API around it are defined in
-:zephyr_file:`include/net/net_pkt.h`.
+:zephyr_file:`include/zephyr/net/net_pkt.h`.
 
 Architectural notes
 ===================

doc/connectivity/networking/api/net_pkt_filter.rst

@@ -45,7 +45,7 @@ can be embedded into a larger structure when a specific condition requires
 extra test data. It is up to the test function for such conditions to
 retrieve the outer structure from the provided ``npf_test`` structure pointer.
 
-Convenience macros are provided in :zephyr_file:`include/net/net_pkt_filter.h`
+Convenience macros are provided in :zephyr_file:`include/zephyr/net/net_pkt_filter.h`
 to statically define condition instances for various conditions, and
 :c:macro:`NPF_RULE()` to create a rule instance to tie them.
 

doc/connectivity/networking/networking-api-usage.rst

@@ -4,7 +4,7 @@ Network Connectivity API
 ########################
 
 Applications should use the BSD socket API defined in
-:zephyr_file:`include/net/socket.h` to create a connection, send or receive data,
+:zephyr_file:`include/zephyr/net/socket.h` to create a connection, send or receive data,
 and close a connection. The same API can be used when working with UDP or
 TCP data. See :ref:`BSD socket API <bsd_sockets_interface>` for more details.
 
@@ -12,5 +12,5 @@ See :ref:`sockets-echo-server-sample` and :ref:`sockets-echo-client-sample`
 applications how to create a simple server or client BSD socket based
 application.
 
-The legacy connectivity API in :zephyr_file:`include/net/net_context.h` should not be
+The legacy connectivity API in :zephyr_file:`include/zephyr/net/net_context.h` should not be
 used by applications.

doc/hardware/arch/arm_cortex_m.rst

@@ -477,7 +477,7 @@ For example, to define a new non-cacheable memory region in devicetree:
 This will automatically create a new MPU entry in
 :zephyr_file:`soc/arm/common/arm_mpu_regions.c` with the correct name, base,
 size and attributes gathered directly from the devicetree. See
-:zephyr_file:`include/linker/devicetree_regions.h` for more details.
+:zephyr_file:`include/zephyr/linker/devicetree_regions.h` for more details.
 
 Static MPU regions
 ------------------

doc/hardware/porting/arch.rst

@@ -459,7 +459,7 @@ Toolchain and Linking
 
 Toolchain support has to be added to the build system.
 
-Some architecture-specific definitions are needed in :zephyr_file:`include/toolchain/gcc.h`.
+Some architecture-specific definitions are needed in :zephyr_file:`include/zephyr/toolchain/gcc.h`.
 See what exists in that file for currently supported architectures.
 
 Each architecture also needs its own linker script, even if most sections can

doc/kernel/data_structures/mpsc_pbuf.rst

@@ -82,8 +82,8 @@ Usage
 Packet header definition
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-Packet header details can be found in :zephyr_file:`include/sys/mpsc_packet.h`.
-API functions can be found in :zephyr_file:`include/sys/mpsc_pbuf.h`. Headers
+Packet header details can be found in :zephyr_file:`include/zephyr/sys/mpsc_packet.h`.
+API functions can be found in :zephyr_file:`include/zephyr/sys/mpsc_pbuf.h`. Headers
 are split to avoid include spam when declaring the packet.
 
 User header structure must start with internal header:

doc/kernel/data_structures/ring_buffers.rst

@@ -382,6 +382,6 @@ Related configuration options:
 API Reference
 *************
 
-The following ring buffer APIs are provided by :zephyr_file:`include/sys/ring_buffer.h`:
+The following ring buffer APIs are provided by :zephyr_file:`include/zephyr/sys/ring_buffer.h`:
 
 .. doxygengroup:: ring_buffer_apis

doc/kernel/services/other/fatal.rst

@@ -15,7 +15,7 @@ Runtime Assertions
 
 Zephyr provides some macros to perform runtime assertions which may be
 conditionally compiled. Their definitions may be found in
-:zephyr_file:`include/sys/__assert.h`.
+:zephyr_file:`include/zephyr/sys/__assert.h`.
 
 Assertions are enabled by setting the ``__ASSERT_ON`` preprocessor symbol to a
 non-zero value. There are two ways to do this:

doc/kernel/usermode/memory_domain.rst

@@ -439,6 +439,6 @@ Related configuration options:
 API Reference
 *************
 
-The following memory domain APIs are provided by :zephyr_file:`include/kernel.h`:
+The following memory domain APIs are provided by :zephyr_file:`include/zephyr/kernel.h`:
 
 .. doxygengroup:: mem_domain_apis

doc/kernel/usermode/syscalls.rst

@@ -250,7 +250,7 @@ passed in.  This includes:
 * Any other arguments that have a limited range of valid values.
 
 Verification functions involve a great deal of boilerplate code which has been
-made simpler by some macros in :zephyr_file:`include/syscall_handler.h`.
+made simpler by some macros in :zephyr_file:`include/zephyr/syscall_handler.h`.
 Verification functions should be declared using these macros.
 
 Argument Validation
@@ -608,7 +608,7 @@ APIs
 ****
 
 Helper macros for creating system call verification functions are provided in
-:zephyr_file:`include/syscall_handler.h`:
+:zephyr_file:`include/zephyr/syscall_handler.h`:
 
 * :c:macro:`Z_SYSCALL_OBJ()`
 * :c:macro:`Z_SYSCALL_OBJ_INIT()`
@@ -622,7 +622,7 @@ Helper macros for creating system call verification functions are provided in
 * :c:macro:`Z_SYSCALL_VERIFY`
 
 Functions for invoking system calls are defined in
-:zephyr_file:`include/syscall.h`:
+:zephyr_file:`include/zephyr/syscall.h`:
 
 * :c:func:`_arch_syscall_invoke0`
 * :c:func:`_arch_syscall_invoke1`

doc/services/debugging/coredump.rst

@@ -240,7 +240,7 @@ The file header consists of the following fields:
      - ``unsigned int``
      - Reason for the fatal error, as the same in
        ``enum k_fatal_error_reason`` defined in
-       :zephyr_file:`include/fatal.h`
+       :zephyr_file:`include/zephyr/fatal.h`
 
 Architecture-specific Block
 ---------------------------
@@ -311,7 +311,7 @@ dumping routine and parser for new targets. To add a new target,
 the following needs to be done:
 
 #. Add a new target code to the ``enum coredump_tgt_code`` in
-   :zephyr_file:`include/debug/coredump.h`.
+   :zephyr_file:`include/zephyr/debug/coredump.h`.
 #. Implement :c:func:`arch_coredump_tgt_code_get` simply to return
    the newly introduced target code.
 #. Implement :c:func:`arch_coredump_info_dump` to construct

doc/services/logging/index.rst

@@ -66,7 +66,7 @@ time filtering is independent for each backend and each source of log messages.
 Source of log messages can be a module or specific instance of the module.
 
 There are four severity levels available in the system: error, warning, info
-and debug. For each severity level the logging API (:zephyr_file:`include/logging/log.h`)
+and debug. For each severity level the logging API (:zephyr_file:`include/zephyr/logging/log.h`)
 has set of dedicated macros. Logger API also has macros for logging data.
 
 For each level following set of macros are available:
@@ -335,7 +335,7 @@ Controlling the logging
 =======================
 
 Logging can be controlled using API defined in
-:zephyr_file:`include/logging/log_ctrl.h`. Logger must be initialized before it can be
+:zephyr_file:`include/zephyr/logging/log_ctrl.h`. Logger must be initialized before it can be
 used. Optionally, user can provide function which returns timestamp value. If
 not provided, :c:macro:`k_cycle_get_32` is used for timestamping.
 :c:func:`log_process` function is used to trigger processing of one log
@@ -521,7 +521,7 @@ Custom Frontend
 ===============
 
 Custom frontend is enabled using :kconfig:option:`CONFIG_LOG_FRONTEND`. Logs are directed
-to functions declared in :zephyr_file:`include/logging/log_frontend.h`.
+to functions declared in :zephyr_file:`include/zephyr/logging/log_frontend.h`.
 If option :kconfig:option:`CONFIG_LOG_FRONTEND_ONLY` is enabled then log message is not
 created and no backend is handled. Otherwise, custom frontend can coexist with
 backends (not available in v1).
@@ -636,7 +636,7 @@ Message formatting
 ------------------
 
 Logging provides set of function that can be used by the backend to format a
-message. Helper functions are available in :zephyr_file:`include/logging/log_output.h`.
+message. Helper functions are available in :zephyr_file:`include/zephyr/logging/log_output.h`.
 
 Example message formatted using :c:func:`log_output_msg_process` or
 :c:func:`log_output_msg2_process`.

doc/services/shell/index.rst

@@ -118,7 +118,7 @@ Use the following macros for adding shell commands:
 * :c:macro:`SHELL_DYNAMIC_CMD_CREATE` - Create a dynamic subcommands array.
 
 Commands can be created in any file in the system that includes
-:zephyr_file:`include/shell/shell.h`. All created commands are available for all
+:zephyr_file:`include/zephyr/shell/shell.h`. All created commands are available for all
 shell instances.
 
 Static commands

doc/services/storage/disk/access.rst

@@ -49,7 +49,7 @@ The SD card will be automatically detected and initialized by the
 filesystem driver when the board boots.
 
 To read and write files and directories, see the :ref:`file_system_api` in
-:zephyr_file:`include/fs/fs.h` such as :c:func:`fs_open()`,
+:zephyr_file:`include/zephyr/fs/fs.h` such as :c:func:`fs_open()`,
 :c:func:`fs_read()`, and :c:func:`fs_write()`.
 
 Disk Access API Configuration Options

doc/services/tracing/index.rst

@@ -21,7 +21,7 @@ that has implied:
 6. Writing custom ad-hoc tools for filtering and presentation.
 
 An application can use one of the existing formats or define a custom format by
-overriding the macros declared in :zephyr_file:`include/tracing/tracing.h`.
+overriding the macros declared in :zephyr_file:`include/zephyr/tracing/tracing.h`.
 
 Different formats, transports and host tools are available and supported in
 Zephyr.

doc/services/usb/hid.rst

@@ -4,8 +4,8 @@ USB Human Interface Devices (HID) support
 #########################################
 
 Since the USB HID specification is not only used by the USB subsystem, the USB HID API
-is split into two header files :zephyr_file:`include/usb/class/hid.h`
-and :zephyr_file:`include/usb/class/usb_hid.h`. The second includes a specific
+is split into two header files :zephyr_file:`include/zephyr/usb/class/hid.h`
+and :zephyr_file:`include/zephyr/usb/class/usb_hid.h`. The second includes a specific
 part for HID support in the USB device stack.
 
 HID Item helpers

doc/services/usb/udc.rst

@@ -5,7 +5,7 @@ USB device controller driver
 
 The USB Device Controller Driver Layer implements the low level control routines
 to deal directly with the hardware. All device controller drivers should
-implement the APIs described in :zephyr_file:`include/drivers/usb/usb_dc.h`.
+implement the APIs described in :zephyr_file:`include/zephyr/drivers/usb/usb_dc.h`.
 This allows the integration of new USB device controllers to be done without
 changing the upper layers.
 With this API it is not possible to support more than one controller

doc/services/usb/uds.rst

@@ -16,7 +16,7 @@ over time. It provides the following functionalities:
   revision 2.0.
 * Provides a programming interface to be used by USB device classes or
   customer applications. The APIs is described in
-  :zephyr_file:`include/usb/usb_device.h`
+  :zephyr_file:`include/zephyr/usb/usb_device.h`
 
 The device stack has few limitations with which it is not possible to support
 more than one controller instance at runtime, and only one USB device

samples/basic/blinky/README.rst

@@ -87,7 +87,7 @@ Tips:
 - If you're not sure what to do, check the devicetrees for supported boards which
   use the same SoC as your target. See :ref:`get-devicetree-outputs` for details.
 
-- See :zephyr_file:`include/dt-bindings/gpio/gpio.h` for the flags you can use
+- See :zephyr_file:`include/zephyr/dt-bindings/gpio/gpio.h` for the flags you can use
   in devicetree.
 
 - If the LED is built in to your board hardware, the alias should be defined in