linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 

  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).