[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200608054614.GO23230@ZenIV.linux.org.uk>
Date: Mon, 8 Jun 2020 06:46:14 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: "Rodolfo C. Villordo" <rodolfovillordo@...il.com>
Cc: Forest Bond <forest@...ttletooquiet.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Forest Bond <forest@...ttletooquiet.net>,Greg Kroah-Hartman
<gregkh@...uxfoundation.org>,devel@...verdev.osuosl.org,linux-kernel@...r.kernel.org
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
* local variables are useful
* if a long expression keeps cropping up all over the place, you
probably are missing an inline helper.
PS: this
> - buf->time_stamp_off_a = vnt_time_stamp_off(pDevice, wCurrentRate);
> - buf->time_stamp_off_b = vnt_time_stamp_off(pDevice, pDevice->byTopCCKBasicRate);
> + buf->time_stamp_off_a =
> + vnt_time_stamp_off(pDevice, wCurrentRate);
> + buf->time_stamp_off_b =
> + vnt_time_stamp_off(pDevice,
> + pDevice->byTopCCKBasicRate);
is no improvement.
Powered by blists - more mailing lists