From: Joe Perches <joe@perches.com>
To: Julia Lawall <julia.lawall@inria.fr>, Al Viro <viro@zeniv.linux.org.uk>
Cc: "Rodolfo C. Villordo" <rodolfovillordo@gmail.com>,
Forest Bond <forest@alittletooquiet.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Forest Bond <forest@alittletooquiet.net>,Greg Kroah-Hartman <gregkh@linuxfoundation.org>,devel@driverdev.osuosl.org,linux-kernel@vger.kernel.org
Date: Mon, 08 Jun 2020 01:41:11 -0700 [thread overview]
Message-ID: <e3d7cc965eccec881bc35ae18d63f4bc23c33dfc.camel@perches.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2006080758510.2430@hadrien>
On Mon, 2020-06-08 at 07:59 +0200, Julia Lawall wrote:
> On Mon, 8 Jun 2020, Al Viro wrote:
>
> > On Sun, Jun 07, 2020 at 10:41:56PM +0000, Rodolfo C. Villordo wrote:
> > > Multiple line over 80 characters fixes by splitting in multiple lines.
> > > Warning found by checkpatch.pl
> >
> > I doubt that checkpatch.pl can catch the real problems there:
> >
> > * Hungarian Notation Sucks. Really.
> > * so does CamelCase, especially for wonders like s_uGetRTSCTSRsvTime
>
> Rodolfo,
>
> If you work hard with Coccinelle and python scripting, it can help with
> the first two problems.
These VIA vt6655/vt6656 drivers have been in staging for more than
a decade. There are relatively few checkpatch coding style
cleanups to do but there are many overall style issues to resolve.
It's true the identifier transforms could be done with Coccinelle,
but the problem is larger than identifier types and line lengths.
Hungarian renaming can't really be automated, it's basically a
sed problem where the new identifiers have to be chosen by someone
with specific device knowledge.
Look at vt6655/rf.c:
Lots of things should be reduced/replaced/simplified.
For instance, these repeated patterns exist:
"(BY_AL2230_REG_LEN << 3) + IFREGCTL_REGW"
"(BY_AL7230_REG_LEN << 3) + IFREGCTL_REGW"
There are 300+ uses just in this one file.
It's a lot of visual noise that should be minimized by using macros.
It would also reduce the number of checkpatch's long line warnings.
All the of unsigned char could be u8, unsigned short -> u16, etc.
Many arrays could be static const.
Nearly every function in the file could be improved.
For instance, this code could be written altogether:
bool RFbAL7230SelectChannelPostProcess(struct vnt_private *priv,
u16 byOldChannel,
u16 byNewChannel)
{
bool ret;
ret = true;
/* if change between 11 b/g and 11a need to update the following
* register
* Channel Index 1~14
*/
if ((byOldChannel <= CB_MAX_CHANNEL_24G) && (byNewChannel > CB_MAX_CHANNEL_24G)) {
/* Change from 2.4G to 5G [Reg] */
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTableAMode[2]);
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTableAMode[3]);
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTableAMode[5]);
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTableAMode[7]);
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTableAMode[10]);
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTableAMode[12]);
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTableAMode[15]);
} else if ((byOldChannel > CB_MAX_CHANNEL_24G) && (byNewChannel <= CB_MAX_CHANNEL_24G)) {
/* Change from 5G to 2.4G [Reg] */
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTable[2]);
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTable[3]);
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTable[5]);
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTable[7]);
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTable[10]);
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTable[12]);
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTable[15]);
}
return ret;
}
This could be something like: (written in email client, untested)
{
unsigned long *table;
static const int indices[] = {2, 3, 5, 7, 10, 12, 15};
int i;
bool ret = true;
/* if changing between 11b/g and 11a, update the indices registers */
if (byOldChannel <= CB_MAX_CHANNEL_24G && byNewChannel > CB_MAX_CHANNEL_24G)
table = dwAL7230InitTableAMode;
else if (byOldChannel > CB_MAX_CHANNEL_24G && byNewChannel <= CB_MAX_CHANNEL_24G)
table = dwAL7230InitTable;
else
return ret;
for (i = 0 ; i < ARRAY_SIZE(indices); i++)
ret &= IFRFbWriteEmbedded(priv, table[indices[i]]);
return ret;
}
next prev parent reply other threads:[~2020-06-08 8:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-07 22:41 Rodolfo C. Villordo
2020-06-08 5:15 ` Greg Kroah-Hartman
2020-06-08 5:46 ` Al Viro
2020-06-08 5:59 ` Julia Lawall
2020-06-08 8:41 ` Joe Perches [this message]
[not found] ` <20200608225838.GA26559@ip-172-31-24-31.ec2.internal>
2020-06-08 23:33 ` Joe Perches
2020-06-10 19:20 ` Rodolfo C Villordo
2020-06-08 7:26 ` Dan Carpenter
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=e3d7cc965eccec881bc35ae18d63f4bc23c33dfc.camel@perches.com \
--to=joe@perches.com \
--cc=forest@alittletooquiet.net \
--cc=gregkh@linuxfoundation.org \
--cc=julia.lawall@inria.fr \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rodolfovillordo@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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®