From: Alyssa Rosenzweig <alyssa@rosenzweig.io>
To: Petr Mladek <pmladek@suse.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Sven Peter <sven@svenpeter.dev>,
Thomas Zimmermann <tzimmermann@suse.de>,
Aun-Ali Zaidi <admin@kodeit.net>,
Maxime Ripard <mripard@kernel.org>,
airlied@redhat.com, Simona Vetter <simona@ffwll.ch>,
Steven Rostedt <rostedt@goodmis.org>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>,
apw@canonical.com, joe@perches.com, dwaipayanray1@gmail.com,
lukas.bulwahn@gmail.com, Kees Cook <kees@kernel.org>,
tamird@gmail.com, Aditya Garg <gargaditya08@live.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org,
Hector Martin <marcan@marcan.st>,
Asahi Linux Mailing List <asahi@lists.linux.dev>,
Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH] vsprintf: Use %p4chR instead of %p4cn for reading data in reversed host ordering
Date: Mon, 28 Apr 2025 13:00:34 -0400 [thread overview]
Message-ID: <aA-0MuLxVTueDAhm@blossom> (raw)
In-Reply-To: <20250428123132.578771-1-pmladek@suse.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Since the other patches went thru drm-misc-next, I guess this should
too?
Le Mon , Apr 28, 2025 at 02:31:32PM +0200, Petr Mladek a écrit :
> The generic FourCC format always prints the data using the big endian
> order. It is generic because it allows to read the data using a custom
> ordering.
>
> The current code uses "n" for reading data in the reverse host ordering.
> It makes the 4 variants [hnbl] consistent with the generic printing
> of IPv4 addresses.
>
> Unfortunately, it creates confusion on big endian systems. For example,
> it shows the data &(u32)0x67503030 as
>
> %p4cn 00Pg (0x30305067)
>
> But people expect that the ordering stays the same. The network ordering
> is a big-endian ordering.
>
> The problem is that the semantic is not the same. The modifiers affect
> the output ordering of IPv4 addresses while they affect the reading order
> in case of FourCC code.
>
> Avoid the confusion by replacing the "n" modifier with "hR", aka
> reverse host ordering. It is inspired by the existing %p[mM]R printf
> format.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Closes: https://lore.kernel.org/r/CAMuHMdV9tX=TG7E_CrSF=2PY206tXf+_yYRuacG48EWEtJLo-Q@mail.gmail.com
> Signed-off-by: Petr Mladek <pmladek@suse.com>
> ---
> Hi,
>
> I am sending this as a proper patch. It would be nice to queue it
> together with the other patches adding the generic printf modifiers.
>
> Best Regards,
> Petr
> ---
> Documentation/core-api/printk-formats.rst | 10 +++++-----
> lib/tests/printf_kunit.c | 4 ++--
> lib/vsprintf.c | 11 ++++++++---
> 3 files changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
> index 125fd0397510..f531873bb3c9 100644
> --- a/Documentation/core-api/printk-formats.rst
> +++ b/Documentation/core-api/printk-formats.rst
> @@ -652,7 +652,7 @@ Generic FourCC code
> -------------------
>
> ::
> - %p4c[hnlb] gP00 (0x67503030)
> + %p4c[h[R]lb] gP00 (0x67503030)
>
> Print a generic FourCC code, as both ASCII characters and its numerical
> value as hexadecimal.
> @@ -660,23 +660,23 @@ value as hexadecimal.
> The generic FourCC code is always printed in the big-endian format,
> the most significant byte first. This is the opposite of V4L/DRM FourCCs.
>
> -The additional ``h``, ``n``, ``l``, and ``b`` specifiers define what
> +The additional ``h``, ``hR``, ``l``, and ``b`` specifiers define what
> endianness is used to load the stored bytes. The data might be interpreted
> -using the host byte order, network byte order, little-endian, or big-endian.
> +using the host, reversed host byte order, little-endian, or big-endian.
>
> Passed by reference.
>
> Examples for a little-endian machine, given &(u32)0x67503030::
>
> %p4ch gP00 (0x67503030)
> - %p4cn 00Pg (0x30305067)
> + %p4chR 00Pg (0x30305067)
> %p4cl gP00 (0x67503030)
> %p4cb 00Pg (0x30305067)
>
> Examples for a big-endian machine, given &(u32)0x67503030::
>
> %p4ch gP00 (0x67503030)
> - %p4cn 00Pg (0x30305067)
> + %p4chR 00Pg (0x30305067)
> %p4cl 00Pg (0x30305067)
> %p4cb gP00 (0x67503030)
>
> diff --git a/lib/tests/printf_kunit.c b/lib/tests/printf_kunit.c
> index b1fa0dcea52f..bc54cca2d7a6 100644
> --- a/lib/tests/printf_kunit.c
> +++ b/lib/tests/printf_kunit.c
> @@ -726,7 +726,7 @@ static void fourcc_pointer(struct kunit *kunittest)
> static const struct fourcc_struct try_ch[] = {
> { 0x41424344, "ABCD (0x41424344)", },
> };
> - static const struct fourcc_struct try_cn[] = {
> + static const struct fourcc_struct try_chR[] = {
> { 0x41424344, "DCBA (0x44434241)", },
> };
> static const struct fourcc_struct try_cl[] = {
> @@ -738,7 +738,7 @@ static void fourcc_pointer(struct kunit *kunittest)
>
> fourcc_pointer_test(kunittest, try_cc, ARRAY_SIZE(try_cc), "%p4cc");
> fourcc_pointer_test(kunittest, try_ch, ARRAY_SIZE(try_ch), "%p4ch");
> - fourcc_pointer_test(kunittest, try_cn, ARRAY_SIZE(try_cn), "%p4cn");
> + fourcc_pointer_test(kunittest, try_chR, ARRAY_SIZE(try_chR), "%p4chR");
> fourcc_pointer_test(kunittest, try_cl, ARRAY_SIZE(try_cl), "%p4cl");
> fourcc_pointer_test(kunittest, try_cb, ARRAY_SIZE(try_cb), "%p4cb");
> }
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 2c5de4216415..34587b2dbdb1 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1804,9 +1804,8 @@ char *fourcc_string(char *buf, char *end, const u32 *fourcc,
> orig = get_unaligned(fourcc);
> switch (fmt[2]) {
> case 'h':
> - break;
> - case 'n':
> - orig = swab32(orig);
> + if (fmt[3] == 'R')
> + orig = swab32(orig);
> break;
> case 'l':
> orig = (__force u32)cpu_to_le32(orig);
> @@ -2396,6 +2395,12 @@ early_param("no_hash_pointers", no_hash_pointers_enable);
> * read the documentation (path below) first.
> * - 'NF' For a netdev_features_t
> * - '4cc' V4L2 or DRM FourCC code, with endianness and raw numerical value.
> + * - '4c[h[R]lb]' For generic FourCC code with raw numerical value. Both are
> + * displayed in the big-endian format. This is the opposite of V4L2 or
> + * DRM FourCCs.
> + * The additional specifiers define what endianness is used to load
> + * the stored bytes. The data might be interpreted using the host,
> + * reversed host byte order, little-endian, or big-endian.
> * - 'h[CDN]' For a variable-length buffer, it prints it as a hex string with
> * a certain separator (' ' by default):
> * C colon
> --
> 2.49.0
>
next prev parent reply other threads:[~2025-04-28 17:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-28 12:31 [PATCH] vsprintf: Use %p4chR instead of %p4cn for reading data in reversed host ordering Petr Mladek
2025-04-28 13:02 ` Aditya Garg
2025-04-28 13:33 ` Geert Uytterhoeven
2025-04-28 17:00 ` Alyssa Rosenzweig [this message]
2025-04-28 17:08 ` Aditya Garg
2025-04-29 11:39 ` Petr Mladek
2025-04-29 13:27 ` Alyssa Rosenzweig
2025-04-29 13:53 ` Aditya Garg
2025-04-29 13:53 ` Alyssa Rosenzweig
2025-04-29 16:07 ` [PATCH] checkpatch: remove %p4cn Aditya Garg
2025-04-29 17:35 ` Joe Perches
2025-04-29 17:48 ` Aditya Garg
2025-04-30 13:49 ` [PATCH v3] " Aditya Garg
2025-05-02 13:30 ` Petr Mladek
2025-05-06 15:40 ` Alyssa Rosenzweig
2025-04-29 17:50 ` [PATCH v2] checkpatch: remove %p4cn and add check for %p4chR Aditya Garg
2025-04-30 12:47 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aA-0MuLxVTueDAhm@blossom \
--to=alyssa@rosenzweig.io \
--cc=admin@kodeit.net \
--cc=airlied@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=apw@canonical.com \
--cc=asahi@lists.linux.dev \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=dwaipayanray1@gmail.com \
--cc=gargaditya08@live.com \
--cc=geert@linux-m68k.org \
--cc=joe@perches.com \
--cc=kees@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=lukas.bulwahn@gmail.com \
--cc=marcan@marcan.st \
--cc=mripard@kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=simona@ffwll.ch \
--cc=sven@svenpeter.dev \
--cc=tamird@gmail.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).