From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1732DC433FE for ; Tue, 22 Nov 2022 14:50:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=BCcEus9JX2wuszk/j+0NhZ34AOAeqGg/sEXsX+8bvqU=; b=O9hchYgfOuU7M0 /kKPLypD/E5wReRMNwClj7HKBOHYSaKBE/tppsF+snHEVAvKfqsLw75iEFQ1BgyC0deORdDS3FKuG jd9oBZ5Q7MdGBZyVfDT8snrHnNw2kv2jIfhVF+nfClxbZdy7a4/UldU63FJobGtLci/5I8TPGo0C7 Kf85jcHo2c9Ui0ZTOZB6XPC2/nQ5ivL1v/0x7fS+Bjn1pdQffJe6qgO+6zDk1sc0ugLSGEtwWoClY rGP0AxBZDgyAknvCgraT7Bi5vBDWFoufBXYE/Ws/VbhrXUtMvRWVmIHZJcfj1kVzypqXS8rEP42qf 1Gw8u8ycY3VUd5FZwWmA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oxUas-00A58R-Fs; Tue, 22 Nov 2022 14:49:50 +0000 Received: from smtp-out1.suse.de ([2001:67c:2178:6::1c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oxUap-00A56S-9D for linux-arm-kernel@lists.infradead.org; Tue, 22 Nov 2022 14:49:48 +0000 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 7D40A21BE4; Tue, 22 Nov 2022 14:49:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1669128585; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=j9AuGuLYTdJN+k3uXzcchb8mQnKbhGw+TLUgV+tqJrU=; b=MEQS0+y9gcppN8qOpnYaqU7svgu2b3vPgGRXci1z6NL61cL4i98zh4U8k84lKJCd/gXFRo Yn4RT0BvfG/CQMNRq0mzn65SnyEDIOv0RYOvo1nC+Uhzpjf3f12g+C8FW74uxEvRhF8K98 wR702WHORWcWBEPCtw7JhNzXykfXhKY= Received: from suse.cz (unknown [10.100.201.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 6EEC42C142; Tue, 22 Nov 2022 14:49:44 +0000 (UTC) Date: Tue, 22 Nov 2022 15:49:40 +0100 From: Petr Mladek To: Russell King Cc: Linus Walleij , Bartosz Golaszewski , Rob Herring , Lee Jones , Alyssa Rosenzweig , Andy Shevchenko , asahi@lists.linux.dev, devicetree@vger.kernel.org, Hector Martin , Jonathan Corbet , Krzysztof Kozlowski , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-gpio@vger.kernel.org, Rasmus Villemoes , Sergey Senozhatsky , Steven Rostedt , Sven Peter Subject: Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221122_064947_491486_630729FC X-CRM114-Status: GOOD ( 25.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue 2022-11-08 16:33:22, Russell King wrote: > From: Hector Martin > > %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 > Signed-off-by: Russell King (Oracle) > --- > Documentation/core-api/printk-formats.rst | 32 +++++++++++++++++++ > lib/test_printf.c | 39 +++++++++++++++++++---- > lib/vsprintf.c | 35 ++++++++++++++++---- > 3 files changed, 93 insertions(+), 13 deletions(-) > > diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst > index dbe1aacc79d0..92a488884cf8 100644 > --- a/Documentation/core-api/printk-formats.rst > +++ b/Documentation/core-api/printk-formats.rst > @@ -625,6 +625,38 @@ Passed by reference. > %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 though a bit more about the semantic and got a bit confused. It might be because I am not familiar with FourCC. Anyway, the description in the commit message provided some more clues. The following documentation looks be more clear to me: Generic FourCC code ------------------- :: %p4c[hrbl] gP00 (0x67503030) 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 value as 32-bit integer. The value might be stored as host-endian, reverse-host-endian, big-endian, or little endian. Examples for a little-endian machine, host native load &(u32)0x67503030:: %p4ch gP00 (0x67503030) %p4cr 00Pg (0x30305067) %p4cb 00Pg (0x30305067) %p4cl gP00 (0x67503030) Examples for a big-endian machine, host native load &(u32)0x67503030:: %p4ch gP00 (0x67503030) %p4cr 00Pg (0x30305067) %p4cb gP00 (0x67503030) %p4cl 00Pg (0x30305067) Best Regards, Petr _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel