From: AdrianRemonda <adrianremonda@gmail.com>
To: Joe Perches <joe@perches.com>
Cc: gregkh@linuxfoundation.org, Larry.Finger@lwfinger.net,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Staging: rtl8188eu: Lines over 80 characters fixed.
Date: Thu, 7 Aug 2014 23:45:32 +0200 [thread overview]
Message-ID: <20140807214532.GA11670@debian> (raw)
In-Reply-To: <1407192737.16152.83.camel@joe-AO725>
On Mon, Aug 04, 2014 at 03:52:17PM -0700, Joe Perches wrote:
> On Tue, 2014-08-05 at 00:45 +0200, Adrian Remonda wrote:
> > This is a patch to the hal/rtl8188eu_recv.c file that fixes up a "line
> > over 80 characters" warning found by the checkpatch.pl tool.
> []
> > diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
> > index f25c87c..8be4819 100644
> > --- a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
> > +++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
> > @@ -41,15 +41,19 @@ int rtl8188eu_init_recv_priv(struct adapter *padapter)
> > /* init recv_buf */
> > _rtw_init_queue(&precvpriv->free_recv_buf_queue);
> >
> > - precvpriv->pallocated_recv_buf = kzalloc(NR_RECVBUFF * sizeof(struct recv_buf) + 4, GFP_KERNEL);
> > + precvpriv->pallocated_recv_buf =
> > + kzalloc(NR_RECVBUFF * sizeof(struct recv_buf) + 4, GFP_KERNEL);
> > if (precvpriv->pallocated_recv_buf == NULL) {
> > res = _FAIL;
> > - RT_TRACE(_module_rtl871x_recv_c_, _drv_err_, ("alloc recv_buf fail!\n"));
> > + RT_TRACE(_module_rtl871x_recv_c_, _drv_err_,
> > + ("alloc recv_buf fail!\n"));
> > goto exit;
> > }
> > - memset(precvpriv->pallocated_recv_buf, 0, NR_RECVBUFF * sizeof(struct recv_buf) + 4);
> > + memset(precvpriv->pallocated_recv_buf, 0,
> > + NR_RECVBUFF * sizeof(struct recv_buf) + 4);
> >
> > - precvpriv->precv_buf = (u8 *)N_BYTE_ALIGMENT((size_t)(precvpriv->pallocated_recv_buf), 4);
> > + precvpriv->precv_buf = (u8 *)N_BYTE_ALIGMENT((size_t)
> > + (precvpriv->pallocated_recv_buf), 4);
>
> Several bits of this are not nice.
>
> the +4 seems senseless.
> zalloc followed by a memset(,0,) is senseless.
> N_BYTE_ALIGNMENT seems senseless as alloc is
> suitable for any alignmet.
>
> btw: The merge window is open, please be patient
> with any staging patch during the merge window.
I have resent the changes now. Is this ok? Or should I wait until the merge
window is close?
Also N_BYTE_ALIGNMENT is being used by several files in the 8188, should
I remove this macro?
next prev parent reply other threads:[~2014-08-07 21:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-04 22:45 [PATCH] Staging: rtl8188eu: Lines over 80 characters fixed Adrian Remonda
2014-08-04 22:52 ` Joe Perches
2014-08-07 21:45 ` AdrianRemonda [this message]
2014-08-08 9:10 ` Dan Carpenter
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=20140807214532.GA11670@debian \
--to=adrianremonda@gmail.com \
--cc=Larry.Finger@lwfinger.net \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox