[Bug 268835] Use BUS_PASS_INTERRUPT+BUS_PASS_ORDER_LATE for bcm_dma

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268835

            Bug ID: 268835
           Summary: Use BUS_PASS_INTERRUPT+BUS_PASS_ORDER_LATE for bcm_dma
           Product: Base System
           Version: CURRENT
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: marklmi26-fbsd@yahoo.com
                CC: manu@freebsd.org

Created attachment 239352
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239352&action=edit
main [so: 14]: Use BUS_PASS_INTERRUPT+BUS_PASS_ORDER_LATE for bcm_dma

Use BUS_PASS_INTERRUPT+BUS_PASS_ORDER_LATE for bcm_dma
for both main [so: 14] and stable/13 .

I'll also be adding an attachment for the stable/13 case
since stable/13 and main do not match in the very few lines
involved.

This avoids crashes for booting with newer RPi* firmware
than is in sysutils/rpi-firmware . But this is not a proposal
for updating sysutils/rpi-firmware at all.

I've my own interest in testing something with newer firmware.
I've also seen reports about *.dtb files that do not exist
in sysutils/rpi-firmware . At some point someone might put in
the work to add support for such RPi* devices. If anyone does,
they likely would like to avoid the stage if dealing with the
boot-crash that now happens.

My test context had:

"C0T" 8 GiByte Rev1.5 RPi4B
"B0T" 8 GiByte Rev1.4 and 4 GiByte Rev1.1 RPI4Bs
RPi3B
RPi2B v1.2
RPi2B v1.1 (so: armv7)

and some non-RPi*'s:

ThreadRipper 1950X (so an amd64)
HoneyComb
MACCHIATObin Double Shot
Rock64
OrangePi+2ed (so: armv7)

For aarch64 and armv7, I test the same boot media both
on RPi*'s and at least one non-RPi*  My testing spanned
main and stable/13 examples.

I've tried multiple tagged RPI* firmware releases and none
lead to a crash with the change in place. The non-RPI*'s
continued to work normally.

For reference, all the boot media are now at (picking an
example system):

# uname -apKU # Long output line split for readability
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #75
main-n259950-5723e5ac6d76-dirty: Fri Jan  6 01:50:53 PST 2023    
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400077 1400077

-- 
You are receiving this mail because:
You are the assignee for the bug.