From: "Jérôme Pouiller" <jerome.pouiller@silabs.com>
To: Tomer Samara <tomersamara98@gmail.com>
Cc: gregkh@linuxfoundation.org, devel@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] staging: wfx: refactor to avoid duplication at hif_tx.c
Date: Mon, 10 Aug 2020 11:38:33 +0200 [thread overview]
Message-ID: <2040746.q8W4dvF0dS@pc-42> (raw)
In-Reply-To: <20200805121442.GA31953@tsnow>
Hello Tomer,
On Wednesday 5 August 2020 14:14:42 CEST Tomer Samara wrote:
>
> Add functions wfx_full_send(), wfx_full_send_no_reply_async(),
> wfx_full_send_no_reply() and wfx_full_send_no_reply_free()
> which works as follow:
> wfx_full_send() - simple wrapper for both wfx_fill_header()
> and wfx_cmd_send().
> wfx_full_send_no_reply_async() - wrapper for both but with
> NULL as reply and size zero.
> wfx_full_send_no_reply() - same as wfx_full_send_no_reply_async()
> but with false async value
> wfx_full_send_no_reply_free() - same as wfx_full_send_no_reply()
> but also free the struct hif_msg.
>
> Signed-off-by: Tomer Samara <tomersamara98@gmail.com>
> ---
> Changes in v2:
> - Changed these functions to static
>
> drivers/staging/wfx/hif_tx.c | 180 ++++++++++++++++-------------------
> 1 file changed, 80 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/staging/wfx/hif_tx.c b/drivers/staging/wfx/hif_tx.c
> index 5110f9b93762..17f668fa40a0 100644
> --- a/drivers/staging/wfx/hif_tx.c
> +++ b/drivers/staging/wfx/hif_tx.c
> @@ -40,7 +40,7 @@ static void wfx_fill_header(struct hif_msg *hif, int if_id,
>
> static void *wfx_alloc_hif(size_t body_len, struct hif_msg **hif)
> {
> - *hif = kzalloc(sizeof(struct hif_msg) + body_len, GFP_KERNEL);
> + *hif = kzalloc(sizeof(*hif) + body_len, GFP_KERNEL);
This change is not related to the rest of the patch. It should probably be
split out.
> if (*hif)
> return (*hif)->body;
> else
> @@ -123,9 +123,39 @@ int wfx_cmd_send(struct wfx_dev *wdev, struct hif_msg *request,
> return ret;
> }
>
> +static int wfx_full_send(struct wfx_dev *wdev, struct hif_msg *hif, void *reply,
> + size_t reply_len, bool async, int if_id, unsigned int cmd,
> + int size)
> +{
> + wfx_fill_header(hif, if_id, cmd, size);
> + return wfx_cmd_send(wdev, hif, reply, reply_len, async);
> +}
This function takes 8 parameters. Are you sure it simplifies the code?
In add, it does two actions: modify hif and send it. I would keep these
two actions separated.
> +
> +static int wfx_full_send_no_reply_async(struct wfx_dev *wdev, struct hif_msg *hif, int if_id,
> + unsigned int cmd, int size, bool async)
> +{
> + return wfx_full_send(wdev, hif, NULL, 0, async, if_id, cmd, size);
> +}
Does it make sense to have a parameter 'async' to
wfx_full_send_no_reply_async()? It is weird to call this function with
async=false, no?
> +
> +static int wfx_full_send_no_reply(struct wfx_dev *wdev, struct hif_msg *hif, int if_id,
> + unsigned int cmd, int size)
> +{
> + return wfx_full_send_no_reply_async(wdev, hif, if_id, cmd, size, false);
> +}
> +
> +static int wfx_full_send_no_reply_free(struct wfx_dev *wdev, struct hif_msg *hif, int if_id,
> + unsigned int cmd, int size)
> +{
> + int ret;
> +
> + ret = wfx_full_send_no_reply(wdev, hif, if_id, cmd, size);
> + kfree(hif);
> + return ret;
> +}
One more time, sending the data and releasing are unrelated actions.
Indeed, it saves a few lines of code, but is it really an improvement?
> +
> // This function is special. After HIF_REQ_ID_SHUT_DOWN, chip won't reply to any
> // request anymore. We need to slightly hack struct wfx_hif_cmd for that job. Be
> -// carefull to only call this funcion during device unregister.
> +// careful to only call this function during device unregister.
Not related to the rest of the patch.
[...]
As it stands, I think this change does not improve the code. Obviously, it
is a subjective opinion. What the other developers think about it?
--
Jérôme Pouiller
next prev parent reply other threads:[~2020-08-10 9:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-05 12:14 [PATCH v2] staging: wfx: refactor to avoid duplication at hif_tx.c Tomer Samara
2020-08-10 9:38 ` Jérôme Pouiller [this message]
2020-08-18 14:02 ` Greg KH
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=2040746.q8W4dvF0dS@pc-42 \
--to=jerome.pouiller@silabs.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tomersamara98@gmail.com \
/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.