Re: [PATCH] staging: rtl8188eu: Replace a custom function with crc32_le()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 01, 2021 at 03:38:09PM +0200, Fabio M. De Francesco wrote:
> Use crc32_le in place of the custom getcrc32. This change makes GCC
> to warn about incorrect castings to the restricted type __le32, but
> they can be safely ignored because crc32_le calculates bitwise
> little-endian Ethernet AUTODIN II CRC32.
> 
> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@xxxxxxxxx>
> ---
>  drivers/staging/rtl8188eu/core/rtw_security.c | 22 ++++---------------
>  1 file changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c b/drivers/staging/rtl8188eu/core/rtw_security.c
> index 1b2cb6196463..5f010cb66970 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_security.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_security.c
> @@ -111,21 +111,6 @@ static void crc32_init(void)
>  	bcrc32initialized = 1;
>  }
>  
> -static __le32 getcrc32(u8 *buf, int len)
> -{
> -	u8 *p;
> -	u32  crc;
> -
> -	if (bcrc32initialized == 0)
> -		crc32_init();
> -
> -	crc = 0xffffffff;       /* preload shift register, per CRC-32 spec */
> -
> -	for (p = buf; len > 0; ++p, --len)
> -		crc = crc32_table[(crc ^ *p) & 0xff] ^ (crc >> 8);
> -	return cpu_to_le32(~crc);    /* transmit complement, per CRC-32 spec */
> -}
> -
>  /* Need to consider the fragment  situation */
>  void rtw_wep_encrypt(struct adapter *padapter, struct xmit_frame *pxmitframe)
>  {
> @@ -609,14 +594,15 @@ u32	rtw_tkip_encrypt(struct adapter *padapter, struct xmit_frame *pxmitframe)
>  
>  				if ((curfragnum + 1) == pattrib->nr_frags) {	/* 4 the last fragment */
>  					length = pattrib->last_txcmdsz - pattrib->hdrlen - pattrib->iv_len - pattrib->icv_len;
> -					*((__le32 *)crc) = getcrc32(payload, length);/* modified by Amy*/
> +					*((__le32 *)crc) = ~crc32_le(~0, payload, length);

Why are you casting a native endian return value to a little endian
pointer?  Are you _SURE_ that is correct?

We can not just ignore warnings, they are there for a reason.  Or if
not, then fix the code up to not have the warnings, but I can't take
this as-is, sorry.

thanks,

greg k-h




[Index of Archives]     [Linux Driver Development]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux