> On 28 Feb 2025, at 9:29 PM, Petr Mladek <pmladek@xxxxxxxx> wrote: > > On Thu 2025-02-27 06:30:48, Aditya Garg wrote: >> From: Hector Martin <marcan@xxxxxxxxx> >> >> %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but >> it's useful to be able to print generic 4-character codes formatted as >> an integer. Extend it to add format specifiers for printing generic >> 32-bit FOURCCs with various endian semantics: >> >> %p4ch Host-endian >> %p4cl Little-endian >> %p4cb Big-endian >> %p4cr Reverse-endian >> >> The endianness determines how bytes are interpreted as a u32, and the >> FOURCC is then always printed MSByte-first (this is the opposite of >> V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would >> allow printing LSByte-first FOURCCs stored in host endian order >> (other than the hex form being in character order, not the integer >> value). >> >> Signed-off-by: Hector Martin <marcan@xxxxxxxxx> >> Signed-off-by: Aditya Garg <gargaditya08@xxxxxxxx> >> > >> --- a/Documentation/core-api/printk-formats.rst >> +++ b/Documentation/core-api/printk-formats.rst >> @@ -648,6 +648,38 @@ Examples:: >> %p4cc Y10 little-endian (0x20303159) >> %p4cc NV12 big-endian (0xb231564e) >> >> +Generic FourCC code >> +------------------- >> + >> +:: >> + %p4c[hrbl] gP00 (0x67503030) >> + >> +Print a generic FourCC code, as both ASCII characters and its numerical >> +value as hexadecimal. >> + >> +The additional ``h``, ``r``, ``b``, and ``l`` specifiers are used to specify >> +host, reversed, big or little endian order data respectively. Host endian >> +order means the data is interpreted as a 32-bit integer and the most >> +significant byte is printed first; that is, the character code as printed >> +matches the byte order stored in memory on big-endian systems, and is reversed >> +on little-endian systems. > > I am a bit confused by the description like I was in the past, see > https://lore.kernel.org/r/Y3zhhLoqAOaZ7rMz@alley ;-) > > I wonder if the following sounds better: > > <proposa> > Print a generic FourCC code, as both ASCII characters and its numerical > value as hexadecimal. > > The generic FourCC code is always printed in the the big-endian format, > the most significant byte first. This is the opposite of V4L/DRM > FOURCCs. > > The additional ``h``, ``r``, ``b``, and ``l`` specifiers define what > endianes is used to load the stored bytes. The data might be interpreted > using the host-endian, reverse-host-endian, big-endian, or little endian. > </proposal> Definitely much clear. > >> +Passed by reference. >> + >> +Examples for a little-endian machine, given &(u32)0x67503030:: >> + >> + %p4ch gP00 (0x67503030) >> + %p4cr 00Pg (0x30305067) >> + %p4cb 00Pg (0x30305067) >> + %p4cl gP00 (0x67503030) >> + >> +Examples for a big-endian machine, given &(u32)0x67503030:: >> + >> + %p4ch gP00 (0x67503030) >> + %p4cr 00Pg (0x30305067) >> + %p4cb gP00 (0x67503030) >> + %p4cl 00Pg (0x30305067) >> + >> Rust > > The patch has been malformed. I guess that your mail client > removed spaces at the beginning of some lines. I dunno what wrong, anyways I'll send a v5 so will make sure things go right. > >> ---- >> >> diff --git a/lib/test_printf.c b/lib/test_printf.c >> index 59dbe4f9a..056929c06 100644 >> --- a/lib/test_printf.c >> +++ b/lib/test_printf.c >> @@ -776,21 +776,46 @@ static void __init fwnode_pointer(void) >> software_node_unregister_node_group(group); >> } >> >> +struct fourcc_struct { >> + u32 code; >> + const char *str; >> +}; >> + >> +static void __init fourcc_pointer_test(const struct fourcc_struct *fc, size_t n, >> + const char *fmt) >> +{ >> + size_t i; >> + >> + for (i = 0; i < n; i++) >> + test(fc[i].str, fmt, &fc[i].code); >> +} >> + >> static void __init fourcc_pointer(void) >> { >> - struct { >> - u32 code; >> - char *str; >> - } const try[] = { >> + static const struct fourcc_struct try_cc[] = { >> { 0x3231564e, "NV12 little-endian (0x3231564e)", }, >> { 0xb231564e, "NV12 big-endian (0xb231564e)", }, >> { 0x10111213, ".... little-endian (0x10111213)", }, >> { 0x20303159, "Y10 little-endian (0x20303159)", }, >> }; >> - unsigned int i; >> + static const struct fourcc_struct try_ch = { >> + 0x41424344, "ABCD (0x41424344)", >> + }; >> + static const struct fourcc_struct try_cr = { >> + 0x41424344, "DCBA (0x44434241)", >> + }; >> + static const struct fourcc_struct try_cl = { >> + le32_to_cpu(0x41424344), "ABCD (0x41424344)", >> + }; >> + static const struct fourcc_struct try_cb = { >> + be32_to_cpu(0x41424344), "ABCD (0x41424344)", >> + }; >> >> - for (i = 0; i < ARRAY_SIZE(try); i++) >> - test(try[i].str, "%p4cc", &try[i].code); >> + fourcc_pointer_test(try_cc, ARRAY_SIZE(try_cc), "%p4cc"); >> + fourcc_pointer_test(&try_ch, 1, "%p4ch"); >> + fourcc_pointer_test(&try_cr, 1, "%p4cr"); >> + fourcc_pointer_test(&try_cl, 1, "%p4cl"); >> + fourcc_pointer_test(&try_cb, 1, "%p4cb"); > > Nit: I would use ARRAY_SIZE() instead of the hardcoded 1 in all cases. > But it might be a matter of taste. I'll make that change > >> } >> > > Otherwise, it looks good to me. > > Best Regards, > Petr
