unfortunately, a way to turn a SensorId into a refdes is probably required

[hawkw]

since the thermal task deals (exclusively?) in SensorId, and i would really like to be able to have a refdes to use when making an ereport to say which thing it was that was over it's critical temp. putting a SensorId in an ereport is of course unacceptable since the control plane doesn't really know what they are, and we should not have two different ways to identify devices upstack any more than we already do. also they can change if you reorder stuff in the TOML which would be sad.

therefore we will need to have a thingy that takes a sensor ID and gives a refdes back. codegen will undoubtedly be involved.

[hawkw]

actually, hum, perhaps not; we just have to plumb it through from the BSP as a constant, or get it from the I2cDevice. That's not as bad.

[hawkw]

actually, hum, perhaps not; we just have to plumb it through from the BSP as a constant, or get it from the I2cDevice. That's not as bad.

UPDATE: I was wrong about this, it is necessary in the case of dynamic inputs, which the thermal task knows about only as SensorIds and not as I2cDevices. So, since the current thermal code kind of abstracts over the possibility that some things will be dynamic and other things will be I2cDevices that it owns by just dealing in sensor IDs, it's probably better to have a sensor ID to refdes mapping. So we do need this.

[hawkw]

#2383 includes a codegen change to support this. I have to make up my mind a bit about how I want to do it and whether it's worth generating the LUT only for non-I2C sensors to save RAM...