Re: [PATCH v4 5/6] iio: dac: ad5504: strictly separate ACPI and DT probe paths

Andy Shevchenko <[email protected]>
Newsgroups org.kernel.vger.linux-devicetree,org.kernel.vger.linux-iio,org.kernel.vger.linux-kernel
Organization Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo
Message-ID <[email protected]>
On Mon, Aug 17, 2026 at 05:11:14PM -0400, Taha Ed-Dafili wrote:
> Refactor the ad5504_probe() function to explicitly separate the ACPI
> and Device Tree execution paths. Previously, the driver relied on a
> fragile -ENODEV return value check from the regulator framework to
> bypass the voltage check on ACPI platforms.
> 
> Following modern IIO subsystem design patterns (such as those found in
> adc/ti-ads7950.c), fork the logic using ACPI_COMPANION(). On ACPI
> systems, where dedicated voltage regulators are typically omitted from
> the firmware description, bypass the regulator subsystem entirely and
> initialize the reference voltage to the hardware default 60V scale via
> a new macro AD5504_VA_MV_ACPI_DEFAULT.
> 
> For Device Tree platforms, treat the VCC regulator as mandatory and
> wrap the allocation in dev_err_probe() to cleanly handle potential
> deferrals and error propagation.

...

> +/*
> + * In case of ACPI, we use the 60 V as default voltage reference.
> + */
> +#define AD5504_VA_MV_ACPI_DEFAULT	(60 * MILLI)

Name it

#define AD5504_VA_ACPI_DEFAULT_mV	(60 * MILLI)

What does VA stand for?

...

> +	if (ACPI_COMPANION(dev)) {

It's better to use has_acpi_companion() or is_acpi_device_node().
I prefer to see the latter as that one unifies the style of checking
across the drivers and subsystems.

For that you will need to use dev_fwnode() from property.h and acpi.h
for the macro itself.

> +		st->vref_mv = AD5504_VA_MV_ACPI_DEFAULT;

...

> -	st->vref_mv = ret / 1000;
> +		st->vref_mv = ret / MILLI;

This should be  (MICRO / MILLI) instead of MILLI.

-- 
With Best Regards,
Andy Shevchenko
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.