Hi Andy, On Thu, Dec 10, 2020 at 03:05:02PM +0200, Andy Shevchenko wrote: > On Thu, Dec 10, 2020 at 2:16 PM Petr Mladek <pmladek@xxxxxxxx> wrote: > > On Fri 2020-11-13 12:54:41, 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. > > > > > > Suggested-by: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> > > > Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> > > > > Andy, Rasmus, > > > > the last version looks fine to me. I am going to push it. > > Please, speak up if you are against it. > > My concerns are: > - not so standard format of representation (why not to use > string_escape_mem() helper?) or is it? The format string may contain spaces that are not meant to be printed. Other unprintable chacaters should not be present (at least not in V4L2 pixelformats). The hexadecimal representation is there to convey the numerical value and that originally came from DRM, not V4L2. > - no compatibility with generic 4cc > (I would rather have an additional specifier here for v4l2 cases. What do you mean by "generic 4cc"? There are two users of 4cc codes in the kernel that I know of: V4L2 and DRM. Something that does not refer to in-memory pixel formats? > OTOH generic %p4cc to me sounds like an equivalent to %4pEh (but we > have similar cases with MAC where %6ph is the same as %pM). > > But I'm not insisting on them, consider it like just my 2 cents to the > discussion. Ack. -- Kind regards, Sakari Ailus