Page MenuHomeFreeBSD

pmu: avoid NULL ofw_get_bus_type(); handle pmu_send() calls w/ NULL recv buffers
Needs ReviewPublic

Authored by adrian on Jan 19 2026, 1:20 AM.
Referenced Files
F175600612: D54771.id.diff
Sun, Oct 11, 11:18 PM
F175536292: D54771.diff
Sun, Oct 11, 1:30 PM
Unknown Object (File)
Wed, Oct 7, 11:23 PM
Unknown Object (File)
Fri, Oct 2, 9:27 PM
Unknown Object (File)
Mon, Sep 28, 2:06 PM
Unknown Object (File)
Fri, Sep 25, 5:02 PM
Unknown Object (File)
Wed, Sep 23, 10:20 PM
Unknown Object (File)
Sep 6 2026, 3:49 PM

Details

Reviewers
None
Group Reviewers
PowerPC
Summary

When booting in qemu with "-machine=mac99,via=pmu" I found two
things:

  • the "extint-gpio1" check returned NULL, so doing a strcmp() on it is wrong, and
  • a couple of places (notably the LED path) was calling pmu_send() with no receive buffer, leading to results being written to a NULL buffer.

Fix both of these, allowing boot to continue.

Locally tested:

  • qemu-system-ppc64 -machine=mac99,via=pmu -cpu 970fx -smp 1

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 69977
Build 66860: arc lint + arc unit

Event Timeline

The type NULL checks are good. I think the whole of the changes for pmu_send() are a bit overkill. Could you test with just the one line I pointed out, and the rest reverted?

sys/powerpc/powermac/pmu.c
634

I *think* this is the only change needed in this function. The expectation is that the callers (all in this file) know already that a response is needed or not. PMU_SET_SLEEPLED, 0xee, has a pmu_receive_cmd_type entry of -1,

the "extint-gpio1" check returned NULL

Passed NULL because ofw_bus_get_type returned NULL?

sys/powerpc/powermac/pmu.c
634

else after a goto is a bit confusing... may be worth making that less weird as a separate change? Then I'd probably swap this with the out_len read, groups the out_msg writes together rather than interleaving things.

641

Unnecessary change