All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Thierry Chatard <tchatard@gmail.com>
Cc: linux-kernel@vger.kernel.org, hansg@kernel.org, lee@kernel.org,
	platform-driver-x86@vger.kernel.org,
	ilpo.jarvinen@linux.intel.com, djrscally@gmail.com,
	linux-media@vger.kernel.org, mchehab@kernel.org,
	sakari.ailus@linux.intel.com, jacopo.mondi@ideasonboard.com,
	nicholas@rothemail.net, v.vitovt@gmail.com
Subject: Re: [PATCH v9 3/6] platform/x86: int3472: tps68470: fix clock consumer registration for Dell Latitude 5285
Date: Thu, 27 Aug 2026 23:35:38 +0300	[thread overview]
Message-ID: <apCfmoIBKLhjexav@ashevche-desk.local> (raw)
In-Reply-To: <20260827201611.99825-4-tchatard@gmail.com>

On Thu, Aug 27, 2026 at 10:16:08PM +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.

Are your patches assisted by AI?

...

>  static int skl_int3472_tps68470_probe(struct i2c_client *client)
>  {
> -	struct acpi_device *adev = ACPI_COMPANION(&client->dev);
> +	struct device *dev = &client->dev;

> +	struct acpi_device *adev = ACPI_COMPANION(dev);

Split the assignment at the same time...

>  	const struct int3472_tps68470_board_data *board_data;
>  	struct tps68470_clk_platform_data *clk_pdata;
> +	struct gpiod_lookup_table * const *tables;
>  	struct mfd_cell *cells;
>  	struct regmap *regmap;
>  	int n_consumers;

...and put it here.

>  	if (!adev)
>  		return -ENODEV;

> +	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");
> +
> +	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)
> +		return -ENOMEM;
> +
> +	/*
> +	 * 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";
> +
> +	tables = board_data->tps68470_gpio_lookup_tables;
> +	for (i = 0; i < board_data->n_gpiod_lookups; i++)
> +		gpiod_add_lookup_table(tables[i]);
> +
> +	ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
> +				   cells, TPS68470_WIN_MFD_CELL_COUNT,
> +				   NULL, 0, NULL);
> +	kfree(cells);
> +
> +	if (ret) {
> +		for (i = 0; i < board_data->n_gpiod_lookups; i++)
> +			gpiod_remove_lookup_table(tables[i]);
> +	}
> +

...

> +++ b/drivers/platform/x86/intel/int3472/tps68470.h

>  struct gpiod_lookup_table;

+ blank line to separate generic and local groups of forward declarations.

> +struct tps68470_clk_consumer;
>  struct tps68470_regulator_platform_data;

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2026-08-27 20:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-27 20:16 [PATCH v9 0/6] Enable cameras on Dell Latitude 5285 2-in-1 Thierry Chatard
2026-08-27 20:16 ` [PATCH v9 1/6] mfd: intel-lpss: add resource conflict quirk for Dell Latitude 5285 Thierry Chatard
2026-08-27 20:16 ` [PATCH v9 2/6] platform/x86: int3472: tps68470: use unsigned int for GPIO lookup loop counters Thierry Chatard
2026-08-27 20:32   ` Andy Shevchenko
2026-08-27 20:16 ` [PATCH v9 3/6] platform/x86: int3472: tps68470: fix clock consumer registration for Dell Latitude 5285 Thierry Chatard
2026-08-27 20:35   ` Andy Shevchenko [this message]
2026-08-28  8:45   ` Sakari Ailus
2026-08-27 20:16 ` [PATCH v9 4/6] platform/x86: int3472: tps68470: add board data " Thierry Chatard
2026-08-28  8:03   ` Sakari Ailus
2026-08-27 20:16 ` [PATCH v9 5/6] media: ipu-bridge: add sensor configuration for OV8858 (INT3477) Thierry Chatard
2026-08-27 20:16 ` [PATCH v9 6/6] media: ov8858: add ACPI device ID INT3477 Thierry Chatard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=apCfmoIBKLhjexav@ashevche-desk.local \
    --to=andriy.shevchenko@intel.com \
    --cc=djrscally@gmail.com \
    --cc=hansg@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jacopo.mondi@ideasonboard.com \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=nicholas@rothemail.net \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=tchatard@gmail.com \
    --cc=v.vitovt@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.