All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.