lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140807214532.GA11670@debian>
Date:	Thu, 7 Aug 2014 23:45:32 +0200
From:	AdrianRemonda <adrianremonda@...il.com>
To:	Joe Perches <joe@...ches.com>
Cc:	gregkh@...uxfoundation.org, Larry.Finger@...inger.net,
	devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Staging: rtl8188eu: Lines over 80 characters fixed.

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?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ