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: Wed, 26 Jan 2022 01:13:37 +0000 [thread overview]
Message-ID: <YfCgQbFxfVZXw9Fg@equinox> (raw)
In-Reply-To: <a681a562-eb41-9dc8-703a-5b235c15a3a1@gmail.com>
On Tue, Jan 25, 2022 at 10:03:06PM +0300, Pavel Skripkin wrote:
> Hi Phillip,
>
> On 1/25/22 01:44, Phillip Potter wrote:
> > Remove all DBG_88E calls from os_dep/ioctl_linux.c, as they do not
> > conform to kernel coding standards and are superfluous. Also restructure
> > where appropriate to remove no longer needed code left behind by removal
> > of these calls. This will allow the eventual removal of the DBG_88E macro
> > itself.
> >
> > Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
> > ---
>
> [code snip]
>
> > @@ -3746,7 +3541,6 @@ static int rtw_dbg_port(struct net_device *dev,
> > u32 write_num = extra_arg;
> > int i;
> > - u16 final;
> > struct xmit_frame *xmit_frame;
> > xmit_frame = rtw_IOL_accquire_xmit_frame(padapter);
> > @@ -3760,11 +3554,7 @@ static int rtw_dbg_port(struct net_device *dev,
> > if (rtl8188e_IOL_exec_cmds_sync(padapter, xmit_frame, 5000, 0) != _SUCCESS)
> > ret = -EPERM;
> > - final = rtw_read16(padapter, reg);
> > - if (start_value + write_num - 1 == final)
> > - DBG_88E("continuous IOL_CMD_WW_REG to 0x%x %u times Success, start:%u, final:%u\n", reg, write_num, start_value, final);
> > - else
> > - DBG_88E("continuous IOL_CMD_WW_REG to 0x%x %u times Fail, start:%u, final:%u\n", reg, write_num, start_value, final);
> > + rtw_read16(padapter, reg);
> > }
> > break;
>
> I see, that you somewhere removes reads and somewhere leaves them. What's
> the difference? I saw, that one of the places has the comment, that asks not
> to remove the read, but others do not have such comment
>
> I can point to few places in 2 and 4 patches where you have removed reads.
>
>
>
> [code snip]
>
> > @@ -4014,16 +3664,8 @@ static int rtw_dbg_port(struct net_device *dev,
> > {
> > u32 odm_flag;
> > - if (0xf == extra_arg) {
> > + if (extra_arg == 0xf) {
> > GetHalDefVar8188EUsb(padapter, HAL_DEF_DBG_DM_FUNC, &odm_flag);
> > - DBG_88E(" === DMFlag(0x%08x) ===\n", odm_flag);
> > - DBG_88E("extra_arg = 0 - disable all dynamic func\n");
> > - DBG_88E("extra_arg = 1 - disable DIG- BIT(0)\n");
> > - DBG_88E("extra_arg = 2 - disable High power - BIT(1)\n");
> > - DBG_88E("extra_arg = 3 - disable tx power tracking - BIT(2)\n");
> > - DBG_88E("extra_arg = 4 - disable BT coexistence - BIT(3)\n");
> > - DBG_88E("extra_arg = 5 - disable antenna diversity - BIT(4)\n");
> > - DBG_88E("extra_arg = 6 - enable all dynamic func\n");
> > } else {
> > /* extra_arg = 0 - disable all dynamic func
> > extra_arg = 1 - disable DIG
> > @@ -4032,51 +3674,17 @@ static int rtw_dbg_port(struct net_device *dev,
> > */
> > SetHalDefVar8188EUsb(padapter, HAL_DEF_DBG_DM_FUNC, &extra_arg);
> > GetHalDefVar8188EUsb(padapter, HAL_DEF_DBG_DM_FUNC, &odm_flag);
> > - DBG_88E(" === DMFlag(0x%08x) ===\n", odm_flag);
> > }
> > }
> > break;
>
> Is odm_flag needed now? Seems like it was used only for printing random
> debug info
You're right, it can probably go :-)
>
> > case 0xfd:
> > rtw_write8(padapter, 0xc50, arg);
> > - DBG_88E("wr(0xc50) = 0x%x\n", rtw_read8(padapter, 0xc50));
> > rtw_write8(padapter, 0xc58, arg);
> > - DBG_88E("wr(0xc58) = 0x%x\n", rtw_read8(padapter, 0xc58));
> > - break;
> > - case 0xfe:
> > - DBG_88E("rd(0xc50) = 0x%x\n", rtw_read8(padapter, 0xc50));
> > - DBG_88E("rd(0xc58) = 0x%x\n", rtw_read8(padapter, 0xc58));
> > - break;
> > - case 0xff:
> > - DBG_88E("dbg(0x210) = 0x%x\n", rtw_read32(padapter, 0x210));
> > - DBG_88E("dbg(0x608) = 0x%x\n", rtw_read32(padapter, 0x608));
> > - DBG_88E("dbg(0x280) = 0x%x\n", rtw_read32(padapter, 0x280));
> > - DBG_88E("dbg(0x284) = 0x%x\n", rtw_read32(padapter, 0x284));
> > - DBG_88E("dbg(0x288) = 0x%x\n", rtw_read32(padapter, 0x288));
> > -
> > - DBG_88E("dbg(0x664) = 0x%x\n", rtw_read32(padapter, 0x664));
> > -
> > - DBG_88E("\n");
> > -
> > - DBG_88E("dbg(0x430) = 0x%x\n", rtw_read32(padapter, 0x430));
> > - DBG_88E("dbg(0x438) = 0x%x\n", rtw_read32(padapter, 0x438));
> > -
> > - DBG_88E("dbg(0x440) = 0x%x\n", rtw_read32(padapter, 0x440));
> > -
> > - DBG_88E("dbg(0x458) = 0x%x\n", rtw_read32(padapter, 0x458));
> > -
> > - DBG_88E("dbg(0x484) = 0x%x\n", rtw_read32(padapter, 0x484));
> > - DBG_88E("dbg(0x488) = 0x%x\n", rtw_read32(padapter, 0x488));
> > -
> > - DBG_88E("dbg(0x444) = 0x%x\n", rtw_read32(padapter, 0x444));
> > - DBG_88E("dbg(0x448) = 0x%x\n", rtw_read32(padapter, 0x448));
> > - DBG_88E("dbg(0x44c) = 0x%x\n", rtw_read32(padapter, 0x44c));
> > - DBG_88E("dbg(0x450) = 0x%x\n", rtw_read32(padapter, 0x450));
> > break;
> > }
>
> 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.
Regards,
Phil
next prev parent reply other threads:[~2022-01-26 1:13 UTC|newest]
Thread overview: 39+ 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 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-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 9:31 ` kernel test robot
2022-01-25 19:03 ` Pavel Skripkin
2022-01-26 1:13 ` Phillip Potter [this message]
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
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
-- strict thread matches above, loose matches on Subject: below --
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=YfCgQbFxfVZXw9Fg@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 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.