Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 6 Apr 2020 10:37:58 +0300
From:   Pekka Paalanen <ppaalanen@gmail.com>
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     Hans Verkuil <hverkuil@xs4all.nl>, Petr Mladek <pmladek@suse.com>,
        Dave Stevenson <dave.stevenson@raspberrypi.com>,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        laurent.pinchart@ideasonboard.com,
        Sakari Ailus <sakari.ailus@linux.intel.com>,
        mchehab@kernel.org, linux-media@vger.kernel.org
Subject: Re: [PATCH 1/1] lib/vsprintf: Add support for printing V4L2 and DRM
 fourccs
Message-ID: <20200406103758.1be49f78@eldfell.localdomain>
In-Reply-To: <20200401151332.GU1922688@smile.fi.intel.com>
References: <20200401140522.966-1-sakari.ailus@linux.intel.com>
        <080ddddf-717e-61dc-8522-fbdbe52da94a@xs4all.nl>
        <20200401151332.GU1922688@smile.fi.intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/DiWGmGA9BuE3BQZbAQv63qz"; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--Sig_/DiWGmGA9BuE3BQZbAQv63qz
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 1 Apr 2020 18:13:32 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Wed, Apr 01, 2020 at 04:13:51PM +0200, Hans Verkuil wrote:
> > On 4/1/20 4:05 PM, Sakari Ailus wrote: =20
> > > Add a printk modifier %ppf (for pixel format) for printing V4L2 and D=
RM
> > > pixel formats denoted by 4ccs. The 4cc encoding is the same for both =
so
> > > the same implementation can be used. =20
>=20
> %p4cc ?
>=20

> Another possibility
>=20
> 	u8 ch[8];
>=20
> 	if (*fourcc & BIT(31)) {
> 		put_unaligned_be32(tmp, &ch[0]);
> 		strcpy(&ch[4], "-BE");
> 	} else {
> 		put_unaligned_le32(tmp, &ch[0]);
> 		strcpy(&ch[4], "-LE");
> 	}
> 	return string(buf, end, &ch[0], spec);
>=20

Hi,

mind, if I guess right what that code does, I think this would confuse
the fourcc code endianness and the pixel data endianness. I think fourcc
codes are always crafted machine-endian, regardless of how the pixel
data is. At least, that is what drm_fourcc.h seems to be doing with
fourcc_code(). That has nothing to do with DRM_FORMAT_BIG_ENDIAN which
refers to the pixel data.


Thanks,
pq

--Sig_/DiWGmGA9BuE3BQZbAQv63qz
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAl6K3FcACgkQI1/ltBGq
qqcp8A/+MFQ/BvUrgpGrroUNyMx5PPIdWVMcfUFCr9qFTvHtgEGi27qifT7TYdgK
91dOR+rQKOE4Dhx7/3NPtr+qq8LSI2/zV199rrbCFhiCsqRLQLQwNDUF9oPqRXDh
FRQXaniCSLU6ROYj5xxVA0SYYB5SxrP7k5H6fHnzodu83HQg/yWmUrHoWLZscdap
Vj09jcfbCzICbwet9l+1fXfR1BNQPp9FQQxfclCQWDyeLDhMmYUcXT+7bayUlzLs
lAeO6gIZBjafsipFnf7sb6viVRVa7lmzhnzLuqoSaCdWoYfmyBCrP+sUYDZbkv7K
mEKeulPbDldxaWl11h6yJvVZusRoX4XM5xLl1JzVG5yTmqsU/oSjt11guMG5Z/0t
/Ipfu1TK4F7/dD2A03+DX2PnRgFtK0L9xVSmAhxj3Z1qwvo9Myvjqkbu+cHu0q1N
TUYT8ILBVmhgYKk3BqM1YYQo4OMmOglzDxnxWlnSPXxdEo1zaH8p3VaCxBPJQob4
XIurW+oIJwKHepmOt34RLbOaIAr4ypfaw4vtUmOLLSiTO8RkeFpeWQpiMqA4gRLq
bJuD2UJzykFx1uwsKwLmE18eT32q14R0JSkQP8WXj9BioAcOE6gct+RltRngK+gL
2G94ro4TnIBTJihF1srsE2EqE/m/wd6wdNM3GaYAAmJSOkj0Q5I=
=8lW6
-----END PGP SIGNATURE-----

--Sig_/DiWGmGA9BuE3BQZbAQv63qz--