[PATCH 0/3] media: ak7375: Add AK7377 support

[PATCH 0/3] media: ak7375: Add AK7377 support

[Jan-Michael Brummer]

The AK7377 drives the focus actuator of the main camera on the Fairphone
5, and is register compatible with the AK7375 already supported by this
driver: a 12 bit position in registers 0x00/0x01 shifted left by four,
and standby control in 0x02.  Patches 1 and 2 add the binding and the
compatible.

Patch 3 is a fix that is independent of the above and applies to every
user of this driver.  probe() calls pm_runtime_set_active() while the
regulators are still off, so the first runtime transition is a suspend
against an unpowered chip; it fails its I2C writes and then disables
regulators that were never enabled.  On the Fairphone 5 that showed up
as an -ENXIO from the first resume, after which focus control stayed
dead for the whole session even though the actuator answered fine on the
bus, and as a WARN from regulator_bulk_free() on unbind.

I can send patch 3 on its own if that is easier to route - it does not
depend on the other two.

Testing: the AK7377 on a Fairphone 5, driving the lens across its range
and checking that the image comes into focus, with an out-of-tree IMX800
sensor driver.  I have no AK7345 or AK7375 hardware, so patch 3 is
untested on those; the change moves the first runtime resume from probe
to the first focus request, and confirmation that this does not regress
them would be welcome.

Jan-Michael Brummer (3):
  media: dt-bindings: ak7375: Add AK7377
  media: i2c: ak7375: Add support for the AK7377
  media: i2c: ak7375: Do not mark the VCM active before powering it

 .../bindings/media/i2c/asahi-kasei,ak7375.yaml |  1 +
 drivers/media/i2c/ak7375.c                     | 45 ++++++++++++++++---
 2 files changed, 41 insertions(+), 5 deletions(-)

-- 
2.51.0

[PATCH] media: dt-bindings: ak7375: Add AK7377

[Jan-Michael Brummer]

The AK7377 is register compatible with the AK7375 and is driven by the
same driver.

Signed-off-by: Jan-Michael Brummer <jan.brummer@tabos.org>
---
 .../devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml        | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml b/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml
index fe312cc..c040757 100644
--- a/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml
@@ -18,6 +18,7 @@ properties:
     enum:
       - asahi-kasei,ak7345
       - asahi-kasei,ak7375
+      - asahi-kasei,ak7377
 
   reg:
     maxItems: 1

[PATCH 1/2] media: i2c: ak7375: Add support for the AK7377

[Jan-Michael Brummer]

The AK7377 drives the focus actuator of the main camera on the Fairphone
5.  It uses the same register layout as the AK7375: a 12 bit position in
registers 0x00/0x01 shifted left by four, and standby control in 0x02.
Confirmed on hardware by driving the lens across its range.

Signed-off-by: Jan-Michael Brummer <jan.brummer@tabos.org>
---
 drivers/media/i2c/ak7375.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ak7375.c b/drivers/media/i2c/ak7375.c
index 9a2432c..4f311c4 100644
--- a/drivers/media/i2c/ak7375.c
+++ b/drivers/media/i2c/ak7375.c
@@ -65,6 +65,25 @@ static const struct ak73xx_chipdef ak7375_cdef = {
 	.power_delay_us	= 10000,
 };
 
+/*
+ * The AK7377 is register compatible with the AK7375: 12 bit position in
+ * registers 0x00/0x01, standby via 0x02.  Verified on the Fairphone 5,
+ * where it drives the focus of the IMX800 main camera.
+ */
+static const struct ak73xx_chipdef ak7377_cdef = {
+	.reg_position	= 0x0,
+	.reg_cont	= 0x2,
+	.shift_pos	= 4,	/* 12 bits position values, need to << 4 */
+	.mode_active	= 0x0,
+	.mode_standby	= 0x40,
+	.has_standby	= true,
+	.focus_pos_max	= 4095,
+	.focus_steps	= 1,
+	.ctrl_steps	= 64,
+	.ctrl_delay_us	= 1000,
+	.power_delay_us	= 10000,
+};
+
 static const char * const ak7375_supply_names[] = {
 	"vdd",
 	"vio",
@@ -331,6 +350,7 @@ static int __maybe_unused ak7375_vcm_resume(struct device *dev)
 static const struct of_device_id ak7375_of_table[] = {
 	{ .compatible = "asahi-kasei,ak7345", .data = &ak7345_cdef, },
 	{ .compatible = "asahi-kasei,ak7375", .data = &ak7375_cdef, },
+	{ .compatible = "asahi-kasei,ak7377", .data = &ak7377_cdef, },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, ak7375_of_table);
@@ -353,5 +373,5 @@ module_i2c_driver(ak7375_i2c_driver);
 
 MODULE_AUTHOR("Tianshu Qiu <tian.shu.qiu@intel.com>");
 MODULE_AUTHOR("Bingbu Cao <bingbu.cao@intel.com>");
-MODULE_DESCRIPTION("AK7375 VCM driver");
+MODULE_DESCRIPTION("AK7375/AK7377 VCM driver");
 MODULE_LICENSE("GPL v2");

[PATCH 2/2] media: i2c: ak7375: Do not mark the VCM active before powering it

[Jan-Michael Brummer]

probe() calls pm_runtime_set_active() while the regulators are still
off, so runtime PM believes a powered device is present.  The following
pm_runtime_idle() runs the suspend path against an unpowered chip, which
fails its I2C writes and then calls regulator_bulk_disable() on
regulators that were never enabled - later tripping the enable/disable
balance check in regulator_bulk_free() on unbind.

Mark the device suspended instead and drop the idle call, so the first
resume happens when something actually uses the VCM.  While at it,
disable the regulators again when resume fails, which leaked an enable
count for the same reason.

Fixes: 90ee26fb2f50 ("media: ak7375: Add ak7375 lens voice coil driver")
Signed-off-by: Jan-Michael Brummer <jan.brummer@tabos.org>
---
 drivers/media/i2c/ak7375.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/ak7375.c b/drivers/media/i2c/ak7375.c
index 4f311c4..2763bbe 100644
--- a/drivers/media/i2c/ak7375.c
+++ b/drivers/media/i2c/ak7375.c
@@ -235,9 +235,12 @@ static int ak7375_probe(struct i2c_client *client)
 	if (ret < 0)
 		goto err_cleanup;
 
-	pm_runtime_set_active(&client->dev);
+	/*
+	 * The regulators are off at this point, so the device is suspended,
+	 * not active.
+	 */
+	pm_runtime_set_suspended(&client->dev);
 	pm_runtime_enable(&client->dev);
-	pm_runtime_idle(&client->dev);
 
 	return 0;
 
@@ -328,6 +331,8 @@ static int __maybe_unused ak7375_vcm_resume(struct device *dev)
 			       cdef->mode_active, 1);
 	if (ret) {
 		dev_err(dev, "%s I2C failure: %d\n", __func__, ret);
+		regulator_bulk_disable(ARRAY_SIZE(ak7375_supply_names),
+				       ak7375_dev->supplies);
 		return ret;
 	}
 

Re: [PATCH] media: dt-bindings: ak7375: Add AK7377

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing driver match for newly added compatible string 'asahi-kasei,ak7377'.
--

commit 9537c3ff68990acd9e078305609fb067fe093ae9
Author: Jan-Michael Brummer <jan.brummer@tabos.org>

media: dt-bindings: ak7375: Add AK7377

This commit updates the device tree binding for the AK7375 to include the
AK7377, which is register compatible and driven by the same driver.

> diff --git a/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml b/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml
> index fe312cc6a8731..c040757eb80c9 100644
> --- a/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml
> @@ -18,6 +18,7 @@ properties:
>      enum:
>        - asahi-kasei,ak7345
>        - asahi-kasei,ak7375
> +      - asahi-kasei,ak7377

[Severity: Medium]
Should the driver match table in drivers/media/i2c/ak7375.c also be updated
to include this new compatible string?

Currently, ak7375_of_table only lists the previous models:

static const struct of_device_id ak7375_of_table[] = {
	{ .compatible = "asahi-kasei,ak7345", .data = &ak7345_cdef, },
	{ .compatible = "asahi-kasei,ak7375", .data = &ak7375_cdef, },
	{ /* sentinel */ }
};

Without adding the new string here, won't a device declaring only
"asahi-kasei,ak7377" fail to probe because the driver lacks a matching
entry?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260829052514.18178-2-jan.brummer@tabos.org?part=1

Re: [PATCH 1/2] media: i2c: ak7375: Add support for the AK7377

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The V4L2 control handler `ak7375_set_ctrl()` performs I2C writes without checking the PM runtime state, predictably failing when the device is idle.
- [High] Potential NULL pointer dereference in `ak7375_probe()` if the device is instantiated without matching firmware data.
--

commit 26c53b3777209184aea3eb12bf84bb8a8e00a5f8
Author: Jan-Michael Brummer <jan.brummer@tabos.org>

media: i2c: ak7375: Add support for the AK7377
    
This commit adds support for the AK7377 focus actuator by defining its
register layout and adding it to the compatible table. The AK7377 drives
the focus of the main camera on the Fairphone 5.

> diff --git a/drivers/media/i2c/ak7375.c b/drivers/media/i2c/ak7375.c
> --- a/drivers/media/i2c/ak7375.c
> +++ b/drivers/media/i2c/ak7375.c

[ ... ]

> @@ -65,6 +65,25 @@ static const struct ak73xx_chipdef ak7375_cdef = {
>  	.power_delay_us	= 10000,
>  };
>  
> +/*
> + * The AK7377 is register compatible with the AK7375: 12 bit position in
> + * registers 0x00/0x01, standby via 0x02.  Verified on the Fairphone 5,
> + * where it drives the focus of the IMX800 main camera.
> + */
> +static const struct ak73xx_chipdef ak7377_cdef = {
> +	.reg_position	= 0x0,
> +	.reg_cont	= 0x2,
> +	.shift_pos	= 4,	/* 12 bits position values, need to << 4 */
> +	.mode_active	= 0x0,
> +	.mode_standby	= 0x40,
> +	.has_standby	= true,
> +	.focus_pos_max	= 4095,
> +	.focus_steps	= 1,
> +	.ctrl_steps	= 64,
> +	.ctrl_delay_us	= 1000,
> +	.power_delay_us	= 10000,
> +};
> +

[Severity: High]
This isn't a bug introduced by this patch, but does the control handler
safely handle I2C writes when the device is not actively streaming?

If userspace sets the V4L2 focus control while the camera is idle,
ak7375_set_ctrl() blindly issues an I2C write without checking the PM 
runtime state:

drivers/media/i2c/ak7375.c:ak7375_set_ctrl() {
    ...
    if (ctrl->id == V4L2_CID_FOCUS_ABSOLUTE)
        return ak7375_i2c_write(dev_vcm, cdef->reg_position,
                                ctrl->val << cdef->shift_pos, 2);
    ...
}

Without first calling pm_runtime_get_if_in_use() or similar, won't the
unpowered VCM NACK the I2C transaction? This would return an error like
-EIO to userspace and break focus initialization before streaming begins.

[ ... ]

> @@ -331,6 +350,7 @@ static int __maybe_unused ak7375_vcm_resume(struct device *dev)
>  static const struct of_device_id ak7375_of_table[] = {
>  	{ .compatible = "asahi-kasei,ak7345", .data = &ak7345_cdef, },
>  	{ .compatible = "asahi-kasei,ak7375", .data = &ak7375_cdef, },
> +	{ .compatible = "asahi-kasei,ak7377", .data = &ak7377_cdef, },
>  	{ /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(of, ak7375_of_table);

[Severity: High]
This is a pre-existing issue, but can this cause a NULL pointer dereference
if the device is instantiated without matching firmware data?

If the driver is instantiated via the I2C sysfs new_device interface or
legacy board info, there will be no corresponding OF or ACPI node. Since
the driver lacks an I2C id_table, device_get_match_data() will return NULL:

drivers/media/i2c/ak7375.c:ak7375_probe() {
    ...
    ak7375_dev->cdef = device_get_match_data(&client->dev);
    ...
    ret = ak7375_init_controls(ak7375_dev);
    ...
}

The cdef pointer is then passed into ak7375_init_controls(), which
dereferences it unconditionally:

drivers/media/i2c/ak7375.c:ak7375_init_controls() {
    ...
    dev_vcm->focus = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_ABSOLUTE,
            0, cdef->focus_pos_max, cdef->focus_steps, 0);
    ...
}

Should there be a NULL check after device_get_match_data() to prevent
local privileged users from triggering a panic via sysfs hotplugging?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260829052514.18178-1-jan.brummer@tabos.org?part=1

Re: [PATCH 2/2] media: i2c: ak7375: Do not mark the VCM active before powering it

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] The commit message incorrectly attributes a regulator leak to `pm_runtime_idle()`, which is structurally impossible.

Pre-existing issues:
- [Critical] Use-After-Free of `struct ak7375_device` on driver unbind due to `devm_kzalloc`.
--

commit a4a5fe00ce60666a1ebfccbdf63f44f93d436c10
Author: Jan-Michael Brummer <jan.brummer@tabos.org>

media: i2c: ak7375: Do not mark the VCM active before powering it

This patch replaces pm_runtime_set_active() with pm_runtime_set_suspended()
in the probe function to correctly reflect that the regulators are initially
off. It also adds a call to disable the regulators in the resume error path
to prevent leaking an enable count.

> probe() calls pm_runtime_set_active() while the regulators are still
> off, so runtime PM believes a powered device is present.  The following
> pm_runtime_idle() runs the suspend path against an unpowered chip, which
> fails its I2C writes and then calls regulator_bulk_disable() on
> regulators that were never enabled - later tripping the enable/disable
> balance check in regulator_bulk_free() on unbind.

[Severity: Medium]
Is this description accurate?

Looking at ak7375_vcm_suspend(), it explicitly checks the active state and
returns early:

drivers/media/i2c/ak7375.c:ak7375_vcm_suspend() {
    ...
    if (!ak7375_dev->active)
        return 0;
    ...
}

Since ak7375_dev is zero-initialized by devm_kzalloc() during probe, active
is false. This means pm_runtime_idle() would never reach the I2C writes or
regulator_bulk_disable() during probe.

Could the actual leak have occurred strictly on the resume error path instead?

> diff --git a/drivers/media/i2c/ak7375.c b/drivers/media/i2c/ak7375.c
> index 4f311c4c06ba0..2763bbed6cbd4 100644
> --- a/drivers/media/i2c/ak7375.c
> +++ b/drivers/media/i2c/ak7375.c
> @@ -235,9 +235,12 @@ static int ak7375_probe(struct i2c_client *client)
>  	if (ret < 0)
>  		goto err_cleanup;
>  
> -	pm_runtime_set_active(&client->dev);
> +	/*
> +	 * The regulators are off at this point, so the device is suspended,
> +	 * not active.
> +	 */
> +	pm_runtime_set_suspended(&client->dev);
>  	pm_runtime_enable(&client->dev);
> -	pm_runtime_idle(&client->dev);
>  
>  	return 0;

[Severity: High]
This is a pre-existing issue, but does this devres cleanup lead to a
use-after-free on driver unbind?

The ak7375_device structure is allocated with devm_kzalloc() earlier in
ak7375_probe(). If a user-space process holds the /dev/v4l-subdevX node open
and the driver is unbound (e.g., via sysfs), ak7375_remove() will complete
and trigger devres to free ak7375_device.

When the process later closes the file descriptor, the V4L2 core functions
(such as subdev_close calling sd->internal_ops->close) will dereference the
now-freed v4l2_subdev pointer.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260829052514.18178-1-jan.brummer@tabos.org?part=2

Re: [PATCH] media: dt-bindings: ak7375: Add AK7377

[Rob Herring]

On Sat, Aug 29, 2026 at 07:25:12AM +0200, Jan-Michael Brummer wrote:
> The AK7377 is register compatible with the AK7375 and is driven by the
> same driver.

If so and there is no driver change, then you are missing a fallback 
compatible as sashiko points out.

> 
> Signed-off-by: Jan-Michael Brummer <jan.brummer@tabos.org>
> ---
>  .../devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml        | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml b/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml
> index fe312cc..c040757 100644
> --- a/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml
> @@ -18,6 +18,7 @@ properties:
>      enum:
>        - asahi-kasei,ak7345
>        - asahi-kasei,ak7375
> +      - asahi-kasei,ak7377
>  
>    reg:
>      maxItems: 1