summaryrefslogtreecommitdiffstats
path: root/Documentation/process/debugging/index.rst
diff options
context:
space:
mode:
authorYijie Yang <yijie.yang@oss.qualcomm.com>2026-08-11 16:46:47 +0800
committerRob Herring (Arm) <robh@kernel.org>2026-08-15 15:46:52 -0500
commite1c13aed4a1641550e8c9518c96f016e1d52d09b (patch)
tree61c2297688373db165cc857b7c7adcb147a5c419 /Documentation/process/debugging/index.rst
downloadlinux-stable-e1c13aed4a1641550e8c9518c96f016e1d52d09b.tar.gz
linux-stable-e1c13aed4a1641550e8c9518c96f016e1d52d09b.zip
dt-bindings: interconnect: qcom-bwmon: Add Maili cpu-bwmon compatiblegrafted
Add the Qualcomm Maili SoC compatible string for the CPU bandwidth monitor (BWMONv4). This falls back to the sdm845-bwmon compatible, consistent with the existing pattern used by other recent SoCs such as sm8750 and kaanapali. Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Link: https://patch.msgid.link/20260811-bwmon-v2-1-80f7f150ab9e@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Diffstat (limited to 'Documentation/process/debugging/index.rst')
-rw-r--r--Documentation/process/debugging/index.rst71
1 files changed, 71 insertions, 0 deletions
diff --git a/Documentation/process/debugging/index.rst b/Documentation/process/debugging/index.rst
new file mode 100644
index 000000000..357243e18
--- /dev/null
+++ b/Documentation/process/debugging/index.rst
@@ -0,0 +1,71 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============================================
+Debugging advice for Linux Kernel developers
+============================================
+
+general guides
+--------------
+
+.. toctree::
+ :maxdepth: 1
+
+ driver_development_debugging_guide
+ gdb-kernel-debugging
+ kgdb
+ userspace_debugging_guide
+
+subsystem specific guides
+-------------------------
+
+.. toctree::
+ :maxdepth: 1
+
+ media_specific_debugging_guide
+
+General debugging advice
+========================
+
+Depending on the issue, a different set of tools is available to track down the
+problem or even to realize whether there is one in the first place.
+
+As a first step you have to figure out what kind of issue you want to debug.
+Depending on the answer, your methodology and choice of tools may vary.
+
+Do I need to debug with limited access?
+---------------------------------------
+
+Do you have limited access to the machine or are you unable to stop the running
+execution?
+
+In this case your debugging capability depends on built-in debugging support of
+provided distribution kernel.
+The :doc:`/process/debugging/userspace_debugging_guide` provides a brief
+overview over a range of possible debugging tools in that situation. You can
+check the capability of your kernel, in most cases, by looking into config file
+within the /boot directory.
+
+Do I have root access to the system?
+------------------------------------
+
+Are you easily able to replace the module in question or to install a new
+kernel?
+
+In that case your range of available tools is a lot bigger, you can find the
+tools in the :doc:`/process/debugging/driver_development_debugging_guide`.
+
+Is timing a factor?
+-------------------
+
+It is important to understand if the problem you want to debug manifests itself
+consistently (i.e. given a set of inputs you always get the same, incorrect
+output), or inconsistently. If it manifests itself inconsistently, some timing
+factor might be at play. If inserting delays into the code does change the
+behavior, then quite likely timing is a factor.
+
+When timing does alter the outcome of the code execution using a simple
+printk() for debugging purposes may not work, a similar alternative is to use
+trace_printk() , which logs the debug messages to the trace file instead of the
+kernel log.
+
+**Copyright** ©2024 : Collabora