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 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.