linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Skripkin <paskripkin@gmail.com>
To: Phillip Potter <phil@philpotter.co.uk>
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: Wed, 26 Jan 2022 13:26:08 +0300	[thread overview]
Message-ID: <b5bbe488-ac43-fd89-7c65-36bfa9c903a6@gmail.com> (raw)
In-Reply-To: <YfCgQbFxfVZXw9Fg@equinox>

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.

Thanks :)




With regards,
Pavel Skripkin

  reply	other threads:[~2022-01-26 10:26 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 [this message]
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
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=b5bbe488-ac43-fd89-7c65-36bfa9c903a6@gmail.com \
    --to=paskripkin@gmail.com \
    --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=phil@philpotter.co.uk \
    --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).