lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20251021124121.93907-1-isaac.scott@ideasonboard.com>
Date: Tue, 21 Oct 2025 13:41:21 +0100
From: Isaac Scott <isaac.scott@...asonboard.com>
To: mchehab@...nel.org
Cc: laurent.pinchart@...asonboard.com,
	sakari.ailus@...ux.intel.com,
	david.plowman@...pberrypi.com,
	naush@...pberrypi.com,
	kieran.bingham@...asonboard.com,
	linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Isaac Scott <isaac.scott@...asonboard.com>
Subject: [PATCH] v4l: controls: Add v4l2 control to store camera module identifier

Add a new v4l2 control ID that would be used by drivers to store a
string representing a SKU or other vendor-specific camera module
identifier. This would be used to tell user space which specific type of
camera module is present in the system.

Signed-off-by: Isaac Scott <isaac.scott@...asonboard.com>

---

Hi all,

This patch builds on the discussion here:

https://lore.kernel.org/all/20250507081338.53614-1-sakari.ailus@linux.intel.com/

regarding the need to be able to identify camera modules. This is useful
when modules need to use the base driver of the camera sensor they
include, but need adjustments to account for different module features.

The driver, or potentially core v4l2, would be responsible for setting
this as a read-only control containing the SKU, or a vendor-specific
identifier for a camera module.

A SKU is expected to cover the sensor (found in the compatible string),
as well as the lens / packaging. For example, Raspberry Pi produce an
IMX708 camera module with several variations; a lot of code duplication
could be avoided in user space applications if a camera module
identifier was available.

These could be expressed through the SKU instead of variations of the
compatible string.

This would allow user space programs, such as libcamera, to select
different configurations specific to that module to account for
differences in lens characteristics, different CCMs, and more.

Tested on media/next

Best wishes,

Isaac
---
 include/uapi/linux/v4l2-controls.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 2d30107e047e..39267bdd5286 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -1102,6 +1102,8 @@ enum v4l2_auto_focus_range {
 
 #define V4L2_CID_HDR_SENSOR_MODE		(V4L2_CID_CAMERA_CLASS_BASE+36)
 
+#define V4L2_CID_CAMERA_MODULE_IDENTIFIER	(V4L2_CID_CAMERA_CLASS_BASE+37)
+
 /* FM Modulator class control IDs */
 
 #define V4L2_CID_FM_TX_CLASS_BASE		(V4L2_CTRL_CLASS_FM_TX | 0x900)
-- 
2.43.0


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ