linux-kernel - Re: [PATCH v5 2/2] media: i2c: Pinefeat cef168 lens control board driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20251006204635.17501-1-asmirnou@pinefeat.co.uk>
Date: Mon,  6 Oct 2025 21:46:35 +0100
From: Aliaksandr Smirnou <asmirnou@...efeat.co.uk>
To: kieran.bingham@...asonboard.com
Cc: asmirnou@...efeat.co.uk,
	conor+dt@...nel.org,
	devicetree@...r.kernel.org,
	hverkuil@...all.nl,
	jacopo.mondi@...asonboard.com,
	krzk+dt@...nel.org,
	linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org,
	mchehab@...nel.org,
	robh@...nel.org
Subject: Re: [PATCH v5 2/2] media: i2c: Pinefeat cef168 lens control board driver

On Sun, 05 Oct 2025 20:58:36 +0100, Kieran Bingham wrote:

> > The focus distance reported by the lens is the distance between the
> > camera's sensor and the subject currently in focus, measured in meters.
> > It correlates with the focus position - higher positions correspond to
> > greater distances - but the relationship is non-linear.
> 
> What's measuring this distance ? Something in the lens, rather than the
> sensor?

It doesn't actively measure the distance. The lens contains a distance
encoder that maps motor steps to an approximate focus distance, calibrated
for that lens model/type at the factory.

> > the Linux V4L2 API does not allow the minimum and
> > maximum values to be changed while the driver is running.
> 
> Have you tried with __v4l2_ctrl_modify_range() ?
> 
> We should make sure this also generates an event that libcamera can
> subscribe to to make sure it knows there's been an update.

Thanks. The unlocked variant of this function works. Previously I tried
its locked variant that led to locking issues, that's why I though it
is not possible.

I'll use that approach and get rid of the custom control.

> I see, so a user interaction can update it too. Does the driver have to
> poll to get this update? Or does it just find out on the next read ?  

The driver reads all lens data at once, so it knows the focus range on
the next read. 

I hope it is ok to modify the focus range straight in g_volatile_ctrl,
when the focus value is requested and read from the lens.

> We're also pushing for a core control for this I think. That's something
> we 'need' in libcamera globally for all cameras. Unfortunately I can't
> point you at an existing control yet ;-(

Good to know. Then for now, I'll keep the custom control for the lens ID,
and switch to a common one once it becomes available.

One suggestion was to use the device name to store the lens ID, but I
couldn't find a way to modify the name after probe, since the lens might
be disconnected and replaced with another. Also, for I2C devices, the
device name appears to be assigned by the kernel.

> I'll see if I can find time to order a kit, and get a compatible lens. I
> have a Nikon DSLR though so I don't have lenses to match this yet :-(

We will be happy to provide a product sample for free, just let us know
the delivery address by email.