All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Molton <ian@mnementh.co.uk>
To: Arend van Spriel <arend.vanspriel@broadcom.com>,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH 13/30] brcmfmac: Clarify if using braces.
Date: Thu, 31 Aug 2017 16:35:28 +0100	[thread overview]
Message-ID: <0423e0d1-9ba5-5b06-31fc-e03a656e11b3@mnementh.co.uk> (raw)
In-Reply-To: <78917893-6b3d-9cfc-1f32-e27226ae6189@broadcom.com>

On 30/08/17 20:11, Arend van Spriel wrote:
>> Whilst this if () statement is technically correct, it lacks clarity.
> 
> I don't see the unclarity here. In my opinion people reading the code
> should have a good level in C language and a decent level of curiosity
> when they come across a function/macro like skb_queue_walk().

I thought it to be part of the general codingstyle for the kernel that
multi-line ifs and elses should be in braces, although I accept that
technically the if-clause is a single block-level statement.

Having said that, *this* specific example falls into a grey area in the
codingstyle, which covers multi-statement, multi-line if() clauses and
single-statement, single-line ones. It does not cover single-statement,
multi-line examples such as the one here.

Whilst I can't therefore definitively justify my position, I can show,
for example, line 999 in net/mac80211/iface.c where a for() statement
uses braces around the skb_queue_walk()

for (i = 0; i < IEEE80211_MAX_QUEUES; i++) {
        skb_queue_walk_safe(&local->pending[i], skb, tmp) {
                struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
                if (info->control.vif == &sdata->vif) {
                        __skb_unlink(skb, &local->pending[i]);
                        ieee80211_free_txskb(&local->hw, skb);
                }
        }
}


And the following in ath9k_htc_tx_cleanup_queue()

if (process) {
        skb_queue_walk_safe(&queue, skb, tmp) {
                __skb_unlink(skb, &queue);
                ath9k_htc_tx_process(priv, skb, NULL);
        }
}

So I feel that we should do the same.

-Ian

  reply	other threads:[~2017-08-31 15:35 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-22 11:25 [PATCH v5] brcmfmac cleanup Ian Molton
2017-08-22 11:25 ` [PATCH 01/30] brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb() Ian Molton
2017-08-30 18:51   ` Arend van Spriel
2017-08-31 15:17     ` Ian Molton
2017-08-22 11:25 ` [PATCH 02/30] brcmfmac: Register sizes on hardware are not dependent on compiler types Ian Molton
2017-08-22 11:25 ` [PATCH 03/30] brcmfmac: Split brcmf_sdiod_regrw_helper() up Ian Molton
2017-08-30 18:59   ` Arend van Spriel
2017-08-31 15:19     ` Ian Molton
2017-08-22 11:25 ` [PATCH 04/30] brcmfmac: Clean up brcmf_sdiod_set_sbaddr_window() Ian Molton
2017-08-22 11:25 ` [PATCH 05/30] brcmfmac: Remove dead IO code Ian Molton
2017-08-22 11:25 ` [PATCH 06/30] brcmfmac: Remove bandaid for SleepCSR Ian Molton
2017-08-22 11:25 ` [PATCH 07/30] brcmfmac: Remove brcmf_sdiod_request_data() Ian Molton
2017-08-22 11:25 ` [PATCH 08/30] brcmfmac: Fix asymmetric IO functions Ian Molton
2017-08-22 11:25 ` [PATCH 09/30] brcmfmac: Remove noisy debugging Ian Molton
2017-08-22 11:25 ` [PATCH 10/30] brcmfmac: Rename bcmerror to err Ian Molton
2017-08-22 11:25 ` [PATCH 11/30] brcmfmac: Split brcmf_sdiod_buffrw function up Ian Molton
2017-08-22 11:25 ` [PATCH 12/30] brcmfmac: Whitespace fixes Ian Molton
2017-08-30 19:05   ` Arend van Spriel
2017-08-22 11:25 ` [PATCH 13/30] brcmfmac: Clarify if using braces Ian Molton
2017-08-30 19:11   ` Arend van Spriel
2017-08-31 15:35     ` Ian Molton [this message]
2017-08-22 11:25 ` [PATCH 14/30] brcmfmac: Rename / replace old IO functions with simpler ones Ian Molton
2017-08-22 11:25 ` [PATCH 15/30] brcmfmac: Tidy register definitions a little Ian Molton
2017-08-30 19:13   ` Arend van Spriel
2017-08-22 11:25 ` [PATCH 16/30] brcmfmac: Remove brcmf_sdiod_addrprep() Ian Molton
2017-08-22 11:25 ` [PATCH 17/30] brcmfamc: remove unnecessary call to brcmf_sdiod_set_backplane_window() Ian Molton
2017-08-22 12:50   ` Julian Calaby
2017-08-22 19:38     ` Arend van Spriel
2017-08-22 19:44       ` Arend van Spriel
2017-08-23  0:03         ` Ian Molton
2017-08-23 10:09       ` Julian Calaby
2017-08-23 12:27         ` Ian Molton
2017-08-23 12:36           ` Julian Calaby
2017-08-23 21:53             ` Ian Molton
2017-08-22 11:25 ` [PATCH 18/30] brcmfmac: Cleanup offsetof() Ian Molton
2017-08-30 19:37   ` Arend van Spriel
2017-08-31 15:37     ` Ian Molton
2017-08-22 11:25 ` [PATCH 19/30] brcmfmac: Remove unused macro Ian Molton
2017-08-30 19:40   ` Arend van Spriel
2017-08-22 11:25 ` [PATCH 20/30] brcmfmac: Remove repeated calls to brcmf_chip_get_core() Ian Molton
2017-08-30 19:42   ` Arend van Spriel
2017-08-22 11:25 ` [PATCH 21/30] brcmfmac: Remove {r,w}_sdreg32 Ian Molton
2017-09-05 21:20   ` Arend van Spriel
2017-08-22 11:25 ` [PATCH 22/30] brcmfmac: Rename buscore->core for consistency Ian Molton
2017-09-05 21:20   ` Arend van Spriel
2017-08-22 11:25 ` [PATCH 23/30] brcmfmac: stabilise the value of ->sbwad in use for some xfer routines Ian Molton
2017-09-05 21:21   ` Arend van Spriel
2017-08-22 11:25 ` [PATCH 24/30] brcmfmac: Correctly handle accesses to SDIO func0 Ian Molton
2017-09-05 21:21   ` Arend van Spriel
2017-08-22 11:25 ` [PATCH 25/30] brcmfmac: Remove func0 from function array Ian Molton
2017-09-05 21:21   ` Arend van Spriel
2017-08-22 11:25 ` [PATCH 26/30] brcmfmac: More efficient and slightly easier to read fixup for 4339 chips Ian Molton
2017-09-05 21:21   ` Arend van Spriel
2017-08-22 11:25 ` [PATCH 27/30] brcmfmac: Replace function index with function pointer Ian Molton
2017-09-05 21:21   ` Arend van Spriel
2017-08-22 11:25 ` [PATCH 28/30] brcmfmac: Clean up interrupt macros Ian Molton
2017-09-05 21:19   ` Arend van Spriel
2017-08-22 11:25 ` [PATCH 29/30] brcmfmac: Remove array of functions Ian Molton
2017-08-22 11:25 ` [PATCH 30/30] brcmfmac: Reduce the noise from repeatedly dereferencing common pointers Ian Molton
2017-09-05 21:46   ` Arend van Spriel
2017-08-22 19:41 ` [PATCH v5] brcmfmac cleanup Arend van Spriel
2017-08-23  0:01   ` Ian Molton

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=0423e0d1-9ba5-5b06-31fc-e03a656e11b3@mnementh.co.uk \
    --to=ian@mnementh.co.uk \
    --cc=arend.vanspriel@broadcom.com \
    --cc=linux-wireless@vger.kernel.org \
    /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.