[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220408061936.GP3293@kadam>
Date: Fri, 8 Apr 2022 09:19:36 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Jaehee Park <jhpark1013@...il.com>
Cc: Jérôme Pouiller <jerome.pouiller@...abs.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org,
outreachy@...ts.linux.dev, Stefano Brivio <sbrivio@...hat.com>
Subject: Re: [PATCH v2] staging: wfx: use container_of() to get vif
On Thu, Apr 07, 2022 at 11:23:49PM -0400, Jaehee Park wrote:
> diff --git a/drivers/staging/wfx/wfx.h b/drivers/staging/wfx/wfx.h
> index 6594cc647c2f..78f2a416fe4f 100644
> --- a/drivers/staging/wfx/wfx.h
> +++ b/drivers/staging/wfx/wfx.h
> @@ -25,6 +25,8 @@
> #define USEC_PER_TXOP 32 /* see struct ieee80211_tx_queue_params */
> #define USEC_PER_TU 1024
>
> +#define wvif_to_vif(ptr)(container_of((void *)ptr, struct ieee80211_vif, drv_priv))
> +
Better to make this a function.
Stefano's comments are correct. It would have saved space with the 80
limit to do a "struct ieee80211_vif *vif = wvif_to_vif();" at the start
of the function. Also dereferencing the results of a function call
like this, "frob(foo)->bar", without checking makes me itch. If it's
at the top of the function then that's kind of different. I normally
assume that the functions in the declaration block cannot fail. From
analysing static checker warnings, putting functions which can fail in
that the declaration block is risky.
It's always better to test things but this patch looks correct to me:
The add interface does:
struct wfx_vif *wvif = (struct wfx_vif *)vif->drv_priv
...
wvif->vif = vif;
The remove interface does:
wvif->vif = NULL;
Those are the only places where ->vif is set container_of() will always
work.
regards,
dan carpenter
Powered by blists - more mailing lists