[PATCH v10 0/8] Enable cameras on Dell Latitude 5285 2-in-1

[PATCH v10 0/8] Enable cameras on Dell Latitude 5285 2-in-1

[Thierry Chatard]

This series enables the front (OV5670/INT3479) and rear (OV8858/INT3477)
cameras on the Dell Latitude 5285 2-in-1 under Linux.

Per Documentation/process/coding-assistants.rst, every patch carries an
Assisted-by tag: this work was developed with help from an AI coding
assistant (Claude Code). I have reviewed and tested all of it on the
hardware and take responsibility for the result.

The series is interdependent (all eight patches are needed for working
cameras) and touches three subsystems: mfd (patch 1), platform/x86 int3472
(patches 2-6) and media (patches 7-8). It is probably best merged as one
set - for example via platform-drivers-x86 with an immutable branch that
the media and MFD trees can pull. Lee, an Acked-by on patch 1 (mfd) would
help enable that; I'm happy to follow whichever merge approach the
maintainers prefer.

Changes since v9 (addressing Sakari Ailus's and Andy Shevchenko's review):
- Rebased onto platform-drivers-x86/for-next.
- Added Assisted-by tags to every patch per coding-assistants.rst (both
  reviewers asked).
- Split the old clock-consumer patch (v9 3/6) into two: a pure refactor
  that moves the Windows MFD-cell setup below the device-type switch
  (now 3/8), and the actual static clock-consumer support (now 4/8), as
  requested by Sakari.
- In that refactor, split the struct device *dev declaration from its
  assignment, and add a blank line separating generic and local forward
  declarations in tps68470.h, as requested by Andy.
- New patch 5/8: factor the always-on VIO regulator init_data out of the
  board-data patch into a shared common_tps68470_vio_reg_init_data, and
  fold in the byte-identical intel_nvl copy, as requested by Sakari.
- Patch 1 keeps Andy's Reviewed-by (subject prefix fixed to "mfd:" in v9).

Earlier changelogs are in the v7-v9 postings:
  v9: https://lore.kernel.org/all/20260827201611.99825-1-tchatard@gmail.com/
  v8: https://lore.kernel.org/all/20260826112452.13539-1-tchatard@gmail.com/
  v7: https://lore.kernel.org/all/20260819140107.1329091-1-tchatard@gmail.com/

Tested on Ubuntu 25.10 (kernel 6.17.0-22-generic) and Ubuntu 26.04 (kernel
7.0.0-30-generic): both cameras working in Zoom, Chrome, and GNOME Camera
via PipeWire. Also independently tested on the closely-related Dell Latitude
5290 2-in-1 (same IPU3/TPS68470/OV5670/OV8858/DW9714 stack) by Vitalii
Tytskyi:
  https://github.com/vitovt/dell-5290-camera-kernel/tree/master/patches

Thierry Chatard (8):
  mfd: intel-lpss: add resource conflict quirk for Dell Latitude 5285
  platform/x86: int3472: tps68470: use unsigned int for GPIO lookup loop
    counters
  platform/x86: int3472: tps68470: move Windows MFD setup below the
    device-type switch
  platform/x86: int3472: tps68470: add static clock consumer support
  platform/x86: int3472: tps68470: use a common always-on VIO regulator
    init_data
  platform/x86: int3472: tps68470: add board data for Dell Latitude 5285
  media: ipu-bridge: add sensor configuration for OV8858 (INT3477)
  media: ov8858: add ACPI device ID INT3477

 drivers/media/i2c/ov8858.c                    |   7 +
 drivers/media/pci/intel/ipu-bridge.c          |   2 +
 drivers/mfd/intel-lpss-acpi.c                 |  32 ++++
 drivers/platform/x86/intel/int3472/tps68470.c | 116 ++++++-----
 drivers/platform/x86/intel/int3472/tps68470.h |   8 +
 .../x86/intel/int3472/tps68470_board_data.c   | 181 ++++++++++++++++--
 6 files changed, 283 insertions(+), 63 deletions(-)


base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
-- 
2.53.0

[PATCH v10 1/8] mfd: intel-lpss: add resource conflict quirk for Dell Latitude 5285

[Thierry Chatard]

The Dell Latitude 5285 2-in-1 has a BIOS bug where the ACPI GEXP device
and the I2C4 controller (INT3446) both claim the same MMIO region via the
shared SB04 variable. This causes intel_lpss_acpi to fail binding to I2C4
with -EBUSY, preventing the front camera (OV5670) sensor from being
registered.

Match the affected machine by DMI and the affected device by ACPI ID,
carrying QUIRK_IGNORE_RESOURCE_CONFLICTS in the ACPI match data and
applying it to the per-device info in probe. This follows the quirk
organisation used by the PCI counterpart.

Assisted-by: Claude Code:claude-opus-4-8
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Thierry Chatard <tchatard@gmail.com>
---
 drivers/mfd/intel-lpss-acpi.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/drivers/mfd/intel-lpss-acpi.c b/drivers/mfd/intel-lpss-acpi.c
index d4b24a717..9d7d0ad62 100644
--- a/drivers/mfd/intel-lpss-acpi.c
+++ b/drivers/mfd/intel-lpss-acpi.c
@@ -8,7 +8,9 @@
  *          Mika Westerberg <mika.westerberg@linux.intel.com>
  */
 
+#include <linux/acpi.h>
 #include <linux/device.h>
+#include <linux/dmi.h>
 #include <linux/gfp_types.h>
 #include <linux/ioport.h>
 #include <linux/module.h>
@@ -171,6 +173,27 @@ static const struct acpi_device_id intel_lpss_acpi_ids[] = {
 };
 MODULE_DEVICE_TABLE(acpi, intel_lpss_acpi_ids);
 
+/*
+ * Devices that need a quirk applied only on the machines matched by
+ * intel_lpss_quirk_dmi[] below. The quirk to apply is carried in the
+ * matching entry's driver_data.
+ */
+static const struct acpi_device_id intel_lpss_acpi_quirk_ids[] = {
+	/* Dell Latitude 5285: ACPI GEXP device conflicts with I2C4 (INT3446) */
+	{ "INT3446", QUIRK_IGNORE_RESOURCE_CONFLICTS },
+	{ }
+};
+
+static const struct dmi_system_id intel_lpss_quirk_dmi[] = {
+	{
+		.matches = {
+			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Latitude 5285"),
+		},
+	},
+	{ }
+};
+
 static int intel_lpss_acpi_probe(struct platform_device *pdev)
 {
 	const struct intel_lpss_platform_info *data;
@@ -185,6 +208,15 @@ static int intel_lpss_acpi_probe(struct platform_device *pdev)
 	if (!info)
 		return -ENOMEM;
 
+	/* Apply per-device quirks that are only needed on certain machines */
+	if (dmi_check_system(intel_lpss_quirk_dmi)) {
+		const struct acpi_device_id *id;
+
+		id = acpi_match_device(intel_lpss_acpi_quirk_ids, &pdev->dev);
+		if (id)
+			info->quirks |= id->driver_data;
+	}
+
 	/* No need to check mem and irq here as intel_lpss_probe() does it for us */
 	info->mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	info->irq = platform_get_irq(pdev, 0);
-- 
2.53.0

[PATCH v10 2/8] platform/x86: int3472: tps68470: use unsigned int for GPIO lookup loop counters

[Thierry Chatard]

The GPIO lookup table loops in the probe and remove paths iterate up to
board_data->n_gpiod_lookups, which is unsigned int. Use unsigned int for
the loop counters to match and avoid a signed/unsigned comparison.

No functional change.

Assisted-by: Claude Code:claude-opus-4-8
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Thierry Chatard <tchatard@gmail.com>
---
 drivers/platform/x86/intel/int3472/tps68470.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/intel/int3472/tps68470.c b/drivers/platform/x86/intel/int3472/tps68470.c
index a77ed32ab..35909a683 100644
--- a/drivers/platform/x86/intel/int3472/tps68470.c
+++ b/drivers/platform/x86/intel/int3472/tps68470.c
@@ -149,8 +149,8 @@ static int skl_int3472_tps68470_probe(struct i2c_client *client)
 	struct regmap *regmap;
 	int n_consumers;
 	int device_type;
+	unsigned int i;
 	int ret;
-	int i;
 
 	if (!adev)
 		return -ENODEV;
@@ -234,7 +234,7 @@ static int skl_int3472_tps68470_probe(struct i2c_client *client)
 static void skl_int3472_tps68470_remove(struct i2c_client *client)
 {
 	const struct int3472_tps68470_board_data *board_data;
-	int i;
+	unsigned int i;
 
 	board_data = int3472_tps68470_get_board_data(dev_name(&client->dev));
 	if (board_data) {
-- 
2.53.0

[PATCH v10 3/8] platform/x86: int3472: tps68470: move Windows MFD setup below the device-type switch

[Thierry Chatard]

The Windows path looks up the board data, builds the tps68470-clk
platform data and registers the MFD cells; none of this is needed for the
ChromeOS path, which registers its own cells. Move that handling out of
the switch and let the ChromeOS case return directly, so the Windows-only
work is no longer done for ChromeOS and the function reads top to bottom.

While moving the code, use a local struct device *dev to shorten the many
&client->dev references, and return -ENODATA (rather than -ENODEV) when no
board data matches this machine, to distinguish it from a missing device.

No functional change for either path.

Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: Thierry Chatard <tchatard@gmail.com>
---
 drivers/platform/x86/intel/int3472/tps68470.c | 99 ++++++++++---------
 1 file changed, 51 insertions(+), 48 deletions(-)

diff --git a/drivers/platform/x86/intel/int3472/tps68470.c b/drivers/platform/x86/intel/int3472/tps68470.c
index 35909a683..35fa77eb3 100644
--- a/drivers/platform/x86/intel/int3472/tps68470.c
+++ b/drivers/platform/x86/intel/int3472/tps68470.c
@@ -142,85 +142,88 @@ skl_int3472_fill_clk_pdata(struct device *dev, struct tps68470_clk_platform_data
 
 static int skl_int3472_tps68470_probe(struct i2c_client *client)
 {
-	struct acpi_device *adev = ACPI_COMPANION(&client->dev);
 	const struct int3472_tps68470_board_data *board_data;
 	struct tps68470_clk_platform_data *clk_pdata;
+	struct acpi_device *adev;
 	struct mfd_cell *cells;
 	struct regmap *regmap;
+	struct device *dev;
 	int n_consumers;
 	int device_type;
 	unsigned int i;
 	int ret;
 
+	dev = &client->dev;
+	adev = ACPI_COMPANION(dev);
 	if (!adev)
 		return -ENODEV;
 
-	n_consumers = skl_int3472_fill_clk_pdata(&client->dev, &clk_pdata);
-	if (n_consumers < 0)
-		return n_consumers;
-
 	regmap = devm_regmap_init_i2c(client, &tps68470_regmap_config);
 	if (IS_ERR(regmap)) {
-		dev_err(&client->dev, "Failed to create regmap: %ld\n", PTR_ERR(regmap));
+		dev_err(dev, "Failed to create regmap: %ld\n", PTR_ERR(regmap));
 		return PTR_ERR(regmap);
 	}
 
 	i2c_set_clientdata(client, regmap);
 
-	ret = tps68470_chip_init(&client->dev, regmap);
+	ret = tps68470_chip_init(dev, regmap);
 	if (ret < 0) {
-		dev_err(&client->dev, "TPS68470 init error %d\n", ret);
+		dev_err(dev, "TPS68470 init error %d\n", ret);
 		return ret;
 	}
 
 	device_type = skl_int3472_tps68470_calc_type(adev);
 	switch (device_type) {
 	case DESIGNED_FOR_WINDOWS:
-		board_data = int3472_tps68470_get_board_data(dev_name(&client->dev));
-		if (!board_data)
-			return dev_err_probe(&client->dev, -ENODEV, "No board-data found for this model\n");
-
-		cells = kzalloc_objs(*cells, TPS68470_WIN_MFD_CELL_COUNT);
-		if (!cells)
-			return -ENOMEM;
+		break;
+	case DESIGNED_FOR_CHROMEOS:
+		return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
+					    tps68470_cros, ARRAY_SIZE(tps68470_cros),
+					    NULL, 0, NULL);
+	default:
+		dev_err(dev, "Failed to add MFD devices\n");
+		return device_type;
+	}
 
-		/*
-		 * The order of the cells matters here! The clk must be first
-		 * because the regulator depends on it. The gpios must be last,
-		 * acpi_gpiochip_add() calls acpi_dev_clear_dependencies() and
-		 * the clk + regulators must be ready when this happens.
-		 */
-		cells[0].name = "tps68470-clk";
-		cells[0].platform_data = clk_pdata;
-		cells[0].pdata_size = struct_size(clk_pdata, consumers, n_consumers);
-		cells[1].name = "tps68470-regulator";
-		cells[1].platform_data = (void *)board_data->tps68470_regulator_pdata;
-		cells[1].pdata_size = sizeof(struct tps68470_regulator_platform_data);
-		cells[2].name = "tps68470-gpio";
-		cells[2].swnode = board_data->tps68470_gpio_swnode;
+	board_data = int3472_tps68470_get_board_data(dev_name(dev));
+	if (!board_data)
+		return dev_err_probe(dev, -ENODATA,
+				     "No board-data found for this model\n");
 
-		for (i = 0; i < board_data->n_gpiod_lookups; i++)
-			gpiod_add_lookup_table(board_data->tps68470_gpio_lookup_tables[i]);
+	n_consumers = skl_int3472_fill_clk_pdata(dev, &clk_pdata);
+	if (n_consumers < 0)
+		return n_consumers;
 
-		ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_NONE,
-					   cells, TPS68470_WIN_MFD_CELL_COUNT,
-					   NULL, 0, NULL);
-		kfree(cells);
+	cells = kzalloc_objs(*cells, TPS68470_WIN_MFD_CELL_COUNT);
+	if (!cells)
+		return -ENOMEM;
 
-		if (ret) {
-			for (i = 0; i < board_data->n_gpiod_lookups; i++)
-				gpiod_remove_lookup_table(board_data->tps68470_gpio_lookup_tables[i]);
-		}
+	/*
+	 * The order of the cells matters here! The clk must be first
+	 * because the regulator depends on it. The gpios must be last,
+	 * acpi_gpiochip_add() calls acpi_dev_clear_dependencies() and
+	 * the clk + regulators must be ready when this happens.
+	 */
+	cells[0].name = "tps68470-clk";
+	cells[0].platform_data = clk_pdata;
+	cells[0].pdata_size = struct_size(clk_pdata, consumers, n_consumers);
+	cells[1].name = "tps68470-regulator";
+	cells[1].platform_data = (void *)board_data->tps68470_regulator_pdata;
+	cells[1].pdata_size = sizeof(struct tps68470_regulator_platform_data);
+	cells[2].name = "tps68470-gpio";
+	cells[2].swnode = board_data->tps68470_gpio_swnode;
+
+	for (i = 0; i < board_data->n_gpiod_lookups; i++)
+		gpiod_add_lookup_table(board_data->tps68470_gpio_lookup_tables[i]);
+
+	ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
+				   cells, TPS68470_WIN_MFD_CELL_COUNT,
+				   NULL, 0, NULL);
+	kfree(cells);
 
-		break;
-	case DESIGNED_FOR_CHROMEOS:
-		ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_NONE,
-					   tps68470_cros, ARRAY_SIZE(tps68470_cros),
-					   NULL, 0, NULL);
-		break;
-	default:
-		dev_err(&client->dev, "Failed to add MFD devices\n");
-		return device_type;
+	if (ret) {
+		for (i = 0; i < board_data->n_gpiod_lookups; i++)
+			gpiod_remove_lookup_table(board_data->tps68470_gpio_lookup_tables[i]);
 	}
 
 	/*
-- 
2.53.0

[PATCH v10 4/8] platform/x86: int3472: tps68470: add static clock consumer support

[Thierry Chatard]

On some platforms a sensor's ACPI _DEP does not list the INT3472 device,
so for_each_acpi_consumer_dev() misses that sensor and never registers its
tps68470-clk consumer entry, leaving the sensor without its MCLK.

Add optional n_clk_consumers/clk_consumers fields to the board data. When
set, probe builds the tps68470-clk platform data from that static list
instead of walking the ACPI consumers. Boards that leave the fields unset
keep using the existing ACPI traversal.

Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: Thierry Chatard <tchatard@gmail.com>
---
 drivers/platform/x86/intel/int3472/tps68470.c | 19 ++++++++++++++++---
 drivers/platform/x86/intel/int3472/tps68470.h |  8 ++++++++
 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/intel/int3472/tps68470.c b/drivers/platform/x86/intel/int3472/tps68470.c
index 35fa77eb3..df0f5f962 100644
--- a/drivers/platform/x86/intel/int3472/tps68470.c
+++ b/drivers/platform/x86/intel/int3472/tps68470.c
@@ -190,9 +190,22 @@ static int skl_int3472_tps68470_probe(struct i2c_client *client)
 		return dev_err_probe(dev, -ENODATA,
 				     "No board-data found for this model\n");
 
-	n_consumers = skl_int3472_fill_clk_pdata(dev, &clk_pdata);
-	if (n_consumers < 0)
-		return n_consumers;
+	if (board_data->n_clk_consumers) {
+		clk_pdata = devm_kzalloc(dev,
+					 struct_size(clk_pdata, consumers,
+						     board_data->n_clk_consumers),
+					 GFP_KERNEL);
+		if (!clk_pdata)
+			return -ENOMEM;
+		clk_pdata->n_consumers = board_data->n_clk_consumers;
+		for (i = 0; i < board_data->n_clk_consumers; i++)
+			clk_pdata->consumers[i] = board_data->clk_consumers[i];
+		n_consumers = board_data->n_clk_consumers;
+	} else {
+		n_consumers = skl_int3472_fill_clk_pdata(dev, &clk_pdata);
+		if (n_consumers < 0)
+			return n_consumers;
+	}
 
 	cells = kzalloc_objs(*cells, TPS68470_WIN_MFD_CELL_COUNT);
 	if (!cells)
diff --git a/drivers/platform/x86/intel/int3472/tps68470.h b/drivers/platform/x86/intel/int3472/tps68470.h
index 3bbaade96..68303e6fa 100644
--- a/drivers/platform/x86/intel/int3472/tps68470.h
+++ b/drivers/platform/x86/intel/int3472/tps68470.h
@@ -12,12 +12,20 @@
 #define _INTEL_SKL_INT3472_TPS68470_H
 
 struct gpiod_lookup_table;
+
+struct tps68470_clk_consumer;
 struct tps68470_regulator_platform_data;
 
 struct int3472_tps68470_board_data {
 	const char *dev_name;
 	const struct tps68470_regulator_platform_data *tps68470_regulator_pdata;
 	const struct software_node *tps68470_gpio_swnode;
+	/*
+	 * Optional static clock consumers, used in place of the ACPI _DEP
+	 * traversal on platforms where a sensor's _DEP omits the INT3472.
+	 */
+	unsigned int n_clk_consumers;
+	const struct tps68470_clk_consumer *clk_consumers;
 	unsigned int n_gpiod_lookups;
 	struct gpiod_lookup_table *tps68470_gpio_lookup_tables[];
 };
-- 
2.53.0

[PATCH v10 5/8] platform/x86: int3472: tps68470: use a common always-on VIO regulator init_data

[Thierry Chatard]

The surface_go and intel_nvl board data define byte-identical VIO
regulator init_data (1.8006 V, apply_uV, always_on). Replace both with a
single shared common_tps68470_vio_reg_init_data so new boards with the
same requirement can reuse it instead of duplicating the definition.

No functional change.

Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: Thierry Chatard <tchatard@gmail.com>
---
 .../x86/intel/int3472/tps68470_board_data.c   | 21 +++++++------------
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/platform/x86/intel/int3472/tps68470_board_data.c b/drivers/platform/x86/intel/int3472/tps68470_board_data.c
index c53542465..c2ec802fc 100644
--- a/drivers/platform/x86/intel/int3472/tps68470_board_data.c
+++ b/drivers/platform/x86/intel/int3472/tps68470_board_data.c
@@ -75,8 +75,12 @@ static const struct regulator_init_data surface_go_tps68470_vcm_reg_init_data =
 	.consumer_supplies = int347a_vcm_consumer_supplies,
 };
 
-/* Ensure the always-on VIO regulator has the same voltage as VSIO */
-static const struct regulator_init_data surface_go_tps68470_vio_reg_init_data = {
+/*
+ * Common always-on VIO regulator init_data. Its voltage must match VSIO;
+ * boards using the TPS68470 I2C pass-through that need this exact setting
+ * can share this instead of defining their own.
+ */
+static const struct regulator_init_data common_tps68470_vio_reg_init_data = {
 	.constraints = {
 		.min_uV = 1800600,
 		.max_uV = 1800600,
@@ -123,7 +127,7 @@ static const struct tps68470_regulator_platform_data surface_go_tps68470_pdata =
 		[TPS68470_CORE] = &surface_go_tps68470_core_reg_init_data,
 		[TPS68470_ANA]  = &surface_go_tps68470_ana_reg_init_data,
 		[TPS68470_VCM]  = &surface_go_tps68470_vcm_reg_init_data,
-		[TPS68470_VIO] = &surface_go_tps68470_vio_reg_init_data,
+		[TPS68470_VIO] = &common_tps68470_vio_reg_init_data,
 		[TPS68470_VSIO] = &surface_go_tps68470_vsio_reg_init_data,
 		[TPS68470_AUX1] = &surface_go_tps68470_aux1_reg_init_data,
 		[TPS68470_AUX2] = &surface_go_tps68470_aux2_reg_init_data,
@@ -339,15 +343,6 @@ static const struct regulator_init_data intel_nvl_tps68470_vcm_reg_init_data = {
 	.consumer_supplies = ovti13b1_vcm_consumer_supplies,
 };
 
-/* Ensure the always-on VIO regulator has the same voltage as VSIO */
-static const struct regulator_init_data intel_nvl_tps68470_vio_reg_init_data = {
-	.constraints = {
-		.min_uV = 1800600,
-		.max_uV = 1800600,
-		.apply_uV = true,
-		.always_on = true,
-	},
-};
 static const struct regulator_init_data intel_nvl_tps68470_vsio_reg_init_data = {
 	.constraints = {
 		.min_uV = 1800600,
@@ -364,7 +359,7 @@ static const struct tps68470_regulator_platform_data intel_nvl_tps68470_pdata =
 		[TPS68470_CORE] = &intel_nvl_tps68470_core_reg_init_data,
 		[TPS68470_ANA]  = &intel_nvl_tps68470_ana_reg_init_data,
 		[TPS68470_VCM]  = &intel_nvl_tps68470_vcm_reg_init_data,
-		[TPS68470_VIO] = &intel_nvl_tps68470_vio_reg_init_data,
+		[TPS68470_VIO] = &common_tps68470_vio_reg_init_data,
 		[TPS68470_VSIO] = &intel_nvl_tps68470_vsio_reg_init_data,
 	},
 };
-- 
2.53.0

[PATCH v10 6/8] platform/x86: int3472: tps68470: add board data for Dell Latitude 5285

[Thierry Chatard]

The Dell Latitude 5285 2-in-1 has two cameras connected through a TPS68470
PMIC/clock/GPIO hub:

  Front: OV5670 (ACPI INT3479) on I2C4
  Back:  OV8858 (ACPI INT3477) on I2C2, daisy-chained behind the TPS68470
         S_I2C port (controlled by reg 0x43 S_I2C_CTL)

Add the regulator supply map, GPIO lookup tables and a static clock
consumer list (for both sensors, to work around the broken INT3479 _DEP)
for this machine, and wire it into the board-data DMI table.

Regulator mapping:
  CORE -> dvdd/INT3477, ANA -> avdd/INT3477, VSIO -> dovdd/INT3477 (opens
  the S_I2C passthrough), AUX1 -> dvdd/INT3479, AUX2 -> dovdd/INT3479,
  VIO kept always_on. VSIO also supplies avdd for INT3479 (OV5670).

Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: Thierry Chatard <tchatard@gmail.com>
---
 .../x86/intel/int3472/tps68470_board_data.c   | 160 ++++++++++++++++++
 1 file changed, 160 insertions(+)

diff --git a/drivers/platform/x86/intel/int3472/tps68470_board_data.c b/drivers/platform/x86/intel/int3472/tps68470_board_data.c
index c2ec802fc..90094732e 100644
--- a/drivers/platform/x86/intel/int3472/tps68470_board_data.c
+++ b/drivers/platform/x86/intel/int3472/tps68470_board_data.c
@@ -464,6 +464,159 @@ static const struct int3472_tps68470_board_data intel_nvl_tps68470_board_data =
 	},
 };
 
+/* Settings for Dell Latitude 5285 2-in-1 */
+
+/*
+ * The BIOS leaves GNVS field C0TP at zero, which causes INT3479's _DEP to
+ * resolve to PCI0 instead of the INT3472 device. Provide a static clock
+ * consumer list so probe registers MCLK lookups for both sensors regardless
+ * of the broken _DEP traversal.
+ */
+static const struct tps68470_clk_consumer dell_5285_clk_consumers[] = {
+	{ .consumer_dev_name = "i2c-INT3477:00" },	/* OV8858 rear camera */
+	{ .consumer_dev_name = "i2c-INT3479:00" },	/* OV5670 front camera */
+};
+
+static struct regulator_consumer_supply dell_5285_int3477_ana_consumer_supplies[] = {
+	REGULATOR_SUPPLY("avdd", "i2c-INT3477:00"),
+};
+
+static struct regulator_consumer_supply dell_5285_int3477_core_consumer_supplies[] = {
+	REGULATOR_SUPPLY("dvdd", "i2c-INT3477:00"),
+};
+
+/*
+ * VSIO controls the S_I2C_CTL passthrough; its voltage must match VIO
+ * (both 1800600 uV). dovdd/INT3477 enables the passthrough when OV8858
+ * opens its I2C path. avdd/INT3479 provides the OV5670 analog supply.
+ */
+static struct regulator_consumer_supply dell_5285_int3477_vsio_consumer_supplies[] = {
+	REGULATOR_SUPPLY("dovdd", "i2c-INT3477:00"),
+	REGULATOR_SUPPLY("avdd", "i2c-INT3479:00"),
+};
+
+static struct regulator_consumer_supply dell_5285_int3479_aux1_consumer_supplies[] = {
+	REGULATOR_SUPPLY("dvdd", "i2c-INT3479:00"),
+};
+
+static struct regulator_consumer_supply dell_5285_int3479_aux2_consumer_supplies[] = {
+	REGULATOR_SUPPLY("dovdd", "i2c-INT3479:00"),
+};
+
+static const struct regulator_init_data dell_5285_tps68470_core_reg_init_data = {
+	.constraints = {
+		.min_uV = 1200000,
+		.max_uV = 1200000,
+		.apply_uV = 1,
+		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies = ARRAY_SIZE(dell_5285_int3477_core_consumer_supplies),
+	.consumer_supplies = dell_5285_int3477_core_consumer_supplies,
+};
+
+static const struct regulator_init_data dell_5285_tps68470_ana_reg_init_data = {
+	.constraints = {
+		.min_uV = 2815200,
+		.max_uV = 2815200,
+		.apply_uV = 1,
+		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies = ARRAY_SIZE(dell_5285_int3477_ana_consumer_supplies),
+	.consumer_supplies = dell_5285_int3477_ana_consumer_supplies,
+};
+
+static const struct regulator_init_data dell_5285_tps68470_vcm_reg_init_data = {
+	.constraints = {
+		.min_uV = 2815200,
+		.max_uV = 2815200,
+		.apply_uV = 1,
+		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies = 0,
+	.consumer_supplies = NULL,
+};
+
+static const struct regulator_init_data dell_5285_tps68470_vsio_reg_init_data = {
+	.constraints = {
+		.min_uV = 1800600,
+		.max_uV = 1800600,
+		.apply_uV = 1,
+		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies = ARRAY_SIZE(dell_5285_int3477_vsio_consumer_supplies),
+	.consumer_supplies = dell_5285_int3477_vsio_consumer_supplies,
+};
+
+static const struct regulator_init_data dell_5285_tps68470_aux1_reg_init_data = {
+	.constraints = {
+		.min_uV = 1213200,
+		.max_uV = 1213200,
+		.apply_uV = 1,
+		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies = ARRAY_SIZE(dell_5285_int3479_aux1_consumer_supplies),
+	.consumer_supplies = dell_5285_int3479_aux1_consumer_supplies,
+};
+
+static const struct regulator_init_data dell_5285_tps68470_aux2_reg_init_data = {
+	.constraints = {
+		.min_uV = 1800600,
+		.max_uV = 1800600,
+		.apply_uV = 1,
+		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies = ARRAY_SIZE(dell_5285_int3479_aux2_consumer_supplies),
+	.consumer_supplies = dell_5285_int3479_aux2_consumer_supplies,
+};
+
+static const struct tps68470_regulator_platform_data dell_5285_tps68470_pdata = {
+	.reg_init_data = {
+		[TPS68470_CORE] = &dell_5285_tps68470_core_reg_init_data,
+		[TPS68470_ANA] = &dell_5285_tps68470_ana_reg_init_data,
+		[TPS68470_VCM] = &dell_5285_tps68470_vcm_reg_init_data,
+		[TPS68470_VIO] = &common_tps68470_vio_reg_init_data,
+		[TPS68470_VSIO] = &dell_5285_tps68470_vsio_reg_init_data,
+		[TPS68470_AUX1] = &dell_5285_tps68470_aux1_reg_init_data,
+		[TPS68470_AUX2] = &dell_5285_tps68470_aux2_reg_init_data,
+	},
+};
+
+static struct gpiod_lookup_table dell_5285_int3477_gpios = {
+	.dev_id = "i2c-INT3477:00",
+	.table = {
+		/*
+		 * TPS68470 GPIO9 = s_resetn (secondary camera reset, active-low)
+		 * TPS68470 GPIO7 = s_enable (secondary camera enable/powerdown)
+		 * These logic outputs are specifically designed for secondary
+		 * camera control on the TPS68470. Matches Surface Go pattern.
+		 */
+		GPIO_LOOKUP("tps68470-gpio", 9, "reset", GPIO_ACTIVE_LOW),
+		GPIO_LOOKUP("tps68470-gpio", 7, "powerdown", GPIO_ACTIVE_LOW),
+		{ }
+	}
+};
+
+static struct gpiod_lookup_table dell_5285_int3479_gpios = {
+	.dev_id = "i2c-INT3479:00",
+	.table = {
+		GPIO_LOOKUP("tps68470-gpio", 3, "reset", GPIO_ACTIVE_LOW),
+		GPIO_LOOKUP("tps68470-gpio", 4, "powerdown", GPIO_ACTIVE_LOW),
+		{ }
+	}
+};
+
+static const struct int3472_tps68470_board_data dell_5285_tps68470_board_data = {
+	.dev_name = "i2c-INT3472:05",
+	.tps68470_regulator_pdata = &dell_5285_tps68470_pdata,
+	.n_clk_consumers = ARRAY_SIZE(dell_5285_clk_consumers),
+	.clk_consumers = dell_5285_clk_consumers,
+	.n_gpiod_lookups = 2,
+	.tps68470_gpio_lookup_tables = {
+		&dell_5285_int3477_gpios,
+		&dell_5285_int3479_gpios,
+	},
+};
+
 static const struct dmi_system_id int3472_tps68470_board_data_table[] = {
 	{
 		.matches = {
@@ -524,6 +677,13 @@ static const struct dmi_system_id int3472_tps68470_board_data_table[] = {
 		},
 		.driver_data = (void *)&intel_nvl_tps68470_board_data,
 	},
+	{
+		.matches = {
+			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Latitude 5285"),
+		},
+		.driver_data = (void *)&dell_5285_tps68470_board_data,
+	},
 	{ }
 };
 
-- 
2.53.0

[PATCH v10 7/8] media: ipu-bridge: add sensor configuration for OV8858 (INT3477)

[Thierry Chatard]

The Omnivision OV8858 is used as the rear camera in several Intel
IPU3-based devices (e.g. Dell Latitude 5285 2-in-1). Its ACPI HID is
INT3477. Add a sensor configuration entry with a link frequency of
360 MHz to allow ipu_bridge to create the firmware node for this sensor.

Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: Thierry Chatard <tchatard@gmail.com>
---
 drivers/media/pci/intel/ipu-bridge.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
index 1bb3a3e98..15fe4d057 100644
--- a/drivers/media/pci/intel/ipu-bridge.c
+++ b/drivers/media/pci/intel/ipu-bridge.c
@@ -65,6 +65,8 @@ static const struct ipu_sensor_config ipu_supported_sensors[] = {
 	IPU_SENSOR_CONFIG("INT33F0", 1, 384000000),
 	/* Omnivision OV2740 */
 	IPU_SENSOR_CONFIG("INT3474", 1, 180000000),
+	/* Omnivision OV8858 */
+	IPU_SENSOR_CONFIG("INT3477", 1, 360000000),
 	/* Omnivision OV5670 */
 	IPU_SENSOR_CONFIG("INT3479", 1, 422400000),
 	/* Omnivision OV8865 */
-- 
2.53.0

[PATCH v10 8/8] media: ov8858: add ACPI device ID INT3477

[Thierry Chatard]

The Omnivision OV8858 appears in ACPI firmware under the HID INT3477 on
Intel IPU3-based platforms such as the Dell Latitude 5285 2-in-1. Add
INT3477 to the ACPI match table so the driver binds when instantiated by
ipu_bridge.

Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: Thierry Chatard <tchatard@gmail.com>
---
 drivers/media/i2c/ov8858.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/media/i2c/ov8858.c b/drivers/media/i2c/ov8858.c
index 3f45f7fab..f0148c1f2 100644
--- a/drivers/media/i2c/ov8858.c
+++ b/drivers/media/i2c/ov8858.c
@@ -1981,11 +1981,18 @@ static const struct of_device_id ov8858_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, ov8858_of_match);
 
+static const struct acpi_device_id ov8858_acpi_ids[] = {
+	{ .id = "INT3477" },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(acpi, ov8858_acpi_ids);
+
 static struct i2c_driver ov8858_i2c_driver = {
 	.driver = {
 		.name = "ov8858",
 		.pm = &ov8858_pm_ops,
 		.of_match_table = ov8858_of_match,
+		.acpi_match_table = ov8858_acpi_ids,
 	},
 	.probe		= ov8858_probe,
 	.remove		= ov8858_remove,
-- 
2.53.0

Re: [PATCH v10 2/8] platform/x86: int3472: tps68470: use unsigned int for GPIO lookup loop counters

[Andy Shevchenko]

On Mon, Aug 31, 2026 at 06:07:48PM +0200, Thierry Chatard wrote:
> The GPIO lookup table loops in the probe and remove paths iterate up to
> board_data->n_gpiod_lookups, which is unsigned int. Use unsigned int for
> the loop counters to match and avoid a signed/unsigned comparison.
> 
> No functional change.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v10 7/8] media: ipu-bridge: add sensor configuration for OV8858 (INT3477)

[Andy Shevchenko]

On Mon, Aug 31, 2026 at 06:07:53PM +0200, Thierry Chatard wrote:
> The Omnivision OV8858 is used as the rear camera in several Intel
> IPU3-based devices (e.g. Dell Latitude 5285 2-in-1). Its ACPI HID is
> INT3477. Add a sensor configuration entry with a link frequency of
> 360 MHz to allow ipu_bridge to create the firmware node for this sensor.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v10 3/8] platform/x86: int3472: tps68470: move Windows MFD setup below the device-type switch

[Andy Shevchenko]

On Mon, Aug 31, 2026 at 06:07:49PM +0200, Thierry Chatard wrote:
> The Windows path looks up the board data, builds the tps68470-clk
> platform data and registers the MFD cells; none of this is needed for the
> ChromeOS path, which registers its own cells. Move that handling out of
> the switch and let the ChromeOS case return directly, so the Windows-only
> work is no longer done for ChromeOS and the function reads top to bottom.
> 
> While moving the code, use a local struct device *dev to shorten the many
> &client->dev references, and return -ENODATA (rather than -ENODEV) when no
> board data matches this machine, to distinguish it from a missing device.

These all have to be split to the separate logical changes.

> No functional change for either path.

...

>  static int skl_int3472_tps68470_probe(struct i2c_client *client)
>  {
> -	struct acpi_device *adev = ACPI_COMPANION(&client->dev);
>  	const struct int3472_tps68470_board_data *board_data;
>  	struct tps68470_clk_platform_data *clk_pdata;
> +	struct acpi_device *adev;
>  	struct mfd_cell *cells;
>  	struct regmap *regmap;
> +	struct device *dev;
>  	int n_consumers;
>  	int device_type;
>  	unsigned int i;
>  	int ret;
>  
> +	dev = &client->dev;

This one is not getting validated, hence it's fine to assign directly above

	struct device *dev = &client->dev;


> +	adev = ACPI_COMPANION(dev);
>  	if (!adev)
>  		return -ENODEV;

...

>  	regmap = devm_regmap_init_i2c(client, &tps68470_regmap_config);
>  	if (IS_ERR(regmap)) {
> -		dev_err(&client->dev, "Failed to create regmap: %ld\n", PTR_ERR(regmap));
> +		dev_err(dev, "Failed to create regmap: %ld\n", PTR_ERR(regmap));
>  		return PTR_ERR(regmap);
>  	}

This should be replaced with return dev_err_probe() in a separate change.

>  	i2c_set_clientdata(client, regmap);
>  
> -	ret = tps68470_chip_init(&client->dev, regmap);
> +	ret = tps68470_chip_init(dev, regmap);
>  	if (ret < 0) {
> -		dev_err(&client->dev, "TPS68470 init error %d\n", ret);
> +		dev_err(dev, "TPS68470 init error %d\n", ret);
>  		return ret;
>  	}

This is as well. And replacing &client->dev by dev should be in a separate
patch.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v10 8/8] media: ov8858: add ACPI device ID INT3477

[Andy Shevchenko]

On Mon, Aug 31, 2026 at 06:07:54PM +0200, Thierry Chatard wrote:
> The Omnivision OV8858 appears in ACPI firmware under the HID INT3477 on
> Intel IPU3-based platforms such as the Dell Latitude 5285 2-in-1. Add
> INT3477 to the ACPI match table so the driver binds when instantiated by
> ipu_bridge.

Sakari wants you to add ACPI_PTR().

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v10 4/8] platform/x86: int3472: tps68470: add static clock consumer support

[Andy Shevchenko]

On Mon, Aug 31, 2026 at 06:07:50PM +0200, Thierry Chatard wrote:
> On some platforms a sensor's ACPI _DEP does not list the INT3472 device,
> so for_each_acpi_consumer_dev() misses that sensor and never registers its
> tps68470-clk consumer entry, leaving the sensor without its MCLK.
> 
> Add optional n_clk_consumers/clk_consumers fields to the board data. When
> set, probe builds the tps68470-clk platform data from that static list
> instead of walking the ACPI consumers. Boards that leave the fields unset
> keep using the existing ACPI traversal.

...

> -	n_consumers = skl_int3472_fill_clk_pdata(dev, &clk_pdata);
> -	if (n_consumers < 0)
> -		return n_consumers;
> +	if (board_data->n_clk_consumers) {
> +		clk_pdata = devm_kzalloc(dev,
> +					 struct_size(clk_pdata, consumers,
> +						     board_data->n_clk_consumers),
> +					 GFP_KERNEL);
> +		if (!clk_pdata)
> +			return -ENOMEM;
> +		clk_pdata->n_consumers = board_data->n_clk_consumers;
> +		for (i = 0; i < board_data->n_clk_consumers; i++)
> +			clk_pdata->consumers[i] = board_data->clk_consumers[i];
> +		n_consumers = board_data->n_clk_consumers;
> +	} else {
> +		n_consumers = skl_int3472_fill_clk_pdata(dev, &clk_pdata);
> +		if (n_consumers < 0)
> +			return n_consumers;
> +	}

Can it be done in a helper, so we will have here something like this:

	if (board_data->n_clk_consumers)
		n_consumers = skl_int3472_fill_static_clk_pdata(dev, &clk_pdata);
	else
		n_consumers = skl_int3472_fill_clk_pdata(dev, &clk_pdata);
	if (n_consumers < 0)
		return n_consumers;

?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v10 5/8] platform/x86: int3472: tps68470: use a common always-on VIO regulator init_data

[Andy Shevchenko]

On Mon, Aug 31, 2026 at 06:07:51PM +0200, Thierry Chatard wrote:
> The surface_go and intel_nvl board data define byte-identical VIO
> regulator init_data (1.8006 V, apply_uV, always_on). Replace both with a
> single shared common_tps68470_vio_reg_init_data so new boards with the
> same requirement can reuse it instead of duplicating the definition.
> 
> No functional change.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v10 6/8] platform/x86: int3472: tps68470: add board data for Dell Latitude 5285

[Andy Shevchenko]

On Mon, Aug 31, 2026 at 06:07:52PM +0200, Thierry Chatard wrote:
> The Dell Latitude 5285 2-in-1 has two cameras connected through a TPS68470
> PMIC/clock/GPIO hub:
> 
>   Front: OV5670 (ACPI INT3479) on I2C4
>   Back:  OV8858 (ACPI INT3477) on I2C2, daisy-chained behind the TPS68470
>          S_I2C port (controlled by reg 0x43 S_I2C_CTL)
> 
> Add the regulator supply map, GPIO lookup tables and a static clock
> consumer list (for both sensors, to work around the broken INT3479 _DEP)
> for this machine, and wire it into the board-data DMI table.
> 
> Regulator mapping:
>   CORE -> dvdd/INT3477, ANA -> avdd/INT3477, VSIO -> dovdd/INT3477 (opens
>   the S_I2C passthrough), AUX1 -> dvdd/INT3479, AUX2 -> dovdd/INT3479,
>   VIO kept always_on. VSIO also supplies avdd for INT3479 (OV5670).

Now it looks like it should (only + lines in the statistics)
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v10 4/8] platform/x86: int3472: tps68470: add static clock consumer support

[Sakari Ailus]

On Tue, Sep 01, 2026 at 02:12:22PM +0300, Andy Shevchenko wrote:
> On Mon, Aug 31, 2026 at 06:07:50PM +0200, Thierry Chatard wrote:
> > On some platforms a sensor's ACPI _DEP does not list the INT3472 device,
> > so for_each_acpi_consumer_dev() misses that sensor and never registers its
> > tps68470-clk consumer entry, leaving the sensor without its MCLK.
> > 
> > Add optional n_clk_consumers/clk_consumers fields to the board data. When
> > set, probe builds the tps68470-clk platform data from that static list
> > instead of walking the ACPI consumers. Boards that leave the fields unset
> > keep using the existing ACPI traversal.
> 
> ...
> 
> > -	n_consumers = skl_int3472_fill_clk_pdata(dev, &clk_pdata);
> > -	if (n_consumers < 0)
> > -		return n_consumers;
> > +	if (board_data->n_clk_consumers) {
> > +		clk_pdata = devm_kzalloc(dev,
> > +					 struct_size(clk_pdata, consumers,
> > +						     board_data->n_clk_consumers),
> > +					 GFP_KERNEL);
> > +		if (!clk_pdata)
> > +			return -ENOMEM;
> > +		clk_pdata->n_consumers = board_data->n_clk_consumers;
> > +		for (i = 0; i < board_data->n_clk_consumers; i++)
> > +			clk_pdata->consumers[i] = board_data->clk_consumers[i];
> > +		n_consumers = board_data->n_clk_consumers;
> > +	} else {
> > +		n_consumers = skl_int3472_fill_clk_pdata(dev, &clk_pdata);
> > +		if (n_consumers < 0)
> > +			return n_consumers;
> > +	}
> 
> Can it be done in a helper, so we will have here something like this:

Please don't; it's better as-is.

> 
> 	if (board_data->n_clk_consumers)
> 		n_consumers = skl_int3472_fill_static_clk_pdata(dev, &clk_pdata);
> 	else
> 		n_consumers = skl_int3472_fill_clk_pdata(dev, &clk_pdata);
> 	if (n_consumers < 0)
> 		return n_consumers;
> 
> ?
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

-- 
Sakari Ailus

[PATCH] mfd: intel-lpss: add Dell Latitude 7275 to the resource conflict quirk

[D. Manresa]

The Dell Latitude 7275 2-in-1 has the same BIOS bug as the Latitude 5285:
the ACPI GEXP device declares an OperationRegion (BAR0) on the GNVS
variable SB04 and the I2C4 controller (INT3446) builds its _CRS from that
same variable, so intel_lpss_acpi fails to bind the controller with
-EBUSY and the front camera sensor (OV5670, INT3479) is never registered
unless acpi_enforce_resources=lax is passed.

Add the machine to the DMI table so QUIRK_IGNORE_RESOURCE_CONFLICTS is
applied to INT3446 on it as well.

Assisted-by: Claude Code:claude-fable-5-1
Signed-off-by: D. Manresa <dmanresa@gmail.com>
---
Applies on top of "mfd: intel-lpss: add resource conflict quirk for Dell
Latitude 5285" from Thierry Chatard's v10 series [1]. Thierry, feel free
to fold this into v11 instead if you prefer.

The conflict was verified in the 7275 DSDT (BIOS 1.18.0): GEXP has
OperationRegion (BAR0, SystemMemory, SB04, 0x0208) and INT3446._CRS
returns LCRS (SMD4, SB04, SIR4). With acpi_enforce_resources=lax, which
has the same effect as the quirk, the controller binds and the camera
works with the board data from "platform/x86: int3472: Add TPS68470 board
data for Dell Latitude 7275" [2]. The distribution kernel here builds
intel-lpss-acpi in, so this exact patch has not been run yet.

[1] https://lore.kernel.org/linux-media/20260831160754.9857-2-tchatard@gmail.com/
[2] https://lore.kernel.org/platform-driver-x86/20260908161445.334910-1-dmanresa@gmail.com/

 drivers/mfd/intel-lpss-acpi.c | 6 ++++++
 1 file changed, 6 insertions(+)

--- a/drivers/mfd/intel-lpss-acpi.c
+++ b/drivers/mfd/intel-lpss-acpi.c
@@ -191,6 +191,12 @@ static const struct dmi_system_id intel_lpss_quirk_dmi[] = {
 			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Latitude 5285"),
 		},
 	},
+	{
+		.matches = {
+			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Latitude 7275"),
+		},
+	},
 	{ }
 };
 

Re: [PATCH] mfd: intel-lpss: add Dell Latitude 7275 to the resource conflict quirk

[Hans de Goede]

Hi,

On 8-Sep-26 18:16, D. Manresa wrote:
> The Dell Latitude 7275 2-in-1 has the same BIOS bug as the Latitude 5285:
> the ACPI GEXP device declares an OperationRegion (BAR0) on the GNVS
> variable SB04 and the I2C4 controller (INT3446) builds its _CRS from that
> same variable, so intel_lpss_acpi fails to bind the controller with
> -EBUSY and the front camera sensor (OV5670, INT3479) is never registered
> unless acpi_enforce_resources=lax is passed.
> 
> Add the machine to the DMI table so QUIRK_IGNORE_RESOURCE_CONFLICTS is
> applied to INT3446 on it as well.
> 
> Assisted-by: Claude Code:claude-fable-5-1
> Signed-off-by: D. Manresa <dmanresa@gmail.com>

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>


Regards,

Hans



> ---
> Applies on top of "mfd: intel-lpss: add resource conflict quirk for Dell
> Latitude 5285" from Thierry Chatard's v10 series [1]. Thierry, feel free
> to fold this into v11 instead if you prefer.
> 
> The conflict was verified in the 7275 DSDT (BIOS 1.18.0): GEXP has
> OperationRegion (BAR0, SystemMemory, SB04, 0x0208) and INT3446._CRS
> returns LCRS (SMD4, SB04, SIR4). With acpi_enforce_resources=lax, which
> has the same effect as the quirk, the controller binds and the camera
> works with the board data from "platform/x86: int3472: Add TPS68470 board
> data for Dell Latitude 7275" [2]. The distribution kernel here builds
> intel-lpss-acpi in, so this exact patch has not been run yet.
> 
> [1] https://lore.kernel.org/linux-media/20260831160754.9857-2-tchatard@gmail.com/
> [2] https://lore.kernel.org/platform-driver-x86/20260908161445.334910-1-dmanresa@gmail.com/
> 
>  drivers/mfd/intel-lpss-acpi.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> --- a/drivers/mfd/intel-lpss-acpi.c
> +++ b/drivers/mfd/intel-lpss-acpi.c
> @@ -191,6 +191,12 @@ static const struct dmi_system_id intel_lpss_quirk_dmi[] = {
>  			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Latitude 5285"),
>  		},
>  	},
> +	{
> +		.matches = {
> +			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> +			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Latitude 7275"),
> +		},
> +	},
>  	{ }
>  };
>  

Re: [PATCH] mfd: intel-lpss: add Dell Latitude 7275 to the resource conflict quirk

[Andy Shevchenko]

On Tue, Sep 08, 2026 at 06:16:29PM +0200, D. Manresa wrote:
> The Dell Latitude 7275 2-in-1 has the same BIOS bug as the Latitude 5285:
> the ACPI GEXP device declares an OperationRegion (BAR0) on the GNVS
> variable SB04 and the I2C4 controller (INT3446) builds its _CRS from that
> same variable, so intel_lpss_acpi fails to bind the controller with
> -EBUSY and the front camera sensor (OV5670, INT3479) is never registered
> unless acpi_enforce_resources=lax is passed.
> 
> Add the machine to the DMI table so QUIRK_IGNORE_RESOURCE_CONFLICTS is
> applied to INT3446 on it as well.
> 
> Assisted-by: Claude Code:claude-fable-5-1
> Signed-off-by: D. Manresa <dmanresa@gmail.com>
> ---
> Applies on top of "mfd: intel-lpss: add resource conflict quirk for Dell
> Latitude 5285" from Thierry Chatard's v10 series [1]. Thierry, feel free
> to fold this into v11 instead if you prefer.

Do not fold, just add into the series this one as patch 2, for example.

> The conflict was verified in the 7275 DSDT (BIOS 1.18.0): GEXP has
> OperationRegion (BAR0, SystemMemory, SB04, 0x0208) and INT3446._CRS
> returns LCRS (SMD4, SB04, SIR4). With acpi_enforce_resources=lax, which
> has the same effect as the quirk, the controller binds and the camera
> works with the board data from "platform/x86: int3472: Add TPS68470 board
> data for Dell Latitude 7275" [2]. The distribution kernel here builds
> intel-lpss-acpi in, so this exact patch has not been run yet.

The patches still need an Ack from Lee.

> [1] https://lore.kernel.org/linux-media/20260831160754.9857-2-tchatard@gmail.com/
> [2] https://lore.kernel.org/platform-driver-x86/20260908161445.334910-1-dmanresa@gmail.com/
-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] mfd: intel-lpss: add Dell Latitude 7275 to the resource conflict quirk

[D. Manresa]

On Wed, 9 Sep 2026, Andy Shevchenko wrote:
> Do not fold, just add into the series this one as patch 2, for example.

Fine by me. Thierry, please carry it as patch 2 of v11 with Hans'
Reviewed-by; no need to change anything else.

Thanks Hans and Andy for the quick review.

D.

Re: [PATCH] mfd: intel-lpss: add Dell Latitude 7275 to the resource conflict quirk

[Lee Jones]

On Wed, 09 Sep 2026, D. Manresa wrote:

> On Wed, 9 Sep 2026, Andy Shevchenko wrote:
> > Do not fold, just add into the series this one as patch 2, for example.
> 
> Fine by me. Thierry, please carry it as patch 2 of v11 with Hans'
> Reviewed-by; no need to change anything else.

Why can't I just apply it?

-- 
Lee Jones

Re: [PATCH] mfd: intel-lpss: add Dell Latitude 7275 to the resource conflict quirk

[Sakari Ailus]

Hi Lee,

On Wed, Sep 09, 2026 at 04:10:27PM +0100, Lee Jones wrote:
> On Wed, 09 Sep 2026, D. Manresa wrote:
> 
> > On Wed, 9 Sep 2026, Andy Shevchenko wrote:
> > > Do not fold, just add into the series this one as patch 2, for example.
> > 
> > Fine by me. Thierry, please carry it as patch 2 of v11 with Hans'
> > Reviewed-by; no need to change anything else.
> 
> Why can't I just apply it?

There are no direct dependencies to the rest. For the functionality, it
might be nice to merge it via one tree and the rest of the set would go in
via the media tree.

In case you prefer to merge the patch,

Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>

-- 
Regards,

Sakari Ailus

Re: [PATCH] mfd: intel-lpss: add Dell Latitude 7275 to the resource conflict quirk

[Andy Shevchenko]

On Wed, Sep 09, 2026 at 04:10:27PM +0100, Lee Jones wrote:
> On Wed, 09 Sep 2026, D. Manresa wrote:
> 
> > On Wed, 9 Sep 2026, Andy Shevchenko wrote:
> > > Do not fold, just add into the series this one as patch 2, for example.
> > 
> > Fine by me. Thierry, please carry it as patch 2 of v11 with Hans'
> > Reviewed-by; no need to change anything else.
> 
> Why can't I just apply it?

This patch on its own can't be applied as it relies on the one
in the other series. You can apply both patches, from that series
and this one. No objections from my side.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] mfd: intel-lpss: add Dell Latitude 7275 to the resource conflict quirk

[Lee Jones]

On Wed, 09 Sep 2026, Andy Shevchenko wrote:

> On Wed, Sep 09, 2026 at 04:10:27PM +0100, Lee Jones wrote:
> > On Wed, 09 Sep 2026, D. Manresa wrote:
> > 
> > > On Wed, 9 Sep 2026, Andy Shevchenko wrote:
> > > > Do not fold, just add into the series this one as patch 2, for example.
> > > 
> > > Fine by me. Thierry, please carry it as patch 2 of v11 with Hans'
> > > Reviewed-by; no need to change anything else.
> > 
> > Why can't I just apply it?
> 
> This patch on its own can't be applied as it relies on the one
> in the other series. You can apply both patches, from that series
> and this one. No objections from my side.

What is the hard / build dep.  I can't see it.

-- 
Lee Jones

Re: [PATCH] mfd: intel-lpss: add Dell Latitude 7275 to the resource conflict quirk

[Andy Shevchenko]

On Thu, Sep 10, 2026 at 10:47:44AM +0100, Lee Jones wrote:
> On Wed, 09 Sep 2026, Andy Shevchenko wrote:
> > On Wed, Sep 09, 2026 at 04:10:27PM +0100, Lee Jones wrote:
> > > On Wed, 09 Sep 2026, D. Manresa wrote:
> > > 
> > > > On Wed, 9 Sep 2026, Andy Shevchenko wrote:
> > > > > Do not fold, just add into the series this one as patch 2, for example.
> > > > 
> > > > Fine by me. Thierry, please carry it as patch 2 of v11 with Hans'
> > > > Reviewed-by; no need to change anything else.
> > > 
> > > Why can't I just apply it?
> > 
> > This patch on its own can't be applied as it relies on the one
> > in the other series. You can apply both patches, from that series
> > and this one. No objections from my side.
> 
> What is the hard / build dep.  I can't see it.

Build dep. The patch from Thierry's series introduces quirk table in
intel-lpss-acpi.c (currently none, at least in Linux Next), this one
is made on top, it simply may not be applied even if the other is not there.

-- 
With Best Regards,
Andy Shevchenko