Hi Jonathan, i just sent out a v5 which should address at least some of
the comments you had for MAX11615 on v3 of this patchset.
I do appreciate the detailed feedback, apparently you know a lot about
this device.
Overall i did underestimate the difficulty of making a good emulation
for any of these 3 devices i am targeting as part of yv4 support. Maybe
i should have started with only MAX31790, but i needed all 3 of those
for my OpenBMC development use-case.
I would still like to continue the work on these. Iterating on 3 devices
at the same time can be challenging for someone starting out,
so most of my focus is on getting machine + functional test in, then
MAX31790, then the others.
> So what is the purpose of limited emulation vs just not emulating it
at all. My use-case for these devices is to support firmware
development, specifically OpenBMC development on that platform.
For that purpose it is already sufficient since the drivers probe and
provide readings. If i find gaps later, i can address them.
Of course if someone else wants a specific feature of the sensor
supported or finds a bug in any of these patches i am happy
to implement these things :)
Thanks again for reviewing,
Alexander
On 5/29/26 14:39, Jonathan Cameron wrote:
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
