Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3044459ybb; Mon, 6 Apr 2020 00:30:07 -0700 (PDT) X-Google-Smtp-Source: APiQypIMjMjkC0LTxUNPuY6P6exspAbLbLjwb9YLwUYt/inOmd2tpfDdrQUSq2v+YYd6IbsFUQAq X-Received: by 2002:a05:6808:1c1:: with SMTP id x1mr11133075oic.55.1586158207706; Mon, 06 Apr 2020 00:30:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586158207; cv=none; d=google.com; s=arc-20160816; b=C6Qw5RkBL8o/4U7iW3dXrtEnSRpebLlpSzBnhc/5aJjgmgZJh3tm/jxzGfZqz4qDdg SlSbkf8PWi7tTji5dAMBXI0S/uz+spj61MYlEnknkvMjmnGhH80J8xDv2q5IVuaPSwwz jrLUpsZ6yx9vZeja9xac6E1lCRx66r+MP9S80czZP8QrpFsc3q0NGbu1Bb9iB0fOrjIW bzE2Gv50P9xgoQ1iLK4Jj5eVW1bSGMSR3J0+tQLXbY+gIxaiIVBtablO9i9Er/Ar251u apwOt+Aj3cBghPuMUvMoiT0Fmw/2Yc+S3YRxQdhEpcwoj3e5gHWDIl6g7VvystjitZ7y W5vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=9ATFS7p4zSi1iZWOuIu76Frl8QB+yLfTZU6N3oa3Ip0=; b=THG+dXajgJ9yOEGAzFcDTsDSPMfPEC0Eg5eB1v1Q8n9L0hrAXMRLDwMBOg62YwucBW HR3CoUuUJW+TzzFe6W9dDM/0T0wNN2NhKZXYyGP6+/Fkqjt/6G6Il/L+iLUWoQvEQGPv aFVtY0520rYGmgGU9s53Fwd89wHd4etcRAU+IqEbA+aeCNBdtNV6tbkgrMfs738HdcEA YMo2zHYQ3K088tDdUHvtyjmVYbykAHUoAAItwjH4eWCEnrw+LfbFq4j+pHWzsM8e9pok bx2NWvOsPqosFx6Dae6oJYQzFLnxZlUgLHN0i0OvAaB97DBdkK4MexQwHc9b+piSv72g u6qA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m22si7902962otn.81.2020.04.06.00.29.41; Mon, 06 Apr 2020 00:30:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726633AbgDFH3G (ORCPT + 99 others); Mon, 6 Apr 2020 03:29:06 -0400 Received: from mga17.intel.com ([192.55.52.151]:63537 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726509AbgDFH3G (ORCPT ); Mon, 6 Apr 2020 03:29:06 -0400 IronPort-SDR: jahqi3kONJ0JXN2xrJezQGIzxgHs+j1Uwl1T6wHAl0JNgpQxNsxlO+zGJyzaj+pfNDTZ6NrEWs JfhSu2D43XRg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2020 00:29:05 -0700 IronPort-SDR: PTRRg3j9W+zcLsusMj2JOJphF/aWn1Jpkx1T57J4M5dh9NJ+iQqcvF/kqw1HGOEmZ9hLAaBu0q L40tKvY5ZtdQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,350,1580803200"; d="scan'208";a="450740106" Received: from unknown (HELO kekkonen.fi.intel.com) ([10.252.48.155]) by fmsmga005.fm.intel.com with ESMTP; 06 Apr 2020 00:29:02 -0700 Received: by kekkonen.fi.intel.com (Postfix, from userid 1000) id 5A0A621D18; Mon, 6 Apr 2020 10:28:58 +0300 (EEST) Date: Mon, 6 Apr 2020 10:28:58 +0300 From: Sakari Ailus To: Rasmus Villemoes Cc: Petr Mladek , Andy Shevchenko , linux-media@vger.kernel.org, Dave Stevenson , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, hverkuil@xs4all.nl, laurent.pinchart@ideasonboard.com, mchehab@kernel.org, Sergey Senozhatsky , Steven Rostedt , Joe Perches , Jani Nikula Subject: Re: [PATCH v2 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs Message-ID: <20200406072857.GD5835@kekkonen.localdomain> References: <20200403091156.7814-1-sakari.ailus@linux.intel.com> <1105bfe5-88f1-040e-db40-54d7761747d5@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1105bfe5-88f1-040e-db40-54d7761747d5@rasmusvillemoes.dk> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rasmus, Thanks for the comments. On Fri, Apr 03, 2020 at 02:10:53PM +0200, Rasmus Villemoes wrote: > On 03/04/2020 11.11, Sakari Ailus wrote: > > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM > > pixel formats denoted by 4ccs. The 4cc encoding is the same for both so > > the same implementation can be used. > > This seems quite niche to me, I'm not sure that belongs in vsprintf.c. > What's wrong with having a > > char *fourcc_string(char *buf, u32 x) > > that formats x into buf and returns buf, so it can be used in a > > char buf[8]; > pr_debug("bla: %s\n", fourcc_string(buf, x)) I guess that could be one option. But changing the implementation could require changing the size of all those buffers. We had this approach, too: Let's see if we'll get more comments on this. > > Or, for that matter, since it's for debugging, why not just print x with > 0x%08x? People generally prefer readable output that they can understand. The codes are currently being printed in characters, and that's how they are defined in kernel headers, too. Therefore the hexadecimal values are of secondary importance (although they could be printed too, as apparently a similar function in DRM does). > > At the very least, the "case '4'" in pointer() should be guarded by > appropriate CONFIG_*. > > Good that Documentation/ gets updated, but test_printf needs updating as > well. Agreed. > > > > Suggested-by: Mauro Carvalho Chehab > > Signed-off-by: Sakari Ailus > > --- > > since v1: > > > > - Improve documentation (add -BE suffix, refer to "FourCC". > > > > - Use '%p4cc' conversion specifier instead of '%ppf'. > > Cute. Remember to update the commit log (which still says %ppf). I will. > > > - Fix 31st bit handling in printing FourCC codes. > > > > - Use string() correctly, to allow e.g. proper field width handling. > > > > - Remove loop, use put_unaligned_le32() instead. > > > > Documentation/core-api/printk-formats.rst | 12 +++++++++++ > > lib/vsprintf.c | 25 +++++++++++++++++++++++ > > 2 files changed, 37 insertions(+) > > > > diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst > > index 8ebe46b1af39..550568520ab6 100644 > > --- a/Documentation/core-api/printk-formats.rst > > +++ b/Documentation/core-api/printk-formats.rst > > @@ -545,6 +545,18 @@ For printing netdev_features_t. > > > > Passed by reference. > > > > +V4L2 and DRM FourCC code (pixel format) > > +--------------------------------------- > > + > > +:: > > + > > + %p4cc > > + > > +Print a FourCC code used by V4L2 or DRM. The "-BE" suffix is added on big endian > > +formats. > > + > > +Passed by reference. > > Maybe it's obvious to anyone in that business, but perhaps make it more > clear the 4cc is stored in a u32 (and not, e.g., a __le32 or some other > integer), that obviously matters when the code treats the pointer as a u32*. The established practice is to use u32 (as this is really no hardware involved) but I guess it'd be good to document that here, too. > > + > > + put_unaligned_le32(*fourcc & ~BIT(31), s); > > + > > + if (*fourcc & BIT(31)) > > + strscpy(s + sizeof(*fourcc), FOURCC_STRING_BE, > > + sizeof(FOURCC_STRING_BE)); > > put_unaligned_le32(0x0045422d, s + 4) probably generates smaller code, > and is more in line with building the first part of the string with > put_unaligned_le32(). Uh. The fourcc code is made of printable characters (apart from the 31st bit) so it can be printed, but I wouldn't use that here. "-BE" is just a string and not related to 4ccs. -- Regards, Sakari Ailus