Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2794848rwb; Fri, 16 Dec 2022 06:38:19 -0800 (PST) X-Google-Smtp-Source: AA0mqf7wGI0BCKf6cCVd/vL7e3iuoN1I6+3bt4mOhLV4fJXOgVbjdxcKRvhv7oi4y5CADsfKZG0C X-Received: by 2002:a17:90a:1b02:b0:220:f82d:b938 with SMTP id q2-20020a17090a1b0200b00220f82db938mr32170461pjq.23.1671201499466; Fri, 16 Dec 2022 06:38:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671201499; cv=none; d=google.com; s=arc-20160816; b=c2PU0SCRYh/enc24hsJZAp/Hgy01Up0rVB9rruVUINrBEElw0JtYIUSXeyD7t2lWhr /MgTHPznKx3e7B+HvenHyChipJ0r3JTATd8Bt7dcP7guVmBsdDus8RdbqoCsxCCHvRqN TGDUIryqtkZfdhMzH51jB9r/djIyEMPRxeY3p1dBRU4U8z9GEdLF7bscfFuytV0u1q/t ZTkknR+TvHX+DS0uBB6Mawxqngty3s4TQ11vVRKMpnDhSNwESSQFQTK7/mQV5qnF+oUj d5kv620I8La54hcj+XtovkI/QkL6Go2OWf7+7nc+SYJncYT3+Z3g+WoL4GAJOMs0tf4e Y4Cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:references:in-reply-to:subject:cc:to:dkim-signature :from; bh=ILMWiiZScwNS17d6HWaLnIR8QTb1Z5L9e+H48oAWxWw=; b=njvwOEYiDgzFk4ORKFuf+TQUOpIb1oIqxH0HDxgWYSwxAlf6p0VFCRFBqNNGf4f4W8 p+EHPJKGyBBe5O650z7e1PuZiLOCOJFxZEOBlbwfiTlb2VxJ98UY1/UTa/wIiE7Q1SMF 0XA6kTSzsJOAxrc3hkRAcYL0mk8MEOS0DOtAq6sW/SiPvcNf7EhriFY+uuF/qcbivTQg q0Ed7PiHMhJIhZllKJ9q5DELmndrNLxBmRpdKm6+2/bnrOLJk/MVqOTmrRZKy5jaNMV6 o5xFu13aCA7LlsQiqKLx4VF+sXXPn+l09Hp2j1NjbfH3ugG2OCgf59CJXq0iOwmRxfng hozA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@toke.dk header.s=20161023 header.b=arjRdpzm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=toke.dk Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k7-20020a17090a514700b00219d31681b8si7855082pjm.42.2022.12.16.06.38.10; Fri, 16 Dec 2022 06:38:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@toke.dk header.s=20161023 header.b=arjRdpzm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=toke.dk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231168AbiLPOdP (ORCPT + 68 others); Fri, 16 Dec 2022 09:33:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231167AbiLPOdM (ORCPT ); Fri, 16 Dec 2022 09:33:12 -0500 X-Greylist: delayed 76056 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Fri, 16 Dec 2022 06:33:11 PST Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7619C566D0; Fri, 16 Dec 2022 06:33:11 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1671201189; bh=dm0GBBree+SzylXPIjAaBNY2/TXFZ6Txd1DUGNgA7kM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=arjRdpzmmwyuBBv92opnBlSC6VrJWXzN266Fc1S1FE5zJC5gntpkUE5y0CwDDOieo EGyz9oOBQTHDH9numOR3RSPNRWKixD2c9L+eZ0ApVbAbR3pBx+lgAJvh2qt+Ovu/WJ zfIJfl1wrCt5CQUpUvkfX+gwVQj80nUOA/RW/9t6y8ukCUYDzNqnZe6LtI84tNfWZz SEjangNkQEpYvp0BKO2UlvLHBh8yQWo1M1oRaAsxNjCzdTCFSoujOcI48f/Y10cPwk t6wqY7Sg1rhdnznF3543cKAWwFtO9rvCrHvb87LcN1Uu4SO+4NVO3n6X8mcLRV+NYK NzKfu/uyh4BfA== To: Arnd Bergmann , Arnd Bergmann , Kalle Valo , Pavel Skripkin Cc: "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Tetsuo Handa , linux-wireless@vger.kernel.org, Netdev , linux-kernel@vger.kernel.org Subject: Re: [PATCH] ath9k: use proper statements in conditionals In-Reply-To: <486f9bc9-408f-4c29-b675-cbd61673f58c@app.fastmail.com> References: <20221215165553.1950307-1-arnd@kernel.org> <87k02sd1uz.fsf@toke.dk> <486f9bc9-408f-4c29-b675-cbd61673f58c@app.fastmail.com> Date: Fri, 16 Dec 2022 15:33:07 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87fsdfbeqk.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Arnd Bergmann" writes: > On Thu, Dec 15, 2022, at 18:16, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>> index 30f0765fb9fd..237f4ec2cffd 100644 >>> --- a/drivers/net/wireless/ath/ath9k/htc.h >>> +++ b/drivers/net/wireless/ath/ath9k/htc.h >>> @@ -327,9 +327,9 @@ static inline struct ath9k_htc_tx_ctl *HTC_SKB_CB(s= truct sk_buff *skb) >>> } >>>=20=20 >>> #ifdef CONFIG_ATH9K_HTC_DEBUGFS >>> -#define __STAT_SAFE(hif_dev, expr) ((hif_dev)->htc_handle->drv_priv ? = (expr) : 0) >>> -#define CAB_STAT_INC(priv) ((priv)->debug.tx_stats.cab_queued++) >>> -#define TX_QSTAT_INC(priv, q) ((priv)->debug.tx_stats.queue_stats[q]+= +) >>> +#define __STAT_SAFE(hif_dev, expr) do { ((hif_dev)->htc_handle->drv_pr= iv ? (expr) : 0); } while (0) >>> +#define CAB_STAT_INC(priv) do { ((priv)->debug.tx_stats.cab_queued++)= ; } while (0) >>> +#define TX_QSTAT_INC(priv, q) do { ((priv)->debug.tx_stats.queue_stat= s[q]++); } while (0) >> >> Hmm, is it really necessary to wrap these in do/while constructs? AFAICT >> they're all simple statements already? > > It's generally safer to do the same thing on both side of the #ifdef. > > The "do { } while (0)" is an empty statement that is needed to fix > the bug on the #else side. The expressions you have on the #ifdef > side can be used as values, and wrapping them in do{}while(0) > turns them into statements (without a value) as well, so fewer > things can go wrong when you only test one side. Alright, makes sense; thanks for explaining! > I suppose the best solution would be to just use inline functions > for all of them and get rid of the macros. Let's merge this patch to fix the bug, and if someone wants to follow up with a conversion to inline functions, that would be awesome, of course :) -Toke