From: Jani Nikula <jani.nikula@linux.intel.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>,
Petr Mladek <pmladek@suse.com>
Cc: mchehab@kernel.org,
"Dave Stevenson" <dave.stevenson@raspberrypi.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
hverkuil@xs4all.nl,
"Sergey Senozhatsky" <sergey.senozhatsky@gmail.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
laurent.pinchart@ideasonboard.com,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
linux-media@vger.kernel.org,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>
Subject: Re: [PATCH 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
Date: Thu, 02 Apr 2020 11:34:48 +0300 [thread overview]
Message-ID: <87eet6mgk7.fsf@intel.com> (raw)
In-Reply-To: <20200401140522.966-1-sakari.ailus@linux.intel.com>
On Wed, 01 Apr 2020, Sakari Ailus <sakari.ailus@linux.intel.com> 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.
I'm not going to take a strong stand in one way or the other regarding
the patch at hand, but I do think at some point we have to draw a line
what should be included in printk formats. Arguably they should be
reserved to things that are generally useful across large parts of the
kernel, right?
I think the more specialized you get, the more you should think about
just using the plain old %s, and your own helpers. Because frankly, the
kernel printk specifiers also start getting more than a little obscure.
Or could we conceive of a way to make this locally extensible yet safe,
letting callers use something like %{foo}, as well as providing a
locally relevant function to do the conversion?
BR,
Jani.
>
> Suggested-by: Mauro Carvalho Chehab <mchehab@kernel.org>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> ---
> Documentation/core-api/printk-formats.rst | 11 +++++++++
> lib/vsprintf.c | 29 +++++++++++++++++++++++
> 2 files changed, 40 insertions(+)
>
> diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
> index 8ebe46b1af39..b6249f513c09 100644
> --- a/Documentation/core-api/printk-formats.rst
> +++ b/Documentation/core-api/printk-formats.rst
> @@ -545,6 +545,17 @@ For printing netdev_features_t.
>
> Passed by reference.
>
> +V4L2 and DRM fourcc code (pixel format)
> +---------------------------------------
> +
> +::
> +
> + %ppf
> +
> +Print a 4cc code used by V4L2 or DRM.
> +
> +Passed by reference.
> +
> Thanks
> ======
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 7c488a1ce318..b39f0ac317c5 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1721,6 +1721,32 @@ char *netdev_bits(char *buf, char *end, const void *addr,
> return special_hex_number(buf, end, num, size);
> }
>
> +static noinline_for_stack
> +char *pixel_format_string(char *buf, char *end, const u32 *fourcc,
> + struct printf_spec spec, const char *fmt)
> +{
> + char ch[2] = { 0 };
> + unsigned int i;
> +
> + if (check_pointer(&buf, end, fourcc, spec))
> + return buf;
> +
> + switch (fmt[1]) {
> + case 'f':
> + for (i = 0; i < sizeof(*fourcc); i++) {
> + ch[0] = *fourcc >> (i << 3);
> + buf = string(buf, end, ch, spec);
> + }
> +
> + if (*fourcc & BIT(31))
> + buf = string(buf, end, "-BE", spec);
> +
> + return buf;
> + default:
> + return error_string(buf, end, "(%pp?)", spec);
> + }
> +}
> +
> static noinline_for_stack
> char *address_val(char *buf, char *end, const void *addr,
> struct printf_spec spec, const char *fmt)
> @@ -2131,6 +2157,7 @@ char *fwnode_string(char *buf, char *end, struct fwnode_handle *fwnode,
> * correctness of the format string and va_list arguments.
> * - 'K' For a kernel pointer that should be hidden from unprivileged users
> * - 'NF' For a netdev_features_t
> + * - 'pf' V4L2 or DRM pixel format.
> * - 'h[CDN]' For a variable-length buffer, it prints it as a hex string with
> * a certain separator (' ' by default):
> * C colon
> @@ -2223,6 +2250,8 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
> return restricted_pointer(buf, end, ptr, spec);
> case 'N':
> return netdev_bits(buf, end, ptr, spec, fmt);
> + case 'p':
> + return pixel_format_string(buf, end, ptr, spec, fmt);
> case 'a':
> return address_val(buf, end, ptr, spec, fmt);
> case 'd':
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2020-04-02 8:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 14:05 [PATCH 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs Sakari Ailus
2020-04-01 14:13 ` Hans Verkuil
2020-04-01 15:13 ` Andy Shevchenko
2020-04-02 7:32 ` Sakari Ailus
2020-04-06 7:37 ` Pekka Paalanen
2020-04-02 7:18 ` Sakari Ailus
2020-04-02 8:34 ` Jani Nikula [this message]
2020-04-02 8:52 ` Sakari Ailus
2020-04-02 13:53 ` Mauro Carvalho Chehab
2020-04-02 23:28 ` Joe Perches
2020-04-02 23:26 ` Joe Perches
2020-04-03 6:37 ` Jani Nikula
2020-04-03 13:11 ` Joe Perches
2020-04-27 14:50 Sakari Ailus
2020-04-27 14:54 ` Sakari Ailus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eet6mgk7.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sakari.ailus@linux.intel.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).