analogdevicesinc
ad7779 driver
v3:
- removed power_mode from ext info and added it in pm_ops
- added of_table and chip_info
- addressed styling issues
- removed filter_type attr from devices that do not support it
- switched to get_optional where it was the case
- added Documentation/ABI/testing file for ext_info attrs
- removed redundant code
- switched to FIELD_GET where it was the case
- changed additionalProperties -> unevaluatedProperties
- moved calibbias & calibscale read/write to separate functions
v4:
- addressed one checkpatch warning
Regarding the naming, I initially started the development on ad7779 and only later I found out about the other two parts in the family, so I didn't change the name of the files. Should it be switched to ad7770/ad777x?
Not sure about the current state of the upstream axi-adc driver (if it is up to date or not), but did you consider sending the non-axi version upstream? Might simplify the review process. Afterwards you can add a separate patch in our tree for the axi-adc support that should be pretty straightforward.
Please don't use the upstream axi-adc... It's also fairly broken and I intend to start work on it in the next few weeks (if nothing else comes). But If there's a "non axi" version that's upstreamable, please go for it.
If everything is considered ok on this version I will split the commits and send the "non-axi" version upstream, but of there are other issues to be addressed I would do that first to make sure all is in order first
v5:
- removed a comment from the code
The remaining checkpatch issue is that index is used for multiple fields in the channel definition(address, channel, scan_index). Should I separate them into 3 variables or is it redundant?
@ranechita , what's the status for this PULL? Did you ever sent the patches upstream?
@ranechita , what's the status for this PULL? Did you ever sent the patches upstream?
No, but I will rebase it and split the commits, and then send it upstream. Until then if there are further reviews on the code, I can fix those first
v6:
- rebased with main and split the commits in order to send non-axi version upstream
@nunojsa The upstream version is without axi, I will upstream a new patch that uses iio-backend for axi and it will added to a different branch. Is it ok if I close this pull request in this case?
@nunojsa The upstream version is without axi, I will upstream a new patch that uses iio-backend for axi and it will added to a different branch. Is it ok if I close this pull request in this case?
Do you have any updates on this? If you think it makes sense, please go ahead and close this PR
Someone else is now handling the iio-backend integration and as far as I know it is close to being submitted. I will close this pull request as it will probably be merged from a different branch