Re: [PATCH v8 3/6] platform/x86: int3472: tps68470: fix clock consumer registration for Dell Latitude 5285

[Andy Shevchenko]

On Wed, Aug 26, 2026 at 01:24:48PM +0200, Thierry Chatard wrote:
> The BIOS on the Dell Latitude 5285 leaves GNVS field C0TP at zero.
> With C0TP=0 the ACPI _DEP method on INT3479 (OV5670, front camera)
> resolves to PCI0 instead of the INT3472 (TPS68470 PMIC) device.
> 
> Because for_each_acpi_consumer_dev() walks the _DEP reverse-mapping,
> INT3479 is invisible to it: the clock consumer lookup entry for the
> front camera is never registered with the tps68470-clk driver, and the
> OV5670 sensor driver cannot acquire its MCLK.
> 
> Add optional static clock consumer fields to the board data so probe can
> register the consumers directly, bypassing the broken _DEP traversal.
> Platforms that do not set these fields keep using the existing ACPI
> traversal path unchanged.

...

>  	struct mfd_cell *cells;
>  	struct regmap *regmap;
>  	int n_consumers;
>  	int device_type;
> -	int ret;
>  	unsigned int i;
> +	int ret;

Yep, this is leftover which needs to be folded into the previous patch.

...

> +	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");

Define

	struct device *dev = &client->dev;

at the top and make these lines better looking

	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");

(note that switching to -ENODATA helps to distinguish the case).


...

> +	ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_NONE,
> +				   cells, TPS68470_WIN_MFD_CELL_COUNT,
> +				   NULL, 0, NULL);

> +	kfree(cells);

Looks like we can switch to use __free() at some point.

> +	if (ret) {
> +		for (i = 0; i < board_data->n_gpiod_lookups; i++)
> +			gpiod_remove_lookup_table(tables[i]);
> +	}


-- 
With Best Regards,
Andy Shevchenko