Wow, thaks for the fast analysis!
> Can you please file a PR
Yes, sure, but ...
> explaining this use-case
this sounds like I'm doing something unreasonable?
> including details of why you are using this dbcool attachment
Well, it works (on -8, and probably did on -6):
$ /usr/sbin/envstat
Current CritMax WarnMax WarnMin CritMin Unit
[amdtemp0]
CPU Temp: 28.000 degC
CPU0 Sensor1: N/A
CPU1 Sensor0: 27.000 degC
CPU1 Sensor1: N/A
[dbcool0]
Sys Temp: 24.250 degC
N/A: 28.000 degC
CPU Temp: 28.250 degC
RAM Vcc: 1.356 V
VCore: 3.364 V
3.3V: 2.517 V
5V: 5.139 V
12V: 12.266 V
CPU Fan: N/A
CHA 1 Fan: 7468 RPM
CHA 2 Fan: N/A
CHA 3 Fan: N/A
VID: 8 0 0 0 0 none
and I feed this into our monitoring.
> instead of, say, getting the sensor data through an ACPI
how would I do that?
> or FDT firmware binding
Sorry for my ignorance, but usn't that an ARM thing?
> and how you know it's safe on this board
That once again sounds like I was doing something dangerous or unreasonable.
I can't remember how I came to that configuration (probabably from some
"not configured" messages), but it gives me the data I want (and doesn't
cause any harm on hardware where that chip is not present).
> Adding a null test is probably all this code needs
Do you mean one guarding the prop_object_retain(sc->sc_prop) call?
I would be afraid there's a complementing prop_object_release() call
somewhere, but I don't see one in dbcool_detach(). Most probably I'm
looking in the wrong place.
> but it's not clear to me a priori that this static configuration is sensible
Does what I tried to explain makes sense?
> so I'd just like to make sure of that first.
So do I.
> The PR will help to track pullups.
Yes, sure.
