To print node name, there are different specifiers in Linux kernel. You can pass device node pointer (struct device_node *) to print function to print device node in different formats.
Lets say I have node named “my-node” in device tree:
compatible = "test,compatible-string";
Printing node (lets say sub-node) using device node pointer:
%pOF => /my-node/my-sub-node@0x12345678
%pOFf => /my-node/my-sub-node@0x12345678
%pOFfp => /my-node/my-sub-node@0x12345678:52
(52 is phandle)
%pOFfcF => /my-node/my-sub-node@0x12345678:test,compatible-string:–P-
Last are flags as below:
D – dynamic
d – detached
P – Populated
B – Populated bus
Tested on: linux-4.14
Print the callback function name
If you cannot trace which function gets called when you call from core driver using function pointer, you can print function name using pf format specifier.
Linux maintains symbol table so based on function address, it can identify function name based on address pointed by function pointer.
e.g. Core driver calls hardware specific enable/disable functions:
core->ops->enable(). If you are not sure, which function is executed as a result of this call, you can print them using %pf or %pF:
pr_info("callee function name is: %pf, core->ops->enable)
%pf prints without offset (e.g. foo) while %pF prints with offset (e.g. foo+0x00/0x80)
Thanks Bhargav(br13patel) for sharing this!
Print caller name
There are few ways to trace caller in Linux kernel.
- Print stack backtrace
- To enable the
dump_stack() function in the kernel config the following options must be set.
- Kernel hacking -> Kernel debugging
- Kernel hacking -> Verbose kernel error messages
- Print caller name
- pr_info(“caller function name is: %pf, __builtin_return_address(0))
Here are few tools/scripts which are useful for static analysis of code:
Check kernel memory leak using kmemleak:
# cppcheck <source-dir>
‘patch’ proposes a fix, when possible.
‘report’ generates a list in the following format: file:line:column-column: message
‘context’ highlights lines of interest and their context in a diff-like style.Lines of interest are indicated with ‘-‘
‘org’ generates a report in the Org mode format of Emacs.
- To apply Coccinelle to a specific directory, M= can be used.
For example, to check drivers/net/wireless/ one may write:
make coccicheck M=drivers/net/wireless/
# ./kselftest_install.sh /tmp
- Kselftest install creates run_kselftest.sh
- Run tests:
# cd install_dir
git describe --contains
git describe --contains 0848c94fb4a5cc213a7fb0fb3a5721ad6e16f096
Below commands once added in vimrc creates a session with F2 and restore using F3:
map <F2> :mksession! ~/vim_session <cr> " Quick write session with F2
map <F3> :source ~/vim_session <cr> " And load session with F3
You can make any number of sessions using “mksession” command and restore using “source” command from vim editor also.
My git send-email config:
git config sendemail.smtpuser
git config sendemail.smtpserver smtp.googlemail.com
git config sendemail.smtpencryption tls
git config sendemail.smtpserverport 587
git config sendemail.suppresscc self
git send-email --to <to_list> --in-reply-to="<message_id_of_message1>" --thread *.patch
This will generate patch in below way:
– Message 1
. – Patch 1
. – Patch 2
This is how I prepared cover page followed by two patches:
git format-patch -2 --subject-prefix="PATCH v2" --cover-letter --thread=shallow
- Here –cover-later would create a cover page. We need to modify subject and content.
- The –thread=shallow flag specifies that all patches will be In-Reply-To your cover letter. Hence all patches would be in reply to cover page by default.
- –subject-prefix=”PATCH v2″ would use given prefix in patch file.
This is how I sent this patches:
git send-email –to <to_id> –cc <cc_id> <patches>
The patch follows below sequence