[PATCH 01/03] staging: dgap: fix a few more 80+ lines as reported by checkpatch
Mark Hounschell
markh at compro.net
Thu Mar 6 14:19:08 UTC 2014
On 03/05/2014 04:39 PM, Dan Carpenter wrote:
> Btw, if you don't get any messages from me that means I have given your
> patch the stamp of approval. So good job on your previous patchset. :)
>
> On Wed, Mar 05, 2014 at 03:54:49PM -0500, Mark Hounschell wrote:
>> @@ -1613,7 +1616,8 @@ static void dgap_tty_uninit(struct board_t *brd)
>> * dgap_sniff - Dump data out to the "sniff" buffer if the
>> * proc sniff file is opened...
>> */
>> -static void dgap_sniff_nowait_nolock(struct channel_t *ch, uchar *text, uchar *buf, int len)
>> +static void dgap_sniff_nowait_nolock(struct channel_t *ch, uchar *text,
>> + uchar *buf, int len)
>
> These don't line up properly. Here is what it looks like:
>
> static void dgap_sniff_nowait_nolock(struct channel_t *ch, uchar *text,
> uchar *buf, int len)
>
>
> This is what it should look like:
>
> static void dgap_sniff_nowait_nolock(struct channel_t *ch, uchar *text,
> uchar *buf, int len)
>
> [tab][tab][tab][tab][space][space][space][space][space]uchar *buf...
>
>
>> @@ -1686,7 +1692,8 @@ static void dgap_sniff_nowait_nolock(struct channel_t *ch, uchar *text, uchar *b
>> r = SNIFF_MAX - ch->ch_sniff_in;
>>
>> if (r <= n) {
>> - memcpy(ch->ch_sniff_buf + ch->ch_sniff_in, p, r);
>> + memcpy(ch->ch_sniff_buf + ch->ch_sniff_in,
>> + p, r);
>
>
> Function arguments line up:
>
> memcpy(ch->ch_sniff_buf + ch->ch_sniff_in, p,
> r);
>
As you say below, "Breaking the lines up like this isn't ideal". This
one I feel should have been left as is. It seems to me that breaking the
line like above should only be done, like if r was 8 chars or more? Even
if p was also on the other side of col 80, I would normally leave p and
r both alone?
>> @@ -2255,7 +2265,8 @@ static int dgap_block_til_ready(struct tty_struct *tty, struct file *file, struc
>> * touched safely, the close routine will signal the
>> * ch_wait_flags to wake us back up.
>> */
>> - if (!((ch->ch_tun.un_flags | ch->ch_pun.un_flags) & UN_CLOSING)) {
>> + if (!((ch->ch_tun.un_flags | ch->ch_pun.un_flags) &
>> + UN_CLOSING)) {
>
>
> This one lines up like this:
>
> if (!((ch->ch_tun.un_flags | ch->ch_pun.un_flags) &
> UN_CLOSING)) {
>
> With the 'U' and third '(' on the same column.
>
OK, I think I got it. That's how I do it in my own code too. So should
be easy to remember for staging.
> Breaking the lines up like this isn't ideal, of course. I would be
> tempted to leave the code as-is. In the end, we always apply
> checkpatch.pl fixes to stop people from resending them over and over but
> it's not the king of the world.
>
OK. Do ya think my rule above would be OK for me in this driver?
>> @@ -2431,7 +2444,8 @@ static void dgap_tty_close(struct tty_struct *tty, struct file *file)
>> * Only officially close channel if count is 0 and
>> * DIGI_PRINTER bit is not set.
>> */
>> - if ((ch->ch_open_count == 0) && !(ch->ch_digi.digi_flags & DIGI_PRINTER)) {
>> + if ((ch->ch_open_count == 0) &&
>> + !(ch->ch_digi.digi_flags & DIGI_PRINTER)) {
>>
>> ch->ch_flags &= ~(CH_RXBLOCK);
>
> On this one breaking the live up doesn't hurt readabilty at all. It
> should look like this.
>
> if ((ch->ch_open_count == 0) &&
> !(ch->ch_digi.digi_flags & DIGI_PRINTER)) {
>
> ch->ch_flags &= ~(CH_RXBLOCK);
>
> That way it's more cear that "ch->ch_flags &= ~(CH_RXBLOCK);" is not
> at the same indent level as "!(ch->ch_digi.digi_flags & DIGI_PRINTER))"
>
Right. Got it.
Thanks
Mark
More information about the devel
mailing list