linux-kernel - [PATCH v1 1/1] platform/x86: int3472: discrete: Remap "reset" to "enable" for OV7251

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>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240821184546.627456-1-andriy.shevchenko@linux.intel.com>
Date: Wed, 21 Aug 2024 21:40:07 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Hans de Goede <hdegoede@...hat.com>,
	platform-driver-x86@...r.kernel.org,
	linux-kernel@...r.kernel.org
Cc: Daniel Scally <djrscally@...il.com>
Subject: [PATCH v1 1/1] platform/x86: int3472: discrete: Remap "reset" to "enable" for OV7251

The driver of OV7251 expects "enable" pin instead of "reset".
Remap "reset" to "enable" and update polarity.

In particular, the Microsoft Surface Book can't load the camera sensor
driver without this change:

 ov7251 i2c-INT347E:00: supply vdddo not found, using dummy regulator
 ov7251 i2c-INT347E:00: supply vddd not found, using dummy regulator
 ov7251 i2c-INT347E:00: supply vdda not found, using dummy regulator
 ov7251 i2c-INT347E:00: cannot get enable gpio
 ov7251 i2c-INT347E:00: probe with driver ov7251 failed with error -2

Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
---

Hmm... I have spent some time to achieve this, and then I realised that
linux-surface GitHub project already has something similar [1].

The advantage of [1] is that it applies the quirk to all OV7251 sensors
on the platform (don't know how useful it IRL).

However, it seems the [1] has two issues:
1) it missed terminator entry in the ACPI ID table;
2) it forces polarity to be active high, while I think the XOR approach
is better as it's possible (but quite unlikely I believe) that reset pin
might be inverted on the PCB level.

All in all, I'm fine with any of these patches to be applied with the
above mentioned improvements / caveats.

Link: https://github.com/linux-surface/kernel/commit/d0f2c2d5a449c2bf69432f90d164183143d8af8d [1]

 drivers/platform/x86/intel/int3472/discrete.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
index b5f6f71bb1dd..0559295dfb27 100644
--- a/drivers/platform/x86/intel/int3472/discrete.c
+++ b/drivers/platform/x86/intel/int3472/discrete.c
@@ -86,6 +86,16 @@ static int skl_int3472_map_gpio_to_sensor(struct int3472_discrete_device *int347
 		return -EINVAL;
 	}

+	/*
+	 * The driver of OV7251 expects "enable" pin instead of "reset".
+	 * Remap "reset" to "enable" and update polarity.
+	 */
+	if (!strcmp(int3472->sensor_name, "i2c-INT347E:00") &&
+	    !strcmp(func, "reset")) {
+		func = "enable";
+		polarity ^= GPIO_ACTIVE_LOW;
+	}
+
 	ret = skl_int3472_fill_gpiod_lookup(&int3472->gpios.table[int3472->n_sensor_gpios],
 					    agpio, func, polarity);
 	if (ret)
-- 
2.43.0.rc1.1336.g36b5255a03ac