[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z7xQikQeHLOHb1G8@smile.fi.intel.com>
Date: Mon, 24 Feb 2025 12:57:14 +0200
From: "andriy.shevchenko@...ux.intel.com" <andriy.shevchenko@...ux.intel.com>
To: Aditya Garg <gargaditya08@...e.com>
Cc: "pmladek@...e.com" <pmladek@...e.com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"linux@...musvillemoes.dk" <linux@...musvillemoes.dk>,
"senozhatsky@...omium.org" <senozhatsky@...omium.org>,
"corbet@....net" <corbet@....net>,
"maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
"mripard@...nel.org" <mripard@...nel.org>,
"tzimmermann@...e.de" <tzimmermann@...e.de>,
"airlied@...il.com" <airlied@...il.com>,
"simona@...ll.ch" <simona@...ll.ch>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"apw@...onical.com" <apw@...onical.com>,
"joe@...ches.com" <joe@...ches.com>,
"dwaipayanray1@...il.com" <dwaipayanray1@...il.com>,
"lukas.bulwahn@...il.com" <lukas.bulwahn@...il.com>,
"sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
"christian.koenig@....com" <christian.koenig@....com>,
"kekrby@...il.com" <kekrby@...il.com>,
"admin@...eit.net" <admin@...eit.net>,
Orlando Chamberlain <orlandoch.dev@...il.com>,
"evepolonium@...il.com" <evepolonium@...il.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
Hector Martin <marcan@...can.st>,
"linux@...linux.org.uk" <linux@...linux.org.uk>,
"asahi@...ts.linux.dev" <asahi@...ts.linux.dev>,
Sven Peter <sven@...npeter.dev>, Janne Grunau <j@...nau.net>
Subject: Re: [PATCH v2 2/3] lib/vsprintf: Add support for generic FOURCCs by
extending %p4cc
On Sun, Feb 23, 2025 at 03:16:28PM +0000, Aditya Garg wrote:
> > Looking at the header files, it looks like doing cpu_to_le32 on that variable and doing le32_to_cpu will actually reverse the order twice, on big endian systems, thus technically all way would not swap the order at all.
> >
> > I'm not really sure how to manage the sparse warnings here.
>
> Not sure whether the maintainers would like it, but we can do something like this:
This is not what we want, I believe. And this looks like a reinventing a wheel
of cpu_to_*() and *_to_cpu() or similar macros.
> case 'l’:
> #ifdef __LITTLE_ENDIAN
> val = orig;
> #else
> orig = swab32(orig);
> val = orig;
> #endif
> break;
>
> case 'b’:
> #ifdef __LITTLE_ENDIAN
> orig = swab32(orig);
> val = orig;
> #else
> val = orig;
> #endif
> break;
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists