On Fri, 15 May 2026 16:58:01 +0200 Alexander Hansen <[email protected]> wrote:
> Product: [1] > Datasheet: [2] > > Sensor readings can be provided upon creation of the device. In case no > readings are provided the ADC reads a pre-defined arbitrary value. > > root@yosemite4:~# cat /sys/bus/iio/devices/iio:device2/name > max11615 > root@yosemite4:~# cat /sys/bus/iio/devices/iio:device2/in_voltage0_raw > 1922 > root@yosemite4:~# cat /sys/bus/iio/devices/iio:device2/in_voltage_scale > 0.500000000 As I mentioned on v1 a lot of the standard linux driver operations with this device will not work. The emulation doesn't deal with multi channel scans for example. So what is the purpose of limited emulation vs just not emulating it at all. (which will fail a couple more things obviously!) I'm not sure what the standard expectations are for this when the features that aren't emulated are not discoverable (i.e. the driver can't tell it should not use them). Jonathan > > trace: > less /tmp/qemu-trace.log | grep -i max116 > max11615_realize i2c_addr: 0x33 > max11615_realize i2c_addr: 0x33 > max11615_event i2c_addr: 0x33, event: 0x01 > max11615_write_setup i2c_addr: 0x33, data: 0xd2 > max11615_write_config i2c_addr: 0x33, data: 0x0f > max11615_event i2c_addr: 0x33, event: 0x03 > max11615_event i2c_addr: 0x33, event: 0x01 > max11615_write_setup i2c_addr: 0x33, data: 0xd2 > max11615_write_config i2c_addr: 0x33, data: 0x0f > max11615_event i2c_addr: 0x33, event: 0x03 > max11615_event i2c_addr: 0x33, event: 0x01 > max11615_write_setup i2c_addr: 0x33, data: 0xd2 > max11615_write_config i2c_addr: 0x33, data: 0x61 > max11615_event i2c_addr: 0x33, event: 0x03 > max11615_event i2c_addr: 0x33, event: 0x00 > max11615_recv i2c_addr: 0x33, reg_addr: 0x00 > max11615_recv_return i2c_addr: 0x33, returns: 0xfa > max11615_recv i2c_addr: 0x33, reg_addr: 0x00 > max11615_recv_return i2c_addr: 0x33, returns: 0xd2 > max11615_event i2c_addr: 0x33, event: 0x04 > max11615_event i2c_addr: 0x33, event: 0x03
