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> > +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. > ---- > > 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. > } > Otherwise, it looks good to me. Best Regards, Petr
