[PATCH v6 0/3] Add %p4cc printk modifier for V4L2 and DRM fourcc codes

[PATCH v6 0/3] Add %p4cc printk modifier for V4L2 and DRM fourcc codes

[Sakari Ailus]

Hi all,

This set adds support for %p4cc printk modifier for printing V4L2 and DRM
fourcc codes. The codes are cumbersome to print manually and by adding the
modifier, this task is saved from the V4L2 and DRM frameworks as well as
related drivers. DRM actually had it handled in a way (see 3rd patch) but
the printk modifier makes printing the format easier even there. On V4L2
side it saves quite a few lines of repeating different implementations of
printing the 4cc codes.

Further work will include converting the V4L2 drivers doing the same, as
well as converting DRM drivers from drm_get_format_name() to plain %p4cc.
I left these out from this version since individual drivers are easier
changed without dealing with multiple trees.

If DRM folks would prefer to convert drivers to %p4cc directly instead I
have no problem dropping the 3rd patch. Nearly all uses in DRM are in
printk family of functions that can readily use %p4cc instead of the
current arrangement that relies on caller-allocated temporary buffer.

Since v5:

- Added V4L2 core conversion to %p4cc, as well as change the DRM
  fourcc printing function to use %p4cc.

- Add missing checkpatch.pl checks for %p4cc modifier.

Sakari Ailus (3):
  lib/vsprintf: Add support for printing V4L2 and DRM fourccs
  v4l: ioctl: Use %p4cc printk modifier to print FourCC codes
  drm/fourcc: Switch to %p4cc format modifier

 Documentation/core-api/printk-formats.rst | 16 +++++
 drivers/gpu/drm/drm_fourcc.c              | 16 +----
 drivers/media/v4l2-core/v4l2-ioctl.c      | 85 ++++++-----------------
 lib/test_printf.c                         | 17 +++++
 lib/vsprintf.c                            | 51 ++++++++++++++
 scripts/checkpatch.pl                     |  6 +-
 6 files changed, 112 insertions(+), 79 deletions(-)

-- 
2.29.2

[PATCH v6 0/3] Add %p4cc printk modifier for V4L2 and DRM fourcc codes

[Sakari Ailus]

Hi all,

This set adds support for %p4cc printk modifier for printing V4L2 and DRM
fourcc codes. The codes are cumbersome to print manually and by adding the
modifier, this task is saved from the V4L2 and DRM frameworks as well as
related drivers. DRM actually had it handled in a way (see 3rd patch) but
the printk modifier makes printing the format easier even there. On V4L2
side it saves quite a few lines of repeating different implementations of
printing the 4cc codes.

Further work will include converting the V4L2 drivers doing the same, as
well as converting DRM drivers from drm_get_format_name() to plain %p4cc.
I left these out from this version since individual drivers are easier
changed without dealing with multiple trees.

If DRM folks would prefer to convert drivers to %p4cc directly instead I
have no problem dropping the 3rd patch. Nearly all uses in DRM are in
printk family of functions that can readily use %p4cc instead of the
current arrangement that relies on caller-allocated temporary buffer.

Since v5:

- Added V4L2 core conversion to %p4cc, as well as change the DRM
  fourcc printing function to use %p4cc.

- Add missing checkpatch.pl checks for %p4cc modifier.

Sakari Ailus (3):
  lib/vsprintf: Add support for printing V4L2 and DRM fourccs
  v4l: ioctl: Use %p4cc printk modifier to print FourCC codes
  drm/fourcc: Switch to %p4cc format modifier

 Documentation/core-api/printk-formats.rst | 16 +++++
 drivers/gpu/drm/drm_fourcc.c              | 16 +----
 drivers/media/v4l2-core/v4l2-ioctl.c      | 85 ++++++-----------------
 lib/test_printf.c                         | 17 +++++
 lib/vsprintf.c                            | 51 ++++++++++++++
 scripts/checkpatch.pl                     |  6 +-
 6 files changed, 112 insertions(+), 79 deletions(-)

-- 
2.29.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Sakari Ailus]

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@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
---
 Documentation/core-api/printk-formats.rst | 16 +++++++
 lib/test_printf.c                         | 17 ++++++++
 lib/vsprintf.c                            | 51 +++++++++++++++++++++++
 scripts/checkpatch.pl                     |  6 ++-
 4 files changed, 88 insertions(+), 2 deletions(-)

diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
index 160e710d992f..da2aa065dc42 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -567,6 +567,22 @@ 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, including format endianness and
+its numerical value as hexadecimal.
+
+Passed by reference.
+
+Examples::
+
+	%p4cc	BG12 little-endian (0x32314742)
+
 Thanks
 ======
 
diff --git a/lib/test_printf.c b/lib/test_printf.c
index 7d60f24240a4..78c94159d9d5 100644
--- a/lib/test_printf.c
+++ b/lib/test_printf.c
@@ -647,6 +647,22 @@ static void __init fwnode_pointer(void)
 	software_node_unregister_nodes(softnodes);
 }
 
+static void __init fourcc_pointer(void)
+{
+	struct {
+		u32 code;
+		char *str;
+	} const try[] = {
+		{ 0x20104646, "FF(10) little-endian (0x20104646)", },
+		{ 0xa0104646, "FF(10) big-endian (0xa0104646)", },
+		{ 0x10111213, "(13)(12)(11)(10) little-endian (0x10111213)", },
+	};
+	unsigned int i;
+
+	for (i = 0; i < ARRAY_SIZE(try); i++)
+		test(try[i].str, "%p4cc", &try[i].code);
+}
+
 static void __init
 errptr(void)
 {
@@ -692,6 +708,7 @@ test_pointer(void)
 	flags();
 	errptr();
 	fwnode_pointer();
+	fourcc_pointer();
 }
 
 static void __init selftest(void)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 3b53c73580c5..ef50557e07b3 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1733,6 +1733,54 @@ char *netdev_bits(char *buf, char *end, const void *addr,
 	return special_hex_number(buf, end, num, size);
 }
 
+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)")];
+	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;
+
+		/* 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));
+	*p++ = ')';
+	*p = '\0';
+
+	return string(buf, end, output, spec);
+}
+
 static noinline_for_stack
 char *address_val(char *buf, char *end, const void *addr,
 		  struct printf_spec spec, const char *fmt)
@@ -2162,6 +2210,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
+ * - '4cc' V4L2 or DRM FourCC code, with endianness and raw numerical value.
  * - 'h[CDN]' For a variable-length buffer, it prints it as a hex string with
  *            a certain separator (' ' by default):
  *              C colon
@@ -2259,6 +2308,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 '4':
+		return fourcc_string(buf, end, ptr, spec, fmt);
 	case 'a':
 		return address_val(buf, end, ptr, spec, fmt);
 	case 'd':
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 92e888ed939f..79858e07d023 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6557,9 +6557,11 @@ sub process {
 					$specifier = $1;
 					$extension = $2;
 					$qualifier = $3;
-					if ($extension !~ /[SsBKRraEehMmIiUDdgVCbGNOxtf]/ ||
+					if ($extension !~ /[4SsBKRraEehMmIiUDdgVCbGNOxtf]/ ||
 					    ($extension eq "f" &&
-					     defined $qualifier && $qualifier !~ /^w/)) {
+					     defined $qualifier && $qualifier !~ /^w/) ||
+					    ($extension eq "4" &&
+					     defined $qualifier && $qualifier !~ /^cc/)) {
 						$bad_specifier = $specifier;
 						last;
 					}
-- 
2.29.2

[PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Sakari Ailus]

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@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
---
 Documentation/core-api/printk-formats.rst | 16 +++++++
 lib/test_printf.c                         | 17 ++++++++
 lib/vsprintf.c                            | 51 +++++++++++++++++++++++
 scripts/checkpatch.pl                     |  6 ++-
 4 files changed, 88 insertions(+), 2 deletions(-)

diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
index 160e710d992f..da2aa065dc42 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -567,6 +567,22 @@ 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, including format endianness and
+its numerical value as hexadecimal.
+
+Passed by reference.
+
+Examples::
+
+	%p4cc	BG12 little-endian (0x32314742)
+
 Thanks
 ======
 
diff --git a/lib/test_printf.c b/lib/test_printf.c
index 7d60f24240a4..78c94159d9d5 100644
--- a/lib/test_printf.c
+++ b/lib/test_printf.c
@@ -647,6 +647,22 @@ static void __init fwnode_pointer(void)
 	software_node_unregister_nodes(softnodes);
 }
 
+static void __init fourcc_pointer(void)
+{
+	struct {
+		u32 code;
+		char *str;
+	} const try[] = {
+		{ 0x20104646, "FF(10) little-endian (0x20104646)", },
+		{ 0xa0104646, "FF(10) big-endian (0xa0104646)", },
+		{ 0x10111213, "(13)(12)(11)(10) little-endian (0x10111213)", },
+	};
+	unsigned int i;
+
+	for (i = 0; i < ARRAY_SIZE(try); i++)
+		test(try[i].str, "%p4cc", &try[i].code);
+}
+
 static void __init
 errptr(void)
 {
@@ -692,6 +708,7 @@ test_pointer(void)
 	flags();
 	errptr();
 	fwnode_pointer();
+	fourcc_pointer();
 }
 
 static void __init selftest(void)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 3b53c73580c5..ef50557e07b3 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1733,6 +1733,54 @@ char *netdev_bits(char *buf, char *end, const void *addr,
 	return special_hex_number(buf, end, num, size);
 }
 
+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)")];
+	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;
+
+		/* 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));
+	*p++ = ')';
+	*p = '\0';
+
+	return string(buf, end, output, spec);
+}
+
 static noinline_for_stack
 char *address_val(char *buf, char *end, const void *addr,
 		  struct printf_spec spec, const char *fmt)
@@ -2162,6 +2210,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
+ * - '4cc' V4L2 or DRM FourCC code, with endianness and raw numerical value.
  * - 'h[CDN]' For a variable-length buffer, it prints it as a hex string with
  *            a certain separator (' ' by default):
  *              C colon
@@ -2259,6 +2308,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 '4':
+		return fourcc_string(buf, end, ptr, spec, fmt);
 	case 'a':
 		return address_val(buf, end, ptr, spec, fmt);
 	case 'd':
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 92e888ed939f..79858e07d023 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6557,9 +6557,11 @@ sub process {
 					$specifier = $1;
 					$extension = $2;
 					$qualifier = $3;
-					if ($extension !~ /[SsBKRraEehMmIiUDdgVCbGNOxtf]/ ||
+					if ($extension !~ /[4SsBKRraEehMmIiUDdgVCbGNOxtf]/ ||
 					    ($extension eq "f" &&
-					     defined $qualifier && $qualifier !~ /^w/)) {
+					     defined $qualifier && $qualifier !~ /^w/) ||
+					    ($extension eq "4" &&
+					     defined $qualifier && $qualifier !~ /^cc/)) {
 						$bad_specifier = $specifier;
 						last;
 					}
-- 
2.29.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes

[Sakari Ailus]

Now that we can print FourCC codes directly using printk, make use of the
feature in V4L2 core.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 85 +++++++---------------------
 1 file changed, 21 insertions(+), 64 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 31d1342e61e8..31662c3a8c9e 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -265,13 +265,9 @@ static void v4l_print_fmtdesc(const void *arg, bool write_only)
 {
 	const struct v4l2_fmtdesc *p = arg;
 
-	pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%c%c%c%c, mbus_code=0x%04x, description='%.*s'\n",
+	pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%p4cc, mbus_code=0x%04x, description='%.*s'\n",
 		p->index, prt_names(p->type, v4l2_type_names),
-		p->flags, (p->pixelformat & 0xff),
-		(p->pixelformat >>  8) & 0xff,
-		(p->pixelformat >> 16) & 0xff,
-		(p->pixelformat >> 24) & 0xff,
-		p->mbus_code,
+		p->flags, &p->pixelformat, p->mbus_code,
 		(int)sizeof(p->description), p->description);
 }
 
@@ -293,12 +289,8 @@ static void v4l_print_format(const void *arg, bool write_only)
 	case V4L2_BUF_TYPE_VIDEO_CAPTURE:
 	case V4L2_BUF_TYPE_VIDEO_OUTPUT:
 		pix = &p->fmt.pix;
-		pr_cont(", width=%u, height=%u, pixelformat=%c%c%c%c, field=%s, bytesperline=%u, sizeimage=%u, colorspace=%d, flags=0x%x, ycbcr_enc=%u, quantization=%u, xfer_func=%u\n",
-			pix->width, pix->height,
-			(pix->pixelformat & 0xff),
-			(pix->pixelformat >>  8) & 0xff,
-			(pix->pixelformat >> 16) & 0xff,
-			(pix->pixelformat >> 24) & 0xff,
+		pr_cont(", width=%u, height=%u, pixelformat=%p4cc, field=%s, bytesperline=%u, sizeimage=%u, colorspace=%d, flags=0x%x, ycbcr_enc=%u, quantization=%u, xfer_func=%u\n",
+			pix->width, pix->height, &pix->pixelformat,
 			prt_names(pix->field, v4l2_field_names),
 			pix->bytesperline, pix->sizeimage,
 			pix->colorspace, pix->flags, pix->ycbcr_enc,
@@ -307,12 +299,8 @@ static void v4l_print_format(const void *arg, bool write_only)
 	case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
 	case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
 		mp = &p->fmt.pix_mp;
-		pr_cont(", width=%u, height=%u, format=%c%c%c%c, field=%s, colorspace=%d, num_planes=%u, flags=0x%x, ycbcr_enc=%u, quantization=%u, xfer_func=%u\n",
-			mp->width, mp->height,
-			(mp->pixelformat & 0xff),
-			(mp->pixelformat >>  8) & 0xff,
-			(mp->pixelformat >> 16) & 0xff,
-			(mp->pixelformat >> 24) & 0xff,
+		pr_cont(", width=%u, height=%u, format=%p4cc, field=%s, colorspace=%d, num_planes=%u, flags=0x%x, ycbcr_enc=%u, quantization=%u, xfer_func=%u\n",
+			mp->width, mp->height, &mp->pixelformat,
 			prt_names(mp->field, v4l2_field_names),
 			mp->colorspace, mp->num_planes, mp->flags,
 			mp->ycbcr_enc, mp->quantization, mp->xfer_func);
@@ -337,13 +325,9 @@ static void v4l_print_format(const void *arg, bool write_only)
 	case V4L2_BUF_TYPE_VBI_CAPTURE:
 	case V4L2_BUF_TYPE_VBI_OUTPUT:
 		vbi = &p->fmt.vbi;
-		pr_cont(", sampling_rate=%u, offset=%u, samples_per_line=%u, sample_format=%c%c%c%c, start=%u,%u, count=%u,%u\n",
+		pr_cont(", sampling_rate=%u, offset=%u, samples_per_line=%u, sample_format=%p4cc, start=%u,%u, count=%u,%u\n",
 			vbi->sampling_rate, vbi->offset,
-			vbi->samples_per_line,
-			(vbi->sample_format & 0xff),
-			(vbi->sample_format >>  8) & 0xff,
-			(vbi->sample_format >> 16) & 0xff,
-			(vbi->sample_format >> 24) & 0xff,
+			vbi->samples_per_line, &vbi->sample_format,
 			vbi->start[0], vbi->start[1],
 			vbi->count[0], vbi->count[1]);
 		break;
@@ -360,21 +344,13 @@ static void v4l_print_format(const void *arg, bool write_only)
 	case V4L2_BUF_TYPE_SDR_CAPTURE:
 	case V4L2_BUF_TYPE_SDR_OUTPUT:
 		sdr = &p->fmt.sdr;
-		pr_cont(", pixelformat=%c%c%c%c\n",
-			(sdr->pixelformat >>  0) & 0xff,
-			(sdr->pixelformat >>  8) & 0xff,
-			(sdr->pixelformat >> 16) & 0xff,
-			(sdr->pixelformat >> 24) & 0xff);
+		pr_cont(", pixelformat=%p4cc\n", &sdr->pixelformat);
 		break;
 	case V4L2_BUF_TYPE_META_CAPTURE:
 	case V4L2_BUF_TYPE_META_OUTPUT:
 		meta = &p->fmt.meta;
-		pr_cont(", dataformat=%c%c%c%c, buffersize=%u\n",
-			(meta->dataformat >>  0) & 0xff,
-			(meta->dataformat >>  8) & 0xff,
-			(meta->dataformat >> 16) & 0xff,
-			(meta->dataformat >> 24) & 0xff,
-			meta->buffersize);
+		pr_cont(", dataformat=%p4cc, buffersize=%u\n",
+			&meta->dataformat, meta->buffersize);
 		break;
 	}
 }
@@ -383,15 +359,10 @@ static void v4l_print_framebuffer(const void *arg, bool write_only)
 {
 	const struct v4l2_framebuffer *p = arg;
 
-	pr_cont("capability=0x%x, flags=0x%x, base=0x%p, width=%u, height=%u, pixelformat=%c%c%c%c, bytesperline=%u, sizeimage=%u, colorspace=%d\n",
-			p->capability, p->flags, p->base,
-			p->fmt.width, p->fmt.height,
-			(p->fmt.pixelformat & 0xff),
-			(p->fmt.pixelformat >>  8) & 0xff,
-			(p->fmt.pixelformat >> 16) & 0xff,
-			(p->fmt.pixelformat >> 24) & 0xff,
-			p->fmt.bytesperline, p->fmt.sizeimage,
-			p->fmt.colorspace);
+	pr_cont("capability=0x%x, flags=0x%x, base=0x%p, width=%u, height=%u, pixelformat=%p4cc, bytesperline=%u, sizeimage=%u, colorspace=%d\n",
+		p->capability, p->flags, p->base, p->fmt.width, p->fmt.height,
+		&p->fmt.pixelformat, p->fmt.bytesperline, p->fmt.sizeimage,
+		p->fmt.colorspace);
 }
 
 static void v4l_print_buftype(const void *arg, bool write_only)
@@ -761,13 +732,8 @@ static void v4l_print_frmsizeenum(const void *arg, bool write_only)
 {
 	const struct v4l2_frmsizeenum *p = arg;
 
-	pr_cont("index=%u, pixelformat=%c%c%c%c, type=%u",
-			p->index,
-			(p->pixel_format & 0xff),
-			(p->pixel_format >>  8) & 0xff,
-			(p->pixel_format >> 16) & 0xff,
-			(p->pixel_format >> 24) & 0xff,
-			p->type);
+	pr_cont("index=%u, pixelformat=%p4cc, type=%u",
+		p->index, &p->pixel_format, p->type);
 	switch (p->type) {
 	case V4L2_FRMSIZE_TYPE_DISCRETE:
 		pr_cont(", wxh=%ux%u\n",
@@ -793,13 +759,8 @@ static void v4l_print_frmivalenum(const void *arg, bool write_only)
 {
 	const struct v4l2_frmivalenum *p = arg;
 
-	pr_cont("index=%u, pixelformat=%c%c%c%c, wxh=%ux%u, type=%u",
-			p->index,
-			(p->pixel_format & 0xff),
-			(p->pixel_format >>  8) & 0xff,
-			(p->pixel_format >> 16) & 0xff,
-			(p->pixel_format >> 24) & 0xff,
-			p->width, p->height, p->type);
+	pr_cont("index=%u, pixelformat=%p4cc, wxh=%ux%u, type=%u",
+		p->index, &p->pixel_format, p->width, p->height, p->type);
 	switch (p->type) {
 	case V4L2_FRMIVAL_TYPE_DISCRETE:
 		pr_cont(", fps=%d/%d\n",
@@ -1459,12 +1420,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
 				return;
 			WARN(1, "Unknown pixelformat 0x%08x\n", fmt->pixelformat);
 			flags = 0;
-			snprintf(fmt->description, sz, "%c%c%c%c%s",
-					(char)(fmt->pixelformat & 0x7f),
-					(char)((fmt->pixelformat >> 8) & 0x7f),
-					(char)((fmt->pixelformat >> 16) & 0x7f),
-					(char)((fmt->pixelformat >> 24) & 0x7f),
-					(fmt->pixelformat & (1UL << 31)) ? "-BE" : "");
+			snprintf(fmt->description, sz, "%p4cc",
+				 &fmt->pixelformat);
 			break;
 		}
 	}
-- 
2.29.2

[PATCH v6 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes

[Sakari Ailus]

Now that we can print FourCC codes directly using printk, make use of the
feature in V4L2 core.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 85 +++++++---------------------
 1 file changed, 21 insertions(+), 64 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 31d1342e61e8..31662c3a8c9e 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -265,13 +265,9 @@ static void v4l_print_fmtdesc(const void *arg, bool write_only)
 {
 	const struct v4l2_fmtdesc *p = arg;
 
-	pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%c%c%c%c, mbus_code=0x%04x, description='%.*s'\n",
+	pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%p4cc, mbus_code=0x%04x, description='%.*s'\n",
 		p->index, prt_names(p->type, v4l2_type_names),
-		p->flags, (p->pixelformat & 0xff),
-		(p->pixelformat >>  8) & 0xff,
-		(p->pixelformat >> 16) & 0xff,
-		(p->pixelformat >> 24) & 0xff,
-		p->mbus_code,
+		p->flags, &p->pixelformat, p->mbus_code,
 		(int)sizeof(p->description), p->description);
 }
 
@@ -293,12 +289,8 @@ static void v4l_print_format(const void *arg, bool write_only)
 	case V4L2_BUF_TYPE_VIDEO_CAPTURE:
 	case V4L2_BUF_TYPE_VIDEO_OUTPUT:
 		pix = &p->fmt.pix;
-		pr_cont(", width=%u, height=%u, pixelformat=%c%c%c%c, field=%s, bytesperline=%u, sizeimage=%u, colorspace=%d, flags=0x%x, ycbcr_enc=%u, quantization=%u, xfer_func=%u\n",
-			pix->width, pix->height,
-			(pix->pixelformat & 0xff),
-			(pix->pixelformat >>  8) & 0xff,
-			(pix->pixelformat >> 16) & 0xff,
-			(pix->pixelformat >> 24) & 0xff,
+		pr_cont(", width=%u, height=%u, pixelformat=%p4cc, field=%s, bytesperline=%u, sizeimage=%u, colorspace=%d, flags=0x%x, ycbcr_enc=%u, quantization=%u, xfer_func=%u\n",
+			pix->width, pix->height, &pix->pixelformat,
 			prt_names(pix->field, v4l2_field_names),
 			pix->bytesperline, pix->sizeimage,
 			pix->colorspace, pix->flags, pix->ycbcr_enc,
@@ -307,12 +299,8 @@ static void v4l_print_format(const void *arg, bool write_only)
 	case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
 	case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
 		mp = &p->fmt.pix_mp;
-		pr_cont(", width=%u, height=%u, format=%c%c%c%c, field=%s, colorspace=%d, num_planes=%u, flags=0x%x, ycbcr_enc=%u, quantization=%u, xfer_func=%u\n",
-			mp->width, mp->height,
-			(mp->pixelformat & 0xff),
-			(mp->pixelformat >>  8) & 0xff,
-			(mp->pixelformat >> 16) & 0xff,
-			(mp->pixelformat >> 24) & 0xff,
+		pr_cont(", width=%u, height=%u, format=%p4cc, field=%s, colorspace=%d, num_planes=%u, flags=0x%x, ycbcr_enc=%u, quantization=%u, xfer_func=%u\n",
+			mp->width, mp->height, &mp->pixelformat,
 			prt_names(mp->field, v4l2_field_names),
 			mp->colorspace, mp->num_planes, mp->flags,
 			mp->ycbcr_enc, mp->quantization, mp->xfer_func);
@@ -337,13 +325,9 @@ static void v4l_print_format(const void *arg, bool write_only)
 	case V4L2_BUF_TYPE_VBI_CAPTURE:
 	case V4L2_BUF_TYPE_VBI_OUTPUT:
 		vbi = &p->fmt.vbi;
-		pr_cont(", sampling_rate=%u, offset=%u, samples_per_line=%u, sample_format=%c%c%c%c, start=%u,%u, count=%u,%u\n",
+		pr_cont(", sampling_rate=%u, offset=%u, samples_per_line=%u, sample_format=%p4cc, start=%u,%u, count=%u,%u\n",
 			vbi->sampling_rate, vbi->offset,
-			vbi->samples_per_line,
-			(vbi->sample_format & 0xff),
-			(vbi->sample_format >>  8) & 0xff,
-			(vbi->sample_format >> 16) & 0xff,
-			(vbi->sample_format >> 24) & 0xff,
+			vbi->samples_per_line, &vbi->sample_format,
 			vbi->start[0], vbi->start[1],
 			vbi->count[0], vbi->count[1]);
 		break;
@@ -360,21 +344,13 @@ static void v4l_print_format(const void *arg, bool write_only)
 	case V4L2_BUF_TYPE_SDR_CAPTURE:
 	case V4L2_BUF_TYPE_SDR_OUTPUT:
 		sdr = &p->fmt.sdr;
-		pr_cont(", pixelformat=%c%c%c%c\n",
-			(sdr->pixelformat >>  0) & 0xff,
-			(sdr->pixelformat >>  8) & 0xff,
-			(sdr->pixelformat >> 16) & 0xff,
-			(sdr->pixelformat >> 24) & 0xff);
+		pr_cont(", pixelformat=%p4cc\n", &sdr->pixelformat);
 		break;
 	case V4L2_BUF_TYPE_META_CAPTURE:
 	case V4L2_BUF_TYPE_META_OUTPUT:
 		meta = &p->fmt.meta;
-		pr_cont(", dataformat=%c%c%c%c, buffersize=%u\n",
-			(meta->dataformat >>  0) & 0xff,
-			(meta->dataformat >>  8) & 0xff,
-			(meta->dataformat >> 16) & 0xff,
-			(meta->dataformat >> 24) & 0xff,
-			meta->buffersize);
+		pr_cont(", dataformat=%p4cc, buffersize=%u\n",
+			&meta->dataformat, meta->buffersize);
 		break;
 	}
 }
@@ -383,15 +359,10 @@ static void v4l_print_framebuffer(const void *arg, bool write_only)
 {
 	const struct v4l2_framebuffer *p = arg;
 
-	pr_cont("capability=0x%x, flags=0x%x, base=0x%p, width=%u, height=%u, pixelformat=%c%c%c%c, bytesperline=%u, sizeimage=%u, colorspace=%d\n",
-			p->capability, p->flags, p->base,
-			p->fmt.width, p->fmt.height,
-			(p->fmt.pixelformat & 0xff),
-			(p->fmt.pixelformat >>  8) & 0xff,
-			(p->fmt.pixelformat >> 16) & 0xff,
-			(p->fmt.pixelformat >> 24) & 0xff,
-			p->fmt.bytesperline, p->fmt.sizeimage,
-			p->fmt.colorspace);
+	pr_cont("capability=0x%x, flags=0x%x, base=0x%p, width=%u, height=%u, pixelformat=%p4cc, bytesperline=%u, sizeimage=%u, colorspace=%d\n",
+		p->capability, p->flags, p->base, p->fmt.width, p->fmt.height,
+		&p->fmt.pixelformat, p->fmt.bytesperline, p->fmt.sizeimage,
+		p->fmt.colorspace);
 }
 
 static void v4l_print_buftype(const void *arg, bool write_only)
@@ -761,13 +732,8 @@ static void v4l_print_frmsizeenum(const void *arg, bool write_only)
 {
 	const struct v4l2_frmsizeenum *p = arg;
 
-	pr_cont("index=%u, pixelformat=%c%c%c%c, type=%u",
-			p->index,
-			(p->pixel_format & 0xff),
-			(p->pixel_format >>  8) & 0xff,
-			(p->pixel_format >> 16) & 0xff,
-			(p->pixel_format >> 24) & 0xff,
-			p->type);
+	pr_cont("index=%u, pixelformat=%p4cc, type=%u",
+		p->index, &p->pixel_format, p->type);
 	switch (p->type) {
 	case V4L2_FRMSIZE_TYPE_DISCRETE:
 		pr_cont(", wxh=%ux%u\n",
@@ -793,13 +759,8 @@ static void v4l_print_frmivalenum(const void *arg, bool write_only)
 {
 	const struct v4l2_frmivalenum *p = arg;
 
-	pr_cont("index=%u, pixelformat=%c%c%c%c, wxh=%ux%u, type=%u",
-			p->index,
-			(p->pixel_format & 0xff),
-			(p->pixel_format >>  8) & 0xff,
-			(p->pixel_format >> 16) & 0xff,
-			(p->pixel_format >> 24) & 0xff,
-			p->width, p->height, p->type);
+	pr_cont("index=%u, pixelformat=%p4cc, wxh=%ux%u, type=%u",
+		p->index, &p->pixel_format, p->width, p->height, p->type);
 	switch (p->type) {
 	case V4L2_FRMIVAL_TYPE_DISCRETE:
 		pr_cont(", fps=%d/%d\n",
@@ -1459,12 +1420,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
 				return;
 			WARN(1, "Unknown pixelformat 0x%08x\n", fmt->pixelformat);
 			flags = 0;
-			snprintf(fmt->description, sz, "%c%c%c%c%s",
-					(char)(fmt->pixelformat & 0x7f),
-					(char)((fmt->pixelformat >> 8) & 0x7f),
-					(char)((fmt->pixelformat >> 16) & 0x7f),
-					(char)((fmt->pixelformat >> 24) & 0x7f),
-					(fmt->pixelformat & (1UL << 31)) ? "-BE" : "");
+			snprintf(fmt->description, sz, "%p4cc",
+				 &fmt->pixelformat);
 			break;
 		}
 	}
-- 
2.29.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 3/3] drm/fourcc: Switch to %p4cc format modifier

[Sakari Ailus]

Instead of constructing the FourCC code manually, use the %p4cc printk
modifier to print it. Also leave a message to avoid using this function.

The next step would be to convert the users to use %p4cc directly instead
and removing the function.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
 drivers/gpu/drm/drm_fourcc.c | 16 +++-------------
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 03262472059c..4ff40f2f27c0 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -30,11 +30,6 @@
 #include <drm/drm_device.h>
 #include <drm/drm_fourcc.h>
 
-static char printable_char(int c)
-{
-	return isascii(c) && isprint(c) ? c : '?';
-}
-
 /**
  * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description
  * @bpp: bits per pixels
@@ -134,17 +129,12 @@ EXPORT_SYMBOL(drm_driver_legacy_fb_format);
  * drm_get_format_name - fill a string with a drm fourcc format's name
  * @format: format to compute name of
  * @buf: caller-supplied buffer
+ *
+ * Please use %p4cc printk format modifier instead of this function.
  */
 const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
 {
-	snprintf(buf->str, sizeof(buf->str),
-		 "%c%c%c%c %s-endian (0x%08x)",
-		 printable_char(format & 0xff),
-		 printable_char((format >> 8) & 0xff),
-		 printable_char((format >> 16) & 0xff),
-		 printable_char((format >> 24) & 0x7f),
-		 format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
-		 format);
+	snprintf(buf->str, sizeof(buf->str), "%p4cc", &format);
 
 	return buf->str;
 }
-- 
2.29.2

[PATCH v6 3/3] drm/fourcc: Switch to %p4cc format modifier

[Sakari Ailus]

Instead of constructing the FourCC code manually, use the %p4cc printk
modifier to print it. Also leave a message to avoid using this function.

The next step would be to convert the users to use %p4cc directly instead
and removing the function.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
 drivers/gpu/drm/drm_fourcc.c | 16 +++-------------
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 03262472059c..4ff40f2f27c0 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -30,11 +30,6 @@
 #include <drm/drm_device.h>
 #include <drm/drm_fourcc.h>
 
-static char printable_char(int c)
-{
-	return isascii(c) && isprint(c) ? c : '?';
-}
-
 /**
  * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description
  * @bpp: bits per pixels
@@ -134,17 +129,12 @@ EXPORT_SYMBOL(drm_driver_legacy_fb_format);
  * drm_get_format_name - fill a string with a drm fourcc format's name
  * @format: format to compute name of
  * @buf: caller-supplied buffer
+ *
+ * Please use %p4cc printk format modifier instead of this function.
  */
 const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
 {
-	snprintf(buf->str, sizeof(buf->str),
-		 "%c%c%c%c %s-endian (0x%08x)",
-		 printable_char(format & 0xff),
-		 printable_char((format >> 8) & 0xff),
-		 printable_char((format >> 16) & 0xff),
-		 printable_char((format >> 24) & 0x7f),
-		 format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
-		 format);
+	snprintf(buf->str, sizeof(buf->str), "%p4cc", &format);
 
 	return buf->str;
 }
-- 
2.29.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Andy Shevchenko]

On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
<sakari.ailus@linux.intel.com> 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

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Andy Shevchenko]

On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
<sakari.ailus@linux.intel.com> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Andy Shevchenko]

On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:

...

> > +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).

> > +       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++ = ')';
> > +       }


To be on constructive side, I would propose to replace above with something
like:

__le32 val;

val = cpu_to_le32(*fourcc & ~BIT(31));

p += string_escape_mem(&val, sizeof(*fourcc), output, sizeof(output), ESCAPE_NP | ESCAPE_HEX, NULL);


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Andy Shevchenko]

On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:

...

> > +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).

> > +       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++ = ')';
> > +       }


To be on constructive side, I would propose to replace above with something
like:

__le32 val;

val = cpu_to_le32(*fourcc & ~BIT(31));

p += string_escape_mem(&val, sizeof(*fourcc), output, sizeof(output), ESCAPE_NP | ESCAPE_HEX, NULL);


-- 
With Best Regards,
Andy Shevchenko


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 3/3] drm/fourcc: Switch to %p4cc format modifier

[Daniel Vetter]

On Mon, Feb 8, 2021 at 9:20 PM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> Instead of constructing the FourCC code manually, use the %p4cc printk
> modifier to print it. Also leave a message to avoid using this function.
>
> The next step would be to convert the users to use %p4cc directly instead
> and removing the function.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> ---
>  drivers/gpu/drm/drm_fourcc.c | 16 +++-------------
>  1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 03262472059c..4ff40f2f27c0 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -30,11 +30,6 @@
>  #include <drm/drm_device.h>
>  #include <drm/drm_fourcc.h>
>
> -static char printable_char(int c)
> -{
> -       return isascii(c) && isprint(c) ? c : '?';
> -}
> -
>  /**
>   * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description
>   * @bpp: bits per pixels
> @@ -134,17 +129,12 @@ EXPORT_SYMBOL(drm_driver_legacy_fb_format);
>   * drm_get_format_name - fill a string with a drm fourcc format's name
>   * @format: format to compute name of
>   * @buf: caller-supplied buffer
> + *
> + * Please use %p4cc printk format modifier instead of this function.

I think would be nice if we could roll this out and outright delete
this one here ... Quick git grep says there's not that many, and %p4cc
is quite a bit shorter than what we have now.
-Daniel

>   */
>  const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
>  {
> -       snprintf(buf->str, sizeof(buf->str),
> -                "%c%c%c%c %s-endian (0x%08x)",
> -                printable_char(format & 0xff),
> -                printable_char((format >> 8) & 0xff),
> -                printable_char((format >> 16) & 0xff),
> -                printable_char((format >> 24) & 0x7f),
> -                format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
> -                format);
> +       snprintf(buf->str, sizeof(buf->str), "%p4cc", &format);
>
>         return buf->str;
>  }
> --
> 2.29.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v6 3/3] drm/fourcc: Switch to %p4cc format modifier

[Daniel Vetter]

On Mon, Feb 8, 2021 at 9:20 PM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> Instead of constructing the FourCC code manually, use the %p4cc printk
> modifier to print it. Also leave a message to avoid using this function.
>
> The next step would be to convert the users to use %p4cc directly instead
> and removing the function.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> ---
>  drivers/gpu/drm/drm_fourcc.c | 16 +++-------------
>  1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 03262472059c..4ff40f2f27c0 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -30,11 +30,6 @@
>  #include <drm/drm_device.h>
>  #include <drm/drm_fourcc.h>
>
> -static char printable_char(int c)
> -{
> -       return isascii(c) && isprint(c) ? c : '?';
> -}
> -
>  /**
>   * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description
>   * @bpp: bits per pixels
> @@ -134,17 +129,12 @@ EXPORT_SYMBOL(drm_driver_legacy_fb_format);
>   * drm_get_format_name - fill a string with a drm fourcc format's name
>   * @format: format to compute name of
>   * @buf: caller-supplied buffer
> + *
> + * Please use %p4cc printk format modifier instead of this function.

I think would be nice if we could roll this out and outright delete
this one here ... Quick git grep says there's not that many, and %p4cc
is quite a bit shorter than what we have now.
-Daniel

>   */
>  const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
>  {
> -       snprintf(buf->str, sizeof(buf->str),
> -                "%c%c%c%c %s-endian (0x%08x)",
> -                printable_char(format & 0xff),
> -                printable_char((format >> 8) & 0xff),
> -                printable_char((format >> 16) & 0xff),
> -                printable_char((format >> 24) & 0x7f),
> -                format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
> -                format);
> +       snprintf(buf->str, sizeof(buf->str), "%p4cc", &format);
>
>         return buf->str;
>  }
> --
> 2.29.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 3/3] drm/fourcc: Switch to %p4cc format modifier

[Sakari Ailus]

Hi Daniel,

Thanks for the comments.

On Tue, Feb 09, 2021 at 08:27:10AM +0100, Daniel Vetter wrote:
> On Mon, Feb 8, 2021 at 9:20 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > Instead of constructing the FourCC code manually, use the %p4cc printk
> > modifier to print it. Also leave a message to avoid using this function.
> >
> > The next step would be to convert the users to use %p4cc directly instead
> > and removing the function.
> >
> > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > ---
> >  drivers/gpu/drm/drm_fourcc.c | 16 +++-------------
> >  1 file changed, 3 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index 03262472059c..4ff40f2f27c0 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -30,11 +30,6 @@
> >  #include <drm/drm_device.h>
> >  #include <drm/drm_fourcc.h>
> >
> > -static char printable_char(int c)
> > -{
> > -       return isascii(c) && isprint(c) ? c : '?';
> > -}
> > -
> >  /**
> >   * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description
> >   * @bpp: bits per pixels
> > @@ -134,17 +129,12 @@ EXPORT_SYMBOL(drm_driver_legacy_fb_format);
> >   * drm_get_format_name - fill a string with a drm fourcc format's name
> >   * @format: format to compute name of
> >   * @buf: caller-supplied buffer
> > + *
> > + * Please use %p4cc printk format modifier instead of this function.
> 
> I think would be nice if we could roll this out and outright delete
> this one here ... Quick git grep says there's not that many, and %p4cc
> is quite a bit shorter than what we have now.

Sounds good; I can submit patches for that but I think I'll do that once we
have the %p4cc modifier in.

-- 
Regards,

Sakari Ailus

Re: [PATCH v6 3/3] drm/fourcc: Switch to %p4cc format modifier

[Sakari Ailus]

Hi Daniel,

Thanks for the comments.

On Tue, Feb 09, 2021 at 08:27:10AM +0100, Daniel Vetter wrote:
> On Mon, Feb 8, 2021 at 9:20 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > Instead of constructing the FourCC code manually, use the %p4cc printk
> > modifier to print it. Also leave a message to avoid using this function.
> >
> > The next step would be to convert the users to use %p4cc directly instead
> > and removing the function.
> >
> > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > ---
> >  drivers/gpu/drm/drm_fourcc.c | 16 +++-------------
> >  1 file changed, 3 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index 03262472059c..4ff40f2f27c0 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -30,11 +30,6 @@
> >  #include <drm/drm_device.h>
> >  #include <drm/drm_fourcc.h>
> >
> > -static char printable_char(int c)
> > -{
> > -       return isascii(c) && isprint(c) ? c : '?';
> > -}
> > -
> >  /**
> >   * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description
> >   * @bpp: bits per pixels
> > @@ -134,17 +129,12 @@ EXPORT_SYMBOL(drm_driver_legacy_fb_format);
> >   * drm_get_format_name - fill a string with a drm fourcc format's name
> >   * @format: format to compute name of
> >   * @buf: caller-supplied buffer
> > + *
> > + * Please use %p4cc printk format modifier instead of this function.
> 
> I think would be nice if we could roll this out and outright delete
> this one here ... Quick git grep says there's not that many, and %p4cc
> is quite a bit shorter than what we have now.

Sounds good; I can submit patches for that but I think I'll do that once we
have the %p4cc modifier in.

-- 
Regards,

Sakari Ailus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Sakari Ailus]

Hi Andy,

On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> 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).

The spaces are expected to be at the end only. I can add such example if
you like. There are no fourcc codes with spaces in the middle in neither
V4L2 nor DRM, and I don't think the expectation is to have them either.

> 
> ...
> 
> > +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).

Earlier in the review it was proposed that special handling of codes below
32 should be added, which I did. Using the parentheses is apparently an
existing practice elsewhere.

Note that neither DRM nor V4L2 currently has such fourcc codes currently.

> 
> > +       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?

The existing instances of printing fourcc codes in V4L2 are scattered
around with priority on implementation simplicity. As we have a single
simplementation here, I'm not really worried about that.

> 
> > +               /* 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).

Sure, you can do that, and I can then review your patch and point to the
coding style documentation. :-)

> 
> > +       *p++ = ')';
> > +       *p = '\0';
> > +
> > +       return string(buf, end, output, spec);
> > +}
> 

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Sakari Ailus]

Hi Andy,

On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> 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).

The spaces are expected to be at the end only. I can add such example if
you like. There are no fourcc codes with spaces in the middle in neither
V4L2 nor DRM, and I don't think the expectation is to have them either.

> 
> ...
> 
> > +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).

Earlier in the review it was proposed that special handling of codes below
32 should be added, which I did. Using the parentheses is apparently an
existing practice elsewhere.

Note that neither DRM nor V4L2 currently has such fourcc codes currently.

> 
> > +       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?

The existing instances of printing fourcc codes in V4L2 are scattered
around with priority on implementation simplicity. As we have a single
simplementation here, I'm not really worried about that.

> 
> > +               /* 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).

Sure, you can do that, and I can then review your patch and point to the
coding style documentation. :-)

> 
> > +       *p++ = ')';
> > +       *p = '\0';
> > +
> > +       return string(buf, end, output, spec);
> > +}
> 

-- 
Kind regards,

Sakari Ailus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Andy Shevchenko]

On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
> On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:

...

> > > +       %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).
> 
> The spaces are expected to be at the end only. I can add such example if
> you like. There are no fourcc codes with spaces in the middle in neither
> V4L2 nor DRM, and I don't think the expectation is to have them either.

But then the code suggests otherwise. Perhaps we need to extract
skip_trailing_spaces() from strim() and use it here.

...

> > > +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).
> 
> Earlier in the review it was proposed that special handling of codes below
> 32 should be added, which I did. Using the parentheses is apparently an
> existing practice elsewhere.

Where? \xHH is quite well established format for escaping. Never heard about
'(xx)' variant before this very series.

> Note that neither DRM nor V4L2 currently has such fourcc codes currently.

...

> > > +       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).
> 
> Sure, you can do that, and I can then review your patch and point to the
> coding style documentation. :-)

Yes, you can. The problem is that we agreed with others to improve readability
by letting some lines to be longer, so the code can lie on one line rather be
broken on two or more.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Andy Shevchenko]

On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
> On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:

...

> > > +       %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).
> 
> The spaces are expected to be at the end only. I can add such example if
> you like. There are no fourcc codes with spaces in the middle in neither
> V4L2 nor DRM, and I don't think the expectation is to have them either.

But then the code suggests otherwise. Perhaps we need to extract
skip_trailing_spaces() from strim() and use it here.

...

> > > +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).
> 
> Earlier in the review it was proposed that special handling of codes below
> 32 should be added, which I did. Using the parentheses is apparently an
> existing practice elsewhere.

Where? \xHH is quite well established format for escaping. Never heard about
'(xx)' variant before this very series.

> Note that neither DRM nor V4L2 currently has such fourcc codes currently.

...

> > > +       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).
> 
> Sure, you can do that, and I can then review your patch and point to the
> coding style documentation. :-)

Yes, you can. The problem is that we agreed with others to improve readability
by letting some lines to be longer, so the code can lie on one line rather be
broken on two or more.

-- 
With Best Regards,
Andy Shevchenko


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Andy Shevchenko]

On Mon, Feb 08, 2021 at 10:58:55PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:

...

> __le32 val;
> 
> val = cpu_to_le32(*fourcc & ~BIT(31));
> 
> p += string_escape_mem(&val, sizeof(*fourcc), output, sizeof(output), ESCAPE_NP | ESCAPE_HEX, NULL);

sizeof(val) and as we are discussing in parallel emails something like
skip_trailing_spaces() to be applied after above.

The rationale of the above, that we reuse existing code and existing standard
for the escaping non-printable characters.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Andy Shevchenko]

On Mon, Feb 08, 2021 at 10:58:55PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:

...

> __le32 val;
> 
> val = cpu_to_le32(*fourcc & ~BIT(31));
> 
> p += string_escape_mem(&val, sizeof(*fourcc), output, sizeof(output), ESCAPE_NP | ESCAPE_HEX, NULL);

sizeof(val) and as we are discussing in parallel emails something like
skip_trailing_spaces() to be applied after above.

The rationale of the above, that we reuse existing code and existing standard
for the escaping non-printable characters.

-- 
With Best Regards,
Andy Shevchenko


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Sakari Ailus]

Hi Andy,

On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
> On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
> > On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > > On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> > > <sakari.ailus@linux.intel.com> wrote:
> 
> ...
> 
> > > > +       %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).
> > 
> > The spaces are expected to be at the end only. I can add such example if
> > you like. There are no fourcc codes with spaces in the middle in neither
> > V4L2 nor DRM, and I don't think the expectation is to have them either.
> 
> But then the code suggests otherwise. Perhaps we need to extract
> skip_trailing_spaces() from strim() and use it here.

But this wouldn't affect the result in this case, would it?

> 
> ...
> 
> > > > +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).
> > 
> > Earlier in the review it was proposed that special handling of codes below
> > 32 should be added, which I did. Using the parentheses is apparently an
> > existing practice elsewhere.
> 
> Where? \xHH is quite well established format for escaping. Never heard about
> '(xx)' variant before this very series.

Mauro referred to FourCC codes while reviewing an earlier version of this,
such as RGB(15).

Does \× imply only the next two characters are hexadecimal? I have to admit
I don't remember seeting that, nor \x notation is common.

> 
> > Note that neither DRM nor V4L2 currently has such fourcc codes currently.
> 
> ...
> 
> > > > +       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).
> > 
> > Sure, you can do that, and I can then review your patch and point to the
> > coding style documentation. :-)
> 
> Yes, you can. The problem is that we agreed with others to improve readability
> by letting some lines to be longer, so the code can lie on one line rather be
> broken on two or more.

Making the end of the line invisible without scrolling vertically doesn't
improve readability for me. It does depend on window width though. I'd
simply only use that if 80 isn't enough.

-- 
Regards,

Sakari Ailus

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Sakari Ailus]

Hi Andy,

On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
> On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
> > On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > > On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> > > <sakari.ailus@linux.intel.com> wrote:
> 
> ...
> 
> > > > +       %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).
> > 
> > The spaces are expected to be at the end only. I can add such example if
> > you like. There are no fourcc codes with spaces in the middle in neither
> > V4L2 nor DRM, and I don't think the expectation is to have them either.
> 
> But then the code suggests otherwise. Perhaps we need to extract
> skip_trailing_spaces() from strim() and use it here.

But this wouldn't affect the result in this case, would it?

> 
> ...
> 
> > > > +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).
> > 
> > Earlier in the review it was proposed that special handling of codes below
> > 32 should be added, which I did. Using the parentheses is apparently an
> > existing practice elsewhere.
> 
> Where? \xHH is quite well established format for escaping. Never heard about
> '(xx)' variant before this very series.

Mauro referred to FourCC codes while reviewing an earlier version of this,
such as RGB(15).

Does \× imply only the next two characters are hexadecimal? I have to admit
I don't remember seeting that, nor \x notation is common.

> 
> > Note that neither DRM nor V4L2 currently has such fourcc codes currently.
> 
> ...
> 
> > > > +       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).
> > 
> > Sure, you can do that, and I can then review your patch and point to the
> > coding style documentation. :-)
> 
> Yes, you can. The problem is that we agreed with others to improve readability
> by letting some lines to be longer, so the code can lie on one line rather be
> broken on two or more.

Making the end of the line invisible without scrolling vertically doesn't
improve readability for me. It does depend on window width though. I'd
simply only use that if 80 isn't enough.

-- 
Regards,

Sakari Ailus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes

[Petr Mladek]

On Mon 2021-02-08 22:09:02, Sakari Ailus wrote:
> Now that we can print FourCC codes directly using printk, make use of the
> feature in V4L2 core.
> 
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 85 +++++++---------------------
>  1 file changed, 21 insertions(+), 64 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 31d1342e61e8..31662c3a8c9e 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -265,13 +265,9 @@ static void v4l_print_fmtdesc(const void *arg, bool write_only)
>  {
>  	const struct v4l2_fmtdesc *p = arg;
>  
> -	pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%c%c%c%c, mbus_code=0x%04x, description='%.*s'\n",
> +	pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%p4cc, mbus_code=0x%04x, description='%.*s'\n",

Is %p4cc really acceptable here?

The original code printed only the 4 characters. The original code
would print something like:

  index=21, type=bla, flags=0x0, pixelformat=BG12, mbus_code=0x0a9f, descrition="bla bla bla"

while the new code will do:

  index=21, type=bla, flags=0x0, pixelformat=BG12 little-endian (0x32314742), mbus_code=0x0a9f, descrition="bla bla bla"

This is much harder to parse because there are spaces also inside pixel_format=<value>



>  		p->index, prt_names(p->type, v4l2_type_names),
> -		p->flags, (p->pixelformat & 0xff),
> -		(p->pixelformat >>  8) & 0xff,
> -		(p->pixelformat >> 16) & 0xff,
> -		(p->pixelformat >> 24) & 0xff,
> -		p->mbus_code,
> +		p->flags, &p->pixelformat, p->mbus_code,
>  		(int)sizeof(p->description), p->description);
>  }
>  

Best Regards,
Petr

Re: [PATCH v6 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes

[Petr Mladek]

On Mon 2021-02-08 22:09:02, Sakari Ailus wrote:
> Now that we can print FourCC codes directly using printk, make use of the
> feature in V4L2 core.
> 
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 85 +++++++---------------------
>  1 file changed, 21 insertions(+), 64 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 31d1342e61e8..31662c3a8c9e 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -265,13 +265,9 @@ static void v4l_print_fmtdesc(const void *arg, bool write_only)
>  {
>  	const struct v4l2_fmtdesc *p = arg;
>  
> -	pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%c%c%c%c, mbus_code=0x%04x, description='%.*s'\n",
> +	pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%p4cc, mbus_code=0x%04x, description='%.*s'\n",

Is %p4cc really acceptable here?

The original code printed only the 4 characters. The original code
would print something like:

  index=21, type=bla, flags=0x0, pixelformat=BG12, mbus_code=0x0a9f, descrition="bla bla bla"

while the new code will do:

  index=21, type=bla, flags=0x0, pixelformat=BG12 little-endian (0x32314742), mbus_code=0x0a9f, descrition="bla bla bla"

This is much harder to parse because there are spaces also inside pixel_format=<value>



>  		p->index, prt_names(p->type, v4l2_type_names),
> -		p->flags, (p->pixelformat & 0xff),
> -		(p->pixelformat >>  8) & 0xff,
> -		(p->pixelformat >> 16) & 0xff,
> -		(p->pixelformat >> 24) & 0xff,
> -		p->mbus_code,
> +		p->flags, &p->pixelformat, p->mbus_code,
>  		(int)sizeof(p->description), p->description);
>  }
>  

Best Regards,
Petr
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Petr Mladek]

On Tue 2021-02-09 19:47:55, Sakari Ailus wrote:
> Hi Andy,
> 
> On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
> > On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
> > > On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> > > > <sakari.ailus@linux.intel.com> wrote:
> > 
> > ...
> > 
> > > > > +       %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).
> > > 
> > > The spaces are expected to be at the end only. I can add such example if
> > > you like. There are no fourcc codes with spaces in the middle in neither
> > > V4L2 nor DRM, and I don't think the expectation is to have them either.
> > 
> > But then the code suggests otherwise. Perhaps we need to extract
> > skip_trailing_spaces() from strim() and use it here.
> 
> But this wouldn't affect the result in this case, would it?

Is there any existing implementation that would skip spaces, please?

IMHO, this might just hide problems. We should show exactly what
is stored unless anyone explicitly ask for skipping that spaces.

> > 
> > ...
> > 
> > > > > +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).
> > > 
> > > Earlier in the review it was proposed that special handling of codes below
> > > 32 should be added, which I did. Using the parentheses is apparently an
> > > existing practice elsewhere.
> > 
> > Where? \xHH is quite well established format for escaping. Never heard about
> > '(xx)' variant before this very series.

> Mauro referred to FourCC codes while reviewing an earlier version of this,
> such as RGB(15).

This is quite easy to parse. The problem is that it is not clear
whether it is hexa or decimal number.

> Does \× imply only the next two characters are hexadecimal? I have to admit
> I don't remember seeting that, nor \x notation is common.

Hmm, the /xyy format might be hard to parse.

What about using the same approach as drm_get_format_name()?
I mean printing '?' when the character is not printable.
The exact value is printed later anyway.

The advantage is that it will always printk 4 characters.


> > > Note that neither DRM nor V4L2 currently has such fourcc codes currently.
> > 
> > ...
> > 
> > > > > +       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).

Ailus, please do not take this as a criticism of your patch.
I understand that it might have sounded like this but Andy did
not mean it.

Andy prefers slightly longer lines over wrapping only few characters.
It makes sense to me. There are more people with the same opinion.
Even checkpatch.pl tolerates lines up to 100 characters these days.

Of course, this is a subsystem specific preference. You did not have
any chance to know it. There is no need to fight over it.

Best Regards,
Petr

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Petr Mladek]

On Tue 2021-02-09 19:47:55, Sakari Ailus wrote:
> Hi Andy,
> 
> On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
> > On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
> > > On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> > > > <sakari.ailus@linux.intel.com> wrote:
> > 
> > ...
> > 
> > > > > +       %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).
> > > 
> > > The spaces are expected to be at the end only. I can add such example if
> > > you like. There are no fourcc codes with spaces in the middle in neither
> > > V4L2 nor DRM, and I don't think the expectation is to have them either.
> > 
> > But then the code suggests otherwise. Perhaps we need to extract
> > skip_trailing_spaces() from strim() and use it here.
> 
> But this wouldn't affect the result in this case, would it?

Is there any existing implementation that would skip spaces, please?

IMHO, this might just hide problems. We should show exactly what
is stored unless anyone explicitly ask for skipping that spaces.

> > 
> > ...
> > 
> > > > > +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).
> > > 
> > > Earlier in the review it was proposed that special handling of codes below
> > > 32 should be added, which I did. Using the parentheses is apparently an
> > > existing practice elsewhere.
> > 
> > Where? \xHH is quite well established format for escaping. Never heard about
> > '(xx)' variant before this very series.

> Mauro referred to FourCC codes while reviewing an earlier version of this,
> such as RGB(15).

This is quite easy to parse. The problem is that it is not clear
whether it is hexa or decimal number.

> Does \× imply only the next two characters are hexadecimal? I have to admit
> I don't remember seeting that, nor \x notation is common.

Hmm, the /xyy format might be hard to parse.

What about using the same approach as drm_get_format_name()?
I mean printing '?' when the character is not printable.
The exact value is printed later anyway.

The advantage is that it will always printk 4 characters.


> > > Note that neither DRM nor V4L2 currently has such fourcc codes currently.
> > 
> > ...
> > 
> > > > > +       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).

Ailus, please do not take this as a criticism of your patch.
I understand that it might have sounded like this but Andy did
not mean it.

Andy prefers slightly longer lines over wrapping only few characters.
It makes sense to me. There are more people with the same opinion.
Even checkpatch.pl tolerates lines up to 100 characters these days.

Of course, this is a subsystem specific preference. You did not have
any chance to know it. There is no need to fight over it.

Best Regards,
Petr
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes

[Sakari Ailus]

Hi Petr,

On Thu, Feb 11, 2021 at 05:31:46PM +0100, Petr Mladek wrote:
> On Mon 2021-02-08 22:09:02, Sakari Ailus wrote:
> > Now that we can print FourCC codes directly using printk, make use of the
> > feature in V4L2 core.
> > 
> > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > ---
> >  drivers/media/v4l2-core/v4l2-ioctl.c | 85 +++++++---------------------
> >  1 file changed, 21 insertions(+), 64 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 31d1342e61e8..31662c3a8c9e 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -265,13 +265,9 @@ static void v4l_print_fmtdesc(const void *arg, bool write_only)
> >  {
> >  	const struct v4l2_fmtdesc *p = arg;
> >  
> > -	pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%c%c%c%c, mbus_code=0x%04x, description='%.*s'\n",
> > +	pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%p4cc, mbus_code=0x%04x, description='%.*s'\n",
> 
> Is %p4cc really acceptable here?
> 
> The original code printed only the 4 characters. The original code
> would print something like:
> 
>   index=21, type=bla, flags=0x0, pixelformat=BG12, mbus_code=0x0a9f, descrition="bla bla bla"
> 
> while the new code will do:
> 
>   index=21, type=bla, flags=0x0, pixelformat=BG12 little-endian (0x32314742), mbus_code=0x0a9f, descrition="bla bla bla"
> 
> This is much harder to parse because there are spaces also inside
> pixel_format=<value>

Note that also the fourcc code itself could contains spaces so that's not
new.

The fourcc (debug) form is now one and the same for V4L2 and DRM, but I
guess nothing would prevent adding a shorter form if needed. This is not
continuously happening during streaming so this is also not performance
critical in any way. The fourcc code was used to be printed this way here
mainly because it was, well, easy to do for "just" debugging purposes.

Hans, any opinion?

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v6 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes

[Sakari Ailus]

Hi Petr,

On Thu, Feb 11, 2021 at 05:31:46PM +0100, Petr Mladek wrote:
> On Mon 2021-02-08 22:09:02, Sakari Ailus wrote:
> > Now that we can print FourCC codes directly using printk, make use of the
> > feature in V4L2 core.
> > 
> > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > ---
> >  drivers/media/v4l2-core/v4l2-ioctl.c | 85 +++++++---------------------
> >  1 file changed, 21 insertions(+), 64 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 31d1342e61e8..31662c3a8c9e 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -265,13 +265,9 @@ static void v4l_print_fmtdesc(const void *arg, bool write_only)
> >  {
> >  	const struct v4l2_fmtdesc *p = arg;
> >  
> > -	pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%c%c%c%c, mbus_code=0x%04x, description='%.*s'\n",
> > +	pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%p4cc, mbus_code=0x%04x, description='%.*s'\n",
> 
> Is %p4cc really acceptable here?
> 
> The original code printed only the 4 characters. The original code
> would print something like:
> 
>   index=21, type=bla, flags=0x0, pixelformat=BG12, mbus_code=0x0a9f, descrition="bla bla bla"
> 
> while the new code will do:
> 
>   index=21, type=bla, flags=0x0, pixelformat=BG12 little-endian (0x32314742), mbus_code=0x0a9f, descrition="bla bla bla"
> 
> This is much harder to parse because there are spaces also inside
> pixel_format=<value>

Note that also the fourcc code itself could contains spaces so that's not
new.

The fourcc (debug) form is now one and the same for V4L2 and DRM, but I
guess nothing would prevent adding a shorter form if needed. This is not
continuously happening during streaming so this is also not performance
critical in any way. The fourcc code was used to be printed this way here
mainly because it was, well, easy to do for "just" debugging purposes.

Hans, any opinion?

-- 
Kind regards,

Sakari Ailus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Sakari Ailus]

Hi Petr,

Thanks for the comments.

On Thu, Feb 11, 2021 at 06:14:28PM +0100, Petr Mladek wrote:
> On Tue 2021-02-09 19:47:55, Sakari Ailus wrote:
> > Hi Andy,
> > 
> > On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
> > > On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
> > > > On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > > > > On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> > > > > <sakari.ailus@linux.intel.com> wrote:
> > > 
> > > ...
> > > 
> > > > > > +       %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).
> > > > 
> > > > The spaces are expected to be at the end only. I can add such example if
> > > > you like. There are no fourcc codes with spaces in the middle in neither
> > > > V4L2 nor DRM, and I don't think the expectation is to have them either.
> > > 
> > > But then the code suggests otherwise. Perhaps we need to extract
> > > skip_trailing_spaces() from strim() and use it here.
> > 
> > But this wouldn't affect the result in this case, would it?
> 
> Is there any existing implementation that would skip spaces, please?
> 
> IMHO, this might just hide problems. We should show exactly what
> is stored unless anyone explicitly ask for skipping that spaces.

I discussed this with Hans and we concluded spaces shouldn't be dropped.

Spaces can be present in the codes themselves in any case.

> 
> > > 
> > > ...
> > > 
> > > > > > +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).
> > > > 
> > > > Earlier in the review it was proposed that special handling of codes below
> > > > 32 should be added, which I did. Using the parentheses is apparently an
> > > > existing practice elsewhere.
> > > 
> > > Where? \xHH is quite well established format for escaping. Never heard about
> > > '(xx)' variant before this very series.
> 
> > Mauro referred to FourCC codes while reviewing an earlier version of this,
> > such as RGB(15).
> 
> This is quite easy to parse. The problem is that it is not clear
> whether it is hexa or decimal number.
> 
> > Does \× imply only the next two characters are hexadecimal? I have to admit
> > I don't remember seeting that, nor \x notation is common.
> 
> Hmm, the /xyy format might be hard to parse.
> 
> What about using the same approach as drm_get_format_name()?
> I mean printing '?' when the character is not printable.
> The exact value is printed later anyway.
> 
> The advantage is that it will always printk 4 characters.

"?" can be expanded by the shell. We (me and Hans) both though a dot (".")
would be good. These aren't going to be present in valid fourcc codes in
any case.

> 
> 
> > > > Note that neither DRM nor V4L2 currently has such fourcc codes currently.
> > > 
> > > ...
> > > 
> > > > > > +       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).
> 
> Ailus, please do not take this as a criticism of your patch.
> I understand that it might have sounded like this but Andy did
> not mean it.
> 
> Andy prefers slightly longer lines over wrapping only few characters.
> It makes sense to me. There are more people with the same opinion.
> Even checkpatch.pl tolerates lines up to 100 characters these days.
> 
> Of course, this is a subsystem specific preference. You did not have
> any chance to know it. There is no need to fight over it.

Fair enough; I can violate the coding style a little in v7.

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Sakari Ailus]

Hi Petr,

Thanks for the comments.

On Thu, Feb 11, 2021 at 06:14:28PM +0100, Petr Mladek wrote:
> On Tue 2021-02-09 19:47:55, Sakari Ailus wrote:
> > Hi Andy,
> > 
> > On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
> > > On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
> > > > On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > > > > On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> > > > > <sakari.ailus@linux.intel.com> wrote:
> > > 
> > > ...
> > > 
> > > > > > +       %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).
> > > > 
> > > > The spaces are expected to be at the end only. I can add such example if
> > > > you like. There are no fourcc codes with spaces in the middle in neither
> > > > V4L2 nor DRM, and I don't think the expectation is to have them either.
> > > 
> > > But then the code suggests otherwise. Perhaps we need to extract
> > > skip_trailing_spaces() from strim() and use it here.
> > 
> > But this wouldn't affect the result in this case, would it?
> 
> Is there any existing implementation that would skip spaces, please?
> 
> IMHO, this might just hide problems. We should show exactly what
> is stored unless anyone explicitly ask for skipping that spaces.

I discussed this with Hans and we concluded spaces shouldn't be dropped.

Spaces can be present in the codes themselves in any case.

> 
> > > 
> > > ...
> > > 
> > > > > > +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).
> > > > 
> > > > Earlier in the review it was proposed that special handling of codes below
> > > > 32 should be added, which I did. Using the parentheses is apparently an
> > > > existing practice elsewhere.
> > > 
> > > Where? \xHH is quite well established format for escaping. Never heard about
> > > '(xx)' variant before this very series.
> 
> > Mauro referred to FourCC codes while reviewing an earlier version of this,
> > such as RGB(15).
> 
> This is quite easy to parse. The problem is that it is not clear
> whether it is hexa or decimal number.
> 
> > Does \× imply only the next two characters are hexadecimal? I have to admit
> > I don't remember seeting that, nor \x notation is common.
> 
> Hmm, the /xyy format might be hard to parse.
> 
> What about using the same approach as drm_get_format_name()?
> I mean printing '?' when the character is not printable.
> The exact value is printed later anyway.
> 
> The advantage is that it will always printk 4 characters.

"?" can be expanded by the shell. We (me and Hans) both though a dot (".")
would be good. These aren't going to be present in valid fourcc codes in
any case.

> 
> 
> > > > Note that neither DRM nor V4L2 currently has such fourcc codes currently.
> > > 
> > > ...
> > > 
> > > > > > +       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).
> 
> Ailus, please do not take this as a criticism of your patch.
> I understand that it might have sounded like this but Andy did
> not mean it.
> 
> Andy prefers slightly longer lines over wrapping only few characters.
> It makes sense to me. There are more people with the same opinion.
> Even checkpatch.pl tolerates lines up to 100 characters these days.
> 
> Of course, this is a subsystem specific preference. You did not have
> any chance to know it. There is no need to fight over it.

Fair enough; I can violate the coding style a little in v7.

-- 
Kind regards,

Sakari Ailus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Petr Mladek]

On Fri 2021-02-12 13:28:56, Sakari Ailus wrote:
> On Thu, Feb 11, 2021 at 06:14:28PM +0100, Petr Mladek wrote:
> > On Tue 2021-02-09 19:47:55, Sakari Ailus wrote:
> > > Hi Andy,
> > > 
> > > On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
> > > > On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
> > > > > On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > > > > > On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> > > > > > <sakari.ailus@linux.intel.com> wrote:
> > > > 
> > > > > > > +       %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).
> 
> I discussed this with Hans and we concluded spaces shouldn't be dropped.
> 
> Spaces can be present in the codes themselves in any case.

Great!

> > 
> > > > 
> > > > ...
> > > > 
> > > > > > > +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).
> > > > > 
> > > > > Earlier in the review it was proposed that special handling of codes below
> > > > > 32 should be added, which I did. Using the parentheses is apparently an
> > > > > existing practice elsewhere.
> > > > 
> > > > Where? \xHH is quite well established format for escaping. Never heard about
> > > > '(xx)' variant before this very series.
> > 
> > What about using the same approach as drm_get_format_name()?
> > I mean printing '?' when the character is not printable.
> > The exact value is printed later anyway.
> > 
> > The advantage is that it will always printk 4 characters.
> 
> "?" can be expanded by the shell. We (me and Hans) both though a dot (".")
> would be good. These aren't going to be present in valid fourcc codes in
> any case.

The dot (".") looks fine to me.

Best Regards,
Petr

Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Petr Mladek]

On Fri 2021-02-12 13:28:56, Sakari Ailus wrote:
> On Thu, Feb 11, 2021 at 06:14:28PM +0100, Petr Mladek wrote:
> > On Tue 2021-02-09 19:47:55, Sakari Ailus wrote:
> > > Hi Andy,
> > > 
> > > On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
> > > > On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
> > > > > On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > > > > > On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> > > > > > <sakari.ailus@linux.intel.com> wrote:
> > > > 
> > > > > > > +       %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).
> 
> I discussed this with Hans and we concluded spaces shouldn't be dropped.
> 
> Spaces can be present in the codes themselves in any case.

Great!

> > 
> > > > 
> > > > ...
> > > > 
> > > > > > > +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).
> > > > > 
> > > > > Earlier in the review it was proposed that special handling of codes below
> > > > > 32 should be added, which I did. Using the parentheses is apparently an
> > > > > existing practice elsewhere.
> > > > 
> > > > Where? \xHH is quite well established format for escaping. Never heard about
> > > > '(xx)' variant before this very series.
> > 
> > What about using the same approach as drm_get_format_name()?
> > I mean printing '?' when the character is not printable.
> > The exact value is printed later anyway.
> > 
> > The advantage is that it will always printk 4 characters.
> 
> "?" can be expanded by the shell. We (me and Hans) both though a dot (".")
> would be good. These aren't going to be present in valid fourcc codes in
> any case.

The dot (".") looks fine to me.

Best Regards,
Petr
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel