> Can you please file a PR
kern/59082
> explaining this use-case
I still don't get this. I want to read out sensor readings and don't know
of a better way.
> including details of why you are using this dbcool attachment instead of,
> say, getting the sensor data through an ACPI or FDT firmware binding
I would be happy to learn of another way.
> and how you know it's safe on this board
How should I be definitely knowing that? Disassemble the BIOS?
> and all the symptoms you just shared?
Which symptoms? That the kernel panics? The full backtrace?
But why? It looks like you already instantly found the problem.
> Adding a null test is probably all this code needs
Yes, the two null tests you suggested indeed fixes it for me
Index: sys/dev/i2c/dbcool.c
===================================================================
RCS file: /cvsroot/src/sys/dev/i2c/dbcool.c,v
retrieving revision 1.64
diff -u -p -r1.64 dbcool.c
--- sys/dev/i2c/dbcool.c 30 Mar 2022 00:06:50 -0000 1.64
+++ sys/dev/i2c/dbcool.c 17 Feb 2025 16:11:13 -0000
@@ -776,7 +776,7 @@ dbcool_attach(device_t parent, device_t
sc->sc_dc.dc_writereg = dbcool_writereg;
sc->sc_dev = self;
sc->sc_prop = args->ia_prop;
- prop_object_retain(sc->sc_prop);
+ if (sc->sc_prop != NULL) prop_object_retain(sc->sc_prop);
if (dbcool_chip_ident(&sc->sc_dc) < 0 || sc->sc_dc.dc_chip == NULL)
panic("could not identify chip at addr %d", args->ia_addr);
@@ -1697,7 +1697,7 @@ dbcool_attach_sensor(struct dbcool_softc
name_index = sc->sc_dc.dc_chip->table[idx].name_index;
snprintf(name, 7, "s%02x", sc->sc_dc.dc_chip->table[idx].reg.val_reg);
- if (prop_dictionary_get_string(sc->sc_prop, name, &desc)) {
+ if (sc->sc_prop != NULL && prop_dictionary_get_string(sc->sc_prop,
name, &desc)) {
strlcpy(sc->sc_sensor[idx].desc, desc,
sizeof(sc->sc_sensor[idx].desc));
} else {
