[tip: timers/core] timekeeping: Fix parameter docs of read_persistent_wall_and_boot_offset()
From: tip-bot2 for Alex Shi
Date: Sun Nov 15 2020 - 17:51:40 EST
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 29efc4612ac1b888e65da408b41dafa4dd00842f
Gitweb: https://git.kernel.org/tip/29efc4612ac1b888e65da408b41dafa4dd00842f
Author: Alex Shi <alex.shi@xxxxxxxxxxxxxxxxx>
AuthorDate: Fri, 13 Nov 2020 15:24:35 +08:00
Committer: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
CommitterDate: Sun, 15 Nov 2020 23:47:24 +01:00
timekeeping: Fix parameter docs of read_persistent_wall_and_boot_offset()
Address the following kernel-doc markup warnings:
kernel/time/timekeeping.c:1563: warning: Function parameter or member
'wall_time' not described in 'read_persistent_wall_and_boot_offset'
kernel/time/timekeeping.c:1563: warning: Function parameter or member
'boot_offset' not described in 'read_persistent_wall_and_boot_offset'
The parameters are described but miss the leading '@' and the colon after
the parameter names.
[ tglx: Massaged changelog ]
Signed-off-by: Alex Shi <alex.shi@xxxxxxxxxxxxxxxxx>
Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Link: https://lore.kernel.org/r/1605252275-63652-6-git-send-email-alex.shi@xxxxxxxxxxxxxxxxx
---
kernel/time/timekeeping.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 9c93923..75cba95 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1576,8 +1576,9 @@ void __weak read_persistent_clock64(struct timespec64 *ts)
* from the boot.
*
* Weak dummy function for arches that do not yet support it.
- * wall_time - current time as returned by persistent clock
- * boot_offset - offset that is defined as wall_time - boot_time
+ * @wall_time: - current time as returned by persistent clock
+ * @boot_offset: - offset that is defined as wall_time - boot_time
+ *
* The default function calculates offset based on the current value of
* local_clock(). This way architectures that support sched_clock() but don't
* support dedicated boot time clock will provide the best estimate of the