From: Phillip Potter <phil@philpotter.co.uk>
To: David Laight <David.Laight@aculab.com>
Cc: "dan.carpenter@oracle.com" <dan.carpenter@oracle.com>,
"Larry.Finger@lwfinger.net" <Larry.Finger@lwfinger.net>,
"straube.linux@gmail.com" <straube.linux@gmail.com>,
"martin@kaiser.cx" <martin@kaiser.cx>,
"linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"paskripkin@gmail.com" <paskripkin@gmail.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v2 15/15] staging: r8188eu: correct long line warnings near prior DBG_88E calls
Date: Wed, 16 Feb 2022 23:45:29 +0000 [thread overview]
Message-ID: <Yg2MmeJe1VGOQd4h@equinox> (raw)
In-Reply-To: <84f4a761263444c2940165dc403afb33@AcuMS.aculab.com>
On Wed, Feb 16, 2022 at 10:01:18AM +0000, David Laight wrote:
> From: Phillip Potter
> > Sent: 16 February 2022 01:07
> >
> > Where it is possible (without out-of-patch-series-scope large scale
> > refactoring), correct code to remove checkpatch warnings about lines
> > that are too long, also correcting operator spacing where appropriate
> > for these lines as well. These warnings occur mostly due to so many
> > DBG_88E removals and parentheses tweaks etc. being adjacent to such
> > long lines, which are therefore included in the resultant diff.
> ...
>
> Somewhere my copy of this seems to have got its tabs deleted.
> I blame outlook :-)
>
> > diff --git a/drivers/staging/r8188eu/core/rtw_br_ext.c b/drivers/staging/r8188eu/core/rtw_br_ext.c
> > index ddc3a2c8aaca..d68611ef22f8 100644
> > --- a/drivers/staging/r8188eu/core/rtw_br_ext.c
> > +++ b/drivers/staging/r8188eu/core/rtw_br_ext.c
> > @@ -382,7 +382,7 @@ int nat25_db_handle(struct adapter *priv, struct sk_buff *skb, int method)
> > if (protocol == ETH_P_IP) {
> > struct iphdr *iph = (struct iphdr *)(skb->data + ETH_HLEN);
> >
> > -if (((unsigned char *)(iph) + (iph->ihl<<2)) >= (skb->data + ETH_HLEN + skb->len))
> > +if (((unsigned char *)(iph) + (iph->ihl << 2)) >= (skb->data + ETH_HLEN + skb->len))
>
> You can delete at least three sets of () from that line.
>
> > return -1;
> >
> > switch (method) {
> > @@ -451,7 +451,11 @@ int nat25_db_handle(struct adapter *priv, struct sk_buff *skb, int method)
> > pOldTag = (struct pppoe_tag *)__nat25_find_pppoe_tag(ph, ntohs(PTT_RELAY_SID));
> > if (pOldTag) { /* if SID existed, copy old value and delete it */
> > old_tag_len = ntohs(pOldTag->tag_len);
> > -if (old_tag_len+TAG_HDR_LEN+MAGIC_CODE_LEN+RTL_RELAY_TAG_LEN > sizeof(tag_buf))
> > +if (old_tag_len +
> > + TAG_HDR_LEN +
> > + MAGIC_CODE_LEN +
> > + RTL_RELAY_TAG_LEN >
> > + sizeof(tag_buf))
> > return -1;
>
> That change really doesn't help readability at all.
> There isn't much point shortening it that much like that, especially
> since the here is a line that is nearly as long just above.
>
> The real fix is to reduce the number of levels of indentation
> to something sane.
> I suspect that use of continue, break and return will help.
>
> The other line length changes have much the same problem
> but not as sever.
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>
Dear David,
Thank you for your feedback, and yes I totally agree - this patch was
more for procedure's sake to quieten the checkpatch warnings, but I was
in two minds about whether I should include it.
The indentation level is absolutely what is the problem here, but it is
arguably not in scope for this particular patch set given these are
pre-existing lines that have the issue. Certainly needs fixing though
for sure - just that this is more substantial and worthy of a separate
patch set in my opinion.
Looks like I need to do V3 anyway as I missed an unused-but-set warning
in patch 5 of the series. I may therefore drop this patch in V3 and
perhaps work on the indentation problem more generally.
Regards,
Phil
prev parent reply other threads:[~2022-02-16 23:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-16 1:06 [PATCH v2 00/15] staging: r8188eu: Cleanup and removal of DBG_88E macro Phillip Potter
2022-02-16 1:06 ` [PATCH v2 01/15] staging: r8188eu: remove previously converted DBG_88E_LEVEL calls Phillip Potter
2022-02-16 1:06 ` [PATCH v2 02/15] staging: r8188eu: remove smaller sets of converted DBG_88E calls Phillip Potter
2022-02-16 9:42 ` Pavel Skripkin
2022-02-17 14:29 ` Dan Carpenter
2022-02-17 14:36 ` Dan Carpenter
2022-02-16 1:06 ` [PATCH v2 03/15] staging: r8188eu: remove converted DBG_88E calls from core/rtw_mlme_ext.c Phillip Potter
2022-02-16 9:50 ` Pavel Skripkin
2022-02-16 1:06 ` [PATCH v2 04/15] staging: r8188eu: remove DBG_88E calls from core subdir Phillip Potter
2022-02-16 1:06 ` [PATCH v2 05/15] staging: r8188eu: remove DBG_88E calls from hal subdir Phillip Potter
2022-02-16 21:35 ` kernel test robot
2022-02-16 21:35 ` kernel test robot
2022-02-16 1:07 ` [PATCH v2 06/15] staging: r8188eu: remove DBG_88E calls from os_dep/ioctl_linux.c Phillip Potter
2022-02-16 1:07 ` [PATCH v2 07/15] staging: r8188eu: remove remaining DBG_88E calls from os_dep subdir Phillip Potter
2022-02-16 1:07 ` [PATCH v2 08/15] staging: r8188eu: remove remaining DBG_88E call from include/usb_ops.h Phillip Potter
2022-02-16 1:07 ` [PATCH v2 09/15] staging: r8188eu: remove all aliased DBG_88E calls Phillip Potter
2022-02-16 1:07 ` [PATCH v2 10/15] staging: r8188eu: remove DBG_88E macro definition Phillip Potter
2022-02-16 1:07 ` [PATCH v2 11/15] staging: r8188eu: remove rtw_debug module parameter Phillip Potter
2022-02-16 1:07 ` [PATCH v2 12/15] staging: r8188eu: fix lines modified by DBG_88E cleanup Phillip Potter
2022-02-16 1:07 ` [PATCH v2 13/15] staging: r8188eu: remove rtw_sctx_chk_waring_status function Phillip Potter
2022-02-16 1:07 ` [PATCH v2 14/15] staging: r8188eu: remove padapter param from aes_decipher function Phillip Potter
2022-02-16 1:07 ` [PATCH v2 15/15] staging: r8188eu: correct long line warnings near prior DBG_88E calls Phillip Potter
2022-02-16 10:01 ` David Laight
2022-02-16 23:45 ` Phillip Potter [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=Yg2MmeJe1VGOQd4h@equinox \
--to=phil@philpotter.co.uk \
--cc=David.Laight@aculab.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=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.