From: Dan Carpenter <dan.carpenter@linaro.org>
To: Riyan Dhiman <riyandhiman14@gmail.com>
Cc: gregkh@linuxfoundation.org, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: vme_user: vme_bridge.h: Document mutex in vme_dma_resource structure
Date: Wed, 14 Aug 2024 12:30:57 +0300 [thread overview]
Message-ID: <545da5b5-fe99-41c8-9cc2-a5861a04ba2b@stanley.mountain> (raw)
In-Reply-To: <CAAjz0QY9jDUx-URQTtdW3kO2mkfV4dhUsJhB9-k12SEt++Gp8g@mail.gmail.com>
On Wed, Aug 14, 2024 at 09:11:22AM +0530, Riyan Dhiman wrote:
> Yes, I agree 'mt' is a vague name and doesn't convey much information.
> In this patch, I have added only comments to address the checkpatch error.
> Given your suggestion to change the variable name, I'd like to confirm,
> Should I create a new patch that includes both the comment and the 'mtx'
> variable name change?
> Or should I leave this current patch with comments only and
> create a separate patch for the variable name changes?
I feel like renaming the spinlock is more useful than adding a comment. Plus
you can't really understand the locking without at least doing a temporary
rename to see what places break.
To be honest, we don't merge a lot of "add locking comments" because it's
probably one of the trickiest checkpatch warnings. You need to understand
the locking before you can add a useful comment.
When you're writing the comment, your target audience is Greg. Greg is
obviously a very experienced kernel developer. He works in USB, stable kernels,
staging, tty, device models stuff, and a bunch of other things. But, he doesn't
know *this* driver in great depth.
When Greg takes a look at this code, it doesn't take him long to make a very
educated guess what the locking is for. If the comment has less information
than Greg can see on his own at a glance then it's just a waste of time. If
someone had questions about the locking would they be better off asking you or
asking Greg? Until you can answer questions better than Greg then it's not
much point in it. Again, Greg doesn't know this driver very deeply because he's
focused on a million other things so it's not that hard.
Trying to figure out the locking is a good exercise. It wouldn't surprise me
if there were some locking bugs in this code and you should try to fix those.
But it's not super easy either.
regards,
dan carpenter
prev parent reply other threads:[~2024-08-14 9:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-03 0:18 [PATCH] staging: vme_user: vme_bridge.h: Document mutex in vme_dma_resource structure Riyan Dhiman
2024-08-03 4:23 ` Dan Carpenter
[not found] ` <CAAjz0QY9jDUx-URQTtdW3kO2mkfV4dhUsJhB9-k12SEt++Gp8g@mail.gmail.com>
2024-08-14 9:30 ` Dan Carpenter [this message]
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=545da5b5-fe99-41c8-9cc2-a5861a04ba2b@stanley.mountain \
--to=dan.carpenter@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=riyandhiman14@gmail.com \
/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