Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp10159pxb; Mon, 8 Feb 2021 13:38:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJwmiB6mV8Lz25n/roRNgp3uMFSEwiHlUtQ3s/Ce5lzvOmEvnS+1IPpFzRnhAbbMTpL1nZ8x X-Received: by 2002:a17:906:3484:: with SMTP id g4mr18754268ejb.38.1612820331115; Mon, 08 Feb 2021 13:38:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612820331; cv=none; d=google.com; s=arc-20160816; b=aM347Ivjrwtmg7QjarXl8zd/nBVUgFsoT1UFLLj9yCGeaHJpIR+M+W4ygCiO+jsAjz VdbCUmIRddwHZjNE674ooxJr4fzRLza3VfPBCjQk6NbiSk81IBkqMyps4jRp+JECXA2F PUiiscomGm39vxl+M06ZeDfBzKQphFecZxqcUODQBTFT7pUpX5gqLyMgMobvoo3WvdrV RLph7YTXeEX9ZNYXeY41GKQ1WDDPEMjOH0jnP+Z3emgfi+dzCDLkGPmZ3HvC56B9O6Zq QB+WbooDwoN9H0+UVeuHFt8uAFYEG6+Pvx4zlBJ5Vw62WJo3ZTVAMDic45H5ywju3EIX ewjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=obDV9I3X9Q9ETr/d7/JJJtO01x++Iqx0cP/5PJD8kOk=; b=YDEV4fqf2jfs0BnKbVg7iVt0E7FerugMZNIyuSGgpLoOcO0s1DUz6JaCCxHnE7X+jl pl737CoWcCZ/F8Yl9CaNeyNHOawKt9yotJQPhctHuCSc6aV3jLUSBlW0bhmqQUpxN5ue 0N/zTSmNAcEjeypU23dFbFqPqmbKheDuMFRF8CqznIWT5+DSJhnXQBxM3afslqkn7KGJ V963D/Z/NTwKoDhffPvKYGJmj7BK+GtgEqAuUboPZuGvw1FTwYNQNKvmIBq8R2kaMZaF 8O0CMib81hDEAzzcY7GDl4RvYdjZSrvvejtgdkK7iVKAqv1pQvrUZUS/3UX3CdFtZ6VB 5mXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=krXYUzcp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w17si12194401ejy.52.2021.02.08.13.38.27; Mon, 08 Feb 2021 13:38:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=krXYUzcp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236704AbhBHVez (ORCPT + 99 others); Mon, 8 Feb 2021 16:34:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38838 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230402AbhBHUon (ORCPT ); Mon, 8 Feb 2021 15:44:43 -0500 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 43754C06178C; Mon, 8 Feb 2021 12:43:47 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id x136so3904027pfc.2; Mon, 08 Feb 2021 12:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=obDV9I3X9Q9ETr/d7/JJJtO01x++Iqx0cP/5PJD8kOk=; b=krXYUzcpYuvD1i4Y1QB/c/ebFNqSUJQasnj0UlR4ZOJhwuTXeBM4WQqNK1QfLdmYdl sanEroE1KhDL8GhqPd5nsfpXjukIJgbZyZ18x0+xK3xTKwOlziFm04okzHYWrcpQ5Mfj iQU7Ke85+pcGCCZSAeZ/5cfchfsXB0lq4/T1iO/ayC9qoGkHn4e29QPdhHYFweU3gXB6 MrDyZ6A+lPDNXs/sKni/w8Z/xtOsbB+YiRdKxgOH4vGvNLq4joNr+xuNsj4ac/UFijfa mqafLQDRU7gqNmKtFFGCBk6dArQgWaMNN5FXS0ufyMgs+IvsPEG8dPpBBozPNF10I0Rn CEEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=obDV9I3X9Q9ETr/d7/JJJtO01x++Iqx0cP/5PJD8kOk=; b=Ywx1S61xXW5h4BZGrS/S06FBTWAySupeXmJ91MyGJp1hY7An7a5ELBuralMNqekacP GxTQCk8pyWZ09F0//dyv9Dy9EKDhG34cJ7j6sY034WtSIUhx6WlNhLZ0ys9Qion56YMo DcnSYxFGEG19MFv6YXWLwCzt/2QrWCK1pnG2/Idzu2Xs1RvnSrcz1ae3JarWXh500gaI 9gAMtSov8nEAaBZoCU3m5Tx50weEaqXKsKUB/dvPdJm6K2QaplUFph0ivxdeWuBeTosL /HAMEkLd+dva0zL6qoyQ7HIm91FXb56Mxyw0FGchzQuefu1myaIZdmZ1bzdD1WcX53Sj bTPg== X-Gm-Message-State: AOAM532Iz2o1RPKHhQHWOoxK6CZ1PHCGz/fVzfLuxQc1CLdIGsMe3ucl dRxej3qsModVSLsBavYowhST1fQd7t8n5y3mqAc= X-Received: by 2002:a63:3d0:: with SMTP id 199mr15739479pgd.4.1612817026721; Mon, 08 Feb 2021 12:43:46 -0800 (PST) MIME-Version: 1.0 References: <20210208200903.28084-1-sakari.ailus@linux.intel.com> <20210208200903.28084-2-sakari.ailus@linux.intel.com> In-Reply-To: <20210208200903.28084-2-sakari.ailus@linux.intel.com> From: Andy Shevchenko Date: Mon, 8 Feb 2021 22:43:30 +0200 Message-ID: Subject: Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs To: Sakari Ailus Cc: Linux Kernel Mailing List , Linux Media Mailing List , Andy Shevchenko , Petr Mladek , Dave Stevenson , dri-devel , Hans Verkuil , Laurent Pinchart , Mauro Carvalho Chehab , Sergey Senozhatsky , Steven Rostedt , Joe Perches , Jani Nikula , Rasmus Villemoes Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus wrote: > > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM > pixel formats denoted by fourccs. The fourcc encoding is the same for both > so the same implementation can be used. Thank you for an update with the examples how current users will be converted. Below review is based on the users I had seen so far and assumptions made in this code. I see that it's tagged by maintainers, but I can't help to comment again on this. In any case the decision is up to them. ... > +V4L2 and DRM FourCC code (pixel format) > +--------------------------------------- > + > +:: > + > + %p4cc > + > +Print a FourCC code used by V4L2 or DRM, including format endianness and > +its numerical value as hexadecimal. > + > +Passed by reference. > + > +Examples:: > + > + %p4cc BG12 little-endian (0x32314742) This misses examples of the (strange) escaping cases and wiped whitespaces to make sure everybody understands that 'D 12' will be the same as 'D1 2' (side note: which I disagree on, perhaps something should be added into documentation why). ... > +static noinline_for_stack > +char *fourcc_string(char *buf, char *end, const u32 *fourcc, > + struct printf_spec spec, const char *fmt) > +{ > + char output[sizeof("(xx)(xx)(xx)(xx) little-endian (0x01234567)")]; Do we have any evidence / document / standard that the above format is what people would find good? From existing practices (I consider other printings elsewhere and users in this series) I find '(xx)' form for hex numbers is weird. The standard practice is to use \xHH (without parentheses). > + char *p = output; > + unsigned int i; > + u32 val; > + > + if (fmt[1] != 'c' || fmt[2] != 'c') > + return error_string(buf, end, "(%p4?)", spec); > + > + if (check_pointer(&buf, end, fourcc, spec)) > + return buf; > + > + val = *fourcc & ~BIT(31); > + > + for (i = 0; i < sizeof(*fourcc); i++) { > + unsigned char c = val >> (i * 8); ... > + /* Weed out spaces */ > + if (c == ' ') > + continue; None of the existing users does that. Why? > + /* Print non-control ASCII characters as-is */ > + if (isascii(c) && isprint(c)) { > + *p++ = c; > + continue; > + } > + > + *p++ = '('; > + p = hex_byte_pack(p, c); > + *p++ = ')'; > + } > + > + strcpy(p, *fourcc & BIT(31) ? " big-endian" : " little-endian"); > + p += strlen(p); > + > + *p++ = ' '; > + *p++ = '('; > + p = special_hex_number(p, output + sizeof(output) - 2, *fourcc, > + sizeof(u32)); This is perfectly one line (in this file we have even longer lines). > + *p++ = ')'; > + *p = '\0'; > + > + return string(buf, end, output, spec); > +} -- With Best Regards, Andy Shevchenko