[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wo6tkqtr.fsf@intel.com>
Date: Mon, 06 Apr 2020 10:37:20 +0300
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Petr Mladek <pmladek@...e.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
linux-media@...r.kernel.org,
Dave Stevenson <dave.stevenson@...pberrypi.com>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
hverkuil@...all.nl, laurent.pinchart@...asonboard.com,
mchehab@...nel.org,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Joe Perches <joe@...ches.com>
Subject: Re: [PATCH v2 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
On Mon, 06 Apr 2020, Sakari Ailus <sakari.ailus@...ux.intel.com> wrote:
> On Fri, Apr 03, 2020 at 02:10:53PM +0200, Rasmus Villemoes wrote:
>> 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.
Not arguing one way or another, just observing that
drm_get_format_name() abstracts that by using:
struct drm_format_name_buf {
char str[32];
};
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Powered by blists - more mailing lists