From: Phillip Potter <phil@philpotter.co.uk>
To: Pavel Skripkin <paskripkin@gmail.com>
Cc: gregkh@linuxfoundation.org, dan.carpenter@oracle.com,
Larry.Finger@lwfinger.net, straube.linux@gmail.com,
martin@kaiser.cx, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 06/10] staging: r8188eu: remove DBG_88E calls from os_dep/ioctl_linux.c
Date: Thu, 27 Jan 2022 08:53:49 +0000 [thread overview]
Message-ID: <YfJdnTKa/gF9TEV5@equinox> (raw)
In-Reply-To: <b5bbe488-ac43-fd89-7c65-36bfa9c903a6@gmail.com>
On Wed, Jan 26, 2022 at 01:26:08PM +0300, Pavel Skripkin wrote:
> Hi Phillip,
>
> On 1/26/22 04:13, Phillip Potter wrote:
>
> [snip]
>
> }
> > >
> > > And here you also removes the reads. I guess, some kind of magic pattern is
> > > used
> > >
> >
> > So these calls are macro arguments, they would never be executed under
> > normal circumstances anyway, unless the rtw_debug kernel module was
> > passed in as 5 or more - it is 1 by default. The DBG_88E macro would
> > expand during preprocessing phase to (for example):
> >
> > do {
> > if (5 <= GlobalDebugLevel)
> > pr_info("R8188EU: " "dbg(0x450) = 0x%x\n", rtw_read32(padapter, 0x450));
> > } while (0)
> >
> > As this is never executed under normal circumstances anyway, I would say
> > calls like these are therefore safe to remove. Happy to be convinced
> > though :-) Many thanks.
> >
>
> I see your point, thanks for explanation.
>
> Well, in this case, you may left all reads, that are executed during normal
> lifetime of a driver. We know, that there is at least 1 place, where read()
> call removal can break things. Might be there are couple of other places we
> don't know about.
>
> IMHO the best thing you can do is to leave these reads and leave a comment
> like "hey, please remove me and test". One day useless reads should be
> anyway removed, since ideally rtw_read family must get __must_check
> annotation + normal error handling.
>
Yeah, not a bad idea - I've tried to remove only those which don't look
like they'd have side effects (such as fwstate checks etc.), but by all
means I can put them back in with the next revision. Thanks.
Regards,
Phil
next prev parent reply other threads:[~2022-01-27 8:53 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-24 22:44 [PATCH 00/10] Cleanup and removal of DBG_88E macro Phillip Potter
2022-01-24 22:44 ` [PATCH 01/10] staging: r8188eu: remove previously added dev_dbg and netdev_dbg calls Phillip Potter
2022-01-24 22:44 ` [PATCH 02/10] staging: r8188eu: remove smaller sets of DBG_88E calls from core dir Phillip Potter
2022-01-25 9:02 ` Dan Carpenter
2022-01-26 0:54 ` Phillip Potter
2022-01-26 6:00 ` Dan Carpenter
2022-01-25 18:17 ` Pavel Skripkin
2022-01-26 1:00 ` Phillip Potter
2022-01-24 22:44 ` [PATCH 03/10] staging: r8188eu: remove DBG_88E calls from core/rtw_mlme_ext.c Phillip Potter
2022-01-25 7:22 ` kernel test robot
2022-01-25 18:31 ` Pavel Skripkin
2022-01-26 1:02 ` Phillip Potter
2022-01-24 22:44 ` [PATCH 04/10] staging: r8188eu: remove all DBG_88E calls from hal dir Phillip Potter
2022-01-25 8:27 ` kernel test robot
2022-01-24 22:44 ` [PATCH 05/10] staging: r8188eu: remove smaller sets of DBG_88E calls from os_dep dir Phillip Potter
2022-01-25 12:48 ` Pavel Skripkin
2022-01-25 12:59 ` Dan Carpenter
2022-01-25 13:04 ` Pavel Skripkin
2022-01-25 13:07 ` Dan Carpenter
2022-01-26 0:58 ` Phillip Potter
2022-01-24 22:44 ` [PATCH 06/10] staging: r8188eu: remove DBG_88E calls from os_dep/ioctl_linux.c Phillip Potter
2022-01-25 9:31 ` kernel test robot
2022-01-25 19:03 ` Pavel Skripkin
2022-01-26 1:13 ` Phillip Potter
2022-01-26 10:26 ` Pavel Skripkin
2022-01-26 10:48 ` Greg KH
2022-01-26 10:58 ` Pavel Skripkin
2022-01-26 11:14 ` Greg KH
2022-01-27 8:53 ` Phillip Potter [this message]
2022-01-24 22:44 ` [PATCH 07/10] staging: r8188eu: remove DBG_88E call from include/usb_ops.h Phillip Potter
2022-01-24 22:44 ` [PATCH 08/10] staging: r8188eu: remove all remaining aliased DBG_88E calls Phillip Potter
2022-01-24 22:44 ` [PATCH 09/10] staging: r8188eu: remove DBG_88E macro definition Phillip Potter
2022-01-24 22:44 ` [PATCH 10/10] staging: r8188eu: remove GlobalDebugLevel flag Phillip Potter
2022-01-25 15:33 ` [PATCH 00/10] Cleanup and removal of DBG_88E macro Greg KH
2022-01-26 0:45 ` Phillip Potter
2022-01-24 22:50 [RESENT PATCH 00/10] staging: r8188eu: " Phillip Potter
2022-01-24 22:50 ` [PATCH 06/10] staging: r8188eu: remove DBG_88E calls from os_dep/ioctl_linux.c Phillip Potter
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=YfJdnTKa/gF9TEV5@equinox \
--to=phil@philpotter.co.uk \
--cc=Larry.Finger@lwfinger.net \
--cc=dan.carpenter@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=martin@kaiser.cx \
--cc=paskripkin@gmail.com \
--cc=straube.linux@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;
as well as URLs for NNTP newsgroup(s).