From: Dan Carpenter <dan.carpenter@linaro.org>
To: Karolina Stolarek <karolina.stolarek@intel.com>
Cc: Julia Lawall <julia.lawall@inria.fr>,
kenechukwu maduechesi <maduechesik@gmail.com>,
outreachy@lists.linux.dev, shreeya.patel23498@gmail.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: rts5208: Replace delay function.
Date: Wed, 18 Oct 2023 13:42:23 +0300 [thread overview]
Message-ID: <e5c482ab-0342-43f5-a62f-c0c176e2e094@kadam.mountain> (raw)
In-Reply-To: <1118ec6d-e1e7-79f3-08e4-9a79c996eed1@intel.com>
On Wed, Oct 18, 2023 at 09:32:46AM +0200, Karolina Stolarek wrote:
> On 18.10.2023 09:03, Julia Lawall wrote:
> >
> >
> > On Tue, 17 Oct 2023, kenechukwu maduechesi wrote:
> >
> > > Replace udelay() with usleep_range() for more precise delay handling.
> > >
> > > Reported by checkpatch:
> > >
> > > CHECK: usleep_range is preferred over udelay
> >
> > This message is typically not a good candidate for outreachy patches,
> > because you need access to the device to be sure that any change is
> > correct.
>
> Could we add a paragraph on how to pick good checkpatch.pl error to fix to
> the Outreachyfirstpatch docs? This could go to "Find a driver to clean up"
> section, for example.
I think you should put a note about usleep_range() and the extra
parentheses one.
Also say something about looking up stuff on lore.
https://lore.kernel.org/all/?q=sd_change_phase%20usleep_range
In this case someone tried to update this before. The patch wasn't
merged but it wasn't clearly explained to the developer why the patch
wasn't merged. Ah well.
Generally fresh warnings are better than old warnings because we fix the
simple stuff where checkpatch is obviously correct.
The other thing is that people really need to look at the wider context.
Look at the surrounding code. Look at when the checkpatch warning was
introduced and try to put yourself in the developer's head to figure out
what they were thinking. Are there other opportunities for cleanups
nearby.
regards,
dan carpenter
next prev parent reply other threads:[~2023-10-18 10:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 1:03 kenechukwu maduechesi
2023-10-18 3:38 ` Andi Shyti
2023-10-18 7:03 ` Julia Lawall
2023-10-18 7:32 ` Karolina Stolarek
2023-10-18 7:45 ` Greg Kroah-Hartman
2023-10-18 7:52 ` Karolina Stolarek
2023-10-18 10:28 ` Julia Lawall
2023-10-18 10:40 ` Karolina Stolarek
2023-10-18 22:17 ` Alison Schofield
2023-10-18 10:42 ` Dan Carpenter [this message]
2023-10-18 10:38 ` Andi Shyti
2023-10-18 8:04 ` Karolina Stolarek
2023-10-23 23:09 ` kernel test robot
2023-11-05 20:58 ` kernel test robot
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=e5c482ab-0342-43f5-a62f-c0c176e2e094@kadam.mountain \
--to=dan.carpenter@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=julia.lawall@inria.fr \
--cc=karolina.stolarek@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=maduechesik@gmail.com \
--cc=outreachy@lists.linux.dev \
--cc=shreeya.patel23498@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
all inboxes | Powered by JetHome®