From: Oscar Carter <oscar.carter@gmx.com>
To: Joe Perches <joe@perches.com>
Cc: Oscar Carter <oscar.carter@gmx.com>,
Forest Bond <forest@alittletooquiet.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Malcolm Priestley <tvboxspy@gmail.com>,
Quentin Deslandes <quentin.deslandes@itdev.co.uk>,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] staging: vt6656: Remove the local variable "array"
Date: Sat, 25 Apr 2020 16:29:40 +0200 [thread overview]
Message-ID: <20200425142940.GC3213@ubuntu> (raw)
In-Reply-To: <b5aa72347748f35245f2fd0272ab3957179ed2eb.camel@perches.com>
On Sat, Apr 25, 2020 at 05:50:39AM -0700, Joe Perches wrote:
> On Sat, 2020-04-25 at 14:38 +0200, Oscar Carter wrote:
> > Remove the local variable "array" and all the memcpy function calls
> > because this copy operation from different arrays to this variable is
> > unnecessary.
>
> You might write here that vnt_control_out already does
> a kmemdup copy of its const char *buffer argument and
> this was made unnecessary by:
>
> commit 12ecd24ef93277e4e5feaf27b0b18f2d3828bc5e
> Author: Malcolm Priestley <tvboxspy@gmail.com>
> Date: Sat Apr 22 11:14:57 2017 +0100
>
> staging: vt6656: use off stack for out buffer USB transfers.
>
> Since 4.9 mandated USB buffers be heap allocated this causes the driver
> to fail.
>
> Since there is a wide range of buffer sizes use kmemdup to create
> allocated buffer.
>
Great. I will add all this information to clarify the commit changelog.
>
> > The same result can be achieved using the arrays directly.
> >
> > Signed-off-by: Oscar Carter <oscar.carter@gmx.com>
> > ---
> > drivers/staging/vt6656/rf.c | 21 +++++----------------
> > 1 file changed, 5 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
> > index 06fa8867cfa3..82d3b6081b5b 100644
> > --- a/drivers/staging/vt6656/rf.c
> > +++ b/drivers/staging/vt6656/rf.c
> > @@ -770,7 +770,6 @@ int vnt_rf_table_download(struct vnt_private *priv)
> > u16 length1 = 0, length2 = 0, length3 = 0;
> > u8 *addr1 = NULL, *addr2 = NULL, *addr3 = NULL;
> > u16 length, value;
> > - u8 array[256];
> >
> > switch (priv->rf_type) {
> > case RF_AL2230:
> > @@ -817,10 +816,8 @@ int vnt_rf_table_download(struct vnt_private *priv)
> > }
> >
> > /* Init Table */
> > - memcpy(array, addr1, length1);
> > -
> > ret = vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
> > - MESSAGE_REQUEST_RF_INIT, length1, array);
> > + MESSAGE_REQUEST_RF_INIT, length1, addr1);
> > if (ret)
> > goto end;
> >
> > @@ -832,10 +829,8 @@ int vnt_rf_table_download(struct vnt_private *priv)
> > else
> > length = length2;
> >
> > - memcpy(array, addr2, length);
> > -
> > ret = vnt_control_out(priv, MESSAGE_TYPE_WRITE, value,
> > - MESSAGE_REQUEST_RF_CH0, length, array);
> > + MESSAGE_REQUEST_RF_CH0, length, addr2);
> > if (ret)
> > goto end;
> >
> > @@ -852,10 +847,8 @@ int vnt_rf_table_download(struct vnt_private *priv)
> > else
> > length = length3;
> >
> > - memcpy(array, addr3, length);
> > -
> > ret = vnt_control_out(priv, MESSAGE_TYPE_WRITE, value,
> > - MESSAGE_REQUEST_RF_CH1, length, array);
> > + MESSAGE_REQUEST_RF_CH1, length, addr3);
> > if (ret)
> > goto end;
> >
> > @@ -870,11 +863,9 @@ int vnt_rf_table_download(struct vnt_private *priv)
> > addr1 = &al7230_init_table_amode[0][0];
> > addr2 = &al7230_channel_table2[0][0];
> >
> > - memcpy(array, addr1, length1);
> > -
> > /* Init Table 2 */
> > ret = vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
> > - MESSAGE_REQUEST_RF_INIT2, length1, array);
> > + MESSAGE_REQUEST_RF_INIT2, length1, addr1);
> > if (ret)
> > goto end;
> >
> > @@ -886,11 +877,9 @@ int vnt_rf_table_download(struct vnt_private *priv)
> > else
> > length = length2;
> >
> > - memcpy(array, addr2, length);
> > -
> > ret = vnt_control_out(priv, MESSAGE_TYPE_WRITE, value,
> > MESSAGE_REQUEST_RF_CH2, length,
> > - array);
> > + addr2);
> > if (ret)
> > goto end;
> >
> > --
> > 2.20.1
> >
>
thanks,
oscar carter
next prev parent reply other threads:[~2020-04-25 14:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-25 12:38 [PATCH 0/3] Refactor the vnt_rf_table_download function Oscar Carter
2020-04-25 12:38 ` [PATCH 1/3] staging: vt6656: Remove the local variable "array" Oscar Carter
2020-04-25 12:50 ` Joe Perches
2020-04-25 14:29 ` Oscar Carter [this message]
2020-04-25 12:38 ` [PATCH 2/3] staging: vt6656: Use return instead of goto Oscar Carter
2020-04-25 12:38 ` [PATCH 3/3] staging: vt6656: Remove duplicate code in vnt_rf_table_download Oscar Carter
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=20200425142940.GC3213@ubuntu \
--to=oscar.carter@gmx.com \
--cc=devel@driverdev.osuosl.org \
--cc=forest@alittletooquiet.net \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=quentin.deslandes@itdev.co.uk \
--cc=tvboxspy@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.