Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: Nikolay Borisov <nborisov@suse.com>
Subject: [PATCH v2 03/14] btrfs: Fix function description format
Date: Wed, 20 Jan 2021 12:25:15 +0200	[thread overview]
Message-ID: <20210120102526.310486-4-nborisov@suse.com> (raw)
In-Reply-To: <20210120102526.310486-1-nborisov@suse.com>

This fixes following W=1 warnings:

fs/btrfs/file-item.c:27: warning: Cannot understand  * @inode:  the inode we want to update the disk_i_size for
 on line 27 - I thought it was a doc line
fs/btrfs/file-item.c:65: warning: Cannot understand  * @inode - the inode we're modifying
 on line 65 - I thought it was a doc line
fs/btrfs/file-item.c:91: warning: Cannot understand  * @inode - the inode we're modifying
 on line 91 - I thought it was a doc line

Signed-off-by: Nikolay Borisov <nborisov@suse.com>
---
 fs/btrfs/file-item.c | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/fs/btrfs/file-item.c b/fs/btrfs/file-item.c
index 6ccfc019ad90..fedb200c39ca 100644
--- a/fs/btrfs/file-item.c
+++ b/fs/btrfs/file-item.c
@@ -24,8 +24,10 @@
 				       PAGE_SIZE))
 
 /**
- * @inode - the inode we want to update the disk_i_size for
- * @new_i_size - the i_size we want to set to, 0 if we use i_size
+ * btrfs_inode_safe_disk_i_size_write
+ *
+ * @inode:      the inode we want to update the disk_i_size for
+ * @new_i_size: the i_size we want to set to, 0 if we use i_size
  *
  * With NO_HOLES set this simply sets the disk_is_size to whatever i_size_read()
  * returns as it is perfectly fine with a file that has holes without hole file
@@ -62,9 +64,11 @@ void btrfs_inode_safe_disk_i_size_write(struct btrfs_inode *inode, u64 new_i_siz
 }
 
 /**
- * @inode - the inode we're modifying
- * @start - the start file offset of the file extent we've inserted
- * @len - the logical length of the file extent item
+ * btrfs_inode_set_file_extent_range
+ *
+ * @inode: the inode we're modifying
+ * @start: the start file offset of the file extent we've inserted
+ * @len:   the logical length of the file extent item
  *
  * Call when we are inserting a new file extent where there was none before.
  * Does not need to call this in the case where we're replacing an existing file
@@ -88,9 +92,11 @@ int btrfs_inode_set_file_extent_range(struct btrfs_inode *inode, u64 start,
 }
 
 /**
- * @inode - the inode we're modifying
- * @start - the start file offset of the file extent we've inserted
- * @len - the logical length of the file extent item
+ * btrfs_inode_clear_file_extent_range
+ *
+ * @inode: the inode we're modifying
+ * @start: the start file offset of the file extent we've inserted
+ * @len:   the logical length of the file extent item
  *
  * Called when we drop a file extent, for example when we truncate.  Doesn't
  * need to be called for cases where we're replacing a file extent, like when
-- 
2.25.1


  parent reply	other threads:[~2021-01-20 12:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20 10:25 [PATCH v2 00/14] Make btrfs W=1 clean Nikolay Borisov
2021-01-20 10:25 ` [PATCH v2 01/14] btrfs: Document modified paramater of add_extent_mapping Nikolay Borisov
2021-01-20 15:54   ` Josef Bacik
2021-01-20 10:25 ` [PATCH v2 02/14] btrfs: Fix parameter description of btrfs_add_extent_mapping Nikolay Borisov
2021-01-20 10:25 ` Nikolay Borisov [this message]
2021-01-21 16:23   ` [PATCH v2 03/14] btrfs: Fix function description format David Sterba
2021-01-20 10:25 ` [PATCH v2 04/14] btrfs: Fix parameter description in delayed-ref.c functions Nikolay Borisov
2021-01-20 10:25 ` [PATCH v2 05/14] btrfs: Improve parameter description for __btrfs_write_out_cache Nikolay Borisov
2021-01-20 10:25 ` [PATCH v2 06/14] btrfs: Document now parameter of peek_discard_list Nikolay Borisov
2021-01-20 10:25 ` [PATCH v2 07/14] btrfs: Document fs_info in btrfs_rmap_block Nikolay Borisov
2021-01-20 10:25 ` [PATCH v2 08/14] btrfs: Fix description format of fs_info parameter of btrfs_wait_on_delayed_iputs Nikolay Borisov
2021-01-20 10:25 ` [PATCH v2 09/14] btrfs: Document btrfs_check_shared parameters Nikolay Borisov
2021-01-20 10:25 ` [PATCH v2 10/14] btrfs: Fix parameter description of btrfs_inode_rsv_release/btrfs_delalloc_release_space Nikolay Borisov
2021-01-20 10:25 ` [PATCH v2 11/14] btrfs: Fix parameter description in space-info.c Nikolay Borisov
2021-01-20 10:25 ` [PATCH v2 12/14] btrfs: Fix parameter description for functions in extent_io.c Nikolay Borisov
2021-01-20 10:25 ` [PATCH v2 13/14] lib/zstd: Convert constants to defines Nikolay Borisov
2021-01-21 15:54   ` David Sterba
2021-01-20 10:25 ` [PATCH v2 14/14] btrfs: Enable W=1 checks for btrfs Nikolay Borisov
2021-01-20 15:55   ` Josef Bacik
2021-01-21  7:31     ` Nikolay Borisov
2021-01-24 13:23       ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210120102526.310486-4-nborisov@suse.com \
    --to=nborisov@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox