Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 21 Aug 2021 19:48:46 +0530
From:   Aakash Hemadri <aakashhemadri123@gmail.com>
To:     "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Larry Finger <Larry.Finger@lwfinger.net>,
        Phillip Potter <phil@philpotter.co.uk>,
        linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/5] staging: r8188eu: restricted __be16 degrades to
 int
Message-ID: <20210821141846.k4n4eorn4ifk5lfj@xps.yggdrasil>
References: <cover.1629360917.git.aakashhemadri123@gmail.com>
 <bd63137c645ecc20dc446a6cfa7f7d3461a642d7.1629360917.git.aakashhemadri123@gmail.com>
 <YR6S7MfxpXpQFl9d@kroah.com>
 <1777630.LqDDHREl4S@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1777630.LqDDHREl4S@localhost.localdomain>
Precedence: bulk

On 21/08/20 05:10PM, Fabio M. De Francesco wrote:
> Building on the objections you had from Greg I suggest that, before attempting 
> anew to address problems like these, you get a better understanding of the topics of 
> native and network endianness and of the API that (conditionally) swap bytes 
> in a variable between little endian and big endian representation.
> 
> To start with, please note that the following code leads to tests for "v.vub[0] == 0xDD" 
> which is true on little endian architectures while "v.vub[0] == 0xAA" is true on big 
> endian ones...
> 
> union {
>         u32 vud;
>         u8 vub[4];
> } v;
> 
> v.vud = 0xAABBCCDD;
> 
> Also note that API like cpu_to_be32(), htonl(), be32_to_cpu(), ntohl, and the likes are 
> used to (conditionally) swap bytes (i.e., change the arrangement of the bytes in a 
> multi-bytes variable).
> 
> Casts have very different purposes and usage patterns and, above all, they cannot 
> magically change the endianness of a variable.
> 
> Regards,
> 
> Fabio
> 

Thanks for the explanation Fabio!
Will rework and send it through!

Thanks,
Aakash Hemadri