Skip to content

AD5686 driver fixes#3218

Closed
rodrigo455 wants to merge 6 commits intomainfrom
staging/ad5313r-iio-support
Closed

AD5686 driver fixes#3218
rodrigo455 wants to merge 6 commits intomainfrom
staging/ad5313r-iio-support

Conversation

@rodrigo455
Copy link
Copy Markdown
Collaborator

@rodrigo455 rodrigo455 commented Mar 27, 2026

AD5686 fixes

This series implements some fixes, cleanups, backports to the AD5686 device driver.

PR Type

  • Bug fix (a change that fixes an issue)
  • New feature (a change that adds new functionality)
  • Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

  • I have conducted a self-review of my own code changes
  • I have compiled my changes, including the documentation
  • I have tested the changes on the relevant hardware
  • I have updated the documentation outside this repo accordingly
  • I have provided links for the relevant upstream lore

@nunojsa
Copy link
Copy Markdown
Collaborator

nunojsa commented Mar 31, 2026

Hi @rodrigo455, is this something to be upstreamed? If so, open the PR against the mirror/ branch that makes sense (iio in this case)

@rodrigo455
Copy link
Copy Markdown
Collaborator Author

rodrigo455 commented Mar 31, 2026

Hi @rodrigo455, is this something to be upstreamed? If so, open the PR against the mirror/ branch that makes sense (iio in this case)

The device support itself can be upstreamed, but I am not sure if that is going to be fine like that, given that the chip info table is declared in a separate file. Most of the other changes here are applicable to features that are not even available upstream, like the triggered buffer support. In main, this driver has a weird PMW trigger that does not make much sense to be here (maybe it should be a separate trigger driver).

I can put together a branch for the device support to be upstreamed, and modify this one just with the fixes?

dlech and others added 6 commits March 31, 2026 15:09
Fix a copy/paste mistake in the struct ad5686_state doc comment.

Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20241120-iio-regulator-cleanup-round-6-v1-2-d5a5360f7ec3@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Simplify the code by using devm_regulator_get_enable_read_voltage().

There is a small change in behavior. Before, all errors from
devm_regulator_get_optional() were ignored and assumed to mean that
the external reference supply was absent. Now, only -ENODEV is checked
and other errors will cause a failure to probe. So now, this will
catch errors, like using the wrong data type for the devicetree
property.

Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20241120-iio-regulator-cleanup-round-6-v1-3-d5a5360f7ec3@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Adopt proper mutex lifecycle with devm_mutex_init(), replacing
mutex_init(). Also, mutex_init() was being called twice.

Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Trigger validation forces internal trigger to be used. Such trigger
ends up being very specific by using a PWM signal to trigger interrupts.
Thus, internal trigger allocation and config is conditioned to the
existence of the irq. Also, state struct is used as trigger drvdata
instead of indio_dev for simplicity and -ENOMEM is properly returned in
case of trigger allocation failure.

Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Sample for the first channel was repeated over all the channels.
Endianness conversion is already taken care inside the write function
implementation. Also, IIO_TRIGGERED_BUFFER dependency is missing in
Kconfig.

Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Since PWM is an optional feature, any other error (notably -EPROBE_DEFER
if the PWM controller hasn't probed yet) falls through to dev_err_probe(),
Otherwise, NULL is assigned to the pwm pointer:
- ENOENT: No pwms property available, as it is intentionally not
  configured.
- ENODEV: kernel build does not have CONFIG_PWM support.
Also, "pwm-trigger" name is dropped, as there is no other pwm to consider.

Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
@rodrigo455 rodrigo455 force-pushed the staging/ad5313r-iio-support branch from ce34a89 to 720f236 Compare March 31, 2026 14:49
@rodrigo455 rodrigo455 changed the title Add AD5313R support AD5686 driver fixes Mar 31, 2026
@nunojsa
Copy link
Copy Markdown
Collaborator

nunojsa commented Apr 2, 2026

Can we close this one? I think this now being handled in #3232 ?

@rodrigo455 rodrigo455 closed this Apr 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants