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:   Tue, 15 Sep 2020 13:49:23 +0200
From:   Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To:     "Daniel W. S. Almeida" <dwlsalmeida@gmail.com>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH RFC 06/11] media: vidtv: get rid of some endiannes
 nonsense
Message-ID: <20200915134923.4794f704@coco.lan>
In-Reply-To: <68DDA2DD-4341-45A9-99CF-BF41573C9AED@getmailspring.com>
References: <47ccbcbd23e44159bbb11274b540d7c2bb66be7c.1600073975.git.mchehab+huawei@kernel.org>
        <68DDA2DD-4341-45A9-99CF-BF41573C9AED@getmailspring.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Daniel,

Em Mon, 14 Sep 2020 12:14:38 -0300
"Daniel W. S. Almeida" <dwlsalmeida@gmail.com> escreveu:

> Hi Mauro,
> 
> > Genmask is always highest order to low order. It doesn't make
> > any sense to make it depends on endiannes.
> >   
> 
> I added these #ifdefs due to this:
> 
> https://lwn.net/Articles/741762/
> 
> i.e.
> 
> Fields to access are specified as GENMASK() values - an N-bit field
> starting at bit #M is encoded as GENMASK(M + N - 1, N).  Note that
> bit numbers refer to endianness of the object we are working with -
> e.g. GENMASK(11, 0) in __be16 refers to the second byte and the lower
> 4 bits of the first byte.  In __le16 it would refer to the first byte
> and the lower 4 bits of the second byte, etc.
> 
> I am not 100% sure, but maybe we actually need them? 

By looking at the changes you did with regards to bitfields,
it sounds that you didn't quite get how BE/LE works.

Basically, if the CPU needs to store a value (like 0x8001) on some 
place, it will store two values: 0x80 and 0x01. Depending on the
endiannes, either 0x80 or 0x01 will be stored first. See:

	https://en.wikipedia.org/wiki/Endianness

In any case, when you do something like:

	mask = GENMASK(11, 0);
	ret = be16_to_cpu(s->bitfield) & mask;

The be16_to_cpu() will ensure that the bits will be at the
position expected by the CPU endiannes. So, no need to check
for __BIG_ENDIAN or __LITTLE_ENDIAN when be*_to_cpu() macros 
are used.

Please also notice that, when there's just one byte to be
stored (e. g. 8 bits), the endiannes won't matter, as the bits 
will still be stored at the same way. that's why there's no
be8_to_cpu() or cpu_to_be8() macros.

Thanks,
Mauro