ADF4350 driver issues on master

[rgetz]

booting a master kernel with a 2019R1 device tree on ZedBoard + FMCOMMS3, gives me this during boot:

adf4350 spi1.0: spi1.0 supply vcc not found, using dummy regulator
adf4350 spi1.0: Linked as a consumer to regulator.0
adf4350 spi1.1: spi1.1 supply vcc not found, using dummy regulator
adf4350 spi1.1: Linked as a consumer to regulator.0

which is fine - this device has no way to tell if it is there or not (it's a write only device), if device tree says it is there - it is.

two issues:

wrong IIO name

names shouldn't be the spi bus - it should be the device name.

iio_attr -c
IIO context has 8 devices:
    iio:device0, ad7291: found 9 channels
    iio:device1, ad9361-phy: found 11 channels
    iio:device2, xadc: found 9 channels
    iio:device3, spi1.0: found 1 channels
    iio:device4, spi1.1: found 1 channels
    iio:device5, cf-ad9361-dds-core-lpc: found 12 channels
    iio:device6, cf-ad9361-lpc: found 4 channels
    iio_sysfs_trigger: found 0 channels

Why is it in device tree?

dtc -I fs /sys/firmware/devicetree/base | less

 adf4351-udc-rx-pmod@1 {
 adf4351-udc-tx-pmod@0 {

why is that in the FMCOMMS2/3 device tree? That should only be in the FMCOMMS5.

[mhennerich]

Wrong IIO name - this used to work. See here: https://wiki.analog.com/resources/tools-software/linux-drivers/iio-pll/adf4350#driver_testing

I guess this broke by the patch which added of bindings, and the way we instantiate the device.

adf4351-udc-rx-pmod@1 { adf4351-udc-tx-pmod@0 {

Why is it in device tree? It's the UP DOWN converter, which is in those projects the PMOD header supports it by the HDL.

[rgetz]

Thanks - makes sense on the ADF4351.

Someone will look into the naming issue?

[mhennerich]

This should be easy to fix.

[mhennerich]

https://github.com/analogdevicesinc/linux/pull/1026

[commodo]

PR #1026 was merged