[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200818140209.GA547677@kroah.com>
Date: Tue, 18 Aug 2020 16:02:09 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Jérôme Pouiller <jerome.pouiller@...abs.com>
Cc: Tomer Samara <tomersamara98@...il.com>, devel@...verdev.osuosl.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] staging: wfx: refactor to avoid duplication at
hif_tx.c
On Mon, Aug 10, 2020 at 11:38:33AM +0200, Jérôme Pouiller wrote:
> 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@...il.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?
I agree with you, this just makes things more complex for no good
reason.
Now dropped from my review queue.
thanks,
greg k-h
Powered by blists - more mailing lists