linux-kernel - Re: [PATCH] staging: wilc1000: use kernel define byte order macros

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 10 Apr 2017 15:36:26 -0400
From:   perry <perry.hooker@...il.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>
Cc:     devel@...verdev.osuosl.org, gregkh@...uxfoundation.org,
        aditya.shankar@...rochip.com, linux-kernel@...r.kernel.org,
        ganesh.krishna@...rochip.com
Subject: Re: [PATCH] staging: wilc1000: use kernel define byte order macros

Hi Dan,

Can you clarify why the rx_buffer always holds little-endian data? It looks to me like this buffer is filled by
wilc_sdio_cmd53(), which uses sdio_memcpy_toio(), which ultimately sets the data with sg_set_buf(). This function
appears to use host-endian byte ordering.

Regards,
Perry

On Fri, 2017-03-24 at 11:57 +0300, Dan Carpenter wrote:
> On Thu, Mar 23, 2017 at 04:15:06PM -0600, Robert Perry Hooker wrote:
> > Well, yes, all data is 'endian' one way or another, right? I guess the byte order of the tx/rx_buffers is host
> > -endian
> > (which could be big), or _maybe_ network-endian...
> 
> The good news is this code is Open Source[tm] so we don't need to guess.
> It's full of little endian data.
> 
> regards,
> dan carpenter
>